Beyond The Single-Agent Ceiling: Scale Out With MCP Agent Teams

超越单智能体上限：利用 MCP 智能体团队实现横向扩展

Most people’s experience with AI is a conversation with one assistant. ChatGPT, Claude, and similar products present one conversational partner. You ask it a question, it reasons, perhaps calls a few tools, and gives you an answer. 大多数人对 AI 的体验都是与一个助手进行对话。ChatGPT、Claude 和类似的产品提供了一个对话伙伴。你向它提问，它进行推理，或许调用几个工具，然后给你一个答案。

That experience creates a natural architectural instinct: if one agent is useful, make that one agent more capable. Give it better instructions. Connect more tools. Add more context. Increase its token budget. Upgrade the model. That is the right place to start. It is not an infinitely scalable place to finish. 这种体验产生了一种自然的架构直觉：如果一个智能体有用，那就让这个智能体变得更强大。给它更好的指令，连接更多的工具，增加更多的上下文，提高它的 Token 配额，升级模型。这是开始的最佳方式，但并不是可以无限扩展的终点。

At some point, the single agent is no longer doing one coherent job. Its instructions contain a job description, an organization chart, a workflow engine, a memory policy, a delegation policy, a review checklist, and a recovery procedure. Its context contains the request, the plan, intermediate evidence, failed attempts, tool results, and the agent’s own conclusions about all of them. Its tool list spans several domains. It is asked to investigate, calculate, edit, criticize, validate, and finally approve its own work. 在某个阶段，单智能体将不再执行单一连贯的任务。它的指令包含了职位描述、组织架构图、工作流引擎、记忆策略、委派策略、审查清单和恢复程序。它的上下文包含了请求、计划、中间证据、失败的尝试、工具结果以及智能体对所有这些内容的结论。它的工具列表跨越了多个领域。它被要求调查、计算、编辑、批评、验证，并最终批准自己的工作。

The architecture still looks simple because there is only one box labeled “agent.” The complexity did not disappear. It moved inside the box, where it became harder to see, test, and govern. This article is about what happens after that point. 这种架构看起来仍然很简单，因为只有一个标有“智能体”的方框。复杂性并没有消失，它只是转移到了方框内部，变得更难观察、测试和管理。本文将探讨在那之后会发生什么。

The previous article reduced an agent to three parts: instructions, an LLM, and MCP tools. That remains the correct foundation. This article extends it with two arguments: A single agent has a capability ceiling. For sufficiently complex, decomposable work, a team can scale beyond that ceiling through specialization, separate contexts, parallelism, and independent validation. 上一篇文章将智能体简化为三个部分：指令、大语言模型（LLM）和 MCP 工具。这仍然是正确的基础。本文在此基础上提出了两个论点：单智能体存在能力上限。对于足够复杂且可分解的工作，团队可以通过专业化、独立的上下文、并行处理和独立验证来突破这一上限。

A team pays a coordination tax. But that tax exists in a single-agent system too, hidden in an increasingly confusing prompt and volatile context. MCP lets us externalize it into explicit, reusable collaboration infrastructure. The practical pattern is to scale up one agent while simplicity remains an advantage, then scale out into a team when implicit coordination becomes the bottleneck. 团队需要支付“协调成本”。但这种成本在单智能体系统中也存在，只是隐藏在日益混乱的提示词和不稳定的上下文中。MCP 让我们能够将其外化为显式、可重用的协作基础设施。实践中的模式是：在保持简单性优势的同时扩展单个智能体，当隐式协调成为瓶颈时，再扩展为团队。

What Is MCP? (The 30-Second Version)

什么是 MCP？（30 秒速览版）

The Model Context Protocol (MCP, spec 2025-11-25) is the interface layer between AI clients and external systems through tools, prompts, and resources. Throughout this series, we have treated MCP servers as the governed capability layer for enterprise AI: thin, remote, mostly stateless interfaces to internal systems and SaaS systems. 模型上下文协议（MCP，规范 2025-11-25）是 AI 客户端与外部系统之间通过工具、提示词和资源进行交互的接口层。在本系列文章中，我们将 MCP 服务器视为企业级 AI 的受控能力层：即连接内部系统和 SaaS 系统的轻量级、远程、基本无状态的接口。

An agent is an MCP client with:

instructions describing its job and boundaries
an LLM providing reasoning and language capabilities
selected MCP tools connecting it to the outside world

智能体是一个 MCP 客户端，具备：

描述其工作和边界的指令
提供推理和语言能力的大语言模型
连接外部世界的精选 MCP 工具

An agent team does not replace that model. It composes it recursively: a specialized agent can be exposed as an MCP tool, another agent can discover and call that tool, and shared collaboration services can also be exposed through MCP. The result is not a new species of software. It is a scale-out architecture built from the same capability model. 智能体团队并没有取代这种模型，而是对其进行了递归组合：一个专业化的智能体可以作为 MCP 工具暴露出来，另一个智能体可以发现并调用该工具，共享的协作服务也可以通过 MCP 暴露。其结果并非一种新的软件物种，而是基于相同能力模型构建的横向扩展架构。

