完善Agent多动作批次持久化
新增Provider多动作整批预检、确认聚合和稳定cursor恢复 修复修改后验证门禁、Agent DB落盘顺序和Goal恢复cursor回退 补齐批次恢复、拒绝、并行、故障与最终收束回归测试 同步Runtime V1.28技术方案和项目决策记录
This commit is contained in:
@@ -1087,13 +1087,22 @@ repair 深度固定为 `1`;同一原 delivery 同时最多存在一个非 `sup
|
||||
- Supervisor prompt 必须明确:不得把 `evidence-ready` 当作自动语义通过,不得忽略或吞掉 `needs-repair`;对无法自行裁决的冲突、缺失决策或用户偏好,只能汇总后通过既有 `user.input_request` 向用户提问,专业 Agent 与 child 不得各自直达用户。
|
||||
- finalization 在项目锁内必须确认所有必要 static delivery 已终态、ready 已认领、claim 已 Observed、允许的单次 repair 已收束;同时要求结构化计划全部完成,并清零 verification、pending confirmation、`user.input_request`、process/reconciliation、isolated join、Goal/steer 等既有 blocker。只有原 `project-supervisor` Session/run 可以随后写入唯一正式用户 assistant 和 completed 投影。
|
||||
|
||||
### Provider 多 action 原批次门禁
|
||||
|
||||
为了让 Supervisor 在同一原生 planning 中提交两个专业委派,同时保持确认顺序和崩溃恢复,Provider 一轮返回 `2-3` 个 action 时必须先建立私有 durable action batch,再允许任何成员产生工具副作用。批次绑定 project、Agent、task、Session、run、loop、steer cursor、完整计划、项目 revision、仓库上下文指纹及全部稳定 actionId;不能在恢复时重新请求 Provider 或重建新身份。
|
||||
|
||||
- Runtime 必须先对整批 action 完成本地策略和 MCP policy preflight。任一成员被拒绝时整批进入 `aborted`,所有成员保持零工具执行,只投影一份稳定拒绝 observation;存在确认成员时整批进入 `waiting-confirmation`,收集完全部精确确认之前,位于确认动作前后的 auto 成员都不得执行。
|
||||
- 全部确认完成后批次进入 `ready`,从 `nextActionIndex=0` 按 Provider 顺序执行。连续安全只读成员仍可复用 V1.27 parallel-read batch;两个 `agent.delegate` 虽按顺序完成 durable dispatch,但 child lane 可在第二个 dispatch 后并行运行。任一成员返回非 `ok`、same-run steer 或仓库上下文漂移时,剩余后缀先持久标记为 `superseded`,不得继续执行。
|
||||
- cursor 只能在成员的 observation、公共投影、receipt、Agent DB 和 context bundle 全部持久化后推进。Runner 重启必须分别恢复缺失的 confirmation sidecar、尚未首次 dispatch 的 `ready` 批次,以及“cursor 已推进但 observed pending 尚未删除”的窗口;相同 actionId 的恢复只补缺失投影,不增加物理副作用、receipt 或 action event。
|
||||
- `waiting-confirmation / ready / aborted / superseded / completed` sidecar 未完成幂等收束前,空 action 完成分支和 finalization 都必须由 `runtime.provider_action_batch` blocker 阻断。Goal pause/resume 不得把 `ready` 批次降级成普通 `planning`,而要保留原 loop、steer 与 action cursor 并投影 `provider-action-batch`。
|
||||
|
||||
### 验收口径
|
||||
|
||||
确定性测试至少覆盖 strict native schema、路径与数量边界、旧 action 空合同恢复且 sidecar 字节不迁移、合同字段跨 Runner 重启保持、客观 `evidence-ready / needs-repair` 判定、artifact SHA-256、verificationRequired、claim 快照、语义不自动通过、单层 repair、同原 delivery 并发 repair 幂等/拒绝、repair 后 final barrier,以及专业 Agent/child 无用户 assistant。
|
||||
|
||||
真实 `gpt-5.5` swarm 验收必须在无固定工具顺序和修复配方的任务中,由同一 `project-supervisor` 父 run 并行委派两个专业 Agent;其中一份弱交付必须形成可解释的 `needs-repair` 或被 Supervisor 判为语义不满足,并恰好触发一次 repair。验收期间强杀并重启 Runner,证明合同、delivery/claim/repair 身份和原父 Session/run 不丢失;最终正式用户 conversation 只有一条由 `project-supervisor` 写入的 assistant。全量 task/event/action/delivery/claim/receipt/conversation/Provider lifecycle 交叉检查必须得到重复 action、receipt、message 均为 `0`,且凭据、私有正文、绝对路径、诱饵和 Provider payload 泄漏均为 `0`。
|
||||
|
||||
2026-07-16 本地确定性回归已完成当前实现切片:`project_supervisor_` 30/30 PASS,另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、规范字段和别名的显式空合同执行器拒绝,以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS,覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试,但本轮尚未完成强杀验收。
|
||||
2026-07-16 本地确定性回归已完成当前实现切片:`project_supervisor_` 30/30、`provider_action_batch_` 12/12、`parallel_read_batch_` 8/8、终态 receipt reconciliation 1/1 PASS,另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、多 action 整批预检、零副作用拒绝、确认聚合、修改后验证 gate 滚动、稳定 cursor 恢复、Agent DB 终态先于 cursor 推进、steer 作废后缀及 Goal resume 不回退 cursor、规范字段和别名的显式空合同执行器拒绝,以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 280/280 PASS,覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试,但本轮尚未完成强杀验收。
|
||||
|
||||
同日真实 Provider 验收未通过。第一次隔离运行的测试驱动误把多行任务拆成多个 steer,不能作为并行结论;修正为单条输入并移除逐个确认后,正式 `openai_chat / gpt-5.5` 在 Supervisor 首轮 planning 即返回 transport failure,尚未创建 delivery。此前那次较长运行也以同类 transport failure 终止,且只形成一个专业委派。因此当前没有“双专业 Agent 真并行、一次弱交付恰好一次 repair、Runner 强杀恢复、唯一最终回复”的真实证据,不得记录 V1.28 PASS。
|
||||
|
||||
@@ -1104,6 +1113,7 @@ repair 深度固定为 `1`;同一原 delivery 同时最多存在一个非 `sup
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml goal_context_bundle_v4_migrates_v3_and_v2_then_rejects_plan_mismatch -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml response_stream_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml mcp_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml provider_action_batch_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml parallel_read_batch_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml swarm_cli::tests -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml typed_goal_pause_and_cancel_require_durable_intent_and_keep_exact_run -- --nocapture`
|
||||
|
||||
Reference in New Issue
Block a user