Agent 集群需要一种新型操作系统，而不是更大的 harness

Pentad Labs · 2026 年 9 月 16 日 · 预计阅读 10 分钟 · 通过电子邮件回复

一个 AI 应用需要 harness。一个企业级 Agent 集群需要操作系统。我想准确说明 agent harness 与 agent OS 的区别，因为两者的主要区别并不在于规模大小。区别在于：当 Agent 不止一个时，harness 的权威性以及它所拥有的事物会发生什么变化。

harness 拥有什么

Charles Holloway 本周在 Colorado Startup Week 发表了一场题为 Build Your Own Harness 的演讲。其中给出了我见过的最清晰的 harness 定义。本文将其视为既定前提。

一个 Agent 是模型加 harness；或许更准确地说：模型（马）套上 harness（缰头、缰绳、马鞍、马勒等）。

• 模型是固定权重、可见上下文、输入 token、输出 token，以及一次一项预测。
• 模型不是文件、工具、记忆、其他会话，也不是任何能在一次模型调用后持续存在的东西。

harness 是你为使模型变得有用而添加的一切，是模型与世界之间的一层。harness 既是模型控制器，也是世界适配器。你认为属于 Agent 的每一项能力，都是你构建、购买或继承而来的东西。

随后，Holloway 将 harness 梳理为围绕共享模型的七项权责：

1. 上下文与状态；
2. 工具；
3. 执行；
4. 编排；
5. 验证；
6. 可观测性；以及
7. 治理与恢复。

他的组织原则是：每一项权责都拥有一项模型无法安全断言的事实。

这正是说 harness 既是模型控制器又是世界适配器的含义。模型说 X，而某个不是模型的东西必须确认 X 是否成立：

• 模型说“已经完成”；模型外部的某个东西必须检查是否真的完成。
• 模型报告自己的历史；模型外部的某个东西必须已经记录过这段历史。

如果模型的主张是唯一证据，那么实际上就不存在证据。等同于根本没有 harness。

一个 Agent 对“猫在垫子上”的主张，当且仅当某个不是 A 的东西验证了猫确实在垫子上时，才是真的。

这是正确的定义，也是正确的检验方式。请注意，它定义的是什么。七项权责中的每一项，都是相对于一次 Agent 运行而言，也就是一次离散的 Agent 活动会话，并且理想情况下会完成有价值的工作。

• 这次运行能够看到什么。
• 这次运行可以调用什么。
• 这次运行的工作在哪里发生。
• 谁可以停止这次运行，等等。

harness 是一个用于让单个 Agent 完成单项工作的控制平面，Holloway 也明确如此表示：工作者负责执行，harness 负责决策。

现在，把 200 个这样的 Agent 放到同一份企业数据上。

操作系统的各个组成部分，都是对资源争用的回答

操作系统就像计算机与程序的政府：两者都需要一种争用管理功能，因为 M 个参与者会对资源提出 N 项请求，而可用资源少于这些请求，也就是存在稀缺性。简而言之，操作系统的任何一个组成部分，都不是因为只有一个程序需要它才被发明出来的。

一台独占整台机器的程序不需要调度器，因为它想运行时就能运行；不需要内存保护，因为没有东西需要防护；不需要文件系统，因为它可以把字节放在任意位置，并记住位置；不需要核算，因为账单由它的所有者承担；也不需要区分监督模式和用户模式，因为机器中只有一个权威主体，那就是该程序。

没有资源争用的地方，就不应存在权威控制。

在计算的头十年左右，这就是全部的安排。每个程序都携带自己的循环、自己的输入输出例程，以及自己关于数据位置的约定。每个程序都有类似 harness 的东西，而该 harness 属于程序自身。

当两个程序希望在同一时间使用同一台机器时，操作系统便出现了，因为两个用户希望同时运行程序。操作系统恰恰在资源被共享、且资源数量少于资源请求数量时出现，也就是在存在稀缺性的情况下出现。

操作系统的每一部分，都是为了应对单个程序不存在的某种争用。

• 调度器应对处理器争用。
• 内存保护应对地址争用。
• 文件系统应对名称争用。
• 核算应对账单争用。
• 监督模式应对权威性争用；这是其他部分赖以成立的前提，因为任何程序都能改写的调度器，并不是真正的调度器。

