"你们的AI Agent是挺聪明的，但它查不到我的库存、看不到我的订单、进不了我的ERP——那它在我公司里就是个摆设。"

这是上个月一个做汽配的客户跟我说的话。他说得对。

AI Agent真正的价值不在于"能聊天"，而在于能办事——能查数据、能调接口、能操作业务系统。这需要Agent和企业现有系统深度打通。

但系统集成恰恰是很多AI项目的最大拦路虎。这篇文章我把实际项目中积累的系统对接方案讲清楚，包括老系统没API怎么搞、安全怎么控、大概要多久。

---

一、AI Agent不接系统，就是个高级聊天机器人

先搞清楚一个概念：AI Agent的能力可以分为三层。

| 层级 | 能力 | 示例 | 需要集成？ |

|------|------|------|-----------|

| L1 对话层 | 回答问题、生成内容 | "退货政策是什么？" | 不需要 |

| L2 查询层 | 读取业务数据 | "我昨天的订单发货了吗？" | ✅ 需要（只读API） |

| L3 操作层 | 执行业务操作 | "帮我把这个订单的地址改成XX" | ✅ 需要（读写API） |

大多数企业做AI，只做到了L1——一个能聊天的知识库。这当然有用，但天花板很低。要让AI Agent真正产生业务价值，必须做到L2甚至L3。

> 系统集成的深度，决定了AI Agent在企业里的价值上限。

---

二、三种集成方式：API / 数据库 / MCP协议

方式1：API对接（最推荐）

这是最标准、最安全的集成方式。AI Agent通过Function Calling机制，调用企业系统的REST API或GraphQL接口来读写数据。

工作原理：

1. 用户在聊天框里说"帮我查一下订单号12345的状态"
2. AI Agent识别意图 → 调用"订单查询"Function
3. Function通过API请求ERP系统 → 返回订单状态
4. AI Agent把结果翻译成自然语言回复用户

优点： 安全（权限可控制在API层）、标准化、易于维护。

缺点： 依赖目标系统有开放API。

实现示例（LangChain Function Calling）：

`python

from langchain.tools import tool

@tool

def query_order_status(order_id: str) -> dict:

    """查询订单状态。输入订单号，返回订单详情。"""

    response = requests.get(

        f"https://erp.company.com/api/orders/{order_id}",

        headers={"Authorization": f"Bearer {API_TOKEN}"}

    )

    return response.json()

注册为Agent的Tool

agent = create_agent(tools=[query_order_status, ...])

`

方式2：数据库直连（Plan B）

当目标系统没有API但有数据库时，可以通过只读数据库账号直接查询数据。AI Agent生成SQL → 执行查询 → 返回结果。

优点： 不需要系统提供API，部署快。

缺点： 安全性风险高（必须严格限制为只读）、SQL注入风险、AI生成的SQL可能效率低。

> ⚠️ 数据库直连必须做到的安全措施：

> 1. 只给AI Agent分配只读权限的数据库账号（绝对不能有写权限）

> 2. 对AI生成的SQL做白名单校验——只允许SELECT，禁止DROP/UPDATE/DELETE

> 3. 设置查询超时（如5秒），防止AI生成低效SQL拖垮数据库

> 4. 敏感字段（如手机号）在查询结果返回前做脱敏

`python

安全的SQL查询方案：预定义模板 + 参数填充

SQL_TEMPLATES = {

    "order_status": "SELECT status, logistics FROM orders WHERE order_id = %s",

    "inventory": "SELECT product_name, stock FROM inventory WHERE sku = %s",

}

def safe_query(template_name: str, params: tuple) -> list:

    if template_name not in SQL_TEMPLATES:

        raise ValueError(f"Unknown template: {template_name}")

    cursor.execute(SQL_TEMPLATES[template_name], params)

    return cursor.fetchall()

`

方式3：MCP协议（新趋势）

MCP（Model Context Protocol）是Anthropic推出的AI Agent与外部系统交互的标准协议，类似于"AI世界的USB接口"。通过MCP Server，AI Agent可以标准化地访问各种数据源和工具。

优点： 标准化、可复用（一个MCP Server可以被多个Agent用）、社区生态在快速发展。

缺点： 协议还在早期阶段，生态不够成熟；对开发团队的技术要求较高。

---

三、常见企业系统的对接方案

| 企业系统 | 集成方式 | 难度 | 周期 | 关键注意事项 |

|----------|----------|------|------|-------------|

| 企业微信/钉钉/飞书 | 官方Bot API | ⭐ 低 | 1-2周 | 作为AI Agent的交互入口，是最先要接的系统 |

| OA审批系统 | API对接 | ⭐⭐ 中 | 2-3周 | 注意审批权限：AI只能查自己发起的审批 |

| ERP（用友/金蝶/SAP） | API或数据库直连 | ⭐⭐⭐ 高 | 3-6周 | ERP接口通常老旧且文档不全，预留更多时间 |

| CRM系统 | API对接 | ⭐⭐ 中 | 2-3周 | Salesforce/HubSpot等主流CRM的API较完善 |

| 邮件系统 | IMAP/SMTP或Graph API | ⭐⭐ 中 | 1-2周 | 建议只读邮件标题和摘要，不读取正文（隐私） |

