# Swarm Management of Agent Harnesses
**作者**: Aparna Dhinakaran
**日期**: 2026-05-03T19:03:47.000Z
**来源**: [https://x.com/aparnadhinak/status/2051014879449157952](https://x.com/aparnadhinak/status/2051014879449157952)
---
As we have built our own harness management tools internally at Arize, and watched external systems like Devin @cognition start managing other Devins, managed agents at @AnthropicAI and long running agents from @leerob at Cursor - one thing has become clear: swarm management is the next real systems problem in AI.
Not single agents. Not one-off tool calls. Managing swarms of long-running agents.
Most agent frameworks have crossed the first line: they can spawn subagents.
That is not swarm management.
It is the beginning of the problem.
The interesting question is what happens after the child exists. Where does it live? Who owns it? Can it be addressed? Can it be steered? Can it finish after the parent has moved on? If the process restarts, does the system know what was still running?
This is the next layer above the agent harness. A harness lets one agent call tools, read files, run commands, and keep a loop going. A delegation tool lets one agent borrow workers. A swarm manager owns a fleet.
The core feature of an agent harness is a loop over tools. A swarm manager is a loop over running harnesses, making sure they are progressing.
That distinction sounds academic until you look at real systems.
Hermes has a very good delegation primitive. Its delegate_task tool creates child AIAgent instances, runs them in parallel, streams progress, applies timeouts, interrupts them, and returns structured summaries back to the parent. Clean. Useful. Understandable.
But the child lives inside the parent tool call.
As we looked around the ecosystem for examples of swarm management really working, one of the absolute best examples was hiding in plain sight: OpenClaw.
OpenClaw has a solid swarm management system. Its subagents become gateway sessions. They get durable session keys, run IDs, lifecycle records, parent-child lineage, cleanup policy, and a push-based completion path back to the requester.
That is the architectural line.
Delegation asks: how does one agent split work? Swarm management asks: how does a runtime own many agents over time?
This blog will spend a lot of time highlighting what we think needs to be in swarm management driven by a lot of ideas in OpenClaw.
## The Agent Needs An ID
The first requirement of swarm management is identity.
If you cannot address a child, you cannot manage it. You can wait for it. You can cancel the local future. You can ask the parent to summarize what happened.
But you cannot operate a fleet.
In OpenClaw, a spawned child gets a session key:
agent:<targetAgentId>:subagent:<uuid>
That key is doing real work.
It turns the child into something the gateway can see. The child can be listed. It can be patched. It can be deleted. It can be linked back to a parent. It can show up next to normal chat sessions, cron sessions, and ACP sessions.
The child also gets a run ID. The session key names where the child lives. The run ID names the current execution.
You need both.
A swarm manager has to know the basics: child session key, run ID, requester, controller, depth, role, workspace, task label, cleanup policy, timestamps, and outcome. That metadata answers the questions the runtime cannot hand-wave away.
Who spawned this child? Is it still running? Does it have descendants? Should it be kept as a session or deleted after completion? Did the result actually get delivered?
If those answers only live inside a model's context window, the runtime cannot manage the swarm.
## Completion Is Not A Return Value
Most delegation systems have a simple contract:
1. Parent calls a tool.
2. Child runs.
3. Parent blocks.
4. Child returns a summary.
5. Parent continues.
That is a good contract for bounded delegation.
It breaks down once the parent is not just waiting on the same call stack.
In a real swarm, the parent may be active. Or idle. Or another subagent. Or restarted. Or gone. The child may have children of its own. The result may need to be private orchestration context, not a user-facing message.
OpenClaw handles this with a push-based model. sessions_spawn returns acceptance and bookkeeping. The result arrives later through the registry and announce flow.
Roughly:
1. Parent spawns a child through sessions_spawn.
2. OpenClaw creates a child session.
3. The child run is registered.
4. The child runs in its own session.
5. The registry waits for lifecycle completion.
6. OpenClaw captures the child's latest output.
7. It builds an internal task_completion event.
8. It routes that event back to the requester session.
The important part is the event:
{
type: "task_completion",
source: "subagent",
childSessionKey,
childSessionId,
taskLabel,
status,
result,
replyInstruction
}
That is the parent-child contract: capture completion, preserve provenance, route it to the right session, and let that session decide what to do next.
The delivery layer has policy. It can steer an active requester session, queue an announce for later, call the gateway agent method directly, deliver a user-facing channel message, retry, or fall back to direct send. Most subagent systems skip this part.
They treat completion as a return value. In a swarm manager, completion is a routing problem.
## Queues Matter More Than Prompts
Once agents can spawn agents, the runtime has to care about concurrency in a very practical way.
You need strict ordering within a session. Two messages should not collide inside the same active agent loop. You also need parallelism across sessions. Otherwise the fleet becomes a single-file line.
This is why swarm management starts to look less like an agent framework and more like runtime infrastructure.
Main agent work is one lane. Subagent work is another. Cron or background work may be another. Each lane can have its own concurrency limit, while each session still serializes its own active run.
A user sends a follow-up while an agent is busy. A child finishes while a parent is still running. A child has children. A cron job completes and needs to notify a session. A steer message arrives while a model is streaming.
If all of those are just messages, the system gets messy fast.
Some messages should steer the active run. Some should be queued as follow-ups. Some should interrupt. Some should be summarized or dropped when the backlog gets too large. The answer lives in queue policy, not better prompting.
## Cancellation Is Too Weak
The simplest systems can cancel a future. That is table stakes.
A real swarm manager needs to steer, interrupt, kill, and cascade. Steering is the interesting one.
When a child is doing the wrong thing, you do not always want to kill it and lose the session. You may want to redirect it.
In OpenClaw, steering a controlled subagent is a control-plane operation. It marks the current run for steer-restart, suppresses stale completion announcement, aborts the in-flight run, clears queues, waits for abort to settle, sends a new agent message, and remaps the registry from the old run to the new one. The system is telling the child to stop what it is doing and pivot.
Kill is different. Kill should terminate the run, mark session state, suppress inappropriate completion announcements, and optionally cascade to descendants.
Cascade matters because a swarm is a tree. Killing an orchestrator while leaving its workers alive is usually wrong. Sometimes it is exactly what you want. The runtime needs to know the graph well enough to make that distinction.
This is where prompt-only coordination falls apart.
You cannot ask the model to remember every live child and manually clean up the tree. The runtime has to own the graph.
## Roles Are A Safety Mechanism
Flat swarms do not scale. If every child can spawn every other child indefinitely, the system eventually becomes useless or dangerous.
The simple split is orchestrator and leaf. Orchestrators coordinate. They can spawn workers, inspect status, and synthesize results. Leaves do work. They cannot coordinate further.
This should be enforced in tools, not just suggested in prompts.
OpenClaw tracks spawn depth and resolves subagent capabilities from that depth. It stores spawnDepth, subagentRole, and subagentControlScope in the child session. Leaves lose management tools. Orchestrators keep them within configured depth and child limits.
Hermes has a similar idea in delegate_task: role="leaf" vs role="orchestrator", configurable delegation.max_spawn_depth, and a kill switch for orchestrator behavior. That is the right instinct.
But in a swarm manager, the boundary belongs in the control plane. The model can request a spawn. The runtime decides whether it is legal.
The runtime should know how deep the child is, how many children the parent already owns, which tools are denied to this role, and whether the child can create more children.
No labels, no hand-holding. The system enforces the shape of the swarm.
## Recovery Is How The Runtime Keeps Ownership
A swarm manager cannot fire-and-forget.
If the system owns children, it needs to know when they are stuck, missing, orphaned, completed, or completed but undelivered.
OpenClaw's subagent registry listens to lifecycle events. It uses agent.wait. It tracks active run context. It persists the registry to disk. It restores runs on startup. It has retry timers for announce delivery and grace windows for transient lifecycle errors.
It also runs a sweeper.
The sweeper is not glamorous. It is the part that makes the system real.
It checks active runs without live run context. It reconciles them against session state. It expires old session-mode records after cleanup. It removes or retries stuck pending lifecycle states. It marks delivery failed instead of leaving cleanup half-done forever.
This is operating-system work.
The analogy is not perfect, but it is useful: a swarm manager needs something close to a process table, because the management problem rhymes.
What is running? Who owns it? What happens when it exits? Which children should die with the parent? Which sessions should survive restart? Which outputs have not been delivered?
Without that, the system is mostly launching work and hoping.
## State Outlives The Run
Every swarm manager eventually becomes a cleanup system.
Subagents create state: transcripts, run records, browser sessions, bundle MCP runtimes, attachment directories, workspace files, delivery status, lifecycle hooks, and cost metadata.
Someone has to own that state after the model stops thinking about it.
OpenClaw lets a child be kept or deleted. That choice matters. A one-shot run can clean up transcript and runtime state. A persistent child session should remain addressable. Attachments may be retained or removed. Browser and MCP runtimes need retirement. Context engines need to know whether a subagent ended or was deleted.
This is another place where delegation and swarm management diverge.
In bounded delegation, cleanup can be local. The child object closes. The thread exits. The parent gets JSON.
In swarm management, cleanup is distributed. The child may be a session. The run may be done but delivery not complete. The session may be kept but attachments removed. The parent may need one more wake-up after descendants settle.
Cleanup is a state machine.
That sounds heavy because it is.
But long-running multi-agent systems accumulate state. Pretending otherwise just moves the complexity into bugs.
## The Layer Above The Harness
OpenClaw is interesting because it exposes the swarm manager layer in code.
There is no magical SwarmManager object that makes everything elegant. The swarm emerges from ordinary runtime machinery:
- session keys
- lanes
- run IDs
- registry records
- lifecycle events
- internal completion events
- queue policy
- delivery routing
- cleanup decisions
- recovery sweeps
That is probably what real swarm management looks like: a set of boring control-plane primitives that make many agents survivable.
Hermes shows what good delegation looks like. Spawn workers, stream progress, return summaries, synthesize.
OpenClaw shows what happens when delegation becomes session infrastructure.
The next generation of agent systems will not just ask whether an agent can call tools. That was the harness question.
The next question is where agents live, who owns them, how they report back, how they are stopped, and what survives after restart.
That is the layer that turns "a single agent harness" into a fleet of well coordinated "agents" that can tackle a wide range of tasks.
## 相关链接
- [克斯马 reposted](https://x.com/mrbleem_eth)
- [Aparna Dhinakaran](https://x.com/aparnadhinak)
- [@aparnadhinak](https://x.com/aparnadhinak)
- [8.4K](https://x.com/aparnadhinak/status/2051014879449157952/analytics)
- [@cognition](https://x.com/@cognition)
- [managing other Devins](https://x.com/cognition/status/2034679897084264659)
- [managed agents](https://www.anthropic.com/engineering/managed-agents)
- [@AnthropicAI](https://x.com/@AnthropicAI)
- [long running agents](https://cursor.com/blog/long-running-agents)
- [@leerob](https://x.com/@leerob)
- [3:03 AM · May 4, 2026](https://x.com/aparnadhinak/status/2051014879449157952)
- [8,469 Views](https://x.com/aparnadhinak/status/2051014879449157952/analytics)
---
*导出时间: 2026/5/4 11:15:27*
---
## 中文翻译
# 智能体束的群体管理
**作者**: Aparna Dhinakaran
**日期**: 2026-05-03T19:03:47.000Z
**来源**: [https://x.com/aparnadhinak/status/2051014879449157952](https://x.com/aparnadhinak/status/2051014879449157952)
---
随着我们在 Arize 内部构建了自己的束管理工具，并目睹了 Devin @cognition 等外部系统开始管理其他 Devin 实例，Anthropic 的托管智能体，以及 Cursor 的 @leerob 开发的长运行智能体——有一点变得非常清晰：群体管理是 AI 领域下一个真正的系统工程问题。
不是单一智能体。不是一次性工具调用。而是管理成群的长运行智能体。
大多数智能体框架已经跨过了第一道门槛：它们可以生成子智能体。
但这并不是群体管理。
这只是问题的开端。
有趣的问题在于子智能体存在之后会发生什么。它存在于何处？谁拥有它？能否对它进行寻址？能否引导它？当父进程继续前行时，它能否完成工作？如果进程重启，系统是否知道还有哪些任务正在运行？
这是位于智能体束之上的下一层。束允许一个智能体调用工具、读取文件、运行命令并保持循环运行。委派工具允许一个智能体借用工作线程。而群体管理器则拥有整个智能体舰队。
智能体束的核心特征是对工具的循环。群体管理器则是对运行中的束进行循环，确保它们正在稳步推进。
这种区别听起来很学术，直到你审视实际的系统。
Hermes 拥有非常好的委派原语。它的 `delegate_task` 工具可以创建子 AIAgent 实例，并行运行它们，流式传输进度，应用超时，中断它们，并将结构化摘要返回给父级。干净、有用、易懂。
但是，子级存在于父级工具调用的内部。
当我们环顾生态系统，寻找群体管理真正奏效的例子时，最好的例子之一其实就在眼皮底下：OpenClaw。
OpenClaw 拥有稳健的群体管理系统。它的子智能体会成为网关会话。它们获得了持久的会话密钥、运行 ID、生命周期记录、父子谱系、清理策略，以及一条基于推送的完成路径，可以反馈给请求者。
这就是架构的界限。
委派问的是：一个智能体如何拆分工作？群体管理问的是：一个运行时如何随时间推移管理众多智能体？
本文将花费大量篇幅重点介绍我们认为群体管理所需的内容，这些内容深受 OpenClaw 中诸多理念的启发。
## 智能体需要一个 ID
群体管理的首要要求是身份标识。
如果你无法寻址一个子智能体，你就无法管理它。你可以等待它。你可以取消本地的 future 对象。你可以请求父级总结发生了什么。
但你无法运营一个舰队。
在 OpenClaw 中，生成的子级会获得一个会话密钥：
agent:<targetAgentId>:subagent:<uuid>
这个密钥承担了实际的工作。
它将子级转化为网关可见的对象。子级可以被列出、被修补、被删除。它可以被链接回父级。它可以与正常的聊天会话、cron 会话和 ACP 会话并列显示。
子级还会获得一个运行 ID。会话密钥定义了子级存在的位置。运行 ID 定义了当前的执行。
两者缺一不可。
群体管理器必须了解基本信息：子会话密钥、运行 ID、请求者、控制器、深度、角色、工作区、任务标签、清理策略、时间戳和结果。这些元数据回答了运行时无法敷衍了事的问题。
是谁生成了这个子级？它还在运行吗？它有后代吗？它是应该作为会话保留，还是在完成后删除？结果真的送达了吗？
如果这些答案仅存在于模型的上下文窗口中，运行时就无法管理群体。
## 完成并非返回值
大多数委派系统都有一个简单的契约：
1. 父级调用工具。
2. 子级运行。
3. 父级阻塞。
4. 子级返回摘要。
5. 父级继续。
这对于有界委派来说是一个很好的契约。
一旦父级不仅仅是在同一个调用堆栈上等待，这个契约就会崩溃。
在一个真正的群体中，父级可能是活跃的、空闲的、另一个子智能体、被重启的，或者已经消失。子级可能有自己的子级。结果可能需要是私有的编排上下文，而不是面向用户的消息。
OpenClaw 通过基于推送的模型处理这个问题。`sessions_spawn` 返回接受信息和簿记数据。结果稍后通过注册表和通告流程到达。
大致流程如下：
1. 父级通过 `sessions_spawn` 生成子级。
2. OpenClaw 创建子会话。
3. 子级运行被注册。
4. 子级在自己的会话中运行。
5. 注册表等待生命周期完成。
6. OpenClaw 捕获子级的最新输出。
7. 它构建一个内部的 `task_completion` 事件。
8. 它将该事件路由回请求者会话。
重要的是这个事件：
{
type: "task_completion",
source: "subagent",
childSessionKey,
childSessionId,
taskLabel,
status,
result,
replyInstruction
}
这就是父子契约：捕获完成状态，保留出处，将其路由到正确的会话，并让该会话决定下一步做什么。
交付层具有策略。它可以引导活跃的请求者会话，将通告排队以备后用，直接调用网关智能体方法，交付面向用户的频道消息，进行重试，或回退到直接发送。大多数子智能体系统忽略了这一部分。
它们将完成视为返回值。在群体管理器中，完成是一个路由问题。
## 队列比提示词更重要
一旦智能体可以生成智能体，运行时就必须以一种非常务实的方式来处理并发问题。
你需要在一个会话内进行严格的排序。两条消息不应该在同一个活跃的智能体循环中发生冲突。你还需要跨会话的并行性。否则，整个舰队就会变成单行道。
这就是为什么群体管理开始看起来不太像智能体框架，而更像运行时基础设施。
主智能体工作是一条通道。子智能体工作是另一条通道。Cron 或后台工作可能是第三条通道。每条通道可以有自己的并发限制，而每个会话仍然串行化其自己的活跃运行。
例如，当智能体正在忙时，用户发送了追问；当父级仍在运行时，子级完成了任务；子级又有子级；Cron 作业完成并需要通知会话；在模型流式传输时，引导消息到达。
如果所有这些都只是消息，系统很快就会变得混乱不堪。
有些消息应该引导活跃运行。有些应该作为追问排队。有些应该中断。有些应该在积压过大时被摘要化或丢弃。答案在于队列策略，而不是更好的提示词。
## 仅仅取消是不够的
最简单的系统可以取消一个 future 对象。这是基本门槛。
真正的群体管理器需要引导、中断、杀死和级联。引导是最有趣的一个。
当子级做错了事情时，你并不总是想杀死它并丢失会话。你可能想要重定向它。
在 OpenClaw 中，引导受控的子智能体是一个控制平面操作。它将当前运行标记为引导重启，抑制过时的完成通告，中止正在进行的运行，清除队列，等待中止完成，发送新的智能体消息，并将注册表从旧运行重新映射到新运行。系统是在告诉子级停止正在做的事情并转向。
杀死则不同。杀死应该终止运行，标记会话状态，抑制不适当的完成通告，并选择性地级联到后代。
级联很重要，因为群体是一棵树。杀死一个编排器却让其工作线程存活通常是错误的。有时这正是你想要的。运行时需要足够了解图结构才能做出这种区分。
这就是仅靠提示词进行协调会崩溃的地方。
你不能要求模型记住每一个存活的子级并手动清理这棵树。运行时必须拥有这个图。
## 角色是一种安全机制
扁平的群体无法扩展。如果每个子级都可以无限期地生成其他子级，系统最终会变得无用或危险。
简单的划分是编排器和叶子节点。编排器负责协调。它们可以生成工作线程，检查状态并合成结果。叶子节点负责工作。它们不能进一步协调。
这应该在工具中强制执行，而不仅仅是在提示词中建议。
OpenClaw 跟踪生成深度，并根据该深度解析子智能体的能力。它在子会话中存储 `spawnDepth`、`subagentRole` 和 `subagentControlScope`。叶子节点会失去管理工具。编排器则保留这些工具，但在配置的深度和子级限制之内。
Hermes 在 `delegate_task` 中有类似的想法：`role="leaf"` 对比 `role="orchestrator"`，可配置的 `delegation.max_spawn_depth`，以及针对编排器行为的终结开关。这是正确的直觉。
但在群体管理器中，边界属于控制平面。模型可以请求生成。运行时决定它是否合法。
运行时应该知道子级有多深，父级已经拥有多少子级，哪些工具被拒绝访问该角色，以及子级是否可以创建更多子级。
没有标签，没有保姆式引导。系统强制执行群体的形态。
## 恢复是运行时保持所有权的方式
群体管理器不能“发射后不管”（fire-and-forget）。
如果系统拥有子级，它需要知道它们何时卡住、丢失、成为孤儿、完成，或已完成但未送达。
OpenClaw 的子智能体注册表会监听生命周期事件。它使用 `agent.wait`。它跟踪活跃的运行上下文。它将注册表持久化到磁盘。它在启动时恢复运行。它有用于通告交付的重试计时器和用于瞬态生命周期错误的宽限窗口。
它还运行一个清理程序。
清理程序并不光鲜亮丽。但它是让系统变得真实的部分。
它检查没有活跃运行上下文的活跃运行。它会根据会话状态协调它们。它会在清理后过期的会话模式记录。它会移除或重试卡住的挂起生命周期状态。它标记交付失败，而不是永远留下一半完成的清理工作。
这是操作系统级别的工作。
这个类比并不完美，但很有用：群体管理器需要类似进程表的东西，因为管理问题是相通的。
什么正在运行？谁拥有它？当它退出时会发生什么？哪些子级应该随父级一起消亡？哪些会话应该在重启后存活？哪些输出尚未交付？
如果没有这些，系统主要是在发射工作并寄希望于好运。
## 状态的寿命长于运行
每个群体管理器最终都会变成一个清理系统。
子智能体创造状态：转录本、运行记录、浏览器会话、MCP 运行时束、附件目录、工作区文件、交付状态、生命周期钩子和成本元数据。
当模型停止思考这些状态后，必须有人来拥有它。
OpenClaw 允许保留或删除子级。这个选择很重要。一次性运行可以清理转录本和运行时状态。持久化的子会话应该保持可寻址。附件可以保留或删除。浏览器和 MCP 运行时需要退役。上下文引擎需要知道子智能体是结束了还是被删除了。
这是委派和群体管理分道的另一个地方。
在有界委派中，清理可以是本地的。子对象关闭。线程退出。父级获取 JSON。
在群体管理中，清理是分布式的。子级可能是一个会话。运行可能已完成但交付未完成。会话可能保留但附件已删除。在后代结算后，父级可能还需要再唤醒一次。
清理是一个状态机。
听起来很繁重，确实如此。
但长运行的多智能体系统会积累状态。否认这一点只会将复杂性转化为 Bug。
## 束之上的那一层
OpenClaw 之所以有趣，是因为它在代码中暴露了群体管理层。
没有什么神奇的 `SwarmManager` 对象能让一切变得优雅。群体是从普通的运行时机制中涌现出来的：
- 会话密钥
- 通道
- 运行 ID
- 注册表记录
- 生命周期事件
- 内部完成事件
- 队列策略
- 交付路由
- 清理决策
- 恢复扫描
这可能就是真正的群体管理样貌：一组无聊的控制平面原语，让众多智能体得以存活。
Hermes 展示了良好的委派是什么样子的。生成工作线程，流式传输进度，返回摘要，合成。
OpenClaw 展示了当委派变成会话基础设施时会发生什么。
下一代智能体系统不仅仅是问智能体能否调用工具。那是束层面的问题。
下一个问题是智能体存在于何处，谁拥有它们，它们如何回报，如何被停止，以及重启后什么依然存在。
正是这一层将“单个智能体束”转变为协调良好的“智能体”舰队，能够处理广泛的各种任务。
## 相关链接
- [克斯马 reposted](https://x.com/mrbleem_eth)
- [Aparna Dhinakaran](https://x.com/aparnadhinak)
- [@aparnadhinak](https://x.com/aparnadhinak)
- [8.4K](https://x.com/aparnadhinak/status/2051014879449157952/analytics)
- [@cognition](https://x.com/@cognition)
- [managing other Devins](https://x.com/cognition/status/2034679897084264659)
- [managed agents](https://www.anthropic.com/engineering/managed-agents)
- [@AnthropicAI](https://x.com/@AnthropicAI)
- [long running agents](https://cursor.com/blog/long-running-agents)
- [@leerob](https://x.com/@leerob)
- [3:03 AM · May 4, 2026](https://x.com/aparnadhinak/status/2051014879449157952)
- [8,469 Views](https://x.com/aparnadhinak/status/2051014879449157952/analytics)
---
*导出时间: 2026/5/4 11:15:27*