学习笔记：从简单到复杂—Anthropic 团队眼中的 AI Agent 进化之路

agent 技术发展这么快，到底该怎么落地？有人投入大量精力搭建复杂的多 agent 系统，结果发现简单的提示工程就能解决问题；也有人在纠结要不要上各种框架，却忽略了最基础的架构设计。

这让我想起了 Anthropic 在 2025 年 10 月发布的那个 YouTube 视频——《Building more effective AI agents》。在这个不到 20 分钟的对话中，Alex Albert 和 Erik Schluntz 分享了过去半年他们在 agent 领域的核心发现。这些发现不仅源于他们自己的实践，更来自与数十个行业客户的深度合作。

看完这个视频后最直观的感受：最成功的 agent 实现，往往不是那些使用复杂框架或专门库的系统，而是基于简单、可组合模式构建的方案。

第一章 什么是 Agent，什么又是 Workflow

在我们深入讨论之前，需要先理清一个经常被混淆的概念。在 Anthropic 的实践中，他们将所有这些变体统称为"agentic systems"（代理系统），但在架构上做了一个重要的区分：workflows（工作流）和 agents（代理）。

Workflows 是通过预定义的代码路径编排 LLM 和工具的系统。想象一下传统的业务流程，每个步骤都清晰明了，系统按照既定的规则执行。而 Agents 则是 LLM 动态指导自身流程和工具使用的系统，它们保持着对如何完成任务的控制权。

这个区分在实践中至关重要。我见过太多人把简单的问题复杂化，明明用 workflow 就能很好解决的任务，非要上完整的 agent 架构。结果就是增加了延迟和成本，却没有带来明显的性能提升。

第二章 简单性原则：不要过度设计

Anthropic 团队反复强调的一个核心原则是：找到尽可能简单的解决方案，只在必要时才增加复杂性。这听起来像是老生常谈，但在 agent 领域尤为重要。

为什么？因为 agentic systems 通常会以延迟和成本为代价，换取更好的任务性能。你需要仔细权衡这种权衡何时才有意义。

当我们确实需要更多复杂性时，workflows 为明确定义的任务提供了可预测性和一致性，而 agents 在需要灵活性和大规模模型驱动的决策时是更好的选择。但对于许多应用来说，优化单个 LLM 调用，配合检索和上下文示例，通常就足够了。

让我分享一个真实案例。有家公司的技术团队最初设计了一个复杂的多 agent 系统来处理客户咨询，动用了上百个子 agent。但当他们把系统拆解后发现，核心的 80% 问题实际上可以通过一个简单的 routing workflow 解决——把不同类型的客户查询分类，然后路由到专门的处理流程。最终他们简化了架构，不仅降低了 60% 的成本，响应速度还提升了 3 倍。

第三章 框架：双刃剑要谨慎使用

现在市面上有各种让 agentic systems 更容易实现的框架：Claude Agent SDK、AWS 的 Strands Agents SDK、Rivet、Vellum 等等。这些框架通过简化调用 LLM、定义和解析工具、链接调用等标准低级任务，让快速起步变得容易。

但这里有个陷阱：它们往往创建了额外的抽象层，可能会掩盖底层的提示和响应，使调试变得更困难。更危险的是，它们可能诱使你在简单设置就足够的情况下增加复杂性。

Anthropic 的建议很直接：开发者应该从直接使用 LLM API 开始。许多模式可以用几行代码实现。如果你确实使用框架，要确保你理解底层的代码。对底层代码的错误假设是客户错误的常见来源。

我印象深刻的是 Erik Schluntz 提到的一个例子。有个团队花了几周时间调试一个基于复杂框架的 agent 系统，最后发现问题是框架的抽象层隐藏了 LLM 的实际输出，他们无法及时察觉模型在某个环节产生了幻觉。当他们回到基础，直接使用 API 并仔细检查每个调用的输入输出后，很快就找到了问题所在。

第四章 构建模块：从基础到进阶

让我们来看看 Anthropic 团队在实践中总结出的常见模式。从基础构建块——增强型 LLM 开始，逐步增加复杂性，从简单的组合工作流到自主 agents。

4.1 增强型 LLM：所有的基础

