Agent OS 不是给大模型换皮：企业智能体操作系统需要哪两层内核
过去一年，“Agent OS”被用来描述桌面助手、工作流编排器、多 Agent 框架，甚至只是一个带工具调用的聊天界面。名称很吸引人，但如果系统没有资源边界、生命周期、权限传递和可重放记录，它更像应用框架，而不是操作系统。
2026 年 8 月发布的 Agent Operating System 参考架构提出了一个更严谨的边界：AOS 不替代 Linux、Windows、容器运行时和物理基础设施，而是在异构模型、Agent、工具和业务系统之上，提供一套实现无关的运行与治理契约。它最有价值的地方不是命名，而是把企业 Agent 系统拆成两个内部平面。
Agent OS 的关键不是统一模型界面，而是让控制治理与运行协调分别持有职责，并形成可追踪的证据回路。
控制与治理面管什么
控制面不是一个“管理员后台”，而是所有高后果动作的裁决层。它至少需要管理六类对象：
| 对象 | 必须回答的问题 | 不能只靠什么 |
|---|---|---|
| Intent | 这次任务究竟要达成什么结果 | 一段自然语言 prompt |
| Authority | Agent 代表谁、可访问什么 | 长期有效的服务账号 |
| Policy | 什么条件下允许调用工具 | 工具描述里的软提示 |
| Risk | 动作的可逆性和影响半径 | 模型自报置信度 |
| Oversight | 哪一步必须人工批准 | 最后统一点“确认” |
| Audit | 为什么做、做了什么、结果如何 | 只保存对话文本 |
授权必须跟随任务缩小，而不是在委派链中膨胀。主 Agent 把“核对发票”委派给子 Agent 时，传递的应该是限定客户、时间窗和只读工具的 capability，而不是复制主 Agent 的完整令牌。每次再委派都要满足 child_authority ⊆ parent_authority，否则多 Agent 会成为权限放大器。
运行与协调面管什么
运行面处理 Agent 作为“非线性程序”的特殊性：它可能等待人类数小时、调用外部服务后断线、切换模型、并发探索多条路径，又在其中一条成功后取消其余分支。传统请求处理器只知道开始和结束，Agent Runtime 必须显式保存中间状态。
一个最小生命周期可以定义为：
CREATED -> ADMITTED -> RUNNING -> WAITING_APPROVAL
-> WAITING_TOOL -> SUSPENDED
-> COMPLETED | FAILED | CANCELLED
每次状态迁移都应携带 run_id、actor_id、intent_id、输入版本、策略版本、预算余额和幂等键。恢复时从检查点继续，而不是把整段对话重新发给模型并祈祷它重复同样的动作。
运行面还要区分四种状态：模型工作上下文、业务事实、工具调用状态和审计事件。工作上下文可以压缩；业务事实必须有来源和有效期；工具状态要求幂等；审计事件只能追加。把它们都塞进向量数据库，会同时破坏一致性、隐私删除和事故取证。
Agent OS 的边界测试
判断一个平台是否真的接近 Agent OS，可以做五个故障实验：
- 在工具执行成功但响应丢失时重启 Runtime，是否会重复付款或重复发信？
- 在人工审批等待期间升级 Agent 版本，旧任务由哪个版本继续？
- 撤销用户权限后，正在运行的子 Agent 是否立即失去派生权限？
- 模型供应商不可用时切换模型，是否保留原策略、工具 schema 和证据链？
- 事故发生后，能否重建“谁的意图、哪版策略、哪个模型、什么输入”导致了动作？
如果答案依赖人工翻日志，这套系统还处于框架阶段。
企业落地顺序
第一阶段不要建设“万能 Agent”。先统一任务与动作事件模型，让所有 Agent 都能被观测和取消；第二阶段引入短期凭证、工具网关和策略裁决；第三阶段才做跨 Agent 委派、轨迹分支和动态模型路由；最后再开放业务团队自助创建 Agent。
这种顺序看起来保守，却避免了最昂贵的返工：当几百个 Agent 已经各自保存状态、各自处理权限后，再补统一控制面几乎等于重写。Agent OS 真正提供的不是一个新桌面，而是让概率性执行体能够进入确定性的企业责任体系。