已有业务 API，怎样让 AI 用起来？贾维斯 MCP 接入的四个环节

企业系统往往已经有不少接口：查询工单、读取产品资料、获取设备状态。给 AI 增加业务能力时，开发团队自然会问：这些接口能不能继续使用？

可以从一层面向助手的工具封装开始。把接口用途、输入条件和返回内容说明清楚，再通过 MCP 服务提供给贾维斯，已有业务接口就有了进入对话任务的路径。

项速科技的贾维斯 AI 助手提供 MCP 服务管理、工具发现和 Agent 资源关联。本文以只读的工单查询为方案，梳理接入工作应怎样展开。工单工具需要由接入方实现，文中的链路不是现成客户案例。

第一环：把业务接口变成一个明确的工具
“查询信息”太宽泛，“根据工单编号读取当前状态与负责岗位”就具体得多。

设计工具时，先确定它回答哪一个问题。对于工单查询，可以要求输入工单编号，返回工单状态、负责岗位和最近更新时间。字段仅是设计示例，应按原系统实际提供的数据调整。

接口设计要点 工单查询方案中的安排
用途 查询指定工单当前处理情况
输入 工单编号；访问身份由可信服务链路处理
输出 原系统实际提供的状态与相关字段
异常 区分记录不存在、无权限和服务暂不可用
副作用 保持只读，不在查询中顺带修改记录
工具说明要让模型理解什么时候可以使用它，也要让开发者能核对调用有没有越过原定职责。

第二环：让贾维斯后端连到 MCP 服务
贾维斯的 MCP 配置支持 stdio、sse、streamable-http。选择方式取决于工具的部署形态与服务端支持情况。

本地进程式服务需要填写可执行命令、参数和环境配置；这里的“本地”指贾维斯后端所在环境。远程服务则需要填写地址，并按服务要求处理请求头、认证与网络访问。

业务API进入贾维斯的接入过程

图 1：原创接入路线图。四个环节是本文建议的推进顺序，不是已完成操作记录。

保存服务配置后，应先进行连接测试，再查看和刷新工具列表。连接能建立，只说明其中一段链路成立；工具是否完整、参数是否正确，还要继续检查。

若通过自定义管理界面调用贾维斯接口，也要遵守当前前后端的数据约定。例如 MCP 配置中的参数、请求头和环境变量，在组件中以对象或数组组织，提交时会经过序列化处理，不能想当然地照搬第三方客户端的整段配置。

第三环：把工具交给负责这项任务的 Agent
MCP 服务进入平台后，还需要与具体 Agent 建立关联。

可以为工单助手写清职责：依据工单编号查询状态，缺少编号时提示补充，服务异常时说明查询未完成。再将所需 MCP 服务关联给它，并配置能够完成工具调用的模型。

这里有三种不同的准备：平台知道服务在哪里，Agent 知道自己能使用哪些资源，业务系统知道这次访问属于谁。它们需要分别落实。

第四环：用业务记录核对结果
第一次联调适合使用专门的测试记录。开发者先记下原系统中的状态，再从助手入口提出查询，检查工具是否被调用、参数是否正确、返回内容是否对应同一条记录。

接入验证的三个检查点

图 2：原创验证建议。尚未提供本轮真实调用结果。

接着补充异常情况：输入不存在的编号、使用无权访问的记录、暂时不可用的服务。正常返回与异常表达都清楚，接入才更适合交给实际使用者。

贾维斯已有调用事件与 MCP 调用日志的实现，可用于接入后的排查。对业务人员而言，最重要的仍是看到正确对象的真实状态；对开发者而言，日志能帮助定位问题发生在哪一段链路。

完成这些准备，助手就能围绕已有系统增加一种交互方式。业务规则继续由原系统执行，贾维斯负责组织用户问题、Agent 和工具之间的配合。

如果你们已有可调用的业务 API，可以访问贾维斯 AI 助手官网，从一个范围明确的只读工具开始评估接入。