拆解 AI Agent：大模型、规划、记忆、工具——PM 到底该管什么

最近两年「Agent」这个词被用得有点泛：接了个工具叫 Agent，套了个工作流也叫 Agent，好像不挂这个词就不够先进。

但剥开概念包装，Agent 的结构其实非常清晰。这篇文章是我对这个结构的一次梳理——它来自我读过的资料、看过的产品，以及和朋友讨论时的碰撞。我尽量只讲清楚两件事：每一块积木是什么，以及 PM 的设计动作落在哪。

一个公式：Agent = 大模型 + 规划 + 记忆 + 工具

一个只会对话的大模型，本质上是一个「聊天框」：你问它答，答完就忘，什么也改变不了。

Agent 和聊天框的区别，在于它在大模型这颗「大脑」之外，长出了三样东西：

• 规划（Planning）：把「帮我搞定这件事」拆成一步步可执行的动作；
• 记忆（Memory）：记住上下文、历史和你说过的话；
• 工具（Tools）：搜索、读写文件、调 API——真正动手去改变世界。

fig. 没有四件套，是聊天框；加上四件套，才是能替你办事的 Agent

这个公式里最反直觉的一点是：大模型只是四分之一。 剩下四分之三都是工程和设计问题——而工程和设计的交界处，恰恰是 PM 该站的位置。

下面逐块拆。

规划：PM 要定义 Agent 的「思考策略」

规划模块回答的问题是：拿到一个任务，先做什么、后做什么？

主流的两种模式，用一句话就能区分开：

• ReAct（边做边想）：思考 → 行动 → 观察 → 再思考，循环直到任务完成。每一步都根据上一步的结果决定下一步，适合不确定的任务。比如客服 Agent 排查「用户为什么登录失败」：查日志 → 发现报错 → 查数据库 → 定位原因，事先根本排不出固定流程。
• Plan-Act（先排再跑）：先列出所有步骤，然后一口气线性执行。适合流程明确的任务，比如自动周报 Agent：拉数据 → 套模板 → 生成 → 发出，流程固定，排好再跑反而更稳、更快。

fig. 走哪条路，由任务的不确定性决定

PM 在这里的决策：你的 Agent 面向的任务长什么样？不确定性高就允许它边走边看（同时接受更慢、更贵）；流程明确就收敛成固定计划（同时接受灵活性下降）。这个选择直接决定用户体验的基调——是「等等，它在思考」，还是「秒出结果」。

记忆：PM 要定义「什么该记住，什么该忘」

记忆不是一个东西，而是三层，越往外越持久：

1. 工作记忆：当前这轮对话。「你刚说的我都记得」——这是上下文窗口在兜底，成本最低，也最容易被忽略。
2. 短期记忆：本次会话内做过的操作。「今天帮你处理了哪些事」——会话结束就清空。
3. 长期记忆：跨会话持久化，用户偏好、项目结构、历史经验，通常落在向量库里。

fig. 越外层的记忆越持久，也越需要管理

PM 在这里的决策：什么该记、什么该忘？存多久？谁来删？

这不是技术问题，是产品问题。电商 Agent 该记住你的历史订单和尺码偏好，但不必记住你每次的浏览——那是噪声；新闻 Agent 该记住你常看的类别，但三天前的旧闻不该再推——那是过时信息。记忆策略做错了，Agent 要么显得「没记性」，要么显得「记仇」，两者都毁体验。

工具：PM 要定义边界、失败规则和安全锁

工具是 Agent 真正「动手」的部分。没有工具，Agent 只能说；有了工具，Agent 才能做。

以「帮我订张机票」为例，一次工具调用的完整链路是：

fig. 从「帮我订机票」到真的出票

PM 在这里的决策有三层：

• 定义工具本身：每个工具的参数、输出格式、适用场景，都要像写 PRD 一样写清楚。定义模糊的工具，模型调用起来就是抽奖。
• 定义失败规则：调用失败了怎么办——重试？换工具？还是如实告知用户「我做不到」？最坏的产品体验是 Agent 假装成功。
• 定义安全锁：删文件、发邮件、付钱这类不可逆操作，必须由用户二次确认，Agent 不能自己决定。这是红线，不是可选项。

结尾：四个 PM 必答的问题

拆完四块积木，回到开头那个问题：PM 的设计动作落在哪？我把它收敛成四个问题，任何一个 Agent 项目启动前都应该答得出来：

1. 规划：我的任务是不确定的还是流程明确的？Agent 应该边做边想，还是先排再跑？
2. 记忆：什么该记住、什么该忘掉？存多久、谁来删？
3. 工具：每个工具的边界和失败规则是什么？哪些操作必须用户确认？
4. 验收：我怎么知道 Agent 做对了？——前三个问题的答案，最终都要落到可测试的验收标准上。

大模型能力的上限由模型厂商决定，但 Agent 体验的下限，由这四个问题的答案决定。而后者，恰恰是 PM 能抓住的东西。