上个月和一个做制造业 ERP 实施的朋友聊天，他讲了个真事：客户想让智能体"自动处理低值采购收货"，结果某天 agent 把一笔本该人工复核的付款给提交了。钱没丢，流程也拦得住，但 CIO 当天就被拉进会里问了三个小时——谁授权的、为什么没挡住、下次怎么防。
这件事之后我意识到：agentic ERP 最该被讨论的，不是"它能不能改数"，而是"它该在什么条件下、经过哪几道关，才能改数"。最近几条行业动态，恰好把这道闸门的设计，补全了。
一、第一道闸：权限要比人更窄
过去一年，agentic ERP 最大的隐性风险，藏在一句话里——"agent 继承运行它的那个用户的全部权限"。一个能确认采购单、过账收货、释放付款冻结的采购经理，把他这三个权限全交给了任何一个跑在他账号下的 agent。agent 不需要三个权限去追一张收货单，但它手上握着三个。
微软这个月给了一个原生答案。Dynamics 365 Finance & Operations 的路线图项 571677，引入"仅 Agent 安全角色"：当一个人是通过 agent 访问 ERP 时，系统可以给他套一套更窄的角色、职责和权限，而且按法人实体分别 scope。换句话说，agent 会话的权限可以比这个人直接在客户端操作时更窄。
这不是新概念，但是第一次落进 ERP 原生安全模型。它干掉的是 agentic ERP 最大的那个窟窿——"给 agent 一把和用户等宽的万能钥匙"。
对实施商来说，这意味着验收清单要加一条：每个 agent 的最小权限集，是不是比操盘人窄、是不是按业务实体隔离。别用一个"全角色"服务账号去跑 agent，那是在审计上自己埋雷。
二、第二道闸：写回要分级，不是一刀切
权限窄了，下一步是：就算 agent 有权，也不是所有动作都该自动提交。从业者机构 Techverx 在 10 月的一篇梳理里，给了一个很接地气的"四档阶梯"：
| 档位 | AI 能做什么 | 闸门 | 例子 |
|---|---|---|---|
| Read | 查询并汇总 | 角色内访问，留痕 | 看某供应商的未结发票 |
| Draft | 建未过账单据 | 仅草稿态，不入账 | 起草一张供应商贷项单 |
| Propose | 提交待批 | 具名审批人看差异 | 价格变更申请 |
| Commit | 无人过账 | 硬上限、可逆、采样审计 | 释放低值已匹配发票 |
核心就一句：没有一道 AI 生成的改动，应该在没有和它对等的风险闸门的情况下触到达 ledger。低风险的可以自动提交，高风险的必须有人审批或采样审计。这跟我们此前聊过的 ArionERP 动作阶梯（读→起草→建议待批→受限执行）是同一个思路，只是 Techverx 把它讲得更工程化、更可操作。
落地建议：给每个 agent 画的不是"它能做什么"，而是"它在哪一档、超过哪一档必须人工"。把风险分级写进 agent 的设计说明书，比事后补审计有效十倍。
三、第三道闸：MCP 连接，别把"用户令牌"透传
权限和分级都设好，还有一道更隐蔽的闸——连接本身。现在主流 ERP 都支持 MCP（Model Context Protocol）让外部 AI 调自己的数据和工具。但 MCP 的授权规则，比大多数人以为的要紧。
Techverx 特别点出一个坑：MCP 服务端必须校验"这个 token 是不是发给我的"，并且不能把客户端的 token 直接透传给上游 ERP。规范里授权本是可选的，所以一个"合规"的 MCP server 仍然可能不安全——这正是经典的"confused deputy（混淆副手）"问题：agent 拿到的凭据，被中间件拿去干了它本没资格干的事。
把 MCP 当成"能连就行"是危险的。每一个架在 AI 和 ERP 之间的 MCP server，都应该当作一个经过安全评审的服务来对待——谁发的令牌、能到哪、能做什么，一条都不能含糊。
对 Odoo 20 这类原生带 MCP server 的开源 ERP，这句话同样成立：Odoo 把"连接"交给你，但"治理"也还给你。你接了哪个模型、给了它什么 scope、令牌怎么管，全是你自己的责任。开源不替你兜底，反而逼你把这道闸早早设计好。
四、第四道闸：留痕与回滚，给每次自动动作一个"回执"
前三道闸解决"能不能改"，第四道解决"改错了怎么办"。当 agent 真的提交了动作，你需要两样东西：一份说清楚"它做了什么、依据是什么"的执行轨迹，以及一个能把它撤回的开关。
这点在产品端已经有人在做了——Odoo 20 的可审计 AI 对话会记录触发器和可读的执行轨迹、并保留 30 天；Oracle Fusion Claw 强调 Outcome Receipts（结果回执）。本质上都是同一件事：让每一次自动动作可追溯、可解释、可回滚。没有这第四道闸，前三道再严，也只是"出事前管得住、出事后说不清"。
红线：高利害动作（付款、过账、释放信用冻结）永远不要放进"无人 Commit"那一档。哪怕模型准确率 99%，那 1% 的代价也足以让一次自动付款成为审计事故。高利害，永不自主——这是四条闸里最不该被省的一条。
五、结语：给 CIO 的三条落地纪律
把四道闸收一下，给正在或准备上 agentic ERP 的管理者三条纪律：
- 最小权限先行。 agent 的权限必须比操盘人窄、按实体隔离；别用全角色服务账号跑 agent。
- 写回分级 + 人工兜底。 用 Read/Draft/Propose/Commit 把风险分级，高利害动作永不自主。
- 连接可治理、动作可回滚。 MCP 当安全服务审，每次自动动作留轨迹、留回执。
智能体改 ERP 里的数，不是洪水猛兽，但也不能"连上就能改"。先过这四道闸，agent 才是帮手；闸门没设好，它就是一把没人盯着的万能钥匙。能力可以买，边界必须自己守——这话放在 agentic ERP 上，比放在任何别的软件上都更对。
本文基于公开信息分析：Microsoft 路线图项 571677 与 Cognilium 解读（2026-09-30 公布，2026-10 预览）、Techverx《AI in ERP: How APIs Make ERP and AI Work Together in 2026》（2026-10）、Odoo 20 官方发布说明（可审计 AI 与 MCP）、Oracle Fusion Claw 发布说明（Outcome Receipts）。观点为作者独立判断，供实施参考。
众谛信息 · 专注 Odoo 与企业管理数字化解决方案
