定义

Harness(直译”马具/挽具”,在 AI 编码语境下中文圈无公认对等词,本文档统一译作”上下文装备”)是你为 AI 编码助手搭的上下文、规则、工具和 workflow 的集合——也就是”你能控制的那一层”。在能动工程(agentic engineering)里,模型能力是给定的、你改不动的部分,而 harness 是你唯一能动手优化的杠杆。三个信源的共识是:决定 agent 实战效果的绝大部分不在换模型,而在这一层的工程质量;它既可以是单个助手的规则/context/skills 配置,也可以再往上叠一层编排多个助手的”元 harness”(Meta Harness)。

术语判别:Harness 是 Anthropic 在 Claude Code 工程实践中提出的核心概念,中文圈没有公认对等词(直译”挽具”不通俗),保留英文为主,中文”上下文装备”作为别名提供解释。

各信源立场对照

信源立场/侧重锚点采信
Cole·大师课首倡”harness 占 90%、模型只占 10%“:真正决定 agent 效果的是你能控制的那层(上下文/规则/工具/workflow),不是模型选型7:13利益中性,有贴片但主张在独立信源可印证
Cole·Omnigent在单个 harness 之上再加一层编排(meta harness):不同助手各有强项,分开跑既省 token 又避免单会话上下文过载0:14与利益同向,待印证,推广概念给 Archon 铺路
Chase·六个层级把同一套构成要素(CLAUDE.md / MCP 甄选 / skills)从团队级工程流程收窄成可逐级修炼的个人技能树利益中性,推付费课但框架不依赖购买
IndyDevDan·Pi 课程给 harness 在开源阵营提供具体可执行样板:14 个 Pi 变体演示从 extension → widget → 多 agent 编排 → meta-agent,200 token 系统提示 vs Claude Code 10000 token,YOLO 默认 vs 审批默认——是 harness 占 90% 的独立同向证据利益中性,14 个 extension 全是工程实证

分歧与共识

  • 共识:三源一致认为 harness(而非模型)是能动工程里真正可控、也真正决定成败的一层;构成要素高度重合——上下文管理、规则(CLAUDE.md)、工具/MCP、skills、workflow。
  • 视角分歧:Cole 大师课站在团队级工程流程讲 harness 是什么、为何占 90%;Chase 六个层级把同一套要素收窄成个人可逐级修炼的技能树(视角从”工程”到”修炼路径”)。
  • 粒度分歧:Omnigent 把 harness 往上抬了一层——不再优化单个 harness,而是编排多个助手的元 harness,这是三源里唯一跳出”单助手”框架的。

怎么用

  • 优化 agent 表现时,先动 harness 再谈换模型:把精力投在上下文组织、CLAUDE.md 规则、工具/skills 配置和 workflow 上,这里是 90% 的收益所在——但注意 CLAUDE.md 并非越多越好(六个层级引 ETH Zurich 研究:滥用收益微弱、推理成本 +20%)。
  • 当单个助手的上下文被塞爆或任务跨多个强项时,考虑往上叠一层编排(meta harness):按助手强项分工、分开跑,既省 token 又避免 Context Rot

适用边界

  • CLAUDE.md 并非越多越好:六个层级引 ETH Zurich 研究,滥用 static context 收益微弱、推理成本 +20%(Chase·20:21);CLAUDE.md / agent.md 该放 5% 例外(公司专有信息、必须每次引用的方法论,Greg·2:06),其余交给 skill / 动态上下文。
  • 未到上下文塞爆或跨强项不必叠 Meta Harness:Meta Harness 不是默认方案——单助手上下文没塞爆、任务没跨多个强项时,再叠一层编排只会徒增协调开销,不属于”能 90/10 就别 50/50”。

关联

  • 静态上下文与动态上下文 — 印证:Harness 是你搭的上下文 / 规则 / 工具 / workflow 的集合;静态 / 动态上下文 是该集合中”上下文管理”维度的具体切片。
  • Agent Teams — 互补:Agent Teams 是 Harness 在 Claude Code 内的多 subagent 协作形态;Harness 是上位原则,Agent Teams 是其在工具边界内的具体落地。