倒置智能体：当用户是规划者，模型是步骤执行者时

当今大多数智能体 (agent) 产品都达成了一个简单的契约：模型决定做什么，用户点击“批准”。对于低风险的消费者聊天场景 —— 预订餐厅、摘要收件箱、起草非正式回复 —— 这确实是正确的形式。但对于法律起草、财务咨询、医疗分诊和事件响应来说，这却是灾难性的错误。在这些场景中，用户承担着模型永远无法承担的问责，而且错误 计划 的成本远高于任何单个 步骤 的成本。

反向智能体翻转了这种极性。用户将计划构思为一系列命名的、可重新排序的步骤。模型按需执行每个步骤 —— 拥有完整的上下文、工具访问权限和推理能力 —— 但绝不决定下一步该做什么。模型可以提供建议，但建议仅供参考，不具有自主性。这并不是一个更糟糕的自主智能体；它是一个完全不同的产品，虽然其成本和延迟表现绝对更差，但信任度绝对更高，专门针对那些否则会完全拒绝采用自主版本的用户。

团队一直在犯的错误是将“自主性”视为默认的努力方向。它其实是一个你在每个界面上选择的 UX 维度。如果搞错了极性，你交付的功能就会被那些承担最高风险的用户悄悄拒绝使用。

默认 UX 在不知不觉中发生了反转

回到十年前。工作流工具意味着：用户定义步骤，系统确定性地执行它们。Airflow、Make、Zapier。计划是用户的知识产权；平台是基础设施。故障模式非常枯燥 —— 步骤重试、连接器断开 —— 但没有人会混淆决策树的所有权归谁。

然后，对话界面出现了。对话设计天生具有交互性，这种界面让模型成为了主动方 —— 由它来决定、规划和回复。用户输入意图，模型返回结果。计划-执行 (Plan-and-execute) 架构将此形式化：规划模块将目标分解为有序步骤，执行模块实现它们。这两个模块都存在于模型内部。用户只出现在两个位置 —— 开始时的提示词，以及结束时的批准点击。有时还有中间的一个检查点。

这种形式对于用户的意图能在提示词中充分表达，且步骤错误后重做成本较低的任务来说是可以的。“帮我找去里斯本低于 400 美元的航班”可以容忍模型挑选搜索策略。但“为 Henderson 案件起草和解信”则不行。

问题不在于自主性本身。问题在于“对话优先”模式偷偷引入了一个假设 —— 模型就是规划者 —— 而这并不是谁显式选择的结果。产品团队交付对话 UI 是因为框架默认就是对话，而对话的形式决定了规划者的位置，规划者的位置又决定了当计划出错时谁来负责。一个 UI 选择引发了三个架构决策的连锁反应，而大多数团队只有在监管机构问责时才会注意到第三点。

何时反转才是正确的默认选择

五种情况使得反向智能体成为正确的产品，而非错误的产品：

用户承担着模型所没有的问责。 律师签署辩护状，医生签署医嘱，SRE 在事故期间运行运维手册。他们的名字签在结果上。受监管领域中人工智能的责任框架都趋向于一个原则：无论系统自主完成了多少工作，环节中的人始终是责任方。如果用户在法庭上要为计划负责，那么他们在 UI 中也应该对计划拥有所有权。

错误计划的成本超过了任何单个步骤的成本。 在法律起草中，错误的辩论结构可能会导致输掉官司，即使每一段文字都写得很好。在事件响应中，错误的修复步骤序列可能会延长停机时间，即使每个命令都执行得非常顺畅。计划是承重的关键。将计划的制定权移交给模型，意味着将杠杆率最高的决策移交给了问责制最低的一方。

用户了解模型无法观察到的情况。 案件周边的策略。病历中未包含的患者背景。值班频道中的政治动态。用户拥有决定下一步该做什么的私密信息，而这些信息永远不会进入系统提示词，因为它们是隐性的、不断变化的，或者明确属于系统范围之外的。

可逆性是不对称的。 有些步骤是无法撤回的 —— 发送电子邮件、提交动议、执行交易。用户需要成为决定何时跨越这些门槛的人。批准每一个单独的调用过于细碎；到那时，模型已经限定了决策的框架。用户需要从一开始就是引入该步骤的人。

