灵感来源：一份AI产品经理笔试题

前段时间，我参加了豆包的AI产品经理笔试。题目很有趣：针对Manus这类通用Agent，为特定人群设计特定场景，并完成从需求拆解到工具定义的完整方案。

完成笔试期间，我系统性研究了 OpenAI Function Calling、Anthropic Tool Use等工具接口规范和 Agent 调度机制，以及Manus首席科学家Peak Ji分享的Context Engineering最佳实践。在那之后，我的工具设计思路发生了极大变化。

在在反复自我推翻和重建的过程中，我慢慢意识到，答案最终都落回了三个维度：场景挖掘、架构思维和评测能力。

我的笔试答卷就是本文的底稿，我希望以我的思路的转变为视角，对通用 Agent 如何在垂直高价值场景实现确定性的交付做一次完整推演。

（1）通用Agent要朝哪里突围？

Manus 作为全球首批能够独立思考、动态规划和决策的通用 AI Agent，其核心价值在于完全的自主性和异步云端执行模式 。但作为产品经理，我们必须诚实地面对用户对它的两极评价：能力强大，但昂贵且缓慢。

1.1 重新理解 Manus 的价值坐标

Manus 的架构特点：基于云端的 Ubuntu 虚拟机沙盒、完整的 Shell 权限、文件系统以及“计划—执行—观察”的 Agent Loop。

分析当前任务➡️选择合适工具➡️执行获取结果➡️写入记忆➡️迭代，循环直至完成任务。

在需要即时响应或低成本的简单场景中，Manus 并不具备竞争力 。它的真正价值主张在于其结果的深度、广度与完整性 。对于目标用户而言，一份耗时半小时但全面、准确、深入的分析报告，远比一份耗时一分钟但肤浅的回答更有价值。

因此，Manus 不应该追求成为各方面 80 分的万能助手，而应聚焦于那些结果质量远比速度和成本重要的细分市场，交付接近满分的专业服务。

1.2 用户+场景锁定：证券分析师的财报季

基于上述定位，Manus的理想用户是一位典型的高级知识工作者。这个角色的核心工作并非执行简单的重复性任务，而是将海量的、非结构化的或半结构化的信息，整合成结构化的、可操作的洞察或战略建议。

他们的核心痛点是信息过载，以及处理海量信息所付出的巨大时间与人力成本。

Manus能将他们从这种低层次的劳动中解放出来，让他们能专注于更高层次的战略思考、创造性分析和最终决策。

如果 Manus 要重点投入一个特定用户人群，我认为证券分析师是很有潜力的切入点；而财报季则应该是Agent落地的第一个场景。

为什么？

• 工作流的高粘性与SOP化：证券分析师的工作流具有极强的周期性。每到财报季，他们都需要重复执行一套固定的 SOP：回顾历史、下载财报、提取数据、更新模型、听电话会、撰写报告。这种既定且高频的流程，是 Agent 介入的最佳土壤。
• 痛点够痛：财报发布后，分析师需要在 SEC EDGAR、公司官网、新闻稿和 Excel 模型之间反复切换。他们不得不手动把非结构化的数据录入到复杂的Excel模型中，这个过程不仅被视为知识工作中的 “dirty work”，而且极易出错。一个数字的录入错误，可能导致整个模型的偏差，导致严重后果。
• 离钱最近，ROI 最清晰：金融行业为效率付费的意愿极强。Manus 在此的 ROI 能够被清晰量化：它不仅是将分析师从数小时的机械劳动中解放出来，更能通过更快的分析速度和更广的覆盖范围，帮助机构在市场做出反应前发现Alpha机会。

---

（2）Agent拟人化陷阱，我踩了

选定用户和场景后，我需要设计一套完整的Agent架构和工具定义来承接这个复杂工作流。在这个过程中，我经历了一次深刻的思路转变。

2.1 理想很丰满，直到sub agents崩塌

最初的方案受到Multi-Agent 框架的影响，我的理念是模拟一个高效的人类研究团队，由一个“首席分析师”角色的Planner Agent和多个专家角色的sub agents构成，接着再为这些sub agents分别设计工具。

Sub agents包括负责读财报的“Filing Parser”，负责查数据的“Data Verifier”，专门更新模型的“Modeler”，负责写报告的“Report Drafter”等等。

这种多角色分工的思路在逻辑上非常顺畅，仿佛只要把角色定义好，它们就能像人类团队一样协作。

