Agent 未走向统一操作系统 而是形成 Agent Execution Plane

过去一阵子，行业很喜欢用两个词：

Agent Kubernetes（K8s 开源容器编排系统）

Agent OS。

截至 2026 年，Agent 确实正在催生一层独立基础设施；但这层基础设施远没有收敛成一个统一的“Agent OS”。

更准确的名字或许是：

Agent Execution Plane，Agent 执行平面。

它不关心 Agent 怎么思考。

它关心的是：Agent 能做什么、能花多少、做到哪里、做得对不对。

一、Agent OS 的方向是对的，名字却把问题装得太满了

Google 最近开源的 AX，是这轮讨论中最值得关注的信号之一。

AX 把自己定义为一个“高吞吐、声明式的 Agent 编排器”：开发者声明 Task、Workspace、Model 等对象，由系统将 Agent 放进隔离环境、挂载工作区、管理生命周期，并尝试在集群里运行海量自主 Agent 工作负载。

很像“Kubernetes for Agents”。

但 AX 自己也在 README 里写得非常谨慎：核心概念、协议和规范都还在快速变化，稳定版本之前很可能出现大量不兼容调整。

AX 的价值在于：Google 已经判断，Agent workload 值得拥有 Kubernetes 之上新的原语。

Task、Workspace、Model、Sandbox、Suspend、Resume，这些东西不是传统容器编排系统天然理解的对象。

与此同时，行业里还有一批看似相似、实则完全不同的产品：

• Orca 解决的是一个人如何同时管理多个 Coding Agent；
• Zeron 解决的是不同 Agent Session 的统一控制与监督；
• MCP 解决的是 Agent 如何连接工具与数据；
• A2A 解决的是 Agent 如何彼此通信；
• Skills 解决的是能力如何被封装、携带和复用；
• Temporal、Durable Task 一类系统解决的是任务如何跨崩溃、等待与重试持续执行；
• Managed Agents 则试图把 Harness、Session、Sandbox 一起托管起来。

它们都属于 Agent 基础设施。

但它们解决的不是同一个问题。

把这一整套东西统称为“Agent OS”，就像把数据库、浏览器、Kubernetes、IDE、OAuth 和 Git 都叫作“互联网操作系统”。

方向没有错，分层却没有发生。

二、Agent 基础设施已经形成，但它是一张栈

Agent Execution Plane：一套正在形成的七层结构

从下往上看，最底层依然是 Kubernetes、虚拟机、网络、存储和算力。

Agent Runtime 负责把这些资源变成一个 Agent 真正能工作的环境：文件系统、终端、浏览器、工作区、隔离边界与状态快照。

Durable Execution 处理更传统、却也更关键的问题：Agent 挂了怎么办？等待人工审批时怎么办？定时器到了怎么办？外部服务晚一天才返回怎么办？

Harness 则是模型真正开始“干活”的地方。它决定模型看到什么、记住什么、如何调用工具、什么时候重试、何时停止、怎样拆任务，以及出了错如何恢复。

再往上，Orchestrator 才负责多个 Agent 的分工、交接、并发和汇总；Control Plane 则决定这些 Agent 的身份、权限、预算、路由、观测与评估方式。

最上面的 Human Control，不是一个 UI 皮肤，而是人类在 Agent fleet 时代的新工作台：看异常、看进度、比结果、接管任务、批准高风险动作。

这套分层真正重要的地方在于：每一层面对的失败都不同。

• Sandbox 失败，可能是环境泄露；
• Durable Execution 失败，可能是任务丢失或重复执行；
• Harness 失败，可能是上下文劣化、循环失控或工具误用；
• Orchestration 失败，可能是错误在多个 Agent 间传递；
• Evaluation 失败，可能是系统稳定产出“看起来完成、实际上错误”的结果；
• Human Control 失败，可能是人类在一堆审批与日志前失去判断力。

Agent OS 这个词，把这些不同的失败压扁了。

Agent Execution Plane，则把它们重新拆开。

三、Kubernetes 无法判断 Agent 是否“做对了”

用Kubernetes 容器编排系统类比并不是完全错误。

Agent 与传统容器任务确实有很多相似处：

