最近 AI 圈子里 Agent 这个词儿快被喊烂了。仿佛只要给 LLM 套个壳，让它自己在那“思考、行动、观察”，所有复杂的业务逻辑就能自动跑通。

但是：现在大部分所谓的 Agent 项目，其实都是在用一种极其低效且不可控的方式，去模拟一个本该用三行 if-else 就能解决的逻辑。

今天不谈概念，只谈工程边界。

---

一、 别再把 Workflow 和 Agent 混为一谈

很多人分不清这两者的区别，其实本质就看一点：控制权在谁手里？

• Workflow（工作流）： 路径是开发者定死的。就像坐地铁，哪站停、哪站转乘，早就写在运行图里了。虽然 LLM 会在某个站点处理数据，但它没权利决定下一站去哪。
• Agent（智能体）： 开发者只给终点和工具。这就像打出租车，你告诉司机去机场，中间是走高架还是绕小路，由司机（LLM）根据路况实时决定。

其核心公式通常被定义为：

如果你能画出清晰的流程图，那就闭着眼睛选 Workflow。 强行在确定性的业务里引入 Agent，除了增加 Token 消耗和报错概率，没有任何收益。

---

二、 核心误区：为什么多 Agent 多段 Prompt？

这是很多开发者最容易踩的坑。他们觉得：我先加载一段 Prompt 让 LLM 当“翻译”，再换一段 Prompt 让它当“校对”，这不就是两个 Agent 在协作吗？

不，这只是“多段式对话”，本质还是被动触发。

真正的“多 Agent 架构”和“换个 Prompt 加载”有三个本质区别：

1. 状态机 vs 文本流： 多 Prompt 只是在传递文本；而多 Agent 拥有独立的状态管理。每个 Agent 有自己的短期记忆、工具调用记录和目标达成度评估。
2. 动态接力（Dynamic Handoff）： 在多 Prompt 模式下，A 完了必须是 B。但在多 Agent 架构中，Agent A 可以根据执行结果决定：是交给 Agent B 协作，还是打回给 Agent C 重做，甚至直接去调用外部 API 查资料。
3. 运行循环（Loop）： Prompt 只是静态指令，Agent 是**“指令 + 运行循环”**。它会在环境中观察工具返回的结果，根据结果自我修正。这种“自适应”能力，是单纯切换 Prompt 做不到的。

一句话总结：Prompt 只是“脚本”，而 Agent 是“带了脑子和记忆的演员”。

---

三、 为什么“一个超级 Agent”是反模式？

在软件工程中，我们讨厌“万能类（God Class）”。在 AI 领域，超级 Agent 就是灾难。

当你试图让一个 Agent 解决所有问题时，你会面临：

• 上下文“中毒”： 随着对话轮次增加，无用信息会干扰判断，幻觉率呈指数级上升。
• 推理漂移： 就像一个人想得越多越容易跑偏，Agent 极易陷入逻辑死循环。
• 调试地狱： 当它输出错误结果时，你根本无法定位是“规划”阶段出了错，还是“执行”工具时出了错。

---

四、 什么时候我坚决不用 Agent？

这是我总结的**“拒用清单”**，只要踩中一条，请立刻回归到传统脚本或 Workflow。

1. 路径高度确定： 只要业务逻辑是“A -> B -> C”，坚决不用 Agent。
2. 对延迟敏感： Agent 的多轮推理非常耗时。如果用户需要毫秒级反馈，Agent 会让你慢得像在上个世纪上网。
3. 容错率为零： 财务结算、权限控制。这种场景不需要“创造力”，只需要严丝合缝的代码。
4. 成本敏感型： 即使 Token 在降价，但用 Agent 跑大规模批处理依然是在烧钱。

---

五、 实战选型：我该怎么组合？

为了方便对号入座，我总结了三个典型场景：

1. 纯 Workflow —— 别给确定性找麻烦

• 例子： 自动处理员工报销单。
• 逻辑： 提取金额 -> 核对政策 -> 检查预算 -> 录入系统。
• 理由： 每一步逻辑都是死的。你不需要 AI 帮你“思考”报销是否合理，你只需要它精准提取。用 Agent 只会增加它“自作聪明”改动数据的风险。

2. 纯 Agent —— 处理“未知的未知”

• 例子： 深度竞品调研。
• 逻辑： 给你一个公司名，去网上搜集它的定价、负面新闻、技术架构。
• 理由： 你无法预知会搜到什么。搜到一半发现公司改名了，Agent 需要自己决定“去搜新名字”。这种路径依赖于结果的任务，是 Agent 的本命区。

3. 混合模式（Workflow + Agent 节点）—— 工业界的主流

• 例子： 智能技术支持（客服）。

• 架构：

• Workflow（骨架）： 用户输入 -> 意图识别 -> 检查保修期（固定 API）。

• Agent（动态节点）： 如果前几步搞不定，且用户上传了报错日志，此时把控制权交给一个“日志分析 Agent”，由它动态决定去查哪份文档或生成修复脚本。

• 理由： 既保证了常规任务的稳和快，又保留了解决疑难杂症的灵活性。

---

写在最后

现在的 AI 开发，难的不是让它“动起来”，而是让它“停在该停的地方”。

好的工程师应该像个吝啬鬼，尽可能压减 Agent 的自主权。 在该死板的地方坚如磐石，在该灵活的地方灵光一现。