“AI 进入 OMS 订单中台的分水岭，不是能不能听懂一句话，而是做完之后能不能留下一条可追溯的操作记录。让腾讯 WorkBuddy 智能体驱动 OMS 订单管理系统，既不意味着把 OMS 订单中台推倒重来，也不意味着让大模型直接读数据库，而是在 OMS 之上加一层标准协议（MCP）——把订单、库存、发货、售后、财务的能力重新封装成「可读资源」与「可调用工具」，并配上权限矩阵与确认门。

下面商派结合实践，用 15 个日常运营场景说明：运营、客服、仓管每天真正卡在哪，智能体能替他们走到哪一步，哪些动作必须留给人，以及一座 OMS MCP 服务到底要打通哪些字段。

01  THE LAST CENTIMETER
Agent 进企业，卡在「最后一厘米」

Gartner 在 2025 年 8 月发布的研究预测：到 2026 年底，将有 40% 的企业应用内置任务专用的 AI 智能体，而 2025 年这个比例不足 5%。但 Gartner 在 2026 年发布的《Agentic AI 技术成熟度曲线》报告中给出了另一组数字：只有 17% 的组织真正部署了 AI 智能体，超过 60% 表示会在未来两年内部署。

两个数字之间的落差，就是业内常说的「最后一厘米」——让智能体回答一个问题很容易，让它真正动你的业务系统很难。

大量产品停在了「对话框里问一句，回你一段文字」的形态。不是因为模型不够聪明，而是因为它连不上系统、不敢写入、写错了没人负责。Gartner 专门给这种现象起了名字：agentwashing（智能体洗白）——把 AI 助手包装成智能体。

“能查不能做，是助手；能做且留痕，才谈得上智能体。”

02  WHY OMS FIRST
为什么 OMS 是智能体最该先落地的一站

如果预算只够做一个智能体试点，建议是 OMS，优先级高于客服和 BI 报表。理由有三。

第一，动作密度最高

客服一天处理的是「问题」，OMS 一天处理的是「动作」——审单、分批、改址、锁库存、建调拨、退换货。动作密度越高，智能体替代的重复劳动越多。

第二，规则最明确

可售库存 = 总库存 − 仓库冻结 − 订单冻结；改商品必须先暂停订单；撤销发货单的前提是状态为「未发货」。这些都是写死在《OMS 操作手册》里的硬约束，天然适合被翻译成工具调用的前置校验。

第三，风险可分级

查库存零风险，批量暂停低风险，正式发货和退款高风险。风险可以分层，就能分层放权，智能体才有落地的空间。

IDC 在 2025 年 1 月的一份研究中判断，全球订单管理（OMS）软件市场未来五年的复合增长率约为 14.8%，核心驱动力正是企业对「能够编排复杂数据流的订单管理系统」需求上升。OMS 订单中台正在从「记录系统」变成「调度系统」，而调度系统天然需要一个新的操作界面——对话，就是那个界面。

03  FIFTEEN SCENARIOS
15 个场景：运营的一天，哪些能交给智能体

我们把《OMS 操作手册》里高频重复的运营动作整理成了 15 个场景，每个场景都遵循同一套句式：说一句话 → 智能体解析 → 调工具 → 给预览 → 过确认门 → 留回执。挑六个最有代表性的。

其余九个场景逻辑一致：智能体负责整理、预填、校验、预览，人负责判断和拍板。

04  FIVE-LAYER BRIDGE
真正的门槛不是模型，是「桥」

到这里，问题从「要不要做」变成了「怎么做才不出事」。最直觉的做法是让智能体直接连数据库，或者把所有开放 API 丢给它自己挑——两条路都走不通。直接连库会绕过业务规则，库存过账、财务关账这类动作一旦写错无法回滚；直接堆 API 则意味着模型要猜参数，几百个接口各有字段风格，猜错率不可控。

可行的做法是加一层协议桥，共五层：

