Bản đồ công trìnhTờ này lắp: Coding agent, Kiểm thử
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Chatbot, trợ lý gợi ý và agent: ba cấp độ
Hãy hình dung ba cách bạn nhờ người sửa vòi nước rò rỉ ở tiệm:
- Gọi điện hỏi thợ (chatbot): thợ nghe bạn tả, khuyên “chắc do gioăng, chị mua gioăng số 3 thay thử”. Bạn tự đi mua, tự thay. Không được thì gọi lại tả tiếp.
- Thợ đứng cạnh chỉ tay (trợ lý gợi ý trong trình soạn thảo): bạn cầm cờ lê, thợ nhắc “vặn chỗ này”, “siết thêm chút”. Nhanh hơn, nhưng bạn vẫn là người làm.
- Thợ đến tận nơi với hộp đồ nghề (coding agent): thợ tự mở tủ xem, tự thử, tự thay, mở nước kiểm tra rồi báo “xong, chị xem lại”. Bạn giao việc và nghiệm thu.
| Tiêu chí | Chatbot | Trợ lý gợi ý code | Coding agent |
|---|---|---|---|
| Thấy code của dự án | Chỉ phần bạn dán vào | File đang mở và lân cận | Tự tìm và đọc bất kỳ file nào được phép |
| Sửa code | Không, bạn tự chép | Gợi ý, bạn chấp nhận | Tự sửa nhiều file |
| Chạy lệnh, chạy test | Không | Thường không | Có, nếu được cấp quyền |
| Tự phát hiện lỗi của chính mình | Không | Hạn chế | Có, qua kết quả lệnh và test |
| Vai trò của bạn | Người thực thi | Người viết có trợ lý | Người giao việc và nghiệm thu |
Ranh giới giữa các cấp đang mờ dần: nhiều trình soạn thảo đã có chế độ agent, nhiều agent dòng lệnh có giao diện trong trình soạn thảo. Bài Bản đồ công cụ AI coding02-03 sẽ phân loại cụ thể. Ở bài này, ta tập trung vào cơ chế chung của mọi agent.
Vòng lặp agent: suy nghĩ – hành động – quan sát
Bản chất: một LLM được đặt trong vòng lặp
Ở bài trước, bạn đã biết LLM chỉ làm một việc: đọc ngữ cảnh rồi viết tiếp. Một coding agent là LLM đặt trong một vòng lặp, cộng với một bộ công cụ. Phần mềm bao quanh mô hình (thường gọi là harness, “bộ khung”) làm ba việc: đưa yêu cầu của bạn và mô tả các công cụ vào ngữ cảnh, thực thi những công cụ mà mô hình yêu cầu, rồi đưa kết quả trở lại ngữ cảnh để mô hình đọc và quyết định bước tiếp.
- Suy nghĩ
- Hành động
- Quan sát
- Cần phê duyệt?
- Bạn đồng ý hoặc từ chối
- Báo cáo kết quả cho bạn
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Bạn giao việc → Suy nghĩ: mô hình đọc ngữ cảnh, quyết định bước tiếp
- Suy nghĩ: mô hình đọc ngữ cảnh, quyết định bước tiếp → Cần dùng công cụ?
- Cần dùng công cụ? → Hành động: yêu cầu gọi công cụ (đọc file, chạy lệnh…) (Có)
- Hành động: yêu cầu gọi công cụ (đọc file, chạy lệnh…) → Cần phê duyệt?
- Cần phê duyệt? → Bạn đồng ý hoặc từ chối (Có)
- Bạn đồng ý hoặc từ chối → Bộ khung thực thi công cụ
- Cần phê duyệt? → Bộ khung thực thi công cụ (Không)
- Bộ khung thực thi công cụ → Quan sát: kết quả được thêm vào ngữ cảnh
- Quan sát: kết quả được thêm vào ngữ cảnh → Suy nghĩ: mô hình đọc ngữ cảnh, quyết định bước tiếp
- Cần dùng công cụ? → Báo cáo kết quả cho bạn (Không, đã xong)
- Báo cáo kết quả cho bạn → Bạn nghiệm thu hoặc giao tiếp
- Bạn nghiệm thu hoặc giao tiếp → Bạn giao việc
Ba nhịp của vòng lặp:
- Suy nghĩ (reason): mô hình đọc toàn bộ ngữ cảnh (yêu cầu, những gì đã thấy) và quyết định: cần xem thêm file nào, chạy lệnh gì, hay đã đủ để trả lời.
- Hành động (act): mô hình viết ra một lời gọi công cụ có cấu trúc, ví dụ “đọc file
src/features/orders/create-order.ts” hoặc “chạy lệnhnpm test“. - Quan sát (observe): bộ khung thực thi và trả kết quả (nội dung file, output của lệnh, thông báo lỗi) vào ngữ cảnh. Vòng lặp quay lại bước suy nghĩ.
Vòng lặp dừng khi mô hình quyết định việc đã xong, khi bạn dừng nó, hoặc khi chạm giới hạn (số bước, ngữ cảnh đầy).
Mô hình không tự “bấm nút”
Một hiểu lầm phổ biến: AI “điều khiển máy tính của bạn”. Chính xác hơn, mô hình chỉ viết ra yêu cầu; phần mềm agent trên máy bạn mới là thứ thực thi, và nó thực thi theo luật bạn đặt. Một lời gọi công cụ, ở dạng đơn giản hóa, trông giống thế này:
{
"tool": "run_command",
"input": {
"command": "npm run typecheck",
"reason": "Kiểm tra lỗi kiểu sau khi sửa hàm tính tổng tiền"
}
}
Tên công cụ và định dạng cụ thể khác nhau giữa các agent, nhưng nguyên lý giống nhau. Hiểu điều này giúp bạn thấy rõ: mọi rủi ro đều đi qua cửa công cụ, và bạn kiểm soát được cánh cửa đó bằng quyền hạn.
Một phiên làm việc điển hình
Giả sử bạn giao: “Build đang lỗi, hãy sửa”. Một agent tốt có thể đi qua các bước như sau:
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Bạn → Agent (mô hình): Build lỗi, hãy sửa và chứng minh build xanh
- Agent (mô hình) → Bộ khung + máy tính: Chạy npm run build
- Bộ khung + máy tính → Agent (mô hình): Lỗi kiểu ở order-summary.tsx dòng 42
- Agent (mô hình) → Bộ khung + máy tính: Đọc file order-summary.tsx
- Bộ khung + máy tính → Agent (mô hình): Nội dung file
- Agent (mô hình) → Bộ khung + máy tính: Tìm định nghĩa kiểu Order
- Bộ khung + máy tính → Agent (mô hình): Order.total là number, code dùng như string
- Agent (mô hình) → Bộ khung + máy tính: Sửa file: định dạng tiền bằng formatVND
- Bộ khung + máy tính → Agent (mô hình): Đã sửa
- Agent (mô hình) → Bộ khung + máy tính: Chạy lại npm run build
- Bộ khung + máy tính → Agent (mô hình): Build thành công
- Agent (mô hình) → Bạn: Báo cáo: nguyên nhân, thay đổi, output build
Chú ý bước cuối: agent chạy lại build để xác nhận, rồi đưa bằng chứng. Đó là hành vi bạn muốn thấy, và bạn có thể yêu cầu rõ trong prompt.
Hộp đồ nghề của agent
Các nhóm công cụ chính
Tên gọi khác nhau giữa các sản phẩm, nhưng hầu hết coding agent đều có những nhóm công cụ sau tại thời điểm viết (2026):
| Nhóm công cụ | Agent làm được gì | Ví dụ trong Bánh Mộc | Mức rủi ro |
|---|---|---|---|
| Đọc file | Xem nội dung code, cấu hình, tài liệu | Đọc docs/specs/tao-don-hang.md |
Thấp (nhưng có thể đọc phải file bí mật) |
| Tìm kiếm trong dự án | Tìm file theo tên, tìm chuỗi trong code | Tìm mọi chỗ dùng cột deposit |
Thấp |
| Ghi và sửa file | Tạo file mới, sửa dòng code | Thêm trường cake_message vào form |
Trung bình (có Git thì quay lui được) |
| Chạy lệnh dòng lệnh | Cài gói, chạy test, build, Git, script | npm test, git diff |
Cao (một lệnh có thể xóa dữ liệu) |
| Web: tìm kiếm, đọc trang | Tra tài liệu mới, đọc issue công khai | Đọc tài liệu Supabase về RLS | Trung bình (nội dung web có thể chứa bẫy) |
| Trình duyệt tự động | Mở ứng dụng, bấm, chụp màn hình | Mở trang tạo đơn, chụp ảnh so với thiết kế | Trung bình |
| Kết nối dịch vụ ngoài | Đọc issue GitHub, truy vấn database, xem thiết kế | Xem danh sách issue của repo banhmoc-oms |
Tùy quyền được cấp |
| Giao việc cho trợ lý phụ (subagent) | Tách việc nghiên cứu ra ngữ cảnh riêng | “Tìm hiểu cách module thanh toán hoạt động” | Thấp |
Nhóm “kết nối dịch vụ ngoài” thường đi qua Model Context Protocol, được giải thích ở bài MCP02-07. Subagent được bàn kỹ hơn trong bài Context engineering02-05.
Công cụ quyết định năng lực
Cùng một mô hình, đặt trong agent có công cụ chạy test và trình duyệt sẽ làm việc tốt hơn hẳn so với khi chỉ có công cụ đọc và sửa file. Lý do: công cụ cho mô hình thông tin thật thay cho phỏng đoán. Thay vì đoán “chắc hàm này nhận tham số kiểu chuỗi”, agent đọc file và biết chắc. Thay vì nói “code này chắc chạy được”, agent chạy và thấy kết quả.
Đây là điểm nối với bài trước: ảo giác giảm mạnh khi mô hình có thể kiểm tra lại thực tế. Một agent bịa tên hàm sẽ nhận ngay lỗi từ trình biên dịch và tự sửa, miễn là nó được yêu cầu chạy trình biên dịch.
Quyền hạn và chế độ phê duyệt
Vì sao phải đặt quyền
Agent có quyền chạy lệnh trên máy bạn tức là có quyền làm gần như mọi thứ bạn làm được: xóa thư mục, đẩy code lên GitHub, gọi API với khóa trong file .env. Phần lớn thời gian agent cư xử tốt, nhưng nó có thể hiểu sai ý bạn, hoặc bị đánh lừa bởi nội dung độc hại nằm trong một trang web hay một file nó đọc (gọi là prompt injection, bàn kỹ ở bài Bảo mật khi dùng agent09-07).
Nguyên tắc giống như giao chìa khóa cho nhân viên mới: tuần đầu chỉ đưa chìa cửa trước, chưa đưa chìa két.
Các chế độ phổ biến
Mỗi công cụ đặt tên khác nhau, nhưng thường có các nấc sau:
| Chế độ | Agent tự làm | Phải hỏi bạn | Khi nào dùng |
|---|---|---|---|
| Chỉ đọc / lập kế hoạch | Đọc, tìm kiếm, đề xuất kế hoạch | Mọi thay đổi | Tìm hiểu codebase, lên kế hoạch tính năng lớn |
| Phê duyệt thủ công | Đọc | Mỗi lần sửa file và chạy lệnh | Mới bắt đầu, việc nhạy cảm |
| Tự sửa file, hỏi lệnh | Đọc, sửa file | Chạy lệnh | Phổ biến nhất khi đã quen |
| Danh sách lệnh cho phép (allowlist) | Thêm các lệnh an toàn đã liệt kê như npm test, git status |
Lệnh ngoài danh sách | Khi đã biết lệnh nào hay dùng |
| Tự động có hàng rào | Hầu hết hành động, trong sandbox giới hạn file và mạng, hoặc có bộ phân loại rủi ro chặn hành động nguy hiểm | Hành động bị đánh giá rủi ro | Việc dài, đã có test tốt, môi trường cô lập |
Sandbox (hộp cát) là môi trường giới hạn: agent chỉ được ghi trong thư mục dự án, không được truy cập mạng tùy tiện. Một số agent chạy trên đám mây trong máy ảo riêng, bản chất cũng là sandbox.
Cách tăng quyền dần dần
- Tuần đầu: phê duyệt thủ công. Mỗi lần agent xin chạy lệnh, đọc lệnh đó và tự hỏi “mình có hiểu lệnh này làm gì không?”. Không hiểu thì hỏi agent giải thích trước khi đồng ý.
- Khi đã quen: cho phép tự sửa file (vì Git luôn cho bạn quay lui), và đưa vào allowlist những lệnh chỉ đọc hoặc chạy kiểm tra:
npm test,npm run lint,npm run typecheck,git status,git diff. - Không bao giờ đưa vào allowlist: lệnh xóa hàng loạt, lệnh đẩy code lên remote, lệnh chạy migration trên database thật, lệnh có chứa khóa bí mật.
Vì sao agent cần cách tự kiểm chứng
“Trông có vẻ xong” không phải là xong
Đây là phần quan trọng nhất của bài. Hãy nghĩ về vòng lặp agent: nó dừng khi mô hình cho rằng việc đã xong. Nếu không có công cụ nào cho nó biết code có chạy đúng hay không, thì tín hiệu duy nhất để dừng là “code trông có vẻ hợp lý”. Và như bài trước đã nói, LLM rất giỏi viết code trông hợp lý.
Hậu quả: bạn trở thành vòng kiểm tra. Bạn phải tự mở app, tự bấm thử, tự phát hiện lỗi, tự mô tả lại cho agent. Năng suất của cả hệ thống bị giới hạn bởi tốc độ bạn kiểm tra thủ công.
Ngược lại, khi agent có cách tự kiểm chứng, vòng lặp tự đóng lại: viết code, chạy kiểm tra, thấy lỗi, sửa, chạy lại, cho tới khi xanh. Bạn chỉ cần nghiệm thu kết quả cuối.
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Không có kiểm chứng
- Agent viết code → Agent báo xong
- Agent báo xong → Bạn tự kiểm tra
- Bạn tự kiểm tra → Bạn mô tả lỗi
- Bạn mô tả lỗi → Agent viết code
- Có kiểm chứng
- Agent viết code → Agent chạy test, build
- Agent chạy test, build → Agent viết code (Lỗi)
- Agent chạy test, build → Agent báo xong kèm bằng chứng (Xanh)
- Agent báo xong kèm bằng chứng → Bạn nghiệm thu
Các công cụ kiểm chứng xếp theo độ rẻ
| Công cụ kiểm chứng | Bắt được gì | Tốc độ | Học ở bài |
|---|---|---|---|
| Type check (TypeScript) | Gọi hàm không tồn tại, sai kiểu dữ liệu | Rất nhanh | Kiểm tra tĩnh08-06 |
| Linter | Lỗi phổ biến, vi phạm quy ước | Rất nhanh | 08-06 |
| Unit test | Sai logic tính tiền, sai chuyển trạng thái | Nhanh | Unit test và TDD08-03 |
| Build | Lỗi tích hợp, thiếu file, sai cấu hình | Trung bình | — |
| Test E2E, ảnh chụp màn hình | Giao diện vỡ, luồng người dùng hỏng | Chậm hơn | E2E với Playwright08-05 |
Bạn không cần có đủ tất cả ngay từ ngày đầu. Nhưng ngay cả một lệnh type check và vài unit test cho hàm tính tiền cũng đã thay đổi chất lượng làm việc của agent một cách rõ rệt. Module 8 sẽ đi sâu; bài Vì sao kiểm thử là dây an toàn08-01 giải thích kỹ lý do.
Đòi bằng chứng, không đòi lời hứa
Khi agent báo “đã sửa xong”, câu hỏi của bạn luôn là: bằng chứng đâu? Bằng chứng tốt gồm:
- Lệnh đã chạy và output thật (ví dụ “12 test passed”).
- Ảnh chụp màn hình giao diện sau khi sửa.
- Danh sách file đã thay đổi và lý do.
- Với lỗi: mô tả nguyên nhân gốc, không chỉ triệu chứng.
Agent hay mắc lỗi gì
Hiểu vòng lặp cũng giúp bạn nhận ra các kiểu thất bại đặc trưng:
- Đi lạc: hiểu sai yêu cầu từ bước đầu, rồi làm rất chăm chỉ theo hướng sai. Cách chữa: yêu cầu kế hoạch trước khi làm việc lớn, theo dõi và dừng sớm.
- Khám phá vô hạn: đọc hết file này tới file khác, ngữ cảnh đầy mà chưa làm gì. Cách chữa: chỉ rõ phạm vi, file liên quan.
- Sửa triệu chứng: thấy test đỏ thì sửa test, thấy lỗi kiểu thì ép kiểu cho qua. Cách chữa: dặn “sửa nguyên nhân gốc, không được tắt kiểm tra hay sửa test cho qua”.
- Vòng sửa đi sửa lại: bạn chỉnh, agent sửa, sinh lỗi khác, bạn chỉnh tiếp. Nếu đã chỉnh hơn hai lần cho cùng một vấn đề, thường nên mở phiên mới với prompt tốt hơn.
Bài Vòng lặp Khám phá → Lập kế hoạch → Code → Kiểm chứng → Commit06-03 sẽ biến những nguyên tắc này thành quy trình làm việc hằng ngày.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261012-016
12.10.2026
- Chị LanChủ chuỗi

