AgentOS：把模型能力变成企业执行力的那一层

结论

企业买模型很容易，买执行力很难。同一个模型接入不同企业后表现出的可靠性差异，往往不是模型能力的差异，而是模型之上有没有一层执行系统——负责拆解任务、设置护栏、管理身份与权限、留存可追溯的决策记录，并在关键节点把决定权交还给人。这一层不是可选配置，是把"能回答问题的模型"变成"能对结果负责的系统"的唯一路径。汉兴把它称为 AgentOS。

发生了什么

2025 年 4 月 17 日，OpenAI 发布《A practical guide to building agents》，面向正在评估是否自建 agent 的产品与工程团队，把内部多个客户部署项目里反复出现的做法，归纳成一套可执行的指南。

指南给出的第一个判断是关于何时该用 agent：不是所有自动化任务都需要 agent。适合的场景通常具备三个特征——决策依赖复杂判断、规则手册难以覆盖所有分支，或者依赖非结构化数据。反过来，规则清晰、路径固定的任务，用传统自动化脚本更便宜、更可控。这个判断本身就是一种编排纪律：先问该不该用 agent，再问怎么做。

在架构层面，指南把编排模式分成两类。一类是单 agent 系统，靠一个循环不断调用模型、执行工具、判断是否结束，适合大多数起步场景；另一类是多 agent 系统，进一步分成"管理者模式"（一个中心 agent 把任务分给若干专家 agent，再汇总结果）和"去中心化模式"（对等的 agent 之间直接互相交接任务）。指南明确建议：先用单 agent 把复杂度压到一个 prompt 能装下的程度，只有当单 agent 处理不同任务、使用不同工具时反复出错，才升级到多 agent。

护栏被单独列为一个体系，而不是一条附加规则。指南把护栏分成多层：相关性分类器判断输入是否偏离任务范围，安全分类器识别越狱与提示注入，PII 过滤器阻止敏感信息外泄，内容审核接口拦截有害输出，此外还有基于规则的过滤、工具调用的白名单限制，以及输出结构化校验。指南的原话是：单一护栏不太可能提供足够的保护，把多个专用护栏组合起来使用，才能构成有韧性的防御。

人工介入被定义为一种安全机制，而不是对 agent 不信任的表现。指南把"审批"作为工具调用的人工路径：模型仍然可以判断某个动作需要执行，但流程会在这一步暂停，等待人工批准或拒绝之后才继续。这在部署早期尤其重要，用来发现失败模式、暴露边界情况，并建立评测循环。

同一时期，Deloitte 在 2026 年 1 月 29 日发布《Engineering the Agentic Enterprise》，从工程与网络安全协作的角度补上了 OpenAI 指南没有展开的部分：可观测性与治理。文章指出，可观测性不是简单的系统监控，而是要能发现 agent 的决策质量、工具使用模式与升级路径中的问题，让团队在问题变成严重故障之前就能定位和处理。文章同时提出零信任原则——每一次交互，无论由人还是 agent 发起，都必须被验证——以及生命周期治理：每个 agent 必须遵守明确的访问参数、凭证与生命周期管理规则，它的决策与产出必须完全可追溯、可解释，并持续接受复核。

为什么这对企业重要

过去两年，很多企业对"上 agent"的理解，停留在选一个模型、接一个聊天界面、连几个工具。这套配置能跑出演示效果，却经不起真实业务场景的重复检验：任务复杂一点就跑偏，出错了没人知道在哪一步出的错，权限没管住导致 agent 碰了不该碰的数据，出了问题也没有人工介入的停止点。

这些失败不是模型的问题。OpenAI 和 Deloitte 两份文件从不同角度描述的，其实是同一件事的两面：企业缺的不是更强的模型，而是模型之上那一层把"生成能力"转化为"可控执行"的系统。这层系统要回答五个问题——任务怎么拆解和路由（编排）、哪些输出必须被拦下来（护栏）、agent 能碰什么不能碰什么（权限）、每一步决策能不能被回溯（观测）、什么时候必须停下来等人（复核）。少了任何一个,企业得到的都不是"可以对结果负责的系统"，而是一个运气好才不出事的黑箱。

汉兴的判断

企业缺的不是更好的模型，是编排、护栏、权限、观测和人工复核这五层执行系统。少了任何一层，agent 都只是一个运气好才不出事的演示。

