ERP 接入智能体：只读查询与审批写入分离

把 LLM 接进 ERP，最难的往往不是让它查到订单，而是回答财务的追问：谁能保证它不会改掉已入账的发票？作者给出的方案是：模型直接读数据，修改只能提交提案，由人审批，再交给独立服务执行。

这套设计把「理解业务」和「执行变更」拆开了。它值得程序员花几分钟读，因为关键不在提示词怎么写，而在工具、账号和审批流程怎样限制模型的行动范围。

只读权限为什么不能靠提示词

ERP 是业务记录的权威来源。模型一旦拥有自由写入的能力，错误判断就可能变成真实业务记录；完全不给数据，它又只能猜。

作者把系统分成两条通道。读取通道允许查询主数据、未结单据、库存、账簿和状态字段，结果返回模型作为上下文。写入通道则放在 ERP 外面，模型只能往队列里提交结构化提案。

Agent 的工具集中，根本不应该出现 ERP 写入 API。

这里有两道不同的约束：不向模型提供写工具，同时让 ERP 账号也没有写权限。作者建议创建专用技术账号，只授予查看角色，对所有业务对象禁用创建和修改授权。

数据访问经过薄服务层，可以使用 OData、REST 或数据库视图，不让模型直接拼接原始 SQL。实体和字段采用白名单，薪资表、银行信息及个人信息默认排除。如果某类对象无法清楚配置为只读，就先不开放。

每次查询还要记录触发它的用户问题，以及模型实际看到的数据行。这样才能追查一次回答用了什么依据。仅记录「调用成功」，不足以解释模型为什么给出某个结论。

审批队列怎样把建议变成可控的修改

作者举了几类修改：释放被阻止的采购订单、更新交货日期、创建贷项通知单。模型遇到这些需求时，输出的应当是提案。

下面这段提案把一次交货日期调整变成了可审核的数据：

{
  "action": "update_delivery_date",
  "object": "PO 4500012345 / item 10",
  "current": "2026-11-12",
  "proposed": "2026-11-19",
  "reason": "Vendor confirmation email dated 6 Nov says dispatch slipped one week",
  "evidence": ["mail:8831", "po_history:4500012345"],
  "requested_by": "agent",
  "confidence": "medium"
}

要关注 current、proposed 和 evidence：它们让审批人看到改前、改后和依据。confidence 即使是 medium，也不能替代证据或审批。

作者坚持一条提案只包含一项修改，避免多个动作捆在一起，被整体放行。审批界面应让具名审批人能够批准、编辑或拒绝，不必为了理解修改内容再进入 ERP 查一遍。

通过审批后，由独立的非 LLM 服务执行。这个执行器持有范围受限的凭证，负责校验数据结构、重新读取当前值、确认提案生成后数据没有变化，再应用修改并将结果写回队列。

重新读取尤其关键。例如提案生成后，采购员已经调整了日期，执行器就不能继续照着旧值覆盖。原文要求检查变化，但没有交代冲突后的处理流程。

审批权沿用现有授权矩阵。某位采购员今天不能在 ERP 里改价格，也不能借审批 Agent 提案获得这项权限。

先验证一个高频问题，再增加一种修改

作者建议从团队每天会问十次的问题起步，例如「订单到哪里了」或「发票为什么被阻止」。先把这个问题需要的读取通道做出来，上线只读问答，再增加一种低风险提案。

这条路线保留 ERP 作为权威数据源，不要求迁移或重建系统。审计线索则串起用户问题、证据、提案和具名审批人。

队列需要持续记录三个指标：每周提案数、批准率、审批耗时中位数。作者认为，批准率低通常说明模型缺少上下文，审批耗时高则说明提案表达不够清楚。

拒绝理由也要保存，例如供应商选错、事项已处理、政策不允许，再用于类似任务的上下文。作者称，持续几周后，提案质量会提高、拒绝率会下降，但没有提供样本规模、具体数值或对照实验。

我的判断

我认同这套方案的权限边界。相比只在提示词里写「禁止修改」，它把约束落实到 ERP 角色、工具清单和独立执行服务，模型即使判断失误，也不能直接把建议写进业务系统。

但「人审批」能否有效，取决于人是否看得懂、看得过来。前端把修改前后值和证据展示清楚，只是起点。原文允许编辑提案，却没说明编辑后是否需要重新校验；执行失败后的重试、重复执行，以及状态检查和实际写入之间的并发问题，也没有展开。

三个指标适合观察趋势，却不能直接定位原因。批准率低，也可能是业务规则不完整；审批慢，也可能只是审批人忙。批准率高，不能单独证明修改正确。

原文称这是他们实践中采用的模式，并表示适用于 SAP、Oracle、Dynamics、Tally 和自建系统，但未展示各平台的接入与权限验证结果。它还明确披露，文章由 AI Agent 为 Suvishaz Tech 起草，并介绍了该公司的 ERP Knowledge Agent。可以借鉴架构，效果部分应当按经验主张看待。

能拿来做什么

• 为 ERP 问答接入 LLM 时，先选一个高频问题，列出所需实体和字段，用专用只读账号验证访问范围，再开放给模型。
• 用前端开发审批页时，把修改前后值、原因和证据放在同一处，每项修改单独审批，并保存审批人和拒绝理由。
• 用 Node 构建服务层时，将提案接收与 ERP 写入执行拆开；执行器校验结构、复查当前值，并沿用现有业务授权。
• 试运行时按周观察提案数、批准率和审批耗时中位数，同时抽查实际修改是否正确，再决定是否扩展动作类型。