还记得你上次做复杂项目的时候吗？比如准备一份重要的商业提案，你需要查市场数据、分析竞争对手、整理财务预测，还要找各种引用资料。一个人干这活儿，基本上就是开十几个网页，复制粘贴到半夜，最后还担心数据有错。

现在想象一下，如果有一个AI团队来帮你——不是一个万能的AI，而是一群各有专长的AI，像真正的团队一样分工合作。主管负责制定策略，研究员各自负责不同模块，最后还有专人负责核查引用。

在 Anthropic 最新发布的工程报告中，他们仔细剖析了多智能体系统如何从“从 0 到 1”升级并落地——远非简单接龙式查询，而是构建了一套高效的“AI 团队”

一句话说完：Anthropic 不只是让 Claude 更聪明，而是把它变成一个“懂组织、会配合、能分工”的研究团队——把人类自上而下的协作方式搬到了 AI 上。解决复杂问题，不再是一个 prompt → 输出，而是：目标 → 拆解 → 协作 → 调度 → 整理 → 引用，也正是我们工作方式的真实投射。

一个让人瞠目结舌的对比实验

Anthropic做了个简单但震撼的测试：让AI完成这样一个任务——"列出S&P 500指数中所有信息技术类公司的董事会成员"。

单个Claude处理时，就像一个勤奋但笨拙的实习生：查一个公司，整理一下，再查下一个，线性处理，速度慢，还容易漏信息。

多智能体版本的Claude呢？就像一个高效的项目组：

• 主管快速制定查询策略

• 多个研究员同时处理不同公司

• 专门的质检员负责核实引用来源

• 最后统一汇总成完整报告

结果？完成率提升了90%！

这个数字背后的启示很简单：再聪明的个体，也比不过一个组织良好的团队。

AI版本的"公司组织架构"

Anthropic是怎么"管理"这支虚拟团队的？他们的做法特别像真实公司的运作：

主控智能体就是项目经理，负责拆解任务、分配工作。它会说："小张你查A公司的董事变动，只用官网和年报；小李你负责B公司，记得交叉验证。"

子智能体像各个部门的专员，每人接到具体任务后，自己去用工具查资料、判断信息真假、做初步总结。关键是它们知道自己的边界——不会越界做别人的活儿。

引用助手就是质检部门，专门检查所有引用是否靠谱，把内容和原始来源一一对应。

记忆系统像公司的文档管理，当任务复杂时，会把中间结果存起来，下次接着用。

最巧妙的是，这些AI不是按部就班地一个接一个工作，而是真正的并行作业。就像一个高效团队，大家同时开工，各干各的，最后汇总结果。

让AI学会"团队合作"的秘诀

很多人以为Anthropic是在写复杂的代码模板。其实不是，他们做的是另一件更聪明的事：研究"优秀的人是怎么合作的"，然后把这些协作智慧教给AI。

比如教会AI这些"职场常识"：

• 不抢别人活儿：每个AI都有明确的任务ID，知道自己该干什么，不该干什么

• 知道什么时候求助：如果查到的信息质量不好，会主动报告或请求支援，而不是硬着头皮瞎编

• 懂得资源管理：每个任务都有"搜索预算"，防止无限循环浪费资源

• 先宽后窄的策略：先用通用关键词探索，摸清大概情况后再精确搜索

更有意思的是，Anthropic甚至让Claude检查自己的工作失误，自己改进工作方式。就像员工定期总结经验教训，不断优化工作流程。

从Demo到真正上线的工程挑战

很多AI项目都卡在演示阶段，无法真正投入使用。Anthropic在工程实现上做了几个关键设计：

容错机制：一个AI出错了，不会拖累整个任务。就像团队里一个人请病假，其他人能顶上。

平滑升级：系统更新时用"彩虹部署"，确保正在进行的任务不受影响。

资源控制：多智能体系统"很费钱"，一个复杂任务可能消耗普通聊天15倍以上的资源。所以必须用在真正值得的场景上。

