2026 年 8 月 22 日

Code Mode 会终结 MCP 和 CLI 吗？我的判断恰恰相反

最近国外社区在聊 Agent 的 Code Mode 模式：让 Agent 通过写 JavaScript 去调用 tools、CLI、MCP，而不是一个个去点工具。随之而来一个很自然的疑问——那用户是不是再也不用接 MCP、装 CLI 或者配 tools 了？

我的回答是：你的直觉方向对，但有个关键点需要修正。

Code Mode 不是让 MCP、CLI、Tools 消失，而是把它们从「Agent 的直接工具接口」降级成「Agent 可以通过代码调用的底层能力」。

这不是一次表面的交互方式变化，而是 Agent 架构的一次根本性转向。

先看清楚 Code Mode 到底在做什么

传统 Agent 的模型是这样的：LLM 直接面对几十、几百个 tools，用 tool_call 一个一个去调。

传统 Agent:
LLM
 |
 | tool_call()
 |
 MCP Tool A
 MCP Tool B
 MCP Tool C

Code Mode 完全不同：LLM 面前只有一个东西——代码执行环境。它写 JavaScript，通过 SDK / API / CLI / MCP 去组合调用各种能力。

Code Mode:
LLM
 |
 | write JS
 |
 Sandbox Runtime
 |
 +-- fetch API
 +-- call CLI
 +-- import SDK
 +-- call MCP
 +-- filesystem
 +-- database

Cloudflare 的 Code Mode MCP 设计就是这个方向：暴露一个代码执行入口，让模型生成 JavaScript，在隔离环境里组合操作，而不是把一大堆工具 schema 摊给模型。

这背后的动机很实际。工具一多，每个都有 schema、有参数说明，模型还没开始干活就先被 context 撑爆了。与其投喂无数工具定义，不如给模型一把能操作一切的「刀」。

四个判断：谁会被淘汰，谁反而会复兴

1. 对个人用户，MCP 安装时代大概率正在结束

现在一个普通用户配置 Claude Code / OpenClaw，是什么样子？

MCP:
- github
- browser
- notion
- slack
- gmail
- filesystem
- postgres
- calendar
CLI:
- git
- gh
- docker
- kubectl
- aws
Tools:
- custom scripts
- APIs

这其实非常像早期 Linux：用户要自己装驱动、配环境、手写 shell。痛苦是真实的。

未来可能是这样：你告诉 Agent「帮我分析这个 GitHub 项目、找 bug、提交 PR、通知 Slack」，它自己生成 JS：

import github from "xxx"
import slack from "xxx"
await github.search()
await github.createPR()
await slack.send()

你完全不关心 MCP server 叫什么、config.json 怎么写、tool schema 长什么样、CLI 参数是啥。这些全都成为 Agent runtime 内部的事。

2. 但 MCP 不会消失，而是会变成 Kernel 层

这里我认同 Harness 团队的一个观点：Agent loop 类似一个新的操作系统，而 MCP 类似 kernel boundary。

这个比喻很准。未来的结构大概是：

 User
 |
 Intent
 |
 AI Agent
 |
 Code Generation
 |
 Sandbox Runtime
 |
 -------------------------
 | | |
 MCP CLI API
 | | |
 GitHub Docker AWS

MCP 不再是给人装的东西，而是给 Agent runtime 用的「标准化设备驱动」。普通用户不需要懂 Linux kernel driver，但 Linux 不能没有 driver。MCP 的位置从「用户插件系统」迁移到了「Agent 内核接口」。

3. CLI 反而可能复兴

很多人以为 MCP 会替代 CLI。但 Code Mode 出现后，我感觉可能正好相反——CLI 会重新成为 Agent 最喜欢的 primitive。理由有三条：

第一，压缩效率高。git status 就几个 token；等效的 call github_get_repository_status({ repository: "xxx" }) 要烧掉一大段 schema。

第二，模型早就训练过海量命令行。git、docker、kubectl、aws、terraform 对 LLM 来说太熟了。

第三，CLI 天然支持组合。kubectl get pods | grep error | jq 一行搞定一次执行；而 MCP 往往是 tool call → LLM → tool call → LLM，来回消耗上下文。

Harness 自己也讨论过：CLI 在「Agent 已知命令、组合操作」的场景占优，而 MCP 更适合发现能力、权限控制和结构化安全边界。

4. 那为什么还需要 MCP？三个绕不开的场景

场景 A：未知能力发现。「帮我优化 AWS 成本」——Agent 根本不知道 AWS 到底有多少 API。MCP 可以 discover 出 ec2、lambda、rds、cost explorer 这些能力地图。
场景 B：权限控制。 让 Agent 拿你的 token 跑 aws delete-instance 风险巨大；MCP 可以精确声明 read_cost=true, delete_instance=false。
场景 C：企业环境。 公司不会允许 Agent 执行任意 shell，但会允许调用经过审计的 MCP capability。

我看到的三段演进

如果拉长时间看，我判断会经历三个阶段：

现在（MCP 1.0 时代）：人 → 配置 MCP → Agent → Tools。用户痛苦。

Code Mode 时代：人 → Agent → 代码 → runtime → MCP/API/CLI。用户不用管工具。

更长期（2030 附近）：可能变成 User Intent → Agent OS → Capability Graph → Execution Runtime → World。到那时 MCP、CLI、API 都只是底层能力，用户在意图层和 Agent 对话即可。

对「个人 AI 操作系统」的真正启示

结合我一直想做的方向——把 OpenClaw 做成「个人级 AI 操作系统」——这个趋势其实已经给出了未来竞争力的答案。

未来个人 AI OS 最重要的，不是「我装了多少个 MCP」，而是「我的 Agent runtime 能不能动态发现、组合、执行我的全部数字能力」。真正分高下的会是：

Agent memory —— 记得住你是谁、你做过什么
Capability discovery —— 能发现并编排新能力
Sandbox execution —— 能安全地执行任意代码
Permission model —— 权限边界清晰可控
Long-running workflow —— 支持长时间、多步骤的自主任务

MCP 会从「用户插件系统」逐渐演变成「Agent 内核接口」。我过去一直追求的「简洁、高效、稳定」，恰好就是这个方向的内核品质——不是堆工具的数量，而是让 runtime 本身足够强健、足够能打。

编辑手记

这篇观点源自与 AI 助手的一次深度对话，话题是海外社区正在热炒的 Agent Code Mode。触发我记录的，是那个一针见血的误读：很多人以为「Code Mode = 不需要 MCP 了」。而真正深刻的转变，是工具从「人的配置负担」变成「Agent 的底层能力图」。如果你也在折腾自己的 Agent 环境，希望这篇能帮你重新校准优先级——别再去数 MCP 的数量，去打磨那个能自己发现能力的 runtime。