把 AI 接入软件：从“会聊天”到“能干活”的实战教程

现在接入 AI，已经不是单纯在软件里加一个聊天框，而是要让 AI 理解业务、调用工具、执行流程、返回结果。下面这篇教程按“最小可落地”的方式整理，适合直接改造成博客正文。

一、先搞清楚：AI 接入软件到底在做什么

传统软件是“人点按钮 → 程序执行固定逻辑”。
AI 接入后，流程会变成：

用户输入目标 → AI 理解意图 → 选择工具 → 执行操作 → 校验结果 → 输出最终内容

所以核心不是“接一个大模型”，而是把模型放进一个可观测、可控制、可回滚的工作流里。

二、整体架构：四层就够了

推荐路径：

text

编辑

1用户请求
2  ↓
3意图识别 / 任务拆解
4  ↓
5检索业务知识 / 查询系统状态
6  ↓
7AI 选择工具
8  ↓
9执行工具：查库、发邮件、调用 API、生成代码
10  ↓
11校验结果
12  ↓
13返回用户

三、关键机制：Function Calling 和 MCP

Function Calling：让 AI 学会“调函数”

模型本身不能直接访问你的数据库、ERP、CRM 或本地文件。
Function Calling 的作用是：把业务函数描述成模型能理解的工具，让模型输出结构化调用指令。

例如：

json

编辑

1{
2  "name": "query_order",
3  "arguments": {
4    "order_id": "ORD-20261026-001"
5  }
6}

模型不会直接查库，而是告诉应用：“我应该调用 query_order，参数是订单号。”应用收到后，再去真正执行。

MCP：把工具标准化

不同平台的 Function Calling 格式不完全一致，工具接入容易变成“每个模型一套适配”。MCP，即 Model Context Protocol，提供了一套更统一的工具通信方式。

它的核心角色很简单：

• MCP Server：暴露工具，比如查订单、读文件、调用第三方 API。
• MCP Client / Agent Runtime：发现工具、转发调用、把结果还给模型。

典型链路：

text

编辑

1MCP Server 暴露工具
2  ↓
3Agent Runtime 拉取工具列表
4  ↓
5Runtime 转成当前模型的 Function Calling 格式
6  ↓
7大模型决定调用哪个工具
8  ↓
9Runtime 通过 MCP 调用真实工具
10  ↓
11结果回传给大模型继续推理

这样做的好处是：工具层和模型层解耦。以后换模型、加工具、接新系统，都不需要重写整套逻辑。

四、最小可运行示例：订单查询助手

假设你要在内部系统里接入一个“订单查询 AI”。

1. 定义工具

python

编辑

1def query_order(order_id: str) -> dict:
2    # 实际项目中替换为数据库查询或内部 API
3    return {"order_id": order_id, "status": "已发货", "amount": 299.0}

2. 给模型提供工具描述

python

编辑

1tools = [
2    {
3        "name": "query_order",
4        "description": "根据订单号查询订单状态和金额",
5        "parameters": {
6            "type": "object",
7            "properties": {
8                "order_id": {"type": "string", "description": "订单号"}
9            },
10            "required": ["order_id"]
11        }
12    }
13]

3. 让模型决定要不要调用

用户问：

帮我查一下订单 ORD-20261026-001 的状态。

模型可能返回：

json

编辑

1{
2  "tool_calls": [
3    {
4      "name": "query_order",
5      "arguments": {"order_id": "ORD-20261026-001"}
6    }
7  ]
8}

4. 应用层执行工具

python

编辑

1result = query_order("ORD-20261026-001")

5. 把结果还给模型生成回答

模型基于真实数据输出：

订单 ORD-20261026-001 当前状态为“已发货”，金额 299 元。

这一步很关键：不要让模型凭空编业务数据，所有事实信息都要来自工具返回结果。

五、进阶：用工作流把 AI 变成“员工”

简单场景可以用单次 Function Calling；复杂业务最好用工作流。

常见节点：

• 意图识别：判断用户是要查询、创建、修改，还是咨询政策。
• 知识检索：从文档库、数据库、向量库里取上下文。
• 工具执行：调用 CRM、ERP、工单系统、代码仓库。
• 条件分支：如果订单已取消，就不再执行退款。
• 人工确认：涉及删除、转账、发布时，必须加审批。
• 反思校验：让模型检查输出是否符合业务规则。

一个内容生成工作流可以这样设计：

text

编辑

1输入选题
2  ↓
3检索资料
4  ↓
5生成初稿
6  ↓
7自检：事实、结构、语气
8  ↓
9修改
10  ↓
11输出终稿

如果接入 MCP，资料检索、CMS 发布、图片生成、视频脚本输出都可以变成标准工具。

六、接入步骤清单

1. 选一个具体任务
   不要一上来做“全能助手”，先从“查订单”“生成周报”“处理工单”这类明确任务开始。

2. 列出可用工具
   哪些 API、数据库、文件、第三方系统可以被调用？每个工具的输入输出是什么？

3. 封装成工具接口
   工具必须稳定、幂等、可日志化。AI 调用失败时，要有明确错误码。

4. 设计工作流
   确定哪些步骤必须确定执行，哪些步骤交给模型决策。

5. 接入模型
   通过 Function Calling 或 MCP 把工具注册给模型。

6. 加安全边界
   敏感操作要限权、限频、限范围；高风险动作必须人工确认。

7. 加观测和日志
   记录每一步：模型看到了什么、调用了什么、返回了什么、为什么失败。

8. 持续评估
   用真实用例测试成功率、延迟、成本和错误类型。

七、容易踩的坑

• 把 AI 当数据库用：模型不应记忆关键业务事实，事实必须来自工具。
• 工具描述写得太模糊：模型选错工具，通常是因为工具说明不清。
• 没有超时和重试策略：外部 API 失败会导致整个流程卡死。
• 缺少人工兜底：涉及资金、发布、删除、外发内容时，必须保留人工审核。
• 只测 happy path：要专门测试参数缺失、权限不足、数据为空、网络超时等异常。