---

前言

原文：How we built our multi-agent research system - Anthropic
原文发布时间：2025年6月13日
注：本文在原文基础上增加了基础概念说明，帮助读者更好理解多智能体系统的工作原理

基础知识：什么是AI智能体？

在深入了解多智能体系统之前，我们先理解一些核心概念。

AI智能体（AI Agent）的定义

AI智能体是能够自主使用工具、执行任务的AI系统。 与传统的聊天机器人不同，智能体具有以下特点：

1. 自主性：不需要人类在每一步都给出指令，能够自己决定下一步做什么
2. 工具使用能力：可以调用搜索引擎、数据库、API等外部工具
3. 循环执行：可以根据执行结果调整策略，进行多轮操作
4. 目标导向：围绕用户给定的目标持续工作，直到完成任务

举个例子：

• 传统AI：用户问"今天天气如何？“，AI直接回答（如果知道）或说"我不知道”
• AI智能体：用户问"今天天气如何？"，智能体会：
  1. 识别需要实时信息
  2. 调用天气API工具
  3. 获取当前天气数据
  4. 整理并返回结果

什么是工具调用（Tool Calling）？

工具调用是智能体与外部系统交互的方式。常见的工具包括：

• 搜索工具：在网络上搜索信息
• 数据库工具：查询、插入、更新数据
• 文件操作工具：读取、写入文件
• API工具：调用第三方服务（如天气、地图、翻译等）
• 计算工具：执行数学计算或代码

什么是上下文窗口（Context Window）？

上下文窗口是AI模型一次能够"看到"和处理的文本量。可以理解为AI的"短期记忆容量"。

• 类比：就像人在阅读时，一次能记住的内容有限。如果文章太长，前面的内容可能会被遗忘
• 限制：当前主流模型的上下文窗口在几万到几十万个token之间（1个token约等于0.75个英文单词或1.5个中文字符）
• 影响：超出上下文窗口的内容需要通过其他方式（如总结、存储）来处理

什么是Token？

Token是AI模型处理文本的基本单位：

• 英文：一个单词通常是1-2个tokens（“hello” = 1 token，“understanding” = 2 tokens）
• 中文：一个汉字通常是1-2个tokens
• 成本计算：AI服务通常按token数量收费

---

什么是多智能体系统？

单智能体 vs 多智能体

单智能体系统：

• 一个AI智能体独立完成所有工作
• 类似于一个人完成整个项目
• 优点：简单、易于控制
• 缺点：受限于单个上下文窗口，处理复杂任务效率低

多智能体系统：

• 多个AI智能体协同工作，各司其职
• 类似于一个团队，每个成员负责不同部分
• 优点：可以并行处理、处理更复杂的任务
• 缺点：需要协调机制，系统更复杂

多智能体系统的工作模式

Anthropic采用的是编排器-工作者（Orchestrator-Worker）模式：

用户查询
    ↓
主智能体（编排器）
    ├→ 子智能体1（工作者）→ 搜索公司信息
    ├→ 子智能体2（工作者）→ 搜索产品信息  
    ├→ 子智能体3（工作者）→ 搜索市场数据
    ↓
主智能体汇总结果
    ↓
返回最终答案

核心思想：

• 主智能体负责理解任务、制定计划、分配工作、汇总结果
• 子智能体专注于执行具体的搜索或分析任务
• 子智能体之间并行运行，互不干扰

编排器-工作者（Orchestrator-Worker）模式如下图所示：

---

为什么研究任务需要多智能体？

Claude现在具备了研究（Research）功能，能够跨网络、Google Workspace以及各种集成工具进行搜索，完成复杂任务。

研究任务的特点

研究工作涉及开放性问题，具有以下特征：

1. 不可预测性：很难提前知道需要哪些步骤
2. 动态调整：需要根据发现不断更新方法
3. 信息量大：可能涉及数十个甚至上百个信息源
4. 多维度探索：需要同时从不同角度调查问题

传统方法的局限：

• 无法为探索复杂主题硬编码固定路径
• 线性的一次性流程无法处理动态变化的需求
• 单个上下文窗口容纳不下所有相关信息

多智能体系统的优势

1. 并行处理能力

场景举例：用户问"列出信息技术类标普500公司的所有董事会成员"

单智能体方式（串行）：

搜索公司1 → 找董事 → 搜索公司2 → 找董事 → ... → 搜索公司100 → 找董事
总耗时：如果每家公司需要1分钟，总共需要100分钟

多智能体方式（并行）：

├ 子智能体1 → 搜索公司1-20的董事
├ 子智能体2 → 搜索公司21-40的董事
├ 子智能体3 → 搜索公司41-60的董事
├ 子智能体4 → 搜索公司61-80的董事
└ 子智能体5 → 搜索公司81-100的董事

总耗时：如果并行运行，只需要20分钟

2. 信息压缩与上下文管理

搜索的本质是压缩：从海量信息中提炼关键洞察。

• 每个子智能体有独立的上下文窗口
• 子智能体同时探索问题的不同方面
• 每个子智能体将发现压缩成关键信息
• 主智能体只需要处理压缩后的精华内容

类比：就像一个研究团队，每个成员负责阅读不同的文献，然后在会议上只分享重点发现，而不是让团队负责人阅读所有文献。

3. 关注点分离

每个子智能体具有：

• 专门的工具：只使用完成自己任务所需的工具
• 专门的提示词：针对特定任务优化的指令
• 独立的探索轨迹：互不干扰，减少路径依赖

性能数据

Anthropic的内部评估显示：

• 多智能体系统（Opus 4 + Sonnet 4）比单智能体Opus 4性能提升90.2%
• 在BrowseComp评估中（测试定位难找信息的能力）：
  • Token使用量解释了80%的性能差异
  • 工具调用次数和模型选择是另外两个关键因素
• 多智能体系统在复杂查询上的研究时间减少高达90%

成本考量

资源消耗数据：

• 智能体平均使用token = 聊天交互的 4倍
• 多智能体系统平均使用token = 聊天交互的 15倍

适用场景：

• ✅ 任务价值高，值得投入更多资源
• ✅ 需要重度并行化处理
• ✅ 信息量超出单个上下文窗口
• ✅ 需要与众多复杂工具交互
• ❌ 任务简单，不需要大量搜索
• ❌ 需要所有智能体共享相同上下文
• ❌ 智能体之间有太多依赖关系（如大部分编码任务）

---

