Agent = LLM + Memory + Planning + Tools + Action
这是工程化的 Agent 定义——不是哲学上的"自主智能体",而是五个具体可设计、可拆解、可写进 PRD 的技术要素。每一个要素对应一类 PM 决策。
五要素总览
| 要素 | 类比 | 核心 PM 决策 |
|---|---|---|
| LLM(大脑) | 决策中枢 | 选什么模型?模型能力够不够?成本怎么样? |
| Memory(笔记本) | 记忆系统 | 它该记什么、忘什么?记忆放在哪里? |
| Planning(项目计划) | 任务拆解 | 任务怎么拆?要不要让用户看到拆解步骤? |
| Tools(工具箱) | 外部能力 | 给它什么工具?工具描述怎么写? |
| Action(双手) | 真正执行 | 什么动作需要用户确认?什么可以自动执行? |
详细展开见各专题页:Agent记忆体系 / Agent规划与反思 / Agent工具与行动
1. LLM — Agent 的大脑
LLM 是 Agent 的"决策中枢",负责:
- 理解任务:你给它的指令
- 生成思考:决定下一步做什么
- 选择工具:什么时候用哪个工具
- 整合信息:把零散的工具返回结果拼成回答
模型评测三维度
| 维度 | 怎么测 | 典型差距 |
|---|---|---|
| 指令跟随 | 给一个复杂指令,看能否严格遵守 | GPT-3.5 经常漏掉一两家/数据错位 → Claude Opus 4.7 完整有交叉验证;调研任务准确率 ~60% → ~95% |
| 工具调用稳定性 | 让它调用 5 个以上工具,看会不会乱选/漏选 | 改完经常引入新 bug → 改完会主动跑测试;编程任务一次成功率 ~30% → ~80% |
| 推理深度 | 给一个需要 2-3 步推理的问题 | 走两步就卡住 → 能完整跑完;操作任务完成率 ~10% → ~70% |
2. Memory — Agent 的笔记本
人脑的记忆分很多种:你记得早餐吃了什么(短期)、记得三年前同事姓什么(长期)、记得怎么骑自行车(程序性)——Agent 也一样。
四类记忆详见 Agent记忆体系:
- Working Memory(工作记忆)→ Context Window
- Episodic Memory(情景记忆)→ 数据库
- Semantic Memory(语义记忆)→ RAG 知识库
- Procedural Memory(程序记忆)→ Skill/Workflows(如 CLAUDE.md)
3. Planning — Agent 的项目计划
Planning 是 Agent 的"任务拆解和路径规划"能力。
三步骤:
- 拆解:把大目标拆成小步骤
- 排序:决定先做哪步、后做哪步
- 调整:执行过程中根据反馈修改计划
PM 在 Planning 上必须做的两个核心决策:
- 计划是否需要给用户看? 给看 = 用户有信任感、能干预(推荐);不给看 = 体验更"无感"但翻车时用户没法救
- 用户能不能修改计划? 能改 = 协作型产品(Cursor);不能改 = 委派型产品(Devin)
三大范式(CoT/ReAct/Plan-and-Execute)+ 全/半/人驱动 Planning 对比,详见 Agent规划与反思。
4. Tools — Agent 的工具箱
Tools 是 Agent 能调用的外部能力——搜索、计算、读写文件、调 API、操作浏览器、执行代码。
LLM 本身只能"生成文本",要做这些事必须"装上工具"——这个机制叫 Function Calling,2023.6 OpenAI 首发,现已是所有主流大模型(GPT-4o / Claude / Gemini)的标配能力。
工具设计、常见错误(1 tool 1 目标、Description 是说明书、10-15 个甜蜜点)、5 类 Agent 工具清单详见 Agent工具与行动。
底层调用范式(FC / MCP)详见 Function Calling与MCP。
5. Action — Agent 的双手
Action 是 Agent 真正执行动作的那一刻——Tools 是"可以做什么"的能力清单,Action 是"实际做了什么"的具体动作。
PM 在 Action 上要做的关键决策:
- 什么 Action 需要用户确认?
- 什么可以自动执行?
- Action 失败了怎么办?
- 怎么恢复?
风险分级(低/中/高)+ PRD 标注规范详见 Agent工具与行动。
Manus 案例:一个真实 Agent 的五要素拆解
以"调研 AI 产品经理薪资"为例:
| 时间点 | Agent 在做什么 | 用到了哪层技术 |
|---|---|---|
| T+0s | 任务拆解为有序步骤列表:1. 搜索招聘网站 2. 提取薪资数据 3. 交叉验证 4. 整理成报告 | Planning |
| T+8s | 生成一段 Python 代码(CodeAct 范式),代码里调用搜索工具执行查询。沙箱运行这段代码,返回搜索结果;从搜索结果中选取相关链接,用 Playwright(headless 浏览器)打开网页、滚动页面、提取正文 | Tools + Action |
| T+30s | 把网页中提取的薪资数据写入沙箱中的文件(如 notes_salary.md)。Manus 的设计哲学是把文件系统当作外挂记忆——重要信息存文件而非塞进上下文 | Memory |
| T+5min | 用不同关键词反复搜索("AI PM 薪资"、"产品经理待遇 2026"、"AI PM salary China"),每搜一次就打开网页、提取数据、写入文件。Manus 的 System Prompt 要求必须从多来源交叉验证,不能只信一个网站 | Action 循环 |
Manus 的 Working Memory 设计(教科书级)
Manus 把 Working Memory 切成"上半区 System Prompt(固定规则)+ 下半区 Event Stream(追加事件)"两区——完整的 System Prompt 文本、<tool_use_rules> 与 Event Stream 结构详见 Agent记忆体系,本页不重复展开。
OODA — Agent 工作的核心循环
五要素不是静态摆设,它们在 OODA 循环 里协同工作:
| 阶段 | 在做什么 | 用到的要素 |
|---|---|---|
| Observe(观察) | 看当前状态、读工具返回结果 | Memory + Tools |
| Orient(定向) | 理解当前在哪、距离目标多远 | LLM |
| Decide(决策) | 决定下一步做什么 | LLM + Planning |
| Act(行动) | 调用工具执行 | Tools + Action |
每一轮 Action 之后回到 Observe,循环往复,直到任务完成。
OODA 是 1950 年代美军决策框架(John Boyd 提出),被搬到 Agent 上完美契合——ReAct 范式本质上就是 OODA 的简化版(Reason→Act→Observe→Reason)。
五要素 vs 五能力(Day9 vs Day10 视角)
Day9 用"架构视角"讲五要素(LLM+Memory+Planning+Tools+Action);Day10 用"能力视角"重新组织成 5 大核心能力(Reflection / Tool Use / Planning / Memory / Multi-Agent)。
两个视角的映射:
| Day9 架构要素 | Day10 能力视角 |
|---|---|
| LLM | (底层,所有能力的基础) |
| Memory | Memory |
| Planning | Planning(含 Reflection 作为子能力) |
| Tools | Tool Use |
| Action | (融在 Tool Use 执行环节) |
| —— | Multi-Agent(跨单 Agent 的协作层,独立维度) |
实际工作中两个视角都用:架构视角决定"系统怎么搭",能力视角决定"PRD 怎么写"。
相关页面
→ Agent记忆体系 → Agent规划与反思 → Agent工具与行动 → Agent vs Workflow → Multi-Agent协作 → Function Calling与MCP → AIPM课程 Day9 → AIPM课程 Day10 → OpenAI人工智能五阶段(Agent 在 AI 发展阶段中的定位) → 模型选型方法论(LLM 选择是五要素的第一步)