Claude Research 拆解：Anthropic 给我们上的一堂工程实践课

最近，AI Agent 这个概念热得发烫，但对大多数人来说，它更像一个“黑箱”。我们只看到酷炫的演示，却不知道其内部是如何运转的。试图搭建 Agent 系统时，也总是不得要领，实际效果不尽如人意。

就在这时，上个月 Anthropic 发布了他们的 Claude Research 系统，还慷慨地附上了详细的工程博客和示例 Prompt，这简直是把顶级厨房的秘方直接公开了。

接下来，我将会拆解一下 Claude Research 内部的原理，学习一个前沿的多 Agent 系统究竟是如何设计、构建和打磨的，偷师 Anthropic 的宝贵工程经验。

系统架构与工作流程

Claude Research 采用了多 Agent 系统的架构，它是一种 “编排者-工作者”（orchestrator-worker）的架构模式。整体架构并不复杂，主要由三个核心 Agent 角色构成：

• Lead Agent: 它是整个系统的大脑。当收到用户一个复杂的请求时（比如“帮我规划一个三个月的徒步旅行”），它负责深度分析、拆解任务，并制定一份详细的研究计划。
• Sub-Agent: 拿到计划后，主导 Agent 会创建并启动多个并行的子 Agent。每个子 Agent 都是一个独立的专家，负责计划中的某个特定方面（比如一个研究徒步路线，一个研究沿途信号覆盖），它们可以独立使用搜索等工具并行开工。
• Citation Agent: 所有子 Agent 完成调研，将关键信息汇报给主导 Agent 后，主导 Agent 会综合信息，形成一份完整的报告。最后，由这位“事实核查员”登场，它会专门为报告中的每一条结论，找到并附上准确的来源引用。

整个工作流程，接收请求 -> 制定计划 -> 并行研究 -> 综合报告 -> 添加引用，一气呵成。

实验结果表明，这个多 Agent 系统在内部评估中的表现，比单个最强大的 Claude Opus 模型高出了 90.2%。这有点类似于神经网络的「涌现」现象。当多个足够智能的 Agent 系统协作工作时，可以产生 1+1 > 2 的惊人效果。

核心工程实践

可以看到，Claude Research 的系统架构并不复杂，多 Agent 系统的协作模式也是很多人容易想到的分治模式。真正值得我们学习的是 Anthropic 的工程经验。

1. Prompt 应是“协作框架”，而非“指令”

很多人在做 Agent 系统的时候，就一头扎进 Prompt 的世界里，仿佛只要 Prompt 写得完美无缺，Agent 就必然能成功。

然而，Anthropic 在介绍系统 Prompt 工程的时候，直接给出了这的话：

"Think like your agents. Effective prompting relies on developing an accurate mental model of the agent."

“站在 Agent 的角度看问题。 高效的 Prompt 其实是在给 Agent 建立一个准确的心智模型。”

"The best prompts for these agents are not just strict instructions, but frameworks for collaboration that define the division of labor, problem-solving approaches, and effort budgets."

“为这些 Agent 设计的最佳 Prompt，不应只是严格的指令，而更应是一种协作框架，它定义了劳动分工、问题解决方法和精力预算。”

Prompt 工程真正的重点并不在于关注各种细节上的技巧，而是给 Agent 指定清晰明确的目标和任务流程。

尤其是在多 Agent 系统中，Prompt 作为 Agent 之间协作的框架，需要定义好任务如何分工、解决问题的思路是什么、以及每个任务应该投入多少精力。否则， Agent 的责任边界划分不清晰，子 Agent 们会互相重复工作或者遗漏关键信息，导致任务失败。

Anthropic 甚至把 Prompt 开源了出来，如果你有时间，我强烈建议你完整看一下全部的 Prompt，看完之后，你对 Prompt 的理解会更上一个台阶。

2. 依据任务难度，动态投入资源

Agent 本身并不擅长判断一个问题是“杀鸡”还是“宰牛”。你让它查个天气，它也可能启动十个子 Agent 搞得惊天动地。

因此，Claude Research 在 Prompt 中加入了子任务规模的规则。对于简单的任务，只需要一个子 Agent，调用 3-10 个工具。而最复杂的研究可能需要 10 个子 Agent，每个子 Agent 使用 10-15 个工具。

