darkmice

验收优先的 Agent 交付系统

证据： Case Study · Clean-room Demo · 公开产品界面

English · 全部案例

问题

Agent 给出一个看起来合理的答案，不等于软件已经交付。真实交付还需要持久化任务状态、可恢复执行、可见产物、独立验证，以及由人或策略掌握的最终决定权，而不能由写代码的 Agent 自己宣布完成。

系统边界

会话 / 项目目标
      │
      ▼
持久化派工账本 ─────► 依赖与定时调度器
      │                      │
      ▼                      ▼
本地执行节点 ◄─────── 执行器能力协议
      │
      ├────► 产物与文件变更证据
      └────► 运行事件与失败信号
                         │
                         ▼
                    独立验证门
                         │
                  接受 / 驳回 / 重试

控制面负责目标、派工状态、重试和验收；执行节点负责用户工作区，并适配可用的 Coding Agent。验证器只消费结果，不能静默改写任务定义。

关键决策与取舍

• 会话作为统一入口。 人的指令、Agent 工作、产物和验收留在一条可追溯链路里；代价是必须建立明确的事件协议。
• 持久化派工，而不是内存任务。 断线、重试和恢复都可以解释；代价是状态机更复杂。
• 按能力适配执行器。 产品语义保持稳定，底层 Coding Agent 可以变化；同时不能为了统一而丢掉供应商原生事件的重要差异。
• 把验收独立成门。 不从“最终回复”或单次测试变绿推断完成，必须由声明过的检查与证据决定。

把失败路径当成产品行为

失败	系统必须怎么做
执行中连接断开	重新连接同一派工，不能重复创建任务。
Worker 心跳消失	让租约过期、保留账本，并清晰显示重试状态。
Agent 说“已完成”但没有产物	交付门保持未通过。
验证器失败	保留日志和失败证据，重试不能覆盖历史。
用户新增约束	记录约束，只对后续工作生效。

读者可以公开核验什么

• Studio 公开仓库展示产品侧指挥台工作。
• Evidence Lab用假数据和独立实现演示派工、依赖、重试、人工干预、证据与验收状态机。
• 生产实现、内部表结构和运行数据仍为私有；这里不会把它们伪装成开源证据。

这个案例展示的能力

跨人与 Agent 的产品定义、持久化编排、协议设计、本地与云的责任边界、失败状态体验，以及基于证据的验收。