🔶 一百万个 Agent，是一个分布式系统问题

我看待 Agent 的方式，和我看待人的方式一样。一个 Agent 是一名工作者。一千个 Agent 是一个组织，而由机器组成的组织，就是一个分布式系统。

人们总告诉我，Agent 可以永远运行。从技术上说，这是真的。你可以在循环中调用模型，直到信用卡被拒付。但 Agent 仍然依赖有限的资源：token、上下文、算力、内存、工具和资金。总会有某样东西耗尽。

人类并没有多大不同。我们工作一段时间就会疲惫。我们的工作记忆很小，也会遗忘。所以我们会把重要内容写下来，睡一觉，第二天早晨带着清醒的头脑和同样的身份回来。

机器也有同样的约束，只是表现形式不同。一台机器会耗尽 CPU。一个 Pod 会耗尽内存。没人会通过假设每个进程都应该永远存活来解决这个问题。我们是在已有资源上调度工作。

我不明白为什么智能可以例外。一个 Agent 可以工作一段时间，记录下重要内容，清空自己的上下文，然后让自己或另一个 Agent 从那里继续。我们在 InsForge 的 VPS 上运行自己的编码 Agent，它们一直会被终止、重启，并耗尽上下文。真正造成伤害的故障，是计划只存在于 Agent 上下文窗口里的那些情况。

TL;DR

• 在 Google Research 的 180 种配置研究中，增加 Agent 可使并行工作提升最高 80.9%，却会让顺序工作下降 39% 至 70%。决定结果的是任务形态。
• 在同一研究中，编排器将错误放大从 17.2 倍降至 4.4 倍。协调是一项真实存在的工作。
• 在 Silo-Bench（ACL 2026）中，2 至 100 个 Agent 的团队进行了大量交流，却推理得很差。最难的任务在 50 个 Agent 时成功率降至零。
• 因此，应该持久存在的是状态，而不是 Agent。应该像调度进程一样调度 Agent，并像恢复节点一样恢复它们。

Agent 开始越来越像进程

这在一段时间前就不再只是一个类比了。已经有一整条研究路线正在构建这种系统。

来自罗格斯大学的 AIOS——一个“LLM Agent Operating System”——用一句话开篇描述了问题：

“允许 Agent 不受限制地访问 LLM 或工具资源，可能导致低效甚至潜在有害的资源分配与使用。”

他们的答案是内核。每个 Agent 请求都会被拆解为系统调用（一次 LLM 调用、一次内存读取、一次存储写入、一次工具使用）；调度器通过经典策略决定下一个运行谁的调用，即先进先出（First-In-First-Out）和时间片轮转（Round Robin）；上下文管理器会在 Agent 执行任务的中途创建快照，以便它能够被中断并恢复。他们报告称，在服务基于现有框架构建的 Agent 时，执行速度最高可提升 2.1 倍。

调度、上下文切换、内存管理、存储、访问控制。这就是一个操作系统，只不过其中的进程恰好会思考。

在更上一层，这也有效。来自 ACL 2026 的 LLM-as-Scheduler 从一个观察出发：大多数查询并不值得使用沉重的多 Agent 工作流，因此让调度器按查询选择工作流。相较于强大的固定工作流，他们实现了 token 减少 43%、端到端延迟降低超过 36%，准确率最多仅下降 1.4 个百分点。

因此，一个 Agent 像一个进程，而数千个进程需要调度器。这没问题。但调度算力只是其中一半。你还必须协调 Agent 彼此之间的关系，而这才是有趣的地方。

十个人会协调，一万人会发明管理者

十个人可以在一个房间里自行协调。一千个人不能彼此全都交谈、并独立决定公司应该做什么，所以我们发明了团队、经理、部门，以及最终的 CEO。经理之所以存在，部分原因是协调本身就是工作，而且必须有人来做。

我曾以为 Agent 会遇到同样的问题。现在已经有数据了。