操作系统不是一个更大的 harness。操作系统是另一类事物，它存在于每一个程序之外，用于管理它们对有限资源的争用。

Agent 集群的七项权责

因此，如果我们逐一考察 Holloway 的七项权责，并询问当 Agent 从一个变成 200 个时——更不用说 2,000 个或 20,000 个——每一项会变成什么，事情就会清晰得多。

对于一个 Agent，上下文与状态是一扇窗口和一段记忆。这段记忆属于 Agent 自己，由它读取、写入和压缩，其他任何东西都不会碰它。

而对于处理同一份企业数据的 200 个 Agent 呢？记忆天然是共享的，因为两个为同一笔贷款进行承保的 Agent，查看的是同一位申请人。问题不再是这次运行能看到什么，而是哪些运行可以看到它。这是一个权限问题。正如我在 7 月所论述的，harness 构建的 Agent 记忆没有可供检查的权限。操作系统将一种在使用者之间具备隔离性的共享存储称为内存管理。其中用于说明这些字节属于谁的部分称为保护。

对于一个 Agent，工具是一份带有 schema 的列表。对于 200 个 Agent，它们是 200 份列表。而企业需要回答的问题是：这些列表的组合，是否构成 Agent 可以对企业资源执行的所有操作集合？没有人写下过这个组合。它只作为 200 张索引卡之和存在，并且每次任意一张卡改变时都会漂移。操作系统将程序可以请求机器执行的封闭操作集合称为系统调用表，将谁可以提出何种请求称为能力（capability）。

对于一个 Agent，执行是一个 worktree 或沙箱。Holloway 在这里很谨慎，而且是正确的：隔离并不能让 Agent 变得安全，它只能让损害变得有界且可知。只有后者是你能够设计的。对于 200 个 Agent，损害上限是 200 个上限之和；“最坏的一次运行能触及什么”的问题，会变成“最坏的一次运行能够触及其他每一次运行中的什么”。操作系统对此的名称是进程，即一个具有边界的地址空间，程序不能仅仅因为自己想要就跨越该边界。

对于一个 Agent，编排是一个序列：先规划，然后实施，然后验证，然后停止。对于 200 个 Agent，问题则是谁现在运行、谁等待、以何种优先级运行、使用何种预算，以及当预算耗尽或更高优先级的运行到来时，谁会被停止。这不是排序，而是调度。调度器是人们最常误以为操作系统可以被简化为的东西。

对于一个 Agent，可观测性是每次运行一份仅追加的日志，以便崩溃后能够重建，而非猜测。Holloway 自己的系统恰好就具备这一点。对于 200 个 Agent，则有 200 份日志。审计员不会问 200 个问题。审计员只会问一个：在第 6 天到第 14 天之间，你的软件看到了这名抵押贷款申请人的哪些数据，又对这些数据做了什么？要从 200 份按运行划分的日志中回答这个问题，需要在从未统一约定的格式之上进行一次从未被编写过的 join。操作系统的回答是具有统一时钟的单一记录，这也是为什么文件系统和日志是内核服务，而不是每个程序都被信任会遵守的约定。

验证与治理应当放在一起，因为在集群范围内，它们会变成同一件事。没有任何 harness 甚至考虑过这种情况。Holloway 针对自我改进场景提出的规则是：用于约束一次运行的策略，必须位于该运行无法改写的地方之外。原因是，能够扩大自身权限的优化器一定会这样做。现在把这条规则放到整个集群中阅读和应用。约束每一次运行的策略，必须位于每一次运行之外。位于每一次运行之外的任何东西，按定义都由它们共享。所有运行共享、且没有任何一次运行能够改写的东西，正是监督模式的定义。决定结果是否发布的关卡，以及决定一次运行能否开始或必须停止的权威，不应是 200 个关卡和 200 个权威。它们要么是一个，要么政策就在 200 个地方悄然漂移；而这正是 Holloway 自己的矩阵中列出的、治理没有所有者时会出现的失败模式。

Agent 集群新增的两项事实，harness 无处安放

有两项事实必须由操作系统拥有，但 harness 的 schema 中没有对应的行。

