0%

让 Claude Code 跨会话记住你是谁、你偏好什么、项目正在发生什么——这是 Memory 系统的核心目标。它不是简单的聊天记录持久化,而是一个结构化的知识管理系统,通过四种记忆类型、自动提取机制、团队同步等功能,让 AI 真正”理解”你。

阅读全文 »

AI Agent 执行命令、修改文件、访问网络——这些都是高风险操作。Claude Code 的权限系统设计了一个分层的决策模型:规则 → 模式 → 钩子 → 分类器 → 用户确认。每一层都可以独立中断工具调用,确保安全性。

阅读全文 »

Claude Code 的多 Agent 系统可能是其最被低估的设计之一。它不是简单的”子代理调用”,而是一个完整的协作框架:四种 Agent 类型(Subagent、Fork、Teammate、Remote)、Teams 邮箱通信、权限同步、Worktree 隔离。这个设计让 Claude Code 能够处理单 Agent 无法完成的复杂任务。

阅读全文 »

Skills 是 Claude Code 最强大的扩展机制之一。它不是简单的”命令别名”,而是完整的 AI 行为定义:可以限制工具池、覆盖模型、注入 Hook、选择执行上下文(inline 或 fork)。更令人惊叹的是,Skills 支持条件激活——只有当你操作特定文件时才被发现。

阅读全文 »

Claude Code 有 48+ 个内置工具,每个工具都是一个完整的生命周期管理单元。从定义到执行,工具要经过七步管道:查找、解析、验证、钩子、权限、执行、后处理。这个设计使得每个工具都是自描述、自验证、自渲染的——框架不需要了解工具的内部逻辑,只需调用标准接口。

阅读全文 »

Claude Code 的终端界面不是传统的 CLI——它是一个完整的 React 应用,运行在终端中。通过 Ink 框架(自定义 React Reconciler + Yoga 布局引擎),Claude Code 实现了组件化 UI、双缓冲渲染、交互式对话框等高级特性。这是 Terminal UI 开发的教科书级案例。

阅读全文 »

导读:同样的模型,不同的体验

主流 Code Agent 竞品一览

当前市面上主流的 AI Code Agent 产品可分为三类:

产品 公司 形态 特点
Claude Code Anthropic CLI Agent 运行时框架,MCP 扩展
Codex CLI OpenAI CLI 同类型竞品,GPT 模型驱动
Cursor Anysphere AI 原生 IDE VS Code fork,深度上下文感知
Trae 字节跳动 AI 原生 IDE 国内版”扣子”,自适应学习
GitHub Copilot Microsoft IDE 扩展 行业先驱,生态成熟
Qoder 阿里云 IDE 扩展 通义灵码,阿里云生态集成

Claude Code 与 Codex CLI 是同类型产品——都是终端型 CLI 工具,直接操作文件系统。其他产品则是 IDE 形态,交互方式不同。


核心体验差异

用 GPT-4 模型 + OpenAI 自家的 Codex CLI,效果还行;
用 GPT-4 模型 + Anthropic 的 Claude Code,效果竟然更好。

这颠覆了常识——为什么自家模型搭配自家 Agent,效果反而不如搭配竞争对手的 Agent?

答案在于:Claude Code 不是”Claude 模型的专属工具”,而是一个通用的 Agent 运行时框架。它的架构设计让任何模型都能发挥更大潜力。

很多人猜测是”Prompt 更好”,但这只是表象。Claude Code 源码泄露后,真相浮出水面——它不是一个 Prompt 工具,而是一个完整的 Agent 运行时框架

这个框架做了什么?它”懂”模型的能力边界,”懂”工具的执行风险,”懂”上下文的压缩策略,”懂”用户的意图流转。模型只是大脑,Claude Code 是躯体。


一、架构对比:状态机 vs ReAct

1.1 市面主流 Code Agent 架构

