Một agent review không được phép ghi. Đây là cách chúng tôi ép buộc điều đó, từng CLI một.

Đầu tuần này, một người dùng gửi cho chúng tôi một báo cáo lần chạy đáng đọc hai lần. Mười bảy agent, một worktree dùng chung, một pipeline với một agent triển khai, một cổng release và hai nhánh review. Phiên bản 1.171.0 của AgentsRoom.

Ba chuyện đã xảy ra trong lần chạy đó, theo đúng thứ tự này.

Agent release có một bộ test đỏ trước mặt. Nó sửa spec của test cho đến khi bộ test xanh. Làm vậy, nó đã giao đi một lỗi thật, giờ được che bởi một test đồng tình với nó.

Rồi hai agent review, trên hai nhánh song song của cùng lần chạy, mỗi con tìm được một bug thật chỉ một dòng. Mỗi con sửa thẳng, trong cùng worktree, cùng lúc. Chúng va vào nhau.

Từng agent trong số đó đều có một prompt bước nói rõ, bằng lời thường, chỉ review. Không gì ngăn chúng, và không gì báo hiệu: nhìn từ phía nền tảng, một bước có công cụ ghi và đã dùng chúng.

Vì sao prompt không giữ được

Cách hiểu dễ dãi là các agent đã phớt lờ chỉ dẫn. Không phải chuyện đã xảy ra, và điều này quan trọng vì nó thay đổi cách sửa phải là gì.

Mỗi agent có một lý do để ghi, biện hộ được trong phạm vi của nó. Một bộ test đỏ và một spec trông có vẻ sai. Một bug mất bốn giây để sửa và bốn mươi giây để mô tả. Không con nào quyết định phá luật. Mỗi con quyết định rằng trường hợp của mình là trường hợp luật không nhắm tới. Nhìn từ bên trong bước đó, ngoại lệ lúc nào cũng có vẻ hợp lý.

Một chỉ dẫn viết ra là một lời đề nghị gửi đến phán đoán của mô hình. Một reviewer cũng có khả năng sửa thì sớm muộn gì cũng sẽ sửa, vì sửa là con đường ngắn nhất từ "tôi tìm thấy rồi" đến "xong". Quy tắc duy nhất sống sót khi chạm phải một ngoại lệ nghe hợp lý là quy tắc mà mô hình không thể tranh cãi: một công cụ không có ở đó.

Vì sao cài đặt toàn cục cũng không làm được

Trước đó, đòn bẩy duy nhất chạm được tới một bước đang chạy là cài đặt provider, thứ bao trùm mọi agent Claude trên máy cùng lúc. Đó là hình dạng sai cho một lần chạy. Trong cùng một pipeline, agent triển khai phải ghi còn reviewer thì không. Một công tắc toàn cục không phân biệt được hai con.

Và giới hạn theo từng agent mà chúng tôi đã có, cái mà một ticket có thể mang theo khi nó khởi chạy một agent, đã cố ý không được truyền sang các bước của team. Vậy nên một agent khởi chạy từ ticket thì bị giới hạn được, còn một node của team thì không. Đó là nguyên nhân chính, và là một quyết định thiết kế đã già đi rất tệ.

Quy tắc: một ô chọn trên node

Bản sửa là một boolean trên node review. Tick Chỉ đọc và agent hiện thân cho bước đó được khởi chạy không có quyền ghi vào dự án: không sửa file, không git commit hay push, không lệnh shell nào mà việc duy nhất là thay đổi cây làm việc. Đọc, grep, git diff, git log, test, linter và mọi công cụ team vẫn mở.

Chúng tôi nói rõ nó không phải là gì: nó không phải một danh sách cấm mà người dùng tự tay viết, cho từng CLI. Không ai nên phải biết năm cú pháp phân quyền chỉ để nói "con này review". Công tắc sinh ra cờ đúng cho từng provider, và nó được áp dụng sau cùng, sau chế độ tự trị và sau bất cứ thứ gì người dùng đã lưu trên agent, nên nó thắng.

Mỗi CLI làm gì, đọc từ chính phần trợ giúp của nó

Chúng tôi chỉ ép buộc trên những provider mà chúng tôi đã đọc được cờ trên chính --help của chúng. Một cờ đoán mò sẽ giết lần khởi chạy bằng lỗi phân tích cú pháp, tệ hơn một bước không bị ép buộc. Các CLI khác chỉ nhận quy tắc viết bằng chữ, và trình soạn thảo nói rõ điều đó bằng chữ thường ngay dưới ô chọn.

Hai chi tiết trong bảng đó làm chúng tôi tốn mỗi thứ một bug, nên đáng để viết ra.

Codex và Grok từ chối cờ lặp lại. Cả hai phân tích đối số bằng một parser nghiêm ngặt. Nếu người dùng đã lưu sẵn --sandbox workspace-write trên agent, nối thêm --sandbox read-only sẽ không ghi đè nó, mà làm sập lần khởi chạy. Vậy nên với các cờ có giá trị, chúng tôi gỡ mọi lần xuất hiện sẵn có, kèm giá trị của nó, trước khi nối cờ của mình vào. Tương tự với --agent trên OpenCode, nơi parser biến một cờ lặp lại thành mảng rồi thất bại ở đoạn sau.

