Proposal: Add DARE Coding Harness Profile

[bouillipx]

DARE Coding Harness Proposal

Status: Proposal

Date: 2026-03-02

Scope: dare_framework/ 上层的第一方默认运行环境

Audience: 架构师、框架维护者、CLI/Agent 开发者

---

1. Executive Summary

本提案建议在现有 DARE Framework Core 之上，正式收敛一层第一方默认运行环境：

• 名称：DARE Coding Harness
• 定位：面向 coding agent 的官方默认 profile
• 目标：把当前已经存在但尚未形成默认闭环的能力，收敛成一个 默认可运行、可审计、可恢复、可审批、可回放 的运行系统

本提案不替代 DARE 现有的 framework 定位，而是在其上增加一个更靠近产品交付和运行保障的层次。

一句话定义：

DARE Core 负责“能力与接口”，DARE Harness 负责“默认运行闭环”。

---

2. Background

当前仓库已经具备较强的 runtime 内核能力：

• DareAgent 已实现 Session / Milestone / Plan / Execute / Tool 五层循环
• Tool 调用已通过 ToolGateway 统一出边界
• 工具安全预检、policy check、approval memory 已接入工具调用主路径
• Hook、Telemetry、MCP、Skill、Knowledge 等能力已可组合装配

这些能力表明，项目已经不再是一个简单的 agent demo，而是一个具有明确控制面意识的 runtime framework。

但从 2026 年 agent engineering 的视角看，当前仓库仍更接近 framework，而不是一个完成态的 agent harness。主要原因不是缺少单点能力，而是缺少以下默认闭环：

1. 默认 event log 与 replay 闭环
2. 默认 checkpoint / resume 闭环
3. validated plan 到 deterministic execution 的默认主路径
4. 默认 context lifecycle 管理
5. 面向 operator 的统一 control plane

这意味着：

• 设计上的“状态外化、可审计、可复验”理念已经清晰
• 但默认运行姿势仍然偏“显式装配的 framework”，而不是“开箱可用的 harness”

---

3. Problem Statement

3.1 当前主要问题

当前系统的主要问题不是“没有 loop / tool / policy / hook”，而是以下几点尚未收敛成第一方默认能力。

P1. Event Log 仍是可选能力，不是默认事实来源

event domain 已被定义为 WORM 事实来源，但 canonical default implementation 和 builder 默认装配仍未形成统一闭环。

结果：

• “可审计”依赖调用方显式注入
• replay/query/verify-chain 不能成为默认运行保障
• observability 和 audit 仍然存在裂缝

P2. step_driven 语义已存在，但尚未升格为可信执行主路径

当前代码与 spec 都已经表达出 model_driven / step_driven 双模式的方向，但 step_driven 还未作为 builder 层面的默认执行选项完成接线。

结果：

• validated plan 的结构价值没有完全转化为运行控制价值
• plan 仍更像“建议”，而不是“受信执行输入”
• 难以沉淀稳定的 replay、evidence、failure corpus

P3. 默认 Context 仍偏“容器”，不是生命周期管理器

当前默认 Context 主要完成：

• STM 读写
• tool listing
• system prompt + skill 注入

但默认 assemble() 尚未把以下能力纳入正式流水线：

• LTM / Knowledge 检索融合
• 预算驱动的压缩
• 大 tool output 摘要折叠
• retrieval / compression provenance

结果：

• 长任务中的稳定性主要仍依赖模型自身记忆和好运气
• 审计层难以解释“为什么这次模型看到了这些上下文”

P4. CLI 更像发任务入口，而不是 operator control plane

当前 CLI 已有：

• run/chat/script
• approvals:*
• mcp:*

但尚未形成完整运行控制面，例如：

• runs inspection
• replay
• resume
• checkpoint browsing
• audit chain verification

结果：

• harness 运行状态对操作者仍不够透明
• “人参与运行时控制”的能力分散在多个局部命令中

---

4. Proposal

本提案建议在 dare_framework/ 之上正式引入 DARE Harness layer，并首先只提供一个官方 profile：

• coding

即：

• 保留 DARE Core 作为稳定、可插拔、面向开发者的 runtime framework
• 新增 DARE Coding Harness 作为第一方默认运行环境

