# Làm thế nào để đặt giới hạn chi tiêu cứng cho một tác vụ của tác nhân lập trình? > Giới hạn chi tiêu cứng phải được gateway nắm giữ ngân sách tác vụ thực thi trước mỗi lệnh gọi mô hình hoặc công cụ trả phí. Dự trữ chi phí tối đa, đối soát mức dùng thực tế, từ chối lệnh gọi không đủ ngân sách và kết thúc tác nhân bằng một checkpoint hữu ích. # Làm thế nào để đặt giới hạn chi tiêu cứng cho một tác vụ của tác nhân lập trình? Ngân sách tác vụ cứng là bài toán admission control. Trước khi mọi lệnh gọi mô hình hoặc công cụ trả phí bắt đầu, gateway đáng tin cậy phải chứng minh chi phí tối đa được phép nằm trong số dư còn lại. Cảnh báo và báo cáo sau lần chạy hữu ích, nhưng không thể dừng khoản vượt đã xảy ra. Thiết kế phải bao phủ token đầu vào, đầu ra tối đa, lần thử lại, fallback, tác nhân con, embeddings, tìm kiếm, sandbox và mọi công cụ trả phí khác. ## Tách giới hạn cứng khỏi mục tiêu mềm Dùng ba giá trị: | Biện pháp | Mục đích | Hành vi | |---|---|---| | Mục tiêu | Chi phí dự kiến | Cảnh báo hoặc chọn kế hoạch rẻ hơn | | Giới hạn mềm | Ngưỡng nâng cấp | Xin phê duyệt hoặc giảm chất lượng | | Giới hạn cứng | Chi tiêu tối đa được phép | Từ chối lệnh gọi tiếp theo trước khi bắt đầu | Ví dụ, tác vụ có thể nhắm $0.60, xin phê duyệt ở $0.90 và dừng ở $1.00. Giới hạn cứng phải nằm phía máy chủ, không chỉ trong prompt. ## Đặt mọi hành động trả phí sau một gateway Cấp cho tác nhân thông tin xác thực tác vụ ngắn hạn chỉ gọi được gateway của bạn. Gateway gắn `task_id`, tra ngân sách, ước tính hành động tiếp theo rồi dự trữ tiền hoặc từ chối. Không cung cấp key nhà cung cấp để tác nhân bỏ qua hạch toán. Áp dụng cùng quy tắc cho tìm kiếm web, sandbox được host, chạy mã và retrieval trả phí. ## Dự trữ trước khi gọi và đối soát sau đó Với lệnh gọi mô hình, ước tính cận trên từ token đầu vào đã biết và đầu ra tối đa cấu hình. Dự trữ nguyên tử, gọi nhà cung cấp, rồi thay dự trữ bằng mức dùng thực tế. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` Dự trữ nguyên tử ngăn hai tác nhân con song song cùng tiêu một số dư còn lại. ## Định giá bằng bảng giá có phiên bản Lưu giá dùng cho mỗi ước tính cùng sự kiện. Giá mô hình và quy tắc thanh toán có thể đổi, nên báo cáo sau này không được tính lại mức dùng cũ theo giá hôm nay. Khi nhà cung cấp trả chi phí chính thức, lưu cả ước tính và phí cuối. Nếu chỉ có token, tính bằng phiên bản bảng giá chọn trước lệnh gọi. Thêm phụ phí thận trọng cho công cụ chưa rõ hoặc từ chối lệnh gọi không thể giới hạn chi phí. ## Làm cho streaming an toàn Dự trữ toàn bộ chi phí phản hồi được phép trước khi mở stream. Đếm mức dùng nhận được khi có, nhưng đừng giả định đóng kết nối client lập tức dừng tính phí. Hủy là tối ưu hóa, không phải ranh giới thực thi. Đặt giới hạn đầu ra mỗi lệnh gọi và timeout theo thời gian thực. Giới hạn tác vụ cứng vẫn bao phủ tổng mọi stream, retry và fallback. ## Bao gồm lần thử lại và tác nhân con Mọi lần thử ghi nợ cùng sổ cái tác vụ cha. Chính sách retry âm thầm mở ngân sách mới sẽ phá giới hạn. Dùng ngân sách phân cấp khi ủy quyền: | Sổ cái | Giới hạn | Quy tắc | |---|---:|---| | Tác vụ cha | $1.00 | Trần tuyệt đối | | Tác nhân con triển khai | $0.55 | Không vượt số dư còn lại của cha | | Tác nhân con phân tích test | $0.25 | Trả lại dự trữ chưa dùng | | Đánh giá cuối | $0.20 | Chỉ chạy nếu còn tiền | Giới hạn con là phân bổ, không phải tiền bổ sung. ## Dừng với checkpoint hữu ích Khi hành động tiếp theo không đủ ngân sách, trả lỗi có kiểu mà bộ điều phối hiểu. Tác nhân không nên liên tục thử lại lệnh gọi bị từ chối. Yêu cầu tác nhân tạo checkpoint không tốn phí từ ngữ cảnh hiện tại, gồm: * thay đổi đã hoàn thành và kết quả test; * công việc còn lại và hành động bị chặn; * trạng thái kho mã hiện tại; * ngân sách bổ sung ước tính; * token tiếp tục hoặc ID tác vụ. Như vậy, dừng do ngân sách trở thành bàn giao có kiểm soát thay vì lần chạy dở dang bị hỏng. ## Dùng kiểm soát nhà cung cấp làm lớp dự phòng Giới hạn tài khoản có thể giảm phạm vi thiệt hại nhưng hiếm khi chính xác theo tác vụ. Chúng có thể gộp nhiều kho mã, cập nhật bất đồng bộ hoặc thiếu chi phí công cụ. Với gateway đa mô hình như Atlas Cloud, giữ sổ cái tác vụ chính thức trong lớp điều phối và ghi ID sử dụng của gateway để đối soát. Ranh giới cứng vẫn được giữ khi đổi mô hình. ## Kiểm thử giới hạn như kiểm soát tài chính Kiểm thử lệnh gọi song song, stream dài, timeout nhà cung cấp, thiếu trường sử dụng, retry, fallback mô hình và lỗi sổ cái. Mặc định từ chối khi dịch vụ ngân sách không sẵn sàng. Xác nhận chi phí đã cam kết cộng dự trữ mở không bao giờ vượt giới hạn cứng. ## Kết luận Giới hạn chi tiêu cứng thực sự được thực thi trước khi chi, bằng dự trữ nguyên tử và một sổ cái cho mọi hành động tính phí. Nếu hệ thống chỉ cảnh báo sau khi nhận mức dùng, đó là giám sát chứ không phải giới hạn cứng. ## FAQ ### max_tokens có phải giới hạn tiền cứng không? Không. Nó chỉ giới hạn độ dài một phản hồi, không giới hạn tổng chi phí tác vụ, token đầu vào, lần thử lại, đổi mô hình hoặc công cụ trả phí. Giới hạn tiền cần sổ cái ngân sách cho mọi hành động tính phí. ### Nên thực thi ngân sách tác nhân lập trình ở đâu? Thực thi tại gateway phía máy chủ hoặc lớp điều phối mà mọi lệnh gọi mô hình và công cụ trả phí đều phải đi qua. Bộ đếm phía client có thể bị bỏ qua hoặc gặp race khi chạy đồng thời. ### Lập ngân sách cho phản hồi streaming thế nào? Dự trữ chi phí đầu ra tối đa được phép trước khi mở stream, sau đó đối soát theo mức dùng được báo cáo khi đóng. Hủy tại nhà cung cấp nếu được hỗ trợ, nhưng đừng chỉ dựa vào việc hủy. ### Các lần thử lại có nên dùng chung ngân sách tác vụ ban đầu không? Có. Lần thử lại, fallback, tác nhân con và lệnh gọi đánh giá phải ghi nợ cùng sổ cái, trừ khi người dùng phê duyệt rõ một ngân sách riêng. ### Điều gì xảy ra khi ngân sách còn lại quá ít? Từ chối hành động tính phí tiếp theo và yêu cầu tác nhân tạo checkpoint từ ngữ cảnh sẵn có, nêu công việc đã xong, phần chưa giải quyết và ngân sách bổ sung cần thiết. ### Giới hạn tài khoản của nhà cung cấp có thay thế giới hạn theo tác vụ không? Thường là không. Giới hạn tài khoản bảo vệ toàn bộ tài khoản và có thể cập nhật trễ. Gateway theo tác vụ cho khả năng cô lập tức thời, còn giới hạn tài khoản là lớp bảo vệ bổ sung.