推荐这篇 LangChain CEO Harrison Chase 写的多 agent 系统设计指南。核心论题极其简单但很少有人讲清楚：多 agent 系统分“读“和“写“——读容易并行，写容易冲突。这就是为什么 Anthropic 的研究 agent 用多 agent 做研究（读），但让单 agent 做综合（写）。如果你在考虑多 agent 架构，这篇文章会帮你避免最常见的设计错误。

如何以及何时构建多 Agent 系统

Anthropic 的博客里有一段经典判断：

“多 agent 研究系统在广度优先的查询上表现尤为出色——即同时追求多个独立方向的任务。”

“多 agent 系统的主要工作原理是它们帮助花掉足够的 token 来解决问题……多 agent 架构有效地为超出单 agent 能力的任务扩展了 token 消耗。”

“对于经济可行性，多 agent 系统要求任务的价值足够高来为增加的性能付费。”

“需要所有 agent 共享完全相同上下文的领域不适合今天的多 agent 系统。”

核心原则：“读“比“写“简单

多 agent 系统里需要做的最重要区分：“读“任务比“写“任务更容易并行化。

这个洞察来自比较两个已知的多 agent 系统——Cognition 的编码系统和 Anthropic 的研究系统。

• 读操作天然可并行。 多个 agent 可以同时搜索、阅读和评估不同的信息源，不产生冲突。 • 写操作引入冲突。 当多个 agent 同时写代码或内容，它们的选择可能产生互不兼容的输出。Cognition 的博客写得很好：“操作承载着隐性决策，冲突的决策带来糟糕的结果。”

Anthropic 的 Claude Research 是理解这个原则的最佳案例。这个系统的多 agent 架构主要处理研究（读）组件。实际的写作——将发现综合成连贯的报告——则特意由一个主 agent 在统一的单次调用中完成。这个设计选择就是在承认：协作写作引入了多 agent 写带来的核心挑战。

什么场景适合多 Agent

适合： • 广度优先的探索（同时追多条独立线索） • 信息总量超过单个上下文窗口 • 需要对接大量复杂工具的场景 • 任务价值足够高，能覆盖多 agent 增加的成本

不适合： • 需要所有 agent 共享相同上下文的领域 • Agent 之间有大量依赖关系 • 涉及大量“写“操作的协作任务 • 经济上无法支持多 agent 额外 token 消耗的任务

工程上需要的配套

持久执行。 当错误发生时，不能每次都从头开始——这对用户来说贵且让人沮丧。你需要能从 agent 卡住的地方恢复的系统。这是 LangGraph 的核心理念：所有长生命期 agent 都需要内建的持久化。

观测和调试。 Agent 比传统软件更难调试。你需要知道：是搜索查询有问题？是选择了糟糕的来源？是工具调用失败？完整的生产追踪让你能系统性地诊断 agent 为什么失败。

评估。 从小的 eval 集开始——甚至 ~20 个数据点就够——但尽早开始。Agent 的 eval 比传统 ML 的 eval 更难，因为输出空间更大、更难定义“成功“。

结论

构建 agent 系统没有“一刀切“的答案。从单 agent 开始，只在多 agent 能增加明确的、可辩护的价值时才加上多 agent。任何框架都应该允许你在这个光谱上自由滑动——从单 agent 到简单多 agent 到完整蜂群。

来源：Harrison Chase / LangChain, “How and when to build multi-agent systems” https://langchain.com/blog/how-and-when-to-build-multi-agent-systems…

#多Agent #Agent工程 #系统设计

How and when to build multi-agent systems

Source: https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems Late last week two great blog posts were released with seemingly opposite titles.“Don’t Build Multi-Agents”by the Cognition team, and“How we built our multi-agent research system”by the Anthropic team.

Despite their opposing titles, I would argue they actually have a lot in common and contain some insights as to how and when to build multi-agent systems:

1. Context engineering is crucial
2. Multi-agent systems that primarily “read” are easier than those that “write”

Context engineering is critical

One of the hardest parts of building multi-agent (or even single-agent) applications is effectively communicating to the models the context of what they’re being asked to do. The Cognition blog post introduces the term “context engineering” to describe this challenge.

In 2025, the models out there are extremely intelligent. But even the smartest human won’t be able to do their job effectively without the context of what they’re being asked to do. “Prompt engineering” was coined as a term for the effort needing to write your task in the ideal format for a LLM chatbot. “Context engineering” is the next level of this. It is about doing this automatically in a dynamic system. It takes more nuance and is effectively the #1 job of engineers building AI agents.

They show through a few toy examples that using multi-agent systems makes itharderto ensure that each sub-agent has the appropriate context.

The Anthropic blog post doesn’t explicitly use the term context engineering, but at multiple points it addresses the same issue. It’s clear that the Anthropic team spent a significant amount of time on context engineering. Some highlights below:

**Long-horizon conversation management.**Production agents often engage in conversations spanning hundreds of turns, requiring careful context management strategies. As conversations extend, standard context windows become insufficient, necessitating intelligent compression and memory mechanisms. We implemented patterns where agents summarize completed work phases and store essential information in external memory before proceeding to new tasks. When context limits approach, agents can spawn fresh subagents with clean contexts while maintaining continuity through careful handoffs. Further, they can retrieve stored context like the research plan from their memory rather than losing previous work when reaching the context limit. This distributed approach prevents context overflow while preserving conversation coherence across extended interactions.