Google Research 与 MIT 在五种架构（单 Agent、独立多 Agent、集中式多 Agent、去中心化多 Agent 和混合多 Agent）及三个模型系列中，对 180 种 Agent 配置进行了受控研究。他们的核心结论是：

“‘更多 Agent’的方法往往会触及上限；如果不与任务的具体属性相匹配，甚至可能导致性能下降。”

任务类型	结果	说明
顺序任务	−39% 至 −70%	测试中的每种多 Agent 变体都使规划类任务表现变差
可并行任务	+80.9%	集中式协调提升了金融推理表现

相同的五种架构，却得到截然相反的结果，决定因素是任务的形态。来源：Google Research，Towards a science of scaling agent systems，2026 年 1 月。

对于需要严格顺序推理的任务，他们测试的每一种多 Agent 变体都使表现下降了 39% 至 70%。他们的解释是，通信开销割裂了推理，并为实际任务留下了过少的“认知预算”。而在金融推理等可并行工作中，集中式协调将性能提升了 80.9%。

更多 Agent 并没有换来更多智能。它们换来的是更多协调，而协调消耗的正是任务本身所需的预算。

第二项发现，是我一直反复思考的内容。

错误放大：独立 Agent 为 17.2 倍，集中式编排器为 4.4 倍

配置	错误放大倍数
独立 Agent（无编排器）	17.2×
集中式编排器（一个协调者）	4.4×

Google Research 实验中的最大错误放大：并行工作但彼此不沟通的 Agent，错误放大最高可达 17.2 倍；集中式编排器则将同一效应控制在 4.4 倍。来源：Google Research，Towards a science of scaling agent systems，2026 年 1 月。

彼此不沟通、并行工作的 Agent 会将错误放大 17.2 倍。在它们前面加一个编排器后，这个数字降至 4.4 倍。这就是经理的作用。经理不会完成每一项任务。它决定需要做什么，拆解工作，分配任务，监控进度，解决冲突，并整合结果。

沟通不等于协调

这一点对我而言最像人类。

被 ACL 2026 接收的 Silo-Bench，让由 2 至 100 个 Agent 组成的团队完成 30 个分布式算法任务；数据被分片，因此没有单个 Agent 能看到全部信息。研究包含 54 种配置和 1,620 次实验。Agent 可以向同伴发送消息、广播消息或共享文件。

它们进行了大量交谈，但并没有多大帮助。

“Agent 会自发形成与任务相适应的协调拓扑结构，并积极交换信息，但却系统性地无法将分布式状态综合为正确答案。”

作者将其称为“沟通—推理鸿沟”（Communication-Reasoning Gap），而他们的一句话概括比我能写出的任何表述都更好：“Agent 是有能力的沟通者，却是糟糕的分布式推理者。”

而且，规模扩大时情况会变得更糟。

SILO-Bench 按 Agent 数量统计的成功率：每个难度级别的终点都远低于起点，Level III 任务在 50 和 100 个 Agent 时成功率降至零。

任务难度	2 个 Agent	5 个 Agent	10 个 Agent	20 个 Agent	50 个 Agent	100 个 Agent
Level I（聚合）	85%	72%	68.7%	65.7%	38.1%	40.6%
Level II（网格）	61.7%	55.3%	28.3%	29.5%	17.4%	14.3%
Level III（全局重排）	36.2%	17.2%	10%	5.7%	0%	0%

DeepSeek-V3.1 在三种通信协议下的平均 SILO-Bench 任务成功率与 Agent 数量关系（论文表 3）。横轴是序数尺度，而非线性尺度。来源：Zhang 等，Silo-Bench，ACL 2026（arXiv:2603.01045）。

每个难度等级的趋势都是下降，中间虽有几次小幅回升（Level I 从 50 个 Agent 到 100 个 Agent，Level II 从 10 个 Agent 到 20 个 Agent），但没有一次接近恢复原有水平。最难的任务，即那些需要同时组合每个数据分片的任务，在 50 个 Agent 时成功率降至零，并在 100 个 Agent 时维持为零。跨模型来看，最强模型的平均成功率从 2 个 Agent 时的 61% 降至 100 个 Agent 时的 18%，最弱模型则从 17% 降至 1%。作者的结论是：“协调开销会随规模复合增长，最终完全消除并行化带来的收益。”

