MCP 工作流暴露面如何收敛

第一次把手头的 MCP 服务端挂给我自己的编码 agent 时，我的想法很简单：能自动跑安全流程，太好了。结果跑完一轮我才反应过来，我几乎是把整台机器都递了出去——工作区指到了用户主目录，工作流全量打开，插件还加载失败了一半。agent 手里是一堆半残的能力，却依然能翻遍我的代码盘。暴露面这东西，宽一点不会让人觉得方便，只会让人睡不好。

先把工作流列表收窄

--workflows 是第一个该动的地方，它决定哪些工作流暴露给外部 agent 调用。很多人（包括当时的我）默认全开，理由是"以后说不定要用"。但面对一个能读写文件的外部 agent，我现在的习惯是先只留只读或低风险的那几个：搜代码、读日志这类，出了问题最多是信息泄露；改文件、装包、开单这类会真实改变系统状态的操作，直接关掉，或者只允许在一次性隔离仓库里做。这里的关键不是技术难度，而是你愿不愿意承认：暴露出去的能力，agent 迟早会用上。

workspace 决定爆炸半径

--workspace 必须是绝对路径，而且得是你愿意让这个 agent 读写的仓库根目录。指向主目录、指向整个代码盘，都是给自己埋雷。一个工作区对应一个仓库，这是控制爆炸半径最有效的手段——多个不相关的项目塞进同一个工作区，检索时跨项目串味，善后时更是够喝一壶。

还有 host-local。这个配置不是可选装饰，它决定工作流在本机执行、文件在本机被读、运行记录留在本机。但别误会：本机执行不等于本机推理。上下文该发出去的照样发出去，配置下发前先回答清楚，这类代码允许送到哪家提供方的哪个端点。

插件加载失败也会骗你

插件缺失或加载失败时，MCP 客户端可能只看到一部分工作流，表现就是"命令存在但没有对应能力"。这种半残状态最容易误导人：你以为自己收窄了暴露面，实际上只是工具少了几个，剩下的那几个照样能跑。所以调完配置别急着收工，去客户端确认一遍工具列表是不是你想要的样子。

最后一句提醒：只从官方仓库获取二进制或镜像，核对校验值。已知的攻击手法里就包括重新打包本地 AI CLI、用引导脚本把请求导向别处，来路不明的"加速版"省下的那点时间，根本不够善后。

我现在把这件事当成一次性的边界练习：开一个小工作区，跑一轮，看它实际读了什么、写了什么，确认无误再谈固化进日常流程。暴露面收窄不是一次配置就完事，而是一种跟着运行记录不断回头核对的习惯。