Anthropic研究系统的架构设计

整体架构：编排器-工作者模式

┌─────────────┐
│  用户查询    │
└──────┬──────┘
       ↓
┌─────────────────────────────────────────┐
│     主研究智能体 (LeadResearcher)        │
│  - 分析查询                              │
│  - 制定研究策略                          │
│  - 创建子智能体                          │
│  - 汇总结果                              │
└────────┬────────────────────────────────┘
         │
         ├──→ ┌─────────────────┐
         │    │  子智能体 1      │
         │    │  搜索主题A       │
         │    └─────────────────┘
         │
         ├──→ ┌─────────────────┐
         │    │  子智能体 2      │
         │    │  搜索主题B       │
         │    └─────────────────┘
         │
         └──→ ┌─────────────────┐
              │  子智能体 3      │
              │  搜索主题C       │
              └─────────────────┘
              ↓
         ┌─────────────────┐
         │  引用智能体      │
         │  添加准确引用    │
         └─────────────────┘
              ↓
         ┌─────────────────┐
         │  最终研究报告    │
         └─────────────────┘

工作流程详解

第1步：查询分析与规划

当用户提交查询"分析2025年AI智能体公司的情况"：

1. 主智能体接收查询
2. 进入思考模式（Extended Thinking）：
   • 这个任务需要哪些信息？
   • 应该创建几个子智能体？
   • 每个子智能体负责什么？
   • 需要使用哪些工具？
3. 保存研究计划到记忆（Memory）：
   • 因为上下文可能超过200,000 tokens
   • 保存计划确保不会丢失研究方向

第2步：创建专业子智能体

主智能体创建多个子智能体，例如：

子智能体1的任务：

任务：查找2025年活跃的AI智能体公司
工具：web_search, web_fetch
输出格式：公司列表，包含名称、网址、简介
边界：只关注专注于AI智能体的公司，不包括只是使用AI的公司

子智能体2的任务：

任务：分析这些公司的融资情况
工具：web_search, 财务数据API
输出格式：融资轮次、金额、投资方
边界：只关注最近两年的融资活动

子智能体3的任务：

任务：了解这些公司的主要产品和技术
工具：web_search, web_fetch, GitHub API
输出格式：产品描述、技术栈、开源项目
边界：关注已发布的产品，不包括实验性项目

第3步：并行执行搜索

每个子智能体独立工作：

1. 迭代搜索：

   • 执行初始搜索
   • 评估结果质量（使用interleaved thinking）
   • 根据发现调整搜索策略
   • 继续搜索直到获得足够信息

2. 动态调整：

   • 如果某个搜索没有结果，尝试不同的关键词
   • 如果发现新的相关方向，跟进调查
   • 如果信息过时，寻找更新的来源

3. 信息压缩：

   • 从大量搜索结果中提取关键信息
   • 只将精华内容返回给主智能体
   • 而不是把所有原始数据都传递回去

第4步：结果综合

主智能体收到所有子智能体的发现后：

1. 评估完整性：是否获得了足够信息？
2. 决策：
   • 如果信息充分 → 进入最终报告阶段
   • 如果有缺口 → 创建新的子智能体补充调查
   • 如果需要深入 → 调整策略，重新分配任务

第5步：添加引用

引用智能体（CitationAgent）的工作：

1. 分析研究报告中的每个声明
2. 在源文档中找到支持该声明的具体位置
3. 添加准确的引用标记
4. 确保所有事实性陈述都有来源支持

第6步：返回结果

最终输出包含：

• 结构化的研究报告
• 详细的数据分析
• 准确的来源引用
• 必要的补充说明

以下是一个多智能体研究系统的完整工作流程图：
)

与传统RAG的对比

传统RAG（检索增强生成）：

用户查询 → 静态检索相似文档 → 生成答案

• 一次性检索
• 不能根据发现调整策略
• 可能检索到不相关的内容

多智能体研究系统：

用户查询 → 动态多步搜索 → 评估与调整 → 深度分析 → 生成答案

• 迭代式搜索
• 根据中间结果动态调整
• 智能评估信息质量
• 可以深入挖掘特定方向

---

提示词工程：让智能体更智能

提示词（Prompt）是引导AI智能体行为的关键。在多智能体系统中，提示词工程变得更加复杂，因为需要协调多个智能体的行为。

什么是提示词工程？

提示词工程是设计和优化给AI的指令，使其更准确地理解和完成任务的过程。

简单类比：

• 给人类员工的工作说明书
• 说明书写得越清晰、越具体，员工工作效果越好
• 但也不能过于死板，需要给出灵活空间

早期遇到的问题

Anthropic在开发过程中遇到的典型失败案例：

1. 过度生成子智能体

   • 问题：简单查询也创建50个子智能体
   • 原因：没有明确的资源分配规则
   • 后果：浪费资源，响应缓慢

2. 无效搜索循环

   • 问题：无休止地搜索不存在的信息
   • 原因：没有设置何时停止的标准
   • 后果：永远无法完成任务

3. 工作重复

   • 问题：多个子智能体做相同的事情
   • 原因：任务描述不够具体
   • 后果：浪费资源，效率低下

八大提示词工程原则

原则1：像智能体一样思考

核心思想：要改进提示词，必须理解智能体如何"思考"。

实践方法：

• 使用Anthropic Console构建模拟环境
• 使用真实的提示词和工具
• 逐步观察智能体的决策过程

发现的问题示例：

• 智能体在已有足够结果时仍继续搜索
• 使用过于冗长的搜索查询
• 选择了错误的工具

改进方法：

• 添加"停止条件"指令
• 提示使用简短查询
• 明确工具使用场景

原则2：教编排器如何委派

核心思想：主智能体需要学会有效分配任务。

错误示例（过于简单）：

主智能体 → 子智能体："研究半导体短缺"

问题：

• 任务太模糊
• 子智能体不知道具体要做什么
• 可能重复工作或遗漏重要信息

正确示例（详细且明确）：

主智能体 → 子智能体：
任务：研究2025年当前的半导体供应链状况
具体目标：
  1. 查找主要半导体制造商的产能数据
  2. 识别当前的供应瓶颈
  3. 分析地缘政治因素的影响
输出格式：
  - 制造商列表及产能
  - 供应链图表
  - 风险因素清单
使用工具：
  - 优先使用行业报告（web_search: "semiconductor supply chain report 2025"）
  - 查询制造商官网（web_fetch）
  - 如需要，使用财务数据工具