• 都需要调度；
• 都需要隔离；
• 都需要生命周期管理；
• 都需要资源配额；
• 都需要多租户；
• 都需要观测；
• 都需要处理失败。

但两者之间有一条决定性的差异。

一个 Kubernetes 的 liveness probe 可以告诉你：

容器还活着。

但它无法告诉你：

这篇研究真的完成了吗？
这个 PR 修的是正确的 bug 吗？
这份退款有没有重复发出？
这个 Agent 是否在错误的数据库里执行了正确的 SQL？

Agent 系统需要的，不只是健康检查，而是一种新的东西：

Semantic Health，语义健康。
或者说，Outcome Verification，结果验证。

它判断的不是“程序还在不在”。

而是“它是否还在朝正确结果推进”。

这就是为什么 AX 更准确的理解，不是“替代 Kubernetes”，而是：

Kubernetes above Kubernetes。

底层 Kubernetes 管机器与容器。
Agent Runtime 管状态化沙箱与执行环境。
Agent Control Plane 管智能工作负载的权限、资源、状态和质量。

四、Harness 它未必会成为长期独立产品层

Agent 基础设施中，第一个被实验明确证明重要的层，是 Harness。

Claw-SWE-Bench 做过一个很有价值的控制实验：固定模型、任务集、Docker Runtime 和官方评测器，只替换 Agent Harness。

在同一 GLM 5.1 模型下，minimal adapter 的 Pass@1 是 19.1%；完整 Harness/adapter 则达到 73.4%。

这不是小优化。

这是同一颗“脑子”，换了一套执行结构后，能力出现了数量级差异。Claw-SWE-Bench 的设计本身，就是把 Harness 从“工程细节”提升为可独立测量的性能变量。

于是，Agent 的能力更接近这样一个乘积：

Agent Performance
=
Model
× Harness
× Environment
× Tools
× Verifier

其中任何一项接近零，整体能力都可能崩掉。

这也是为什么 Harness 开始从“提示词工程的边角料”，变成一种独立工程学。

Meta-Harness 做得更进一步：它不让工程师手工调 Harness，而是让一个外层系统直接阅读执行轨迹、分数和历史候选方案，然后搜索并修改 Harness Code。论文中，自动发现的 Harness 在文本分类上提升 7.7 个点，同时把 Context Token 压低到四分之一；在高难数学和 Agentic Coding 任务中，也超过了手工设计基线。

WHALE 则把问题再推进一步：

不是只优化模型权重。
也不是只优化 Harness。
而是权重和 Harness 交替优化。

因为模型变了，最佳 Harness 也可能变；Harness 变了，模型可被激发出来的能力也会变。WHALE 在多个任务上，优于单独优化权重或单独优化 Harness 的方案。参见一篇 Agent 论文揭开了生产真相：能力可以耦合，执行必须标准化

这说明了一件很重要的事：

Harness 不是 Prompt。
Harness 是模型能力外溢成行动能力时，必须经过的执行结构。

但故事的反转也从这里开始。

五、Harness悖论：它越重要，越可能变薄、被吞掉

如果 Harness 对性能如此重要，它会不会成为一个长期独立、价值巨大的基础设施层？

未必。

因为 Harness 里的很多复杂逻辑，本质上都是对“当前模型还做不到什么”的补丁。

模型不擅长长程任务，就补 context reset。
模型容易忘任务，就补 handoff 文件。
模型不会自己拆任务，就补 planner。
模型容易停不下来，就补 stop rule。
模型不知道结果是否正确，就补 judge 和 verifier。
模型不擅长管理上下文，就补 memory scaffold。

问题是，模型能力一旦上升，其中一部分补丁就会过期。

Anthropic 在 Managed Agents 的工程复盘中提到过一个很典型的案例：他们曾针对旧模型加入一套上下文重置机制，但换到更新模型后，原先需要被频繁重置的行为消失了，那套机制反而变成了累赘。

Anthropic 的表述很准确：

Harness 编码了关于模型能力边界的假设。
而模型变强后，这些假设可能失效。

这意味着未来会出现一个非常反直觉的趋势：