Chị Lan cài một coding agent dòng lệnh lên máy và mở thư mục banhmoc-oms (lúc này mới có khung dự án). Việc đầu tiên chị giao rất nhỏ: “Trang danh sách đơn hàng đang hiển thị tổng tiền dạng 350000, hãy hiển thị thành 350.000 ₫.”
Chị chọn chế độ phê duyệt thủ công. Trên màn hình, chị thấy agent:
- Tìm kiếm chuỗi
totaltrong thư mụcsrc/features/orders/. - Đọc file component bảng đơn hàng.
- Phát hiện dự án đã có hàm
formatVNDtrongsrc/lib/format.ts, và dùng lại thay vì viết mới. - Xin phép sửa file. Chị đọc phần thay đổi (chỉ ba dòng) và đồng ý.
- Xin chạy
npm run typecheck. Chị chưa biết lệnh này, bèn hỏi agent. Agent giải thích đó là lệnh kiểm tra kiểu, chỉ đọc, không thay đổi gì. Chị đồng ý. - Báo cáo: đã sửa một file, type check không lỗi.
Chị nhận ra hai điều. Thứ nhất, vì dự án đã có sẵn formatVND, agent dùng lại đúng mẫu đó; một dự án ngăn nắp giúp agent làm đúng. Thứ hai, chị vẫn chưa tận mắt thấy trang hiển thị đúng. Chị yêu cầu thêm: “Mở trang danh sách đơn ở môi trường local và chụp màn hình cho chị xem.” Agent có công cụ trình duyệt nên làm được. Ảnh chụp cho thấy số tiền hiển thị đúng, nhưng cột tổng tiền bị lệch phải sang trái. Một lỗi mà type check không bao giờ bắt được.
Sau tuần đầu, chị đưa npm test, npm run lint, npm run typecheck, git status, git diff vào danh sách lệnh được phép. Những lệnh như git push hay bất cứ lệnh nào chạm tới database, chị vẫn để chế độ hỏi.
Prompt mẫu
Giao việc kèm yêu cầu tự kiểm chứng và bằng chứng:
Điền ô trống rồi sao chép
Trang /orders đang hiển thị tổng tiền dạng số thô (350000).
Mục tiêu: hiển thị dạng 350.000 ₫ ở mọi cột tiền trên trang này.
- Dùng lại hàm định dạng tiền có sẵn trong src/lib nếu có; không cài thư viện mới.
- Chỉ sửa trong src/features/orders/.
Khi xong: chạy npm run typecheck và npm test, dán output; liệt kê file đã sửa.
Sửa lỗi build mà không che triệu chứng:
Điền ô trống rồi sao chép
npm run build đang lỗi với thông báo sau:
[dán nguyên văn lỗi]
Hãy tìm nguyên nhân gốc và sửa. Không được tắt kiểm tra kiểu, không thêm "any",
không xóa hay sửa test để cho qua. Sau khi sửa, chạy lại build và dán kết quả,
kèm một câu giải thích nguyên nhân.
Hỏi trước khi cho phép một lệnh lạ:
Điền ô trống rồi sao chép
Trước khi chạy lệnh vừa đề xuất, hãy giải thích: lệnh này làm gì, có thay đổi file
hay dữ liệu nào không, có gọi mạng không, và có cách nào kiểm tra an toàn hơn không.
Sai lầm thường gặp
-
Sự cố 01
Dùng agent như chatbot.
Triệu chứngChép code từ agent ra ngoài, tự chạy, rồi dán lỗi vào. Bạn bỏ phí đúng thứ khiến agent mạnh.
Cách tránhĐể agent tự chạy lệnh kiểm tra trong dự án, bạn chỉ quan sát và nghiệm thu.
-
Sự cố 02
Bật chế độ tự động hoàn toàn ngay từ ngày đầu.
Triệu chứngCảm giác nhanh, nhưng bạn không biết agent đã làm gì và không học được gì.
Cách tránhBắt đầu bằng phê duyệt thủ công, mở rộng quyền dần qua allowlist, dùng sandbox cho việc tự động dài.
-
Sự cố 03
Tin vào câu “đã xong”.
Triệu chứngAgent dừng khi nó nghĩ đã xong, không phải khi phần mềm đúng.
Cách tránhLuôn yêu cầu bằng chứng: output test, build, ảnh chụp màn hình.
-
Sự cố 04
Không có công cụ kiểm chứng nào trong dự án.
Triệu chứngKhông có test, không có type check, agent chỉ còn biết “trông có vẻ đúng”.
Cách tránhTừ ngày đầu, có ít nhất lệnh type check, lint và vài unit test cho logic tiền.
-
Sự cố 05
Bấm đồng ý theo phản xạ.
Triệu chứngPhê duyệt mà không đọc thì còn tệ hơn không phê duyệt, vì cho bạn cảm giác an toàn giả.
Cách tránhĐưa lệnh an toàn vào allowlist để giảm số lần hỏi; với lệnh lạ, yêu cầu giải thích trước.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Quan sát vòng lặp
Mở một coding agent trong một thư mục dự án mẫu (có thể là dự án tạo bằng công cụ khởi tạo của Next.js). Giao việc: “Giải thích cấu trúc thư mục dự án này và cách chạy nó.” Ghi lại từng công cụ agent dùng (đọc file nào, chạy lệnh gì).
Kết quả mong đợi
Một danh sách 5–15 hành động, trong đó agent đọc
package.json, có thể đọcREADME.mdvà các file cấu hình. Bạn thấy rõ agent “tự tìm hiểu” thay vì đoán. -
Bài 2
Cơ bản
Thiết kế allowlist
Liệt kê 10 lệnh bạn nghĩ agent sẽ hay chạy trong dự án Bánh Mộc. Phân chúng thành ba nhóm: cho phép tự động, phải hỏi, cấm.
Kết quả mong đợi
Nhóm tự động gồm lệnh chỉ đọc và chạy kiểm tra; nhóm phải hỏi gồm cài gói, commit; nhóm cấm gồm lệnh chạm production, xóa hàng loạt, đẩy thẳng lên nhánh chính.
-
Bài 3
Nâng cao
So sánh có và không có kiểm chứng
Giao cùng một việc nhỏ (ví dụ viết hàm tính tổng tiền đơn trừ tiền cọc) hai lần ở hai phiên mới: lần một không nói gì về kiểm chứng; lần hai yêu cầu viết test cho ba trường hợp (bình thường, cọc bằng tổng, đơn rỗng) và chạy test trước khi báo xong.
Kết quả mong đợi
Lần hai có test, agent có thể tự phát hiện và sửa ít nhất một lỗi trước khi báo xong. Bạn tự cảm nhận được sự khác biệt về độ tin cậy.
Thuật ngữ trong bài
- Coding agent
- Phần mềm đặt LLM trong vòng lặp với công cụ để tự đọc, sửa, chạy code
- Vòng lặp agent (agentic loop)
- Chu trình suy nghĩ – hành động – quan sát lặp lại tới khi xong
- Công cụ (tool)
- Khả năng cụ thể agent được dùng: đọc file, chạy lệnh, duyệt web…
- Lời gọi công cụ (tool call)
- Yêu cầu có cấu trúc mà mô hình viết ra để bộ khung thực thi
- Bộ khung (harness)
- Phần mềm bao quanh mô hình, thực thi công cụ và quản lý ngữ cảnh
- Chế độ phê duyệt
- Mức độ agent phải hỏi bạn trước khi hành động
- Allowlist
- Danh sách lệnh được phép chạy không cần hỏi
- Sandbox
- Môi trường cô lập giới hạn file và mạng agent được truy cập
- Subagent
- Trợ lý phụ chạy trong ngữ cảnh riêng, báo về bản tóm tắt
- Prompt injection
- Nội dung độc hại cài vào dữ liệu agent đọc nhằm điều khiển nó
Đọc thêm
- Tài liệu về chế độ quyền và cách dùng agent: https://code.claude.com/docs
- Tài liệu chế độ agent trong trình soạn thảo: https://docs.cursor.com
- Tài liệu GitHub Copilot và coding agent: https://docs.github.com
- Bài liên quan: Vòng lặp Khám phá → Lập kế hoạch → Code → Kiểm chứng → Commit06-03, Bảo mật khi dùng agent09-07
Nghiệm thu tờ 02-02
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.

