提案：Harness² 双层递归 —— 任务级证据闭环 + Harnessing 级经验沉淀（双插件 + 真实会话 E2E）

[HeliosLz]

提案：Harness² 双层递归 —— 任务级证据闭环 + Harnessing 级经验沉淀

定位：生态项目提案 / Phase 1 原型，不是上游 PR。仓库刚公开，欢迎契约审查、质疑与共创。
仓库：https://github.com/HeliosLz/harness2-recursion

问题

Agent 在任务里反复失败时，现有 harness 通常只做“重试 / 换模型”，很少有插件完整回答三个问题：

1. 失败模式是什么（可结构化、可复现）？
2. 哪种 harness 修改能改善它（候选编辑 + 逐候选隔离验证）？
3. 这次修改/拒绝的因果证据能否沉淀下来，避免编辑器再次提出已被证伪的方案？

方案：两个独立插件 + 一条冻结事件契约

插件	职责	关键约束
harness2-task-recursion	失败信号 → Propose（LLM 产出双候选）→ Probe（每候选一个隔离子智能体 + 指标）→ Compose 决策 → 账本 v3 → 应用/降级	只监听 3 个事件；agent/pre-step 内绝不做 I/O/LLM/子智能体；observeOnly 默认 true
harness2-meta-recursion	消费三类结构化事件 → 事后归因 → EXPERIENCE.md → 只读 harness2Experience 门面	不监听原始会话/工具/LLM 事件；不读用户对话；经验只供编辑器查询，不注入执行器上下文

两个包互不 import；事件载荷字段级冻结、发射前严格校验、账本先 append 后 emit（append 失败不 emit）。

三个希望重点 review 的差异点

1. 双插件事件契约：task 只产出 probe/completed / compose/applied / compose/rejected / propose/failed 四类结构化事件，meta 只消费它们。跨包类型各自声明、结构一致，src/constants.ts 两包逐字节相同。
2. propose/failed 是独立终态：Propose 两次失败 = 没有产生任何可探测候选，这不是“候选被拒绝”。它有自己的事件与账本记录，与 probe/completed/compose/* 在同一 cycleId 下互斥；meta 对它只诊断、零写入。我们明确拒绝用“空 id 的 compose/rejected”表达它——那会产生形状合法但消费方无法归因的语义遮蔽。
3. 元知识只改进编辑器，不注入执行器：经验条目的 edit 字段（component/operation/contentHash）永远取自 task 的事实载荷；反射 LLM 只能解释 condition（且必须被 evidenceSummary 子串约束）；confidence 由冻结公式从证据（trials/metricDelta/adoption/tokenCostSource）重算，不采信 LLM 或文件值。这从结构上杜绝“LLM 篡改编辑内容”。

可审计性（本提案核心）

• 冻结契约：CONTRACT.md（事件 schema、门面签名、账本 v3、归因规则、迁移映射、applyMode 裁决）
• 逐项验收：SELF-CHECK.md（每条验收对应证据文件/测试名，含独立审计发现与整改记录）
• 测试：task 15 + meta 14 + loader smoke 5 = 34/34；两包 tsc --noEmit 0 error
• 真实会话 E2E：隔离 profile 内通过官方 dsh plugin add 安装，两次真实 headless 会话（触发 agent/request-error）：
  • 账本 4 条 v3 记录（2 probe/completed + 2 compose/applied）
  • applyMode：run1=noop-todo（激活时账本不存在，冻结语义）→ run2=next-task-ledger（读到上一修订源）
  • 修订锚点链 null → … → … → … 贯通；EXPERIENCE.md 生成 positive 条目（confidence 0.50，measured tokens）
  • 卸载后 7 个监听器全部释放，四类事件不再写账本/经验文件
  • 复现：E2E_CLI=<0.2.1 dsh bin.js> node e2e/run.mjs

真实的缺口（不隐藏）

缺口	状态
pre-step-patch 需要等待上游提供 applyHarnessPatch API	上游依赖，不是方案未实现；dsh 0.2.1 无此 API，当前如实降级到 next-task-ledger/noop-todo，保留 TODO，不伪造 API
Probe 子智能体工具沙箱	上游依赖：等待子智能体工具限制 API；当前 prompt 明确 ADVISORY、结果仅用于行为对比
八类组件名与 Harness² 原文对齐	常量已冻结 + 旧名迁移表；等待权威清单确认

希望讨论的问题

1. 事件命名与载荷字段是否符合生态惯例（尤其 propose/failed 独立终态设计）？
2. harness2Experience 只读门面保持 ctx.provide(frozenFacade) 是否合适，还是应改为 Cordis Service 导出？
3. 上游是否计划提供运行时 harness patch API 与子智能体工具限制 API？接口形态是什么？
4. 是否有维护者愿意把本方案纳入 experimental bundles 联合孵化？
5. 组件名表是否有官方 / Harness² 原文的权威清单可对齐？

链接

• 仓库：https://github.com/HeliosLz/harness2-recursion
• 契约：https://github.com/HeliosLz/harness2-recursion/blob/main/CONTRACT.md
• 验收：https://github.com/HeliosLz/harness2-recursion/blob/main/SELF-CHECK.md
• 真实 E2E：https://github.com/HeliosLz/harness2-recursion/blob/main/e2e/README.md