用户无论如何都会验证输出内容。 如果一名资深律师助理要阅读模型生成的每一段文字，那么自主规划所宣称的效率提升就是虚幻的。律师助理的审查才是实际的限速因素。反向智能体意味着助理编写一次计划，由模型来填充步骤 —— 往返次数更少，而不是更多。

当这些条件成立时，自主智能体的 UX 解决的是错误的问题。用户并不是想委托计划；他们只是想委托打字。

反转所需的交互原语

聊天框对此并不适用。交互原语在本质上就不同，而不仅仅是程度上的差异。

具名、可调序的步骤。 计划是一等公民产物：一个带有稳定标识符、描述和依赖关系的步骤列表。用户可以将步骤 3 拖动到步骤 2 之上，重命名步骤 4，将步骤 5 一分为二，或者完全删除步骤 6。计划是可编辑的结构，而不是聊天消息。一旦用户在这种结构中投入了创作精力，他们就以一种从未拥有过模型自动生成的提纲的方式拥有了它。

按步骤按需执行。 当用户点击“执行步骤 3”时，模型将运行该步骤——前序步骤的输出作为上下文可见，相关工具可用，并在需要时进行完整的推理。模型不会自动推进。它不会抢先运行步骤 4。它不会提议“干脆继续完成剩下的部分”。执行的边界就是步骤的边界，而步骤的边界由你设定。

带有判断而非仅是批准的中期计划检查点。 检查点不是一个“是/否继续”的简单判断——它是用户检查步骤输出、可能对其进行编辑、可能以不同的框架重新运行、然后才决定下一步做什么的时刻。步骤 N 的输出是用户下一个计划决策的 输入，而不仅仅是更大流水线中的中间变量。

模型建议的下一步仅供参考。 模型可以在每一步之后提议步骤 N+1 可能是什么。这很有用——模型拥有新鲜的局部上下文，可能会注意到你没有注意到的事情。但这个建议是咨询性的：它作为一个草稿步骤出现，你可以接受、编辑或忽略它。它不会自动插入到计划中。默认动作是“什么都不做”；你必须主动拉取建议。

计划版本控制与回放。 因为计划即规范，所以计划的更改需要被跟踪。用户可以重新规划、重新运行、比较不同计划版本的输出。“得到不同的结果是因为模型变了，还是因为我改变了计划？”这是系统必须回答的问题。

这些不是聊天 UI 上的装饰。它们重新定义了交互模型。如果一个团队试图将这些功能硬塞进聊天界面，那么产出的东西感觉既像是一个更糟的聊天工具，又像是一个更糟的规划器。

评估框架必须改变

自主 Agent 是根据目标完成度来评估的：给定一个用户目标，系统是否实现了它？轨迹质量是次要关注点——对于调试很有趣，但对于产品主张来说并不关键。

反转 Agent 要求一个不同的评分维度：计划一致性 (Plan conformance)。给定用户的计划，模型是否忠实地执行了每一步？步骤 3 的输出是否反映了步骤 3 的要求，是否符合计划指定的格式，是否使用了你授权的工具？目标完成现在是 用户 的问题，因为用户拥有计划。模型的工作是成为一个可靠、可预测的、执行规格明确的步骤的执行者。

这听起来像是一个更小的评估面，在某些方面确实如此。但它也暴露了自主 Agent 评估套件从未衡量过的失败模式：

• 步骤漂移 (Step drift) —— 模型将步骤 3 解释为一个略有不同的步骤，因为它的训练倾向于自主形态。如果结果是好的，目标完成度评估会判定这没问题。但计划一致性评估会将其标记为退化。
• 隐式重新规划 (Implicit re-planning) —— 模型在执行中途认为用户的计划不是最优的，并重新排序或合并了步骤。在计划即规范的领域，这是灾难性的。
• 过早优化 (Premature optimization) —— 模型跳过了一个步骤，因为它判断该步骤是不必要的。这正是反转本应防止的自主行为。
• 上下文渗漏 (Context bleed) —— 步骤 3 隐式执行了一个本应由步骤 2 授权的工具。审计追踪偏离了你预期的轨迹。

