Agent 从生成答案走向执行任务后，产品设计对象也从回答质量扩展到执行行为。本文从一次真实返工经历出发，分析 Agent 面对的四类不确定性，提出意图确认、权限边界、过程可见、失败恢复和结果验证五层控制系统，并讨论产品经理如何划定模型的决策边界。

之前做一个项目时，我先向 AI 描述了一个大概想法。那时，我并没有要求它立刻执行，只是想先把需求讲出来，再和它讨论接下来的步骤：这件事应该怎么做、先做什么、哪些地方需要重点考虑。

但 AI 没有等到这些问题讨论清楚。

它根据我提供的有限信息，自行补全了没有说清楚的部分，替我决定了执行方向，然后直接开始做。

从表面上看，它的反应很快。没有反复追问，也没有停下来等待确认，很快就给出了一套看起来相当完整的结果。

问题是，那并不是我真正想要的东西。

由于它没有充分理解我的需求，最终做出来的内容与我的设想存在明显偏差。我不得不重新解释自己的想法，再和它一轮轮调整。原本希望 AI 帮我节省时间，最后却把一部分时间花在了纠正它过早做出的决定上。

这不只是时间成本，还包括 Token 成本。

第一次生成的内容没有被真正使用，但理解、生成和修改都已经消耗了资源。接下来为了纠正方向，我还要重新描述需求、补充背景、解释哪里不对，再让它修改。AI 看起来完成了一次任务，实际上只是提前制造了一次返工。

这个经历并不算严重。它没有删除重要文件，也没有造成不可挽回的损失。但正因为它如此普通，反而更能说明 Agent 产品中一个容易被忽略的问题：

有时，AI 会执行，却不会判断自己何时不该执行。

过去使用聊天机器人时，需求没有说清楚，最常见的结果只是得到一个不够准确的回答。发现不对，重新提问就可以了。

当 AI 获得读取文件、修改内容、执行命令和调用外部工具的能力以后，理解偏差就不再只停留在对话框里，而会进入真实的执行过程。

它可能选错方案、修改错误对象、遗漏关键限制，也可能在第一个判断已经偏离的情况下，继续完成后面的所有步骤。每一步看起来都在推进任务，整个任务却可能沿着错误方向越走越远。

所以，当 AI 从“给出答案”走向“替用户完成任务”时，我们真正需要讨论的已经不只是它能不能做，而是另一个更接近产品本质的问题：

当任务中仍然存在大量不确定性时，我们凭什么放心地让它继续做下去？

一、Agent 的产品边界：从生成答案到改变状态

“Agent”可能是过去一段时间里，被使用得最泛滥的 AI 概念之一。

只要一个产品可以调用工具、拆分任务，或者连续执行几个步骤，就很容易被包装成 Agent。于是，不同产品都在强调自己接入了多少工具、可以完成多长的任务，以及能够替用户操作多少软件。

如果只从功能数量理解 Agent，很容易忽略它真正带来的变化。

Agent 与普通聊天机器人的区别，并不只是多了几个工具，而是 AI 开始获得了影响外部环境的能力。

使用聊天机器人时，用户提出问题，AI 生成回答。即使回答不准确，大部分错误仍然停留在对话框里。用户可以判断是否采用，也可以直接放弃。

这是一种相对清晰的责任关系：AI 提供内容，用户决定是否行动。

Agent 改变了这种关系。

它不再只告诉用户应该怎样做，而是开始替用户完成其中一部分工作。它可以搜索资料、读取文件、修改代码、整理数据、操作浏览器，甚至在不同工具之间传递信息。

在这个过程中，AI 输出的不再只是一段文字，而是一个个真实动作。

Anthropic 在《Building effective agents》中，将工作流与 Agent 做了区分：工作流中的模型和工具按照预先设定的路径运行；Agent 则会根据任务和环境，动态决定下一步应该做什么。[1]

这个区别看起来只是技术架构不同，实际上对应着两种产品逻辑。

