Agent、AVM 与 AgentOS：如何构建 AI Native 软件 • End of Dev

过去几年，我们已经非常习惯把 LLM 接入软件。

让 LLM 判断用户意图、从文档中提取信息、生成 SQL 或总结报告，这些用法共享同一种结构：外层软件准备输入并调用 LLM，LLM 返回结果，软件再决定下一步。随着 LLM 能够调用工具，一次调用内部可以包含多轮推理和行动；我们常常把这个调用单元命名为 Agent，再将多个 Agent 连接成 Workflow。

在这种结构中，LLM，乃至所谓的 Agent，都是由外层软件以函数形式调用的。无论内部多么复杂，只要调用时机、输入上下文和后续控制流仍由外层软件决定，它在系统中的结构位置就是一个函数。本文把这种调用单元称为 LLM 智能函数。

这些系统当然是 AI 软件，但它们还不是本文所说的 AI Native 软件。

原因不在于模型不够强，也不在于一次能调用多少个工具，而在于主体逻辑仍然属于传统软件。即使一个 LLM 智能函数拥有很长的 Prompt、能够使用多个工具，甚至暴露为 XxxAgent.run()，它仍然由外层程序调用和编排。

AI Native 软件需要一次更根本的控制反转：Agent 不再是被软件调用的函数，而成为承担责任、感知状态和选择行动的主体；传统程序则退到能力与规则层。

传统 AI 软件：Software calls LLM 智能函数
AI Native 软件：Agent calls Software Capabilities

要承载这种软件，我们需要一套不同于传统应用框架的运行时。本文将它称为 AgentOS：它保存 Agent Definition，管理 Agent 与 AVM（Agent Virtual Machine）的生命周期，并提供 Event、Context、Memory、Capability、执行环境和治理机制。AgentOS 负责让 Agent 可靠地运行，但不预先定义具体业务应该沿哪条流程前进。

如果说 AVM 是解释单个自然语言程序的虚拟机，那么 AgentOS 就是管理大量 Agent 程序、执行实例及其运行环境的系统。它也是世界收敛模型的具体工程实现。

这要求我们重新回答几个基础问题：Agent 究竟是什么？自然语言如何成为一种程序？谁来解释这种程序？一个长期存在的 Agent 如何被唤醒、获得上下文、使用记忆和工具，并在当前责任收敛后暂停？多个 Agent 又如何在没有中心业务编排器的情况下，共同构成一套软件？

下文将先从传统 AI 软件与 AI Native 软件的结构差异出发，再沿着世界收敛模型、Agent Definition、Agent Virtual Machine（AVM） 与 AgentOS 逐层展开，并尝试给出一套完整的理论和工程模型。

为了让后面的抽象概念始终对应到一套具体系统，本文会贯穿使用一个自动化软件研发系统作为例子。它包含负责需求澄清的 Product Agent、负责实现的 Developer Agent、负责审查和验证的 Review Agent 与 Test Agent，以及 Security Agent、Release Agent 等长期承担不同责任的 AI 角色；Product Owner、Tech Lead 和 Release Approver 等人类角色也会参与其中。前面的理论章节会借这些角色说明局部概念，第 8 章再把它们组合成一套完整的软件系统。

1. 从 LLM 智能函数到 Agent Runtime

传统软件开发的核心工作，是把需求翻译成一套可以被机器确定执行的状态和控制流。

Input
  ↓
Predefined Control Flow
  ↓
Output

开发者需要在系统运行之前回答：可能收到什么输入，当前处于什么状态，应该进入哪个分支，发生异常后如何恢复，以及整个流程在什么条件下结束。软件最终能够做出的全部行为，都必须通过代码提前获得表达。

这也是复杂业务系统开发困难的根源之一。真正困难的往往不是写出正常路径，而是穷举现实世界的组合：需求存在歧义怎么办，前置状态已经变化怎么办，两个规则发生冲突怎么办，外部系统返回了从未见过的结果怎么办。每增加一种状态，都可能与已有状态产生新的组合；每增加一个异常分支，又需要考虑它与后续流程如何衔接。

传统软件并非不能处理复杂问题，而是只能处理已经被开发者转化为程序结构的复杂问题。面对设计范围之外的输入，它通常只能拒绝、报错、进入统一兜底，或者把问题交还给人类。

1.1 传统 AI 软件：传统软件加上 LLM 智能函数

LLM 出现后，我们获得了一种过去没有的软件能力：程序可以调用一个能够理解自然语言、处理模糊信息和生成开放结果的函数。

const intent = await llm.classify(message);

if (intent === "change_requirement") {
  return runChangeRequirementFlow(message);
}

return runDefaultFlow(message);

这个函数可以用于分类、提取、检索、生成、评分和规划。它甚至可以在内部调用工具，经过多轮推理后再返回结果。但从系统结构上看，主体逻辑没有改变：

Output = Program(Input, LLMIntelligentFunction(Prompt, Context))

仍然是外层程序决定：

什么时候调用 LLM；
给它哪些信息；
要求它返回什么；
如何解释返回结果；
下一步进入哪个程序分支；
整个业务过程何时结束。

“LLM 智能函数”描述的是 LLM 或所谓 Agent 在软件中的结构位置，并不是说 LLM 本身在理论上等同于一个普通函数。一个拥有几十个工具、能够连续运行十分钟的 Agent，只要仍由外层程序传入参数、发起调用并接收返回值，它就是一个 LLM 智能函数。

把多个这样的函数命名为 Product Agent、Developer Agent 和 Review Agent，再按照固定顺序连接起来，也不会改变这一点：

Product Agent
  ↓
Developer Agent
  ↓
Review Agent
  ↓
Test Agent

只要节点、顺序、分支和结束条件仍由开发者提前画好，所谓的 Agent 就仍然是 Workflow 调用的 LLM 智能函数。模型可以让每一个节点更加灵活，却无法走出外层软件预先定义的业务图。

本文把这种开发方式称为传统 AI 软件开发：

传统 AI 软件，是在传统程序所拥有的业务控制流中，把 LLM 或所谓 Agent 作为 LLM 智能函数来调用。

这类软件非常有用。RAG、智能搜索、文档提取、生成式 UI，以及大量带有 LLM 节点的业务流程，都可以用这种方式可靠实现。称它为“传统”不是为了否定它，而是为了区分两种完全不同的软件结构。

1.2 AI Native 是一次控制反转

AI Native 软件不再由外层程序预先拥有完整的业务控制流。

开发者定义 Agent 的身份、责任、能力、规则和收敛条件。系统运行后，Agent 感知当时的状态，判断下一步应该做什么，并调用传统软件提供的能力完成行动。真实的行动路径直到运行时才会产生。

Traditional AI Software

Software
  └── calls LLM 智能函数

AI Native Software

Agent Runtime
  ├── calls Tool
  ├── calls MCP
  ├── calls Workflow
  ├── calls Domain Service
  └── collaborates with Agents and Humans

因此，AI Native 的核心不是更长的 Prompt、更自主的 Tool Calling 或者更多 Agent，而是控制关系发生了反转：

在传统 AI 软件中，Software 调用 LLM 智能函数；在 AI Native 软件中，Agent 调用 Software Capabilities。

可以从几个维度观察这种区别：

	传统软件	传统 AI 软件	AI Native 软件
主体逻辑	确定性代码	确定性代码	Agent Definition
LLM 的位置	无或辅助能力	程序调用的智能函数	AVM 的执行引擎
业务控制流	开发时固化	开发时固化	运行时形成
未预期情况	拒绝、异常或兜底	由 LLM 处理局部内容	Agent 继续感知、推理、行动或升级
确定性代码	定义逻辑与边界	定义逻辑与边界	定义能力与边界
完成条件	到达结束节点	到达结束节点	Agent 判断局部收敛

这也给出了一个简单的判断方法：

当现实偏离设计者最初预想的流程时，系统能否仍然根据责任、状态和能力，形成一条没有被显式编写过的行动路径？

如果系统只能进入预先准备好的异常分支，它仍然是传统软件；如果 LLM 只能在某个节点内生成更灵活的返回值，它仍然是传统 AI 软件。只有当 Agent 能够继续观察、选择工具、修改方案、请求协作，并在权限边界内产生新的行动序列时，软件才开始具有 AI Native 的结构。

1.3 Workflow 从骨架变成能力

AI Native 并不意味着 Workflow 会消失。编译、测试、发布、支付、数据迁移和事务处理仍然适合由确定性流程实现。

真正发生变化的是 Workflow 在系统中的位置。传统 AI 软件把 Workflow 当作整个系统的骨架，再把 LLM 放进其中；AI Native 软件把 Workflow 当作 Agent 可以调用的一种能力。

传统 AI 软件：Workflow ──▶ LLM 智能函数
AI Native 软件：Agent ──▶ Workflow（Capability）

例如，build → test → package 可以继续是一条固定的 CI Workflow。但是否应该运行它、选择什么参数、失败后调查什么、是否需要修改代码后重试，应当由 Developer Agent 或 Release Agent 根据当前状态决定。

固定的执行流程没有问题，问题在于是否试图用它预先描述整个开放业务过程。Workflow 适合实现已经确定的方法，Agent 适合判断此刻应该采用什么方法。

1.4 开放理解，受限行动

传统软件的输入边界通常由 Schema 和控制流共同定义。超出边界的信息，即使人类能够理解，也可能无法进入系统。例如，“升级这个依赖，但要照顾仍在使用旧版客户端的用户”很难映射成一个预先设计好的 API 参数集合。

Agent 可以理解这种没有被提前枚举的语义输入，主动读取项目状态，识别“照顾旧版客户端”在当前系统中意味着协议兼容、灰度策略还是数据迁移，并在必要时向人类澄清。

但能够理解开放输入，不意味着 Agent 可以产生不受限制的输出。它仍然只能使用被授予的 Capabilities，只能在策略允许的环境中行动，并且必须把高风险或超出责任的判断升级给其他 Agent 或人类。

开放的理解与决策
        ↓
受约束、可审计的外部行动

