Điều phối các tác tử Claude Code: Mô hình Chánh Văn Phòng

Công việc lập trình bằng AI trong thời gian dài thường thất bại không phải vì tác tử không biết viết mã, mà vì ngữ cảnh của chúng chỉ tồn tại tạm thời và những báo cáo tự thân của chúng thiếu độ tin cậy. Cách khắc phục mang tính tổ chức hơn là kỹ thuật: một phiên điều phối và kiểm chứng, trong khi các phiên riêng biệt thực thi, một bảng bên ngoài bền vững lưu giữ trạng thái, và mọi tuyên bố đều phải được chạy lại trước khi tin.

Mô hình này đã được biết đến với các tên gọi như orchestrator-worker (điều phối – thực thi) và coordinator-implementor-verifier (điều phối – triển khai – kiểm chứng). "Chánh Văn Phòng" chỉ là cách gọi của tác giả. Bài viết này trình bày vòng lặp, các công cụ giúp nó khả thi, và những kiểu thất bại mà nó được sinh ra để phát hiện.

Tóm tắt nhanh

• Tách biệt điều phối và thực thi. Phiên điều phối viết bản giao việc, kiểm chứng các tuyên bố, và đọc diff. Nó không trực tiếp viết mã.
• Đặt trạng thái vào kho bền vững, không đặt trong ngữ cảnh. Một bảng công việc, hay bất kỳ hệ thống tác vụ bên ngoài nào có API, sẽ tồn tại qua nén ngữ cảnh, cái chết của phiên, và việc bàn giao. Ngữ cảnh hội thoại thì không.
• Coi mọi báo cáo của tác tử là bằng chứng, không phải mệnh lệnh. Chạy lại các lệnh. Mã thoát (exit code) mới có thẩm quyền, bản tóm tắt chỉ là ý định.
• Ghi vào các kênh bền vững. Tin nhắn giữa các phiên có thể bị trễ, bị giữ, hoặc hết hạn. Một tệp đã commit hoặc một thẻ trên bảng thì luôn đến nơi.
• Đặt giới hạn thời gian để báo cáo, không phải để cắt việc. Khoảng thời gian cố định quyết định tần suất bạn báo cáo, không bao giờ quyết định nơi công việc dừng lại.
• Đừng tin công cụ của chính mình. Những lỗi tốn kém nhất trong công việc tác tử đến từ các phép kiểm tra báo thành công cho công việc mà chúng chưa từng làm.

Mô hình này giải quyết vấn đề gì?

Một phiên lập trình AI đơn lẻ hoạt động tốt trong một giờ, sau đó suy giảm. Ba điều xảy ra:

• Ngữ cảnh là hữu hạn và mất mát. Các phiên dài bị nén lại. Những chi tiết quan trọng ba giờ trước trở thành một bản tóm tắt, và bản tóm tắt ấy đánh mất những đặc thù khiến chi tiết kia trở nên hữu ích.
• Báo cáo tự thân lệch khỏi thực tế. Một tác tử nói "test đã xanh" là đang báo cáo ý định và ký ức của nó, chứ không phải một quan sát mới. Khoảng cách giữa hai thứ này tăng theo độ dài phiên.
• Không có gì tích lũy. Một bài học rút ra đau đớn ở giờ thứ hai sẽ biến mất ở phiên kế tiếp, trừ khi ai đó đã ghi nó xuống nơi phiên sau đọc được.

Thêm nhiều tác tử không sửa được điều này — nó nhân nó lên. Bạn sẽ có vài phóng viên thiếu tin cậy và không ai đối chiếu chúng.

Thứ sửa được nó là một sự phân công lao động vay mượn từ các tổ chức con người: một người mà công việc không phải là làm việc, mà là biết điều gì là đúng.

Mô hình Chánh Văn Phòng là gì?

Đây là tên gọi cho một dạng điều phối tác tử, trong đó một phiên sống lâu đóng vai trò điều phối viên — giao việc, kiểm chứng tuyên bố, và duy trì trạng thái chia sẻ — trong khi các phiên ngắn hạn riêng biệt thực hiện triển khai.

