TL;DR

Claude Code 之所以“顺滑”，核心不是模型，而是架构和设计哲学。
6 条可以直接迁移到你自己 Agent 的铁律：

  1. 保持单一主循环 —— 一条主 loop，最多一条分支，调试优先。
  2. 小模型，大闭环 —— 80% 的读/扫/总结都交给小模型，关键时刻才用大模型。
  3. 上下文文件（claude.md） —— 用一个 context 文件固化团队约定与偏好。
  4. LLM Search 胜于 RAG —— 用 ripgrep/jq/find + LLM，而不是复杂的向量检索。
  5. 分层工具设计 —— 高频动作单独做工具，低频留给 Bash，高层工具保证 determinism。
  6. 显式 To-Do 清单 —— 让模型自己维护待办，防止长会话跑偏。

一、保持单一主循环

我看到很多人做 Agent 时，喜欢搞多智能体、复杂 orchestrator。结果是：看 demo 很炫，真要调试时一团糟。Claude Code 完全反其道而行之：一条主循环，最多一条分支。

它的策略是：如果遇到复杂任务，就 spawn 一个“子自己”，最多一层，跑完再把结果写回消息历史。好处是整个控制流一目了然，出错时能很快定位。

经验教训：debuggability > 架构炫技。


二、小模型，大闭环

Claude Code 超过一半的调用走的都是 Haiku（小模型），用来读文件、parse JSON、总结 git 历史。只有关键生成（比如复杂编辑）才用大模型。
这有两个好处：

  • 成本能降 70–80%。
  • 反馈速度快，闭环很短，用户觉得“爽”。
    对我来说，这其实是个很实用的模式：别浪费大模型去干小活。

三、上下文文件：claude.md 模式

Claude Code 的另一个 killer feature 是 claude.md。它是一个上下文文件，写清楚所有人类无法从代码直接推断出的规则：

  • 哪些目录要忽略
  • 用哪些库
  • 代码风格/注释习惯
    每次请求都会把 claude.md 附上。效果非常明显：有和没有，差距是天与地。
    如果你做自己的 Agent，可以试着加个 agent.md，让它成为团队偏好的“单一真相源”。

四、LLM Search 胜于 RAG

Claude Code 在搜索上做了一个非常“逆潮流”的选择：不用 RAG。
它直接让模型写 ripgrep/jq/find，就像你在终端里手敲一样。模型理解代码和正则，足以定位绝大多数问题。

为什么这样更好？因为 RAG 有很多隐形失效点（相似度函数、chunk 粒度、reranker…），而 LLM Search 可见、可调试。

我现在越来越相信：别急着上 RAG，先让模型像人一样搜索。


五、分层工具设计

Claude Code 的工具集很讲究层次感：

  • 低层：Bash、Read、Write
  • 中层：Edit、Grep、Glob
  • 高层：Task、WebFetch、diagnostics
    原则是：高频动作 → 独立工具（比如 Grep），这样更准确；低频场景交给 Bash 即可。

这点给我的启发是：设计工具时不要贪心，把 agent 最容易用错/用频繁的动作，做成独立工具。


六、显式 To-Do 清单

长会话的一个大坑是“上下文腐烂”。Claude Code 的解法是：让模型自己维护 To-Do list。
它会频繁检查和更新 To-Do，这样就能保持方向一致，还能在中途插入/删除子任务。
相比多 agent 接力，这种方式简单、直观，而且能充分利用 LLM 的“边想边写”能力。


附录：Prompts & Tools 清单

Claude Code 的核心提示：太长评论留下邮箱，我会定期回复

Claude Code 的核心 Tools 提示：太长评论留下邮箱，我会定期回复

Claude Code 的 prompt 工程很值得参考：

  • <system-reminder>：定期提醒模型某些状态（但不暴露给用户）。
  • <good-example>/<bad-example>：用示例来 steer 模型选择。

工具方面，它的必备集包括：

  • 低层：Bash、Read、Write
  • 中层：Edit、Grep、Glob
  • 高层：Task、WebFetch、diagnostics