A Single Agent Is The Right Place To Start

单智能体是起点的最佳选择

Teams introduce real cost. A coordinator has to decompose work, select collaborators, wait for results, resolve conflicts, and synthesize an answer. Multiple agents consume more tokens and create more failure boundaries. Shared state needs ownership, permissions, and lifecycle rules. For many tasks, none of that is justified. 团队会带来实际成本。协调者必须分解工作、选择协作者、等待结果、解决冲突并综合答案。多个智能体会消耗更多 Token 并产生更多的故障边界。共享状态需要所有权、权限和生命周期规则。对于许多任务而言，这些投入是不值得的。

Use one agent when the work is:

short
mostly sequential
contained within one context
served by a small, coherent toolset
easy to validate directly
not valuable enough to justify additional inference and infrastructure cost

当工作符合以下条件时，请使用单智能体：

短小
基本是顺序执行的
包含在一个上下文内
由一套小型、连贯的工具集提供支持
易于直接验证
价值不足以抵消额外的推理和基础设施成本

Before adding agents, scale up the single agent: improve its instructions, use a stronger model where the economics make sense, reduce and clarify its tools, move deterministic computation into MCP servers, package repeatable workflows as prompts, and give long-running work an explicit task lifecycle. 在增加智能体之前，先扩展单智能体：改进其指令，在经济合理的情况下使用更强的模型，精简并明确其工具，将确定性计算移至 MCP 服务器，将可重复的工作流封装为提示词，并为长时间运行的任务提供明确的生命周期。

This follows the same principle used throughout the series: do not add probabilistic orchestration where a deterministic capability would be better. If server code can reliably perform a calculation or enforce a known workflow, use server code. A second agent is not a substitute for a well-designed tool. But scaling up eventually reaches diminishing returns. 这遵循了本系列文章一贯的原则：不要在可以使用确定性能力的地方增加概率性编排。如果服务器代码可以可靠地执行计算或强制执行已知的工作流，请使用服务器代码。第二个智能体不能替代设计良好的工具。但扩展最终会达到边际收益递减的临界点。

The Single-Agent Ceiling

单智能体上限

The ceiling is not a single model limit. Several pressures compound. 这个上限并非单一模型限制，而是多种压力共同作用的结果。

Context saturation: One agent must carry the plan, evidence, intermediate results, conversation history, and its own reasoning in one working context. A larger context window increases capacity, but it does not guarantee that every relevant detail receives the right attention at the right time.
上下文饱和： 一个智能体必须在一个工作上下文中承载计划、证据、中间结果、对话历史及其自身的推理。更大的上下文窗口增加了容量，但不能保证每个相关细节都能在正确的时间得到正确的关注。
Tool overload: A generalist agent needs more tools. The tool-design article showed that tool performance can fall off a cliff as the choice set grows. Dividing work across specialists lets each agent see a smaller, more relevant capability surface.
工具过载： 通用型智能体需要更多的工具。之前的工具设计文章表明，随着选择范围的扩大，工具性能可能会断崖式下跌。将工作分配给专业人员，可以让每个智能体面对更小、更相关的能力范围。
Role collision: Planning, execution, criticism, approval, and final communication require different behavior. Encoding all of them into one instruction set creates conflicting objectives: move quickly but verify everything, explore alternatives but remain concise, propose a solution but distrust it.
角色冲突： 规划、执行、批评、批准和最终沟通需要不同的行为模式。将所有这些编码进一套指令中会产生相互冲突的目标：既要快速行动又要验证一切，既要探索替代方案又要保持简洁，既要提出解决方案又要对其保持怀疑。
Sequential throughput: One agent explores one trajectory at a time. When a problem contains several independent research paths or checks, a team can work on them concurrently using separate contexts.
顺序吞吐量： 一个智能体一次只能探索一条路径。当问题包含多个独立的研究路径或检查点时，团队可以使用独立的上下文并行工作。
Path dependence: An early mistaken assumption shapes later reasoning. The same agent reviewing its own work sees the conclusion through the context that produced it.
路径依赖： 早期的错误假设会影响后续的推理。同一个智能体在审查自己的工作时，会通过产生该结论的上下文来看待它。
Weak self-verification: Telling an agent to “double-check your answer” is useful, but it does not create an independent reviewer, an authoritative state boundary, or a requirement that validation succeed before completion.
弱自我验证： 告诉智能体“仔细检查你的答案”是有用的，但这并不能创造一个独立的审查者、权威的状态边界，也不能强制要求在完成前必须通过验证。

These pressures explain why adding more instructions can make an agent worse. Each new rule may be sensible in isolation, but the complete prompt becomes a crowded control plane for responsibilities that should have explicit owners and interfaces. 这些压力解释了为什么增加更多的指令反而可能让智能体表现更差。每一条新规则单独看可能都是合理的，但完整的提示词变成了一个拥挤的控制平面，承载了本应有明确所有者和接口的职责。