给贾维斯接入第一个业务工具，从一个只读查询开始

准备给系统加 AI 时，团队很容易列出一张很长的愿望清单：查客户、查订单、写记录、做总结，最好还能直接完成整套流程。

真正开始接入，往往需要一个更小、更清楚的切口。比如，让助手根据设备编号，查询设备当前的维护状态。

这个任务的好处是容易讨论：要查什么、谁能查、结果在哪里，都能找到明确答案。本文以设备查询为设计方案，说明怎样为项速科技的贾维斯 AI 助手准备第一个业务工具。它不是内置连接器介绍，也不是已经跑通的实战记录。

先写出一句完整的工具职责

可以把职责写成：“按设备编号查询维护状态，不修改设备数据。”

这句话同时规定输入、目的和操作范围。开发者可以据此找到已有接口，业务负责人也可以判断这个工具是否适合提供给目标岗位。

一个过于宽泛的名称，例如“设备操作”，会让调用目的变得含糊。初期不妨用能表达动作的名称，再补充使用条件和异常说明。工具命名可以遵循团队规范，关键是与真实行为一致。

图 1：原创工具设计示意。设备查询为拟议接入场景，需要另行实现。

给输入和输出定下清楚的约定

以下是一份工具设计草案，可用于与业务系统负责人沟通：

项目	设计建议
工具名称	get_device_maintenance_status，仅作示例
必填输入	设备编号 device_id
身份来源	由可信认证链路传递并在服务端核对
正常返回	原接口已有的设备编号、维护状态、更新时间等字段
无记录	明确返回未找到，不拼凑相似设备的状态
无权限	明确拒绝，并由业务方确定用户可见的提示
操作范围	只读查询，不顺带创建或修改记录

不需要为了“方便 AI”就让工具接受任意 SQL，也不必把整个设备数据库暴露出来。围绕一个业务目的准备有限输入和必要输出，会更容易核对接入结果。

再决定怎样提供给贾维斯

工具确定后，由 MCP 服务封装对应业务接口。接入人员根据部署条件选择贾维斯支持的传输方式，配置服务地址或运行命令，并准备所需认证信息。

接下来在贾维斯中检查服务连接与工具列表，再将服务关联给设备助手 Agent。Agent 的任务说明应与工具职责一致，例如缺少设备编号时先提示补充，不把一般维护知识当作某台设备的实时状态。

如果还希望解释维护流程，可以另外准备相关手册并关联知识库。这样，设备状态来自业务接口，流程解释来自文档，信息来源容易分清。

先准备测试问题，再进行联调

可以请业务负责人提供一条可用测试记录，以及对应的原系统状态。验证问题不必很多，但应有区别：

1. 正确编号：是否查询到同一台设备，字段是否一致？
2. 缺少编号：是否要求补充，而不是随意选择对象？
3. 编号不存在：是否清楚表达没有记录？
4. 无访问权限：是否按原系统规则拒绝？
5. 服务异常：是否说明未完成查询？

图 2：原创接入验证建议。所有结果均需在实际环境填写。

联调时同时观察工具返回、助手表达和原系统记录。只有三者对应起来，才能判断这个任务是否完成，而不是仅凭回答语气作出结论。

一个小工具，可以让团队看清后续工作

跑通范围明确的查询后，团队会更清楚模型是否适合、身份怎样传递、哪些日志有用，以及用户真正需要哪些字段。后续新增工具，就可以继续沿用这套设计与核对方法。

贾维斯提供 MCP 服务管理、Agent 关联与 Vue 3 助手入口，使已有业务能力有了进入对话的组织方式。对于第一次尝试的团队，一个只读查询足以作为评估起点。

访问贾维斯 AI 助手官网，了解接入能力，再从你们已有接口中挑选第一个值得交给助手的任务。