隐私保护：保留系统决策轨迹方便优化，但不记录用户隐私信息。

这套系统到底适合解决什么问题？

根据Anthropic的数据，最常见的使用场景是：

• 商业研究：企业画像、竞争分析、投资调研

• 信息验证：背景调查、事实核查、合规审查

• 内容创作：长篇写作、文献整理、知识体系构建

• 学术研究：论文脉络梳理、跨领域知识整合

简单说，如果你的问题"不是一句话能回答的"，就很适合多智能体系统来处理。

用户反馈中最常见的评价是："帮我节省了本该花几天的工作。"

重新思考AI的使用方式

看完Anthropic的这套系统，我最大的感触是：AI的未来可能不在于造出一个无所不能的"超级大脑"，而在于构建一个高效协作的"智能组织"。

人类解决复杂问题，从来不是靠一个最聪明的人，而是靠一群人的分工合作。Anthropic做的事情，本质上是用"组织行为学"的思路来重新设计AI系统。

这比单纯提升模型能力更有启发性。如果我们把AI看成"合作伙伴"而非"问答机器"，那么真正高效的AI工作流程可能是：

目标 → 拆解 → 分工 → 并行执行 → 整合 → 验证

这不就是我们人类团队协作的方式吗？

也许，AI的未来不是让机器变得更像超人，而是让机器学会像人一样协作。当AI懂得了开会、分工、汇报、复盘，它们就不再是工具，而成了真正的工作伙伴。

你觉得呢？在你的工作中，是更需要一个万能的AI助手，还是一个懂得分工合作的AI团队？欢迎在评论区分享你的想法和经验。

完整研究报告翻译

Anthropic：我们是如何构建多智能体研究系统的

Claude 现在具备了研究能力，能够跨网页、Google Workspace 和各类集成工具进行搜索，从而完成复杂任务。

这个多智能体系统从原型走向生产阶段的过程，让我们在系统架构、工具设计和提示词工程方面学到了至关重要的经验。一个多智能体系统由多个智能体（即在循环中自主调用工具的 LLM）协同工作组成。我们的 Research 功能包括一个负责制定研究流程的主控智能体，它会根据用户查询调用工具，并创建多个并行的子智能体同时搜索信息。多智能体系统带来了新的挑战，比如智能体间的协调、评估和可靠性保障。

这篇文章分解了我们总结出的有效原则——希望它们对你构建自己的多智能体系统时有所帮助。

多智能体系统的优势

研究类任务本质上是开放式问题，很难事先预测需要哪些步骤。你无法为探索复杂主题预设一条固定路径，因为研究过程是动态的、依赖于每一步发现的线索的。

当人类进行研究时，他们会根据新的发现不断调整策略，追踪在探索中浮现出的线索。

这种不可预测性使得 AI 智能体在研究任务中尤其适用。研究需要灵活性，要能在探索过程中转向或延伸至相关方向。模型必须在多个回合中自主决策，基于中间成果判断接下来要走哪条路。线性的一次性流水线方案无法胜任这类任务。

搜索的本质是压缩：从海量语料中提取出有价值的见解。子智能体通过并行运行、拥有各自的上下文窗口，同时探索问题的不同方面，再将最重要的 token 汇总给主控研究智能体，极大促进了信息压缩的效率。每个子智能体还可实现关注点的分离——使用不同的工具、提示词和探索路径——从而降低路径依赖、增强研究的独立性和完整性。

一旦模型智能达到某一临界点，多智能体系统就成为扩展性能的关键方式。例如，在过去十万年中，个体人类的智能虽有提升，但进入信息时代后，人类社会的整体能力实现了指数级增长，这得益于“集体智能”与协调能力。即使是通用智能体，作为个体也有极限；成群智能体协作可以实现远超单体能力的成就。