Hình dung nhanh nhất là một giám đốc tích hợp (integration manager). Trong quy trình làm việc của Git, những người đóng góp làm việc trong kho riêng của họ và một người bảo trì kéo từng thay đổi, kiểm thử cục bộ, rồi quyết định cái gì được vào kho tham chiếu. Phiên điều phối làm đúng công việc đó, nhưng cho các phiên tác tử thay vì những người đóng góp.

Những tên gọi quen thuộc của cùng một mô hình

• Orchestrator-worker (điều phối – thực thi), còn gọi là supervisor hay điều phối phân cấp.
• Coordinator-implementor-verifier (CIV) — điều phối – triển khai – kiểm chứng.
• Maker-checker (người làm – người kiểm), hay chuỗi xác thực, vay mượn từ tài chính và vận hành.
• Integration manager — phiên bản con người, được ghi lại trong các quy trình phân tán của Git từ rất lâu trước đây.
• Team lead và teammates — cách tài liệu về subagent của chính Claude Code mô tả.

Tất cả đều nói cùng một điều: một tác tử lập kế hoạch và kiểm tra, những tác tử khác làm việc, và trạng thái chia sẻ nằm ngoài mọi cửa sổ ngữ cảnh đơn lẻ.

Lưu ý phân biệt: cụm "chief of staff agent" còn được dùng rộng rãi cho một thứ khác — trợ lý quản lý lịch, hộp thư và ưu tiên của một người, rồi định tuyến công việc tới các tác tử chuyên biệt. Cùng phép ẩn dụ, khác bài toán. Bài này nói về một vòng lặp lập trình.

Nhiệm vụ của phiên điều phối

Phiên điều phối đôi khi được gọi là overwatch. Các trách nhiệm của nó:

• Kéo và giao việc từ một hàng đợi bền vững, theo một thứ tự xác định.
• Viết bản giao việc đủ rõ để một mô hình yếu hơn cũng làm theo được mà không cần phán đoán của người điều phối.
• Kiểm chứng tuyên bố bằng cách chạy lại các lệnh mà phiên thực thi nói rằng nó đã chạy.
• Đọc diff, không đọc bản ghi hội thoại. Cái gì đã vào kho mới quan trọng; tác tử nói gì về nó thì không.
• Ghi lại bài học vào một tài liệu bền vững trước khi phiên kết thúc.
• Điều chỉnh một phiên đang lệch hướng, mà không lấy mất công việc của nó.

Điều nó không làm: viết phần triển khai. Khoảnh khắc phiên điều phối bắt đầu viết mã, nó ngừng kiểm chứng, và mô hình sụp đổ thành một phiên đơn lẻ quá tải.

Ba thành phần cần thiết

Bạn cần ba thứ. Công cụ cụ thể có thể thay thế, vai trò thì không.

1. Môi trường chạy tác tử: Claude Code

Claude Code cung cấp chính các phiên: dùng công cụ, sửa tệp, truy cập shell, và khả năng các phiên nhắn tin cho nhau. Mỗi phiên có cửa sổ ngữ cảnh riêng — đó chính là điểm mấu chốt. Sự cô lập là một đặc tính, vì sự lẫn lộn của phiên này không làm ô nhiễm phiên khác.

2. Hạ tầng phiên: cmux

cmux quản lý các không gian làm việc terminal và có thể điều khiển từ dòng lệnh, nên có thể viết script. Phiên điều phối sinh ra một phiên thực thi mới như sau:

cmux workspace create \
--name project-session-12 \
--cwd /path/to/repo \
--command 'claude "Read docs/briefs/current.md and do exactly what it says."'

Hai điểm trong lệnh trên rất quan trọng, và cả hai đều tốn thời gian thực để học:

• --command gửi văn bản tới shell của workspace, không khởi động tác tử. Bạn phải gọi tác tử một cách tường minh. Một chỉ thị trần sẽ bị gõ vào shell không thể chạy nó, mà trình khởi chạy vẫn báo thành công.
• Giữ prompt ngắn và trỏ tới một tệp. Chuỗi lệnh dài không thực thi được một cách đáng tin cậy. Một prompt ngắn trỏ tới bản giao việc đã commit thì vững chắc hơn, đồng thời khiến bản giao việc có thể xem lại và chạy lại.

3. Kho trạng thái bền vững: bảng kế hoạch