AI Native 软件不是消灭边界，而是把边界从“允许经过哪些预定义路径”，转变为“允许使用哪些能力、改变哪些状态、承担哪些责任”。

1.5 开发难度发生了转移

AgentOS 也不会神奇地消除软件复杂度。它减少的是开发者在运行前穷举开放业务路径的工作，同时把一部分难度转移到了运行时工程：

传统软件
  业务复杂度 → 状态机 → 分支 → Workflow → 控制代码

AI Native 软件
  业务复杂度 → 责任划分 → 能力与边界 → Runtime → 评估与治理

开发者不再需要为每一种情况编写具体分支，但必须设计清晰的 Agent Definition，提供可靠的 Tool 和领域服务，处理权限与环境隔离，建设 Memory、可观测性、评估和恢复机制。

所以更准确的结论是：

AgentOS 降低了描述开放业务过程的难度，同时提高了对运行时基础设施、行为边界和系统治理的要求。

不过，在设计这套运行时之前，我们首先需要定义 Agent 的基本行为语义：它能够感知什么，为什么行动，又在什么时候停止行动。世界收敛模型回答的正是这个问题。

2. 世界收敛模型

在《世界收敛模型：多智能体协作的另一种范式》中，我们讨论了一种不同于请求—响应和中心化编排的协作模型：每个 Agent 根据自己能够感知的状态，判断当前是否仍有属于自己责任范围的事情需要处理；如果有，它便继续行动，如果没有，它便进入收敛，等待下一次变化。

这里的“世界”首先是一个虚拟概念。它不是 AgentOS 中实际存在的对象、服务或者全局数据结构，也不存在一份由所有 Agent 共享的“世界状态”。它只是用来描述：

在某个时刻，一个 Agent 能够感知到的全部状态。

可以把它记作：

World(agent, t) := all states perceivable by agent at time t

不同 Agent 拥有不同的身份、权限、工具和记忆，因此能够感知的世界也不同。Developer Agent 看到代码、Issue 和构建结果；Security Agent 看到依赖、权限与漏洞报告；人类产品负责人看到需求、进度和等待自己确认的决策。真实状态仍由 Git、Issue Tracker、CI 等领域系统保存，AgentOS 只负责让 Agent 取得与当前责任有关的信息。

2.1 Event 表示变化，Tool 读取状态

Agent 对世界的感知并不只有 Event。

Event 表示变化。 PR 更新、测试结束、新需求和定时器到期都可以像中断一样唤醒 Agent。但 Event 通常不包含完成判断所需的全部状态：pull_request.updated 可以提醒 Review Agent，却无法替代完整的代码 Diff、CI 结果、关联需求和项目规范。因此，Agent 还需要通过只读 Tool、API、文件系统、数据库或者 MCP 主动观察当前状态：

Event  ≈ Δ：世界发生了什么变化
Tool   ≈ State Access：世界现在是什么样子

读取类 Tool 用于感知世界，写入类 Tool 用于改变世界；两者可以使用相同协议，但必须具有不同的权限和审计边界。没有新 Event 不代表客观上没有问题，Agent 仍然可以通过定时唤醒主动检查；收到 Event 也不代表必须行动，它仍需判断这次变化是否影响自己的责任。

2.2 收敛是一种主观判断

世界收敛不是某个全局 Workflow 到达了最后一个节点，也不是系统中所有数据都进入了某种客观完美状态。它是一个 Agent 基于当前能够感知的信息，对自身责任作出的局部判断：

Converged(agent, t)
  := 当前没有可感知、可处理且属于该 Agent 责任的未完成事项

同一个测试失败事件，对 Developer Agent 来说可能意味着代码仍需修改，对 Product Agent 来说却未必需要任何行动。即使是同一个 Agent，随着它读取到更多状态，收敛判断也可能改变。

这种主观性并不是缺陷。开放世界中的信息永远不可能完整，系统真正需要的不是证明“整个世界已经完成”，而是让每一个承担责任的主体回答：基于我现在知道的事情，还有什么是我应该做的？

因此，一个 Agent 的基本运行语义可以被压缩成：

感知变化与状态
  ↓
根据责任进行判断
  ↓
采取行动，或返回 Converged

如果 Agent 采取了行动，领域状态会随之变化，并可能产生新的 Event，唤醒自己、其他 Agent 或人类。多个主体不需要服从一张预先写好的全局流程图，它们只需要持续推动各自负责的局部状态走向收敛，协作便通过这些行动的级联产生。

2.3 收敛不等于正确

Agent 返回 Converged，只表示它基于当前能够感知的信息，认为没有仍由自己负责的行动。它不证明客观世界已经正确，也不证明其他 Agent 或人类已经完成工作。

因此，收敛必须与确定性验证以及其他 Agent 和人类的观察共同使用。编译器、测试、Schema、Policy、CI Gate 和领域约束继续验证已知边界；其他 Agent 与人类则从不同责任角度重新观察结果。Review Agent 宣布收敛，不等于代码绝对没有缺陷，而是表示在当前 Diff、测试、规范和自身能力范围内，已经没有继续 Review 的理由。未来出现新的测试、告警或安全知识时，一个新 Event 会再次打破这个判断。

世界收敛模型接受这种暂时性：软件不是达到一次永久完成，而是在持续变化中反复进入局部稳定。

世界收敛模型由此给出了 Agent 的行为语义，但它还没有回答一个工程问题：究竟用什么来定义一个 Agent？

3. Agent Definition 与 AVM

3.1 Agent Definition：自然语言程序

传统软件使用函数、类和模块描述行为。当我们创建一个 Agent 时，也需要一种形式来定义它是谁、负责什么、能够做什么，以及如何判断自己的工作已经完成。本文将这份定义称为 Agent Definition。

Agent Definition 不是用来临时诱导模型生成某种回答的 Prompt，也不是一段需要先被转换成工作流的配置。它就是 Agent 的程序，并且由 AVM 直接解释执行。

一份 Agent Definition 至少需要表达：

Identity：Agent 的身份以及它在系统中的位置；
Responsibility：它持续负责哪些结果；
Instructions：处理问题时应遵循的原则和方法；
Policies：绝对不能违反的规则，以及必须升级给人类的情况；
Event Interests：哪些变化可能与它有关；
Capabilities：它可以读取什么、调用什么和修改什么；
Convergence Conditions：它如何判断当前已经没有需要继续推进的事项。

例如，一个自动化研发系统中的 Developer Agent 可以被定义为：

你是当前项目的 Developer Agent。

你负责把已经明确的产品需求转化为可维护、可验证的代码变更，
并持续处理由这些变更引起的构建、测试和代码审查反馈。

开始工作前，先读取关联 Issue、仓库规范和当前分支状态。
不要绕过测试、权限和代码审查策略。
当需求存在会显著改变产品行为的歧义时，请求 Product Owner 确认，
不要自行假设。

你可以读取和修改被分配的代码仓库、运行开发命令、提交变更，
并读取 CI 与 Review 结果。

当实现已经提交、相关检查通过，且没有仍由你负责的反馈时，
当前工作收敛。

这段定义没有列出“先执行 A，再执行 B，失败后进入 C”的完整流程。面对升级依赖、修复并发问题或者实现新接口，它可能生成完全不同的行动路径。但这些路径始终受到同一份身份、责任、能力和策略约束。

3.2 为什么自然语言可以成为程序

传统程序要求开发者提前枚举状态和分支，是因为机器只能执行形式化指令。它的优势是精确和可重复，但代价是行为空间在设计时就已经封闭：没有被写入控制流的情况，只能成为异常或者未定义行为。

自然语言程序描述的不是每一条执行路径，而是在开放情境中生成执行路径的语义约束。同一句“确保这次修改不破坏旧版客户端”，可能在不同项目中产生不同的检查、测试和实现方式。路径不是开发者事先写好的，而是 Agent 根据当时的状态，在运行时构造出来的。

这并不意味着自然语言可以替代所有代码。恰恰相反，越开放的内部推理，越需要严格的外部边界：

Natural language inside, typed effects outside.

Agent 可以使用自然语言理解需求、形成假设和选择行动，但真正改变世界的操作必须经过具有明确输入输出、权限、审计和失败语义的 Tool。数据库约束、访问控制、分支保护、安全策略和事务一致性也不应该依赖模型“记得遵守”，而应该由确定性系统强制保证。

因此，AI Native 软件并不是把代码全部改写成自然语言，而是重新划分两者的职责：

确定性代码定义世界的规律，Agent 判断在这些规律之内应该做什么。

3.3 Agent Definition 与 Prompt 的区别

Agent Definition 和模型最终收到的 Prompt 并不是同一个东西。

Agent Definition 是长期存在的源程序，描述 Agent 稳定的身份和行为语义。Prompt 则是 AVM 为某一次执行组装出的有限输入，其中可能包括 Agent Definition、当前 Event、即时 Context、从 Memory 中检索出的相关内容，以及当前可以使用的 Capabilities。

Agent Definition       长期存在的自然语言程序
Event                  本次执行的触发变化
Context                本次执行需要的有限信息
Memory                 跨执行保留的经验与认知
Capabilities           当前被允许使用的外部能力
Prompt                 AVM 为一次模型执行物化出的输入

这个区分非常重要。如果把 Agent Definition 等同于 Prompt，Agent 就会退化成一次模型调用；如果把全部历史都塞进 Prompt，Memory 也会退化成不断增长的聊天记录。逻辑上的 Agent 应当长期存在，而每次模型执行只应获得完成当前判断所需的有限上下文。

Agent Definition 已经是一种程序，但程序还需要执行环境。自然语言不会自己读取 Event、检索 Memory、获得工具权限或者保存执行状态。这些工作属于 Agent Virtual Machine。

3.4 AVM：Agent Virtual Machine

如果把 Agent Definition 看成一种自然语言程序，那么 Agent Virtual Machine（AVM） 就是解释这种程序的虚拟机。