在固定工作流里，产品团队提前确定了大部分执行路径。模型可以处理某些不确定内容，但它能走到哪里、调用哪些工具、什么时候结束，通常仍然受到明确规则约束。

而在 Agent 中，产品团队把一部分决策权交给了模型。

用户只告诉它目标，它需要自己拆分任务、选择工具、执行操作、观察反馈，再决定下一步行动。Anthropic 将这个过程描述为一种持续循环：规划、行动、观察结果、调整，然后继续执行，直到任务完成，或者遇到必须向用户确认的问题。[2]

Agent 的价值确实来自自主性。如果每一步都需要用户手动指定，它就只是一个更复杂的操作界面。它能够为用户节省时间，正是因为它可以在用户没有给出完整流程的情况下，自己填补一部分空白。

问题也恰恰出现在这里。

用户交给 Agent 的通常只是一个目标，而不是一份没有歧义的执行说明。自然语言中存在大量被省略的条件：用户真正重视什么、什么内容不能修改、哪一种结果可以接受、遇到异常时应该保守处理还是继续尝试。

这些信息，人和人交流时都未必能一次说清，更不可能因为换成 AI 就自动消失。

Agent 每向前执行一步，实际上都在做两件事：一件是完成任务，另一件是猜测用户没有说出来的部分。

有些猜测很轻微。例如，选择什么格式整理一份资料，即使判断错误，也可以很快调整。

有些猜测则会直接改变任务结果。例如，是否覆盖原文件、是否向外部发送内容、是否删除数据、是否使用某个账号授权，或者是否在信息不足时替用户做出业务决定。

它们不能被当作同一种产品行为。

两个 Agent 最后都完成了同一项任务，并不代表它们同样可靠。一个在执行前确认关键限制，只读取必要信息，并在高风险操作前征求用户同意；另一个虽然也交付了结果，却读取了多余文件、反复尝试错误方案，并在未经确认的情况下修改了重要内容。

如果只看最终结果，它们似乎同样成功。从用户角度看，这显然是两个完全不同的产品。

前者让人感到过程可控，后者只是恰好没有造成严重后果。

当 AI 从生成答案进入真实执行环境后，产品团队需要设计的对象也发生了变化。过去，我们更关心回答是否准确、语言是否自然、响应是否足够快。现在，还必须说明每个动作的选择依据与权限边界，设计中途出错后的恢复方式，并明确什么状态才算真正完成。

工具赋予 AI 行动能力，却不会自动告诉它行动边界。

Agent 产品真正跨越的边界，是从“生成内容”走向“改变状态”。一旦 AI 能够改变文件、数据、系统和现实流程，产品设计就不能只追求它做了多少事，还要考虑它如何做、何时做、做错以后怎么办，以及用户能否重新拿回控制权。

二、Agent 面对的四类不确定性

人们习惯把自动化理解成一种确定性的提升。

过去需要人手动完成十个步骤，现在交给系统自动完成，看起来意味着人为失误更少、过程更稳定、效率也更高。

但 Agent 并不完全符合传统自动化的逻辑。

传统自动化通常建立在明确规则上：输入满足某个条件，系统就执行对应操作。Agent 面对的却经常是另一类任务。用户不会告诉它每一步应该怎么做，而只会给出一个比较模糊的目标，例如“帮我整理一下这个项目”“看看这份方案有没有问题”“把这些资料整理好并发给团队”。

目标越接近真实工作，里面没有说清楚的内容往往越多。Agent 必须在信息并不完整的情况下，一边理解任务，一边决定下一步行动。

它没有消除不确定性，只是接过了过去由人承担的一部分判断。

1. 用户意图不确定

用户没有说出来，不代表用户没有要求。

例如，用户让 Agent“整理项目文件”，可能只希望它重新分类，也可能允许它修改文件名；可能希望保留所有历史版本，也可能只想留下最终文件。

如果 Agent 每遇到一个细节都向用户确认，自动化就会变成另一种操作负担。但如果它从不确认，就只能用自己的推断补全需求。

