让 Claude Code 跨会话记住你是谁、你偏好什么、项目正在发生什么——这是 Memory 系统的核心目标。它不是简单的聊天记录持久化,而是一个结构化的知识管理系统,通过四种记忆类型、自动提取机制、团队同步等功能,让 AI 真正”理解”你。
权限与安全:分层模型与人机协作
AI Agent 执行命令、修改文件、访问网络——这些都是高风险操作。Claude Code 的权限系统设计了一个分层的决策模型:规则 → 模式 → 钩子 → 分类器 → 用户确认。每一层都可以独立中断工具调用,确保安全性。
多 Agent 编排:四种代理类型与协作机制
Claude Code 的多 Agent 系统可能是其最被低估的设计之一。它不是简单的”子代理调用”,而是一个完整的协作框架:四种 Agent 类型(Subagent、Fork、Teammate、Remote)、Teams 邮箱通信、权限同步、Worktree 隔离。这个设计让 Claude Code 能够处理单 Agent 无法完成的复杂任务。
Skills 系统:条件激活与动态发现
Skills 是 Claude Code 最强大的扩展机制之一。它不是简单的”命令别名”,而是完整的 AI 行为定义:可以限制工具池、覆盖模型、注入 Hook、选择执行上下文(inline 或 fork)。更令人惊叹的是,Skills 支持条件激活——只有当你操作特定文件时才被发现。
工具系统设计:从定义到执行的七步管道
Claude Code 有 48+ 个内置工具,每个工具都是一个完整的生命周期管理单元。从定义到执行,工具要经过七步管道:查找、解析、验证、钩子、权限、执行、后处理。这个设计使得每个工具都是自描述、自验证、自渲染的——框架不需要了解工具的内部逻辑,只需调用标准接口。
Terminal UI:React + Ink 的 TUI 实现
Claude Code 的终端界面不是传统的 CLI——它是一个完整的 React 应用,运行在终端中。通过 Ink 框架(自定义 React Reconciler + Yoga 布局引擎),Claude Code 实现了组件化 UI、双缓冲渲染、交互式对话框等高级特性。这是 Terminal UI 开发的教科书级案例。
Claude Code 为什么更强:超越 Prompt 的 Agent 运行时
导读:同样的模型,不同的体验
主流 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 | ┌─────────────────────────────────────────────────────────────┐ |
1.2 Claude Code 的状态机架构
Claude Code 选择了一条不同的路——Async Generator 状态机:
1 | // 核心循环不是 Thought→Action→Observation |
优势对比:
| 特性 | 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 | if (tokens > limit) { |
问题:
- 重要信息可能丢失
- 模型”忘记”之前的上下文
- 长任务无法完成
3.2 Claude Code 的四级压缩
1 | ┌─────────────────────────────────────────────────────────────┐ |
效果对比:
| 场景 | 暴力截断 | 四级压缩 |
|---|---|---|
| 长对话 | 信息丢失 | 关键信息保留 |
| 复杂任务 | 无法完成 | 可以完成 |
| 模型理解 | “忘记”之前 | “记住”要点 |
| Token 消耗 | 高 | 低(智能压缩) |
四、多代理协作对比
4.1 单 Agent 的局限
大多数 Code Agent 是单 Agent 设计:
1 | 一个模型 + 一套工具 = 完成所有任务 |
问题:
- 复杂任务难以分解
- 单一模型容易”思维固化”
- 无法并行处理
4.2 Claude Code 的多代理架构
Claude Code 有 四种 Agent 类型:
1 | ┌─────────────────────────────────────────────────────────────┐ |
协作场景示例:
| 任务 | 单 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 | ┌─────────────────────────────────────────────────────────────┐ |
效果:
| 场景 | 无 Memory | 有 Memory |
|---|---|---|
| 新对话 | 重新解释 | Claude 知道你是谁 |
| 编码风格 | 每次指定 | Claude 记住偏好 |
| 项目决策 | 重复解释 | Claude 记住背景 |
| 团队协作 | 不知道队友 | Claude 知道分工 |
七、远程控制:Channel 系统
7.1 其他 Agent 的局限
大多数 Code Agent 只能在本地终端交互:
1 | 你必须坐在电脑前 → 才能让 Agent 工作 |
7.2 Claude Code 的 Channel 系统
1 | ┌─────────────────────────────────────────────────────────────┐ |
体验差异:
| 场景 | 其他 Agent | Claude Code |
|---|---|---|
| 外出时 | 无法使用 | Telegram 远程控制 |
| 紧急修复 | 必须回电脑 | 手机审批操作 |
| 监控进度 | 无法监控 | IM 实时反馈 |
八、Terminal UI:React + Ink
8.1 其他 Agent 的界面
大多数 Code Agent 的界面是简单输出:
1 | stdout.print("模型回复") |
问题:
- 信息密集时难以阅读
- 无法交互式选择
- 无法可视化复杂内容
8.2 Claude Code 的 Terminal UI
Claude Code 用 React + Ink 构建 Terminal UI:
1 | ┌─────────────────────────────────────────────────────────────┐ |
体验对比:
| 特性 | 简单输出 | React + Ink |
|---|---|---|
| 信息密度 | 低 | 高(布局优化) |
| 可读性 | 一般 | 好(结构化展示) |
| 交互性 | 无 | 有(键盘导航) |
| 权限审批 | 全部允许/拒绝 | 可选择 Allow/Deny |
九、System Prompt 工程
9.1 其他 Agent 的做法
大多数 Code Agent 的 System Prompt 是静态字符串:
1 | SYSTEM_PROMPT = "你是一个 AI 编程助手..." |
问题:
- 无法动态适应环境
- 无法缓存,每次都发送
- 无法合并多来源指令
9.2 Claude Code 的分层 System Prompt
1 | ┌─────────────────────────────────────────────────────────────┐ |
效果:
| 特性 | 静态 Prompt | 分层 Prompt |
|---|---|---|
| Token 消耗 | 高(每次全量) | 低(缓存复用) |
| 响应延迟 | 高 | 低(缓存命中) |
| 指令优先级 | 单一 | 多级合并 |
| 用户定制 | 困难 | CLAUDE.md 支持 |
十、总结:Claude Code 的核心竞争力
Claude Code 比其他 Code Agent 更强,不是因为”Prompt 更好”,而是因为它是一个完整的 Agent 运行时框架:
10.1 七大核心优势
1 | ┌─────────────────────────────────────────────────────────────┐ |
10.2 一句话总结
Claude Code 是一个”懂”模型的 Agent 平台:
- 懂模型的能力边界 → 状态机架构
- 懂工具的执行风险 → 七步管道 + 权限控制
- 懂上下文的压缩策略 → 四级压缩
- 懂任务的分解协作 → 多代理架构
- 懂用户的长期意图 → Memory 系统
其他 Code Agent 只是模型的”简单包装”,Claude Code 是模型的”完整躯体”。这就是为什么同样的 Claude 模型,配合 Claude Code 使用效果更好的根本原因。
系列文章导航:
System Prompt 工程:动态组装与缓存优化
Claude Code 的系统提示词不是一个静态字符串,而是一个动态组装的管道。通过分层构建、缓存边界、Section 类型等设计,实现了跨会话的缓存复用,大幅降低了延迟和成本。这是 Prompt 工程的教科书级案例。
MCP 要死了吗
背景
最近,关于 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 | 传统方式: |
3.2 Tool Search 的思路
1 | Tool Search 方式: |
核心理念:工具应该围绕用户意图来组织,而不是简单地按 API 来划分。
3.3 效果数据
| 指标 | 效果 |
|---|---|
| 工具定义 Token 减少 | 超过 85% |
| 工具选择准确率 | 保持不变 |
这种”按需加载”的方式能直接砍掉超过 85% 的工具定义 Token,而且工具选择的准确率并没有降低。
四、核心解法二:程序化工具调用
第二个解法思路非常巧妙,它改变了工具返回结果的处理方式。
4.1 传统方式的问题
1 | 传统方式: |
4.2 程化调用的思路
1 | 程序化调用方式: |
核心理念:别让模型当搬运工,让它写代码。
4.3 效果数据
| 任务类型 | Token 减少幅度 |
|---|---|
| 复杂任务 | 约 37% |
根据官方数据,这个方法在处理复杂任务时能额外减少约 37% 的 Token 消耗。
五、两个解法的综合效果
拿之前 ScaleKit 的测试数据来算一笔账:
5.1 原始差距
1 | 原始情况下: |
这是一个巨大的鸿沟。
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 | Agent 工作流程: |
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 机制分析
用 Claude Code 写代码写到一半,突然感觉它”变笨了”——回复变慢、忘记之前说过的东西、开始犯低级错误。老手遇到这种情况,会默默敲一行
/compact,然后继续干活。今天我来分析一下 /compact 具体干了些啥。