简体
仅保留 CRUMB 标志中的面包角色：右上角被咬了一口、面带微笑的吐司
返回展厅

CRUMB

Generative Game Studio · Demo

从一句话游戏构想到可玩的初稿，智能体的工作全程可见、可随时介入。

CRUMB 是用于休闲游戏原型制作的多智能体工作室执行框架。

设计与开发 · 借助 AI 编程智能体构建

  • CLI本地演示
  • Web Studio本地演示

构建游戏的智能体，与判定它的依据分开。

一个本地工作室演示，把一句话游戏构想经由规格、构建和执行检查贯穿下来。每一步都写入 JSONL transcript，纯 reducer 决定下一步效果，只有 dispatcher 执行副作用。执行 QA 与模型判定分开，以决定通过、重新设计、修复还是人工引导。

用一句话提出游戏构想，Claude Code、Codex 和 Gemini CLI 智能体便按 Planner → Builder → 确定性 QA → Verifier 协作，CRUMB Studio 则显示事件、进度和产物，并接受自然语言介入。

从公开仓库克隆并在本地运行的演示。

系统结构图 · 依据公开提交 f5e17c0 的代码路径绘制
CRUMB 工作室系统人在 Studio 中提出游戏构想并进行引导，Studio 将命令写入 inbox。coordinator 按顺序把 inbox 和 transcript 中的新事件交给 reducer；纯 reducer 决定状态和下一步效果，只有 dispatcher 执行副作用。Planner 的规格、Builder 的构建与产物、执行 QA 的结果以及 Verifier 的判定，都成为 transcript 事件。Verifier 只接收投影后的证据，reducer 依据 QA 结果检查并更正其分数：PASS 结束会话，PARTIAL 等待人确认，其余则退回重新设计或修复。游戏构想 · 引导在本地使用的人packages/studio事件 · 产物视图写入 inbox 命令src/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.ts事件循环 · replay · tailsrc/reducer状态 → 下一步效果判定路由session done完成 · PASS 或停止原因src/dispatcher/live.ts执行效果 · spawn actor评判输入投影model-config · presetactor → 执行框架 · 模型agent actor · CLIPlanner Lead · 规格Builder · 编写游戏artifacts/游戏文件dispatcher/qa-runner.ts执行 QA · 检查Verifier actorVerifier · 模型判定src/validator防欺骗 · 分数更正人 · Studio事件控制transcript 是状态的来源工作智能体 · 产物验证 · 决定1构想 · 引导2user 事件3按顺序 reduce4效果5actor 设置6运行 Planner7spec8运行 Builder9文件10构建记录11qa_check12运行对象13qa.result1qa.result2仅投影证据3评判输入4judge.score5分数 · QA 证据6更正后的判定7完成1更正后的判定2PARTIAL 确认3重新设计 · 修复4完成5构想 · 引导1新事件 · replay2按顺序 reduce3读取 · SSE

从构想到可玩

构想依次成为规格、构建和一次执行 QA。每一步都经过 transcript；actor 之间不互相调用。

  1. 游戏构想 · 引导构想 · 引导写入 inbox 命令packages/studio

    在 Studio 中输入一句话游戏构想和自然语言引导，Studio 将命令写入 inbox。Studio 从不直接编辑 transcript。

  2. 写入 inbox 命令packages/studiouser 事件事件循环 · replay · tailsrc/loop/coordinator.ts

    coordinator 读取 inbox 命令，并作为 user 事件记录到 transcript。

  3. 事件循环 · replay · tailsrc/loop/coordinator.ts按顺序 reduce状态 → 下一步效果src/reducer

    实时事件从队列中逐个 reduce，保持每个事件的效果顺序；分派本身异步运行。

  4. 状态 → 下一步效果src/reducer效果执行效果 · spawn actorsrc/dispatcher/live.ts

    reducer 是纯函数，只决定状态和下一步效果：goal 选中 Planner，spec 选中 Builder，build 选中 qa_check。

  5. actor → 执行框架 · 模型model-config · presetactor 设置src/dispatcher/live.ts

    由哪个执行框架、提供商和模型运行 actor，按 CLI 标志 > 配置 > 预设 > ambient > 回退的顺序解析。actor 并不固定于某个提供商。

  6. 执行效果 · spawn actorsrc/dispatcher/live.ts运行 PlannerPlanner Lead · 规格agent actor · CLI

    dispatcher 以投影后的输入运行 Planner。条件性调研经由 Planner 的调研计划和证据交接继续进行，本图中已将其折叠。

  7. Planner Lead · 规格agent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    Planner 的规格成为 transcript 事件，reducer 据此选中 Builder。actor 之间不互相调用。

  8. 执行效果 · spawn actorsrc/dispatcher/live.ts运行 BuilderBuilder · 编写游戏agent actor · CLI

    dispatcher 运行 Builder。若同一 actor 持续失败，circuit 打开并更换 adapter；若仍然失败则停止。

  9. Builder · 编写游戏agent actor · CLI文件游戏文件artifacts/

    Builder 将入口文件、源码和资源作为产物写出。

  10. Builder · 编写游戏agent actor · CLI构建记录transcript.jsonl · append-onlysrc/transcript

    build 事件和 artifact.created 连同产物的 identity 记录在 transcript 中。

  11. 执行效果 · spawn actorsrc/dispatcher/live.tsqa_check执行 QA · 检查dispatcher/qa-runner.ts

    build 事件之后，reducer 发出一个携带产物与构建 identity 以及验收条件的 qa_check 效果，由 dispatcher 执行。

  12. 游戏文件artifacts/运行对象执行 QA · 检查dispatcher/qa-runner.ts

    执行 QA 以代码和浏览器检查运行实际产物。默认超时 120 秒是配置值。

  13. 执行 QA · 检查dispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    无论成功还是失败，结果都记录为 system qa.result 事件。即使检查抛出异常，也会记录包含失败字段的结果。

