AI产品经理必懂的10个Agent相关的概念

写在最前​

01​

PART​

感知，Agent 能接收什么​

你可以把感知理解成 Agent 的眼睛和耳朵，它能接收到什么信息，就只能在那个范围里做决策。超出感知范围的信息，对 Agent 来说根本不存在。​

产品经理设计 Agent 时，最常犯的错是默认用户只会输入文字。但真实场景远不止于此。用户会上传表单数据、图片截图、结构化 JSON，工具执行后也会返回结果，这些都是 Agent 要处理的输入。​

哪个通道没设计好，那个通道的信息就会被丢掉。信息一旦丢掉，后面的决策质量就已经上限了，再好的模型也补不回来。​

​

💪

我在评估 Agent 感知层时，第一件事是列清楚所有输入来源和数据类型，确认每种类型有没有对应的处理机制：​

•

文字 → 语义理解​

•

结构化数据 → 参数解析​

•

图片 → 视觉模型​

•

工具返回值 → 结果解析​

​

​

感知层的完整性决定了信息边界，信息边界决定了整个 Agent 系统决策质量的上限。​

​

​

​

​

​

​

02​

PART​

Memory，Agent 怎么记住事情​

Agent 没有天生的记忆能力，它的记忆是通过三套独立机制拼出来的，分别对应不同时间维度。​

​

💪

短期记忆存在对话历史里，也就是当前会话从头到现在的所有消息。这个空间是有上限的，一旦对话内容超过这个长度，最早的内容就会被截断。Agent 截断前说过的事，就真的不再知道了。多轮对话场景里，用户反映 Agent 忘记了之前说的需求，大多数原因都在这里。​

​

​

💪

长期记忆存在向量数据库里。把历史信息转成向量，需要时根据当前问题去检索最相关的内容拿出来用。检索准不准，直接决定 Agent 拿到的背景知识质量够不够。老王的前面文章也讲过类似的思路。​

​

​

💪

工作记忆是当前这个任务的中间状态，比如任务编号是什么、已经完成了哪几步、下一步要做什么、上一个工具返回了什么结果。这些临时信息要有专门的容器去存，否则 Agent 在多步任务里就会出现重复操作或者跳过关键步骤。​

​

​

💡 梳理建议​

三套机制各自独立，混在一起设计必然乱。产品经理在做 Agent 需求时，要先明确每类信息该走哪套记忆机制，测试时也要分别验证。​

​

​

​

​

​

​

03​

PART​

Planning，把模糊意图变成可执行步骤​

用户说的是意图，但 Agent 要执行的是具体动作。中间那段从模糊到具体的转化，就是 Planning 在做的事。​

​

​

​

💪

很多人以为模型足够聪明，Planning 就自然搞定了。这个判断存在一个关键漏洞，Planning 的质量高度取决于 Prompt 设计，而不是模型本身的聪明程度。同一个模型，换一套任务分解策略，执行质量可以相差 40% 以上。​

​

目前主流的 Planning 框架叫 ReAct，逻辑是思考-行动-观察的循环。Agent 先做推理，决定下一步要做什么动作，执行之后观察结果，再进入下一轮推理。每个中间步骤都可以看到，便于排查问题。​

​

​

​

⚠️ 注意别踩坑了​

Planning 设计时最容易出问题的地方是子任务的拆分粒度。拆太粗，每步任务超出工具能力，执行失败；拆太细，步骤太多，累积误差上升。一个可操作的判断标准：每个子任务的输出结果必须是明确可验证的，不能用"处理完成"这种没法判断的结论收尾。​

​

​

​

​

​

​

04​

PART​

Reasoning，每一步动作前的判断过程​

Planning 决定做什么任务，Reasoning 决定在具体这一步该怎么做。​

​

两者的区别在于粒度：​

​

​

💪

在 ReAct 框架里，每一轮推理步骤就是 Reasoning 的体现。Agent 在执行下一个动作之前，先基于当前状态和已有信息，判断应不应该执行、执行什么、用什么参数。这个判断出错，Agent 就会调用不该调用的工具，或者参数填错，导致工具执行失败。​

​

Reasoning 质量差，通常不是模型能力问题，而是输入信息不完整。 Agent 拿不到足够的上下文，只能基于残缺信息做推断，结论自然偏差。这意味着产品经理在评估 Agent 行为异常时，要先检查那一步 Agent 拿到的上下文是否完整，而不是先怀疑模型。​