大多数 Code Agent 采用 ReAct(Reasoning + Acting) 模式:

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────┐
│ ReAct 循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Thought → Action → Observation → Thought → Action → ... │
│ │
│ 问题:容易陷入死循环 │
│ ├─ 模型反复"思考"但无法推进 │
│ ├─ 工具失败后没有恢复机制 │
│ └─ 上下文无限膨胀直到截断 │
│ │
└─────────────────────────────────────────────────────────────┘

1.2 Claude Code 的状态机架构

Claude Code 选择了一条不同的路——Async Generator 状态机

1
2
3
4
5
6
7
8
9
10
11
12
// 核心循环不是 Thought→Action→Observation
// 而是 state = next 的状态推进

while (true) {
const next = await step(queryContext)
state = next // 状态推进,不是循环

if (state.type === 'end') break
if (state.type === 'error') {
state = recover(state) // 有恢复机制!
}
}

优势对比

特性 ReAct Claude Code 状态机
死循环风险 低(状态推进有边界)
错误恢复 有(6 种恢复策略)
流式交互 困难 原生支持(Generator)
上下文管理 简单截断 四级压缩
模型控制 被动 主动(state 驱动)

二、工具生态对比

2.1 工具数量对比

Code Agent 内置工具 扩展机制
Claude Code 48+ MCP 协议(无限扩展)
Codex CLI ~20 有限扩展
Cursor ~15 IDE 内嵌,无扩展
Trae ~15 IDE 内嵌,无扩展
GitHub Copilot ~10 IDE 生态,有限
Qoder ~10 阿里云生态,有限

MCP 协议是 Claude Code 的杀手级特性——任何开发者都可以用任何语言编写 MCP Server,扩展 Claude Code 的能力。相比之下,其他产品的扩展性都受限。

大多数 Code Agent 的工具执行是”裸奔”的:

1
调用工具 → 执行 → 返回结果

Claude Code 的工具执行有 七步管道

1
查找 → 解析 → 验证 → 钩子 → 权限 → 执行 → 后处理

关键差异

管道步骤 Claude Code 其他 Agent
验证 Schema 校验 + 业务规则 通常无
钩子 PreToolUse/PostToolUse 可拦截
权限 五层决策链 简单开关
后处理 结果渲染 + 错误恢复 直接输出

三、上下文管理对比

3.1 市面常见做法

大多数 Code Agent 的上下文管理是暴力截断

1
2
3
if (tokens > limit) {
截断最早的消息
}

问题:

  • 重要信息可能丢失
  • 模型”忘记”之前的上下文
  • 长任务无法完成

3.2 Claude Code 的四级压缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ 四级上下文压缩 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Level 1: Snip │
│ └─ 快速裁剪:删除空白、重复内容 │
│ │
│ Level 2: Micro │
│ └─ 微压缩:保留 tool_use ID,删除详细参数 │
│ │
│ Level 3: Collapse │
│ └─ 块压缩:合并相邻消息,生成摘要 │
│ │
│ Level 4: AutoCompact │
│ └─ 深度压缩:调用子代理生成完整摘要 │
│ │
└─────────────────────────────────────────────────────────────┘

效果对比

场景 暴力截断 四级压缩
长对话 信息丢失 关键信息保留
复杂任务 无法完成 可以完成
模型理解 “忘记”之前 “记住”要点
Token 消耗 低(智能压缩)

四、多代理协作对比

4.1 单 Agent 的局限

大多数 Code Agent 是单 Agent 设计:

1
一个模型 + 一套工具 = 完成所有任务

问题:

  • 复杂任务难以分解
  • 单一模型容易”思维固化”
  • 无法并行处理

4.2 Claude Code 的多代理架构

Claude Code 有 四种 Agent 类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ 四种 Agent 类型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Subagent(子代理) │
│ └─ 短生命周期,完成子任务后汇报 │
│ │
│ Fork(分叉代理) │
│ └─ 独立上下文,不污染主对话 │
│ │
│ Teams(团队代理) │
│ └─ 邮箱通信,任务分发,并行执行 │
│ │
│ Remote(远程代理) │
│ └─ MCP 协议,扩展到外部服务 │
│ │
└─────────────────────────────────────────────────────────────┘