Bảng kế hoạch là một bảng lập kế hoạch được phơi ra cho tác tử qua MCP: các dự án, mục tiêu, tác vụ có cạnh phụ thuộc, tài liệu thiết kế liên kết, và bình luận. Phiên điều phối và mọi phiên thực thi đọc ghi trên cùng một bảng.

Đây là thành phần mà người ta hay bỏ qua, và bỏ qua nó chính là lý do các thiết lập đa tác tử không sống sót qua một đêm. Bảng là bộ nhớ. Phiên là thứ dùng rồi bỏ, bảng thì không.

Những gì nằm trên bảng:

• Tác vụ như những bản hợp đồng thi công. Phát biểu vấn đề, các đầu việc, giao diện, hợp đồng xác thực, các phi mục tiêu. Đủ chi tiết để một phiên thực thi không bao giờ phải đọc tài liệu cha để hoàn thành công việc.
• Trạng thái lật nguyên tử cùng với công việc. in_progress ngay khi bắt đầu, done ngay khi được kiểm chứng xong. Không bao giờ gom lại ở cuối phiên.
• Tài liệu thiết kế liên kết tới các tác vụ mà chúng chi phối.
• Bình luận, nơi con người để lại chỉ đạo và tác tử để lại lý lẽ.

Vòng lặp vận hành

Một mục công việc một lúc. Một lần giao việc. Một commit.

1. PULL     kéo tác vụ chưa bị chặn kế tiếp từ bảng
2. READ     đọc tài liệu thiết kế liên kết trước khi chạm vào bất cứ thứ gì
3. RED GATE chạy bộ kiểm chứng trước: nó phải thất bại
4. DELEGATE giao việc cho một phiên thực thi, hoặc tự làm
5. PROVE    chạy lại mọi lệnh được tuyên bố; mã thoát quyết định
6. OBSERVE  đọc diff từng đoạn một
7. GATE     giải quyết làn phê duyệt, kèm lý lẽ
8. SHIP     lật trạng thái, chỉ commit mục đó, ghi nhận tiến độ

Vì sao cổng đỏ phải chạy trước

Nếu phép kiểm tra đã xanh trước khi bạn bắt đầu, công việc chẳng chứng minh được gì. Bạn không thể phân biệt một triển khai đúng với một phép kiểm tra không bao giờ chạy, một bộ lọc không khớp gì, hay một test khẳng định điều vốn đã đúng.

Chạy bộ kiểm chứng trước cũng phát hiện công việc cũ với chi phí rẻ. Trên thực tế, một phần đáng kể các tác vụ trong hàng đợi hóa ra đã xong rồi, được làm dưới một thẻ khác hoặc trở nên vô nghĩa vì một thay đổi sau đó. Một cổng đỏ trả về xanh trong một lệnh tốn vài giây và tiết kiệm cả giờ đồng hồ bạn lẽ ra phải đọc mã để triển khai thứ đã tồn tại.

Vì sao mỗi mục một commit

Lịch sử Git giữ tương quan một-một với bảng. Tiêu đề mỗi commit nêu tên tác vụ của nó. Khi có thứ gì đó vỡ ba ngày sau, đường đi từ triệu chứng tới quyết định chỉ cách một lệnh git log.

Kỷ luật kiểm chứng: trái tim của mô hình

Đây là phần phân biệt phương pháp luận này với "chạy vài tác tử cùng lúc".

Báo cáo là bằng chứng, không phải mệnh lệnh

Khi một phiên thực thi báo "bộ test xanh, 49 phép kiểm, không lỗi", việc của phiên điều phối là tìm xem điều đó có đúng không. Không phải vì tác tử nói dối, mà vì thứ chúng báo cáo và thứ chúng kiểm tra thường là hai đối tượng khác nhau.

Một khuôn mẫu đáng ghi nhớ: một phiên viết một mã băm commit vào tệp log bằng tay, rồi kiểm chứng nó bằng git cat-file, nhưng đối chiếu với mã băm ngắn nằm trong shell của nó chứ không phải chuỗi nó đã viết. Cả hai phép kiểm đều đạt. Tệp chứa một mã băm không phân giải được thành gì cả.

Quy tắc rút ra: kiểm chứng hiện vật bằng cách đọc giá trị trở ra từ chính hiện vật, không bao giờ từ biến mà bạn tưởng mình đã ghi vào đó.

