Anthropic 研究员详解：构建高效 Claude 智能体的完整方法论

访谈对象：Alex Albert (Claude 关系负责人)、Erik Schluntz (多智能体研究员)
时间：2025年11月
来源：Anthropic 官方播客

前言

“编码是智能体最基本、最核心的技能。一旦拥有了一个出色的编码智能体，这个智能体几乎可以完成任何其他类型的工作。”

“工具应该映射 UI，而非 API——这是构建智能体工具最常见也最严重的错误观念。”

最近，来自 Anthropic 的两位核心成员——Claude 关系负责人 Alex Albert 与多智能体研究员 Erik Schluntz，深入探讨了 AI 智能体在过去数月中的快速演进。他们分享了从简单的”工作流”过渡到复杂的”多智能体系统”的实践经验，并详细阐述了如何通过代码、Claude Skills、MCP 和工具的最佳实践来构建更高效、更自主的 Claude 智能体。

三个核心洞察：

编码能力是一切的基础：强大的编码智能体可以泛化到任何领域，这种”溢出效应”是 Claude 在所有任务上表现出色的关键
架构演进路径清晰：从静态工作流 → 单一智能体循环 → 智能体工作流 → 多智能体系统，复杂度逐级递增
UI映射原则至关重要：工具设计应模拟用户界面而非后端API，这能显著提升智能体效率

一、Claude 作为智能体的基础：编码能力的”溢出效应”

1.1 智能体能力的训练根源

要理解如何构建高效的智能体，首先要明白 Claude 为何擅长执行智能体任务。Erik 指出，核心在于大量的刻意练习。

训练策略：

在训练过程中，Claude 被要求处理许多开放式问题
这些任务要求采取多个步骤、使用工具、探索环境
通过强化学习对编码、搜索等不同场景进行大量练习

这种训练方式让 Claude 积累了丰富的”作为智能体”的经验，因此在智能体任务上表现出色。

1.2 为什么编码是最重要的技能

外界普遍认为 Claude 在编码方面异常强大，但常误以为这种能力仅限于技术领域。Erik 提出了不同的看法：

编码是智能体最基本、最核心的技能。

Anthropic 的理念是“先训练最难的东西”——即编码，那么其他一切都会变得更容易。

编码能力的泛化场景：

搜索任务：编写代码调用 Web 搜索 API
行程规划：编写代码创建日程表或数据结构
数据分析：编写脚本处理和可视化数据

编码能力的”溢出效应”极其显著，它是使 Claude 在所有领域都表现出色的基石。

1.3 从直接生成到代码生成的效率革命

这种以编码为核心的理念，已经体现在 Claude.ai 网页版的功能中：Claude 能通过编写代码来创建实际的文件。

典型案例：

Erik 分享了一个亲身经历。他让 Claude 帮他为演示文稿制作图表：

简单图表：Claude 直接编写 SVG 代码生成
复杂图表：当需要大量重复性细节时，Claude 改变策略——编写一段脚本来生成 SVG 文件

效率对比：脚本运行速度远远快于 Claude 逐字生成图像文件的速度。

核心原则： 对于许多复杂或重复性的任务，让智能体编写代码来生产某个”人工产物”，比让它直接创建这个产物要高效得多。

二、开发者工具的演进：从 SDK 到 Skills

2.1 Claude Code SDK：通用智能体框架

当开发者真正开始构建自己的智能体时，Claude Code SDK 正变得越来越受欢迎。

SDK 的核心价值：

解决了”重复造轮子”问题
内置了所有基础工作：循环、工具构建、工具执行、文件系统交互、MCP 处理
虽然名字里有”Code”，但本质上是一个通用智能体框架

使用建议：

Erik 强烈建议开发者将这个 SDK 作为智能体循环的核心。这样开发者可以把时间花在真正有价值的地方：

通过 MCP 添加独特的工具
定制业务逻辑
实现特定功能

高度可定制性：

开发者可以移除编码相关部分，然后填入自己需要的任何提示或工具。Erik 甚至用它规划过约会——通过集成网络搜索工具，这个”编码 SDK”帮他搜索了地区活动和餐馆，推荐了长木花园和附近的中餐馆。

2.2 Claude Skills：从指令到资源的跃迁

技能的起源：Claude.md 文件

开发者可以在项目根目录放置 Claude.md 文件，向 Claude 提供项目背景信息：

编程风格偏好
项目目录结构
技术栈说明

Skills 的革命性扩展：