任务边界：
  - 只关注2024-2025年的数据
  - 不包括历史上的短缺（如2021年汽车芯片危机）
  - 专注于供应端，不深入需求端分析

效果：

• 子智能体明确知道要做什么
• 不会与其他子智能体重复工作
• 能够交付符合预期的结果

原则3：根据查询复杂性调整工作量

核心思想：不同任务需要不同级别的投入。

规模化规则（嵌入到提示词中）：

任务类型	子智能体数量	每个智能体的工具调用	示例
简单事实查找	1个	3-10次	“谁是苹果公司CEO？”
直接比较	2-4个	10-15次	“比较iPhone和三星旗舰机”
中等研究	3-7个	15-25次	“分析电动车行业现状”
复杂研究	10+个	25-50次	“全面分析AI对就业市场的影响”

提示词示例：

根据查询复杂度分配资源：
- 如果是单一事实查询（如"XX的股价"），使用1个智能体，3-5次搜索
- 如果需要比较2-3个实体，使用2-3个子智能体并行调查
- 如果是开放性研究（如"XX行业趋势"），使用5-10个子智能体，明确分工
- 每个子智能体应在15-30次工具调用内完成任务，除非任务特别复杂

原则4：工具设计和选择至关重要

核心思想：选对工具是成功的一半。

问题场景：

• 用户问：“我们Q3的销售数据如何？”
• 错误：智能体在网上搜索
• 正确：智能体应该查询内部数据库或Google Drive

工具选择启发式规则（提示词示例）：

工具选择指南：
1. 首先检查所有可用工具的描述
2. 根据用户意图匹配工具：
   - 内部信息（"我们的"、"公司的"）→ 优先使用Google Drive、Slack等内部工具
   - 公开信息（"市场上"、"行业内"）→ 使用web_search
   - 实时数据（"当前"、"最新"）→ 使用专门的数据API
   - 技术问题（"代码"、"bug"）→ 使用GitHub API、Stack Overflow搜索
3. 优先使用专用工具而非通用工具
4. 如果不确定，可以先使用web_search了解情况，再决定用哪个专用工具

工具描述质量的重要性：

❌ 糟糕的工具描述：

{
  "name": "data_tool",
  "description": "Gets data"
}

智能体无法理解何时使用这个工具。

✅ 良好的工具描述：

{
  "name": "financial_database_query",
  "description": "查询公司内部财务数据库。可获取季度收入、支出、利润等财务指标。数据范围：2020年至今。适用于分析公司财务表现、预算执行情况。不包含员工个人薪资数据。",
  "parameters": {
    "metric": "收入/支出/利润/现金流",
    "time_period": "YYYY-Q1格式，如2024-Q3",
    "department": "可选，按部门筛选"
  }
}

原则5：让智能体自我改进

核心思想：Claude模型本身可以是优秀的提示词工程师。

自动化改进流程：

1. 工具测试智能体的工作流程：

1. 接收一个有缺陷的工具描述
2. 尝试使用该工具完成各种任务（测试几十次）
3. 记录所有失败案例和困惑点
4. 分析失败原因
5. 重写工具描述，添加：
   - 更清晰的使用场景说明
   - 常见错误的警告
   - 参数的详细解释
   - 输出格式的示例
6. 再次测试新描述

效果：

• 任务完成时间减少40%
• 智能体避免了大部分常见错误
• 工具使用更加精准

示例：改进前后对比

改进前：

{
  "name": "search_documents",
  "description": "搜索文档"
}

智能体遇到的问题：

• 不知道能搜索哪些类型的文档
• 不知道搜索语法
• 返回结果太多，不知道如何筛选

改进后：

{
  "name": "search_documents",
  "description": "在公司文档库中搜索文档。支持PDF、Word、Excel、PPT格式。返回最相关的前10个结果。",
  "best_practices": [
    "使用2-4个关键词，不要使用完整句子",
    "如果结果太多，添加时间或部门筛选",
    "搜索人名时使用全名以提高准确性"
  ],
  "parameters": {
    "query": "搜索关键词，建议2-4个词",
    "file_type": "可选：pdf/docx/xlsx/pptx，默认搜索所有类型",
    "date_range": "可选：2024-01-01至2024-12-31格式",
    "department": "可选：销售/研发/市场等"
  },
  "example": {
    "query": "Q3 销售报告",
    "file_type": "pdf",
    "date_range": "2024-07-01至2024-09-30"
  }
}

原则6：先广后窄

核心思想：模仿专家研究策略——先了解全局，再深入细节。

智能体的常见错误：

• 直接使用非常具体、冗长的查询
• 如：“2025年第三季度中国东部地区新能源汽车销量前十名企业的详细财务数据和市场份额变化趋势分析”
• 结果：搜索引擎找不到精确匹配，返回0结果

正确的搜索策略（写入提示词）：

搜索策略指南：
阶段1 - 广度探索（1-3个关键词）：
  - 先用简短、广泛的查询了解全局
  - 示例："新能源汽车 中国"
  - 目的：了解有哪些信息可用，识别主要来源

阶段2 - 评估与规划：
  - 评估初步结果
  - 识别重要的子主题
  - 决定需要深入哪些方向

阶段3 - 定向深入（4-6个关键词）：
  - 根据初步发现，细化查询
  - 示例："新能源汽车 销量 2025 Q3"
  - 目的：获取具体数据

阶段4 - 精确定位（如果需要）：
  - 查找特定数据点
  - 示例："比亚迪 销量 2025年9月"
  - 目的：补充细节

实际效果对比：

❌ 直接使用具体查询：

查询："2025年9月中国新能源汽车市场占有率前十名企业销量数据"
结果：0条相关结果（查询过于具体）

✅ 先广后窄策略：

查询1："新能源汽车 中国 2025"
→ 发现：多个行业报告、新闻文章、数据网站

查询2："新能源汽车 销量 2025"
→ 发现：月度销量数据、同比分析

查询3："比亚迪 理想 蔚来 销量 2025年9月"
→ 发现：具体企业的详细销量数据

结果：成功获取所需信息

原则7：引导思考过程

核心思想：让智能体"显式思考"，提高决策质量。

Extended Thinking（扩展思考）模式：

• Claude输出额外的"思考过程"tokens
• 这个思考过程对用户可见
• 类似于"在草稿纸上打草稿"

主智能体使用思考来规划：

<thinking>
让我分析这个查询："比较2025年中美AI政策的异同"

