11 月初，一家政企单位把一批国产终端摆上工位，配了桌面智能体。能查单据、看数据、盯流程，演示的时候挺顺。IT 部开会讨论，第一个问题不是跑多少算力、接多大的模型，而是：它凭什么碰业务系统。
这个提问顺序，比任何一份 AI 选型 PPT 都更接近现实。用友 11 月 2 日那篇稿子把场景写得很具体：桌面智能体和聊天框最大的区别，是它要动手。查单据、看数据、盯流程，这些动作最后都要落到真实的 ERP、财务和人事系统里。一旦落到系统里，问题就从「好不好用」变成「出了事谁签字」。
最近一周我翻了十几份公开资料，从天津峰会的政企采购清单，到柏林 TechEd 之后的顾问讨论，再到几份 2027 规划指南，发现大家其实在补同一份作业：AI 已经能伸手进 ERP 干活了，但甲方手里的验收单还没跟上。
本周多份政企 AI 选型清单给运行日志留的一致底线：唯一追踪标识，覆盖从用户请求到工具调用的完整链路
一、把形容词换成四条能压测的条款
峰会现场有句措辞：「在安全可控的底线之上，效率、智能与生态成熟度，正成为政企客户选型的核心标尺。」（环球网，11 月 5 日）话说得漂亮，可「安全可控」四个字落到验收单上，得拆开。
2026 年多份企业 AI Agent 选型清单给的拆法相当一致，我按能现场核验的顺序捋一遍：
| 验收项 | 现场怎么压测 | 要交回什么 |
|---|---|---|
| 内网闭环 | 断网压测，确认推理、检索、调度、执行全在本地 | 外联清单，证明没有默认调外部 API 的组件 |
| 权限粒度 | 换不同用户身份问同一问题、下同一指令 | 行列级权限矩阵，最小授权 + 每次调用独立鉴权 |
| 运行留痕 | 随机抽某天某人，让安全团队自己从后台还原 | 唯一追踪标识 + 日志留存 180 天，覆盖请求→检索→输出→工具调用 |
| 认证路径 | 问进度，不问「有没有」 | 等保三级、密评、信通院评测各自的推进计划与时间 |
有一条判断标准特别好用：安全团队能不能在不问供应商的情况下，自己从后台还原出「某天某人让智能体做了什么」。
还有一句更该贴在采购文件里：《用友》那篇稿子自己写的——私有化部署本身不等于安全，关键看内网闭环是否彻底。只把流程工具放本地、推理仍走公有云，风险并没有消除。对金融、能源、政务、医药，「数据物理隔离不出域」不是加分项，是准入项。
这两年做国产化替代的项目，最容易在这一节翻车。硬件、操作系统、数据库都换了，模型和推理链路上还挂着一个外部 API，验收时没人问，上线后没人查。
「私有化」是个部署方式，不是个安全结论。把它写进合同只能证明机器在哪，证明不了数据在哪、推理在哪、日志能不能自己调出来。
二、分工不是修辞，它决定出事之后谁签字
用友给 YonWork 那套能力起了个名字，叫「自主业务闭环执行」：跑在企业业务系统之上，跨产品、跨品牌、跨版本连接现有系统，在授权和规则范围内把业务目标拆成可执行步骤，调用工具、推进流程、回传结果。紧跟在后面的是一句分工说明——真实员工负责目标、判断、授权和担责；数智员工负责拆解、执行、核验、生成、提醒和回传。
这段看着像产品文案，其实是责任条款。「担责」两个字写在人这边，不是随便写的。它决定了凭证错了找谁、付款批错了找谁、审计来问的时候谁能把那条链路讲完整。
曙光云 OneBox 走的是另一条路：「数桥」不让模型直接连数据库，而是在智能体和传统业务系统之间加一层服务端数据管理模块，接住 ERP、MES、财务、人事这些活数据。两条技术路线不同，绕开的是同一个雷区——把数据库账号交给大模型。
真实员工
目标、判断、授权、担责；对结果与合规边界负责
数智员工
拆解、执行、核验、生成、提醒、回传；不定义规则
这跟我们做实施时的老规矩其实是一回事：谁配置、谁复核、留什么痕、异常升级找谁，四件事写进制度，再动开关。区别只是以前这套约束人，现在同时要约束一段会自己跑的代码。
三、执行能力先跑出去了，治理还在后面追
科莱特 11 月 6 日那篇讲 SAP TechEd 2026 的文章，把 Joule Work 的位置摆得挺清楚。它前身是 SAP Mobile Start，现在是员工和智能体打交道的统一工作入口；CTO Philipp Herzig 的说法很直接：过去是 AI 学习你的业务，现在是在你的业务里把活干完。库存低于安全线，自动发起采购申请、推送审批，顺就往下走，卡住再交给人。
但同一篇稿子里还有两句，采购方更该划重点：智能体没法自己制定业务规则、合规要求和风险标准；完整的权限管控与审计追溯能力，要等到 2027 年 Q1 才补齐，目前只开放给少量试点客户。
这就是当下最现实的时间差。厂商把「能干活」先推出来了，「能管住」排在下一年的路线图里，甲方却已经准备拿它跑真实单据。中间这段空档，不会由厂商替你补。
稿子对顾问职业的判断也挺克制：被替代的首先是「可规则化、可审计、责任密度相对较低的执行任务」，不是顾问这个角色。只会做基础执行的人空间会被压缩；能把混乱业务梳理成系统规则、对数据质量和合规边界负责的人，价值反而更清楚。
我们这行这两年确实有这个感觉。客户不再为「把功能配出来」付溢价，愿意付钱的是「把边界说清楚、把异常情况兜住」。这活儿恰好是智能体最不擅长的那部分。
四、别把「预期」当「结果」写进验收单
亿滋（Mondelez）联合埃森哲把 order-to-cash 建在新建的全球云 ERP 之上，覆盖每年百万级交易，稿子里的措辞是 expects to be able to——预计能够简化日常任务、加快交付、提升准确度。这是预期值，不是验收值，写得也算规矩。
反过来看 Constellation Research 那个 Infor 案例，做法就值得抄：上线前先把 outcome targets 定下来，发票处理自动化的目标写的是 60% 到 70%，最后报 75%；再用过程挖掘做上线前后对比，同时量时间节省和错误率。目标先定、口径先说，结果才有得对。
国内这几周还冒出好几份「企业级 Agent 平台选型指南」，把架构、数据、治理、行业沉淀列成四维评估，方向上没错。但要留个心眼：其中不少带明确免责声明，属于厂商宣传或转载资讯。里面的认证编号、市场占有率可以拿来做提问清单，别直接当独立结论抄进选型报告。
验收句式其实很简单：不要「效率提升约 20%」，要「以我方 2026 年 9 月的关账天数和对账人工小时为基线，跑满三个月后对比」。基线是自己的，数字才跑不掉。
五、上线前，先把这三条写死
第一条，把形容词翻译成压测项。断网压测报告、外联清单、行列级权限矩阵、180 天日志与抽样还原演示、认证推进计划——五项里缺一项，验收单就先别签。安全团队要能自己查出「某天某人让智能体做了什么」，不能靠供应商截图。
第二条，把责任和升级路径写进制度。谁配置、谁复核、谁担责、告警一周没人管往哪升、怎么回滚，一条条落到岗位。高利害动作（大额付款、主数据变更、税务相关）永远留人工兜底，agent 可以起草和执行已批准的步骤，落槌的人不能缺席。
第三条，用自家基线验收，只看一个流程。挑最痛的一条，比如应收催款或供应商订单确认，把目标值、复核人、异常兜底、留痕位置全写死，跑一个月。跑顺了再谈扩面，跑不顺只损失一个月。
Metanow 那份 2027 规划指南里有一句我挺认同：模型升级和业务规则变更，都应该像软件变更一样触发回归测试。它把指南标成前瞻规划，没敢说 2027 的结果已知。这种克制，比一堆漂亮预测更可信。
这两年 ERP 里的 AI，功能侧跑得比谁都快。真正拖后腿的，是没人愿意提前填的那张验收单。等出了事再补，成本就不是填表的时间了。
把钥匙交出去之前，先把「谁能开哪扇门、开过之后怎么查」写清楚。这句话不新鲜，但这一周的所有动态，绕来绕去都在说它。
资料来源：用友 BIP《一台国产电脑摆上工位之后》（2026-11-02）、赛迪网（2026-11-03）、环球网天津峰会报道（2026-11-05）；科莱特教育经网易订阅《Joule Work 重构 SAP 顾问工作》（2026-11-06，SAP TechEd 2026 柏林 10/27–28）；Consumer Goods Technology（Mondelez × Accenture）；Constellation Research（Team Air Distributing × Infor Velocity Suite）；Metanow《AI Agents in Business: What Changes in 2027》（研究核查 2026-11-06）；ITBear / IT168 / 中国工控网企业级 Agent 平台选型指南（2026-11，含厂商宣传口径，本文已标注）。
本文由广州众谛信息科技整理撰写，供企业数字化与信息化负责人参考，不构成采购建议。配图为 AI 生成。
