The journey of this multi-agent system from prototype to production taught us critical lessons about system architecture, tool design, and prompt engineering. A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together. Our Research feature involves an agent that plans a research process based on user queries, and then uses tools to create parallel agents that search for information simultaneously.
这个多智能体系统从原型到生产的旅程教会了我们关于系统架构、工具设计和提示工程的关键课程。多智能体系统由多个智能体（LLM 在循环中自主使用工具）协同工作组成。我们的研究功能涉及一个智能体根据用户查询规划研究流程，然后使用工具创建并行智能体同时搜索信息。
这是 Anthropic 对 Claude Research 功能（类似 OpenAI 的 Deep Research）的工程复盘。核心架构：一个"主控智能体"接收用户问题 → 拆分成子任务 → 并行启动多个"子智能体"各自搜索 → 汇总结果。这就是"编排者-工作者"模式的真实生产实现。
Research work involves open-ended problems where it's very difficult to predict the required steps in advance. This unpredictability makes AI agents particularly well-suited for research tasks. Research demands the flexibility to pivot or explore tangential connections as the investigation unfolds.
研究工作涉及开放式问题，很难提前预测所需步骤。这种不可预测性使 AI 智能体特别适合研究任务。研究需要随着调查展开而灵活转向或探索横向关联的能力。
The essence of search is compression: distilling insights from a vast corpus. Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent.
搜索的本质是压缩：从海量语料中提炼洞察。子智能体通过各自独立的上下文窗口并行运作来促进压缩——同时探索问题的不同方面，然后为主控智能体浓缩最重要的 token。
Our internal evaluations show that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.
我们的内部评估显示，使用 Claude Opus 4 作为主控智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在内部研究评估中比单智能体 Claude Opus 4 高出 90.2%。
Multi-agent systems work mainly because they help spend enough tokens to solve the problem. Token usage by itself explains 80% of the performance variance. There is a downside: agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats.
多智能体系统有效的主要原因是它们能花费足够的 token 来解决问题。仅 token 使用量本身就解释了 80% 的性能差异。但缺点是：智能体通常比聊天交互多消耗约 4 倍 token，多智能体系统则多消耗约 15 倍。
这是一个极其重要的发现：Token 消耗量 = 性能。80% 的性能差异可以用 token 使用量来解释。这意味着"用更多 token 想问题"几乎等于"想得更好"。多智能体架构的本质就是通过并行化来成倍增加有效 token 使用量。但成本是单次对话的 15 倍——所以只适合高价值任务。
Our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.
我们的研究系统采用编排者-工作者模式的多智能体架构：主控智能体协调流程，同时将任务委派给并行运作的专门子智能体。
Traditional approaches using Retrieval Augmented Generation (RAG) use static retrieval. In contrast, our architecture uses a multi-step search that dynamically finds relevant information, adapts to new findings, and analyzes results to formulate high-quality answers.
传统 RAG 使用静态检索——获取与输入查询最相似的文本块。相比之下，我们的架构使用多步搜索：动态发现相关信息，适应新发现，分析结果以构建高质量答案。
Early agents made errors like spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates. Since each agent is steered by a prompt, prompt engineering was our primary lever.
早期智能体会犯这样的错误：为简单查询生成 50 个子智能体、无休止地搜索不存在的来源、用过多更新互相干扰。由于每个智能体都由提示驱动，提示工程是我们改进的主要杠杆。
Think like your agents. To iterate on prompts, you must understand their effects. We built simulations with our Console, then watched agents work step-by-step. This immediately revealed failure modes: agents continuing when they had sufficient results, using overly verbose search queries, or selecting incorrect tools.
像你的智能体一样思考。要迭代提示，必须理解提示的效果。我们用 Console 构建了模拟环境，逐步观察智能体工作。这立即暴露了失败模式：智能体在已有足够结果时仍继续搜索、使用过于冗长的搜索查询、或选择错误工具。
Teach the orchestrator how to delegate. Each subagent needs an objective, an output format, guidance on tools and sources, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.
教编排者如何委派。每个子智能体都需要：目标、输出格式、工具和来源指引、以及清晰的任务边界。没有详细的任务描述，智能体会重复工作、留有遗漏、或找不到必要信息。
Scale effort to query complexity. Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities.
根据查询复杂度调整投入。简单事实查找只需 1 个智能体和 3-10 次工具调用；直接比较可能需要 2-4 个子智能体各 10-15 次调用；复杂研究可能使用超过 10 个子智能体并有明确的职责划分。
Tool design and selection are critical. Agent-tool interfaces are as critical as human-computer interfaces. An agent searching the web for context that only exists in Slack is doomed from the start. We gave our agents explicit heuristics: examine all available tools first, match tool usage to user intent, prefer specialized tools over generic ones.
工具设计和选择至关重要。智能体-工具接口和人机接口一样关键。一个在网页上搜索只存在于 Slack 中的上下文的智能体从一开始就注定失败。我们给智能体明确的启发式规则：先检查所有可用工具、将工具使用与用户意图匹配、优先使用专用工具而非通用工具。
Let agents improve themselves. Claude 4 models can be excellent prompt engineers. When given a prompt and a failure mode, they can diagnose why the agent is failing and suggest improvements. We created a tool-testing agent that rewrote tool descriptions, resulting in a 40% decrease in task completion time.
让智能体自我改进。Claude 4 模型可以成为优秀的提示工程师。给定提示和失败模式后，它们能诊断智能体失败的原因并建议改进。我们创建了一个工具测试智能体来重写工具描述，使任务完成时间减少了 40%。
Parallel tool calling transforms speed and performance. We introduced two kinds of parallelization: (1) the lead agent spins up 3-5 subagents in parallel; (2) subagents use 3+ tools in parallel. These changes cut research time by up to 90%.
并行工具调用改变速度和性能。我们引入了两层并行化：（1）主控智能体并行启动 3-5 个子智能体；（2）子智能体并行使用 3+ 个工具。这些改进将研究时间减少了高达 90%。
这段是全文最实用的部分——8 条提示工程原则都是从真实生产环境中提炼的。核心洞察：①智能体需要明确的"工作量预算"防止过度投入 ②工具描述的质量直接决定智能体能否正确使用工具（这就是 ACI 概念的延伸）③并行化是性能的倍增器（90% 时间缩减！）。如果你在构建自己的 Agent 系统，这些原则比任何框架文档都更有参考价值。
Traditional evaluations often assume that the AI follows the same steps each time. But multi-agent systems don't work this way. Even with identical starting points, agents might take completely different valid paths to reach their goal.
传统评估通常假设 AI 每次遵循相同步骤。但多智能体系统不是这样工作的。即使起点完全相同，智能体也可能走完全不同的有效路径到达目标。
Start evaluating immediately with small samples. In early agent development, a prompt tweak might boost success rates from 30% to 80%. With effect sizes this large, you can spot changes with just a few test cases.
立即用小样本开始评估。在早期智能体开发中，一个提示调整可能将成功率从 30% 提升到 80%。效果如此显著，只需少量测试用例就能发现变化。
LLM-as-judge evaluation scales when done well. We used an LLM judge that evaluated each output against criteria: factual accuracy, citation accuracy, completeness, source quality, and tool efficiency.
LLM 作为裁判的评估方法可以扩展。我们使用 LLM 裁判，按以下标准评估每个输出：事实准确性、引用准确性、完整性、来源质量和工具效率。
Human evaluation catches what automation misses. Human testers noticed that early agents consistently chose SEO-optimized content farms over authoritative sources like academic PDFs or personal blogs.
人工评估能发现自动化遗漏的问题。人工测试者注意到，早期智能体持续选择 SEO 优化的内容农场，而非学术论文或个人博客等权威来源。
评估多智能体系统的核心矛盾：路径不可预测，但结果必须可验证。Anthropic 的解决方案：不检查"是否走了正确的路"，而是检查"是否到达了正确的终点"。用 LLM 裁官按多维度评分是最实用的可扩展方案。但人工测试仍不可替代——因为 LLM 自己也可能偏好低质量内容。
In traditional software, a bug might break a feature. In agentic systems, minor changes cascade into large behavioral changes. Agents are stateful and errors compound. When errors occur, we can't just restart—we built systems that can resume from where the agent was.
在传统软件中，bug 可能破坏一个功能。在智能体系统中，微小的变更会级联成巨大的行为变化。智能体是有状态的，错误会累积。当错误发生时，我们不能直接重启——我们构建了能从智能体出错位置恢复的系统。
Debugging benefits from new approaches. Agents make dynamic decisions and are non-deterministic between runs. Adding full production tracing let us diagnose why agents failed and fix issues systematically.
调试需要新方法。智能体做动态决策且运行之间不确定。添加完整的生产追踪让我们能诊断智能体失败的原因并系统性修复问题。
Deployment needs careful coordination. We use rainbow deployments—gradually shifting traffic from old to new versions while keeping both running simultaneously.
部署需要精心协调。我们使用彩虹部署——逐步将流量从旧版本切换到新版本，同时保持两者并行运行。
Synchronous execution creates bottlenecks. Currently, our lead agents execute subagents synchronously. Asynchronous execution would enable additional parallelism but adds challenges in result coordination and error propagation.
同步执行造成瓶颈。目前主控智能体同步执行子智能体。异步执行可以实现更多并行，但在结果协调和错误传播方面带来新挑战。
When building AI agents, the last mile often becomes most of the journey. Codebases that work on developer machines require significant engineering to become reliable production systems. The compound nature of errors in agentic systems means that minor issues can derail agents entirely. The gap between prototype and production is often wider than anticipated.
构建 AI 智能体时，最后一英里往往变成了大部分旅程。在开发机器上运行的代码库需要大量工程才能成为可靠的生产系统。智能体系统中错误的复合特性意味着，小问题可能完全使智能体脱轨。原型和生产之间的差距往往比预期的更大。
Despite these challenges, multi-agent systems have proven valuable for open-ended research tasks. Users have said that Claude helped them find business opportunities they hadn't considered, navigate complex healthcare options, and save up to days of work.
尽管有这些挑战，多智能体系统已被证明对开放式研究任务非常有价值。用户反馈说 Claude 帮助他们发现了未考虑到的商业机会、导航复杂的医疗保健选项、节省了长达数天的工作时间。
最后这段话是所有 Agent 开发者的写照："最后一英里变成了大部分旅程"。Demo 能跑 ≠ 生产能用。Agent 系统的核心难点不是让它"能工作"，而是让它"可靠地工作"——错误恢复、状态管理、部署策略、可观测性，这些工程问题比算法本身更耗时。这也是为什么 Anthropic 的文章对工程师特别有价值——它们分享的是真实的"生产教训"而非理论。