然而，这套方案被残酷的现实暴打。

我发现，当任务链路变长时，这种基于自然语言对话的 Multi-Agent 系统极其脆弱。

上下文爆炸： 多个Agent之间反复转发大段的财报原文，导致上下文窗口迅速被填满，不仅成本高昂，模型性能也随之下降。

灾难性遗忘：随着推理轮次增加，Agent很容易遗忘最初提及的信息。注意力不断被新的信息挤占，最初下达的核心指令被逐渐遗忘，sub agent甚至开始调用不存在的工具。

无法debug：出错后找不到是哪个sub agent出的问题，没有审计日志和checkpoint。

Sub agent信息同步困难：靠自然语言传话的松耦合交接，看着灵活，其实是开盲盒。输入输出数据结构模糊，不利于容错、重试和审计。没有严格的接口定义，没有结构化的数据契约，Agent之间就像夏洛问大爷，问了个寂寞。

花里胡哨的sub agent设计只能在demo里，落地的关键在于结构化的状态管理，每次工具调用都有清晰的权责边界。

2.2 新架构——Orchestrator+工具集

在扒了OpenAI Function Calling, Anthropic Tool Use相关技术文档，参考了Manus首席科学家季逸超分享的上下文工程经验之后，我彻底放弃了多Sub agent的架构，转而采用 Orchestrator+ 标准化工具集的新架构。

• Orchestrator ：只负责任务分解、链路规划与状态追踪。
• 七个无状态工具：针对财报季的工作流，定义 7 个原子化的工具。每个工具都必须有明确的工具描述、输入参数、输出参数、工具使用说明。

• 工具描述：一句话说明工具做什么，指向一个明确的专业任务（比如提取数据、事实校验、模型更新）

• 输入参数：使用 JSON Schema 明确输入字段，规定数据类型（string/array/object）

• 输出参数：同样用 JSON Schema 定义返回格式，确保工具输出可被下游使用

• 工具使用说明：给模型写的使用说明书，规定啥时候调用、参数怎么填、返回结果怎么解读、出错怎么处理

七个工具可被归纳为三个模块：

1. 数据准备

• data_fetcher：数据入口。从SEC、FactSet等不同供应商那里抓取标准化数据，屏蔽底层API差异。
• financial_doc_parser：文档解析。阅读复杂的10-K/10-Q报告、新闻稿PDF，将非结构化的表格和文字，转化为机器可读的结构化数据。

2. 核心加工

• fact_validator：质检。对解析出的数据进行交叉验证，识别数值矛盾、会计勾稽问题，为后续步骤提供可信输入。
• model_updater：更新模型。将验证通过的数据，精准写入分析师复杂的Excel财务模型，完成耗时最长、最易出错的手动更新环节。

3. 交付输出

• report_assembler：排版工。将数据与分析结论，填充到预定义的模板中，生成格式统一、可直接分发的PDF或DOCX报告。
• compliance_checker：法务合规。对最终报告进行合规扫描，确保内容符合信息披露规范。
• communication_sender：邮件发送。在合规检查通过后，将报告安全发送给指定对象，并默认强制要求人工确认，实现权责的最终交接。

（3）复盘：定义可靠的工具

架构改变只是第一步，在证券分析师财报季这个场景中，Agent面临的难题是近乎于零的容错空间。下面分享五个关键的设计策略：

1. 防御性Schema设计：约束幻觉

大模型最擅长生成内容，但这个特性在工具调用时反而成了致命伤。模型经常会自作聪明地编造时间格式，比如把Q（季度）写成2Q，或者虚构不存在的股票代码，甚至直接编造不存在的工具，直接导致下游系统崩溃。

应对的办法是通过Schema的强类型约束。以data_fetcher工具为例，为了限制模型自由发挥，我使用了枚举选项来限制时间跨度：

"interval": {    "type": "string",    "enum": ["D", "W", "M", "Q", "A","none"],    "description": "时间粒度（价格类数据必填；其余填none）"}

💡 踩坑心得：约束反而是自由。工具参数层就得把模型的创造力压制住，只留决策力，只能选不能编。

2. 上下文卸载：重活外包

金融场景的挑战在于，一份财报PDF动辄几十页。如果直接把解析后的文本喂给模型，抛开token成本十分炸裂，还会出现灾难性遗忘。上下文太长，模型记不住前面的关键信息，Agent掉链子是必然。