1. 任务分解：
   - 需要了解中国的AI政策
   - 需要了解美国的AI政策
   - 需要对比分析

2. 工具选择：
   - web_search：查找政策文件和新闻
   - web_fetch：获取完整的政策文档

3. 子智能体规划：
   - 子智能体1：研究中国AI政策（专注政府文件、官方声明）
   - 子智能体2：研究美国AI政策（专注白宫发布、国会法案）
   - 子智能体3：查找专家分析和对比文章

4. 复杂度评估：中等，需要3个子智能体，每个10-15次搜索

5. 时间估计：5-8分钟
</thinking>

好的，我将创建3个专业子智能体来研究这个问题...

子智能体使用Interleaved Thinking（交错思考）：

在每次工具调用后，评估结果质量：

[执行搜索："中国AI政策 2025"]
[获得10个搜索结果]

<thinking>
评估这些结果：
- 结果1-3：新闻报道，信息较浅
- 结果4：政府白皮书，非常相关！
- 结果5-7：评论文章，可以作为补充
- 结果8-10：旧新闻（2023年），不够新

决策：
1. 首先web_fetch获取结果4（白皮书）的完整内容
2. 然后搜索更多官方政策文件
3. 如果信息足够，可以结束；如果不够，继续搜索
</thinking>

接下来我将获取政府白皮书的完整内容...

效果：

• 指令遵循能力提升
• 推理质量改善
• 搜索效率提高
• 能更好地适应各种任务

原则8：并行工具调用

核心思想：速度就是生产力，并行处理大幅提升效率。

串行执行的问题（早期版本）：

时间线：
0分钟：开始搜索来源1
2分钟：搜索来源1完成
2分钟：开始搜索来源2
4分钟：搜索来源2完成
4分钟：开始搜索来源3
6分钟：搜索来源3完成
...
总耗时：如果需要搜索20个来源，需要40分钟

并行执行的改进：

第1层并行：主智能体并行创建子智能体

时间点0：同时创建5个子智能体
├ 子智能体1 启动
├ 子智能体2 启动
├ 子智能体3 启动
├ 子智能体4 启动
└ 子智能体5 启动

5个智能体同时工作，而不是一个接一个

第2层并行：每个子智能体并行使用多个工具

子智能体1在时间点0同时：
├ web_search: "AI政策 中国"
├ web_search: "人工智能 监管 中国"
└ web_search: "AI发展规划 中国"

3个搜索同时进行，而不是依次执行

效果对比：

串行方式：

总任务：研究10个主题，每个主题搜索4个来源
执行方式：1个智能体，逐个搜索
总工具调用：10 × 4 = 40次
执行时间：40 × 30秒 = 20分钟

并行方式：

总任务：研究10个主题，每个主题搜索4个来源
执行方式：5个子智能体并行，每个智能体并行调用3个工具
总工具调用：仍然是40次，但并行执行
执行时间：(10 ÷ 5) × (4 ÷ 3) × 30秒 ≈ 2分钟

效率提升：90%（20分钟 → 2分钟）

实现细节：

在提示词中明确并行策略：

并行执行规则：
1. 如果需要创建多个子智能体，一次性全部创建，不要等待一个完成再创建下一个
2. 每个子智能体应该尽可能并行调用多个工具（通常3-5个）
3. 只有当后续工具调用依赖前一个结果时，才串行执行
4. 例如：
   - 可以并行：同时搜索"公司A收入"和"公司B收入"
   - 必须串行：先搜索找到公司网址，再web_fetch获取该网址内容

启发式方法 vs 硬性规则

Anthropic的提示词策略重点：

✅ 推荐：启发式方法（灵活指导）

原则：复杂查询通常需要5-10个子智能体
示例："如果查询涉及多个独立维度，考虑为每个维度创建一个子智能体"

❌ 避免：硬性规则（僵化限制）

规则：必须创建正好7个子智能体
问题：无法适应不同复杂度的查询

人类研究策略的编码：

• 将困难问题分解为小任务
• 仔细评估来源质量
• 根据新信息调整搜索方法
• 识别何时深入（depth）vs 广度（breadth）

防护措施：

防止失控的明确限制：
- 单个任务最多创建15个子智能体
- 每个子智能体最多50次工具调用
- 如果连续3次搜索无结果，停止并报告
- 总执行时间不超过30分钟

---

评估体系：如何衡量智能体表现

在传统软件开发中，评估相对简单：给定输入A，检查输出是否等于预期的B。但智能体系统不同——即使输入相同，每次执行的路径也可能完全不同。

为什么评估多智能体系统很困难？

传统软件：

输入：2 + 2
过程：执行加法
输出：4
评估：输出是否等于4？✓

多智能体系统：

输入："分析特斯拉的竞争优势"
过程1：智能体A搜索了3个来源，花费2分钟
过程2：智能体B搜索了10个来源，花费5分钟
输出1：分析报告（着重技术优势）
输出2：分析报告（着重市场地位）
评估：都是合理的答案，但路径和角度完全不同

核心挑战：

• ❌ 不能要求智能体遵循固定步骤（因为合理路径有很多条）
• ❌ 不能简单对比输出文本（因为表述方式多样）
• ✅ 需要评估结果是否达到目标，过程是否合理

三层评估策略

第1层：小样本快速迭代

何时使用：开发早期，快速验证改进方向

方法：

• 准备20个代表性查询
• 每次修改提示词后测试这20个查询
• 观察成功率变化

为什么有效：

• 早期阶段，改进的影响很大（如30% → 80%成功率）
• 效果明显到不需要大规模统计就能看出
• 快速反馈循环，加速迭代

示例：

测试集（20个查询）：
1. "谁是OpenAI的CEO？" (简单事实)
2. "比较GPT-4和Claude的优缺点" (对比)
3. "分析大语言模型的发展趋势" (综合研究)
...
20. "帮我找到AI伦理方面的学术论文" (文献检索)

改进前成功率：8/20 = 40%
修改提示词（添加工具选择规则）
改进后成功率：17/20 = 85%
结论：改进有效！

常见误区：

• 等到能构建几百个测试用例才开始评估 ❌
• 正确做法：立即开始，哪怕只有10个测试用例 ✓

第2层：LLM作为评判员（可扩展评估）

何时使用：需要评估大量输出，人工评估不现实

为什么用LLM当评判员：

• 研究输出是自由文本，很难用代码评估
• 很少有"唯一正确答案"
• LLM可以像人类一样理解内容质量