| 自研/老旧系统 | 数据库直连或中间件 | ⭐⭐⭐⭐ 很高 | 4-8周 | 见下方"老系统没API怎么办" |

---

四、权限和安全：AI Agent不能当"超级管理员"

系统集成最大的风险不是技术问题，而是权限失控。AI Agent如果以管理员身份调用API，等于给每个员工都开了一个后门。

权限控制的四个原则

1. 用户身份传递：AI Agent调用API时，必须携带当前用户的身份信息，API层面做权限校验。张三问"我的工资"，AI只能查张三的工资，不能查李四的。
2. 最小权限原则：AI Agent只获得完成任务所需的最小权限。查订单状态只需要"订单只读"权限，不需要"修改订单"权限。
3. 敏感操作二次确认：涉及资金、合同、人事变动的操作，AI Agent在执行前必须让用户二次确认——"你确定要把订单12345的收货地址改为XX吗？"
4. 全链路审计：记录谁、什么时间、通过AI Agent做了什么操作，所有日志至少保留6个月。

数据脱敏清单

以下字段在传给大模型之前必须做脱敏处理：

• 手机号（138****1234）
• 身份证号（前6后4保留，中间星号）
• 银行卡号（仅显示后4位）
• 家庭地址（仅显示到区县）
• 薪酬数据（仅显示数值，不关联具体人员）

`python

import re

def desensitize(text: str) -> str:

    """敏感数据脱敏"""

    # 手机号脱敏

    text = re.sub(r'1[3-9]\d{9}', lambda m: m.group()[:3] + '**' + m.group()[-4:], text)

    # 身份证号脱敏

    text = re.sub(r'\d{17}[\dXx]', lambda m: m.group()[:6] + '**' + m.group()[-4:], text)

    return text

`

---

五、老系统没API怎么办？三种补救方案

这是很多传统企业最头疼的问题。ERP是10年前上的、OA是定制的、CRM是自己开发的——全都没有API。

方案A：数据库只读查询（推荐）

给AI Agent开一个只读数据库账号，直接查数据。能解决80%的"查数据"需求，但不能写数据。

成本： 1-2周，1名后端开发。

方案B：开发Adapter中间件（中等方案）

在老系统外面包一层Adapter服务，把老系统的数据库操作封装成标准REST API。

成本： 3-6周，1-2名后端开发。

额外好处： Adapter开发一次，以后其他系统也能用，相当于给老系统做了一个现代化接口层。

`python

Adapter中间件示例

from fastapi import FastAPI

import psycopg2

app = FastAPI()

@app.get("/api/legacy/orders/{order_id}")

def get_order(order_id: str):

    """将老系统数据库查询封装为REST API"""

    conn = psycopg2.connect(LEGACY_DB_DSN)

    cursor = conn.cursor()

    cursor.execute(

        "SELECT order_id, status, amount FROM t_orders WHERE order_id = %s",

        (order_id,)

    )

    row = cursor.fetchone()

    return {"order_id": row[0], "status": row[1], "amount": row[2]}

`

方案C：RPA模拟操作（不推荐）

用RPA工具模拟人工操作老系统的界面——自动点击按钮、填写表单、读取页面内容。听起来很美，但实际稳定性很差：界面一改RPA就挂、响应慢、无法处理异常情况。

仅在以下情况考虑： 老系统即将被替换（半年内）、且没有数据库访问权限、且需求非常低频。

---

六、集成案例：一个制造业客户的真实对接过程

去年帮重庆一家汽配厂做了AI Agent系统集成。

客户背景： 200人，有ERP（用友U8）、自研MES、企业微信。需求：让车间主管能通过企业微信里的AI助手实时查询生产进度、设备状态、订单交付情况。

集成路径：

1. 第1-2周：对接企业微信Bot API，让AI助手先能在企微里对话（L1层）
2. 第3-4周：对接ERP数据库（只读），AI可以查询订单状态和库存数据（L2层）。用友U8的API文档不全，最后选了数据库直连方案
3. 第5-7周：开发MES Adapter中间件。MES是自研的老系统，完全没有API。写了一个Adapter服务，把MES数据库里的生产进度数据封装成REST API
4. 第8周：联调测试 + 权限配置 + 上线

上线效果： 车间主管每天要打十几个电话问进度，现在在企业微信里@AI助手直接查。每天节省约1.5小时。更重要的是，信息获取从"找人问"变成了"自己查"，决策速度明显加快。

踩过的坑：

• ERP数据库表结构复杂，一个"订单状态"分散在5张表里，AI生成的SQL经常不准。解决方案：让后端开发写预定义的SQL模板，AI只负责选模板+填参数，而不是自由生成SQL
• MES数据实时性要求高，数据库直连查询偶尔超时。解决方案：加了一层Redis缓存，常用数据5分钟刷新一次

---

总结

• API对接是最推荐的集成方式，安全、标准、易维护
• 老系统没API时，数据库只读查询是最务实的Plan B
• 权限控制是系统集成最大的风险点，必须做到用户身份传递、最小权限、二次确认、全链路审计
• MCP协议是未来趋势，但目前生态还不够成熟
• 系统集成的周期和成本往往被严重低估，建议预留POC时间2倍以上的集成时间