答案摘要：工作流智能体调用 ERP 接口时，应把“能不能调用”和“同一请求能否重复执行”拆开设计。智能体只负责在限定步骤中提出结构化参数，权限服务根据用户、部门、业务对象和审批状态做服务端判断，ERP 写入接口则使用业务单号、流程实例和动作类型组成幂等键。这样才能在人工确认、接口超时或重复回调时，避免越权写入和重复建单。
先划清智能体、工作流和 ERP 的责任
工作流智能体不是 ERP 的超级账号。它可以根据知识库和当前流程提取字段、解释缺项、生成待审核动作，但不应绕过 ERP 原有的角色、组织、金额和状态校验。建议把链路拆成四层：智能体负责理解与建议，工作流负责节点、分支和超时，权限服务负责判断操作者与工具范围，ERP 负责最终数据校验和落库。
例如“创建采购申请”可以由智能体从邮件或表单中提取供应商、物料、数量和预算科目，但提交前仍要检查申请人所属部门、预算期间、供应商状态和审批规则。涉及付款、库存、合同生效或客户资料的动作，应设置人工确认节点，并把确认人、确认时间和看到的参数版本写进审计记录。
工具权限要按动作和数据范围拆开
不要只给智能体一个名为 erp.write 的宽权限。工具目录应列出动作、对象、字段、前置状态和允许的调用来源。查询采购单、创建草稿、提交审批、撤回申请和修改收货信息，虽然都属于采购流程，但风险和授权边界不同。
| 权限维度 | 需要明确的条件 | 服务端检查 |
|---|---|---|
| 身份 | 当前用户、应用身份、代理关系 | 校验会话和代理授权，不接受模型自行声明的身份 |
| 组织 | 部门、门店、项目或租户 | 将对象归属与数据范围绑定，禁止跨范围读取 |
| 动作 | 查询、草稿、提交、审批、撤回 | 按动作授予，写操作默认进入流程节点 |
| 字段 | 金额、供应商、收货地址、客户资料 | 按敏感级别限制读取、修改和导出 |
| 状态 | 订单或申请当前阶段 | 只允许从规定状态进入下一状态 |
权限判断必须发生在工具网关或业务服务端，前端隐藏按钮、提示词约束和模型自报角色都不能替代服务端校验。拒绝时返回可供流程处理的错误类型，例如“需要人工审批”“对象不属于当前部门”或“状态已变化”，不要把权限细节直接拼进面向客户的回答。
幂等键要覆盖业务动作而不是只看请求 ID
网络重试、队列重复消费和 ERP 回调都可能让同一个动作到达多次。只用每次请求自动生成的 request_id 无法识别业务重复；应根据动作定义稳定的幂等键。创建单据可使用“租户 + 流程实例 + 节点动作 + 业务对象版本”，提交审批可使用“单据号 + 审批轮次 + 动作类型”，回写外部单号则要同时保留来源系统和外部事件编号。
落库时先在幂等记录表上建立唯一约束，再执行业务写入。首次请求保存参数摘要、权限判断、操作者和结果；重复请求如果参数摘要相同，返回原结果或处理中状态；如果同一幂等键对应的参数不同，应拒绝执行并进入人工核对。幂等记录不能只保存成功，失败原因、超时和人工重试也要有状态，便于判断是否可以安全再次执行。
人工确认、超时和补偿要成为流程状态
工作流节点不能把“模型已经给出答案”当作“业务已经完成”。涉及金额、库存、合同、客户资料或外部通知的动作，应明确待确认、已确认、执行中、成功、可重试失败、需人工处理和已撤销等状态。人工确认时展示的字段应来自即将提交的参数版本，确认后若原数据已变化，服务端要重新做权限和版本校验。
接口超时不等于 ERP 没有写入。流程应先查询幂等键或业务单号，再决定重试；无法确认时进入人工处理队列，不直接再次创建。对于已成功但回调丢失的情况，用对账任务补齐状态；对于部分成功的多系统动作，记录每个子动作的结果和补偿方式，不能用一句“整体失败”掩盖已经发生的写入。
上线前的工具调用验收清单
- 普通员工、部门负责人和代理账号分别调用同一工具，数据范围和审批节点是否符合预期。
- 重复发送同一流程事件、队列重复消费和超时后重试，是否只产生一个 ERP 业务结果。
- 参数在人工确认后被修改、ERP 状态已变化或权限被撤销时，服务端是否拒绝旧版本执行。
- ERP 返回限流、鉴权失败、字段校验失败和未知超时时，流程是否进入不同的处理状态。
- 审计记录能否还原用户、智能体版本、工具名称、参数摘要、权限判断、幂等键和最终结果。
- 切换到只读模式或关闭某个工具后，已有流程是否按约定暂停、补偿或转人工。
如果 ERP 没有稳定的业务单号、状态接口或回查能力，先不要让智能体直接执行写操作。可以先接入只读查询和草稿生成，收集真实字段、异常码与人工处理时间，再决定是否开放提交或审批工具。聚匠科技可结合工作流智能体、AI 智能体、企业知识库 RAG和大模型私有化部署，把权限、工具目录、日志和回滚边界纳入同一套交付验收。