如果你曾经待过一个有 100 人的 Slack 频道，你早就知道这一点。把 100 个人放进同一个频道，不会产生一个组织。把 100 个 Agent 接到同一条消息总线上，也不会产生集体智能。

当经理失效时会发生什么？

如今大多数多 Agent 系统都通过一个中央编排器进行协调。一个主 Agent 分解目标，将任务交给工作 Agent，监控它们，并合并结果。Google 的数据表明，这是一个合理的默认选择，我们也是这样做的。

分布式系统领域的人知道接下来会发生什么。主节点会成为瓶颈。然后主节点会失败。它耗尽上下文，或者卡住，或者所在机器宕机，又或者只是开始做出糟糕的决策。

AgentNet 的作者（NeurIPS 2025）直言不讳地指出，现有系统“往往依赖集中式协调，从而导致可扩展性瓶颈、适应性下降和单点故障”。他们的答案是去中心化路由：Agent 根据本地专业能力在彼此之间传递工作。MIT Media Lab 的 Ayush Chopra 走得更远：“真正的分布式系统展现出从 Agent 交互中涌现的协调”，而且“智能存在于交互模式本身，而不在任何单独的决策者中”。

我认为这里不必二选一。分布式系统早在数十年前就通过持久状态、心跳、故障检测、共识、故障转移和领导者选举解决过类似问题。如果领导者消失，另一个节点会接管；它之所以能够接管，是因为它所需的状态从未存在于领导者内部。

一个可靠的系统不能依赖某一个智能进程永远存活。因此，重要的不是 Agent 的生命周期，而是状态的生命周期。目标、计划、决策、已完成任务、待处理任务、工件、所有权和检查点，都应该比任何单个 Agent 活得更久。Agent 来来去去，组织仍会继续。

在分布式编程领域深耕多年的 Christopher Meiklejohn，今年春天直截了当地说：“当多个 Agent 在同一个代码库上工作时，你就拥有了一个分布式系统”，随之而来的问题“不是 bug。[……] 它们是多个共享状态的自治进程存在时不可避免的结果。”

真正有意思的问题

因此，你需要一个调度器、某种层级结构、比工作者生命周期更长的内存、清晰的所有权、背压、故障恢复，以及足够的可观测性来知道哪个 Agent 卡住了。有时你需要一个领导者，以及替换它的方法。

这就是为什么我认为，有意思的基础设施问题不是“我们如何构建一个永远运行的 Agent？”，而是“我们如何调度和协调数百万个不会永远运行的智能工作者？”

操作系统教会了我们如何调度进程。容器编排器教会了我们如何调度和恢复短暂的工作负载。分布式系统教会了我们如何让不可靠的机器汇聚成可靠的服务。人类组织则教会了我们，能力有限的个体如何构建任何单独个人都无法完成的事物。Agent 正处于这四者的交汇点。

单个 Agent 是一个智能问题。一百万个 Agent 是一个分布式系统问题。

这篇文章讨论的是问题。至于一百万个 Agent 的基础设施实际上应该是什么样子——检查点、调度器、给工作者的预算，以及协调者死亡时的交接——值得单独写一篇文章，这也是我接下来要写的内容。

如果你喜欢这篇文章，请告诉我；或者在 X 或 LinkedIn 上关注我，以便看到下一篇。

FAQ

读完本文后，人们常问的三个问题

多 Agent 系统应该有一个中央编排器吗？

通常应该有，但有一个前提。集中式编排器将错误放大控制在 4.4 倍，而独立 Agent 的数值为 17.2 倍。但编排器同时也是瓶颈和单点故障，因此它的状态必须存放在自身之外，并且另一个 Agent 必须能够接管。

什么是 Agent 操作系统？

