用途：Harness 是一套构建项目智能体上下文的架构方法，核心是把合适的信息迁移到合适的上下文层，使智能体既能做出良好决策，又不被暂时不需要的细节淹没。它包含两个维度：上下文架构（智能体知道什么）与智能体生命周期（智能体如何跨时间工作），二者通过 artifact 交汇——artifact 既是信息（上下文），也是连续性机制（生命周期）。
命令：带参数调用时分发到对应文件。 /harness audit → 阅读并遵循本技能目录下的 commands/audit.md，评估现有项目的上下文架构并提出改进建议。 /harness init → 阅读并遵循本技能目录下的 commands/init.md，首次从零引导搭建项目 harness。 无参数 → 按下方方法论继续。
第一部分：上下文架构（如何组织智能体所知）。三层抽象：L1 架构——系统形态、边界、不变量、原则，始终在上下文中，小而稳定、高杠杆，每个 artifact 约 100–500 tokens；L2 设计——模式、机制、方法、任务计划，激活时加载，是工作蓝图，每个 artifact 约 1000–5000 tokens；L3 实现——具体代码、脚本、参考数据、示例，按需加载，大小不定，只取当前所需。层越高越小越稳定。多数 harness 问题源于越层：L3 细节污染 L1（如 CLAUDE.md 塞满实现笔记），或完全缺失 L1（智能体无架构意识，做出破坏系统边界的决策）。
artifact 与层映射：L1（始终存在）含 CLAUDE.md、技能元数据（name + description）、hook 触发器、项目级不变量；L2（激活时）含技能正文 SKILL.md、design/DESIGN.md、blueprints/、任务计划、决策记录；L3（按需）含 scripts/、references/、assets/、代码文件、测试夹具。
CLAUDE.md 是最关键的 L1 artifact，始终加载，每个 token 都须发挥作用。好的 CLAUDE.md 包含：这个系统是什么（一句话）；如何构建/测试/运行（仅命令）；架构形态（模块边界、数据流、关键模式，或指向 design/）；非显而易见的约定。坏的 CLAUDE.md 包含逐文件拆解、通用最佳实践、频繁变化的实现细节。检验标准：删掉某行若不会让智能体做出更差的架构决策，该行就不该在。
技能天然横跨三层：L1 为 frontmatter 中的 name + description（约 100 tokens，启动时对所有已安装技能加载，决定是否激活）；L2 为 SKILL.md 的 markdown 正文（<5000 tokens，激活时加载，含方法论、循环、原则）；L3 为支持文件（commands/、scripts/、references/，仅在分发时加载）。SKILL.md 应保持在 500 行以内，更长则部分应移入 L3。
上下文原则：最小有效上下文——L1 每 token 都在与当前任务工作空间竞争，只写能改变智能体决策的内容；稳定层与易变细节——L1 应少变，L2 随任务变，L3 持续变；指针优于内容——L1 引用复杂信息时应指向而非内联，如"模块边界见 design/DESIGN.md"。
层问题诊断：智能体任务中途忘记架构（L1 过薄或缺失→向 CLAUDE.md 补充架构上下文）；上下文过载、响应慢（L1 过厚、L3 细节上溢→审计 CLAUDE.md，将细节移入 L2/L3）；破坏模块边界（无设计文档或 CLAUDE.md 缺边界→添加 design/ 或架构章节）；加载不必要文件（技能正文内联引用过多→拆分为支持文件按需加载）；重复同样错误（缺 hook 或缺 L1 原则→加 hook（机械）或 CLAUDE.md 规则（判断））。
第二部分：智能体生命周期（如何跨时间工作）。接替优于持久——每个智能体实例都是短暂的，其上下文在单次会话后消失，不要对抗这一点；应按接替设计：知识通过 artifact 存活，而非某个智能体的记忆。连续性的单位是 artifact 链，不是智能体实例；L1 与 L2 artifact 是超越每次会话的机构记忆，提交信息是考古记录，蓝图 State 章节是代际交接文档。要给"智能体"更长的有效生命周期，不要延长会话，而是提升抽象层级：在 L1（架构）运作的智能体跨越项目生命周期，在 L3（实现细节）运作的智能体随单个任务而生灭。
一个任务一个上下文——单个任务应能容纳于一个上下文窗口，否则就是两个任务。每个任务获得只含所需信息的聚焦上下文，防止先前工作污染后续决策。scoping 任务时问：智能体能否在上下文不退化的情况下完成？
Hooks 是生命周期护栏，从上下文窗口之外塑造行为，始终激活、零 token 成本。两类：prompt hooks——注入提醒，让智能体运用判断，适合需上下文感知的检查（层完整性、一致性、架构边界）；script hooks——运行命令，机械通过或阻止，适合不需判断的检查（lint、格式校验、禁用模式）。
变更后一致性：修改被其他文件引用的路径、名称、术语或结构时，检查每个依赖文件。常见失败模式是引用过时，如重命名目录却在 SKILL.md 中留下旧路径，修改约定却在 CLAUDE.md 中留下旧措辞。提醒"是否更新了所有引用你刚改内容的文件？"的 prompt hook 是最高价值的 hook 之一。
第三部分：为有限的人类带宽设计。智能体吞吐持续上升，人类审查能力却不会。当智能体产出多于人能细看时，瓶颈从"智能体能否做到"转向"人能否在错误发布前抓住关键"。原则：面向人类审查的智能体产出应是骨架级，细节视为可廉价替换。就像代码架构，人的工作是确保骨架成立，而非检查每一行；只要架构正确，模块可低成本重写。此模式在既有方法论技能中已实践：design-driven 的 30/70 划分（人策展定义形态的 30%，智能体拥有其内 70%，骨架成立则 70% 可丢弃）；reframe 的骨架与血肉（审查发生在骨架层，血肉从骨架投射，用户理解失败时可廉价重绘）；goal-driven 的 GOAL.md/record/stories 不对称（人逐行编辑指南针，record 为只追加事件日志，stories 可选叙事）；evidence-driven 的 State 作为证据链（可按需审计，由智能体在执行层维护，不逐行人工审查）。
设计新技能或产出时的实际后果：尽早识别骨架——20% 若出错会使其余无价值的产出，就是人必须突出看到的；细节可折叠而非省略——表格、只追加日志、<details> 块、按需引用，问题不是细节本身，而是细节被强塞进人的主视图；使细节级错误廉价——某细节错了，修复应是局部的，若修正一处细节迫使重审整个产出，那是架构错了；规模化下把彻底性当作非策略——"人应审查一切"预示审查疲劳，随后要么盖章要么瓶颈，应挑出人必须抓住的内容并设计产出形态恰好呈现它。经验法则：若智能体产出量随其工作量线性增长，而必审量亚线性增长，设计就在正轨；若二者同增，技能是在为审查失败做准备。该原则随时间更重要：骨架/细节之分在软件架构中一直存在，新的是比例——当人写所有代码时，骨架级与细节级决策之比大致匹配人能审查的量；智能体生产细节后该比爆炸，原本隐含的纪律变成承重结构。
元原则：理解为什么，而非只知道做什么。理解约束背后推理的智能体，在新情境中比机械遵循规则的智能体运用更好判断。编写任何 harness artifact 时都解释 why——多花几个 token，却能在每个任务中复利为更好的决策。
限制：以上为该方法论的公开说明，未提供具体实现代码、收费、价格与平台支持信息。