Một chia sẻ mới trong cộng đồng OpenClaw vừa nhắc đúng một chỗ mà rất nhiều anh em làm automation hay bỏ quên: chi phí token không chỉ đến từ prompt và output, mà còn đến từ dữ liệu rác bị kéo vào context.
Theo ví dụ được nêu, chỉ riêng một trang Yahoo Finance nếu đẩy nguyên HTML thô vào agent có thể ngốn tới khoảng 704 nghìn token. Sau khi lọc bỏ phần điều hướng, script, quảng cáo và markup thừa, lượng token còn khoảng 2,6 nghìn. Một số trang khác cũng giảm rất mạnh: Wikipedia từ khoảng 154 nghìn xuống 19 nghìn, còn Hacker News từ khoảng 8,6 nghìn xuống 859.
Đây không phải chuyện tối ưu lặt vặt. Với anh em đang chạy OpenClaw qua cron, heartbeat, MCP hay các pipeline nghiên cứu lặp đi lặp lại, kiểu lãng phí này có thể âm thầm đội chi phí lên rất nhanh.
Vì sao web fetch thường bị đội token quá mức?
Vấn đề nằm ở chỗ nhiều workflow lấy toàn bộ nội dung trả về từ web rồi ném thẳng vào context. Trong thực tế, phần mô hình cần thường chỉ là:
- tiêu đề
- đoạn mô tả chính
- nội dung bài viết hoặc bảng dữ liệu quan trọng
- một số metadata có giá trị
Nhưng HTML gốc lại kèm thêm rất nhiều thứ không giúp ích cho suy luận:
- menu điều hướng
- footer
- CSS class và cấu trúc layout
- JavaScript nhúng
- widget tracking
- quảng cáo
- khối nội dung lặp
Khi agent phải đọc đống này ở mỗi lượt chạy, anh em sẽ gặp đồng thời ba vấn đề:
- Tăng chi phí token
- Giảm chất lượng suy luận vì nhiễu quá nhiều
- Làm chậm pipeline và bào mòn quota nhanh hơn dự tính
Bài học đáng chú ý cho người vận hành OpenClaw
Điểm hay của chủ đề này là nó không chỉ dành cho người tối ưu hệ thống lớn. Ngay cả một máy cá nhân chạy vài job mỗi ngày cũng nên rà lại cách fetch dữ liệu web.
Nếu anh em đang có các tác vụ như:
- theo dõi giá hoặc tin thị trường
- quét bài viết để tóm tắt
- tổng hợp đối thủ cạnh tranh
- đọc changelog, docs hoặc forum
- lấy dữ liệu từ website rồi đưa vào báo cáo
thì việc lọc nội dung trước khi vào context gần như là bước bắt buộc chứ không còn là tùy chọn.
Cách làm thực chiến để cắt lãng phí
Một hướng đơn giản là biến tầng web fetch thành pipeline hai bước:
1. Thu thập nội dung
Ở bước đầu, cứ lấy dữ liệu từ web như bình thường.
2. Rút gọn trước khi đưa vào model
Trước khi đẩy sang LLM, hãy làm sạch dữ liệu bằng một trong các cách sau:
- chuyển HTML sang markdown/text sạch
- chỉ giữ vùng article/main content
- loại bỏ script, style, nav, footer
- cắt theo selector hoặc schema cụ thể
- tóm tắt sơ bộ ở tầng scraping trước khi gọi model lớn
Nếu workflow của anh em chạy lặp lại nhiều lần, nên chuẩn hóa luôn thành một lớp tiền xử lý cố định thay vì vá từng prompt.
Khi nào nên đầu tư thêm một MCP chuyên xử lý nội dung?
Bài chia sẻ gốc có nhắc tới một công cụ hoạt động theo dạng MCP server để OpenClaw có thể nhận nội dung đã được làm sạch tốt hơn. Đây là hướng hợp lý nếu anh em có một trong các dấu hiệu sau:
- thường xuyên fetch web ở quy mô lớn
- dùng model đắt tiền cho các job định kỳ
- có nhiều nguồn web với HTML nặng
- đã bắt đầu thấy chi phí tăng nhưng chưa rõ nguyên nhân
Lợi ích của việc tách lớp này ra thành MCP hoặc service riêng là anh em có thể kiểm soát ổn định hơn:
- đầu vào sạch hơn
- prompt đơn giản hơn
- dễ audit log và đo token
- dễ thay thế model mà không phải viết lại cả pipeline
Đây là chuyện chi phí, nhưng cũng là chuyện chất lượng
Nhiều người nghĩ tối ưu token chỉ để tiết kiệm tiền. Thực ra phần lợi hơn thường nằm ở chất lượng đầu ra. Một agent đọc 2 nghìn token sạch gần như luôn đáng tin hơn một agent phải bơi trong vài trăm nghìn token HTML lộn xộn.
Nói ngắn gọn: đầu vào gọn thì đầu ra mới sắc.
Gợi ý kiểm tra nhanh cho anh em đang chạy OpenClaw
Nếu muốn tự audit hệ thống của mình, anh em có thể kiểm tra nhanh theo checklist này:
- log hiện tại có lưu raw HTML vào context không
- mỗi lượt fetch web đang tốn khoảng bao nhiêu token
- phần nào của nội dung thực sự được mô hình sử dụng
- có thể rút xuống markdown sạch hoặc structured data không
- job nào chạy nhiều lần nhất để ưu tiên tối ưu trước
Chỉ cần sửa đúng vài workflow fetch web nặng, anh em có thể giảm đáng kể chi phí hàng tuần mà không cần đổi model hay cắt bớt tính năng.
Kết luận
Điểm đáng giá nhất từ chủ đề này không phải là một con số gây sốc, mà là lời nhắc rất thực tế: đừng để tầng thu thập dữ liệu phá hỏng economics của cả hệ agent.
OpenClaw mạnh ở khả năng ghép nhiều công cụ và workflow lại với nhau. Nhưng càng ghép nhiều, anh em càng phải để ý chất lượng dữ liệu đầu vào. Nếu không, hệ thống nhìn thì thông minh mà thực tế lại đang đốt token vào những thứ mô hình không cần đọc.
Với anh em đang vận hành agent hàng ngày, đây là một tối ưu nhỏ nhưng tác động rất lớn.
Top comments (0)