Harness thinning，Infrastructure thickening。
Harness 变薄，基础设施变厚。

模型越来越强之后，下面这些东西可能会逐渐变薄：

复杂的 Planner
人为 Task Decomposition
Context Reset Hack
固定的 Handoff Scaffold
过度明确的推理脚手架

但下面这些不会随着模型变聪明而消失：

Sandbox
Permission
Durable State
Budget
Evaluation
Observability
Identity
Audit
Side-effect Control

模型变强，只会让它获得更大的行动半径。

行动半径越大，确定性基础设施反而越重要。

这也解释了为什么大厂正在快速吞掉通用 Harness。

OpenAI 在 9 月发布 Agents API 时，直接把它定义为“由 OpenAI 托管的 Codex Harness”。官方列出的能力包括：管理 Context、有效调用工具、拆分子任务、协调 Subagent、跨 Session 恢复工作，以及在文件与代码环境中连续运行数天。

Anthropic 的 Managed Agents、AWS 的 AgentCore Harness、Microsoft 的 Agent Framework Harness，也都在做类似的事：把通用的 Agent Loop、Context、Memory、Planning、Approval、Telemetry 做成托管能力。

所以，通用 Harness 的价值并不是不存在。

恰恰是因为它重要、通用、标准化，它才最容易被模型厂商和云厂商内置。

六、真正长期留下来的，是 Harness Contract

Anthropic 的 Managed Agents 架构，给了一个特别好的启发。

它把一个 Agent 拆成三部分：

Brain = Model + Harness
Hands = Sandbox + Tools
Session = Durable Event Log

Harness 负责调用模型、组织上下文、路由工具请求。

Sandbox 负责运行代码、写文件、执行命令。

Session 则独立保存发生过的一切：消息、工具调用、结果、中间状态、任务历史。

这个拆法的价值在于：三者可以分别失败、分别重启、分别替换。

Sandbox 挂了，可以新开一个。
Harness 挂了，可以从 Session Log 恢复。
模型升级了，可以替换模型。
Harness 逻辑变了，也可以换新的实现。

真正稳定的，不再是某一套复杂 Harness 逻辑。

而是几个能跨模型、跨 Harness、跨运行环境存在的接口：

Session Interface
Sandbox Interface
Tool Interface
Model Interface
Policy Interface
Evaluation Interface

Anthropic 将这种做法描述为把 Agent 的“脑”和“手”解耦：Session 是外置、持久的事件日志；Harness 与 Sandbox 都可以成为随时替换的执行实体。

这是一种非常操作系统式的思想。

操作系统并不需要知道未来每一个程序如何运行。
它需要提供足够稳定的抽象：进程、文件、网络、权限、内存。

未来的 Agent Execution Plane 也许不需要预测未来每一种 Harness。

它需要提供足够稳定的抽象：Session、Workspace、Sandbox、Policy、Budget、Evaluation、Artifact。

七、Agent 最难恢复的，是“已经发生过的事”

传统分布式系统里，一个服务崩了，很多时候可以重启。

Agent 世界里，最难的问题不是 restart，而是 resume。

因为 Agent 的状态远不是一个变量。

它可能同时分布在：

Conversation
+ Compacted Context
+ Filesystem
+ Git State
+ Browser State
+ Database State
+ Tool State
+ Memory
+ Artifacts
+ External Side Effects

一个 Agent 写了文件、切了分支、跑了一半部署、提交了一次表单、发了一封邮件、调用了支付接口，然后崩了。

此时，“重新执行一次”未必是恢复。

它可能是二次提交、重复扣款、重复发信、重复删库。

这也是为什么 Agent Infra 没有推翻 Temporal 一类 Durable Workflow 系统，反而正在重新发现它们过去十年解决过的问题：

• Event History；
• Checkpoint；
• Retry；
• Timer；
• Human Approval；
• Resume；
• Long-running Workflow。

Temporal 已经开始提供将 OpenAI Agents SDK 接入 Durable Workflow 的方式，让模型调用和工具调用具备跨失败恢复、等待人类输入和保持执行历史的能力。

但 Temporal 解决的仍主要是：

什么时候执行？
失败怎么办？
等待怎么办？
从哪里继续？

