Playbook cắt token thừa cho agentic workflow

Playbook cắt token thừa cho agentic workflow

Agent CI chạy hàng trăm lượt mỗi ngày mà không ai nhìn hoá đơn. Đây là playbook bốn bước giúp team Việt Nam tìm và loại token lãng phí trong production.

Bao nhiêu token mỗi ngày đang bay vào... không khí?

Một workflow chạy trung bình 6-7 lần/ngày, mỗi lần gọi LLM cả chục turn — nhưng team bạn có biết bao nhiêu token trong đó thực sự cần LLM suy luận, và bao nhiêu chỉ là copy-paste context mà CLI đọc file tốt hơn?

GitHub vừa công bố kết quả tối ưu token trên chính hệ thống agentic workflow nội bộ của họ. Con số đáng chú ý: một workflow giảm được 62% Effective Tokens chỉ bằng cách bỏ đi những thứ không cần thiết. Không phải nâng model, không phải viết lại agent — chỉ là dọn dẹp.

Bài này là playbook bốn bước để bạn làm điều tương tự cho hệ thống agent đang chạy production.

Mục tiêu: biết rõ từng đồng token đang đi đâu

Nếu bạn đang vận hành agent CI — auto-triage issue, review PR, chạy lint tự động — mục tiêu không phải "giảm token" một cách mù quáng. Mục tiêu là tách bạch phần nào cần LLM suy luận, phần nào chỉ là data-fetching mà script thường làm tốt hơn.

Giống thợ mộc kiểm tra phôi gỗ trước khi đục: phần nào là thớ tốt giữ lại, phần nào là giác bỏ đi. Không phân biệt được thì phí cả khối gỗ.

Checklist trước khi bắt tay

Nếu 3/5 câu trên bạn trả lời "không" hoặc "chưa chắc" — đó chính là lý do token đang rò rỉ mà không ai hay.

Bốn bước cắt token thừa

Bước 1 — Bật observability ở tầng proxy

Mỗi agent framework (Claude CLI, Copilot CLI, Codex CLI) log khác format. Cách GitHub giải quyết: đặt một API proxy giữa agent và LLM provider. Proxy này ghi lại mọi request dưới dạng chuẩn — token-usage.jsonl — bao gồm input tokens, output tokens, cache-read tokens, model, timestamp.

Với team Việt Nam đang dùng nhiều framework khác nhau, bước này quan trọng nhất: một điểm thu thập duy nhất, format chuẩn, bất kể agent nào gọi.

Giả sử team bạn 4 người, chạy 5 workflow khác nhau trên GitHub Actions. Không có proxy log thì mỗi người tự đoán workflow nào tốn — proxy cho bạn dữ liệu thật.

Bước 2 — Audit: tìm workflow nào đang "ăn" nhiều nhất

Sau khi có log, bước tiếp là tổng hợp. GitHub dựng một Daily Token Usage Auditor — chính nó cũng là agent — đọc artifact từ các run gần đây, flag workflow nào tăng usage bất thường.

Bạn không cần build auditor agent ngay. Bắt đầu bằng script đơn giản:

# Tổng hợp token usage từ artifact
jq -s 'group_by(.workflow) | map({workflow: .[0].workflow, total_input: (map(.input_tokens) | add), total_output: (map(.output_tokens) | add), runs: length})' token-usage.jsonl

Một metric đáng áp dụng: Effective Tokens (ET) — công thức chuẩn hóa chi phí qua các model tier:

ET = m × (1.0 × Input + 0.1 × CacheRead + 4.0 × Output)

Trong đó m là hệ số model (Haiku ≈ 0.25, Sonnet ≈ 1.0, Opus ≈ 5.0). Output tokens mang trọng số 4× vì đắt nhất. Cache-read chỉ 0.1× vì phục vụ từ cache rẻ hơn nhiều.

Metric này giúp so sánh công bằng giữa workflow dùng model rẻ và workflow dùng model đắt.

