先分享一个真实的案例。
某团队打造了一款客服Agent，设计理念看似“超前”：用户提问进来后，Agent自主判断是否需要查询订单、检索知识库或转接人工，完全不加限制。结果上线第一天，当用户询问“退货政策”时，这个Agent竟然调用了8次数据库、3次知识库，最后返回了一段包含SQL报错信息的回答。整个过程耗时47秒，消耗Token约$0.12，用户体验评分只有1星。
反观如果用简单的if-else判断“退货政策”→直接返回固定文本，用时仅0.3秒，成本为零，回答准确无误。这就是过度Agent化带来的代价：把一个确定性问题交给了概率性系统去“自由发挥”。
一、先厘清概念：什么是Agent，什么不是
当前行业最大的混乱之一，就是所有技术方案都被冠以“Agent”之名。
1.1 三种类型，三种定义
| 类型 | 核心特征 | 控制权 | 适用场景 |
|---|---|---|---|
| 单次LLM调用 | 输入→输出，一步完成 | 完全由代码控制 | 分类、摘要、翻译 |
| 确定性工作流 | 多步LLM调用，流程写死 | 代码控制流程，LLM只管每一步 | 多步处理、管道、ETL |
| 自主Agent | LLM自己决定下一步做什么 | LLM控制流程 | 开放性任务、动态决策 |
关键区别在第三列——谁来决定下一步动作？
- 如果是你的代码决定：那就是工作流，无论内部调用了多少次LLM
- 如果是LLM自己决定：那才是真正的Agent
用通俗的话讲：工作流好比GPS导航——路线已预设，按指引前行；Agent好比自动驾驶——车自主选择方向。你的场景真的需要自动驾驶吗？大多数时候，导航就够了。
1.2 一个核心拷问
在决定采用Agent之前，先问自己一个问题：
这个任务的决策路径，能用if-else写出来吗？
- 如果能——用工作流，不要上Agent。
- 如果不能——再问第二个问题：决策分支有多少？
- 如果只有3-5个，用一个分类器加工作流即可，依然不必上Agent。
- 如果决策分支多到写不完，或者需要根据中间结果动态调整策略——这时Agent才有存在的意义。
Agent是“迫不得已的选择”，而非“最前沿的做法”。
二、确定性工作流 vs 自主Agent：如何取舍？
2.1 确定性工作流的优势
| 维度 | 确定性工作流 | 自主Agent |
|---|---|---|
| 可预测性 | 极高——相同输入，相同流程 | 低——相同输入，可能走不同路径 |
| 成本 | 可控——步骤固定，Token消耗可预估 | 不可控——Agent可能循环调用 |
| 调试难度 | 低——哪步出错一目了然 | 高——决策链路如同黑盒 |
| 延迟 | 低——步骤数固定 | 不确定——可能执行很多步 |
| 失败模式 | 显式——代码报错 | 隐式——Agent“自信地犯错” |
工作流的每一项优势，恰恰对应Agent的劣势。
2.2 何时必须使用Agent？
真正需要Agent的场景有一个共同特征：任务的执行路径在开始时无法预判。
| 场景 | 为什么需要Agent | 为什么工作流不行 |
|---|---|---|
| 代码调试 | 需根据报错信息动态决定检查哪个文件、修改哪行代码 | 无法预知所有可能的报错及修复路径 |
| 多轮信息收集 | 需根据用户已提供的信息决定下一步提问内容 | 用户输入千变万化，分支难以穷举 |
| 复杂研究 | 需根据搜索结果动态决定下一步搜索方向 | 信息检索路径是动态的 |
| 多工具协调 | 需根据中间结果选择不同工具组合 | 工具组合的排列数太多 |
注意：大多数你以为需要Agent的场景，其实用“分类器+工作流”就能解决。例如客服场景，看似需要“Agent自主决策”，实际上用户意图就那么几类。先用分类器判断意图，再走对应的固定工作流——比Agent更快、更便宜、更可靠。
三、好架构的五个设计原则
如果你确实需要Agent，如何设计才能避免翻车？
3.1 原则一：任务拆小，职责单一
一个Agent只干一件事。
反模式：
SuperAgent: 既查数据库、又调API、还写代码、还发邮件
→ 什么都能做 = 什么都做不好
正确模式：
Orchestrator（编排器）
→ DataAgent（只负责查数据）
→ CodeAgent（只负责写代码）
→ EmailAgent（只负责发邮件）
每个Agent职责单一、可独立评测
为什么要拆？两个原因：
第一，可评测。一个负责五件事的Agent，出错了难以定位问题。五个各做一件事的Agent，每个都可以单独建立评测集。
第二，可替换。DataAgent太慢？换一个更快的，其他组件不受影响。SuperAgent整体出问题？只能全部推倒重来。这就像组装电脑——使用标准接口的独立组件，坏了换一个就行；如果CPU和显卡焊在一块板上，坏一个全得扔。
3.2 原则二：工具边界窄而明确
工具的设计直接决定Agent调用的准确率。
| 差的工具设计 | 好的工具设计 |
|---|---|
| query(sql) — 可执行任意SQL | get_order(order_id) — 只能查询特定订单 |
| send_message(content) — 可发送任意内容 | send_order_update(order_id, status) — 只能发送订单状态更新 |
| 描述模糊：“处理数据” | 描述精确：“根据订单ID查询订单状态，返回JSON” |
| 无参数校验 | 有Schema校验：order_id必须为正整数 |
核心原则：一个工具只干一件事，描述精确到没有歧义，参数带有Schema校验。
为什么描述如此重要？因为Agent是根据工具描述来决定调用哪个工具的。描述模糊，Agent就容易选错。好比一家餐厅，菜单上写“好吃的东西”——客人无法选择；如果写“清蒸桂花鱼·约500g·蒸制15分钟·配姜丝酱油”——一目了然。
3.3 原则三：显式错误恢复
Agent失败是必然的，关键在于如何处理失败。
反模式——让Agent“自己想办法”：
Agent调用API失败 → Agent决定换一种方式试 → 又失败
→ Agent决定再换一种 → 循环8次 → 超时 → 用户等了2分钟看到空白页面
正确模式——显式错误处理：
Agent调用API失败
→ 捕获错误类型
→ 网络超时？→ 重试（最多3次，指数退避）
→ 参数错误？→ 修正参数后重试
→ 权限不足？→ 上报给编排器，走降级路径
→ 未知错误？→ 停止执行，返回错误信息，通知人工
失败必须被捕获、归类，然后走预设的恢复路径。不要让Agent在失败后“自由发挥”——它会越发挥越离谱。
3.4 原则四：人在回路（Human-in-the-Loop）
对于不可逆操作，强制人工确认。
| 操作类型 | 是否需要人工确认 | 原因 |
|---|---|---|
| 查询数据 | 不需要 | 可逆，无副作用 |
| 生成草稿 | 不需要 | 可丢弃 |
| 修改数据库 | 需要 | 可能造成数据损坏 |
| 发送邮件/消息 | 需要 | 发出去就收不回来 |
| 删除数据 | 需要 | 不可逆 |
| 付款/转账 | 必须 | 涉及资金安全 |
设计上的做法是在工作流中设置“检查点”（Checkpoint）——Agent执行到不可逆操作前，暂停执行，把计划展示给人类，等人类确认后再继续。用人话说：你让AI帮你开车可以，但过收费站的时候必须你自己刷卡。
3.5 原则五：可观测、可打断
Agent不能是黑盒。
| 维度 | 黑盒Agent | 可观测Agent |
|---|---|---|
| 执行过程 | 看不到中间步骤 | 每一步决策都有日志 |
| 思考过程 | 不知道为什么选这个工具 | 推理链路可追踪 |
| 异常发现 | 跑完才知道出了问题 | 实时监控，异常即告警 |
| 人工干预 | 只能杀进程 | 可在任意步骤暂停、修正、继续 |
关键设计：
- 每一步决策都要输出结构化日志：选了什么工具、为什么选、输入是什么、输出是什么
- 设置“保险丝”：最大步数限制、最大Token消耗限制、最大执行时间限制
- 支持“热干预”：人可以在Agent执行过程中修改指令或取消操作
这就好比无人机——自动飞行可以，但地面站必须能实时看到航线，随时能按“返航”按钮。没有这个能力的无人机，不叫自动化，叫失控。
四、一个实战案例：客服系统的编排选择
把上面的原则串起来，看一个客服系统如何从“全Agent”演化到“工作流+最小Agent”。
4.1 V1：全Agent方案（反模式）
用户消息 → SuperAgent（自主决策）
→ 自己判断意图
→ 自己选工具
→ 自己组织回答
→ 直接回复用户
问题：不可控、不可测、成本高、响应慢。
4.2 V2：工作流+最小Agent（正确方案）
用户消息 → 意图分类器（确定性，一次LLM调用）
├─ “查订单” → 提取订单号（确定性）→ 查数据库（代码）→ 格式化回复（确定性）
├─ “退货政策” → 直接返回固定文本（零LLM调用）
├─ “投诉” → 情绪分类（确定性）→ 生成安抚回复（确定性）→ 创建工单（代码）
└─ “复杂/未知问题” → Agent（自主决策，只在这里用）→ 人工审核 → 回复
对比：
| 指标 | V1 全Agent | V2 工作流+最小Agent |
|---|---|---|
| 平均延迟 | 8-15秒 | 1-3秒 |
| 平均成本/次 | $0.05-0.12 | $0.005-0.02 |
| 准确率 | 约78% | 约95% |
| 可调试性 | 极差 | 好 |
| Agent使用比例 | 100% | 约15%（仅复杂问题） |
85%的请求用确定性工作流处理，只有15%真正需要Agent。成本降低了一个数量级，准确率反而上升。这就是“克制”的力量。
五、常见的过度Agent化症状
对照自查，你的系统有没有这些问题：
| 症状 | 诊断 | 处方 |
|---|---|---|
| Agent经常“绕圈”——反复调用同一个工具 | 任务不需要动态决策 | 改成固定工作流 |
| Agent偶尔调用错误的工具 | 工具描述不够精确 | 重写工具描述+加Schema校验 |
| Agent输出不稳定——同一问题十次答八种 | 给了太多“自由度” | 缩小Agent的行动空间 |
| Token消耗忽高忽低 | Agent执行步数不可控 | 加最大步数限制 |
| 出了问题不知道在哪一步出错 | 缺乏可观测性 | 加结构化日志 |
| 用户偶尔收到荒谬的回复 | 无人工兜底 | 对高风险回复加人工审核 |
如果你中了3条以上——恭喜，你的系统过度Agent化了。治疗方案：把能写死的流程写死，只保留真正需要动态决策的部分给Agent。
六、设计检查清单
每次设计AI编排架构前，过一遍这个清单：
□ 1. 这个任务能用单次LLM调用解决吗？→ 能就别搞工作流
□ 2. 这个任务能用确定性工作流解决吗？ → 能就别上Agent
□ 3. 每个Agent的职责是否单一可评测？→ 不是就拆
□ 4. 每个工具的描述是否精确无歧义？ → 不是就改
□ 5. 参数是否有Schema校验？ → 没有就加
□ 6. 失败是否有显式恢复路径？→ 没有就补
□ 7. 不可逆操作是否有人工确认？→ 没有就加
□ 8. 中间过程是否可观测可打断？→ 不是就改
□ 9. 是否设置了保险丝（最大步数/Token）？→ 没有就加
□ 10. 每个组件是否有独立的评测集？ → 没有就建
全部打勾，才开始写代码。
写在最后
这篇文章的核心观点可能让很多人感到不适：
最好的Agent架构，是Agent用得最少的架构。
2026年的AI行业有一种奇怪的“Agent崇拜”——似乎不上Agent就不够先进，不让LLM自主决策就是在浪费AI的能力。但工程的本质从来不是“用最前沿的技术”，而是“用最合适的技术解决问题”。
确定性工作流不够酷？没关系，它快、它便宜、它可靠、它能调试。这四条加起来，比“酷”值钱一百倍。
Agent有它的价值——在真正需要动态决策的场景里，Agent是不可替代的。但那些场景，远比你想象的少。
克制，是架构师最被低估的美德。
知道什么时候用Agent是能力，知道什么时候不用Agent是智慧。把“能不能用”和“该不该用”分清楚——这是AI工程化从“炫技”走向“成熟”的标志。