agentic systems 的基本构建块是 LLM 增强检索、工具和记忆等能力。Anthropic 目前的模型可以主动使用这些能力——生成自己的搜索查询、选择合适的工具、确定要保留哪些信息。

这里的关键是：针对你的特定用例定制这些能力，并确保它们为你的 LLM 提供简单、文档良好的接口。Anthropic 最近发布的 Model Context Protocol（MCP）就是一个很好的例子，它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

4.2 Prompt Chaining：分解的力量

提示链将任务分解为一系列步骤，每个 LLM 调用处理前一个的输出。你可以在任何中间步骤添加程序化检查（称为"gate"），以确保过程仍然在轨道上。

这个工作流程在任务可以轻松清晰地分解为固定子任务的情况下最为理想。主要目标是通过让每个 LLM 调用成为一个更容易的任务，来用延迟换取更高的准确性。

举个例子，生成营销文案然后翻译成另一种语言，或者先写文档大纲、检查大纲是否符合特定标准，然后基于大纲编写文档。这些都是 prompt chaining 大显身手的场景。

4.3 Routing：专业化的价值

Routing 对输入进行分类并将其引导到专门的后续任务。这个工作流允许关注点分离，构建更专门的提示。没有这个工作流，优化一种类型的输入可能会损害其他类型的输入的性能。

Routing 在复杂任务中效果很好，这些任务有明显的类别，最好分开处理，并且分类可以通过 LLM 或更传统的分类模型/算法准确处理。

客户服务查询是一个典型应用场景。一般问题、退款请求、技术支持——这些不同类型的查询可以被引导到不同的下游流程、提示和工具。另一个实用案例是成本优化：将简单/常见问题路由到更小、成本效率高的模型如 Claude Haiku 4.5，将困难/不寻常的问题路由到更强大的模型如 Claude Sonnet 4.5。

4.4 Parallelization：速度和质量的平衡

LLM 有时可以同时在任务上工作，并以编程方式聚合它们的输出。这个工作流体现在两个关键变体中：sectioning（将任务分解为并行运行的独立子任务）和 voting（多次运行同一任务以获得不同的输出）。

并行化在分割的子任务可以并行化以提高速度，或者需要多个视角或尝试以获得更高置信度结果时有效。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的 LLM 调用处理时，LLM 通常表现更好，允许对每个特定方面进行专注关注。

sectioning 的一个实际应用是实现护栏，一个模型实例处理用户查询，另一个筛选不当内容或请求的查询。这倾向于比让同一个 LLM 调用同时处理护栏和核心响应表现更好。而在 voting 方面，审查代码漏洞时，几个不同的提示审查代码，如果发现问题就标记出来，这种多方验证的方式大大提高了检测的准确性。

4.5 Orchestrator-Workers：动态任务分配

在 orchestrator-workers 工作流中，中央 LLM 动态分解任务，将其委托给 worker LLMs，并综合它们的结果。

这个工作流适用于复杂任务，你无法预测所需的子任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然拓扑相似，但与并行化的关键区别在于它的灵活性——子任务不是预定义的，而是由 orchestrator 根据特定输入确定的。

编码产品就是 orchestrator-workers 的典型应用场景。每次对多个文件进行复杂更改时，中央 orchestrator 可以分析任务描述，动态决定需要修改哪些文件以及如何修改，然后将不同的文件分配给不同的 workers 处理，最后整合所有更改。

4.6 Evaluator-Optimizer：迭代改进的艺术

在 evaluator-optimizer 工作流中，一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。

当我们有明确的评估标准，并且迭代细化提供可衡量的价值时，这个工作流特别有效。适合的两个迹象是：首先，当人类表达他们的反馈时，LLM 响应可以明显改善；其次，LLM 可以提供这种反馈。这类似于人类作家在制作精炼文档时可能经历的迭代写作过程。

文学翻译就是一个很好的例子。翻译器 LLM 最初可能无法捕捉到某些细微差别，但评估器 LLM 可以提供有用的批评。另一个应用是复杂的搜索任务，需要多轮搜索和分析来收集全面信息，评估器决定是否需要进一步搜索。

第五章 Agents：自主性的平衡