Bước 3 — Cắt MCP tools không dùng

Đây là nguồn lãng phí phổ biến nhất mà GitHub phát hiện. Khi đăng ký MCP server với 40 tools, toàn bộ schema — tên function, JSON schema — được gửi kèm mỗi lần gọi API. Nói thẳng: 38 tools bạn không dùng vẫn ngốn 10-15 KB context mỗi turn.

Cách xử lý:

  1. Lấy log tool_calls thực tế từ N run gần nhất
  2. So sánh với danh sách tools đăng ký
  3. Tool nào không xuất hiện trong 30 ngày → loại khỏi config

GitHub ghi nhận: bỏ unused tools giảm per-call context 8-12 KB, tiết kiệm vài nghìn token mỗi run mà không thay đổi hành vi.

Bước 4 — Chuyển data-fetching ra khỏi LLM loop

Đây là bước mang lại hiệu quả lớn nhất. Nhiều agent turn chỉ là fetch PR diff, đọc file content, lấy review comments — hoàn toàn deterministic (xác định trước, không cần suy luận). Mỗi lần agent gọi MCP tool để fetch data, nó tốn một full reasoning turn: formulate arguments → gọi tool → nhận output vào context.

Hai chiến lược thay thế:

Pre-agentic download: Data mà agent chắc chắn cần (diff, changed files) — fetch bằng gh CLI ở setup step, ghi ra file. Agent đọc file thay vì gọi MCP.

CLI proxy cho runtime fetch: Khi agent cần quyết định fetch gì lúc chạy — dùng lightweight HTTP proxy route traffic đến REST API, agent chạy gh pr view --json như terminal bình thường.

Cả hai cách đều đưa phần data-fetching ra khỏi vòng suy luận LLM — giống bào phẳng mặt gỗ trước khi đưa thợ chạm: bớt việc thô cho phần cần tay nghề.

Ba cái bẫy team nào cũng có thể vấp

Bẫy 1: Tối ưu token nhưng giảm chất lượng mà không hay. Workflow nhẹ hơn chưa chắc đã tốt hơn — có thể nó đang làm ít việc hơn. Theo dõi song song: turn count ổn định + token-per-call giảm = tối ưu thật. Cả hai cùng giảm = có thể agent đang skip việc.

Bẫy 2: Một dòng config sai gây loop vô tận. GitHub kể trường hợp thực tế: workflow copy file sang /tmp/ rồi chạy glob, nhưng sandbox chỉ cho phép relative path. Agent không dùng được tool → rơi vào 64-turn fallback loop, tự đọc source code thay compiler. Một dòng allowlist fix xong. Bài học: guardrail thiếu hoặc sai không chỉ chặn agent — nó biến agent thành cỗ máy đốt token.

Bẫy 3: Tối ưu workflow ít chạy, bỏ quên workflow chạy nhiều. Workflow chạy 7 lần/ngày tiết kiệm 30% > workflow chạy 1 lần/ngày tiết kiệm 60%. Ưu tiên theo tần suất × ET-per-run, không phải theo % tiết kiệm đơn lẻ.

Bước tiếp theo cho team bạn

  1. Tuần này: Thêm API proxy logging cho workflow agent chạy nhiều nhất. Chỉ cần output jsonl với input/output/cache tokens.
  2. Tuần sau: Chạy audit script, xác định top 3 workflow tốn ET nhất. Kiểm tra unused MCP tools.
  3. Tháng này: Chuyển ít nhất 1 data-fetching step sang pre-agentic CLI. Đo ET trước/sau.

Đừng cố tối ưu tất cả cùng lúc. Chọn workflow chạy thường xuyên nhất, cắt phần thô rõ ràng nhất. Kết quả sẽ compound nhanh hơn bạn nghĩ — GitHub thấy một workflow tiết kiệm khoảng 7.8 triệu ET tích lũy chỉ vì nó chạy đủ thường xuyên.

LLM call rẻ nhất là call bạn không cần gọi.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo