第2章：什么时候该做 Agent，什么时候不该做
上一章讲了 Agent 是什么。这一章讲一个更实用的问题：你手上的任务，到底需不需要 Agent？
这个问题比听起来重要得多。Agent 的灵活性是有代价的——更多的 token 消耗、更高的延迟、更难预测的行为、更难调试的失败。如果一个确定性的 Workflow 就能解决问题，上 Agent 不是升级，是自找麻烦。
Anthropic 和 OpenAI 在各自的工程指南里，不约而同地给出了同一个建议：从最简单的方案开始。
2.1 Anthropic 的黄金法则：找到最简单的解决方案，只在必要时增加复杂度
核心直觉
不要一上来就造 Agent。先问自己：一个普通的 API 调用能不能解决？
原文怎么说的
Anthropic 在《Building Effective Agents》中开篇就写 [1]：
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.
这句话值得反复读。Anthropic 自己是做大模型的——卖模型的人告诉你"可能根本不需要用我们的高级功能"，这种建议的可信度通常比较高。
紧接着他们解释了为什么：
Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.
Agent 系统用延迟和成本换任务表现。这个 tradeoff 不是免费的，你需要想清楚值不值。
他们还观察到一个规律 [1]：
The most successful implementations weren't using complex frameworks or specialized libraries — instead, they were building with simple, composable patterns.
最成功的实现不是用复杂框架搭的，而是用简单、可组合的模式搭的。
为什么这个原则如此重要
因为在社区经验里，"过早引入 Agent"几乎是最常见的一类抱怨。
一位长期帮助团队落地 LLM 系统的工程师总结了一个反复出现的模式 [2]：
Everyone reaches for agents first, sets up memory systems, adds routing logic, creates tool definitions. It feels powerful until everything breaks.
Using an agent means handing control to the LLM, but unless your task is so dynamic that its flow can't be defined upfront, that kind of freedom usually hurts more than it helps.
每个人都先去搞 Agent——加记忆系统、加路由逻辑、加工具定义。看起来很强，直到全崩了。除非你的任务流程真的没法提前定义，否则把控制权交给 LLM 通常弊大于利。
在 DEV Community 上也有类似的吐槽 [3]：
Multi-agent architectures are seductive — one agent plans, one retrieves, one generates, one validates, they talk through a message bus. It looks amazing on a whiteboard but in production it's a nightmare to debug.
Teams adopt something like CrewAI on day one and then spend more time debugging the framework than their actual agent logic.
Multi-Agent 架构在白板上画起来很漂亮——一个规划、一个检索、一个生成、一个验证，通过消息总线通信。但到了生产环境就变成了调试噩梦。有些团队第一天就引入 CrewAI，结果花在调试框架上的时间比调试业务逻辑还多。
要注意，这两条都属于经验层材料，不是严格意义上的行业统计。它们的价值在于提醒你：很多团队踩过同一种坑，而不是证明"所有项目都会这样"。
工程权衡
这里的核心权衡是控制权 vs 灵活性：
| 维度 | 你掌控流程 | LLM 掌控流程 |
|---|---|---|
| 可预测性 | 高——每次走同一条路 | 低——每次可能不同 |
| 调试难度 | 低——看代码就知道发生了什么 | 高——需要追踪 LLM 的推理过程 |
| 适应性 | 低——新场景需要改代码 | 高——LLM 可以即兴应对 |
| 成本 | 低——通常只需要 1-2 次 LLM 调用 | 高——可能需要几十次调用 |
| 延迟 | 低——确定性的执行路径 | 高——循环次数不确定 |
只有当任务的适应性需求压过了可预测性和成本需求时，Agent 才值得考虑。
常见误区
误区："先用 Agent 搭个原型，之后再简化。" 实践中几乎不会发生。一旦用 Agent 搭了原型，系统的架构就会围绕"LLM 掌控流程"来设计——工具定义、状态管理、错误恢复都是 Agent 模式的。要回退到简单的 Workflow，往往意味着重写而不是简化。正确的路径是反过来：先用最简单的方案搭原型，遇到瓶颈了再往上加。
2.2 决策矩阵：从单次调用到自主 Agent
核心直觉
不是只有两个选项（Agent 或不 Agent）。中间有一个从简单到复杂的完整光谱，你需要找到刚好够用的那一层。
四个层级
Anthropic 在指南中描述了一个清晰的能力递进路径 [1]，我把它整理成四个层级：
层级 1：单次 LLM 调用（+ 检索 + few-shot 示例）
Anthropic 的原话 [1]：
For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough.
一次调用加上 RAG 检索和几个示例，就能解决大多数应用。不要小看这一层——很多看似复杂的任务，一个精心设计的 prompt 加上合适的上下文就够了。
适用场景：文本分类、情感分析、翻译、简单问答、格式转换、数据提取。
层级 2：链式调用
把任务拆成几个步骤，每步调用一次 LLM，前一步的输出作为后一步的输入。流程是固定的，代码决定调用顺序。
适用场景：先生成草稿再润色、先提取信息再验证格式、先分类再路由到不同处理逻辑。
对应 Anthropic 的 Prompt Chaining 和 Routing 模式。
层级 3：预定义编排
流程更复杂——有并行、有条件分支、有迭代。但核心特征不变：流程是开发者预先定义的，LLM 只负责每个节点的内容生成。
适用场景：复杂的文档处理流水线、多数据源聚合、需要多个 LLM 互相检查的质量保证流程。
对应 Anthropic 的 Parallelization、Orchestrator-Workers、Evaluator-Optimizer 模式。
层级 4：自主 Agent
LLM 自己决定下一步做什么、调用什么工具、循环多少次。开发者只定义可用的工具和约束条件。
Anthropic 的判断标准 [1]：
Agents can be used for open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path.
适用场景：开放式任务、步骤数不可预测、无法提前硬编码路径。
决策矩阵
怎么判断该用哪一层？看三个维度：
| 判断维度 | 用简单方案（层级 1-2） | 用复杂编排（层级 3） | 用 Agent（层级 4） |
|---|---|---|---|
| 流程确定性 | 步骤固定，能画出流程图 | 步骤基本固定，有少量条件分支 | 步骤不确定，取决于中间结果 |
| 成功标准 | 明确（格式正确、分类准确） | 明确但需要迭代（质量达标） | 模糊或开放（"帮我解决这个问题"） |
| 工具使用 | 不需要或固定的 1-2 个 | 固定的多个，调用顺序已知 | 多个，哪个该调用取决于 LLM 判断 |
适合 Agent 的场景
综合 Anthropic 和 OpenAI 的指南，Agent 最适合的场景有几个共同特征：
开放式任务：无法提前枚举所有可能的路径。比如"修复这个 bug"——你不知道需要读几个文件、改几处代码、跑几次测试。
需要模型驱动决策：每一步该做什么取决于上一步的结果，而且这个决策需要理解力，不能用 if-else 搞定。
有外部反馈机制：Agent 能知道自己做对了没有。测试通过、用户确认、系统返回成功——这类反馈让 Agent 可以自我纠正。
OpenAI 在《A Practical Guide to Building Agents》中总结了三个具体信号 [4]：
- 复杂决策：判断逻辑无法简化为简单的 if-else 规则（比如退款审批需要考虑多种上下文因素）
- 难以维护的规则系统：规则太多、变化太快，硬编码的规则引擎维护成本过高
- 非结构化数据交互：需要理解和处理文档、邮件、对话等自然语言内容
不适合 Agent 的场景
反过来，以下特征意味着你应该用更简单的方案：
固定流程：每次都走同样的步骤，不需要根据中间结果调整。用 Workflow。
可硬编码的路径：所有可能的分支都能提前想到并处理。用条件逻辑。
没有明确的成功标准：Agent 不知道什么时候该停止。这不是说 Agent 不适合，而是说你还没想清楚任务定义——先搞清楚成功标准，再决定用什么技术。
对延迟和成本极度敏感：Agent 往往意味着更多轮调用、更长链路和更高的不确定性。如果你的场景需要毫秒级响应，或者预算只允许非常低的单次调用成本，Agent 大概率不是答案。
一个对比：为什么 Coding Agent 成立，而"全能办公 Agent"不成立
Anthropic 的指南里特别提到，软件开发是 Agent 的理想场景 [1]，因为它同时满足了好几个条件：
- 代码方案可以通过自动化测试验证
- Agent 可以用测试结果作为反馈来迭代
- 问题空间虽然开放，但有边界（代码库、语言、框架都是确定的）
- 输出质量可以客观衡量
对比"帮我自动处理一切办公室工作"这种目标：没有自动化的验证机制，反馈模糊（什么叫"处理好了"？），边界无限大（邮件、日程、文档、审批、沟通……），质量标准主观。这就是为什么 Coding Agent（Claude Code、Cursor、Devin）已经在大量开发者的工作中产生了真实价值，而"全能办公 Agent"还停留在演示阶段。
HN 上有一个讨论帖 "What to build instead of AI agents"（2025 年 7 月）[5] 里有人说得很到位：通过测试套件来引导 Agent，本质上是一个强力的反馈机制——有了反馈循环，Agent 大部分时候都能跑通。这解释了为什么 Coding Agent 有效：它们有一个内建的评估函数。
2.3 如何选择高 ROI 用例
核心直觉
不是所有能用 Agent 的地方都应该用 Agent。你需要一个框架来评估哪些用例值得投入。
用例评分框架
我建议从三个维度评估一个潜在的 Agent 用例：
维度一：自动化收益（Automation Payoff）
这个任务现在消耗多少人力？自动化后能省多少？
- 高收益：每天/每周重复执行、每次耗时长、需要专业人员处理
- 低收益：偶尔执行、每次很快、任何人都能做
Klarna 的客服 Agent 是一个经典的高收益案例：它在上线第一个月就处理了 230 万次对话，相当于 700 名全职客服的工作量，解决时间从 11 分钟降到了 2 分钟以下，官方还把它描述为一个显著改善效率和利润的案例 [6]。
但这个案例也有后续。后来的外部报道提到，Klarna 管理层重新强调了人类客服体验的重要性，并承认如果过度按成本优化，服务质量会下滑 [7]。这一层信息不是 Klarna 那条官方喜报的一部分，所以更适合把它当作补充背景来理解：自动化收益高，不等于完全自动化就一定对。
维度二：任务复杂度（Task Complexity）
任务需要多少步？需要多少判断？涉及多少工具和数据源？
- 适合 Agent：多步骤、需要推理判断、涉及多个工具
- 不适合 Agent：单步、规则明确、一个 API 调用就搞定
维度三：容错空间（Error Tolerance）
Agent 做错了会怎样？代价有多大？能不能轻松回滚？
- 容错高：错了可以重来、有人工审核兜底、损失可控
- 容错低：错了不可逆、影响资金安全、直接面向客户无缓冲
把这三个维度组合成一个简单的评分：
用例价值 = 自动化收益 × 任务复杂度 × 容错空间| 用例 | 自动化收益 | 任务复杂度 | 容错空间 | 综合评估 |
|---|---|---|---|---|
| 代码 bug 修复 | 高（频繁、耗时） | 高（多步推理） | 高（有测试验证） | 优先做 |
| 客服分流和简单问答 | 高（量大、重复） | 中（分类 + 查询） | 中（有人工兜底） | 值得做 |
| 研究报告生成 | 中（每次耗时但频率不高） | 高（多源检索 + 综合） | 高（人工审阅） | 值得做 |
| 自动审批财务报销 | 中 | 中 | 低（涉及资金） | 谨慎，需要强 Guardrails |
| 自动发送营销邮件 | 中 | 低 | 低（发出去就收不回来） | 不建议全自动 |
成本和延迟：不要拍脑袋估
做 ROI 评估不能不看成本，但这里最容易掉进一个坑：把某个团队、某个框架、某个模型配置下的数字，当成通用规律。
更稳的结论其实没有那么花哨：
- 单次调用通常最便宜，也最容易控延迟
- 一旦进入多轮循环、反思、重试、工具调用，成本和延迟都会明显上升
- Agent 的真实账单往往不是被"模型单价"决定的，而是被调用轮次、上下文长度、失败重试率、工具链路长度共同决定
- 优化手段确实有效，比如 prompt caching、模型路由、减少无效上下文、限制最大循环次数，但优化后的 Agent 也未必比简单 Workflow 划算
所以这一节最重要的建议不是记某个倍数，而是记一个计算方法：
- 先估算单次任务平均会走多少轮
- 再估算每轮大概会消耗多少输入/输出 token
- 把工具调用、失败重试、超时和人工复核的成本一起算进去
- 最后拿总成本去对照自动化节省的人力、时延或转化收益
如果你连这四步都还没做，就谈不上真正的 ROI 评估。
常见误区
误区："先上线再算 ROI。" Agent 的成本结构和传统软件不同——它的运行成本（API 调用费用）可能远超开发成本。一个设计不当的 Agent 如果被大量用户触发，账单可能在几天内就失控。在上线前估算每次调用的 token 消耗和对应成本，是 Agent 工程的基本功。
2.4 OpenAI 的务实建议：从小处开始，逐步扩展
核心直觉
不要试图一步到位造一个全能 Agent。从一个最小的用例开始，用真实用户验证它有没有价值，然后再加功能。
OpenAI 的方法论
OpenAI 在《A Practical Guide to Building Agents》中给出了一个务实的构建路径 [4]：
第一步：识别合适的用例。 用前面提到的三个信号来判断——复杂决策、难维护的规则系统、非结构化数据交互。OpenAI 明确说了：
Before committing to building an agent, validate that your use case can meet these criteria clearly. Otherwise, a deterministic solution may suffice.
在投入建设之前，先验证你的用例是否真的满足这些标准。否则，一个确定性方案可能就够了。
第二步：从单 Agent 开始。 不要上来就搞 Multi-Agent。OpenAI 的建议是：
Begin with single-agent deployments; scale to multi-agent only as complexity demands.
这和 Anthropic 的观点完全一致。单 Agent + 几个工具 + 清晰的指令，能覆盖的场景比你想象的多。
第三步：逐步添加工具。 不要一开始就给 Agent 20 个工具。从最核心的 2-3 个工具开始，观察 Agent 的表现，发现瓶颈后再加。
第四步：每一步都评估。 加了新能力后，用评估数据验证是否真的提升了任务完成率，而不是凭感觉。
Google 的"无常"原则
Google 开发者博客在一篇 Agent 构建经验总结中提出了一个很有意思的原则 [8]：
Architect with a mindset of impermanence.
用"无常"的心态做架构。理由是：
The complex agent harness you write today might be replaced in a few months — or even weeks — by advancements in state-of-the-art models.
你今天写的复杂 Agent 框架，可能几个月甚至几周后就被模型能力的进步淘汰了。他们发现，一个原本需要多步 Agent 方案才能完成的虚拟试穿体验，现在用一个 prompt 就能搞定。
这个原则的工程含义是：
- 不要在 Agent 编排逻辑上做过重的投入——模型变强后，很多编排可能变得不必要
- 把精力花在工具质量和评估体系上——这些不管模型怎么变都有价值
- 保持架构的可拆解性——你应该能轻松把一个 Agent 降级成 Workflow，或者把一个 Multi-Agent 系统简化成单 Agent
12-Factor Agent 的观察
一项基于 100 多位 Agent 构建者访谈的总结指出了一个很朴素的现实 [9]：
Most production agents aren't that agentic at all — they're mostly deterministic software with small, carefully controlled LLM interactions.
大多数生产环境里的"Agent"其实没那么 agentic——它们主要是确定性软件，加上少量精心控制的 LLM 交互。
这不是在否定 Agent 的价值，而是在指出一个经常被忽略的事实：在生产环境里真正稳定运行的系统，通常不是那种"LLM 完全掌控一切"的纯 Agent，而是大量确定性逻辑 + 关键节点由 LLM 决策的混合体。
METR 的实验数据
METR（一个 AI 安全研究组织）在 2025 年 7 月发布了一个引人注目的随机对照实验结果 [10]：
16 名经验丰富的开源开发者，246 个任务。开发者预测 AI 工具会让他们快 24%。实际结果：慢了 19%。METR 在后续更新里给出的表述更精确：这个 slowdown 的置信区间大约在 +2% 到 +39% 之间；这里的正值表示"更慢"，不是更快 [11]。
原因是：开发者确实花了更少的时间写代码和查文档，但花了更多时间写 prompt、审查 AI 输出、等待响应。超过一半的 AI 生成建议最终被弃用。
这个故事也有后续：METR 在 2026 年 2 月的更新里没有简单宣布"现在已经转正了"，而是明确说他们在调整实验设计 [11]。这恰恰说明，"AI 到底能让知识工作快多少"这件事，本身还在持续校准中。当前最稳的态度不是迷信单一 uplift 数字，而是承认：不同任务、不同工具、不同使用方式，结果差异会非常大。
一个决策流程图
综合以上所有信息，我建议用这个流程来做决策：
面试高频题
题目：你的上一个项目为什么选择了 Agent 而不是简单的 Workflow？如果重来你会怎么决策？
好的回答思路：
这道题考的不是你选了什么，而是你怎么做决策的。面试官想看到：
你考虑过更简单的方案。 不要上来就说"我们决定用 Agent"。先说清楚任务是什么，为什么简单方案不够用——步骤不确定？需要动态工具选择？需要根据中间结果调整策略？
你清楚 Agent 的代价。 提到成本、延迟、调试难度、不可预测性。说明你不是为了用新技术而用新技术。
你有评估方法。 你怎么知道 Agent 比 Workflow 效果好？用了什么指标？做了对比实验还是只凭直觉？
一个好的回答结构：
我们的任务是 [具体描述]。一开始我们试过用固定流程的 Workflow——[描述 Workflow 方案]，但发现 [具体问题：比如新类型的输入走不通、需要动态调整步骤数、中间结果影响后续路径]。于是我们改用了 Agent 架构，让 LLM 根据中间结果决定下一步。
Agent 方案确实解决了灵活性问题，但代价是 [成本增加了 X 倍 / 延迟从 Y 增加到 Z / 偶尔出现不可预测的行为]。我们通过 [优化手段：model routing、prompt caching、设置最大循环次数] 来控制成本。
如果重来，我可能会 [具体改进：比如先用 Orchestrator-Workers 模式验证核心路径，确认确实需要动态决策后再升级到 Agent；或者只在某个子任务上用 Agent，其余保持确定性 Workflow]。
加分点：
- 引用 Anthropic 的建议：从最简单的方案开始，只在必要时增加复杂度
- 提到 Google 的"无常"原则：Agent 架构应该可以随时降级
- 提到 12-Factor Agent 的观察：生产环境里最稳定的"Agent"通常是大量确定性逻辑 + 少量 LLM 决策的混合体
- 承认自己踩过的坑比只给"正确答案"更有说服力
参考资料
[1] Erik Schluntz, Barry Zhang. Building Effective Agents. Anthropic, 2024-12. https://www.anthropic.com/engineering/building-effective-agents
[2] Decoding AI. Stop Building AI Agents: Use Smarter LLM Workflows. https://www.decodingai.com/p/stop-building-ai-agents
[3] DEV Community. Things You're Overengineering in Your AI Agent. https://dev.to/serhiip/things-youre-overengineering-in-your-ai-agent-the-llm-already-handles-them-2lop
[4] OpenAI. A Practical Guide to Building Agents. 2025-04-17. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
[5] Hacker News. What to build instead of AI agents. 2025-07. https://news.ycombinator.com/item?id=44450160
[6] Klarna. Klarna AI assistant handles two-thirds of customer service chats in its first month. 2024. https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/
[7] Bloomberg. Klarna Turns From AI to Real Person Customer Service. 2025-05-08. https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service
[8] Google Developers Blog. 5 Developer Tips from the Agent Bake-Off. 2026-04. https://developers.googleblog.com/build-better-ai-agents-5-developer-tips-from-the-agent-bake-off/
[9] learn-agentic-ai.com. 12-Factor Agents: Building Reliable LLM Applications. https://www.learn-agentic-ai.com/en/blog/12-factor-agents-building-reliable-llm-applications
[10] METR. Early 2025 AI Experienced OS Dev Study. 2025-07. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[11] METR. We are Changing our Developer Productivity Experiment Design. 2026-02-24. https://metr.org/blog/2026-02-24-uplift-update/