TH
ตัวละครขนมปังจากโลโก้ CRUMB เพียงตัวเดียว: ขนมปังแผ่นยิ้มแย้มที่ถูกกัดไปหนึ่งคำที่มุมขวาบน
กลับไปที่ห้องจัดแสดง

CRUMB

Generative Game Studio · Demo

จากไอเดียเกมหนึ่งบรรทัดสู่ร่างที่เล่นได้ โดยเห็นงานของเอเจนต์และแทรกแซงได้

CRUMB คือฮาร์เนสสตูดิโอแบบหลายเอเจนต์สำหรับสร้างต้นแบบเกมแคชวล เสนอเกมในหนึ่งบรรทัด แล้วเอเจนต์ Claude Code, Codex และ Gemini CLI จะทำงานร่วมกันผ่าน Planner → Builder → QA เชิงกำหนด → Verifier ขณะที่ CRUMB Studio แสดงอีเวนต์ ความคืบหน้า และผลงาน และรับการแทรกแซงด้วยภาษาธรรมชาติ

ออกแบบและพัฒนา · สร้างด้วยเอเจนต์เขียนโค้ด AI

  • CLIเดโมในเครื่อง
  • Studio บนเว็บเดโมในเครื่อง

เอเจนต์ที่สร้างเกม แยกจากหลักฐานที่ตัดสินมัน

เดโมสตูดิโอในเครื่องที่นำไอเดียเกมหนึ่งบรรทัดผ่าน spec บิลด์ และการตรวจการรัน ทุกขั้นลงใน transcript JSONL reducer บริสุทธิ์ตัดสินผลกระทบถัดไป และมีเพียง dispatcher ที่ทำผลข้างเคียง QA การรันและคำตัดสินของโมเดลถูกแยกกันเพื่อตัดสินระหว่างผ่าน ออกแบบใหม่ ซ่อม และการกำกับโดยคน

เดโมที่โคลนจากรีโพซิทอรีสาธารณะแล้วรันในเครื่อง

แผนที่ระบบ · วาดจากเส้นทางโค้ดที่คอมมิตสาธารณะ f5e17c0
ระบบสตูดิโอ CRUMBคนเสนอและกำกับเกมจาก Studio และ Studio เขียนคำสั่งลง inbox coordinator ส่งอีเวนต์ใหม่จาก inbox และ transcript ให้ reducer ตามลำดับ reducer บริสุทธิ์ตัดสินสถานะและผลกระทบถัดไป และมีเพียง dispatcher ที่ทำผลข้างเคียง spec ของ Planner บิลด์และผลงานของ Builder ผล QA การรัน และการตัดสินของ Verifier ล้วนกลายเป็นอีเวนต์ใน transcript Verifier ได้รับเพียงหลักฐานที่ฉายมา และ reducer ตรวจและแก้คะแนนเทียบกับผล QA: PASS จบเซสชัน PARTIAL รอคน และที่เหลือกลับไปออกแบบใหม่หรือซ่อมไอเดียเกม · การกำกับคนที่รันในเครื่องpackages/studioดูอีเวนต์ · ผลงานเขียนคำสั่งลง inboxsrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsลูปอีเวนต์ · replay · tailsrc/reducerสถานะ → ผลกระทบถัดไปการกำหนดทางตามคำตัดสินsession doneเสร็จ · PASS หรือเหตุผลที่หยุดsrc/dispatcher/live.tsรันผลกระทบ · spawn actorการฉายอินพุตของผู้ตัดสินmodel-config · presetactor → harness · โมเดลagent actor · CLIPlanner Lead · สเปกBuilder · เขียนเกมartifacts/ไฟล์เกมdispatcher/qa-runner.tsQA การรัน · การตรวจVerifier actorVerifier · คำตัดสินของโมเดลsrc/validatorต่อต้านการหลอกลวง · แก้คะแนนคน · Studioการควบคุมอีเวนต์transcript คือแหล่งของสถานะเอเจนต์ทำงาน · ผลงานการตรวจยืนยัน · การตัดสินใจ1เสนอ · กำกับ2อีเวนต์ของผู้ใช้3reduce ตามลำดับ4ผลกระทบ5การตั้งค่า actor6รัน Planner7spec8รัน Builder9ไฟล์10บันทึกบิลด์11qa_check12สิ่งที่รัน13qa.result1qa.result2หลักฐานเท่านั้น3อินพุตของผู้ตัดสิน4judge.score5คะแนน · หลักฐาน QA6คำตัดสินที่แก้แล้ว7เสร็จ1คำตัดสินที่แก้แล้ว2การตรวจ PARTIAL3ออกแบบใหม่ · ซ่อม4เสร็จ5เสนอ · กำกับ1อีเวนต์ใหม่ · replay2reduce ตามลำดับ3อ่าน · SSE

จากไอเดียสู่การเล่น