Agent-specific infrastructure 还必须继续回答：

下一步该做什么？
要不要继续？
该调用哪个工具？
这个结果是否足够好？
这一步有没有超出权限？
还允许花多少钱？

这就是传统 Workflow Engine 与 Agent Execution Plane 的边界。

前者让执行可靠。
后者还要让智能行动可控。

八、Multi-Agent 最显眼，但它不是最深的问题

这两年，最容易让人兴奋的 Agent 演示，往往是“一次启动 20 个 Agent”。

一个做研究。
一个写代码。
一个测试。
一个审查。
一个查资料。
一个汇总。
一个再审查。

这类画面很有未来感。

但“更多 Agent 一定更强”，并不成立。

Google Research 对 180 种 Agent 配置做过控制实验，结论相当直接：

• 对可并行拆分的任务，多 Agent 可以明显提升表现；
• 对强顺序依赖的任务，所有测试过的多 Agent 架构都出现了 39%—70% 的性能下降；
• 独立 Agent 架构的错误放大最高可达 17.2 倍。

所以，真正的判断函数不是：

更多 Agent = 更高能力

而更像：

收益
=
任务可并行性
× 子任务独立性
× 验证质量

－ 协调成本
－ Context Transfer Loss
－ Token Cost
－ Error Propagation

研究任务天然更适合多 Agent。

因为它可以进行广度优先搜索：不同 Agent 各自找资料、找案例、找反例、做不同方向的验证。

但 Coding 并不天然适合高并发多 Agent。

Coding 是 Agent Infrastructure 最好的实验场：

Git = State
Worktree = Isolation
Tests = Verifier
Repository = Environment
Diff = Artifact
CI = Evaluation

但同一个代码库中的工作，往往有强顺序依赖。

一个人改了接口，另一个人的测试、类型、依赖和实现都可能随之变化。此时更多 Agent 带来的不一定是并行，而可能是更多 Context 转移、更多冲突、更多错误传播。

所以，Multi-Agent 并不是下一代 Agent Infra 的最终答案。

它只是一个需要被严肃治理的执行形态。

九、真正的瓶颈，正在从 Orchestration 转向 Verification

今天，Fan-out、Fan-in、Handoff、DAG、Planner-Worker 等编排结构已经并不稀缺。

很多框架都会。真正昂贵的问题是：

我怎么知道 Agent 做完了？

再进一步：

我怎么知道它做对了？

一个 Agent 可以运行六小时，调用一百次工具，给出一份看起来极其完整的结果。

但它可能：

• 在错误的目录改了文件；
• 用错误版本的数据做了分析；
• 漏掉了关键异常；
• 在没有真实验证的情况下宣布任务完成；
• 只通过了局部测试；
• 在错误的权限边界内操作；
• 为了通过某个评估指标，绕开了真正目标。

所以，未来更重要的结构或许不是：

Agent → Tool

而是：

        Planner
           │
           ▼
        Generator
           │
           ▼
        Verifier
           │
      ┌────┴────┐
      │             │
    PASS             RETRY

问题甚至在于：Verifier 自己也可能不可靠。

它可能看到一个 bug，却觉得“好像问题不大”；可能过度相信 Generator 的解释；可能只检查表面产物，而没有检查真实外部状态。

于是，Evaluation 不能再只是 Benchmark 阶段的东西。

它要进入 Runtime。

AWS 已经把这件事做成 AgentCore 的正式能力：对生产流量进行持续评估，围绕任务完成度、工具使用、安全性、响应质量等维度提供 13 类内置 Evaluator，并支持自定义评估标准。

这背后是一个非常大的变化：

Evaluation 正从 Benchmark Tooling，进入 Runtime Infrastructure。

 评估正从基准工具迁移到运行时基础设施。

传统系统的 Observability 能告诉你：

CPU 多高。
延迟多长。
调用了多少次接口。
哪一个服务报错。

Agent 系统的 Observability 还必须看到：

Token Usage
Tool Calls
Model Calls
Trajectory
Context Growth
Retry Count
Handoff
Budget
Verifier Result
Task Progress
Permission Decision
Artifacts

