夜雨聆风多数 AI 产品经理在推动 Agent 落地时，卡点不是技术选型，而是连 Agent 到底在干什么都还没搞清楚。PRD 写了一堆，研发团队跑起来系统之后发现不稳定、不可控，第 6 周开始出现不可逆的返工。
问题不出在框架选型，也不出在模型能力，而是 10 个底层概念没有对齐。凡是让研发先动手的，最后都绕回来重新讲概念。
老王复盘过多个 Agent 落地项目，得出的结论一致：概念对齐先于一切。这 10 个概念，先搞懂再动手。
👁️ 感知，Agent 能接收什么
你可以把感知理解成 Agent 的眼睛和耳朵，它能接收到什么信息，就只能在那个范围里做决策。超出感知范围的信息，对 Agent 来说根本不存在。
产品经理设计 Agent 时，最常犯的错是默认用户只会输入文字。但真实场景远不止于此。用户会上传表单数据、图片截图、结构化 JSON，工具执行后也会返回结果，这些都是 Agent 要处理的输入。
哪个通道没设计好，那个通道的信息就会被丢掉。信息一旦丢掉，后面的决策质量就已经上限了，再好的模型也补不回来。
老王在评估 Agent 感知层时，第一件事是列清楚所有输入来源和数据类型，确认每种类型有没有对应的处理机制：
文字 → 语义理解
结构化数据 → 参数解析
图片 → 视觉模型
工具返回值 → 结果解析
每个通道单独确认，不能笼统假设全部支持。
❗ 老王核心思考
感知层的完整性决定了信息边界，信息边界决定了整个 Agent 系统决策质量的上限。
🧠 Memory，Agent 怎么记住事情
Agent 没有天生的记忆能力，它的记忆是通过三套独立机制拼出来的，分别对应不同时间维度。
短期记忆存在对话历史里，也就是当前会话从头到现在的所有消息。这个空间是有上限的，一旦对话内容超过这个长度，最早的内容就会被截断。Agent 截断前说过的事，就真的不再知道了。多轮对话场景里，用户反映 Agent 忘记了之前说的需求，大多数原因都在这里。
长期记忆存在向量数据库里。把历史信息转成向量，需要时根据当前问题去检索最相关的内容拿出来用。检索准不准，直接决定 Agent 拿到的背景知识质量够不够。老王的前面文章也讲过类似的思路。
工作记忆是当前这个任务的中间状态，比如任务编号是什么、已经完成了哪几步、下一步要做什么、上一个工具返回了什么结果。这些临时信息要有专门的容器去存，否则 Agent 在多步任务里就会出现重复操作或者跳过关键步骤。
💡 梳理建议
三套机制各自独立，混在一起设计必然乱。产品经理在做 Agent 需求时，要先明确每类信息该走哪套记忆机制，测试时也要分别验证。
📋 Planning，把模糊意图变成可执行步骤
用户说的是意图，但 Agent 要执行的是具体动作。中间那段从模糊到具体的转化，就是 Planning 在做的事。
很多人以为模型足够聪明，Planning 就自然搞定了。这个判断存在一个关键漏洞，Planning 的质量高度取决于 Prompt 设计，而不是模型本身的聪明程度。同一个模型，换一套任务分解策略，执行质量可以相差 40% 以上。
目前主流的 Planning 框架叫 ReAct，逻辑是思考-行动-观察的循环。Agent 先做推理，决定下一步要做什么动作，执行之后观察结果，再进入下一轮推理。每个中间步骤都可以看到，便于排查问题。
⚠️ 踩坑了
Planning 设计时最容易出问题的地方是子任务的拆分粒度。拆太粗，每步任务超出工具能力，执行失败；拆太细，步骤太多，累积误差上升。一个可操作的判断标准：每个子任务的输出结果必须是明确可验证的，不能用"处理完成"这种没法判断的结论收尾。
🔍 Reasoning，每一步动作前的判断过程
Planning 决定做什么任务，Reasoning 决定在具体这一步该怎么做。
两者的区别在于粒度：
- Planning
→ 任务级别的规划
- Reasoning
→ 步骤级别的判断，包括条件判断、因果分析、约束核查
在 ReAct 框架里，每一轮推理步骤就是 Reasoning 的体现。Agent 在执行下一个动作之前，先基于当前状态和已有信息，判断应不应该执行、执行什么、用什么参数。这个判断出错，Agent 就会调用不该调用的工具，或者参数填错，导致工具执行失败。
Reasoning 质量差，通常不是模型能力问题，而是输入信息不完整。 Agent 拿不到足够的上下文，只能基于残缺信息做推断，结论自然偏差。这意味着产品经理在评估 Agent 行为异常时，要先检查那一步 Agent 拿到的上下文是否完整，而不是先怀疑模型。
Chain of Thought 是提升 Reasoning 可靠性的一种常见策略，核心机制是要求模型输出推理过程，而不只是结论。有了推理过程，就能定位出错在哪一步，问题才能定向修复。
🎯 Goal，Agent 凭什么知道什么时候该停
没有明确的目标，Agent 就不知道往哪个方向走，也不知道什么时候算完成了。这是最直接的失控来源。
目标在工程上分两个层次：
- 终态目标
—— 描述最终要达成的状态，比如用户的问题已经得到准确回答，或者文件已经成功写入指定位置
- 过程目标
—— 描述每个子步骤的局部完成状态，比如当前轮次的信息已检索完毕、工具调用结果已记录
目标设计不清晰会导致两类问题：
- 提前停止
—— Agent 误判任务已完成，但实际上用户的需求没有被满足 - 过度执行
—— Agent 没有明确的终止条件，持续调用工具直到 Token 耗尽或触发系统限制，每次调用都在产生费用
❗ 产品设计思路
产品经理设计需求时，要在 System Prompt 里明确描述终态条件，同时设计一个显式的任务完成验证机制，Agent 在输出最终结果之前先过一遍终态条件清单。这个机制不需要复杂，但必须存在。
目标体系设计是 Agent 可控性最核心的杠杆，比框架选型、比模型选择都重要得多。
🛠️ Tool Use，Agent 能做的事为什么不止聊天
LLM 本身只能生成文字。真正让 Agent 变得有用的原因，是它能调用外部工具。搜索网页、执行代码、查询数据库、发送请求、操作文件，这些能力全部来自工具调用，而不是模型自身。
工具调用分四步：
模型根据当前状态判断需要调用哪个工具、传什么参数 Host 系统实际执行调用，等待工具返回结果 工具返回结果作为观测值传给 Agent Agent 基于这个结果继续推理，决定下一步动作
⚠️ 都是细节
工具的定义质量对调用效果影响很大。每个工具的名称、描述、参数说明，模型都会读取并依此决定如何调用。描述不清楚，模型选错参数，工具执行失败，整个链路就断了。和研发确认工具定义的清晰度，是产品经理在 Agent 需求阶段最容易忽视的事。
你需要在 System Prompt 里面把调用的工具以及它的参数约束好，以及返回的 JSON 格式。
工具数量也有上限。实测中，当 Agent 同时可以调用的工具超过 20 个时，选择准确率开始明显下降，因为模型在工具选择阶段的判断负担加重。工具集应该按任务场景严格筛选，不能无差别地全部暴露给 Agent。
🚧 Action Space，给 Agent 划定行动边界
Agent 被允许做的所有动作的集合，就是动作空间。这个边界不是靠 Agent 自己判断的，而是在系统层面硬性限定的。
这个概念对产品经理来说非常重要。Agent 能不能修改数据库，能不能写文件，能不能发外部请求，这些不是 Prompt 能控制的，是系统设计层面必须明确划定的权限边界。
🔴 安全红线
动作空间设计过宽是 Agent 安全问题最常见的来源。内容生成类的 Agent 如果被给予了文件系统写入权限，在 Prompt 设计不当的情况下，可能覆写不该动的配置文件甚至核心数据。这类损失不是因为模型判断错了，而是因为系统从一开始就没有划定边界。
区分只读工具和读写工具是动作空间设计的基础：
- 只读工具
—— 风险极低，可以让 Agent 自主使用
- 读写工具
—— 涉及状态修改，必须配合人工确认或审核机制，不能让 Agent 单独决策
高风险业务场景里，动作空间还应该随任务阶段动态收窄，任务启动阶段和执行中期可以用的工具集不一样，按阶段逐步放开权限，而不是一次性全部开放。
👀 Observation，执行之后 Agent 怎么知道发生了什么
Agent 执行完一个动作之后，环境会给它一个反馈，这个反馈就叫 Observation。它是 Agent 进入下一轮推理的唯一信息来源。
Think-Act-Observe 是 Agent 运作的基础循环，三个环节缺一不可。Observation 的质量直接决定下一轮推理能不能正常推进。
Observation 有两类常见的工程问题：
- 信息过载
—— 工具返回了大量原始数据，内容太多，Agent 反而抓不到真正有用的信号，做出的判断反而不如拿到更少但更精准数据时的效果 - 信息缺失
—— 工具出错时只返回了空值或通用错误码，Agent 从中无法推导出任何有意义的后续动作，整个链路就此卡住
💡 设计思路
设计 Observation 的基本原则是最小充分：返回的信息足够支撑下一步决策，但不引入无关噪声。如果工具返回的原始结果很长，应该在工具层先做一次提炼，而不是把原始内容直接扔给 Agent 处理。
多步任务里，历史 Observation 也会占用上下文窗口。随着步骤增多，早期 Observation 会被截断。工作记忆管理的一个核心要求，就是只保留对当前决策仍然有效的 Observation，不再有效的及时清理。
🔄 Reflection，Agent 能不能发现自己做错了
Reflection 是 Agent 对自身执行结果进行评估和修正的能力。Agent 执行完一段任务序列，主动判断结果是否符合预期，识别偏差并调整后续策略。
没有 Reflection 的 Agent，遇到偏差只会继续错下去，因为它没有机制发现自己在偏航。有了 Reflection，Agent 才能在中间环节检测到偏差并主动纠偏。
Reflection 的实现分两类：
- 内联 Reflection
—— 在任务执行过程中嵌入周期性自检节点，每隔若干步骤暂停一次，评估当前进度是否偏离目标。响应快，但每次自检都消耗额外 Token
- 后置 Reflection
—— 任务完成后整体复盘，评估结果、归因偏差、产出改进建议，适合长期运行的 Agent 系统用来积累经验
⚠️ 概念辨析
Reflection 和重试是两件事，不能混用。 重试是失败后重复执行相同动作，Reflection 是在评估失败原因之后调整策略再执行。区别在于有没有对失败原因进行分析。重试不分析原因，只是机械重复，第二次大概率还会失败。
加入 Reflection 机制的 Agent 系统，在复杂多步任务上的成功率平均提升 25-35%，但任务总耗时也会相应增加 15-20%。产品经理决策是否引入 Reflection 时，需要评估这个成本收益比是否适合当前场景。
🤝 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。引入多智能体架构意味着系统复杂度显著上升，调试难度成倍增加，不是越多越好。
最后
10 个概念相互依赖，哪一条没对齐，最终都会用不同的症状显现出来——产品功能异常、成本超预期、系统不稳定——根因几乎全部指向同一个问题：概念没有在产品团队和研发团队之间真正对齐过。
Agent 系统的可控性不是调出来的，是设计进去的。 概念对齐是设计的前提，这一步跳过了，后面的每一步都在还债。