Skills 不再局限于提供纯文本”指令”，而是允许开发者为 Claude 提供任何类型的文件作为”资源”。

资源类型示例：

模板文件：公司官方 PowerPoint 模板
辅助脚本：Claude 可调用的现成代码
资产文件：图像、Logo、高管照片等

从”给指令”到”给资源”——这标志着智能体工具的重大转变。

“黑客帝国”比喻：

Alex 用《黑客帝国》中 Neo 学习功夫的场景作比喻：当”功夫”程序被注入大脑后，他瞬间掌握了技能。给 Claude 一项”技能”的感觉非常相似——比如给它一个”如何创建电子表格”的技能包，Claude 就像变成了专业的”银行家”，能够构建复杂的财务模型。

三、智能体系统的架构演进

3.1 从工作流到智能体循环

几个月前，智能体领域正处于过渡期：从”工作流”向”单一智能体系统”转变。

工作流 vs 智能体循环：

类型	特点	适用场景
工作流	链接的提示词序列，每步单次执行	需要极低延迟的简单任务
智能体循环	模型在循环中运行，可反馈和纠正	追求绝对质量的复杂任务

为什么智能体循环胜出：

Claude 在”响应反馈”和”纠正自身工作”方面的能力已经非常出色，因此智能体循环在追求质量的任务上表现远超工作流。

3.2 智能体工作流：串行的智能体链

Erik 观察到的最新趋势：“智能体工作流”(Workflows of Agents)。

案例对比：数据查询与图表绘制

旧的工作流（Workflow）：

步骤一（单次尝试）：Claude 编写 SQL 命令加载数据
步骤二（单次尝试）：基于数据绘制图表
失败点：如果步骤一的 SQL 失败，步骤二对此一无所知，基于错误数据继续执行

新的智能体工作流（Workflow of Agents）：

步骤一（完整智能体）：
- 尝试编写 SQL 查询
- 运行并查看输出
- 如果失败，迭代重试直到获得正确数据
步骤二：当且仅当步骤一确认成功后，才移交给下一个智能体

从”链接提示”演进到”链接智能体”——这是智能体架构的重要里程碑。

3.3 可观测性挑战与简单性原则

复杂性带来的难题：

随着系统变得越来越复杂，可观测性会变得”非常困难”。

Erik 的核心建议：

永远从最简单的方法开始，只有在绝对必要时才增加复杂性。

推荐的渐进路径：

第一步：尝试单次调用能否解决问题
第二步：使用 Claude Code SDK 等简单智能体循环
第三步：只有在简单方法无法满足需求时，才构建复杂的多层系统

每增加一层复杂性，系统的可观测性就会变得更难。

3.4 多智能体系统：并行的协作架构

智能体工作流 vs 多智能体：

类型	执行方式	特点
智能体工作流	串行（Sequential）	一个智能体完成后传递给下一个
多智能体	并行（Parallel）	多个智能体同时工作

多智能体的典型应用场景：

场景一：并行委托

一个”父智能体”将任务委托给多个”子智能体”并行工作。

示例：Anthropic 的深度研究搜索产品

主”协调器”智能体决定创建几个子智能体
子智能体同时执行大量搜索任务
用户更快获得最终答案

场景二：上下文保护

主智能体将繁重的子任务外包给子智能体。

示例：代码库搜索

任务可能需要消耗数万个 token（在庞大代码库中查找）
最终答案却很简短（文件名和行号）
子智能体在自己的上下文中处理，只返回简短答案
保护主智能体的上下文窗口

3.5 Claude 学习成为”管理者”

实现机制：

多智能体通过工具调用框架实现。对主智能体来说，子智能体就像一个可调用的”工具”。

Claude 的”管理挑战”：

Erik 目前的研究重点之一，是训练 Claude 成为更好的”管理者”。

Claude 会犯和人类”新手管理者”一样的错误。

常见错误：

向子智能体提供不完整或含糊的指令
错误地期望子智能体拥有和它一样的上下文背景

改进方向：

通过训练，Claude 开始：

变得更啰嗦、更详细
有意识地向子智能体提供任务的”整体背景”
学习如何成为更称职的管理者

四、智能体开发者的核心最佳实践

4.1 保持简单，按需增加复杂性

首要原则：

Start simple and make sure you only add complexity as you need.

推荐路径：

单次调用 → 简单智能体循环（如 SDK） → 复杂多层系统

智能体系统的可观测性非常困难，复杂架构会加剧这一难题。

