前言¶
把模型接进工具链之后，很多团队仍停留在「一问一答」：任务结束，上下文清空，下一轮从零开始。一旦要让 Agent 在后台跑研究循环、反复改稿、自动准备 PR，问题会变成另一类：它该改哪些文件、分数谁说了算、失败怎么回滚、状态压进上下文之后还能不能续跑。单次对话里靠人盯着尚可；跑几小时或几天，缺少明确的控制面，很容易出现自评自嗨、丢日志、或把不可逆操作悄悄做完。
下面介绍 harness-engineering 这套 Skill：它不教你怎么写 prompt，而是教你怎么设计 Agent 外面的「挽具」（harness）——允许编辑的表面、锁定的评估、持久化日志、新颖性门控，以及人类审批边界。
这是什么¶
harness-engineering 是 Agent Skills for Context Engineering 仓库中的一条 Skill，维护者为该开源集合（muratcankoylan）。官方描述概括为：在设计自主 Agent 挽具时使用——研究循环、评估脚手架、锁定与可编辑表面、持久日志、新颖性门控、剪枝、回滚、PR 准备与人类审批边界。
在 Agent Skills 开放格式里，Skill 通常是一个包含 SKILL.md（含 name、description 与操作说明）的目录；客户端通过「发现 → 激活 → 执行」渐进加载，仅在任务匹配 description 时读入全文。本 Skill 的定位是：挽具是「有用的一次会话」与「能长期自主运行且不破坏目标」之间的分水岭。
核心功能¶
以下能力均来自官方 Skill 正文，按概念分节说明。
挽具边界（Harness Boundary）¶
Agent 提出动作；挽具定义允许的表面、反馈方式、持久化与晋升规则。官方给出四类表面：
| 表面 | 示例 | 规则 |
|---|---|---|
| Locked（锁定） | 评估指标、rubric、校验脚本、合并策略 | 可读、可提议修改，但不能用改过的规则给自己打分 |
| Editable（可编辑） | Skill 草稿、实验文件、被测 prompt/config | 循环内可变更 |
| Append-only（仅追加） | 结果日志、研究线程、被拒想法 | 只能追加，不能改写历史 |
| Human-controlled（人控） | 合并、生产部署、凭证、破坏性操作 | 需明确人类批准 |
紧反馈环（Tight Feedback Loops）¶
自主性依赖反馈快、语义清晰、难被「刷分」。资料引用 Karpathy 的 autoresearch 作为最小模式：一个可编辑文件、一个锁定评估文件、固定墙钟预算、单一标量指标、git 回滚、持久结果日志。要点不是「只能有一个指标」，而是模糊反馈会带来模糊的自主行为。面向开放的研究→Skill 工作，可用锁定的 rubric、确定性结构检查、来源可追溯与人类复审阈值替代单一标量。
持久状态（Durable State）¶
长跑 Agent 必须把状态外置到文件，以便压缩上下文后仍能恢复。资料提到 Prime Intellect 的自主 nanoGPT 工作中，THREAD.md 式草稿与日志对恢复、监控、审计的价值。仅追加日志应记录：尝试过什么、成败原因、候选保留/丢弃/送审理由、查阅的上游来源、下一 Agent 该做什么。
搜索纪律（Search Discipline）¶
官方列举六条显式规则：按日程刷新上游来源；大额预算前做新颖性检查；保留被拒尝试避免重复发现；多组件堆叠时做 leave-one-out 剪枝；质量相同时奖励简化；晋升前单独验证。
机制注册表（Mechanism Registry）¶
研究→Skill 系统应把「已接受机制」与散文说明分开追踪。机制记录建议包含稳定 mechanism_id、owning_skill、status、激活场景、行为变化、证据与失败模式。新颖性门控应先对照该注册表，再考虑更广语料重叠——关键词重叠易漏掉「换说法的重复」，机制对比更能抓住真实重复。
治理（Governance）¶
自主 Agent 可起草变更、跑检查、写 PR 摘要，但不得在未经人类明确授权的情况下合并、部署或 push（除非用户对该动作单独授权）。
两种典型循环¶
Autoresearch 式（对稳定评估器优化工件）：
read locked context -> choose hypothesis -> edit allowed surface -> commit/checkpoint
-> run evaluator -> log result -> keep if better -> discard or rollback if worse
-> repeat
要求：评估器在可编辑面之外；反馈节奏可比较；失败留审计轨迹；回滚成本低；对崩溃与超时有策略。
Research-To-Skill 式（来源变为 Skill 变更）：
discover -> retrieve -> gate -> score -> extract mechanism
-> map to existing or new skill -> draft proposal -> validate structure
-> prepare PR -> human review
锁定评估 = 来源 rubric + Skill 变更 rubric + 结构检查 + 审阅者批准；可编辑工件 = 提议的 Skill delta。
抗指标博弈（Metric Gaming Resistance）¶
优化型 Agent 会学习挽具。需防范：改评估代码/rubric 后自批；堆冗长内容讨好裁判却伤害激活；引用未检索来源；刷总分却漏关键维度；日志里隐瞒失败。缓解：每轮锁定 rubric、分维度报分、要求检索证据、保留被拒尝试、治理变更走人工审阅。
监控 Agent¶
长跑可用只读监控 Agent，输出：当前最佳候选、活跃任务/草稿、上次上游刷新、失败或陈旧循环、日志与声称状态不一致、下一步与阻塞项——除非显式授权，监控侧不应写可编辑面。
设计清单与目录布局¶
官方八步清单：一句话目标；四类表面；反馈机制（标量/rubric/确定性测试/人审或组合）；保留/丢弃/崩溃/超时/送审状态；循环前建持久线程日志；长跑加来源刷新、机制注册表新颖性与剪枝；无请示可做 vs 需批准；用一好一坏工件验证挽具。
推荐目录：
research-run/
THREAD.md
sources/
queue.md
evaluations/
proposals/
logs/
results.tsv
rejected.md
drafts/
机器可读日志用 TSV 或 JSONL；Markdown 用于交接与审阅摘要。
何时启用、何时不用¶
适合激活（官方 When to Activate）：
- 构建自主研究或实验循环
- 设计带锁定指标与可编辑代码/内容的 Agent 环境
- 做产出 PR 或后台 Agent
- 评估 Agent 能否在少人工打断下安全运行
- 为工作流增加新颖性、消融、剪枝、回滚或持久日志
- 防止 Agent 刷 benchmark、削弱 rubric、或在压缩后丢状态
不要用它替代（相邻 Skill 负责）：
- 无自主控制面的质量门、回归套件或结果指标 →
evaluation - 挽具工具的模式、响应格式与恢复错误 →
tool-design - 项目级任务-模型匹配、流水线形态与成本 →
project-development - 远程沙箱、暖池与托管会话基础设施 →
hosted-agents
安装与启用¶
本 Skill 随 官方仓库 提供，路径为 skills/harness-engineering/（内含符合 Agent Skills 规范的 SKILL.md）。
Agent Skills 的通用机制（agentskills.io）：客户端启动时仅加载各 Skill 的 name 与 description；任务匹配 description 时再读入完整说明并执行。具体如何把该目录挂到 Cursor、Codex CLI 或 Claude Code，以各客户端文档为准；已抓取资料中未给出统一安装命令，此处不臆造配置项或版本号。
在支持 Skills 的客户端中，确保 harness-engineering 的 description 可被发现；当任务涉及「自主挽具、研究循环、锁定评估面、回滚与审批边界」时，应触发激活并遵循 SKILL.md 中的清单与循环模式。
典型用法（官方示例）¶
示例 1：锁定指标
Agent 优化 train.py，但 prepare.py 负责数据加载与评估。Agent 可改模型，不能改指标；失败实验记入日志并回滚。
示例 2：锁定 rubric
Agent 评估新的工程类文章，但来源策展 rubric 在本轮锁定。来源通过后起草 Skill 提案；不能降低 rubric 阈值把不合格来源硬塞进来。
示例 3：自动 PR、不自动合并
Agent 在检查通过后准备分支与 PR 正文；合并仍属 Human-controlled 表面，需人批准（资料在此截断，语义与 Governance 一节一致）。
设计新挽具时，可先按清单画出四类表面，再选 Autoresearch 或 Research-To-Skill 循环，并落地 THREAD.md 与 logs/results.tsv 再开 loop。
适用场景与注意¶
适合需要多天级自主运行、又不想把评估权交给 Agent 的团队：实验自动化、Skill/文档从研究到 PR 的流水线、后台改代码并准备 PR 的 coding agent。限制在于：挽具设计本身有工程量；与 evaluation、tool-design 等 Skill 边界要分清，避免在一个 Skill 里混做通用评测或工具契约。
注意 anti-gaming：任何「可编辑的评分逻辑」都会成为攻击面；长跑必须 append-only 日志与机制注册表，否则 compaction 后难以审计。人类审批边界要在挽具里写死，而不是依赖模型自律。
结尾¶
harness-engineering 把自主 Agent 从对话产品里常用的「单次会话」推进到「有控制面的长期循环」：锁什么、改什么、记什么、何时回滚、谁点头，都应在挽具里先设计好。完整说明与示例见官方目录：
https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering/tree/main/skills/harness-engineering
