不要让智能体直接调用 CRM：业务系统 API 接入必须加这一层安全预检

在 CRM、OA、工单系统中接入智能体，最危险的做法是：

自然语言 -> 模型 -> 直接调用业务 API

这条链路少了身份、租户和权限控制，也没有解决参数错误、重复请求和高风险操作确认问题。

更适合生产环境的方式是：

自然语言
  -> 业务后端提取上下文
  -> 智能体安全预检
  -> API Gateway
  -> 业务系统

智能体不应该成为权限中心。它可以理解请求、检查字段、识别风险，但最终授权必须由业务系统后端完成。

1. 用物业工单做一个最小 Demo

本次在 Haoee 上搭建了“物业工单接口安全校验助手”。

它面向物业 CRM、OA 和工单系统接入前的安全预检，输入字段包括：

• 租户 ID；
• 用户 ID；
• 用户角色；
• 工单号；
• 操作类型；
• 查询条件；
• 分页参数。

输出只有三种方向：

• 允许进入人工确认；
• 待补充；
• 阻断。

当前 Demo 使用 deepseek-v4-pro，编排为开始节点和安全预检节点。

没有接入真实工单 API，也没有保存 Token。这样做是为了先验证安全边界，而不是在 Demo 阶段直接操作客户数据。

2. 预检节点应该检查什么

动作识别

将请求区分为：

query
create
update
assign
delete
export
permission_change

动作不是普通文本标签，而是后续权限控制的基础。

参数完整性

查询工单至少需要：

{
  "tenant_id": "tenant-demo-001",
  "user_id": "user-1001",
  "ticket_id": "T20260804001",
  "action": "query"
}

如果用户只说“帮我看看最近的工单”，智能体不能自行编造租户或工单号，而应返回缺少字段。

风险分级

建议按以下方式处理：

3. API 接入不能只看 Token

很多项目把“有 Token”当成“安全”。

实际上还需要考虑：

• Token 是否最小权限；
• 是否按租户隔离；
• 是否支持过期和轮换；
• 是否记录调用人；
• 是否限制来源；
• 是否防重放；
• 是否限流；
• 是否能追溯请求和响应。

令牌不应进入提示词，也不应让模型直接生成。推荐由后端安全存储，智能体只获得受控工具，不接触原始凭证。

4. 工具调用的参数设计

工具接口应该使用明确的 Schema：

{
  "name": "query_ticket",
  "parameters": {
    "tenant_id": {
      "type": "string",
      "required": true
    },
    "ticket_id": {
      "type": "string",
      "required": true
    },
    "page_size": {
      "type": "integer",
      "minimum": 1,
      "maximum": 100
    }
  }
}

服务端还要二次校验：

• 参数类型；
• 字段长度；
• 枚举值；
• 对象归属；
• 查询范围；
• 用户权限。

模型输出结构正确，不代表业务请求一定合法。

5. 当前 Demo 的测试记录

准备了三类测试：

• 完整参数的只读查询；
• 缺少身份和租户参数的查询；
• 普通客服尝试修改状态和派工。

实际测试没有进入模型推理，返回模型路由错误：

未找到匹配的 LLM 接口路由：path=/v1/responses

所以目前不能声称安全判断已经通过。这个 Demo 的实际状态是：

• 配置完成；
• 编排保存完成；
• 智能体发布完成；
• 端到端测试受模型路由影响。

修复路由后，应重新验证正常请求、缺参请求和高风险请求，并把结果记录到交付验收表中。

值得注意的是真实项目其实应由交付伙伴把平台智能体与客户后端、网关、权限系统和审计系统组合起来。