评估维度（Anthropic的rubric）：

评分标准（每项0.0-1.0分）：

1. 事实准确性 (Factual Accuracy)
   - 声明是否与来源匹配？
   - 是否有捏造的信息？
   - 评分示例：
     1.0分：所有事实都准确，有可靠来源
     0.5分：大部分准确，但有小错误
     0.0分：包含明显错误或捏造

2. 引用准确性 (Citation Accuracy)
   - 引用的来源是否真实存在？
   - 引用是否支持相应的声明？
   - 评分示例：
     1.0分：所有引用准确对应
     0.5分：引用基本准确但位置有偏差
     0.0分：引用错误或缺失

3. 完整性 (Completeness)
   - 是否涵盖了查询的所有方面？
   - 是否遗漏重要信息？
   - 评分示例：
     1.0分：全面覆盖所有要求
     0.5分：涵盖主要内容但有遗漏
     0.0分：严重不完整

4. 来源质量 (Source Quality)
   - 是否使用了高质量的主要来源？
   - 是否避免了低质量来源？
   - 评分示例：
     1.0分：主要使用权威来源（学术论文、官方文档）
     0.5分：混合使用高质量和中等质量来源
     0.0分：主要使用低质量来源（内容农场、论坛）

5. 工具效率 (Tool Efficiency)
   - 是否使用了正确的工具？
   - 工具调用次数是否合理？
   - 评分示例：
     1.0分：工具选择正确，调用次数合理
     0.5分：有些工具使用不当，但完成任务
     0.0分：工具选择错误，浪费资源

LLM评判员的提示词示例：

你是一个研究质量评估专家。请评估以下AI生成的研究报告。

用户查询：{query}
AI输出：{output}
使用的来源：{sources}

评估任务：
1. 阅读输出和来源
2. 按照评分标准打分（0.0-1.0）
3. 给出总体评价（通过/不通过）
4. 解释评分理由

输出格式（JSON）：
{
  "factual_accuracy": 0.9,
  "citation_accuracy": 0.85,
  "completeness": 0.95,
  "source_quality": 0.8,
  "tool_efficiency": 0.9,
  "overall_score": 0.88,
  "pass": true,
  "reasoning": "报告全面准确，引用恰当..."
}

实验结果：

• 尝试了多个评判员分别评估不同维度
• 发现单个LLM调用评估所有维度更一致
• 与人类判断的一致性高

特别有效的场景：
测试用例有明确答案时，LLM评判员只需检查答案是否正确：

查询："列出研发预算前3的制药公司"
正确答案：[辉瑞, 罗氏, 强生]
AI输出：[辉瑞, 罗氏, 强生, 默沙东]
评估：错误（包含了第4名）

第3层：人工评估（捕捉边缘情况）

何时使用：发现自动化评估遗漏的问题

人类测试者发现的问题：

1. 微妙的来源选择偏见

观察：智能体总是选择SEO优化的内容农场
而忽视：
  - 学术PDF（排名较低但更权威）
  - 个人博客（专家洞察但不流行）
  - 政府文档（权威但网站老旧）

解决：在提示词中添加来源质量启发式
"优先选择：
 1. 学术论文和研究报告
 2. 官方文档和政府网站
 3. 知名媒体和专业博客
 避免：
 1. SEO内容农场
 2. 未经证实的社交媒体内容
 3. 过于老旧的信息（除非研究历史）"

2. 不寻常查询的幻觉

查询："xxx小众技术的最新发展"
问题：智能体编造了不存在的公司和产品
原因：搜索结果很少，但智能体试图给出"完整"答案

解决：添加"不确定性处理"规则
"如果搜索结果很少或不可靠：
 1. 明确说明信息有限
 2. 只报告确实找到的信息
 3. 不要填补空白
 4. 建议用户如何获取更多信息"

3. 系统性失败模式

观察：在特定类型的查询中总是失败
例如：需要多步推理的问题
"找到标普500公司中，CEO年龄最小的10家公司的创始人"

需要：
1. 获取标普500列表
2. 查找每家公司CEO
3. 查找每个CEO年龄
4. 排序找到前10
5. 查找这些公司的创始人

失败原因：智能体在步骤2就放弃了

解决：改进任务分解提示
"对于多步骤查询：
 1. 先明确列出所有步骤
 2. 创建检查点来跟踪进度
 3. 每完成一步，评估是否可以继续
 4. 不要试图一次性完成所有步骤"

为什么人工评估不可或缺：

• 发现罕见但严重的问题
• 理解用户真实体验
• 发现评估盲点
• 激发新的改进想法

涌现行为的挑战

什么是涌现行为：系统整体表现出未被明确编程的行为

示例：

修改前：主智能体提示词添加"尽量详细"
期望：主智能体给出更详细的指示

实际涌现：
1. 主智能体给子智能体的指示变长了（预期内）
2. 子智能体开始过度搜索（未预期）
3. 子智能体之间开始重复工作（未预期）
4. 整体效率下降50%（未预期）

原因：
- "尽量详细"被子智能体理解为"搜索越多越好"
- 详细的指示导致子智能体工作重叠
- 主智能体花太多时间写指示，反而降低效率

应对策略：

1. 全面测试：改动后测试完整工作流
2. 监控交互：观察智能体之间的交互模式
3. 迭代调整：小步快跑，及时发现问题
4. 建立框架：不是严格指令，而是协作框架

---

生产环境的挑战与解决方案

将原型变成可靠的生产系统，是一段充满挑战的旅程。对于多智能体系统，这段旅程比预期更长、更复杂。

挑战1：智能体是有状态的，错误会复合

什么是"有状态"：
智能体在长时间运行中保持和更新信息，每个决策都基于之前的状态。

类比：

• 无状态服务：像快餐店点餐，每次都是独立的交易
• 有状态智能体：像侦探办案，每个线索都影响下一步调查方向

问题场景：

正常流程（10步骤）：
步骤1 ✓ → 步骤2 ✓ → 步骤3 ✓ → ... → 步骤10 ✓
结果：成功

出错流程：
步骤1 ✓ → 步骤2 ✓ → 步骤3 ✗ (工具失败)
↓
智能体状态混乱
↓
步骤4-10 全部基于错误状态执行
↓
结果：完全失败

如果步骤3重启：
- 成本：前2步的所有工作（可能已用数万tokens）
- 用户体验：等待几分钟后被告知"请重新开始"

