摘要

随着大语言模型从对话生成器演化为能够调用工具、操作环境并持续执行任务的智能体，Agent 系统的研究重点正在从“单个模型能否完成任务”转向“多个异构模型能否在长期环境中共享状态、接续执行并接受统一治理”。现有工作已经在 reasoning-and-acting、工具使用、多智能体协作、长期记忆、Agent-Computer Interface 与基准评测等方向取得显著进展，但对任务身份是否独立于模型存在、模型更换后执行连续性如何保持、现实世界状态如何被验证、权限与算力如何统一调度等系统层问题，仍缺少足够明确的操作化框架。本文提出一套面向长期 Agent 系统的五层成熟度模型，将系统划分为 L1 对话中心型智能、L2 能力中心型工具智能、L3 状态中心型共享 Agent 基础设施、L4 治理中心型 Agent Operating System，以及 L5 自适应自主认知基础设施。

在此基础上，本文提出三个核心概念。第一，Agent Portability Vector，将 Agent 可迁移性分解为能力、状态、身份、策略与证据五个维度，用以说明 MCP 等协议主要提高 Capability Portability，却不能自动保证完整的 Agent Portability。第二，Handoff Integrity，用于刻画执行主体或模型切换后关键任务状态的保真程度。第三，“非确定性执行者—确定性治理外壳”原则，即把大语言模型视为高能力但非确定性的语义执行器，将身份、权限、任务状态、执行权、证据、幂等、Production Finality 与恢复语义外置到确定性 Control Plane 中。

本文采用设计科学与参与式单案例研究相结合的方法，以 LMN516 长期 AI 基础设施为案例。2026 年 9 月 14 日的实时控制平面快照显示，该系统已持久化 1428 个语义问题对象、935 个执行尝试、1829 个 Intake Receipt、10 个 Worker 与 64 条 Production Reconciliation 记录；数据库中还存在 Intake、Execution Authority、Worker Binding、Run Check-in、Production Finality 与 Reconciliation 等控制函数，代码仓库则存在统一 MCP Gateway、OAuth 与 bearer 校验相关的持续演化记录。案例表明，LMN516 已满足 L3 的核心进入条件，即关键任务状态不再主要依赖单一聊天上下文而存在；但跨 ChatGPT、GitHub Copilot 与本地模型的无转录接力尚未完成稳定、重复的端到端验证，统一身份、统一权限、Compute Fabric 与系统级调度仍未完全形成。因此，本文将其主要分类为 L3，并以七维工程量表给出约 3.2 的辅助诊断值，而不将该数值解释为经过统计验证的客观测量。

关键词： 大语言模型智能体；Agent OS；MCP；Control Plane；模型可迁移性；多智能体；本地模型；自主计算；LMN516

Abstract

As large language models evolve from conversational generators into agents capable of tool use, environmental interaction, and long-horizon execution, the central engineering question is shifting from whether a model can complete an isolated task to whether heterogeneous models can share state, hand off execution, and operate under a common governance framework over time. This paper proposes a five-level maturity model for persistent agent systems: L1 Conversation-Centric Intelligence, L2 Capability-Centric Tool Intelligence, L3 State-Centric Shared Agent Infrastructure, L4 Governance-Centric Agent Operating System, and L5 Adaptive Autonomous Cognitive Infrastructure. Three operational concepts are introduced: an Agent Portability Vector covering capability, state, identity, policy, and evidence portability; Handoff Integrity for measuring state fidelity across executor replacement; and a deterministic governance envelope around nondeterministic language-model executors.

Using a design-science and participatory single-case methodology, the framework is applied to LMN516, a long-running personal agent infrastructure integrating persistent control state, MCP, cloud and local models, repository automation, production governance, and heterogeneous compute nodes. A live snapshot on 14 September 2026 contained 1,428 semantic question objects, 935 execution attempts, 1,829 intake receipts, 10 workers, and 64 production reconciliation records. The case satisfies the entry criteria for L3 because critical task identity and execution state persist independently of a single conversation. However, transcript-free handoff among ChatGPT, GitHub Copilot, and local models has not yet been repeatedly validated end-to-end, while unified identity, permission, scheduling, and compute abstraction remain incomplete. LMN516 is therefore classified primarily as L3, with an auxiliary engineering diagnostic estimate of approximately 3.2.

Keywords: LLM agents; agent operating system; Model Context Protocol; control plane; agent portability; multi-agent systems; local language models; autonomous computing

1 引言

