基于 @anthropic-ai/claude-code v2.1.88 源码，从产品视角拆解 Claude Code 的架构。不讨论代码实现细节（主要是不会），只看”为什么这么设计”。哈哈，我要是再写三国人物，都快忘记自己是干什么的了。

核心问题

总的来说，Claude Code 用了512,000 行源码，都在解决一个问题：

当 AI 已经”几乎什么都能做”时，产品要解决的就不再是能力，而是，如何让用户在不失控的前提下，逐步把控制权交给 AI。

源码中每一个模块，都在这条线上承担不同角色。下面从”能做什么”，到”做到什么程度”，到”用户敢不敢用”拆开看。

一、能力的可组合表达：工具即语言

Claude Code 有 40+ 个工具（Tool），每个工具是一个独立模块：prompt.ts 定义描述，UI.tsx 定义渲染，constants.ts 定义命名。

工具不是给用户看的功能菜单，而是给模型用的语言。每个工具的 prompt 本质上是一段 system prompt 片段，告诉模型”你有这个能力，这样用”。

关键设计在于工具集是按角色分配的。源码中 ALL_AGENT_DISALLOWED_TOOLS 定义了子代理不能碰的工具（如 ExitPlanMode、TaskStop），ASYNC_AGENT_ALLOWED_TOOLS 定义了异步代理能用的子集。不同 Agent 角色拥有不同工具集，这比”一个角色一套权限”精细得多。

产品判断：传统 AI 产品把能力封装在后端，用户无感。Claude Code 反过来，把每个能力拆成显式工具，让用户和模型都能感知”我有锤子，我有扳手”。这让工具组合变得可预期，也让后面要讲的权限管控有了精确的粒度。

二、可控的风险暴露：三层权限系统

Claude Code 的权限不是简单的”允许/拒绝”，而是三层防线。

第一层，PermissionMode（全局模式）：default 逐个审批，plan 只读，bypassPermissions 全跳过。

第二层，PermissionRule（规则引擎）：按工具名、路径、操作类型设规则，支持 allow / deny / ask 三种行为，来源可以是 settings、CLAUDE.md、插件配置。

第三层，classifier（命令分类器）：源码中有 bashClassifier 和 yoloClassifier，对 bash 命令做风险分级，读操作自动放行，写操作可能确认，破坏性操作强制拦截。

产品判断：核心矛盾是信任与安全的平衡。默认模式下每个写操作都确认，用户体验碎裂；全跳过有风险。解法是让分类器自动判断风险等级，低风险通过，高风险拦截。

但这套系统也有问题。classifier 会误判，某些看起来无害的命令可能有副作用，而某些复杂命令反而安全。用户很难理解规则的优先级逻辑，debug 时更难追踪”为什么这个操作被拦了”。权限系统从”产品功能”变成了”需要产品本身文档化的产品功能”，这是一个递归问题。

三、延迟执行的信任机制：Plan Mode

EnterPlanModeTool 和 ExitPlanModeV2Tool 构成了一个”计划模式”。进入后 AI 只能读文件、搜索代码、分析架构，不能做任何修改。退出需要用户显式确认，计划本身可以被审批。

产品判断：这解决了一个核心焦虑，”AI 会不会乱改我的代码？” Plan mode 让用户可以放心把整个项目丢给 AI 分析，因为知道它不会动手。分析完、看完计划、确认没问题，才切换执行。

更抽象地说，这是一种”延迟执行的信任机制”，AI 先证明自己理解了问题，再被允许去解决问题。信任不是预设的，是通过”只读阶段”的分析质量建立的。

四、行为的精确控制：classifier、sandbox 和 hook

权限之外，Claude Code 还有一层行为控制机制。

Sandbox（沙箱）：源码中有完整的 sandbox adapter，工具执行可以在隔离环境中运行。这比”允许/拒绝”更进一步，不是阻止操作，而是限制操作的影响范围。

Hooks（钩子系统）：用户可以配置 shell 命令，在工具调用前后自动执行。系统提示词明确写了：”Treat feedback from hooks as coming from the user. If you get blocked by a hook, determine if you can adjust your actions.”

Anti-Distillation（反蒸馏）：ANTI_DISTILLATION_CC 标志触发时，会在 API 请求中注入虚假工具定义，目的是污染竞争对手的训练数据。虽然社区指出用代理就能绕过，但产品意图很明确，保护自己的知识产权。

产品判断：这三层（权限、沙箱、钩子）构成了一个递进的控制体系。权限控制”能不能做”，沙箱控制”做了影响多大”，钩子控制”做了之后外部系统怎么反应”。对于一个会自主执行命令的 AI 来说，这种纵深防御是必要的。

五、有限资源下的无限体验：成本约束架构

Claude Code 在架构层面就在控制成本。