4.1 核心判断

当前阶段最合理的产品化方向，不是继续优先扩展更多 tool / MCP / sub-agent，而是先把以下能力变成默认闭环：

1. 默认 event log
2. 默认 checkpoint / resume
3. 默认 session summary
4. 默认 security boundary + approval memory
5. 默认 deterministic step execution
6. 默认 context lifecycle policy

这六项能力共同定义了 2026 语境下的 harness。

---

5. Goals

5.1 Primary Goals

1. 在不破坏 DARE Core 可插拔架构的前提下，提供第一方官方默认 harness。
2. 让一次默认 run 具备完整的 audit / resume / approval / replay 基础设施。
3. 让 validated plan 在适用场景下成为 deterministic execution 的真实输入。
4. 让 Context 从“消息容器”升级为“上下文生命周期管理器”。
5. 让 CLI 演进为 operator control plane。

5.2 Secondary Goals

1. 降低 examples 与真实运行 profile 的偏差。
2. 为未来 regulated profile 打基础，但不在当前阶段一次性做满。
3. 为 eval、replay、failure analysis、未来训练数据沉淀提供稳定事件面。

---

6. Non-Goals

本提案当前明确不做以下事情：

1. 不把 DARE 从 framework 改写成单一产品。
2. 不在当前阶段优先实现分布式多租户 orchestration。
3. 不一次性引入银行级远端 WORM 存储后端。
4. 不以新增更多 tool / MCP provider 作为本提案的主要价值。
5. 不强制所有任务都使用 step_driven。

---

7. Architectural Positioning

7.1 Layering

建议将系统逻辑上划分为两层：

Layer A. DARE Core

职责：

• 提供 domain model、kernel interface、builder、default impl
• 保持高可插拔性
• 面向框架开发者和高级装配者

包含但不限于：

• agent
• context
• tool
• plan
• security
• event
• hook
• observability
• config
• memory
• knowledge
• mcp

Layer B. DARE Harness

职责：

• 提供 profile 化默认 wiring
• 统一 runtime state layout
• 提供 operator control plane
• 将 durability / auditability / resume / replay 变成默认能力

建议新增目录：

dare_framework/harness/
├── builder.py
├── defaults.py
├── profile.py
├── runtime_state.py
├── replay.py
└── control_plane.py

7.2 Relationship

flowchart TB
  A["DARE Core"] --> B["DARE Coding Harness"]
  B --> C["CLI / API / Examples"]

  subgraph Core["DARE Core"]
    C1["Agent"]
    C2["Plan"]
    C3["Tool"]
    C4["Context"]
    C5["Security"]
    C6["Event"]
    C7["Hook / Telemetry"]
  end

  subgraph Harness["DARE Coding Harness"]
    H1["Default Wiring"]
    H2["Runtime State Layout"]
    H3["Checkpoint / Replay"]
    H4["Operator Control Plane"]
    H5["Profile Policy"]
  end

Loading

---

8. Why Start With a Coding Harness

虽然项目上下文中包含银行/金融、多 agent 协作等愿景，但从当前仓库成熟度看，最自然、最可落地的第一方 harness 方向仍然是：

• 本地工作区
• 文件与命令工具
• MCP 工具接入
• approval memory
• 可验证 coding task

原因：

1. 当前 examples 已明显以 coding agent 为主线。
2. 当前 tool、approval、workspace boundary 都天然服务 coding 场景。
3. coding harness 最容易形成 replay、failure corpus 和 deterministic eval。
4. 在 coding harness 跑通后，再派生更严格的 regulated profile 会更稳。

因此本提案建议：

• 先交付 coding profile
• 后续再考虑 regulated / workflow / multi-agent profile

---

9. Target Architecture

9.1 Runtime View

flowchart TB
  U["User / CLI / API"] --> CP["Operator Control Plane"]
  CP --> H["DARE Coding Harness"]

  H --> ORCH["Session + Milestone Orchestrator"]
  H --> EVT["Default Event Log"]
  H --> CHK["Checkpoint Store"]
  H --> SUM["Session Summary Store"]
  H --> REP["Replay / Resume Engine"]

  ORCH --> CTX["Context Lifecycle Manager"]
  ORCH --> SEC["Trust / Policy / Approval Boundary"]
  ORCH --> PLAN["Planner / Validator / Step Executor"]
  ORCH --> TOOLS["Tool Gateway / MCP / Skills"]
  ORCH --> OBS["Hooks / Telemetry"]