第一项是核算。这次运行花费的是谁的预算？对于单个 Agent，答案显然是你的，因此没有任何 harness 需要为它增加一个字段。当 200 个 Agent 分布在四个业务部门中时，账单是一项模型无法断言、Agent 无法断言的事实；按运行记录的日志也只会以该次运行的货币单位记录它。企业希望以企业自己的货币单位看到它。

第二项是身份。这是哪个 Agent，它代表谁行事，又凭借谁的授权访问资源？对于独立的单个 Agent，答案是你：它在你的登录身份下运行，harness 继承了你的身份，却没有意识到自己已经这样做了。当数量达到 200 个时，Agent 身份与任何个人的身份都是不同的东西；它比任何一次会话存活得更久；没有它，审计员的问题就无法回答。

这两项都是仅存在于 Agent 之间的事实。两者都不是 harness 关心的问题，因为 harness 中并不存在“之间”。

为什么 harness 无法长成操作系统

人们很容易认为，只要不断加入足够多的权责，harness 最终就会成为 Agent 操作系统；就像一个足够大的程序在幸运时会成为平台一样。但由于一个无法靠更多努力克服的结构性原因，事实并非如此。

harness 存在于 Agent 运行内部；否则，它便无法完成自己的工作：向模型中介世界，并以某种有限的方式控制模型对世界的影响。harness 的这种内部性，恰好使它成为 harness：它是模型与世界之间的一层，由该 Agent 的索引卡配置。Holloway 的控制平面——接纳工作、选择工作者与预算、执行策略、记录发生的事情——是为一个项目及其运行而存在的。将它复制 200 次，你就拥有了 200 个控制平面。但如果你有 200 个控制平面，那么显然你实际上拥有零个有效控制平面。真正重要的事实，即无论整个集群是否遵守策略，都不是它们中任何一个可以断言的事实。必须有某个处于它们全部之外的东西，拥有所有对有效控制而言重要的事实。

那个东西不是更大的 harness。它是 harness 运行其上的东西。

想想一个类比：Unix 不是 libc，libc 也不是 Unix，尽管从某种非常真实的历史意义上说，两者若没有彼此都难以想象。C 运行时不断增加程序可能需要的各种便利，却从未成为内核本身，因为内核的职责是成为程序无法改写的东西，而库按定义就是程序链接进来的东西。权威性检验可以给出结论。如果这项事实是“该集群处于策略范围内”，那么拥有这项事实的主体不能是集群中的任何成员，也不能是任何成员的组成部分。

这一押注

所以：面向 Agent 的操作系统。Agent 完成工作。操作系统管理 Agent；它之所以能管理 Agent，是因为它位于每一个 Agent 之外，负责调度、隔离、记录、核算，并决定拒绝或允许、继续或停止、现在还是稍后。

这就是 WunderOS：面向 Agent 的操作系统。Holloway 的演讲是我所知对应用所需那一层最好的阐述，而操作系统必须假定那一层存在，并站在它之外。企业的问题——我们如何让一组 Agent 在符合我们独有的审计与风险要求的前提下，可靠且可接受地完成广泛任务——是一个关于“之间”的问题，而“之间”正是操作系统存在的地方。

← All posts

An agent fleet needs a new kind of OS, not a bigger harness

Pentad Labs · September 16, 2026 · 10 min read · Reply by email

An AI application needs a harness. An enterprise fleet of agents needs an operating system. I want to say exactly what the difference between agent harness and agent OS is, because it is not chiefly the difference between small and big. The difference is what happens to the authority of a harness and to what it owns when there is more than one agent.

What a harness owns

Charles Holloway gave a talk at Colorado Startup Week this week called Build Your Own Harness. It contains the clearest definition of a harness I’ve seen. I take it here as given.

An agent is a model plus a harness; maybe better: a model (the horse) wrapped by a harness (bridle, reins, saddle, martingale, and so).

• A model is fixed weights, a visible context, tokens in, tokens out, one prediction at a time.
• The model is not files, tools, memory, other sessions, or anything that survives a call to the model.

The harness is everything you add to make the model useful, the layer between it and the world. A harness is both a model-controller and a world-adapter. Every capability you think of as the agent’s is something you built, bought, or inherited.

