Context dài chưa phải quyết định đúng

Context dài chưa phải quyết định đúng

GLM-5.2 có 1M-token context và effort mode mới, nhưng thứ builder cần quyết không phải model nào hot hơn: đó là workflow nào đáng đưa vào production.

10:17 sáng, Slack của team Sao Mai nổ một câu rất quen: model mới có 1M token context, mình có nên chuyển agent coding sang luôn không?

Một bạn backend thả emoji lửa. Một bạn infra hỏi giá. Tech lead thì im lặng ba phút, rồi nhắn: nếu nó đọc được cả repo, nó có sửa đúng cả repo không?

Đó là khoảnh khắc mình thích nhất trong mọi cuộc họp về AI tool: khi hype đụng vào vận hành. GLM-5.2 của Z.ai đáng chú ý thật: biến thể glm-5.2[1m] có context window 1.000.000 token, output tối đa 131.072 token, thêm hai mức thinking effort là High và Max. Nhưng nếu bạn đang build hệ thống AI coding agent, câu hỏi hay hơn không phải là model này có mới không. Câu hỏi là: workflow nào thật sự hưởng lợi từ context dài, và workflow nào chỉ đang chất thêm giấy tờ lên bàn một nhân viên mới chưa được onboard?

Sơ đồ minh họa cho bài Context dài chưa phải quyết định đúng

Sơ đồ tóm tắt ý chính của bài viết.

Việc đang xảy ra: cuộc đua không còn chỉ là trả lời hay

GLM-5.2 không xuất hiện trong khoảng trống. Gần đây, nhiều release đang kéo builder về cùng một hướng: model phải làm việc được trong phiên dài, nhiều file, nhiều tool, nhiều bước.

Z.ai đặt cược vào 1M-token context cho coding agent. MiniMax M3 cũng đi theo hướng long-context, agentic coding và multimodal, tức xử lý được text, image, video trong workflow phát triển phần mềm. Zyphra với Zamba2-VL lại chọn hướng khác: vision-language model, tức model đọc được cả ảnh và chữ, nhưng dùng kiến trúc hybrid Mamba2–Transformer để giảm mạnh độ trễ phản hồi đầu tiên. Còn các tối ưu kiểu FlashAttention-3 nhắc chúng ta rằng tốc độ inference, tức tốc độ model chạy khi phục vụ request thật, không phải chi tiết phụ.

Nói gọn: thị trường đang dịch từ model trả lời đúng trong demo sang model chịu được ca làm việc dài trong sản phẩm.

Nhưng GLM-5.2 có một chi tiết khiến mình phải gạch bút đỏ: lúc launch, Z.ai chưa công bố benchmark như SWE-bench, Terminal-Bench hay Code Arena. Không có nghĩa model yếu. Chỉ có nghĩa là builder chưa nên thay cả pipeline chỉ vì một con số context sáng loáng.

Va chạm của team Sao Mai: đọc được hết repo vẫn có thể sửa sai

Team Sao Mai đang có một monorepo vừa phải: service Python, một ít frontend, CI lắt nhắt, tài liệu nội bộ rải trong Markdown. Agent hiện tại hay vấp ở refactor nhiều file: sửa schema ở một chỗ, quên test ở chỗ khác, rồi tự tin báo xong.

Khi nghe GLM-5.2 có 1M-token context, phản xạ đầu tiên rất dễ hiểu: nhét toàn bộ repo vào prompt cho khỏe. Khỏi RAG. Khỏi chunking. Khỏi mất công chọn file.

Hình dung thế này: bạn giao một nhân viên mới đọc hết Notion, Jira, Slack export và repo trong ngày đầu. Người đó có thể nhìn thấy mọi thứ, nhưng chưa chắc biết ưu tiên nào quan trọng, quy ước nào còn dùng, ticket nào đã lỗi thời. Context dài cũng vậy. Nó mở rộng trí nhớ làm việc, nhưng không tự biến thành phán đoán kỹ thuật.

