把 API 地址交给 AI 工作台，还不等于把业务能力交给 AI。一个可用的 MCP 工具需要清楚说明它解决什么问题、接收哪些有边界的参数、成功时返回哪些可核对的事实、失败时如何表达，以及版本变化如何处理。身份与原系统权限仍须单独验收。
近期观察：接入入口增加，工具契约更重要
截至 2026 年 10 月 5 日，检索 WorkBuddy、千问办公、豆包工作近 24 小时、72 小时及 7 天的公开资讯，未发现三者足以单独成篇的重大版本发布。本文是近期观察。蓝凌 2026 年 9 月 30 日的方案说明提到将流程、公文与会议能力封装为 Skill，接入 WorkBuddy、千问办公、豆包工作等桌面智能体。它展示了多入口调用业务能力的方向，但不能据此推断各产品对任意企业 API 都有相同的调用表现。
WorkBuddy 官方更新日志（最近所列 2026 年 9 月 21 日版本）涉及连接器授权和工具显示；千问办公官方客户端更新日志（2026 年 9 月 23 日版本）记录连接器相关优化。豆包工作在本次检索窗口内未见可核验的重大新版本。三者各有产品定位，企业应在目标版本和业务场景中实测工具发现、参数传递与结果呈现，而不是凭某一端的演示推断另一端。
什么叫“工具契约”
MCP 2025-06-18 工具规范规定了工具名称、描述、inputSchema，并允许用 outputSchema 描述结构化结果；执行错误可通过 isError 表达。协议给出的是机器可理解的外形。企业仍需定义字段的业务含义、权限边界、数据时点和错误恢复方法。
例如，ERP 已有一个“按订单号查询订单”的 REST API。若直接发布为“调用接口”，模型可能不知道订单号是否包含组织前缀、返回金额是否含税、取消单是否应显示、没有权限与订单不存在是否要区别处理。工具契约要把这些约定写进能力定义，并由服务端执行校验。下面是用于说明方法的假设场景，不是产品演示或客户案例。
| 契约要素 | 应明确的内容 | 验收问题 |
|---|---|---|
| 工具用途 | “查询当前员工有权查看的订单状态”，限定只读、对象和结果 | 模型能否区分查询与修改订单？ |
| 输入 | 订单编号格式、必填项、允许的组织范围和最大查询范围 | 缺字段、错格式、越范围时是否被拒绝？ |
| 输出 | 订单状态、更新时间、来源系统、必要标识与可解释单位 | 员工能否回到 ERP 核对同一条记录？ |
| 错误 | 参数无效、无权限、记录不存在、上游超时分别处理 | AI 会不会把“查不到”误说成“没有订单”？ |
| 变更 | 字段含义、可选值、版本与回退方案 | ERP 字段变化后，旧客户端如何回归测试？ |
输入：让 AI 填得对，也让服务端守住边界
输入参数应尽量贴近业务对象，而非裸露数据库表名或万能 SQL。订单查询可要求一个明确的订单编号；若允许批量查询，就设置数量上限和分页规则。字段描述要写清示例、单位、枚举值和互斥条件。inputSchema 可帮助客户端理解参数结构，但它不能代替服务端校验和员工授权。MCP 规范也明确要求服务器验证工具输入并实施访问控制。
不要让模型自行填入“当前员工 ID”来证明身份。身份应来自经过认证的调用上下文，目标系统再判断该员工对订单的功能与数据权限。否则模型猜对一个 ID 也可能成为越权入口。
输出：先返回可核对事实，再组织自然语言
工具返回的核心应是业务事实：来源系统、对象标识、状态、更新时间、单位及必要的差异说明。若提供结构化结果，可用 outputSchema 约束字段类型和必填项。面向用户的自然语言解释可以由工作台生成，但应保留可回查的业务标识，不把推断写成系统事实。
尤其要区分“值为零”“字段为空”“记录不存在”和“当前员工无权查看”。这四种结果在 ERP 中含义不同。如果都压成空字符串，AI 很容易给出过于确定的回答。涉及金额、库存、审批状态时，应把币种、数量单位、统计时点和数据范围一并返回。
错误与变更：让调用失败可解释
协议层错误与工具执行错误不同。未知工具或参数结构不合法可能形成协议错误；ERP 超时、业务校验失败等可以作为工具执行错误返回。企业还应在结果中提供便于定位的错误类别和调用标识，同时避免把内部密钥、堆栈或敏感原始数据暴露给工作台。超时后若涉及写入，先回查业务结果，不能盲目重试；相关边界可参考重复写单的验收方法。
当 API 字段、业务状态或权限规则变化，应先更新能力定义，再在目标工作台回归测试成功、空结果、无权限和上游异常四类路径。兼容性不能只看工具还在列表中；结果含义是否保持一致同样重要。
一项只读工具的最小验收
- 选择一个可在原系统核对的查询问题，明确员工角色与业务对象。
- 列出必填参数、格式、上限和业务含义，用正常值与错误值各测一次。
- 用有权、无权员工分别调用，核对连接器授权和目标系统数据范围。
- 对照原系统检查状态、单位、更新时间和来源，测试空结果与超时。
- 在计划使用的 AI 工作台版本中检查工具发现、参数确认、结果呈现和审计记录。
这是面向企业项目的建议性验收清单，具体字段与阈值应由业务系统负责人确定。对于新增、修改、删除与审批工具，还要增加人工确认、结果回查和重试保护，不能直接沿用只读查询的通过标准。
星云 PLUS 在这条链路中的位置
根据星云 PLUS AI 系统连接器白皮书，星云 PLUS 可复用现有数据、RESTful API、业务页面等资源，将其整理为可发布的 AI 业务能力，并配置业务语义、输入输出、版本与授权。连接器可把 AI 用户映射到员工个人账号，先判断能力授权，再由目标系统判断功能和数据权限；调用记录可用于追查。具体 API 适配、客户端兼容与生产范围需按目标环境评估和验收。
对于本文的订单查询，合适的起点是把一个已有的只读接口做成定义清楚、结果可回查的工具，再验证不同岗位的访问范围。企业无需为了 AI 先重构整套 ERP，也不应把接口能连通当作已完成业务验收。
资料来源与核验日期
- 蓝凌：企业 Skill 接入桌面智能体方案，发布于 2026-09-30，核验于 2026-10-05。
- WorkBuddy 官方更新日志，引用 2026-09-21 条目，核验于 2026-10-05。
- 千问办公官方客户端更新日志，引用 2026-09-23 条目，核验于 2026-10-05。
- MCP 工具规范 2025-06-18，核验于 2026-10-05。
- 星云 PLUS AI 系统连接器白皮书 v1.0，产品事实核验于 2026-10-05。
结语
把业务 API 接入 AI 工作台，先定义好“能问什么、怎样问、结果是什么、失败怎么办”，再用真实员工权限与原系统结果验收。若企业正在评估首个连接场景，可从星云 PLUS 官网查看连接器与系统评估方式。