Holloway then inventories the harness as seven authorities around a shared model:

1. context and state,
2. tools,
3. execution,
4. orchestration,
5. verification,
6. observability, and
7. governance with recovery.

His organizing rule is that each authority owns a fact the model cannot safely assert.

That’s what it means to say the harness is both model-controller and world-adapter. The model says X and something that isn’t the model has to see if X is the case:

• The model says “it’s done”; something outside the model must check that it is.
• The model reports its history; something outside the model must have recorded it.

If the model’s claim is the only evidence, then there is no evidence. Effectively there’s no harness at all.

An agent’s claim that “the cat is on the mat” is true if and only if something that isn’t A verifies that the cat is on the mat.

That is the right definition and the right test. Notice what it is a definition of. Every one of the seven authorities is stated relative to an agent run, i.e., a discrete session of agent activity and, ideally, useful work.

• What this run can see.
• What this run may call.
• Where this run’s work happens.
• Who may stop this run, and so on.

The harness is a control plane for one agent doing one job, and Holloway says as much: workers execute, the harness decides.

Now put two hundred of them on the same enterprise data.

The parts of an operating system are answers to contention

An operating system is like a government for computers and programs: in each case, a contention-management function is required because M actors make N claims on resources where there are fewer resources than there are claims on them, i.e., where there is scarcity. In short, no part of an operating system was invented because only one program needed it.

A program that has the whole machine to itself needs no scheduler, since it runs whenever it wants; no memory protection, since there is nothing to protect it from; no filesystem, since it can put bytes wherever it likes and remember where; no accounting, since the bill is its owner’s; and no distinction between supervisor mode and user mode, since there is only one authority in the box and it’s the program.

Where there is no contention for resources, no authority should be.

For the first decade or so of computing that was the whole arrangement. Each program carried its own loop, its own input and output routines, its own conventions for what was where. Each program had something akin to a harness, and the harness was the program’s.

The operating system appeared when two programs wanted the same machine at the same time because two users wanted to run programs at the same time. Operating systems arise exactly when resources become shared and are less numerous than resource-claims, that is, in the presence of scarcity.

Every part of an operating system answers a contention that doesn’t exist for a single program.

• The scheduler answers contention for the processor.
• Memory protection answers contention for addresses.
• The filesystem answers contention for names.
• Accounting answers contention for the bill.
• Supervisor mode answers contention for authority, which is the one the others depend on, because a scheduler that any program can rewrite is not a scheduler.

An operating system is not a big harness. An operating system is a different kind of thing, which exists outside every program in order to manage their contention over limited resources.

The seven authorities for a fleet of agents

So this all becomes clearer if we take Holloway’s seven one at a time and ask what each becomes when there are two hundred agents (to say nothing of two or twenty thousand) instead of one.

Context and state, for one agent, is a window and a memory. The memory is the agent’s own, which it reads and writes, compacts, and which nothing else touches.

For two hundred agents working the same enterprise data? Memory is shared by construction, since two agents underwriting the same loan are looking at the same applicant, and the question is no longer what this run can see but which runs may see it. That is a permissions question and, as I argued in July, agentic memory, as harnesses build it, has no permissions to check. The operating system’s name for a shared store with isolation between its users is memory management. The part of it that says whose bytes these are is protection.

Tools, for one agent, are a list with schemas. For two hundred agents they are two hundred lists, and the enterprise question is whether the combination of those lists is the set of things agents may do to enterprise resources. Nobody wrote that combination down. It exists only as the sum of two hundred index cards that drifts every time a card changes. The operating system’s name for the closed set of things a program may ask the machine to do is the system call table , and the name for who may ask for which is a capability.

Execution, for one agent, is a worktree or a sandbox. Holloway is careful here and correct: isolation does not make an agent safe, it makes the damage bounded and knowable. Only the second of those is something you can design. For two hundred agents the bound on damage is the sum of two hundred bounds, and the question of what the worst run can reach becomes the question of what the worst run can reach in every other run. The operating system’s name is the process , an address space with a boundary the program cannot cross just because it wants to.

