Đừng Làm Hỏng Tác Nhân: Bài Học về Tối Ưu Token

Bài viết này dành cho những người tò mò muốn biết thực tế là ai đó xây dựng một harness optimizer như thế nào — và, quan trọng hơn, làm sao họ biết rằng nó thực sự hoạt động.

Khi chúng tôi ra mắt JFrog Boost ở chế độ xem trước công khai, chúng tôi kể câu chuyện về hóa đơn khiến chúng tôi khựng lại và 100 tỷ token mà chúng tôi thu hồi trên toàn bộ R&D của JFrog. Điều bài viết đó không đề cập là câu hỏi đã chiếm phần lớn thời gian kỹ sư của chúng tôi: làm thế nào để đo lường mọi thứ này?

Bởi vì hóa ra “chúng tôi cắt 84% đầu ra” và “chúng tôi làm cho phiên của bạn tốt hơn” là hai khẳng định hoàn toàn khác nhau, và chỉ một trong số đó dễ dàng đưa lên dashboard.

Đây là bài viết đầu tiên trong một loạt bài mở ra cách JFrog Boost tự đo lường, sau đó so sánh với các công cụ tiết kiệm token mà các nhóm đang chạy. Bài tiếp theo sẽ đi sâu vào RTK cụ thể: điểm mà cách tiếp cận của nó đúng hướng cho phân khúc này, và nơi việc đo lường của nó thiếu sót. Mọi nội dung bên dưới là phương pháp luận mà những bài benchmark đó được xây dựng lên.

Join Boost Slack Community

The Manifest: Why Boost Exists

Khoảng cách mà chúng tôi muốn thu hẹp. Context đầu vào giờ là khoản chi chính trong hóa đơn agentic coding — theo kế toán của Cursor, khoảng 70% chi phí. Agent của bạn không tốn tiền để “suy nghĩ”. Nó tốn tiền để đọc lại một log pytest mà nó đã hiểu cách đây bốn lượt. Lãng phí là có thật, rất lớn, và hầu như vô hình khi nhìn từ bên trong một phiên làm việc.

Tại sao cách sửa hiển nhiên lại không hiệu quả. Khi bắt đầu tìm hiểu, bạn sẽ thấy một kệ đầy các công cụ hứa hẹn giảm 60–90%. Chúng tôi thử chúng, vay ý tưởng từ chúng, và liên tục va phải cùng ba khoảng trống sau:

1. Họ đo lường ranh giới sai. Việc nén được đo ở điểm sai trong pipeline sẽ tự tâng bốc. Sẽ nói thêm ở phần dưới — đây là vấn đề tinh tế nhất trong lĩnh vực này.
2. Họ tối ưu một cách im lặng. Agent không biết rằng mình vừa được trao một bản tóm tắt. Khi nó cần phần bạn đã loại bỏ, nó không thể hỏi lại. Nó sẽ đoán, hoặc chạy lại lệnh, hoặc rơi vào vòng lặp.
3. Họ không có vòng phản hồi thời gian chạy. Một benchmark nói với bạn rằng bộ lọc an toàn trên các tác vụ bạn đã nghĩ tới để kiểm tra. Nó không nói gì về phiên thứ 400 vào chiều thứ Ba trên một repo mà không ai trong nhóm bạn từng mở.

Cách tiếp cận của chúng tôi, thể hiện qua bốn cam kết:

• Độ chính xác là giới hạn; tiết kiệm là mục tiêu.Mục tiêu không bao giờ là token ít nhất. Mục tiêu là các agent chính xác sử dụng ít token hơn. Nếu một bộ lọc tiết kiệm 90% nhưng khiến mất một câu trả lời đúng, đó là bộ lọc tồi.
• Tối ưu ở cuối cùng.Boost là giai đoạn cuối cùng trước khi đầu ra vào cửa sổ ngữ cảnh — không bao giờ sớm hơn. Đây vừa là quyết định đo lường vừa là quyết định kiến trúc.
• Thông báo cho agent về những gì xảy ra. Mỗi đầu ra được tối ưu đều mang một dấu hiệu và một đường lui. Agent hiểu lớp tối ưu thay vì bị thao túng một cách thầm lặng.
• Xem mọi lần khôi phục như dữ liệu.Khi một agent yêu cầu bản gốc, đó không phải là một thất bại cần che giấu. Đó là sự kiện mang tín hiệu mạnh nhất trong hệ thống.

Mọi thứ bên dưới là chi phí mà những cam kết đó buộc chúng tôi phải chịu để hiện thực hóa.

Why We Started Measuring in the First Place

Chúng tôi không bắt đầu với việc xây dựng một ngăn xếp đo lường. Chúng tôi bắt đầu với việc xây bộ lọc.

