lhk229 15c0d6f028 修通澄清信封被收束门禁拦死的活锁,并给最终回复重试加兜底
策划子 Agent 每轮都在正确地吐 AGC_NEEDS_USER_INPUT_V1 信封(header 带主题、
三选项齐全),却被拒了 26 次,一条生产 run 空转 65 轮直到人工介入。

信封是通过 respond_to_user 交付的,走最终回复通道,于是撞上两道「计划必须全部
完成」的判据:
- runtime_state.rs 收束链首位的 structured_plan_completion_blocker
- runtime_protocol/finalization.rs 上「finalization 必须绑定已全部完成的计划
  快照」这条 journal 持久不变量(第二道,是上面那条测试逼出来的)

而计划里「按用户决定收敛并提交」那一步在用户答之前永远不可能 completed:想问
用户就得先 respond_to_user,问不出去就答不了。对任何含「答完之后再做 X」步骤的
计划,这条判据都不可满足。

以前没炸靠两件偶然:策划子 Agent 不提交结构化计划(判据第一行就跳过),或者
提交了之后肯把没做的步骤标成 completed。翻了同机全部历史 run:4 条没提交计划、
2 条首版 3/4 改成 4/4 放行、这条首版 1/4 之后再没改过——就死了。

修法是判据豁免而不是代填步骤状态:澄清信封是本 run 挂起等用户答,剩余步骤归
用户答复后的 continuation run,把它们标成 completed 是伪造进度。豁免只放行
「计划未完成」这一件事,快照自身的结构合法性仍然逐项校验,其余 blocker 照常。

第二件:最终回复被拦下后 run 原地续跑重试,此前没有任何上限。空转闸只认裸
update_agent_plan,而这里模型每轮都在认真调 respond_to_user,没有任何计数器会
累加。新增 stale_finalization_rounds(持久 Runtime state,与
plan_submit_gdd_rejection_count / plan_update_idle_rounds 同一模式,重启不能把
活锁洗成新的无限 Provider 开销),上限 32——刻意留在两道软闸之上,让自愈路径
先有机会起作用。真实推进后清零。

守门两条:
- 同一份未完成计划,普通交付收束必须被拦(blocker.tool=runtime.plan_update)、
  澄清信封必须放行。两半都实测非空转:撤掉任一处豁免,对应那半立刻红。
- 兜底额度必须高于两道软闸,防止有人把它调到软闸以下抢跑自愈。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 10:08:44 +00:00
2026-08-25 15:41:55 +08:00
2026-08-25 12:36:51 +08:00
2026-08-25 15:41:55 +08:00
2026-06-13 16:22:18 +08:00
2026-08-25 15:41:55 +08:00
2026-07-17 22:07:52 +08:00
2026-08-21 12:20:43 +08:00
2026-08-25 16:08:54 +08:00
2026-08-25 15:41:55 +08:00
2026-08-24 21:44:44 +08:00
2026-04-26 18:06:23 +08:00
2026-07-07 14:04:08 +08:00
2026-07-16 18:33:06 +08:00
2026-08-21 15:07:29 +08:00
2026-05-08 17:58:33 +08:00
2026-08-10 20:14:30 +08:00
2026-07-08 17:35:45 +08:00
2026-07-17 22:07:52 +08:00
1
2026-05-14 14:21:17 +08:00
2026-08-25 16:08:54 +08:00
2026-08-25 15:41:55 +08:00

Genarrative / 陶泥儿

一个 AI 原生互动内容与小游戏平台,当前主站聚焦图片画布创作、项目与素材管理,以及账号、钱包和后台管理等平台公共能力。

当前已经具备这些主要能力:

  • 图片画布编辑、项目与素材管理
  • 图片、视频、音频等外部生成任务
  • 账号、钱包、充值、兑换码与个人资料
  • 后台运营、配置与生产运维工具
  • AI 游戏创作独立 App

运行

前置条件:

  • Node.js
  • Rust / Cargo
  • SpacetimeDB CLI

安装依赖:

npm install

该命令会按根 package.json 的 npm workspaces 一次安装主站、Admin、Mobile、Desktop、AGC、Preview Deployer、内部 packages 与工具依赖;仓库只使用根 package-lock.json,不要在子目录单独执行 npm install / npm ci 或提交嵌套 lockfile。

准备环境变量:

  • 复制 .env.example.env.local
  • 只填写本次联调所需配置;不要提交 .env.local、密钥、Token 或其它本地认证信息
  • api-server 环境变量和 Provider 配置以 .env.example 及当前开发运维文档为准

启动开发环境:

npm run dev

补充说明:

  • npm run dev 会启动 SpacetimeDB standalone、独立 bgfilter-worker、Rust api-server、主站 Vite 与后台 Vite,适合完整联调;内部 worker ready 后才启动 API。
  • 主站默认地址是 http://127.0.0.1:3000,后台可从 http://127.0.0.1:3000/admin/ 进入,也可直连 http://127.0.0.1:3102
  • 五个模块可独立启动:npm run dev:spacetimenpm run dev:api-servernpm run dev:bgfilter-workernpm run dev:webnpm run dev:admin-web;其中 dev:api-server 会安全带起同 runner 的 BgFilter worker 依赖。
  • 如需自动刷新后端模块,使用 npm run dev -- --watch;其中 spacetime-module 改动后只会重新发布模块,不会重启 standalone,Rust 源码改动会把 api-serverbgfilter-worker 作为一个组合单元重启。主站和后台前端源码变化交给 Vite 自身 HMR,不由外层 watcher 重启。非 watch 模式下可在 npm run dev 终端输入 rs api-serverrs bgfilter-workerrs webrs admin-webrs spacetimers all,其中 rs spacetime 也是只重新发布模块。

构建生产包:

npm run build

常用检查

类型检查:

npm run lint

编码检查:

npm run check:encoding

主要结构

主运行时:

创作与项目能力:

文档入口

docs/ 已在 2026-05-15 完成压缩整理,旧 PRD、设计、审计、阶段计划和技术流水账不再作为实现依据。当前只读取:

S
Description
叙世
Readme 785 MiB
Languages
Rust 56.1%
TypeScript 24.4%
JavaScript 9.9%
Java 3.7%
Go 3.1%
Other 2.6%