Anthropic的解决方案：

1. 持久化执行（Durable Execution）

# 伪代码示例
class ResearchAgent:
    def __init__(self):
        self.checkpoints = []  # 保存检查点
        
    def execute_task(self, task):
        try:
            # 执行前保存检查点
            checkpoint = self.save_checkpoint()
            result = self.perform_search(task)
            return result
        except ToolError as e:
            # 出错时，从检查点恢复
            self.restore_checkpoint(checkpoint)
            # 让智能体知道工具失败了
            return self.handle_error(e)
    
    def handle_error(self, error):
        # 给智能体提供错误信息，让它自己决定怎么办
        context = f"工具调用失败：{error}。请尝试其他方法。"
        return self.continue_with_context(context)

2. 智能错误处理

传统方式：
工具失败 → 整个任务失败 → 返回错误

Anthropic方式：
工具失败 → 通知智能体 → 智能体自适应

示例：
智能体："我需要查询Google Drive"
系统："Google Drive工具当前不可用"
智能体："那我改用web_search在公开文档中查找"
或
智能体："我了解了，我会告诉用户需要启用Google Drive权限"

3. 定期检查点（Checkpoints）

长任务执行过程：
0分钟：开始，保存检查点0
5分钟：完成阶段1，保存检查点1
10分钟：完成阶段2，保存检查点2
12分钟：阶段3出错 → 从检查点2恢复（而不是从头开始）
14分钟：继续执行
20分钟：完成

如果没有检查点：
12分钟出错 → 从头开始 → 再花12分钟 → 再次出错的风险

4. 结合确定性保护

# 重试逻辑
def call_tool_with_retry(tool, params, max_retries=3):
    for attempt in range(max_retries):
        try:
            return tool(params)
        except TransientError as e:
            if attempt < max_retries - 1:
                wait_time = 2 ** attempt  # 指数退避
                sleep(wait_time)
                continue
            else:
                # 最后一次尝试失败，通知智能体
                raise ToolPermanentlyFailed(e)

挑战2：调试需要新方法

传统软件调试：

问题："函数返回了错误的结果"
调试方法：
1. 查看代码
2. 设置断点
3. 逐步执行
4. 检查变量值
5. 找到bug，修复

智能体系统调试：

问题："智能体没找到明显的信息"
挑战：
1. 智能体每次运行路径不同
2. 无法"逐步执行"（决策是神经网络做的）
3. 不知道智能体"为什么"这样做
4. 无法简单重现问题

Anthropic的调试工具链：

1. 全链路追踪（Full Production Tracing）

用户报告："智能体说找不到xxx公司的信息"

传统日志：
[INFO] Task started
[INFO] Search completed
[INFO] Task finished
→ 完全不知道发生了什么

完整追踪：
[00:00] 用户查询：xxx公司最新融资
[00:01] 主智能体分析：需要创建1个子智能体
[00:02] 子智能体创建：任务"查找xxx公司融资信息"
[00:03] 工具调用：web_search("xxx公司 融资")
[00:04] 搜索返回：0个结果
[00:05] 子智能体思考：搜索无结果，尝试不同关键词
[00:06] 工具调用：web_search("xxx company funding")
[00:07] 搜索返回：3个结果
[00:08] 工具调用：web_fetch(result_1_url)
[00:09] 网页返回：404错误
[00:10] 子智能体思考：链接失效，尝试其他结果
...
[01:30] 子智能体返回："未找到可靠信息"
[01:31] 主智能体响应用户："抱歉，找不到xxx公司的融资信息"

现在我们知道了：
1. 初始搜索关键词可能有问题（中文"xxx公司"没结果）
2. 英文搜索有结果，但链接失效
3. 智能体确实努力了，不是"偷懒"
4. 问题在于：来源质量差，或者智能体应该尝试更多变体

2. 决策模式监控

不监控个别对话内容（保护隐私）
而是监控：
- 工具使用模式：智能体更常用哪些工具？
- 失败模式：哪类查询总是失败？
- 资源使用：平均使用多少token？多少工具调用？
- 时间分布：在哪个步骤花费最多时间？

示例洞察：
发现：50%的失败案例都涉及工具X
分析：工具X的错误处理有问题
修复：改进工具X的描述和错误信息
结果：失败率下降30%

3. 可视化工具

流程图生成：
用户查询
  ↓
主智能体（耗时：2s，tokens：500）
  ├→ 子智能体1（耗时：30s，tokens：5000）
  │   ├ web_search（3次）
  │   ├ web_fetch（2次，1次失败）
  │   └ 返回结果A
  ├→ 子智能体2（耗时：45s，tokens：8000）
  │   ├ web_search（5次）
  │   ├ web_fetch（3次）
  │   └ 返回结果B
  └→ 子智能体3（耗时：25s，tokens：4000）
      ├ web_search（2次）
      └ 返回结果C
  ↓
主智能体汇总（耗时：5s，tokens：2000）
  ↓
返回用户

一眼看出：
- 子智能体2花时间最多（瓶颈在这里）
- 子智能体2的web_fetch全部成功（没有错误）
- 可能：子智能体2的任务更复杂，或搜索策略不够高效

挑战3：部署需要特殊策略

问题：智能体是长期运行的有状态系统

场景：

当前状态：
- 100个用户正在使用智能体
- 每个智能体运行在不同阶段：
  - 用户A的智能体：刚开始，在分析查询
  - 用户B的智能体：中期，3个子智能体正在搜索
  - 用户C的智能体：末期，正在汇总结果

现在要部署新版本代码...

传统部署方式（不适用）：

1. 停止所有服务
2. 部署新代码
3. 重启服务

问题：
- 用户A-C的智能体全部被中断
- 所有进度丢失
- 用户体验极差

Anthropic的解决方案：彩虹部署（Rainbow Deployment）

彩虹部署策略：
1. 保持旧版本继续运行
2. 启动新版本（并行运行）
3. 新用户 → 新版本
4. 老用户 → 继续使用旧版本（直到完成）
5. 逐渐增加新版本的流量
6. 所有旧用户完成后，关闭旧版本

时间线：
T0：100%流量在旧版本
T1：新版本启动，新用户 → 新版本（5%流量）
T2：新版本稳定，逐步增加（20%流量）
T3：继续增加（50%流量）
T4：大部分流量在新版本（80%流量）
T5：旧版本只服务剩余的长任务（10%流量）
T6：所有旧任务完成，旧版本关闭（100%新版本）

