Timeout của agent không phải là hủy hành động

Bạn vừa bước ra. Client timeout. Nest reconnect, hoặc run trông như kẹt trên UI. Phản xạ thường gặp: coi hành động đang treo là đã hủy — hoặc POST lại cùng một request cho “chắc ăn.” Cả hai đều sai.

Một bài viết về control plane agent thật đặt luôn thất bại vào tiêu đề: timeout của agent không phải là hủy hành động. Câu chuyện quen dù bạn không dùng stack đó: agent xin lưu báo cáo, người vận hành bước ra, client timeout, process restart. Khi quay lại, không biết ghi đã xong, còn đang bay, hay chưa bắt đầu. Đoán rồi gửi lại là cách có bản ghi thứ hai.

Đây không phải bài cửa duyệt hôm qua. Bài đó nói đừng để vòng tự do cầm write và host-shell. Bài này là việc làm sau khi một lời gọi tool đã rời client.

Cái gì thực sự dừng — và cái gì không

Soot đang preview. Bạn chọn quyền. Bạn có thể Stop một run. Hành động đã xong thì vẫn xong. Workspace không phải sandbox OS.

Hai điểm nữa khi UI trông như chết:

• Mất kết nối hoặc rời watch không Stop run.
• Nest là workspace của người vận hành, không phải runtime. Lưu trong Nest chưa phải Active cho đến khi host xác nhận.

Đóng tab, bỏ watch, hay đợi client timeout không phải hủy. Nếu ghi file hay lệnh host-shell đã xong trên máy, Stop không hoàn tác. Nếu còn đang bay, host vẫn có thể làm xong trong lúc bạn nhìn spinner.

Agent không được tự quyết mình được phép làm gì — đó là quyết định ở tầng tool, không phải hy vọng model sẽ từ chối POST lần hai. Trách nhiệm không ủy thác khi bạn bước ra khỏi client. Quyền nằm ở tầng tool, không nằm trong prompt bạn không thể “prompt đi” (ghi chú về ranh giới đó).

Kết quả không chắc thì xem run gốc

Sau một lần gửi không chắc chắn, giữ conversation id và run id gốc, cùng biên nhận nếu đã có. Watch run đó. Đừng mở conversation mới rồi POST cùng tool call “cho chắc.” Gửi lại không phải rollback.

soot watch --conversation <conversation-id> --run <run-uuidv7>

Dùng ID của run đã gửi hành động. Token trên là placeholder — copy conversation id và run uuid thật từ phiên đó.

Khi watch:

1. Gọi tên hành động. Đường dẫn file, lệnh, hoặc tool — không phải “nó đang làm gì đó.”
2. Xem artifact, không xem spinner. Tool ghi file thì ls / stat / diff với bản bạn không đưa cho agent. UI có thể chậm hơn host.
3. Đừng Stop trừ khi bạn muốn chặn việc mới. Stop được ghi nhận trước khi hủy và rào effect mới cũng như xuất bản. Nó không hoàn tác hành động đã xong. Nó cũng không làm nửa lần ghi biến mất.
4. Đừng spawn bản song sinh. soot run thứ hai cùng mission là lần thử thứ hai, không phải truy vấn lần đầu.

Nếu soot check --show vẫn liệt kê write hoặc host-shell mà run sau không cần, gỡ cho *run kế*. Việc đó không rút lại những gì run này đã làm.

Một chuỗi ngắn cho người vận hành

Khi client timeout hoặc Nest reconnect:

1. Ghi conversation id và run id trước khi bấm gì khác.
2. soot watch cặp đó. Đợi host có trạng thái kết thúc, hoặc bạn thấy được artifact.
3. Nếu cần run ngừng *việc mới*, Stop — rồi vẫn kiểm tra những gì đã hạ cánh.
4. Chỉ sau đó mới quyết có cần run mới không, với mission hẹp hơn, không lặp cùng một lần ghi.

Chúng tôi không khẳng định Soot có hàng đợi duyệt bền trong sản phẩm, sống sót mọi lần restart server. Thực hành sống sót restart là thứ docs đã nói: giữ ID, xem run gốc, coi lần gửi lại là effect mới.

soot spawn mặc định là Soot general, có write và host-shell. Không phải chỉ đọc. Nếu cách làm việc của bạn là timeout rồi gửi lại, spawn --empty hoặc gỡ grant đến khi client treo không thể apply hai lần. Đó là lớp kiểm soát bổ sung cho Stop.

Việc làm tiếp

Đọc Stop và kết quả không chắc trong docs vận hành, rồi cùng các quy tắc đó trên quick start. Nếu run vẫn ghi được, nhìn soot check --show trước khi gõ lệnh kế.