Agent 接入 ERP 前，先列清哪些接口能查、哪些能改

Agent 接入 ERP 前，先把可查询、可建议和可写入分开，再确认每个接口代表谁执行。读到订单不等于有权改订单，生成采购建议也不等于允许提交采购单。本文适合希望把库存、订单或采购流程交给智能体辅助的企业，交付一份可以与 ERP 管理员一起填写的接口清单；示例不对应任何实际 ERP 产品或客户环境。

先选一条能说清业务结果的链路

不要以“对接整个 ERP”启动询价。选一个任务，例如销售查询合成订单 SO_DEMO_01 的交期，并在缺货时生成补货草案。输入包括订单号、请求人、所属组织和问题；输出先限定为可见订单信息与草案，不直接改变库存或财务状态。业务负责人确认结果含义，ERP 管理员确认这些数据在哪个接口获得，开发方再评估适配工作量。

把订单状态、物料编码、组织编码、币种、计量单位和时间含义写进字典。两个接口都叫数量，可能分别表示基本单位、采购单位或可用量；同一个客户编码也可能只在某公司账套内唯一。模型不能凭上下文补齐缺少的组织或单位。遇到歧义应向用户明确询问，或输出无法执行的原因，不能拿默认值完成一个形式正确的请求。

接口清单要记录动作而不只是地址

OpenAPI 3.1.1 规范提供描述 HTTP 接口、输入输出与安全机制的结构，可作为与 ERP 供应商交流的契约框架；它不证明某款 ERP 已经开放了这些能力。逐项登记接口用途、可用版本、请求字段、返回字段、权限方式、分页、错误码和副作用。目标系统没有官方接口资料时，应标为待核实，不能凭其他产品经验编造路径。

下载 ERP 读写接口盘点表，其中查询订单、创建采购草稿和调整库存是三项合成能力。查询订单只允许当前组织与负责范围；采购草稿要求授权用户确认；库存调整在本次试点中明确排除。这样供应商能够按实际能力报价，业务人员也知道“没有做库存修改”是约定范围，而不是演示遗漏。接口支持范围变化时，更新清单版本与验收任务。

身份映射放在服务端执行

企业入口的登录用户要映射到 ERP 内部身份、组织和数据范围。不能让模型从用户一句“我是采购经理”推导角色，也不能把管理员令牌交给模型再靠提示词限制用途。若接口只支持服务账户，适配层仍需校验请求人的业务权限，并把真实请求人作为审计上下文保存；是否允许代理执行还需由系统管理员确认。

查询返回也应进行字段与对象授权。用户无权查看成本价时，不把成本价送入模型以后再要求它别回答，而是在查询或输出映射阶段就排除。审批人与请求人是否可以是同一人、金额是否有额度、跨组织是否需额外批准，都写成可执行规则。只有在权限与确认均通过后，系统才可以调用允许的写入动作，模型的建议不能扩大动作范围。

用读、草稿和拒绝三类样例联调

合成订单查询应得到指定订单的交期与来源标识；同号但属于另一组织的订单应拒绝或按策略隐藏存在性。缺货建议输出物料、建议数量、计算依据和不确定项，尚未确认前不生成正式采购单。批准后的写入要带业务请求号并读取目标结果核对，确认写入的是同一组织、同一物料和已批准数量，不能只凭接口返回成功判断完成。

另外安排单位不匹配、物料不存在、记录已关闭和审批后数据变化。失败结果应能回到业务语言，例如“物料单位需要确认，草案未提交”，而不是只显示技术错误码。查询无结果也可能来自权限、归档或输入错误，应按目标接口语义分类；不要为了让回答更完整而跨账套搜索。任何补查都应维持原请求人的访问范围。

结果未知和回退提前设计

创建采购单超时不等于创建失败。先凭原业务请求号查询，查到则补记单号，查不到但无法证明未执行则进入人工核对。不要换号重发，也不要让 Agent 自动生成一张反向单据抵消未知结果。ERP 中的作废、冲销与撤回通常有各自业务含义，应由有权限人员按目标系统规则确认，不能用通用“回滚”按钮概括。

验收表同时记录业务结果与工程证据：谁发起、谁确认、使用哪个角色、输入摘要、接口回执和读回差异。演示环境中成功不代表生产接口、性能与权限配置已验收，正式环境要按授权再验证。对于无法提供稳定单号、状态查询或最小权限的接口，先保留人工提交，不能把端到端无人值守作为默认交付承诺。

另一个常见遗漏是测试环境与正式环境字典不同。试点时使用的物料编码、组织编码与状态映射，在正式接入前应逐项复核，并由业务管理员批准切换清单。测试接口返回完整数据，不证明生产账户具有相同范围。把环境差异登记成依赖，而不是临上线才靠开发者临时改值。

可从流程自动化专题与平台能力边界理解方案位置，接口复杂项目可查看系统集成服务。如需评估具体 ERP 接入，请通过定制咨询提供脱敏流程、接口资料、组织权限和一个可验收任务，先明确能查、能建议和能改的边界。