Demo 很神奇，架构图却让人不安
许多 AI 项目都会经历一个瞬间：兴奋悄悄变成了不安。
Demo 成功了。用户只写一句话，模型就选择一个工具、查询一些数据、再调用另一个工具，最后给出一份漂亮的答案。那几分钟里，你会感觉软件似乎跨过了某条界线：我们不再逐步编程，而是描述一个结果，然后看着机器自己找到路径。
接着，有人问了一个再普通不过的问题：
如果它选错工具怎么办？
房间安静了下来。
更多问题随之出现。它能读什么？能改什么？最多重试几次？它可以未经批准就发邮件吗？如果客户在工单里写了一段指令，那些指令会不会影响 Agent？一条每次路径都可能不同的失败记录，又该怎样复现？
我们的第一反应往往是再加一段 prompt、一道 guardrail、一个 evaluator，甚至再加一个 Agent 去监督第一个。有时这些确实必要。但有时，那个令人不太舒服的答案其实更简单：
我们从一开始就不需要 Agent。
我们需要的是一个应用：让 AI 负责需要判断的部分，其他事情仍由普通代码完成。
AI Agent 与工作流：区别在哪里？
“Agent”这个词已经宽泛到几乎可以指任何使用语言模型的应用，也让架构讨论变得不必要地混乱。
“Agent”应该描述一种架构，而不是一种野心。
Anthropic 在构建有效 Agent的指南中给出了一个很有用的区分：
- 在工作流中，代码决定模型和工具按什么顺序被调用。
- 在 Agent 中，模型控制自己的过程，并在任务进行时决定使用哪些工具。
OpenAI 的构建 Agent 实用指南也作出了类似区分：一个应用即使使用 LLM，只要不是由 LLM 控制工作流执行，按照这个定义，它就不是 Agent。
这并不是关于命名的争论，而是在决定：下一步究竟由谁控制。
由应用控制的工作流： 代码 → 被允许的上下文 → 模型 → 验证 → 代码决定下一步
由 Agent 控制的工作流： 目标 → 模型决策 → 工具 → 观察结果 → 模型再次决策
两者都可能有价值，只是解决的问题不同。
真正的错误，是把第二种架构当作第一种架构理所当然的升级版。
想象一张客服工单
假设一位客户写道：
订单 4821 被扣了两次钱，可以帮我处理吗？
一个自治式设计可能会让 Agent 访问客户资料、订单、支付、退款、邮件和内部政策。Agent 阅读消息，决定查询哪些信息，判断是否退款，然后发送回复。
在架构图上，它非常优雅，因为整个系统都可以被画成一个写着 Agent 的大方框。
但这个方框隐藏了几乎所有真正重要的决定。
对于这个任务，应用其实已经知道很多事情：
- 必须从消息中提取订单号。
- 必须查询订单及其交易记录。
- 必须检查重复扣款政策。
- 退款可能需要审批，或者由确定性的规则作出决定。
- 必须根据真实发生的结果回复客户。
只有其中一部分需要语言理解。一个更小的设计可以是：
模型依然承担了真正有价值的工作：理解混乱的自然语言，写出体贴的回复。但它从未拿到整个应用的万能钥匙。它只看到当前任务所需的信息，而它的输出是一份具有明确结构的建议，不是可以随意行动的许可。
这样的系统也许没有那么“未来感”。但凌晨两点，当客户告诉你系统错误处理了这笔款项时，它会容易信任得多。
更简单不等于“更少 AI”
AI 产品开发中存在一种奇怪的压力：似乎必须让模型控制尽可能多的东西。如果应用选择工具，好像就不够智能；如果后端规则批准退款，好像就没有做到 Agentic。
但自治不是产品。解决用户的问题才是产品。
LLM 可以在由应用控制的工作流中，为模糊请求分类、从格式不一的文档中提取字段、比较两种解释、总结证据，或者写出自然的文字。代码决定下一步，并不会夺走模型的推理能力。
事实上，约束往往能让这种推理更有用。模型获得更干净的上下文，面对更明确的问题，输出可以通过 schema 验证。失败时，团队知道是哪一步失败，也知道模型当时看到了什么。
好的工程，不是用一个组件拥有多少自由来衡量，而是看整个系统是否表现良好。
每一份自治能力都有一笔“自治税”
把控制权交给模型，可能会减少编排代码，但复杂性并没有消失。它只是被搬到了运行时行为里，变得更难看见。
路径本身也成了输出
在固定工作流中，你可以列出重要路径：请求被批准、拒绝或升级人工。每条路径都可以有测试、权限、超时和负责人。
而在 Agent 中，工具调用顺序是生成出来的。两个相似的请求可能走过不同路线。你需要评估的不只是最终答案，还包括系统为了得到答案走过的路径。
这也是 Agent 评估困难的原因之一。只看最终答案的准确率，并不能反映成本、鲁棒性或可复现性。一个系统即使能得到正确答案，如果路径昂贵或脆弱，也可能在基准测试中表现不错，却并不是一个好产品。
错误会随着步骤增加而累积
下面只是一个直观例子，而不是可靠性模型：假设每一步都有 95% 的概率表现合格，听起来似乎很可靠。但在连续十个步骤中，如果暂时假设它们彼此独立，那么每一步都合格的概率只有约 60%。
真实世界里的错误并不独立，因此这不是一份可靠性预测。它只是提醒我们：长链条会累积不确定性。工具错误、含糊响应、过期上下文、重试和错误假设，都可能被带进后续决策。
工作流同样可以有多个步骤，但它能在步骤之间设置确定性检查。下一个动作不必继承模型的自信。
成本和延迟变得难以预测
一个工作流通常在开始前就能告诉你最多会调用几次模型。Agent 则可能搜索、反思、重试、调用工具、修改计划，然后再次搜索。
这种灵活性有时正是 Agent 成功的原因，但也让预算和响应时间更难预测。诚实的比较不是“一次工作流调用”和“一次 Agent 调用”，而是比较所有尝试、token、工具调用、失败和完成时间的完整分布。
权限变成了架构问题
Agent 要使用工具，就必须先获得访问权。工具和权限越多，一次错误决策或受到操纵的输入所造成的后果就越大。
OWASP 把这种风险称为过度代理权（Excessive Agency），并总结了三个常见原因：功能过多、权限过大、自治程度过高。它的建议非常务实：减少工具、限制每个工具的能力和权限，并对高影响操作要求人工批准。
这个原则的价值远不止安全：
只给模型解决问题所必需的最小自治能力。
不是完全没有自治，也不是最大化自治，而是让每一份自由都有充分理由。
你应该构建什么？
真正需要回答的，并不是哪种架构看起来更先进，而是哪种架构既能提供足够的灵活性，又不会加入任务根本不需要的控制能力。
| 问题类型 | 推荐架构 |
|---|---|
| 简单的生成、提取或分类 | 单次模型调用 |
| 包含多个已知步骤的可预测流程 | 由应用控制的工作流 |
| 模型需要外部信息或执行一个已批准的操作 | 由应用选择并限制范围的工具调用 |
| 固定工具必须按照受控顺序运行 | 编排式工作流 |
| 必须进行动态规划并选择工具 | Agent |
| 多个独立目标确实能从协作中获益 | 多 Agent 系统 |
只有当前一层无法解决问题时，才向更复杂的一层移动。
结构化输出通常是这些架构内部的一份契约，而不是单独一级的自治能力。工具调用也是如此：让模型为一个已批准函数填写参数，与允许它在几十个工具之间自由选择，完全是两种不同的授权。
从能工作的最小系统开始
上面的表格是一份细粒度选择指南。下面的四层阶梯则按照“谁控制执行”来归纳这些选择：单次模型调用、由应用控制的工作流、有边界的模型决策步骤，以及完整 Agent。一旦某个层级能够可靠解决问题，就停在那里。
第一层：一次模型调用
当任务是转换而不是执行时，使用一次调用：对消息分类、提取结构化数据、总结文档、生成候选项或起草回复。
在认定任务需要 Agent 之前，先尝试检索和示例。Anthropic 的指南提到，对许多应用来说，一次经过优化、带有检索和上下文示例的 LLM 调用已经足够。如果仍然不确定该选哪个模型，应先比较实际表现，再改变架构；同一个模型、同一个 Prompt，答案却不一样中的实验也说明，单次成功运行并不足以成为判断依据。
第二层：由应用控制的工作流
当步骤已经明确，但其中一个或多个步骤需要语言理解或推理时，使用工作流。
应用负责收集上下文、调用模型、验证响应、执行被批准的操作并选择下一步。这是文档处理、内容审核、销售线索筛选、客服分类、用户引导和许多内部流程的可靠默认选择。可复用的工作流与结构化输出契约可以把模型配置和应用逻辑分开，而不必把执行控制权交给模型。
第三层：有边界的模型决策步骤
有时应用知道整体流程，却不知道其中某一部分的最佳完成方式。可以让模型在少量只读工具之间选择，持续搜索直到获得足够证据，或者根据评分标准反复修改答案。此时，理解LLM 与 Agent 框架的取舍也会很有帮助。
这是一种混合架构：把自治能力放进一个带调用次数上限、时间上限、受限凭证和明确退出条件的边界内。
混合系统不是一种需要感到抱歉的妥协。它往往才是更成熟的设计：在正确性重要的地方保持确定性，在真正存在不确定性的地方允许适应。
第四层：Agent
当执行路线确实无法预先指定、环境能提供有价值的反馈，而且适应能力带来的价值超过新增成本和风险时，再使用 Agent。
编程就是一个很好的例子。Agent 可以检查陌生代码库、制定计划、修改文件、运行测试、从失败中学习，然后重试。具体路径取决于它发现了什么，而自动测试又提供了异常强的反馈信号。
开放式研究也可能值得使用 Agent，因为有价值的来源和后续问题并不总能提前预测。即使如此，Agent 仍然需要边界：允许访问的来源、引用要求、支出上限，以及在重要用途前的人类审核。
不要使用 Agent 的情况
- 任务遵循可预测的顺序。
- 你已经知道需要哪些工具。
- 步骤数量少且有明确上限。
- 应用逻辑可以可靠地执行流程。
- 错误操作代价很高，同时又无法进行独立验证。
可以考虑 Agent 的情况
- 无法提前预测下一个有价值的动作。
- 系统必须随着信息增加而动态选择工具。
- 任务需要反复规划与修正。
- 环境能够提供反馈，帮助模型发现错误并恢复。
- 即使成本和复杂性更高，额外灵活性仍能创造可衡量的价值。
构建 Agent 前先问五个问题
1. 请求开始前，我们能否描述成功路径？
如果可以，就把这条路径写进软件。不要让一个概率模型重新发现团队已经理解的流程。
2. 哪些决定真的需要判断力？
圈出涉及歧义、非结构化信息或权衡的位置，在那里使用模型。身份检查、权限、算术、政策执行和不可逆操作，则应尽可能留在普通代码中。
3. 一次错误操作的代价是什么？
推荐错一篇文章和错误地发出一笔退款，不是同一件事。后果越严重，就越应该减少权限、增加独立验证，并把批准权移到模型之外。
4. 系统能否判断自己成功了？
当环境能提供有效反馈时，Agent 最有价值：测试通过、查询返回结果、文件成功编译，或者人类批准了结果。“答案听起来很可信”并不是一个好的停止条件。
5. 我们怎样还原一次糟糕的运行？
上线前，想象一位真实用户在三周后报告了损失。你能找回当时的输入、上下文、模型版本、工具调用、中间输出、审批记录和最终操作吗？如果不能，系统还没有准备好获得更多自治能力。
这种架构在实践中是什么样子
在 ModelRiver，我们经常在团队比较不同模型与 Provider时看到这种区别：模型只是系统的一部分，周围的工作流往往决定了是否真的需要 Agent。ModelRiver 的工作流与后端流水线也遵循同样的职责分离——模型负责语言与有边界的判断，应用代码继续负责可信逻辑与高影响操作。
前面的客服工单可以变成一段明确的交接过程：
模型不需要同时拥有订单、支付、政策和邮件系统的无限访问权。结构化响应告诉后端模型理解到了什么；后端验证事实、执行权限和业务规则、完成被批准的操作，并在另一个模型步骤确有价值时返回已经确认的结果。
对于更长的流程，多步骤后端流水线让 AI 步骤与后端步骤轮流执行，而不必让模型成为整个系统的最终控制者。为什么 AI 需要多次调用你的后端通过一个完整退款案例展示了这种模式。
这只是本文原则的一种实现方式：让应用保留控制权，只把 AI 放在语言或判断真正产生价值的地方。
先构建那个“无聊”的版本
在技术行业，“无聊”经常被当作贬义词。我开始觉得，它其实是一种称赞。
一个无聊的系统会告诉你它将做什么。它的权限很窄，失败状态都有名字。新来的工程师可以在白板上把它画出来，而不需要画一朵写着“AI 魔法”的云。当模型表现异常时——而所有模型终究都会如此——应用依然知道边界在哪里。
这并不意味着我们应该停止探索 Agent。它们处理不确定任务的能力是真实的，而且仍在进步。它意味着：自治能力应该是对已证实需求的回应，而不是架构上的装饰。
先构建工作流。观察它在哪些地方变得僵硬，测量它无法处理的案例，然后只在那些地方给模型自由。
目标不是永远把 AI 拴在一根短绳上，而是在松手之前，清楚地知道为什么。
构建能够解决问题的最简单架构
在加入 Agent 之前，先验证最简单的方法。比较不同模型，并用真实工作流进行测试，可以帮助你判断真正需要的是单次模型调用、受控流水线、有边界的工具使用，还是完整的 Agent 自治能力。
ModelRiver 帮助团队在一个平台上访问并试验来自多个 Provider 的 AI 模型。