这个概念可以与 JVM 类比：Java 程序不需要了解底层 CPU、操作系统和内存管理的全部细节，它只需要遵循 JVM 提供的执行语义；同样，Agent Definition 不应该关心具体使用哪一家模型、工具连接如何建立、Memory 存储在哪里，或者执行中断后如何恢复。AVM 在 Agent Definition 与底层模型及基础设施之间提供了一层稳定抽象。

JVM	AVM
Java Language	Natural Language
Java Program	Agent Definition
JVM	Agent Virtual Machine
Execution Engine	LLM
Stack / Heap	Context / Memory
Standard Library / System Call	Tool / MCP
Interrupt	Event
Exception	Tool Error / Policy Violation
Process Exit	Converged / Suspended

这个类比最重要的部分，是把 LLM 放回正确的位置：

LLM 不是 Agent，LLM 是 AVM 内部可替换的执行引擎。

Agent 是长期存在的逻辑主体，拥有身份、定义、记忆、能力和生命周期。LLM 只在 Agent 需要理解状态和决定下一步行动时参与一次执行。更换模型可能改变性能、成本和推理质量，却不应该改变 Agent 在系统中的身份，也不应该让它失去过去的记忆和未完成的工作。

3.5 AVM 的执行接口

AVM 的核心接口可以抽象为：

AVM.run(
  AgentDefinition,
  Event,
  Context,
  Memory,
  Capabilities
) -> Action | Converged

它接收自然语言程序与当前执行环境，最终只返回两类结果：

Action：Agent 决定继续观察或改变世界，例如读取文件、查询 CI、修改代码、发送消息或者设置定时器；
Converged：基于当前能够感知的信息，Agent 认为已经没有属于自己责任的事情需要继续处理。

一次 AVM.run 表示 Agent 的一个决策步。Agent 可能先决定读取代码，AgentOS 执行这个 Tool Call 并把结果放入 Context，然后再次运行 AVM；下一步可能是查询测试日志、检索项目记忆或者修改文件。这个循环会持续到 Agent 返回 Converged，或者因为等待外部结果而暂时挂起。

context = assemble(event, memory, capabilities)

loop:
    result = AVM.run(agent_definition, context)

    if result is Converged:
        persist_and_suspend()
        break

    observation = execute_validated(result.action)
    context.append(observation)

AVM 负责解释和执行单个 Agent，但不应该偷偷替 Agent 作出业务决定。它可以限制资源、拒绝越权调用、处理中断、记录轨迹和恢复检查点，却不应该根据硬编码业务规则决定“现在该由 Review Agent 接手”。后者仍然应该来自 Agent 对自身责任和当前状态的判断。

3.6 逻辑 Agent 与物理执行

一个常驻的 Agent 不意味着一块 GPU、一个容器或者一个模型会话必须永远运行。

逻辑上的 Agent 可以持续存在，物理上的 AVM 则按需创建：Event 到达时恢复 Agent 的状态并执行，返回 Converged 后保存必要信息并释放计算资源。下一次被唤醒时，再从持久化状态继续。

Logical Agent:  ──────────────────────────────────────────────▶

Physical AVM:      [run]          [run][run]            [run]
                    event          tool result           timer

这种分离同时解决了身份连续性与资源成本问题：Agent 可以像团队成员一样长期承担责任，但只有在世界变化或者需要继续工作时才消耗模型和执行资源。

同一个逻辑 Agent 的决策过程通常应该保持串行。新的 Event 可以进入收件箱，也可以触发中断判断，但不应让两个 AVM 同时以同一身份修改共享记忆和领域状态。需要并行完成的工作，应当交给其他 Agent，或者由 Agent 调用具有明确并发语义的工具。

3.7 AVM 与 JVM 的不同

JVM 执行的是已经形式化的确定性指令，而 AVM 解释的是存在歧义、结果具有概率性的自然语言程序。JVM 的可移植性主要是指相同字节码在不同机器上保持相同语义；AVM 的可移植性则是一种语义可移植性：同一份 Agent Definition 可以在不同模型和基础设施上继续表达相同的身份、责任与边界，但不能保证每次产生完全相同的行动路径。

因此，AVM 不能只是模型调用接口。它还要控制 Context，从长期 Memory 中读写信息，暴露经过授权的 Tool 和 MCP，对外部副作用进行校验与审计，并在失败、冲突或信息不足时把问题重新交还给 Agent。执行轨迹、状态恢复和成本治理则由更外层的 AgentOS 提供。

这也解释了为什么只有 LLM API 和 Tool Calling 还不足以构成 Agent。它们提供了执行引擎和系统调用，却没有定义程序、内存、生命周期、中断、权限和收敛语义。

到这里，我们已经得到了一台能够运行单个 Agent 的虚拟机。但一套软件不会只有一个 Agent。谁来管理大量逻辑 Agent 与物理 AVM，投递 Event、组装 Context、提供 Memory、分配能力、隔离执行环境并记录整个系统的运行轨迹？这正是 AgentOS 需要回答的问题。

4. AgentOS：从单个 Agent 到软件系统

世界收敛模型定义了 Agent 如何行动，Agent Definition 描述了它的程序，AVM 提供单个 Agent 的执行环境。AgentOS 则负责把这些概念组织成一套可以真正运行的软件系统。

它管理大量长期存在的逻辑 Agent，并按需创建物理 AVM，为每次执行提供 Event、Context、Memory、Capabilities 和计算资源。它还要保证外部行动受到权限控制，执行失败可以恢复，整个过程可以观察和审计。

可以用一句话描述三者的关系：

Agent Definition 是程序
AVM 解释并执行单个程序
AgentOS 管理程序、执行实例及其运行环境

4.1 AgentOS 管理运行时，而不是业务流程

AgentOS 应当控制的是运行顺序和运行资源，而不是业务行动和责任流转。它可以决定某个 AVM 什么时候获得计算资源，可以限制一个 Agent 同时只能有一个活动执行，可以在 Event 到达后恢复检查点；但它不应该硬编码“需求分析结束后必须轮到架构设计”。

在世界收敛模型中，业务流转来自领域状态的变化：

Developer Agent 修改代码并创建 PR
  ↓
Git 保存真实状态，并产生 pull_request.opened Event
  ↓
Event Kernel 将变化投递给可能关注它的 Agent
  ↓
Review Agent 被唤醒
  ↓
Review Agent 读取 PR、CI、Issue 和规范
  ↓
自行判断是否需要行动

Event Interests 可以帮助 AgentOS 筛选哪些 Agent 可能需要被唤醒，但它只是一种运行时投递机制，不代表 Agent 必须执行某个业务步骤。最终是否行动、采取什么行动以及何时收敛，仍由 Agent 自己判断。

因此：

AgentOS 是 Agent Runtime 的管理者，而不是业务过程的管理者。

4.2 AgentOS 中没有 World Service

既然 Agent 根据自己感知的世界行动，一个直觉性的设计是让 AgentOS 建立一个 World Service，为所有 Agent 维护统一的世界状态。但这既没有必要，也会制造新的问题。

真实状态已经由各个领域系统保存。Git 是代码和版本历史的事实来源，Issue Tracker 是任务状态的事实来源，CI 是构建与测试状态的事实来源。AgentOS 如果复制这些状态，就必须处理同步、冲突、过期和权限问题，并最终形成一个无法真正完整的全局投影。

AgentOS 应该保存的是运行 Agent 所需的状态：

Agent Definition 与版本；
Agent 的生命周期状态；
Event Inbox、消费位置和处理中断；
当前 Context 与执行 Checkpoint；
Memory 及其访问范围；
Capabilities、凭证引用和权限策略；
Environment 与 Artifact 引用；
Tool Result、执行轨迹、成本和审计记录。

它不保存“世界”。Agent 被唤醒后，通过 Event 得知变化，通过 Tool 和 MCP 读取真实领域状态，再结合 Context 与 Memory 形成这一次执行所需的有限认知。World 只是我们从外部描述这些可感知状态时使用的概念。

4.3 AgentOS 的核心组成

从整体结构看，AgentOS 可以分成四组运行时能力：

Control Plane
  Agent Registry / Event Kernel / Scheduler

Execution Plane
  AVM Runtime / Context Assembler / Model Gateway / Tool / MCP Gateway

State Plane
  Memory / Checkpoint / Artifact

Isolation & Governance
  Capability / Environment / Observability / Policy / Budget

这些组件共同提供通用运行语义，而不是某个领域的业务逻辑。同一套 AgentOS 可以应用到不同的业务领域，比如软件研发、客户支持或者研究协作；不同系统之间的区别来自 Agent Definition、领域系统和 Capabilities，而不应该来自修改 AgentOS 内核中的流程代码。它们如何协作，可以从一次完整的 Agent 执行过程来看。

4.4 从 Event 到 Converged

一次完整的 AgentOS 运行过程可以表示为：

1. 领域状态发生变化并产生 Event
2. Event Kernel 持久化变化并投递给相关 Agent
3. Scheduler 恢复逻辑 Agent，并创建或分配 AVM
4. Context Assembler 装配 Agent Definition、Event、Memory 与 Capabilities
5. AVM 运行一个决策步，返回 Action 或 Converged
6. Action 经过权限校验后，由 Tool / MCP Gateway 执行
7. Tool Result 写回 Context，必要时保存 Checkpoint，再进入下一决策步
8. Agent 返回 Converged 或等待外部结果，AgentOS 持久化状态并挂起 AVM

Agent 的行动会改变 Git、Issue、CI、数据库或者其他领域系统，并进一步产生 Event。这些 Event 又可能唤醒其他 Agent 或人类，于是多个局部执行形成行动级联。

Domain State
    │ changes
    ▼
  Event ──▶ AgentOS ──▶ AVM ──▶ Action
    ▲                              │
    └──────── new changes ◀────────┘

整个系统不需要一个“全局收敛引擎”来判断所有工作是否结束。每个 Agent 只判断自己的局部责任是否收敛；当相关 Agent 都不再产生行动时，系统自然进入暂时稳定状态。新的 Event 到达后，这个状态又会被打破。

