Auto-think và Auto-build: kiến trúc biến agent thành hệ điều hành biết để lại receipts

TL;DR

• Auto-think = lớp idea-intake. Research agent feed bằng evidence, một agent tên Dreamer nhận diện tín hiệu lặp lại, áp lực hệ thống, run thất bại rồi nặn thành "candidate idea contract". Nó quyết định cái gì có thể đáng build.
• Auto-build = vòng build có verify. Đưa việc đã duyệt qua Main, Coder, QA, trust reporting, retention, operator view. Nó quyết định cái gì build được, verify, và để lại receipts.
• Buildroom không phải chat transcript - nó là một workflow room nằm trên filesystem, ép hệ thống tách bạch research, ideas, reviews, plans, builds, verification, trust, retention, operator.
• Chuỗi contract gồm 12 file JSON đi tuần tự từ research-input.json tới operator-summary.json. Có schema cho từng file trước khi có automation.

Một agent bình thường chỉ trả lời prompt trước mặt

Bạn dựng agent (Hermes, OpenClaw, hay stack bất kỳ) để research, suy nghĩ, và code. Phần khó không phải ba mảnh đó - phần khó là wiring chúng lại để agent tự figure out cái gì quan trọng, tự quyết cái gì đáng build, rồi build mà không cần human in the loop.

Phiên bản đầu của hầu hết hệ thống agent là về sản xuất nhiều output hơn. Phiên bản tốt hơn là về compounding judgment - phân biệt được một tín hiệu thú vị với một build candidate, một ý tưởng cứ quay lại với một plan đã duyệt, một receipt của Coder với một verification độc lập. Đó là lúc agent bắt đầu giống hệ điều hành hơn là chuỗi prompt.

Split quan trọng: cái gì đáng build vs cái gì build được

Auto-think và Auto-build trông giống nhau nhưng làm hai việc khác hẳn. Auto-think decide what might be worth building. Auto-build decide what can be built, verify it, and leave receipts. Khi hai job này blur vào nhau, hệ thống trở nên liều lĩnh - và toàn bộ setup này được thiết kế chính xác để chống điều đó.

Trong implementation tham chiếu có hai mảnh nối với nhau: một buildroom công khai (docs, schemas, demo-room examples, verification scripts, dashboard assets, test suite) là template và proof packet; và một runtime riêng tư (Control Room adapter, web API endpoint, React UI đọc live state) là bề mặt phần mềm hiển thị + điều phối hệ thống đang chạy. Buildroom không nên depend vào private paths - nó ship safe fixtures và demo packets, đó là cái làm pattern này tái sử dụng được.

Các vai trò trong buildroom

• Research - gom evidence: structured evidence, summaries, watch items, provider health, daily outputs. Nó sở hữu "research lane".
• Dreamer (tên nội bộ của lane Auto-think) - đọc research packets, system pressure, failed runs, QA gaps, retention state, operator pressure rồi sinh ra candidate idea contracts. Nhưng Dreamer không được approve việc của chính mình. Dreamer chỉ nói "cái này có heat"; Main quyết định heat đó có thật không.
• Main - review idea contract, quyết định có proceed không (approval gate), rồi viết một product plan có giới hạn.
• Coder - chỉ implement plan đã duyệt và bounded. Coder không nhận "go improve the system" mà nhận bounded work, rồi biến product plan thành build plan.
• QA - verify độc lập, mặc định không tin summary của Coder. QA đọc plan, implementation, changed files, verification receipts rồi tự viết receipt riêng.
• Trust reporting - tóm tắt room health thành ba trạng thái: clean, watch, investigate.
• Retention - quyết định artifact đã hoàn thành nên keep, improve, park hay prune. Trong bản public, retention chỉ recommendation.
• Operator - xem Control Room: bề mặt cho con người, hiển thị Dreamer, Main, Coder, QA, research, tracks, trust, retention, recently built artifacts, risks, timeline.

Chuỗi contract: 12 file để lại receipts

Buildroom ép hệ thống đi qua một chuỗi handoff bằng file, mỗi bước có schema riêng:

1. research-input.json - evidence đầu vào.
2. idea-contract.json - handoff đầu tiên từ thinking sang building: cái gì nên tồn tại, ai hưởng lợi, why now, evidence nào support, cái gì out of scope, verify thế nào. Đây là khác biệt giữa "tôi có một ý tưởng" và "hệ thống có thể review cái này".
3. intent-review.json - filter sớm: ý tưởng đã sẵn sàng thành contract-backed candidate chưa.
4. main-review.json - approval gate. Một artifact thật trong demo room ghi "decision": "approved_for_coder", "auto_approved": false - chứng minh build không nhảy thẳng từ idea sang execution.
5. product-plan.json - Main viết sau khi approve: allowed paths, planned files, non-goals, verification commands, acceptance checks, risk assessment, protected-surface notes.
6. build-plan.json - Coder biến product plan thành executable packet để QA có thứ cụ thể mà verify.
7. verification.json - receipt của Coder; qa-verification.json - receipt độc lập của QA.
8. verification-delta.json - so sánh evidence Coder và QA với các trạng thái rõ ràng: confirmed, drift, regression, missing_evidence. Câu hỏi không phải "tests có pass không" mà là "evidence của Coder và QA có agree không".
9. trust-report.json - room health; retention-review.json - keep / improve / park / prune; operator-summary.json - status dành cho con người.

Vòng lặp đầy đủ

Research gom evidence → Dreamer nặn tín hiệu thành candidate idea contracts → intent review lọc ý tưởng yếu hoặc không an toàn → Main review contract → Main viết product plan có giới hạn → Coder chuẩn bị build plan → Coder implement trong allowed paths → Coder ghi verification → QA verify độc lập → delta so sánh evidence Coder và QA → trust reporting tóm tắt room health → retention recommend cái gì sống sót → operator xem Control Room. Trong Hermes runtime, operator dashboard nằm ở endpoint /api/operator/dashboard. Đó là toàn bộ hệ thống.

Guardrails - những gì tuyệt đối không được phép

• Dreamer không được approve build của chính mình.
• Dreamer không được mutate protected workflow surfaces.
• Coder không được mở rộng scope một cách ngầm (silently).
• QA không được rubber-stamp output của Coder.
• Retention không được tự xoá live state.
• Control Room không phải cái cớ để giấu uncertainty.
• Mọi build có ý nghĩa đều phải để lại receipts.

Một Dreamer signal không phải là task. Một build intent không phải là approval. Một ý tưởng lặp lại không tự động đáng build. Config và cron layer chỉ là policy surfaces - quyết định cái gì chạy, khi nào, profile nào sở hữu lane nào, summary nào được produce, operator-facing state đặt ở đâu. Public buildroom không cần những private paths đó; nó ship safe fixtures và demo packets, đó là lý do bản extraction có thể chia sẻ.

Muốn tự build một cái? Bắt đầu từ chuỗi contract

Đừng bắt đầu bằng việc cho agent quyền làm mọi thứ. Bắt đầu từ contract chain: tạo một local buildroom → thêm schemas → thêm một research packet → thêm một idea contract → bắt Main review nó → bắt Main viết product plan → bắt Coder chỉ build trong allowed paths → bắt QA verify độc lập → so sánh receipts → viết trust report → viết retention review → render operator summary.

Phiên bản nhỏ nhất có thể "boring and local": không cần live cron, private profiles, browser automation, hay dashboard ngày đầu. Nó chỉ cần produce các file đúng thứ tự và prove rằng handoff hoạt động. Quy tắc: add schemas before automation. Đừng để Auto-think approve việc của chính nó. Đừng để Coder mở rộng scope ngoài product plan. Đừng đánh dấu work là trusted cho tới khi có QA độc lập.

Kết

Một agent bình thường trả lời prompt trước mặt. Một agent tốt hơn nhớ những gì đã xảy ra. Ở đây, một research agent dựng nền evidence, Dreamer nhận ra cái gì cứ quay lại, còn Auto-think và Auto-build biến phần intelligence tích lũy đó thành verified work có receipts - có boundaries, có memory, có state, có review, và có một cách đi từ thought tới build mà không giả vờ rằng mọi suy nghĩ đều xứng đáng được execute.

via Hermes Agent (Nous Research)