Điều kéo chúng tôi vào con đường này là một giai đoạn khi các con số bắt đầu mất ý nghĩa. Tỷ lệ tiết kiệm trên dashboard của chúng tôi trông rất tốt. Trong khi đó, các phiên làm việc không cảm nhận được sự cải thiện tương xứng. Các nhà phát triển không thông báo rằng họ ngừng gặp tình trạng compaction. Một số chiến thắng được báo cáo lớn nhất đến từ các lệnh mà khi chúng tôi ngồi xuống đọc đầu ra thực tế, không có quá nhiều thứ để cắt.

Có điều gì đó không ổn, và “đồ thị đang đi lên” không phải là câu trả lời chấp nhận được cho một công cụ mà chúng tôi chuẩn bị đưa tới hàng nghìn kỹ sư.

Kéo sợi chỉ ấy ra, chúng tôi thấy hai câu hỏi riêng biệt nhưng bị rối vào cùng một chỉ số:

1. Tôi có đang làm hỏng agent không?
2. Tôi có thật sự tiết kiệm token không?

Chúng cần những dụng cụ đo hoàn toàn khác nhau.

Question 1: Am I Breaking the Agent?

Quy tắc đầu tiên là mọi can thiệp bên ngoài của chúng tôi không được làm agent tệ đi — chậm hơn, ngu hơn, hoặc bị mắc kẹt. Điều đó đặt ra vấn đề khó xử: làm sao bạn phát hiện một agent bối rối, tại thời gian chạy, trên hàng nghìn phiên hoạt động mỗi ngày?

Bạn không thể A/B test ngày làm việc thực tế của một lập trình viên. Bạn không thể đọc cuộc trò chuyện — Boost chỉ thu thập telemetry cấp cao như số token và lỗi vĩ mô; chúng tôi không bao giờ xem, lưu trữ, hay truyền mã hoặc hội thoại, và chúng tôi không định bắt đầu làm điều đó. Và sự bối rối không ném ra ngoại lệ. Nó trông giống như một agent lặng lẽ chạy ls sáu lần để thiết lập lại vị trí.

Vì vậy chúng tôi cần chính agent nói cho chúng tôi biết. Trong luồng.

Hậu tố Boost. Mỗi đầu ra được tối ưu kết thúc bằng một dấu hiệu ngắn:

[Boost filtered 84% of the original output, get original content with boost retrieve 123]

Quy tắc nhận thức. Dấu hiệu đó vô dụng nếu agent không biết phải làm gì với nó. Vì vậy Boost cung cấp một skill đóng gói — một system prompt tối giản dạy agent lớp tối ưu là gì và rằng đầu ra đầy đủ chỉ cách một lệnh.

Tín hiệu. Bây giờ phần thú vị. Khi một agent gọi boost retrieve, nó đang nói với chúng tôi, không được kích thích và trong môi trường production, rằng bộ lọc chúng tôi áp dụng đã loại bỏ thứ mà nó cần. Đó là một bộ lọc đã khiến agent mất tập trung thay vì đem lại tập trung.

Chúng tôi phát telemetry trên mọi lần retrieve. Tổng hợp qua các phiên, nó trở thành danh sách xếp hạng các bộ lọc tệ nhất của chúng tôi — theo lệnh, theo loại repo, theo ngôn ngữ. Tỷ lệ retrieve tăng đột biến sau một thay đổi bộ lọc là một suy giảm, và chúng tôi xử lý nó như một sự cố.

Đây là bánh đà: hệ thống tự phơi bày lỗi của chính nó, xếp hạng theo tần suất, và đề xuất nơi cần nới lỏng. Gần như tự cải thiện — với con người xem xét mọi thay đổi trước khi phát hành. Chúng tôi đang tối ưu cửa sổ ngữ cảnh của người khác. Đó không phải nơi để tự động hoàn toàn.

Bên offline. Tín hiệu thời gian chạy nói cho chúng tôi biết nơi chúng tôi gây tổn hại người dùng thực; nó không thể cho biết chúng tôi có trượt chất lượng tổng thể hay không. Để làm điều đó, chúng tôi chạy Terminal-Bench 2.0: cùng tỷ lệ vượt bài tập, với chi phí thấp hơn khoảng 12%. Cùng câu trả lời, ít tiền hơn. Đó là ranh giới — một con số tiết kiệm đi kèm tỷ lệ pass, nếu không có cái đó thì không phát hành.

Question 2: Am I Actually Saving Tokens?

Phần lớn việc lọc nhiễu CLI và MCP của chúng tôi được truyền cảm hứng từ RTK, một dự án mã nguồn mở thực sự thông minh xứng đáng được ghi nhận vì đã đặt vấn đề này lên bản đồ. Nhưng xây dựng trên ý tưởng đó lộ ra một bẫy đo lường mà chúng tôi cho là bị đánh giá thấp trên toàn ngành.

Vị trí bạn đứng trong pipeline quyết định những gì bạn có thể công khai tuyên bố một cách trung thực.

