Claude Code 作为一款循环代理系统，其设计逻辑远超普通聊天机器人。从上下文工程到工具设计，从 Skills 分层到 Subagents 隔离，这套系统需要精细治理而非简单调参。本文深度拆解六大核心层级，提供实战框架与健康检查方案，助你驾驭真正的工程级 AI 协作。

最近半年，我深度体验了 Claude Code。从最初把它当成普通聊天机器人，到后来发现上下文混乱、工具堆积后效果反而变差，我才意识到这不是单纯的提示词问题，而是整个系统设计的本质使然。经过反复研究和实践，我总结出一套完整的治理框架，希望能帮大家少走弯路。

Claude Code 的本质是一个反复循环的代理系统，而不是单纯的“问答机”。卡住的地方往往不是模型不够聪明，而是上下文加载错误、判断机制缺失或无法回滚。理解它的核心，就是把它拆成六层来看：底层运行机制、概念边界、上下文工程、Skills 设计、工具与 Hooks、Subagents 以及 Prompt Caching。如果只强化某一层，系统就会失衡——规则写得太长反而污染自己，工具太多就选择混乱，子代理到处开就状态漂移，验证环节缺失就根本不知道哪里出问题。

底层运行机制：反复循环的代理过程

Claude Code 的核心是“循环代理”而非一次性回答。真正需要关注的五个层面包括：

1. 输入层：用户指令 + 当前上下文
2. 模型层：Claude 的推理与决策
3. 工具层：外部动作能力
4. 控制层：状态管理与回滚
5. 输出层：验证与持久化

很多问题排查起来其实很简单：结果不稳定就查上下文加载顺序；自动化失控就看控制层设计；长会话质量下降就清理中间产物。换个新会话往往比反复调提示词更有效。

概念边界：清晰区分不同能力

记住这个简单口诀：

• Tool / MCP：给新动作能力
• Skill：给一套工作方法
• Subagent：隔离执行环境
• Hook：强制约束与审计
• Plugin：跨项目分发

搞清楚边界，就能避免把所有东西塞到一个篮子里。

上下文工程：最重要的系统约束

很多人以为上下文只是“容量问题”，其实真正卡住的是“噪音太多”。

Claude Code 的 200K 上下文并非全可用，一个典型 MCP Server（比如 GitHub）就会占用 4,000–6,000 tokens，接 5 个 Server 就吃掉 12.5% 的窗口。

推荐的分层实践：

• 偶尔用的东西不要每次加载
• CLAUDE.md 保持短小精悍（官方示例仅 2.5K tokens）
• 大型参考文档拆到 Skill 的 supporting files
• 用 .claude/rules/ 处理路径/语言差异
• 长会话主动用 /context 查看消耗，及时 /clear 或 /compact
• 写好 Compact Instructions，让压缩后保留关键信息

默认压缩算法会优先删掉早期 Tool Output 和架构决策，导致“两小时前定的规则突然消失”。解决办法是开新会话前让 Claude 写一份 HANDOFF.md，记录进展、死路和下一步计划，新实例只需读这份文件就能无缝接力。

Plan Mode 的价值在于把“探索”和“执行”拆开：先只读澄清目标、提交方案，确认后再动文件。复杂重构时尤其有效——甚至可以让一个 Claude 写计划，另一个以“高级工程师”身份审核，实现 AI 审 AI。

Skills 设计：按需加载的工作流

Skill 不是模板库，而是“描述符常驻、内容按需加载”的工作流。好的 Skill 要满足：

• 描述写“何时用我”，而非“我是干什么的”
• 包含完整步骤、输入输出和停止条件
• 正文只放导航和核心约束，大资料放 supporting files
• 有副作用的 Skill 必须设置 disable-model-invocation: true

三种典型类型：

1. 检查清单型（质量门禁）
2. 工作流型（标准化操作 + 回滚）
3. 领域专家型（固定路径收集证据）

低频 Skill 建议 disable-auto-invoke 或直接移到 AGENTS.md，避免常驻上下文。反模式包括描述过短、正文过长、一 Skill 覆盖五件事等。

工具设计：让 Claude 少选错

给 Agent 的工具和给人用的 API 不同——重点不是功能全，而是“容易用对”。实用原则：

