Điều khiển worker nền

Hướng dẫn này cho bạn cách chạy một cuộc hội thoại với vai trò người điều khiển thay vì worker: phiên làm việc đọc và xác minh, còn các agent nền làm phần chỉnh sửa.

Điều gì thay đổi khi bạn gõ /vibe

Hai điều, và chỉ điều thứ nhất được bộ máy cưỡng chế:

1. Công cụ của chính phiên bị hạ xuống chỉ đọc, cộng thêm năm động từ worker. Cách duy nhất để nó tác động tới kho mã là thông qua một worker, và cách duy nhất để nó biết chuyện gì đã xảy ra là đọc những tệp mà worker đã động vào.
2. Nó được yêu cầu xác minh bằng cách đọc, chứ không phải bằng cách tin. Báo cáo của một worker là lời khai về việc nó đã làm, không phải bằng chứng rằng việc đó đã thành công.

Điều thứ nhất mới là điểm tựa. Một người điều khiển vẫn còn grep và edit được sẽ tự tay làm việc khi bị áp lực, và đó chính là kiểu hỏng hóc mà cơ chế này ra đời để ngăn.

/vibe migrate the auth module to the new session API

Worker bắt đầu từ số không

Một worker chưa bao giờ thấy cuộc hội thoại của bạn và sẽ không bao giờ thấy. Bản giao việc là toàn bộ ngữ cảnh của nó.

Đó là điều giữ cho mô hình này rẻ — hai mươi worker, mỗi worker giữ lịch sử của người điều khiển, sẽ tốn ngữ cảnh gấp hai mươi lần người điều khiển — và cũng chính là điều khiến việc viết bản giao việc trở nên khó. “Giờ làm nốt cái kia đi” đọc lên là một chỉ dẫn trọn vẹn với người điều khiển và chẳng là gì cả với một phiên hoàn toàn mới.

Một bản giao việc tốt nêu rõ tệp, lệnh và định nghĩa hoàn thành:

Trong lib/features/auth/, thay mọi lời gọi SessionStore.read(key) bằng SessionStore.get(key). Phương thức mới trả về Future<String?> trong khi phương thức cũ trả về String?, nên phía gọi cần await. Chạy fvm flutter analyze lib/features/auth khi xong và báo lại mọi lỗi bạn không sửa được.

Năm động từ

Động từ	Việc nó làm
vibe_spawn	Khởi động một worker theo bản giao việc. Trả về ngay lập tức.
vibe_list	Hạng, trạng thái, thời gian đã chạy và kết quả cuối của từng worker
vibe_send	Một lượt tiếp nối cho worker đã chạy xong
vibe_wait	Chặn cho đến khi một worker kết thúc
vibe_kill	Dừng một worker

Việc sinh worker là bất đồng bộ theo đúng thiết kế. Một người điều khiển chặn ở mỗi lần sinh worker là đang chạy từng worker một, tức là một cách làm chậm hơn của chính việc nó vốn đã tự làm. Chỉ dùng vibe_wait khi bạn thật sự không thể tiếp tục nếu thiếu một câu trả lời cụ thể.

Hai hạng

Hạng	Dành cho
fast	Công việc cơ học với đặc tả rõ ràng — chỉnh sửa, đổi tên, phác thảo, chạy lệnh
good	Thiết kế, phán đoán, hoặc đánh giá thứ mà một worker fast tạo ra

Một cách bố trí phổ biến là rải worker fast ra các tệp độc lập, rồi sinh một worker good để đánh giá những gì chúng cùng làm.

Xác minh

Đây chính là phần quyết định mô hình này có đáng gì hay không.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Sau đó hãy đọc những tệp nó đã nêu tên. Người điều khiển có read, search, lsp và ast_grep; giữ lại chúng chính là vì lý do đó. Một người điều khiển tin ngay vào báo cáo chỉ còn là kẻ tóm tắt sự lạc quan của các agent khác.

lsp(action: "diagnostics", file: "*") sau một vòng worker thường là phép kiểm tra nhanh nhất.

Khi worker mất mạch

Hãy dừng nó và giao việc lại. Một bản giao việc mới, đã chỉnh sửa thì rẻ hơn một cuộc tranh cãi, và vibe_send chỉ hoạt động với worker đã chạy xong lượt của mình.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Giới hạn

• Tám worker chạy đồng thời. Đây là mức trần về chi phí, không phải giới hạn kỹ thuật: mỗi worker là một phiên mô hình đầy đủ, và một người điều khiển rải ra hai mươi worker thì đã hết theo dõi nổi chúng đang làm gì.
• Không worker nào sống lâu hơn chế độ. Khi lượt chạy kết thúc, tất cả chúng đều bị dừng và bản ghi hội thoại cho biết đã dừng bao nhiêu. Một agent nền vẫn còn sửa tệp sau khi cuộc hội thoại đã đi tiếp là kiểu hỏng hóc duy nhất mà cơ chế này không được phép có.
• Bên dưới, worker vẫn là subagent bình thường. Cùng giới hạn độ sâu, cùng chính sách rào chắn, cùng bản ghi lượt chạy con. Vibe chỉ đổi ai lái chúng, chứ không đổi thứ chúng được phép làm — nên lời nhắc phê duyệt vẫn xuất hiện cho các lệnh write và exec của worker.

Khi nào không nên dùng

Chế độ vibe dành cho công việc có thể tách thành những bản giao việc độc lập. Nếu bước tiếp theo phụ thuộc vào đầu ra của bước trước, thì thứ bạn đang mô tả là một quy trình hoặc một điều phối, và cả hai đều diễn đạt phụ thuộc một cách đúng đắn thay vì bắt người điều khiển mô phỏng chúng bằng vibe_wait.

Liên quan

• Chạy agent song song — những cách rải việc khác
• Điều phối — khi công việc có hình dạng rõ ràng
• Công cụ agent tích hợp — các động từ và tham số của chúng