Agents 随着 LLM 在关键能力上的成熟而在生产中出现——理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复。Agents 从人类用户的命令或交互式讨论开始工作。一旦任务清楚，agents 就会独立规划和操作，可能会返回给人类以获取更多信息或判断。

在执行过程中，agents 在每一步从环境获得"ground truth"（如工具调用结果或代码执行）以评估其进度至关重要。Agents 可以在检查点或遇到障碍时暂停以获得人类反馈。任务通常在完成时终止，但包括停止条件（如最大迭代次数）以保持控制也是常见的。

Agents 可以处理复杂的任务，但它们的实现通常很简单。它们通常只是 LLM 在循环中基于环境反馈使用工具。因此，清晰周到地设计工具集及其文档至关重要。

一个真实案例是 Anthropic 的编码 Agent 解决 SWE-bench 任务。这些任务涉及基于任务描述编辑许多文件。Agent 可以自主分析问题描述，确定需要修改的文件，执行更改，运行测试，并根据测试结果迭代改进。整个过程完全自主，但包含了多个检查点和停止条件以确保可控性。

第六章 2025 年的新进展：Skills 和 MCP 的协同效应

在 2025 年的视频讨论中，Alex 和 Erik 特别强调了几个新的发展，这些在 2024 年底的原始博客文章中还没有详细展开。

6.1 Agent Skills：上下文工程的实践

Anthropic 在 2025 年 10 月推出的 Agent Skills 功能，代表了一种新的 agent 构建思维。Skills 不是简单的工具，而是一整套精心设计的上下文工程实践。每个 Skill 都包含了丰富的上下文信息、使用示例和边界条件，就像一个经验丰富的工程师写下的详细操作手册。

Erik 在视频中说了一个很有意思的观察：他们在为 SWE-bench 构建 agent 时，实际上花在优化工具上的时间比整体提示还多。例如，他们发现模型在使用相对路径的工具时会犯错，因为 agent 已经移出了根目录。为了解决这个问题，他们更改工具以始终需要绝对文件路径——结果发现模型完美地使用了这种方法。

这个故事很好地说明了 Agent Skills 的核心理念：把 agent-computer interface（ACI）当成人机交互（HCI）来对待。你在设计面向人类的界面时投入多少努力，在设计面向 agent 的界面时也应该投入同样的努力。

6.2 Model Context Protocol：工具生态的标准化

MCP 作为开放标准，正在快速成长为一个丰富的工具生态系统。开发者可以通过简单的客户端实现集成各种第三方工具，而不需要为每个工具编写自定义集成代码。

这种标准化带来的好处是巨大的。就像 USB 标准统一了外设接口一样，MCP 统一了 AI agents 与外部系统的交互方式。开发者可以专注于 agent 本身的逻辑，而不是重复造轮子。

6.3 Multi-Agent Patterns：并行化和协作

视频中还特别讨论了 multi-agent 系统的设计模式，包括并行化、MapReduce 和 test-time compute。这些模式让多个 agents 可以协同工作，各自处理任务的不同方面或尝试不同的解决方案。

一个有趣的并行化案例是在代码审查场景中。你可以启动多个 agents，每个使用不同的提示策略审查同一段代码。如果一个 agent 发现了问题，就标记出来。这种多方验证的方式比单一 agent 审查更可靠。

但这里需要特别小心。Anthropic 团队观察到，很多团队过早地引入了 multi-agent 架构，结果增加了系统复杂性而没有带来明显收益。他们的建议是：从单一 agent 开始，只有在明确的性能瓶颈或可衡量的收益时才考虑 multi-agent 架构。

第七章 常见失败模式和最佳实践

7.1 过早优化

最常见的错误可能就是过早引入复杂的 agent 架构。有团队一开始就构建了一个包含十几个子 agents 的系统，每个 agent 负责一小块任务。但当他们测试时发现，一个简单的 workflow 就能达到 90% 的效果，而且速度快得多、成本更低。

7.2 工具设计不当

工具的文档和定义应该和整体提示一样经过精心设计。有几种方法可以指定相同的操作。例如，你可以通过编写 diff 或重写整个文件来指定文件编辑。对于结构化输出，你可以在 markdown 或 JSON 中返回代码。在软件工程中，这些差异是表面的，可以无损地相互转换。然而，对于 LLM 来说，某些格式比其他格式难写得多。

