Bài viết ra mắt Muse Wonder của Meta mô tả một hành vi được gọi là Active Focus (Tập trung chủ động): mô hình liên tục nỗ lực hướng tới một mục tiêu khó khăn, thử nghiệm các phương pháp thay thế, vượt qua các điểm nghẽn, và theo cách diễn đạt của Meta là yêu cầu làm rõ khi cần cũng như xin ý kiến (check-in) trước các hành động quan trọng. Meta cũng khuyến nghị cần có sự xác nhận của con người trước các hành động mang lại hệ quả lớn, và hướng dẫn coding-agents của họ cung cấp Muse Code với tính năng phê duyệt và sandbox được bật ngay từ lần chạy đầu tiên.
Đó là một thiết kế chuẩn xác. Nhưng nó cũng đặt ra câu hỏi mà mọi nhóm đang vận hành agent song song đều biết: khi mô hình dừng lại để hỏi, ai sẽ là người trả lời, tốc độ phản hồi ra sao và với ngữ cảnh nào? Một yêu cầu check-in rơi vào một terminal không ai theo dõi sẽ khiến tiến trình chạy bị đình trệ. Còn một yêu cầu check-in được gửi vào Inbox dùng chung, gắn liền với Task tương ứng, lại trở thành một bước đánh giá (review). Bài viết này nói về cách xây dựng giải pháp thứ hai.
Active Focus mang lại những gì
Meta đã huấn luyện ba hành vi và đo lường chúng trên một benchmark nội bộ có tên là FocusBench, nơi Muse Wonder Full dẫn đầu với 54,2% và phiên bản Wonder khả dụng qua API đạt 44,9%, xếp sau GPT-6 Astra và Claude Opus 5.5. Bỏ qua điểm số; chính các hành vi mới là điều quan trọng đối với một bảng quản lý công việc (board):
- Sự bền bỉ (Persistence). Mô hình tiếp tục kiên trì bất chấp thất bại. Trên SWE-Marathon, benchmark lập trình dài hạn, Wonder đạt 53,1 điểm so với 46,3 của Opus 5.5. Quá trình chạy dài hơn, nhiều lần thử hơn, đồng nghĩa với nhiều nội dung cần review hơn.
- Làm rõ (Clarification). Mô hình sẽ hỏi lại khi Task mơ hồ thay vì tự đoán mò. Trên một board, đó là một bình luận trong Task; còn trong terminal, đó là một dấu nhắc lệnh đang chờ người dùng nhấn phím.
- Xin ý kiến (Check-ins). Mô hình tạm dừng trước một hành động mà nó đánh giá là quan trọng. Lời khuyên từ chính Meta là hãy yêu cầu con người xác nhận cho bất kỳ hành động nào mang lại hệ quả lớn.
Mỗi hành vi này đều làm thay đổi tính chất của hàng đợi review (review queue). Sự bền bỉ làm tăng khối lượng công việc trên mỗi Task. Việc yêu cầu làm rõ tạo ra các gián đoạn ngắt quãng. Còn check-in bổ sung các quyết định sẽ chặn tiến trình chạy cho đến khi có người phê duyệt.
Điểm đến của các yêu cầu check-in
Trong Muse Code, dấu nhắc phê duyệt xuất hiện trong terminal của người đăng ký và tiến trình chạy sẽ tạm dừng để chờ đợi. Các phiên chạy ở chế độ headless (muse exec) không có dấu nhắc tương tác, vì vậy tài liệu của Meta hướng dẫn chọn một chính sách có thể hoàn thành mà không cần giám sát hoặc chấp nhận việc các hành động bị tạm giữ sẽ mãi không được giải quyết. Đó là một sự đánh đổi rõ ràng: hoặc là có người túc trực bên bàn phím, hoặc là mô hình chạy khi đã tắt tính năng phê duyệt, hoặc là hành động sẽ phải chờ đợi vô thời hạn.
Trên board của Sharkly, phiên chạy là một Task được giao cho một Agent trên Computer. Khi Agent dừng lại để hỏi, câu hỏi sẽ được ghi lại trong Task dưới dạng bình luận và được chuyển tới Inbox. Task sẽ lưu giữ toàn bộ ngữ cảnh: nội dung câu hỏi, những gì Agent đã thực hiện cho đến thời điểm đó, log thực thi của các lệnh gọi công cụ (tool call) và sự kiện Runtime. Bất kỳ ai tiếp nhận đều có thể trả lời ngay trên Task, và phiên chạy có điểm tựa để tiếp tục. Yêu cầu check-in vẫn là một quyết định của con người; nhưng đó là một quyết định có lưu lại lịch sử, có hàng đợi, và có thể được xử lý bởi nhiều người khác nhau.
Đó là sự khác biệt giữa một cơ chế bảo vệ và một sự đình trệ. Hành vi của mô hình là như nhau. Nhưng hệ thống bao quanh nó sẽ quyết định xem một lần check-in chỉ tốn một phút hay kéo dài cả ngày.
Thiết lập Agent để các lượt check-in thực sự hữu ích
Một lượt check-in chỉ phát huy giá trị nếu câu hỏi được đặt ra đúng cách. Hãy đưa ra tiêu chuẩn rõ ràng trong phần chỉ dẫn (instructions) của Agent:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
Quy tắc đầu tiên đặt ra ranh giới rõ ràng. Mô hình của Meta tự quyết định điều gì được coi là quan trọng; nhưng chỉ dẫn này cho nó biết nhóm của bạn coi trọng điều gì. Quy tắc thứ hai giúp bình luận có thể được phản hồi chỉ trong ba mươi giây bởi một người không hề theo dõi quá trình chạy trước đó. Quy tắc thứ ba ngăn mô hình hỏi về mọi thứ vu vơ—vốn là trạng thái lỗi biến một agent cẩn thận thành một agent gây phiền toái. Bài viết về guardrail cho Opus 5.5 cũng đề cập đến ranh giới tương tự từ khía cạnh prompt injection: cổng review chính là chốt kiểm soát tối thượng, bất kể mô hình hứa hẹn điều gì.
Ước tính quy mô hàng đợi
Sự bền bỉ đồng nghĩa với việc cần review nhiều hơn trên mỗi Task, chứ không hề ít đi. Hãy lên kế hoạch cho điều đó.
| Luồng công việc (Lane) | Phiên chạy điển hình | Những gì gửi đến hàng đợi |
|---|---|---|
| Muse Wonder với một Task dài | Nhiều bước, nhiều lần thử nghiệm rồi hoàn tác cách tiếp cận | Diff dài hơn, log chi tiết hơn, từ 0 đến 3 lần check-in |
| Opus 5.5 với cùng một Task | Ít bước hơn, dứt khoát hơn | Diff ngắn hơn, hoặc một Task bị trả lại khi mới hoàn thành một nửa |
| Bất kỳ mô hình nào, chạy qua đêm không giám sát | Bất cứ điều gì chính sách cho phép | Hoặc là các hành động bị tạm giữ, hoặc là các hành động không ai xác nhận |
Có ba phương pháp giúp hàng đợi luôn được thông suốt. Hãy điều hướng các yêu cầu check-in tới một reviewer cụ thể cho từng lane thay vì gửi cho tất cả mọi người, nhờ đó câu hỏi không phải chờ đợi một tập thể. Thiết lập thời gian timeout cho mỗi Task của Agent để phiên chạy bị chặn bởi check-in sẽ báo lỗi rõ ràng thay vì cứ ở trạng thái running suốt nhiều giờ. Và hãy đọc log, chứ không chỉ nhìn vào diff, đối với các phiên chạy của Wonder: hành trình đi qua ba cách tiếp cận thất bại chính là phần mà một mô hình bền bỉ tạo ra, và đó cũng là nơi ẩn chứa những lỗi tinh vi nhất. Coding agents while you’re away đề cập chi tiết đến trường hợp chạy qua đêm, và bài viết human review is the bottleneck giải thích lý do tại sao quy trình này không hề rẻ đi dù mô hình có tốt hơn.
Một yêu cầu check-in chuẩn mực trên board trông như thế nào
Dưới đây là cấu trúc được tạo ra từ các chỉ dẫn ở trên, dưới dạng một bình luận trong Task mà reviewer có thể xử lý ngay trên điện thoại:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
Bốn dòng, một quyết định, cả hai phương án đều đã được lên kế hoạch sẵn. Reviewer chỉ cần nhập “yes” hoặc “no, keep it” trên Task, tiến trình chạy sẽ tiếp tục và log sẽ ghi lại ai là người đưa ra quyết định. Hãy so sánh điều đó với một dấu nhắc lệnh terminal hiển thị Allow? [y/N] trước một người không hề theo dõi bốn mươi bước trước đó.
Hai điểm tinh chỉnh sau khi lane đã vận hành được một tuần. Nếu một reviewer phải trả lời hầu hết các yêu cầu check-in, hãy chỉ định thêm một reviewer thứ hai cho Agent của lane đó để một cuộc họp buổi chiều không làm tắc nghẽn mọi phiên chạy dài. Và nếu Agent liên tục hỏi về cùng một nhóm hành động, nhóm đó nên được đưa thẳng vào phần chỉ dẫn dưới dạng mặc định đồng ý (standing yes) hoặc mặc định từ chối (standing no), chứ không nên xuất hiện trong hàng đợi.
Trường hợp sử dụng máy tính (Computer Use)
Meta liệt kê computer use trong số các năng lực của Wonder: thao tác với trình duyệt, ứng dụng máy tính và ứng dụng di động. Đây chính là nơi các lượt check-in đóng vai trò quan trọng nhất và dấu nhắc lệnh terminal tỏ ra kém hiệu quả nhất, bởi vì hành động đó là một cú nhấp chuột trên một màn hình mà reviewer không thể nhìn thấy. Các nguyên tắc tương tự từ bài viết về computer-use của Astra đều được áp dụng: Agent chạy trên một Computer do nhóm lựa chọn, yêu cầu check-in nêu rõ tên màn hình và hành động thực hiện, đồng thời người xác nhận có thể xem log của Task trước khi đồng ý. Một mô hình xin phép nhấn nút Submit chỉ thực sự an toàn nếu có người biết rõ nút Submit đó sẽ thực hiện điều gì.
Những điều cần hiểu cho đúng
Active Focus là một hành vi của mô hình, và hành vi của mô hình không phải là một sự đảm bảo chắc chắn. Tài liệu của chính Meta cũng chỉ ra rằng các mô hình vẫn có thể mắc lỗi trong những tác vụ nhiều bước lạ lẫm, và báo cáo an toàn đầy đủ của họ vẫn đang chờ phát hành. Check-in là một tính năng giúp một hệ thống review vốn đã tốt trở nên tốt hơn; nó không thể thay thế cho hệ thống đó. Bất kỳ nhóm nào diễn giải câu “xin ý kiến trước các hành động quan trọng” như một tấm vé cho phép chạy không cần giám sát thì đều đã hiểu sai. Một nhóm gắn mỗi lượt check-in với một Task, một reviewer và một khoảng thời gian timeout mới là nhóm xây dựng đúng những gì tính năng này hướng tới.
Không khoản chi phí nào trong số này bị tính vào hóa đơn của Sharkly. Chi phí sử dụng mô hình được tính qua khóa API Meta được cấu hình trên Computer. Mô hình đã được cập nhật vào ngày 12 tháng 10. Ngữ cảnh, tiến độ, các điểm nghẽn, kết quả và sự đánh giá của con người luôn được minh bạch từ khâu yêu cầu cho đến khi phát hành. Bạn có thể tự xây dựng quy trình này thủ công bằng worktree, hoặc sử dụng Sharkly để quản lý toàn bộ quy trình làm việc.