这就是 AgentOS 与世界收敛模型之间的关系：AgentOS 不把“世界”实现成一个模块，而是提供一套运行时，使拥有局部感知和局部责任的 Agent 能够被可靠地唤醒、行动、协作和暂停。

5. AgentOS 的确定性底座

AgentOS 的价值不只在于启动一个 AVM。真正困难的是让大量 Agent 在长期运行中仍然具有连续性、安全性和可治理性。

一次演示可以把 Agent Definition、用户输入和几个 Tool 一起放进模型上下文，然后等待结果。但一套真实软件需要面对 Event 重复投递、模型超时、工具执行到一半失败、上下文超过窗口、多个 Agent 竞争资源、代码访问不可信网络，以及系统运行几个月后 Memory 持续增长等问题。

这些问题不能依靠 Agent 的自然语言推理解决。它们属于运行时基础设施，必须由 AgentOS 提供确定性保证。

确定性底座并不是把 Agent 重新限制在固定流程中。面对相同 Context，LLM 仍然可能形成不同判断；开放推理的价值，恰恰在于行动路径不需要被提前压缩成唯一控制流。AgentOS 要做的，是让这种概率性只存在于理解和决策中，而所有外部副作用都必须经过确定性接口：

Probabilistic Reasoning
        ↓
Structured Action
        ↓
Schema Validation
        ↓
Capability & Policy Check
        ↓
Transactional Domain Operation
        ↓
Auditable State Change

这形成了 Agent 与系统之间最关键的职责划分：Agent 决定在当前情境中应该尝试什么，系统保证什么是被允许的，以及行动如何可靠发生。权限、事务、幂等、资源限制、数据约束和合规规则不能只写进 Agent Definition，期待模型每次都正确遵守，而必须由下面这些运行时基础设施强制执行。

5.1 Event Kernel 与 Scheduler

Event 是 Agent 被唤醒的主要入口，因此它首先需要成为一种可靠的持久化记录，而不只是进程内的一条消息。

一个 Event 通常需要包含：

唯一标识、类型和发生时间；
来源主体与关联领域对象；
因果关系和 Trace；
可见范围与权限标签；
优先级、过期时间和投递状态；
用于幂等处理的业务标识。

Event Kernel 负责接收变化、持久化、筛选潜在接收者和保证投递。面对网络与进程故障，工程上通常无法同时获得简单、低成本且严格的 exactly-once 语义，因此由 Event 触发的 Tool Call 和领域写入需要围绕幂等性设计：重复收到同一变化，不应该产生重复提交、重复发布或重复扣款。

Scheduler 则负责运行时层面的秩序：优先处理生产事故还是低优先级整理任务，一个 Agent 可以占用多少模型预算，多少 AVM 可以并发运行，等待外部 Tool Result 时是否释放资源，以及怎样避免某个繁忙 Agent 饿死其他 Agent。

这些都是资源决策，不是业务决策。Scheduler 可以因为预算不足暂停 Developer Agent，却不应该因为“开发完成”而决定下一步必须执行 Review Agent。

5.2 Context 与 Memory

Context 和 Memory 经常被混为一谈，但它们解决的是两个不同问题。

Context 是一次 AVM 执行可以直接看到的有限信息。它包含当前 Event、正在进行的工作、必要的领域状态、相关 Memory 片段、可用能力的描述，以及最近的 Tool Result。Context 必须受到模型窗口、注意力和成本限制。

Memory 是跨越多次执行持续存在的信息基础设施。它不应该被整体塞进 Prompt，而应该在需要时检索、压缩和组合成 Context。

AgentOS 至少需要处理几类不同的 Memory：

Working Memory：当前任务的目标、假设、进度与待办；
Episodic Memory：过去发生过什么，包括成功、失败和关键决策；
Semantic Memory：从经历和资料中抽取出的稳定事实与概念；
Procedural Memory：完成某类工作通常采用的方法和步骤；
Project Memory：多个 Agent 和人类可以共享的项目知识；
Private Memory：只对特定 Agent 或权限主体开放的信息。

Memory Service 不能只是一个向量数据库。它还需要处理：

信息何时写入、由谁写入；
如何检索与当前责任真正相关的内容；
多条记忆冲突时如何合并；
哪些内容需要压缩、遗忘或者重新确认；
每条记忆的来源、时间、置信度和适用范围；
Agent、项目和组织之间的访问控制；
模型、Embedding 和存储结构升级后的迁移。

特别是 Procedural Memory，它记录的是“这类事情通常怎样完成”。最初它可能只是一段自然语言经验；当这种方法被反复验证并趋于稳定后，就有机会进一步结晶为可执行的 JIT Artifact（将在后续章节介绍）。

5.3 Tool、MCP 与 Capability

Tool 是 Agent 感知和改变外部状态的基本接口，MCP 则可以作为发现和连接外部能力的标准协议。但仅仅把一份 Tool 列表交给模型并不够，AgentOS 还需要一个完整的 Capability System。

Capability 描述的不只是“系统里有这个 Tool”，而是某个 Agent 在特定执行中是否被允许使用它：

Capability
  = Tool
  + Identity
  + Scope
  + Permission
  + Environment
  + Policy

同一个 Git Tool，对不同 Agent 可以表现为完全不同的能力。Review Agent 可能只能读取代码并提交 Review Comment；Developer Agent 可以修改自己的工作分支；Release Agent 可以创建 Tag，但只有在人类批准后才能写入受保护分支。

Tool Gateway 需要在模型之外强制执行这些限制，并区分读取与写入能力：

输入输出必须具有明确 Schema；
凭证按执行范围临时注入，不进入 Prompt；
权限在调用时重新检查，不能只依赖 Agent Definition 中的文字；
高风险操作可以要求更强隔离或人类授权；
每次调用都记录调用者、参数、结果和外部副作用；
超时、部分成功和重试必须具有明确语义。

AgentOS 也不必把所有能力一次性写进 Context。它可以根据 Agent 的身份、当前任务和能力作用域，提供分层发现与按需加载。但这种能力检索只是为了控制上下文规模，不应该演变成替 Agent 选择业务行动的机制。

5.4 Environment 与 Sandbox

AVM 是自然语言程序的语义执行环境，但 Agent 调用的能力可能需要真正运行代码、访问文件系统、安装依赖甚至连接网络。这些操作需要另一个更底层的隔离环境。

Environment Service 可以提供统一的生命周期：

create environment
  ↓
mount inputs and working files
  ↓
inject scoped credentials and network policy
  ↓
execute tool
  ↓
collect logs and artifacts
  ↓
snapshot, suspend or destroy

它需要管理：

文件系统与进程隔离；
CPU、内存、磁盘和执行时间配额；
网络出口和允许访问的域名；
Secret 的短期注入与自动回收；
依赖缓存、构建缓存和制品存储；
Snapshot、失败现场与调试信息；
环境过期后的清理。

底层隔离技术可以根据风险选择，而不应该写死在 Agent 的定义中：

风险级别	可选环境
低风险、只读操作	轻量进程或普通 Container
常规代码执行	Container + gVisor
不可信代码或多租户	Kata Containers 或 Firecracker
高权限生产操作	独立强隔离环境 + 人类授权

AgentOS 应该先定义 Environment 抽象，再根据部署条件选择 Container、gVisor、Kata Containers 或 Firecracker。这样 AVM 与 Agent Definition 只依赖统一能力语义，不需要感知底层隔离实现。

5.5 Checkpoint、Artifact 与 Recovery

Agent 的一次工作可能持续数小时甚至数天，中间等待 CI、等待其他 Agent、等待人类确认，或者遭遇模型与基础设施故障。把它当成一次不可中断的模型请求显然不可行。

AgentOS 需要在关键边界持久化 Checkpoint：当前目标、已经完成的行动、待处理 Event、Tool Call 状态、相关 Artifact 和下一步意图。恢复时，AVM 不需要回放全部聊天历史，而是从结构化状态和必要 Memory 中重建有限 Context。

Tool Call 也需要具有可恢复语义。AgentOS 必须区分：

调用尚未发出；
调用已经发出但结果未知；
调用已经成功但结果尚未写入 Context；
调用失败且可以安全重试；
调用产生了部分副作用，需要补偿或人工处理。

代码、报告、构建产物、测试结果和生成脚本不应该只存在于模型输出中。它们应当作为具有版本、来源和权限的 Artifact 保存，并能够被其他 Agent、人类和后续执行引用。

5.6 Observability、Evaluation 与 Governance

传统服务可以通过请求日志、指标和 Trace 观察行为；Agent 系统还需要回答“它为什么这样做”。但这不等于无限期保存完整思维过程，而是记录足以重建决策上下文的可审计信息：使用了哪个 Agent Definition 和模型，看到了哪些来源，调用了什么能力，产生了什么副作用，以及最终为什么宣布收敛。

AgentOS 的治理层需要覆盖：

模型与 Tool 的调用成本；
单个 Agent、项目和组织的预算；
成功率、返工率、人工升级率和收敛时间；
越权调用、策略拒绝和异常副作用；
Agent Definition、Memory 和 JIT Artifact 的版本变化；
线上行为的回放、评估、回归测试与审计。

这些基础设施构成了 AI Native 软件的确定性底座。Agent 可以在上面处理开放问题，但运行时必须保证：一个概率性决策不会变成不可追踪、不可恢复且权限无限的外部行动。

传统 LLM 应用经常评估一次输入是否得到了正确输出。持续运行的 Agent 则需要更接近真实岗位的评估方式：它是否及时发现了与自己相关的变化，是否获取了足够信息，是否选择了合理能力，是否留下可验证结果，是否在错误状态下宣布收敛，以及是否把超出权限的问题交给了正确的人。

因此 Agent 评估至少包含：

Decision Quality：判断与行动是否合理；
Outcome Quality：领域状态是否向目标改善；
Convergence Quality：何时继续、等待、升级或收敛是否合理；
Boundary Compliance：是否遵守权限、策略和资源限制；
Recovery Quality：工具失败或环境变化后能否恢复；
Collaboration Quality：是否向其他 Agent 或人类提供了足够、准确的信息；
Cost and Latency：是否以合理成本完成责任。

