Agent 负责执行，谁来决定任务真的完成？

从一个修改请求开始

假设用户要求修改一个共享接口。实现者提交了补丁，并表示测试通过，但 Reviewer 发现调用方还依赖旧字段。此时有三种不同事实：实现者交卷了，验证材料产生了，任务还没有满足完成条件。把三者压缩成一个“成功”会丢掉返工与验收依据。

Harness 的设计目标是让这些判断不再散落在对话里：请求先形成明确的任务与工作流，角色按受限 WorkOrder 工作，返回结果经过契约校验，再由控制层推进。本文例子是阅读场景，不是本次执行记录。¹

小接口承接完整控制职责

CLI 与 MCP 面向同一个 Kernel，设计接口只有两个方法：

interface Harness {
  execute(command: HarnessCommand): Promise<CommandResult>;
  watch(taskId: TaskId, after?: EventCursor): AsyncIterable<HarnessEvent>;
}

这是架构契约摘录，不是可以单独运行的程序。execute 接收结构化命令，watch 观察事件；宿主不需要知道工作流文件怎样解析、租约怎样保存，或另一个执行器使用哪些命令行参数。¹

取舍是把较多规则集中到一个深模块，而不是让每个宿主各写一遍。成本是 Kernel 必须承担真正的状态与策略实现，不能只转发调用；收益是切换宿主不需要更换任务语义。

事件是事实，文档是投影

任务目录里有 brief.md、decisions.md、evidence.md、handoff.md、state.yaml 与 events.jsonl。它们并不是六份同等权威的状态。事件账本保存机械历史，快照与中文任务文档由已接受的事件形成；手改 state.yaml 不能代替一个合法状态转换。²

accepted command
  -> version-checked event append
  -> task snapshot
  -> brief / evidence / handoff / delivery projections

文件系统实现从账本重建状态，内存实现也走同一投影契约。相比只保留最终快照，这增加了事件设计、存储与回放成本，却能解释“为何停在这里”，并为另一个宿主提供恢复依据。它没有把文件系统变成分布式任务队列。

权限来自用户，不来自角色自述

自然语言分类可以提出任务画像，但安全资格与授权由确定性规则判断。ActionIntent 明确动作、目标、效果、数据类别和请求范围；外部写入要求确认，破坏性效果在默认策略下阻断。任务级与项目级设置不能放宽全局不可变规则。¹³

MCP 服务器固定宿主身份，工具参数不能自报更高权限的 actor。审批、Skill 信任审核，以及暂停、取消、需求调整等用户控制命令留在本地 CLI，不暴露为模型可调用的授权入口。发现 Skill 也不等于信任它；新增能力或外部写权限需要重新审核。⁴

这牺牲了一部分“全自动”的便利。选择接受人工确认，是因为模型提出的操作建议与用户授予的执行权不能互相替代。

独立评审不是多开一个相同上下文

低风险局部修改可以走 engineering_fast。高风险工作流则区分 Generator、Adversarial Reviewer 与 Judge：实现者写隔离 worktree，评审者与裁决者只读，首次评审上下文默认不包含实现者的自我解释和完整聊天。¹

Reviewer 的问题需要位置、主张、证据与验证方法；Judge 要对问题给出接受、拒绝或需要更多证据的判断。独立性来自权限与输入组织，不只是不同角色名称。代价是更多轮次和上下文准备，因此并非每个小改动都强制走完整对抗流程。

完成与应用补丁是两道门

DeliveryPackage.ready 表示交付包满足完成契约，不授予 apply、commit、push、开 PR 或合并权限。这些动作重新形成精确意图；审批之后工作区或补丁变化，也不能继续沿用过期确认。²⁵

回到开场例子：共享接口仍有高风险问题时，不能因为实现者已经输出代码而标记完成；预算耗尽时应保留已完成工作与剩余风险。即便评审最终通过，应用补丁与对外推送仍是独立动作。

执行顺序见技术页，失败与恢复断言见实验验证，版本变化见迭代记录。

来源与范围

本文固定在 1f2270eaa31ba099837375bfcdfd162c8f31f1b9，按架构、契约和匹配实现解释。V1 的设计环境是个人 macOS 与 Node.js 20；不把本网站所在 Linux 环境当作上游平台支持证据。本次未运行 Harness 上游测试、安装器或真实宿主 smoke。