Lớp lỗi cần đề phòng

Lỗi phổ biến nhất trong kỹ thuật tác tử là một công cụ đo báo thành công cho công việc mà nó chưa từng làm. Nó có nhiều hình dạng:

Hình dạng	Trông như thế nào	Lừa bạn ra sao
Khẳng định rỗng	Test đạt bất kể tính năng có hoạt động hay không	Xóa thứ đang được kiểm mà nó vẫn xanh
Không khớp âm thầm	grep, bộ lọc hay vị từ không khớp gì	Không tìm thấy gì lại đọc thành "sạch sẽ"
Phép kiểm lỗi	Một lệnh không chạy được chút nào	Lỗi bị nuốt, sự vắng mặt đọc thành bằng chứng
Tham chiếu sai	Bộ lọc khóa theo "mới hơn X"	Mọi thứ xảy ra ở khoảng giữa lọt lưới
Tiền đề cũ	Phép kiểm có giá trị kỳ vọng đọc từ mã đang lỗi	Nó đạt chính con bug mà nó sinh ra để bắt
Lệch phạm vi	Một phép kiểm xanh trên một tập con nhưng trình bày như toàn bộ	Mẫu số không bao giờ được nêu

Cách phòng vệ tổng quát: mọi phép kiểm có thể không khớp đều phải nói ra điều đó. Số đếm bằng không và việc không chạy được phải phân biệt được. Và một khẳng định vắng mặt cần một đối chứng dương trong cùng lượt chạy, vì nếu không có gì chạy thì "không có gì xấu xảy ra" vẫn đạt.

Chứng minh điều khẳng định trước khi tin điều phủ định

Trước khi kết luận một thứ gì đó vắng mặt, hãy chứng minh công cụ của bạn tìm được nó khi nó hiện diện. Trỏ phép kiểm vào một ca đã biết là tốt trước. Một công cụ báo "sạch" và một công cụ hỏng tạo ra kết quả đầu ra giống hệt nhau.

Kênh bền vững thắng kênh tạm thời

Các phiên có thể nhắn tin trực tiếp cho nhau. Kênh đó thực sự hữu ích — đó là cách phiên điều phối trả lời một câu hỏi giữa chừng, và cách một phiên thực thi báo lên một mâu thuẫn thay vì đi vòng quanh nó.

Nhưng nó không đủ tin cậy để phụ thuộc vào. Một tin nhắn có thể bị xếp sau một phiên đang bận, bị giữ để chờ phê duyệt tùy chế độ quyền của phiên nhận, hoặc hết hạn mà không được gửi. Im lặng không phải là đồng ý.

Vậy nên bất cứ thứ gì bắt buộc phải đến thì đi qua một kênh bền vững:

• Tệp đã commit. Một bản giao việc, một tài liệu bàn giao, một ràng buộc. Các phiên đọc kho mã lúc khởi động.
• Thẻ và bình luận trên bảng, nơi ngữ cảnh gắn với công việc thuộc về.
• Liên kết chia sẻ. Đặt Context: trong prompt khởi chạy thay vì dán ngữ cảnh vào đó. Prompt giữ ngắn, và ngữ cảnh ở lại nơi nó được bảo trì.

Một tin nhắn là cú hích nhẹ. Một tệp là một hợp đồng.

Nơi mọi thứ nên nằm

Một kỷ luật nhỏ mà trả cổ tức: giữ chính sách bền vững tách khỏi nội dung công việc tạm thời.

Thư mục chính sách giữ hợp đồng chi phối mọi chu kỳ — vòng lặp, luật định tuyến, và các tiêu chuẩn. Sống lâu, được xem xét, hiếm khi đổi. Bản giao việc dùng một lần, ngữ cảnh tác vụ, và chỉ thị riêng của phiên thì thuộc về bảng hoặc một thư mục tạm.

Trộn chúng vào nhau nghĩa là sáu tháng nữa không ai biết tệp nào còn chi phối thứ gì.

Giới hạn thời gian: báo cáo mà không dừng lại

Một lượt chạy tự động dài nên báo cáo theo nhịp thay vì biến mất hàng giờ rồi quay về với một bức tường diff.

