拥有协调层，
封装执行层

这是一个系列的第二篇。第一篇《AgentOS：一份概念定义》用 AgentOS 这个框架，定义了一个概念性方向——行业该如何理解「人 + 多个 Agent 长期共存」这件事。它是一面镜头。

本篇不再讨论行业，而是一份立论：说清这样一个产品该往哪走、边界在哪、凭什么。它面向同路的构建者——你大概率已经理解 Agent 的大势，但不了解这个具体产品的内情。本文不假设你知道任何实现细节，只想把一套立场摊开给你看。

镜头是认识工具，立论是承诺工具。第一篇帮你看清，第二篇说明选择。

关于那个空着的名字

你会注意到，本文从头到尾不给这个产品起名字。它曾被叫作「工作台」，但那只是上一阶段的临时产物——「工作台」「AgentOS」或任何其他词，都不够准确。

这不是还没想好，而是刻意的。后文会讲到「三个定位槽位」：镜头、内核、身份。本文只锁定内核（架构）和赌注这两个稳定的东西，身份（名字）这一槽刻意留空——名字是承诺，应该等方向被现实验证之后，才最后被定义。过早命名，只会把一个尚在生长的方向，钉死在一个不够准的词上。

行文约定：下文以「这个产品 / 这套系统」中性指代它；当需要点明它本质上是什么时，会说它是「一套协调层」——这是描述，不是名字。

这是一套为「超级个体」打造的协调层：它拥有人与 Agent 协作的契约、事实与治理，封装一切执行引擎；并以「资源治理 + 多厂商 + 极致个人化」为不可替代的赌注。

这句话里每个词都承重：

协调层

产品的本体不是某个界面、也不是某个 Agent，而是「协调」本身——见第二部分。

拥有 / 封装

协调归自己建、自己改；执行藏在接缝后、随时可换。这是唯一的不变量。

契约 · 事实 · 治理

协议（怎么对话）、Trace（发生过什么）、Harness（允不允许）——协调层的三件实物。

赌注

资源治理、多厂商、极致个人化——巨头结构性留下的空白，护城河所在。

这句主张在后文的三个阶段里一字不变。变的只是「协调」要覆盖多宽：

1 个 Agent　→　N 个 Agent　→　N 人 × N Agent

这套系统不是通用平台。它服务于超级个体——一个人，带着一批 Agent，长期协作，完成本来需要一个小团队才能完成的工作。

把服务对象收窄到「一个人」，会反过来决定所有边界：

• 不做最大公约数，做极致贴合单个人工作流的个人化——这恰恰是大厂结构性做不到的。
• 早期不引入多用户、权限分级、协作分享——那是最后一个阶段才触碰的边界。
• 人是稀缺资源。「人类注意力」是这个产品形态最硬的约束：一个人面对越来越多的 Agent，所有协调设计最终都要为「不淹没这唯一的人」服务。

超级个体不是「小号的企业」。现阶段，为一个人设计、和为一个组织求共识求规模，是两套不同的取舍——这个产品先站在「贴合与掌控」这一侧。

这类产品很难找到一个准确的名字。原因不在词不够多，而在于——人们想让一个名词同时干三件本质不同的事。这三件事必须拆开，各自归位：

把三件事塞进一个词，必然顾此失彼：用「协议」当身份，界面就显得不重要；用「AgentOS」当身份，边界就过大、工程承诺过重；用「工作台」当身份，又丢掉了 Agent 这一侧的主动性。边界从来不该由一个名词来画，而该由一条归属规则来画（第 VII 章）。

为什么不直接自称 AgentOS

操作系统这个隐喻，理解上是对的，但作为身份过重。而且回到 OS 的本意——操作系统从不实现应用，它只调度、隔离、记录、提供系统调用。所以「用 OS 的框架思考，但只做协调内核、不自己造执行」，恰恰才是 OS 的正解。这也正是「理解上对、工程上别太重」的解法。

在第一篇的形态光谱上，这个产品站在第 07 档（Agent Workbench）：用 AgentOS 框架设计，朝完备方向走，但不在早期就背起第 08 档那种完备内核的承诺。

这一章是整篇的脊柱。后面所有概念——UCI、ACI、协议、Harness、Loop、Runtime、Trace——都不是孤立的名词，而是这张图上的一个位置和一组关系。

这张图的连接逻辑，一句一句读：

• 两张对称的嘴：人和 Agent 都「说话进系统」。人这一侧叫 UCI，Agent 那一侧叫 ACI。它们是镜像的——一个把人的意图翻译进系统，一个把 Agent 的行动与求助翻译进系统。
• 同一种语言：两张嘴说的不是两套话，而是同一套结构化事实——协议内核。这是整张图的重心。一个权限请求、一次决策、一个状态变化，无论由人发起还是 Agent 发起，都归约到同一组 command / event / state / decision / permission / trace。
• 一道横切的线：协议内核以下，是把这套事实真正执行出来的工程栈。「拥有 / 封装」那条线横切于此——线以上（含治理接缝）自己拥有，线以下（推理与运行）一律封装。

传统理解是「GUI 面向人，CLI 面向 Agent」。更准确的对称关系是：UCI ⇄ ACI，围绕同一个协议内核——人和 Agent 不是各用各的入口，而是共同操作同一套协议。

