随着学习的深入，我越发觉得技术的“不值钱”，在技术爆炸的时代，知道“为什么要用agent实现功能”远比“怎么实现一个agent功能”更有价值。所以我不得不停下来重新审视自己的设计和认知，在读了两篇agent领域的“圣经”（Anthropic的《Building effective agents》和OpenAI的《A practical guide to building agents》）后，简单记录下自己的心得。
在开始任何一个Agent项目之前，有一个问题值得先想清楚：我的场景真的需要Agent吗？
这不是一个哲学问题，而是一个工程决策。Anthropic在《Building effective agents》中开篇就给出了一个非常务实的建议：“找到尽可能最简单的解决方案，仅在必要时才增加复杂度”。OpenAI的《A practical guide to building agents》也表达了类似的立场：在决定构建Agent之前，先验证你的用例是否明确符合某些标准，否则确定性方案可能就足够了。
那么，什么情况下“确定性方案不够”，什么情况下“Agent是更好的选择”？答案藏在两个概念的本质区别里。
Workflow vs Agent：本质区别在哪里？
Anthropic给出了一个非常清晰的定义：
Workflow是通过预定义的代码路径来编排LLM和工具的系统。而Agent是LLM动态地指导自己的流程和工具使用，保持对如何完成任务的控制权。
OpenAI的定义同样直白：
Workflow是为了达成用户目标而必须执行的一系列步骤。而Agent是能够以高度独立性代表用户执行同样工作流的系统。
用一句话概括：Workflow是“铺好轨道的火车”，Agent是“自己认路的司机”。
在Workflow中，每一步做什么、调用什么工具、如何处理结果，都是开发者事先写死的。LLM只是在每个节点上执行一个具体的子任务，比如“总结这段文本”或“判断这个分类”。而在Agent中，LLM拥有对流程的控制权——它自己决定下一步做什么、用什么工具、何时停止。
什么时候该用Workflow？
Anthropic明确指出，Workflow的适用场景是任务明确、步骤可预测的情况。
具体来说，以下几种模式非常适合用Workflow实现：
1.并行化：将同一个任务拆分成多个独立的子任务，让多个LLM同时处理。比如同时用多个prompt审查代码漏洞，或者评估内容是否违规。每个子任务之间没有依赖关系，可以并行执行。
2.路由：根据输入内容将任务路由到不同的后续流程。比如客户服务场景中，根据用户的问题类型（退货、咨询、投诉）走不同的处理路径。
3.Orchestrator-Workers：由一个中央LLM动态分解任务，分发给多个Worker LLM执行，最后汇总结果。适用场景包括需要对多个文件做复杂修改的编码任务，或需要从多个来源搜集信息的搜索任务。
4.Evaluator-Optimizer：一个LLM生成答案，另一个LLM进行评估和反馈，形成迭代优化循环。适用于文学翻译、复杂搜索等需要多轮打磨的任务。
这些场景的共同点是：虽然可能涉及多个LLM调用，但整体的流程结构是预先定义好的**。Orchestrator虽然会“动态”决定分配什么子任务，但它本身的职责和位置是固定的。
什么时候该用Agent？
Agent的用武之地，恰恰是Workflow力不从心的地方。
Anthropic给出的判断标准非常精炼：
Agent适用于开放式问题——那些难以或不可能预测所需步骤数量，且无法硬编码固定路径的场景。
OpenAI的表述异曲同工：
Agent特别适合那些传统确定性方法和基于规则的方法无法奏效的工作流。
1. 复杂决策
工作流涉及细微的判断、大量的例外情况或高度依赖上下文的决策。比如客服场景中的退款审批——要不要退、退多少、需不需要人工介入，这些决策没有固定的“如果-那么”规则可以覆盖。
2. 难以维护的规则系统
系统已经因为规则过于庞杂而变得臃肿不堪，任何修改都可能导致意料之外的连锁反应。比如供应商安全审查，涉及的判断维度可能多达数十项，且不断变化——用规则引擎维护会是一场噩梦。
3. 重度依赖非结构化数据
场景涉及自然语言理解、从文档中提取语义、或与用户进行对话式交互。比如处理房屋保险理赔，需要理解事故描述、评估损失、对照保单条款——这些都不是结构化数据能简单承载的。
Anthropic还给出了一个更实操的判断维度：
Agent可以处理复杂的任务，但它们的实现通常很直接——本质上就是LLM在循环中根据环境反馈使用工具。关键在于，你必须对LLM的决策有一定程度的信任，并且Agent的自主性意味着更高的成本和潜在的复合错误风险。
总结来说
| 维度 | 用 Workflow | 用 Agent |
| 步骤是否可预测 | 是，路径清晰 | 否，开放式 |
| 是否需要硬编码 | 可以，且应该 | 不能 |
| 决策复杂度 | 低到中，规则明确 | 高，需要推理和判断 |
| 对LLM信任度要求 | 低，LLM只做局部任务 | 高，LLM掌控全局 |
| 成本与延迟 | 可控、可预测 | 较高、不确定 |
| 适用场景示例 | 代码审查、内容审核、翻译优化 | 自主编码、复杂搜索、客服决策 |
OpenAI在指南中还给出了一个非常有价值的实践经验：
客户通常在“增量式方法”上取得更大的成功——先最大化单个Agent的能力，只有在单Agent无法满足需求时，才考虑拆分为多Agent系统。
这意味着，即使你判断自己的场景需要Agent，也不要一上来就构建复杂的多Agent架构。从一个简单的单Agent开始，给它逐步增加工具，保持复杂度可控。只有当单Agent的prompt变得过于臃肿、工具选择频繁出错时，再考虑拆分为多个专业Agent。
Anthropic也给出了类似的提醒：很多框架会诱使你增加不必要的复杂度，而一个更简单的方案往往就足够了。建议开发者从直接使用LLM API开始，很多模式用几行代码就能实现。
回到最初的问题
所以，“我的场景为什么需要Agent，而不是普通Workflow？”
1. 如果你的任务步骤可预测、路径可硬编码——用Workflow，更便宜、更可靠。
2. 如果你的任务是开放式的、步骤不确定、需要动态决策——用Agent，它能做到Workflow做不到的事。
3. 无论选哪个，从最简单的方案开始，只在必要时增加复杂度。
这是一个关于工程判断力的考验，正如Anthropic所说，最成功的实现往往不是用了最复杂的框架，而是用了简单、可组合的模式。
---
参考文献：
Anthropic, "Building effective agents" (2024)
OpenAI, "A practical guide to building agents" (2024)