反转 Agent 的评估套件更接近于工作流引擎的一致性测试，而不是 LLM 的任务基准测试。它评分的是对规范的忠实度，而不是追求目标时的创造力。重复使用现有 Agent 评估设施的团队将无法捕捉到最重要的失败模式。

成本与延迟的权衡是真实的

反转 Agent 肯定比其自主版本更昂贵、更缓慢。用户参与到每一个步骤中，这意味着人类的延迟主导了实际耗时（墙钟时间）。每一个步骤都是一次独立的模型调用，有其自身的上下文组装和工具往返。激进的缓存会有所帮助，但无法弥补自主性带来的差距。Token 成本会上调，因为每一步都是独立地以完整上下文锚定的，而不是在一个长长的自主轨迹中链式进行。

假装不是这样，或者试图将延迟优化回聊天水平，都会让设计一步步退回到自主模式。要抵制这种诱惑。这种权衡本身就是产品。一个愿意花 30 分钟编写一个 12 步计划并审查每个输出的用户，与一个想要在聊天中得到 90 秒答案的用户不是同一个人——试图用同一个界面服务两者，会产生一个对两者都失败的 UI。

团队应该采用的成本框架是：反转 Agent 是在与用户 完全不使用 AI 的手动操作 进行竞争。相关的基线是“助理自己输入每个段落”，而不是“Agent 在 30 秒内完成”。与那个基线相比，即使是一个缓慢、昂贵、深度受控的助手也是巨大的杠杆。错误的做法是拿它与自主 Agent 进行基准测试（在那种测试下反转版本总是会输），并得出产品不好的结论——而实际上，它是为不同用户准备的不同产品。

组织性的失败模式

团队交付错误 UX 的最常见方式：在某个高责任领域，产品经理调研 “用户希望从 AI 那里得到什么”，听到 “我希望它帮我起草”，然后将其解读为 “构建一个聊天助手”，并交付了一个聊天 UI。高责任用户礼貌地向团队表示感谢，但并不采用。团队得出结论，认为模型还不够好，于是等待下一次能力提升。

下一次能力提升永远解决不了这个问题。问题不在于模型质量，而在于 UX 极性。用户希望在他们规划时，模型帮他们打字。而团队提供的是一个在他们审批时替他们规划的模型。

设计时的纠偏问题是：在这个产品中，谁拥有主导权？ 如果答案是 “由于职业必要性，用户拥有主导权”，而 UI 又没有提供由用户创作的一流计划结构，那么这个 UI 就是错误的。任何提示词工程、评估改进或模型升级都无法修复它。产品的根基是错误的，高责任用户在尝试几分钟内就能通过职业模式识别发现这一点。

那些在正确的领域有意识地交付反向智能体的团队，发现了相反的情况 —— 那些明确拒绝自动版本的用户开始采用该产品。这种感觉像是倒退的约束（更慢、更多的点击、更多的用户投入），事实证明正是让产品值得信赖的核心特性。

自治是一种 UX 维度，而非默认设置

帮助理解的框架是：智能体自治是一个滑块，而不是终点。不同的界面位于滑块的不同位置，而正确的位置取决于问责制、可逆性和用户的信息优势。一个产品可能需要多个界面 —— 用于低风险查询的自动聊天，以及用于高责任工作的反向规划器 —— 并且两者之间有明确的交接。

团队应该停止这样做：将 “更自动化” 视为进步的轨迹。自治只是几种产品定位中的一种，对于受监管、需负责的高责任领域的很大一部分用户来说，正确的产品位于滑块的 低自治 端 —— 这不是因为模型弱，而是因为用户的问责特征要求如此。

下一代智能体产品看起来将不那么像聊天窗口，而更像是一个结构化编辑器：用户构思计划，模型根据需求填充每个步骤，审计轨迹准确显示哪些决策属于谁。这不是退化。这是最高杠杆、最高责任的使用场景一直以来所需要的 UX 形态 —— 行业只是在经历了几年先构建自动化版本的尝试后才注意到这一点。