Loading

9.2 Key Harness Responsibilities

Harness 层必须默认承担以下职责：

1. 为一次 run 创建稳定的 runtime identity
2. 记录关键事件并形成可校验的审计链
3. 维护 checkpoint、summary、resume/replay 所需状态
4. 根据 profile 决定 execution mode
5. 统一配置 context lifecycle policy
6. 向 CLI 暴露 inspection、approval、resume、replay、audit 能力

---

10. Default coding Profile

10.1 Profile Definition

coding profile 是第一方默认 harness profile，面向：

• coding task
• repository-level task execution
• workspace-bound tools
• approval-aware command execution
• 需要 replay / summary / milestone verification 的任务

10.2 Enabled by Default

coding profile 默认开启：

1. event_log
2. approval_memory
3. policy_security_boundary
4. checkpoint_store
5. session_summary_store
6. context_policy = coding_default
7. execution_mode = auto

10.3 Runtime State Layout

建议统一使用以下目录布局：

.dare/runtime/
├── events.sqlite
├── checkpoints/
├── session_summaries/
├── replay_cache/
└── metadata.json

说明：

• events.sqlite：默认 event log
• checkpoints/：执行控制与中断恢复
• session_summaries/：run summary 与阶段摘要
• replay_cache/：可选，加速 replay/view
• metadata.json：当前 profile、版本、schema 信息

---

11. Event Log as a First-Class Default

11.1 Decision

默认 event log 必须成为 harness 的基础设施，而不是显式可选依赖。

11.2 Rationale

没有默认 event log，就无法让以下能力成为默认保障：

• replay
• verify-chain
• run inspection
• fault analysis
• approval trace
• milestone-level audit

11.3 Requirements

默认 event log 至少必须支持：

1. append
2. query
3. replay
4. verify_chain

默认后端建议：

• sqlite + hash-chain

11.4 Payload Contract

关键事件 payload 应统一稳定字段：

• task_id
• run_id
• session_id
• milestone_id（如适用）
• conversation_id（如适用）
• _trace（如可用）
• event_version

payload 的序列化口径必须固定，以保证：

• query 行为稳定
• replay 行为可预期
• hash-chain 计算可重现

---

12. Checkpoint, Resume, and Session Summary

12.1 Decision

checkpoint 与 session summary 不应继续分散存在于局部 internal helper 中，而应提升为 harness 的正式组成部分。

12.2 Requirements

Harness 默认必须支持：

1. 创建 checkpoint
2. 查询 checkpoint
3. 从 checkpoint 恢复
4. 在 run 结束后写出 session summary
5. 在必要时从 session summary 辅助恢复上下文

12.3 State Model

建议最小恢复单元包含：

• run_id
• task_id
• execution_mode
• current_milestone_idx
• validated_plan_ref 或 step progress
• context_ref
• checkpoint_time

12.4 Resume Semantics

恢复语义建议分三种：

1. manual
   • 用户显式执行 resume
2. approval_resolved
   • 审批通过后恢复挂起 run
3. crash_recovery
   • 未来能力，当前阶段可保留接口

---

13. Execution Model

13.1 Modes

建议将 execution mode 正式定义为：

• model_driven
• step_driven
• auto

13.2 Semantics

model_driven

适用于：

• 轻任务
• 开放式探索任务
• 无 validated steps 的任务

行为：

• 保持当前由模型决定工具调用的兼容逻辑

step_driven

适用于：

• validated plan 已存在
• 需要 deterministic replay
• 高风险或高审计任务

行为：

• 只执行 validated steps
• 顺序执行
• step failure 终止后续 step

auto

建议新增，并作为 coding profile 默认值。

规则：

1. 若无 validated plan，走 model_driven
2. 若 validated plan 含可执行 steps，优先 step_driven
3. 若 step path 不可用，则显式记录回退原因并退回 model_driven

13.3 Why auto

auto 是最实用的默认值，因为它同时满足：

• 向后兼容
• 不阻塞当前 examples
• 推动系统逐步转向 deterministic execution