4.2 采用智能体的视角（换位思考）

核心思维：

从智能体的角度去思考，设身处地站在 Claude 的立场上。

最有效的实践方法：

阅读智能体看到的原始日志
查看它在工具调用中实际看到的信息
问自己：”如果我是智能体，只看到这些信息，我真的有足够信息解决这个问题吗？”

关键认知：

开发者容易忘记——我们（人类）能看到一切，而模型”只看得到我们展示给它的东西”。

4.3 工具应映射 UI，而非 API（最重要）

这是 Erik 强调的最常见且最严重的错误观念。

错误观念 vs 正确心智：

错误观念	正确心智
工具应与后端 API 一一对应	工具应与用户界面（UI）一一对应

核心原因：

模型（Claude）是工具的”用户”，它不像”传统程序”那样工作。

经典案例：Slack 对话理解

错误方式：API 映射

后端有三个独立端点：

load_slack_conversation()：返回 user ID 和 channel ID
turn_user_id_into_username()：ID 转用户名
turn_channel_id_into_channel_name()：ID 转频道名

如果提供这三个独立工具，智能体必须连续进行三次工具调用才能理解任何事情。极其低效。

正确方式：UI 映射

反问：人类用户如何看待 Slack？

我们看到的是”所有内容都已完美渲染好”的界面，不需要”点击用户 ID 来看他的名字”。

解决方案：

创建一个工具，一次性呈现所有信息
需要尽可能少的交互
在后台自己完成那三次 API 调用
返回已经”渲染”好的、包含用户名和频道名的完整对话文本

核心思想：

不要让智能体去做那些连你作为用户都会觉得”糟糕透顶”的、繁琐的交互操作。

五、未来展望：长程任务的自动交付

5.1 自我验证的闭环系统

Erik 预测，智能体将变得更加普及，首先从”可验证”领域开始，比如软件工程。

当前状态：

开发者在智能体写完代码后，必须自己充当”QA 工程师”测试

未来突破：

智能体能够自己”封闭测试循环”
不仅编写网络应用，还能自己打开、测试、找到自己的 Bug
不再等待人类发现问题

5.2 计算机使用能力的革命性影响

关键能力融合：

将”软件工程能力”与”计算机使用”(Computer Use) 能力相结合。

计算机使用的含义：

像人一样操作计算机
滚动、点击、编辑文本

解锁的新场景：

一旦智能体掌握了这种能力，将解锁大量目前被”拒之门外”的领域。

具体案例：Google Doc 编辑

现状：

在 Claude 界面和文档之间来回复制粘贴

未来：

直接说：”嘿 Claude，帮我清理一下这篇 Google Doc”
Claude 直接在文档中操作：滚动、点击、编辑文本

“无论你在哪里，Claude 都能与你同在”——这将是截然不同的、更高效的交互体验。

5.3 从编码智能体到通用智能体

演进路径：

编码智能体 → 自我测试编码智能体 → 计算机使用智能体 → 通用自主智能体

当智能体能够：

理解任务需求
编写代码实现
自我测试验证
操作任何软件界面

它就真正成为了可以自主完成长程任务的通用智能体。

结语：从工具到伙伴的跃迁

核心要点回顾

1. 编码能力是基础

强大的编码能力可以泛化到所有领域
“先训练最难的”策略证明有效

2. 工具演进路径清晰

SDK 解决了基础架构问题
Skills 提供了从指令到资源的跃迁

3. 架构复杂度需谨慎

从简单开始，按需增加复杂性
可观测性随复杂度指数级下降

4. UI 映射原则至关重要

工具设计应模拟用户界面
最小化智能体的交互次数

对开发者的启示

构建智能体时的三个关键转变：

思维转变：从”调用 API”到”模拟 UI”
架构转变：从”链接提示”到”链接智能体”
角色转变：从”编写代码”到”管理智能体”

通往未来的路径

当前的智能体开发仍处于早期阶段，但演进路径已经清晰：

单一智能体 → 智能体工作流 → 多智能体系统 → 自主长程任务执行

最终目标不是替代人类开发者，而是让 AI 成为真正的协作伙伴。

当智能体能够理解你的意图、自主规划任务、执行并验证结果，我们就进入了一个全新的人机协作时代。这不是科幻，而是正在发生的现实。

来源： Anthropic 官方播客
整理： Anthropic 研究员深度解析 Claude 智能体构建方法论
整理时间： 2025年11月6日