执行 Trace、领域结果和人类反馈共同构成评估数据。它们不仅用于发现问题，也会反过来改善 Agent Definition、Memory、Capability、JIT Artifact 和 Application UI。

6. JIT 与 Application UI：软件的两次结晶

确定性底座使 Agent 能够安全、连续地处理开放问题，但如果每一次机器行动都重新经过 LLM 推理，每一次人机交流都重新通过自然语言表达，系统仍然会昂贵、缓慢且容易产生歧义。

AI Native 软件可以从真实运行中识别两类逐渐稳定的 Hot Path：机器侧反复出现且已经固定的多步工作，以及人类侧反复发生的信息交换。前者可以结晶为 Agent 调用的 JIT Tool，后者可以结晶为人类使用的 Application UI。它们都来自运行经验，也都只优化行动与交互，不接管主体的业务判断。

6.1 JIT：把固定的多步工作结晶为程序

假设 Developer Agent 需要反复完成同一套代码变更验证。在系统还没有直接提供这项能力时，每一个 Tool Result 都会返回 Agent，再由 LLM 判断下一步应该调用什么。第一次探索这套方法时，这种开放推理是有价值的；但当整套工作的控制结构已经固定，并且成功运行了几百次，继续让 LLM 在每一步之间重复判断就变成了浪费。

JVM 会观察程序的运行，在发现频繁执行的 Hot Path 后，将它编译为更高效的机器码。AgentOS 也可以引入类似的 Just-In-Time（JIT）结晶机制：观察 Agent 的执行轨迹，识别其中反复出现且控制结构已经固定的多步工作，再将整段工作改写为一段可执行程序。

JIT 结晶的不是仍然需要开放判断的业务决策，而是一段已经不再需要 LLM 逐步选择下一项动作的工作。每次输入和结果可以不同，但步骤、顺序、分支和失败语义必须已经稳定到足以由确定性程序表达。Agent 仍然判断何时需要完成这项工作；一旦决定调用，JIT 程序便直接完成整串动作。

多轮 LLM 判断与 Tool Call
            ↓
固定的步骤、顺序与失败处理
            ↓
Node / Python JIT Artifact
            ↓
作为一个 Tool 提供给 Agent

这个类比成立在“观察运行、识别 Hot Path、生成并管理可执行产物”。JIT 保留 Agent 作为行动主体，同时把一段固定工作中的多轮模型调用和 Tool 往返压缩为一次 Tool Call：

LLM 负责探索未知路径，JIT 负责固化已经稳定的路径。

6.1.1 JIT Artifact 以 Tool 形式进入 Capability 体系

这里需要区分三个概念：AgentOS 把生成的代码、测试和管理元数据称为 JIT Artifact；Artifact 对 Agent 暴露的结构化调用接口是 Tool；这个 Tool 被授予某个 Agent 后，才成为该 Agent 当前可以使用的 Capability。

JIT Artifact 经过验证后，会以 Tool 的形式注册到 Capability 体系，并在后续执行中注入给相关 Agent/AVM。对于 Agent 来说，它只是多了一个可以调用的新 Tool，并不存在另一套 JIT 执行路径：

Event
  ↓
AgentOS 唤醒 Agent
  ↓
AVM 解释 Agent Definition
  ↓
Agent 根据 Context、Memory 与 Capabilities 作出判断
  ↓
选择调用一个 Tool
  ↓
Tool 由人工实现或 JIT Artifact 实现
  ↓
一次执行完成整段工作，并把结果返回 Agent
  ↓
继续行动或判断收敛

Agent 需要理解当前问题，判断这个 Tool 是否适用，并主动调用。AgentOS 负责观察、结晶、验证、注册和管理 JIT Artifact；具体行动仍由 Agent 决定。

JIT 优化的是一次任务中原本需要多轮 LLM 推理和 Tool Call 才能完成的固定工作，将它压缩为一个具有明确输入输出的 Tool Call。Agent 仍然负责理解任务以及决定何时使用这项能力。

6.1.2 结晶过程

JIT Artifact 的生成在后台进行，产物进入统一的 Capability 体系：

Agent Execution Traces
          ↓
识别反复出现的操作结构
          ↓
判断输入、输出、控制结构和前置条件是否稳定
          ↓
生成 Node / Python 程序与测试
          ↓
在隔离环境中验证行为、权限和资源消耗
          ↓
注册为有作用域的 JIT Tool
          ↓
作为 Capability 注入相关 Agent

AgentOS 的 JIT Manager 可以承担：

从执行 Trace 和 Procedural Memory 中发现高频操作；
聚类相似的调用序列，区分偶然重复与固定工作；
推导结构化输入、输出和适用前置条件；
生成代码、测试和失败处理；
在 Sandbox 中使用历史样本与边界样本验证；
限制 Artifact 可使用的 Tool、网络和文件范围；
管理版本、作用域、有效期、指标和失效条件；
在长期稳定后，将产物产品化为正式 Tool 或领域服务。

这是一条后台的“能力生产线”，而不是前台的业务执行路径。

6.1.3 JIT Artifact 是受管理的 Tool 实现

一份 JIT Artifact 不能只是一段临时脚本。作为 Tool 背后的可执行实现，它至少应该带有：

输入与输出 Schema；
适用的 Agent、项目和任务范围；
前置条件和运行时 Guard；
所需 Capability 与最小权限；
来源 Trace 与生成依据；
源代码、运行时和依赖版本；
测试、验证样本和已知限制；
版本、有效期与失效规则；
超时、错误和部分副作用语义；
执行指标、调用记录与回退说明。

Agent 决定调用对应的 Tool 后，Tool Gateway 检查当前输入与环境是否满足 JIT Artifact 声明的 Guard。检查失败或执行出错时，错误会像普通 Tool Error 一样返回 Agent；Agent 可以重新观察状态，拆开步骤完成、选择其他 Tool，或者请求人类处理。

6.1.4 JIT 不是 Cache

Cache 复用的是答案：相同输入直接返回曾经计算过的相同输出。

JIT 复用的是已经固定的工作过程：面对不同输入，执行同一段程序并产生新的输出。

Cache
  same input ──▶ stored output

JIT Tool
  new input ──▶ fixed multi-step program ──▶ new output

以代码变更验证为例。某个项目已经形成一套固定规则：准备隔离环境，恢复锁定版本的依赖，依次运行 Lint、类型检查和单元测试；任何一步失败便停止后续测试，并把失败阶段、日志与退出状态写入统一报告。在 JIT 结晶之前，这些动作可能由 Developer Agent 一步步推动：

Agent 判断 → prepare_test_environment
Tool Result 返回 Agent
Agent 判断 → restore_dependencies
Tool Result 返回 Agent
Agent 判断 → run_lint
Tool Result 返回 Agent
Agent 判断 → run_typecheck
Tool Result 返回 Agent
Agent 判断 → run_unit_tests
Tool Result 返回 Agent
Agent 判断 → collect_validation_report

每个动作本身都是确定性的，但“收到结果后再决定调用下一个 Tool”仍然消耗一次 LLM 执行。AgentOS 观察到整条路径已经反复以相同步骤运行后，可以生成并验证一个 JIT Artifact，再把它暴露为 validate_change Tool：

Agent 判断 → validate_change({ ref }) → ValidationReport

validate_change 内部：
prepare environment
  → restore dependencies
  → lint
  → typecheck
  → unit tests
  → collect report

以后 Developer Agent 仍然需要判断当前变更是否应该执行这套验证，但不再需要在每个步骤之间重新推理。一旦选择调用，整个固定工作便在一次 Tool Call 中完成；最终报告或者结构化错误再返回 Agent，由它决定接下来修复问题、改用其他能力，还是请求人类处理。

6.1.5 什么应该被结晶

适合 JIT 的过程通常具有几个特征：

已经在不同输入上反复成功；
输入与输出可以结构化；
步骤、顺序、分支与失败处理已经固定；
执行过程中不再需要 LLM 判断下一步动作；
结果可以通过测试或规则验证；
外部副作用清晰并可以限制；
失败后可以安全地交还给 Agent。

“固定”并不要求每次输入和输出完全相同，而是要求控制结构已经可以由程序独立执行。参数、文件和测试结果可以变化，但程序不需要在每一步重新询问 LLM 接下来该调用什么。如果内部仍然依靠 LLM 选择下一项 Tool，那么它只是被封装起来的 Agent 执行，而不是 JIT 结晶出的程序。

不适合 JIT 的则是仍然依赖开放判断的工作：模糊需求澄清、新架构设计、复杂利益权衡、首次出现的故障诊断、高风险授权，以及任何无法建立可靠验证标准的决策。

结晶过早会把尚未理解清楚的经验变成错误代码。AgentOS 因此不仅要识别重复次数，还要判断这项工作的控制结构是否真正固定，并持续观察 JIT Artifact 的成功率、输入分布和外部依赖。一旦环境变化使它不再可靠，就应该停止注入或者使其失效。

6.1.6 从经验到基础设施

JIT Artifact 最初是临时的、局部的。它可能只对某个 Agent、某个项目或某个版本的代码库有效。AgentOS 管理它的生命周期，并根据实际使用逐渐提升其地位：

Execution Experience
  ↓
Procedural Memory
  ↓
JIT Artifact（临时 Tool 实现）
  ↓
Productized Tool / Domain Service

这条路径让 AI Native 软件拥有一种传统软件没有的形成方式：开发者不必在系统运行前准确识别并实现每一段可复用逻辑，Agent 可以先用自然语言和现有能力探索；当某种方法在真实运行中变得稳定后，系统再把它结晶成程序。

但无论产物处于哪一层，它都只是 Agent 所调用能力的实现，而不是 AgentOS 的业务控制流：

AgentOS 把 Agent 反复执行并已经固定的多步工作结晶为新的能力，再交还给 Agent 使用。

机器侧反复出现且已经固定的多步工作可以结晶为 JIT Tool。沿着同样的思路，人类与 Agent 之间反复出现的稳定交流，也可以结晶为一种更精确的交互形式——Application UI。