一种将 Agent 视为进程的运行时系统。AIOS 提出了一种内核，其中包括调度器、上下文管理器、内存管理器、存储管理器、工具管理器和访问控制机制，使许多 Agent 可以共享有限的 LLM、内存和工具容量，而不是让每个 Agent 都假设自己会永远运行。

什么

I think about agents the way I think about people. One agent is a worker. A thousand agents is an organization, and an organization of machines is a distributed system.

People keep telling me agents can run forever. Technically that's true. You can call a model in a loop until your credit card declines. But the agent still runs on finite stuff: tokens, context, compute, memory, tools, money. Something always runs out.

Humans aren't that different. We work for a while and get tired. Our working memory is tiny. We forget things. So we write the important parts down, sleep, and come back the next morning with a clear head and the same identity.

Machines have the same constraint in a different shape. A box runs out of CPU. A pod runs out of memory. Nobody fixes that by assuming every process should live forever. We schedule work over the resources we have.

I don't see why intelligence gets a pass. An agent can work for a while, write down what matters, clear its context, and let itself or another agent pick up from there. We run our own coding agents on VPSes at InsForge, and they get killed, restarted, and run out of context all the time. The failures that actually hurt are the ones where the plan lived only inside the agent's context window.

TL;DR

• Adding agents helped parallel work by up to 80.9% and hurt sequential work by 39% to 70% in Google Research's 180-configuration study. The shape of the task decides.
• An orchestrator cut error amplification from 17.2× to 4.4× in the same study. Coordination is a real job.
• In Silo-Bench (ACL 2026), teams of 2 to 100 agents talked plenty and reasoned badly. The hardest tasks hit zero success at 50 agents.
• So the durable thing should be the state, not the agent. Schedule agents like processes and recover them like nodes.

Agents are starting to look like processes

This stopped being an analogy a while ago. There's a whole research line building it.

AIOS, an "LLM Agent Operating System" out of Rutgers, opens with the problem in one sentence:

"Allowing unrestricted access to LLM or tool resources can lead to inefficient or even potentially harmful resource allocation and utilization for agents."

Their answer is a kernel. Every agent request gets broken into system calls (an LLM call, a memory read, a storage write, a tool use), a scheduler decides whose call runs next using the classics, First-In-First-Out and Round Robin, and a context manager snapshots an agent mid-task so it can be interrupted and resumed. They report up to 2.1× faster execution when serving agents built on existing frameworks.

Scheduling, context switching, memory management, storage, access control. That's an operating system. The processes just happen to think.

It pays one level up too. LLM-as-Scheduler, from ACL 2026, starts from the observation that most queries don't deserve a heavy multi-agent workflow, and lets a scheduler pick the workflow per query. They got 43% fewer tokens and more than 36% lower end-to-end latency, for at most a 1.4 percentage-point drop in accuracy against a strong fixed workflow.

So one agent looks like a process, and thousands of processes need a scheduler. Fine. But scheduling compute is only half of it. You also have to coordinate the agents with each other, and that's where it gets interesting.

Ten people coordinate. Ten thousand invent managers.

Ten people can coordinate themselves in a room. A thousand people can't all talk to each other and independently decide what the company should do, so we invented teams, managers, departments, and eventually a CEO. Managers exist partly because coordination is itself work, and someone has to do it.

I assumed agents would have the same problem. Now there's data.

Google Research and MIT ran a controlled study of 180 agent configurations across five architectures (single agent, plus independent, centralized, decentralized, and hybrid multi-agent) and three model families. Their headline:

"the 'more agents' approach often hits a ceiling, and can even degrade performance if not aligned with the specific properties of the task"

Sequential tasks

−39% to −70%

every multi-agent variant tested made planning-style tasks worse

Parallelizable tasks

+80.9%

centralized coordination on financial reasoning

Same five architectures, opposite outcomes, decided by the shape of the task. Source: Google Research, Towards a science of scaling agent systems , January 2026.

On tasks that need strict sequential reasoning, every multi-agent variant they tested made things worse, by 39% to 70%. Their explanation is that the communication overhead fragmented the reasoning and left too little "cognitive budget" for the actual task. On parallelizable work like financial reasoning, centralized coordination improved performance by 80.9%.