---

14. Context Lifecycle Policy

14.1 Decision

默认 Context 不应仅是 STM 容器，而应演进为“上下文生命周期管理器”。

14.2 Default coding_default Strategy

建议 first-party 默认策略名为：

• coding_default

默认职责：

1. 保留最近交互与用户硬约束
2. 折叠过大的 tool output
3. 在 assemble 前做预算检查
4. 在需要时融合 LTM / Knowledge
5. 产出带 provenance 的 metadata

14.3 Assemble Pipeline

flowchart TD
  A["Build query from latest intent"] --> B["Read STM window"]
  A --> C["Retrieve LTM"]
  A --> D["Retrieve Knowledge"]
  B --> E["Normalize candidates"]
  C --> E
  D --> E
  E --> F["Dedup + rank + budget allocation"]
  F --> G["Compress if needed"]
  G --> H["Emit AssembledContext + metadata"]

Loading

14.4 Required Metadata

默认 AssembledContext.metadata 至少应包含：

• context_id
• tool_snapshot_hash
• retrieval.query
• retrieval.ltm_count
• retrieval.knowledge_count
• compression.before_estimate
• compression.after_estimate
• compression.strategies_applied

14.5 Tool Output Folding

对于大 tool output，默认策略应优先：

1. 保留结构化结论
2. 提取关键证据
3. 折叠原始长输出

而不是将原始日志无限写入 STM。

---

15. Operator Control Plane

15.1 Decision

CLI 必须从“发任务入口”升级为“operator control plane”。

15.2 Current Foundation

当前 CLI 已具备良好基础：

• approvals:*
• mcp:*
• run/chat/script

本提案建议在此基础上正式补齐 harness 级命令。

15.3 Proposed Commands

建议新增或强化以下命令：

1. runs list
   • 查看最近 run
2. runs show <run_id>
   • 查看某次 run 的 milestones、summary、状态
3. replay <run_id>
   • 重放最小运行轨迹
4. resume <run_id|checkpoint_id>
   • 从挂起状态恢复
5. checkpoints list
   • 查看待恢复 checkpoint
6. audit verify-chain
   • 校验 event log hash-chain

15.4 Control Plane Boundary

Operator control plane 应只做：

• 查询
• 授权
• 恢复
• 审计
• 运行态控制

而不直接承担业务逻辑编排。

---

16. Configuration Model

16.1 Problem

当前 Config 已具备 hooks、security、workspace_dir、user_dir 等字段，但缺少明确 typed harness config。

16.2 Proposal

建议新增 typed config：

• HarnessConfig
• EventLogConfig
• CheckpointConfig
• SessionSummaryConfig
• ExecutionConfig
• ContextPolicyConfig

16.3 Example

{
  "harness": {
    "profile": "coding",
    "execution_mode": "auto",
    "resume_policy": "manual",
    "event_log": {
      "enabled": true,
      "backend": "sqlite",
      "path": ".dare/runtime/events.sqlite",
      "verify_chain_on_start": true
    },
    "checkpoints": {
      "enabled": true,
      "dir": ".dare/runtime/checkpoints"
    },
    "session_summary": {
      "enabled": true,
      "dir": ".dare/runtime/session_summaries"
    },
    "context_policy": {
      "strategy": "coding_default",
      "max_stm_messages": 40,
      "enable_ltm": true,
      "enable_knowledge": true,
      "summarize_large_tool_output": true
    }
  }
}

16.4 Compatibility Rule

兼容规则建议如下：

1. 若无 harness 配置，系统保持当前行为
2. 若配置 harness.profile = coding，自动启用默认 wiring
3. 显式 builder 注入始终优先于 profile 默认值

---

17. Proposed Public API

17.1 New Builder

建议新增第一方 builder：

agent = await (
    CodingHarnessBuilder("coding-agent")
    .with_config(config)
    .build()
)

17.2 Builder Semantics

CodingHarnessBuilder 本质上应复用 DareAgentBuilder，但自动完成：

1. 默认 event log 装配
2. 默认 approval manager 装配
3. 默认 security boundary 装配
4. 默认 execution control 装配
5. 默认 session summary store 装配
6. 默认 context policy 装配
7. execution mode 解析