我们的内部评估表明：在需要同时追踪多个独立方向的“广度优先”查询中，多智能体系统的表现尤为出色。我们发现，在以 Claude Opus 4 为主控智能体、Claude Sonnet 4 为子智能体的系统中，整体性能相比单智能体 Claude Opus 4 提高了 90.2%。比如在查询“信息技术类 S&P 500 公司所有董事会成员”时，多智能体系统能将任务拆解分派给多个子智能体并行处理，而单智能体系统则只能顺序检索，效率低且结果不全。

多智能体系统之所以有效，是因为它们能在任务上“烧掉”足够多的 token。在我们对 BrowseComp（测试智能体查找难找信息能力）的分析中，影响性能的三个关键因素解释了 95% 的方差——其中“使用的 token 数量”单独就解释了 80% 的差异，另外两个是工具调用次数与模型选择。这验证了我们通过分布式架构设计提升 token 使用效率的策略，即利用不同上下文窗口的子智能体来提升并行推理能力。Claude 最新模型更进一步地提高了 token 使用效率：将 Sonnet 3.7 升级为 Sonnet 4，效果甚至优于直接翻倍 token 上限。多智能体架构能在超过单智能体处理能力的任务中充分发挥 token 预算的作用。

但也存在缺点：这种架构在实践中非常“烧 token”。我们的数据表明，一个普通的智能体交互平均消耗的 token 是一次聊天的 4 倍，而一个多智能体系统的 token 消耗大约是聊天的 15 倍。为了在经济上可行，多智能体系统必须应用在价值足够高的任务上，才能抵消性能带来的成本。此外，如果某个任务领域要求所有智能体共享完整上下文，或者智能体间存在大量强耦合依赖，那么目前的多智能体系统也并不适用。例如，大多数编程任务中并没有太多可并行处理的子任务，而 LLM 智能体目前还不擅长实时协作与分工。我们发现，多智能体系统最适合高价值、强并行、上下文超出单一窗口、以及需要与复杂工具交互的场景。

Research 架构概览

我们的 Research 系统采用多智能体架构，使用“协调者-工作者”模式，即主控智能体负责整体协调，而多个专职子智能体并行执行任务。

多智能体架构实战图示：用户的查询首先由主控智能体接收处理，它会创建多个专职子智能体，各自并行探索查询的不同方面。

当用户提交一个查询时，主控智能体会分析该查询、制定研究策略，并同时生成多个子智能体，分别去探索不同方向。如图所示，子智能体就像智能过滤器，迭代调用搜索工具，在这个例子中是收集 2025 年 AI 智能体公司的信息，之后将公司列表返回给主控智能体，后者再汇总为最终答案。

传统的检索增强生成（RAG）方法采用的是静态检索——根据输入查询，提取若干最相似的文本片段用于生成回答。而我们采用的架构则是动态的多步骤搜索，能够根据新发现的信息不断调整策略，并对结果进行分析，从而生成高质量的答案。

多智能体 Research 系统的完整工作流程图：用户提交查询后，系统创建一个 LeadResearcher 智能体并进入迭代研究流程。LeadResearcher 先思考整体策略并将研究计划保存至 Memory（用于持久化上下文），因为当上下文窗口超过 20 万 token 时，会发生截断，因此必须保留原始计划。随后，LeadResearcher 会创建多个专职子智能体（图示中为两个，实际可任意数量），分别承担具体的研究子任务。每个子智能体独立进行网页搜索，利用 交叉思考（interleaved thinking） 评估工具结果，并将发现返回主控智能体。LeadResearcher 汇总这些信息，并判断是否还需要进一步研究——如果需要，可以生成更多子智能体，或调整策略。一旦信息充足，系统便退出研究循环，并将所有结果交由 CitationAgent 处理，该智能体负责将研究内容与原始文档进行比对、定位引用出处，从而确保所有结论都有出处。最终带有引用信息的研究结果返回给用户。

针对研究智能体的提示词工程与评估机制

