Hồi tháng 8 mình có viết về phase-scheduled activation và việc cắt context ở mức 80-95% — phần lớn là đoán ngược từ việc nhìn pipeline multi-agent của mình đốt token budget rồi tự chọn một ngưỡng nghe có vẻ hợp lý. Hóa ra đoán cũng không tệ. Ngày 21/9, AWS open-source Strands Harness, và trong release notes có đúng những con số mình từng đoán: truncate kết quả tool trên 1.500 token, kích hoạt tóm tắt khi context vượt 85%. Có người đã chạy benchmark thật. Còn mình thì chỉ chạy theo cảm giác.

Đó mới là chuyện đáng nói, không phải cái tít “AWS ra thêm một agent framework.” Strands Harness là harness tổng quát xây trên Strands SDK sẵn có, Apache 2.0, không phụ thuộc model cụ thể — Bedrock, Anthropic, OpenAI, Google, Ollama, LiteLLM, chọn tùy thích. Qua sáu benchmark (ALFWorld, GAIA, WebShop, Terminal-Bench 2.1, và vài cái khác), nó tốn ít hơn 28% token so với các harness khác cùng loại. Riêng trên Terminal-Bench 2.1, nó vượt điểm harness của chính Claude Code trong khi chi phí thấp hơn 77%. Đọc lại câu đó lần nữa. Không phải “gần bằng Claude Code với giá rẻ hơn.” Mà là tốt hơn, với một phần tư chi phí.

Tiền thực sự chảy đi đâu

Harness agent nào cũng rò rỉ ở cùng một chỗ: kết quả tool. Bạn gọi search API, đọc file, chạy shell command — kết quả thô đi thẳng vào context window, nguyên văn, mỗi lượt, mãi mãi, cho đến khi có thứ gì đó đẩy nó ra. Một lệnh grep -r trên repo cỡ vừa có thể đổ 8.000 token vào context cho một kết quả mà model chỉ cần khoảng 200 token là đủ hiểu. Nhân với một vòng lặp agent 40 lượt, bạn đang đốt tiền thật cho văn bản không ai đọc lần thứ hai.

Cách Strands Harness giải quyết đơn giản đến mức gần như xúc phạm: nếu kết quả tool vượt 1.500 token, cắt. Không phải một lượt tóm tắt, không gọi LLM để nén lại — một ngưỡng cắt cứng. Giả định đằng sau là nếu kết quả lớn đến vậy, tín hiệu hữu ích thường nằm ở đầu (thông báo lỗi, N kết quả đầu tiên, header file), phần đuôi là nhiễu. Sau đó, riêng khi toàn bộ context window vượt 85% mức sử dụng, nó mới chạy một lượt tóm tắt thật sự để nén lịch sử thay vì cắt thứ mới nhất.

Hai vấn đề khác nhau, hai công tắc khác nhau. Mình từng gộp “kết quả tool quá lớn” và “context sắp đầy” thành một vấn đề và giải bằng một lượt tóm tắt duy nhất — chậm hơn và tốn hơn việc chỉ kiểm tra rồi cắt. Tách hai chuyện này ra là kiểu quyết định chỉ đến được từ việc chạy benchmark thật, không phải từ trực giác.

Một bản rút gọn bạn có thể lấy dùng ngay

Không cần cả bộ SDK mới lấy được 80% lợi ích. Đại khái nửa phần truncation trông như thế này, viết dưới dạng middleware quanh bất kỳ lời gọi tool nào:

MAX_TOOL_RESULT_TOKENS = 1500
CONTEXT_SUMMARIZE_THRESHOLD = 0.85

def wrap_tool_result(result: str, token_counter) -> str:
    tokens = token_counter(result)
    if tokens <= MAX_TOOL_RESULT_TOKENS:
        return result
    # giữ phần đầu, ghi chú lại phần bị cắt — đừng cắt lặng lẽ
    head = token_counter.truncate(result, MAX_TOOL_RESULT_TOKENS)
    return f"{head}\n\n[...đã cắt, còn {tokens - MAX_TOOL_RESULT_TOKENS} token bị bỏ]"

def maybe_summarize(context, context_window_size):
    usage = context.token_count() / context_window_size
    if usage < CONTEXT_SUMMARIZE_THRESHOLD:
        return context
    return summarize_older_turns(context, keep_last_n_turns=3)

Chi tiết quan trọng: wrap_tool_result chạy trên từng lời gọi tool, rẻ và đồng bộ. maybe_summarize chạy hiếm, tốn một lượt gọi LLM, nên chỉ kích hoạt khi gần chạm trần thật sự. Nếu đảo ngược lại — tóm tắt liên tục, truncate hiếm — bạn sẽ trả tiền cho việc nén dữ liệu mà phần lớn thời gian không cần đến.

Chỗ mình không đồng ý hoàn toàn

Mình không nói ngưỡng cố định 1.500 token là đúng cho mọi trường hợp. Nó là default tốt cho shell output, grep file, response API — bất cứ thứ gì mà độ liên quan giảm dần theo vị trí. Nó là default tệ cho thứ như một bản dump schema SQL đầy đủ hay một payload JSON có cấu trúc dài, nơi field bạn cần có thể nằm ở node thứ 400 trên 500. Số liệu benchmark của AWS là số liệu tổng hợp trên sáu task; tổ hợp tool của agent bạn mới quyết định 1.500 là hào phóng hay khắc nghiệt. Đáng để đo tỷ lệ bị-truncate thực tế của bạn trước khi tin default mù quáng.

Thay đổi lớn hơn là tín hiệu mà release này phát ra: context engineering không còn là kỹ thuật thủ công mỗi team tự phát minh lại nữa, mà trở thành một kỷ luật được benchmark, công bố, có số liệu A/B thật đứng sau các ngưỡng. Sáu tháng trước, “ngưỡng truncate của bạn là bao nhiêu” là câu hỏi bạn trả lời bằng cái nhún vai và một con số nghe có vẻ ổn. Giờ có một bộ benchmark công khai bạn có thể chạy lên chính harness của mình để biết 1.500 token có thực sự đáng giá gì không, hay bạn đang để hiệu năng rơi rớt vì cắt quá tay.

Nếu bạn đang chạy một agent harness tự chế trong production, bài tập về nhà không phải là “chuyển sang Strands.” Mà là: lấy con số, chạy workload thật của bạn với cả hai ngưỡng, xem cái nào tổ hợp tool của bạn thực sự thưởng cho. Mình đã làm vậy. Hóa ra ngưỡng 80% cho việc tóm tắt mà mình đoán hồi tháng 8 gần đúng đến mức không đáng chỉnh, nhưng mình lại đang truncate kết quả tool quá dè dặt — 3.000 token thay vì 1.500. Cắt xuống, chạy lại cùng pipeline, chất lượng output y như cũ, số token mỗi lần chạy giảm rõ rệt. Sửa nhỏ, tiền free.