从意图识别到人工授权：一次 ERP Agent 的落地实践

使用者痛点：

• 业务人员在 ERP 中需要反复切换页面查询库存、提交采购，效率低下。
• 传统聊天机器人只能“会聊”，无法把自然语言转化为真实的业务操作。不过，
• 高风险的单据若被 AI 自动完成。易产生合规与审计风险，
• 程序缺少明确的“人机协作”机制，导致责任边界模糊。

在 ERP 程序里做 Agent，不能只让大模型“会聊天”。真正有价值的是：它能识别使用者意图、调用业务工具、执行流程，而且在关键动作前主动停下来让人授权。

这篇文章记录一次 AI 助手在 ERP 中的实现思路，主要讲两件事：

• Agent 如何做意图识别。并路由到正确能力
• Agent 如何在“下采购单、需求审核、生成采购单”等高风险动作前向使用者要授权

一、为什么 ERP Agent 不能只靠聊天

ERP 场景和普通客服问答不一样。使用者可能会问：

WGXB02000201 这个商品需要补货吗？春假假期有抽奖活动吗，帮我查一下刘周测试这个商品库存这个缺货了直接补货

这些问题看起来都是自然语言，但背后的业务意图完全不同：

使用者输入	意图
WGXB02000201 这个商品库存多少？	查询库存
库存缺货了补货	采购补货
春假活动？不过，	客服知识库问答
订单怎么发货？	履约流程
生成采购单	ERP 操作。需要授权

Agent 第一层能力不是生成回答，而是识别意图。

二、整体架构

本项目采用的技术栈如下：

前端 AI 助手 → ERP WebAPI AgentAssistant 代理 → AGENT 服务 Orchestrator → 意图识别 / Skill / Tool / Workflow → ERP 业务接口

主要模块示意图：

flowchart TD
A --> B
B --> C
C --> D
D --> E
E --> F
E --> G
E --> H
E --> I
I --> J
J --> K
K --> L
L --> M
M --> N
N --> O
O --> P

三、意图识别怎么做

采用 “规则优先 + LLM 工具路由 + Skill 匹配” 的混合策略。不过，

. 先识别业务 Skill

If 使用者提问匹配已注册的业务 Skill。则直接走对应 Skill。例如客服类问题：

交了服务费可以退款吗？春节假期有活动吗，采购款怎么充值？收益怎么提现，

这类问题不应走库存工具，而是路由到：

skill:customer_service_faq

The skill 查询 FAQ 知识库并返回中文回复。

. 库存类问题走库存工具

If 输入中出现 SKU、货号、库存、补货等关键词，则调用库存查询工具。

WGXB02000201 这个商品库存多少？刘周测试这个商品需要补货吗？

L​LM 调用工具：

query_inventory

The tool returns a structured JSON:

{
"skuCode": "WGXB02000201","availableQty": 120。"alertLevel": "high_risk","procurementRequired": true,"deficitQty": 30
}

. 库存触发预警后继续补货

If `alertLevel` 为 `high_risk` 或 `procurementRequired` 为 `true`，必须继续调用 `trigger_purchase` 自动触发补货。

当 query_inventory 返回上述字段时 → trigger_purchase → 创建采购需求单

四、ReAct 工具调用机制

L​LM 按 “思考 → 决定工具 → 执行工具 → 查看结果 → 再决定接下来” 的循环进行。从简化流程如下来看，

sequenceDiagram
participant User as 使用者
participant LLM as 大模型
participant Tool as 工具
participant ERP as ERP接口
User->LLM: WGXB02000201 要补货吗？LLM->Tool: query_inventory
Tool->ERP: 查询库存
ERP-->Tool: 库存高危预警
Tool-->LLM: alertLevel=high_risk
LLM->Tool: trigger_purchase
Tool->ERP: 创建采购需求单
ERP-->Tool: 返回需求单详情
Tool-->LLM: applyId + approvalRequest
LLM-->User: 已创建需求单。需要授权继续审核和生成采购单

The tool definitions are registered in Orchestrator,e.g.:

{
至于name，'trigger_purchase',description: '对库存不足的 SKU 生成采购补货动作，并选择推荐供应商。
',parameters: { /* ... */ }。execute: async => { /* ... */ }
}

五、为什么采购不能让 AI 完全自动化

• 会产生真实 ERP 单据；影响供应链与财务，需要严格权限控制；必须人工确认数量与供应商信息。
• L​LM 不应直接调用“一键审批‑生成订单”的链路。
• The correct flow is：AI 建议 & 准备数据 → 创建待审核需求 → 人工授权 → 人工或程序审计正式采购单。