相比单智能体系统，多智能体系统面临的协调复杂度呈指数级增长。早期的智能体常常犯一些错误：比如为简单问题生成 50 个子智能体，在网上没完没了地搜索根本不存在的信息，或者频繁地互相打断更新进度，反而妨碍了任务推进。由于每个智能体的行为都由其提示词驱动，因此提示词工程成为我们优化这些行为的主要手段。以下是我们在优化提示词时总结的关键原则：

1. 像智能体那样思考。 想要优化提示词，必须理解它们的作用。为此我们在 Console 平台上构建了模拟环境，使用实际系统中的提示词与工具，逐步观察智能体的工作过程。这立刻暴露了很多失败模式：智能体在已有足够信息时仍继续搜索、生成冗长的搜索查询、或选择了错误的工具。提示词调优的关键是建立起对智能体行为的准确心理模型，很多影响深远的优化都来自这种理解。

2. 教会协调者如何分派任务。 在我们的系统中，主控智能体需要将一个查询拆解成若干子任务，并描述给各个子智能体。每个子智能体都必须明确：研究目标、输出格式、可用工具和资源、任务边界。如果这些信息不清晰，智能体就可能重复劳动、遗漏关键部分、或找不到正确信息。我们最初允许主控智能体仅用一句话说明任务，比如“研究半导体短缺情况”，但实际发现这种描述太模糊，子智能体往往误解任务或进行重复检索。比如，一个智能体研究 2021 年的汽车芯片危机，另外两个则都在查找 2025 年的供应链情况，没有合理的分工。

3. 将任务复杂度与资源分配挂钩。 智能体不擅长判断任务所需的工作量，因此我们在提示词中加入了“规模控制规则”。简单的事实查询只需 1 个智能体、调用 3-10 次工具；比较任务需要 2-4 个子智能体，每个调用 10-15 次工具；复杂研究任务则可能需要超过 10 个子智能体、每个都有明确分工。这种显式规则帮助主控智能体合理分配资源，避免在简单任务中“过度投资”——这是我们早期版本常见的错误模式。

4. 工具的设计与选择至关重要。 智能体与工具之间的接口就像人类与计算机之间的 UI 界面一样关键。用对了工具，就能高效完成任务——有时甚至是唯一可行的方式。比如，一个智能体试图在网页上搜索只有 Slack 里才存在的信息，那肯定是徒劳无功。在引入 MCP server 后，模型可以接入外部工具，但由于工具描述质量参差不齐，这个问题变得更严重。我们明确要求智能体在使用工具前先浏览一遍工具列表、结合用户意图选择合适工具、做泛化探索时优先用 Web 工具、在有专用工具时避免使用通用工具。一个差劲的工具描述会彻底带偏智能体方向，因此每个工具都必须定义清晰、用途单一。

5. 让智能体自我改进。 Claude 4 系列模型在提示词工程方面表现出色。只需提供一个失败案例和相应提示词，它们就能分析失败原因并提出改进方案。我们甚至创建了“工具测试智能体”：给它一个存在问题的 MCP 工具，它会尝试使用，并重写工具描述以避免错误。这个智能体对工具进行了数十次测试，识别出各种细节和 bug。我们通过这一过程显著提升了工具的易用性，后续使用新描述的智能体完成任务所需时间平均减少 40%。

6. 先广后深。 搜索策略应当模仿人类专家的做法：先整体扫一遍，再深入具体细节。智能体经常会默认使用冗长、具体的搜索语句，结果却一无所获。为此我们在提示词中明确要求先用简短、广义的关键词进行第一轮搜索，然后评估结果，再逐步聚焦方向。

7. 引导其“思考过程”。 我们使用 延展思维模式，使 Claude 显式输出其“思考路径”——这类似一个可控的草稿区。主控智能体会用这个模式进行任务规划，判断使用哪些工具、判断查询的复杂度和子智能体的数量、为每个子智能体定义任务。测试表明，这显著提升了智能体的指令执行力、推理质量和整体效率。子智能体也会先规划，再在获取工具结果后进行交叉思考：评估信息质量、发现遗漏、优化下一步查询策略，从而更好地适应任务需求。