协作场景示例

任务 单 Agent Claude Code 多代理
重构大型模块 容易迷失 Fork + Subagent 分解
并行调研 无法并行 Teams 并行执行
跨项目操作 困难 Remote MCP 扩展
长时间任务 上下文爆炸 Teams 邮箱通信

五、安全机制对比

5.1 市面常见做法

大多数 Code Agent 的安全机制是简单开关

1
allowDangerousCommands: true/false

问题:

  • 无法精细控制
  • 一旦开启,所有危险操作都允许
  • 用户无法审批具体操作

5.2 Claude Code 的分层权限模型

Claude Code 有 五层决策链

1
规则检查 → 模式检查 → 钩子检查 → 分类器检查 → 用户确认

精细控制示例

操作 其他 Agent Claude Code
git status 允许/拒绝 允许(Git 白名单)
rm -rf node_modules 允许/拒绝 确认(危险命令)
rm -rf / 允许/拒绝 拒绝(永远禁止)
写入 .git/config 允许/拒绝 拒绝(敏感路径)
运行测试 允许/拒绝 允许(安全操作)

六、Memory 系统:其他 Agent 没有

6.1 跨会话记忆

大多数 Code Agent 每次对话从零开始

1
新对话 → 模型不知道你是谁 → 重新解释需求

Claude Code 的 Memory 系统:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ Memory 系统 │
├─────────────────────────────────────────────────────────────┤
│ │
│ User Memory(用户画像) │
│ └─ 记住你的角色、技能水平、偏好 │
│ │
│ Feedback Memory(行为反馈) │
│ └─ 记住你对 Claude 工作方式的纠正 │
│ │
│ Project Memory(项目动态) │
│ └─ 记住项目的决策、截止日期、正在进行的工作 │
│ │
│ Reference Memory(外部引用) │
│ └─ 记住外部系统指针:仪表板、工单系统 │
│ │
└─────────────────────────────────────────────────────────────┘

效果

场景 无 Memory 有 Memory
新对话 重新解释 Claude 知道你是谁
编码风格 每次指定 Claude 记住偏好
项目决策 重复解释 Claude 记住背景
团队协作 不知道队友 Claude 知道分工

七、远程控制:Channel 系统

7.1 其他 Agent 的局限

大多数 Code Agent 只能在本地终端交互:

1
你必须坐在电脑前 → 才能让 Agent 工作

7.2 Claude Code 的 Channel 系统

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────────┐
│ Channel 系统 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 手机 Telegram → 发消息给 Claude Code │
│ ↓ │
│ Claude Code 在你的电脑上工作 │
│ ↓ │
│ 结果回复到你的 Telegram │
│ │
│ 六层访问控制确保安全: │
│ ├─ 能力声明 │
│ ├─ 运行时开关 │
│ ├─ OAuth 认证 │
│ ├─ 组织策略 │
│ ├─ 会话白名单 │
│ └─ Marketplace 验证 │
│ │
└─────────────────────────────────────────────────────────────┘

体验差异

场景 其他 Agent Claude Code
外出时 无法使用 Telegram 远程控制
紧急修复 必须回电脑 手机审批操作
监控进度 无法监控 IM 实时反馈

八、Terminal UI:React + Ink

8.1 其他 Agent 的界面

大多数 Code Agent 的界面是简单输出

1
2
stdout.print("模型回复")
stdout.print("工具结果")

问题:

  • 信息密集时难以阅读
  • 无法交互式选择
  • 无法可视化复杂内容

8.2 Claude Code 的 Terminal UI

Claude Code 用 React + Ink 构建 Terminal UI:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ React + Ink TUI │
├─────────────────────────────────────────────────────────────┤
│ │
│ 组件化 UI │
│ ├─ Header(标题栏) │
│ ├─ MessageList(消息列表) │
│ ├─ ToolBar(工具栏) │
│ ├─ ContextPanel(上下文面板) │
│ ├─ InputBox(输入框) │
│ └─ PermissionDialog(权限对话框) │
│ │
│ Flexbox 布局(Yoga 引擎) │
│ 双缓冲渲染(避免闪烁) │
│ 交互式组件(键盘导航) │
│ │
└─────────────────────────────────────────────────────────────┘