大语言模型 Agent 的发展通常被描述为能力扩张史：模型先获得更强的推理能力，随后学会调用搜索、数据库、代码执行、浏览器、操作系统与外部 API，并进一步进入多智能体协作与长期记忆场景。ReAct 将 reasoning 与 acting 置于统一执行轨迹中[1]，Toolformer 展示了模型学习工具调用时机与参数的可能性[2]，AutoGen 将多 Agent 对话抽象为复杂应用的构造机制[3]，Generative Agents、MemGPT 等工作则分别从长期经验与上下文虚拟化角度探索持续状态[4-5]。与此同时，AgentBench、GAIA 与 SWE-agent 等工作开始在真实或近真实交互环境中评价 Agent 的执行能力[6-8]。这些研究共同表明，现代语言模型已经不再只是文本生成器，而是逐步成为能够观察、决策和改变环境的执行主体。

然而，“模型能做什么”与“系统是否成熟”并不是同一个问题。一个模型即使能够访问 GitHub、数据库、Shell、Browser、MCP Server 与真实 GUI，如果当前任务是什么、谁正在执行、上一次做到哪里、现实环境究竟处于什么状态、当前 Agent 是否拥有执行某项操作的权限等关键信息仍主要存在于会话上下文中，那么系统的连续性仍然依赖于具体模型和具体会话。模型一旦更换，系统就可能出现任务身份丢失、重复执行、状态分叉或错误闭环。本文因此提出一个不同于常见 Agent Benchmark 的问题：一个长期运行的 AI 系统在什么条件下开始成为独立于具体模型而存在的基础设施？

这一问题本质上把 Agent 研究带入了传统系统软件领域。长期 Agent 不仅需要推理和工具调用，还需要处理身份、执行权、幂等、并发、部分失败、事实一致性、事件顺序、权限、调度与恢复。Autonomic Computing 早已提出 self-configuration、self-optimization、self-healing 与 self-protection 的愿景[11]；Saltzer 和 Schroeder 的保护原则强调最小权限等安全边界[13]；Lamport 对分布式系统事件排序的经典讨论则揭示了异步系统中“最后到达的消息并不必然代表最新事实”的根本问题[14]。大语言模型 Agent 的特殊性在于，它们是一类语义能力很强、却具有非确定性的执行主体，因此传统系统里的许多控制责任不能继续隐含在执行器内部，而必须被显式外置。

本文的目标不是建立一个行业通用的等级标准，也不是用单一案例证明某种架构必然优于其他方案，而是提出一个可被反驳、可被后续系统修正和复用的工程分析框架。围绕这一目标，本文给出五层 Agent 系统成熟度模型，提出 Agent Portability、Handoff Integrity 与“非确定性执行者—确定性治理外壳”三个核心概念，并利用 LMN516 的真实长期演化作为参与式单案例，讨论一个个人级系统如何从 Tool-Using AI 逐步转向共享 Agent 基础设施，以及其距离 Agent OS 仍存在的关键鸿沟。

2 相关工作与研究缺口

2.1 工具调用、MCP 与 Capability Portability

ReAct 和 Toolformer 所代表的工作解决了一个基础问题：模型如何从封闭的参数知识走向外部环境，并在推理过程中主动使用外部能力[1-2]。这类范式改变了语言模型的角色，使其从 predictor 逐渐变成 actor。MCP 进一步把这一能力层标准化，其 Host-Client-Server 架构允许不同 Server 暴露 Tools、Resources 与 Prompts，并通过协议化接口降低不同 AI Host 与外部系统之间的耦合[15]。从软件工程角度看，这相当于给 Agent 建立了一套能力接口层，使不同模型或客户端能够复用相同服务。

但 Capability Interface 的统一并不能自动生成 Shared Agent State。假设 ChatGPT 与 Copilot 都可以通过同一个 MCP Server 调用 deploy()，这只说明二者拥有相似能力，并不说明它们知道自己是否在处理同一个长期问题，也不说明它们共享同一个执行身份、同一套权限边界与同一份 Production 事实。由此，本文把 MCP 主要解决的问题称为 Capability Portability，而把“模型更换以后仍然保持任务世界连续”称为 Agent Portability；两者相关，但不能互相替代。

2.2 多智能体、长期记忆与状态外置

AutoGen 展示了多个可定制 Agent 通过对话、代码和工具协同完成复杂任务的能力[3]；Generative Agents 通过经验记录、反思与检索支持持续行为[4]；MemGPT 则借鉴传统操作系统的分层存储思想，对有限 Context Window 进行虚拟化管理[5]。这些工作共同说明，长期行为不能完全依赖单次上下文。然而，长期 Memory 与权威事实状态仍然必须区分：一个向量数据库可以帮助 Agent 记住“过去发生过什么”，却不能证明 Production 此刻运行的真实版本；一段持久化文字可以记录“某任务已经完成”，却不能替代真实环境中的验收与健康检查。

因此，本文主张把 Memory 与 Evidence/Truth 分离。Memory 服务于语义恢复和推理，Evidence 则负责对现实状态提供可验证依据；当二者冲突时，权威观测必须具有更高优先级。这一区分对长期 Agent 系统尤其重要，因为模型很容易把历史判断、计划或先前假设误当成当前事实。

