Lý do khó nhìn thấy lãng phí token là vì đó không phải thất bại mà là sự trùng lặp: đọc cùng một tệp hai lần, thử lại với cùng tham số, gọi lại cùng một công cụ. Vì vậy tôi đã tạo một CLI đọc các trace đã kết thúc và chỉ ra bước nào đã lặp lại việc đã làm trước đó!
[Dùng thử]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Chạy cục bộ, không cần đăng ký. Không kéo theo torch nên chỉ mất vài giây để cài đặt. Yêu cầu Python 3.12 trở lên. Tệp phiên Claude Code nằm dưới ~/.claude/projects/.
Đây là đầu ra thực tế khi chạy trên một phiên Claude Code công khai (258 lượt):
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[Cách phán định]
Nó không lưu và trực quan hóa trace như Langfuse hay Phoenix. Nó đọc các trace đã kết thúc và chỉ ra phần lãng phí.
Quy trình gồm 2 bước. Trước tiên, nhóm các lần gọi cùng một công cụ với cùng tham số lại với nhau, sau đó kiểm tra xem sha256 của đầu ra có hoàn toàn giống nhau hay không. Nếu đầu ra khác nhau thì coi như trạng thái đã thay đổi và sẽ không bị bắt.
Không có phán định bằng LLM. Với cùng một trace đầu vào thì kết quả lúc nào cũng giống nhau.
Phần lãng phí được tìm thấy sẽ được phân thành bốn loại. Lặp lại lỗi (thử lại cùng một lỗi mà không sửa nguyên nhân), tái thực thi tác dụng phụ (gọi lại công cụ làm thay đổi trạng thái với cùng tham số), vùng xám (lặp lại chỉ đọc — không có tác dụng phụ nhưng vẫn tốn token), và không thể phán định. Với các công cụ như Bash hay PowerShell, nơi hiệu quả có thể thay đổi hoàn toàn tùy nội dung tham số, hệ thống không phán định chỉ dựa vào tên công cụ mà để vào loại không thể phán định.
[Đã tìm thấy gì trong dữ liệu công khai]
Khi chạy nguyên trạng trên benchmark Toolathlon (22 mô hình frontier × 3 lần chạy, 6.780 trace, 176.270 tool span), tôi tìm ra 8.042 lượt gọi trùng lặp.
Nếu dùng nguyên con số này thì sẽ bị thổi phồng. 47% là vùng xám (lặp lại tuyên bố hoàn tất công việc, tạo lại thư mục đã tồn tại, v.v.), nên sau khi loại ra thì còn 4.251 trường hợp. Tương đương 2,41% so với tổng tool span.
Điều nổi bật là có 1.343 trường hợp tái thực thi trùng lặp với các công cụ làm thay đổi trạng thái, trong đó có 459 lần gửi email bị lặp lại với cùng tham số. Tuy vậy, đây chỉ là phát hiện rằng "cùng một công cụ đã được gọi hai lần với cùng tham số"; chỉ từ trace thì không thể xác nhận email có thực sự được gửi hai lần hay không.
[Điều bất ngờ]
Bản thân Claude Code hiệu quả hơn tôi nghĩ. Tôi đã đo sáu mẫu ứng viên như đọc lại tệp hay thử lại vô nghĩa, và trong năm trường hợp thì chúng hầu như không tồn tại trong các phiên CC thực tế. Có vẻ việc caching và duy trì ngữ cảnh đã chặn chúng từ trước rồi.
Phía lãng phí dày hơn là môi trường gắn nhiều máy chủ MCP. Mức chênh lệch giữa CC có 20 công cụ (0,80%) và Toolathlon có 523 công cụ (2,41%) là gấp 3 lần.
[Giới hạn]
Hiện vẫn chưa có trường hợp cắt giảm nào được đo lường. Có thể phát hiện và ước tính, nhưng hiện có đúng 0 trường hợp ai đó xem kết quả này, sửa thứ gì đó và hóa đơn thực sự giảm xuống.
47% vùng xám không bị lọc bỏ mà chỉ được phân loại rồi hiển thị. Việc lặp lại chỉ đọc có thực sự là lãng phí hay không còn tùy vào ngữ cảnh thực thi, và đó là phần tôi không thể tự phán định.
Hiện chưa hỗ trợ Cursor và Codex.
Tôi sẽ loại bỏ các detector không vượt qua kiểm chứng. Tôi từng làm detector phát hiện đọc lại tệp nhưng đã hủy nó vì trên mẫu 30 trường hợp, độ chính xác thấp hơn rất nhiều so với ngưỡng 70% (kể cả nhìn thoáng cũng chỉ 3,3%, còn nghiêm ngặt thì 0%), và tôi đã để lại cả dự đoán lẫn kết quả trong tài liệu preregistration.
[Kết lại...]
Tôi dự định sẽ tiếp tục nghiên cứu và kiểm chứng trong lĩnh vực này!
Xin lỗi vì README đang là tiếng Anh.. hu hu
Nếu bạn dùng thử, tôi rất muốn nhận được phản hồi về những điểm nên cải thiện hay nên bổ sung!
Mong mọi người sẽ tiếp tục quan tâm đến clew, xin cảm ơn...!!
1 bình luận
[Để mọi người dễ đọc hơn, tôi đã viết bản dịch tiếng Hàn của README!]
Clew
Trình phát hiện mang tính quyết định để tìm các thao tác lãng phí trong trace của agent.
Clew đọc trace thực thi AI agent đã hoàn tất và tìm ra các bước lặp lại những việc đã làm rồi — gọi lại cùng một công cụ với cùng tham số, thử lại một lời gọi thất bại với cùng tham số, hoặc truy vấn lại thông tin đã có sẵn trong ngữ cảnh. Vì hoạt động mà không cần phán định của LLM, nên nếu đưa cùng một trace vào thì luôn cho ra cùng một kết quả.
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdVí dụ đầu ra thực tế khi chạy trên một phiên Claude Code công khai:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsVì sao điều này quan trọng
Trong các phiên AI coding agent, sự lãng phí chỉ lộ ra trên hóa đơn. Vì mọi lời gọi công cụ đều trả về 200 và không có gì báo lỗi, nên sự lãng phí không thể nhìn thấy bằng mắt thường. Nhưng bên trong trace, agent lại đọc cùng một tệp hai lần, thử lại một lời gọi thất bại với cùng tham số, và gọi lại cùng một công cụ với cùng payload.
Vì thao tác đọc (read) chiếm 65~90% số token trong các phiên coding agent, kiểu lãng phí này âm thầm tích tụ. Các công cụ observability có thể cho thấy trace, nhưng không nói bước nào là trùng lặp.
Phát hiện những gì
Clew tìm ba mẫu trùng lặp:
repeat — cùng một tool/node bị gọi lặp lại
requery — cùng một tool bị gọi lại với cùng đầu vào (đầu ra giống hệt)
pingpong — hai agent qua lại với nội dung về bản chất là giống nhau (multi-agent)
Mỗi phát hiện được phân loại thành bốn nhóm:
error_repeat — đầu ra là lỗi nhưng vẫn lặp lại cùng lời gọi
side_effect — chạy lại công cụ làm thay đổi trạng thái (gửi/ghi/tạo, v.v.)
idempotent — lặp lại công cụ chỉ đọc hoặc mang tính khai báo (không có tác dụng phụ nhưng vẫn tốn token)
unclassified — công cụ không có trong mapping. Vì hiệu ứng phụ thuộc vào payload nên không suy luận chỉ từ tên công cụ (Bash/PowerShell, v.v.)
[Cách hoạt động]
Đây là cascade 2 giai đoạn:
Cổng cấu trúc — gom các lời gọi cùng một công cụ với cùng tham số (đã chuẩn hóa)
Cổng đồng nhất — kiểm tra xem sha256 của đầu ra có khớp hoàn toàn hay không. Nếu khác thì xem như trạng thái đã thay đổi và không gắn cờ
Bộ kiểm tra cấu trúc rẻ sẽ lọc ứng viên trước, còn kiểm tra ngữ nghĩa đắt hơn (embedding + cosine) chỉ chạy khi cần. Vì không có phán định của LLM nên kết quả là mang tính quyết định — điều này rất quan trọng nếu bạn muốn đưa vào CI.
[Định dạng đầu vào]
Claude Code — phân tích trực tiếp session JSONL
LangGraph — phát hiện trùng lặp chuỗi trong trace
LangChain·CrewAI·AutoGen·LlamaIndex, v.v. — phân tích trace được instrument theo định dạng chuẩn OpenTelemetry/OpenInference (mới là hỗ trợ định dạng, việc xác minh thực nghiệm theo từng framework vẫn đang được tiến hành)
Trace benchmark công khai (Toolathlon, RedundancyBench)
Cursor và Codex session hiện vẫn chưa được hỗ trợ — đang xem xét định dạng cục bộ của chúng.
[Kết quả xác minh]
Benchmark công khai (Toolathlon, 6.780 trace, 176.270 tool span):
Phát hiện 8.042 lời gọi trùng lặp. Trong đó 47% là vùng xám (thao tác idempotent, khai báo hoàn tất), loại trừ chúng thì còn 4.251 trường hợp (2,41% so với tool span). Cao gấp khoảng 3 lần so với các phiên Claude Code (0,80%).
Có 1.343 lần thực thi trùng lặp trên công cụ thay đổi trạng thái, bao gồm 459 lần gửi email lặp lại với cùng tham số. Tuy nhiên, đây chỉ là phát hiện rằng cùng một công cụ đã bị gọi trùng với cùng tham số; chưa xác nhận liệu tác dụng phụ thực sự có xảy ra hay không.
Benchmark gán nhãn (RedundancyBench):
precision 0.826 (ước lượng cận dưới cho trùng lặp trong cùng tệp). Một phần đáng kể nhãn RB là trùng lặp liên tệp (cross-file), nằm ngoài phạm vi của thiết kế phân tích theo từng phiên. recall thấp ở mức 0.157.
[Ranh giới trung thực]
Chưa có trường hợp tiết kiệm được đo đạc thực tế. Có thể phát hiện và ước tính, nhưng hiện chưa có dữ liệu before/after nào cho thấy người dùng thật đã sửa gì đó và hóa đơn thực sự giảm xuống.
47% những gì bị gắn cờ trong benchmark là vùng xám (chạy lại idempotent). Công cụ không lọc bỏ mà chỉ phân loại — vì việc một lần chạy lại chỉ đọc có phải là lãng phí hay không còn phụ thuộc vào ngữ cảnh mà ta không thể thấy được.
Vì yêu cầu khớp hoàn toàn theo sha256, nên chỉ cần đầu ra khác một chút là sẽ không bị gắn cờ. Đây là lý do recall thấp, và cũng là thiết kế ưu tiên precision.
Claude Code được tối ưu hóa đặc biệt tốt. Khi đo sáu mẫu lãng phí tiềm năng trong các phiên CC thực tế, có năm mẫu hoàn toàn không tồn tại ở đó. Sự lãng phí đáng chú ý xuất hiện không phải ở bản thân CC mà trong môi trường MCP đa công cụ.
Ước tính chi phí (amplification) là ước tính chứ không phải số đo thực, và chỉ khả dụng với định dạng Claude Code.
Những gì chưa được xác minh sẽ bị loại bỏ
Tôi từng làm một bộ phát hiện việc đọc lại tệp, nhưng trong 30 mẫu chú thích thủ công, precision thấp hơn rất nhiều so với ngưỡng đăng ký trước (70%) — ngay cả khi chấm thoáng cũng chỉ 3,3%, còn nghiêm ngặt thì 0% — nên đã loại bỏ. Dự đoán và kết quả đều được lưu lại cùng nhau trong tài liệu đăng ký trước.