17.3 Escape Hatch

保留 escape hatch：

• 任何显式注入都覆盖 harness 默认值
• 原有 DareAgentBuilder 保持可用

这样可以避免 harness 层过度侵入 core API。

---

18. Implementation Plan

建议分四个阶段推进。

Phase A: Default Durability

目标：

• 建立默认事件链和状态目录

交付：

1. SQLiteEventLog
2. verify_chain
3. replay
4. builder 默认 event log 装配
5. runtime state dir layout

完成标志：

• 在无显式注入 event log 的情况下，run 仍可产出完整审计链

Phase B: Deterministic Execution

目标：

• 让 validated plan 真正进入可信执行路径

交付：

1. builder 支持 execution_mode
2. 默认 step_executor / evidence_collector 装配
3. 新增 auto mode
4. step-driven 集成测试

完成标志：

• validated steps 可按顺序 deterministic 执行并可回放

Phase C: Context Lifecycle

目标：

• 让 context 成为生命周期管理器

交付：

1. coding_default context policy
2. assemble/compress 标准策略
3. provenance metadata
4. tool output folding
5. milestone summary 接线

完成标志：

• 可解释本次 assemble 的来源与压缩行为

Phase D: Operator Plane

目标：

• 让 CLI 成为真正运行控制面

交付：

1. runs list/show
2. replay
3. resume
4. checkpoints list
5. audit verify-chain

完成标志：

• operator 可在不读底层文件的情况下观察和控制 harness

---

19. Acceptance Criteria

本提案的验收标准以“默认运行行为”而不是“实现数量”为准。

19.1 Runtime Defaults

1. 用户使用第一方 harness builder 即可获得默认 event log。
2. 默认 run 会产出稳定的 session.* / milestone.* / plan.* / tool.* / security.* 事件链。
3. 默认 event log 可执行 verify_chain()。

19.2 Deterministic Execution

1. 在 step_driven 模式下，validated steps 必须顺序执行。
2. step failure 必须阻止后续 step 执行。
3. 在 auto 模式下，有 validated steps 时优先选择 deterministic path。

19.3 Resume / Replay

1. 审批挂起后 run 可恢复。
2. checkpoint 可被列出并恢复。
3. replay 可输出最小运行快照。

19.4 Context Lifecycle

1. assemble metadata 能解释上下文来源。
2. 大 tool output 不再无约束堆积到 STM。
3. 预算与压缩行为可观测。

19.5 Operator Plane

1. CLI 能查看 runs、checkpoints、approval 状态。
2. CLI 能发起 replay 与 resume。
3. CLI 能进行 audit chain 校验。

---

20. Risks and Trade-offs

20.1 Increased Default Complexity

风险：

• 默认 wiring 增加后，系统显得更重

缓解：

• 将复杂度主要放在 harness 层，而非污染 core domain

20.2 SQLite Is Not Final WORM

风险：

• sqlite + hash-chain 不能等同于最终合规级 WORM

缓解：

• 当前阶段先满足单机本地 durability
• 远端不可变存储后端后续单独演进

20.3 step_driven May Reduce Flexibility

风险：

• 对开放任务而言，deterministic execution 可能过于刚性

缓解：

• 保留 model_driven
• 以 auto 为默认，不一刀切

20.4 Context Policy Can Overreach

风险：

• 过早抽象多种 context policy 可能造成复杂度膨胀

缓解：

• 第一阶段只支持一个第一方 coding_default

---

21. Open Questions

以下问题建议在后续 design 阶段进一步细化：

1. replay(from_event_id) 的最小快照是否需要包含 context summary 与 budget snapshot
2. session_summary 与 milestone summary 的边界如何定义
3. approval resolved 后恢复粒度是 tool-level 还是 milestone-level
4. auto mode 的回退原因是否要显式写入 event log
5. context provenance metadata 是否需要哈希化以支持更强 replay 对齐

---

22. Recommended Next Step

建议以本提案为基础，创建正式 OpenSpec change：

• change name: add-coding-harness-profile

并以该 change 作为以下现有方向的收敛上层：

1. p0-default-eventlog
2. p0-step-driven-execution

推荐后续产物顺序：

1. proposal.md
2. design.md
3. tasks.md
4. delta specs