我参考了Manus首席科学家Peak分享的策略，使用上下文卸载 (Context Offloading)：将文件系统视为终极上下文，将计算与记忆解耦，利用文件系统作为外化的、结构化的记忆**。模型不需要背出所有的财报数据，就像这个场景的中的用户——证券分析师不需要背诵所有的财报数据，他们只需要知道文件夹的路径然后在需要时查看。**

在model_updater工具中，我不再传递完整的财务数据JSON，而是只传递文件路径：

"parsed_core_path": {    "type": "string",    "description": "来自financial_doc_parser的parsed_core.json路径"}

💡 踩坑心得：优秀Agent的设计要遵循重活外包，决策内化的原则。让工具处理繁重数据，让模型专注逻辑判断。

3. 幂等性设计：为失败预留后路

模型的推理具有不确定性，网络环境也存在波动。在执行长链路任务时，重试是不可避免的。

如果工具不支持幂等操作，一次重试就可能导致数据重复写入，甚至触发多次扣款，这是从demo走向生产场景的致命问题。

所以，我在所有写入类工具中都强制加入了幂等键：

"idempotency_key": {    "type": "string",    "description": "幂等键；相同输入与版本下生成相同结果"}

有了这个，Orchestrator就可以放心大胆重试，不用担心工具搞乱数据。

💡 踩坑心得：提前给失败留后路。承认Agent会出错，并提供后悔药。

4. 错误也得结构化：工具的返回值就是系统提示词

工具执行失败了，如果光返回一个`error`，大模型要么开始编数据，要么陷入死循环反复调用。

Anthropic的经验是：工具输出也是Prompt的一部分。

所以在financial_doc_parser工具里，我设计了一套详细的反馈结构：

"issues": {    "type": "array",    "items": {        "properties": {            "code": { "type": "string" },            "suggestion": {                 "type": "string",                "description": "如'retry' | 'switch_source' | 'HITL'"             }        }    }}

解析失败时，工具不仅报错，还通过字段告诉模型下一步怎么办——是重试，换数据源，还是喊人来帮忙。这招把错误处理逻辑前置到工具层，引导模型自我修正。
``````plaintext
💡 踩坑心得：失败也得有导航。不指望一次成功，而是设计一套机制，让工具在出错时有修复的方向。

这时候Human-in-the-loop（人在回路）机制需要介入。Langchain创始人Harrison Chase同样推崇在涉及高风险操作时，
必须加入这一环节。

communication_sender

"require_human_confirm": {    "type": "boolean",    "default": true,    "description": "是否强制人工确认后才发送"}

在专业场景下，PM不仅需要懂技术的边界，更需要理解真实世界的
权责边界，让用户能够产生真正的信任感。

💡 踩坑心得：放弃部分效率，是AI产品走向成熟的标志。 让AI做什么和做不到什么，一样重要。

结语：AI 产品经理的「新三板斧」

回顾这次笔试，以及过程中对Agent架构的思考，我最深刻的体会是：AI产品经理的技能树将会持续迭代。

在Andrej Karpathy定义的decade of AI Agent中，AI PM需要掌握「新三板斧」：

1. 场景挖掘能力决定产品价值高度

基座模型的边际效应正在递减，真正的价值藏在那些被遗漏的长尾需求中。产品经理的业务解构能力——将模糊的非结构化需求，拆解为模型可理解、工具可执行的标准化流程。只有深入到业务流最泥泞的地方，才能构建出不可替代的护城河。

2. 架构思维比 Prompt Engineering更重要

Prompt Engineering 是有效的优化技巧，但真正的核心竞争力在于系统架构。LLM本质上是概率模型，而我们不能只依赖模型的「灵感」，需要为概率系统注入确定性的逻辑约束。这本质上是控制论中的「负反馈回路」，是一套检测+修正误差的闭环机制。

用确定性的逻辑架构去包裹概率性的模型内核，是 AI 工程化的必经之路。架构师思维，将是未来 AI PM 的标配。

3. 评测能力会决定产品下限

Agent的成熟始于对失败的系统性管理。工具作为Agent的手脚，必须内置清晰的失败响应与降级机制。

真正的系统韧性来自高频、定量的错误分析。通过持续的压力测试得到的「失败矩阵」是产品迭代的指南针。AI PM对评测标准的定义能力和对失败的深度剖析能力会决定产品的下限。

未来的 AI 产品经理，必须是半个业务专家、半个系统架构师，以及一个绝对的长期主义者。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】