​

​

​

Chain of Thought 是提升 Reasoning 可靠性的一种常见策略，核心机制是要求模型输出推理过程，而不只是结论。有了推理过程，就能定位出错在哪一步，问题才能定向修复。​

​

​

​

​

​

​

05​

PART​

Goal，Agent 凭什么知道什么时候该停​

没有明确的目标，Agent 就不知道往哪个方向走，也不知道什么时候算完成了。这是最直接的失控来源。​

目标在工程上分两个层次：​

​

•

终态目标—— 描述最终要达成的状态，比如用户的问题已经得到准确回答，或者文件已经成功写入指定位置​

•

过程目标—— 描述每个子步骤的局部完成状态，比如当前轮次的信息已检索完毕、工具调用结果已记录​

​

目标设计不清晰会导致两类问题：​

​

提前停止—— Agent 误判任务已完成，但实际上用户的需求没有被满足​

过度执行—— Agent 没有明确的终止条件，持续调用工具直到 Token 耗尽或触发系统限制，每次调用都在产生费用​

​

​

💪

❗ 产品设计思路​

产品经理设计需求时，要在 System Prompt 里明确描述终态条件，同时设计一个显式的任务完成验证机制，Agent 在输出最终结果之前先过一遍终态条件清单。这个机制不需要复杂，但必须存在。​

​

​

​

​

目标体系设计是 Agent 可控性最核心的杠杆，比框架选型、比模型选择都重要得多。​

​

​

​

​

​

​

06​

PART​

Tool Use，Agent 能做的事为什么不止聊天​

LLM 本身只能生成文字。真正让 Agent 变得有用的原因，是它能调用外部工具。搜索网页、执行代码、查询数据库、发送请求、操作文件，这些能力全部来自工具调用，而不是模型自身。​

​

工具调用分四步：​

模型根据当前状态判断需要调用哪个工具、传什么参数​

Host 系统实际执行调用，等待工具返回结果​

工具返回结果作为观测值传给 Agent​

Agent 基于这个结果继续推理，决定下一步动作​

​

​

💪

⚠️ 都是细节​

工具的定义质量对调用效果影响很大。每个工具的名称、描述、参数说明，模型都会读取并依此决定如何调用。描述不清楚，模型选错参数，工具执行失败，整个链路就断了。和研发确认工具定义的清晰度，是产品经理在 Agent 需求阶段最容易忽视的事。​

​

你需要在 System Prompt 里面把调用的工具以及它的参数约束好，以及返回的 JSON 格式。​

工具数量也有上限。实测中，当 Agent 同时可以调用的工具超过 20 个时，选择准确率开始明显下降，因为模型在工具选择阶段的判断负担加重。工具集应该按任务场景严格筛选，不能无差别地全部暴露给 Agent。​

​

​

​

​

​

07​

PART​

Action Space，给 Agent 划定行动边界​

Agent 被允许做的所有动作的集合，就是动作空间。这个边界不是靠 Agent 自己判断的，而是在系统层面硬性限定的。这个概念对产品经理来说非常重要。​

Agent 能不能修改数据库，能不能写文件，能不能发外部请求，这些不是 Prompt 能控制的，是系统设计层面必须明确划定的权限边界。​

​

💪

🔴 安全红线​

动作空间设计过宽是 Agent 安全问题最常见的来源。内容生成类的 Agent 如果被给予了文件系统写入权限，在 Prompt 设计不当的情况下，可能覆写不该动的配置文件甚至核心数据。这类损失不是因为模型判断错了，而是因为系统从一开始就没有划定边界。​

​

​

区分只读工具和读写工具是动作空间设计的基础：​

​

高风险业务场景里，动作空间还应该随任务阶段动态收窄，任务启动阶段和执行中期可以用的工具集不一样，按阶段逐步放开权限，而不是一次性全部开放。​

​

​

​

​

​

08​

PART​

Observation，执行之后 Agent 怎么知道发生了什么​

Agent 执行完一个动作之后，环境会给它一个反馈，这个反馈就叫 Observation。它是 Agent 进入下一轮推理的唯一信息来源。​

​

💪

Think-Act-Observe 是 Agent 运作的基础循环，三个环节缺一不可。Observation 的质量直接决定下一轮推理能不能正常推进。​