2.3 Agent 评测与系统层评价缺口

AgentBench 在操作系统、数据库、知识图谱和网页等多个环境评价 Agent 能力[6]，GAIA 强调真实问题中的多步骤推理、工具调用与可验证答案[7]，SWE-agent 则表明 Agent-Computer Interface 的设计会显著改变软件工程任务表现[8]。这些工作主要回答“Agent 能否完成任务”，而本文进一步关注：当模型切换、会话中断、节点失败或多个执行者并发时，系统是否仍然能够维持同一个任务世界。

这类问题与传统 Benchmark 的差异在于，单次成功不足以证明长期可持续性。一个 Agent 可以在某一回合正确部署应用，却仍可能在下一回合忘记自己已经部署；两个 Agent 都可能各自完成正确动作，却因为缺乏共享身份和执行权而产生双写。本文因此把长期系统成熟度从“能力成功率”扩展到“状态连续性与治理完整性”。

3 理论框架

3.1 模型中心系统与系统中心 AI

本文把长期任务运行所必需的关键状态集合记为 K，其中至少包含语义任务身份、目标、约束、执行状态、执行权、证据、依赖关系与 Production Truth。为了描述系统对具体模型的依赖程度，可以定义一个概念性模型依赖率 D_model：

D_model = |仅存在于模型或会话上下文中的关键状态|
          --------------------------------------
                      |K|

D_model 不是统计量表，而是一种工程检查方法。模型中心系统中，大量状态隐式存在于 Context Window；系统中心 AI 中，关键状态被持久化到外部控制平面，不同模型只作为读取和更新这些状态的执行者。由此，本文提出第一个核心判断：Agent 系统成熟度的关键分界，不在于模型连接了多少工具，而在于关键状态是否已经从模型内部迁移到系统外部。

3.2 Agent Portability Vector

为避免把“不同模型都能调用相同工具”误认为“Agent 已经可迁移”，本文将 Agent Portability 表示为五维向量 Π_agent=(κ,σ,ι,π,ε)。其中 κ 表示 Capability Portability，即能力接口能否被不同模型复用；σ 表示 State Portability，即任务与执行状态能否被恢复；ι 表示 Identity Portability，即执行主体是否拥有稳定可识别身份；π 表示 Policy Portability，即权限和策略是否独立于具体 Host；ε 表示 Evidence Portability，即现实事实与验收证据是否可以被不同 Agent 共享。

如果需要一个保守的标量描述完整可迁移性，可以取 P_full=min(κ,σ,ι,π,ε)。这种定义强调最短板效应：某个 MCP Server 可能使 κ 很高，但如果新模型找不到同一个 Q，则 σ 仍然很低；如果本地模型不知道自己是否拥有 Production 权限，则 π 仍然不足；如果不同客户端读取到的事实来源不一致，则 ε 会成为接力瓶颈。因此，MCP 可以显著改善能力互操作，却不会自动完成 Agent Portability。

3.3 Semantic Identity 与 Q/RUN 分离

长期系统中的任务连续性需要一个稳定的语义身份。用户可能在不同时间、不同入口用不同措辞描述同一问题，例如“网站不稳定”“后台又 500 了”“为什么这个问题还出现”，如果每句话都机械创建新任务，系统会把一个长期问题拆成多个孤立对象。本文因此主张 Relation-first Intake：新输入首先判断与既有语义对象的关系，再决定是创建新 Question、链接既有 Question、附加 Evidence，还是忽略无持久价值的信息。

与此同时，长期问题与一次执行尝试必须被分离。本文把 Q 定义为持续存在的语义问题或目标，把 RUN 定义为一次具体执行尝试。一个 Q 可以经历多个 RUN：某次失败、某次中断、某次完成验证但尚未进入 Production、某次最终通过真实验收。Q/RUN 分离避免了“这次执行失败”等价于“整个问题失败”的语义混淆，也使执行权、Worker Binding、Lease、审计与恢复拥有稳定锚点。

3.4 Handoff Integrity

模型可替换性的核心不是“新模型可以读取数据库”，而是“新模型能否准确恢复任务”。本文提出 Handoff Integrity 指标 H。设交接时必须恢复的关键状态为 j=1...n，每一项恢复准确度为 rj∈[0,1]，权重为 wj，则 H=Σ(w_j×r_j)/Σw_j。关键状态至少包括语义身份、当前目标、约束、已完成工作、剩余工作、证据、权限和依赖关系。

H=1 表示无损恢复，H 越低则说明模型切换后越依赖人工重新解释。本文暂以 H≥0.90 作为成熟 L3 的工程建议阈值，同时明确该阈值尚未通过跨系统大样本统计验证；它的作用是给工程实验提供一个明确起点，而不是构成自然科学意义上的普遍常数。