版本管理：

# 伪代码
class AgentVersionManager:
    def route_request(self, user_session):
        if user_session.has_active_agent():
            # 有活跃智能体：继续使用原版本
            version = user_session.agent_version
        else:
            # 新任务：使用最新版本
            version = self.get_latest_version()
        
        return self.get_agent(version)

好处：

• ✅ 无缝升级，用户无感知
• ✅ 保护进行中的任务
• ✅ 可以逐步验证新版本
• ✅ 出问题可以快速回滚

挑战4：同步执行的瓶颈

当前实现（同步）：

主智能体创建子智能体组1 [A, B, C]
↓
等待A, B, C全部完成
↓
主智能体评估结果
↓
主智能体创建子智能体组2 [D, E]
↓
等待D, E全部完成
↓
主智能体汇总结果

问题：
- 如果C很慢（5分钟），A和B早完成（1分钟），也要等
- 主智能体不能根据A和B的结果提前调整策略
- 子智能体之间不能协调（如果A发现B在做重复工作）

未来方向（异步）：

主智能体创建子智能体A
↓ (同时)
主智能体创建子智能体B
↓ (同时)
主智能体创建子智能体C
↓
A完成 → 主智能体立即收到 → 可以创建D基于A的结果
↓ (B和C仍在运行)
B完成 → 主智能体评估 → 发现B和C重复 → 停止C
↓
D完成 → 主智能体已经可以开始汇总（无需等C）

异步的好处：

1. 更好的资源利用：不等待最慢的子智能体
2. 动态调整：根据早期结果及时修正
3. 智能体协调：可以避免重复工作
4. 更快的完成时间：不被最慢的任务拖累

异步的挑战：

1. 状态一致性：多个智能体同时修改状态
2. 结果协调：如何合并异步返回的结果
3. 错误传播：一个智能体失败如何影响其他智能体
4. 复杂度：系统更难理解和调试

为什么还没实现：

• 当前模型处理的任务复杂度，同步执行已经足够
• 异步增加的复杂度 > 性能收益
• 但随着模型能力提升，异步会变得必要

---

总结与展望

从原型到生产：漫长的旅程

构建AI智能体时，"最后一英里"往往成为大部分旅程。

原型阶段（20%的时间）：

• 基本功能能跑通
• 在理想条件下表现良好
• Demo效果惊艳

生产化（80%的时间）：

• 处理各种边缘情况
• 确保长期稳定运行
• 优化性能和成本
• 建立监控和调试工具
• 处理并发和扩展性
• 实现平滑部署

为什么差距这么大：

1. 错误的复合性

   • 传统软件：一个bug影响一个功能
   • 智能体系统：一个小错误导致完全不同的执行轨迹

2. 非确定性

   • 传统软件：相同输入总是相同输出
   • 智能体系统：相同输入可能不同输出

3. 状态复杂性

   • 传统软件：大多无状态或简单状态
   • 智能体系统：长期运行的复杂状态

多智能体系统的价值

尽管面临挑战，多智能体系统已经证明了其价值。

用户反馈：

• 发现新机会：“Claude帮我找到了我从没想过的业务方向”
• 节省时间：“原本需要一周的研究，Claude几小时就完成了”
• 复杂决策支持：“在选择医疗方案时，Claude整理了我根本看不完的信息”
• 技术问题解决：“Claude追踪了多个相关的bug报告，帮我解决了困扰已久的技术问题”

量化价值：

• 节省研究时间：数小时到数天
• 信息覆盖度：比人工搜索多10-20倍来源
• 发现意外联系：人类可能遗漏的洞察

成功的关键要素

Anthropic总结的核心要素：

1. 精心设计的工程

   • 持久化执行
   • 错误恢复机制
   • 平滑部署策略

2. 全面的测试

   • 小样本快速迭代
   • LLM评判员可扩展评估
   • 人工发现边缘情况

3. 细致的提示词和工具设计

   • 清晰的任务委派
   • 高质量的工具描述
   • 灵活的启发式规则

4. 强大的运营实践

   • 完整的追踪和监控
   • 快速的调试工具
   • 主动的性能优化

5. 跨团队协作

   • 研究团队：理解模型能力边界
   • 产品团队：把握用户需求
   • 工程团队：确保系统可靠
   • 三方紧密合作，深刻理解当前智能体的能力

技术演进的方向

短期（已在进行）：

• 提升单个智能体的能力（更强的模型）
• 优化提示词策略（更好的指导）
• 改进工具生态（MCP等标准）

中期（未来1-2年）：

• 异步多智能体协调
• 更复杂的任务分解
• 跨会话的记忆和学习

长期（未来3-5年）：

• 自主学习和自我改进的智能体
• 更复杂的多智能体协作模式
• 接近人类团队的协作效率

对开发者的建议

如果你想构建自己的多智能体系统：

1. 从小开始

• 不要一开始就构建复杂系统
• 先让单智能体可靠工作
• 逐步增加复杂度

2. 重视评估

• 立即开始评估，哪怕只有几个测试用例
• 建立快速反馈循环
• 结合自动化和人工评估

3. 观察智能体行为

• 构建可视化工具
• 记录详细的追踪日志
• 理解智能体的"思维过程"

4. 注重用户价值

• 只在任务价值能覆盖成本时使用多智能体
• 关注用户真实需求，不被技术炫酷迷惑
• 持续收集反馈

5. 准备好迭代

• 多智能体系统需要大量调优
• 预期要花大量时间在生产化上
• 建立可持续的改进流程

---

附录：实用技巧

技巧1：端状态评估（适用于状态可变的智能体）

适用场景：智能体在多轮对话中修改持久状态

例子：

任务：使用智能体管理待办事项列表
智能体可以：添加、删除、修改、完成任务

传统评估（逐轮检查）：
第1轮：添加"买牛奶" → 检查是否正确添加 ✓
第2轮：添加"写报告" → 检查是否正确添加 ✓
第3轮：完成"买牛奶" → 检查是否正确标记 ✓
第4轮：删除"写报告" → 检查是否正确删除 ✓

问题：
- 如果智能体用不同方式达到相同目标怎么办？
- 如果智能体先删除再重新添加呢？
- 每一步都检查，评估脚本会非常复杂

端状态评估（更好）：

只检查最终状态：
初始状态：空列表
执行一系列命令后...
最终状态应该是：
- [ ] 写报告（未完成）
- [✓] 买牛奶（已完成）
- [ ] 开会（未完成）

