一、背景：让 AI Agent 在企业业务系统中安全运行
随着大语言模型（LLM）和 AI Agent 技术的发展，越来越多的企业开始尝试将 AI 助手集成到现有业务系统中。
在制造业场景下，用户可以直接在 MES、ERP、WMS 等业务系统中，通过自然语言查询生产进度、库存情况、订单状态以及质量数据，而不必频繁切换系统或手动查找报表。
例如，用户登录 MES 系统后，在系统内置的 AI Chat 界面中输入：
查询今天各生产线的生产完成情况，并统计各生产线的完成数量。
AI Agent 接收到用户的问题后，需要理解用户意图，选择合适的 Skill，并调用 MES Business API 获取真实业务数据，最终将结果以自然语言形式返回给用户。
从业务角度看，这只是一次普通的 AI 问答。
但从技术架构角度看，它涉及多个系统之间的身份认证、访问授权、凭据传递以及业务 API 调用。
尤其需要解决以下问题：
- 用户已经登录 Business System，Chat System 是否需要用户再次登录？
- 如何让 Chat System 确认请求来自哪个用户？
- 如何让 AI Agent 调用业务 API 时继续遵循当前用户的权限？
- 如何避免将用户的长期 Access Token 直接暴露给 AI Agent？
- 如何防止 Skill 重复调用、越权调用以及凭据重放？
- 如何建立从用户提问到最终业务 API 调用的完整审计链路？
本文结合 AI Agent Architecture and Business API Invocation Flow V2.0 时序图，介绍一种面向企业业务系统的 AI Agent 集成架构。
该架构采用以下设计原则：
用户在 Business System 中完成登录，在 Business System 中发起 AI 对话；Chat System 负责对话管理，AI Backend 负责安全控制和业务代理，OpenClaw 负责 Agent 推理，Skill 负责封装业务能力，Business System 继续执行最终的业务认证与授权。
二、整体架构设计
整个系统包含五个核心组件：
- SSO：统一身份认证。
- Business System：企业业务系统。
- Chat System：AI 对话系统。
- AI Backend Service：AI 后端及业务 API 代理服务。
- AI Agent（OpenClaw）：负责理解用户意图并调用 Skill。
Skill 作为 AI Agent 与企业业务能力之间的接口层，根据业务域划分为 MES Skill、ERP Skill、WMS Skill 等。
2.1 SSO：统一身份认证
SSO（Single Sign-On，单点登录）负责用户身份认证。
用户通过企业统一身份认证系统登录 Business System。
登录完成后，Business System 根据自身的认证和授权机制，获得访问受保护业务 API 所需的访问凭据。
这里需要区分两个概念：
- OpenID Connect（OIDC）主要用于身份认证。
- OAuth 2.0 主要用于授权和访问令牌的管理。
ID Token 用于向客户端提供用户身份相关信息，Access Token 则用于访问相应的受保护资源。
两者的用途不同，不能直接互换。
在本文的架构中，用户的登录入口是 Business System，而不是 Chat System。
Chat System 不需要重新要求用户输入用户名和密码，而是通过 Business System 转发的可信身份凭据或经过验证的身份上下文，识别本次 AI 请求的用户。
2.2 Business System：用户入口与业务授权中心
Business System 是用户实际使用的企业业务系统，例如 MES、ERP 或 WMS。
它承担两个重要职责。
第一，作为用户的登录入口。
用户通过 SSO 登录 Business System，然后在业务系统内部使用集成的 AI Chat 功能。
第二，作为企业业务数据的提供方。
当 AI Agent 需要查询或操作业务数据时，最终仍然需要通过受保护的 Business API 完成调用。
例如：
- MES：查询生产订单、工单进度和生产报工记录。
- ERP：查询采购订单、销售订单和库存信息。
- WMS：查询库存、入库任务和出库任务。
- QMS：查询质量检验结果和不合格记录。
在这套架构中，Business System 不仅是用户入口，也是业务权限的重要边界。
AI Agent 不能因为接收到了用户的问题，就自动获得访问整个业务系统的权限。
2.3 Chat System：AI 对话入口
Chat System 是集成在 Business System 中的 AI 对话服务。
用户不需要离开原有业务系统，而是直接在当前界面发起自然语言请求。
例如：
查询生产订单 PO-20261024 的当前状态。
Business System 将用户的问题及必要的访问凭据转发给 Chat System。
Chat System 负责：
- 接收用户的聊天请求。
- 验证请求的身份和访问权限。
- 管理对话上下文。
- 将经过验证的请求转发给 AI Backend。
- 接收 AI Backend 返回的自然语言结果。
- 将最终回答返回给 Business System，由其展示给用户。
需要强调的是，Chat System 的身份认证不能仅仅依赖请求中携带了一个 Access Token。
它必须验证凭据的真实性、有效性以及适用范围，并确保请求确实属于已经认证的用户。
如果 Chat System 和 Business System 属于不同的信任域，还应通过明确的服务端认证机制保护系统之间的调用。
2.4 AI Backend Service：安全控制与业务 API 代理
AI Backend 是整个架构的核心控制层。
它连接 Chat System、OpenClaw 和 Business API，负责在 AI 推理与企业业务系统之间建立安全的调用通道。
主要职责包括：
- 验证来自 Chat System 的请求。
- 识别并绑定当前用户的可信身份。
- 创建服务端安全上下文。
- 生成一次性 Request ID。
- 将用户问题和必要的任务上下文传递给 AI Agent。
- 接收 Skill 发起的业务调用请求。
- 校验并消费一次性 Request ID。
- 恢复与请求关联的用户访问凭据。
- 代表用户调用 Business API。
- 记录业务调用审计信息。
- 将结果返回给 AI Agent 和 Chat System。
其中最重要的设计是：
AI Backend 代替 AI Agent 持有和使用用户的业务访问凭据，Agent 只通过受限的调用凭证请求访问业务能力。
这样可以避免将用户的长期 Access Token 直接暴露给 AI Agent或 Skill。
2.5 AI Agent 与 Skill：负责推理，不负责最终授权
AI Agent负责理解用户的自然语言问题，并根据任务需要选择合适的 Skill。
例如，用户要求查询生产订单状态，AI Agent选择 MES Skill，并生成结构化的业务调用请求。
MES Skill 将业务操作和参数提交给 AI Backend，而不是直接使用用户 Access Token 调用 MES。
因此，各组件的职责可以概括为：
| 组件 | 核心职责 |
|---|---|
| Business System | 用户入口、用户会话和业务 API |
| Chat System | 对话交互、请求接收与转发 |
| AI Backend | 安全上下文、调用凭证、代理访问和审计 |
| AI Agent(OpenClaw) | 意图理解、任务规划和 Skill 调度 |
| Skill | 业务能力封装和结构化工具调用 |
| Business API | 最终业务认证、授权和业务规则执行 |
三、完整调用流程
下面按照一次完整的 AI 问答，介绍各系统之间的调用过程。
第一步：用户登录 Business System
用户通过 SSO 完成身份认证，并进入 Business System。
Business System 根据既定的认证和授权机制建立用户会话。
例如：
User
|
v
SSO
|
| Authenticate User
v
Business System
|
| Establish User Session
v
Business Application
此时，用户已经处于 Business System 的登录状态。
用户不需要再单独登录 Chat System。
第二步：用户在 Business System 中发起 AI 对话
用户在业务系统内置的 AI Chat 界面中输入：
查询今天各生产线的生产完成情况。
Business System 将聊天请求转发给 Chat System。
根据实际的认证方案，请求中可以包含访问凭据，也可以携带经过认证的用户会话信息。
如果使用 Access Token 进行传递，则需要确保该 Token 的受众、有效期和授权范围符合相应调用要求。
特别需要注意，不能假定用于访问 Business API 的 Access Token 一定也可以直接用于 Chat System。
如果 Token 的受众是 MES API，那么 Chat System 不应将它视为天然适用于自身 API 的凭据。
可以通过专门的 OAuth 令牌交换、服务端身份绑定或其他明确设计的信任机制，解决不同系统之间的身份传递问题。
第三步：Chat System 验证请求并转发给 AI Backend
Chat System 收到请求后，首先完成必要的身份认证和访问控制。
验证通过后，将用户问题以及必要的身份凭据转发给 AI Backend。
整个调用关系如下：
User
|
| Ask a Question
v
Business System
|
| Forward Chat Request
| + User Access Token / Trusted Identity Context
v
Chat System
|
| Authenticate and Authorize
v
AI Backend
这里需要区分两个安全边界。
第一个是 Business System 到 Chat System 的请求边界。
第二个是 Chat System 到 AI Backend 的请求边界。
两个边界都需要进行相应的身份验证和访问控制，不能只验证用户最初的登录过程。
第四步：AI Backend 建立服务端安全上下文
AI Backend 收到请求后，根据可信的用户身份信息建立安全上下文。
例如：
{
"userId": "U10086",
"tenantId": "TENANT001",
"businessSystem": "MES",
"allowedOperations": [
"production-order.read",
"production-report.read"
]
}
以上字段仅为示例。
实际系统应根据企业的用户体系、组织结构和业务授权规则建立相应的上下文。
AI Backend 可以根据当前用户的身份和授权范围，确定本次 AI 任务允许使用哪些业务能力。
但需要注意，allowedOperations 不能直接来自 AI 模型的输出。
它应由可信的服务端策略决定，并在每次实际业务调用时再次校验。
第五步：AI Backend 生成一次性 Request ID
AI Backend 为本次任务建立服务端关联关系，并生成一次性 Request ID。
例如：
Task ID: task_20261024_001
User ID: U10086
Request ID: rq_7f4a9c...
Status: Active
Allowed Operations:
- production-order.read
- production-report.read
AI Backend 在服务端保存 Request ID 与对应安全上下文的关联。
AI Agent不需要获得用户的原始 Access Token，只需要获得完成当前任务所必需的请求上下文。
这里需要特别区分：
- Task ID：标识整个 AI 任务。
- Request ID：授权一次特定的业务代理调用。
- Trace ID：关联各服务之间的日志和调用链路。
如果一个 AI 任务需要调用多个 Business API，就不应将严格的一次性 Request ID 当作整个任务的通用凭证。
推荐为每一次业务调用签发独立的 Request ID，并让这些凭证共享同一个任务级安全上下文。
第六步：AI Backend 调用 AI Agent
AI Backend 将原始用户问题以及必要的任务上下文传递给 AI Agent。
例如：
User Query:
查询今天各生产线的生产完成情况。
Task ID:
task_20261024_001
Available Capabilities:
- Query production lines
- Query production reports
- Summarize production quantities
在这个阶段，AI Agent负责理解用户的真实意图，并决定需要调用哪些 Skill。
AI Backend 不应将用户的完整 Access Token 放入 Prompt，也不应把敏感凭据作为普通对话上下文传递给模型。
第七步：AI Agent选择 MES Skill
AI Agnet (OpenClaw) 识别出用户的问题属于生产报表查询，选择 MES Skill。
MES Skill 将自然语言任务转换成结构化业务操作。
例如：
{
"operation": "production-report.read",
"parameters": {
"productionDate": "2026-10-24",
"groupBy": "productionLine"
}
}
随后，Skill 通过受控接口请求 AI Backend 执行业务调用。
Skill 不直接访问 MES Business API，也不直接持有用户 Access Token。
第八步：Skill 调用 AI Backend Proxy
Skill 将 Request ID、业务操作标识和业务参数提交给 AI Backend。
例如：
POST /api/agent-proxy/invoke
Content-Type: application/json
请求体：
{
"requestId": "rq_7f4a9c...",
"operation": "production-report.read",
"parameters": {
"productionDate": "2026-10-24",
"groupBy": "productionLine"
}
}
AI Backend 根据预先配置的业务操作目录，确定该操作对应的 Business API。
例如：
Operation:
production-report.read
HTTP Method:
GET
Endpoint:
/api/production/reports
Required Permission:
production-report.read
Agent 不能自行指定任意目标 URL，也不能通过修改参数访问未经授权的 API。
第九步：AI Backend 校验并消费 Request ID
AI Backend 收到代理调用请求后，执行以下检查：
- 验证调用方是否为可信的 Agent 或 Skill 执行环境。
- 检查 Request ID 是否存在。
- 检查 Request ID 是否过期。
- 检查 Request ID 是否已被消费。
- 检查其关联的任务是否有效。
- 检查请求的业务操作是否被允许。
- 验证业务参数。
- 原子性地消费 Request ID。
- 获取服务端保存的安全上下文。
其中，一次性消费必须通过原子操作实现，实际实现中，还应明确凭证消费、业务调用和调用状态之间的一致性边界，尤其要考虑网络超时和业务操作重试的情况。
第十步：AI Backend 代表用户调用 Business API
完成校验后，AI Backend 从服务端安全上下文中获取适用的用户访问凭据，并调用对应的 Business API。
例如：
GET /api/production/reports?date=2026-10-24
Authorization: Bearer <user-access-token>
这一过程的关键是：
AI Backend 代理业务调用，但不取代 Business System 的最终授权。
Business API 仍然需要验证访问凭据，并根据用户权限执行相应的业务操作。
第十一步：Business API 返回 JSON 数据
Business API 验证请求并完成业务授权后，返回查询结果。
例如：
{
"productionDate": "2026-10-24",
"productionLines": [
{
"lineCode": "LINE01",
"completedQuantity": 1250
},
{
"lineCode": "LINE02",
"completedQuantity": 980
}
]
}
AI Backend 将业务数据返回给 AI Agent。
AI Agent根据真实数据生成自然语言回答。
例如：
今天 LINE01 已完成 1,250 件，LINE02 已完成 980 件，两条生产线合计完成 2,230 件。
AI Agent 负责组织和解释数据，而不是替代业务系统生成业务事实。
第十二步：响应沿原调用链路返回
最终响应按照原调用链路返回：
Business API
|
| JSON Response
v
AI Backend
|
| Business Data
v
AI Agent
|
| Natural Language Response
v
AI Backend
|
| Chat Response
v
Chat System
|
| Final Response
v
Business System
|
| Display Result
v
User
至此，一次完整的 AI 问答结束。
整个过程中，用户始终在 Business System 内完成交互，无须跳转到独立的 Chat System。
四、为什么采用 AI Backend 代理模式？
在企业 AI 集成中，一种常见方案是直接把用户的 Access Token 提供给 AI Agent，再由 Agent 调用业务 API。
这种方案实现简单，但会扩大敏感凭据的暴露范围。
本文采用 AI Backend 代理模式，将凭据管理和业务访问控制集中在可信服务端。
两种方案的主要区别如下：
| 对比项 | Agent 直接调用 Business API | AI Backend 代理调用 |
|---|---|---|
| Agent 是否持有用户 Access Token | 通常需要 | 不需要 |
| Token 泄露风险 | 暴露面较大 | 可以显著缩小暴露面 |
| 业务 API 调用审计 | 分散在各个调用方 | 可以集中管理 |
| API 白名单 | 需要各调用方遵守 | 可由 Backend 统一实施 |
| 参数校验 | 依赖 Agent 或 Skill | 可以在服务端强制执行 |
| 一次性调用凭证 | 通常需要额外设计 | 可以集中实现 |
| 业务系统最终授权 | 仍需执行 | 仍需执行 |
需要注意，代理模式并不意味着 Token 的风险完全消失。
AI Backend 本身成为了重要的安全边界，必须妥善保护令牌存储、服务端通信、权限策略以及调用日志。
五、一次性 Request ID 的安全设计
一次性 Request ID 是整个架构的重要安全机制。
它的核心作用不是取代 Access Token，而是避免将用户的长期访问凭据直接交给 AI Agent。
建议遵循以下原则：
5.1 服务端保存敏感凭据
Request ID 与用户身份、访问凭据及允许执行的操作之间的关联，保存在 AI Backend 的可信存储中。
Agent 只接收一次性调用凭证。
5.2 调用凭证必须具备明确的授权范围
Request ID 应绑定：
- 用户身份。
- 所属 AI 任务。
- 允许执行的业务操作。
- 必要的业务参数或参数约束。
- 有效期。
- 消费状态。
不能因为某个 Request ID 有效，就允许调用方执行任意业务 API。
5.3 每次业务调用独立消费
假设用户的问题需要查询三个不同的生产报表。
可以为每次调用分别生成 Request ID：
AI Task
|
+-- Request ID A -> Query Production Line 1
|
+-- Request ID B -> Query Production Line 2
|
+-- Request ID C -> Query Production Line 3
这样既能支持多个 Skill 调用，又能保持严格的一次性消费语义。
5.4 防止重复业务操作
一次性 Request ID 只能防止同一凭证被重复消费，不能自动保证业务操作只执行一次。
例如，AI Backend 已经成功提交一笔库存调整，但响应在网络传输过程中丢失。
如果 Agent 使用新的 Request ID 再次提交相同操作，仍然可能造成重复执行。
因此，对于具有业务副作用的操作，还应设计幂等键、业务流水号或业务状态检查。
5.5 不能忽略原始 Token 的授权范围
即使 Request ID 仍然有效，也不代表原始 Access Token 一定有效。
Business API 仍然需要验证 Token 的有效期、受众及权限。
对于运行时间较长的 AI 任务，还应考虑用户权限被撤销、访问令牌过期以及授权范围变化等情况。
六、总结
本文介绍了一种将 AI Agent 集成到企业现有业务系统中的安全架构。
它不是让用户登录独立的 Chat System，而是让用户继续在 Business System 中工作，并将 AI Chat 作为业务系统的一项能力提供。
整个调用链路如下：
User
|
| Login via SSO
v
Business System
|
| Chat Request + Access Token / Trusted Identity Context
v
Chat System
|
| Authenticated Chat Request
v
AI Backend
|
| Create Security Context
| Generate One-Time Request ID
v
AI Agent
|
| Invoke Skill
v
AI Backend Proxy
|
| Validate and Consume Request ID
| Retrieve Server-Side Access Credentials
v
Business API
|
| Authenticate and Authorize
v
Business Data
|
v
AI Agent
|
v
AI Backend
|
v
Chat System
|
v
Business System
|
v
User
这套架构的核心价值在于，将用户交互、AI 推理和业务访问控制进行合理分离。
- Business System 负责用户入口和业务能力。
- Chat System 负责对话交互。
- AI Backend 负责安全上下文、凭据管理和业务 API 代理。
- AI Agent 负责 AI 推理和任务规划。
- Skill 负责封装业务调用。
- Business API 负责最终的业务认证、授权和规则执行。
其中，一次性 Request ID 进一步缩小了用户长期访问凭据的暴露范围，并为每次 Agent 工具调用建立了明确的授权边界。
最终目标不是让 AI Agent 获得企业系统的全部权限，而是让它能够在经过验证、授权、限制和审计的条件下，安全地使用企业业务能力。
用户留在 Business System 中工作，AI Agent 在受控环境中执行任务，敏感凭据始终由可信服务端管理，业务系统继续掌握最终授权权力。
这就是面向 MES、ERP、WMS 等企业核心系统设计 AI Agent 集成架构时，应当坚持的基本原则。