Ở đây có ba rủi ro:

  1. Context window — vùng ngữ cảnh model giữ trong một lượt xử lý — càng dài thì càng dễ khiến team lười thiết kế input. Đưa nhiều không đồng nghĩa đưa đúng.
  2. Thinking effort — mức ngân sách suy luận model dùng trước khi trả lời — nếu bật Max cho mọi việc, bạn có thể mua thêm chất lượng ở task khó nhưng cũng mua thêm độ trễ và chi phí.
  3. Không có benchmark launch nghĩa là team phải tự đo theo workload của mình, nhất là agent loop: plan, edit, test, fix.

Điểm dễ hiểu sai là nghĩ 1M token sẽ thay thế orchestration. Orchestration là lớp điều phối nhiều bước, nhiều tool hoặc nhiều agent. Trong production, nó vẫn cần để quyết định lúc nào đọc repo, lúc nào chạy test, lúc nào rollback, lúc nào hỏi người thật.

Bóc lớp kỹ thuật: 1M token mua cho bạn điều gì?

Mình sẽ không phủi tay bảo context dài chỉ là marketing. Với coding agent, 1M token có vài lợi ích rất thật.

Một là giảm tóm tắt cưỡng bức. Với context nhỏ, agent thường phải summarize, tức nén lịch sử và file liên quan thành bản tóm tắt. Nén thì mất chi tiết. Mất chi tiết thì dễ sửa nhầm edge case. Context dài giúp giữ nhiều file, test, config và lịch sử trao đổi trong cùng một phiên.

Hai là tốt hơn cho refactor xuyên file. Ví dụ cụ thể: giả sử team bạn muốn đổi cách validate dữ liệu trong 40 file Python. Nếu agent thấy được source, test, config và convention cùng lúc, nó có cơ hội lần theo dependency tốt hơn việc cứ mở từng file theo kiểu đoán mò.

Ba là hỗ trợ long-horizon run. Đây là các phiên agent kéo dài qua nhiều bước: lập kế hoạch, sửa code, chạy test, đọc lỗi, sửa tiếp. Nguồn về GLM-5.2 nhắc lại GLM-5.1 từng duy trì khoảng 1.700 agent steps trong một phiên. Với GLM-5.2, thông điệp rõ ràng là nhắm vào phiên làm việc dài hơn, ít đứt mạch hơn.

Nhưng builder cần hỏi tiếp: model có dùng được context đó một cách ổn định không? Một nhân sự vào daily standup mà nghe hết mọi người nói vẫn có thể bỏ sót blocker quan trọng. Model cũng có thể có hiện tượng lẫn thông tin, ưu tiên sai file, hoặc bám vào đoạn cũ đã bị thay đổi.

Framework 3P: chọn model theo phiên làm việc, không theo poster launch

Nếu là tech lead, mình sẽ không hỏi: GLM-5.2 có hơn model đang dùng không? Mình sẽ dùng khung 3P: Phiên, Phí, Phanh.

1. Phiên: task của bạn dài thật hay chỉ dài vì input bừa?

Hãy phân loại task coding agent thành ba nhóm:

| Nhóm task | Có cần 1M context? | Gợi ý |
|---|---:|---|
| Sửa bug một file, viết unit test nhỏ | Thường không | Dùng model nhanh, context vừa đủ |
| Refactor nhiều module, migration API | Có thể có | Thử GLM-5.2 hoặc MiniMax M3 với repo snapshot |
| Điều tra lỗi qua log, ảnh, video, UI | Tùy dữ liệu | Cân nhắc model multimodal hoặc VLM |

MiniMax M3 đáng nhìn nếu workflow của bạn không chỉ có code text mà còn dính screenshot, video, desktop task. Zamba2-VL lại gợi ý một hướng khác cho app cần đọc tài liệu ảnh, biểu đồ, giao diện: không phải mọi vấn đề đều cần coding model khổng lồ.

2. Phí: effort mode phải gắn với độ khó, không bật Max như mặc định văn phòng

GLM-5.2 có High và Max. Trong Claude Code, các tùy chọn như xhigh, max, ultracode map sang Max effort.

Đừng để mọi ticket chạy Max chỉ vì nghe có vẻ cẩn thận. Hãy đặt rule:

High:
- sửa bug có phạm vi rõ
- viết test
- giải thích module