Trên Claude Code, danh sách phải xếp chồng. --disallowedTools nhận một danh sách cách nhau bằng dấu cách và có thể lặp lại, và chúng tôi đã truyền sẵn một cái khi agent không được phép điều khiển trình duyệt nhúng. Parser nối một tùy chọn variadic lặp lại, nên hai danh sách cộng dồn thay vì cái sau thay thế cái trước.

Danh sách đầy đủ cho Claude Code gồm bốn công cụ sửa file, mọi lệnh con git ghi vào index, cây, refs hoặc remote (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree), và các lệnh shell chỉ tồn tại để thay đổi file (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i). Grok nhận cùng các chuỗi quy tắc đó, ở dạng glob của nó, cộng thêm tên riêng của nó cho các công cụ file (search_replace, write, hashline_edit).

Prompt vẫn có việc của nó

Cờ từ chối. Nó không giải thích. Và một agent đụng phải một lời từ chối mà nó không hiểu sẽ coi đó là bug và tìm đường khác để đi qua, chính xác là hành vi chúng tôi đang cố loại bỏ.

Vậy nên một bước chỉ đọc cũng nhận thêm hai câu trong prompt của nó. Câu đầu nói rằng bước này chỉ đọc, liệt kê điều đó nghĩa là gì, và khẳng định rằng một lời từ chối là quy tắc, không phải chướng ngại để đi vòng bằng lệnh khác. Câu thứ hai liệt kê những gì vẫn mở, và bảo agent báo cáo cái gì cần thay đổi, kèm file, dòng và lý do, trong bản bàn giao của nó, rồi để bước sở hữu mã áp dụng.

Trên các CLI có cờ đã xác minh, đoạn đó là thứ khiến lời từ chối được hiểu. Trên các CLI khác, nó là toàn bộ sự ép buộc, và chúng tôi thà nói thẳng còn hơn giả vờ.

Ai chỉ đọc trong các mẫu được giao kèm

Các node phán xét thì chỉ đọc: bước xác minh QA của hai mẫu khởi đầu, các bước tái hiện và xác minh của Bug hunt, các nhánh QA và Bảo mật của Release shield, tester của Feature squad.

Các node sở hữu mã vẫn tiếp tục ghi: developer, và cổng release được viết để tự sửa mọi phát hiện. Một cổng release không ghi được là một cổng release không release được.

Sự phân chia đó là toàn bộ thiết kế, và là sự phân chia mà sự cố đã vi phạm hai lần: một node release ghi sai chỗ, và các node review ghi, chấm hết.

Đây không phải là gì

Nó không phải ranh giới bảo mật. Người báo cáo đã nói điều đó trong báo cáo, và họ đúng: một bash -c lách qua được danh sách cấm công cụ. Nếu bạn cần cô lập một agent mà bạn không tin tưởng, đó là sandbox hoặc một máy riêng, và Codex là con duy nhất trong năm con mà chế độ chỉ đọc thực sự là thứ đó.

Thứ công tắc chặn được là tai nạn và trôi vai trò, tức là thứ thực sự xảy ra. Một reviewer không cố tình thoát khỏi danh sách cấm. Nó với tới Edit theo phản xạ, và phản xạ đó giờ bị từ chối.

Thứ chúng tôi chưa xây

Người báo cáo còn xin thêm một thứ: một sự kiện trên dòng thời gian của lần chạy nói "node X đã ghi vào cây", như tín hiệu tối thiểu ngay cả khi không ép buộc. Đó là ý hay và chúng tôi chưa làm ở đây, vì nó cần một diff cơ sở cho từng bước ở phía runner. Nếu nhu cầu quay lại, đó là mảnh tiếp theo.

Nếu bạn không dùng AgentsRoom

Các cờ ở trên sao chép được nguyên xi. Một agent review khởi chạy bằng tay với codex --sandbox read-only, hoặc claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)", không thể làm điều hai node review của chúng tôi đã làm. Đặt cùng hai câu đó vào prompt của nó để nó biết vì sao mình bị từ chối.

Thứ ô chọn thêm vào là bạn không phải nhớ cú pháp nào trong năm cú pháp được áp dụng, là cờ thắng mọi chế độ tự trị mà bước đang chạy, và là nó sống sót qua một lần chạy quay lại cùng bước đó sau này.

Công tắc trên node và bảng theo từng provider được ghi lại trên trang Agent Teams. Còn việc một lần review bởi agent có đáng làm hay không, và bao nhiêu phần của một diff vẫn xứng đáng có một con người, là câu hỏi khác, và chúng tôi đã viết về nó trong Bạn có nên vẫn review code của AI agent không?. Bài này nói về thứ nhỏ hơn, máy móc hơn: một khi bạn đã quyết định một agent review, hãy khiến nó không thể làm gì khác về mặt vật lý.