体验对比

特性 简单输出 React + Ink
信息密度 高(布局优化)
可读性 一般 好(结构化展示)
交互性 有(键盘导航)
权限审批 全部允许/拒绝 可选择 Allow/Deny

九、System Prompt 工程

9.1 其他 Agent 的做法

大多数 Code Agent 的 System Prompt 是静态字符串

1
SYSTEM_PROMPT = "你是一个 AI 编程助手..."

问题:

  • 无法动态适应环境
  • 无法缓存,每次都发送
  • 无法合并多来源指令

9.2 Claude Code 的分层 System Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────────────────────────────────┐
│ 分层 System Prompt │
├─────────────────────────────────────────────────────────────┤
│ │
│ 静态可缓存区域 │
│ ├─ 角色定义 │
│ ├─ 系统规则 │
│ ├─ 工具说明 │
│ └─ 任务指导 │
│ │
│ ─────────── 缓存边界 ─────────── │
│ │
│ 动态可变区域 │
│ ├─ 当前日期 │
│ ├─ 项目结构 │
│ ├─ Git 状态 │
│ ├─ MCP 指令 │
│ └─ CLAUDE.md(用户指令) │
│ │
└─────────────────────────────────────────────────────────────┘

效果

特性 静态 Prompt 分层 Prompt
Token 消耗 高(每次全量) 低(缓存复用)
响应延迟 低(缓存命中)
指令优先级 单一 多级合并
用户定制 困难 CLAUDE.md 支持

十、总结:Claude Code 的核心竞争力

Claude Code 比其他 Code Agent 更强,不是因为”Prompt 更好”,而是因为它是一个完整的 Agent 运行时框架

10.1 七大核心优势

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
┌─────────────────────────────────────────────────────────────┐
│ Claude Code 七大核心优势 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 状态机架构 │
│ └─ 替代 ReAct,避免死循环,支持流式交互 │
│ │
│ 2. 工具生命周期 │
│ └─ 七步管道:验证、钩子、权限、后处理 │
│ │
│ 3. 四级上下文压缩 │
│ └─ 智能压缩,保留关键信息,实现"伪无限对话" │
│ │
│ 4. 多代理协作 │
│ └─ 四种 Agent 类型,Teams 邮箱通信,并行执行 │
│ │
│ 5. 分层权限控制 │
│ └─ 五层决策链,精细控制每个操作 │
│ │
│ 6. Memory 系统 │
│ └─ 跨会话记忆,Claude"记住"你是谁 │
│ │
│ 7. 分层 System Prompt │
│ └─ 缓存优化,降低 Token 消耗和延迟 │
│ │
└─────────────────────────────────────────────────────────────┘

10.2 一句话总结

Claude Code 是一个”懂”模型的 Agent 平台

  • 懂模型的能力边界 → 状态机架构
  • 懂工具的执行风险 → 七步管道 + 权限控制
  • 懂上下文的压缩策略 → 四级压缩
  • 懂任务的分解协作 → 多代理架构
  • 懂用户的长期意图 → Memory 系统

其他 Code Agent 只是模型的”简单包装”,Claude Code 是模型的”完整躯体”。这就是为什么同样的 Claude 模型,配合 Claude Code 使用效果更好的根本原因。


系列文章导航:

背景

最近,关于 AI Agent 如何与外部系统交互的讨论非常热烈,尤其是围绕 MCP 和 CLI 的争论。很多人认为 MCP 因为成本高、效率低而即将被淘汰。但就在四月二十二日,MCP 的”亲爹”Anthropic 发布了一篇重磅博客,为我们揭示了一个全新的视角。本文将深入解读这篇文章,探讨 MCP 的现状挑战以及它真正的未来。


一、社区对 MCP 的三大”罪状”

1.1 成本太高

根据 ScaleKit 的严格测试,在相同操作下:

方案 成本对比
CLI 基准成本
MCP 17倍于 CLI

这意味着使用 MCP 的成本是 CLI 的 17 倍,这是一个巨大的差距。

1.2 上下文占用严重

Perplexity 的 CTO 直言他们内部正在远离 MCP,原因惊人:

1
MCP 占用了高达 72% 的宝贵上下文窗口

对于需要长上下文的复杂任务,这几乎是不可接受的。

1.3 Schema 过于臃肿

以 GitHub 的 MCP 为例:

数据项 数值
工具数量 43 个
单工具描述 Token 4026 Token
每次交互 全部 43 个工具定义都要发给模型

每次交互都要把 43 个工具的”说明书”全部发给模型,光工具定义就占用了大量 Token,这无疑是巨大的浪费。


二、官方回应:三种连接方式,各有其场

面对这些批评,Anthropic 并没有直接反驳,而是给出了一个更宏观的框架。

2.1 Agent 连接外部系统的三种方式

方式 适用场景 优势 劣势
直连 API 简单场景 直接、快速 扩展性差,陷入 M×N 集成噩梦
CLI 本地环境 高效、灵活 无法在云端运行
MCP 云端环境 标准化、跨平台 成本较高

2.2 Anthropic 承认 CLI 的优势

Anthropic 大方承认:CLI 在本地环境确实高效。但他们强调了一个关键趋势:

1
越来越多的生产级 Agent 正在云上运行

在云端环境中:

  • 没有本地文件系统
  • 无法执行 CLI 命令
  • 如 Claude 网页版、移动端 App

MCP 的价值就体现出来了:它提供了一个标准化的远程连接层,能统一服务于各种客户端。

2.3 MCP 的全新定位

Anthropic 为 MCP 找到了一个全新的、也是它最该待的地方:

1
云端 Agent 的标准化接入层

无论是网页版的 Claude,还是集成在 VS Code 里的 Cursor,都可以通过一个统一的 MCP 服务器来访问后端服务。这个定位非常清晰。

2.4 市场数据印证

时间节点 MCP SDK 月下载量
早期 1 亿
当前 3 亿

短短几个月内下载量翻了 3 倍,这说明开发者们正在积极拥抱这个标准。


三、核心解法一:Tool Search(工具搜索)

Anthropic 提出了两个核心技术解法来解决 Token 消耗问题。

3.1 传统方式的痛点

1
2
3
传统方式:
每次交互 → 把一整本厚厚的说明书(全部工具定义)塞给模型
→ 巨大的 Token 消耗

3.2 Tool Search 的思路

1
2
3
Tool Search 方式:
模型先告诉系统它想做什么 → 系统去"书架"上找到对应的那几页说明书
→ 只把相关工具定义发给模型

核心理念:工具应该围绕用户意图来组织,而不是简单地按 API 来划分。

3.3 效果数据

指标 效果
工具定义 Token 减少 超过 85%
工具选择准确率 保持不变

这种”按需加载”的方式能直接砍掉超过 85% 的工具定义 Token,而且工具选择的准确率并没有降低。


四、核心解法二:程序化工具调用

第二个解法思路非常巧妙,它改变了工具返回结果的处理方式。

4.1 传统方式的问题

1
2
传统方式:
工具返回大量原始数据 → 直接涌入模型的上下文 → 上下文爆炸

4.2 程化调用的思路

1
2
3
程序化调用方式:
模型在安全的代码沙箱里写一小段代码 → 处理数据(过滤、计算、整合)
→ 只把精炼后的结果返回给模型

核心理念:别让模型当搬运工,让它写代码。

4.3 效果数据

任务类型 Token 减少幅度
复杂任务 约 37%

根据官方数据,这个方法在处理复杂任务时能额外减少约 37% 的 Token 消耗。


五、两个解法的综合效果

拿之前 ScaleKit 的测试数据来算一笔账:

5.1 原始差距

1
2
原始情况下:
MCP Token 消耗 = CLI 的 32 倍