In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.

Context engineering is critical to making agentic systems work reliably. This insight has guided our development ofLangGraph, our agent and multi-agent framework. When using a framework, you need to have full control what gets passed into the LLM, and full control over what steps are run and in what order (in order to generate the context that gets passed into the LLM). We prioritize this with LangGraph, which is a low-level orchestration framework with no hidden prompts, no enforced “cognitive architectures”. This gives you full control to do the appropriate context engineering that you require.

Multi-agent systems that primarily “read” are easier than those that “write”

Multi-agent systems designed primarily for “reading” tasks tend to be more manageable than those focused on “writing” tasks. This distinction becomes clear when comparing the two blog posts: Cognition’s coding-focused system and Anthropic’s research-oriented approach.

Both coding and research involve reading and writing, but they emphasize different aspects. The key insight is that read actions are inherently more parallelizable than write actions. When you attempt to parallelize writing, you face the dual challenge of effectively communicating context between agents and then merging their outputs coherently. As the Cognition blog post notes: “Actions carry implicit decisions, and conflicting decisions carry bad results.” While this applies to both reading and writing, conflicting write actions typically produce far worse outcomes than conflicting read actions. When multiple agents write code or content simultaneously, their conflicting decisions can create incompatible outputs that are difficult to reconcile.

Anthropic’s Claude Research illustrates this principle well. While the system involves both reading and writing, the multi-agent architecture primarily handles the research (reading) component. The actual writing—synthesizing findings into a coherent report—is deliberately handled by a single main agent in one unified call. This design choice recognizes that collaborative writing introduces unnecessary complexity.

However, even read-heavy multi-agent systems aren’t trivial to implement. They still require sophisticated context engineering. Anthropic discovered this firsthand:

We started by allowing the lead agent to give simple, short instructions like ‘research the semiconductor shortage,’ but found these instructions often were vague enough that subagents misinterpreted the task or performed the exact same searches as other agents. For instance, one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains, without an effective division of labor.

Production reliability and engineering challenges

Whether using multi-agent systems or just a complex single agent one, there are several reliability and engineering challenges that emerge. Anthropic’s blog post does a great job of highlighting these. These challenges are not unique to Anthropic’s use case, but are actually pretty generic. A lot of the tooling we’ve been building has been aimed at generically solving problems like these.

Durable execution and error handling

**Agents are stateful and errors compound.**Agents can run for long periods of time, maintaining state across many tool calls. This means we need to durably execute code and handle errors along the way. Without effective mitigations, minor system failures can be catastrophic for agents. When errors occur, we can’t just restart from the beginning: restarts are expensive and frustrating for users. Instead, we built systems that can resume from where the agent was when the errors occurred.

This durable execution is a key part ofLangGraph, our agent orchestration framework. We believe all long running agents will need this, and accordingly it should be built into the agent orchestration framework.

Agent Debugging and Observability

Agents make dynamic decisions and are non-deterministic between runs, even with identical prompts. This makes debugging harder. For instance, users would report agents “not finding obvious information,” but we couldn’t see why. Were the agents using bad search queries? Choosing poor sources? Hitting tool failures? Adding full production tracing let us diagnose why agents failed and fix issues systematically.

We have long recognized that observability for LLM systems is different than traditional software observability. A key reason why is it needs to be optimized for debugging these types of challenges. If you’re not sure what exactly this means - check outLangSmith, our platform for (among other things) agent debugging and observability. We’ve been building LangSmith for the past two years to handle these types of challenges. Try it out and see why this is so critical!

Evaluation of agents

A whole section in the Anthropic post is dedicated to “effective evaluation of agents”. A few key takeaways that we like:

• Start small with evals, even ~20 datapoints is enough
• LLM-as-a-judgecan automate scoring of experiments
• Human testing remains essential

This resonates whole-heartedly with our approach to evaluation. We’ve been building evals into LangSmith for a while, and have landed on several features to help with those aspects:

• Datasets, to curate datapoints easily
• RunningLLM-as-a-judgeserver side (more features coming here soon!)
• Annotation queuesto coordinate and facilitate human evaluations

Conclusion

Anthropic’s blog post also contains some wisdom for where multi-agent systems may or may not work best:

Our internal evaluations show that multi-agent research systems excel especially for breadth-first queries that involve pursuing multiple independent directions simultaneously.

Multi-agent systems work mainly because they help spend enough tokens to solve the problem…. Multi-agent architectures effectively scale token usage for tasks that exceed the limits of single agents.

For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.

Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time. We’ve found that multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.

As is quickly becoming apparent when building agents, there is not a “one-size-fits-all” solution. Instead, you will want to explore several options and choose the best one according to the problem you are solving.

Any agent framework you choose should allow you to slide anywhere on this spectrum - something we’ve uniquely emphasized with LangGraph.

Figuring out how to get multi-agent (or complex single agent) systems to function also requires new tooling. Durable execution, debugging, observability, and evaluation are all new tools that will make your life as an application developer easier. Luckily, these are all generic tooling. This means that you can use tools like LangGraph and LangSmith to get these off-the-shelf, allowing you to focus more on the business logic of your application than generic infrastructure.