TECHDEV · Flagship · Công cụ mã nguồn mở
context-diet
Chế độ ăn xác định cho context của agent — mọi lần cắt đều được ghi sổ, không bịa ra gì cả. Công cụ thu gọn nội dung tích lũy trước khi tới model, và chứng minh mọi lần cắt bằng manifest.
TypeScript · MCP server + CLI · MIT · Node 20+ · Thư viện runtime: MCP SDK, zod · Không dùng model, không dùng mạng, không chạy shell.
Vì sao context cạn kiệt
Coding agent không cạn context vì một file lớn duy nhất. Chúng cạn vì tích lũy: output của tool, log test, log build, các lượt lặp lại, và cùng một nội dung được dán lại dưới dạng mới. Context Diet thu gọn nội dung tích lũy đó trước khi tới model — và chứng minh mọi lần cắt bằng manifest.
Công cụ làm gì
Context Diet là MCP server (kèm CLI) với sáu công cụ:
| Công cụ | Việc làm |
|---|---|
diet_count | Số dòng, số byte và số token ước tính của một đoạn text |
diet_dedupe | Loại dòng trùng lặp và khối lặp lại (các trace chỉ khác địa chỉ 0x cũng gộp lại, lần xuất hiện đầu tiên được giữ nguyên văn) |
diet_extract | Trích đoạn xếp hạng theo mức liên quan cho một truy vấn |
diet_summarize | Tóm tắt trích xuất theo ngân sách token |
diet_pack | Toàn bộ pipeline + manifest cho từng dòng |
diet_check | Kiểm tra đầy đủ kế hoạch-so-với-thực thi: những mục đã lên kế hoạch nào còn sống sót trong output |
Cam kết cốt lõi
Các dòng output luôn được sao chép nguyên văn từ input. Context Diet không bao giờ bịa, diễn đạt lại hay viết lại text. Nếu một chi tiết quan trọng, nó hoặc nằm trong output, hoặc được đếm trong manifest — không bao giờ bị viết lại âm thầm.
Dòng gần trùng
Các stack trace lặp lại chỉ khác địa chỉ bộ nhớ 0x sẽ gộp về lần xuất hiện đầu tiên, được giữ nguyên văn kèm vị trí; các vị trí sau chỉ được đếm (không giữ) và báo cáo riêng khỏi các dòng trùng chính xác trong manifest. Hex trần không có tiền tố 0x, timestamp và PID được giữ nguyên chính xác, vì chúng có thể là định danh có ý nghĩa. Đây là so khớp text, không phải chứng minh hai lỗi có cùng cách sửa. Truyền --exact-only (CLI) hoặc exactOnly (MCP) để so khớp byte-identical nghiêm ngặt.
Dòng được bảo vệ
Truyền các dòng nguyên văn phải sống sót (protectLines trong diet_summarize/diet_pack, --protect-file trong CLI). Chúng được giữ trước tiên, trước cả dòng lỗi. Nếu chỉ riêng chúng đã vượt ngân sách, chế độ fail (mặc định) sẽ báo lỗi thay vì bỏ chúng; chế độ partial giữ chúng và gắn cờ shortfall chỉ để chẩn đoán. Manifest của pack báo cáo số dòng được bảo vệ đã giữ so với bị thiếu. Bảo vệ là danh sách do người gọi khai báo rõ ràng, không bao giờ là mẫu đoán mò, và công cụ này không phát hiện mâu thuẫn ngữ nghĩa giữa các yêu cầu: báo cáo vượt ngân sách/thiếu, nêu tên mọi dòng được bảo vệ đang bị đe dọa, chính là báo cáo xung đột — nó không bao giờ âm thầm chọn yêu cầu nào để bỏ.
Kiểm tra đầy đủ
Đưa cho diet_check (hoặc CLI check) một kế hoạch — những mục đáng lẽ phải xuất hiện, ví dụ tên test — và một output, có thể đã được cắt gọn. Mỗi mục được coi là tìm thấy khi có dòng output chứa nó nguyên văn dưới dạng chuỗi con (phân biệt hoa thường); mỗi mục tìm thấy đều kèm dòng bằng chứng, và các mục thiếu được liệt kê theo tên. Kết quả là bản ghi sidecar bền vững: giữ nó ngoài artifact đã cắt gọn, không bao giờ nối thêm vào bên trong artifact. Kênh báo động tách riêng: CLI thoát khác 0 khi kiểm tra thất bại, nên CI đỏ đúng lúc một sentinel không sống sót. Yên lặng khi ổn, ồn ào khi hỏng. Kiểm tra này một chiều theo thiết kế — nó không phát hiện các mục đã thực thi nhưng không có trong kế hoạch — và định danh ngắn có thể false-positive bên trong định danh dài hơn, nên hãy dùng định danh cụ thể.
Chế độ marker (tùy chọn): truyền marker thực thi và một dòng chỉ được tính là bằng chứng thực thi khi nó chứa mục nguyên văn VÀ mang marker đúng ranh giới từ, nên một log chỉ nhắc lại kế hoạch sẽ được 0 executed-pass. Trong các dòng chứa một mục, dòng có marker đầu tiên quyết định: marker fail trên dòng đó nghĩa là executed-fail, nếu không là executed-pass, và survived yêu cầu không thiếu gì và không fail gì. Marker do người gọi cung cấp (markers / --markers); marker fail mặc định là ["FAIL"] trừ khi người gọi ghi đè, và marker fail mà không có markers là lỗi. Các lần bỏ qua do người gọi khai báo (skipped / --skipped) là thay đổi kế hoạch, không phải lần thực thi: kiểm tra tin vào khai báo, liệt kê skip theo tên, và không bao giờ tính chúng là thiếu. Giới hạn, nói thẳng: bằng chứng có marker là sự hiện diện của text, không phải chứng minh chống lại log lặp lại marker — hãy giữ kế hoạch và output ở hai kênh riêng và kiểm tra các dòng bằng chứng; một FAIL trước đó không bị PASS sau đó xóa, vì dòng có marker đầu tiên quyết định.
Cách dùng
# Thử trong 3 bước
git clone https://github.com/techdevfun/context-diet
cd context-diet
npm install && npm run build
# dạng CLI:
node dist/cli.js pack --input examples/session.log --budget 400 --query "test failure"
# dạng MCP server (Claude Code, Cursor, bất kỳ MCP client nào) qua stdio:
# command: node, args: ["<path>/context-diet/dist/server.js"]# Cấu hình MCP
{
"mcpServers": {
"context-diet": {
"command": "node",
"args": ["/path/to/context-diet/dist/server.js"]
}
}
}# Log này thực sự lớn cỡ nào?
node dist/cli.js count --input ci.log
# Chỉ lấy các lỗi và vùng xung quanh:
node dist/cli.js extract --input ci.log --query "timeout database"
# Nhét vừa 300 token, kèm biên lai:
node dist/cli.js pack --input ci.log --budget 300Lệnh và cấu hình chép từ README của context-diet (v0.5.0). Cần Node 20 trở lên. Chưa có cài đặt qua npm cho công cụ này: gói npm, npm install -g context-diet, sẽ đến cùng lần publish npm đầu tiên — xem Roadmap trong README. Cho tới lúc đó, build từ source như trên.
Số liệu đã đo (README, một log session thật)
examples/session.log (169 dòng output lệnh thật: các lần chạy test chi tiết, một đoạn README, một output build) được pack về ngân sách 400 token với truy vấn test failure:
| Dòng | Byte | Token ước tính | |
|---|---|---|---|
| Trước | 169 | 7.917 | 1.942 |
| Sau | 23 | 1.587 | 392 |
| Tiết kiệm | 86,4% | 80,0% | 79,8% |
- Manifest: dedupe −54 dòng, extract −4, summarize −88. Nguyên văn: true.
- Số token là ước tính (quy tắc chars/4 đã ghi trong tài liệu); số dòng và số byte là chính xác.
Đây KHÔNG phải gì
- Không phải LLM summarizer: v1 không bao giờ viết lại text. Nếu bạn cần tóm tắt trừu tượng thực sự, công cụ này sẽ không làm được.
- Không phải code minifier: code được xử lý như text (không biến đổi AST).
- Không phải memory store: mỗi lần gọi đều stateless. (Dự án anh em memgraph lưu quyết định qua các session; Context Diet loại bỏ trùng lặp trong một session. Hai sản phẩm khác nhau, hướng ngược nhau.)
- Số token là ước tính (quy tắc chars/4). Số dòng và số byte là chính xác.
Không có mục “đối thủ hơn chúng ta ở đâu” ở đây vì README không có mục như vậy — chỉ có danh sách “Đây KHÔNG phải gì” ở trên.
Giới hạn và an toàn
- Input file bị giới hạn trong
--root(mặc định: thư mục làm việc). - Không dùng mạng, không chạy shell, không gọi model.
- Giới hạn kích thước input/output kèm thông báo lỗi rõ ràng.
- Đừng pipe secret mà bạn vốn không muốn cho model thấy: công cụ truyền text qua, và bản tóm tắt tới cùng đối tượng vốn đã có thể thấy log. Redaction nằm trong roadmap.
Chưa có trong v1 (roadmap): tóm tắt bằng LLM (tùy chọn), nén dựa trên model, minification code nhận biết AST, cache xuyên session, dashboard, tự áp dụng vào config agent, phân tích JUnit/XML, output SARIF, redaction secret.
Giấy phép
MIT. Xem LICENSE trong repo.
Công cụ liên quan
Các công cụ mã nguồn mở khác của TECHDEV: sessguard, runverdict, gheist-guard, vetgate, ci-failure-detective, agent-seatbelt, devsecops-os, env-doctor, skill-audit, logtrim, testguard, breakcheck, keymap, memgraph, ggufit, leaseguard, factfence, jsonfold
Đóng góp ý kiến
Bình chọn cho công cụ này, đề xuất tính năng, hoặc thảo luận với các vận hành khác trên bảng cộng đồng.