ไอเดียกลายเป็น spec บิลด์ และการรัน QA ทุกขั้นผ่าน transcript และ actor ไม่เรียกกันเอง

  1. ไอเดียเกม · การกำกับเสนอ · กำกับเขียนคำสั่งลง inboxpackages/studio

    ไอเดียเกมหนึ่งบรรทัดและการกำกับด้วยภาษาธรรมชาติถูกป้อนใน Studio ซึ่งเขียนคำสั่งลง inbox Studio ไม่เคยแก้ transcript โดยตรง

  2. เขียนคำสั่งลง inboxpackages/studioอีเวนต์ของผู้ใช้ลูปอีเวนต์ · replay · tailsrc/loop/coordinator.ts

    coordinator อ่านคำสั่งใน inbox และบันทึกลง transcript เป็นอีเวนต์ของผู้ใช้

  3. ลูปอีเวนต์ · replay · tailsrc/loop/coordinator.tsreduce ตามลำดับสถานะ → ผลกระทบถัดไปsrc/reducer

    อีเวนต์สดถูก reduce ทีละรายการจากคิว โดยรักษาลำดับผลกระทบของแต่ละอีเวนต์ ส่วน dispatch รันแบบอะซิงโครนัส

  4. สถานะ → ผลกระทบถัดไปsrc/reducerผลกระทบรันผลกระทบ · spawn actorsrc/dispatcher/live.ts

    reducer เป็นฟังก์ชันบริสุทธิ์ที่ตัดสินเพียงสถานะและผลกระทบถัดไป: goal เลือก Planner, spec เลือก Builder, build เลือก qa_check

  5. actor → harness · โมเดลmodel-config · presetการตั้งค่า actorsrc/dispatcher/live.ts

    harness ผู้ให้บริการ และโมเดลที่รัน actor ถูกกำหนดตามลำดับ CLI flag > config > preset > ambient > fallback 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

    spec ของ Planner กลายเป็นอีเวนต์ใน transcript และ reducer เลือก Builder จาก spec นั้น 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 ถูกบันทึกใน transcript พร้อมตัวตนของผลงาน

  11. รันผลกระทบ · spawn actorsrc/dispatcher/live.tsqa_checkQA การรัน · การตรวจdispatcher/qa-runner.ts

    หลังอีเวนต์ build reducer ส่งผลกระทบ qa_check ที่มีตัวตนของผลงานและบิลด์ และเงื่อนไขการยอมรับ แล้ว dispatcher รัน

  12. ไฟล์เกมartifacts/สิ่งที่รันQA การรัน · การตรวจdispatcher/qa-runner.ts

    QA การรันรันผลงานจริงด้วยการตรวจโค้ดและเบราว์เซอร์ timeout เริ่มต้น 120 วินาทีเป็นค่าตั้ง

  13. QA การรัน · การตรวจdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    ไม่ว่าสำเร็จหรือล้มเหลว ผลลัพธ์ถูกบันทึกเป็นอีเวนต์ qa.result ของระบบ แม้การตรวจจะเกิด exception ก็ยังบันทึกผลลัพธ์พร้อมฟิลด์ที่ล้มเหลว

ขอบเขตความไว้วางใจของการตรวจยืนยัน

QA การรันคือหลักฐานจากการรันผลงานจริง ส่วน Verifier คือโมเดลที่ตัดสินจากหลักฐานที่ฉายมา reducer กระทบยอดทั้งสองก่อนเลือกเส้นทางถัดไป

  1. QA การรัน · การตรวจdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    ไม่ว่าสำเร็จหรือล้มเหลว ผลลัพธ์ถูกบันทึกเป็นอีเวนต์ qa.result ของระบบ แม้การตรวจจะเกิด exception ก็ยังบันทึกผลลัพธ์พร้อมฟิลด์ที่ล้มเหลว

  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/reducerการตรวจ PARTIALไอเดียเกม · การกำกับ

    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. ไอเดียเกม · การกำกับเสนอ · กำกับเขียนคำสั่งลง inboxpackages/studio

    ไอเดียเกมหนึ่งบรรทัดและการกำกับด้วยภาษาธรรมชาติถูกป้อนใน Studio ซึ่งเขียนคำสั่งลง inbox Studio ไม่เคยแก้ transcript โดยตรง

Replay และการสังเกต

การสร้างสถานะใหม่จาก transcript ไม่รันผลกระทบใด และ Studio อ่านบันทึกเดียวกันเพื่อแสดงผล

  1. transcript.jsonl · append-onlysrc/transcriptอีเวนต์ใหม่ · replayลูปอีเวนต์ · replay · tailsrc/loop/coordinator.ts

    writer ตรวจสคีมา กำหนด ULID และเวลา แล้วเพิ่มต่อท้าย เมื่อเล่นซ้ำ อีเวนต์ในอดีตจะถูก reduce เท่านั้น ผลกระทบของมันไม่ถูกรันอีก

  2. ลูปอีเวนต์ · replay · tailsrc/loop/coordinator.tsreduce ตามลำดับสถานะ → ผลกระทบถัดไปsrc/reducer

    อีเวนต์สดถูก reduce ทีละรายการจากคิว โดยรักษาลำดับผลกระทบของแต่ละอีเวนต์ ส่วน dispatch รันแบบอะซิงโครนัส

  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 เป็นหลักฐานช่องทางหนึ่ง ทั้งสองอย่างไม่ได้วัดทุกพฤติกรรมของเกม ความสนุก หรือความพึงพอใจของผู้ใช้