6.2 人类同构与 Application UI

一套 AI Native 软件不会只包含 AI Agent。需求中的价值判断、架构中的取舍、安全与发布授权，以及大量未被组织知识覆盖的异常，都需要人类参与。

传统系统通常把这件事称为 Human in the Loop：软件流程运行到某个预先设计好的节点，暂停下来等待人类输入，然后继续执行。这种说法默认软件 Workflow 才是主体，人类只是被插入其中的特殊环节。

世界收敛模型提供了另一种理解：人类和 AI Agent 都是拥有身份、责任、感知和行动能力的 Actor。二者在系统中的结构是同构的，只是推理与交互的实现方式不同。

AI Actor
  = Agent Identity + Agent Definition + AVM(LLM)

Human Actor
  = Human Virtual Agent + Interaction Channel + Human

AI Agent 通过 AVM 获得 Context，使用 LLM 进行判断，通过 Tool 改变领域状态。人类通过通知、页面、Git、IM、Email 或其他渠道感知状态，使用大脑作出判断，再通过这些渠道采取行动。

AI：
Event / Tool Observation
  → Context
  → AVM + LLM
  → Tool Call
  → Domain State

Human：
Notification / Active Inspection
  → Human Perception
  → Human Reasoning
  → UI / Channel Action
  → Domain State

系统不需要把人类建模成一个能够运行 LLM 的伪 Agent。它只需要为真实的人建立一个 Human Virtual Agent：人类在数字系统中的身份与责任投影。

Human Virtual Agent 可以拥有：

身份、团队与责任范围；
能够接收的 Event 和待处理事项；
可以感知的领域状态；
可以执行的 Capability 与授权级别；
正在参与的任务和历史决策；
等待其判断、审批或补充的信息。

它没有 AVM，也不需要 LLM。真实人类的大脑就是它的推理引擎。AgentOS 需要做的，是把相关变化送达合适的渠道，并让人类的行动以与其他 Agent 相同的身份、权限和审计语义进入领域系统。

因此，人类不是全局流程中的一个 human_approval 节点，而是一个持续承担责任的主体。Tech Lead 可以主动发现架构风险，Security Reviewer 可以在没有人显式请求时检查高风险变更，Product Owner 也可以在任何阶段改变需求。这些行动会像 AI Agent 的行动一样改变领域状态，并产生新的 Event。

6.2.1 没有 Application UI，软件也可以运行

使用 AgentOS 构建一套软件，并不意味着必须同时开发一套专用 Application UI。

以自动化软件研发系统为例，Git、Issue Tracker、CI、IM、Email、CLI 和文件本身已经提供了足够丰富的感知与行动渠道：

人类通过 Issue 提交需求；
Agent 通过 Git 读取和修改代码；
人类通过 PR Comment 提出意见；
Agent 通过 CI 获取测试结果；
Agent 通过 IM 请求 Tech Lead 作出判断；
人类通过 Email 或命令批准一次发布。

只要 Agent Definition、领域系统、Tool、Event 和人类渠道已经建立，整个系统就可以完成从需求到交付的流转。它已经是一套软件，而不是一个等待 UI 才能成立的后端。

这给 AI Native 软件带来了一个很重要的起点：

系统可以先以 Headless 形态运行，通过现有的通用渠道让 Agent 和人类共同工作。

Application UI 因此不是系统成立的必要条件，而是系统运行之后可以继续形成的一层交互优化。

6.2.2 为什么仍然需要 Application UI

如果自然语言已经能够表达任何意图，为什么还要构建 UI？

公交车上的乘客本来可以在到站前喊一声“司机，我下一站下车”。这足以传递信息，也确实能够工作。但后来公交车增加了下车按钮：乘客按下按钮，司机看到统一信号，系统明确记录有人准备下车。

按钮并没有创造一种新的业务能力。公交车仍然执行同一件事，但“下一站下车”这个反复出现的意图，被编码成了一种更简单、精确、低歧义的交互。

人类之间也是如此。我们可以用语言讨论一套架构，但在黑板上画出组件、连接和边界，往往能够更快地传递结构信息。图形不是因为语言无法表达，而是因为它为特定信息提供了更高带宽、更低歧义的编码方式。

Application UI 的价值与此相同：

UI 把反复出现的人机交流，结晶为更精确的状态表达和意图输入。

例如，人类当然可以在 IM 中说“这个方案我同意，但数据库变更要延后”。但一个 Approval Panel 可以把同样的意图表达为：批准代码方案、拒绝数据库迁移、附加原因、限定有效版本。它减少了 Agent 对自然语言的猜测，也让权限、审计和后续 Event 更加明确。

6.2.3 UI 不只是 Chat，也不只是 Event Feed

人类与 Agent 一样，不仅通过 Event 感知世界。

通知、Inbox 和 Timeline 可以告诉人类发生了什么变化；但人类也需要主动读取当前状态：打开代码 Diff，搜索历史决策，检查测试日志，查看架构图，比较两份方案，或者浏览当前环境中的 Artifact。

因此，一套 Application UI 通常同时承载三类交互：

被动感知：通知、Inbox、状态变化和待处理事项；
主动感知：页面、搜索、Diff、日志、报告、图表和领域对象；
行动表达：批准、拒绝、编辑、评论、上传、执行和委派。

Chat 适合表达开放意图，却不适合承载所有信息。让人类在聊天记录里寻找一个测试失败、用自然语言描述代码行差异，或者每次都输入完整发布参数，都会降低沟通效率和准确性。

UI 可以被形式化为：

Application UI
  = Human-readable State Projection
  + Typed Intent and Action Interface

它一边把复杂领域状态投影成人类容易理解的形式，一边把人类的意图转换成结构化领域命令（Command）、Capability Call 或领域状态变更。

6.2.4 UI 关注交互，而不是逻辑

Application UI 不应该拥有 Agent 调度、责任流转、收敛判断或领域规则。否则系统会再次把真正的软件逻辑藏进页面按钮和前端状态机中。

同一个“批准发布”行为，可以来自 Application UI、Git Comment、IM、Email、CLI，也可以来自具有相应权限的 AI Agent。不同渠道最终都应该映射到同一个结构化 Command 和 Capability：

Application UI ─┐
Git / IM        ├─▶ approve_release(command) ─▶ Domain State ─▶ Event
Email / CLI     ┤
AI Tool Call  ──┘

权限、业务规则、状态变更和审计属于 Capability 与领域系统。UI 只负责让人类更高效地理解状态、表达意图和触发能力。

一个简单的检验方法是：

如果移除 Application UI，只保留其他合法渠道，系统的核心业务语义是否仍然成立？

如果答案是否定的，往往意味着业务逻辑已经泄漏到了 UI。如果答案是肯定的，而 UI 让高频操作更清晰、更快速、更不容易出错，那么它就在做正确的事情。

6.2.5 UI 应该从真实交互中生长

传统软件经常在真实流程尚未发生前，就试图设计完整的菜单、页面和操作路径。AI Native 软件可以先通过自然语言和通用渠道运行，再观察人类与 Agent 的真实交流：

哪些状态总是需要人类反复询问；
哪些信息在文字中很难准确表达；
哪些参数经常遗漏或产生歧义；
哪些授权需要更明确的风险提示；
哪些操作被不同人反复以相同方式完成。

这些 Interaction Hot Path 可以逐渐结晶为专用界面：

反复询问当前进度
  → Status View

反复在消息中粘贴代码片段
  → Diff Viewer

反复确认发布范围与风险
  → Release Approval Panel

反复用文字描述组件关系
  → Architecture Canvas

反复澄清需求字段
  → Structured Requirement Editor

由此可以得到与 JIT 对称的两条结晶路径：

机器侧已固定的工作 Hot Path
  → JIT Tool

人类侧的交互 Hot Path
  → Application UI

JIT 把已经固定的多步工作变成 Agent 可以一次调用完成的 Tool；Application UI 把已经稳定的信息交换方式变成人类可使用的交互。两者都不会取代主体的判断，而是减少重复表达和执行的成本。

7. 如何设计 AI Native 软件

传统软件设计通常从功能列表、数据模型、页面和 Workflow 开始。AI Native 软件需要换一个起点：先找出系统中持续承担责任的主体，以及它们能够感知和改变的领域状态。

7.1 定义领域事实，而不是复制 World

首先确定哪些系统拥有真实状态，以及哪些不变量必须由确定性代码保证。

在软件研发领域，Git 保存代码与版本历史，Issue Tracker 保存需求和任务，CI 保存构建与测试结果，Artifact Store 保存制品，部署平台保存运行状态。AgentOS 不复制这些事实，只通过 Tool、MCP 和 Event 把它们暴露给拥有权限的 Actor。

这个阶段需要明确：

每类状态的唯一事实来源；
可以执行的 Command 与状态转换；
哪些操作必须是事务性的；
哪些变化会产生 Event；
哪些规则无论 Agent 如何判断都不能违反。

7.2 从责任划分 Agent 和人类

不要先画“第一步、第二步、第三步”的流程图，而是问：哪些结果需要有人长期负责？

一个好的责任边界应该让 Actor 能够独立判断自己的局部收敛。例如 Developer Agent 负责可维护、可验证的代码变更；Review Agent 负责发现实现中的正确性和可维护性问题；Product Owner 负责需求价值和范围取舍。

责任划分既包括 AI Agent，也包括 Human Virtual Agent。一个判断应该由谁承担，取决于能力、风险、授权和组织责任，而不是为了满足某种固定的“人类审批比例”。

7.3 编写 Agent Definition 与收敛条件

为每个 AI Agent 编写身份、责任、原则、策略、Event Interests、Capabilities 和 Convergence Conditions。

重点不是罗列操作步骤，而是让 Agent 能在新的情境中回答：

这件事是否属于我；
我还缺少什么信息；
我可以采取哪些行动；
什么情况必须与其他 Actor 协作；
什么情况必须停止或升级；
到什么状态，我的当前责任才算收敛。