Quy tắc khiến việc giới hạn thời gian hiệu quả: khoảng thời gian quyết định tần suất bạn nổi lên, không bao giờ quyết định nơi công việc dừng lại. Khi đồng hồ hết giữa một mục, hãy hoàn thành mục đó, kiểm chứng nó, commit nó, rồi báo cáo. Cắt một lượt chạy giữa tác vụ sẽ bỏ lại công việc ở trạng thái khó phục hồi nhất — nửa vời, chưa kiểm chứng, và không thể mô tả trung thực.

Một điểm kiểm tra là thời điểm nổi lên, không phải yêu cầu xin phép. Báo cáo được gửi đi và mục tiếp theo bắt đầu ngay trong cùng lượt. Nếu bạn thấy mình đang viết "tôi có nên tiếp tục không?", hãy xóa nó đi.

Hãy báo cáo điều đã được chứng minh, không phải điều đã được cố gắng. Một mục không có kết quả kiểm chứng là mục đang dang dở, không phải đã xong.

Vài chi tiết vận hành tốn thời gian để học

• Kiểm tra rằng một phiên được sinh ra thực sự đã khởi động. Trình khởi chạy báo rằng một workspace đã được tạo, điều này không đồng nghĩa với một tác tử đang chạy. Ghi lại mốc thời gian ngay trước khi khởi chạy, và chỉ chấp nhận tiến trình có thời điểm bắt đầu muộn hơn mốc đó.
• Tên phiên không phải địa chỉ bạn đoán được. Tên bạn đặt cho workspace thường không phải tên mà tầng nhắn tin dùng. Liệt kê lại các phiên đang sống trước khi gọi tới một phiên.
• Mã định danh ngắn là tiền tố hiển thị, không phải khóa. Việc đệm cho đủ độ dài tạo ra một giá trị đúng định dạng nhưng không tồn tại. Hãy tìm bằng một chuỗi con nhãn đặc trưng.
• Tìm theo nhãn, đừng tìm theo cách bạn diễn giải. Tiêu đề một mục log thường là cách phiên viết tự đóng khung điều nó đã làm, không phải nhãn thật của thẻ.
• Trong cây làm việc chia sẻ, đừng bao giờ commit trần. git add rồi git commit sẽ commit toàn bộ index, kể cả thứ một phiên chạy song song đã stage. Dùng git commit -- <đường dẫn>.

Khi nào nên dùng mô hình này, khi nào không

Nên dùng khi:

• Công việc vượt quá sức chứa của một cửa sổ ngữ cảnh.
• Nhiều luồng công việc có thể chạy song song.
• Tính đúng đắn quan trọng hơn tốc độ, và một chữ "xong" sai là đắt.
• Dự án sẽ sống lâu hơn ký ức của bất kỳ phiên đơn lẻ nào.

Không nên dùng khi:

• Tác vụ là một thay đổi đơn lẻ, phạm vi rõ ràng. Một phiên, không nghi thức.
• Bạn không kham nổi chi phí phối hợp. Mô hình này tiêu tốn token thật cho việc kiểm chứng mà không sinh ra mã.
• Không có kho bền vững. Không có nó thì bạn không chạy mô hình này — bạn đang chạy vài phiên và hy vọng.

Chi phí phối hợp chính là mục đích. Bạn đang mua khả năng tin vào kết quả.

Bắt đầu từ đâu

• Dựng một bảng bền vững. Một dự án, một vài mục tiêu, các tác vụ có cạnh phụ thuộc. Đảm bảo tác tử của bạn tiếp cận được nó qua API hoặc MCP.
• Viết hợp đồng ra giấy. Một tệp nêu rõ vòng lặp, định nghĩa "xong", và các tiêu chuẩn. Commit nó. Mọi phiên đọc lúc khởi động.
• Chạy một điều phối viên và một thực thi. Đừng bắt đầu với sáu. Hãy làm vòng kiểm chứng trung thực với hai.
• Thêm một hiện vật bàn giao. Một tệp duy nhất mà phiên điều phối cập nhật cuối mỗi phiên với trạng thái hiện tại và mọi điều đã học. Đây là thứ khiến các phiên tích lũy được.
• Giữ một nhật ký bài học. Khi có gì làm bạn bất ngờ, hãy viết nó vào nơi phiên sau sẽ đọc, trước khi phiên đó kết thúc.

