Howie2099

Claude Code 四层架构与 Agentic Loop

记忆/扩展/集成/编程四层架构+Agentic Loop循环，附组件选型决策树

2026-07-21
AgentAIClaude

🎯 核心主张（一句话）

Claude Code 的全部能力可以压缩成一张四层地图（记忆→扩展→集成→编程）加一颗心脏（Agentic Loop）；选型不靠背功能，靠一棵"谁触发、在哪跑、要不要隔离"的决策树。

📖 正文

四层架构：一栋摩天大楼

Claude Code 的完整技术栈自下而上分四层，书中用大楼作比：

  • 记忆层（CLAUDE.md）= 地基。Claude 是无状态模型，每次新对话对项目一无所知。CLAUDE.md 是"给 AI 的员工手册"，会话启动时自动加载，一次写清技术栈、规范、常用命令。地基决定承载上限：上层所有机制都建立在 Claude 正确理解项目上下文的前提上。
  • 扩展层（Commands / Skills / 子智能体 / Hooks）= 主体楼层。四大组件正交：Commands 是用户手动触发的标准化工作流（命令模式）；Skills 由 Claude 按语义自动加载领域知识；子智能体为大任务开辟隔离上下文、只回传结论；Hooks 在事件节点做确定性拦截（中间件模式）。职责一句话分清：CLAUDE.md 管"知道什么"，Skills 管"怎么做"，子智能体管"谁来做"，Hooks 管"能不能做"。
  • 集成层（Headless + MCP）= 水电管网。Headless 让 Claude "走出去"嵌入 CI/CD 流水线（claude -p 非交互运行）；MCP 让外部能力"走进来"（数据库、GitHub、Jira 经标准协议接入）。一出一进，两大支柱。
  • 编程层（Agent SDK）= 顶楼建筑师工作室。这是使用者与构建者的分水岭：前三层靠配置文件延展行为，跨过 SDK 就能用 Python/TS 代码直接驱动核心能力，构建自己的 Agent。Claude Code 本身就是用 Agent SDK 建出来的一个 Agent——它是一种架构模式的实现，不只是一款产品。

阅读方向也有讲究：自下而上是构建视角（看支撑），自上而下是使用视角（看功能）。

5 级记忆体系概览

记忆层不是单个文件，而是一个 5 级体系：从全局到本地逐级覆盖，越具体的层级优先级越高——和 CSS 层叠、"全局-用户-项目-本地"四级配置是同一套工程思想。细节见 CLAUDE.md 记忆系统工程。

Agentic Loop：Harness 的心脏

Claude Code 收到任务后不是"看一眼就猜答案"，而是跑一个循环：收集上下文 → 推理 → 行动（工具调用）→ 观察反馈 → 再推理。修一个 bug 的真实过程是：查报错日志、搜相关代码、理解上下文、然后才动手改。

循环只在两种情况下终止：模型自认任务完成、不再发起工具调用；或撞到 --max-turns 轮次上限（防无限循环，也是成本护栏）。

为什么说它是心脏：四层架构里的一切机制，最终都是往这个循环里注入东西——CLAUDE.md 注入初始上下文，Skills 注入领域知识，Hooks 在循环的工具调用节点上拦截，子智能体是把一段循环外包到隔离上下文里跑。复杂行为不是预先编排出来的，而是从"观察-假设-验证"的反复迭代中涌现的——这也解释了为什么优化 Harness（喂进循环的东西）比换模型更能改变表现。

一次请求的完整旅程

以"审查 src/payment/ 最近的代码变更，确保没有安全隐患"为例，各组件自动接力：记忆层先构建项目上下文 → Skills 按语义注入审查领域知识 → 子智能体在隔离环境里执行审查、只回传结论 → Hooks 在关键操作前守住质量与安全关卡。用户只说了一句自然语言，其余全部自动编排——这就是"可组合性"：单个组件是积木，组合起来是流水线。

但注意：这是"全家桶"演示。实际工程里多数任务用不到全部组件，价值不在"全部用上"，而在"按需调用"。

组件选型决策树（全书最实用的工具）

按顺序问自己三个问题：

第一问：谁触发这个任务？

  • 人触发 → 再问逻辑复杂度：步骤固定、每次一样（发版检查清单）→ Commands；需要 Claude 按情境判断（领域知识咨询）→ Skills。
  • 自动触发 → 再问在哪触发：在特定事件节点（提交前拦敏感信息）→ Hooks（PreToolUse）；在 CI/CD 流水线（PR 提交后自动审查）→ Headless 模式（常与 Commands 组合）。

第二问：运行环境有什么约束？（叠加项，不互斥）

  • 任务量大、怕上下文溢出、需要隔离 → 叠加子智能体。
  • 要访问外部系统（数据库、GitHub Issue、第三方 API）→ 叠加 MCP。
  • 需要代码级编排控制（多 Agent 流水线、嵌入自有服务）→ 上 Agent SDK。

第三问（校验）：能不能更简单？ 选型第一原则是用最简单的方案解决当前问题。别刚学会子智能体就处处委派，别刚会 Hooks 就给每个小操作加守卫——过度工程化和工程化不足同样有害，很多问题一份 CLAUDE.md 就够了。

辅助记忆的触发机制口诀：Commands 是"你叫它做"，Skills 是"它自己知道该做"，子智能体是"它安排别人做"，Hooks 是"不管谁做，到这一步必查"。更本质的二分法：Commands 和 Hooks 是确定性触发，Skills 和子智能体是 AI 自主判断——安全场景优先用确定性的 Hooks，灵活场景才交给 AI 判断。

另外两点澄清：Commands 最新已并入 Skills 体系（成为用户以 /command 触发的"任务型 Skill"），但手动显式触发与语义自动触发的区分依然是理解架构的关键；Plugins 不是新能力而是打包机制——Skills 定义能力类型，Plugins 定义分发形式，类比 npm 之于 Node.js。

🧭 业界视角（书外补充）

  • 社区共识的分层选型法（与书中决策树互相印证）：提示词模板 → slash command；有领域逻辑和辅助文件 → Skill；需要隔离上下文的并行工作 → 子智能体；必须 100% 执行的规则 → Hook。最常见的错误不是不会用某机制，而是"对的工具放错了层"——该 Hook 强制的行为写进了系统提示词，只能概率性生效。
  • Shrivu Shankar 的子智能体警告：自定义子智能体会"看守"上下文——建一个 PythonTests 子智能体后，主 agent 就看不到测试相关上下文，无法整体推理。子智能体适合"结论可压缩"的任务（搜索、调研、验证），不适合切走核心工程上下文。用决策树时要加这条约束。（来源：blog.sshh.io "How I Use Every Claude Code Feature"）
  • Anthropic 官方上下文工程三手段：上下文是稀缺资源，性能随填充度衰减。compaction（压缩）、just-in-time retrieval（用时才取）、structured note-taking（状态写进文件而非留在对话里）——这三招本质都是在保护 Agentic Loop 每一轮的信噪比。
  • Simon Willison 的 Skill 先行策略：三种扩展机制里 Skill 创建成本最低、见效最快。先写 Skill，需要强制时再加 Hook，需要隔离时再上子智能体——给决策树补了一个"从哪开始"的默认路径。

🔗 知识网络