Agent Orchestrator của tôi đã tiêu tốn 1-2 triệu token Opus cho mỗi tác vụ.

Tại sao chi phí lại tăng vọt

Bộ điều phối (orchestrator) được xây dựng cho Claude Code và sử dụng một hệ thống phân cấp các tác nhân phụ (sub-agents). Mỗi tác nhân phụ kế thừa các thiết lập của tác nhân cha, chạy prompt riêng và đưa kết quả ngược lại vào vòng lặp cho đến khi một người kiểm duyệt xác nhận đầu ra là “sạch”. Công cụ này hoàn thành các tác vụ, nhưng mức giá phải trả là cực kỳ đắt đỏ.

Ba loại “thuế” ẩn đã nhân lên số lượng token:

  • Thuế mô hình (Model tax) – Các tác nhân phụ không bao giờ chỉ định mô hình cụ thể, vì vậy chúng mặc định sử dụng Opus, cấp độ đắt nhất. Một tác vụ nhỏ lẽ ra có thể xử lý bằng mô hình rẻ hơn (Haiku hoặc Sonnet) lại bị tính phí theo mức giá của Opus.
  • Thuế bộ nhớ đệm (Cache tax) – Việc lưu bộ nhớ đệm prompt (prompt caching) chỉ tái sử dụng các kết quả khớp chính xác từng byte. Vì mỗi tác nhân phụ đều thêm các hướng dẫn tùy chỉnh, mọi lần gọi đều buộc phải ghi vào bộ nhớ đệm mới (cold cache write). Bộ nhớ đệm của tác nhân cha không thể được tái sử dụng, làm mất đi khoản tiết kiệm mà một bộ nhớ đệm dùng chung thường mang lại.
  • Thuế vòng lặp (Loop tax) – Quy tắc “lặp cho đến khi sạch” đã duy trì quy trình hoạt động chừng nào người kiểm duyệt còn tìm thấy bất kỳ lỗi nào. Do không có giới hạn cứng, vòng lặp cứ chạy mãi cho đến khi mô hình dừng lại.

Tổng hợp lại, những hệ số nhân này đã biến một vài dòng mã thành một “cơn lũ” token.

Tại sao quy tắc ngân sách trong prompt lại thất bại

Thiết kế ban đầu cố gắng kiềm chế chi tiêu bằng cách nhúng trực tiếp quy tắc ngân sách vào system prompt. Về lý thuyết, việc bảo mô hình “hãy duy trì dưới X token” lẽ ra phải giới hạn được mức sử dụng. Tuy nhiên, trên thực tế, một quy tắc dựa trên prompt chỉ đơn thuần là một sự ưu tiên. Khi phiên làm việc (session) kéo dài, mô hình sẽ nén ngữ cảnh và có thể bỏ qua hoặc lờ đi hoàn toàn các hướng dẫn đó. Kết quả là: mô hình hoạt động như thể quy tắc đó chưa từng tồn tại.

Chuyển việc thực thi từ prompt sang mã nguồn

Thiết kế lại đã loại bỏ logic ngân sách khỏi prompt và đưa nó vào một hệ thống hook mang tính xác định (deterministic) mà mô hình không thể ghi đè.

  1. Lựa chọn mô hình rõ ràng – Mỗi lần điều phối tác nhân phụ hiện nay đều yêu cầu một lựa chọn mô hình cụ thể (Haiku, Sonnet hoặc Opus). Việc kế thừa ngầm định đã bị loại bỏ, nhờ đó các tác vụ rẻ tiền sẽ giữ được mức giá rẻ.
  2. Các chốt chặn cứng thông qua hook PreToolUse – Trước khi bất kỳ công cụ nào chạy, hook sẽ kiểm tra:
    • Số lượng điều phối đã thực hiện trong phiên làm việc.
    • Liệu mô hình được chọn có đáp ứng cấp độ tối thiểu hay không (để ngăn việc vô tình sử dụng Opus).
    • Số lượng vòng lặp tối đa, sau đó quy trình sẽ bị hủy bỏ.

Nếu bất kỳ chốt chặn nào bị kích hoạt, mã nguồn sẽ hủy bỏ tác nhân phụ; mô hình ngôn ngữ không có cách nào để tranh luận nhằm tiếp tục quy trình.

Điều này có ý nghĩa gì đối với các nhà phát triển

Bất kỳ hệ thống nào áp đặt hạn mức chi tiêu, chính sách bảo mật hoặc giới hạn đối với các lệnh mang tính phá hủy đều nên coi các ràng buộc đó là mã nguồn, chứ không phải là hướng dẫn hội thoại. Một prompt có thể bị ghi đè, bị lờ đi hoặc bị mất trong quá trình nén nội bộ của mô hình. Ngược lại, mã nguồn thực thi một cách xác định và có thể được kiểm chứng (audit).