@@ -1,7 +1,7 @@
 ---
 title: "MCP，终将会走向失败"
 date: 2026-10-01 10:00:00
-updated: 2026-10-01 17:22:00
+updated: 2026-10-01 18:40:00
 tags:
   - MCP
   - Agent
@@ -52,6 +52,8 @@ Anthropic 在 2024 年发布 MCP 时，目标很明确：让 AI 应用以统一
 
 如果一个标准的目标是减少集成成本，就不能只停在“双方有能力声明”这一步。它还需要让不兼容的地方可见、可检测、可解释。公开支持矩阵、可复现的兼容测试和清楚的错误信息，很多时候比再加一个功能更有价值。
 
+![同一份授权凭据面对不同实现，可能得到通过、拒绝或反复重试的结果](/gallery/mcp-will-fail/auth-expectation-mismatch.webp)
+
 ---
 
 ## 扩展没有把边界补齐
@@ -78,13 +80,15 @@ Pi 的代码模式和 Cloudflare 提出的“代码模式”都在解决一个
 
 这是一种运行框架上的改进。Pi 通过工具元数据和延迟加载，把 MCP 接到自己已经确定的执行方式下面。它没有证明所有 MCP 服务端从此可以彼此无差别地工作，也没有证明每个智能体都该照这个方式设计。
 
+![运行框架可以在基础管道之上完成发现、过滤、代码组合与上下文管理](/gallery/mcp-will-fail/harness-wraps-pipe.webp)
+
 批评 MCP 以后，很容易得出另一个结论：那就用命令行。对于编程智能体，命令行确实很自然。模型会 Bash、管道、grep、jq，也会写临时程序；代码库、Git、包管理器和开发者的登录态通常已经在电脑上了。很多开发任务用命令行比远程工具顺手得多。
 
 但从“命令行对编程智能体很好用”推导到“命令行是所有智能体的通用工具接入协议”，中间跨得太远。命令行需要一个可用的执行环境、文件系统、已安装的软件和依赖管理。一个只需要读 CRM、查订单、改工单或调用几个远程 API 的智能体，没必要先拿到一台完整的 Linux 机器。
 
 把所有外部能力都包成命令行，往往还会反过来影响智能体架构：为了调用一个远程服务，智能体被迫拥有沙箱、文件系统、程序依赖和可能的登录态。原本只是“怎样调用一个能力”的问题，变成了“这台机器里应该放什么状态、什么凭据、谁来维护”的问题。命令行是很好的工具，不该被当作所有问题的底座。
 
-![运行框架可以在基础管道之上完成发现、过滤、代码组合与上下文管理](/gallery/mcp-will-fail/harness-wraps-pipe.webp)
+![命令行适合某些任务，但不应让每个小任务都先拖上一整台工作站](/gallery/mcp-will-fail/cli-is-not-default.webp)
 
 OpenAI 现在的智能体架构提供了一个更合理的边界：运行框架、会话和执行环境是不同概念。智能体可以设置 `environment.type = none`；不需要运行代码或操作文件时，运行框架仍可调用远程 HTTP MCP 服务和函数工具。只有真正需要命令、代码或文件操作时，才创建执行环境。[13]
 
@@ -116,6 +120,8 @@ OpenClaw 这类产品很容易强化“智能体就是一台电脑”的直觉
 
 这意味着“本地优先”和“云端优先”也不必二选一。工作流可以把代码检查调度到本地，把长时间处理交给隔离沙箱，把 CRM 查询留在远程服务，把最终状态写回项目系统。需要统一的不是智能体永远待在哪台机器上，而是这些执行节点怎样取得有限权限、报告进度并交还产物。
 
+![控制层把任务按需分派到本地、临时沙箱和远程服务，再集中收回状态与产物](/gallery/mcp-will-fail/control-plane-dispatch.webp)
+
 ---
 
 ## MCP 应该退回一个更小的位置