问得太多，用户会觉得它不够智能；问得太少，它又可能在错误理解上持续执行。

好的 Agent 需要判断哪些信息可以合理推断，哪些信息一旦判断错误，就会改变任务方向。

在我前面提到的经历中，AI 理解了大概方向，也具备执行能力。真正的问题是，它没有识别出当时的信息还不足以支持执行。它把“我已经知道用户大概想做什么”，误判成了“我已经知道应该怎么做”。

2. 执行环境不确定

即使 Agent 正确理解了目标，也不代表后面的过程一定会按照计划运行。

文件可能缺失，网页结构可能变化，接口可能报错，账号权限可能不足，工具返回的内容也可能不完整。

Agent 的特点是，它可能不会在第一次失败后停止，而是根据结果调整方案，继续尝试。这种能力使它不必因为一个小问题就把任务全部交还给用户，也要求产品提前设置尝试边界：最多重试多少次，能否换用风险更高的方法，原方案失败后可以更换到哪些路径，以及新路径需要更多数据或权限时如何再次确认。

工具调用成功与否，只能说明某一个动作是否执行，并不能说明 Agent 是否采用了正确的方法。

3. 长链路中的错误会累积

Agent 往往通过连续多步行动完成任务。后面的步骤通常依赖前面的结果。

如果最开始对用户意图的理解出现一点偏差，后续计划就可能建立在错误前提上；如果中间一次工具调用返回了不完整信息，Agent 也可能把它当成可靠事实继续使用。

一个早期的小错误可能不会立刻让任务失败，反而会被包装进后面越来越完整的结果里。

这也是 Agent 错误与普通问答错误的重要区别。问答系统说错一句话，错误通常可以被直接指出。Agent 在错误方向上完成了十个步骤，用户面对的却可能是一份结构完整、格式规范，看起来已经可以使用的成果。它越完整，用户有时越难发现最初的判断已经偏了。

Anthropic 在《Demystifying evals for AI agents》中指出，Agent 会在多轮执行中调用工具、修改环境状态，并根据中间结果继续行动，因此错误可能在过程中传播和累积。[3]

如果产品只展示一个不断转动的进度图标，最后告诉用户“任务已完成”，用户无法判断偏差发生在哪里，也不知道应该从哪一步纠正。

4. “完成”的定义不确定

Agent 最容易制造的一种错觉，是把动作完成等同于目标实现。

成功调用发送接口，不代表内容发给了正确的人；成功生成文件，不代表文件符合使用要求；成功修改代码，不代表问题已经解决，也不代表没有引入新的问题。

传统软件中的完成条件通常比较明确。用户点击提交，系统保存数据，流程就可以结束。但 Agent 面对的目标经常具有模糊性。“整理好”“分析一下”“做得更专业”“选择最合适的方案”，都不能只靠一个接口返回成功来判断。

这也是 Agent 评测开始从单次答案转向完整任务和多次运行的原因。τ-bench 不仅检查 Agent 有没有调用工具，还会检查交互结束后的数据库状态是否符合目标，并通过多次运行观察它能否稳定完成任务、遵守业务规则。[4]

一个 Agent 偶尔成功，并不代表它已经成为可靠的产品。用户真正需要的，是在相似条件下能够对产品行为形成稳定预期。

判断一个 Agent 是否完成任务，至少要看三个层面：结果是否正确，过程有没有越过边界，以及下一次能否以相近方式完成。

这四类不确定性共同存在时，Agent 产品需要建立一套控制机制，分别处理意图、环境、过程和结果中的偏差。

三、让 Agent 值得信任的五层控制系统

如果错误无法被彻底消除，产品团队能做的，是让偏差更早被发现，让风险始终处于可控制的范围内。

这听起来像安全问题，实际上也是产品体验问题。

用户不敢把任务交给 Agent，未必是因为他们认为 AI 不够聪明。更多时候，是因为用户不知道它会做到什么程度，也不知道发生偏差以后，自己能不能及时阻止。