3.5 Memory、Evidence 与 Truth

长期 Agent 系统需要 Memory，但 Memory 不能拥有最高事实优先级。本文建议至少区分 Personal Memory、Operational State、Historical Event、Observed Evidence 与 Authoritative Truth Source，并采用“权威观测 > 已验证运行证据 > 持久任务状态 > 检索记忆 > 模型假设”的事实优先序。这样，当模型记忆“Production 应该是版本 A”，而真实 Runtime Probe 显示版本 B 时，系统必须选择 B。

这一区分揭示了许多所谓 Agent Memory 设计的潜在问题：语义相似度无法替代状态权威。Vector Retrieval 可以回答“过去可能发生过什么”，却不能承担事务数据库、部署真相源或执行租约的职责。将这些角色混合，会使系统在长期运行中不断把“记得”误当成“事实”。

3.6 非确定性执行者—确定性治理外壳

本文把 LLM Agent 定义为一种 nondeterministic semantic executor。它擅长 reasoning、planning、interpretation、generation 与 uncertainty resolution，但不适合单独承担 transaction log、execution lease、idempotency、permission database、production truth、state machine 与 audit trail。对于一个非确定性执行主体，可靠性不能仅靠“让模型更聪明”获得，而需要一个确定性治理外壳。

该外壳至少应包括 Identity、Policy、Task State、Execution Authority、Idempotency、Evidence、Finality 与 Recovery。其目标不是削弱 Agent，而是把模型真正擅长的语义推理与系统必须确定执行的职责分离。本文认为，这一分离是从 L2/L3 走向 Agent OS 的核心架构原则。

4 五层 Agent 系统成熟度模型

本文据此提出五层模型。L1 为 Conversation-Centric Intelligence，会话近似运行状态，任务连续性高度依赖 Context Window；L2 为 Capability-Centric Tool Intelligence，模型通过 Function Calling、Browser、Shell、MCP 等获得执行能力，但 Shared Tools 尚未形成 Shared State；L3 为 State-Centric Shared Agent Infrastructure，语义任务身份、执行尝试、证据与部分治理状态已经外置到共享 Control Plane，不同模型可以围绕同一个长期任务世界工作；L4 为 Governance-Centric Agent Operating System，系统开始统一管理身份、权限、调度、事件、模型路由、Compute Registry、Worker Runtime、Memory、Evidence、Audit 与 Recovery；L5 为 Adaptive Autonomous Cognitive Infrastructure，在 L4 的治理基础上加入持续评价、动态模型选择、动态算力分配、自恢复、长期目标与有界自治。

这五层之间的关键差异不是功能数量，而是“系统承担了多少持续性责任”。L1 的状态中心是 Conversation，L2 的中心是 Model+Tools，L3 的中心变成 Shared State，L4 的中心进一步转向 Governance，L5 则在治理基础上形成闭环自适应。由此可得一个重要推论：一个拥有上千个 Tool 的系统仍可能只是 L2，而一个模型参数较小的本地 Agent，如果接入了成熟的身份、任务、证据和调度体系，也可以成为 L4 系统中的合法执行节点。

5 研究方法

本文采用设计科学与参与式单案例研究结合的方法。L1-L5 模型、Agent Portability Vector 与 Handoff Integrity 属于设计科学意义上的概念性产物，其目标不是通过大样本拟合得出统计规律，而是为工程系统提供可操作、可验证和可反驳的分析工具。案例部分则选择 LMN516，一个长期运行、持续修改的真实个人 Agent 基础设施；研究者同时参与系统分析、任务编排、故障排查与结构设计，因此能够获得比纯黑盒观察更细的证据，但也必然带来参与式研究的正向偏差。

为降低这种偏差，本文只把数据库、代码仓库或真实 Runtime 能支持的内容计为已实现能力，设计意图但未通过真实环境验证的部分统一标记为“部分实现”或“待验证”。证据来源包括持久化 Control Plane 状态、数据库控制函数、GitHub 仓库演化记录以及运行架构事实。本文使用的快照时间为 2026 年 9 月 14 日，由于系统处于高频演化中，所有数量型指标均只代表该时间点。

6 LMN516 单案例分析

6.1 从个人网站到共享控制平面

LMN516 最初可以被理解为个人网站与内容系统，但长期演化后已经包含前台与后台应用、GitHub 自动化、Supabase/PostgreSQL、MCP Gateway、Control Tower、Q/RUN/Worker、Production Reconciliation、本地与云端模型、多台本地设备与 VPS、自建 Production、GUI 自动化及微信入口。此时“网站”逐渐只承担 Interface 角色，真正决定系统连续性的部分开始转移到后端控制状态与运行基础设施。

