08 从产品结构到工程视角：过渡章

这一章的作用

第一篇用七章建立了 Claude Code 的产品结构视角：启动、命令、工具、执行循环、UI、扩展、治理、构建形态。到这里为止，你应该已经能回答：

Claude Code 是什么类型的系统？
它的入口在哪里？
用户面和模型面怎么分开？
运行时骨架大概落在哪些文件？
它的治理层和扩展层分别是什么？

这足够你把 Claude Code 看成一个「系统对象」，而不是一堆散功能。

但再往下深挖，只靠产品结构视角是不够的。

为什么需要换一套视角

如果继续按「有哪些模块、模块里有哪些文件」的方式读下去，你会遇到几个问题：

很多重要机制不属于任何单一模块。比如恢复（recovery）横跨 query loop、工具编排、compact；side-channel 横跨 hooks、memory 提取、skill 改进。按模块读，这些东西会散成碎片。
很多设计决策的价值在边界上，不在模块内部。比如主路径和 side-channel 的分离、读路径和写路径的分开、控制面和执行面的解耦——这些都是跨模块的架构判断，不换视角看不出来。
可迁移的经验不是模块清单。你不会把 Claude Code 的 QueryEngine.ts 复制到自己的系统，但你可以把「session owner + turn loop」这种模式迁移过去。模块视角抓不住这种颗粒度。

所以第二篇要做的，是把视角从「它由什么组成」切换到「它是怎么工程化的」。

第二篇的三章在做什么

这一篇很短，只有三章：

09 Harness 工程经验综合

这是第二篇的主轴。它把 Claude Code 当成一份样本，提炼 harness engineering 的核心观察框架——怎么定义运行环境、怎么构造上下文、怎么约束行动空间、怎么把恢复纳入主路径、怎么分流辅助复杂度、怎么支撑长期演化。这一章也同时承担了原有框架、工程模式、学习路线、横切结构观察的综合职责。

如果你关心「从 Claude Code 能学到什么可迁移的工程判断」，这一章是核心。

10 评测基础设施与受控自改进

这一章专门讨论 harness engineering 里最容易被过度解读的一块：agent 系统的「自改进」到底是什么。

Claude Code 在这一块给出的答案很克制：不是失控自治，而是基于 telemetry + feature gate + side-channel + 窄写入面的受控渐进改进。这种取向比任何「agent 自动进化」的修辞都更有工程价值。

08（本章）从产品结构到工程视角的过渡

把读者从第一篇的产品视角送到第二篇的工程视角，同时说明接下来第三篇的深挖章节应该带着什么问题去读。

换视角后该问的问题

如果从这里往下读，建议你带着一组新问题去读第三篇。它们会比「这个模块有什么文件」更能帮你看到系统成熟度。

主状态机在哪里？什么会让它继续，什么会让它停？
上下文是怎么被构造出来的？有哪些不同来源在参与？
哪些动作会经过权限检查？权限检查在主路径的哪个位置？
当失败发生，系统走哪条路径恢复？
哪些工作是主路径做的，哪些被分流到 side-channel？为什么？
长期协作所需的基础设施（memory、compact、tasks、subagent）分别解决什么问题？
内部运行态和外部协议是怎么分开的？

如果你能带着这些问题去看 13–26，你会发现同样的源码会读出完全不同的东西。

第二篇与后面深挖章节的关系

第二篇不替代第三篇的深挖。它只是把你送进去的时候，手里拿着一套更有用的问题和一组更清晰的边界判断。

具体来说：

第二篇讲原则和观察框架
第三篇讲每个子系统的细节
第四篇把两者拼成总图

这三层是一个递进关系。如果你跳过第二篇直接读第三篇，也不是不行——但你会更容易把深挖章节当成「一个个 feature 解析」，而不是「一个 runtime 的横切结构」。

最小阅读路径的提醒

如果你时间有限，不打算读完第二篇的所有章：

至少读 09。它是第二篇的主轴，也是本书 harness engineering 视角的集中表达。
10 只有在你关心评测、遥测、受控自改进时才是必读。
本章（08）本身是过渡章，读完这一页就可以了，不需要回头重读。

继续的下一步

从这里，推荐的下一步是：

如果你认同「把 Claude Code 当 harness 样本研究」这个框架——直接读 09。
如果你只关心具体子系统——跳到 28 阅读路径与索引查你感兴趣的主题。
如果你想先看全局——跳到 27 总体运行时架构图。