让 AI 能做事，是能力设计；让用户敢把事情交给 AI，才是信任设计。

1. 意图确认：把隐藏假设暴露出来

减少用户操作是合理目标。用户选择 Agent，就是希望省去一部分规划和执行成本。如果每完成一步都要弹出确认窗口，Agent 就会退化成一个需要不断点击“下一步”的流程工具。

减少确认，并不等于取消确认。

产品真正需要解决的是：哪些信息可以由 Agent 自行判断，哪些信息必须由用户决定。可以用两个因素判断：当前需求存在多大歧义，以及判断错误会带来多大后果。

如果任务歧义较低，而且结果容易撤销，Agent 可以拥有更大的自主空间。用户让 AI 调整一段内部草稿的格式，即使结果不符合预期，也可以快速修改。

如果任务仍然模糊，后续动作又会影响外部系统，Agent 就不应该仅凭猜测继续推进。

例如，用户说“把这份材料整理好后发给大家”，Agent 仍需要明确接收人、发送渠道、当前版本能否对外发布，以及附件中是否包含不应该公开的信息。

更好的确认方式应该把 Agent 对任务的理解直接展示出来：

我理解你的目标是将这份材料整理为正式版本，并发送给项目群中的五位成员。目前我还不能确定是否需要保留内部批注。确认删除批注后发送吗？

这种确认把 Agent 隐藏的假设暴露了出来。用户只有看见 AI 如何理解任务，才能判断双方是否已经对齐。

2. 权限边界：按风险逐步开放能力

读取文件、修改文件、删除文件和把文件发送给外部人员，虽然都可以被描述为工具调用，但风险完全不同。

OpenAI 在《A practical guide to building AI agents》中建议，根据工具的读写属性、可逆性、账户权限和潜在财务影响划分风险等级。对于敏感、不可逆或影响较大的操作，应当触发人工确认。[5]

Anthropic 也提到，用户可以针对不同工具和动作设置“始终允许”“需要批准”或“阻止”等权限。[2]

Agent 的权限设计不应该只有“允许”和“不允许”两个选项。产品至少需要区分读写属性和结果可逆性，判断影响范围是否会触达外部人员与系统，并识别账号、隐私、资金等高风险资源。

低风险操作可以持续授权，高风险操作则应该按次确认。权限也不必在任务开始时一次性全部交出，而可以随着任务推进逐步开放。

例如，一个负责整理会议资料的 Agent，最初只需要读取指定文件。用户确认整理结果后，它才获得写入新文件的权限。等用户再次确认接收人和发送内容后，它才可以调用邮件或通讯工具。

Agent 权限设计的目标，是让每一项权限都与当前任务真正需要的能力匹配。

3. 过程可见：展示用户做判断所需的信息

当 Agent 执行长任务时，一种产品什么都不展示，只给用户一个不断变化的进度提示；另一种产品展示大量工具调用、系统日志和技术细节。前者让人失去控制感，后者又很难真正帮助用户判断。

过程可见不等于把所有内容都堆到界面上，更不等于公开模型完整的内部推理。

用户真正需要看到的是：Agent 当前理解的目标、准备采用的计划、已经完成的关键步骤、使用过的文件和来源、对原有内容进行了哪些修改、现在遇到什么异常，以及下一步是否会触发高风险动作。

OpenAI 把 tracing 和 observability，也就是执行追踪与可观测性，作为 Agent 开发工具的重要组成部分；Anthropic 在 Agent 评测中则把输出、工具调用、中间结果和交互过程组成的完整记录称为 trace 或 trajectory，用于分析任务究竟在哪一步发生了问题。[6][3]

这些轨迹不应该永远隐藏在后台。开发团队需要它定位错误，用户也需要经过整理的过程信息来判断是否继续信任 Agent。

如果用户只能看到最后结果，一旦结果不符合预期，他只能重新描述整个任务。如果能够定位偏差出现在哪一步，就可以只纠正那个判断，而不必推翻全部过程。这不仅提升控制感，也直接减少返工时间和 Token 消耗。