2026 年 9 月 14 日的实时快照显示，LMN516 Control Plane 中存在 1428 个 control_question、935 个 control_run、1829 个 control_intake_receipt、10 个 control_worker 与 64 条 control_production_reconciliation。这些数字不能直接证明任务质量，因为数量大并不等于语义归一正确，但它们证明了关键任务对象已经独立于单一聊天上下文持久存在。数据库中同时存在 Intake Envelope、Run Registration、Run Check-in、Execution Authority、Worker Binding、Production Finality 与 Production Reconciliation 等控制函数，这意味着控制逻辑已经不再只是聊天提示词中的约定，而开始被实现为系统行为。

6.2 MCP Gateway 与 Capability Layer

代码仓库的提交记录显示，LMN516 已经经历统一 MCP Gateway、MCP OAuth、公网元数据地址、access token 以及 bearer 校验等多轮实现与修复。这些演化说明 Capability Layer 已经从临时的工具连接转向长期接口治理。尤其是统一 Gateway 的出现，使 ChatGPT、Copilot 或未来本地 Agent 理论上可以复用同一能力表面，而不必分别绑定底层数据库、部署逻辑与业务接口。

然而，本文不把“已经存在 MCP”视为 L3 的充分条件。真正支持 L3 判断的是 MCP 后面的 Control State：如果不同模型只能调用相同工具，却无法恢复同一个 Q、同一个执行历史与同一份 Evidence，那么系统仍然主要是 L2。LMN516 的特殊之处在于，它已经同时拥有能力层与持久控制层，因此开始跨过这一边界。

6.3 Production Finality 与现实状态

LMN516 当前一个重要治理原则是 commit != complete、main != production、production deployment != acceptance。这条原则看似只是部署规范，实际上解决了 Agent 系统中极其常见的认知偏差：模型倾向于把“命令返回成功”当成“目标已经完成”，而真实系统可能出现代码已进入 main 但 Production 仍是旧版本、Deployment 返回 success 但真实页面仍然 500、服务已经启动但切流失败等情况。

因此，LMN516 把 Implementation、Verification、Git Landing、Production Deployment、Runtime Observation、Real Acceptance 与 Reconciliation 看成不同阶段。Production Reconciliation 的意义并不是记录一个部署日志，而是明确告诉 Agent：系统内部动作成功并不自动代表外部世界状态成功。可以将这一原则概括为 Command success ≠ World-state success，它也是 Evidence Plane 必须独立于 Memory 和计划状态存在的原因。

6.4 本地模型与 Compute Ownership

LMN516 已经把本地模型引入多设备环境。本文认为，本地模型最重要的系统意义并不是降低 API 成本，而是 Compute Ownership：云端模型本质上是外部租赁计算资源，而本地模型可以成为长期在线、可观测、可控制的内部 Compute Asset。只有当模型被抽象成资源，而不是“某台电脑上打开的一个聊天程序”时，系统才有可能进一步形成真正的 Compute Fabric。

理想情况下，上层任务不再指定“去 Mac mini 跑”或“去 M4 跑”，而只声明 capability、privacy、latency、memory、priority 等需求，由 Scheduler 根据 Node Registry、当前负载与策略选择实际执行节点。LMN516 已经拥有异构设备、节点角色与本地模型，但尚未完全达到这种资源抽象，因此其 Compute Fabric 只能评价为部分形成。

7 LMN516 成熟度评估

本文首先按 L1-L5 的必要条件进行主要分类，再使用七维工程量表作为辅助诊断。七个维度分别为 Capability Interoperability、Semantic State Persistence、Identity & Authority、Evidence & Finality、Handoff Integrity、Compute Abstraction 与 Autonomous Recovery。根据当前证据，本文分别给出 3.4、3.8、3.1、3.7、2.7、2.6 与 3.1 的工程诊断值，等权平均约为 3.2。这里的小数只用于表达同一层级内部的不均衡，不具有统计学尺度意义。

正式分类仍应写成 L3：State-Centric Shared Agent Infrastructure。它之所以不是 L2，是因为语义任务、执行尝试、Worker、Execution Authority、Production Finality 与 Reconciliation 已经成为独立于单一模型的持久系统对象；它之所以还不是 L4，是因为 ChatGPT、Copilot 与本地模型尚未被证明可以在没有转录历史的条件下稳定接续同一任务，统一 Identity、Capability、Scheduler、Event Bus 与 Compute Registry 也没有全部闭环。换言之，当前 LMN516 的核心不平衡是 control-plane maturity > cross-model execution uniformity：控制面走在前面，执行客户端仍在追赶。

8 Cross-Model Continuity Test：成熟 L3 的可验证实验