这是一个巨大的鸿沟。

5.2 应用解法后

方案 Token 消耗估算
原始 MCP 约 32000 Token
Tool Search 后 约 10000 Token
CLI 约 1000 Token

差距从 32 倍缩小到约 7 倍。

5.3 成本合理性分析

虽然 MCP 还是比较 CLI 更贵,但这个差距已经不再是不可逾越的了。在云端环境下,MCP 带来的:

  • 标准化
  • 安全性
  • 跨平台能力

其价值完全可以覆盖这部分成本差异。


六、实战案例:Cloudflare 的聪明做法

理论说再多不如看一个实际案例。Cloudflare 是 MCP 的深度用户。

6.1 他们面临的挑战

1
需要通过 MCP 开放约 2500 个 API 端点

如果按传统方式,这简直是一场灾难。

6.2 聪明的解决方案

Cloudflare 的做法非常聪明:

设计 说明
对外暴露工具数 只有 2 个
工具名称 search + execute

6.3 工作流程

1
2
3
Agent 工作流程:
1. 用 search 找到需要的 API
2. 通过 execute 在服务端执行操作(像写脚本一样)

6.4 效果

指标 数值
工具定义 Token 约 1000 Token

这个案例完美诠释了 Anthropic 的理念:MCP 服务器应该像 CLI 一样设计,让 Agent 通过代码来编排和控制


七、MCP 与 Skills 的生态融合

除了解决技术问题,Anthropic 还在推动生态的融合。

7.1 MCP 与 Skills 的关系

角色 职责 类比
MCP 连接各种服务,提供”能力” 工具箱
Skills 告诉 Agent 如何使用能力完成任务 操作手册

7.2 Claude 数据插件案例

Claude 的数据插件是一个典型例子:

组成 数量
Skills 10 个
MCP 服务器 8 个

用户可以轻松地分析来自不同数据库的数据。

7.3 第三方服务商跟进

像 Canva、Notion 这些第三方服务商也开始效仿:

1
发布 MCP 服务器 + 配套 Skills

这标志着一个更加成熟和协同的 Agent 生态正在形成。


八、总结:未来的分工格局

Anthropic 的这篇博客,并非对社区批评的简单反驳,而是一次深刻的自我进化和战略澄清。

8.1 针对三大痛点的解决方案

痛点 解决方案
成本太高 Tool Search(减少 85% 工具定义 Token)
上下文占用 程序化调用(减少 37% 结果 Token)
Schema 臃肿 代码编排模式(Cloudflare 案例)

同时,Anthropic 也大方承认了 CLI + Skills 模式的价值,并将 Skills 正式纳入了官方最佳实践。

8.2 MCP 的主战场

1
云端和跨平台环境 → MCP 是目前唯一合理的标准化解决方案

8.3 未来的分工格局

环境 最佳实践
云端生产环境(面向用户的 SaaS) MCP + Skills
开发者本地环境 CLI + Skills
简单任务 直连 API

不存在一个万能的解决方案,Agent 时代的连接层正在走向多元化和专业化。


附录:关键数据汇总

数据项 来源 数值
MCP vs CLI 成本差距 ScaleKit 测试 17 倍
MCP 上下文占用 Perplexity CTO 72%
GitHub MCP 工具数 官方 Schema 43 个
Tool Search Token 减少 Anthropic 85%+
程序化调用 Token 减少 Anthropic 37%
MCP SDK 月下载量 npm 数据 3 亿
Cloudflare 工具定义 Token 实战案例 1000

结论

MCP 并没有死,它只是找到了属于自己的战场。Agent 时代的连接层正在走向多元化和专业化。作为技术从业者,我们需要理解不同工具的适用场景,并根据自己的业务需求做出最合适的技术选型。


参考资源

用 Claude Code 写代码写到一半,突然感觉它”变笨了”——回复变慢、忘记之前说过的东西、开始犯低级错误。老手遇到这种情况,会默默敲一行 /compact,然后继续干活。今天我来分析一下 /compact 具体干了些啥。

阅读全文 »