8. 并行工具调用能显著提升速度和效果。 复杂研究任务往往需要从多个来源探索信息。我们早期的智能体依赖顺序检索，这极慢。为此我们采用两层并行策略：（1）主控智能体一次性生成 3-5 个子智能体；（2）每个子智能体同时调用多个工具。这种设计将复杂查询的研究时间缩短了约 90%，不仅显著提速，也让 Research 系统在几分钟内完成以往数小时工作，同时覆盖更多信息。

我们的提示词策略侧重于传授“策略性启发”而非“死规则”。我们研究了熟练人类如何完成研究任务，并将其策略编码进提示词中——比如：如何将复杂问题拆解为子问题、如何评估信息质量、如何根据中间发现调整方向、何时应从深度研究转向广度探索。我们也预设了安全边界，防止智能体“无限扩散”。最终，我们依靠快速迭代、精细可观测性和测试用例闭环来不断优化提示词策略。

有效评估智能体系统

构建可靠的 AI 应用离不开良好的评估机制，多智能体系统也不例外。但评估多智能体系统本身就面临独特挑战。传统评估通常假设 AI 每次都遵循同一组步骤：输入 X，系统应该走路径 Y，最终输出 Z。但多智能体系统并不是这样运作的。即便起点完全相同，不同智能体也可能选择截然不同但同样合理的路径达成目标。比如一个智能体查阅了 3 个信息源，另一个可能用了 10 个工具，或者选择了不同工具但得到了相同答案。

由于我们往往事先并不知道“正确步骤”是什么，因此无法仅通过比对路径来判断对错。我们需要更灵活的评估方式，既能判断结果是否正确，也能衡量过程是否合理。

从一开始就用小样本启动评估。 智能体开发早期的改动往往影响巨大，提升空间充足，属于“低垂果实”。一个简单的提示词改动可能将成功率从 30% 提升到 80%。在这种效果差异显著的阶段，几个用例就足以显现成效。我们从大约 20 个真实使用场景出发，反复测试这些查询，以便明确评估提示词和工具改动的影响。我们经常听说，AI 团队推迟构建评估系统，是因为认为必须有成百上千个测试样本才有价值。但实际上，最好从一开始就用几个例子进行小规模评估，而不是等到有能力做大规模测试再开始。

当使用得当时，“LLM 评审”是可扩展方案。 研究任务的输出是自由格式文本，很少有唯一标准答案，因此难以用传统程序化方式评估。这类场景非常适合使用 LLM 担任“评分员”。我们使用了一个由大模型构成的“评判者”，它根据预设评分标准对每个输出打分：包括事实准确性（陈述是否符合来源）、引用准确性（引文是否确实支持该陈述）、覆盖完整性（是否涵盖所有用户要求的信息）、信息源质量（是否优先使用权威来源而非低质量二级网页）以及工具使用效率（是否合理使用工具，次数是否过多或过少）。

我们曾尝试多个评分模型分别评估不同维度，但最终发现：使用一个 LLM，在一个提示词中输出从 0.0 到 1.0 的各项评分以及最终通过/未通过的结果，是最一致、最符合人工判断的方式。尤其在测试用例确实存在“正确答案”时（例如“列出研发投入最高的三家制药公司”），该方法评估表现极好。使用 LLM 评审让我们可以扩展评估规模，轻松评估数百份输出。

人工评估能发现自动机制忽略的盲点。 人类测试者可以发现评估系统遗漏的边缘情况，比如某些奇怪查询中模型产生了幻觉性回答、系统组件崩溃、或选择了偏向 SEO 的低质量信息源等。以我们的经验为例，早期版本的智能体经常选择高度优化的“内容农场”网页，而不是那些权威性更高但排名不高的来源，比如学术 PDF、博客、非主流站点等。我们在提示词中加入了“信息源质量启发规则”，成功缓解了这一问题。

即使评估系统高度自动化，人工测试仍不可或缺。