为了把“模型可替换”从口号转化为可验收条件，本文提出 Cross-Model Continuity Test（CMCT）。实验第一阶段由 ChatGPT 创建或链接真实任务 Q-X，并产生 RUN-A，完成部分工作后写入 Evidence 与 Remaining Work；第二阶段关闭原会话，不向 Copilot 粘贴历史记录，只给出“继续当前 LMN516 主线任务”，要求 Copilot 自行通过 Mainline、Q-X、RUN-A 历史与 Evidence 恢复任务，并创建新的合法执行尝试 RUN-B，而不是复活已终止 RUN；第三阶段由本地模型仅依赖共享系统状态回答该任务为什么存在、已经完成什么、谁执行过、哪些事实已验证、什么仍未完成，并在权限允许时继续低风险子任务；第四阶段重新进入一个新的 ChatGPT 会话，要求其在不读取原始聊天的条件下重构完整执行链。

成熟 L3 的建议验收条件包括：Handoff Integrity≥0.90、Duplicate Q rate=0、Duplicate active RUN=0、Unauthorized execution=0、Evidence divergence=0、Production truth mismatch=0。当前 LMN516 尚未完成该实验的多轮稳定验收，因此本文把跨模型接力描述为“结构上已经接近可验证”，而不是“已经证明完成”。这种负面结论很重要，因为如果论文把设计能力误写成已验收能力，就会重新犯本文试图批判的错误：把系统内部意图误当成现实世界事实。

9 从 L3 到 L4：Agent OS 的真正含义

如果 L3 的关键词是 Shared State，那么 L4 的关键词应是 Resource Governance。L4 不是增加更多 MCP Tool，而是让系统自己管理多个 Agent：Identity Service 区分 human-owner、ChatGPT session、Copilot worker、本地模型节点、Scheduler 与后台 Worker；Capability/Policy 决定不同 Actor 在不同环境、Q 与 RUN 上可以执行什么动作；Scheduler 和 Event Bus 把运行从 User Prompt 驱动转向 Event→Policy→Dispatch；Model Router 与 Compute Registry 负责在本地模型、云端模型和不同节点之间进行资源匹配；Audit、Budget 与 Recovery 则保证长期运行不会因为非确定性计划而失控。

这种结构与传统操作系统存在有用的概念映射。Process 可以类比 Agent/Worker，PID 可以类比 RUN Identity，User 可以类比 Actor Identity，Permission 可以类比 Capability，CPU 可以类比 Model/Compute，Syscall 可以类比 Tool/MCP Call，System Log 可以类比 Event/Audit，而 Kernel Policy 则可类比 Control Plane。二者并不等价，但这个映射揭示了多 Agent 系统一旦长期运行后为什么会自然遭遇操作系统和分布式系统问题：真正困难的部分不再是“还能增加什么功能”，而是“谁拥有资源、谁能执行、状态是否一致、失败后如何恢复”。

10 一致性、并发与自治风险

进入 L4 后，主要风险会从能力不足转向一致性错误。幂等要求同一事件被重复消费时不能造成双重副作用；并发要求两个 Agent 不能同时声称拥有同一个 RUN；Stale State 要求关键动作前重新读取权威状态，因为“正确推理 + 过期输入”仍会得到错误操作；Partial Failure 则要求系统知道一次 build→transfer→start→switch→verify 链路究竟停在哪一步，而不能只记录一个模糊的 FAILED。Lamport 关于分布式事件顺序的分析[14]在这里重新出现：不同 Agent 和节点的消息到达顺序不能简单等价为事实发生顺序。

更重要的是，自主系统的风险具有放大效应。单个模型错误回答一次通常影响有限，但一个错误判断如果被自动执行、自动重试并通过多个 Worker 扩散，风险会迅速放大。因此成熟 Agent OS 的目标不是“尽可能自动”，而是“在可观察、可回滚、幂等、权限明确和失败边界可控的条件下尽可能自动”。低风险、可验证、可撤销任务适合本地模型长期自治；Production 权限、删除数据、认证和安全变更则必须保留更严格的 Policy Gate 或人类确认。

11 从 L4 到 L5：自适应自主认知基础设施

本文并不把 L5 等同于 AGI。L5 指的是一种系统行为：在 L4 已经提供身份、权限、调度、事件、证据和恢复的基础上，系统能够持续 Observe、Evaluate、Decide、Dispatch、Act、Verify，并根据结果 Adjust。它不仅会自动执行，还会判断自己的模型路由、资源分配和恢复策略是否有效，从而形成持续评价闭环。

例如，本地模型负责 Evidence Extraction 后，系统可以持续统计 precision、recall、uncertainty、latency 与 cost；如果 Recall 下降，高风险样本自动升级到强模型，而低风险样本继续使用本地模型。如果某个节点长期高负载，后台低优先级任务自动延后；如果节点离线，Recovery Policy 依次尝试确定性修复路径，再进行故障转移。这里的关键不是让 LLM 临场“想办法”，而是让 LLM 参与 Diagnosis 和 Planning，同时让 Recovery Policy、权限边界与最终验证保持确定性。

