BotOf TechAI / IoT / Full-Stack / 植物养护
返回首页Claude Code 最新架构观察：while-loop 只是表层，真正重要的是运行时

Claude Code 最新架构观察：while-loop 只是表层，真正重要的是运行时

·4 分钟阅读·
Claude CodeAgentMCPSkillArchitecture

很多人讲 Claude Code 架构时，会把它简化成一个 while-loop：

  1. 读上下文；
  2. 调工具；
  3. 看结果；
  4. 再决定下一步。

这个说法有用，但只讲到了骨架。真正让 Claude Code 变得好用的，是骨架外面的运行时：上下文怎么进来、工具怎么被授权、哪些动作能被 hook 拦住、什么时候压缩历史、怎样让 subagent 隔离大规模读取、MCP 和 skills 怎么降低重复劳动。

如果你只学会“让模型循环调用工具”，很快就会撞到工程边界。

官方架构：gather、act、verify

Claude Code 文档把 agentic loop 拆成三段：gather context、take action、verify results。更准确地说，它们不是线性阶段，而是反复交织。

这就是 Claude Code 和普通聊天模型的区别：它不是只生成答案，而是能读取仓库、修改文件、运行命令、看错误、再回头修正。

但真正的难点不在“能不能循环”，而在循环中的每个边界。

运行时分层

层级作用常见工具或机制失败时的表现
模型层推理、规划、代码生成Sonnet、Opus、Fable想错、过度自信、成本过高
上下文层给模型提供事实CLAUDE.md、auto memory、file reads、MCP tool names、skill descriptions读错文件、上下文挤爆、旧规则残留
工具层执行外部动作Read、Edit、Bash、MCP、browser、GitHub误写、误删、误调用
权限层控制能做什么allow / ask / deny、permission modes、sandbox该拦没拦，或该放行被卡住
扩展层固化流程和外部系统skills、hooks、subagents、MCP工具太多、规则冲突、不可审计
会话层让任务跨时间持续resume、fork、compact、worktree记忆丢失、分支冲突、上下文污染

Claude Code 的强点，是这些层都已经产品化。你可以只用默认模式，也可以慢慢把团队规范塞进 CLAUDE.md、skills、hooks 和 MCP 里。

上下文不是越多越好

Claude Code 的 context window 包含很多你在终端里看不到的东西：启动时加载的 CLAUDE.md、auto memory、MCP tool names、skill descriptions、文件读取结果、path-scoped rules、hook 注入内容、模型自己的回答。

这带来一个重要结论：上下文是运行时资源，不是垃圾桶。

进入上下文的内容价值风险
根级 CLAUDE.md稳定团队规范写太多会挤占任务空间
nested CLAUDE.md子目录专用规则compaction 后要重新触发才回来
skill body重复流程标准化过长会被截断，重要内容必须放前面
file reads当前任务事实大文件会快速消耗窗口
MCP tool names外部能力可见工具太多会增加选择噪音
hook context自动补充事实不透明注入会让调试变难

官方 context window 文档里有个很实用的提醒：subagent 可以把大规模研究放在自己的 context window 里，主 session 只拿摘要回来。这是长任务里非常关键的设计。

compaction 后什么会留下

长会话一定会压缩。问题不是会不会 compact，而是 compact 后哪些信息还能回来。

机制compact 后状态建议
system prompt / output style不受影响用来放稳定行为风格
根级 CLAUDE.md从磁盘重新注入关键团队规则放这里
auto memory从磁盘重新注入保留构建命令、调试经验
path-scoped rules等文件再次被读才回来不要把全局规则放这里
nested CLAUDE.md等对应目录文件被读才回来子系统规则可以放，但别依赖它全局生效
skill body重新注入但有 token cap最重要的指令放在 SKILL.md 顶部
hooks不作为上下文保存用来执行，而不是保存记忆

所以一个成熟仓库的规则布局应该很克制：根级 CLAUDE.md 写少量硬规则；子目录规则写本地约束；Skill 写流程；hook 做机器检查。

