ERP 中的 AI 智能体：给采购员更好的草稿，而非无限授权

周一采购会上，十四份建议订单等着审核。其中一行写着“12箱”，采购员本想买12件。每箱12件，建议就会买入144件。故事是虚构的，问题却很实际：软件只提出有用建议，还是能自行把建议变成对供应商的承诺？

采购员希望有人帮忙查缺货、准备单据，不想盯着每次敲键盘，也承担不起发货后才发现错误。合理的智能体落地，先要划清这个边界，而不是只看演示能否完成惊艳的任务。

这是运营 AI 系列第一篇。第二篇讲 MCP 连接，第三篇讲审批和审计控制。这里先判断哪些工作值得委派，以及如何证明结果可靠。

别只看“智能体”这个名字

AI 智能体可以为完成目标选择并调用工具，例如查询订单、检查收货、创建草稿或请求下一步。“Copilot”和“agent”是含义有重叠的产品标签。要看实际工具及执行权限，不能凭名字认定一个只说话、另一个才会行动。

计算、校验和可重复交易应使用确定的业务规则。语言模型可帮助理解混乱的供应商消息或解释异常，但不应是唯一计算器，也不应决定采购员有权买什么。如果固定流程已经很好地解决问题，再加智能体可能只有成本，没有有用的灵活性。

错误回答本身就可能造成损失或泄露数据。只读助手若泄露别的门店的私有价格，或者编造付款状态，同样有害。写权限增加另一层后果，但读取也需要控制。

按具体任务选择运行模式

评估数据敏感度、业务影响、对外承诺、操作量及恢复方式，而不只是有没有“撤销”。预留最后一件商品在技术上可以取消，却仍可能让真正买家错过购买。数千次小操作也可能累积成很大的风险敞口。

下列模式是与负责人约定的运行政策，不是法律风险分类，也不是自动晋级阶梯。草稿做得好，并不等于获得发送权限。

模式	适合工作	必要边界
读取并解释	允许访问的库存/发票证据	记录及字段范围、时效与输出隐私
准备	采购草稿、提醒或匹配异常	无隐藏后续动作；人工审核
依政策执行	明确获准的一项有限操作	当前授权、必要的确切审批、防重复
暂停并升级	歧义、拒绝访问或未批承诺	停止该操作；交给明确负责人

沿着采购订单走完整个流程

对这个虚构采购场景，先选一家供应商和一个产品系列。核对 SKU/变体、获批供应商、采购单位、币种、交期、可用库存、已有承诺和在途收货。同一产品可能有多个供应商及包装规格，不能强制每件商品只对应一家供应商。

工具应返回带时间的证据及明确数量：12件 = 1箱，而不是12箱。计算及数量限制由业务逻辑验证。换算不清、库存过时或供应商记录待解决时，交给采购员处理异常，模型不能编造缺失值。

草稿必须真的不产生执行后果。测试保存草稿是否会占用预算、发送邮件或触发其他流程。审核页应显示供应商、目的地、商品、数量/单位、单价、币种、税、总额及证据时间。授权采购员批准的是这一确切版本。关键字段变化或证据过期后，重新检查，必要时重新审批。

执行时再次核验当前权限和业务约束。只有系统确认已提交的结果，才能说采购订单已创建。若发给供应商是另一步，应单独记录发送结果。创建单据、发出单据与供应商接受，不是同一状态。

权限在对话之外强制执行

交互请求的有效权限，是请求者权限、智能体/工具范围与当前业务政策的交集。必须落实到记录及字段，而非只隐藏菜单；每次工具调用都应检查。一家门店的问题不能检索另一家的私有文档或缓存回答。

无人值守任务需要范围有限的服务身份、明确负责人及到期/复审机制，不能共用管理员，也不能无说明地继承某人的会话。提示词、检索文件、输出、日志及模型服务商访问应遵守同一数据政策。核查保留期、区域、分包处理者与训练条款；ERP 自托管不代表外部模型调用也留在本地。

供应商 PDF、客户消息及网页是证据，不是新的授权。发票中的一句话无权批准变更银行信息。OWASP 将过多工具、权限和自主性称为过度代理权。限制应在应用程序里强制执行，而非只写在提示词中。

先选审核目的清楚的工作

库存问答：按允许的库位/状态返回数量及证据时间。区分可承诺量与实物在手量，也区分估计与实际分配。

