不止会聊：用“聊天”的方式“办事”
多数人一提到 AI 应用，不是 RAG 检索，就是简单聊天助手——回答能聊，但真正“做事”能力有限，难以深入业务流程。要让 AI 不止回答，还能查询库存、推荐商品、创建订单、确认支付，就必须让它安全、受控地调用企业现有的业务接口。
本文用一个简洁示例演示：在 JeecgBoot AI 应用平台里，借助“插件（MCP 工具）”机制，把业务 API 封装成可被 AI 选择与调用的“工具”，让导购型 AI 具备真实交易闭环能力：查询 → 推荐 → 下单 → 支付 → 查询订单。
1. 场景与目标概述
目标：构建一个“智能导购助手”，它能：
- 按需求检索商品列表并筛选。
- 查询指定商品库存。
- 创建订单并提示是否支付。
- 完成支付（扣减库存）。
- 查询订单详情与分类信息。
平台：JeecgBoot AI 应用平台（已内置示例接口）。
关键能力：通过“插件”暴露结构化工具，AI 根据提示词和上下文自主选择调用顺序，形成稳定的业务流程。
2. 业务接口清单（待封装为工具）
下述接口在 JeecgBoot 示例中已内置；我们只需按规范配置为插件工具。
list_products - 查询商品列表
请求：GET /demo/shop/products
参数：
category(可选)：分类（电子产品 / 图书 / 生活用品 / 食品）keyword(可选)：名称或描述关键词搜索 返回：商品数组（字段：id, name, price, category, description, stock）
check_stock - 查询商品库存
请求：GET /demo/shop/stock?productId=P001
参数：productId (必填)
返回：库存对象（productId, productName, stock, available）
create_order - 创建订单（不立即扣库存）
请求：POST /demo/shop/purchase
参数：productId(必填), quantity(必填>0), userId(可选)
返回：订单信息（id, productId, productName, quantity, unitPrice, totalAmount, status=pending, createTime）
confirm_payment - 支付并扣减库存
请求：POST /demo/shop/stock/deduct?orderId=O1001
参数：orderId(必填)
返回：扣减结果（orderId, productId, productName, deductedQuantity, remainingStock, orderStatus=paid）
get_order_details - 查询订单详情
请求：GET /demo/shop/order?orderId=O1001
参数：orderId(必填)
返回：完整订单对象
get_categories - 获取商品分类
请求：GET /demo/shop/categories
返回：分类名称数组
3. 为什么“插件（工具封装）”是关键？
AI 与业务结合的核心挑战：
- 安全边界：不能让模型随意构造危险请求。
- 语义到调用的映射：自然语言“我想买一个平板”如何匹配到
list_products？ - 调用顺序约束：必须先查列表 → 再查库存 → 再下单 → 再支付。
- 数据真实性：杜绝“幻觉”商品、价格、订单号。
插件提供：
- 工具注册（名称、描述、入参、出参）→ 让模型理解“能做什么”。
- 结构化参数规范 → 降低模型拼错字段概率。
- 系统级鉴权与域名控制 → 避免越权。
- 可视化维护 → 便于增删迭代。
这本质上就是“函数调用”范式在业务侧的工程落地：用有限、可信的动作空间取代无限自由的接口访问。
4. 实现方案总览
设计思路：预先在 JeecgBoot 中维护一个“购物业务插件”，把所有电商相关接口映射为工具，AI 应用引用该插件后即可执行购物闭环。
流程示意：
5. 创建插件（MCP 管理）
进入菜单：AI应用平台 → MCP管理 → 点击“新增MCP”。
在弹窗中填写：
| 字段 | 说明 |
|---|---|
| 名称 | 插件唯一标识（建议语义化，如 shop_assistant） |
| 类型 | 选择“插件” |
| baseURL | API 服务域名（为空则默认平台域名） |
| 鉴权方式 | token 或 apikey（系统自动在 Header 传递） |
| token值 | 可留空，留空则使用当前登录用户 token |
| 描述 | 简述用途，帮助模型理解适用场景 |
创建完成后进入插件详情页：
若未配置工具，AI 将没有可调用的动作，所以工具维护是“赋能 AI”的关键。
插件与 MCP 的区别与关系
这里容易混淆两个概念：MCP 本身是一套“协议规范”，而 JeecgBoot 的“插件”是平台侧对一组 HTTP 接口的快速封装与适配。理解它们的层次和演进关系，有助于后续扩展。
MCP（Model Context Protocol）是什么？
- 一套开放协议：统一定义“工具（function / action）”“资源（可浏览/检索的数据）”“提示词模板”等在模型上下文中的呈现与调用方式。
- 标准化交互形态：模型通过明确的 schema 了解可用操作，避免自由拼接不确定调用。
- 传输与实现解耦：协议不限定必须是 HTTP，也可以是 WebSocket、SSE 等；服务端只要按协议返回规定结构即可。
- 目标：让不同平台/模型对接同一能力时“零或低改造”，提升复用与治理。
JeecgBoot“插件”是什么？
- 产品级封装：面向已有 RESTful 接口做低成本映射，把每个接口注册为可被模型理解与调用的“工具”。
- 聚焦 HTTP 场景：当前形态主要支持标准的请求-响应（GET/POST 等），参数与返回结构在界面中配置。
- 快速落地：无需编写额外适配代码即可让业务 API 获得“被模型调用”能力。
- 内置鉴权与域名控制：提升安全边界管理与可视化维护效率。
什么时候选“插件”类型？（典型使用信号）
- 已有一组稳定的 RESTful 接口，希望“当天接入、当天可用”。
- 业务边界清晰（电商、工单、库存、审批等单域）。
- 调用模式为同步请求-响应，暂不需要事件订阅或长连接。
- 团队期望低学习成本与可视化维护。
什么时候考虑原生 MCP Server？
- 需要同时暴露“工具 + 结构化资源浏览 + 文件/文档检索”复合能力。
- 需要跨多系统聚合，含非 HTTP、消息队列、数据库直连等。
- 需要对不同模型（多家供应商）提供统一、可版本化的协议层。
- 需要更细颗粒的审计、回放、调用链追踪与配额治理。
简要对比（核心关注点）：
| 维度 | JeecgBoot 插件 | 原生 MCP Server |
|---|---|---|
| 接入速度 | 极快（界面配置） | 中等（需编码实现协议） |
| 能力范围 | HTTP 接口函数调用 | 任意协议下的多资源 + 函数 |
| 灵活度 | 中（以配置为主） | 高（自定义行为/流式/复合逻辑） |
| 维护门槛 | 低 | 较高 |
| 适合阶段 | 验证/初期 | 扩展/多系统融合 |
一句话总结：MCP 是“协议标准”，插件是“快速落地的实现形态”；前者解决跨平台一致性，后者解决业务接入效率。开始用插件并不阻碍未来演进为完整 MCP 生态。
6. 配置工具：字段与规范
添加工具时需填写：
- 工具名称：英文/数字/下划线，插件内唯一，例如
list_products。 - 请求方式：GET / POST / PUT / DELETE 等。
- 访问路径：必须以
/开头，如/demo/shop/products。 - 描述：告诉 AI 何时调用、用途是什么（尽量包含触发条件关键字）。
- 请求参数：
- 名称：与 API 字段一致。
- 描述：用途 + 注意事项（是否允许为空、取值范围）。
- 类型：string / integer / boolean / array 等。
- 传入方式：Raw(JSON)、Form-Data、Query、Path、Header。
- 是否必填：驱动 AI 正确补参。
- 默认值：可减少空值错误。
- 输出参数：定义返回结构字段，帮助模型引用真实数据而不是幻想。
示例界面：
将所有业务接口按上述格式录入：
提示：描述中适当加入“触发词”（如“推荐”“库存”“下单”“支付”），能让模型更准确匹配调用时机。
7. 在 AI 应用中关联插件
进入 AI 应用创建页面：
-
选择模型（尽量选能力较强的，直接影响工具调用正确率）。
-
点击“关联 MCP & 插件” → 添加刚创建的购物插件：
-
补充应用的基本信息、欢迎语、预设问题。
到此，AI 已“看得见”并“懂如何调用”这些业务能力。
8. 提示词设计策略
一个好的系统提示词 = 行为约束 + 流程顺序 + 失败处理 + 核心判断。下面给出示例（已适度精简/结构化），可直接使用再按需微调：
## 导购助手精简提示
角色：温和、真诚、贴近真人的导购，帮助选品、查库存、下单与支付；绝不虚构商品/价格/库存。回答只用自然中文，不展示内部过程，不输出 JSON/代码。
## 人格与语气
热心、礼貌、不过度重复；缺货直说并主动给替代；禁用“我是AI”等表述。示例：
- “我帮您查下库存，稍等哦～” “这款暂时没货，要不要看看类似的？”
## 不可逾越底线
1. 不编造：空结果必须如实说明，不造商品/价格/订单/库存。
2. 不泄露内部：不出现思考/Action/Observation字样。
3. 保持口吻：短句、自然、人类化。
4. 先确认意图：描述模糊时先问清类目/品牌/用途/预算。
## 工具调用核心逻辑
始终“先查再答”。凡涉及商品或购买均先调用 list_products；获取到商品后按需继续。
触发 list_products（任一满足）：出现商品名称/品牌/型号/类目/用途；询问价格/库存/推荐/折扣；明确购买意向（买/购/下单/订/入手/现货）；出现数量。模糊描述（“想买电脑”）也要查。重复出现商品名需重新查，禁止复用旧ID。
触发 check_stock：已有商品ID且询问库存/是否有货/能不能买/数量够不够。
触发 create_order：已完成 list_products+check_stock 且库存充足，并用户明确要下单（“就这个” “下单”）。
触发 confirm_payment：已有订单且用户明确支付（付款/支付/确认支付）。未确认不得调用。
触发 get_order_details：用户询问订单状态/详情。
禁止：未查直接推荐；使用历史商品ID；跳过中间步骤；支付前未询问确认。
## 失败与补救
list_products 为空：如实说明（“暂时没找到”）并主动引导提供更具体品牌/型号/预算；不得自行举例。库存不足：说明并可再查其它商品（重新调用 list_products）。
## 快速自检（任一不满足需补查）
1. 已调用最新 list_products？ 2. 所有商品/价格/库存来自最近结果？ 3. 下一步是否需库存/下单/支付？ 4. 步骤是否连续未跳？ 5. 空结果是否如实反馈？
## 数据真实性
所有信息必须来自最新工具返回；空结果的允许回复：
- “目前暂时没有找到这类商品～”
- “数据库里还没有这款，要不要我帮您看看类似的？”
- “抱歉，现在库存信息里没有记录。”
## 标准下单流程（严格顺序）
1. list_products → 拿商品ID或空结果终止。
2. check_stock → 库存不足提示并可重新查询；足够继续。
3. create_order → 返回订单号/商品名/总金额，询问是否支付。
4. confirm_payment → 用户确认后才支付并扣减库存。
5. get_order_details → 用户请求时查询并返回。
## 输出规范
自然中文、短句、不堆标点；不展示工具调用；所有描述源于最新工具数据；每次与商品相关回复前确认数据新鲜。
## 简化决策（内化，不输出）
收到消息→ 若含查询/购买意图→ list_products；空则反馈并询问细化；有商品且问库存→ check_stock；库存足且要下单→ create_order；有订单且确认支付→ confirm_payment；问状态→ get_order_details；其它闲聊→ 正常寒暄。
欢迎语与预设问题：
开场白
您好～我是您的智能购物助手，可以帮您挑选商品、创建订单并完成购买。
无论您想买电子产品、生活用品、图书还是食品，我都能为您快速推荐。
您想先看看哪一类商品？😊
预设问题
- 有哪些商品分类？
- 给我看看电子产品
- 有适合送礼的东西吗？
9. 测试与验证
启动会话，输入购买意向：
可以看到：
- 模型先列出商品（list_products）。
- 用户进一步确认后查询库存（check_stock）。
- 创建订单（create_order）并返回金额。
- 用户确认支付 → 支付扣库存（confirm_payment）。
- 可随时通过 get_order_details 获取状态。
所有环节的数据均来自真实接口，避免幻觉；流程严格受限于提示词与工具配置。
10. 常见问题与优化方向
| 问题 | 可能原因 | 优化措施 |
|---|---|---|
| 模型未调用工具 | 描述不清/缺触发词 | 在工具描述中补关键动词与场景词 |
| 参数缺失或类型错误 | 参数定义不充分 | 补充参数“是否必填”“示例值” |
| 跳过库存直接下单 | 提示词约束不足 | 强化“必须先 check_stock”语句 |
| 幻觉商品ID | 未强调“最新结果” | 在提示词加入“不可复用旧ID”规则 |
进一步扩展：
- 用户画像与推荐：增加“历史浏览/偏好”接口工具。
- 会话记忆：在系统侧维护最近一次商品集合 ID，避免重复查询。
- 权限控制：区分普通用户与管理员可调用的工具集合。
- 失败重试策略：接口超时时模型返回“稍后再试”而不是误判“无结果”。
- 审计与回放：记录每次工具调用及模型上下文，便于风控与回溯。
11. 本文小结
通过 JeecgBoot 的插件（MCP）机制：
- 用结构化“工具”把业务 API 封装给 AI。
- 用提示词约束调用时机与顺序，保障流程正确。
- 实现从“会聊天”到“能执行真实业务”的跃迁。
这套方式可推广到客服工单、供应链跟踪、合同审批、报销流转等任意需要“查询 + 决策 + 操作”闭环的场景。后续可以继续增强推荐策略、上下文记忆与安全审计。