编者按｜FinOS

企业 AI 落地翻车，很少是因为「模型不够聪明」，而是因为没有共享的操作系统：谁能代表哪个租户行动、代码在什么边界里跑、对存量系统的写操作谁说了算、员工用的入口是不是企业自己的。本系列讲清这些层，并用可核对的工程事实说话——企业 AI 操作系统。

先说结论

多买 Agent 是在复制推理循环；操作系统是在共享进门、身份、落库和编排边界。 两件事被当成一件事，Demo 就会被误认成上线标准。

企业真正缺的不是又一个会说话的 Bot，而是一套把对话送进治理路径的连接面：请求代表谁、对话存在哪、编排边界在哪一层——答案不能藏在前端组件或某个模型 SDK 里。沙箱、行动治理、企业入口是后面的层；连接面缺位，后面的层也接不住流量。

下面从一次典型的「周五 Demo、周一失控」现场说起，把第一层讲清楚。

一、Demo 能聊，生产为什么会失控？

业务线周五交了一份能跑的 Demo：对话框接上 ERP 查询，现场问答流畅，采购点头。周一灰度，客服、运营、财务各自接了自己的模型密钥和脚本。有人用个人 Key 直打供应商接口，有人把会话写在浏览器里，有人把编排塞进前端组件。下午第一张工单重复提交了十几次——超时后客户端重试，下游当成新请求。复盘会上没人能回答：这个请求代表哪个身份、对话存在哪、编排边界在哪一层。

翻车点很少是模型突然变笨，而是请求从未进入一条可共享的入站路径。

Cockroach Labs 在 2026 年 6 月的工程评论里写过一句硬判断：多数团队都做过令人印象深刻的 Agent，真正无事故上线的少得多；原因几乎从来不是模型本身。他们把生产事故拆成状态、身份、扇出风暴、爆炸半径、可观测性和单位成本——全是分布式系统问题，被聊天窗口盖住了。

Red Hat 2026 年 7 月的案例写得更贴现场。一个在预发环境「全绿」的客服 Agent，上线后同一夜里叠出三类事故：工具调用超时后重试，工单接口没有幂等信封，复制出 43 张重复单；开发期图省事的宽权限服务账号被原样推到生产，模型选错账户参数，4000 美元记到别人头上；模型一本正经地告诉客户「90 天可退」，真实政策是 30 天，输出从推理接口直线落到对客渠道，中间没有校验层。作者强调：框架把重试、路由、工具调用做对了，缺的是框架下面的地板——身份边界、幂等、输出进入真实世界前的闸门。

这些故事指向同一件事。Agent 框架解决的是推理循环。企业要的是操作系统：身份与租户、常驻运行时、沙箱、行动治理、自己的入口。本文只把第一层讲清楚——连接面。

二、「操作系统」五层：为什么连接面必须独立存在？

把「操作系统」说成五层，是为了避免下一场采购会又滑回「再买一个更聪明的 Bot」：

| 层 | 管什么 | |----|--------| | 连接面 | 请求怎样进门，对话落在哪，编排契约跟哪一层绑定 | | 执行器 | 常驻跑和租户怎么切 | | 沙箱 | 代码在哪类主机原语里跑 | | 行动治理 | 对存量系统的写是否该发生 | | 桌面入口 | 员工用的壳是不是企业自己的 |

五层里任何一层被聊天窗吞掉，Demo 都会显得完整，生产都会在另一处裂开。连接面替不了沙箱和写接口治理；连接面缺位，后面的层也接不住流量。

三、连接面为什么要独立于模型和业务 UI？

很多团队把三件事焊在一起：渠道界面、入站编排、具体模型。换模型供应商，就要改小程序；换一套聊天窗，就要重写认证和会话存储；业务线再做一个 Bot，又复制一遍密钥分发。焊得越紧，Demo 越快，生产越难接管。

焊死通常不是架构师故意选的。Demo 周只有一条最短路径：前端拿 Key、拼消息、打模型、把回复渲染回去。认证被省略，因为演示账号就一个；对话不落库，因为刷新浏览器就能重来；编排写在页面里，因为「先让领导看见能聊」。这条路径在会议室成立，在并发、审计、换供应商时不成立。连接面要做的，就是把这条最短路径拆开，留下可以版本化的入站形状。

入站契约至少要能回答四件事，而且答案不能藏在前端组件里：

• 请求代表谁——经过校验的身份，不是客户端自报的头；

• 属于哪一次对话——可检索、可迁移的会话标识；

• 这是不是一次重试——幂等键或请求身份，避免超时复制副作用；

• 下一步交给哪一类被批准的运行时——而不是写死某家 SDK 对象。

契约认这四件事，模型供应商和聊天窗才能从签名里拿掉。

对话存储和 Orchestrator 也不该焊成一块。存储回答「这次对话说过什么、已经发生过什么」；编排回答「下一步走哪条被批准的路径」。两者绑死之后，换运行时就要迁历史，迁历史就会被业务当成「换模型等于换系统」。Cockroach 把 Agent 记忆写成分布式状态问题，指的正是这一层：会话要能在节点故障后被证明还在，而不是靠模型自己「回忆」。

行业里已经有人把这件事说成「操作系统层」，而不是「再做一个聊天窗」。Wonderful 公开材料把自己的企业 AI 平台写成 AI-native operating layer，并单独强调 Model optionality：做出来的东西不要锁死在某一个模型上，新模型应该能落进来而不拆掉已有编排。这句话的工程含义比口号重要——可替换的不是宣传语，是入站契约没有把模型厂商写进签名。

