如何用 Claude Code：模型是 CPU，Harness 是操作系统，Context 是内存页
先说清楚这篇要回答什么
已经写过一个十一篇的系列，讲 SRE 和 agent 之间的同构性，讲 Spec/Loop/Hook/Fork 四个控制论原语。那个系列的语言是抽象层的为什么。这篇不重复那些内容，只回答一个更朴素的问题：把我自己天天在用的 context-infrastructure 这个 repo 摊开来看，我到底在怎么用 Claude Code。
我每次打开任务前做的一件事
任何任务开始之前，我不是直接开始干活，是先让 agent 读四个文件。SOUL.md 定义它要扮演的角色和底层逻辑，USER.md 记录我是谁、我的技术兴趣和沟通偏好，WORKSPACE.md 是整个 repo 的目录路由表，COMMUNICATION.md 规定语言风格和一套我自己写的 agent 交互原则。四个文件加起来几千 token，session 一启动就全局加载，成本固定且低。这是我理解如何用 Claude Code 的第一层：不是每次重新自我介绍，是把自我介绍的成本一次性摊销进一份能被反复加载的文档里。
这四个文件是我给自己的记忆系统分的最上层，几乎不变，被动加载。剩下两层是动态的。中间一层是一个纯 append 的日志文件，每天由一个后台 agent 扫过去二十四小时的文件变动，写进去一条带优先级的观察：高优先级是方法论和硬约束，中优先级是项目决策，低优先级是任务流水。这个文件默认不整篇加载，agent 按关键词或按最近几天检索，只拉真正相关的那几条。最下面一层是每周跑一次的蒸馏：过期的低优先级条目删掉，同主题的中优先级条目合并，反复出现的高优先级条目晋升成一条正式的 skill 或 axiom，写进 rules/ 目录，从此变成最上层的一部分。
这套结构解决的问题很具体。一次对话的 context window 是有限资源，但我积累的经验不是。如果每次都想着这次要不要把过去半年的教训塞进 prompt，答案永远是不行。所以我把记住什么这件事拆成三种不同的生命周期：几乎不变的、每天增长但很快过期的、被反复验证后才值得永久保留的。Agent 不需要一次性看到全部，它需要知道去哪里拉，拉多少。
这也是为什么 rules/skills/INDEX.md 只放一行摘要和触发关键词，具体执行步骤留在各自的文件里，agent 判断用得到某个 skill 时再去读。每个 skill 前面还标一个符号，勾表示十五分钟内能配置好开始用，齿轮表示需要额外配置，这个符号本身就是一次 context 压缩，把这东西值不值得我现在读的判断外置出去，省掉一次探索性阅读。CLAUDE.md 里有一条明文规定：找文件先查 WORKSPACE.md，再搜索。效果是把一次可能要几十次工具调用的目录探索，压成一次文件读取。这次会话我处理博客仓库缺一篇文章这件事之前，第一件事就是查 WORKSPACE.md 定位到具体路径，不是打开终端满仓库 find。
只做到这一层还不够
以上都是 context engineering：管理模型在单次推理时眼前看到的那个世界。真正让我确信这层不够用的，是自己那套 SRE oncall triage skill 跑了大半年之后暴露出的问题。调查阶段的 agent 提前看到了操作命令模板，会一边查一边规划修复方案，一个典型的过早假设。主 agent 直接调原始的监控和日志查询，一次尾延迟调查能吃掉三万 token 的原始输出，context 被污染之后，后面所有判断都建立在一个已经变形的认知基础上。这些问题不是 context 里塞的东西不对，是整个执行流程本身没有边界。
需要区分的第二个概念是 harness engineering。Context engineering 管的是单次推理时模型眼前的世界，harness engineering 管的是跨越整个 agent 生命周期的世界：状态怎么持久化，工具怎么授权，循环什么时候该停，多个 agent 之间怎么隔离。可以把模型看成一个 CPU，harness 是操作系统，context 是当前进程占用的那一页内存。CPU 变快了不代表不需要操作系统调度进程、管理权限、隔离故障，模型变强同样不代表可以跳过 harness 直接把任务扔给它。
这条边界能解释一个常见的误判。有人看到模型能处理的上下文越来越长、越来越准，就断言编排这层要消失了。真正在被模型吸收的是 context engineering 层里那些能压缩成更好的下一个 token 预测的技巧：思维链被推理模型内置，输出解析被结构化输出取代，few-shot 模板被零样本能力取代。Harness engineering 层几乎没被触及，它管的是模型之外的东西：物理世界的读写、信任边界、跨会话的时间维度、多 agent 之间的协调、成本。这些都不是更好的下一个 token 能解决的问题。
四条硬约束，和它们的依赖顺序
想清楚这条边界之后，我给 oncall skill 加了四条硬约束，都是 harness 层面的工作。第一条把调查过程切成三个阶段，调查者、决策者、操作员，阶段之间用文件级的门控而不是提示词里的提醒来隔离，调查阶段的 agent 物理上读不到操作命令模板。第二条要求每条发现必须挂一行具体证据，一段查询的返回值加时间戳，或者一个历史 case 的具体引用，不满足就把置信度强制压低，措辞也被迫从确定变成候选。第三条给假设证伪设一个硬刹车，连续三次假设被推翻必须停下来升级，不能继续在错误方向上深挖。第四条不让主 agent 直接碰原始的监测数据，所有查询都派给一个子 agent，只让它返回一段几百 token 的结构化摘要。
这四条不是坐在桌前凭空设计出来的，是照着别人的做法批判性抄来的。今年年中 gstack 那套 Claude Code skill 套件很火的时候，我派了几个子 agent 调研了一晚上，结论是九成不适合我的场景，但有四件事必须立刻抄，抄的正好是上面这四条，各自对应一种失败模式：过早假设、幻觉结论、在错误方向上死循环、context 被污染。真正有意思的是画完依赖图才看出来的一条：子 agent 隔离必须先做，阶段门控才有意义。如果主 agent 已经被三万 token 的原始数据污染过，再告诉它现在切换到下一阶段解锁更多信息，它脑子里残留的上一阶段记忆还在那里，只是假装没看到。上下文压缩不会给 agent 一次真正的白板，只有从一开始就不让它接触污染源才行。
同样重要的是我没抄的三件事。没抄角色扮演，把 agent 包装成某个身份对 SRE 场景没有意义，我需要的是调查者、决策者、操作员之间的阶段切换，不是让它假装自己是谁。没抄命令数量的扩张，那套工具从最初六个 skill 涨到二十多个，是一路用下来攒出来的结果，不是先验设计，被这类数字震慑、觉得自己也该配齐二十几个 skill，方向已经错了。也没抄把代码产出速度当作衡量标准，oncall triage 的成功指标是平均修复时间和误判率，不是一天写了多少行。判断该抄什么的方法本身值得说一句：一套工具真正的创新点，往往不在它自己发明了什么新机制，是它怎么把更基础层的现成机制拼装起来解一个具体问题。把抄来的东西按这条过一遍，能省掉大量无效模仿。
这套边界感觉不陌生
Hooks 的拦截点、决策能力、可扩展规则，和 Kubernetes 的 admission webhook 几乎是同一种工程模式，权限配置对应 RBAC，会话状态对应 etcd 里持久化的对象状态。这不是巧合，是同一套三十年 infra 工程经验被复用到了新的载体上。当然不能照抄：Kubernetes 的 controller 是确定性的，agent 是概率性的，可能不收敛甚至发散；Kubernetes 的状态可以精确观测，agent 的状态是 context、文件、外部系统和模型内部黑箱混在一起的模糊状态；Kubernetes 是标准的持续 reconcile，主流 agent 目前还是一次性跑完就结束，这是还没被填满的空间。但差异不改变一个基本判断：任何一个 Kubernetes 早期已经解决过的工程问题，大概率会在 agent 工程里以新的形态重新出现一次，解法可以直接搬，不用从零探索。
一次诚实的自我体检
把 agent 工作流拆成六层，能看得更清楚：spec 定义目标，boundary 划边界，workflow 组织怎么做，memory 管跨会话状态，verification 检查产出对不对，observability 看得见系统在做什么。逐层对照 context-infrastructure 这个 repo：
| 层 | 现状 |
|---|---|
| Spec | 厚，WORKSPACE.md、AGENTS.md、几十个 skill 文件 |
| Workflow | 厚，大量 skill 和 subagent 编排模式 |
| Memory | 厚，三层记忆池加上每周的观察和蒸馏 |
| Boundary | 中等，有 mutation approval gate，但覆盖不全 |
| Verification | 薄，缺一套系统性的 review subagent 或 eval suite |
| Observability | 薄，缺 agent 走偏率、skill 成功率这类可度量指标 |
这张表比任何我写了多少个 skill 的产出型自夸都更有用，它直接指出下一步该往哪投。不是每层都值得同等投入，值不值得投，看四个具体条件：任务重复频率高，该投 skill 和 workflow；误操作代价高，该投 hook 和 boundary；任务跨会话，该投 memory；输出质量难判断，该投 verification；多 agent 协作，该投 observability。复杂度本身没有意义，减少了多少认知负担才是唯一的衡量标准。按这条看，我在 verification 和 observability 上明显投入不足。这不是一句抽象的自我批评，是一条具体的施工清单：下一次改这套系统，先补一套能自动判断 agent 输出对不对的东西，再补一套能看清 agent 什么时候开始走偏的东西，不是再写一个新 skill。