但即使看见这些，也只能回答：

Agent 做了什么。

它仍然无法天然回答：

Agent 做得好不好。

而这，正是未来最难、也最有价值的一层。参见从 Token 到 State：AI 的下一个战场，为什么是 World Model

十、安全会被更强模型放大

还有一个很容易被忽略的误解：

模型更聪明之后，人类审批就够了。

事实恰恰相反。

Anthropic 在 Claude Code 与 Cowork 的安全工程复盘中披露：用户大约会批准 93% 的 Permission Prompts。审批出现得越频繁，人越容易失去注意力，最后把“批准”变成一种条件反射。

这就是 Approval Fatigue。

因此，人类在环并不是万能保险。

未来更可靠的方式，不是让人反复点“确认”，而是通过结构性边界控制 Agent 能做什么：

Sandbox
VM
Credential Isolation
Network Egress Policy
IAM
Secrets Boundary
Budget Limit
Audit Trail
Side-effect Control

模型越强，它能触达的系统越多，潜在 blast radius 越大。

所以 Control Plane 不应该只负责 Dashboard 漂不漂亮。

它负责的是 Agent 的行为边界。

模型能力越强，Control Plane 越重要。

十一、未来的 Agent Infra，不会收敛为一个 Agent OS

未来两三年，比较可能出现的不是一个统一 Agent OS，而是几条同时收敛的路径。

第一条，是模型厂商吞掉通用 Harness。

OpenAI、Anthropic、AWS、Microsoft 都已经在做。对创业公司而言，一个“帮你写 Agent Loop 的 SDK”，会越来越难形成长期壁垒。

第二条，是 Workflow Engine 吸收 Agent 语义。

Temporal、Durable Task、Step Functions 不会过时。它们会在原有的可靠执行能力之上，接入模型调用、Agent Session、Human-in-the-loop 与持续状态。

第三条，是 Agent Runtime 变成独立基础设施。

Stateful Sandbox、Suspend/Resume、Warm Environment、Workspace Mount、Session Recovery、高密度多路复用，这些都是传统 Container Runtime 没有完全围绕 Agent 优化的问题。

第四条，是 IDE 变成 Agent Control Room。

未来开发者可能不再是“我写代码”。

而是：

我同时管理 5—20 个正在写代码、跑测试、查资料、修复问题的执行单元。

这也是 Orca、Zeron、Codex App 一类产品真正值得关注的地方：它们未必是新的 Runtime，却可能在定义人类如何监督 Agent fleet。

第五条，是协议层逐渐标准化。

MCP     → Agent 与 Tool / Data
A2A     → Agent 与 Agent
Skills  → 可复用能力包

协议一旦变得可互通，竞争重点就会从“能不能连接”转向：

谁更能运行、验证、治理和审计这些能力。

十二、真正的护城河，可能是“什么叫做做对”

从商业角度看，通用 Harness 会越来越容易被内置。
通用 Loop 会越来越容易被商品化。
通用 Skills Format 的标准价值也会逐步下降。

但下面这套组合，反而会越来越重要：

Agent+Environment+DomainEvaluator+ProprietaryTraces+Verification+Workflow  智能体、环境、领域评估器、专有追踪数据、验证与工作流

因为真正难复制的，不是“怎样调用模型”。

而是：

在这个具体领域里，什么叫做做对。

医疗 Agent 的“做对”，不是回答像医生。
财务 Agent 的“做对”，不是生成一张漂亮表格。
客服 Agent 的“做对”，不是正确调用工单接口。
Coding Agent 的“做对”，也不只是代码能编译。

它们都需要一个真实环境、一套领域规则、可验证的结果、失败后的恢复路径、权限与责任边界。

这才是未来 Agent 产品最深的护城河。

不是模型能不能调用工具。

而是它能否在真实世界里，持续、可靠、可审计地承担后果。

Agent OS 也许不会以一个统一产品的方式出现。

但 Agent Execution Plane 已经在形成。

它最终要解决的，也不是“怎样让更多 Agent 同时跑”。

而是：怎样把智能，组织成可靠能力。

>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。

*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；

*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；

关注我，一起AIGC从0到1~