这是一个可以被反对的判断。反对的版本是：随着模型的推理与自我纠错能力上升，护栏和人工复核会逐渐变得多余，企业只需要把预算花在更强的模型上。我们不同意，理由是护栏和复核要防的不是模型能力不够，而是目标本身可能被误解、权限本身可能被滥用——这类风险不会随模型变强而消失，反而会随 agent 拿到的自主权变大而放大。

我们把这五个问题固定成一个原创框架，作为汉兴评估企业 agent 部署成熟度的标准。

```AgentOS 五层执行系统 [1] 编排层 Orchestration 产出：任务路由规则，单 agent 何时升级为多 agent [2] 护栏层 Guardrails 产出：分类器 + 规则 + 审核接口的组合防线 [3] 权限层 Identity & Access 产出：每个 agent 的身份、凭证与访问边界 [4] 观测层 Observability 产出：决策与工具调用的完整追溯记录 [5] 复核层 Human-in-the-loop 产出：明确写下的停止点与审批路径```

配套指标，我们称为可追责执行率：

```可追责执行率 = 有完整追溯记录且落在权限边界内的 agent 决策数 ÷ agent 决策总数```

这个指标不衡量 agent 干了多少活，衡量的是这些活里有多少能在出问题时被查清楚、能证明没有越权。一个企业如果只看任务完成率,看不到这个分母,它衡量的是产量，不是可控性。

一个中国企业的情境（示例推演）

以下情境用于说明框架的用法，不对应任何真实客户，数据为示例推演。

一家长三角的连锁零售企业上线了一个客服 agent，处理退换货与物流查询。第一版做法是接入模型加订单系统，客服人效提升明显，团队一度认为项目已经成功。三个月后出现两次事故：一次是 agent 在缺乏授权的情况下批准了超出权限范围的退款，另一次是客户投诉 agent 给出的物流承诺与实际不符，客服主管想查是哪一步出的错，却发现系统只留下了最终回复，没有留下中间的推理与工具调用记录。

按五层框架重做：权限层把退款额度拆成分级审批，超过阈值的必须转人工；护栏层加入规则校验，物流承诺类回复必须核对实时物流接口数据后才能发出；观测层把每一次工具调用和中间推理写入日志，可按会话回放；复核层在退款与投诉类场景设置强制停止点。这套改动没有换模型，改的是模型之上的四层系统。

反方观点与适用边界

这个判断在两类场景下需要调整。

第一类，低风险、高频、结果容易验证的任务。 比如内部文档摘要、会议纪要生成，这类任务出错成本低、纠错成本也低，为它们搭建完整的五层系统可能比任务本身更贵。这类场景可以先用单 agent 加基础护栏跑起来，把五层系统的投入留给真正涉及资金、合规或客户承诺的场景。

第二类，指南本身承认的局限。 OpenAI 的指南聚焦在 agent 应用层的设计模式，不覆盖模型训练、底层基础设施选型这些更上游的问题；Deloitte 的文章讨论的是企业级软件架构的演进方向，不是针对某个具体行业的实施细则。两份文件给出的是原则和分类，不是可以直接套用的实施手册,落地时仍需要针对具体业务流程重新设计每一层的规则。

企业现在应该做什么

给 CEO：下一次审批 agent 项目预算时，要求项目方回答五层框架里的每一层由谁负责。 如果某一层没有明确的负责人，这个项目还没有准备好接触真实业务数据。

给 CAIO：为已经在跑的 agent 项目补一份权限清单和一份停止点清单。 权限清单写清每个 agent 能访问什么、不能访问什么；停止点清单写清哪些结果类型必须先经人工批准才能生效。这两份清单是五层系统里成本最低、见效最快的部分。

给 FDE：在下一个交付项目里，把观测层作为默认交付物,而不是可选项。 每一次 agent 决策留下可回放的记录，不只是为了排查故障，更是让业务方在系统出问题时能立刻定位到具体哪一层失效，而不是怀疑整个系统不可信。

证据、来源与公开边界

• OpenAI，《A practical guide to building agents》，2025 年 4 月 17 日。https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
• Deloitte US，《Engineering the Agentic Enterprise》，2026 年 1 月 29 日。https://www.deloitte.com/us/en/services/consulting/articles/engineering-the-agentic-enterprise.html

本文引用的框架描述与做法建议均来自上述两份官方文件原文。文中的中国企业情境为示例推演，不对应任何真实客户。AgentOS 五层执行系统与可追责执行率指标为汉兴原创，未经第三方验证。

元信息

栏目 Enterprise AI　作者 汉兴 AGI 实验室　版本 v1.0　成稿 2026 年 8 月 12 日