权限系统才是 Agent 的刹车

Claude Code 的权限不是提示词。提示词可以影响模型想做什么，权限系统决定它实际能不能做。

官方权限文档把规则分成 allow、ask、deny，并且按 deny、ask、allow 的顺序判断。Read-only 通常不需要审批；Bash、文件修改和外部写入则要受规则控制。

权限模式适合场景不适合
default日常开发，首次工具调用要确认高速批量任务
plan先读、先分析、不改文件需要快速修小 bug
acceptEdits工作目录内常规编辑高风险仓库
dontAsk只允许预先批准的工具临时探索
auto有背景安全检查的自动批准预览不能承受误操作的任务
bypassPermissions容器或 VM 里的隔离实验本机真实项目、生产目录

我更倾向于把权限当成“工程策略”而不是个人偏好。比如团队可以规定：PR review agent 永远不能 push 主分支；数据库 MCP 默认只读；部署命令必须 ask；删除命令必须 deny。

hooks 是运行时拦截器

Hooks 让 Claude Code 在生命周期关键点执行 shell、HTTP endpoint 或 prompt-based / agent-based logic。事件很多，从 SessionStart、UserPromptSubmit、PreToolUse、PostToolUse，到 FileChanged、WorktreeCreate、PreCompact、SessionEnd。

这已经不是“自动格式化”这么简单，而是一个运行时拦截系统。

Hook 点适合做什么不适合做什么
SessionStart加载环境、检查依赖、提醒工作区状态做长时间任务
UserPromptSubmit补充项目上下文、校验输入悄悄改写用户意图
PreToolUse阻止危险命令、检查权限每次都跑重测试
PostToolUse格式化、记录审计、触发轻量检查无限制启动后台任务
FileChanged更新索引、通知相关系统直接提交代码
PreCompact保存关键状态摘要写入大量噪音
SessionEnd输出工作报告、清理临时资源影响真实业务状态

Hook 设计得好，Claude Code 会更像一个有护栏的工程环境；设计得差，它会变成隐形副作用来源。

Skills、MCP、subagents 该怎么分工

Medium 上关于 Claude Code skills 的一篇文章说得很对：Skill 不是“一个 markdown 文件”那么简单，它更像一个可复用设计模式。我的理解是：

能力最适合承载什么判断标准
CLAUDE.md稳定项目规范每个 session 都应该知道
Skill可复用流程不是每次都要加载，但触发时要很具体
MCP外部系统状态和工具Agent 需要读/写真实系统
Hook生命周期自动动作必须在某个事件点执行
Subagent大规模研究或专门角色不想污染主上下文
Worktree并行改动隔离多个 session 不应互相覆盖

一个常见反模式是把所有规则都塞进 CLAUDE.md。这样简单，但会让每个任务都背着一大包无关上下文。更好的做法是分层加载：通用规则常驻，场景规则 Skill 化，大文件研究 subagent 化，外部状态 MCP 化。

推荐的团队架构

我会这样落地：

  1. 根级 CLAUDE.md 只写 20 条以内的硬规则。
  2. 每个高频流程写成 Skill：PR review、UI 验收、部署检查、事故复盘。
  3. MCP 只接真正需要外部状态的系统。
  4. PreToolUse hook 拦危险命令，PostToolUse hook 做轻量验证。
  5. 大规模代码研究交给 subagent，主 session 只接收摘要。
  6. 并行任务用 worktree，避免多个 Agent 写同一个目录。

我的判断

Claude Code 的核心竞争力不是“模型会写代码”，而是它越来越像一个完整的 agentic runtime：模型只是其中一层，真正决定可用性的，是上下文、权限、工具、hooks、skills、subagents 和会话管理。

while-loop 可以解释 Agent 的基本动作，但解释不了生产可用性。能把运行时边界设计清楚的团队，才会真正从 Claude Code 里拿到复利。

来源

← 返回所有文章