最近，来自 Anthropic 的 Alex Albert (Claude 关系负责人) & Erik Schluntz (多智能体研究员) 共同探讨了 AI 智能体在过去数月中的快速演进。他们分享了从简单的"工作流"过渡到复杂的"多智能体系统"的实践经验，并深入探讨了如何通过代码、Claude Skills、MCP和工具的最佳实践来构建更高效、更自主的 Claude 智能体。
欢迎订阅合集 AI 播客捕手，专门面向文字内容爱好者分享 AI 领域优质播客！如需文字稿，后台私我获取，请务必备注（城市+行业+岗位+一句话介绍）。
目录
-
Claude 作为智能体的基础：从编码能力到通用工具
-
开发者工具的演进：从 Claude Code SDK 到 Claude Skills
-
智能体系统的演进：从工作流到多智能体
-
智能体开发者的最佳实践
-
保持简单，按需增加复杂性 - 采用智能体的视角（换位思考） - 工具应映射 UI，而非 API（核心）
-
未来展望：长程任务的自动交付
Claude 作为智能体的基础：从编码能力到通用工具
要理解如何构建高效的智能体，首先要明白 Claude 为何擅长执行智能体任务。Anthropic 的多智能体研究员 Eric 解释说，核心在于大量的刻意练习。在训练过程中，Claude 被要求处理许多开放式问题 (open-ended problems)。这些任务要求 Claude 必须采取多个步骤、使用工具、探索当前所处环境及工作内容，然后才能给出最终答案。通过在强化学习（RL）过程中对编码、搜索任务等不同环境进行大量练习，Claude 积累了丰富的"作为智能体"的经验，因此变得非常擅长此类工作。
外界普遍认为 Claude 在编码方面异常强大，但有时会误以为这种能力仅限于技术领域，无法迁移。Eric 对此提出了不同的看法：编码是智能体最基本、最核心的技能。Anthropic 之所以首先专注于编码，是因为一旦拥有了一个出色的编码智能体，这个智能体几乎可以完成任何其他类型的工作。
这种能力的泛化是如何实现的？例如，如果智能体需要执行搜索任务，它可以通过编写代码来调用 Web 搜索的 API；如果需要规划一个周末行程，它可以通过编写代码来创建一个日程表或数据结构。Anthropic 的理念是"先训练最难的东西"（train on the hardest thing first），即编码，那么其他一切（如搜索、规划）都会因此变得更容易。编码能力的"溢出效应" (spillover effect) 极其显著，它是使 Claude 在所有领域都表现出色的基石。
这种以编码为核心的理念，已经体现在 Claude.ai 网页版最近发布的一项功能中：Claude 能通过编写代码来创建实际的文件。例如，用户要求 Claude 创建一个表格，Claude 会先编写一段 Python 脚本，当这段脚本被执行后，一个 Excel 表格就真的被创建并出现在用户面前。这代表了智能体未来的一个重要方向：Claude 编写脚本并在计算机上采取行动，以创建传统意义上非代码相关的产物。
Eric 分享了一个亲身经历来佐证这一点。几天前，他让 Claude 帮他为一场演示文稿制作一些图表。一开始，Claude 通过直接编写 SVG（一种图像文件格式）代码来生成简单的图表。但当 Eric 要求制作一个包含大量重复性细节的、更复杂的图表时，Claude 改变了策略。它没有选择自己逐行编写那个极其冗长、充满重复模式的 SVG 文件，而是选择编写一段代码（脚本）来生成这个 SVG 文件。
这种方式的效率天差地别。脚本运行的速度远远快于 Claude 逐字生成图像文件的速度。这揭示了一个重要原则：对于许多复杂或重复性的任务，让智能体编写代码来生产某个"人工产物"（artifact），比让它直接创建这个产物要高效得多。
开发者工具的演进：从 SDK 到"技能"
当开发者真正开始着手构建自己的智能体时，Anthropic 发现 Claude Code SDK 正变得越来越受欢迎。Eric 强调，这个 SDK 的重要性在于它解决了一个核心的"重复造轮子"问题。在过去，如果开发者想从零开始（即只通过调用 API 端点）构建一个编码智能体或任何通用智能体，他们必须自己编写所有的核心逻辑：包括构建循环（loops）、构建工具、执行工具、与文件系统交互、以及处理 MCP（Model-Chosen Parameters，模型选择的参数）等。
Claude Code SDK 将所有这些基础工作全部打包内置了。虽然它的名字里带着"Code"，但 Eric 指出，Claude Code 本质上是一个通用智能体（general-purpose agent） ，只是它最常被用于处理代码任务。Anthropic 强烈建议开发者将这个 SDK 作为其智能体循环的核心。这样一来，开发者无需在那个已经被 Anthropic 投入大量时间打磨和完善的"核心智能体循环"上花费精力。相反，他们可以把时间花在真正有价值的地方：通过 MCP 添加他们自己独特的工具、自定义的业务逻辑或特定的功能。
这个 SDK 具有高度的可定制性。开发者可以移除其中特定于编码的部分，然后像插槽一样，填入他们自己需要的任何提示（prompt）或工具。Eric 甚至分享了他个人对 Claude Code "最奇怪的用法"：他曾用它来为自己规划一次约会。通过集成网络搜索工具，这个"编码 SDK"帮他搜索了该地区有趣的活动和餐馆，最终推荐了长木花园（Longwood Gardens）和附近的一家中餐馆。事实证明，效果还相当不错。
在 Claude Code 之外，开发者工具的另一个演进方向体现在"技能"（Skills）这一新概念上。这源于软件工程师们喜爱的一个早期功能：Claude.md 文件。开发者可以在项目根目录中放置一个 Claude.md 文件，用来向 Claude 提供关于这个项目的背景信息，比如"我的编程风格是怎样的"或"这个项目的目录结构布局是怎样的"。
"技能" (Skills) 则是 Claude.md 文件令人兴奋的扩展。它不再局限于提供纯文本的"笔记"或"指令"，而是允许开发者为 Claude 提供任何类型的文件作为"资源" 。
这些资源可以包括：
- 模板文件 ：例如，公司官方的 PowerPoint 模板。 2. 辅助脚本 ：Claude 在执行任务时可以调用的现成代码（helper scripts）。 3. 资产文件：例如图像、Logo，甚至是公司所有高管的"大头照"（head shot）。
这种转变意义重大，它标志着从仅仅给智能体 指令 (instructions)转向同时为其提供 资源 (resources) 。 以前，你只能告诉 Claude "制作 PPT 时要遵循公司规范"；现在，你可以把所有的示例模板照片作为一项"技能"直接提供给 Claude。当 Claude 需要在多个演示文稿中重复使用这些照片时，它"手头就有一切所需"，可以直接取用。
Alex 分享了一个内部非常流行的比喻来形容"技能"：这就像电影《黑客帝国》（The Matrix）中，主角 Neo 第一次学习功夫的场景。当"功夫"程序被"注入"他的大脑后，他瞬间就掌握了这项技能。给 Claude 一项"技能"的感觉非常相似------比如，你给它一个"如何创建电子表格"的技能包，突然之间，Claude 就像变成了一个专业的"银行家"，能够为你构建复杂的财务模型。
Eric 对这个比喻做了补充：这也很像电影中他们为执行任务而"加载所有武器架和工具"的场景。 "技能"不仅是知识，更是智能体可以随时取用的装备和工具。
智能体系统的演进：从工作流到多智能体
几个月前，智能体领域正处于一个过渡期：从"工作流"（Workflows）向"单一智能体系统"（Single Agent System）转变。前者是指一系列高度定义、链接在一起的提示词（prompt chains），后者则是让模型在一个循环（loop）中运行。
而现在，这个领域已经发生了进一步的演进。Eric 指出，智能体循环（Agent loops）在很大程度上已经取代了静态的工作流。根本原因在于，Claude 模型在"响应反馈"和"纠正自身工作"方面的能力已经变得非常出色。因此，对于那些追求"绝对质量" (absolute quality) 的任务，智能体循环的表现已经远远超过了传统的工作流。
（当然，工作流在某些场景下依然有价值，比如当你需要极低的延迟、只想要 Claude 尽力给出"一次性"（single shot）答案时。）
基于这一进展，Eric 观察到了一个最新的趋势，他称之为"智能体工作流" (workflows of agents)。
为了理解这个概念，我们先看一个"旧"的工作流案例：假设一个应用程序需要先查询数据库再绘制图表。
- 旧的工作流（Workflow） ：
- 工作流的步骤一 （单次尝试）：Claude 编写一条 SQL 命令来加载数据。 2. 工作流的步骤二 （单次尝试）：数据被传递到下一个环节，Claude 编写代码来显示图表。 3. 失败点：如果步骤一的 SQL 命令失败了（比如语法错误或没有返回任何数据），步骤二对此一无所知，它会基于错误的数据（或空数据）继续执行，导致整个流程"彻底搞砸"（completely screwed）。
- 新的智能体工作流（Workflow of Agents） ： 1. 工作流的步骤一 （一个闭环）：它不再是单次尝试，而是一个完整的智能体 。这个智能体会尝试编写 SQL 查询，然后运行它，查看输出。 2. 如果发现查询失败或返回了非预期的结果，这个智能体会进行迭代和重复（iterate and repeat），直到它确认自己获得了正确的数据。 3. 工作流的步骤二：当且仅当步骤一的智能体确认成功后，它才会将控制权（和正确的数据）移交给工作流的下一个步骤（例如，另一个负责图表绘制的智能体）。
Alex 总结道，这标志着智能体架构的演进：从"链接提示"（chaining prompts）发展到了"链接智能体"（chaining agents）。
然而，这种演进也带来了新的挑战，其中最突出的就是"可观测性 " (Observability) 和"验证" (Verification) 的难题。Eric 坦言，随着系统变得越来越复杂（例如"智能体工作流"），可观测性会变得"非常困难"。
正因如此，他仍然坚信一个核心原则：简单性（Simplicity）至关重要 。尽管今天的模型比一年前强大得多，能够处理更复杂的智能体设置，但开发者在构建时，仍应遵循"从最简单可行方案开始，然后逐步增加复杂度"的路径。
具体来说，开发者应该首先尝试"单次调用"能否解决问题。如果不行，再尝试使用像 Claude Code SDK 这样封装好的、相对简单的智能体循环。只有在这些简单方法确实无法满足需求时，才应该一层一层地增加复杂性（比如构建"智能体工作流"），因为每增加一层复杂性，都会让系统的可观测性变得更难。
在"智能体工作流"之外，另一个常被提及的术语是"多智能体" (Multi-Agent)。Alex 提问这二者是否是同一回事。
Eric 明确表示， "多智能体"与"智能体工作流""非常不同" 。
- 智能体工作流 (Workflows of Agents) ：本质上是串行的 (sequential)。一个智能体完成工作，然后它的输出被发送给下一个智能体。
- 多智能体 (Multi-Agent) ：本质上是并行的 (parallel)。系统中有多个智能体（或多个 Claude 实例）在同一时间工作。
Eric 举了两个"多智能体"的典型例子：
1. 并行委托（Delegation in Parallel） 一个"父智能体"（parent agent）可以将任务委托给（比如）五个"子智能体"（sub-agents），这五个子智能体可以各自并行工作。Anthropic 内部的深度研究搜索产品就是这样运作的：主"协调器"智能体（orchestrator agent）会决定并创建几个子智能体，让它们同时执行大量的搜索任务。这对用户的好处是显而易见的：因为一切都是并行发生的，用户能更快地获得最终答案。
2. 保护上下文（Context Protection） 在 Claude Code 中，模型也会使用子智能体。假设主智能体需要执行一个子任务，这个任务本身可能需要消耗数万个 token（比如，在一个庞大的代码库中查找某个特定类的实现细节），但该任务的最终答案（比如文件名和行号）其实非常简短。
在这种情况下，主智能体可以将这项繁重的工作"外包"给一个子智能体。子智能体在自己的上下文中处理那数万 token，完成后，只将那个简短的最终答案返回给主智能体。这样做的好处是保护了主智能体的上下文窗口，避免其被那些对主任务而言不必要的中间信息所"淹没"。
这种机制是如何实现的？Eric 解释说，它复用了工具调用（Tool Calling）框架。对于主智能体 Claude 来说，这个子智能体看起来就像一个它可以调用的普通"工具"。主智能体会把任务提示（prompt）作为参数传递给这个"工具"，子智能体（另一个 Claude 实例）随之开始工作。
Eric 目前的研究重点之一，就是训练 Claude 成为一个更好的"管理者" 。这包括教会它如何向子智能体提供清晰的指令，并确保它能从子智能体那里获取到它需要的东西。
Alex 好奇地问，Claude 是否"直观地理解"它在和另一个自己对话。Eric 回答说，Claude 在这方面会犯和人类"新手管理者"一样的错误。例如，它会向子智能体提供不完整或含糊不清的指令，同时却（错误地）期望子智能体能拥有和它一样的上下文背景。
通过在训练中不断实践，Claude 正在逐步改善。研究人员观察到，Claude 开始变得更啰嗦、更详细 ，它会有意识地向其子智能体提供任务的"整体背景" (overall context)，以便它们能够更好地完成那些需要"汇总"的工作。简而言之，Claude 正在学习如何成为一名更称职的管理者。
智能体开发者的最佳实践
在讨论了各种先进的智能体架构之后，话题回到了最根本的问题：如果一个开发者想要开始构建智能体（无论是使用 Claude Code SDK 还是自己搭建），他们应该遵循哪些最佳实践？Eric 提供了几个至关重要的建议，其中"UI vs API"的心智模型尤为关键。
保持简单，按需增加复杂性
这是开发智能体系统的首要原则。永远从最简单的方法开始，只有在绝对必要时才增加复杂性 (Start simple and make sure you only add complexity as you need)。智能体系统的可观测性非常困难，复杂的架构（如多智能体）会加剧这一难题。因此，优先尝试单次调用（Singleshot），其次是简单的智能体循环（如 SDK），最后才考虑复杂的多层系统。
采用智能体的视角（换位思考）
开发者必须"从你的智能体的角度去思考 " (think from the point of view of your agents)。当你为 Claude 提供工具、提示或任何功能（affordances）时，你必须"设身处地地站在 Claude 的立场上" (put yourself in Claude's shoes)。
最有效的做法是：去阅读智能体看到的原始日志 （raw transcript），查看它在工具调用中实际看到了什么信息。然后问自己："如果我是智能体，只看得到这些信息，我真的有足够的信息来解决这个问题吗？"
开发者很容易忘记：我们（人类）能看到一切，而模型"只看得到我们展示给它的东西"。
工具应映射 UI，而非 API（核心）
这是 Eric 强调的一个最常见且最严重的错误观念。当人们（特别是开发者）开始构建工具或 MCP（模型选择的参数）以连接 Claude 和外部世界时，他们有一个"非常自然但非常错误的第一直觉" ：
错误观念 ：工具（Tools/MCPs）应该与你的后端 API 一一对应。
正确心智 ：工具（Tools/MCPs）应该与你的用户界面（UI） 一一对应。
为什么？因为模型（Claude）最终是这些工具的"用户"（user），它不像"传统程序"（traditional program）那样工作。
Eric 用一个关于 Slack 的例子完美地阐释了这一点：
假设你想让智能体理解一段 Slack 对话。你的后端 API 可能有三个独立的端点 (endpoints)：
load_slack_conversation()：加载对话内容（但只返回 user ID 和 channel ID）。turn_user_id_into_username()：根据 ID 转换用户名。turn_channel_id_into_channel_name()：根据 ID 转换频道名。
如果采用"API 映射"的错误方式 ，你会给模型提供这三个独立的工具。其后果是：智能体为了"理解"任何事情，都必须连续进行三次工具调用（先加载，再转换用户，再转换频道）。这极其低效。
如果采用"UI 映射"的正确方式 ，你会反问自己：一个人类用户 是如何看待 Slack 的？我们看到的是一个"所有内容都已完美渲染好" (everything all nicely rendered) 的界面。我们不需要去"点击用户 ID 来看他的名字"。
因此，你应该为模型创建一个工具（或 MCP），它能一次性 呈现所有信息，并且需要尽可能少的交互 。这个工具应该模拟 UI，在后台自己完成那三次 API 调用，然后将一个已经"渲染"好的、包含用户名和频道名的完整对话文本返回给模型。
这个心智模型的核心是：不要让智能体去做那些连你作为用户都会觉得"糟糕透顶"（terrible）的、繁琐的交互操作。
未来展望：封闭 QA 循环与"计算机使用"
最后，讨论展望了智能体的未来 6 到 12 个月。Eric 预测，智能体将变得更加普及，首先从那些"可验证"（verifiable）的领域开始，比如软件工程 。编码智能体已经改变了许多人的工作方式，而未来最大的增益点在于"自我验证"。
目前，开发者在智能体（比如 Claude）写完代码后，必须自己去充当"QA 工程师"的角色来进行测试。未来最令人兴奋的突破是智能体能够自己"封闭这个测试循环" (closing that loop of testing) 。
例如，一个智能体不仅能编写一个网络应用程序，它还能自己去（通过"计算机使用"能力）"打开它、测试它、然后找到它自己的 Bug"，而不是等你去发现 Bug。
实现这一点的关键在于将"软件工程能力"与"计算机使用" (Computer Use) 能力相结合。一旦智能体掌握了像人一样操作计算机（滚动、点击、编辑文本）的能力，它将解锁大量目前被"拒之门外"的领域。
一个具体的例子是：现在，如果你想让 Claude 帮你修改一篇 Google Doc，你只能在 Claude 界面和文档之间来回复制粘贴。但如果智能体有了"计算机使用"能力，你可以直接说："嘿 Claude，帮我清理一下这篇 Google Doc。" 它就可以直接在文档中为你操作，滚动、点击、编辑文本。这将是一种截然不同的、更高效的交互体验，智能体将真正实现"无论你在哪里，Claude 都能与你同在"。