从这个角度看，L5 并不要求出现一个无所不能的超级模型。它更可能来自大量可靠小机制的组合：强 Control Plane、多模型路由、本地与云端 Compute Fabric、持续 Evaluation、严格 Policy 与人类最终 Authority。模型仍然重要，但模型逐渐变成可替换的计算资源，而不是系统本身。

12 与 Autonomic Computing 的关系

LMN516 的演化与 Autonomic Computing 的经典愿景存在明显对应，但 LLM Agent 引入了新的复杂性。传统自治计算主要关注系统如何 self-configure、self-optimize、self-heal 与 self-protect[11-12]；LLM Agent 则进一步引入了语义泛化、行为非确定性和执行主体可替换三个特征。Agent 不只运行开发者预先编写的 Runbook，还会根据上下文生成新的操作计划，因此传统 Monitor-Analyze-Plan-Execute 闭环还必须增加 Identity、Authority、Evidence、Finality 与 Handoff。

本文据此把长期 Agent 的执行闭环概括为 Observe → Resolve State → Plan → Authorize → Execute → Verify → Reconcile。其中 Authorize 防止非确定性执行器越过安全边界，Reconcile 则负责把执行结果重新与现实世界对齐。这两个环节正是从“AI 自动化”走向“可治理自主系统”时最容易缺失的部分。

13 讨论：成熟系统为什么反而会限制模型

Agent Demo 常以“一个模型可以自主完成多少步骤”展示能力，而长期系统成熟度的一个重要表现恰恰是把某些责任从模型手中拿走。任务身份交给系统，权限交给 Capability/Policy，幂等交给持久化控制逻辑，Production 事实交给 Runtime Observation，执行租约交给 Authority/Lease。模型则专注 reasoning、planning、interpretation、generation 与 uncertainty handling。表面上看，Agent 自由度下降了，但整个系统的可靠性反而提高。

这形成一个重要悖论：系统越成熟，单个模型越不需要“无所不能”。最强模型仍然能提升复杂推理上限，但它不应该同时充当数据库、操作系统、权限系统、审计日志与事实真相源。很多长期 Agent 失败并不是因为模型不够聪明，而是因为架构错误地要求模型承担了它不擅长的确定性系统职责。

14 LMN516 的研究意义与边界

本文不声称 LMN516 发明了 MCP、多智能体、Task Queue、本地 LLM、GitHub Actions、自治计算或调度系统。其研究价值主要来自组合：个人网站、长期内容、Control Plane、真实 Production、MCP、云端与本地模型、异构计算节点、GUI Automation、长期 Q/RUN 与 Production Reconciliation 被放在同一个持续运行环境中。与其把它描述为某个单点技术创新，不如把它理解为一个个人级长期 Agent Infrastructure 的系统实验。

这个案例最有价值的观察也并非“已经达到多高层级”，而是它暴露了一个典型不平衡：Control Plane 的成熟速度已经超过 Cross-model Execution 的统一速度。任务、执行、Evidence 与 Production 语义已经相对先进，但不同模型还没有全部成为等价的一等客户端。因此，从 L3.2 到成熟 L3 的真正目标不是继续增加功能，而是“换模型，不丢任务”；从成熟 L3 到 L4 的目标则是“系统自己管理多个 Agent”；从 L4 到 L5，才是“系统开始持续评价并调整自己的运行方式”。

15 有效性威胁与局限

本文存在明显局限。首先，LMN516 是单案例，不能证明 L1-L5 模型适用于所有 Agent 架构，未来需要在企业 Agent 平台、研究框架和纯本地多 Agent 系统中进行交叉案例验证。其次，研究者同时参与系统设计与分析，这提供了丰富一手证据，也带来正向偏差；为减轻这一问题，本文坚持未完成真实验收的能力不计为“已实现”，并保留跨模型 Handoff 尚未通过多轮端到端验证这一负面结果。第三，3.2 只是工程诊断值，七个维度当前等权，尚未通过大样本校准，因此正式结论应理解为“LMN516 属于 L3，且部分控制面已经接近 L4 前置条件”，而不是“3.2 是精确客观测量”。最后，本文快照时间为 2026 年 9 月 14 日，案例系统仍在高频演化，数量、MCP 状态与节点结构不应被解释为长期不变量。

16 结论

本文试图回答一个表面简单、但很容易被 Tool 数量掩盖的问题：什么时候一个 AI 系统开始不再等于其中最强的那个模型？本文提出，真正的分界不是模型能否调用工具，而是系统是否开始独立保存和治理 Identity、Task、Execution、Policy、Evidence、Compute 与 Recovery。围绕这一分界，本文建立 L1-L5 五层成熟度模型，并提出 Agent Portability Vector、Handoff Integrity 与“非确定性执行者—确定性治理外壳”三个核心概念。