多智能体系统会出现“涌现行为”，也就是说，即使没有明确编程指定，也可能出现意想不到的协作模式。例如，对主控智能体的微小提示词调整，就可能导致子智能体的行为方式大幅变化。因此，构建成功系统的关键，不只是关注单个智能体行为，还要理解各智能体之间的交互结构。

这也意味着，最有效的提示词不只是任务说明，而是一整套“协作框架”：它要定义清晰的分工策略、解决问题的方法路径、执行资源分配逻辑（例如分配 token 预算、调用次数等）。想要做好这些，离不开高质量的提示词设计、合理的工具接口、有效的行为准则、强大的可观测性与快速反馈迭代机制。

你可以在我们的 Anthropic Cookbook 中查看这些实际系统所使用的提示词示例。

生产级稳定性与工程挑战

在传统软件开发中，bug 可能导致某个功能失效、性能下降、或者系统崩溃。而在智能体系统中，哪怕是微小改动，也可能引发行为的大规模级联变化——这让构建一个能长期运行、持有状态的复杂智能体系统变得异常困难。

智能体具备状态，错误会层层叠加。 智能体通常运行时间较长，需跨多个工具调用维持内部状态。这就要求我们构建健壮的执行机制，并能在出错时提供应对手段。否则，哪怕是一个微小的故障，也可能对整个任务流程造成灾难性影响。一旦发生错误，系统不能简单重启——因为代价太高，用户体验太差。因此我们构建了“可恢复系统”：智能体在出错时可以从中断位置恢复执行。我们还利用 Claude 模型的智能能力来自我应对问题，比如在提示词中让它识别出“某个工具正在出错”，然后换个策略，这种方法效果惊人。我们用 Claude 的智能应对能力 + 稳定的系统保护机制（比如重试逻辑、定期保存状态）相结合，实现了高度鲁棒性。

调试需要全新方式。 智能体的行为是动态的、非确定性的。即使提示词完全一样，模型的每次输出可能不同。这让调试难度骤增。例如，用户可能反馈“智能体没找到明显信息”，但我们却很难复现原因——到底是搜索词不佳？选择了错误来源？还是某个工具崩了？我们引入了完整的生产级追踪系统（production tracing），可系统性地定位问题所在并修复。此外，我们并不会追踪具体的用户对话内容，而是监控智能体的决策模式和交互结构——以确保用户隐私。这种高层级的可观测性帮助我们快速定位问题根因、识别非预期行为并修复共性错误。

部署需精密协调。 智能体系统是一个高度有状态的网络系统，涉及提示词、工具、执行逻辑等要素，它们基本是“长时间运行”的。每当我们部署一个系统更新时，系统中运行的智能体可能正处于任意执行阶段。因此，我们必须防止“良性改动”破坏已有运行中的任务。

我们不能一次性把所有智能体都切到新版本，而是采用 彩虹部署（Rainbow Deploy） 的策略：渐进式将用户从旧版本平滑切换到新版本，同时保证两个版本能同时稳定运行。

同步执行造成瓶颈。 目前我们的主控智能体是以同步方式执行子智能体——它必须等待一批子智能体执行完毕，才能进入下一阶段。这种方式简化了协调流程，但也带来了明显瓶颈。例如，主控智能体在等待时无法指导子智能体、子智能体之间也无法沟通协作，整个系统会因等待单一子任务而卡住。

如果实现异步执行（Asynchronous Execution），就可以实现更大并行度：多个智能体可以同时运行，甚至在运行过程中动态生成新的子智能体。但这也会带来额外挑战，比如如何协调异步结果、如何保持状态一致性、如何处理跨智能体的错误传播等。

随着模型能力提升，我们相信异步系统将带来巨大的性能增益，值得我们在工程上投入实现。

结语（Conclusion）

在构建 AI 智能体的过程中，所谓的“最后一公里”，往往才是最难的一程。从开发者本地跑通的代码，到上线成为可靠的生产系统，中间需要大量工程工作才能真正落地。