1. OMS 核心：订单、库存、仓储、售后、财务，保持不变
2. 开放 API 与单据：OMS 已有的开放数据、任务队列、Webhook、单据接口，只做鉴权、幂等与限流
3. OMS MCP 服务：把 API 封装成 Resources（读）、Tools（做）、Prompts（场景模板），内建权限矩阵与确认门
4. WorkBuddy 智能体：理解自然语言，选工具、传参、读结果、生成预览与回执
5. 业务结果：客服、运营、仓管、采购、财务用一句话驱动 OMS，拿到可复核的结果

这层的关键词是「重新暴露」而非「新建」。MCP 服务不新增任何业务字段，只是把 OMS 既有的订单、库存、仓储、售后、财务对象，按「读」和「做」两类原语重新组织。

工具名即业务意图，参数结构固定，模型不需要猜；智能体只能通过这两类原语访问数据，碰不到库，从协议层就守住了数据安全。

05  CONFIRMATION GATE
确认门：敢放手的前提是能刹车

15 个场景分别落在三个自动化等级上：

“确认门要建在 MCP 工具层，而不是写在提示词里。”

写在提示词里的「请先跟我确认」，模型有可能忘记、被绕过，甚至被后续指令覆盖；注册在工具层的确认门，没拿到 human-in-the-loop 回执就不执行。像 shipment.revoke、invoice.red 这类工具在注册时即被标记为「人工确认」，调用即触发审批。

这不是对模型的不信任，而是把风险控制从「概率问题」变成「确定性问题」。

06  FIELD BLUEPRINT
字段打通清单：一座 OMS MCP 服务要暴露什么

一句话总结：MCP 服务不生产数据，它只决定「哪些能力可以被谁、以什么方式调用」。这也是它相对于「给每个 Agent 写一套定制接口」的根本优势——OMS 已有开放数据、任务队列、Webhook 与单据接口，MCP 在其之上做协议封装与权限收敛，避免重复建设。

07  ROLLOUT PATH
落地顺序：先读后写，先低危后高危

建议分五步推进，每一步都能独立验收：

1. 只读资源先暴露　库存查询、订单监控、状态回写检查。零风险，先让智能体「看得见」，也让业务团队建立信任
2. 半自动配置　批量操作、订单编辑、失败订单修复、赠品规则、补货采购，带预览与确认门
3. 高危执行　发货、撤销、退款、红冲，MCP 层强制 human-in-the-loop，逐场景灰度
4. 能力包沉淀　把 15 个场景固化成可复用能力包，支持一句话触发与定时任务（例如「今晚 22 点定时审单」）
5. 持续治理　监控调用日志、回执率与误拦截率，按业务反馈迭代规则与确认阈值

08  FIVE RISKS
五项风险，需要在设计阶段就想好

09  BOUNDARY
边界声明：这些不该向它要

为避免期待错位，也明确说清楚不做什么：

1. 不承接通用 ERP、MES、PLM 的生产执行与成本核算——它们是 OMS 的被集成对象，通过接口对接，不在本方案范围内
2. 不自建运力——智能体能做的是订单路由与物流优选，实际承运由快递与同城配送服务商完成
3. 不做流量投放与代运营——智能体优化的是履约与库存动作，不是广告投放
4. 不承诺「无人化经营」——发货、退款、库存过账、财务关账这类动作，设计中永远保留人的位置。这不是能力不足，而是责任边界

∞  THE END
OMS 不需要被重写，它需要被驱动

AI 进入订单中台，真正的分水岭不是模型能不能听懂「把这批预售单暂停」，而是它能不能在暂停之前，先告诉你这批单有多少、影响多少金额、会不会和别的规则打架，然后在你点下确认后，留下一行「谁、在什么时间、对哪些单做了什么」的记录。

“重写意味着风险和沉没成本，加一层协议桥，意味着你过去十几年沉淀的业务规则全部可以继续生效——只是操作方式从『在系统里点半天』变成了『说一句话』。”

对运营来说，省下的是每天数小时的重复点击；对管理者来说，拿到的是可追溯、可审计的操作记录；对 IT 来说，守住的是「数据不进模型上下文、动作不过确认门不执行」的底线。

如果你的团队正在评估智能体落地，不妨从最没有风险的那一层开始：先把库存查询和订单监控交给它，让它先「看得见」。