月底了，老板在群里问一句「这个月绩效都评完了吗」。
这个问题在系统里是有答案的。但要拿到这个答案，需要有人登录后台、找到考核模块、选周期、翻列表、数人头、比对应该评的和已经评的------快则五分钟，慢则半小时，取决于系统有多复杂。
问题不在于系统里没有这个数据。问题在于：人得先学会怎么操作系统，才能拿到本来就知道在哪里的数据。
AI 出现以后，这件事本应该有解。但很多企业的尝试停在了「给系统加一个聊天框」这一步，再往下就走不动了。因为会遇到三个断层。
一、三个断层
第一，能力没有接口化。
一个企业管理系统里能做的事，散落在几百个页面和按钮里。「查一下上个月的绩效」「把这个审批催一下」「看看哪些物资该盘点了」------这些事系统都能做，但没有一份「可被程序调用的清单」。AI 面对一个满是按钮的界面，和面对一个只会用鼠标的新员工，处境是一样的。
第二，数据在内网。
企业系统大多私有化部署。公网的 AI 摸不到内网数据，内网的 AI 又往往没有足够的能力。数据边界和能力边界错位。
第三，权限没地方表达。
AI 以什么身份进入系统？能看本部门的还是全公司的？看完之后这个动作记在谁的账上？没有答案，就不敢让它碰真数据。
这三个断层不解决，加多少聊天框都只是表面改造。
二、MCP 补的恰好是第一和第三个断层
MCP（Model Context Protocol）用一句话说清楚就是：把你的系统能力，写成一份 AI 看得懂的清单，并约定好怎么调用。
它不神秘。一个 MCP Server 会暴露若干「工具」（tool），每个工具有名字、一段自然语言说明、一份参数 schema。AI 拿到这份清单，就能像人调用函数一样调用你的系统，不需要理解你的界面长什么样，也不需要知道你的前端是 Vue 还是 React。
这件事的价值在于它是标准的。今天接 ChatGPT，明天接 Claude，后天接自己的本地模型，只要都支持 MCP，工具定义不用重写一遍。对企业来说，这意味着「接入 AI」从一次性项目变成了可复用资产。
至于权限------MCP 的调用终究是带着身份发起的。谁发起的、用什么凭证、能看到多少，仍然是系统自己的权限模型在管。AI 不是绕过权限的通道，它只是换了一个入口，而入口后面还是那套熟悉的权限表。
三、陀螺匠是怎么接的
陀螺匠是我们的企业管理系统，覆盖人事、客户、物资、审批、打卡、项目、财务、云盘和低代码九块。它从一开始就是私有化部署的形态，所以「数据出不去」对这个产品不是限制，而是前提。
我们把系统能力 MCP 化的路径，简单说是这样：
一个独立的 MCP 端点。 走 HTTPS，协议是 JSON-RPC 2.0，鉴权用 Bearer Token。这意味着任何一个支持 MCP 的客户端，拿到 token 就能接进来，不需要为每个模型单独适配。
按模块收敛工具粒度。 早期我们试过「一个模块一个大工具」的做法，很快发现不行------参数太杂，AI 容易填错。后来改成按查询意图拆：绩效考核这一块，最终收敛成四个工具：
| 工具 | 干什么 |
|---|---|
assess_list |
列出某个周期内的考核记录 |
assess_detail |
取单条考核的明细 |
assess_statistics |
按周期出分布统计 |
assess_trend |
拉多个周期的趋势 |
工具少了，AI 选错的概率就低；参数简单了，填错的概率就低。这个取舍比想象中重要。
工具说明写得像给人看的说明书。 这一点很多接入方会忽略。工具描述不是注释，它是 AI 唯一的判断依据。写「查询考核列表」和写「查询指定日期区间内的绩效考核记录，返回被考核人、评分人、得分、审核状态；不传日期则返回全部」，AI 的表现差别是数量级的。
四、三个真实场景
工具接好之后，最直接的变化是：那些「一句话就能问、但要动手才能查」的问题，变成了真的只需要一句话。
场景一：绩效催办。
「上个月的绩效，还有谁没评？」
AI 会去调 assess_list，按周期筛选，把审核状态为未完成的记录捞出来，按部门归组报给你。以前这件事是 HR 每月固定花半天做的，现在是早上打开聊天框问一句。
场景二：跨模块关联查询。
「这个月新入职的三个人，试用期考核安排了吗？」
这类问题以前最难，因为它横跨人事和考核两个模块，得开两个页面自己对照。工具化之后，AI 可以先查入转调离记录拿到名单，再拿名单去查考核计划，最后告诉你缺了谁。
场景三：异常提醒。
「哪些部门的评分分布不太对？」
assess_statistics 能给出分数分布，AI 可以做一些很朴素的判断------比如某个部门全是满分、或者分数高度集中在一个档位，就值得人看一眼。这种提醒不需要多智能，只要能自动跑起来就有价值。
五、踩过的三个坑
这部分可能是本文最有用的地方，因为都是真金白银试出来的。
坑一：同一个接口，不同 token 看到的不是同一份数据
assess_list 一开始让我们很困惑：明明传了部门、状态、日期各种筛选条件，返回的结果永远是那几条，而且都跟 token 对应的那个用户有关。
查了很久才想明白：这个接口是按 token 用户的可见范围锁定的。用普通员工的 token，它只返回这个人作为被考核人或评分人参与的考核。你传什么筛选参数都没用，因为范围在更前面就被裁掉了。
结论很直白：想拿全公司数据，就必须用有全公司查看权限的 token。这件事应该在文档里写死，而不是让每个接入方自己去猜------我们从那以后在工具描述里明确标注了「本工具受 token 权限范围限制」。
坑二：统计口径里的「count」不是你以为的那个 count
assess_statistics 返回里有个 count 字段，直觉上它是「这个周期一共有多少条考核」。于是我们很自然地想：
未评分数 = count - 已评分数量合计这个减法永远等于零。因为 count 统计的是已评分记录，未评分的根本没进这个数。我们拿一条明确知道没评分的记录去验证，它在统计结果里压根不存在。
这个坑的危险之处在于：它不会报错。你得到的是一个看起来很正常的 0，然后告诉老板「都评完了」。
坑三：时间参数看着能用，其实很脆
接口支持 time: "2026-07" 这种写法，文档上也有。实际调用会抛解析错误。最后只能用 start_date / end_date 传具体的日期区间。
类似的小坑还有几处。这类问题的共性是：它们不会在接入第一天暴露，而是在某个特定月份、特定参数组合下突然出现。所以我们的做法是把所有踩过的坑写成文档，作为技能包的一部分随代码走------下次不用重新踩一遍。
六、为什么「私有化 + MCP」这个组合值得认真看一下
现在市面上有两种主流做法。
一种是 SaaS 系统内置 AI 助手。优点是开箱即用，缺点是 AI 的能力边界等于这个 SaaS 的功能边界，而且你的数据必须放在它的服务器上。
另一种是买一个大模型，自己想办法喂数据。优点是自由，缺点是「想办法」这三个字往往意味着一个没有尽头的工程。
MCP 提供了第三条路：系统留在内网，能力以标准协议暴露出来，AI 用哪个、放在哪、谁来调，都由企业自己决定。
对私有化部署的产品来说，这条路几乎是天然的------数据本来就不出内网，接进来的是调用方，不是数据搬运方。企业可以让 AI 只读不写，也可以限定它只能碰某几个模块，甚至可以只在上班时间开放。这些控制点都在自己手里。
七、接下来
陀螺匠现在把考核这块的工具打磨得比较完整了，其余模块在按同一套范式推进。过程中最深的体会是：MCP 接入的难点不在协议，在于把「系统能做什么」翻译成「AI 能理解什么」。
这件事没有标准答案，每个系统的业务语义都不一样。但一旦翻译对了，后面所有的模型都能复用同一份清单------这大概是 MCP 对做企业软件的人最实在的好处。
如果你的团队也在做类似的接入，欢迎在评论区聊聊你遇到的坑。尤其是权限范围和数据口径这两块，我猜大家的经历会很相似。
本文基于陀螺匠（tuoluojiang）绩效考核模块的 MCP 接入实践整理。文中提到的接口行为均为实际测试结果，具体行为可能随版本变化，接入前请以自己的环境为准。