评估：最终状态是否符合预期？✓

优点：
- 评估简单
- 允许智能体使用不同路径
- 更接近用户真实关心的事情（结果，而非过程）

检查点评估（平衡方案）：

对于复杂工作流，设置几个关键检查点：

检查点1（启动后）：应该创建了项目文件夹
检查点2（中期）：应该完成了数据收集
检查点3（结束前）：应该生成了报告草稿
检查点4（最终）：应该有完整的最终报告

这样既有一定的过程验证，又不会过度约束智能体

技巧2：长期对话管理

问题：生产环境中的智能体对话可能持续数百轮

挑战：

标准上下文窗口：200,000 tokens
长对话轻松超过：
- 100轮对话 ≈ 50,000 tokens
- 50个工具调用结果 ≈ 100,000 tokens
- 各种中间结果 ≈ 80,000 tokens
总计：230,000 tokens → 超出限制！

解决方案：分层记忆系统

第1层：短期记忆（上下文窗口）

保留最近的：
- 最近10轮对话
- 当前任务的工具调用
- 正在处理的文档

第2层：工作记忆（外部存储）

当完成一个阶段时：
1. 总结该阶段的工作
2. 提取关键发现
3. 存储到外部记忆系统
4. 从上下文中删除细节

示例：
完成"市场调研阶段"后：
存储总结：
{
  "phase": "市场调研",
  "key_findings": [
    "市场规模：100亿美元",
    "增长率：15%每年",
    "主要竞争对手：A、B、C公司"
  ],
  "sources": [链接列表],
  "completed_at": "2025-01-15"
}

从上下文中删除：
- 所有搜索详情
- 中间分析过程
- 原始搜索结果

第3层：长期记忆（持久化存储）

整个任务完成后：
- 最终报告
- 关键决策点
- 学到的经验

下次相似任务时可以参考

实现示例：

class ConversationManager:
    def __init__(self):
        self.context_window = []  # 短期记忆
        self.working_memory = {}  # 工作记忆
        self.long_term_memory = {}  # 长期记忆
        
    def add_turn(self, turn):
        self.context_window.append(turn)
        
        # 检查是否接近上下文限制
        if self.estimate_tokens() > 180000:
            self.compress_context()
    
    def compress_context(self):
        # 总结旧的对话
        summary = self.summarize_old_turns()
        
        # 存储到工作记忆
        self.working_memory[f"phase_{len(self.working_memory)}"] = summary
        
        # 从上下文中删除旧对话，只保留总结
        self.context_window = [
            {"role": "system", "content": f"之前的工作总结：{summary}"}
        ] + self.context_window[-20:]  # 保留最近20轮
    
    def spawn_fresh_subagent(self, task):
        # 创建新子智能体，只传递必要信息
        essential_context = self.extract_essential_context()
        return Subagent(task, context=essential_context)

关键技巧：

1. 主动压缩：不要等到超限才压缩
2. 选择性保留：不是所有历史都重要
3. 结构化总结：使用JSON等结构化格式，便于检索
4. 清晰切分：明确什么时候进入新阶段
5. 优雅降级：即使丢失一些历史，也不应该完全失败

技巧3：子智能体输出到文件系统

问题："传话游戏"导致信息失真

场景：

子智能体A（生成了3000字的详细分析）
↓ 通过对话传给
主智能体（总结成500字）
↓ 通过对话传给
子智能体B（基于500字工作）

信息损失：3000字 → 500字 → 可能遗漏关键细节

解决方案：使用文件系统（或外部存储）

实现方式：

class SubagentWithFileSystem:
    def complete_analysis(self):
        # 进行详细分析
        detailed_report = self.analyze_data()
        
        # 将完整报告存储到文件
        report_id = self.save_to_filesystem(detailed_report)
        
        # 只返回引用和简要总结给主智能体
        return {
            "summary": "分析了100个数据点，发现3个关键趋势...",
            "report_id": report_id,  # 其他智能体可以通过这个ID访问完整报告
            "key_findings": [...]
        }

好处：

1. 信息完整性

   • 其他智能体可以访问原始详细内容
   • 不依赖主智能体的总结能力

2. Token效率

   • 不需要在对话中复制大量文本
   • 主智能体的上下文只包含引用

3. 并行访问

   • 多个智能体可以同时读取同一份报告
   • 避免重复生成相同内容

适用场景：

✓ 代码文件（子智能体生成代码，其他智能体审查）
✓ 数据分析报告（详细的统计分析结果）
✓ 可视化图表（生成的图像或图表）
✓ 结构化数据（CSV、JSON等）

✗ 简短的事实性信息（直接在对话中传递更好）
✗ 需要即时讨论的内容（文件系统增加交互延迟）

实践示例：

任务：创建一个带AI功能的网站

主智能体规划：
1. 子智能体A：设计HTML结构
2. 子智能体B：写CSS样式
3. 子智能体C：实现JavaScript逻辑

传统方式（通过对话）：
主智能体 ← A返回HTML代码（2000行）
主智能体总结 → 传给B（可能遗漏细节）
主智能体 ← B返回CSS（1500行）
主智能体整合 → 传给C（整合可能出错）

文件系统方式：
A → 写入 /project/index.html
A → 返回主智能体：{file: "index.html", summary: "创建了响应式布局，包含导航、主体、页脚"}

B → 读取 /project/index.html（获取完整HTML结构）
B → 写入 /project/styles.css
B → 返回主智能体：{file: "styles.css", summary: "实现了现代设计，使用了CSS Grid"}

C → 读取 /project/index.html 和 /project/styles.css
C → 写入 /project/script.js
C → 返回主智能体：{file: "script.js", summary: "添加了交互功能和API调用"}

主智能体 → 读取所有文件，打包提供给用户

---

参考资源

官方资源

• Anthropic Research功能介绍
• Anthropic Cookbook - 开源提示词示例
• Model Context Protocol (MCP)
• Claude API文档

相关技术

• Extended Thinking：Claude扩展思考模式文档
• BrowseComp评估：OpenAI的浏览智能体评估基准
• Rainbow Deployment：彩虹部署策略说明

深入学习

• Anthropic的提示词工程指南
• 多智能体系统的学术研究
• 大语言模型应用的最佳实践

参考文章：

Googel Agent白皮书
[译] Anthropic 是如何构建 Multi-Agent Research 系统的（2025）