MCP 还是自写脚本？给 Agent 接外部能力的决策框架

先说结论：这不是技术选型，是成本账

你在 Claude Code、Cursor 或者任何 Agent 里，想让它查一下 Notion 数据库、发一条 Slack 消息、跑一段只读的 SQL。三种接法摆在面前：装一个 MCP server、写个小脚本让 Agent 用 Bash 调、直接让 Agent 拼 curl 发 HTTP 请求。

选错的代价不是“多写了几行代码”，而是后面每一次调用都在持续烧钱：Agent 每次调用都在烧 token，工具描述写得烂它就选错工具，权限给得宽它就可能把生产数据翻出来。这一篇不讲 MCP 协议细节，只给你一套能直接用的决策框架：三条路线的真实成本、一棵三阶梯决策树、五个实战场景、一份动手前的验收清单。

三条路线的真实成本：别比功能，比账单

先把三条路拆开看——看的不是“能做什么”，而是“要付什么”：

路线一：MCP server。标准协议，一次配置，Claude Code、Cursor、Cherry Studio 这些支持 MCP 的客户端都能复用。代价是协议开销（每次调用一次 JSON-RPC 往返）、server 进程要常驻、工具描述膨胀——description 写不好，Agent 就选错工具或者传错参数。它适合的是跨客户端、长期存在的能力。

路线二：自写脚本 + CLI。Agent 用 Bash 执行 python scripts/notify.py --channel "#deploy" --text "上线完成"。代价几乎为零：没有协议开销，调试就是改代码、跑一遍，Agent 还能直接读你的源码理解语义。缺点是只服务当前项目和当前客户端，换一个 Agent 客户端就得重接一次。

路线三：Agent 直拼 HTTP。让 Agent 直接 curl 或者用 fetch 调 API。零前置成本，今天就能用。代价是 API 的细节全部暴露在上下文里：Agent 容易 hallucinate 参数名，鉴权 token 进了上下文就有泄露风险，而且每次调用它都要重新“理解”一遍 API 文档，token 烧得最凶。只适合一次性、低频、只读的调用。

一张表帮你记住：

• 前置开发成本：直拼 HTTP 最低，脚本中等，MCP 最高（要写 server、写 schema、处理传输层）。
• 单次调用 token 成本：直拼 HTTP 最高（每次都要带 API 上下文），脚本最低（参数就几个 flag），MCP 居中。
• 跨客户端复用：只有 MCP 是开箱即用的；脚本靠复制文件；直拼 HTTP 每次重来。
• 调试难度：脚本最容易（print 就行）；MCP 最难（client 日志、server 日志、协议握手三处都要看）。
• 权限控制粒度：脚本最细（你想怎么收敛就怎么收敛）；MCP 取决于 server 实现；直拼 HTTP 最粗（token 给出去就是全部权限）。

三阶梯决策树：30 秒定方向

按顺序问三个问题，答案会自己指向那条路。

阶梯一：这个能力要用多久？一次性验证想法——直接 curl，别建任何工程。用完就扔的东西不配拥有 server。项目周期内反复用——写脚本，20 分钟写完，收益覆盖全项目。跨项目、跨客户端长期用——这才值得考虑 MCP。

阶梯二：能力是谁提供的？官方或社区已经有成熟 MCP server（GitHub、Postgres、Slack、Notion、Playwright 都有官方或高质量社区实现）——直接用，别自己造轮子，你造的第一个版本一定不如人家踩过一年坑的版本。只有 REST API 文档——先写脚本封装成 CLI，跑顺了再考虑要不要包成 MCP。内部系统、私有协议——脚本优先，因为需求变得快，脚本改起来便宜。

阶梯三：Agent 需要多少“理解”才能用对？参数简单、幂等、只读——暴露原始能力就行，怎么接都行。参数复杂、有副作用、需要业务判断——必须在封装层做收敛：把 20 个参数收成 3 个，把危险操作加二次确认。这时候脚本比 MCP 更灵活，因为你可以直接改代码，而 MCP 的工具 schema 一旦定下来，改起来牵一发动全身。

压缩成一条规则：

有可信的官方 MCP → 直接用它；只用一次 → curl；跨客户端长期用 → 写 MCP；其他一切情况 → 先写脚本 CLI。脚本被第三个项目复用时，再把它升级成 MCP。

注意最后那句：脚本是 MCP 的草稿。先有被验证过的脚本，再谈标准化。直接从零写 MCP，大概率是在为还没发生的需求付架构税。

五个实战场景：从“该用什么”到“怎么写”