4. 失败恢复：不要让用户为一次错误重新开始

很多产品把“任务完成”设计得很完整，却没有认真设计“任务失败”。

一旦 Agent 走错方向，用户往往只能继续在当前对话中反复解释，或者彻底放弃当前结果，从头再来。这两种方式都把恢复成本交给了用户。

Agent 产品应该把失败视为一条正常路径，至少具备几种恢复能力：用户发现方向不对时可以暂停；长任务可以保存阶段性检查点；修改类操作能够撤销；原方案失败后可以保留已有成果并换一条路径；Agent 无法继续时，可以把当前状态完整交还给用户。

这里的重点，是降低一次失败的破坏范围。

如果 Agent 完成了十个步骤，在第八步出现问题，成熟的产品应该允许用户从第七步继续，而不是重新消耗一次理解、规划和执行成本。

恢复能力也决定了用户愿意给 Agent 多大的自主权。当用户知道过程可查看、可暂停、可撤销时，他更可能允许 Agent 独立完成长任务。

5. 结果验证：把“完成”变成可以检查的证据

Agent 调用工具后，经常会收到一个明确的成功信号：文件创建成功、邮件发送成功、数据写入成功、代码执行结束。

这些信号只能证明某个动作已经发生，不能证明用户目标已经实现。

产品需要区分三个层次的完成：第一层是动作完成，工具是否正常调用；第二层是状态正确，文件、邮件或数据是否到达预期位置；第三层是目标实现，最终结果是否真正解决了用户的问题。

很多 Agent 停留在第一个层次，却用“任务已完成”描述整个结果。

更可信的产品应该给出完成依据。例如，代码 Agent 不只是告诉用户“已经修复”，还需要运行相关测试，并说明修改了哪些文件、测试结果如何。资料整理 Agent 不只是生成一份文档，还要说明使用了哪些来源、遗漏了哪些信息，以及哪些结论仍然存在不确定性。

任务完成不应该只是 Agent 对自己的评价，而应该变成用户可以检查的证据。

意图确认、权限边界、过程可见、失败恢复和结果验证，共同组成了 Agent 产品的控制系统。它们的作用，是在给 Agent 更大自主权之前，先建立一条可以被理解、干预和修正的执行路径。

值得信任的 Agent 也会出错，但用户始终知道它正在做什么，清楚自己把哪些决定交给了它，并且在发生偏差时，仍然能够把任务带回正确方向。

四、自主程度设计：并非越高越好

谈到 Agent 时，人们很容易把“完全自主”当成最终目标。似乎它向用户提问越少、连续执行时间越长、能够独立完成的步骤越多，就越先进。

这种判断忽略了一个前提：不同任务的风险并不相同。

让 Agent 整理一份尚未对外发布的草稿，和让它向客户发送正式邮件，不应该拥有相同的自主程度。让它读取项目资料，与允许它删除文件、修改数据库或者发起付款，也不应该使用同一套交互逻辑。

衡量 Agent 产品时，真正应该追求的是“合适的自主性”。把任务歧义和操作风险放在一起，可以得到四种基本情况。

低歧义、低风险：直接执行

目标明确、结果容易撤销，就没有必要频繁打断用户。例如按照指定模板整理文字，或在副本中生成几个备选方案。

高歧义、低风险：先探索，再让用户选择

用户只说“帮我把这份内容做得更专业”，Agent 很难判断他想调整结构、语言、视觉风格还是论证深度。此时可以先生成多个方向、制作预览，或者明确说明暂时采用了哪些假设，再让用户选择。

低歧义、高风险：完成准备，最后一步确认

用户意图已经清楚，但执行结果具有较高风险，例如取消服务、向客户发送邮件或者更新正式系统中的数据。Agent 可以提前完成准备，在真正提交、发送、删除或付款之前展示关键内容并获得授权。

高歧义、高风险：停止执行，重新确认目标