More agents didn't buy more intelligence. They bought more coordination, and coordination eats the same budget the task needs.

The second finding is the one I keep coming back to.

Error amplification: independent agents 17.2x versus centralized orchestrator 4.4x 0× 5× 10× 15× 20× Independent agents: 17.2× error amplification Independent agents (no orchestrator) 17.2× Centralized orchestrator: 4.4× error amplification Centralized orchestrator (one coordinator) 4.4× Maximum error amplification in Google Research's experiments: agents working in parallel without talking amplified errors up to 17.2×; a centralized orchestrator contained the same effect to 4.4×. Source: Google Research, Towards a science of scaling agent systems , January 2026.

Agents working in parallel without talking amplified errors by 17.2×. Put an orchestrator in front of them and it dropped to 4.4×. That's what a manager is for. The manager doesn't do every task. It decides what needs to happen, breaks the work apart, assigns it, watches progress, resolves conflicts, and combines the results.

Communication is not coordination

This one sounds the most human to me.

Silo-Bench, accepted at ACL 2026, gave teams of 2 to 100 agents thirty distributed algorithm tasks, with the data sharded so no single agent could see everything. 54 configurations, 1,620 experiments. The agents could message peers, broadcast, or share files.

They talked a lot. It didn't help much.

"agents spontaneously form task-appropriate coordination topologies and exchange information actively, yet systematically fail to synthesize distributed state into correct answers."

The authors call this the Communication-Reasoning Gap, and their one-line version is better than anything I'd write: "agents are competent communicators but poor distributed reasoners."

It also gets worse with scale.

SILO-Bench success rate by agent count: every difficulty level ends far below where it started, and Level III tasks reach zero success at 50 and 100 agents 0% 25% 50% 75% 100% 2 5 10 20 50 100 agents in the system task success rate Level I (aggregate), 2 agents: 85% success Level I (aggregate), 5 agents: 72% success Level I (aggregate), 10 agents: 68.7% success Level I (aggregate), 20 agents: 65.7% success Level I (aggregate), 50 agents: 38.1% success Level I (aggregate), 100 agents: 40.6% success Level II (mesh), 2 agents: 61.7% success Level II (mesh), 5 agents: 55.3% success Level II (mesh), 10 agents: 28.3% success Level II (mesh), 20 agents: 29.5% success Level II (mesh), 50 agents: 17.4% success Level II (mesh), 100 agents: 14.3% success Level III (global shuffle), 2 agents: 36.2% success Level III (global shuffle), 5 agents: 17.2% success Level III (global shuffle), 10 agents: 10% success Level III (global shuffle), 20 agents: 5.7% success Level III (global shuffle), 50 agents: 0% success Level III (global shuffle), 100 agents: 0% success Level I (aggregate) Level II (mesh) Level III (global shuffle) 0% at 50 and 100 SILO-Bench task success rate versus agent count for DeepSeek-V3.1, averaged across three communication protocols (paper Table 3). The x-axis is ordinal, not linear. Source: Zhang et al., Silo-Bench , ACL 2026 (arXiv:2603.01045).

The trend is down at every difficulty level, with a couple of small upticks along the way (Level I from 50 to 100 agents, Level II from 10 to 20), and none of them come close to recovering. The hardest tasks, the ones that need every shard combined at once, hit zero success at 50 agents and stay there at 100. Across models, the average success rate fell from 61% with 2 agents to 18% with 100 for the strongest model, and from 17% to 1% for the weakest. The authors' conclusion: "coordination overhead compounds with scale, eventually eliminating parallelization gains entirely."

If you've ever been in a 100-person Slack channel you already knew this. Putting 100 people in one channel doesn't give you an organization. Putting 100 agents on one message bus doesn't give you collective intelligence either.

What happens when the manager fails?

Most multi-agent systems today coordinate through a central orchestrator. A master agent decomposes the goal, hands tasks to workers, watches them, and merges the results. The Google numbers say that's a reasonable default, and it's what we do too.

