红标笔趣阁
31.0MB · 2026-03-24
2026年，我们正站在 AI 发展的一个重要拐点上。当一些系统开始以“Agent Operating System”而非“聊天机器人框架”自我定义（例如最近发布的 OpenFang）时，它们共同指向一个更深层的范式转移：AI 正从“被动响应”进化为“主动工作”。这不是简单的功能增强，而是从“工具”到“伙伴”的根本性质变——从“问一句，答一句”的对话机，走向“给目标、交结果”的工作伙伴。
要理解这个转变，我们需要追溯 AI Agent 的完整演进路径——从最简单的请求-响应，到今天的多代理操作系统，再到未来的人机深度分工——Agent 自主执行，人类专注于目标设定、关键决策与结果验收的自主运营时代。
最初的 LLM 应用是纯粹的二元系统：用户提问，AI 回答。没有记忆，没有上下文，每次交互都是独立的孤岛。那时的智能，是一闪而逝的火花，而不是可以持续燃烧的火堆。
用户 → AI
AI → 用户
这个阶段的核心特征：
这时的 AI 是一个“智能黑盒”——它拥有知识，但无法累积经验。
Chat 模式的引入打破了孤立性。通过 session 机制，AI 获得了“短期记忆”：对话第一次从“句子”变成了“故事”。
用户 → AI → 用户 → AI → 用户 → AI ...
↑___________↑
上下文传递
但这个阶段仍有一个根本限制：参与方只有两个——用户和 AI。所有信息必须在它们之间直接流动。AI 可以“记住”对话历史，但无法“访问”对话之外的世界。
在讨论工具调用之前，我们需要先理解两个奠基性的学术突破：
Chain-of-Thought (CoT) — 2022年1月，Google Research 的 Jason Wei 等人发表了论文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models。这篇论文的突破在于：让 AI “展示工作过程”而非直接给出答案。
传统：问题 → 答案
CoT： 问题 → 思考步骤 → 答案
这看似简单的改变，却让 LLM 在复杂推理任务上的表现大幅提升。它揭示了一个深刻的事实：语言模型需要“思考空间”来展开推理。
ReAct — 2022年10月，Yao 等人发表的 ReAct: Synergizing Reasoning and Acting in Language Models 被普遍认为是定义了现代 AI Agent 时代的开创性论文。它的核心洞见是：推理 (Reasoning) 与行动 (Acting) 应该交织进行。
ReAct 循环：
Thought → Action → Observation → Thought → Action → ...
这个模式被广泛认为是现代 Agent 架构的奠基性工作之一，对后续的 Agent 系统设计产生了深远影响。
Tool Use / Function Calling 的引入是 Agent 发展的第一个重大飞跃。它引入了一个新的参与方：机器系统。
用户
↓ ↑
AI ←──────→ 机器系统
(工具/API/数据库)
这不再是二人对话，而是三方协作。AI 不再仅依靠内部知识回答问题，它可以：从“会说话”变成“能办事”。
值得注意的是，OpenAI 的 Function Calling (2023年6月) 并非凭空出现。早在 2023年2月，Meta AI 的研究人员就发表了 Toolformer 论文 (Toolformer: Language Models Can Teach Themselves to Use Tools)，展示了如何让语言模型自主学习使用工具。
Toolformer 的创新在于：
这预示着未来 Agent 的工具能力可能不再依赖人工设计，而是通过自学习获得。
函数调用只是开始。真正的趋势是向**领域特定语言（DSL）**演进：自然语言用来“说清楚想要什么”，DSL 用来“精确地告诉机器要做什么”。
| 层次 | 表示形式 | 特点 |
|---|---|---|
| L1 | 自然语言 | 歧义性，适合人-人、人-AI |
| L2 | JSON Schema | 结构化，适合 AI-机器 |
| L3 | DSL | 领域抽象，表达能力更强 |
Model Context Protocol (MCP) 和 Agent-to-Agent Protocol (A2A) 是这一趋势的体现。一些前瞻性的系统已经开始将其整合，试图将“工具接入”和“代理互操作”标准化，从而构建一个分层的能力表达体系。
当前主流的 Function Calling 基本都使用 JSON Schema 来描述参数结构。这是一个非常务实的折中：
但从 Agent OS 的视角看，JSON Schema 更像是一个L2 级别的“线缆协议”：
换句话说，JSON Schema 非常适合做：
但它并不直接提供：
这也是为什么，很多系统在使用 JSON Schema 做 Function Calling 的同时，还要另外维持一套“领域模型”或“配置 DSL”——两边不可避免地出现割裂和重复。
要真正让 Agent 在复杂系统里“看懂世界”和“改写世界”，我们有必要在 L3 引入一种统一的元模型（Meta-Model），用来定义各类 DSL 的结构与语义——而不仅仅是函数参数。
一种代表性的做法是Nop平台中XDef/XDSL 的设计：
与最终文档同构：
集合语义内建：
xdef:body-type="list|set|union|map" 明确子节点集合的语义，xdef:key-attr 定义稳定 key，直接服务于差量合并和快速查找。结构复用与引用：
xdef:name 为任意节点命名模型，xdef:ref 在同一文件或跨文件复用结构片段，领域类型与 def-type 语法：
!string、class-name、bean-name 等域特定类型表达业务语义，在这样的设计下，一个 Agent OS 可以：
而面向外部的 JSON Schema Function Calling，只需要看作是这套 L3 元模型的一种投影：
统一元模型的另一个直接结果是：DSL 可以自然地被嵌入到对话之中。
一个典型的 Agent 交互，不再只是自然语言 + 零散的 JSON，而是：
人类：
用中文给我说明这个 Plan 有哪些风险，并在必要时调整步骤。
Agent：
（自然语言解释）
（同时给出一段更新后的 `<plan>` XML/DSL 片段）
在这个过程中：
为了在保持可检查性的前提下提供足够的表达力，一个常见的设计是：
例如一个基于 XDef 的规则 DSL 片段可以是：
<rule name="validate-order-amount">
<condition>
<script lang="js" sandbox="true">
<![CDATA[
// 访问上下文对象，返回 true/false
const total = ctx.order.items.reduce((s, it) => s + it.price * it.qty, 0);
return total <= ctx.limits.maxOrderAmount;
]]>
</script>
</condition>
<message>订单金额超出限额</message>
<level>ERROR</level>
</rule>
这里的设计要点是：
树是可静态分析的：
rule/condition/message/level 等节点全部由 XDef 定义，脚本是“限域图灵完备”的叶子节点：
失败检测仍然可以分层进行（对应 5.5 节）：
这种“声明式骨架 + 少量可控脚本”的模式，既满足了业务复杂度带来的表达需求，又保留了 Agent 系统在 Plan、Delta、安全审计等方面的可分析性与可演化性。
在一个成熟的 Agent OS 中，我们可以预期：
工具调用让 AI 可以访问外部世界，但要真正成为有用的 Agent，还需要记忆系统。传统的 Chat 只有短期记忆（context window），现代 Agent 需要多层级 Memory 架构：
| 层级 | 类型 | 特点 | 示例 |
|---|---|---|---|
| L1 | 短期记忆 | Context Window，对话内有效 | “刚才那个”指代上文 |
| L2 | 长期记忆 | 跨会话持久化，用户偏好 | 记住用户喜欢中文、技术风格 |
| L3 | 外部记忆 | 向量数据库、知识图谱、RAG | 查询公司 Wiki、代码库 |
| L4 | 经验记忆 / 案例记忆 | 任务执行历史、案例库 | 记住上次方案，避免重复错误 |
其中 L1 的 Context Window 本质上是一种容量受限的工作记忆，类似于进程的工作集或 CPU 的快速缓存 —— 决定了 Agent 在一次推理中能“带在脑中”的信息上限。
传统模式:
用户 → AI (仅依赖 context window)
现代模式:
用户 → AI ←→ 向量数据库 (语义搜索)
←→ 知识图谱 (结构化知识)
←→ 工具调用 (实时数据)
Memory System 的完善是 Agent 从“一次性助手”进化为“长期伙伴”的关键：
OpenFang 的 Hands 就是典型的例子——它们可以积累知识、构建图谱、追踪准确性。这是“代理为你工作”的基础能力。
工具调用解决了 AI 与机器的交互，但引入了新问题：AI 如何在关键时刻获得人的确认？
传统的做法是让 AI “猜测”用户意图，但这在敏感操作（支付、删除、发送）中风险极高。解决方案是将人作为 Agent Loop 的一部分：
用户消息 → AI 推理 → [需要确认?]
↓ 是
生成 UI 描述 → 用户填写 → AI 继续执行
↓ 否
直接执行工具
这是一个关键创新：AI 不再仅返回文本，它可以返回界面描述。
想象一个场景：用户要求“帮我预订明天去上海的机票”。传统的 AI 可能直接调用 API，但智能的 Agent 会：
这不是预先设计的 UI，而是根据上下文动态生成的交互界面。
OpenFang 的 Approval Gates 正是这一模式的体现：
值得一提的是，Google 在 2025 年 12 月开源了 A2UI (Agent-to-User Interface) 协议，旨在标准化 Agent 动态生成原生 UI 的方式。该协议允许 Agent 发送结构化 JSON 蓝图，由客户端渲染为 native 组件，进一步推动了动态 UI 在智能体系统中的规范化应用。
人机融合的另一个维度是多信道通信。以 OpenFang 这类系统为例，往往会提供一组 Channel Adapters（覆盖 T@elegrimm、Discord、Email、WhatsApp 等常见渠道）。**Agent 不再住在某一个聊天窗口里，而是像基础设施一样渗透进所有日常工具中。**这意味着：
当我们将视野放大，会发现单个 Agent 的能力有限。复杂任务需要专业化分工：
┌─────────────┐
│ Orchestrator│ (协调者)
└──────┬──────┘
┌───────┼───────┐
↓ ↓ ↓
Researcher Coder Writer
(研究员) (程序员) (作者)
这就是多代理系统的核心思想。**单个 Agent 像一个高手，多个 Agent 才像一支团队。**2023-2025 年涌现了大量框架：
| 框架 | 核心理念 | 特点 |
|---|---|---|
| AutoGen (Microsoft) | 对话式协作 | Agent 之间通过对话协调 |
| CrewAI | 角色分工 | 每个 Agent 有明确的角色和任务 |
| LangGraph | 图状态机 | 用有向图定义 Agent 工作流 |
但它们主要采用事件驱动架构，以被动响应为主，缺乏原生的自主调度能力。
在工业界探索的同时，学术界也在定义 Agent OS 的理论框架。2024年3月，论文 AIOS: LLM Agent Operating System 系统性地提出了将 LLM 作为操作系统的“内核”的设想：
┌─────────────────────────────────────┐
│ Application Layer │
│ (Agents, Workflows, Tasks) │
├─────────────────────────────────────┤
│ AIOS Kernel Services │
│ ┌─────────────────────────────┐ │
│ │ LLM as OS Kernel │ │
│ │ • Scheduling & Context Mgmt │ │
│ │ • Memory Management │ │
│ │ • Tool Registry │ │
│ │ • Inter-Agent Communication │ │
│ └─────────────────────────────┘ │
├─────────────────────────────────────┤
│ Hardware/Infrastructure │
└─────────────────────────────────────┘
AIOS 论文的贡献在于：它从操作系统原理出发，系统性地定义了 Agent OS 应该具备的核心服务——调度、内存管理、工具注册、代理间通信。这与传统操作系统的设计高度吻合。当 Agent 多到需要“内核服务”来管理时，我们就真的在和一个新物种级别的计算平台打交道了。
这里我想提出一种理解 Agent OS 的新视角：（注：这是本文作者提出的理解框架，而非任何现有系统的官方定义）
graph TD
subgraph "传统操作系统"
A1["进程<br/>(资源分配、执行单元)"]
A2["内存空间<br/>(私有地址空间)"]
A3["动态链接库 DLL<br/>(共享代码)"]
A4["系统调用<br/>(内核接口)"]
A5["文件描述符<br/>(资源句柄)"]
end
subgraph "Agent OS"
B1["代理<br/>(上下文、执行状态)"]
B2["记忆存储<br/>(向量库、知识图谱)"]
B3["技能<br/>(能力模块)"]
B4["工具<br/>(调用接口)"]
B5["工具会话/连接<br/>(活跃资源句柄)"]
end
A1 --> B1
A2 --> B2
A3 --> B3
A4 --> B4
A5 --> B5
操作系统中进程（Process）的定义是正在执行的程序，它包含四个核心维度：
操作系统：进程是资源分配的基本单位。每个进程拥有：
Agent OS 对应：Agent 是资源分配的基本单位
操作系统：进程是调度的基本单位。每个进程拥有：
Agent OS 对应：Agent 是执行的基本单位
操作系统：进程拥有私有地址空间
Agent OS 对应：Agent 拥有私有上下文空间
操作系统：通过虚拟内存和特权级实现隔离
Agent OS 对应：通过能力系统和沙箱实现隔离
这个类比的核心洞见是：Skill 作为共享能力库。
传统操作系统中，多个进程可以加载同一个 DLL：
Process A ──┐
├──→ shared.dll
Process B ──┘
在 Agent OS 中，多个 Agent 可以共享同一个 Skill：
# Agent A (researcher)
[available-skills]
include = ["git-master"]
# Agent B (coder)
[available-skills]
include = ["git-master", "playwright", "frontend-ui-ux"]
git-master skill 被两个 Agent 共享。就像 DLL 被多个进程加载一样。
有趣的是，AIOS 论文也提出了类似的观点：Agent OS 应该提供类似传统 OS 的内核服务。这或许说明，当一个系统足够复杂时，它会不可避免地重新发明操作系统的核心概念。
当我们将 Agent OS 与传统操作系统类比时，会发现许多成熟概念尚未体现。这些缺失指明了演进方向。
信号机制：OS用信号实现异步中断，进程可捕获并优雅处理。Agent OS 缺乏类似机制——执行长任务的 Agent 无法被优雅中断，只能强制停止，导致状态丢失。
演进方向：Agent 可注册中断处理函数，收到中断时保存任务状态以便恢复。
僵尸回收：OS中子进程退出后进入“僵尸状态”，保留退出码等待父进程读取，之后才释放资源。Agent OS 中，子 Agent 完成任务后资源可能未被及时回收。
演进方向：引入类似 wait() 机制，主 Agent 获取结果后系统自动回收子 Agent 资源。
死锁检测：OS中多个进程循环等待资源时，系统可检测死锁。Agent OS 中可能形成循环依赖（A 等 B 的结果，B 等 A 的确认）。
演进方向：维护依赖图，检测循环等待并触发恢复策略。
检查点：数据库使用检查点实现故障恢复。Agent 长任务遇故障时目前往往从头开始，造成浪费。
演进方向：关键步骤前自动保存检查点，失败时从检查点恢复。（Plan机制实现了某种轻量级的检查点，详见4.5节“Plan的检查点与恢复机制”。）
资源配额：OS通过 cgroups 限制进程的 CPU、内存等资源使用。Agent OS 中多租户如何公平分配 LLM 调用、计算、存储、网络等各类资源？ 演进方向：为每个 Agent 分配 token 预算、API 频率上限、内存限制、磁盘配额、执行时长等，结合优先级调度，实现全面的资源公平调度与隔离。
内存换页（Context 管理）：OS将不活跃内存页换出到磁盘。Agent 对话历史超过 Context Window 时，如何“换出”早期内容？
演进方向：将早期对话摘要存储到向量数据库，需要时检索召回（语义化换页）。
写时复制（CoW）：OS 中 fork() 创建子进程时共享内存，仅写入时才复制。克隆 Agent 时可共享知识库，修改时才复制。
演进方向：克隆时共享底层向量存储，仅在修改时创建私有副本。
这些概念的缺失，说明当前 Agent OS 仍处于“早期 Unix”阶段——核心功能已具备，但系统级的成熟机制仍在演进中。
要理解 Agent 如何自主执行复杂任务，我们必须引入其核心机制：Plan（计划）。没有 Plan 的 Agent，只是在“聪明地即兴发挥”；有了 Plan 的 Agent，才有可能“系统地负责到底”。
与传统技术（如BPM、CI/CD）中由人预先定义的静态工作流不同，Agent 的 Plan 是一个动态的、自我驱动的执行蓝图。其关键差异在于 Agent 能够围绕 Plan 形成一个完整的自主闭环：
这个闭环意味着 Agent 可以：
因此，Plan 不再是一张静态的流程图，而更像一份 Agent 的**“执行合约”与“运行时状态”**的结合体，是其实现自主工作的关键。对人类来说，Plan 是一张“看懂机器在干什么”的窗口；对 Agent 来说，Plan 是一张“记住自己承诺了什么”的清单。
Plan 是一种特殊的任务表示形式——它是展开的执行轨迹，内嵌进度标记。在一个典型的 Agent 会话中，通常会包含：
Session（会话）
├── session.json # 消息历史
├── plan.xml # 任务计划和进度 ← Plan 在这里
├── out-{timestamp}.log # 工具执行日志
└── history-{snapshot}.json # 历史快照
Plan 的一种可能定义（以 XML 为例）：
<plan title="研究用户需求">
<steps>
<step name="collect_requirements" title="收集需求" status="completed">
<note>已收集5个核心需求点</note>
</step>
<step name="analyze_feasibility" title="分析可行性" status="in_progress">
<note>正在评估技术方案</note>
</step>
<step name="design_solution" title="设计方案" status="not_started"/>
<step name="implement" title="实现" status="not_started"/>
<step name="verify" title="验证" status="not_started"/>
</steps>
</plan>
| 维度 | OS 调度/作业管理 | Agent Plan |
|---|---|---|
| 目标 | 资源利用率、公平性 | 任务完成、目标达成 |
| 输入 | 队列长度、优先级、资源状态 | 自然语言目标、环境状态 |
| 适应性 | 静态策略（CFS、实时调度） | 动态重新规划 |
| 语义 | 无（纯数学优化） | 语义理解、常识推理 |
| 粒度 | CPU 时间片、内存页 | 任务步骤、子目标 |
核心区别：
① “Rush to Response” 问题 LLM 默认立即生成答案，导致幻觉或不完整回答。复杂任务必须先规划后行动。
② 推理 ≠ 规划 推理是步骤式思考，规划是前瞻性目标导向。研究表明：推理失败的根本原因是贪婪局部最优选择在长视界中被放大。
③ 保持一致性
Nop AI 通过 ConsistencyChecker Agent 检查 Plan 与 Chat 的一致性，确保执行不偏离计划。
当 Agent 执行过程中断（网络故障、超时、资源不足）时，Plan 记录了“执行到哪里”，使得恢复后可以从断点继续，而非从头开始。
与 PCB 的类比：
| PCB 组件 | PCB 内容 | Agent Plan 对应 | 说明 |
|---|---|---|---|
| PID | 进程标识 | Plan ID | 唯一标识任务 |
| State | RUNNING/READY/BLOCKED | step.status | 当前状态 |
| PC | 程序计数器 | <step status="in_progress"> | 执行到哪里 |
| Registers | 通用寄存器 | <note> | 中间结果（示意性类比：寄存器是 CPU 内部的瞬时状态，而 <note> 更像是被主动持久化的一小块中间结果，用于检查点与恢复） |
| Stack | 调用栈 | 步骤依赖关系 | 执行上下文 |
Plan 不仅是执行蓝图，更是人类意图与机器执行之间的契约。但这个契约不是一次性签订的静态合约，而是一个动态对齐过程。
在实践中，Plan 面临三个根本性约束：
意图模糊性：人类往往无法清晰表达真实目标。"做一个好用的搜索功能"——什么是"好用"？响应快？结果准？交互流畅？这些维度可能相互矛盾。
分解有损性：高层次目标转化为步骤时必然丢失信息。"优化性能"分解为"加缓存"、"建索引"、"异步处理"——但哪一个是瓶颈？优先级如何？分解本身就需要领域知识，而这个知识可能正是人类想要委托给 Agent 的。
验收标准的递归问题：如果人类能精确定义"什么是完成"，那任务本身可能已经足够明确，不需要 Agent 来规划。越是需要 Agent 规划的任务，人类越难给出精确验收标准。
Plan 的角色会随着系统能力成熟度而演进：
阶段一：人机对齐工具（当前）
人类模糊目标 → Agent 生成 Plan 草案 → 人类阅读、修改、确认 → 执行
↑ ↓
└──── 过程中持续校准 ←───────┘
此时 Plan 的核心价值是让人类看见 Agent 的理解，在执行前校准。这不是"契约签订"，而是"对齐对话"。
阶段二：框架约束下的自动化（中期）
人类不再逐条审核 Plan，而是提供约束框架：
# 人类提供的框架
goal: "重构支付模块"
constraints:
- 保持 API 向后兼容
- 测试覆盖率不低于 80%
- 不引入新的外部依赖
gates: # 关键门限点——必须人类确认
- 设计方案确定后
- 涉及数据迁移前
- 上线部署前
auto_proceed: true # 门限点之间自动执行
Agent 在框架内自主规划和执行，只在门限点暂停等待人类硬性验收。
阶段三：信任积累后的全自动化（远期）
当 Agent 在特定领域积累了足够的成功案例和信任记录后，人类可以逐步放宽门限点：
初期：每 3 个步骤设一个门限
中期：只在关键决策点设门限（设计变更、资源申请、外部交互）
成熟期：只在最终验收设门限，中间过程完全自主
这种渐进式授权类似员工晋升——新人每步都要汇报，资深员工只在关键节点请示，专家可以独立完成整个项目。
门限点是 Plan 契约化的关键机制。一个门限点包含：
| 组件 | 说明 | 示例 |
|---|---|---|
| 触发条件 | 何时触发门限 | 执行到步骤 N / 检测到特定操作类型 / 资源消耗超阈值 |
| 硬标准 | 必须满足的客观条件 | "测试通过率 100%"、"预算不超过 $500" |
| 软提示 | 给人类参考的判断维度 | "请关注：是否有更简单的方案？" |
| 超时策略 | 人类未响应时的行为 | 等待 / 降级执行 / 回滚 / 上报 |
门限点示例：
┌─────────────────────────────────────────┐
│ ️ 门限点：数据库迁移方案确认 │
├─────────────────────────────────────────┤
│ 硬标准： │
│ 回滚脚本已生成 │
│ 预估停机时间 < 10 分钟 │
│ 已在 staging 环境验证 │
├─────────────────────────────────────────┤
│ 软提示： │
│ • 是否有不停机迁移的方案？ │
│ • 迁移窗口是否避开业务高峰？ │
├─────────────────────────────────────────┤
│ [批准] [拒绝并重新规划] [查看详细方案] │
└─────────────────────────────────────────┘
Plan 作为契约，其含义是：
Plan 不是"一次性签名的合同"，而是"持续校准的协作框架"。它的核心价值不在于"精确描述未来"，而在于"让双方对'正在做什么'保持同步理解"。
一个具体的 Agent OS 实现，其架构可能包含以下组件（此为概念示意，用于帮助理解这类系统如何组织功能）：
┌──────────────────────────────────────────────┐
│ Agent OS Kernel │
├──────────────────────────────────────────────┤
│ Registry | Scheduler | Capabilities | Events│
├──────────┬──────────┬──────────┬─────────────┤
│ Agent 1 │ Agent 2 │ Agent 3 │ ... │
├──────────┴──────────┴──────────┴─────────────┤
│ Skills (shareable) │
├──────────────────────────────────────────────┤
│ Channels (adapters) │
└──────────────────────────────────────────────┘
这类系统在产品表达上，可能会强调“可长期运行、可按计划调度”的代理实例，从而把 Agent 从事件驱动的被动响应，推向时间驱动的持续工作。
这类系统最独特的创新之一是自主代理——能够独立运行的代理包。
传统的 Agent 框架是事件驱动的：用户触发 → Agent 执行 → 等待下一次触发。
自主代理可以是时间驱动的：
# 示例：设置一个代理每天早上 6 点自动运行
agentctl hand activate lead --schedule "0 6 * * *"
# 它可能会：
# 1. 发现潜在客户
# 2. 丰富客户信息
# 3. 评分 (0-100)
# 4. 去重
# 5. 推送到 CRM
# 6. 发送通知
这是**“代理为你工作”而非“你使用代理”**。
当我们把操作系统的进程概念和声明式的差量架构放在同一张图里看，会出现一个很“工程师直觉”的问题：Agent 能不能像软件产品线一样被差量化组装，并且在运行时差量化试错？
这里的关键不是“又一种配置覆盖”，而是一种更强的变更语言：可组合、可回滚、可审计。
差量（Delta）是一种声明式增量修改描述：它描述“在基础之上添加/修改/删除什么”，而不是拿一份新配置把旧配置拍扁。配置文件在陈述“状态”，Delta 在陈述“修改”。
从代数角度看，它满足一种非常实用的结构（你不需要把它当数学炫技，它对应的是工程里的“可组合”和“可撤销”）：
最终应用 = BaseProduct ⊕ Delta1 ⊕ Delta2 ⊕ ... ⊕ DeltaN
快照只能告诉你“结果变成了什么”，Delta 才能告诉你“是怎么走到这一步的”。
先从最朴素的用法开始：用 Delta 快速定制 Agent 变体。
// 运行时根据上下文动态组装 Agent（示意伪代码）
Agent agent = AgentBuilder.create("researcher")
.withDelta("security-focused") // 增加安全检查习惯
.withDelta("chinese-language") // 增加中文输出与本地语境
.build();
这让“同一个基础 Agent”可以长出很多面向场景的变体：多租户、多团队、多目标切换都更轻。
Delta 的威力不只在“叠加”，还在“作用点足够精确”。
diff 关注的是“文本怎么变”，Delta 关注的是“结构和语义怎么变”。
这意味着 Agent 修改配置、代码、文档时，可以更接近“结构化外科手术”，而不是大段替换文本。
真正有趣的地方在运行时：Delta 让 Agent 可以在“想象空间”里试错。
核心机制很简单：Session 内置快照与分支。
主线(Main): Step1(成功) → Step2(成功) → Step3(调用Tool-X) → [失败]
↓
分支(Fix): 调参/重试 → [失败]
↓
分支(Fix): 换Tool-Y → [成功]
↓
主线(Main): Step1(成功) → Step2(成功) → Step3(成功) → Step4...
这个设计的洞见是：让系统保留“尝试能力”，但不强迫人类阅读“失败噪声”。 主线像一条干净的审计路径；分支像后台的试错草稿纸。
当不确定性来自“选哪条路”，最稳的做法不是让 LLM 靠直觉拍一个答案，而是并行跑几条路再选。
最后由聚合器（Meta-Agent）或人类做一次判断：保留哪条、融合哪些。
当你同时管理多个并行 Agent 时，细粒度对话会把人拖回耦合模式。Delta 可以自然演进成一种人类指导语言：把“单个 Agent 的对话指令”，提升为“整片 Agent 群体的行为调整”。
apply delta "focus-china" to agents [researcher-*, analyst-*]
apply delta "add-citation-requirement" to agent researcher-3
这不是为了“像配置一样好看”，而是为了把人机协作从“盯步骤”升级为“定方向 + 设验收”。
自主代理带来了前所未有的安全挑战。一个典型的 Agent OS 实现，常见做法是把安全拆成多层“防线”（这里列的是一种代表性实现的分层清单）：
| 层次 | 机制 | 防护目标 |
|---|---|---|
| 1 | WASM 双重计量沙箱 | 防止失控代码 |
| 2 | Merkle 哈希链审计 | 防篡改日志 |
| 3 | 信息流污点追踪 | 敏感数据追踪 |
| 4 | Ed25519 签名清单 | 身份验证 |
| 5 | SSRF 防护 | 防止内网攻击 |
| 6 | 秘密清零 | API 密钥自动擦除 |
| 7 | OFP 互认证 | P2P 安全 |
| 8 | 能力门控 | 权限控制 |
| 9 | 安全头 (CSP等) | Web 安全 |
| 10 | 健康端点脱敏 | 信息泄露防护 |
| 11 | 子进程沙箱 | 进程隔离 |
| 12 | Prompt 注入扫描 | 输入安全 |
| 13 | Loop Guard | 循环检测 |
| 14 | Session Repair | 状态恢复 |
| 15 | 路径遍历防护 | 文件系统安全 |
| 16 | GCRA 速率限制 | DoS 防护 |
这不仅是“安全功能列表”，而是一个完整的信任架构。
在多代理系统中，一个关键问题是权限传递：Agent A 创建 Agent B 时，B 能否获得比 A 更高的权限？
一种典型答案是：否。例如通过类似 validate_capability_inheritance() 的检查，确保子代理永远不会越过父代理的权限边界。
敏感操作必须经过人类确认：
这是将人作为最终安全边界的设计哲学。
当 Agent 进入“人机异步协作”的自主运营时代，人类长时间缺席，安全机制需要从“实时防护”转向“事后审计 + 异常上报”。这就要求在现有防御体系之上增加：
这种架构将人类从“实时坚控者”转变为“抽样审计者”，在保证安全的同时释放人类注意力。
前面我们讨论了多种失败处理机制：
这些机制的共同前提是：我们能够识别什么是失败。
然而，Agent 的失败不像传统软件那样有明确的错误码或异常。一个执行可能：
这意味着失败检测本身需要分层——不同层面的失败需要不同的检测机制。我们可以将失败区分为语法层面和语义层面两个维度。
语法层面的失败是可自动判定的。主要包括：
| 检测类型 | 机制 | 示例 |
|---|---|---|
| Schema 校验 | 结构化约束 | JSON Schema、XML Schema |
| DSL 语法检查 | 领域语言规则 | 查询语法、配置语法 |
| 类型系统检查 | 静态类型约束 | TypeScript、Java 类型 |
传统类型系统的约束是全局的、固定的，由语言设计者预设。但 Agent 系统往往需要领域特定的局部校验规则。
例如，一个字段必须满足 prop-name 格式，且必须与 props 中定义的属性名称一致。这种跨字段的语义约束，传统类型系统难以表达。
Schema 的核心优势在于：
graph LR
subgraph 类型系统
A["是字符串吗？"]
end
subgraph Schema
B["是合法的 prop-name 格式吗？"]
C["是否与 props 中定义的属性名一致？"]
end
A --> B --> C
这表明 Agent 系统需要的是领域语义感知的校验，而非通用的类型安全。
语义层面的失败是形式正确但意图偏离。这类失败无法通过静态检查发现，必须通过运行时推演来验证。
graph LR
Input["输入"] --> Step1["Step1"] --> Step2["Step2"] --> Output["输出"]
Output --> Problem["看起来对<br/>实际错"]
style Problem fill:#ffcccc
“推演”要可自动化，必须依赖三类输入：
推演一致性检查的价值在于：它把“形式正确但意图偏离”这类问题，从主观判断转为可对比的差量。
语义检查的核心是：根据已有语义自动推演，然后检查推演结果是否一致。
典型的实现方式包括：
Nop 平台提供了录制/回放的自动化测试机制，通过观察调整后产生的录制结果的差量来逐步修正处理过程：
graph TD
subgraph 录制阶段
I1["输入 I"] --> E1["执行过程"] --> O1["输出 O"]
I1 --> R1["录制 I'"]
E1 --> R2["录制 P'"]
O1 --> R3["录制 O'"]
end
subgraph 回放阶段
I2["输入 I"] --> E2["执行过程<br/>(修改后)"] --> O2["输出 O*"]
I2 --> U1["使用 I'"]
O2 --> C1["比较 Δ(O,O*)"]
end
R3 -.-> C1
这种方法的核心不是判断"对错"，而是比较差量：
理想情况：Δ(O, O*) = ∅ （无变化，修改安全）
预期变化：Δ(O, O*) = { "fieldA": "old" → "new" } （预期修改）
异常漂移：Δ(O, O*) = { "fieldA": ..., "fieldB": ..., "fieldC": ... } （意外修改过多）
推演结果的差量展现和比较，让人类可以快速定位"哪里变了"，判断变化是否符合预期。
录制/回放中的差量分析，体现了 Agent 系统的一个设计原则：
从信息论角度，信息 = 不确定性消除 = 惊讶度：
绝对状态："房间温度是 23°C" → 信息量：低（如果我知道大概是 22°C）
差量信息："房间温度从 20°C 升到 23°C" → 信息量：高（变化意味着事件）
AI 的认知带宽是有限的。让它处理"全量状态"是浪费；让它处理"差量"才是高效。
传统方式：AI 看到的是"快照"
// 时间 T1: { "system": { "cpu": 45, "memory": 60 } }
// 时间 T2: { "system": { "cpu": 78, "memory": 62 } }
// AI 需要自己比较，才知道"什么变了"
差量方式：AI 看到的是"变化流"
{
"delta": {
"system.cpu": { "old": 45, "new": 78, "change": "+33" }
},
"significance": "high"
}
不仅认知是差量的，行动也应该是差量的。
命令式（传统）：
AI: "把配置文件改成这样：{ ... 完整的新配置 ... }"
问题：需要知道完整的目标状态，容易覆盖其他修改，难以回滚，难以审计。
差量式：
AI: "在配置文件中：添加字段 X = Y，修改字段 A 从 old 到 new"
优势：只表达"意图的变化"，可以和其他差量组合，可以回滚，天然可审计。
差量和全量是可以自动转换的：
全量 → 差量：δ = S₂ - S₁（两个全量状态可以计算出差量）
差量 → 全量：S₂ = S₁ + δ（一个全量加上差量得到新全量）
这意味着存储策略可以灵活选择。但如果要保存修改意图，差量化存储就很重要——因为意图无法从两个全量状态中自动推断。
interface IntentfulDelta {
changes: DeltaChange[];
// 意图信息（无法自动推断）
intent: {
goal: string; // "优化数据库性能"
reasoning: string; // "增加连接池大小可以减少连接创建开销"
};
metadata: {
author: AgentIdentity;
timestamp: Date;
context: ExecutionContext;
};
}
综合语法和语义两个层面，可以构建一个完整的失败检测框架：
┌─────────────────────────────────────────────────────────────┐
│ L4: 意图层 (Intent Alignment) │
│ • 目标是否达成？ │
│ • 结果是否有价值？ │
│ → 判定：人类最终验收（参考意图记录） │
├─────────────────────────────────────────────────────────────┤
│ L3: 语义层 - 行为一致性 (Behavioral Consistency) │
│ • 录制/回放差量检查 │
│ • 单元测试/集成测试 │
│ • 领域不变量验证 │
│ → 判定：自动化 + 人类确认异常 │
├─────────────────────────────────────────────────────────────┤
│ L2: 语义层 - 领域约束 (Domain Constraints) │
│ • Schema 领域规则校验 │
│ • 跨字段引用一致性 │
│ • 业务规则校验 │
│ → 判定：完全自动化 │
├─────────────────────────────────────────────────────────────┤
│ L1: 语法层 (Syntax Validation) │
│ • JSON/XML 结构校验 │
│ • DSL 语法检查 │
│ • 基础类型检查 │
│ → 判定：完全自动化 │
└─────────────────────────────────────────────────────────────┘
各层级的特征：
| 层级 | 失败特征 | 检测成本 | 修复策略 |
|---|---|---|---|
| L1 语法 | 结构错误 | 极低 | 语法修正 |
| L2 领域约束 | 规则违反 | 低 | 规则对齐 |
| L3 行为一致性 | 输出偏离 | 中 | 差量分析 |
| L4 意图对齐 | 目标误解 | 高 | 目标澄清 |
差量分析的价值：L3 层的"差量分析"是连接"自动化检测"和"人类判断"的桥梁。它不是简单地判断"对错"，而是展现"变化"，让人类可以快速理解 Agent 行为的偏离程度和方向。
Model Context Protocol (MCP) 旨在成为 AI 工具连接的通用标准。
在 MCP 之前：
在 MCP 之后：
一个 Agent OS 可以同时实现 MCP Client 和 MCP Server：
Agent-to-Agent Protocol (A2A) 则试图解决另一个问题：不同框架的代理如何互操作？
A2A 的核心概念：
┌─────────────┐ A2A Protocol ┌─────────────┐
│ Agent OS A │ ←─────────────────→ │ Framework B │
│ (OpenFang) │ │ (LangGraph) │
└─────────────┘ └─────────────┘
通过实现 A2A 协议，一个 Agent OS 可以处理相关任务端点，并与任何 A2A 兼容系统协作。
当协议标准化、Agent OS 成熟、Plan 成为可靠契约后，我们将迎来 AI Agent 演进的第七阶段：自主运营时代。这一阶段的标志是人机异步协作——人类专注于目标设定与结果验收，Agent 在人类不需要实时在线的情况下持续工作。
| 维度 | 人机融合阶段（阶段3） | 自主运营阶段（阶段7） |
|---|---|---|
| 交互方式 | 同步、实时、对话式 | 异步、任务式、结果导向 |
| 主控权 | 人类在环内（Human-in-the-loop） | 人类在环上（Human-on-the-loop） |
| 时间关系 | 人类等待 Agent，Agent 等待人类 | Agent 可在人类离线时持续工作，人类按需介入 |
| 交互粒度 | 细粒度指令（“下一步做什么”） | 粗粒度目标（“完成什么”） |
| 人类角色 | 实时操作者、每步确认者 | 目标设定者、关键决策者、结果验收者 |
| 人类瓶颈 | 注意力 | 判断力 |
实现“Agent 可以在人类不需要实时在线的情况下持续工作”需要 Agent OS 具备比传统操作系统更高级的调度能力。而 Delta 的“平行宇宙”机制（4.8.5）为此提供了天然的支撑——任务分解后，调度器可以为每个子任务创建独立的执行分支，实现真正的并行探索，最终通过聚合器合并。
人类目标
↓
┌─────────────────┐
│ 人类：目标澄清 │ ← 可能需要多轮对话来明确目标
└─────────────────┘
↓
┌─────────────────┐
│ 任务分解器 │ ← 将高层次目标分解为可并行子任务
└─────────────────┘
↓
┌─────────────────────────────────────┐
│ 调度器 (Scheduler) │
│ 分配资源、管理优先级、坚控执行状态 │
└─────────────────────────────────────┘
↓ ↓ ↓ ↓ ↓
Agent A Agent B Agent C Agent D Agent E
(研究) (分析) (生成) (验证) (聚合)
↓ ↓ ↓ ↓ ↓
└────────┴────────┴────────┴────────┘
↓
┌───────────────┐
│ 结果聚合器 │ ← 合并、去重、解决冲突
└───────────────┘
↓
┌───────────────┐
│ 人类验收/判断 │
└───────────────┘
↓
┌───────────────┐
│ 反馈与调整 │ ← 人类可以要求Agent修改方向
└───────────────┘
↓
[迭代或完成]
当 Agent 可以自主并行工作，人类的瓶颈将从注意力转移到判断力：
经济含义：当判断力成为主要瓶颈之一，人类的价值将更多地体现在设定正确的目标、做出关键决策、评估复杂结果，而非实时坚控和微操。这可能会催生新的职业——“Agent 经理”或“判断力工程师”，他们擅长设定目标、设计验收标准和快速评估结果。组织的产出不再是执行能力的线性叠加，而是判断质量的指数放大。
McKinsey 在 2025 年提出了 “Agentic Organization” 的概念：人类与 AI 代理并肩工作，以近乎零边际成本创造价值。
这不仅是技术变革，更是组织变革：
前沿研究正在探索自进化代理（Self-Evolving Agents）：
OpenFang 的 Hands 已经迈出了第一步：它们可以积累知识、构建图谱、追踪准确性。
随着协议标准化（MCP、A2A），我们可能会看到：
这个愿景也面临重大挑战，需要技术、法律和社会层面的共同演进：
复杂性管理：当代理数量和交互频率指数级增长，如何保证系统的可理解性和可调试性？ → 需要可观测性（Observability）和分布式追踪的 Agent 原生支持，例如为每个任务生成唯一的追踪 ID，记录决策路径。
安全对抗：恶意代理可能伪装成合法服务，如何建立信任机制？ → 引入信任评分和行为基线，动态检测异常；对 Agent 的记忆库进行防投毒保护。
论理与法律：代理行为造成损失时，责任如何界定？自主代理的法律地位如何定义？ → 需要行业共识和立法先行，例如建立“代理行为审计标准”和“责任保鲜框架”。
协议碎片化：多个竞争性协议（MCP、A2A、厂商私有协议）共存，如何避免新的孤岛？ → 可能出现协议适配层或元协议，作为不同协议间的翻译器；同时推动开放治理，避免一家独大。
对抗性攻击：针对 Agent 的“幻觉诱导”、“提示词注入变种”将成为新威胁。 → 持续强化输入过滤和输出验证，引入对抗性训练，并在架构层面设计“隔离区”运行高风险任务。
回顾 AI Agent 的演进历程，我们看到一条清晰的轨迹：
Request-Response → Chat → Tool Use → Human-in-Loop → Multi-Agent → Agent OS → Autonomous Operation
↓ ↓ ↓ ↓ ↓ ↓ ↓
孤立 连续 三方协作 人机融合 专业分工 自主运营 人机异步协作
但最重要的转变是从“Chat”到“Work”，最终到**“Autonomous Work”**。
传统的 AI 是一个“智能问答机”——你问，它答。今天的 Agent OS 是一个“数字员工”——给它一个目标，它会规划、执行、汇报、改进。而未来的自主运营时代，人类将不再与 Agent 实时对话，而是向一群并行工作的 Agent 发布目标，然后在关键节点验收它们提交的结果，并给出反馈调整方向。
一些系统已经开始体现这个转变的早期形态，例如提供多种自主工作的代理：
它们不再“等待你输入”，而是“为你工作”。当这些代理能够并行协作、人类只需每天早晨验收成果时，生产力的解放就真正实现了。
这正是 Agent 的终极形态：不是工具，而是伙伴；不是被动响应，而是主动执行；不是单点智能，而是系统协作；不是实时操控，而是目标驱动。
未来的组织将同时拥有人类员工和 AI 代理，形成深度分工的协作模式：
这不是“人类 vs 代理”的替代关系，而是“人类 + 代理”的协同关系。人类不再被低价值的微操消耗，而是专注于真正需要人类判断的工作。
这个时代正在到来。而 Agent OS、MCP、A2A 这些技术和协议，正是通往这个未来的基础设施。
本文中“Agent = Process, Skill = DLL”的类比是作者在分析多代理系统时提出的一种理解框架，而非任何框架的官方定义。
这个类比的价值在于：
有趣的是，一些 Agent OS 的安全分层做法（WASM 沙箱、能力门控、进程隔离等）与传统操作系统的安全机制高度吻合——这或许说明，当一个系统足够复杂时，它会不可避免地重新发明操作系统的核心概念。
| 时间 | 论文/事件 | arXiv | 意义 |
|---|---|---|---|
| 2022.01 | Chain-of-Thought | 2201.11903 | 推理能力突破，“展示工作过程” |
| 2022.10 | ReAct | 2210.03629 | 定义现代 Agent 架构，Reasoning+Acting |
| 2023.02 | Toolformer | 2302.04761 | 模型自主学习使用工具 |
| 2024.03 | AIOS | 2403.16971 | Agent OS 的学术理论框架 |
| 时间 | 事件 | 意义 |
|---|---|---|
| 2022.11 | ChatGPT 发布 | LLM 进入主流 |
| 2023.3 | GPT-4 + Plugins | 首次工具调用 |
| 2023.6 | OpenAI Function Calling | 标准化工具接口 |
| 2023.9 | AutoGen 发布 | 多代理协作框架 |
| 2024.2 | CrewAI 发布 | 角色化代理编排 |
| 2024.5 | LangGraph 发布 | 图状态机工作流 |
| 2024.11 | MCP 发布 | 工具连接标准 |
| 2025.4 | A2A 发布 | 代理互操作协议 |
| 2025.12 | Google 发布 A2UI 协议 | 用于 Agent 动态生成原生 UI 的标准化协议 |
| 2026.2 | OpenFang 发布 | 首个自称 Agent OS 的系统之一 |
前文 2.4.3 提到，成熟的 Agent OS 往往会采用“自然语言 + 嵌入式 DSL”的协作模式。本节给出一个具体的实现案例：NopAutoCoder 的工具调用 DSL。它体现了本文讨论的多个设计要点：
<call-tools> 片段，作为 Agent 的“可执行计划”。NopAutoCoder 通过一段结构化的 XML 声明当前会话可用的所有工具与子 Agent：
<available-tools>
<tool name="shell">
<schema>
<shell id="int" explanation="short-description">single-line-bash-command</shell>
</schema>
</tool>
<tool name="patch-text-file">
<schema>
<patch-text-file id="int" path="absolute-path-to-file"
explanation="short-description-of-aiming"><![CDATA[YOUR-PATCH]]></patch-text-file>
</schema>
</tool>
<tool name="call-agent">
<schema>
<call-agent id="int" explanation="..." agent="..." sessionId="... (optional)"><![CDATA[...]]></call-agent>
</schema>
</tool>
<!-- ... 省略其他工具定义 ... -->
</available-tools>
<available-agents>
<agent name="NopAutoCoder">
<description>通用自主编码 Agent。</description>
</agent>
<agent name="CodeReviewer">
<description>专职代码审查 Agent。</description>
</agent>
<!-- ... -->
</available-agents>
这里可以看到一种典型的“元模型化”做法：
<tool> 节点内部用 <schema> 子节点描述其入参结构，id 和 explanation 这样的通用属性，统一了工具调用的“协议头”，<available-agents> 提供了二级调度能力——当前 Agent 可以再委托其他 Agent 完成子任务。这些结构完全可以由 XDef 一类的元模型来定义和约束，使得：
<call-tools> 作为嵌入式 Plan 片段在执行阶段，NopAutoCoder 不用自然语言描述“我要先读文件再打补丁”，而是直接返回一段 <call-tools> DSL 片段，作为一次批量执行的“微型 Plan”：
<call-tools>
<shell id="101" explanation="Read /app/main.py to get context for editing."><![CDATA[
cat /app/main.py
]]></shell>
<patch-text-file id="102" path="/app/main.py"
explanation="Add 'import os' after 'import sys'."><![CDATA[
@@import sys
+import os
]]></patch-text-file>
</call-tools>
约束规则包括：
id 唯一：每个调用在当前 <call-tools> 块内必须有唯一的整数 id，便于结果匹配和追踪。explanation 必填：所有调用都必须用简短自然语言解释目的，
<call-tools> 块内的多个调用如果彼此无依赖，可以被底层执行引擎自动并行化。从本文第 4 章 Plan 的视角看，这其实是一种非常细粒度的 Plan 片段：
<call-tools> 是一次“工具级”的微计划，<shell> / <patch-text-file> 调用对应 Plan 中的一个步骤，<call-agent> 与会话级 Plan对于复杂任务，NopAutoCoder 通过 call-agent 工具把子任务委托给专门的 Agent，并通过 sessionId 维持会话上下文：
<call-tools>
<call-agent id="201" explanation="Ask CodeReviewer agent to review a function."
agent="CodeReviewer"><![CDATA[
Review this code: ...
]]></call-agent>
</call-tools>
<!-- 响应示例 -->
<call-tools-response>
<agent-output id="201" sessionId="session-ABC-123" status="success"><![CDATA[
This code is inefficient. Use memoization. Would you like an example?
]]></agent-output>
</call-tools-response>
此后，任何后续对 CodeReviewer 的调用，都可以通过复用 sessionId="session-ABC-123" 来继续这一会话。这种机制在语义上对应本文中提到的：
sessionId 将短期记忆提升为可持续的外部会话状态；通过 NopAutoCoder 的这个嵌入式 DSL 案例，我们可以看到：
能力列表（available-tools/agents） 体现了统一元模型的优势：
执行片段（call-tools/call-tools-response） 将“工具调用”提升为一等公民：
嵌入式 DSL 让 Agent 与人类之间的对话不仅仅是自然语言：