Max:
- refactor nhiều file
- migration có rủi ro dữ liệu
- agent tự chạy nhiều vòng plan/edit/test/fix

Effort mode giống OKR nội bộ: không phải việc gì cũng là ưu tiên cấp công ty. Nếu task nhỏ mà dùng chế độ nặng nhất, bạn có thể đang đổi vài dòng code lấy một hóa đơn token không vui.

3. Phanh: trước khi production, phải có cách dừng agent

Đây là phần ít sexy nhất nhưng cứu team nhiều nhất.

Với long-context agent, hãy thêm ba phanh:

Nếu không có phanh, context dài chỉ làm agent có thêm không gian để đi xa hơn trước khi bạn phát hiện nó đi lệch.

Điều đáng giữ lại: long context là năng lực kiến trúc, không phải chiến thắng tự động

Điểm mình muốn giữ từ GLM-5.2 là: 1M-token context có thể đổi cách thiết kế coding agent.

Trước đây, nhiều pipeline phải chia repo thành chunk, dùng RAG — retrieval-augmented generation, tức truy xuất tài liệu liên quan rồi đưa vào prompt — và liên tục tóm tắt lịch sử. Với context dài hơn, bạn có thêm lựa chọn: nạp repo snapshot lớn hơn, giữ lịch sử dài hơn, giảm số lần retrieve.

Nhưng đừng vội vứt RAG. Với repo lớn, tài liệu cũ, log nhiễu, hoặc nhiều branch, retrieval vẫn giúp chọn đúng phần liên quan. Context dài nên là phòng họp rộng hơn, không phải lý do mời cả công ty vào một cuộc họp 15 phút.

Tín hiệu từ FlashAttention-3 và Zamba2-VL cũng nhắc thêm: production không chỉ cần thông minh. Nó cần độ trễ hợp lý, throughput ổn, và kiến trúc phục vụ được user thật. Một model chậm ở time-to-first-token — thời gian chờ token đầu tiên — có thể làm trải nghiệm agent giống như đồng nghiệp seen tin nhắn nhưng mãi chưa trả lời.

Còn câu chuyện Pyodide wheels lên PyPI thì tưởng xa mà gần: release dùng được thật không chỉ nằm ở model. Nó còn nằm ở cách đóng gói, phân phối, tích hợp vào workflow. AI tooling trưởng thành khi developer cài, chạy, rollback và tự động hóa được, chứ không phải khi landing page đẹp hơn.

Điều nên bỏ qua: benchmark trống không phải drama, nhưng là tín hiệu cần tự đo

Z.ai không đưa benchmark lúc launch. Mình không xem đó là lý do gạt GLM-5.2 khỏi bàn. Nhưng nó là lý do để không mua niềm tin bằng cảm giác.

Trong một buổi chiều, team builder có thể tự dựng bài kiểm tra nhỏ:

  1. Chọn 3 task thật trong repo: một bug, một refactor, một test-generation.
  2. Chạy model hiện tại và GLM-5.2 trên cùng branch.
  3. Ghi lại: số vòng agent, số file sửa, test pass/fail, diff phải sửa tay, thời gian chờ, token dùng.
  4. Chạy mỗi task ít nhất vài lần nếu có ngân sách, vì agent rất dễ dao động giữa các run.
  5. Review diff như review PR thật, không chấm bằng cảm giác trả lời hay.

Kết quả bạn cần không phải model nào thắng mọi ô. Bạn cần biết task nào đáng chuyển, task nào giữ nguyên, và task nào nên thiết kế lại workflow.

Sau bài này, thứ mình mong bạn nghĩ khác là: context dài không phải lời mời nhét mọi thứ vào prompt; nó là cơ hội thiết kế lại phiên làm việc của agent cho có kỷ luật hơn.

Nếu là mình, mình sẽ thử GLM-5.2 trước ở refactor nhiều file và agent run dài, giữ model nhanh hơn cho việc nhỏ, và chỉ bật Max effort khi ticket thật sự xứng đáng. Nhân viên mới đọc hết tài liệu công ty vẫn cần brief rõ; model 1M token cũng không ngoại lệ — không thì nó sẽ chăm chỉ làm sai, rất chuyên nghiệp.

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

Nguồn tham khảo