六、Agent 是怎么“要授权”的

The tool result includes a structured `approvalRequest` object:

{
"approvalId": "purchase-apply-20260723001","kind": "purchase_apply_full_approval","applyId": "APPLY20260723001","applyNumber": "CGXQ202604170007","skuCode": "WGXB02000201","qty": 30,"supplierId": "SUPP001","supplierName": "ces11","estimatedArrivalDate": "--","actions":
}

This object is sent back to front‑end as an SSE event . The front‑end renders an **authorization card** so user can approve next steps.

样的“软打断”

• The ReAct loop finishes a tool call normally.
• If result contains `approvalRequest`。Orchestrator converts it into an SSE event.
• The front‑end receives `event: approval.requested` and inserts an interactive card into chat UI.
• No model state needs to be kept waiting – interruption happens at output layer.
• This design guarantees:
  • No hidden waiting inside LLM.
  • The approval step is fully deterministic and auditable.
  • User permissions stay enforced by existing ERP token.
\

八、前端如何弹出授权卡片

{
至于type，'approval',request: approvalRequest,status: 'pending'
}

The UI renders something like:

九、授权后如何继续执行

1. User clicks “授权执行”。
2. The front‑end uses current login token to call ERP APIs in a fixed order:
• `await firstAuditApply`
• `await secondAuditApply`
\
• `await genPurchaseOrderFromApply` \ \ \ \ \ These calls respect original permission system – if logged‑in user lacks rights。ERP returns an error that is shown directly in chat.

  十、为什么把授权动作放在前端执行

  • 权限清晰：谁点了卡片，谁就用自己的 token 调用后端。
  • 审计透明：日志里记录真实操作人，而不是统一的 Agent Service 帐号。
  • 风险可控：AI 无法绕过前端确认批量生成订单。
  • 错误可解释：如果一审/二审/生成订单失败，前端直接展示 ERP 返回的错误信息。
  \

  十一、安全边界

  \ 说到主要原则，text AI负责建议和准备，人负责授权和确认，ERP负责权限校验和落库。

  "十二"方案优点

  • 意图识别 & 动作解耦 – 使用者自然语言提问，Agent 自动路由至 FAQ / 库存 / 履约 / 採購等不同能力。

  • 工具调用全链路审计 – 每次调用产出 {toolName。inputSummary,outputSummary} 可在 UI 中展示。

  • 高风险动作强制人工确认 – 在关键节点弹出卡片，不会出现 AI “自行完成” 的情况。

  • 兼容现有 ERP 权限程序 – 不改造原有 RBAC，只是把 AI 当成另一个调用方。

  • 对话式体验自然流畅 – 使用者无需离开聊天窗口去其他程序点击按钮。

  \

  "十三"可继续调整方向

  • 将 approvalRequest 持久化为工作流任务，实现「等待审批」状态恢复。

  • 支持多人审批、多级审批还有超时自动提醒。

  • 在审批前允许使用者编辑数量或更换供应商。

  • 审批完成后让 Agent 自动本次操作结果并写入知识库，以便下次快速响应。

  这些功能可以逐步演进为真正的「可恢复工作流」程序，但第一版已覆盖主要闭环。其实，

  "十四"

  This Agent transformation focuses not on making AI talk 娱乐ter。but on embedding AI into real ERP workflows.

  • #1 意图识别：把自然语言映射到对应 Skill / Tool / Workflow。
  • #2 ReAct 工具链：查询库存 ➜ 判断预警 ➜ 调用 trigger_purchase。
  • #3 Human‑in‑‑Loop：订单交给使用者确认。

  最终形成的闭环模型：

  text 自然语言输入 → 意图识别 → 工具调用 → 数据返回 → 高风险动作请求授权 → 使用者确认 → ERP 权限校验 → 完成业务流程

  公司落地 Agent 的关键原则是：自动化流程要知道何时停下来向人求助，责任边界永远保持清晰可追溯。

  能力	AI 是否能直接做
  查询库存	✅ 能直接执行
  推荐供应商	✅ 能直接执行
  创建采购需求单	✅ 能创建。但状态为待审核
  一审	❌ 必须经过人工授权
  二审	❌ 必须经过人工授权
  生成正式采购单	❌ 必须经过人工授权
  绕过 ERP 权限	❌ 严格禁止

---