团队里最常被抱怨的一句话是「我要去三个系统里凑数据」。查订单去 ERP，看工单去工单系统，权限申请去 IT 平台。AI 工作台如果只能聊天，等于又多开一个窗口。

把内部系统接进来，主流做法是 MCP 连接器。我用百智办公试了一遍，把过程和坑写下来。

一、先想清楚要接什么

不要一上来就想把系统全接进去。判断标准是：这个操作是不是经常重复、且结果能用一个明确格式返回。

我们第一批接了三个：查订单状态、查工单进度、查某人的设备台账。三个都是查询类，不涉及写入，风险最低。

写入类的操作（比如直接改订单状态）建议第二批再考虑，而且要单独授权。

二、连接器的基本形态

MCP 连接器本质是一个暴露若干工具方法的服务，工作台调用这些方法拿到结果。每个方法要写清楚三件事：方法名、参数格式、返回什么。

方法名要能一眼看懂，「query_order_status」比「tool_1」好得多。参数要严格校验，宁可报错也不要猜。返回尽量结构化，别返回一大段自然语言——模型读结构化的结果更稳。

三、接入顺序

第一步先写一个最小可用的连接器，只暴露一个方法，参数写死一部分，在自己机器上跑通。

第二步把返回值打磨好。这一步花的时间最多，很多人以为连上就算完成，结果模型拿到的是一坨长文本，回答质量很差。

第三步做权限：哪些人能用哪个方法，在后台配置。

四、把结果格式做对

我们第一次接订单查询，返回的是原始 JSON，字段名是内部数据库的缩写。模型能读，但经常读错字段。

后来改成返回固定结构：订单号、状态、下单时间、金额，四个字段，状态用中文。回答质量立刻稳定了。

这条经验可以推广：连接器不只是「能不能连上」，更是「返回的东西模型能不能读懂」。后者的工作量往往更大。

五、权限要细到方法

同一个连接器，查订单和查客户资料应该是两种权限。我们在后台按方法授权，客服组只能查订单，销售组能查客户资料但不含联系方式。

这一层不做，等于把内部系统直接开放出去。

六、踩过的坑

第一个坑是没做超时。某个系统响应慢，工作台那边一直等，最后整个任务超时。现在每个方法都设了 8 秒超时，超时返回明确的失败信息。

第二个坑是错误信息直接返回给模型。模型看到「SQL 语法错误」就自己开始猜着改参数，越猜越乱。现在的做法是返回一句人话：「查询失败，请确认订单号是否正确」。

第三个坑是测试环境用真实数据。第一次联调直接查了生产订单，虽然只是读，但也不该。现在联调一律用测试环境。

七、什么情况下别急着接

如果一件事一周只做一两次，接连接器的投入不划算，手工做更省事。

如果内部系统本身接口不稳定、字段经常变，也不要接，维护成本会把你拖住。

还有一个现实问题：接进来意味着别人能通过 AI 访问那个系统。先把权限和审计想清楚，再谈方便。

八、连接器的维护

接进去不是终点。我们的做法是每季度梳理一次：哪些方法还有人用、哪些报错率高、哪些参数经常被填错。

报错率高通常意味着参数设计有问题。我们有一个方法原来要求传内部 ID，结果大家填的是订单号，报错堆了一堆。后来改成两种都接受，报错立刻降下来。

九、测试怎么做

给每个方法准备三条用例：正常值、边界值、错误值。正常值验证能通，边界值验证不会崩，错误值验证报错信息是否能看懂。

这三条用例写在一个简单脚本里，改完连接器就跑一遍。没有这一步，改动基本靠运气。

十、文档写给谁看

连接器的文档有两个读者：配它的人，和用它的模型。前者要清楚的参数说明，后者要干净的返回值。

我们现在的做法是一份 README 加一处返回值示例。写得不多，但每次改动都更新。文档过期比没有文档更糟。

十一、最后

把系统接进工作台，价值不在于多了几个按钮，而在于把人从「切窗口凑数据」里解放出来。判断这件事做得好不好，有个简单标准：同事还会不会为了查一条订单打开原来的系统。

如果还会，说明要么没接对，要么接完没人知道。这两件事都要修。