Distributed systems people know what comes next. The master becomes the bottleneck. Then the master fails. It runs out of context, or gets stuck, or its machine dies, or it just starts making bad calls.

The AgentNet authors (NeurIPS 2025) say it directly: existing systems "often rely on centralized coordination, leading to scalability bottlenecks, reduced adaptability, and single points of failure." Their answer is decentralized routing, where agents pass work among themselves based on local expertise. Ayush Chopra at the MIT Media Lab goes further: "genuine distributed systems exhibit coordination that emerges from agent interactions," and "the intelligence is in the interaction patterns themselves, not in any individual decision-maker."

I don't think you have to pick a side here. Distributed systems solved versions of this decades ago with durable state, heartbeats, failure detection, consensus, failover, and leader election. If the leader disappears, another node takes over, and it can do that because the state it needs was never inside the leader.

A reliable system can't depend on one intelligent process staying alive forever. So the thing that matters isn't the lifetime of an agent. It's the lifetime of the state. Goals, plans, decisions, done tasks, pending tasks, artifacts, ownership, checkpoints. Those should outlive any individual agent. Agents come and go. The organization continues.

Christopher Meiklejohn, who spent his career on distributed programming, put it bluntly this spring: "the moment you have multiple agents working on the same codebase, you have a distributed system," and the problems that follow "aren't a bug. [...] They're an inevitable consequence of having multiple autonomous processes that share state."

The interesting problem

So you need a scheduler, some hierarchy, memory that outlives the worker, clear ownership, backpressure, failure recovery, and enough observability to know which agent is stuck. Sometimes you need a leader, and a way to replace it.

That's why I think the interesting infrastructure question isn't "how do we build an agent that runs forever?" It's "how do we schedule and coordinate millions of intelligent workers that don't?"

Operating systems taught us how to schedule processes. Container orchestrators taught us how to schedule and recover ephemeral workloads. Distributed systems taught us how unreliable machines can add up to a reliable service. Human organizations taught us how individually limited people build things no single person could. Agents sit right where those four overlap.

A single agent is an intelligence problem. A million agents is a distributed systems problem.

This post is about the problem. What the infrastructure for a million agents should actually look like, the checkpoints, the scheduler, the budget a worker gets, the handoff when a coordinator dies, deserves its own post, and that's the next one I'll write.

If you liked this one, tell me, or follow me on X or LinkedIn so you catch the next one.

FAQ

Three questions people ask after reading this

Should a multi-agent system have a central orchestrator?

Usually yes, with a caveat. A centralized orchestrator contained error amplification to 4.4×, versus 17.2× for independent agents. But an orchestrator is also a bottleneck and a single point of failure, so its state has to live outside it, and another agent has to be able to take over.

What is an agent operating system?

A runtime that treats agents like processes. AIOS proposes a kernel with a scheduler, context manager, memory manager, storage manager, tool manager, and access control, so many agents can share finite LLM, memory, and tool capacity instead of each one assuming it runs forever.

What should survive when an agent dies?

Goals, plans, decisions, completed and pending tasks, artifacts, ownership, and checkpoints. If that state is durable and outside any single agent, an agent can run out of context, get killed, or be rescheduled, and the work continues.

Sources

• Kim, Liu et al., Towards a science of scaling agent systems: When and why agent systems work, Google Research blog, January 28, 2026. Paper: arXiv:2512.08296.
• Zhang et al., Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems, ACL 2026 main conference. Code.
• Mei et al., AIOS: LLM Agent Operating System, Rutgers University, 2024, revised 2025.
• Xiang et al., LLM-as-Scheduler: Agentic Workflow Dynamic Scheduling, ACL 2026.
• Yang et al., AgentNet: Decentralized Evolutionary Coordination for LLM-based Multi-Agent Systems, NeurIPS 2025.
• Ayush Chopra, What is a Multi-Agent System?, MIT Media Lab, June 16, 2025.
• Christopher Meiklejohn, Multi-Agent Systems Have a Distributed Systems Problem, March 30, 2026.