这种 Prompt 看似简单，但其实它是系统中最重要的 Prompt，因为 LLM 没办法自行领悟这种道理。换句话说，我们其实是在定义一些启发式规则，把人的智慧注入 Agent 系统中，补足 LLM 不擅长的部分。

3. 精心设计工具及其“说明书”

为 Agent 提供正确且描述清晰的工具是成功的关键，工具本身的功能和其说明文字都必须精心设计。在工具上投入的时间精力甚至应该不亚于 Prompt 工程。

如果工具的描述含糊不清，Agent 可能被误导，直接用错工具（比如需要在内部工具搜索的信息，去互联网上找）。对于需要多步执行的 ReAct 系统，单次的错误会像滚雪球一样迅速累计，得出错误的结果。

4. 利用 LLM 赋能和评估系统

这个思路非常巧妙。除了让 LLM 当“选手”，还可以让它当“教练”和“裁判”。

• 当教练: 当 Agent 系统执行失败时，可以让另一个 LLM 来诊断失败日志，分析可能是哪个环节的 Prompt 或工具描述出了问题，从而帮助我们改进。
• 当裁判: 研究报告的好坏很难用代码评估。Anthropic 的做法是，让 LLM 扮演“评委”，根据一份评分标准（如事实准确性、引用质量、全面性等），从多个角度为最终结果打分。

系统实现上的挑战

Anthropic 也在博客中写出了构建这个 Agent 所面临的各种系统实现上的挑战。正是这部分让我确信了这篇文章的价值。任何尝试构建复杂 Agent 系统的人，都必须面对以下几种现实挑战：

• 高延迟 (Latency): 这套系统本质上非常慢。一个用户请求，背后可能触发了主 Agent 和子 Agent 之间数十次的模型调用，这些调用环环相扣，导致最终响应时间很长，难以满足实时交互的需求。
• 高成本 (Cost): 天下没有免费的午餐。数十次模型调用，直接带来了高昂的运行成本。处理一个复杂查询的开销，远非单次聊天可比。
• 可靠性与调试难度 (Reliability & Debugging): 这是一个复杂的分布式系统，任何一个子 Agent 的小失误，都可能导致整个任务链条失败。更要命的是，由于大模型的非确定性，追踪和复现一个 Bug 极其困难。
• 可观测性需求 (Observability): 正因为系统如此复杂且脆弱，必须建立强大的监控和可视化工具，来追踪每一个 Agent 的行为、思考过程和工具调用。没有这种“可观测性”，整个系统就像一个难以理解和修复的“黑箱”。

总结与思考

梳理完这些架构设计、工程经验和现实挑战后，一个清晰的图景浮现在我眼前。

AI Agent 绝对不仅仅是写个 Prompt 那么简单。一个成功的 AI Agent 系统，是人机智慧与系统工程的结合体。它既需要我们掌握与模型巧妙沟通的艺术，也需要我们具备应对分布式系统难题的工程经验与能力。

单一的 Prompt 技巧，或是单纯的后端开发，都无法独立撑起这样一个复杂的系统。如果把这些环节分拆给不同角色——比如让产品经理去写 Prompt，开发工程师搭框架，算法工程师建 Benchmark——结果很可能是灾难性的。由于没有人了解系统的全貌，最终只能拼凑出一个勉强能用的系统。

更关键的问题是，真正的 Agent 系统不可能是一次性搭建好的，而是需要不断地进行「构建-测试-分析-改进」循环，观察 LLM 的行为，精心调节 Prompt，构建启发式规则，让一切都恰到好处地配合起来。角色分拆带来的沟通成本，会让这个循环的每一步都变得无比低效。

真正能够把 Agent 系统搭好的，我认为是能够打通所有组件全链路的 “全栈 Agent 工程师”。他们既能设计 Agent 的协作框架，又能编写工具，还能构建稳健运行的系统。他们能让 Agent 系统的迭代速度达到最快，让 Agent 能够最终从 demo 阶段不断优化，最终成为一个好用的系统。

AI 浪潮之下，工具越强大，掌舵人的价值就越凸显。掌握这种贯穿始终的综合能力，应该是我们这一代 AI 从业者追求。