场景一：让 Agent 查生产数据库（只读）。→ 写脚本。别用 postgres MCP server——它太开放，Agent 拿到的是完整 SQL 执行能力，你得靠 prompt 约束它“只查不写”，这相当于把保险柜密码告诉保安然后叮嘱他别开门。正确做法是写 scripts/db_read.py --sql "..."，在脚本里硬编码三条铁律：只允许 SELECT 开头（正则拒绝 INSERT/UPDATE/DELETE/DROP）、自动追加 LIMIT 200、连接串用只读账号。权限收敛写在代码里，而不是写在 prompt 里。

场景二：让 Agent 发 Slack 通知。→ 用官方 MCP。Slack 有官方 MCP server，鉴权、频道列表、消息格式都处理好了，自己写脚本等于重复造轮子。但有两个坑要躲：只给 bot token 最小权限（chat:write 就够，别给 admin）；在 MCP 配置里只暴露你需要的两三个 tool，多余的 tool 在客户端配置里禁用掉——Agent 看不到的工具就不会误用。

场景三：让 Agent 调用公司内部 OA 审批 API（私有、无官方 MCP）。→ 脚本先行。先写 oa.py approve --id 12345 --comment "同意"，在脚本里做三件事：调用前先查单据状态（幂等，避免重复审批）、写一行审计日志（谁、何时、批了哪个单）、支持 --dry-run 让 Agent 先看再做。等第三个项目也要用这个能力时，再把它包成内部 MCP server——这时你已经知道真实的调用模式，schema 设计不会拍脑袋。

场景四：让 Agent 批量压缩 200 张图片。→ 都不是，别接能力。这是最常见的误区。如果任务是“确定的批量流水线”，正确做法是写个脚本一次跑完，Agent 只负责触发，不负责逐项执行。让 Agent 对 200 张图片逐张调用工具，是 token 黑洞，一张图烧掉几百 token 的工具调用开销，200 张就是灾难。判断标准：步骤确定、输入批量 → 脚本一把梭；需要判断、逐项决策 → 才值得让 Agent 逐个调工具。

场景五：让 Agent 操作浏览器做 E2E 验证。→ 用社区 MCP（Playwright MCP）。浏览器自动化的状态管理极其复杂：页面上下文、元素等待、截图、console 日志，社区的 Playwright MCP 已经踩过这些坑。自己写脚本要处理 CDP 会话和竞态，成本高一个数量级。但记住只给它开测试环境的地址——别让 Agent 拿着浏览器 automation 去点生产后台。

动手前的六项验收清单：无论选哪条路

路线定下来之后，动手之前过一遍这六条，任何一条不满足都先别接：

1. 最小权限。token 只给需要的 scope；数据库用只读账号；任何生产写操作必须有二次确认机制。先问自己：如果 Agent 被 prompt 注入了，这个权限能造成的最大破坏是什么？
2. 工具描述写给 Agent 看，不是写给人看。description 里最重要的不是参数文档，而是“什么时候用、什么时候别用”。好例子：只读查询生产订单表。禁止用于报表导出；超过 1000 行请先聚合；不要在高峰期（9:00-11:00）调用。烂例子：执行 SQL 查询，参数为 sql 字符串。
3. 幂等与 dry-run。有副作用的操作必须支持 --dry-run，让 Agent 先输出“我打算做什么”给你确认，再真正执行。审批、发版、删数据这类操作没有 dry-run 就是裸奔。
4. 输出收敛。返回给 Agent 的 JSON 只含必要字段，列表默认截断 50 条并告诉总数（{"total": 2317, "items": [...]}）。Agent 不需要的那 2000 行数据，每一行都是钱。
5. 失败要可读。脚本 exit code 非零，第一行就是人话错误原因，别让 Agent 去猜。比如 ERROR: 订单 12345 已审批，当前状态=approved，无需重复操作 远胜于一堆 traceback。
6. 审计日志。谁、何时、调了什么、参数是什么，记一行日志。Agent 出事时，这是你唯一的案发现场。MCP server 也一样：在 server 里加日志中间件，别依赖客户端的记录。

两个反直觉的结论

第一，MCP 不是“更高级”，是“更贵”的标准化。今天 MCP 生态最大的坑，就是为了“标准化”给一次性需求写了个 server，结果维护成本超过收益。标准化只在复用次数够多时才回本——经验数字是 3 次：同一个能力被三个不同的项目或客户端用上，MCP 的账才算得过来。在此之前，脚本永远是更划算的选择。

第二，最好的 Agent 工具，是“Agent 不需要懂业务”的工具。把业务判断下沉到封装层：该校验的校验、该收敛的收敛、该二次确认的二次确认。Agent 只做选择题，不做问答题。实践下来，工具层的错误率下降比 prompt 优化一个数量级更明显——因为代码里的 if 语句从不 hallucinate。

下次给 Agent 接外部能力，先问自己三句话：用几次？谁提供的？Agent 需要理解多少？答案会自己指向那条路。而当你犹豫的时候，记住默认答案永远是：先写脚本。