争论表面谈协议，底层谈权限模型

Simon Willison在2026年9月20日发布的一则评论中，回应了Hacker News上“R MCP一直是个坏主意吗”的讨论。他提出的对象是MCP，也就是用于让Agent接入外部工具和服务的一种方式。评论的核心并不是宣称MCP普遍优秀，而是指出，评价它之前必须先看Agent被允许拥有多大的行动范围。

如果系统是Claude Code、Codex、Meta Muse或OpenClaw这类完整终端Agent，并且拥有不受限制的互联网访问能力，那么直接让Agent调用API往往更简单。此时，Agent已经可以自己寻找并连接外部服务，MCP没有明显填补一个必要缺口。把这个场景里的低收益，推广成所有Agent都不需要MCP，才是争论中最容易出现的跳跃。

当Agent不能被放任，问题就变了

另一类系统并不希望把一个拥有全网权限的终端交给Agent。产品团队可能只允许它访问明确列出的外部服务，也可能希望用户在需要时连接新的服务，而不是让模型自行决定所有连接。这样的系统面对的首要问题就不再是“Agent能不能调用API”，而是“谁决定它能调用哪些API”。

这也是Willison认为MCP今天仍有价值的地方。MCP可以让外部服务以工具边界的形式进入系统，使服务选择不必完全隐藏在Agent的提示词、运行环境或临时脚本里。它并不自动替产品团队做出授权决定，但能让这些决定拥有更清晰的承载位置，从而更容易成为产品配置而不是模型行为。

四项需求把连接问题变成控制面问题

材料中最具体的判断标准有四项。第一是控制Agent能够访问哪些外部服务。第二是处理认证时，不让Agent直接接触API密钥。第三是给用户提供合理的界面，让用户能够连接并认证更多服务。第四是对系统正在发生什么保留强审计日志。这四项要求共同说明，企业Agent的工具接入不是一次简单的函数调用，而是一组需要被产品化的控制能力。

直接API调用把很多责任推向Agent运行环境。服务地址、认证方式、秘密保存和调用记录，可能分散在运行时与脚本中，系统也更依赖Agent是否按照预期行动。通过受控工具接口，产品可以把用户认证与模型发起调用区分开，把凭证处理放在模型之外，并让调用行为进入系统级记录。材料没有给出具体部署架构或安全测试结果，因此更准确的说法是MCP让这些能力更容易提供，而不是它已经自动实现了完整治理。

MCP的价值来自责任分离，而非调用效率

从任务结果看，Agent通过MCP调用外部服务，和Agent直接访问API，似乎可以完成同一件事。真正不同的是系统把责任放在哪里。直接访问让Agent更接近服务端点和凭证，而受控工具接口允许产品在Agent与服务之间安排一层边界。这个边界的价值，不是让一次调用更快，也不是让模型获得更多能力，而是让外部访问可以被系统单独管理。

对技术负责人而言，这种分离会影响产品的默认路径。用户授权某项服务，可以成为一个独立流程。模型请求某个工具，可以成为一次可检查的系统动作。服务白名单和审计日志，也可以从“需要额外开发的外围能力”变成接入设计的一部分。材料只支持“更容易提供”这一判断，不能据此推断所有MCP部署都会安全，或者所有工具调用都会自动经过充分审批。

先问Agent能否直达一切，再决定是否采用

因此，MCP不适合被当成所有Agent都必须使用的基础协议。对于个人使用、权限开放、允许Agent直接访问互联网的终端系统，引入MCP可能只会增加协议和适配层，收益未必抵得上复杂度。对于面向多人使用、需要用户连接服务、需要隐藏凭证或必须追踪调用行为的Agent产品，直接API调用的简洁则可能把治理负担推迟到更晚的阶段。

可执行的判断顺序应当从权限模型开始，而不是从协议偏好开始。先明确Agent是否被允许直接访问任意外部服务，再确认凭证是否可以进入Agent可见范围，随后判断用户认证与审计是否需要成为产品能力。如果这些约束都不存在，MCP的价值可能很低。如果这些约束存在，就应把MCP作为控制面的一部分评估，同时继续单独检查授权范围、凭证保护和绕过路径。MCP提供的是一条边界，不是边界以内的全部安全答案。