能不用Agent就不用：AI编排架构里最反直觉的设计原则

2026年最流行的技术幻觉：只要上了Agent，问题就能自己解决。 事实是——Agent用得越多，你失控得越快。最好的Agent架构，恰恰是Agent用得最少的那种。

先讲一个真实的故事。

某团队做了一个客服Agent，设计很"先进"：用户问题进来，Agent自主决定要不要查订单、要不要查知识库、要不要转人工。完全自主，不设限制。

上线第一天，Agent给一个问"退货政策"的用户查了8次数据库、调了3次知识库、最后返回了一段包含SQL报错信息的回答。

用时47秒，消耗Token约$0.12，用户体验评分1星。

而如果用一个简单的if-else判断"退货政策"→直接返回固定文本？用时0.3秒，成本$0，回答完美。

这就是过度Agent化的代价：把一个确定性问题交给了概率性系统去"自由发挥"。

一、先搞清楚一件事：什么是Agent，什么不是

这个行业最大的混乱之一，就是所有东西都被叫Agent。

1.1 三种东西，三个名字

关键区别在第三列——谁来决定下一步做什么？

• 如果是你的代码决定：那就是工作流，不管里面调了多少次LLM
• 如果是LLM自己决定：那才是Agent

用人话说：工作流是GPS导航——路线预设好了，照着走就行；Agent是自动驾驶——车自己决定往哪开。你的场景真的需要自动驾驶吗？大多数时候，导航就够了。

1.2 一个灵魂拷问

在你决定用Agent之前，问自己一个问题：

这个任务的决策路径，能用if-else写出来吗？

如果能——用工作流。别上Agent。

如果不能——再问第二个问题：决策分支有多少？ 如果就3-5个，用一个分类器+工作流。还是别上Agent。

如果决策分支多到写不完、或者需要根据中间结果动态调整策略——好，这时候Agent才有存在的意义。

Agent是"没办法的办法"，不是"最先进的做法"。

二、确定性工作流 vs 自主Agent：该选哪个？

2.1 确定性工作流的优势

工作流的每一个优势，都是Agent的一个劣势。

2.2 什么时候必须用Agent？

真正需要Agent的场景有一个共同特征：任务的执行路径在开始时无法确定。

注意：大多数你以为需要Agent的场景，其实用"分类器+工作流"就能解决。

比如客服场景，看起来需要"Agent自主决策"，实际上用户意图就那么几类。先用一个分类器判断意图，再走对应的固定工作流——比Agent更快、更便宜、更可靠。

三、好架构的五个设计原则

如果你确实需要Agent，怎么设计才不会翻车？

3.1 原则一：任务拆小，职责单一

一个Agent只干一件事。

反模式：

1  SuperAgent: 既查数据库、又调API、还写代码、还发邮件
2  → 什么都能做 = 什么都做不好

正确模式：

1  Orchestrator（编排器）
2    → DataAgent（只负责查数据）
3    → CodeAgent（只负责写代码）
4    → EmailAgent（只负责发邮件）
5  每个Agent职责单一、可独立评测

为什么要拆？两个原因：

第一，可评测。 一个做五件事的Agent，出错了你不知道是哪件事出了问题。五个各做一件事的Agent，每个都可以单独建评测集。

第二，可替换。 DataAgent太慢？换一个更快的，其他不受影响。SuperAgent太慢？整个推倒重来。

这就好比组装电脑——用标准接口的独立组件，坏了换一个就行；如果你把CPU和显卡焊在一块板上，坏一个全得扔。

3.2 原则二：工具边界窄而明确

工具设计直接决定Agent的调用准确率。

核心原则：一个工具只干一件事，描述精确到没有歧义，参数有Schema校验。

为什么描述这么重要？因为Agent是根据工具描述来决定调用哪个工具的。描述模糊，Agent就容易选错。

这就好比你开了一家餐厅，菜单上写"好吃的东西"——客人不知道点什么。你写"清蒸桂花鱼·约500g·蒸制15分钟·配姜丝酱油"——一目了然。

3.3 原则三：显式错误恢复

Agent失败是必然的。关键是怎么处理失败。

反模式——让Agent"自己想办法"：

1  Agent调用API失败 → Agent决定换一种方式试 → 又失败
2  → Agent决定换另一种 → 循环8次 → 超时 → 用户等了2分钟看到一个空白页面

正确模式——显式错误处理：

1  Agent调用API失败
2    → 捕获错误类型
3    → 网络超时？→ 重试（最多3次，指数退避）
4    → 参数错误？→ 修正参数后重试
5    → 权限不足？→ 上报给编排器，走降级路径
6    → 未知错误？→ 停止执行，返回错误信息，通知人工

失败必须被捕获、归类、然后走预设的恢复路径。不要让Agent在失败后"自由发挥"——它会越发挥越离谱。

3.4 原则四：人在回路（Human-in-the-Loop）

对不可逆操作，强制人工确认。

设计上的做法是在工作流中设置"检查点"（Checkpoint）——Agent执行到不可逆操作前，暂停执行，把计划展示给人类，等人类确认后再继续。

用人话说：你让AI帮你开车可以，但过收费站的时候必须你自己刷卡。

3.5 原则五：可观测、可打断

Agent不能是黑盒。

关键设计：

• 每一步决策都要输出结构化日志：选了什么工具、为什么选、输入是什么、输出是什么
• 设置"保险丝"：最大步数限制、最大Token消耗限制、最大执行时间限制
• 支持"热干预"：人可以在Agent执行过程中修改指令或取消操作

这就好比无人机——自动飞可以，但地面站必须能实时看到航线，随时能按"返航"按钮。没有这个能力的无人机，不叫自动化，叫失控。

四、一个实战案例：客服系统的编排选择

把上面的原则串起来，看一个客服系统怎么从"全Agent"演化到"工作流+最小Agent"。

4.1 V1：全Agent方案（反模式）

1  用户消息 → SuperAgent（自主决策）
2    → 自己判断意图
3    → 自己选工具
4    → 自己组织回答
5    → 直接回复用户

问题：不可控、不可测、成本高、慢。

4.2 V2：工作流+最小Agent（正确方案）

1  用户消息 → 意图分类器（确定性，一次LLM调用）
2    ├─ "查订单" → 提取订单号（确定性）→ 查数据库（代码）→ 格式化回复（确定性）
3    ├─ "退货政策" → 直接返回固定文本（零LLM调用）
4    ├─ "投诉" → 情绪分类（确定性）→ 生成安抚回复（确定性）→ 创建工单（代码）
5    └─ "复杂/未知问题" → Agent（自主决策，只在这里用）→ 人工审核 → 回复

对比：

85%的请求用确定性工作流处理，只有15%真正需要Agent。成本降了一个数量级，准确率反而上升了。

这就是"克制"的力量。

五、常见的过度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工程化从"炫技"走向"成熟"的标志。

— 完 —