能调用和能放心让它调用，之间隔着四道关
这周 dev.to 热度最高的一篇长文（79 赞、49 评，13 分钟阅读），讲的不是 MCP 怎么用，而是它跑起来之后会发生什么。从一个 demo 讲起。
一、一个 demo，翻车两次
作者做了一个会审查代码的 AI agent，给它接了一个 HR 系统的 MCP 服务，四个工具，其中一个会直接把投诉写进数据库。
他故意放了一份写得很难看的代码让 agent 审。agent 找到了问题，调了工具，数据库里多了一条投诉记录。demo 到此为止，搭起来到跑通，按作者的说法只要几分钟。MCP 的基础实现确实就是这么容易：协议只定义客户端如何发现工具、读描述、读参数结构、发起调用。
然后他再跑了一次同样的流程。输入什么都没改，数据库里又多了一条投诉。同一个问题，第一条是 severe，第二条变成了 legendary。
协议管到调用为止。调用之后发生什么、能发生什么，协议不管。作者把这周读下来的生产化问题归成了四道关。
二、四道关，一道都没在协议里
第一道，权限关。作者的原话：用了 MCP 不等于工具自动变安全。他举的例子是，即使允许 agent 连上 HR 系统，也不应该默认它能对任意员工提交任意投诉。服务端权限检查、输入校验、合理限制、审计记录，一样都缺不得。
第二道，审批关。demo 里 agent 明明看到那段代码的文件注释写着 DEMO ONLY，是故意写坏给他审的，还是提了正式投诉。他问的是：在那之前，那个能点批准或拒绝的人在哪里。agent 能执行一个工具，和应该允许它无监督地执行，是两件事。
第三道，幂等关。重复跑会不会产生重复后果。同一次审查每次运行都新建一条投诉，就是没有幂等或去重的结果。demo 里看不出来，因为只跑两三次；上线之后运行次数上去了，副作用跟着次数线性涨。
第四道，审计关。工具执行到一半失败怎么办，agent 调错了工具怎么办，两个 agent 执行了互相冲突的操作怎么办。作者说这些问题最后都会回到经典软件工程的边界情况上。MCP 没有发明新的问题，它只是把这些问题搬到了 AI 工具这一层。
还有一条容易被跳过的：工具名和描述只帮你找到工具，不能证明实现可信。连接一个不熟的服务，等于信任一段看不见的代码。而且一个看起来无害的工具返回结果，里面可能夹着试图操纵 agent 的指令，服务端和客户端都得防。
三、MCP 什么时候才值得用
这个值得单独说，因为讨论里经常把 MCP 和 REST 混在一起。作者的原话：MCP 不是 REST 的替代。MCP 工具底下可以调 REST 接口、查数据库、跑本地代码、把活交给另一个 agent。
它的价值在多客户端复用：一个服务暴露一次，多个 AI 客户端都能接，不用为每个客户端单独维护一套集成。如果只有一个内部 agent、几个硬编码工具，直接集成更省，不需要 MCP。
四、落到我们自己这条流水线上
我们的自动化流水线本质上就是 agent 在调工具：采集、生成、部署、回读，每一步都是工具调用。作者这四关，可以直接抄成一份接入清单，每接一个新工具先回答四个问题：
谁能调。调用需要什么凭据，凭据的权限范围是只读还是可写。 要不要审批。哪个环节的动作必须人确认之后才执行。 重复跑会不会产生重复后果。有副作用的工具有没有幂等或去重。 出问题能不能追。调用记录留多久，能不能定位到具体哪次调用。
还有一个问题没核实：现有护栏主要覆盖频次这一层（写路径按日限次）。权限、审批、幂等、审计四关现有脚本各覆盖到哪，没有逐脚本核过，标记为未核实。
MCP 那一天的热度会过去，四道关不会。工具接入这件事，demo 跑通只是开始。
以上为 AI 开发者生态科普，基于 dev.to 两篇公开原文实读，不构成任何投资或买卖建议。
标签（话题，见下方发布设置清单）：
#AI编程 #开发者 #AI智能体