• 名称前缀分层（github_pr_*）
• 支持 concise / detailed 响应格式
• 错误响应要教模型如何修正
• 能合并就合并，避免碎片工具让模型自己筛选

Claude Code 团队的演进经验值得借鉴：从“在工具参数里加提问”到“独立 AskUserQuestion 工具”，效果提升巨大。因为只有显式调用才能强制暂停。Todo 工具也一样——模型变强后，它反而成了枷锁。

什么时候不该加 Tool？本地 shell 就能可靠完成的事、只需静态知识的任务，或更适合 Skill 约束的工作流。

Hooks：把不确定性收回到确定性流程

Hooks 不是“自动脚本”，而是把不能让 Claude 临场发挥的事强制化。比如格式化、保护文件、任务完成通知等。

适合放 Hooks 的：阻断修改受保护文件、Edit 后自动 lint、SessionStart 注入动态上下文、完成后推送通知。 不适合：复杂语义判断、长时间业务流程、多步决策（这些放 Skill 或 Subagent）。

Hooks + Skills + CLAUDE.md 三层叠加，才能真正稳住：规则写在 CLAUDE.md，顺序在 Skill，硬校验在 Hook，缺任何一层都会有漏洞。

Subagents：隔离执行的独立实例

Subagent 的核心价值是隔离而非并行。扫代码库、跑测试、做审查这类会产生大量输出的任务，交给 Subagent，主线程只拿摘要，避免污染。

配置要点：限定 tools、选合适 model、设 maxTurns、isolation: worktree。长时间 bash 可 Ctrl+B 后台运行，Subagent 也一样。

反模式：权限和主线程一样宽、输出格式不固定、子任务强依赖。

Prompt Caching：架构核心

整个 Claude Code 都围绕 Prompt 缓存设计。高命中率不仅省钱，还放宽速率限制。

缓存按前缀匹配，因此顺序至关重要。破坏缓存的陷阱：系统 Prompt 放时间戳、随意打乱工具顺序、中途增删工具。动态信息（如当前时间）应放在用户消息里，不要动系统 Prompt。

会话中途切换模型会重建缓存，更贵——必要时用 Subagent 交接。Compaction（压缩）其实是开 fork 让模型总结历史，命中缓存只需 1/10 价格。defer_loading 让工具延迟加载，保持缓存稳定。

验证闭环：没有 Verifier 就没有工程 Agent

“Claude 说完成了”没用，必须有明确验证层级：

• 最低：退出码、lint、单元测试
• 中间：集成测试、截图对比、smoke test
• 更高：生产日志、监控指标、人工审查

在 Prompt、Skill 和 CLAUDE.md 中提前写清楚验收标准。如果你连“什么叫做好了”都说不清，这个任务就不适合直接扔给 Agent。

高频命令：主动管理上下文

这些命令的核心是主动治理，别等系统自动处理：

• /context、/clear、/compact、/simplify、/rewind、/btw、/insight
• 双击 ESC 快速回溯上一条输入
• 所有历史存本地 ~/.claude/projects/，grep 就能搜索

如何写好 CLAUDE.md

CLAUDE.md 是你和 Claude 的“协作契约”，只放每次会话都必须成立的事：构建/测试/运行方式、目录边界、代码风格、NEVER 列表、Compact Instructions。

不放：大段背景、完整 API、空泛原则、Claude 自己能读仓库推断的信息。最佳实践是先用起来，发现反复出现的问题再补充。每次纠正错误后，让 Claude 自己更新：“Update your CLAUDE.md so you don’t make that mistake again。”

实战经验、反模式与健康检查

在混合语言项目（Rust + Lua）中，我发现环境透明最重要：先跑 doctor 命令收敛状态，再暴露编辑入口。Hooks 可按文件类型分别触发 lint。

常见反模式包括：把所有规则塞 CLAUDE.md、Skill 描述过短、工具碎片化、Subagent 权限过宽等。

我把六层框架做成了开源 Skill（tw93/claude-health），一行命令 npx skills add tw93/claude-health 后跑 /health，就能自动检查你的配置，给出优先级报告。

结语

用 Claude Code 会经历三个阶段：从“功能怎么用”，到“流程怎么优化”，再到“怎么让 Agent 在约束下自主稳定运行”。

最关键的问题是：如果你说不清“什么叫做完”，这个任务大概率就不适合交给 Claude。