Bản đồ công trìnhTờ này lắp: Coding agent
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Từ prompt engineering đến context engineering
Ở bài trước, bạn học viết một prompt tốt. Nhưng prompt chỉ là một thứ trên bàn làm việc của agent. Trong một phiên dài, prompt của bạn có thể chỉ chiếm vài phần trăm ngữ cảnh; phần còn lại là file agent đã đọc, output lệnh, những lần thử sai, hướng dẫn của công cụ.
Hãy hình dung một đầu bếp giỏi làm việc trên một chiếc bàn inox có kích thước cố định. Bạn đưa phiếu order (prompt) rất rõ ràng. Nhưng nếu trên bàn còn ngổn ngang nguyên liệu của ba món trước, vỏ trứng, khay bột thừa, hai tờ order cũ đã hủy, thì dù phiếu order rõ đến đâu, khả năng nhầm vẫn cao. Context engineering là nghệ thuật giữ cho chiếc bàn đó chỉ có đúng những thứ cần cho món đang làm.
Ngữ cảnh gồm những gì
Bức tranh đầy đủ
Mỗi lượt agent suy nghĩ, bộ khung gửi cho mô hình một khối ngữ cảnh gồm nhiều lớp:
- Hướng dẫn hệ thống của công cụ
- Mô tả các công cụ
- File hướng dẫn dự án
- Lịch sử hội thoại
- Kết quả công cụ
- Phần này thường phình nhanh nhất
- Ghi ra ngoài
- Chọn lọc
- Nén
- Cô lập
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Cửa sổ ngữ cảnh tại một lượt
- 6. Kết quả công cụ: nội dung file đã đọc, output lệnh, ảnh → Phần này thường phình nhanh nhất
| Thành phần | Ai kiểm soát | Đặc điểm | Bạn tác động thế nào |
|---|---|---|---|
| Hướng dẫn hệ thống của công cụ | Nhà cung cấp | Cố định, luôn có | Chọn công cụ, chọn chế độ |
| Mô tả công cụ (kể cả MCP) | Bạn và nhà cung cấp | Mỗi công cụ thêm vào đều tốn chỗ, luôn có mặt | Chỉ bật MCP server cần dùng |
| File hướng dẫn dự án | Bạn | Nạp đầu mỗi phiên | Giữ ngắn, chỉ điều quan trọng |
| Mô tả skill | Bạn | Chỉ phần mô tả ngắn luôn có; nội dung nạp khi dùng | Viết mô tả skill rõ để agent biết lúc nào cần |
| Lịch sử hội thoại | Bạn | Tăng theo từng lượt | Một việc một phiên, làm mới khi cần |
| Kết quả công cụ | Agent, theo hướng bạn chỉ | Phình nhanh nhất: một file dài, một log lỗi có thể chiếm rất nhiều token | Chỉ rõ file, lọc output lệnh |
| Tóm tắt | Công cụ hoặc bạn | Thay phần cũ bằng bản rút gọn | Chủ động tóm tắt có định hướng |
Điều nhiều người không để ý
- Mô hình đọc lại toàn bộ ngữ cảnh ở mỗi lượt. Một log lỗi 2.000 dòng được đọc vào ở bước 3 sẽ tiếp tục “nằm trên bàn” ở bước 4, 5, 6…, chiếm chỗ và tốn tiền ở mọi lượt sau.
- Những lần thử sai cũng nằm trong ngữ cảnh. Nếu agent đã thử ba cách sai, cả ba vẫn còn đó, và có thể “nhiễm” vào lần thử thứ tư.
- Ảnh tốn token. Ảnh chụp màn hình rất hữu ích, nhưng chụp hàng chục ảnh trong một phiên sẽ làm đầy ngữ cảnh nhanh.
- Mỗi MCP server bạn bật đều đặt mô tả công cụ của nó lên bàn, kể cả khi phiên này không dùng tới. Bài MCP02-07 sẽ bàn cách chọn.
Hiện tượng hiệu suất giảm khi ngữ cảnh đầy
Vì sao càng đầy càng kém
Cửa sổ ngữ cảnh lớn không có nghĩa mô hình chú ý đều đến mọi thứ trong đó. Có thể hình dung khả năng chú ý của mô hình như một lượng đèn chiếu cố định: bàn càng nhiều đồ, mỗi món nhận được càng ít ánh sáng. Thông tin quan trọng (như quy ước “tiền là số nguyên VNĐ” bạn nói từ đầu phiên) dễ bị chìm giữa hàng nghìn dòng code và log.
Tài liệu thực hành tốt của nhiều nhà cung cấp agent đều nêu cùng một nhận xét: hiệu suất giảm khi ngữ cảnh đầy dần, và đây là ràng buộc gốc mà phần lớn các thực hành khác xoay quanh. Cửa sổ lớn hơn giúp chứa được nhiều hơn, nhưng không xóa bỏ hiện tượng này.
Ngoài chuyện “chú ý loãng”, còn ba cơ chế khác:
- Nhiễu từ lần thử sai: đoạn code sai vẫn trong ngữ cảnh, mô hình có thể tái sử dụng một phần của nó.
- Chỉ dẫn mâu thuẫn: đầu phiên bạn nói “dùng bảng”, giữa phiên bạn đổi ý “dùng thẻ”; cả hai đều còn đó.
- Mất chi tiết khi bị nén tự động: khi gần đầy, nhiều công cụ tự tóm tắt phần cũ; chi tiết nhỏ mà quan trọng có thể bị lược đi.
Dấu hiệu nhận biết
| Dấu hiệu | Ví dụ trong Bánh Mộc | Nguyên nhân thường gặp |
|---|---|---|
| Quên quy ước đã nói | Đột nhiên dùng số thực cho tiền | Quy ước nằm xa ở đầu phiên, bị chìm |
| Đọc lại file vừa đọc | Lại mở schema.ts lần thứ tư |
Nội dung cũ đã bị nén mất |
| Lặp lại lỗi đã sửa | Lỗi múi giờ quay lại | Lần thử sai cũ còn trong ngữ cảnh |
| Tự mâu thuẫn | Nói đã xong rồi lại bảo còn thiếu | Chỉ dẫn xung đột |
| Chậm và đắt hơn rõ rệt | Mỗi lượt chờ lâu hơn | Ngữ cảnh rất lớn bị đọc lại mỗi lượt |
| Trả lời chung chung | Đề xuất kiểu “sách giáo khoa”, không bám dự án | Thông tin dự án bị loãng |
Bốn chiến lược quản lý ngữ cảnh
Có thể gom mọi kỹ thuật vào bốn động từ:
| Chiến lược | Ý tưởng | Ví dụ cụ thể |
|---|---|---|
| Ghi ra ngoài | Thứ cần nhớ lâu thì viết vào file, không giữ trong hội thoại | Quyết định ghi vào ADR; tiến độ ghi vào file ghi chú; quy ước vào AGENTS.md |
| Chọn lọc | Chỉ đưa vào đúng phần cần | Chỉ đường dẫn file thay vì dán cả file; lọc output lệnh; chỉ bật MCP cần thiết |
| Nén | Thay phần dài bằng bản tóm tắt | Yêu cầu tóm tắt phiên trước khi làm mới; tóm tắt có định hướng |
| Cô lập | Đẩy việc tốn ngữ cảnh sang nơi khác | Subagent nghiên cứu; phiên riêng cho review; mỗi việc một phiên |
Chọn lọc: những thói quen nhỏ, hiệu quả lớn
- Chỉ đường dẫn, đừng dán. “Đọc
docs/specs/tao-don-hang.mdmục 3″ tốt hơn dán cả spec vào prompt; agent đọc đúng phần cần. - Lọc output lệnh. Test hoặc build có thể in ra hàng nghìn dòng. Dặn agent dùng chế độ in gọn, hoặc chỉ lấy phần cuối:
# Chạy test với kiểu báo cáo gọn: chỉ in chấm cho test qua, chi tiết cho test hỏng
npx vitest run --reporter=dot
# Build và chỉ giữ 40 dòng cuối của output (thường chứa lỗi chính)
npm run build 2>&1 | tail -n 40- Giới hạn phạm vi khám phá. “Tìm trong
src/features/orders/thôi” ngăn agent đọc toàn bộ dự án. - Đừng để agent đọc file khổng lồ không cần thiết: file dữ liệu mẫu lớn, file lock của trình quản lý gói, thư mục build. Có thể ghi vào file hướng dẫn: “Không đọc
pnpm-lock.yaml,.next/,node_modules/.”
Nén: tóm tắt có định hướng
Nhiều công cụ có lệnh tóm tắt (nén) ngữ cảnh, tự động khi gần đầy hoặc chủ động khi bạn gọi; tên lệnh tùy công cụ. Khi chủ động nén, hãy nói rõ cần giữ gì: “Tóm tắt phiên, giữ nguyên: các quyết định về múi giờ, danh sách file đã sửa, test nào còn đỏ; bỏ qua chi tiết các lần thử thất bại.”
Nén tự động tiện nhưng không biết điều gì quan trọng với bạn. Nén chủ động có định hướng an toàn hơn. Còn cách an toàn nhất là kết hợp: ghi những gì quan trọng ra file, rồi làm mới phiên.
Phiên sạch, tóm tắt, làm mới
Khi nào nên làm mới phiên
Làm mới phiên (xóa ngữ cảnh, mở cuộc trò chuyện mới) là thao tác rẻ nhất và hiệu quả nhất mà người mới hay quên. Quy tắc gợi ý:
- Chuyển sang việc không liên quan. Vừa sửa màn hình bếp xong, giờ làm báo cáo doanh thu: phiên mới.
- Đã chỉnh agent hơn hai lần cho cùng một vấn đề mà vẫn sai. Ngữ cảnh đã nhiễm những hướng sai; mở phiên mới với prompt tốt hơn, có rút kinh nghiệm từ các lần trước.
- Vừa xong giai đoạn nghiên cứu hoặc phỏng vấn, chuẩn bị thực thi. Kết quả nghiên cứu đã ghi ra file; phiên thực thi chỉ cần đọc file đó.
- Thấy dấu hiệu suy giảm như bảng ở trên.
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Đang trong một phiên → Việc tiếp theo liên quan việc vừa làm?
- Việc tiếp theo liên quan việc vừa làm? → Làm mới phiên (Không)
- Việc tiếp theo liên quan việc vừa làm? → Đã chỉnh hơn 2 lần cùng một lỗi? (Có)
- Đã chỉnh hơn 2 lần cùng một lỗi? → Ghi bài học ra file, làm mới phiên với prompt tốt hơn (Có)
- Đã chỉnh hơn 2 lần cùng một lỗi? → Ngữ cảnh đã dùng nhiều, có dấu hiệu suy giảm? (Không)
- Ngữ cảnh đã dùng nhiều, có dấu hiệu suy giảm? → Yêu cầu agent ghi file bàn giao (Có)
- Yêu cầu agent ghi file bàn giao → Làm mới phiên
- Ngữ cảnh đã dùng nhiều, có dấu hiệu suy giảm? → Tiếp tục trong phiên (Không)
- Làm mới phiên → Phiên mới: đọc AGENTS.md, file bàn giao, spec liên quan
Ghi chú bàn giao giữa hai phiên
Trước khi làm mới một phiên còn dang dở, yêu cầu agent viết ghi chú bàn giao vào file. Giống ca sáng bàn giao cho ca chiều ở tiệm: đã làm gì, đang dở gì, lưu ý gì. Ví dụ:
# Bàn giao: tính năng hủy đơn (cập nhật 12/10)
## Đã xong
- Hàm cancelOrder trong src/features/orders/status.ts, chỉ cho hủy trước dang_giao (moi/da_xac_nhan/dang_lam)
- Ghi order_status_history khi hủy
- 6 unit test, tất cả xanh
## Đang dở
- Nút "Hủy đơn" trên trang chi tiết: chưa có hộp xác nhận
## Quyết định đã chốt
- Đơn đã cọc khi hủy: chỉ đánh dấu, hoàn tiền xử lý tay (ngoài phạm vi lần này)
## Lưu ý
- Đã thử dùng transaction của Supabase client, không hợp; dùng transaction của DrizzlePhiên mới chỉ cần: “Đọc docs/progress/huy-don.md và tiếp tục phần đang dở.” Agent bắt đầu với một bàn sạch và đủ thông tin.
Tài liệu là bộ nhớ dài hạn của dự án
Agent mất trí nhớ, dự án thì không được phép
Mỗi phiên mới, agent bắt đầu từ con số không. Thứ duy nhất nối các phiên lại với nhau là những gì được ghi ra: trong file, trong code, trong lịch sử Git. Vì vậy với dự án làm cùng AI, tài liệu không còn là “việc làm thêm cho chuyên nghiệp” mà là bộ nhớ của cả hệ thống.
Bộ nhớ nhiều tầng
Không phải tài liệu nào cũng nên nạp mỗi phiên. Hãy tổ chức theo tầng, giống cách tiệm bánh có bảng quy định dán ở bếp (ai cũng thấy mỗi ngày), sổ công thức (mở khi cần) và kho hồ sơ (hiếm khi mở):
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Tầng 1 – Luôn nạp: AGENTS.md ngắn gọn (lệnh, quy ước, cạm bẫy, chỉ đường tới tài liệu) → Tầng 2 – Nạp khi cần: docs/PRD.md, docs/specs/, docs/adr/, skills (chỉ đường)
- Tầng 2 – Nạp khi cần: docs/PRD.md, docs/specs/, docs/adr/, skills → Tầng 3 – Sự thật thực thi: code, schema, test (mô tả ý định của)
- Tầng 3 – Sự thật thực thi: code, schema, test → Tầng 4 – Lịch sử: Git log, commit message, pull request, issue (thay đổi được ghi ở)
- Tầng 1 nhỏ và đắt giá: chỉ những điều agent sẽ làm sai nếu không biết, kèm “bản đồ” chỉ tới tầng 2. Bài AGENTS.md, rules và skills02-06 hướng dẫn viết chi tiết.
- Tầng 2 là kiến thức theo chủ đề: spec từng tính năng, quyết định kiến trúc (xem bài Tài liệu hóa kiến trúc04-09), quy trình lặp lại dạng skill. Agent đọc khi việc đang làm liên quan.
- Tầng 3 là sự thật cuối cùng. Test đặc biệt quý: nó là tài liệu chạy được, không bao giờ “lỗi thời” mà không ai biết.
- Tầng 4 trả lời câu hỏi “vì sao code lại thế này”. Commit message rõ ràng giúp cả người lẫn agent sau này.
Nguyên tắc tiết lộ dần (progressive disclosure): tầng trên chỉ cần nói “thông tin X nằm ở đâu”, không cần chép lại nội dung. Ví dụ AGENTS.md chỉ ghi: “Quy tắc trạng thái đơn: xem docs/specs/trang-thai-don.md.”
Giữ bộ nhớ không lỗi thời
Tài liệu sai còn tệ hơn không có, vì agent tin nó. Hai thói quen:
- Cập nhật tài liệu trong cùng commit với thay đổi code. Đưa vào tiêu chí hoàn thành: “Nếu thay đổi ảnh hưởng spec, cập nhật spec.”
- Định kỳ rà soát AGENTS.md: dòng nào không còn đúng, dòng nào agent không cần nữa.
Mẫu “nghiên cứu ở phiên phụ, thực thi ở phiên chính”
Vấn đề
Trước khi tích hợp VietQR vào Mộc OMS, agent cần tìm hiểu: tài liệu của dịch vụ, cách các module hiện có xử lý thanh toán, cấu trúc bảng payments. Việc tìm hiểu này có thể đọc hàng chục file và trang tài liệu. Nếu làm trong phiên chính, đến lúc bắt tay viết code, bàn đã đầy những thứ chỉ cần cho việc tìm hiểu.
Giải pháp: cô lập việc nghiên cứu
Subagent (trợ lý phụ) là một agent con chạy trong ngữ cảnh riêng. Phiên chính giao cho nó một câu hỏi; nó đọc bao nhiêu file tùy ý trong ngữ cảnh của nó, rồi chỉ trả về bản tóm tắt. Phiên chính nhận một trang kết luận thay vì bốn mươi file.
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Bạn → Phiên chính: Chuẩn bị tích hợp xác nhận thanh toán VietQR
- Phiên chính → Subagent (ngữ cảnh riêng): Tìm hiểu luồng thanh toán hiện có và bảng payments
- Ghi chú (S): Đọc 30 file, tìm kiếm, chạy lệnh Tất cả nằm trong ngữ cảnh của subagent
- Subagent (ngữ cảnh riêng) → Phiên chính: Tóm tắt 1 trang: file liên quan, luồng hiện tại, rủi ro
- Phiên chính → Bạn: Đề xuất kế hoạch dựa trên bản tóm tắt
- Bạn → Phiên chính: Duyệt kế hoạch
- Phiên chính → Phiên chính: Thực thi với ngữ cảnh gọn
Nhiều agent tại thời điểm viết (2026) có sẵn cơ chế subagent, hoặc cho phép bạn tự định nghĩa subagent chuyên biệt (ví dụ một subagent chuyên review bảo mật). Nếu công cụ của bạn không có, làm thủ công cũng được:
- Phiên A (nghiên cứu): “Tìm hiểu X, chưa sửa gì. Ghi kết luận vào
docs/research/x.md.” - Bạn đọc file kết luận, bổ sung nếu cần.
- Phiên B (thực thi): “Đọc
docs/research/x.mdvà spec, lập kế hoạch, rồi thực thi.”
Cùng tinh thần đó, review cũng nên làm ở phiên riêng: một phiên mới đọc diff so với spec sẽ khách quan hơn chính phiên vừa viết code, vì nó không bị “thiên vị” bởi những lý lẽ đã nằm trong ngữ cảnh. Chi tiết về nhiều agent song song có ở bài Nhiều agent song song06-09.
Mẫu thất bại kinh điển: phiên “bồn rửa bát”
Phiên “bồn rửa bát” (kitchen sink) là phiên mà mọi thứ đều được ném vào: sửa lỗi dashboard, hỏi về VietQR, nhập file khách hàng, đổi màu nút, rồi quay lại sửa dashboard. Sau hai giờ, ngữ cảnh là một mớ hỗn độn, agent bắt đầu mắc những lỗi ngớ ngẩn.
| Phiên “bồn rửa bát” | Phiên có kỷ luật |
|---|---|
| Nhiều việc không liên quan trong một phiên | Một việc (hoặc một nhóm việc liên quan) một phiên |
| Quy ước nói miệng ở đầu phiên | Quy ước nằm trong AGENTS.md, nạp lại mỗi phiên |
| Dán cả file, cả log dài | Chỉ đường dẫn, lọc output |
| Nghiên cứu và thực thi lẫn lộn | Nghiên cứu ở phiên phụ, kết luận ghi ra file |
| Chỉnh đi chỉnh lại cho tới khi được | Sau hai lần không được, làm lại phiên sạch |
| Tiến độ chỉ nằm trong hội thoại | Tiến độ ghi vào file bàn giao, code commit thường xuyên |
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-019
13.10.2026
- Chị LanChủ chuỗi
- HàBán hàng online
Một buổi tối, chị Lan mở agent và làm liền một mạch: sửa lỗi dashboard đếm sai đơn hủy, hỏi cách tích hợp VietQR, nhờ viết script nhập 800 khách hàng từ Google Sheet cũ, đổi màu nút “Xác nhận đơn”, rồi quay lại dashboard. Gần cuối buổi, agent viết lại hàm tính tổng tiền và dùng số thực, dù đầu buổi chị đã dặn “tiền là số nguyên VNĐ”. Script nhập khách hàng đọc nhầm cột ngày sinh. Chị bực, chỉnh ba lần, agent càng sửa càng lệch.
Hôm sau, chị Lan áp dụng bài học:
- Đưa quy ước vào tầng 1. Câu “Tiền lưu dạng số nguyên VNĐ (bigint), không dùng số thực” được ghi vào
AGENTS.md, để phiên nào cũng có. - Một việc một phiên. Dashboard một phiên, nhập khách hàng một phiên, màu nút làm luôn trong phiên dashboard vì cùng khu vực.
- Nghiên cứu VietQR ở phiên phụ. Chị giao subagent: “Tìm hiểu cách module thanh toán hiện tại lưu
payments, và đọc tài liệu dịch vụ xác nhận chuyển khoản mà mình dán link. Trả về tóm tắt: luồng dữ liệu, webhook, rủi ro trùng giao dịch.” Kết luận được ghi vàodocs/research/vietqr.md, sau đó trở thành đầu vào cho spec. - Lọc output. Chị thêm vào
AGENTS.md: “Chạy test bằngnpx vitest run --reporter=dot; khi build lỗi chỉ cần 40 dòng cuối.” - File bàn giao. Với script nhập khách hàng (làm qua hai buổi), cuối buổi đầu chị yêu cầu agent ghi
docs/progress/nhap-khach-hang.md; buổi sau mở phiên mới, đọc file đó và làm tiếp.
Kết quả rõ nhất chị cảm nhận: số lần phải “chỉnh lại” giảm hẳn, và mỗi phiên kết thúc nhanh hơn. Chị ví von với Hà: “Ngày xưa chị bắt AI vừa nghe điện thoại, vừa viết đơn, vừa đếm tiền. Giờ mỗi lúc chỉ giao nó một việc, trên một cái bàn sạch.“
Prompt mẫu
Giao việc nghiên cứu cho subagent hoặc phiên phụ:
Điền ô trống rồi sao chép
Dùng một subagent (hoặc làm trong phiên này nhưng KHÔNG sửa code) để tìm hiểu:
[câu hỏi cụ thể, ví dụ: luồng ghi nhận thanh toán hiện tại liên quan bảng payments].
Phạm vi: src/features/payments/, src/db/schema.ts.
Trả về tóm tắt tối đa 1 trang: file liên quan, luồng dữ liệu, điểm rủi ro, câu hỏi còn mở.
Ghi tóm tắt vào docs/research/[chu-de].md.Yêu cầu ghi chú bàn giao trước khi làm mới phiên:
Điền ô trống rồi sao chép
Mình sắp mở phiên mới. Hãy ghi file docs/progress/[ten-viec].md gồm:
đã xong (kèm file liên quan), đang dở, quyết định đã chốt và lý do, cách tiếp cận đã thử nhưng không
hợp, bước tiếp theo cụ thể. Ngắn gọn, đủ để một phiên mới đọc là làm tiếp được.Nén có định hướng:
Điền ô trống rồi sao chép
Tóm tắt phiên này để tiếp tục. Giữ nguyên: quyết định về [chủ đề], danh sách file đã sửa,
test nào đang đỏ và vì sao. Bỏ qua: chi tiết các lần thử thất bại, output lệnh cũ.Mở đầu phiên mới đúng cách:
Điền ô trống rồi sao chép
Đọc docs/progress/[ten-viec].md và docs/specs/[spec].md. Chưa sửa gì.
Tóm tắt lại cho mình trong 5 dòng bạn hiểu việc đang ở đâu và bước tiếp theo là gì.Sai lầm thường gặp
-
Sự cố 01
Dặn quy ước quan trọng bằng lời trong hội thoại.
Triệu chứngLời dặn chìm dần khi phiên dài, và mất hẳn ở phiên sau.
Cách tránhQuy ước lâu dài ghi vào AGENTS.md; quyết định ghi vào spec hoặc ADR.
-
Sự cố 02
Phiên “bồn rửa bát”.
Triệu chứngTrộn nhiều việc không liên quan làm ngữ cảnh rối và agent lạc hướng.
Cách tránhMột việc một phiên; làm mới phiên khi chuyển chủ đề.
-
Sự cố 03
Cố cứu một phiên đã nhiễm.
Triệu chứngChỉnh lần thứ ba, thứ tư trong cùng phiên hiếm khi tốt hơn bắt đầu lại.
Cách tránhSau hai lần chỉnh không thành, ghi bài học ra file, mở phiên sạch với prompt tốt hơn.
-
Sự cố 04
Để output dài tràn vào ngữ cảnh.
Triệu chứngLog build, kết quả test đầy đủ, file dữ liệu lớn chiếm chỗ ở mọi lượt sau.
Cách tránhDùng chế độ báo cáo gọn, lọc phần cuối, ghi hướng dẫn lọc vào AGENTS.md.
-
Sự cố 05
Bật quá nhiều MCP server “cho chắc”.
Triệu chứngMỗi server đặt mô tả công cụ của nó vào ngữ cảnh, kể cả khi không dùng.
Cách tránhChỉ bật server cần cho dự án; tắt khi không dùng.
-
Sự cố 06
Tài liệu lỗi thời.
Triệu chứngAgent tin tài liệu, nên tài liệu sai dẫn agent làm sai một cách tự tin.
Cách tránhCập nhật tài liệu cùng commit với code; rà soát định kỳ.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Kiểm kê ngữ cảnh
Mở một phiên agent mới trong dự án của bạn, xem chỉ báo mức sử dụng ngữ cảnh (nếu công cụ có) trước khi gõ gì. Sau đó giao một việc nhỏ và xem mức sử dụng sau mỗi vài lượt.
Kết quả mong đợi
Bạn thấy ngay cả phiên trống cũng đã có một phần ngữ cảnh bị chiếm (hướng dẫn hệ thống, mô tả công cụ, file hướng dẫn), và việc đọc file hay chạy lệnh làm tăng nhanh thế nào.
-
Bài 2
Cơ bản
Viết file bàn giao
Ở cuối một phiên làm việc dang dở, yêu cầu agent viết file bàn giao theo prompt mẫu. Mở phiên mới, chỉ cho đọc file đó và yêu cầu tóm tắt lại.
Kết quả mong đợi
Phiên mới tóm tắt đúng hiện trạng và bước tiếp theo. Nếu thiếu, bạn biết file bàn giao cần bổ sung mục nào.
-
Bài 3
Nâng cao
So sánh nghiên cứu trong phiên chính và phiên phụ
Chọn một câu hỏi khám phá rộng (ví dụ “luồng dữ liệu từ form tạo đơn tới database đi qua những file nào”). Làm một lần ngay trong phiên chính, một lần qua subagent hoặc phiên phụ ghi ra file. Ghi lại mức ngữ cảnh còn lại của phiên chính sau mỗi cách.
Kết quả mong đợi
Cách dùng phiên phụ để lại phiên chính gọn hơn hẳn, với cùng chất lượng kết luận.
Thuật ngữ trong bài
- Context engineering
- Kỷ luật quyết định thông tin nào vào ngữ cảnh của agent, khi nào và bằng cách nào
- Phiên (session)
- Một cuộc làm việc liên tục với agent, có ngữ cảnh riêng
- Làm mới phiên
- Xóa ngữ cảnh, bắt đầu cuộc trò chuyện mới
- Nén ngữ cảnh (compaction)
- Thay phần hội thoại cũ bằng bản tóm tắt
- Ghi chú bàn giao
- File ghi tiến độ để phiên sau làm tiếp
- Subagent
- Agent phụ chạy trong ngữ cảnh riêng, trả về bản tóm tắt
- Tiết lộ dần (progressive disclosure)
- Chỉ nạp thông tin chi tiết khi cần, tầng trên chỉ chỉ đường
- Phiên “bồn rửa bát”
- Phiên trộn nhiều việc không liên quan, làm ngữ cảnh rối
- Checkpoint
- Điểm lưu trong phiên agent để quay lui, không thay thế Git
Đọc thêm
- Thực hành tốt về quản lý ngữ cảnh và subagent: https://code.claude.com/docs
- Định dạng file hướng dẫn cho agent: https://agents.md
- Ghi lại quyết định kiến trúc: https://adr.github.io
- Bài liên quan: Vòng lặp Khám phá → Lập kế hoạch → Code → Kiểm chứng → Commit06-03, Chia nhỏ công việc06-05, Nhiều agent song song06-09
Nghiệm thu tờ 02-05
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