---

23. Final Position

本提案的最终结论是：

对当前仓库而言，下一阶段最重要的不是继续扩展更多 agent 能力，而是把现有内核能力收敛成一个默认可靠的 DARE Coding Harness。

其核心标准不是“模型更聪明”，而是：

• 默认有状态
• 默认可审计
• 默认可审批
• 默认可恢复
• 默认可回放
• validated plan 可以驱动执行

只有当这些能力成为默认运行闭环时，DARE 才真正从“强大的 runtime framework”进一步迈向“成熟的 2026 agent harness”。

[zts212653]

Feedback to DARE Coding Harness Proposal

From: Cat Café Team (布偶猫宪宪)
Date: 2026-03-02
Context: 三路 Deep Research + GPT-5.2 Pro 审阅 + Cat Café 多猫协作实践

---

TL;DR

你们的核心判断完全正确：2026 年 Harness > Model，"默认有状态、可审计、可审批、可恢复、可回放"是企业级 Agent 的 table stakes。

我们基于业界调研和实践，提供以下补充建议，希望能帮助你们把 Proposal 从"正确的方向"推进到"可落地的规范"。

---

1. 建议补充的能力维度

1.1 副作用契约（Side-Effect Contracts）

问题：Proposal 强调 event log 和 replay，但对"外部系统副作用"的处理不够显式。

Event Sourcing 能让内部状态可回放，但：

• 发出去的邮件不能撤回
• 第三方 API 写入可能不可逆
• 资金划拨需要补偿事务

建议：在 Harness 层显式定义副作用契约：

@side_effect(
    idempotent=True,           # 幂等保证
    reversible="compensate",   # 可逆策略：compensate / draft-first / none
    approval_required=True,    # 是否需要人审
    audit_level="evidence"     # 审计级别：log / audit / evidence
)
def send_payment(account_id: str, amount: Decimal) -> PaymentResult:
    ...

参考：GPT 报告提到的 OpenPort Protocol (arXiv 2026-02-22) 把 draft-first、幂等、reason codes 写成了协议语义。

1.2 Multi-Agent 协作原语

问题：Proposal 聚焦单 Agent 的 Harness，但 A2A 协议已进入 Linux Foundation。

建议：在 Harness 层预留多 Agent 协作的扩展点：

class HarnessConfig:
    # 单 Agent 能力
    event_log: EventLogConfig
    checkpoint: CheckpointConfig

    # 多 Agent 扩展（可选）
    identity: AgentIdentityConfig      # 身份声明
    collaboration: CollaborationConfig  # 协作协议
    handoff: HandoffConfig              # 任务交接

实践参考：Cat Café 的多猫协作已经跑了几个月，核心发现是"身份契约"比"能力发现"更重要——先确定"谁是谁、谁能做什么、谁批准谁"，再谈互操作。

1.3 Context Provenance（上下文溯源）

问题：Proposal 的 Context Lifecycle 强调压缩和 LTM 融合，但缺少"来源标注"。

风险：当 context 来自多个来源（STM、LTM、Knowledge、外部检索），agent 可能混淆权威度，导致用公开网页内容覆盖内部机密文档的判断。

建议：在 AssembledContext.metadata 中加入 provenance：

@dataclass
class ContextChunk:
    content: str
    provenance: Provenance

@dataclass
class Provenance:
    source_type: Literal["stm", "ltm", "knowledge", "retrieval", "user_input"]
    source_id: str
    timestamp: datetime
    trust_level: Literal["internal", "external", "unverified"]
    retrieval_query: Optional[str]  # 如果是检索来的

参考：FDA 2026-01 发布的 AI 药物开发指导原则明确要求"数据溯源（Provenance）"，这可能成为 regulated 行业的合规要求。

---

2. 实施建议

2.1 step_driven 的边界条件

Proposal 当前描述：

"若 validated plan 含可执行 steps，优先 step_driven"

潜在问题：

• 什么算"可执行 step"？
• step 失败后的回退策略？
• step 执行过程中环境变化（TOCTOU）怎么处理？

建议：显式定义 step 的契约：