编写 diff 需要在编写新代码之前知道更改块中有多少行正在更改。与 markdown 相比，在 JSON 中编写代码需要额外的转义换行符和引号。

7.3 缺乏可观测性

当你使用复杂框架时，可能会失去对 agent 内部工作过程的可视性。这在调试时是个大问题。Anthropic 建议始终保持对 agent 规划步骤的透明度，确保你能够观察和理解 agent 的决策过程。

7.4 测试不充分

Agents 的自主性意味着更高的成本和错误复合的潜在可能性。建议在沙盒环境中进行广泛测试，并设置适当的护栏。Anthropic 强调，自动化测试虽然有助于验证功能性，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

第八章 实践中的成功应用

8.1 客户支持：对话与行动的结合

客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。对于更开放的 agents 来说，这是一个自然的匹配，因为支持交互自然遵循对话流程，同时需要访问外部信息和行动；工具可以集成以提取客户数据、订单历史和知识库文章；退款或更新工单等行动可以通过编程方式处理；成功可以通过用户定义的解决方案明确衡量。

几家公司通过基于使用的定价模型展示了这种方法的有效性，该模型仅对成功的解决方案收费，显示了对 agents 有效性的信心。

8.2 编程 Agents：可验证的问题空间

软件开发领域显示了 LLM 功能的巨大潜力，能力从代码完成发展到自主解决问题。Agents 特别有效，因为代码解决方案可以通过自动化测试验证；agents 可以使用测试结果作为反馈来迭代解决方案；问题空间定义明确且结构化；输出质量可以客观衡量。

Anthropic 自己的实现中，agents 现在可以仅基于 pull request 描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。这是一个显著的里程碑，展示了 agents 在实际编程任务中的能力。

第九章 三大核心原则

在实施 agents 时，Anthropic 尝试遵循三个核心原则：

保持设计的简洁性

这是反复出现的主题。最成功的系统往往不是最复杂的，而是最适合特定需求的系统。从简单的提示开始，通过全面的评估进行优化，只有当更简单的解决方案不够时才添加多步骤 agentic systems。

优先考虑透明度

明确显示 agent 的规划步骤。这不仅有助于调试和理解 agent 的行为，也让用户能够建立对系统的信任。当用户能够看到 agent 的决策过程时，他们更愿意接受和依赖这个系统。

精心设计 agent-computer interface（ACI）

通过彻底的工具文档化和测试来构建。就像对待人机交互（HCI）一样投入精力来设计 agent-computer interface。一个经验法则是考虑在人类计算机界面（HCI）上投入多少努力，并计划在创建良好的 agent-computer 界面（ACI）上投入同样的努力。

结语：在复杂与简单之间找到平衡

回顾 Anthropic 团队的这些实践和发现，一个清晰的脉络浮现出来：成功的 AI agent 系统不是关于构建最复杂的系统，而是构建适合你需求的系统。

从 2024 年底"Building Effective Agents"博客文章的发布，到 2025 年 10 月这个深入的对话讨论，我们可以看到 Anthropic 的思考在不断演进。Agent Skills 的推出、MCP 生态的成长、context engineering 概念的成熟——所有这些进展都在指向同一个方向：让 agents 更强大、更可靠、更易于理解和使用。

框架可以帮助你快速起步，但在进入生产环境时不要犹豫减少抽象层并使用基本组件。通过遵循这些原则，你可以创建不仅强大而且可靠、可维护且受用户信任的 agents。

最重要的是记住：简单性不是妥协，而是智慧。在 AI agent 的世界里，最优雅的解决方案往往也是最简单的。当你 tempted（诱惑）去构建一个复杂的多 agent 系统时，停下来问问自己：我真的需要这个复杂性吗？更简单的方案会不会更好？

这些问题的答案，可能就决定了你的 agent 项目是成功还是失败。

参考资料

• • Building more effective AI agents - YouTube
• • Building Effective Agents - Anthropic Blog
• • Equipping agents for the real world with Agent Skills
• • Effective context engineering for AI agents
• • Code execution with MCP: building more efficient AI agents