收敛条件应该描述结果，而不是描述必须经过的流程。相比“依次执行单元测试、集成测试，然后发送完成消息”，更合适的定义是“相关变更已经被验证，没有仍由你负责的失败或未处理反馈”。

7.4 设计 Capability，而不是业务编排

接下来提供 Agent 完成责任所需的确定性能力。每个 Capability 都应该拥有结构化输入输出、最小权限、明确副作用、失败语义和审计记录。

如果一个过程已经完全确定，可以把它实现成 Tool 或 Workflow，但把是否调用它的判断留给 Agent。AgentOS 只负责能力注入和运行时治理，不在基础设施中编写业务流转规则。

这个阶段也需要明确读取与写入边界。Agent 可以拥有广泛的只读感知能力，但对修改代码、操作生产、发送外部消息和使用敏感数据设置更严格的作用域与授权。

7.5 建立 Memory 与 Environment

根据责任设计 Memory，而不是无差别保存全部对话。确定哪些工作状态需要 Checkpoint，哪些经验属于 Agent 私有，哪些知识应当项目共享，哪些流程经验有机会进一步结晶。

同时为代码与 Tool 执行定义 Environment：代码和输入如何提供，能够访问哪些网络和 Secret，资源如何限制，Artifact 如何收集，失败现场如何保留，任务结束后如何清理。

7.6 先让系统 Headless 运行

在专用 UI 和大量优化出现之前，先让 Agent 通过 Git、Issue、IM、Email、CLI、API 等现有渠道与领域系统和人类协作。

Headless 运行可以尽早验证最重要的问题：责任是否清晰，Agent 是否能够获得足够状态，Capability 是否完整，收敛是否合理，人类能否在任意阶段自然介入，以及系统是否在没有中心编排器时仍能向前推进。

如果这些问题尚未解决，提前构建复杂 UI 只会把不成熟的流程固化下来。

7.7 观察、评估并逐步结晶

系统运行后，持续观察 Agent 的行为和人类的交互：

Agent 在哪里频繁返工或错误收敛；
哪些 Tool 缺失或权限边界不合理；
哪些经验应该进入 Memory；
哪些多步机器操作已经固定到不再需要逐步推理；
哪些人机交流已经成为稳定 Interaction Hot Path。

然后有选择地结晶：

未知问题
  → Agent + Natural Language

重复且固定的多步工作
  → JIT Tool

重复且稳定的人机交流
  → Application UI

长期稳定的领域能力
  → Tool / Domain Service

AgentOS 构建的软件不是永远停留在概率性自然语言中，也不是在第一天就把所有流程固化为代码。它允许系统从开放结构开始，根据真实运行逐渐形成更确定、更快速、更低成本的部分。

这可以概括为一种不同的软件形成方式：

传统软件先固化，再运行；AI Native 软件先运行，在运行中识别稳定结构，再逐步固化。

下一步，我们可以把这套方法放进一个具体系统：如果要构建一套自动化软件研发系统，Agent、AgentOS、JIT、Application UI 和人类团队将如何共同工作？

8. 示例：自动化软件研发系统

假设我们要构建一套持续运行的自动化软件研发系统。它不是一个接收需求、生成一次代码然后退出的 Coding Agent，而是一支由 AI Agent 和人类共同组成的长期研发团队。

这套系统需要持续处理需求澄清、架构设计、代码实现、Review、测试、安全检查、发布和线上反馈。现实中的研发工作不会严格沿着一条流水线前进：架构设计可能暴露需求问题，测试可能要求重新设计接口，线上指标可能让已经完成的需求再次进入开发，紧急修复也可能跳过常规优先级。

如果我们试图提前画出所有节点和分支，最终只会得到另一个越来越复杂的研发 Workflow。AgentOS 的目标，是让不同 Actor 根据各自责任和真实领域状态推动系统前进。

8.1 领域系统保存事实

首先不创建任何“研发世界状态”，而是确认真实信息由谁保存：

领域事实	事实来源
需求、缺陷与验收条件	Issue Tracker
代码、分支、Commit 与 PR	Git Repository
构建、测试与扫描结果	CI System
Package、Binary 与报告	Artifact Store
环境、部署与版本	Deployment Platform
日志、指标与告警	Observability Platform
讨论、通知与人工回复	Git、IM、Email 等 Channel

这些系统通过 Tool 和 MCP 暴露读取与写入能力，并在 Issue 创建、PR 更新、CI 完成、部署结束或告警触发时产生 Event。Event 只说明发生了什么变化；Agent 被唤醒后，再根据需要读取完整 Issue、代码 Diff、测试日志、部署状态和历史决策。这些可感知状态共同构成概念上的 World。

8.2 AI Agent 与人类责任

系统可以包含以下 AI Agent：

AI Agent	持续责任
Product Agent	澄清需求、维护范围与验收条件
Architect Agent	维护架构一致性，识别跨系统影响与技术约束
Developer Agent	实现可维护、可验证的代码变更
Review Agent	检查正确性、可读性、兼容性和潜在缺陷
Test Agent	设计和执行验证，定位测试失败与覆盖缺口
Security Agent	识别依赖、权限、数据和供应链风险
Release Agent	判断版本是否具备发布条件并执行获准发布
SRE Agent	观察线上运行状态，处理告警和回归问题

人类也以对等 Actor 的形式参与：

Human Virtual Agent	持续责任
Product Owner	产品价值、范围优先级和模糊需求的最终取舍
Tech Lead	高影响架构决策与长期技术方向
Human Developer	处理 Agent 能力之外的实现与调试问题
Security Reviewer	高风险权限、数据和合规判断
Release Approver	关键环境和高风险版本的发布授权

这些角色不是一张固定流程图中的节点。Product Owner 可以在实现阶段修改需求，Security Agent 可以在依赖变化时主动介入，SRE Agent 可以根据线上告警重新唤醒 Developer Agent。谁在什么时候行动，由领域变化是否影响其责任决定。

8.3 Capability、Memory 与隔离环境

每个 Actor 只能获得完成责任所需的能力。

Developer Agent 可以读取 Issue 和仓库，在获准的代码环境中修改文件、运行命令和创建 PR，但不能直接写入受保护分支或发布生产版本。Review Agent 可以读取代码、测试和架构规范，并提交 Review，却不能悄悄修改被审代码。Release Agent 可以执行部署 Tool，但生产环境能力需要发布策略或 Release Approver 授权。

代码和 Tool 在限定网络、Secret、资源和生命周期的 Sandbox 中执行。任务产生的 Commit、日志、报告与 Artifact 被持久化，执行环境则在收敛后 Snapshot 或清理。

Memory 维持长期连续性：Working Memory 保存当前假设和进度，Episodic Memory 提供类似改动的成败经验，Semantic 与 Project Memory 保存架构和团队知识，Procedural Memory 保存已经验证的方法，Private Memory 隔离敏感信息。Context Assembler 只选取当前判断需要的片段，而不是把所有 Memory 放进模型。

8.4 一个需求如何进入系统

假设 Product Owner 在 Issue Tracker 中提交了一个需求：

为现有 CLI 增加离线任务队列；网络恢复后自动同步，并且不能破坏旧版插件接口。

issue.created Event 可能被投递给 Product Agent、Architect Agent 和其他关注新需求的 Actor。但收到 Event 不代表它们必须做出相同反应。

Product Agent 读取 Issue、产品说明和用户反馈，发现“自动同步”没有定义冲突处理方式，于是询问 Product Owner：离线期间同一任务在其他设备被修改时，应该以哪一方为准？此时它没有可以继续自行决定的事情，AgentOS 保存 Checkpoint 并挂起 AVM。

Architect Agent 则并行检查 CLI 架构、插件接口和同步服务，先记录本地存储与插件事件语义的约束。Product Owner 回复“保留两份修改并提示用户选择”后，新的 Event 同时唤醒两个 Agent：Product Agent 更新验收条件并收敛，Architect Agent 继续设计本地队列、同步协议和兼容层。

这里没有 wait Product Agent → run Architect Agent 的编排。两个 Agent 各自在无法继续时等待领域状态变化；人类回复也不是“完成审批节点”，而是责任主体补充只有自己能够决定的信息。

8.5 从架构到代码

Architect Agent 把方案写入 Architecture Decision Record 并关联 Issue。Tech Lead 因持续负责高影响架构决策而收到通知，可以通过 Git 或后来形成的 Architecture Canvas 查看组件、数据流、备选方案和风险。如果他要求本地存储加密，这条评论会同时影响 Architect、Security 和 Developer Agent：前两者更新方案与密钥要求，Developer Agent 则在约束足够明确后进入获准的代码环境并开始实现。

Developer Agent 的执行可能包括：

读取 Issue、ADR 和仓库规范
  ↓
检查 CLI、同步服务和插件 API 的当前实现
  ↓
修改本地队列与同步逻辑
  ↓
添加迁移和兼容性处理
  ↓
运行受影响测试
  ↓
创建 PR 并关联需求与 ADR

这些步骤不是 AgentOS 中预先写好的流程。Developer Agent 可以根据仓库结构、测试失败和实现发现增加调查、修改方案，甚至把问题重新交给 Product Owner 或 Architect Agent。例如旧插件在网络恢复时重复接收事件，就会让 Architect Agent 因 Issue 或 ADR 更新而重新进入非收敛态。

8.6 Review、Test 与 Security 的并行收敛

PR 创建后，pull_request.opened Event 会唤醒可能相关的 Review、Test 和 Security Agent。它们根据不同责任读取不同状态：

Review Agent 读取代码 Diff、Issue、ADR、仓库规范和已有 CI 结果；
Test Agent 读取验收条件、改动范围和历史回归，补充离线、恢复、冲突和旧插件兼容测试；
Security Agent 关注本地队列中的敏感数据、加密方式、密钥权限和依赖变化。

三者可以并行，也可以根据彼此产生的新状态调整判断。假设 Test Agent 发现同步中断后会重复上传任务，便把失败样本、日志和复现步骤写入 CI Report。Developer Agent 因 ci.completed 重新进入非收敛态，修复幂等问题并推送 Commit；新的 pull_request.synchronize 又让相关 Agent 检查受影响部分。领域状态记录代码、反馈和验证结果，不需要“打回重做”节点或流程引擎维护循环次数。

