Agent 基础设施领域正在发生一件没人谈论的事。
不同的团队，做着不同的产品，秉持不同的设计哲学，却反复构建出同一种架构——不是大致相似，而是结构同构，连组件边界都一致。
Anthropic 最近发布的 Managed Agents 是最新案例。他们的工程博客描述了一个分解为三个组件的系统：Session（超越单次推理生命周期的持久上下文）、Harness（定义 Agent 能做什么的能力配置）、Sandbox（代码实际运行的隔离执行环境）。他们称自己的方法为 "meta-harness"——一个具有"通用接口、允许许多不同 harness"的系统。
这几乎与 Rotifer Protocol 作为开放标准构建的架构完全一致——将 Agent 基础设施分解为 Memory（持久上下文）、Gene（版本化能力配置）、Binding（执行环境接口）。
两个团队。零交流。同一架构。
这不是巧合。这是信号。
三组件模式
让我们精确描述收敛的内容。
每一个成熟的 Agent 基础设施最终都会分离出三个关切：
| 关切 | 管理什么 | Anthropic 术语 | 开放协议术语 |
|---|---|---|---|
| 持久上下文 | 跨模型调用、崩溃、Session 边界存活的状态 | Session | Agent Memory |
| 能力配置 | Agent 能做什么——工具、提示词、技能、行为规则 | Harness | Gene |
| 执行环境 | 代码实际运行的地方——隔离的、安全的、对资源的访问受控 | Sandbox | Binding |
这些不是随意分组。它们是问题空间中的天然断裂面。
持久上下文必须与模型的上下文窗口分离，因为上下文窗口是有限的、短暂的、且模型特定的。一个运行数小时甚至数天的 Agent 需要能查询、检查点、恢复的状态——即使底层模型实例已经死亡。
Anthropic 的工程团队说得很清楚：Session 不是上下文窗口。它是 Agent 所做一切的可查询、持久化日志。当一个新的模型实例被唤醒时，它查询 Session 来重建工作上下文。Rotifer Protocol 的 Agent Memory 模型解决的是同一个需求——Agent 可以在上面休眠和唤醒的持久化结构化状态。
能力配置必须与模型本身分离，因为模型的变化速度比能力定义的变化速度快。当你从一个模型版本升级到另一个时，你不希望能力定义被破坏。Harness——那些使 Agent 对特定领域有用的具体规则、工具和行为模式——应该是一个可移植的、版本化的制品。
这是 Anthropic 的 "meta-harness" 洞察变得有趣的地方。他们明确地将系统设计为"对 Claude 未来需要的具体 harness 不持立场"。Harness 是插件，不是内置。Rotifer Protocol 对同一概念的称呼是 Gene——一个模块化的、版本化的、可独立评估的能力单元，可以被组合、转移和替换，而不需要触及模型或执行环境。
执行环境必须与其他一切分离，原因是安全。Agent 在模型 + harness 层推理、规划、决定做什么，但实际执行发生在沙箱中，凭证、文件系统访问和网络权限都受到严格控制。
Anthropic 的架构明确强制执行这一边界：凭证永远不进入 Sandbox。它们留在 vault 中，通过 MCP 代理访问。Rotifer Protocol 的 Binding 接口服务于相同目的——抽象执行环境的同时，在推理层和执行层之间强制执行安全边界。
为什么反复发生
这种三向分解不是谁在抄谁。它持续独立出现，因为问题空间有三个真正不同的关切，且有不同的生命周期需求。
上下文生命周期 ≠ 能力生命周期。 Agent 对自己做过什么的记忆（上下文）在执行过程中持续变化。但它对自己能做什么的定义（能力配置）只在有人刻意更新时才会变化。这两件事需要不同的存储、不同的版本管理和不同的访问模式。
能力生命周期 ≠ 环境生命周期。 一个能力定义（"调用这个 API、解析响应、失败时重试"）应该跨多个执行环境工作——云容器、边缘运行时、WebAssembly 沙箱、甚至硬件安全飞地。如果能力与特定环境耦合，每次环境变更都会强制能力重写。
环境生命周期 ≠ 上下文生命周期。 执行环境天生是临时的——你启动一个容器，运行一些代码，然后销毁它。上下文必须跨这些临时执行持久化。
三个关切。三种不同的生命周期。三个组件。
这类似于操作系统领域发生过的事。每个 OS 最终都有了进程（隔离执行）、文件（持久化状态）和套接字（通信接口）——不是因为有谁规定了它，而是因为问题本身有这些天然接缝。Agent 基础设施有同样的接缝。架构自己写出了自己。
有趣的数据点
除了结构性收敛，Anthropic 的工程博客还包含几个值得研究的定量洞察。
Token 预算解释 80% 的性能方差
在他们的多 Agent 研究系统中，Anthropic 发现"token 用量本身解释了 80% 的方差，工具调用次数和模型选择是另外两个解释因素。"
这是一个惊人的发现。它意味着对于大量 Agent 任务，最重要的杠杆不是你用哪个模型，也不是你提供哪些工具，而是你为任务分配了多少 token。这对任何能力评估系统都有深远影响——能力评估的成本维度不仅是商业关切，它是主导性的性能变量。
对于任何构建 Agent 能力评估的人（例如 Rotifer Protocol 的适应度函数 F(g)），这意味着资源成本指标值得比通常更多的权重。
子代理即压缩，而非仅仅是并行
围绕多 Agent 系统的标准叙事是并行——将任务拆分为子任务，并发运行，合并结果。Anthropic 的团队提供了更精妙的框定：
"搜索的本质是压缩：从庞大的语料库中蒸馏洞察。子代理通过在各自的上下文窗口中并行操作、同时探索问题的不同方面、然后为主研究代理浓缩最重要的 token 来促进压缩。" — Anthropic, "How we built our multi-agent research system"
每个子代理不仅是执行子任务的工人。它是一个压缩引擎——将一个大的、高维的搜索空间蒸馏为一个紧凑的摘要，供编排 Agent 消费。价值不仅是速度，而是信息密度管理。
这将多 Agent 组合从吞吐量优化重新框定为信息论操作。当你组合多个能力时，你不仅仅是在并行化工作——你在管理跨上下文窗口的压缩比。
工具测试代理将效率提升 40%
最具实践性的洞察之一：Anthropic 创建了一个专门的代理，其唯一工作是测试工具、发现边缘情况，并重写工具描述以帮助未来的代理避免失败。这个过程将任务完成时间减少了 40%。
这是元评估——使用代理来评估代理能力的质量，然后基于实证测试改进能力描述。在一个能力由许多作者贡献的开放生态系统中，这种自动化质量改进可能具有变革性。想象一个 Judge Gene，其唯一目的是测试其他 Gene 并优化它们的 phenotype 描述，使代理更容易正确使用。
分歧之处
这就是收敛结束、分歧开始的地方。
Anthropic 的 Managed Agents 和 Rotifer Protocol 在架构分解上达成了一致。它们同意能力应该是模块化的、版本化的、可与模型和执行环境分离的。它们同意安全边界、持久上下文和 meta-harness 哲学。
但它们在一个根本问题上产生了分歧：能力如何变得更好？
平台模式：策展
在 Anthropic 的 Managed Agents 中，harness 目录是策展式的。Anthropic 工程师构建 harness、测试它们、部署它们。当一个 harness 变得过时（因为模型变得更聪明，不再需要脚手架），平台团队将其退役。质量控制是中心化的——每个 harness 在对用户可用之前都经过 Anthropic 的内部验证。
这是一个被证明有效的模式。Apple 的 App Store 这样运作。AWS 的托管服务这样运作。中心化策展提供质量保证和一致的用户体验。
协议模式：选择
在开放进化协议中，能力（Gene）由任何人提交——人类开发者、AI Agent、自动化管道。它们在竞争性 Arena 中由标准化适应度函数评估，并根据测量的性能跨 Agent 传播。高适应度 Gene 通过水平逻辑转移（HLT）传播。低适应度 Gene 被更好的替代方案取代。
没有人策展目录。目录通过选择压力自我策展。
权衡
| 维度 | 平台（策展） | 协议（选择） |
|---|---|---|
| 质量下限 | 高——一切都经过审核 | 可变——取决于评估严格程度 |
| 创新上限 | 受限于平台团队的带宽 | 无上限——任何人都可以提交 |
| 改进速度 | 平台发布节奏 | 持续——适应度景观始终活跃 |
| 可移植性 | 绑定到平台 | 可移植——任何 Binding 都可以执行 |
| 失败模式 | 平台团队跟不上时的停滞 | 评估不够严格时的噪音 |
两种模式都不是普遍更好的。它们优化的是不同的东西。
但有一个观察让这种分歧变得有趣：模型能力正在商品化。多个实验室现在提供具有强大函数调用、结构化输出和多轮推理能力的模型。随着模型层变得可替换，价值转向能力层——那些使 Agent 对特定领域有用的 harness、工具和行为配置。
如果模型层商品化但能力层保持中心化，你会得到一个模型提供商在价格上竞争、而一两个平台控制能力目录的世界。如果能力层是开放和竞争性的，你会得到一个能力独立于任何单一平台进化的生态系统。
Meta-harness 模式使两种未来都成为可能。这正是它成为正确架构的原因——它不预设治理问题的答案。
收敛告诉了我们什么
当独立团队反复抵达同一架构时，值得追问：是什么结构性属性使这不可避免？
答案是 Agent 基础设施是一个操作系统问题，而操作系统有已知的分解模式。Agent 的推理引擎是 CPU。能力配置是指令集。执行环境是进程沙箱。持久上下文是文件系统。
一旦你将它视为 OS 问题，三组件分解就变得显而易见——收敛的必然性也是如此。每个构建 Agent 基础设施的团队最终都会发现这些接缝，因为接缝在问题中，不在任何特定解决方案中。
不可避免的不是治理模式。"指令集"会是专有的（像 x86）还是开放的（像 RISC-V）？能力分发会是中心化的（像应用商店）还是去中心化的（像带竞争评估的包注册表）？
这些不是技术问题。它们是生态设计问题。它们将决定 Agent 能力是以一家公司路线图的速度进化，还是以一个开放生态系统集体智慧的速度进化。
Meta-harness 模式给了我们架构。我们在上面构建什么——仍待决定。
Rotifer Protocol 是面向 AI Agent 的开源进化框架。协议规范、CLI 和 SDK 可在 rotifer.dev 获取。Gene、Arena、Binding 和 HLT 定义在协议规范中。