采购建议：准备有边界的草稿并解释输入。数量、供应商承诺及下达仍走获批流程。

发票异常：按约定容差比较发票、采购单和收货，考虑分批收货、币种及税。标记不确定的匹配，不要悄悄付款或入账。

逾期提醒：先核对到期日、争议及近期付款，向正确且获授权的收件人起草。此前草稿被接受，不足以证明可以无人值守发送；联系规则和升级限制依然适用。

商品文案：依据已核验属性起草。编辑检查语言、成分/安全声明、尺寸及保修。翻译应保持原声明含义，不应夸大。

工资发放、供应商银行变更、退款、全目录定价、删除及会计更正，需要明确的控制设计。有些企业早已用确定规则、审批及审计证据自动生成常规分录。问题并非一概禁止自动化，而是不能让概率模型对重大工作拥有开放式授权。

常态化前，先测那些难处理的情况

让厂商演示跨门店查询被拒绝、供应商文件内含恶意指令、审批后订单发生变化，以及权限过期。拒绝提示再好看，如果数据或操作已经泄出，也没有意义。

模拟订单已创建、确认消息尚未到达就超时。重试前先查已有操作/引用。防止重复；对可重试故障使用带抖动、有上限的指数退避，设置重试预算，并给未明结果指定负责人。不要盲目重放状态不明的采购、付款或退款。无效请求与权限拒绝需要纠正，不是反复重试。

为单次及累计金额、记录数、工具调用、运行时长和服务商支出设限。测试停止运行是否阻止新工作，同时保留进行中操作的结果供核对。记录操作者、委派范围、来源引用、拟议变更、审批/版本、工具结果及操作编号。限制日志访问并脱敏，不要把每份客户文件都复制进去。

要求简洁且有证据的解释，而非隐藏的模型思维链。核查谁能查看/导出证据、保留多久及如何调查事故。NIST AI 风险管理框架是自愿采用的组织参考，不是产品认证。

衡量试点时，别把采纳等同于正确

如有帮助，可把30/60/90天作为复审窗口，而非自动增加权限的时间表。从限定查询开始，再做有人审核的草稿。一次有限写操作仍需独立决定、故障测试和责任人。如果只做草稿经济效果最好，就维持这种模式。

教学例子中共200个案例：原样接受160份、修改30份、拒绝10份，原样采纳率80%。对已接受草稿独立抽样40份，发现2份实质性错误，即该样本的5%。这不能精确估计全部案例，但足以说明采纳不等于正确。纳入难例、多语言、拒答以及罕见但影响严重的失败。

下面的时间模型使用同一批200个案例的虚构测量。比较相同工作，审核、异常处理和持续支持都应计入。

同一批200个案例	分钟
基线：200 × 6	1,200
AI 辅助审核：200 × 3	600
额外异常处理	120
分摊到试点的设置/支持	90
辅助后总投入	810
净释放工作容量	390（6.5小时）

假设人工价值24/小时，6.5小时对应156的工作容量；再扣假设模型/工具费40，其他成本前分摊收益116。数值是无特定币种的教学单位，不是保证回报或现金节省，工资可能不变。还要跟踪周转时间、已核实错误、数据事故及客户/供应商结果。小试点零事故不等于零风险。

带着更具体的承诺回到周一

采购员现在收到十四份可审核建议。箱/件差异成为异常，不会趁大家睡觉直接把订单发给供应商。她更正源换算，重跑受影响建议并核验结果。主数据改善减少一种故障，不意味着下一次永不出错。

选产品前，用自己的权限及难例要求演示。StoreConsole Intelligence 导览便于了解产品，不证明所有流程与连接器都已启用。应在自己的安装中确认草稿、审批、执行及恢复的真实行为。

面向客户的 AI 应安排清楚告知并检查适用规则。欧盟《AI 法案》第50条对直接互动设有透明度义务，并规定范围和例外，并非每项内部 ERP 操作都适用同一规则。就业、信贷及其他敏感决策需另行评估。

有用的成果并不夸张：减少重复查找，让决策准备更充分，同时保有可核验证据和采购员能掌控的授权。

审阅于2026年11月5日。Anichur Rahaman 是 StoreConsole 创建者。采购场景、试点数量及成本模型均为教学示例。