Palantir 把另一头讲得更清楚。AIP 官方叙事里，Ontology 是决策中心的企业表示：对象、关系、动作，而不是原始表和对话框。首席架构师 Akshay Krishnaswamy 在 2024 年 1 月的工程博客里写：要把生成式 AI 接到运营，靠的是这套可版本化的对象与动作总线；平台文档随后把 Ontology SDK 称作企业内的 operational bus。你可以不同意 Ontology 这个词，但分层判断站得住：稳定的是契约与对象，可换的是模型和 UI。

把两段公开材料收成架构师能带走的一层：

连接面的职责不是「聊得更像人」，而是让任何渠道的请求，都经过同一套认证、同一处对话存储、同一条编排边界，再交给当时被批准的运行时。

OpenAI 也提供过面向聊天界面的 ChatKit 套件。那是把对话线程、流式事件接到 Agents SDK 的 UI/服务器抽象，集成方仍要自己做存储、鉴权和编排。名字容易混，层不要混：聊天套件解决窗口，连接面解决请求如何进入被治理的路径。

四、生产里最常见的四种「焊死」

现场反复出现的，不是「模型选错了」，而是契约焊错了层。

1. 渠道直连模型 SDK。 每个前端自己持有密钥、自己拼消息、自己决定重试。超时重试没有统一的请求身份，下游只能当新请求。Red Hat 那 43 张重复工单，就是这类焊法的自然结果。

2. 会话只活在进程内存或浏览器。 Demo 足够。节点重启、会话迁移、审计回溯立刻断档。Cockroach 问过一个该在上线前回答的问题：服务这个会话的节点中途挂了，状态去哪了，你能不能证明？回答不了，就还没有连接面。

3. 编排和某一个运行时绑死。 Orchestrator 的代码里写死了某家 SDK 的会话对象。采购换模型，渠道适配和编排一起返工。Wonderful 说的「不要锁死模型」，落在工程上就是：编排边界认契约，不认供应商对象。

4. 把聊天 UI 当成操作系统。 窗口换皮很快，身份、落库、编排仍散落在各业务线。多买几个 Agent，只是把焊点复制了几遍。

更好的做法很短：渠道只打到入站契约；认证通过后先写对话存储，再进入 Orchestrator；Orchestrator 只认稳定的入站形状，运行时和模型在契约后面替换。定时触发的智能体也走同一条编排边界，不要另开一套「脚本直连模型」的旁路。

四条焊死往往叠在同一条链路上。前端直连模型，会话就不落企业库；会话不落库，超时重试就没有可对账的请求身份；没有请求身份，编排只能把供应商对象当状态；供应商对象当了状态，换模型就等于换操作系统。拆开其中一环，其余三环才有地方挂。

架构评审与其问「这个 Agent 聪明不聪明」，不如问：身份、会话、重试、运行时选择，哪一项还写在 UI 里？

五、一条可核对的入站链路（存在性证明）

分层讲到这里，已经不依赖任何一家供应商。需要的是存在性证明：这条链路能不能被写成可版本化的契约，而不是口口相传的架构图。

凡泰的 ChatKit Middleware 按公开文档，采用契约优先的微服务结构，定位是对话式 AI 中间件——不是沙箱，也不是行动治理网关。它把入站写成一条固定顺序：

用户查询 → 认证 → 对话存储 → Orchestrator → 运行时（finclaw）→ 投递

认证在对话存储之前，存储在编排之前，编排在推理之前。模型与 Claw 运行时落在编排之后，渠道 UI 落在查询之前。换模型或换窗口，不应倒逼重写中间三段。中间件回答的是「请求如何进入治理过的 Agent 路径」，不回答代码在什么边界里跑、对 ERP 的写操作谁批准——那是后续层。

契约优先的意思是：入站顺序和边界先于具体实现冻结。UI 和模型都可以换，这条顺序不能散。

这只是连接面的存在性证明，不是「买一个中间件等于有了操作系统」。操作系统还要有常驻执行器与租户隔离、主机沙箱、行动面治理、企业自己的入口。没有连接面，那些层没有统一的进门；只有连接面，生产写操作照样会从旁路溜走。

存在性证明也有边界。公开文档能核对的是契约优先和这条入站顺序，不是吞吐量、客户名单或「已经替你管好沙箱」。把中间件说成操作系统全家桶，和把聊天窗说成操作系统，是同一种层错位。读者带走的应是可复述的顺序：先认证，再落库，再编排，最后才是运行时。顺序在，模型和 UI 才有资格成为可替换件。

你们线上那条「已经能聊」的链路里，认证、对话存储、编排、模型，哪一段还焊在业务 UI 上？欢迎评论区对照自己的架构图聊聊。

参考文献

• Quentin Packard，《What Breaks When Agentic AI Reaches Production?》，Cockroach Labs，2026-06-04。https://www.cockroachlabs.com/blog/agentic-ai-production-infrastructure/

• Richard Naszcyniec、Joshua Wilson，《Why good AI agents fail in production: The missing infrastructure layer》，Red Hat Blog，2026-07-13。https://www.redhat.com/en/blog/why-good-ai-agents-fail-production-missing-infrastructure-layer

• Wonderful，《One AI-native operating layer for employees, agents and apps.》。https://www.wonderful.ai/ai-os

• Akshay Krishnaswamy，《Connecting AI to Decisions with the Palantir Ontology》，Palantir Blog，2024-01-04。https://blog.palantir.com/connecting-ai-to-decisions-with-the-palantir-ontology-c73f7b0a1a72

• Palantir，《Platform overview》（Ontology SDK 作为 operational bus）。https://palantir.com/docs/foundry/platform-overview/overview/

• OpenAI，《Advanced integrations with ChatKit》。https://developers.openai.com/api/docs/guides/custom-chatkit