@dataclass
class ValidatedStep:
    action: str
    preconditions: List[Condition]   # 执行前必须满足
    postconditions: List[Condition]  # 执行后必须满足
    rollback: Optional[RollbackStrategy]  # 失败时的回退
    idempotency_key: str             # 幂等键

2.2 Event Log 的 payload 稳定性

Proposal 当前描述：

"payload 的序列化口径必须固定，以保证 query/replay/hash-chain 可重现"

建议补充：

• 定义 payload schema 版本策略（如何升级 schema？）
• 定义敏感数据 redaction 规则（哪些字段不能进不可变日志？）
• 定义 retention 策略（多久后可以归档/删除？）

实践参考：OpenTelemetry GenAI semantic conventions 正在标准化 agent 事件语义，建议对齐。

2.3 auto mode 的决策透明度

Proposal 当前描述：

"若 step path 不可用，则显式记录回退原因并退回 model_driven"

建议强化：把 mode 决策本身也作为 event 记录：

@dataclass
class ExecutionModeDecision(Event):
    chosen_mode: Literal["model_driven", "step_driven"]
    reason: str
    fallback_from: Optional[str]  # 如果是回退，从哪里回退
    validated_plan_ref: Optional[str]

这样审计时可以回答："为什么这次用了 model_driven 而不是 step_driven？"

---

3. 风险提醒

3.1 "确定性"的定义混用

我们的审阅发现业界对 "deterministic" 有三种不同理解：

1. 编排确定：workflow 可回放，但 LLM 调用仍非确定
2. 治理确定：稳定的失败语义、前后置条件、审批链
3. 物理确定：轨迹缓存，把成功路径固化成脚本

建议在 Proposal 中明确你们指的是哪一种，避免用户误解。

3.2 SQLite 的局限性

Proposal 当前：

"默认后端建议：sqlite + hash-chain"

潜在问题：

• SQLite 单机写入瓶颈
• 跨实例共享需要额外设计
• 在 regulated 场景可能不被接受为 WORM

建议：

• 明确 SQLite 是"开发/单机默认"
• 定义抽象接口，允许替换为 PostgreSQL / S3 / 专用 WORM
• 在 Proposal 中说明"生产级后端"的演进路径

3.3 "Undo AI" 的复杂度

Gemini 报告提到 Veeam/Securiti 的 Agent Commander 把"精确撤销"做成产品。

风险：如果 Harness 承诺"可撤销"但实际只能撤销内部状态，用户会有预期落差。

建议：在 Proposal 中明确"可撤销"的边界：

• 哪些操作可完全撤销？
• 哪些操作只能"尽力而为"？
• 哪些操作不可撤销？

---

4. 来自 Cat Café 的实践经验

4.1 人审是设计原语，不是可选功能

我们的 F049 Mission Hub 把人审做成了任务调度的核心：

建议领取 → 铲屎官批准 → 自动创建执行 thread

经验：不要把 human-in-the-loop 当成"高级功能"，而是从第一天就把它设计成系统的一部分。企业用户对"AI 自动做了什么"非常敏感。

4.2 跨 Agent Review 比自检更重要

我们的 Review 流程强制要求"跨家族 peer review"——布偶猫写的代码必须让缅因猫 review，不能自己 review 自己。

经验：如果你们的 Harness 支持多 Agent，建议把"不同 Agent 不能互相批准自己"写成默认策略。

4.3 Skill/SOP 是流程约束的载体

你们提到 AWS Strands Agent SOPs，我们的 Skills 系统类似但更进一步：

• 不只是"步骤指南"，而是"流程约束 + 决策树 + 验证清单"
• 每个 Skill 都有显式的"触发条件"和"输出契约"

建议：考虑在 Harness 层定义 Skill/SOP 的元模型，让流程约束可配置、可版本化、可审计。

---

5. 总结

维度	Proposal 现状	建议
核心判断	✅ 正确	保持
副作用契约	未显式	补充
Multi-Agent	未覆盖	预留扩展点
Context Provenance	部分	强化
确定性定义	可能混用	明确
人审原语	有提及	升级为核心

一句话：Proposal 的方向完全正确，建议在"副作用契约"和"Multi-Agent 预留"上加强，同时明确"确定性"的具体含义。

---

祝 DARE 团队顺利！期待看到 Coding Harness 落地。🐱

— Cat Café Team