← 返回藏书阁Harness Engineering
Harness Engineering
定义
Harness Engineering 是一种 AI 协作工程方法论。核心理念：AI 参与问题分析、方案设计、编码实现、审查和验证，但最终判断权始终留在工程师手中。
词源
Harness（挽具）的隐喻：把原始力量巨大但方向不定的 LLM，通过工具编排、记忆、沙箱、校验接入可控系统——就像给烈马套上挽具让它拉动真实载荷。
四大标准组件
- 运行时控制系统 — 工具编排、状态持久化、错误恢复、反馈循环
- 上下文工程 — Context Window 优化、动态检索/摘要、防 Context Rot
- 工具集成与防护 — API 标准化、预执行校验、阻止幻觉执行、安全护栏
- 生命周期管理 — 多步长任务、Checkpoint/Crash Recovery、Human-in-the-Loop
- Vibe Coding：「让 AI 尽量自由地生成」
- Harness Engineering：「让 AI 在正确的轨道上尽量高效地生成」
- 真正的高效来自正确的约束
核心公式
代码产出 = AI 能力 × 上下文质量（乘法）
上下文质量趋近于零时，模型再强产出也是零。提升上下文质量是比提升模型能力更高效的杠杆。
QQ音乐实践（L5 工程治理层）
不替代 Claude Code/Cursor/Cline 等执行层工具，只定义工程上下文和协作协议：
- 五阶段 + 四门禁流程
- 三层知识体系 + 三仓联动
- 24 Agents + 34 Skills + 35 Commands（全部版本化 markdown）
- Self-Refinement 闭环
OpenSpec 是个人/小团队的规格驱动开发工具。Harness Engineering 是企业级多服务场景的工程治理层。两者理念相通（先对齐再动手），但复杂度层级不同。OpenSpec 可作为 Harness Engineering 执行层的一部分。
2026-06-30 补充：可执行流程与 containment
2026 年的外部材料把 Harness Engineering 推向两条更具体的路线：
| 1. Containment harness：[[anthropic-agent-containment | How we contain Claude across products]] 强调限制 agent 的 blast radius。harness 不只是提效工具，也是权限、环境隔离、监控和恢复的控制层。 |
- Executable workflow harness：aharness 用有限状态机、typed submissions 和 validated exits 控制 Codex 工作流，针对的是 process drift：跳过审批、忘记恢复规则、声称不存在的证据、从陈旧上下文继续推进。
这说明“把流程写进 prompt”不够；关键流程应尽量变成可验证、可审计、可恢复的运行时结构。
2026-07-01 补充：verification membrane
| [[agentops-coding-agent-verification | AgentOps coding-agent verification membrane]] 把 Harness Engineering 的“控制”进一步具体化为完成门禁：不是 agent 声称完成就结束，而是必须有独立 judge、真实测试或 gate 产生 verdict，并把证据写入 repo-native ledger。 |
这补上了 harness 的一个常被忽略的环节：workflow 可以防止 process drift，但仍需要 verification membrane 防止“流程走完但结果未证实”。对 Hermes 来说，完成任务的最小闭环应是：写入/执行 → 独立或真实验证 → 记录证据 → 再汇报。
2026-07-05 补充：约束基底与风险路由
| [[steerability-via-constraints | Steerability via constraints]] 和 [[lovable-scaling-agentic-coding | Lovable 的实践]]共同说明：harness 的核心是把自由生成变成受约束、可分流、可验证的工程过程。前者强调 access control、network policy、coding convention 和小型 docs CLI 等 substrate；后者强调 markdown 风险策略、LLM 分类和 deterministic enforcement，把 PR 分到 fast AI / slow AI / human review 三条通道。 |
对 Hermes 来说，危险操作不应只靠 prompt 约束；应尽量变成工具层 guard、目录边界、验证脚本和日志证据。
2026-07-06 补充：持久状态与轨迹监控
| [[distributed-attacks-persistent-state-ai-control | Distributed Attacks in Persistent-State AI Control]] 把 harness 风险从“单次 diff 是否安全”推进到“多轮 PR 是否共同形成攻击链”。当 coding agent 在同一个 codebase 上跨 session 工作时，攻击或失控行为可以被拆成多个自然-looking 小改动，直到某个 PR 获得最好的掩护。 |
这提示 Harness Engineering 需要 stateful link-tracker：记录新增入口、权限、配置、依赖、测试豁免和 helper 之间的连接，并在后续变更中检查 suspicious buildup。对 Hermes 来说，长期 cron 和知识库维护也应做轨迹审计，避免连续小修改共同改变任务目标或污染上下文。
2026-07-07 补充：组合式工具策略、行动边界与生产 Loop
| [[dscc-compositional-agent-policies | DSCC]] 和 [[underspecbench-action-boundary | UnderSpecBench]] 共同把 harness 的控制面从“单步工具调用”推进到“工具链 + 指令歧义 + side effects”。DSCC 说明：某个工具单独允许，不代表它和另一个工具组合后仍安全；harness 需要 session-level policy、Most Restrictive Set 和 taint-like state。UnderSpecBench 则说明：目标、范围或 blast radius 不明确时，agent 往往会猜测并继续行动，因此安全 harness 应把澄清、拒绝或 defer 视为正向结果。 |
| [[loop-engineering-autonomous-log-to-staging | Loop Engineering 实战：从日志扫描到预发部署的全自主闭环]] 则说明，Harness 不是终点：当单次 run 已具备工具、权限、测试和流程后，还需要外层 Loop 来承担自动发现、调度、跨轮状态和独立验证。文章中的日志维护案例把 Connectors、Automations、Skills、Worktrees、Sub Agents、State 连接成生产维护系统，并用预发日志、Trace、线上对比等证据防止“修复者自证”。 |
对 Hermes 来说，危险操作的默认门禁应至少包含：目标是否明确、目录/资源是否明确、影响半径是否受控、是否读过敏感/未验证上下文、后续工具是否可能外传或放大该上下文。若无人 cron 场景无法澄清，就应降级为只读发现、raw 留存或 HOLD，而不是扩大执行。长期 loop 还需要独立验证、最大重试次数、预算熔断和人类审批边界。
2026-07-08 补充：harness 作为自我改进对象与运行时恢复层
| [[lilian-weng-harness-engineering-self-improvement | Lilian Weng — Harness Engineering for Self-Improvement]] 把 harness 定义为 prompts、tools、subagents、control flow、memory、workflow logic、MCP/external context 和 backend jobs 的可编程组合层，并指出近端 self-improvement 更可能先发生在 harness / workflow / context 层，而非模型直接改权重。这让 Harness Engineering 从“约束 agent”升级为“优化产生更好 agent 行为的机器”。 |
| [[agenttether-graph-guided-runtime-repair | AgentTether]] 则补上运行时恢复维度：harness 不应只在执行前设置 guardrails，也应在失败后把轨迹转成 Critical Transition Graph，定位 failure-critical subtrajectory，并把修复经验压缩成 Repair Memory。对 Hermes 来说，未来 harness 的最小闭环应包含：预执行边界、执行中证据、独立 verdict、失败定位、带记忆重试。 |
2026-07-09 补充：确定性 gate 与行动严重度
| [[deterministic-gates-tool-agent-policy | Deterministic Gates for Tool-Using Agent Policy Enforcement]] 把 harness 的预执行控制具体化为 read-only deterministic pre-call gate：当底层工具会接受任何语法正确的写操作时，策略判断不能只交给模型；应该由 gate 读取当前状态和参数，阻止 forbidden state transition。 |
| [[action-graded-severity-scale-tool-agents | Action-Graded Severity Scale for Tool-Using AI Agents]] 则补上事后评估：harness 不能只报告 attack-success/pass-fail，而要根据工具调用轨迹判断最严重 side effect，例如是否可逆、是否跨 scope、是否扩权。对 Hermes 来说，完成门禁应从“任务成功”升级为“任务成功 + 没有越界 action + 有可审计轨迹”。 |
| [[evosop-iterative-tool-optimization | EvoSOP]] 进一步提醒：harness 中反复成功的多步流程可以晋升为 SOP 高阶工具，但必须配套合并、评估和剪枝机制，避免 workflow/tool layer 膨胀。 |
2026-07-10 补充：test-time harness evolution 与 code-owned contracts
| [[tthe-test-time-harness-evolution | TTHE]] 把 harness 从静态脚手架推进为 test-time adaptation 的状态：在不更新模型权重、不使用 gold label 的情况下，系统可以从未标注执行轨迹中提出 harness 变体，并用执行代理信号选择一个持久化到后续输入。这提示 Hermes 的无人 loop 不应只把失败和跳过原因写进报告，还应让这些轨迹逐步改进搜索 query、晋升门槛、验证 gate 和页面合同。 |
| [[from-prompts-to-contracts-harness-engineering | From Prompts to Contracts]] 则补充了企业产品化维度：source boundary、entity routing、answer contract、validator、trace 和 composition boundary 应由代码/manifest/schema 拥有，而不是只写在 prompt 中。对 llm-wiki 来说，正式页面模板、raw hash、source-backed claims、回答引用边界和发布前检查，都是知识库 harness 的合同层。 |
二者共同说明：Harness Engineering 的下一步不是“写更长规则”，而是把规则变成可版本化、可验证、可演化的控制程序；同时要警惕 proxy hacking 和过度演化，确保每次规则持久化都有真实验证证据。
2026-07-12 补充：能力诊断与按需工具路由
| [[uniclawbench-proactive-agent-benchmark | UniClawBench]] 的三角色闭环评估说明，harness 需要能诊断失败发生在哪个能力层：skill usage、exploration、long context、multimodal 或 cross-platform coordination。[[ratel-context-engineering-tool-selection | Ratel]] 则补充了执行前的 capability router：不是把全部工具交给模型，而是先根据任务选择少量相关工具/技能。 |
这两者合在一起，给 Hermes 一个更清晰的 harness 形态：任务开始时做 capability retrieval，执行中保留轨迹与产物，结束时按能力维度归因并由独立验证层给 verdict。否则 skill 越多，系统越可能变成“强但混乱”的工具堆。
2026-07-13 补充：harness 需要被当作可测变量，报告声明也需要 receipts
| [[harness-benchmarks-meta-review | The harness still matters]] 把多个 coding-agent benchmark 的公开证据整理成 meta-review，核心提醒是：同一个模型在不同 harness 下，质量、成本、token 使用和运行时间都会变化；不存在跨所有模型和任务通吃的 harness。对 Hermes 来说，这意味着每日雷达、wiki ingest、代码修改等自动化流程也应被当成可测 harness，而不是只归因于模型强弱。 |
| [[did-it-claim-evidence-reconciliation | did-it]] 则把 harness 的验证边界推进到最终报告：agent 说“测试通过/文件已创建/迁移已跑完”不等于事实，必须能在 transcript 或重新执行中找到 claim-level receipt。未来 Hermes 的完成定义应更显式地区分 BACKED、UNSUPPORTED、CONTRADICTED 和 NOT-CHECKABLE，避免“无证据但语气确定”的完成声明。 |
2026-07-14 补充：harness 同时塑造环境、工具面和上下文边界
| [[seta-scaling-environments-terminal-agents | SETA]] 说明 harness 可以作为环境生成器：把来源、任务规格、依赖、测试、oracle solution、rollout verifier 组合成 terminal agent 可学习/可评估的环境。[[execute-code-tool-surface-ablation | execute_code 工具面限制实验]] 则说明 harness 也是工具面选择器：开放 bash、限制 code execution、使用 IDE primitives 会改变 path-cost、failure-cost 与安全边界。 |
| [[aigx-context-format | AIGX]] 补上上下文边界层：per-file boundary index、forbidden imports 和 gotchas 把“应当如何改这个仓库”的隐性知识变成 agent 可消费的结构。三者合起来说明，好的 harness 不只是 prompt，而是环境、工具、上下文、verifier 的组合控制面。 |
2026-07-15 补充：前置理解阶段可以成为 harness 的显式模块
| [[acquire-qa-driven-repository-knowledge | ACQUIRE]] 把 coding-agent 修复流程拆成 Questioner、Answerer、Resolver 三个角色，说明 harness 可以在行动前加入一个“知识缺口 → 证据型 QA”的显式模块。与纯关键词定位或直接 patch 相比，这种结构更容易审计：可以分别检查问题是否覆盖机制/设计/结构/生态，答案是否有证据，最终补丁是否消费了这些答案。 |
对 Hermes 来说，这适合成为复杂任务的低风险默认：先只读生成 QA，再决定是否进入写操作。它也和 Context-Engineering、Agentic-Coding、Agent-Benchmarks 形成闭环：上下文由问题驱动，行动由证据支撑，评测能观察中间过程。
2026-07-16 补充：harness 优化必须能持续迁移，并能在工具可靠性变化时换路由
| [[agent-optimizers-compound-terminal-bench | Do Agent Optimizers Compound?]] 把 harness self-improvement 从一次性静态提分推进到持续学习评测：旧任务优化后，新任务到来时是否迁移，第二轮优化是否继续提升且不遗忘旧能力。它提醒 Hermes：每日雷达、skills、SOP 和工具纪律的持久化改动，都应带 regression control；否则“自我优化”可能只是对昨天的任务过拟合。 |
| [[set-shifting-behavioral-test-harnessed-agents | Set-shifting Behavioral Test]] 则补上工具路由层：当冗余工具的 hidden reliability 变化时，agent 往往会固定到少数 recurring routine，受路径依赖和工具 framing 影响。Harness 因此不只要定义工具，还要记录何时因证据变化从 PDF 转 HTML、从 RSS 转 GitHub API、从 shell 转专用读写工具；route change 本身应成为可审计信号。 |
二者共同说明：可演化 harness 的最低要求是“改进 + 回归控制 + 路由适应”。对 Hermes 来说，低风险规则可以直接固化，但每次固化都应问：是否保留 orient/raw/index/log/验证等旧能力？是否在来源不可用、工具失败或任务边界变化时及时换路？
2026-07-17 补充：harness 自身需要行为地图、安全门禁和规则治理
| [[harness-handbook-evolving-agent-harnesses | Harness Handbook]] 把 harness evolution 的瓶颈定义为“行为到代码位置”的映射问题：当 prompts、state、tools、validators、control flow 分散在多个文件和阶段中时，直接 grep 或整仓塞上下文都不稳定；更好的方式是生成行为中心的 handbook，并在修改时用渐进披露定位相关阶段、条目和源码证据。 |
| [[security-debt-autonomous-coding-agents | Autonomous Coding Agents 的 Security Debt]] 则提醒，高吞吐 coding-agent workflow 会把 secrets、供应链、权限和 CI/CD 配置风险推到协作界面；harness 不能只管功能正确性，还要在 PR / tool / review 入口加入 security gate。[[self-improving-coding-agents-behavioral-rules | Self-Improving Coding Agents Through Behavioral Rules]] 补上跨会话治理：review feedback 应被压缩为版本化行为规则、checklist 和 validation，而不是只写成一次性反思。 |
对 Hermes 来说，下一步 harness 自我优化应从“每日新增规则”升级为“行为地图 + 安全边界 + 规则生命周期”：知道规则影响哪个阶段，知道哪些变更需要安全检查，也知道哪些规则应合并、退役或验证。
2026-07-18 补充：控制原语必须在 effect boundary 被验证
| [[stop-means-stop-control-primitives | Stop Means Stop]] 指出，approval、cancel、timeout 这类 agent-framework 控制原语经常只有命名层面的 barrier semantics：暂停一个分支不代表 sibling branch 不会产生副作用，取消/超时也不代表 orphan/zombie task 已停止。 |
| [[proof-or-stop-evidence-gated-lifecycle-control | Proof-or-Stop]] 从另一侧补充：生命周期状态也不能由 agent claim 推进，必须由 fresh、source-state-bound、可复查的 evidence gate 推进。二者共同说明，Harness Engineering 的控制层要靠近真实 side effect 和生命周期状态机，而不是只靠 prompt、UI 状态或框架内部标志。对 Hermes 来说，后台进程 kill/timeout、部署发布、文件写入和消息投递都应尽量有 post-effect verification。 |
2026-07-19 补充：harness 应有 eval 回归、purpose-shaped context 与身份控制面
| [[coder-eval-skill-evaluation-ci | coder_eval]] 把 agent/skill harness 的质量变成可回归测试对象：任务合同、sandbox、weighted criteria、tool-call/cost telemetry 和 CI verdict 共同决定 skill 是否真的生效。[[okfy-purpose-shaped-knowledge-bundles | OKFy]] 则提醒 harness 不能只控制工具，也要控制 agent 看到的上下文工作集：大型 wiki / repo 应按 Purpose 编译成小而当前的 bundle，并用 source checking 与 owner verdict 防止自证。[[chancery-agent-identity-writ-control | Chancery]] 补上身份与权限层：长期 loop、worker 与工具调用应具备可撤销身份、只缩窄不扩大的授权、sealed credentials 与 metadata audit。 |
对 Hermes 来说，下一代 harness 形态应是三层合同：eval contract 证明 workflow 没退化；context contract 证明 agent 使用的是任务所需、来源可追踪的知识；identity/action contract 证明实际副作用在允许范围内发生并可审计。
2026-07-21 补充：harness 需要 repo artifact、静态评分与运行时轨迹三层证据
| [[flow-next-agentic-engineering-workflow | Flow-Next]] 把 harness workflow 具体化为 repo-native artifact chain：spec、task graph、fresh-context worker、cross-model review 和 receipt。[[harness-score-maturity-scanner | Harness Score]] 则从另一侧把 repo harness 的结构成熟度变成 deterministic scanner：AGENTS.md、rules、skills、hooks、sensors、CI 和 safety hygiene 都可被本地评分。[[nemo-relay-agent-runtime-control | NeMo Relay]] 补上运行时层：agent run 需要 raw events、scope、policy 和 normalized trajectory，而不只是最终 patch 或自然语言报告。 |
这说明 Harness Engineering 的证据栈至少有三层：设计前的 workflow artifacts、执行前/仓库级的 maturity checks、执行中的 trajectory receipts。对 Hermes 来说，复杂任务不应只验证最终文件是否存在，还要记录任务如何被切片、repo 是否具备反馈/guardrails、工具调用是否在允许 scope 内发生。
2026-07-22 补充：harness QA 栈要覆盖 catalog、lint、runtime record 与 tamper evidence
| [[microsoft-agent-skills-context-driven-development | Microsoft Agent Skills]] 提醒，harness 的上下文包会自然长成 catalog / installer / docs / MCP configs 生态；如果没有 selective loading 和 context budget，技能越多反而越容易让 agent 混淆。[[vigiles-agent-harness-audit | Vigiles]] 则把 AGENTS.md、skills、subagents、hooks 的有效性变成 audit/lint/test/eval 对象，重点识别 false confidence：规则看起来存在，但 agent 没有采用或 hook 实际失效。 |
| [[halo-record-runtime-records | Halo Record]] 补上 runtime evidence 的完整性：tool calls、model calls、data access、approvals 可以进入 hash-chained append-only log。对 Hermes 来说，这把 harness QA 栈扩展为四层：catalog/routing 控制加载什么；lint/audit 检查 harness artifact 是否健康；test/eval 检查行为是否真的改变；runtime records 证明 effectful actions 没被静默篡改。 |
2026-07-23 补充：harness 可以被包装成 agent 可路由的知识仓库，并加入 research-first gate
| [[harness-engineering-anthology | Harness Engineering Anthology]] 把 harness 方法论本身包装成 repo-native context bundle：README 建议把 agent 指向该仓库和目标系统，由 AGENTS.md 路由到 thesis、playbooks、sources 与 proof。这把 harness 从“提示词里的一套原则”推进到“可被 agent 消费、可引用、可路由、可追溯的知识环境”。对 Hermes / llm-wiki 来说，wiki/ai/ 也应逐步具备类似结构：入口、主题地图、任务路由、playbooks、来源库和 receipts，而不只是页面列表。 |
| [[nothing-new-under-the-sun-research-first-scouting | Nothing New Under The Sun]] 则补上行动前的经济性/战略性 gate：在新增代码或依赖前，先按 REUSE / USE / FORK / BUY / INTEGRATE / BUILD 搜索，并用 reliability、strategic value、adaptability、TCO、speed-to-value 评估候选。Harness 因此不只控制“如何安全执行”，也要控制“是否应该执行/构建”。对 Hermes 来说，复杂工程任务默认应先做只读 scouting；对 llm-wiki radar 来说，正式页面晋升也应先问是否已有页面、是否只需更新、是否只留 raw。 |
2026-07-24 补充：harness 正在扩展为 workspace、loop skill 与语义 lint 三层
| [[bossconsole-agent-operator-console | BOSS Console]] 把 harness 从 repo 内的规则、hooks 和验证脚本扩展到桌面 workspace：浏览器、终端、编辑器、secret manager、MCP 工具和插件系统都成为 agent 可感知、可治理的操作面。[[agentops-bounded-operating-loop | AgentOps]] 则把一次 coding-agent run 固化为 intent snapshot、bounded build、fresh Validate 与 durable verdict。[[alint-model-backed-code-analysis | alint]] 进一步说明，AI 生成代码的常见语义失败可以沉淀为 model-backed lint rules，而不是每次靠开放式 review 重新发现。 |
这三者共同提示：下一代 harness 至少有三层合同：workspace contract（agent 能看什么、能动什么、secret 如何隔离）、operating-loop contract（意图、范围、验证者和 verdict 如何持久化）、semantic-lint contract（哪些高频失败模式被机器化检查）。对 Hermes / llm-wiki 来说，这意味着每日 cron 和代码任务都应更显式地区分 read-only observation、effectful action、post-effect verification 与 semantic quality gate。
2026-07-25 补充：harness 需要被 benchmark、治理并跨宿主抽象
| [[openbench-harness-benchmark | OpenBench]] 把 harness 从“工程经验”变成可测变量：固定模型和任务，比较不同 coding-agent harness 的正确率、token tax、墙钟时间、checker 与 transcripts。[[preloop-agent-control-plane | Preloop]] 则把工具/模型流量拉到 control plane：MCP firewall、model gateway、policy-as-code、approval、runtime observability 和 audit trail。[[omnigent-meta-harness | Omnigent]] 补充 meta-harness 方向：Claude Code、Codex、Cursor、OpenCode、Hermes、Pi 和自定义 agents 可在同一 orchestration/session/sandbox/policy 层中组合。 |
这三者共同说明：下一阶段 Harness Engineering 至少要回答三类问题：它是否比其他 harness 更有效；它是否在真实副作用前有可审计控制面；它的方法层是否能跨宿主迁移。对 Hermes / llm-wiki 来说，daily radar、coding task 和发布 workflow 都应记录自身 harness cell：使用了什么来源/工具路径、哪些 gate 生效、是否有 verifier、成本/失败在哪里、哪些结论只是 medium confidence。
2026-07-26 补充：harness 的下一块基底是 route、session、approval 与 runner evidence
| [[agent-graph-fact-routed-skill-workflows | Agent Graph]] 把 skill/workflow 从长 prompt 推进到 fact-routed graph：当前事实选择下一条合法 Route，只加载该 route 需要的资源，并用 Outcomes/Tests 支持恢复和验证。[[agent-session-io-harness-neutral-session-substrate | agent-session-io]] 则补上跨宿主 session 读取层：Codex/Claude Code 等本地会话可以被 list/show/export，为 claim-level receipts、失败复盘和 harness A/B 评测提供原始轨迹。 |
| [[approving-human-gated-multi-agent-workflows | Approving]] 把 human approval、sandbox、artifact contract 和 rollback 组合为多 agent workflow 的控制结构；[[ai-dev-team-supervised-delivery-harness | AI Dev Team]] 则强调 runner-observed verification：模型说测试通过不算，runner 观察到命令结果才算。对 Hermes / llm-wiki 来说，下一步低风险优化不是引入重平台，而是把这些机制转成轻量合同：route 状态外部化、session/工具输出作为 receipts、高风险动作 HOLD 等待人工 gate、完成声明绑定 runner output。 |
2026-07-27 补充：harness 需要治理 token、视觉重复、安全 catalog 与知识包边界
| [[token-diet-token-efficiency-skill | token-diet]] 把 token / 输出 / 文件读取 / 工具调用 / 测试范围变成 harness 纪律，说明成本优化不是“少做验证”，而是减少冗余叙事、重复探索和无边界上下文膨胀。[[sitegeist-visual-diversity-benchmark | Sitegeist]] 则把 harness 扩展到生成式前端/视觉任务：隔离生成、artifact contract、移动端/console/redundant asset 检查和 duplicate audit，防止 coding agent 在可运行之外陷入模板化重复。 |
| [[sail-skill-secure-ai-lifecycle | SAIL Skill]] 提醒安全 harness 需要 catalog-backed risk disposition：风险 ID、生命周期阶段、标准映射、缓解措施和审计产物，而不是模型自由发挥的安全建议。[[design-harness-evidence-board | design-harness]] 与 [[okf-gem-local-knowledge-bundles | OKF Gem]] 进一步说明，复杂设计和项目知识也需要 repo-native artifacts、lint/search/graph、append-only log 和 human gate。 |
对 Hermes / llm-wiki 来说，harness 的下一层合同应覆盖四类预算与证据：token budget（少冗余但不省证据）、artifact diversity（不只 build/pass，也查重复和模式收敛）、security catalog（风险有 ID 和映射）、knowledge boundary（全局 wiki、repo-local bundle、临时 memory 分层）。
2026-07-28 补充：agent topology、action control、claim honesty 与 operator control room
| [[graph-engineering-agent-topology | Graph Engineering]] 把 harness 的结构语言扩展为两类图：知识图谱负责实体、关系、事件、来源与融合；任务图负责真实依赖、并行 worker、独立 verifier、stop rule 和 human gate。它提醒我们，复杂 agent workflow 不应只是一段长 prompt，而应有可检查的 topology。 |
| [[cyvisguard-mcp-security-control-plane | CyVisGuard]] 则把控制层压到 action boundary：identity/delegation、capability policy、data-flow taint 和 audit trail 需要在 MCP/tool 调用前后生效。[[halu-core-claim-grounded-agent-evaluation | halu-core]] 补上最终报告维度：agent 是否真的做了事，以及报告中的 claim 是否能由 action log 支撑，应该被分开评分。[[rimz-agent-fleet-control-room | RimZ]] 说明多 agent 时代还需要 operator control room：状态、任务、context health、cost、durable messages、scheduled wakeups 和 exit codes 都是 harness 的可观测面。 |
对 Hermes / llm-wiki 来说，下一步低风险改进是把每日 radar 的完成定义收紧为：candidate graph（发现和晋升关系）、action receipt（写了哪些文件/跑了哪些验证）、claim honesty（报告声明是否有工具输出支持）、operator summary（PASS/HOLD/FAIL 和阻塞原因）。
2026-07-29 补充：harness 需要 scope 收敛、eval design、runtime context 与可编译 skill
| [[coderail-convergent-coding | CodeRail]] 把 vibe coding 的发散探索收敛成 repo-local lifecycle gate：start 声明范围与完成标准，check 对照 repo truth 判断是否跑偏，done 验证测试/人工检查、确认变更未越界并留下交接状态。它补充了 harness 的“scope convergence”层：规格不一定一开始完整，但探索所得必须被追认为可检查 guardrail。 |
| [[laborant-evaluation-design-skills | Laborant]] 把 AI 系统评测设计变成 skill：先界定 live runner、行为边界、cases、methods、scorers、observations、metrics 和 limitations，再谈实现 evaluator。[[vinv-runtime-context-bandits | Vinv]] 则把上下文从静态 repo 文本推进到 runtime traces、metrics 和 context graph。二者共同说明：harness 的 verifier 不能只停在“跑了测试/读了文件”，还要回答评测对象是什么、运行时实际发生了什么、哪些 claim 证据不足。 |
| [[agentbattler-bench-sealed-harness-benchmark | AgentBattler Bench]] 强调 sealed schedule、container isolation、separate verifier、snapshot hash、replay 和撤回被污染 ranking；[[kitbash-cross-host-agent-skill-format | Kitbash]] 则把 skill 当作可编译、有 standing token cost、有 lockfile/drift 风险的工程制品。对 Hermes / llm-wiki 来说，下一步低风险改进是把每次 radar/ingest 都看成一个 bounded harness cell：先收敛候选范围，再设计最小评测/证据标准，尽量读取运行时或工具输出证据，最后把 skill/page/index/vector 等派生产物视为可检查、可漂移的 compiled outputs。 |
2026-07-30 补充：harness review、安全 hook、协作 spine 与 skill lifecycle
| [[better-harness-evidence-bounded-workflow-review | Better Harness]] 把 coding-agent workflow 本身变成可复盘对象：任务理解、上下文准备、受控执行、变更验证和交付学习都必须绑定 evidence；缺证据不能被包装成评分。[[portcullis-claude-code-security-hooks | Portcullis]] 则把控制层推进到 Claude Code / OpenCode hooks：Bash、文件、凭证、MCP、agent spawn、output 等 effect boundary 都需要预执行或后执行检查。 |
| [[quorum-mcp-agent-collaboration-spine | quorum]] 补充多 agent 场景的 coordination primitive：身份、事件 cursor、房间消息和文件 claim。[[hermes-skill-loop-closed-skill-learning-loop | hermes-skill-loop]] 则说明 harness 的自我改进应覆盖 skill learning、usage telemetry、curator 归档/合并、防递归和 origin firewall。对 Hermes / llm-wiki 来说，下一步低风险改进是把每日 radar 当成一个 evidence-bounded harness cell：候选发现、晋升/拒绝、文件写入、验证、向量重建和自我优化建议都要有 receipts；高风险无人动作命中 ask 类安全边界时默认 HOLD。 |
2026-07-31 补充：bounded loop、确定性 firewall 与 MCP admission
vibe-loop-bounded-coding-agent-loops 把 harness 的外层 loop 具体化为 runtime-owned supervisor：任务源、锁、隔离 worktree、gate/review、run records 和 autopilot 共同限制 coding agent 的行动半径。redstamp-deterministic-agent-firewall 则说明 effect boundary 上的授权应尽量确定性：risk tier、egress allowlist、write roots、secret exfil 和 tamper-evident audit 不能只靠模型自律。
mcp-gauntlet-agentic-mcp-server-evaluator 进一步把 harness 的接入门槛扩展到 MCP server：不仅要检查 schema，还要评估 agent task success、runtime output injection、robustness 和 definition drift。对 Hermes 来说，下一步 harness 的低风险改进是把“外部工具/技能/自动 loop 接入”统一成 admission cell：scope、权限、代表性任务、输出污染、漂移指纹、runner receipt。
2026-08-01 补充：组织级 scope、配置 preflight、control plane 与 board 化 loop
qm-multiplayer-agent-harness 把 harness 扩展到多人组织运行时：person / room / project 各自拥有 scoped memory、files、keychain view、permissions、crons、web apps 与 durable sandbox，底层 agent loop 可切换 Pi、OpenCode、Codex、Claude Code 等宿主。agentdoctor-coding-agent-config-audit 则提醒 harness 的第一道门不一定是测试，而是 repo 的 agent 配置 preflight：敏感文件是否会进入上下文、bypass 权限是否开启、MCP/context/instruction 是否过宽或 stale。
forgeos-skill-intelligence-control-plane 把 skill routing、最小 ContextPack、deterministic steps、policy filter 与 evidence ledger 组织成 trust control plane；loop-board-autonomous-pr-task-board 则把长期 coding loop 放进 board / worktree / PR / checks / human review / stop condition 结构中，强调 agent 不能触碰主 checkout，也不能设置“人类已看过”的状态。对 Hermes / llm-wiki 来说，下一步 harness 最小单元应是 scoped work cell：明确身份/作用域、运行前配置体检、最小上下文包、确定性 gate、外部证据、停车条件和报告 receipts。
2026-08-02 补充：harness 需要 memory substrate、trajectory substrate 与 fact-routed skill contract
axisagentic-runtime-trajectory-framework 把 harness 的运行证据提升为 append-only trajectory：同一条记录可用于恢复、回放、评测和 SFT export。agent-graph-fact-routed-skill-workflows 则说明 workflow contract 应由外部事实选择合法下一步，而不是让 agent 在长 prompt 中自行记忆流程。optmem-permanent-agent-memory 补上轻量长期记忆 substrate：经验可追加、可压缩、可撤销，但不应替代任务级证据。
对 Hermes 来说，成熟 harness 的最低栈正在变成：事实路由决定下一步，effect boundary gate 控制副作用，runtime trace 保存证据，memory/skill lifecycle 只晋升经过验证的经验。否则“自动化越多”很容易变成不可复盘的 prompt 驱动流程。
2026-08-03 补充：生产工具 catalog 与 tool-level gates
awesome-agentic-devops 和 claude-starter-kit 共同提醒：harness 的边界应前移到“工具/skill/agent 是否允许进入工作流”。前者用 official-first、approval control、tracing evidence、maturity 与 operational risk 给 DevOps agent/MCP catalog 打分；后者把 Claude Code 项目流程中的提交、安全审查、bash guard、trace scan 做成 tool-level gate，而不是提示词提醒。
对 Hermes 来说，这补上了 admission-control 层：外部 skill 或 MCP 不能只按 star/README 入库或安装，应先记录权限、是否只读、是否有审批、是否可追踪、是否可回滚；复杂代码任务也应把 commit/deploy/delete 等关键副作用变成 gate。
写入记录
- 2026-08-03 09:00 CST：补充 Awesome Agentic DevOps、ultracodex、record-and-replay-skill、Claude Starter Kit 对 operator-safety catalog、agent-as-function、示范到 skill、tool-level gates 的启发。
- 2026-08-02 09:01 CST：补充 OptMem、AxisAgentic、Agent Graph、SimpleEnglish 对长期记忆、轨迹证据、事实路由 skill 和受控语言评测的启发。
- 2026-08-01 09:06 CST：补充 QM、AgentDoctor、ForgeOS、loop-board 对组织级 scope、配置 preflight、skill/control-plane 路由和 board 化 autonomous PR loop 的启发。
- 2026-07-31 09:01 CST：补充 vibe-loop、redstamp、mcp-gauntlet 对 bounded loop、确定性 action firewall 与 MCP admission cell 的启发。
- 2026-07-30 09:00 CST：补充 Better Harness、Portcullis、quorum、hermes-skill-loop 对 evidence-bounded workflow review、安全 hook、agent 协作 spine 与 skill lifecycle 的启发。
- 2026-07-29 09:00 CST：补充 CodeRail、Laborant、Vinv、AgentBattler Bench、Kitbash 对 scope convergence、eval design、runtime context、benchmark integrity 与跨宿主 skill 编译的启发。
- 2026-07-28 09:00 CST：补充 Graph Engineering、CyVisGuard、halu-core、RimZ 对 agent topology、MCP action control、claim-grounded report 和 agent fleet control room 的启发。
- 2026-07-27 09:07 CST：补充 token-diet、Sitegeist、SAIL Skill、design-harness、OKF Gem 对 token 预算、视觉重复、安全 catalog 和知识包边界的 harness 启发。
- 2026-07-25 09:00 CST：补充 OpenBench、Preloop、Omnigent 对 harness-as-variable、control-plane governance 和 meta-harness 抽象的启发。
- 2026-07-24 09:01 CST：补充 BOSS Console、AgentOps 与 alint 对 workspace-level harness、bounded operating loop 和 semantic lint gate 的启发。
- 2026-07-23 09:00 CST：补充 Harness Engineering Anthology 与 Nothing New Under The Sun 对 agent context bundle、AGENTS-style routing 和 research-first build gate 的启发。
- 2026-07-22 09:00 CST：补充 Microsoft Agent Skills、Vigiles、Halo Record 对 skill catalog、harness audit/lint/test/eval、runtime records 与 tamper-evident action ledger 的启发。
- 2026-07-21 09:01 CST：补充 Flow-Next、Harness Score、NeMo Relay、FastContext 对 agent workflow、harness scoring、runtime trajectory 或只读上下文探索的启发。
- 2026-07-19 09:04 CST：补充 coder_eval、OKFy、Chancery 对 eval 回归、purpose-shaped context 和 agent 身份/权限控制面的启发。
- 2026-07-18 09:00 CST：补充今日 radar 对证据门控、上下文质量、技能安全或控制原语的启发。
- 2026-07-01 09:00 CST：补充 AgentOps 对 Harness Engineering 的 verification membrane 启发。
- 2026-07-05 09:02 CST：补充 constraints substrate 与 Lovable risk routing 对 Harness Engineering 的启发。
- 2026-07-06 09:00 CST：补充 persistent-state coding-agent attack 对跨 PR / 跨 session stateful link-tracker 的启发。
- 2026-07-07 09:00 CST：补充 DSCC 组合式工具策略与 UnderSpecBench 行动边界评测对 harness 门禁的启发。
- 2026-07-07 09:29 CST：补充阿里云开发者生产 Loop 案例，明确 Harness 外层还需要自动发现、跨轮状态、独立验证和人类审批边界。
- 2026-07-08 09:00 CST：补充 Lilian Weng 对 harness self-improvement 的框架，以及 AgentTether 对运行时失败定位/修复记忆的启发。
- 2026-07-09 09:00 CST：补充 deterministic gates、action-graded severity 与 EvoSOP 对 harness / benchmark / skill 生命周期的启发。
- 2026-07-10 09:00 CST：补充 TTHE 与 Prompts-to-Contracts 对 test-time harness evolution、code-owned contracts 和 llm-wiki 合同层的启发。
- 2026-07-12 09:00 CST：补充 UniClawBench 与 Ratel 对 harness 能力诊断、按需工具路由和验证闭环的启发。
- 2026-07-13 09:00 CST：补充 harness-benchmarks 与 did-it 对 harness A/B 评测、成本/质量分离和最终声明 receipts 的启发。
- 2026-07-14 09:00 CST：补充 SETA、execute_code 工具面实验与 AIGX 对环境生成、工具面、仓库上下文格式的启发。
- 2026-07-15 09:02 CST：补充 ACQUIRE 对前置知识缺口、证据型 QA 和只读理解阶段作为 harness 模块的启发。
- 2026-07-16 09:00 CST：补充持续学习 agent optimizer 与 set-shifting 工具路由评测，明确 harness 自我优化需要 regression control、旧能力保留和可靠性变化时的 route change。
- 2026-07-17 09:00 CST：补充 Harness Handbook、agentic coding security debt 与 behavior-rule self-improvement，明确 harness 自身需要行为地图、安全门禁和规则生命周期治理。