Thước đo xem nó có hiệu quả hay không không phải là viết được bao nhiêu mã. Mà là liệu ở bất kỳ thời điểm nào, bạn có thể hỏi "trạng thái công việc này là gì?" và nhận được một câu trả lời đúng.

Suy ngẫm kết bài

Bản năng khi các tác tử lập trình AI kém hiệu quả trong công việc dài là với tới một mô hình tốt hơn hoặc một cửa sổ ngữ cảnh lớn hơn. Cả hai đều có ích. Nhưng không cái nào giải quyết ràng buộc thật sự: không ai đang kiểm tra cả.

Một phiên điều phối không viết dòng mã nào nhưng biết điều gì là đúng thì đáng giá hơn một thực thi nữa. Đó là bài học cũ từ các tổ chức con người, và hóa ra nó vẫn chuyển dịch được.

Câu hỏi thường gặp

Mô hình Chánh Văn Phòng trong điều phối tác tử AI là gì?

Đây là tên gọi cho một dạng phối hợp vốn đã tồn tại dưới các tên khác. Một phiên AI sống lâu điều phối và kiểm chứng công việc, trong khi các phiên riêng biệt thực thi, với trạng thái chia sẻ được giữ trong một kho bên ngoài bền vững thay vì trong ngữ cảnh hội thoại. Cùng dạng này được biết đến với tên orchestrator-worker, supervisor, coordinator-implementor-verifier, và maker-checker.

Vì sao không chạy thẳng một phiên lập trình AI dài?

Ba thứ đổ vỡ: ngữ cảnh hữu hạn và bị nén; báo cáo tự thân lệch khỏi thực tế khi phiên dài ra; và không có gì tích lũy. Một điều phối viên cộng với một bảng bền vững giải quyết cả ba, vì trạng thái sống ngoài cuộc hội thoại.

Tôi có nhất thiết cần cmux và bảng kế hoạch cụ thể đó không?

Không. Bạn cần hai năng lực: một cách sinh phiên tác tử biệt lập bằng chương trình, và một kho tác vụ bền vững có API hoặc MCP mà tác tử tiếp cận được. Thứ bạn không thể thay thế được là kho bền vững.

Phiên điều phối kiểm chứng công việc của phiên thực thi như thế nào?

Bằng cách chạy lại các lệnh mà phiên đó tuyên bố đã chạy và đọc mã thoát, bằng cách đọc diff thay vì bản ghi hội thoại, và bằng cách kiểm tra hiện vật bằng cách đọc giá trị trở ra từ chính hiện vật thay vì từ biến mà lẽ ra đã được ghi vào đó.

Cổng đỏ là gì và vì sao chạy nó trước khi triển khai?

Cổng đỏ là bộ kiểm chứng cho một tác vụ, chạy trước mọi triển khai, và bắt buộc phải thất bại. Nếu phép kiểm đã xanh trước khi bắt đầu, bạn không thể phân biệt một triển khai đúng với một phép kiểm không bao giờ chạy.

Các phiên tác tử AI nên giao tiếp với nhau thế nào?

Qua hai kênh với những bảo đảm khác nhau. Tin nhắn trực tiếp xử lý câu hỏi và cảnh báo, nhưng có thể bị xếp hàng, bị giữ, hoặc hết hạn. Mọi thứ bắt buộc phải đến thì đi qua một kênh bền vững: tệp đã commit, thẻ hoặc bình luận trên bảng, hoặc liên kết chia sẻ.

Giới hạn thời gian cho một lượt chạy tác tử tự động nên dài bao lâu?

Đủ dài để các mục công việc hoàn tất bên trong nó, đủ ngắn để con người có thể ngắt ở một thời điểm tốt. Mười lăm đến ba mươi phút phù hợp với hầu hết công việc. Quy tắc then chốt: khoảng thời gian chi phối tần suất báo cáo, không bao giờ chi phối nơi công việc dừng lại.

Mô hình này có dùng được với các mô hình khác ngoài Claude không?

Phương pháp luận độc lập với mô hình. Các thiết lập dùng nhiều mô hình có một lợi thế thật: để việc kiểm chứng do một họ mô hình khác thực hiện so với phần triển khai sẽ bắt được những lỗi mà một mô hình bị mù hệ thống trước chính kết quả của nó.