用户意图没有对齐，操作结果又难以撤销，这是最不适合 Agent 自主推进的情况。能够拒绝在信息不足时行动，本身也是一种 Agent 能力。

人工介入也不等于用户不断点击确认。人在 Agent 流程中可以承担三种角色：涉及偏好和业务取舍时，人是决策者；涉及外部影响和不可逆操作时，人是授权者；Agent 超过重试次数、遇到规则冲突或无法判断下一步时，人是异常处理者。

人工介入发生在什么时机，真正决定了这段体验是顺畅还是烦琐。

如果 Agent 每一步都要求确认，用户会觉得烦琐；如果它直到造成错误以后才交还控制权，用户会失去信任。合适的设计，是让 Agent 在低风险、信息充分的部分保持连续执行，在关键分叉点和高风险动作前主动停下。

接管机制还必须带着上下文和进度。Agent 停止后，应该交付它对当前任务的理解、已经完成的关键步骤、无法继续的具体原因，以及建议用户决定的下一步选项。

成熟的 Agent 能在适合自主执行的地方减少用户负担，在必须由人判断的地方保留边界，自己无法继续时，也不会把一个混乱的残局交回来。

五、模型能力提升后，控制机制会消失吗？

今天的 Agent 会误解需求、选错工具、在错误方向上继续执行，可能只是因为模型能力还不够。随着推理、记忆和工具使用能力继续提升，产品是否还有必要设计这么多控制机制？

这个反问并不是没有道理。

模型进步确实可以解决一部分问题。更强的模型能够更准确地理解自然语言，更合理地拆解任务，也更容易发现工具返回结果中的异常。过去需要用户反复说明的内容，未来可能一次就能被正确理解。

但 Agent 面对的问题，并不都来自模型不够聪明。

有些不确定性存在于用户目标本身

用户说“帮我选一个最合适的方案”，其中的“最合适”究竟指价格最低、风险最小、效果最好，还是执行速度最快？

这不是一个只要模型更聪明就必然能够推导出来的答案。模型可以根据上下文猜测，也可以结合用户历史偏好进行判断，但只要用户自己没有明确表达，结果中就始终包含推断。

更强的模型可能猜得更准，却无法把偏好问题变成客观事实。

错误率降低，不代表风险可以忽略

产品是否可以取消控制机制，不能只看错误出现的概率，还要看一次错误会造成什么后果。

可以把 Agent 风险粗略理解为四个因素共同作用：

偏差发生的概率 × 偏差造成的影响 × 被发现所需的时间 ÷ 结果的可恢复程度

这是一个用于产品分析的简化表达，不是一条严格数学公式。它想说明的是：概率只是风险的一部分。

一个偶尔写错内部草稿的 Agent，和一个偶尔向错误账户付款的 Agent，即使成功率完全相同，也不应该采用相同的产品设计。

对于低风险、可撤销的任务，模型能力提升后，产品可以减少确认。对于高风险、不可逆的任务，即使错误已经很少发生，权限控制、结果验证和人工授权仍然有存在价值。

能力越强，单次行动的影响范围也可能越大

聊天机器人生成一段错误文字，影响通常停留在当前对话。Agent 如果能够连续运行数小时，访问多个系统，并自主调整执行方案，那么一次早期误判可能影响更多文件、数据和外部对象。

Anthropic 在 2026 年发布的《Measuring AI agent autonomy in practice》中观察到，Agent 正在更长时间地自主运行，高自主、高风险的使用场景虽然仍然较少，但已经开始出现。[7]

这项研究只覆盖 Anthropic 自身的模型和相关使用数据，而且 Claude Code 场景以软件开发为主，不能直接代表全部 Agent 产品。不过，它至少揭示了一个值得关注的趋势：Agent 的自主性不是孤立增长的。随着它能够执行更复杂的任务，产品也需要重新考虑监督和介入方式。

能力和控制并不是二选一的关系。Agent 越能做事，产品越需要明确它可以在哪里做、做到什么程度，以及用户如何在必要时改变方向。