Prompt Caching（缓存分界线）：系统提示词被 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 标记分成两个区域。前面是静态内容（身份、工具指南、风格），所有 session 共享，可以用 scope:’global’ 缓存；后面是动态内容（环境信息、语言偏好），每个 session 不同。

这意味着每次对话只重新计算变化的部分，静态区域走缓存，大幅降低 token 消费。不是”先做出来再说”，而是在架构层面解决经济性问题。

Token Budget：允许用户指定 token 预算（如 “+500k”），系统自动规划工作量填满预算。这让用户对成本有预期，也让系统可以更高效地分配推理资源。

产品判断：AI 产品的成本结构决定了它能走多远。Claude Code 的做法是从产品架构层面控制成本，而不是事后优化。这是”平台产品”和”实验产品”的分水岭。

六、上下文的有限与假装无限：autoCompact

系统提示词写了：”The system will automatically compress prior messages in your conversation as it approaches context limits. This means your conversation with the user is not limited by the context window.”

源码中 services/compact/ 目录下有完整的压缩管线：

autoCompact.ts：监控 token 使用量，触发压缩

compact.ts：执行压缩（调用 API 总结历史）

microCompact.ts：轻量级压缩（只清理工具结果）

reactiveCompact：响应式压缩（feature flag 控制）

产品判断：这是”无限上下文”的障眼法，但也是正确的做法。用户不需要理解上下文窗口、token 限制这些技术概念，他们只想”一直聊下去”。Claude Code 把复杂的上下文管理隐藏在自动机制后面，用户感知到的就是”对话没有限制”。

更关键的是，这跟第五节的成本控制是联动的，压缩本身消耗 token（要调 API 做总结），所以”什么时候压缩”、”压缩多少”是一个成本与体验的权衡问题，不只是技术问题。

七、平台化的边界扩展：插件系统

Claude Code 的插件架构覆盖了几乎所有产品层面：

Commands：注册斜杠命令

Hooks：工具调用前后执行脚本

Agents：注册自定义 Agent 类型

Output Styles：定制输出风格

Skills：注册可复用技能

MCP 集成：声明 MCP 服务器依赖

源码中 utils/plugins/ 有完整的生命周期管理：安装、版本控制、依赖解析、自动更新、Marketplace 分发。

产品判断：插件系统透露的野心是，Claude Code 不想只做终端工具，而想成为 AI 编程的”操作系统”。通过插件，它可以扩展到 Slack、GitHub、自定义 Agent 等任意场景。策略像 VS Code，核心产品提供基础能力，生态提供无限可能。

同时插件系统也服务于前面的权限框架，插件的 hooks 可以嵌入权限检查流程，插件的 agents 受到工具集限制。这意味着扩展能力的同时，控制体系也在扩展，而不是被绕过。

八、从工具到角色：未发布功能揭示的未来

源码中暴露了大量未发布功能的 feature flag，其中三个构成了一个连贯的未来图景。

KAIROS（自主守护进程）：一个常驻后台 Agent，定期接收 tick 唤断醒，判断是否主动执行任务。它有完整的 pacing 机制（用 SleepTool 控制频率）、terminal focus 感知（用户在看时更协作，离开时更自主）、bias toward action（有判断就执行，不问确认）。

autoDream（后台记忆整合）：在用户空闲时，fork 一个子代理做记忆整合，合并观察、消除矛盾、把模糊洞察转成确定事实。这是”AI 自己整理自己的大脑”。

BUDDY（电子宠物）：18 个物种、稀有度分级（普通 60% 到传说 1%）、闪光变体、属性系统（DEBUGGING、PATIENCE、CHAOS、WISDOM、SNARK）。原计划 2026 年 4 月彩蛋发布。

产品判断：这三个功能放在一起看，方向很清楚，AI 从”被动响应的工具”正在变成”有自己节奏的角色”。KAIROS 是行动层（什么时候做什么），autoDream 是认知层（怎么理解过去的交互），BUDDY 是情感层（怎么让用户在意这个 AI）。

还有一层更深层的变化，从”单次交互”到”持续关系”。KAIROS 模式下 AI 不再是”你问它答”，而是”它在你不问的时候也在工作”。这改变了产品的根本形态，用户不再拥有一个”工具”，而是拥有一个”同事”。

回到核心问题

Claude Code 源码中最有价值的洞察不是某个具体功能，而是它在处理的核心张力：

AI 的能力正在逼近”什么都行”，但产品的挑战是”什么该做”。

工具系统解决”能力可表达”，权限系统解决”风险可控制”，Plan mode 解决”信任可建立”，成本架构解决”经济可持续”，插件系统解决”生态可扩展”，KAIROS 解决”关系可延续”。

这些设计不是独立的，它们共同指向一个产品判断：

当 AI 已经很强时，产品价值不在 AI 能做什么，而在用户敢让它做什么。信任、控制、成本，这三个维度的工程化，才是 AI 产品的真正护城河。

感谢阅读，求关注，求转发