为什么这个对称如此关键？因为它决定了产品的本体不在两端，而在中间。换两端的形态（GUI 改版、换一种 Agent 工具）都不动摇产品；动摇产品的，是改了中间那套共享事实。这正是下一章和第 VII 章要展开的。

这里的「协议」不是狭义的网络协议，而是系统内部共同遵守的语言与行为规则：哪些事可以被表达、每件事的结构是什么、谁能发起、谁要响应、状态如何流转、结果如何记录。可以理解为——系统内部的语法 + 状态机 + 记录格式。

协议优先于页面

同一件事，有两种设计顺序。以「Agent 想改 package.json，需要人批准」为例：

当一件事先成为结构化事实，它就能被多个入口共享，而不是每个页面各实现一套。这是「同说一种协议」在工程上的落地方式。

Trace 是事实，不是展示

执行时间线（Trace）常被误解为「好看的过程动画」。在这套架构里，它是协议内核的事实记录：任务开始、计划摘要、工具调用、文件改动、错误重试、权限请求、人的决策与干预、完成或失败——全部落进同一份事实。

因为是事实而非展示，它才能同时支撑：GUI 回放、Agent 续跑、远程恢复、审计、调试、以及历史分叉时重建上下文。各种零散记录不应是几套孤立日志，而应收敛到同一个事实层。

内核会长大，但语义稳定

单 Agent 阶段，内核处理的是 command / event / state / decision / permission / trace。进入多 Agent 后，会在它之上叠一层 Coordination Protocol（assignment / handoff / review / conflict / escalation）。但叠加不是推翻——底层那套交互语义始终稳定。协议是从真实功能里长出来的，不是一次设计完整的（这条会在第 VIII 章作为红线再出现）。

协议内核定义了「该发生什么」，但事情真正做成，靠的是它下面的三层工程责任。这三层常被混成一团，分开看才清楚：

三者的关系是自上而下的：Harness 给 Loop 立规矩，Loop 驱动 Runtime 干活，Runtime 触达真实世界。它们共同构成「执行」——而执行，正是下一章那条线要划开的对象。

一个关键区分：Loop / Harness 的具体策略（怎么推理、怎么重试）属于某个 Agent 的实现；但它们与系统交互的方式（何时进协议、如何写 Trace、怎么被治理）属于产品本身。不抽到产品级，每个 Agent 都会各自发明一套审批与日志，最终治理、回放、审计全部失控。

前三章立起了架构：两张对称的嘴、一个共享内核、一组执行工程栈。这一章只做一件事——在这套架构上划一条线，并主张这条线永不改变。

两层，两个动词

一块试金石

遇到任何一个组件，问两个问题，就能判断它该被拥有还是被封装：

• 「明天它被更好的替代品换掉，这还是不是同一个产品？」　是 → 执行层，封装它；否 → 协调层，拥有它。
• 「这东西的价值，是我创造的，还是供应商创造的？」　供应商创造 → 封装；我创造 → 拥有。

换掉底层的某个 Agent 引擎，这还是同一个产品——所以引擎是执行层。改掉 Trace 的结构、决策的语义、协议的模型，它就变成了另一个产品——所以这些是协调层。

线不是齐整的：Loop 与 Hook 的精确切法

这条线并不在「协议」和「执行栈」之间齐整地横切，而是穿过执行栈本身：

一句话记住这条线：治理执行是 IN，实现推理内核是 OUT。

执行层是巨头（Anthropic、OpenAI）竞争且必胜的地方——模型质量、loop 质量。在那里和他们正面竞争没有胜算，正确的姿势是封装它、骑在它上面、随时可换。

真正结构性的空白，留在协调层之上的这三条赌注里：

一个判断：底层平台越成功，上层协调的空间越大。原厂越强，越多人需要一层「自己拥有、可观测、跨厂商、贴合自己」的协调层来驾驭它。

一致性红线（跨三阶段恒定的 NO）

无论加多少功能、走到哪个阶段，下面几条始终是越界：

• 不把「造执行引擎」当成这个产品的核心。哪怕自己做了一个 Agent 或执行内核，它也只是产品矩阵里相邻的另一件产品——和任何第三方引擎一样，从同一道接缝接入，不享有渗进协调内核的特权。
• 不绑定单一厂商，不让某个厂商的实现细节渗进协议。
• 界面不持有业务真相。GUI 只是协议事实的一层渲染，可随体验偏好千变万化；真正的状态与事实存活在协议、状态机、Trace 里，而不是某个页面的内部状态里。
• 不为了通用化而牺牲个人化，不做最大公约数。
• 协议不「一次设计完整」——它必须从真实功能里长出来。

演进路径是固定的：单人单 Agent → 单人多 Agent → 多人多 Agent。本质上，是第 IV 章那张图沿两条轴逐次加宽——先加宽「Agent 的数量」，再加宽「人的数量」。每跨一个阶段，只解锁一条轴；那条线和三条赌注，始终不变。

每个阶段的边界是确定的：一个阶段内做 3 个版本还是 10 个版本都行，但只要某个功能跨出本阶段的「暂不做」清单，就是越界，必须推迟，或显式地决策升级到下一阶段。

三阶段一图速览