对 LMN516 的单案例分析表明，该系统已经跨过 L2 的核心边界：语义任务、执行尝试、Worker、执行权、Production Finality 与 Reconciliation 均已成为独立于单一会话的持久对象，因此更适合被描述为 L3 Shared Agent Infrastructure，而不是“一个接了很多 AI 工具的网站”。但它仍不能被写成成熟 L4，因为跨 ChatGPT、Copilot 与本地模型的无转录连续接力尚未完成稳定重复验证，统一 Identity、Capability、Scheduler、Event Bus 与 Compute Fabric 仍存在明显缺口。约 3.2 的辅助诊断值正是这种结构不均衡的表达：Control Plane 走在前面，跨模型执行面仍在追赶。

更一般地说，长期 Agent 系统未来的竞争力可能越来越少取决于“绑定了哪一个最强模型”，而越来越多取决于模型之外的基础设施。模型会升级，协议会变化，设备会替换；如果关键任务状态仍绑定于单个会话，那么每一次更换模型都近似一次系统失忆。反之，如果 Identity、Task、Policy、Evidence、Compute 与 Runtime 被外置为独立系统对象，新的模型进入时只需要获得合法身份、读取当前世界并继续工作。此时模型仍然非常重要，但系统不再等于模型。

因此，本文把 Agent OS 的核心问题定义为：如何为可替换、非确定性但高能力的智能执行主体，构造一个长期存在、状态一致、权限可控、事实可验证、算力可调度并能够恢复的运行环境。 从这一视角看，Agent OS 不是“大模型外面再套一层 UI”，也不是“一组更多的 MCP Tools”，而是一类新的系统软件问题。LMN516 当前的意义，不在于它已经走到终点，而在于它已经开始从“使用 AI”进入“构造 AI 基础设施”的阶段。

参考文献

[1] YAO S, ZHAO J, YU D, et al. ReAct: Synergizing Reasoning and Acting in Language Models[C]//International Conference on Learning Representations. 2023.

[2] SCHICK T, DWIVEDI-YU J, DESSÌ R, et al. Toolformer: Language Models Can Teach Themselves to Use Tools[C]//Advances in Neural Information Processing Systems. 2023, 36.

[3] WU Q, BANSAL G, ZHANG J, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation[C]//Conference on Language Modeling. 2024.

[4] PARK J S, O’BRIEN J C, CAI C J, et al. Generative Agents: Interactive Simulacra of Human Behavior[EB/OL]. arXiv:2304.03442, 2023.

[5] PACKER C, WOODERS S, LIN K, et al. MemGPT: Towards LLMs as Operating Systems[EB/OL]. arXiv:2310.08560, 2023.

[6] LIU X, YU H, ZHANG H, et al. AgentBench: Evaluating LLMs as Agents[C]//International Conference on Learning Representations. 2024.

[7] MIALON G, FOURRIER C, SWIFT C, et al. GAIA: A Benchmark for General AI Assistants[C]//International Conference on Learning Representations. 2024.

[8] YANG J, JIMENEZ C E, WETTIG A, et al. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering[EB/OL]. arXiv:2405.15793, 2024.

[9] WANG G, XIE Y, JIANG Y, et al. Voyager: An Open-Ended Embodied Agent with Large Language Models[EB/OL]. arXiv:2305.16291, 2023.

[10] XI Z, CHEN W, GUO X, et al. The Rise and Potential of Large Language Model Based Agents: A Survey[EB/OL]. arXiv:2309.07864, 2023.

[11] KEPHART J O, CHESS D M. The Vision of Autonomic Computing[J]. Computer, 2003, 36(1): 41-50.

[12] WHITE S R, HANSON J E, WHALLEY I, et al. An Architectural Approach to Autonomic Computing[C]//Proceedings of the International Conference on Autonomic Computing. 2004.

[13] SALTZER J H, SCHROEDER M D. The Protection of Information in Computer Systems[J]. Proceedings of the IEEE, 1975, 63(9): 1278-1308.

[14] LAMPORT L. Time, Clocks, and the Ordering of Events in a Distributed System[J]. Communications of the ACM, 1978, 21(7): 558-565.

[15] MODEL CONTEXT PROTOCOL CONTRIBUTORS. Model Context Protocol Specification[EB/OL]. Model Context Protocol, 2025-11-25 [2026-09-14].

系统证据说明

本文涉及 LMN516 当前状态的数量、控制函数和仓库演化结论，来自 2026 年 9 月 14 日对其真实 Supabase Control Plane 与 GitHub 仓库的只读核验。出于安全与长期可维护性考虑，本文不公开数据库项目标识、设备用户名、网络地址、密钥与内部认证材料。