在智能体系统中，错误是“累积式”的。传统软件中一个小问题可能仅导致某个功能不可用，而在智能体系统中，一个步骤出错，智能体就可能偏离轨道、进入错误路径，最终导致完全不可预测的输出。这意味着原本只是一个“小 bug”，也可能彻底改变任务走向。

正因如此，原型和生产之间的鸿沟往往比预期更大。

尽管如此，多智能体系统在处理开放式研究类任务方面，已经展现出极高的价值。有用户告诉我们，Claude 帮助他们发现了原本没考虑过的商业机会、顺利应对复杂的医疗决策、解决技术难题，甚至节省了数天的研究时间，找到了自己独自难以发现的信息连接。

通过细致的工程落地、完善的测试体系、精细化的提示词和工具设计、可靠的运行机制，以及研究、产品与工程团队的紧密协作，多智能体研究系统已经可以稳定大规模运行。

我们正在亲眼见证它们改变人们解决复杂问题的方式。

 

这是一张 Clio 的嵌入图（embedding plot），展示了用户在使用 Research 功能时最常见的用例类别：

• 构建跨专业的软件系统（10%）

• 撰写和优化技术/专业内容（8%）

• 发展商业增长与收入策略（8%）

• 辅助学术研究与教育资料开发（7%）

• 搜集与验证有关人物、地点、组织的信息（5%）

致谢（Acknowledgements）

本文作者：Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox 和 Daniel Ford。

这项工作汇集了 Anthropic 多个团队的共同努力，才使得 Research 功能成为现实。

特别感谢 Anthropic 应用工程团队（apps engineering team），是他们的专注与投入，推动这个复杂的多智能体系统从想法变为落地产品。

同时我们也非常感激早期用户们所提供的宝贵反馈。

附录（Appendix）

以下是一些关于多智能体系统的额外技巧与建议：

评估“状态演变型”智能体的最终结果（End-state evaluation of agents that mutate state over many turns） 对于那些在多轮对话中持续修改状态的智能体来说，传统的评估方法很难适用。因为这些任务不是“只读型”的研究，智能体的每一步操作都会改变后续流程的上下文环境，造成强依赖。

我们发现：与其逐步分析每一步操作，不如将评估聚焦在“最终状态”上——只要它最终达成了正确目标，就无需追求严格一致的中间过程。这种方法接受“路径多样性”的存在，确保智能体即使走了不同路线，也能完成预期任务。

对于更复杂的流程，我们会把评估拆解成多个阶段性检查点，判断是否在特定阶段完成了相应状态更改，而不是逐步核验全部过程。

管理长对话中的上下文（Long-horizon conversation management） 生产级智能体往往需要处理持续数百轮的对话，这对上下文管理提出了很高要求。随着会话推进，常规的上下文窗口逐渐耗尽，因此必须引入智能压缩机制和外部记忆系统。

我们的方法是：当某个阶段性任务完成后，智能体会将其总结，并将关键信息存入外部内存（Memory），然后再开始新任务。如此一来，当上下文接近极限时，系统可以启动一个新的子智能体，用于承接后续任务，旧上下文也可通过记忆系统检索。

这种“分布式上下文管理”策略可有效避免上下文溢出，同时保持对话连续性。

将子智能体输出存入文件系统，减少“传声筒效应”（Subagent output to a filesystem to minimize the ‘game of telephone’） 在某些场景下，让子智能体的结果不必经过主控智能体中转，而是直接以“工件”形式持久化输出，会更加高效和准确。

例如：我们引入了“智能体产物系统”（artifact system），子智能体可调用工具将研究报告、代码、图表等结果写入外部系统，然后只需将指向该工件的引用返回给协调者即可。

这种方式不仅避免了因多轮传递导致信息变形，也节省了因 token 往返造成的资源浪费。

尤其适用于结构化输出场景（代码、报告、图表等），此时子智能体的专属提示词往往能直接生成最佳内容，而无需“中转再翻译”。

原文：https://www.anthropic.com/engineering/built-multi-agent-research-system