Orchestration, for one agent, is a sequence: plan, then implement, then verify, then stop. For two hundred agents it is who runs now, who waits, at what priority, under what budget, and who gets stopped when the budget is gone or a higher-priority run arrives. That isn’t sequencing, it’s scheduling. A scheduler is the thing an operating system is most often mistaken for being reducible to.

Observability, for one agent, is a journal per run, append-only, so that a crash is reconstructable rather than a guess. Holloway’s own system has exactly this. For two hundred agents there are two hundred journals. An auditor doesn’t ask two hundred questions. The auditor asks only one: what did your software see and do with this mortgage applicant’s data between the sixth day and the fourteenth. Answering that from two hundred per-run journals is a join nobody has written, over formats nobody agreed. The operating system’s answer is a single record with one clock , which is why the filesystem and the log are kernel services and not conventions each program is trusted to follow.

Verification and governance go together, because fleet-wide they become the same thing. Which no harness even so much as contemplates. Holloway’s rule for the self-improving case is that the policy that bounds a run must sit outside what the run can rewrite. His reason is that an optimizer that can widen its own permissions will widen them. Now read and apply the rule fleet-wide. The policy that bounds every run must sit outside every run. Whatever sits outside every run is, by definition, shared by all of them. Whatever is shared by all of them and cannot be rewritten by any of them is the definition of supervisor mode. The gate that decides whether a result ships, and the authority that decides whether a run may start or must stop, are not two hundred gates and two hundred authorities. They are one or they are policy drifting silently in two hundred places, which Holloway’s own matrix lists as the failure when governance has no owner.

Two facts a fleet of agents adds that a harness has no place for

There are two facts an operating system must own for which a harness has no row in its schema.

The first is accounting. Whose budget did this run spend. For a single agent the answer is trivially yours, so no harness ever grew a slot for it. At two hundred agents across four business units the bill is a fact the model cannot assert, the agent cannot assert, and the per-run journal records only in the currency of that run. The enterprise wants it in the currency of the enterprise.

The second is identity. Which agent is this, acting for whom, with whose authority to access resources? For a lone agent the answer is you, running under your login, and the harness inherits your identity without noticing it has done so. At two hundred the agent’s identity is a distinct thing from any person’s, it outlives any session, and the auditor’s question is unanswerable without it.

Both are facts that exist only between agents. Neither is a harness concern, because there is no between in a harness.

Why a harness cannot grow into an operating system

It’s tempting to think that a harness with enough authorities added becomes an operating system for agents, the way a large enough program becomes a platform, if you’re lucky. But it doesn’t, for a structural reason that doesn’t yield to more effort.

A harness lives inside the agent run since, otherwise, it couldn’t do its job of mediating the world to the model and controlling the model’s effects on the world in some limited way. It’s exactly the harness’s insideness that makes it a harness: the layer between model and the world, configured by this agent’s index card. Holloway’s control plane—which admits work, chooses a worker and a budget, enforces policy, and records what happened—exists for a project and its runs. Multiply it by two hundred and you have two hundred control planes. But if you have two hundred control planes, then of course you have zero effective control plane. The fact that matters, whether or not the fleet as a whole is inside policy, is not a fact any of them can assert. Something outside all of them must own all the facts that matter to effective control.

That something is not a bigger harness. It is the thing the harnesses run on.

Consider an analogy: Unix isn’t libc and libc isn’t Unix, despite the fact neither is, in some very real sense, imaginable without the other historically. The C runtime grew every convenience a program could want and never became the kernel itself, because the kernel’s job is to be the thing the program cannot rewrite, and a library is by definition something the program links in. The authority test settles it. If the fact is “this fleet is within policy,” the owner of that fact cannot be any member of the fleet, nor a proper part of any member of the fleet.

The bet

So: an operating system for agents. The agents do the work. The operating system manages the agents, and it manages them by being the thing outside every one of them that schedules, isolates, records, accounts, and says no or yes, keep going or stop, now or later.

That is what WunderOS is, an operating system for agents. Holloway’s talk is the best account I know of the layer an application needs, and it is the layer an operating system must assume and then stand outside of. The enterprise question, how do we make a family of agents do a wide range of things reliably and acceptably under audit and risk requirements that are uniquely ours, is a question about the between, and the between is where an operating system lives.