我到底在怎么用 Claude Code
先说清楚这篇要回答什么
已经写过一个十一篇的系列，讲 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 前面标一个符号，勾表示十五分钟内能配置好，齿轮表示需要额外配置，这个符号本身就是一次 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 包装成某个身份对 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：
| 层 | 现状 |
|---|---|
| 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。