模型升级也可能改变原有产品行为

Agent 不是一个单独运行的模型。它还包括系统提示、工具、权限、任务状态、错误处理方式和用户界面。

更换一个更强的模型，并不保证产品的所有表现都会同步提升。新模型可能更擅长规划，却更倾向于自行扩展任务范围；可能能够完成更多步骤，却更少向用户确认；也可能在平均结果上更好，但在某类边界场景中出现新的行为。

如果产品团队没有稳定的评测标准，就很难判断一次模型升级究竟改善了什么，又损害了什么。

随着模型变强，控制机制当然不应该永远保持今天的确认频率。低风险任务可以逐渐减少审批，重复操作可以积累用户授权，成熟用户也可以从“逐步批准”转向“整体监控、必要时介入”。

真正会变化的，是控制方式，而不是控制本身。

管理不确定性不是给今天不够聪明的模型打补丁。它是 Agent 从演示走向真实产品后，需要长期承担的一项设计责任。

六、AI 产品经理需要回答的五个问题

传统产品设计经常从用户流程出发：用户从哪里进入、依次完成哪些操作、系统给出什么反馈、最后怎样离开。

Agent 没有完全摆脱流程，但流程中的一部分决定权被交给了模型。相同的入口和需求，也可能产生不同的执行路径。

产品经理面对的不再只是“用户下一步点击什么”，还要考虑“模型下一步可以决定什么”。

1. 这个任务真的需要 Agent 吗？

并不是所有加入大模型的产品，都需要做成 Agent。

有些任务路径稳定、规则明确，传统工作流反而更加便宜、快速，也更容易测试。Agent 更适合处理那些目标相对明确，但实现路径会因为上下文和环境变化而不同的任务。

判断一个场景是否适合使用 Agent，可以检查几个条件：用户能否描述一个相对清晰的目标；完成任务是否需要根据中间结果调整方案；Agent 是否能够观察环境变化；是否存在明确工具帮助它采取行动；最终结果能否被检查；失败以后能否控制影响范围。

如果任务没有清晰目标，也无法验证结果，Agent 很可能只是在一个模糊环境中持续生成动作。如果任务路径完全固定，又没有动态决策需求，那么 Agent 带来的可能只是额外延迟、成本和不可预测性。

2. Agent 的自主权从哪里开始，到哪里结束？

一个完整任务里，通常存在三类内容：可以交给 Agent 的执行判断；可以由 Agent 提出建议、但应该由用户决定的内容；以及必须由用户明确授权的操作。

产品经理需要把这三类内容区分开，而不是只设计一个统一的“自动执行”开关。

对于同一项任务，Agent 的自主权也可以分阶段变化。它可以自主完成资料收集和方案准备，在关键决策点向用户展示选项，获得授权后再继续执行。

3. Agent 在什么情况下必须停下来？

传统流程中的异常通常由明确规则触发：字段为空、接口报错、权限不足。Agent 除了面对系统异常，还会面对认知上的不确定性。

更具体的做法，是提前识别任务中的关键分叉点，明确哪些信息缺失时不能继续，哪些假设会改变最终方向，哪些操作执行后无法撤销，以及重试次数、规则冲突和预计成本达到什么条件时必须交还用户判断。

这些条件共同构成 Agent 的停止规则。产品经理需要为暂停、询问、升级和退出设计明确路径，而不是把所有异常都交给模型临场发挥。

4. 用户需要看到什么，才能有效监督？

Agent 可以自主执行，不代表用户应该完全失去过程信息。但监督也不是把系统日志全部展示出来。

产品经理需要根据任务长度和风险，决定展示目标理解、阶段进度、关键判断、权限状态、异常信息和修改记录中的哪些内容。

监督的目标，是确保用户在需要介入时，有足够信息做出判断。好的监督体验，应该让用户能够放心离开，也能够随时回来接管。

5. 产品怎样证明 Agent 真的有用？