最终可能形成：

Review Agent    → 没有未处理的正确性问题 → Converged
Test Agent      → 验收与回归检查通过     → Converged
Security Agent  → 风险已处理或获准接受   → Converged
Developer Agent → 没有仍由自己负责的反馈 → Converged

这不是一个全局 all_checks_passed 收敛判定。Git 与 CI 可以提供确定性的 Merge Policy，但各个 Agent 是否还有工作，仍然是局部判断。新的反馈、代码变化或策略更新随时可以打破当前收敛。

8.7 发布与线上反馈

代码满足 Merge Policy 并进入目标分支后，Release Agent 会读取变更范围、Artifact、测试与安全结果、目标环境和发布策略。低风险内部版本可以直接调用发布 Workflow；涉及数据格式迁移、权限变化或关键客户时，Capability Policy 要求 Release Approver 授权。无论人类通过 Email、CLI 还是 Application UI 批准，最终都调用同一个 approve_release Capability。

获得授权后，Release Agent 执行确定性部署 Workflow。SRE Agent 随后通过指标与告警持续承担线上责任；如果旧插件错误率上升，新的 Event 会再次唤醒 SRE、Developer 和 Security Agent。需求、实现、发布和运行不是一条走完即销毁的流程，而是由持续存在的责任主体共同维护的系统。

8.8 系统如何逐步长出程序与 UI

这套系统可以从 Headless 形态开始，再根据真实运行逐渐形成专用程序和界面：

阶段一：AgentOS + Git / Issue / CI / IM / Email / CLI
  先验证责任、能力和收敛是否成立

阶段二：固定的多步工作 → JIT Artifact → Tool
  例如 validate_change、prepare_release_evidence

阶段三：人类交互 Hot Path → Application UI
  例如 Requirement Editor、Architecture Canvas、Change View、Approval Panel

JIT Artifact 在 Sandbox 中生成和验证，再以 Tool 的形式注册到 Capability 体系并注入相关 Agent；Agent 仍然判断何时调用。Application UI 则把领域信息投影给人类，并把操作转换成已有的 Command 与 Capability Call；它不决定下一个 Agent，也不维护研发流程状态。

因此，系统会同时发生两种演进：固定的机器工作逐渐结晶为程序，人类交流逐渐结晶为 UI。长期稳定的 JIT Artifact 还可以继续产品化为正式 Tool 或领域服务。

8.9 这套系统为什么是 AI Native

这套自动化研发系统并不是因为使用了很多 Agent 就成为 AI Native，而是因为它的主体逻辑不再由一张全局 Workflow 定义。

传统研发自动化：
预定义流程调用 Product / Code / Review LLM 智能函数

AI Native 研发系统：
持续存在的 Actor 根据领域状态承担责任并选择行动

AgentOS 固定 Event、AVM、Memory、Capability、Sandbox、Checkpoint 和治理语义；Git、CI、部署平台等确定性系统固定领域规则；具体某个需求如何澄清、实现、验证和发布，则由 Agent 和人类在运行时共同决定。它能处理未被预先枚举的情况，不是因为没有规则，而是因为规则不再被写成封闭的行动路径：

领域系统定义什么是允许发生的，Agent 与人类判断此刻应该让什么发生。

这就是在 AgentOS 之上构建软件的完整形态：自然语言程序承担开放责任，确定性能力守住外部边界，多个 Actor 通过领域状态和 Event 协作，再把固定工作与稳定交互逐步结晶为程序和 UI。

9. 从传统软件渐进迁移

AI Native 不需要以重写整个系统为起点。传统软件中已经稳定的数据库、服务、Workflow、权限和 UI 都是有价值的确定性资产。迁移的目标不是把每个函数换成 Agent，而是把真正需要开放判断的责任，从封闭控制流中逐步释放出来。

9.1 先识别 Function 与 Agent 的边界

一个简单原则是：

方法已知、输入输出稳定、结果可验证
  → Function / Tool / Workflow

目标明确、路径开放、需要持续感知和判断
  → Agent

Schema 校验、既定构建流程、测试执行和事务提交本身，应由确定性的 Function、Tool 或 Workflow 完成。Agent 可以判断何时调用这些能力以及如何处理结果，但不需要通过 LLM 逐步执行其中已经确定的逻辑。需求澄清、故障调查、架构取舍和跨系统协调则很难被完整写成固定函数。

不要因为 LLM 能够完成一个任务，就把它变成 Agent；也不要因为一段逻辑目前由代码实现，就拒绝重新审视它是否其实在模拟开放的人类判断。

9.2 把稳定能力从控制流中分离

迁移的第一步通常不是创建 Agent，而是整理现有软件边界：把数据库操作、领域命令、外部 API 和稳定 Workflow 封装成具有 Schema、权限和审计语义的 Capability。

过去这些能力可能只能被某个页面或内部流程调用。将它们从控制流中分离后，人类、传统程序和 Agent 都可以通过同一接口使用：

Existing UI ─────┐
Legacy Workflow ─┼─▶ Typed Capability ─▶ Domain System
Agent Tool Call ─┘

这一步本身不会让系统变成 AI Native，却建立了最重要的确定性边界，也避免 Agent 只能通过模拟点击 UI 操作系统。

9.3 从 Shadow Mode 逐步开放行动

选择一个具有开放输入、需要频繁人工判断，但外部行动范围可以被清楚限制的责任。例如：

分析 CI 失败并提出修复方案；
对新 Issue 进行澄清和影响分析；
汇总发布证据并识别风险；
调查线上告警并生成可验证诊断。

先让 Agent 在只读或 Shadow Mode 下工作：它感知真实 Event、读取真实状态并给出判断，但不直接产生外部副作用。将结果与人类实际决策比较，完善 Agent Definition、Context、Memory 和评估集。

表现稳定后，再逐步授予创建草稿、添加内部评论、在 Sandbox 中修改代码和运行测试等可恢复、低风险能力。高风险行动继续要求更强的 Policy、Sandbox 或人类授权。

Read Only
  ↓
Draft / Suggestion
  ↓
Reversible Action in Sandbox
  ↓
Scoped Domain Write
  ↓
High-risk Action with Human Authorization

迁移不是从“没有自主性”一次跳到“完全自主”，而是逐渐扩大 Agent 可以可靠承担的责任和副作用范围。

9.4 用 Event 和责任替换局部编排

当单个 Agent 已经能够长期承担责任后，可以把一部分原有业务编排改为领域 Event 和局部收敛。

例如，旧系统可能在 CI 失败后按固定顺序执行分类 LLM、重试脚本和人工通知。迁移后，CI 只需要记录真实失败并产生 Event；Developer Agent、Test Agent 或 SRE Agent 根据责任读取状态并决定行动。

不必一次删除全部 Workflow。可以先让 Workflow 继续执行确定部分，把无法穷举的异常和判断交给 Agent；随着责任边界稳定，再减少中心编排器拥有的业务决策。

9.5 建立长期运行能力

从一次性 Agent 调用走向 AgentOS，需要逐步补齐：

持久化 Agent Identity 与 Definition；
Event Inbox、幂等与因果追踪；
Context、Memory 与 Checkpoint；
Capability、凭证与环境隔离；
模型、Tool 和预算治理；
执行 Trace、评估与恢复；
AI Agent 和 Human Virtual Agent 的统一身份与责任模型。

只有当 Agent 可以跨越多次唤醒保持身份、记忆和未完成责任时，它才从一个 LLM 智能函数变成真正持续存在的 Actor。

9.6 在运行中结晶，而不是提前重建一切

系统稳定运行后，再根据实际 Trace 和交互决定哪些部分应该固化：

重复且固定的多步工作结晶为 JIT Artifact，并以 Tool 形式提供给 Agent；
经过长期验证的 JIT Artifact 产品化为正式 Tool 或领域服务；
重复的人机交流结晶为 Application UI；
仍然开放且不断变化的问题继续交给 Agent。

这种方式避免迁移项目变成一次规模庞大的“AI 重写”。新的 Agent Runtime 与旧系统可以长期共存，传统代码继续承担稳定规律，LLM 智能函数继续完成局部智能计算，Agent 则负责那些真正需要运行时判断的开放责任。

10. 写在最后

回到最初的问题，AI Native 软件与传统 AI 软件的分界，从来不在于使用了多少模型、工具或所谓的 Agent，而在于谁拥有业务行动的控制权。

Agent 不再是被软件调用的函数，而成为承担责任、感知状态和选择行动的主体；传统软件则成为 Agent 可以调用、但不能违反的能力与规则。

当控制关系发生倒转，LLM 便不再等同于 Agent。它只是 AVM 内部可替换的执行引擎；AgentOS 也不是新的中心编排器，而是负责执行、资源与边界的运行时。业务判断留给 Agent，外部世界的规律仍由确定性代码守住：Agent 决定应该做什么，系统保证什么可以做，以及行动如何可靠发生。

这也意味着，软件不必在运行之前固化所有可能的路径。未知问题可以先由 Agent 使用自然语言探索；已经固定的多步工作可以结晶为 JIT Tool；反复出现的人机交流可以生长为 Application UI；长期稳定的规律则继续沉淀为 Tool 和领域服务。代码、Workflow 和 UI 没有消失，只是不再需要先于真实世界完整地存在。

传统软件先固化，再运行；AI Native 软件先运行，在运行中识别稳定结构，再逐步固化。

但这仍然只是工程层面的变化。软件原本就是人类对现实世界运行方式的抽象：我们把事物写成状态，把规律写成代码，把变化写成流程。过去，机器只能沿着这些预先刻画的路径行动，因此这种模仿虽然精确，却也僵硬。

归根结底，我们的软件不过是对自然运行方式的一种拙劣模仿。AgentOS 并没有改变这一点，但它让这种模仿不再那么呆板，而是更加灵活，也更加贴近自然的本质。