验证的信任边界

执行 QA 是实际运行产物得到的证据；Verifier 是依据投影证据作判断的模型。reducer 先调和两者，再选择下一条路径。

  1. 执行 QA · 检查dispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    无论成功还是失败，结果都记录为 system qa.result 事件。即使检查抛出异常，也会记录包含失败字段的结果。

  2. transcript.jsonl · append-onlysrc/transcript仅投影证据评判输入投影src/dispatcher/live.ts

    Verifier 的输入由最新的 goal、spec、build、qa.result 和 artifact.created，加上选定的调研证据投影而成。这只是收窄上下文，并不证明隔离或没有泄漏。

  3. 评判输入投影src/dispatcher/live.ts评判输入Verifier · 模型判定Verifier actor

    dispatcher 以投影后的输入运行 Verifier。

  4. Verifier · 模型判定Verifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Verifier 的判定记录为 judge.score 事件。这是模型的判断，不是关于执行的事实。

  5. 状态 → 下一步效果src/reducer分数 · QA 证据防欺骗 · 分数更正src/validator

    收到 judge.score 时，reducer 将其与 QA 结果、Builder 的提供商以及调研计划和证据一起交给防欺骗检查。

  6. 防欺骗 · 分数更正src/validator更正后的判定判定路由src/reducer

    没有成功执行的 PASS 会改为 FAIL，与执行相关的分数依据确定性 QA 更正。其他规则是有条件的更正，并不普遍证明真实性。

  7. 判定路由src/reducer完成完成 · PASS 或停止原因session done

    PASS 以 done 结束会话。因预算或 circuit 停止的也以 done 结束，但保留停止原因，因此 done 并不总是 PASS。

失败与人工引导

PARTIAL 交给人，Critical 进入重新设计，Important 或 Minor 进入修复，因预算或 circuit 停止时留下停止原因。

  1. 防欺骗 · 分数更正src/validator更正后的判定判定路由src/reducer

    没有成功执行的 PASS 会改为 FAIL，与执行相关的分数依据确定性 QA 更正。其他规则是有条件的更正，并不普遍证明真实性。

  2. 判定路由src/reducerPARTIAL 确认游戏构想 · 引导

    PARTIAL 等待人来确认。

  3. 判定路由src/reducer重新设计 · 修复src/dispatcher/live.ts

    在 FAIL 和 REJECT 中，Critical 退回 Planner 重新设计，Important 或 Minor 作为修复反馈交给 Builder，均作为 dispatcher 效果执行。

  4. 判定路由src/reducer完成完成 · PASS 或停止原因session done

    PASS 以 done 结束会话。因预算或 circuit 停止的也以 done 结束，但保留停止原因，因此 done 并不总是 PASS。

  5. 游戏构想 · 引导构想 · 引导写入 inbox 命令packages/studio

    在 Studio 中输入一句话游戏构想和自然语言引导，Studio 将命令写入 inbox。Studio 从不直接编辑 transcript。

重放与观测

从 transcript 重建状态时不执行任何效果，Studio 读取同一份记录进行展示。

  1. transcript.jsonl · append-onlysrc/transcript新事件 · replay事件循环 · replay · tailsrc/loop/coordinator.ts

    writer 校验 schema，分配 ULID 和时间，然后追加写入。重放时，过去的事件只经过 reduce，不再执行其效果。

  2. 事件循环 · replay · tailsrc/loop/coordinator.ts按顺序 reduce状态 → 下一步效果src/reducer

    实时事件从队列中逐个 reduce，保持每个事件的效果顺序；分派本身异步运行。

  3. transcript.jsonl · append-onlysrc/transcript读取 · SSE事件 · 产物视图packages/studio

    Studio 读取 transcript 和产物，并通过 SSE 显示进度、指标和产物。这不是发送到远程服务的遥测。

所有连接以相同粗细显示。选择一个流程，即只突出显示其路径，并标出步骤编号。

  • 实线 · 输入、结果与记录的流向
  • 虚线 · 运行、判定、请求
  • 长点线 · 观测与报告，独立于判定
  • 粗黑线 · 所选流程；数字表示顺序
  • 方框 · 代码或状态边界，标题栏注明名称
  • 内层小框 · 该边界中的组件
  • 点线框 · 该边界之外
  • 橙色轮廓 · 模型作出判断之处
  • 事件循环 · reducer · dispatcher
  • 记录 · 配置 · 产物
  • 确定性检查 · 校正
  • Studio · actor

依据公开提交 f5e17c0 的代码路径绘制。actor 是运行时中的执行角色，与构建本仓库所用的编程智能体不同。

状态的来源
transcript 是状态的来源，reducer 是纯函数。只有 dispatcher 执行副作用（运行 actor、QA、写入文件），因此回放只重建状态，不产生副作用。
回放的范围
回放得到的是相同的状态，并不会让 LLM 的生成或浏览器与网络的行为变得确定。
判定的范围
执行 QA 只检查已配置的检查项，Verifier 的分数只是依据的一个来源。两者都不衡量游戏的全部行为、趣味性或用户满意度。