Cấp cho agent một ngân sách có thể cưỡng chế
Chặn lời gọi vượt số lượt hoặc thời hạn, dành phần bàn giao và phân biệt hoàn thành với hết tài nguyên hay thao tác còn chạy.
Với kỹ sư vận hành agent, quy tắc dừng phải được ứng dụng thực thi. Prompt “hãy làm việc hiệu quả” không ngăn được lời gọi công cụ tiếp theo. Hãy xác định bằng chứng cần có để hoàn thành, tài nguyên được cấp và các trạng thái kết thúc trước khi bắt đầu chạy.
Giả sử agent điều tra lỗi xuất dữ liệu trong repository, được dùng mười hai lời gọi công cụ và mười phút. Nó được đọc tệp, chạy kiểm thử nhưng không sửa hay phát hành. Mục tiêu là chỉ ra nguyên nhân có khả năng đúng cùng bằng chứng. Các giới hạn này là chính sách minh họa, không phải khuyến nghị chung cho mọi cuộc điều tra.
Tách thành công khỏi hết tài nguyên
Hoàn thành nghĩa là có đủ bằng chứng theo yêu cầu. Với lỗi xuất dữ liệu, đó có thể là lỗi đã tái hiện, đường dẫn mã liên quan và giải thích nguyên nhân phù hợp trace. Ứng dụng có thể yêu cầu các trường này, nhưng kết luận kỹ thuật cuối vẫn cần duyệt.
Hết ngân sách nghĩa là đã dùng hết tài nguyên được phép mà chưa đáp ứng hợp đồng. Hệ thống nên trả phát hiện đã xác minh cùng bước kiểm tra còn thiếu. Gọi tình trạng đó là hoàn thành chỉ vì mô hình viết xong đoạn cuối sẽ mô tả sai điều đã xảy ra.
Một kết thúc khác là cần người dùng bổ sung thông tin thiết yếu. Nếu không có repository được nêu hoặc thiếu dữ liệu gây lỗi, agent có thể chưa làm tiếp được việc có ích. Cần phân biệt tình trạng này với một điều chưa chắc chắn thông thường mà các công cụ sẵn có vẫn giúp điều tra được.
Mỗi nhánh cần trạng thái lưu trữ và thông báo riêng. Lần tiếp tục sau đó mới biết nó đang làm nốt việc cũ hay bắt đầu một nhiệm vụ mới sau kết quả đã hoàn thành.
Dành ngân sách bàn giao trước khi dùng hết
Nếu dùng mọi token và giây cho điều tra, agent có thể không giải thích được nó đã tìm thấy gì. Giữ một phần để tổng hợp bằng chứng, lưu mã thao tác còn chạy và nêu bước tiếp. Phần dự phòng phải nằm trong cách tính của bộ thực thi, không chỉ là mong muốn gửi cho mô hình.
Chính sách đơn giản có thể dành tối đa mười trong mười hai lượt cho điều tra, giữ phần còn lại để quan sát thao tác đang chạy hoặc ghi bản bàn giao. Phân bổ cụ thể chỉ để minh họa. Có nhiệm vụ không cần gọi thêm công cụ để kết thúc; nhiệm vụ khác cần bảo vệ một lượt xác nhận cuối riêng.
Một trace giả định làm rõ cách dùng phần dự phòng. Sau chín lượt đọc còn ba lời gọi. Khởi chạy một kiểm thử dùng lượt thứ mười nhưng chưa xác định kết quả. Các lượt giữ lại có thể quan sát mã thao tác đó rồi lưu bàn giao:
| Trạng thái | Lượt đã dùng | Lượt còn lại | Hành động tiếp được phép |
|---|---|---|---|
| Đã đọc xong | 9 | 3 | Khởi chạy một kiểm thử có lý do |
| Đã khởi chạy kiểm thử | 10 | 2 | Quan sát mã tiến trình đã lưu |
| Đã nhận kết quả cuối | 11 | 1 | Ghi bằng chứng và bàn giao |
| Đã lưu bàn giao | 12 | 0 | Dừng gọi công cụ |
Nếu lượt quan sát vẫn thấy tiến trình còn chạy, hệ thống phải áp dụng chính sách tiếp tục hoặc hủy đã công bố. Không được gắn nhãn kiểm thử thành công chỉ vì phần dự phòng gần cạn.
Đo thời gian bằng đồng hồ đơn điệu, tức đồng hồ không lùi khi giờ hệ thống được chỉnh. Lưu mức sử dụng thực tế từ nhà cung cấp và số lần thực thi công cụ khi có thể. Ước lượng token còn lại do mô hình tự nói không phải cơ chế thanh toán hoặc cưỡng chế đáng tin.
Từ chối lời gọi tiếp theo tại bộ thực thi
Đây là chính sách cấp lượt cho ví dụ mười hai lời gọi. Mười lượt được điều tra; hai lượt cuối dành cho quan sát thao tác cũ hoặc ghi bàn giao. Điều tra mới cũng dừng trước hạn tuyệt đối ba mươi giây. Đây là các hằng số phục vụ bài học, không phải cấu hình tối ưu đã đo. Hàm nhận số đọc đồng hồ theo giây, trả bộ đếm mới hoặc None nếu không cấp lượt.
import math
def claim(used, kind, now, deadline):
if type(used) is not int or not 0 <= used <= 12:
raise ValueError("invalid used count")
if type(kind) is not str or kind not in {"investigate", "handoff"}:
raise ValueError("unknown call purpose")
if any(type(t) not in (int, float) or not math.isfinite(t)
for t in (now, deadline)):
raise ValueError("finite clock readings required")
if used == 12 or now >= deadline:
return None
if kind == "investigate" and (used >= 10 or now >= deadline - 30):
return None
return used + 1
print(claim(9, "investigate", 100, 600))
print(claim(10, "investigate", 100, 600))
print(claim(10, "handoff", 580, 600))
print(claim(11, "handoff", 590, 600))
print(claim(12, "handoff", 599, 600))Các đầu ra lần lượt là 10, None, 11, 12, None. Tại giây 570, điều tra mới bị từ chối dù chỉ mới dùng hai lượt. Một lời gọi bàn giao vẫn có thể bắt đầu khi ấy nếu còn dung lượng. Tới giây 600, mọi lời gọi mới đều bị chặn. Kiểm tra đúng các mốc biên quan trọng như đường chạy bình thường vì lỗi lệch một lượt có thể tiêu mất phần dự phòng.
Ứng dụng phải phân loại mục đích lời gọi. Nếu để mô hình tự gắn nhãn, nó có thể gọi mọi truy vấn mới là bàn giao. Khi được cấp lượt, lưu bộ đếm mới trước khi chạy công cụ và tính lần thử đó ngay cả khi công cụ trả lỗi. Yêu cầu bị từ chối không được gọi công cụ.
Hàm thuần này không có lưu trữ hoặc kiểm soát đồng thời: hai worker cùng đọc used=9 đều có thể nhận 10. Bộ thực thi dùng chung cần thao tác kiểm tra rồi cập nhật nguyên tử, hoặc giao dịch bảo vệ việc cấp lượt, cùng bản ghi lần thử ổn định. Chỉ kiểm thử các phép tính tuần tự chưa bảo vệ được trường hợp nhiều worker tranh cùng ngân sách.
Tài liệu Python time, được đọc ngày 21 tháng 9 năm 2026, nói mốc tham chiếu của monotonic() không được định nghĩa và chỉ hiệu giữa các số đọc mới có ý nghĩa. Một tiến trình đang chạy có thể dùng hạn đơn điệu cục bộ; không nên lưu số đọc nguyên dạng như timestamp lịch có thể chuyển sang máy khác. Khi phục hồi, áp dụng chính sách hạn bền vững đã xác định rồi thiết lập ngân sách đồng hồ cục bộ mới.
Cấp lượt không đồng nghĩa hủy tác vụ khi tới hạn. Lời gọi được chấp nhận ở giây 599 có thể chạy quá 600 nếu công cụ không nhận timeout hoặc deadline phù hợp và không hỗ trợ thực thi giới hạn đó. Dự phòng tạo cơ hội kết thúc có trách nhiệm, không bảo đảm mạng chậm hoặc tiến trình bị kẹt sẽ hợp tác. Kiểm tra truyền hạn xuống công cụ và dọn tiến trình riêng với hàm số học này. Giới hạn token và tiền cũng cần cách tính riêng: mười hai lượt đọc tệp ngắn khác mười hai lần sinh nội dung dài.
Exponential Backoff And Jitter của Marc Brooker, công bố ngày 4 tháng 3 năm 2015, dùng mô phỏng tranh chấp để giải thích công việc thừa khi các client cùng thử lại đồng bộ. Các con số trong nguồn thuộc mô phỏng ấy, không phải agent ở đây. Chọn thời điểm thử lại cũng không làm phép ghi tự nhiên an toàn để lặp.
Tài liệu idempotency của Stripe, được đọc ngày 21 tháng 9 năm 2026, đưa ra hợp đồng dịch vụ cụ thể khi gửi lại cùng khóa và tham số. Adapter của agent phải tra bản ghi thao tác hoặc quy tắc idempotency của dịch vụ thực sự dùng sau một timeout chưa rõ kết quả. Còn lượt gọi không đủ để xác định phép ghi đầu tiên đã commit hay chưa.
Giới hạn thử lại và giả thuyết lặp
Công cụ có thể lỗi vì tham số sai, dịch vụ tạm hỏng, thiếu quyền hoặc không có tài nguyên. Những trường hợp này không nên đi vào cùng một vòng thử lại. Tham số sai có thể sửa một lần; bị từ chối quyền không phải lý do để thử các mã tài nguyên lân cận đến khi tìm được mã truy cập được.
Hướng dẫn rate limit của OpenAI, được đọc ngày 20 tháng 9 năm 2026, bàn về chờ rồi thử lại khi bị giới hạn. Thời gian chờ vẫn tiêu ngân sách nhiệm vụ. Không ngủ rồi thử quá mốc kết quả còn hữu ích. Ghi số lần thất bại cùng mức sử dụng thực tế bị tính phí; yêu cầu lỗi không nhất thiết có phí bằng yêu cầu hoàn tất.
Hành động lặp cũng có thể cho thấy vòng suy luận không tiến triển. Nếu cùng một tệp được đọc ba lần theo cùng giả thuyết mà không có bằng chứng mới, yêu cầu bước kiểm tra khác hoặc dừng. Ngưỡng là lựa chọn của ứng dụng; tín hiệu có ích là công việc lặp nhưng bằng chứng không thay đổi.
Giữ đúng trạng thái thao tác đang sống
Nếu agent khởi chạy kiểm thử rồi lượt quan sát hết thời gian, tiến trình có thể vẫn chạy. Mở bản sao thứ hai vì chưa thấy đầu ra vừa lãng phí vừa có thể gây nhiễu. Giữ mã tiến trình và quan sát trạng thái thật của nó.
Chính sách hạn cần nói rõ cách xử lý công việc còn hoạt động: hủy nếu được hỗ trợ, cho một khoảng gia hạn giới hạn hoặc trả tham chiếu bền vững để quan sát sau. Bàn giao phải nêu trường hợp nào đã xảy ra. “Kiểm thử thất bại” là sai nếu điều duy nhất biết được là đã ngừng quan sát trước lúc nó kết thúc.
Với công cụ gây tác động, timeout không rõ kết quả nghiêm trọng hơn. Thao tác có thể đã commit trước khi mất phản hồi. Kiểm tra mã thao tác hoặc bản ghi trạng thái trước khi thử lại. Điều kiện dừng phải tính cả tác động chưa đối soát, không chỉ suy luận còn dang dở.
Đánh giá trực tiếp hành vi dừng
Bài báo ReAct nghiên cứu vòng xen kẽ suy luận và hành động. Khi đưa vòng này vào sản phẩm, thêm hành vi dừng vào đánh giá. Thỉnh thoảng giải được tác vụ nhưng thường xuyên vượt quyền không đáp ứng toàn bộ hợp đồng.
Dùng bộ thử có đáp án ngay, có manh mối hữu ích xuất hiện muộn, công cụ liên tục lỗi và bằng chứng được yêu cầu không tồn tại. Ghi riêng thành công, báo chưa xong trung thực, lời gọi vượt mức và hành động sau trạng thái cuối. Gộp chúng vào một tỷ lệ thành công sẽ che lỗi vận hành.
Đọc bản bàn giao của lần hết ngân sách. Kỹ sư khác cần nhận biết revision repository, tệp đã đọc, lệnh thực sự hoàn tất, quan sát và phần chưa chắc chắn. Một chỉ mục bằng chứng ngắn có thể dễ dùng hơn toàn bộ hội thoại.
Dừng đúng không yêu cầu agent giải được mọi tác vụ. Nó yêu cầu hệ thống báo đúng việc đã làm, việc còn chạy và điều kiện cần để tiếp tục. Nhờ vậy giới hạn tài nguyên vẫn đi cùng kết quả kỹ thuật hữu ích.