​

​

Observation 有两类常见的工程问题：​

信息过载—— 工具返回了大量原始数据，内容太多，Agent 反而抓不到真正有用的信号，做出的判断反而不如拿到更少但更精准数据时的效果​

​

​

💪

💡 设计思路​

设计 Observation 的基本原则是最小充分：返回的信息足够支撑下一步决策，但不引入无关噪声。如果工具返回的原始结果很长，应该在工具层先做一次提炼，而不是把原始内容直接扔给 Agent 处理。​

​

多步任务里，历史 Observation 也会占用上下文窗口。随着步骤增多，早期 Observation 会被截断。工作记忆管理的一个核心要求，就是只保留对当前决策仍然有效的 Observation，不再有效的及时清理。​

​

​

​

​

​

09​

PART​

Reflection，Agent 能不能发现自己做错了​

​

💪

Reflection 是 Agent 对自身执行结果进行评估和修正的能力。Agent 执行完一段任务序列，主动判断结果是否符合预期，识别偏差并调整后续策略。没有 Reflection 的 Agent，遇到偏差只会继续错下去，因为它没有机制发现自己在偏航。有了 Reflection，Agent 才能在中间环节检测到偏差并主动纠偏。​

​

​

Reflection 的实现分两类：​

•

内联 Reflection—— 在任务执行过程中嵌入周期性自检节点，每隔若干步骤暂停一次，评估当前进度是否偏离目标。响应快，但每次自检都消耗额外 Token​

•

后置 Reflection—— 任务完成后整体复盘，评估结果、归因偏差、产出改进建议，适合长期运行的 Agent 系统用来积累经验​

​

⚠️ 概念辨析​

•

Reflection 和重试是两件事，不能混用。 重试是失败后重复执行相同动作，Reflection 是在评估失败原因之后调整策略再执行。区别在于有没有对失败原因进行分析。重试不分析原因，只是机械重复，第二次大概率还会失败。​

•

加入 Reflection 机制的 Agent 系统，在复杂多步任务上的成功率平均提升 25-35%，但任务总耗时也会相应增加 15-20%。产品经理决策是否引入 Reflection 时，需要评估这个成本收益比是否适合当前场景。​

​

​

​

​

​

10​

PART​

Multi-Agent，什么时候需要多个 Agent 协作​

多个 Agent 实例协同工作来完成一个任务，这种架构叫 Multi-Agent。它解决的是单 Agent 在上下文长度、并发能力、能力边界上的天花板问题。​

​

💪

单 Agent 的核心限制是上下文窗口。当一个任务需要的信息量超过单个上下文窗口能装下的范围时，Agent 必然要丢失部分信息，决策质量因此下降。​

Multi-Agent 的出发点是把任务拆开，让不同 Agent 各自持有局部但完整的上下文，再通过协调机制汇总结果。​

​

​

Multi-Agent 有两种主流架构：​

•

分层式架构—— 一个协调 Agent 负责任务分解和结果汇总，若干执行 Agent 各自负责具体子任务。协调 Agent 不直接操作工具，只处理协调逻辑。边界清晰，适合大多数业务场景​

•

平行式架构—— 多个对等 Agent 各自独立处理同一个任务，最后通过投票或结果融合确定最终输出，适合需要多视角验证的高精度场景，比如代码评审、风险评估​

​

🔴 引入决策标准​

Multi-Agent 带来的新问题是协调成本。多个 Agent 并发运行时，如何避免重复操作、如何处理冲突结果、如何追踪整体状态，这些问题的复杂度不低于单 Agent 本身的设计。​

只有一个判断标准：任务的复杂度或规模明确超出单 Agent 能力边界时才引入。 单 Agent 能完成的，不用 Multi-Agent。引入多智能体架构意味着系统复杂度显著上升，调试难度成倍增加，不是越多越好。​

​

​

​

​

​

11​

PART​

最后​

10 个概念相互依赖，哪一条没对齐，最终都会用不同的症状显现出来——产品功能异常、成本超预期、系统不稳定——根因几乎全部指向同一个问题：概念没有在产品团队和研发团队之间真正对齐过。​

Agent 系统的可控性不是调出来的，是设计进去的。 概念对齐是设计的前提，这一步跳过了，后面的每一步都在还债。​