停止构建AI Agent！这里有5个更简单的LLM工作流模式，能解决90%的问题
本文永久链接 – https://tonybai.com/2025/07/10/stop-building-ai-agents
大家好，我是Tony Bai。
如果你正在开发 AI 应用，你很可能听说过、尝试过，甚至正在挣扎于构建一个“AI Agent”。
我们都看过那些令人心潮澎湃的 Demo：一个 AI Agent 被赋予一个目标，然后它就能自主地规划、调用工具、浏览网页、编写代码，最终完成任务。于是，我们纷纷投身其中，搭建记忆系统、定义工具、编写角色背景……感觉就像在创造一个真正的数字生命，充满了力量和进步感。
但现实往往是残酷的。正如资深 AI 教育者 Hugo Bowne-Anderson 在他那篇引爆讨论的文章《Stop Building AI Agents》中描述的，他曾用 CrewAI 构建了一个“研究小组”：三个 Agent、五个工具，纸面上完美，实践中一塌糊涂。
- 研究员 Agent 忽略了 70% 的网页抓取工具。
- 摘要员 Agent 在处理长文档时完全忘记了使用引用工具。
- 协调员 Agent 在任务不明确时直接“撂挑子不干了”。
这是一个“美丽的计划，以壮观的方式分崩离析”。这个故事听起来熟悉吗？
Hugo 一针见血地指出：问题的根源，可能不是你的实现细节，而是你从一开始就选择去构建一个 Agent。
AI Agent 的真正“魔鬼”：失控的工作流
要理解为什么 Agent 如此脆弱，我们必须先弄清它的定义。一个 LLM 应用通常具备四个特性：
1. 记忆 (Memory): 让 LLM 记住过去的交互。
2. 信息检索 (Information Retrieval): 通过 RAG 等方式为 LLM 提供上下文。
3. 工具使用 (Tool Usage): 赋予 LLM 调用函数和 API 的能力。
4. 工作流控制 (Workflow Control): 让 LLM 的输出来决定下一步使用哪个工具以及何时使用。
这第四点，正是“Agent”的定义，也是问题的核心！
当我们构建一个 Agent 时，我们实际上是把系统的控制权交给了 LLM。我们希望它能像一个自主的决策者一样，动态地编排整个工作流程。
但这就像是让一个充满创造力、才华横溢但情绪不定的艺术家去担任整个交响乐团的指挥。他可能会即兴发挥出惊人的乐章，但更可能的是，他会忘记看乐谱，让整个演奏陷入混乱。
大多数 Agent 系统崩溃，不是因为功能太少，而是因为复杂度太高、控制权失控。
Hugo 用一张简单的决策图告诉我们，在绝大多数场景下，我们需要的根本不是 Agent。
那么，如果不是 Agent，我们应该构建什么？
你应该构建的 5 个 LLM 工作流模式
答案是：用更简单的、由你（开发者）的代码来控制流程的工作流模式。 下面这 5 个模式，源自 Anthropic 的研究，并由 Hugo 在实践中验证，足以解决 90% 的真实世界问题。
(1) 提示词链 (Prompt Chaining)
用例： 根据领英资料，撰写个性化的推广邮件。
这是一个典型的顺序任务。你先用一个 LLM 调用将非结构化的个人资料文本，转换为结构化的数据（姓名、公司、职位），然后再用第二个 LLM 调用，基于这些结构化数据和公司背景，生成一封定制邮件。
- 适用场景： 任务有明确的先后顺序。
- 失败模式： 链条中的任何一环失败，整个流程就会中断。
- 优点： 流程可预测，简单，易于调试。
(2) 并行化 (Parallelization)
用例： 从一份简历中，同时提取多个部分的信息。
当你想一次性处理多个独立的子任务时，并行化是最佳选择。你可以定义多个并行的任务，如提取工作经历、提取技能列表、提取教育背景，然后让它们同时运行，最后汇总结果。
- 适用场景： 多个独立任务可以并发执行以提高速度。
- 失败模式： 可能出现竞态条件或超时问题。
- 优点： 极大地提升数据抽取的效率。
(3) 路由 (Routing)
用例： 一个客户支持工具，根据用户问题类型分发到不同的处理流程。
路由模式就像一个智能交换机。你先用一个 LLM 或简单的逻辑来对输入进行分类（例如，这是“账单问题”还是“技术问题”），然后将请求“路由”到相应的专有处理函数或工作流中。控制权一旦交出，就不再收回。
- 适用场景： 不同的输入需要完全不同的处理逻辑。
- 失败模式： 边界情况可能无法匹配任何路由，需要有默认的“兜底”方案。
- 优点： 结构清晰，逻辑解耦。
(4) 编排器-工作者 (Orchestrator-Worker)
用例： 一个需要将任务动态分解成多步的邮件生成器。
这看起来像路由，但有一个关键区别：控制权始终在“编排器”手中。编排器（可以是 LLM 或你的代码）负责做决策和协调，而“工作者”（通常是具体的函数）负责执行。例如，编排器先调用 LLM 将目标公司分类为“科技”或“非科技”，然后选择一个专门的“科技邮件工作者”或“非科技邮件工作者”来撰写邮件，并管理整个流程的始终。
- 适用场景： 任务需要动态决策和受控的步骤执行。
- 失败模式： 编排器错误地分解或委托了子任务。
- 优点： 完美地将决策与执行分离，兼具灵活性和可控性。
(5) 评估器-优化器 (Evaluator-Optimizer)
用例： 优化一封营销邮件的语气和结构，以满足特定标准。
当你对输出质量有极高要求时，这个模式非常有用。一个“生成器”LLM 先生成初始内容，然后一个“评估器”LLM 对其进行打分。如果分数不达标，“评估器”会提供反馈，然后“生成器”根据反馈进行优化，如此循环，直到满足质量要求或达到重试上限。
- 适用场景： 输出质量比速度更重要。
- 失败模式： 可能陷入无限的优化循环。
- 优点： 能持续打磨，产出高质量的结果。
那么，什么时候才真正需要 Agent？
读到这里，你可能会问，Agent 是否就一无是处？并非如此。Hugo 指出，Agent 在一类特定场景中表现出色：当有一个敏锐的人类在环中（Human-in-the-Loop）时。
- 数据科学助手： Agent 探索性地写 SQL、生成图表，你来评估结果、修正逻辑。
- 创意写作伙伴： Agent 负责头脑风暴、提供结构，你来判断质量、引导方向。
- 代码重构助手： Agent 发现潜在模式、提出优化建议，你来审查、批准变更。
在这些场景中，Agent 是一个创造力的放大器，而非一个自主的工人。它适用于不稳定的、探索性的工作，而非需要稳定可靠的自动化流程。
小结：放弃对 Agent 的执念，回归简单
AI Agent 的概念被过度炒作和滥用。在大多数真实世界的应用中，我们并不需要一个拥有自主意识、能动态控制一切的复杂系统。
我们需要的，是更清晰、更简单、更可控的工作流结构。上述 5 种模式，为我们提供了强大的武器库。它们提醒我们软件工程的第一原则：从简单开始，逐步增加复杂性，并始终将控制权留在最可靠的地方——你自己的代码里。
所以，下一次当你准备构建下一个 LLM 应用时，请先停下来问自己：我真的需要一个 Agent 吗？还是一个简单的“提示词链”或“路由器”就足够了？
这个问题的答案，可能会为你节省下数周甚至数月的调试时间。
资料地址：https://decodingml.substack.com/p/stop-building-ai-agents
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
- 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
- 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
- 想打造生产级的Go服务，却在工程化实践中屡屡受挫？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论