# Context Language Models: agent tự sửa context thay vì compaction

[Muhammad Farooq](https://homus.dev/speakers/muhammad-farooq) · [Prompt Engineering](https://homus.dev/orgs/prompt-engineering)

> Context language model để agent tự sửa context như một file thay cho /compact, thử pi-clm với Qwen3.8-27B local và các gotcha về harness, cache, chi phí.

Topics: Context Engineering, Agents, Coding Agents

Canonical: https://homus.dev/talks/context-language-models-your-agent-doesnt-need-compaction

## 1. Context management là nút thắt của agent

Muhammad mở đầu bằng nhận định: quản lý context là một trong những nút thắt thật sự của agent hiện nay. Khi agent tiến gần tới cuối context window, chúng ta buộc nó tóm tắt (summarize) toàn bộ những gì đã xảy ra từ đầu tới giờ. Và ở đâu đó trong quá trình ấy, thông tin quan trọng nhất có thể bị vứt đi.

Vậy nếu thay vì tóm tắt, ta để agent tự chỉnh sửa context window của chính nó thì sao? Đó chính xác là điều mà nhóm nghiên cứu ở Meta và University of Washington đã làm trong một paper mới có tên Context Language Models (CLM). Trước khi giải thích cách nó hoạt động, anh cho xem một demo ngắn.

![Hình trong paper Context Language Models: context dạng file c_t đi qua hàm f theta CLM thành context dạng file c_t+1](https://homus.dev/photos/Bgtr1Ue40Jo-0023.jpg)

Ý tưởng cốt lõi của paper: context ở bước t được coi là một file (context as a file), đi qua một hàm do model sinh ra ("any function of the context"), và kết quả là file context cho bước t+1.

## 2. Demo: agent tự dọn context của chính nó

Trên màn hình là Pi, coding agent mã nguồn mở, đang chạy local trên chiếc DGX Spark của anh với model Qwen3.8-27B. Anh giao cho nó một chồng log ca làm việc của một nhà kho (16 file log), nhiều hơn hẳn những gì context window của nó chứa được (ngân sách 32K token). Đoạn demo được tua nhanh 2,3 lần; ở góc dưới terminal có một dòng đếm kiểu "clm 14.2k / 32.8k", tức context hiện tại so với ngân sách.

Bình thường, tới lúc này harness sẽ nhảy vào và viết một bản summary để giữ lại context. Nhưng hãy nhìn điều đang xảy ra ở đây: agent mở một file, và file đó chính là context của nó. Nó lấy đoạn log khoảng 3.000 token mà nó đọc từ vài lượt trước và thay bằng một dòng duy nhất, dòng này vẫn giữ đúng thông tin mà đoạn context kia cung cấp.

![File LIVE_CONTEXT.md với các khối CTX_TURN user, assistant, toolResult chứa log ca ngày 1, chú thích its own context khoảng 3.000 token](https://homus.dev/photos/Bgtr1Ue40Jo-0103.jpg)

File `LIVE_CONTEXT.md` lấy từ lần chạy thử của anh: mỗi lượt là một khối có header `[[CTX_TURN index=... role=...]]`. Khối toolResult chứa nguyên log ngày 1, khoảng 3.000 token; đây là phần agent sẽ rút gọn thành một dòng.

Nếu nhìn vào panel bên cạnh, bạn sẽ thấy kích thước context leo lên sau mỗi file agent đọc, rồi tụt xuống mỗi lần model tự dọn dẹp sau chính nó.

![Biểu đồ context size per request: các cột tăng dần tới gần 26K rồi tụt xuống hai lần, đánh dấu model cleaned up, đường giới hạn 32K](https://homus.dev/photos/Bgtr1Ue40Jo-0123.jpg)

Biểu đồ kích thước context theo từng request trong lần chạy thử (task seals, pi-clm): cột tăng dần lên quanh 25K đến 26K, hai lần tụt mạnh xuống dưới 5K ở chỗ ghi "model cleaned up", và không bao giờ chạm vạch 32K.

Cái hay là không có luật nào quy định giữ gì, bỏ gì. Chính model quyết định đâu là thông tin quan trọng nhất. Phần còn lại của video, anh nói về cách nó hoạt động, cách bạn tự chạy nó, và vài gotcha anh gặp khi thử nghiệm, vì có một khoản chi phí rất dễ bị bỏ sót.

## 3. Mọi harness hiện nay xử lý context đầy theo cùng một cách

Trước hết là vì sao chuyện này quan trọng. Mọi agent harness hiện nay, như Claude Code, Codex hay Pi, xử lý context đầy theo cách rất giống nhau. Tại một ngưỡng cố định, ví dụ 75% context window, model viết một bản summary; harness giữ lại vài lượt cuối cùng và về cơ bản thay toàn bộ cuộc hội thoại trước đó bằng bản summary ấy. Nếu bạn dùng Codex hay Claude Code, bạn có thể tự kích hoạt việc này bằng slash command `/compact`.

Cách các harness hiện nay làm: khi context chạm ngưỡng cố định (ví dụ 75%), các lượt cũ bị thay bằng một khối summary, chỉ vài lượt cuối còn nguyên văn.

## 4. Vấn đề: summary được viết trước khi ai biết điều gì quan trọng

Nhưng đây là vấn đề. Giả sử agent của bạn đang debug một service, và 40 lượt trước nó đã đọc một file cấu hình, trong đó có một giá trị mà về sau hoá ra quan trọng nhất. Bản summary đã được viết trước khi bất kỳ ai biết giá trị đó sẽ quan trọng. Nếu giá trị ấy không lọt vào summary, nó coi như biến mất, và agent thậm chí không biết mình đang thiếu cái gì. Agent có thể tốn thêm nhiều thời gian lục lại log, hoặc đốt rất nhiều token để tìm lại nó.

Paper xây một benchmark nhỏ quanh đúng vấn đề này, gọi là ContextBench, gồm những task đơn giản như giữ cho một bảng Sudoku luôn được cập nhật trong khi các nước đi liên tục đổ vào. Trên benchmark đơn giản này, phần lớn các kỹ thuật compaction hiện có đều thất bại.

![ContextBench của Meta: hình Sudoku với edit cells, bảng Sudoku lớn với các ô vừa điền, mũi tên moves, các nhãn Summary, Self-Compact, ACM, RLM, Folding](https://homus.dev/photos/Bgtr1Ue40Jo-0303.jpg)

ContextBench: agent phải giữ bảng Sudoku đúng khi các nước đi (moves) liên tục tới, chỉ sửa đúng các ô thay đổi. Hàng nhãn bên dưới là các cách quản lý context được so sánh: Summary, Self-Compact, ACM, RLM, Folding.

## 5. Summary tốt hơn, compact thường hơn: vẫn chưa đủ

Một cách để xử lý là dùng prompt summary thông minh hơn, hoặc compact thường xuyên hơn. Cách này có thể giúp phần nào, nhưng vấn đề là compaction vẫn xảy ra tại một thời điểm cụ thể, và summary vẫn được viết ra. Cuối cùng bạn sẽ có một bản summary của các bản summary, và nó có thể làm mất toàn bộ những thông tin quan trọng nhất mà bạn muốn giữ.

## 6. Context language model là gì

Vậy context language model chính xác là gì? Với một language model bình thường, mỗi lượt chỉ cộng thêm vào cuối context. Context mới đưa vào model ở lượt kế tiếp bằng context cũ cộng với bất cứ thứ gì model vừa sinh ra.

Context language model thay dấu cộng đó bằng một hàm. Model quyết định toàn bộ context sẽ trông như thế nào ở lượt kế tiếp, nên nó có thể giữ, thu gọn, xoá hoặc viết lại bất cứ phần nào nó cần.

Khác biệt duy nhất nằm ở phép toán giữa hai lượt: language model thường cộng thêm output vào cuối, context language model thay dấu cộng bằng một hàm của toàn bộ context.

## 7. Cách hoạt động: context là một file

Cụ thể nó chạy như sau. Trước mỗi request, harness ghi context ra một file. Trong file đó, mỗi lượt là một khối có header riêng. Model có thể mở file, sửa nó bằng một đoạn script Python nhỏ, đúng như cách nó vẫn sửa code. Và bất cứ thứ gì còn lại trong file ở cuối lượt sẽ trở thành prompt tiếp theo. Đó chính là điều ta đã thấy trong demo.

![Sơ đồ How it works: harness ghi file LIVE_CONTEXT.md, mỗi khối có header CTX_TURN, robot agent cầm bút sửa file](https://homus.dev/photos/Bgtr1Ue40Jo-0423.jpg)

Harness (biểu tượng bánh răng) ghi từng lượt vào `LIVE_CONTEXT.md`, mỗi lượt mở đầu bằng một header như `[[CTX_TURN index=3 role=toolResult]]`. Agent (robot cầm bút) được quyền sửa chính file này.

## 8. Model tự nghĩ ra chiến lược riêng

Khi bạn trao cho model quyền kiểm soát kiểu này, nó tự nghĩ ra chiến lược của riêng nó. Trong paper, model tự đặt ra một role mới tên là "notes" chỉ để dùng cho chính nó. Nó viết một helper function nhỏ để compact các kết quả search cũ và gọi function đó 37 lần. Và trong một lần chạy multi-agent, nó giữ một bảng điểm (scoreboard) của 21 sub-agent ngay trong context của mình và cập nhật tại chỗ 163 lần.

![Its own strategies: helper def compact_turns gọi 37 lần trên old results; scoreboard theo dõi 21 subagents, BEST SO FAR 0.9992, 5 running](https://homus.dev/photos/Bgtr1Ue40Jo-0503.jpg)

Hai chiến lược model tự nghĩ ra: bên trái, helper `def compact_turns(...)` được gọi 37 lần để thu gọn các kết quả cũ; bên phải, một khối "## STATE" trong context theo dõi sub-agent với "BEST SO FAR 0.9992" và "AGENTS 21, 5 running".

## 9. Điều khiển bằng plain English, và kết quả trên BrowseComp-Plus

Cái hay nữa là bạn có thể kích hoạt compaction bằng những chỉ dẫn rất đơn giản bằng tiếng Anh thông thường. Ví dụ, nếu bạn nói kiểu như sau thì nó thật sự làm theo:

```
once you pass 24,000 tokens, compact down to 4,000
```

Chỉ vậy là đủ để thay đổi chính xác thời điểm model sẽ compact.

Theo paper, cách này hiệu quả trên BrowseComp-Plus, một benchmark về deep research. CLM đạt 59,4% với Qwen3.6-27B, cao hơn khoảng 11% so với cách dùng summary tốt nhất, trong khi tốn ít hơn khoảng một phần năm compute.

![Biểu đồ BrowseComp-Plus 32K peak ctx: accuracy theo prefix-reuse PFLOPs mỗi câu hỏi, CLM khoảng 60% được khoanh, Summary, Self-Compact, MEM1, RLM, Base, ACM; con số 59.4% Qwen3.6-27B](https://homus.dev/photos/Bgtr1Ue40Jo-0543.jpg)

Biểu đồ trong paper (BrowseComp-Plus, peak context 32K, model Qwen3.6-27B): trục dọc là accuracy, trục ngang là compute đo bằng PFLOPs mỗi câu hỏi có tính prefix reuse. CLM nằm cao nhất ở khoảng 6 PFLOPs, trong khi Summary thấp hơn và tốn compute hơn (quanh 7 đến 8). Các cách khác như RLM, Base, ACM, Self-Compact, MEM1 đều thấp hơn.

## 10. Tự chạy: extension pi-clm cho Pi

Vậy làm sao để tự chạy? Chính tác giả paper đã phát hành một extension cho Pi tên là pi-clm, và bạn cài nó chỉ bằng một lệnh. Trên màn hình, anh chạy lệnh cài, rồi mở Pi và gõ `/clm`:

```
$ pi install npm:@lolipopshock/pi-clm
Installed npm:@lolipopshock/pi-clm
$ pi
/clm
```

Slash command `/clm` mở ra đúng cái panel bạn đã thấy trong demo: kích thước context theo thời gian, và một trang cho thấy từng chỉnh sửa model đã làm, đặt cạnh nhau (side by side). Theo README của pi-clm, panel có các trang overview, input và edits; ngoài ra còn có `/clm-compact` để yêu cầu model tự compact ngay.

## 11. Thiết lập thử nghiệm và bài test warehouse logs

Để thử nghiệm, anh chạy với Qwen3.8-27B, serve local bằng vLLM trên DGX Spark. Paper dùng một phiên bản trước của model 27B, còn anh dùng bản mới nhất (tính tới video đăng ngày 05/10/2026). Paper đặt ngân sách 32.000 token cho model, nên anh giữ đúng ngân sách đó. Anh hứa sẽ để các thiết lập chính xác trong phần mô tả video cho ai muốn tái hiện.

Mục tiêu của anh là xem cách này trụ được tới đâu trên task thật. Anh dựng ba task khác nhau, đều không vừa trong context window, và chạy chúng với pi-clm lẫn cách summarization của Pi. Trên màn hình, ba task là: seal codes (16 ngày log), incident (9 log) và inventory (24 bin).

Một ví dụ chính là warehouse logs nhắc tới ở đầu video: log của 16 ngày, và agent phải theo dõi các mã niêm phong xe tải (truck seal code). Sau đó nó phải tìm ra mã nào bị huỷ (void) một ngày hoặc vài ngày sau, rồi liệt kê những mã vẫn còn hiệu lực. Anh nhấn mạnh đây là ví dụ tổng hợp (synthetic), đừng coi nó là benchmark. Nhưng anh tìm thấy vài điều rất thú vị mà context language model làm với nó.

![My test: 16 file warehouse logs, log day01 có dòng applied seal DPO-0609-RV được khoanh, mã đó bị VOID ở ngày 06, answer.txt still valid; Pi summary và pi-clm; case study synthetic 1 run each](https://homus.dev/photos/Bgtr1Ue40Jo-0723.jpg)

Bài test: 16 file log ngày. Trong `logs/day01.log` một dòng ghi seal `DPO-0609-RV` được gắn lên xe đi Bend; tới ngày 06 mã này bị VOID. Agent phải ghi vào `answer.txt` các mã còn hiệu lực. Cột bên trái cho thấy tổng log khoảng 39K, vượt vạch 32K. Hai đối thủ: Pi summary và pi-clm (`LIVE_CONTEXT.md`); nhãn bên phải ghi "case study, synthetic, 1 run each".

## 12. Baseline: summary của Pi bịa ra mã seal

Để có baseline, anh dùng cơ chế summarization mặc định của Pi, và ngay chính baseline đã cho ra vài điều thú vị. Pi tóm tắt ba lần. Anh đối chiếu từng bản summary với log gốc. Bản summary đầu liệt kê 12 mã seal, nhưng 11 trong số đó không tồn tại ở bất cứ đâu: model đã bịa ra chúng. Tới bản summary thứ ba, 14 trên 18 mã là bịa. Nó còn tự chế ra cả một dãy mã nằm ngay sát mã thật.

Đây là một trong những vấn đề chính của summary chồng summary: bạn mất rất nhiều thông tin, và agent, nhất là với model nhỏ, có thể hallucinate rất nhiều. Bản summary trông hoàn toàn tự tin, có ô đánh dấu đã xong và mục các bước tiếp theo, nên agent không có cách nào biết nó sai.

![Baseline Pi summary: summary 3 với 18 mã seal, phần lớn tô cam là bịa, 14/18 fake; mục Critical Context liệt kê UP8-1760-ER, UP8-1761-ER, UP8-1762-ER bị gạch là invented](https://homus.dev/photos/Bgtr1Ue40Jo-0803.jpg)

Summary thứ ba của Pi: 18 mã, các mã viền cam là không có trong log, tổng cộng "14 / 18 fake". Mục "Critical Context" cho thấy dãy bịa: từ mã thật `UP8-1759-ER` ở Day 11, model tự sinh `UP8-1760-ER`, `UP8-1761-ER`, `UP8-1762-ER` cho Day 12 tới 14, bị gạch và ghi "invented".

## 13. Agent trả lời đúng nhờ grep, và một thông tin deploy bị bỏ sót

Điều thú vị là agent vẫn ra được đáp án đúng bất chấp những bản summary đó. Nhưng lý do không phải vì nó nhớ. Nó quay lại đọc lại mọi file từ ổ đĩa bằng grep, dù prompt đã dặn rõ là không được làm vậy. Trên màn hình, lệnh nó chạy có dạng `cat logs/day01.log ... logs/day16.log | grep -i "seal"`, được ghi là "grep rescue", với kết quả 17 trên 18 và một dòng "missing" trong `answer.txt`.

Ở một task khác, sau một lần summary, agent kết luận rằng các log không hề chứa thông tin deploy nào. Nhưng thực tế dòng deploy nằm ngay đó, agent đã đọc nó rồi, chỉ là trong quá trình summarization nó bị bỏ qua hoàn toàn. Tất cả những điều trên là với summarization mặc định của Pi.

![Incident task: 9 file log gateway tới shipping, search được đánh dấu; câu agent sau summary The logs don't contain explicit deploy/rollback metadata bị gạch; dòng deploy-bot deploy v4.7.3 trong logs/search.log được khoanh](https://homus.dev/photos/Bgtr1Ue40Jo-0903.jpg)

Task incident với 9 log service (gateway, auth, orders, payments, inventory, search, email, billing, shipping). Sau một lần summary, agent nói "The logs don't contain explicit deploy/rollback metadata." Trong khi đó `logs/search.log` có ngay dòng 14:00:00 "deploy-bot deploy v4.7.3 started".

## 14. pi-clm trên cùng các task

Giờ đến pi-clm trên cùng những task đó. Model viết toàn bộ context của nó vào một khối notes duy nhất. Trong trường hợp này, khối notes theo dõi mọi mã seal đã được áp dụng, mọi mã đã bị huỷ, và việc cần đọc tiếp theo. Cả 18 mã đều chính xác. Trên hai task seal và incident, nó trả lời đúng mọi câu trừ một, trong khi Pi hoặc phải nhờ tới "grep rescue", hoặc bịa ra dữ liệu.

![LIVE_CONTEXT.md của pi-clm: khối CTX_TURN role=notes với PROGRESS read day01-14, danh sách APPLIED, VOIDED và NEXT; nhãn ba task seal codes 16 days, incident 9 logs, inventory 24 bins](https://homus.dev/photos/Bgtr1Ue40Jo-0923.jpg)

Context của pi-clm sau khi model tự sửa: ngoài lượt user ban đầu, mọi thứ gom vào một khối `role=notes` gồm PROGRESS (đã đọc day01 tới 14), APPLIED (5 trên 19 mã được hiển thị), VOIDED (`DPO-0609-RV` ngày 6, `1F1-2919-ZJ` ngày 14) và NEXT (đọc day15, day16 rồi ghi các seal còn hiệu lực vào `answer.txt`).

Phần tốt nhất là nó thật sự hoạt động và bạn dùng được ngay. Tuy vậy, có vài gotcha quan trọng cần nhớ. Theo anh, nếu bạn định xây dựng trên nền này, biết giới hạn quan trọng hơn biết điểm mạnh. Đây là điều anh luôn khuyên: hãy nhìn vào chỗ hệ thống thất bại, nhất là với những kiểu language model mới như thế này.

## 15. Gotcha 1: harness quan trọng hơn bạn nghĩ

Gotcha đầu tiên: harness quan trọng hơn bạn tưởng. Trong ba trên bốn lần chạy với cấu hình mặc định, model không hề tự sửa context của mình lần nào. pi-clm có một tấm lưới an toàn (safety net): khi context sắp tràn, nó thay các tool output cũ bằng một ghi chú ngắn. Và trong phần lớn trường hợp, chính lưới an toàn này làm hết việc.

Trên màn hình, các tool output cũ trong context bị thay bằng khối "[overflow guard]"; tool result ghi kiểu "(~3,516 tok) withheld over budget" kèm đường dẫn tới bản đầy đủ trong một thư mục tạm, tức nội dung gốc được cất vào thư mục withheld chứ không mất.

Lý do là parallel tool call. Model đọc bốn file trong một lượt và vượt qua các reminder (ngưỡng nhắc về ngân sách context) trước khi kịp phản ứng. Vì vậy nếu muốn dùng cách này, bạn cần bật hai thứ: chỉ một tool call mỗi lượt, và một ghi chú về kích thước context sau mỗi kết quả, đúng như cách harness của paper hoạt động. Với hai thiết lập đó, model đã tự sửa context của nó. (README cấu hình của pi-clm gọi đây là các "parity switch" để so với harness của paper, và khuyên để tắt khi dùng bình thường.)

## 16. Gotcha 2 và 3: prefix cache, chi phí và latency

Gotcha thứ hai là chi phí và latency. Khi một server như vLLM đọc prompt của bạn, nó lưu phần việc đã tính vào cache. Nếu không có gì thay đổi, nó có thể dùng lại phần đầu prompt đó; đây là prefix caching. Với context language model, vị trí model sửa trong file context rất quan trọng. Nếu nó sửa ở gần cuối file, phần lớn context vẫn được giữ và dùng lại như prefix cache, nên phản hồi sẽ nhanh hơn. Nhưng nếu nó bắt đầu sửa ở giữa file, mọi thứ sau điểm đó mất khỏi prefix cache, nghĩa là phải xử lý lại toàn bộ phần phía sau. Việc này không chỉ tăng latency mà còn tăng chi phí sinh.

![Gotcha 2 cache: sửa gần cuối thì phần trên được reused, sửa ở giữa thì phải re-read; biểu đồ time to first token đo trên DGX Spark với 38K context: append 0.28s, edit 90% 2.8s, edit 75% 6.6s, edit 50% 11.8s, edit 25% 16.3s, first block 19.6s](https://homus.dev/photos/Bgtr1Ue40Jo-1143.jpg)

Bên trái: sửa gần cuối (edit near end) thì phần trên được dùng lại, nhanh; sửa ở giữa (edit in middle) thì từ chỗ sửa trở xuống phải đọc lại. Bên phải, đo trên DGX Spark với context 38K, time to first token: chỉ nối thêm 0,28 giây; sửa ở vị trí 90% là 2,8 giây; 75% là 6,6 giây; 50% là 11,8 giây; 25% là 16,3 giây; sửa ngay khối đầu là 19,6 giây.

Gotcha thứ ba: nó không tự động rẻ hơn. Trong một lần chạy task seal, pi-clm xử lý khoảng gấp đôi số token so với Pi (trên màn hình: 216K so với 103K). Ở một lần chạy khác, chỉ 10% prompt lấy được từ cache, 90% còn lại phải tính lại. Paper cũng xây một cách sửa gọi là suffix cache reuse, giữ lại phần việc đã tính cho đoạn text không đổi nằm sau chỗ sửa. Nhưng tính tới video đăng ngày 05/10/2026, đó mới là một bản patch cho SGLang, chỉ cho một model trên một GPU, nên anh chưa thể thử.

## 17. Gotcha 4 và 5: model phải giỏi việc này, và prompt injection

Gotcha thứ tư: model phải giỏi việc này. Trong paper, model 9 tỷ tham số kém cách dùng summary 6 điểm cho tới khi họ train nó bằng reinforcement learning (trên màn hình, biểu đồ BrowseComp-Plus với Qwen3.5-9B ghi accuracy 28,8 trước RL và 42,5 sau RL). Ngoài ra, kết quả nổi bật của họ dùng một ngân sách nhỏ, 32.000 token, trong khi Qwen3.6-27B có context window 262K. Ở mức 128.000 token, CLM và summary về cơ bản hoà nhau.

Và một điều nữa về bảo mật. Nếu model có thể ghi vào memory của chính nó, thì một prompt injection cũng có thể làm vậy. Khi đó prompt injection sẽ ở lại qua các lượt. Đây là một trong những mối lo mà chính paper nêu ra.

Rủi ro paper tự nêu: khi model ghi được vào context của chính nó, một đoạn prompt injection lọt vào ở lượt 1 có thể được giữ lại qua các lượt sau.

## 18. Kết luận: summary viết một lần rồi được tin mãi mãi

Nhìn chung, Muhammad rất thích hướng đi này. Summary được viết một lần rồi được tin mãi mãi, và trong các lần chạy của anh, đó chính xác là chỗ mọi thứ đi sai. Để model tự quản lý context của nó đã giải quyết những vấn đề đó cho anh. Điều kiện chính là harness phải cho nó đủ chỗ để phản ứng, và bạn phải để mắt tới cache. Anh thấy đây là một cách tiếp cận rất thú vị và nghĩ sẽ còn nhiều phiên bản tiến hoá từ nó.

Cuối video, anh mời người xem chia sẻ trong phần bình luận: bạn sẽ dùng cách này cho việc gì, đã thấy thứ gì tương tự chưa, hoặc đang dùng cách nào để quản lý context window của mình.

## Nguồn và liên kết

- Tên gốc: Context Language Models: Your Agent Doesn't Need Compaction
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=Bgtr1Ue40Jo](https://www.youtube.com/watch?v=Bgtr1Ue40Jo)

- Kênh YouTube Prompt Engineering (Muhammad Farooq): [youtube.com/channel/UCDq7SjbgRKty5TgGafW8Clg](https://www.youtube.com/channel/UCDq7SjbgRKty5TgGafW8Clg)

- Paper Context Language Models (Meta và University of Washington) trên arXiv: [arxiv.org/abs/2609.37725](https://arxiv.org/abs/2609.37725)

- Mã nguồn nghiên cứu của paper: [github.com/facebookresearch/context-language-models](https://github.com/facebookresearch/context-language-models)

- pi-clm, extension cho Pi giúp agent tự quản lý context (lệnh cài, `/clm`, `/clm-compact`, cấu hình reminder và overflow guard): [github.com/lolipopshock/pi-clm](https://github.com/lolipopshock/pi-clm)

- Pi coding agent, package npm `@earendil-works/pi-coding-agent` ([npmjs.com/package/@earendil-works/pi-coding-agent](https://npmjs.com/package/@earendil-works/pi-coding-agent))

Nguồn: https://homus.dev/talks/context-language-models-your-agent-doesnt-need-compaction · cập nhật 2026-10-18