合并最新 Agent 编排基线
合并 origin/master 的 Agent Runtime 编排依赖与测试门禁 恢复 platform-agent 的任务图校验与动态编排实现 为后续 AGC Router 流程调试提供可启动的最新基线
This commit is contained in:
@@ -16,6 +16,20 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-26 运行中自主扩图提案留在编排层
|
||||
|
||||
- 背景：`agent-runtime-orchestration` 已能构造和调度动态 DAG，但 LLM 在执行中发现缺少步骤时没有通用的安全扩图合同。
|
||||
- 决策：新增严格 serde 的 `GraphProposal`（`TaskProposal` + `GraphEdge`）和 `GraphLimits`，由 `TaskGraph::apply_proposal` / `expand_with_proposal` 在内存中构造不可变候选图；新节点默认 `Pending`，边方向为前置 `from` → 依赖方 `to`。
|
||||
- 安全与一致性：所有 Agent、端点、重复引用、环、节点/边/深度/扇出预算在候选返回前一次校验；边只能指向新节点，禁止给已运行任务原地追加依赖。任一失败保留旧图。成功后的 epoch、基图版本、proposal 幂等和持久化由宿主负责，crate 不调用 LLM/Provider/ToolHost/Runner，也不写 `.agent/runtime/**`。
|
||||
- 验证：非游戏 conformance 覆盖有效扩图、ready/wave 重算、未知 Agent/端点、重复边、已有任务修改、环、预算、严格 JSON 和原子失败；关联文档为 `docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md` V1.55。
|
||||
|
||||
## 2026-08-26 通用多 Agent DAG 编排与执行内核分层
|
||||
|
||||
- 背景：`agent-runtime-core` 已承接 catalog、run/action 生命周期、lane、宿主 ToolHost、spawn/all-join 和 Provider 契约，但动态任务图的 ready 选择、依赖波次与返工下游闭包仍混在 `platform-agent::game_creation`，其它产品无法复用且非法环会被合并成伪 wave。
|
||||
- 决策：新增纯 Rust `agent-runtime-orchestration`，依赖方向固定为 `agent-runtime-orchestration -> agent-runtime-core`。公共层只持有任务 ID、Agent ID、通用状态和依赖边，统一负责构图校验、ready、active/satisfied 波次、下游闭包和全量/返工选择；动态构图仍必须是 DAG，跨轮循环通过新的 pass / epoch 表达。
|
||||
- 产品边界：16 个游戏任务、六组角色、产物/验收条件、Evaluator Markdown 和中文语义路由继续留在 `platform-agent`；AGC 组合根使用公共层校验任务图与 `AgentCatalog`。Runtime store、Runner、Provider、权限、ToolHost、委派 journal、isolated write scope 和 `.agent/runtime/**` 不迁移、不双写。
|
||||
- 验证方式：非游戏 conformance 覆盖并行分支、汇合、repair closure、AgentCatalog 和非法图失败关闭；`platform-agent` 锁定种子 DAG 与现役波次/返工顺序，并验证环拒绝和 catalog 注入。根检查脚本必须执行新 crate 测试。
|
||||
- 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md` V1.54。
|
||||
## 2026-08-27 `plan.submit_gdd` 拒绝无审批决定的 `user_revision`
|
||||
|
||||
- 背景：结构校验允许 `round=0 + user_revision + confirmed`，提交闸原先只做结构、身份和 Session CAS。Provider 可在首次 collecting、澄清续跑或提交前质量返工里把未确认项标成用户审批修改，审批卡显示「已确认」。
|
||||
|
||||
@@ -62,4 +62,4 @@ SpacetimeDB 任务统一先读取 `.codex/skills/genarrative-spacetimedb/SKILL.m
|
||||
|
||||
## Gitea CI 依赖闭合
|
||||
|
||||
`.gitea/workflows/project-ci.yml` 的 `Native shell tests` 在运行原生壳门禁前，必须使用 `cargo fetch --locked` 预取 `server-rs/Cargo.toml`、桌面壳和 AGC 壳三份依赖。AGC 壳检查还会运行 `platform-llm` 与 `shared-contracts` 的 server-rs workspace 测试，这些命令以及 AGC 壳测试必须带 `--locked`，避免在测试阶段重新解析 registry index；锁文件发生变化时应先更新受信任 CI 镜像缓存，再重跑门禁。
|
||||
`.gitea/workflows/project-ci.yml` 的 `Native shell tests` 在运行原生壳门禁前，必须使用 `cargo fetch --locked` 预取 `server-rs/Cargo.toml`、桌面壳和 AGC 壳三份依赖。Backend host workspace tests 使用 `cargo test --locked --workspace --exclude spacetime-module --no-fail-fast`，避免 `spacetime-module` 的 `spacetime-types` feature 统一污染普通领域 crate 的 host 测试；随后单独执行 `cargo test --locked -p spacetime-module --no-fail-fast`，由 `spacetime-module/src/active.rs` 在 host 测试构建期间提供仅测试期的 SpacetimeDB ABI 链接支持，使该 crate 的纯单元测试也纳入 Backend 门禁。`spacetime-module` 的 reducer / procedure 运行时行为仍必须通过真实 SpacetimeDB runtime/integration harness 验证，host 链接支持不得被当作运行时替身。Backend 另外执行 `cargo check --locked -p spacetime-module` 验证模块源码。AGC 壳检查还会运行 `platform-llm` 与 `shared-contracts` 的 server-rs workspace 测试，这些命令以及 AGC 壳测试必须带 `--locked`，避免在测试阶段重新解析 registry index；锁文件发生变化时应先更新受信任 CI 镜像缓存，再重跑门禁。
|
||||
|
||||
@@ -51,6 +51,7 @@ SpacetimeDB crate、SDK、CLI / standalone 与生成 bindings 按 `2.8.3` 对齐
|
||||
|
||||
## AGC DirectProject 与 UI workflow
|
||||
|
||||
- 通用 Agent Rust 分层为 `agent-runtime-core`（catalog、执行生命周期、ToolHost/spawn/all-join/Provider 契约）、`agent-runtime-orchestration`（动态无环任务图、ready、依赖波次、返工下游闭包和受限自主扩图提案）与 `platform-agent` 游戏适配器；循环返工通过新 pass / epoch 表达，不在单张依赖图中建立回边。LLM 可经宿主结构化 function call 提出新增节点/边，编排层只生成经校验的新候选图，epoch 与持久化仍由宿主掌控。
|
||||
- DirectProject 只连接客户端内置的 `agc_tools` STDIO MCP。它负责审核引用读取、标准美术准备、已登记资源有界查询、视频 / 角色动画 / 音效 / BGM 的 create-or-derive、已登记图片去背景、desktop/mobile 浏览器试玩和受控 `agc_web_search`；付费资源调用由客户端绑定回合、幂等账本、请求上限和投影权威。
|
||||
- DirectProject 的 Codex 原生文件、搜索、命令、图片查看和 Skill 仅在真实 `game/` cwd 与 `workspaceWrite(writableRoots=[game])` 内可用；原生命令网络保持关闭。多 Agent、Apps、插件、hooks、图片生成、Goals、Workspace Dependencies、Tool Suggestion 和原生浏览器/电脑控制保持关闭。app-server 使用隔离 `CODEX_HOME`，provider 凭据只由 AGC 客户端代理持有，不能进入模型上下文或 shell 环境。
|
||||
- `ui-prototype`（设计图片）与 UI 编辑器 `UI` JSON 是不同资源。白名单 `ui.workflow.run` 按页面执行 `prepare → recognize → status → finalize`，由 provider-backed 识别、合并和组件绑定持久化 State/revision，并把 `reference-ready → structure-ready → merge-ready → binding-ready → application-ready → completed` 投影到 manifest。Provider 缺失、请求失败、工具缺失、结果不匹配或仍有待审节点时保留真实阶段并返回 blocker，不得用 deterministic seed 伪造完成。
|
||||
|
||||
@@ -1651,6 +1651,58 @@ V1.53 把根 Project Supervisor 的 same-run steer 从“收到消息立即中
|
||||
- LLM 判定、解析或持久化失败时写入关联的非终态 fallback 回复，保持当前任务运行，并在下一安全边界应用已排队 steer；失败不能退回“默认中断”。判定与回复按 `agentId / runId / steerId` 幂等，冲突终态失败关闭。
|
||||
- 验收必须覆盖判定 LLM 的 `true / false` 协议、公开回复幂等、入队本身不中断、`runtime.steer` 有活动 Provider 时仍不中断、缺失 decision 拒绝条件中断、`false` decision 不中断、`true` decision 只中断旧 cursor，以及判定失败后同一 run 继续。
|
||||
|
||||
## V1.54 通用多 Agent DAG 编排 crate
|
||||
|
||||
V1.48-V1.50 已把 catalog、执行生命周期与 Provider 契约收进 `agent-runtime-core`，但动态任务图的 ready 选择、依赖波次和返工下游闭包仍编译在 `platform-agent::game_creation`。V1.54 新增独立 `server-rs/crates/agent-runtime-orchestration`（package name `agent-runtime-orchestration`），作为 `agent-runtime-core` 上方的纯 Rust 编排层；它不复制 Runtime store、Runner、Provider、ToolHost、delegation journal、权限或产品持久文件。
|
||||
|
||||
### 图模型与无环合同
|
||||
|
||||
- 公共层只保存任务 ID、执行 Agent ID、通用状态和依赖边，不保存游戏组别、角色文案、产物路径、Evaluator Markdown 或中文关键词。任务在运行时注册，因此“动态 DAG”表示宿主可以按目标或 pass 动态构图与重规划，不表示依赖边可以形成环。
|
||||
- 构图一次性失败关闭：拒绝空或非法 ID、重复任务、重复依赖、未知依赖、自依赖和任意有向环，并保持任务注册顺序作为所有确定性输出的稳定顺序。环内没有可证明的首个 ready 节点，也无法给 completion、重放和下游失效定义单调顺序；需要迭代时由宿主建立新的 pass / epoch，并显式携带上一轮结果，不在同一依赖图里回边。
|
||||
- 编排层提供 pending ready 选择、active/satisfied 依赖波次、指定任务的下游影响闭包和全量/返工选择计划。active 任务依赖的非 active 节点必须显式位于 satisfied 集合；缺失前置不能按“图外即完成”静默放行。
|
||||
- 每个任务携带 `agentId`，并可对 V1.48 `AgentCatalog` 做引用校验；未知 Agent 在创建任何 run 或调用宿主前失败关闭。crate 依赖方向固定为 `agent-runtime-orchestration -> agent-runtime-core`，依赖闭包只使用标准库与 `serde / serde_json`，不得反向依赖 AGC、Tauri、`platform-agent` 或 `platform-llm`。
|
||||
|
||||
### AGC 生产适配与兼容
|
||||
|
||||
- `platform-agent` 继续拥有 16 个游戏任务、六组枚举、标题/角色/产物/验收条件、Evaluator Markdown 解析和游戏关键词路由；它把现有 `GameCreationTaskGraph` 映射为公共任务图，并由公共层计算 ready、dependency waves 和 repair downstream closure。
|
||||
- `GameCreationTaskGraph`、`GameCreationAgentPassPlan` 的 serde 字段、种子任务、有效 DAG 的顺序与现役 `.agent/passes/pass-N/task-graph.json` 输出保持不变。构图或计划函数改为显式返回错误，非法环、未知依赖或不完整 partition 不再合并成一个伪 wave。
|
||||
- AGC 的现役 Agent catalog 构造同时用公共编排层校验 16 个任务的 Agent 引用，证明新 crate 已进入生产组合根。isolated child 的项目路径、write scope、证据和深度限制仍是 AGC 工具/策略合同；通用 spawn/all-join 继续由 `agent-runtime-core` 执行，本轮不再造第二套委派协议。
|
||||
|
||||
### V1.54 验收
|
||||
|
||||
- 新 crate 的非游戏 conformance fixture 在运行时构造并行分支与汇合节点，覆盖稳定 ready 集合、依赖波次、返工下游闭包、AgentCatalog 引用，以及重复/未知/自依赖/有环/缺失 satisfied 的失败关闭；fixture 不得出现游戏任务名、AGC 路径或 Tauri 类型。
|
||||
- `platform-agent` 回归锁定 16 任务种子图、首轮全量波次、结构化返工和下游扩展的现有顺序，并增加非法游戏图不会进入计划的负向用例；AGC adapter 回归锁定 catalog 与任务图一致。
|
||||
- 根脚本增加 `agent-runtime-orchestration:check`，并纳入 `ai-game-creator-shell:check`。完成后至少运行新 crate、`platform-agent`、AGC adapter/生成编排定向测试、Tauri `cargo check --tests`、依赖树、`npm run check:encoding` 和 `git diff --check`；独立 crate 产生的本地 `Cargo.lock/target` 不进入提交。
|
||||
|
||||
### V1.54 本轮验证记录（2026-08-26）
|
||||
|
||||
- 已通过：`agent-runtime-core` 20 项、`agent-runtime-orchestration` 5 项、`platform-agent` 19 项；新 crate 依赖树仅引入 `agent-runtime-core` 与 `serde`（测试专用 `serde_json`），`cargo fmt --check`、`npm run check:encoding` 和 `git diff --check` 均通过。
|
||||
- 已通过：AGC 任务图与注入 `AgentCatalog` 的一致性测试、非法环失败关闭、反序列化重复依赖失败关闭；测试产生的独立 crate `Cargo.lock/target` 已清理。
|
||||
- 未完成：Tauri `cargo check --tests` 已编译到 AGC 自定义 `build.rs`，随后因仓库四个候选路径均缺少内置 Codex CLI vendor 资源而退出（`build.rs:77`）；本轮未执行 `npm ci`，因此不能将 Tauri 组合根或完整 `ai-game-creator-shell:check` 记为通过。
|
||||
- 未执行：当前 Rust 1.96 工具链未安装 `clippy` component；没有把该静态检查结果用其它门禁结果替代。
|
||||
|
||||
## V1.55 运行中自主扩图提案
|
||||
|
||||
V1.54 的公共编排层可以在运行前构造动态 DAG，但 LLM 在执行过程中发现缺少步骤时还没有一个通用、受限的扩图入口。V1.55 在同一 `agent-runtime-orchestration` crate 增加结构化 `GraphProposal`，让宿主能够把 LLM 的 function-call arguments 解析为候选节点和边，并在不改变 `agent-runtime-core` 执行职责的前提下生成下一张图。
|
||||
|
||||
### 提案 DTO 与宿主边界
|
||||
|
||||
- `GraphProposal` 只包含 `nodes` 与 `edges`。节点使用 `{ id, agentId }`，边使用 `{ from, to }`；`from` 是前置任务，`to` 是依赖它的任务。DTO 使用 `camelCase` 且拒绝未知字段，节点和边的稳定标识沿用公共图模型约束。
|
||||
- `TaskGraph::apply_proposal` / `expand_with_proposal` 是纯校验与候选构造 API：不调用 LLM、Provider、ToolHost、Runner 或持久化。宿主负责声明 function tool、把 arguments 反序列化为 `GraphProposal`，并在成功后把返回的候选图写入自己的新 epoch。
|
||||
- 新节点统一以 `Pending` 加入，并保留现有任务状态和注册顺序。提案边必须指向本次新增节点；不允许在运行中的旧任务上原地追加前置依赖。若业务确实要改旧边，宿主应构造完整候选图并按自己的 CAS/epoch 合同一次替换。
|
||||
|
||||
### 原子校验与预算
|
||||
|
||||
- 候选图只有在所有检查通过后才返回；未知 Agent、未知端点、重复节点/边、自依赖、有向环和已有节点依赖修改都会失败，原图保持不变。
|
||||
- `GraphLimits` 同时限制完整候选图的 `maxTasks`、`maxEdges`、`maxDepth`（根层计 1）和 `maxOutDegree`（一个前置任务的直接下游数）。默认值为 `128 / 512 / 32 / 32`；超限不截断、不部分提交。
|
||||
- 成功扩图后，宿主必须把它视为新的 graph/epoch，重新计算 ready task 与 dependency waves，并在自己的持久层记录提案身份、基图版本和幂等结果。crate 不把 epoch、proposal ID 或执行事实写入图，也不自动重放 Provider。
|
||||
|
||||
### V1.55 验收
|
||||
|
||||
- 非游戏 conformance 覆盖有效新增节点/边、全部新节点 `Pending`、ready/wave 重算、未知 Agent、未知端点、重复边、已有任务修改、环、节点/边/深度/扇出预算和失败原子性。
|
||||
- 覆盖 `GraphProposal`、`GraphEdge`、`GraphLimits` 与 `TaskGraph` 的严格 JSON round-trip；未知字段、非法标识和零预算均失败关闭。
|
||||
- 真实 LLM 接入仍由宿主后续提供；本切片证明了宿主可在一个结构化 function call 回合中安全生成候选新图，但不把 provider 请求或持久化当作 crate 的事实源。
|
||||
|
||||
## 验收命令
|
||||
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml structured_plan_ -- --nocapture`
|
||||
|
||||
@@ -1,5 +1,11 @@
|
||||
# AI 游戏创作智能体 App 实施计划
|
||||
|
||||
## 2026-08-26 运行中自主扩图提案
|
||||
|
||||
- `agent-runtime-orchestration` 提供严格 serde 的 `GraphProposal`、`TaskProposal`、`GraphEdge` 与 `GraphLimits`。宿主可把 LLM function-call arguments 解析后交给 `TaskGraph::apply_proposal`，在内存中得到新的、完整校验过的候选 DAG。
|
||||
- 新节点默认 `Pending`；边使用 `from`（前置）→ `to`（依赖方），且新增边只能指向本次新增节点。未知 Agent/端点、重复节点/边、自依赖、有向环和节点/边/深度/扇出预算超限整次失败，旧图不变。
|
||||
- crate 不调用 Provider、Runner、ToolHost 或持久化；宿主负责 function tool 暴露、基图/epoch CAS、proposal 幂等、落盘和重新调度 ready/dependency waves。修改既有任务依赖时必须由宿主构造完整候选图并切换新 epoch。
|
||||
|
||||
## 2026-08-25 账户 / 项目画布 / 本地素材导入
|
||||
|
||||
- 素材读取区分三类来源：`asset.list` / `agc_list_registered_assets` 是当前项目本地 manifest，`agc_list_project_files` / `file.list` 只发现项目目录中实际存在但可能未登记的文件，`asset.library.list` 是当前登录账号素材库，项目画布资源读取是当前网页项目/画布的完整图片清单；账户素材库不能替代项目画布清单。
|
||||
|
||||
@@ -264,7 +264,7 @@ npm run check
|
||||
|
||||
- `Repository checks`：调用唯一入口 `npm run check:repository-ci`，执行 `npm run lint`、AI 游戏创作壳 AppSurface 定向测试、主站与后台生产构建和提交差异空白检查。本地 master `pre-push` 复用同一入口，禁止在 workflow 与 hook 中维护两份近似命令。
|
||||
- `Frontend tests`：按唯一根 workspace lockfile 执行一次干净的 `npm ci`，再独立执行根 `npm run test`、`npm run bgfilter-worker:smoke-test`、`npm run check:production-health-patrol`、`npm run check:production-api-release` 和 `npm run check:production-api-deploy`，让 Vitest、Node test smoke harness 及不依赖真实服务的生产巡检 / 发布 / 部署行为 fixture 在 Gitea job 中持续执行；其中 `.test.mjs` 使用 Node test runner，不依赖 Vitest 的 `scripts/**/*.test.ts` 收集规则。
|
||||
- `Backend tests`：先对 `server-rs/Cargo.lock` 执行带 5 次整命令级有界重试的 `cargo fetch --locked`，再执行 `npm run check:server-rs-ddd`、`cargo test --locked --workspace --no-fail-fast`、`api-server --all-targets` 编译和 `spacetime-module` 编译；依赖准备必须位于会触发 Cargo build 的 DDD / 产物边界门禁之前，避免锁新增依赖未命中镜像缓存时绕过既有下载重试。runner 安装 `ffmpeg`，避免视频抽帧测试因工具缺失提前返回。依赖真实服务或密钥的测试必须显式 `ignored`，不能让普通 PR job访问现场环境。
|
||||
- `Backend tests`：先对 `server-rs/Cargo.lock` 执行带 5 次整命令级有界重试的 `cargo fetch --locked`，再执行 `npm run check:server-rs-ddd`、`cargo test --locked --workspace --exclude spacetime-module --no-fail-fast`、`cargo test --locked -p spacetime-module --no-fail-fast`、`api-server --all-targets` 编译和 `cargo check --locked -p spacetime-module`；普通 workspace host 测试排除 `spacetime-module` 以避免其 `spacetime-types` feature 统一污染领域 crate，模块自身的纯单元测试通过独立 package test 纳入门禁。`spacetime-module` 的 reducer / procedure 运行时行为仍必须通过真实 SpacetimeDB runtime/integration harness 验证，不能把 host 链接支持当作运行时替身。依赖准备必须位于会触发 Cargo build 的 DDD / 产物边界门禁之前，避免锁新增依赖未命中镜像缓存时绕过既有下载重试。runner 安装 `ffmpeg`，避免视频抽帧测试因工具缺失提前返回。依赖真实服务或密钥的测试必须显式 `ignored`，不能让普通 PR job访问现场环境。
|
||||
- `Native shell tests`：按唯一根 workspace lockfile 安装全部 App 依赖后执行 `npm run check:native-shells`，对所有触发方式一致覆盖微信壳、Expo 和 Tauri 的完整验收，并执行 `npm run ai-game-creator-shell:check` 与 AI 游戏创作壳 release build smoke；最后确认桌面壳与 AI 游戏创作壳的 `Cargo.lock` 都没有被构建过程改写。共享 Agent Runtime 后台锁 suite 固定 `--test-threads=1`，不能用并行偶发失败后的逐项通过替代整套稳定门禁。
|
||||
|
||||
四个 job 合起来覆盖根 `npm run check`，并补齐根检查没有包含的 BgFilter worker smoke harness、无密钥生产巡检 / 发布 / 部署行为 fixture、server-rs DDD、正式 workspace Rust 测试与现役后端编译门禁。普通 PR CI 不注入业务密钥，不启动真实 API、SpacetimeDB、OSS、支付、图片生成或生产 live smoke；需要现场环境、可变外部状态、Docker 编排或发布凭据的 `check:*` 继续按对应专题和 Jenkins 发布流程执行，不能遍历所有同名前缀脚本冒充 PR 门禁。
|
||||
|
||||
Reference in New Issue
Block a user