大多数团队试着把大模型接到ERP旁边，一周之内就会撞上同一堵墙：演示很惊艳，然后财务的人问了一句，"那什么阻止它去改一张已过账的发票？"

这个问题问得对。ERP是记录系统。如果模型能随便往里写，每一次幻觉都会变成一条账目记录；如果它完全碰不到，那模型就只是个靠猜的聊天机器人。

实际采用的做法是：模型直接读，但它只能提出写入建议，每一处改动都由人来批准。听起来简单，也确实简单——这正是重点。

把世界分成两条道

把读和写当成两套完全不同的系统，而不是同一套系统上的两个权限。

  • 读道：智能体可以查询主数据、未结单据、库存、账簿和状态字段，结果作为上下文回传给模型。
  • 写道：智能体永远不能调用写入接口，它只能创建一份"提案"——一条描述它想做什么改动的结构化记录——放进ERP之外的队列里。

最关键的设计决定是：写道根本不存在于智能体的工具集里。它不是某个写着"别写"的开关，而是那个工具压根就没有。

让读道真正只读

"只读"应该由ERP来强制，而不是靠提示词。

  • 给智能体建一个专用技术账号，只给显示权限，任何业务对象上都没有创建或修改授权。
  • 读取通过一层薄薄的服务层暴露（OData、REST或数据库视图），而不是让模型自己拼裸SQL。
  • 把智能体能看到的实体和字段做成白名单。薪资表、银行信息以及任何个人数据默认排除在外。
  • 记录每一次查询，连同触发它的用户问题。当有人问"智能体为什么这么说"，你需要它当时看到的那几行原始数据。

如果某个对象在ERP里没法干净地表达"仅显示"，那就先别暴露它，以后再补。

把每次写入变成一份提案

当智能体判断某件事该变——释放一张被冻结的采购订单、更新交期、开一张贷项通知单——它输出的是这样一份提案：

  • 动作：update_delivery_date
  • 对象：PO 4500012345 / 行项目 10
  • 当前值：2026-11-12，建议值：2026-11-19
  • 理由：供应商11月6日的确认邮件称发货推迟一周
  • 证据：邮件8831、采购订单历史4500012345
  • 发起方：智能体；置信度：中

几条规则让这套东西跑得起来：

  • 展示改动前后。审批人不必打开ERP就能看懂这次改动。
  • 附上证据。每份提案都链接到支撑它的文档或数据行。
  • 一份提案只对应一处改动。不要打包，打包会被橡皮图章式地一路盖章通过。

审批队列就是人坐的地方

队列是一个小应用（或者你现有工具里的一个频道），由指定的人对每份提案批准、修改或驳回。只有批准之后，一个独立的、非大模型的服务才会用它自己那份范围极窄的凭据去执行改动。

这个执行器故意做得很无聊：按schema校验提案，重新读取当前值确认提案生成后没有变化，应用改动，再把结果写回队列。

审批权限沿用你现有的授权矩阵。如果某个采购员今天在ERP里改不了价格，那他也批准不了智能体提出的价格改动。

把闭环合上

驳回也是数据。把原因存下来（"供应商错了""已经处理过""政策不允许"），再喂回智能体在类似场景下的上下文里。几周之后，提案质量会上升，驳回率会下降——而且你有一份书面记录说明原因。

盯三个数字：每周提案数、批准率、批准所需时间的中位数。批准率低，说明智能体需要更好的上下文；批准时间长，说明提案写得不够清楚。

你能得到什么

  • 不用迁移。ERP仍是记录系统，什么都不用重建。
  • 可审计。每处改动都有一个问题、一份证据、一份提案和一个具名的批准人。
  • 安全的爬坡。从只读问答开始，给一个低风险动作加上提案，等数字说话了再扩。

从哪儿开始

挑一个你团队每天要问ERP十遍的问题（"这单到哪了？""这张发票为什么被冻结？"），只为它建读道，先上线，然后加第一种提案类型。

这套模式本身与厂商无关，在SAP、Oracle、Dynamics、Tally或自研系统上都能用。Suvishaz Tech的ERP Knowledge Agent采用的就是这个思路。