Một bộ tối ưu dựa trên prefix bao quanh lệnh:

rtk git log | grep ABC-123

Đọc shell cẩn thận. Bộ tối ưu nén đầu ra của git log — và sau đó grep chạy. Bất cứ thứ gì grep sắp loại bỏ, bộ tối ưu đã nhận công là đã bỏ. Các token mà nó báo cáo tiết kiệm vốn dĩ không bao giờ định đến cửa sổ ngữ cảnh. Nếu bạn chặn đầu ra trước một bộ lọc grep và nhận công cho thứ mà grep định loại bỏ, đó không phải là tiết kiệm. Đó là phép toán.

Đứng sớm có một chi phí thứ hai: bạn đang viết lại đầu ra trước khi pipeline mà nhà phát triển thực sự thiết kế kết thúc, và chính lúc đó bạn có nhiều khả năng cắt mất thứ mà phần sau cần.

Vì vậy chúng tôi chọn đầu bên kia:

(git log | grep ABC-123) | boost

Boost chạy cuối cùng. Những gì nó thấy chính xác là thứ đáng ra sẽ rơi vào cửa sổ ngữ cảnh, byte từng byte. Mỗi token mà nó báo là token thực sự đang trên đường vào.

Sau đó nhân với số lượt. Đây là phần mà hầu hết các ước tính tiết kiệm bỏ sót hoàn toàn.

Mỗi khi người dùng gửi một tin nhắn mới trong một phiên đang diễn ra, tất cả token trước đó được gửi lại. Cho đến khi phiên chạm tới compaction, mọi lệnh CLI, mọi đầu ra, mọi yêu cầu và phản hồi MCP vẫn nằm trong cửa sổ — và bạn bị tính phí cho nó trên từng lượt.

Vậy giá trị của việc cắt bớt một đầu ra lệnh không phải là số token bạn cắt. Là số token bạn cắt, nhân với số lượt mà đầu ra đó sẽ nằm trong ngữ cảnh. Một log 3.000 token bị loại ở lượt thứ 4 của phiên 40 lượt không phải là tiết kiệm 3.000 token. Ước tính trên mỗi phiên của chúng tôi tính đến thời gian cư trú này, đó là lý do tại sao các con số của chúng tôi được tính toán thay vì nội suy từ tỷ lệ nén.

Và đó là lý do tại sao tiết kiệm tăng theo cả hai hướng: ít token mỗi lượt nghĩa là lượt đó rẻ hơn, và bạn có thể thực hiện nhiều lượt hơn trước khi chạm compaction, và ít compaction hơn — mỗi lần compaction đều khiến bạn mất đi độ trung thực ngữ cảnh có giá trị.

If You’re Building One of These

Bốn điều chúng tôi sẽ trao cho bất kỳ ai bắt đầu đi trên con đường này:

• Chọn ranh giới đo lường trước khi chọn bộ lọc.Nó quyết định liệu mọi con số bạn đưa ra sau đó có thật hay không.
• Cho agent cách để phản đối bạn.Một bộ tối ưu agent không thể ghi đè là một bộ tối ưu bạn không thể gỡ lỗi.
• Ghi lại đường khôi phục, không chỉ đường tiết kiệm.Tỷ lệ retrieve của bạn là chỉ số chất lượng trung thực hơn bất kỳ tỷ lệ nén nào.
• Không bao giờ báo một con số tiết kiệm mà không có con số đúng đắn đi kèm.Nén mà không có tỷ lệ pass chỉ là một tuyên bố, không phải kết quả.

Boost miễn phí và đang ở chế độ xem trước công khai. Thử ngay tại boost.jfrog.com — và nếu bạn tìm thấy bộ lọc khiến agent của bạn kém thông minh hơn, boost retrieve sẽ báo cho chúng tôi trước khi bạn phải làm vậy.

Đây là bài đầu tiên trong một loạt bài so sánh cách tiếp cận đằng sau JFrog Boost với các công cụ tiết kiệm token mà các nhóm đang chạy trong production. Tiếp theo: một cái nhìn kỹ hơn về RTK, nơi ranh giới đo lường của nó vỡ dưới các phiên agentic thực tế, được benchmark trực tiếp so với JFrog Boost.

Liên hệ tư vấn và mua giải pháp — Softribution

Nếu quý công ty cần tư vấn triển khai giải pháp tối ưu hóa ngữ cảnh, đánh giá tác động token, hoặc muốn mua giải pháp tương tự cho hệ thống của mình, đội ngũ tư vấn công nghệ của Softribution sẵn sàng hỗ trợ. Chúng tôi cung cấp đánh giá chuyên sâu, thử nghiệm tương thích với workflow hiện tại, và dịch vụ triển khai kèm theo giám sát hiệu năng. Vui lòng liên hệ với Softribution để được tư vấn cụ thể hoặc nhận báo giá giải pháp phù hợp với tổ chức của bạn.