AIPM 课程第十天，主题是 Agent 五大核心能力的深入展开 + 底层工具调用基础设施（Function Calling / MCP）。Day9 搭骨架，Day10 把肉填满，并往下挖到"工具调用范式演进"这一层。
授课结构
| 主题 | 对应概念页 |
|---|---|
| 调研类 Agent 案例引入 5 大核心能力（Reflection / Tool Use / Planning / Memory / Multi-Agent） | Agent五要素技术定义 |
| Reflection：单 Agent 自反思 vs 双 Agent 生成+批评 + 何时不用 | Agent规划与反思 |
| Tool Use 工作机制 + Tool Use vs RPA | Agent工具与行动 |
| Planning 3 范式深入对比表（CoT / ReAct / Plan-and-Execute） | Agent规划与反思 |
| 全自动 / 半自动 / 人驱动 Planning（Devin / Kimi K2 / Cursor 案例） | Agent规划与反思 |
| Planning 常见翻车（过度拆解 / 计划僵死） | Agent规划与反思 |
| Multi-Agent Collaboration（Claude Research：Lead Researcher + Subagent） | Multi-Agent协作 |
| Agent 模式选择决策树 | Agent vs Workflow |
| Function Calling 4 步 + Plugin vs FC 演进 | Function Calling与MCP |
| MCP：Agent 的 USB-C + 架构图 + 前后端区分 | Function Calling与MCP |
| FC 与 MCP 的上下层关系（不是替代） | Function Calling与MCP |
| Code Execution with MCP：Token 节省 95%+ 新范式 | Function Calling与MCP |
串联逻辑
Day10 是从"应用层一路下沉到协议层"的一天——
- 应用层：把 Day9 的五要素重新组织成"5 种核心能力"视角（Reflection / Tool Use / Planning / Memory / Multi-Agent），每个能力配一个具体的产品案例（Claude Research / Kimi K2 / Cursor / Devin），让 PM 看到不同公司在五要素上各自的取舍
- 范式层：Planning 抽出来单独深挖——CoT/ReAct/Plan-and-Execute 三范式不只是技术名词，每个范式对应一类产品形态和成本结构（ChatGPT o1 是 CoT / LangChain 是 ReAct / Claude Code 是 Plan-and-Execute）
- 协议层：Function Calling 解决"LLM 怎么输出结构化调用请求"（模型层），MCP 解决"工具怎么标准化暴露"（协议层），二者是上下层而非替代关系。Code Execution with MCP 是当前最前沿的优化范式，能把 Context 从 5000 Token 压到 200 Token
这条线把"PM 怎么决策"和"工程怎么实现"连了起来。
课堂笔记要点
- Reflection 能 work 的根本原因：模型的"鉴赏力"比"创作力"强——它能写出一篇 70 分的文章，但给它一篇 70 分的文章它能指出"这里逻辑不连贯、那里数据没引用、开头太平淡"。鉴赏 > 创作 是反思机制成立的前提。
- Reflection 不是万能锤：简单任务（翻译一句话、提取数据）、实时交互场景（客服）、评估标准不清（创意写作）这三类不该加 Reflection——只在"质量要求高 + 评估标准明确 + 用户能等"的场景下使用。
- Tool Use vs RPA：RPA 是流水线机械臂（按固定脚本死板执行，页面改版就崩），Agent Tool Use 是实习生的双手（LLM 动态决定用哪个工具、传什么参数，能理解变化、调整操作）。适用范围：RPA 高频重复标准流程 / Agent Tool Use 需要判断力的非标场景。
- 三范式对比关键数字：CoT 1-5 步 / ReAct 5-20 步 / Plan-and-Execute 10-50+ 步，成本依次从"1 次 LLM 调用"涨到"10-50+ 次"。代表产品：ChatGPT o1/o3 思考 / LangChain Agent / Claude Code & Kimi K2 探索。
- 三种 Planning 形态对应的产品哲学：全自动（Devin，AI 全权代理）/ 半自动（Kimi K2 探索，展示计划面板允许修改）/ 人驱动（Cursor，开发者列步骤 AI 按步执行）——本质上是"信任度 × 控制欲"两轴上的不同站位。
- Planning 翻车两种典型：(1) 过度拆解——AutoGPT 把"买一杯咖啡"拆 30 步，第 15 步因网站超时卡死循环，Token 暴涨 10 倍；(2) 计划僵死——Claude Code 改了 10 个文件后忘了最初要修哪个 bug，解决方案是在对话中定期回顾原始目标。Agent 即使发现 API 失效仍死板执行后续步骤的"假装成功"，是 Plan-and-Execute 范式最隐蔽的坑。
- Multi-Agent 核心论点："与其让一个 Agent 做所有事，不如让多个 Agent 各自擅长一件事，然后协作完成"。Lead Researcher（PM 型 Agent）负责拆解和编排，Subagent 各自独立 Context 专注子任务，最后回到 Lead Researcher 整合输出。Claude Research 用的就是这个架构。
- Agent 模式选择决策树：单步就能完成 → 直接 LLM 调用 / 多步但路径固定 → Workflow / 多步且路径不固定 → Agent，且 Agent 还要再细判：要调外部工具？+Tool Use / 任务超 3 步？+Planning / 质量要求高+标准明确？+Reflection / Context 不够 or 有明确分工？+Multi-Agent。
- Function Calling 是 Agent 从"只能说话"变"能动手做事"的关键转折点：2023.6 OpenAI 首发 FC API，成功率从 ~60% 提升到 2025 年的 95%+，从实验性功能变成可靠的生产级能力。
- Plugin vs FC 的代际差：Plugin 是用户手动装、每次对话只能用 1-3 个、门槛高；FC 是 LLM 自己判断、理论上可以同时用几十个工具、用户无感知。这就是"用户不需要知道有什么工具可以用，模型自己知道"的范式跃迁。
- MCP 的本质比喻：Agent 的 USB-C——只要工具方按 MCP 标准暴露接口，任何 Agent 都能直接接入，不需要写适配代码。这把工具开发者和 Agent 开发者解耦，是生态层的标准化。
- FC 与 MCP 不是替代关系：FC 解决"模型层"问题（LLM 能输出结构化调用请求），MCP 解决"协议层"问题（统一工具调用的通信格式）。FC 在上，MCP 在下，二者配合才完整。
- Code Execution with MCP 是当前最前沿的优化：传统方式 30 个 Tool 定义占 4500-6000 Token，新范式只放一个
execute_code工具占 200 Token，LLM 写 Python 代码按需导入 MCP Server——Token 节省 95%+，且工具数量不再受 Context 限制。Claude Code 内部用的就是这个范式。
相关页面
→ Agent五要素技术定义 → Agent记忆体系 → Agent规划与反思 → Agent工具与行动 → Agent vs Workflow → Multi-Agent协作 → Function Calling与MCP → AIPM课程 Day9（前一日 Agent 架构总览） → 模型选型方法论（route_model 是 Planning 范式落地） → RAG（MCP 是工具调用层，与 RAG 的"外挂知识"是平行机制）