很多 Agent 产品最容易展示的指标，是调用了多少工具、自动执行了多少步骤、为用户生成了多少内容。这些数据可以说明产品很忙，却不能证明它真正创造了价值。

产品团队至少需要从五个维度观察 Agent：最终结果是否满足用户目标；过程是否遵守权限和业务规则；相似任务多次运行是否稳定；用户需要纠正、确认和接管多少次；发生偏差后，需要多少时间和 Token 才能回到正确方向。

如果产品承诺提高效率，就要计算用户真正节省了多少时间。如果产品承诺端到端完成任务，就要检查最终环境状态。如果产品强调可靠性，就要重复运行相似任务，观察它是否只在某一次恰好成功。

在传统软件中，产品经理通常先定义流程，再让用户按照流程完成任务。在 Agent 产品中，流程的一部分由模型动态生成。产品经理无法预先画出每一条执行路线，但仍然必须定义路线的边界。

他需要明确可以交给模型的决定、必须向用户解释的判断、必须获得授权的动作、触发停止的信号，以及证明任务完成的证据。

这些问题决定了 Agent 是一个偶尔表现惊艳的演示，还是一个能够进入真实工作流程的产品。

七、从“能做”到“值得托付”

回头看我最开始提到的那次经历，AI 并没有表现出明显的能力不足。

它能够理解项目的大概方向，也能快速制定方案并开始执行。从工具调用和内容生成的角度看，它甚至称得上高效。

但从产品结果来看，那次执行并不成功。因为在真正理解我的需求之前，它就替我补全了缺失信息，并把自己的推断直接变成了行动。

这个问题很容易被归结为“提示词没写清楚”。如果用户一开始就把背景、目标、限制和交付标准全部说明，AI 当然更容易给出正确结果。

真实世界中的任务，很少从一开始就拥有一份完整说明书。

人们经常只知道自己想解决什么问题，却还没有想清具体方案；也可能默认了一些背景信息，没有意识到 AI 并不知道；还有些关键要求，本来就需要在讨论过程中逐渐明确。

如果一个 Agent 只有在用户写出完美需求时才可靠，那么它实际上把最困难的任务理解工作重新交还给了用户。

Agent 真正有价值的地方，正是它可以面对不完整信息，帮助用户逐步理解问题、补充条件并推进任务。但这也意味着，它必须学会区分：哪些空白可以合理补全，哪些空白必须留给用户决定。

过去评价 AI 产品，人们更关心模型知道多少、回答是否准确、生成速度是否足够快。当 AI 开始调用工具、修改文件并进入真实业务流程后，评价范围还要覆盖它能否识别尚未理解的内容，是否会在高风险动作前停下，用户能否看见任务推进依据，发生偏差后能否从中间状态恢复，以及“完成”有没有可以检查的证据。

这些问题共同指向的，是 Agent 如何管理不确定性。

未来 Agent 产品之间的竞争，可能不会只发生在模型和工具数量上。当不同产品都能够搜索资料、处理文件、执行代码和操作软件以后，真正拉开差距的，是谁能够让用户放心地把更重要的任务交出去。

对 AI 产品经理来说，这也意味着工作重点正在变化。我们设计的不再只是一个模型如何回答问题，而是一个拥有行动能力的系统，应该如何与人分配判断权、执行权和最终责任。

产品经理无法提前规定 Agent 的每一步，却必须为它划定可以行动的范围，并为用户保留理解、干预和恢复的能力。

模型能力决定 Agent 最远能够走到哪里。

产品设计决定用户是否愿意让它走那么远。

一个真正成熟的 Agent，不是把人彻底移出流程，而是让人只出现在那些必须由人决定的位置。

参考资料

1. Anthropic, Building effective agents

2. Anthropic, Trustworthy agents in practice

3. Anthropic, Demystifying evals for AI agents

4. Shunyu Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains

5. OpenAI, A practical guide to building AI agents

6. OpenAI, New tools for building agents

7. Anthropic, Measuring AI agent autonomy in practice