s01-s06 里什么是真骨架
先说我的结论
s01-s06 这 6 节都重要，但它们重要的方式并不一样。
如果我要判断“哪些是 Claude Code 类 harness 的真骨架”，我会这样分：
- 核心骨架：
s01 Agent Loop、s02 Tool Use、s06 Context Compact - 稳定器：
s03 TodoWrite - 放大器：
s04 Subagents、s05 Skills
这个排序的意思不是后面几节不值钱，而是没有前面三层，你很难做出一个长期可工作的 coding agent。
s01：循环是心脏
没有 loop，就没有 agent harness。
s01 真正值钱的地方，是把一件经常被神秘化的事讲回了工程事实：
- 读输入
- 调模型
- 看模型要不要调工具
- 执行工具
- 把结果塞回下一轮
- 决定什么时候停
如果这一层没建立起来，后面所有花样都只是在空中加装饰。
s02：工具是外部能力的接缝
s02 重要，是因为它决定 agent 什么时候开始不再只是“会说”，而是“能做”。
我很认同这条资源那个味道很重的判断：加一个工具，本质上就是多一个 handler，不是突然获得魔法。
这个视角很关键。
因为它会逼你把问题想得更清楚：
- 工具接口是不是足够小
- 工具结果回写后，模型下一轮到底看到了什么
- 调工具失败时，应该在哪一层补保护
s03：TodoWrite 不是花活，是防漂移装置
很多人第一次看 TodoWrite 会觉得它只是产品体验优化。
我不这么看。它更像一个非常便宜、但极有效的稳定器。
原因是长任务里最容易坏掉的，不是单轮推理，而是目标漂移：
- 做着做着忘了原问题
- 子任务做完了但没人收口
- 任务中途切换后再回来，状态已经散了
TodoWrite 本质上是在给 agent 一个外显的工作记忆面板。没有它也能跑，但长期任务会更容易散。
s04：Subagents 是上下文隔离，不只是“多开几个 agent”
s04 真正值钱的点，不是“有多个 agent 很酷”，而是它把一个关键工程动作显性化了：上下文隔离。
大任务拆分后，如果所有子问题都继续堆在同一个主上下文里，主 agent 很快就会被无关细节淹没。
Subagents 的意义，是让子任务带着自己的局部上下文完成，再把结果回收到主线，而不 是让主上下文无限膨胀。
所以我把它放在“放大器”而不是“最小骨架”。它很重要，但前提是前面的 loop 和 tool use 已经站住了。
s05：Skills 是按需加载知识，不是预塞一切
Skills 的关键不是知识多，而是加载时机对。
这一点对 coding agent 很重要，因为上下文预算是真约束，不是抽象问题。
如果每轮都把所有规则、模板、注意事项预塞进去，模型很快就会被固定成本拖死。Skills 的好处是：
- 平时不占上下文
- 需要时再拉入
- 还能把经验沉淀成结构化能力
所以它也是放大器，不是 loop 那种底层骨架，但它对长期可维护性很关键。
s06：Context Compact 是长期运行的生存条件
如果只让我从 s01-s06 里挑一个最容易被低估的章节，我会选 s06。
很多人能接受“Agent 需要 loop”“Agent 会调工具”，却低估了另一个现实：上下文总会满。
没有 compact，前面那些能力很容易只在短任务里好用。任务一长，消息一多，工具结果一堆，系统就开始变慢、变贵、变糊。
所以我把 s06 和 s01、s02 放在同一级。它不只是优化项，而是“让前面所有能力还能继续工作下去”的条件。
如果我要自己从零做一个最小 harness
我会按这个顺序做：
s01loops02tool uses03todos06compacts04subagentss05skills
原因很简单：先让系统能跑，再让它不漂，再让它能活久一点，最后再加杠杆。