Chắt từ chương 2 và 3 của khoá Agentic AI – Complete Course for Beginners (freeCodeCamp, 24h15m, giảng viên Bappy). Hai chương này dài 1h25m và không có một dòng code nào — đó là phần dành cho bạn.
Nâng cấp cách bạn dùng agent, và nâng cấp chính cái hệ bạn đang dùng. Hướng vào trong, không phải hướng ra ngoài. Đây không phải cẩm nang để đi chất vấn người khác.
Không có mục nào dạy bạn viết code. Cố ý.
| Chương | Tên | Về cái gì |
|---|---|---|
| 1 | Vì sao lại có agent | Bốn nấc tiến hoá, và lỗ hổng mà mỗi nấc sinh ra để vá |
| 2 | Agent khác chatbot chỗ nào | Định nghĩa, và sáu dấu hiệu nhận diện |
| 3 | Bên trong một agent có gì | Năm bộ phận cấu tạo |
| 4 | Giữ quyền kiểm soát | Phần con người — và phần nguy hiểm |
Phần hai — đi sâu vào phần con người (thêm 2026-08-01)
| Chương | Tên | Về cái gì |
|---|---|---|
| 5 | Đặt chốt duyệt ở đâu | Chốt thuộc về điểm hành động; bốn kiểu chốt; và nó tốn công tới đâu — dùng khi nghe báo giá |
| 6 | Rào chắn nhiều tầng | Hệ phòng thủ 5 tầng; che dữ liệu khách; và ví dụ chatbot y tế gần như trùng ngành spa |
| 7 | Bản đồ phần còn lại | 22 chương còn lại: cái gì làm cái gì, vì sao làm thế. Đi rộng, không đi sâu |
| 8 | Nhìn thấy khúc giữa | ⭐ Truy vết ≠ tự báo cáo — và vì sao vault này đã có sẵn trace mà chưa ai đọc |
Đọc theo thứ tự. Chương 1 là nền cho tất cả những chương sau. Chương 5–6 đi sâu hơn vào đúng phần chương 4 đặt ra, nên đọc sau chương 4. Chương 7 đọc lúc nào cũng được — nó là bản đồ, không phải bài học.
Nếu chỉ có thời gian đọc một chương: đọc chương 4. Nếu có thời gian đọc hai: thêm chương 6 — nó gần với công việc thật của bạn nhất.
Cuốn này không cố làm bạn thấy AI thần kỳ, cũng không phải bộ vũ khí để đi bắt bẻ ai. Nó cố cho bạn đủ hiểu để thiết kế lại.
Phản xạ mình mong bạn có sau khi đọc: nhìn một luồng làm việc đang chạy — kể cả cái vault này — và chỉ ra được "chỗ này thiếu bộ phận X", "chốt duyệt ở đây đặt sai chỗ", "cái này chưa bao giờ được kiểm".
⚠️ Ghi chú về bản đầu. Bốn chương đầu ban đầu được viết theo hướng khác — "để bạn không bị loè", tức là vũ khí chất vấn người bán hàng. Đó là Claude tự phỏng đoán mục đích của bạn, bạn chưa bao giờ nói vậy. Đã sửa hướng ngày 2026-08-01. Nội dung kiến thức không đổi; phần khung và các mục kết chương thì đổi.
Chỗ nào đọc thấy khó hiểu, hỏi ngay. Bạn phải hỏi tức là chỗ đó mình viết chưa đủ rõ — và mình sẽ sửa thẳng vào chương đó chứ không chỉ giải thích miệng.
Nguồn gốc mọi khẳng định: xem các trang wiki agentic-ai-chuong-02 và agentic-ai-chuong-03.
Bạn từng hỏi ChatGPT một chuyện mới xảy ra, và nó trả lời đại loại "tôi không có thông tin sau tháng 4 năm 2023".
Rồi vài tháng sau, bạn hỏi một chuyện mới toanh — và nó trả lời được, còn dẫn cả nguồn báo.
Chuyện gì đã xảy ra ở giữa? Câu trả lời không phải "AI thông minh lên". Đó là bốn nấc tiến hoá, và hiểu bốn nấc này là hiểu được phần lớn những gì đang diễn ra trong ngành.
Mỗi nấc sinh ra để vá đúng một lỗ hổng của nấc trước. Kể theo thứ tự thì rất dễ nhớ.
Một mô hình ngôn ngữ được huấn luyện bằng cách cho đọc một lượng khổng lồ văn bản trên internet. Rồi đến một ngày, người ta dừng lại. Ngày đó gọi là mốc chặn kiến thức (knowledge cutoff).
Hãy tưởng tượng một người đọc sách báo ngấu nghiến suốt nhiều năm, rồi bị nhốt vào một căn phòng kín không cửa sổ. Hỏi họ chuyện trước ngày bị nhốt: uyên bác. Hỏi chuyện sau đó: mù tịt.
Trong khoá học, giảng viên mở thẳng trang thông số kỹ thuật của một mô hình OpenAI và chỉ vào dòng chữ "knowledge cutoff: January 1, 2024". Nghĩa là: hỏi chuyện ngày 2 tháng 1 năm 2024, chịu.
Điều đáng lo hơn: người bị nhốt trong phòng đôi khi không biết là mình không biết. Đó là lý do AI thỉnh thoảng nói sai một cách rất tự tin.
Vậy làm sao để nó biết chuyện mới? Có ba cách, và đó chính là ba nấc còn lại.
Cách hiển nhiên nhất: nhồi dữ liệu mới vào mô hình rồi huấn luyện lại. Nghề gọi là fine-tuning (huấn luyện tinh chỉnh).
Cách này hoạt động. Vấn đề là giá.
Một mô hình có từ hàng triệu tới hàng tỉ tham số. Huấn luyện lại cần siêu máy tính, cần tiền thuê máy chủ, và cần thời gian. Giảng viên nói rất thật lòng ở đoạn này — đại ý: công ty lớn thì làm được vì họ có máy, có tiền, có thời gian; còn tôi làm ứng dụng cho khách hàng thì tôi không có siêu máy tính, không có ngân sách, và khách hàng của tôi phải làm ăn — họ không ngồi chờ tôi huấn luyện lại mô hình.
Đây là câu đáng nhớ, vì nó đúng với mọi doanh nghiệp nhỏ. Nấc 2 là con đường của tập đoàn, không phải của bạn.
Nếu không dạy lại được, thì đừng dạy nữa. Cứ để người đó trong phòng, nhưng đưa cho họ một tủ hồ sơ và bảo: trước khi trả lời, mở tủ tra đã.
Đó là RAG — viết tắt của retrieval-augmented generation, dịch thoáng là sinh văn bản có tra cứu tài liệu.
Cách nó chạy, kể theo trình tự:
Cái kho ấy là một loại cơ sở dữ liệu đặc biệt, tìm theo ý nghĩa gần nhau chứ không phải khớp từng chữ. Bạn hỏi "giá dịch vụ chăm sóc da mặt" thì nó cũng tìm ra tài liệu viết "chi phí liệu trình facial", dù không trùng chữ nào.
Vì sao RAG là bước tiến lớn: cập nhật kiến thức từ chỗ "cần siêu máy tính và vài tuần" xuống còn "bỏ thêm file vào tủ". Đó là lý do RAG bùng nổ, và tới hôm nay vẫn là cách phổ biến nhất để làm chatbot biết về doanh nghiệp của bạn.
Gần như mọi "chatbot AI cho doanh nghiệp" mà bạn được chào bán đều là RAG. Giờ bạn biết bên trong nó là gì.
Nhưng tủ hồ sơ có một điểm chết: ai đó phải bỏ giấy vào tủ.
Giảng viên chỉ ra chỗ hỏng bằng một ví dụ rất đời: tin tức buổi sáng bạn đã nạp vào kho rồi — còn tin buổi chiều thì sao? Tin một tiếng nữa thì sao? Không ai ngồi cả ngày nạp dữ liệu được.
Với thông tin thay đổi liên tục — thời tiết, giá cả, tồn kho, lịch hẹn — tủ hồ sơ luôn cũ.
Nên người ta làm khác: thay vì đưa tủ hồ sơ, đưa chìa khoá.
Chìa khoá ở đây gọi là công cụ (tool): quyền tìm kiếm trên web, quyền đọc lịch, quyền mở ổ đĩa, quyền gọi vào phần mềm khác. Và điểm mấu chốt — thứ làm nên cái tên "agent":
Chính nó tự quyết định khi nào cần dùng chìa khoá nào.
Bạn không lập trình "gặp câu hỏi kiểu này thì tra web". Bạn đưa chìa, đưa mục tiêu, rồi nó tự chọn.
Giảng viên demo ngay trên ChatGPT, hai câu hỏi liên tiếp:
Cùng một ứng dụng. Hai hành vi khác nhau. Không ai bảo nó phải tra — nó tự quyết.
Đó, chính xác đó, là ranh giới giữa nấc 3 và nấc 4.
Đây là thứ đáng mang theo nhất từ chương này. Áp lên cái bạn đang dùng — chứ không phải lên lời quảng cáo của ai:
1. Nó có biết chuyện xảy ra hôm nay không? → Không → đang ở nấc 1. Muốn lên thì phải thêm kho tài liệu hoặc công cụ.
2. Nó tra tài liệu của tôi, hay tra được cả thế giới bên ngoài? → Chỉ tra tài liệu tôi nạp vào → nấc 3. Tốt, nhưng có người phải nuôi kho đó — ai? bao lâu một lần?
3. Nó tự nghĩ ra các bước, hay tôi phải chỉ từng bước một? → Tôi phải chỉ từng bước → chưa phải agent. Câu hỏi tiếp theo: nó thiếu gì để tự nghĩ được — thiếu công cụ, thiếu quyền, hay thiếu mục tiêu rõ?
wiki/ là kho tài liệu của bạn; trình duyệt là cửa ra thế giới.⇒ Vault này ở nấc 4. Nhưng để ý câu 2: ai nuôi kho wiki/? Hiện là Claude tự nuôi, và bạn là người duy nhất kiểm. Đó là một điểm yếu có thật, không phải chi tiết vụn.
1. Vì sao ChatGPT ngày xưa không trả lời được tin mới, mà bây giờ lại được? Không phải vì mô hình thông minh lên hay hết mốc chặn kiến thức. Mốc chặn vẫn còn nguyên. Thứ được thêm vào là công cụ tìm kiếm web — và khả năng tự quyết định khi nào dùng nó.
2. RAG và fine-tuning khác nhau ở đâu? Fine-tuning sửa chính mô hình — đắt, chậm, cần siêu máy tính. RAG để nguyên mô hình, chỉ đặt cạnh nó một kho tài liệu — rẻ, nhanh, cập nhật bằng cách bỏ thêm file.
3. Điều gì khiến một hệ thống được gọi là "agentic"? Không phải vì nó thông minh hơn. Vì nó tự quyết định các bước, thay vì chờ bạn chỉ từng bước.
Toàn bộ chương này rút từ chương 2 của khoá học (00:08:33 → 00:41:26). Trích dẫn chi tiết kèm mốc thời gian: xem agentic-ai-chuong-02 và bon-nac-tien-hoa-ai.
Chương sau: Agent khác chatbot chỗ nào — sáu dấu hiệu nhận diện.
Bạn đang dùng vài công cụ AI. Chúng trông na ná nhau: một ô chat, gõ vào, nó trả lời.
Nhưng bên dưới thì rất khác nhau — và cái khác đó quyết định bạn giao được việc gì cho chúng. Giao nhầm loại việc cho nhầm loại công cụ là lý do phổ biến nhất khiến người ta thất vọng với AI: không phải công cụ tệ, mà là dùng sai chỗ.
Chương này cho bạn thước đo để phân loại. Trước hết là định nghĩa, sau đó là sáu dấu hiệu.
Định nghĩa trong khoá học:
Agentic AI là một loại AI có thể nhận một nhiệm vụ hoặc mục tiêu từ người dùng, rồi tự làm cho xong với sự hướng dẫn tối thiểu của con người. Nó lập kế hoạch, hành động, thích ứng với thay đổi, và chỉ xin trợ giúp khi cần.
Đọc lại chữ "tối thiểu". Không phải "không cần". Giảng viên dừng lại nhấn riêng chữ này. Chương 4 sẽ cho thấy vì sao chữ đó quan trọng đến mức đáng để nhấn.
Rất nhiều người nghĩ "agentic" nghĩa là thông minh hơn. Không phải.
Cùng một mô hình ngôn ngữ có thể đứng sau cả chatbot lẫn agent. Khác biệt không nằm ở độ thông minh, mà ở chỗ:
Ai là người nghĩ ra bước tiếp theo?
Giảng viên nói gọn: "Vì sao gọi hệ này là agent? Vì ứng dụng đủ thông minh để tự hiểu khi nào cần gọi công cụ và khi nào không. Ở đây ta không quyết định thay nó."
Chatbot là người tra cứu. Bạn hỏi gì đáp nấy. Hỏi xong là hết việc.
Agent là người trợ lý. Bạn nói "lo giúp chị vụ tuyển người" — họ tự soạn tin, tự đăng, tự lọc hồ sơ, tự hẹn lịch, và quay lại hỏi bạn ở đúng những chỗ cần quyết.
Khoá học dựng một ví dụ rất sáng: agent tuyển dụng.
Người dùng gõ đúng một câu:
"Tôi muốn tuyển một kỹ sư backend, kinh nghiệm 2–4 năm."
Rồi thôi. Sau đó agent tự chạy:
Hãy để ý bước 4. Đó là chỗ chatbot không bao giờ làm được. Chatbot không tự nhận ra kế hoạch đang thất bại, và càng không tự đề xuất sửa.
Và hãy để ý một chỗ nữa: con người vẫn tự phỏng vấn. Agent chuẩn bị mọi thứ quanh cuộc phỏng vấn, nhưng không thay chỗ đó. Cũng như ở mỗi bước trên, nó dừng lại xin xác nhận trước khi đi tiếp.
Đây là thước đo. Đủ sáu thì là agent thật.
Tự ra quyết định và hành động, không cần chỉ từng bước. Trong ví dụ trên: một câu lệnh, mười một bước tự chạy.
Nó coi câu bạn nói là một mục tiêu bền, không phải một câu hỏi rời rạc. Giảng viên có một câu rất đắt:
"Mục tiêu đóng vai trò chiếc la bàn cho tính tự chủ."
Không có mục tiêu thì tự chủ chỉ là chạy loạn.
Bẻ mục tiêu lớn thành chuỗi việc nhỏ, đúng thứ tự.
Điểm hay: agent có thể đưa ra nhiều phương án rồi tự chấm điểm. Trong khoá học, nó đưa hai lựa chọn — phương án A: tự đăng tin lên các nền tảng, nhanh và rẻ; phương án B: thuê công ty tuyển dụng, đắt hơn vì phải mua gói dịch vụ — rồi tự so tốc độ, chi phí, rủi ro, và hỏi bạn chọn cái nào.
Nó không chỉ làm. Nó cân nhắc rồi mới làm.
Đây là dấu hiệu quan trọng nhất, và là phần do mô hình ngôn ngữ đảm nhiệm. Suy luận quyết định: bẻ mục tiêu thế nào, dùng công cụ nào cho bước nào, khi nào phải dừng hỏi người, và làm gì khi công cụ hỏng ("công cụ A không chạy thì chuyển sang công cụ B").
⭐ Đây chính là ranh giới. Không có suy luận thì chỉ là chatbot. Giảng viên nói thẳng như vậy.
Đổi kế hoạch khi thực tế không như dự tính, mà vẫn bám mục tiêu. Chính là bước 4 trong ví dụ: hồ sơ về quá ít → tự nới vị trí, tự đề xuất quảng cáo.
Nhớ việc đang làm dở.
Ví dụ trong khoá rất dễ hình dung: bạn giao việc tuyển người, rồi đi vắng hai ngày. Quay lại hỏi "tuyển tới đâu rồi?"
Với việc kéo dài nhiều ngày, thiếu dấu hiệu này là hỏng.
Áp lên từng công cụ bạn đang dùng, rồi quyết định giao việc gì cho cái nào:
💡 Áp vào vault này. Soi sáu ô thì Claude đủ cả sáu, nhưng ô số 6 — nhớ ngữ cảnh — là ô yếu nhất và được chống bằng nạng:
wiki/vàlog.mdlà bộ nhớ lắp ngoài, do chính Claude viết ra. Nghĩa là ô yếu nhất lại là ô ít được kiểm nhất. Nếu bạn định nâng cấp một thứ, đây là ứng viên hàng đầu.
1. Cùng một mô hình ngôn ngữ, cái gì biến nó từ chatbot thành agent? Khả năng suy luận để tự quyết định các bước — và được trao công cụ để thực hiện các bước đó. Không phải mô hình thông minh hơn.
2. Trong ví dụ tuyển dụng, bước nào chứng minh rõ nhất đây là agent chứ không phải chatbot? Bước 4 — tự nhận ra chỉ có 2 hồ sơ thay vì 20, rồi tự đề xuất đổi chiến lược. Chatbot không tự phát hiện kế hoạch đang hỏng.
3. Vì sao "mục tiêu là la bàn của tính tự chủ"? Vì tự chủ mà không có mục tiêu rõ thì chỉ là hành động vô hướng. Mục tiêu là thứ cho phép agent tự đánh giá "việc này có đưa mình tới đích không?" — nền tảng của cả lập kế hoạch lẫn thích ứng.
Rút từ chương 2 và 3 của khoá học. Trích dẫn kèm mốc thời gian: agentic-ai và sau-dac-tinh-agent.
Chương sau: Bên trong một agent có gì
Chương 2 dạy bạn nhìn agent từ ngoài vào: nó cư xử thế nào. Chương này nhìn từ trong ra: nó làm bằng gì.
Nghe có vẻ kỹ thuật, nhưng thực ra rất thực dụng. Vì khi có người chào bán agent cho bạn, họ sẽ nói về một hoặc hai bộ phận và im lặng về những bộ phận còn lại. Biết đủ năm bộ phận thì bạn biết cái gì đang thiếu.
Chỉ có năm thứ. Dễ nhớ hơn bạn tưởng.
Toàn bộ khả năng suy nghĩ nằm ở đây. Giảng viên nói: "mô hình ngôn ngữ là bộ não duy nhất mà hệ agentic có."
Nó lo bốn việc: hiểu mục tiêu bạn giao · lập kế hoạch · suy luận · chọn công cụ nào cho bước nào.
Hệ quả thực tế với bạn: chọn mô hình nào không chỉ ảnh hưởng tới văn phong của câu trả lời. Nó ảnh hưởng tới chất lượng quyết định. Một agent chạy trên mô hình yếu sẽ lập kế hoạch dở, chọn nhầm công cụ, và không nhận ra khi nào mình đang sai.
Nên khi ai đó chào bán agent, đây là câu hỏi hợp lệ: "chạy trên mô hình nào?"
Tên nghề: orchestrator. Đây là bộ khung phần mềm nối bộ não với công cụ, với bộ nhớ, và với con người.
Nó lo phần "thứ tự": việc nào trước việc nào sau · khi nào rẽ nhánh · hỏng thì thử lại mấy lần · khi nào lặp · khi nào dừng lại hỏi người.
Giảng viên nhấn: "Không thể tạo bằng Python trần được. Phải dùng một framework trọn gói."
So sánh: nếu mô hình ngôn ngữ là cái đầu và công cụ là tay chân, thì bộ điều phối là hệ thần kinh nối chúng lại và quy định thứ tự hành động.
Các tên bạn sẽ nghe: LangGraph (trọng tâm của khoá này), LangChain (đời trước, cùng đội ngũ), CrewAI, AutoGen.
💡 Một cái tên đáng nhớ riêng cho bạn: n8n. Đây là nền tảng dựng luồng bằng kéo thả, không cần viết code. Giảng viên có nhắc tên nhưng khoá học không dạy nó — mình đã kiểm cả 26 chương. Nếu sau này bạn muốn tự dựng một luồng tự động cho spa hay cho phễu mà không muốn học Python, đây là hướng đáng tìm hiểu, chứ không phải LangGraph.
Đã gặp ở chương 1: tìm kiếm web, lịch, email, ổ đĩa, cơ sở dữ liệu, và API của gần như mọi phần mềm.
Khoá học mở một danh mục công cụ để cho thấy độ phong phú: công cụ tìm kiếm, công cụ đọc bài nghiên cứu khoa học, công cụ chạy code, công cụ năng suất (lịch, email, Zoom), công cụ duyệt web, công cụ truy cập cơ sở dữ liệu, công cụ thao tác tệp tin. Hàng nghìn cái.
So sánh: công cụ là chùm chìa khoá bạn đưa cho trợ lý. Chìa tủ hồ sơ, chìa xe, thẻ ra vào, quyền đặt lịch.
Đưa nhiều chìa thì họ làm được nhiều việc hơn — và cũng gây hỏng được nhiều thứ hơn. Chuyện đưa chìa nào là nội dung chương 4.
Một chi tiết thú vị: trong hệ có RAG, cái tủ hồ sơ ở chương 1 cũng được tính là một công cụ. Nấc 3 trở thành một bộ phận nhỏ bên trong nấc 4.
Chỗ agent giữ lại việc đang làm dở. Chia hai loại:
| Ngắn hạn | Dài hạn | |
|---|---|---|
| Giữ gì | Trạng thái việc đang chạy | Toàn bộ lịch sử trao đổi |
| Ví dụ | Đang ở bước 4/11, vừa lọc xong hồ sơ | Mọi lần bạn và nó làm việc từ đầu tới nay |
So sánh: ngắn hạn là tờ giấy nháp trên bàn khi đang làm dở một việc. Dài hạn là cuốn sổ tay ghi lại mọi việc đã làm. Người trợ lý không có sổ tay thì sáng nào cũng phải được kể lại từ đầu.
Cụ thể hơn: agent giữ một bản ghi có cấu trúc, gồm mục tiêu (tuyển kỹ sư backend), ràng buộc (2–4 năm kinh nghiệm, làm từ xa, kỹ năng cần có), và tiến độ (đã soạn mô tả chưa, đăng ở đâu, nhận mấy hồ sơ, hẹn mấy buổi phỏng vấn).
Nhờ bản ghi đó mà bạn đi vắng hai ngày quay lại vẫn hỏi được "tới đâu rồi".
Bộ phận cuối, và là bộ phận mình muốn bạn nhớ nhất.
Nó lo ba việc: xin duyệt trước những bước quan trọng · thực thi các luật cứng mà agent không được vượt · báo động khi bất định — như giảng viên nói, "báo cho con người khi xuất hiện mâu thuẫn hoặc điều không chắc chắn".
⭐ Điểm đáng chú ý nhất của chương này: con người là một bộ phận trong kiến trúc, không phải phụ kiện gắn thêm sau.
Nghĩa là: một agent được thiết kế đàng hoàng thì chỗ cho bạn can thiệp đã được chừa sẵn từ khi vẽ bản thiết kế. Nếu ai đó bán cho bạn một agent mà phần "người duyệt" phải chắp vá thêm vào sau, đó là dấu hiệu họ dựng ẩu.
Chính cái vault này — nơi bạn đang đọc — cũng có gần đủ năm bộ phận:
| Bộ phận | Trong vault của bạn |
|---|---|
| Bộ não | Mô hình đang chạy |
| Bộ điều phối | Phần mềm Claude Code — chạy vòng lặp gọi công cụ, thử lại khi hỏng, chặn quyền. Còn CLAUDE.md là luật quy trình đặt bên trên nó, không phải bản thân bộ điều phối |
| Công cụ | Trình duyệt, tải file, đọc và ghi tệp, chạy lệnh |
| Bộ nhớ | Thư mục wiki/ và cuốn nhật ký wiki/log.md — ⚠️ nằm ngoài mô hình, xem ghi chú dưới |
| Giám sát viên | Mỗi lần dừng lại hỏi bạn trước khi cài đặt hay tải về |
Đây không phải ví von cho vui. Cuốn nhật ký log.md tồn tại đúng vì lý do nêu ở bộ phận số 4: không ghi thì phiên làm việc sau mất trí nhớ.
⚠️ Một chỗ sách vở gọn hơn thực tế. Ở trên, bộ nhớ được mô tả như một bộ phận có sẵn bên trong agent. Với các trợ lý AI bạn đang dùng thì không hẳn vậy: mô hình ngôn ngữ tự nó không nhớ gì sau khi phiên làm việc kết thúc. Trí nhớ dài hạn phải được gắn thêm từ bên ngoài — bằng file, bằng cơ sở dữ liệu.
Cả trí nhớ ngắn hạn cũng có giới hạn: mô hình chỉ "nhìn" được một lượng chữ nhất định cùng lúc, phiên làm việc dài thì phần cũ bị tóm tắt lại, tức là có hao hụt.
⇒ Câu hỏi thực dụng khi đánh giá một trợ lý AI: "nó nhớ được bao lâu, và trí nhớ đó lưu ở đâu?" Nếu câu trả lời là "không lưu đâu cả" thì mỗi lần dùng bạn phải kể lại từ đầu.
1. Vì sao chọn mô hình ngôn ngữ nào lại quan trọng hơn bạn tưởng? Vì mô hình là bộ não duy nhất — nó không chỉ viết câu trả lời mà còn lập kế hoạch và ra quyết định. Mô hình yếu thì agent quyết định dở, không chỉ viết dở.
2. Bộ điều phối làm gì mà không dựng bằng code thường được? Nó lo thứ tự và luồng: rẽ nhánh, thử lại khi hỏng, lặp, gọi công cụ, và dừng lại chờ người duyệt. Tự viết từ đầu thì phải làm lại toàn bộ những thứ này.
3. Vì sao "giám sát viên là một bộ phận" lại là điều đáng mừng? Vì nó có nghĩa quyền kiểm soát của bạn được thiết kế sẵn từ đầu, chứ không phải thứ vá thêm khi có sự cố.
Rút từ chương 3 của khoá học (00:41:26 → 01:33:18). Trích dẫn kèm mốc thời gian: nam-thanh-phan-agent.
Chương sau: Giữ quyền kiểm soát — phần quan trọng nhất.
Giảng viên đặt cho phần này một tiêu đề không hề vòng vo: "tính tự chủ có thể nguy hiểm". Rồi đưa ba ví dụ. Mình giữ nguyên cả ba, vì cả ba đều là chuyện đời thật chứ không phải giả định kỹ thuật.
Một. Agent tuyển dụng gửi thư mời làm việc cho ứng viên — với mức lương sai. Ngân sách của bạn là một, thư ghi mười. Thư đã gửi đi rồi, cho một người ngoài công ty.
Hai. Agent sàng lọc hồ sơ theo tuổi hoặc theo quốc tịch. Vi phạm luật chống phân biệt đối xử. Không ai bảo nó làm vậy — nó chỉ đang tối ưu theo dữ liệu cũ.
Ba. Agent được giao chạy quảng cáo tuyển dụng. Hồ sơ đã về đủ, nhưng nó vẫn thấy "cần thêm nữa" và tiếp tục đốt tiền quảng cáo.
Bây giờ hãy để ý điều quan trọng nhất về cả ba chuyện này:
Không có chuyện nào là lỗi kỹ thuật.
Agent chạy đúng như được bảo. Nó không hỏng, không bị lỗi, không bị tấn công. Cái sai là không ai đặt giới hạn cho nó.
Đây là lý do chương này quan trọng hơn ba chương trước cộng lại — với người sắp cho AI đụng vào tiền, vào khách hàng, vào nhân sự.
"Tôi không thể trao toàn quyền cho agent làm mọi thứ. Chắc chắn phải có quan sát của con người. Nếu không thì có thể xảy ra chuyện khác."
Và nhớ lại định nghĩa ở chương 2 — "với sự hướng dẫn tối thiểu của con người". Tối thiểu. Không phải bằng không. Giảng viên nhấn chữ đó ngay từ đầu khoá, và tới đây thì rõ vì sao.
Mục tiêu của agentic AI không phải là loại con người ra khỏi vòng lặp. Là giảm con người xuống mức tối thiểu cần thiết — rồi giữ chặt cái mức tối thiểu đó.
Khoá học nêu năm cơ chế. Mình sắp lại theo thứ tự bạn sẽ dùng trong thực tế.
Định sẵn agent được làm gì và không được làm gì.
Ví dụ nguyên văn trong khoá: "được sàng lọc ứng viên một cách độc lập, nhưng phải xin duyệt trước khi loại bất kỳ ai."
Để ý sự khéo léo ở đây: nó không chặn agent làm việc. Nó chỉ chặn đúng cái hành động khó thu hồi — loại một người.
Tên nghề: human-in-the-loop, viết tắt HITL. Đây là những chốt cài sẵn trong luồng, buộc agent dừng lại chờ bạn duyệt rồi mới đi tiếp.
Trong ví dụ tuyển dụng, các chốt nằm ở: duyệt mô tả công việc trước khi đăng · duyệt trước khi đổi chiến lược · duyệt trước khi hẹn phỏng vấn · duyệt thư mời làm việc trước khi gửi.
Và con người vẫn tự phỏng vấn — agent chuẩn bị mọi thứ quanh cuộc phỏng vấn nhưng không thay chỗ đó.
Nguyên tắc đặt chốt: đặt ở nơi hành động khó thu hồi hoặc tốn tiền. Gửi email cho người ngoài. Tiêu tiền. Loại một ứng viên. Xoá dữ liệu. Cam kết với khách hàng.
Ở những chỗ dễ sửa — soạn nháp, sắp xếp, tổng hợp — thì đừng đặt chốt, kẻo mất luôn cái lợi của tự động hoá.
Bạn đã gặp HITL rồi mà không gọi tên:
Dừng, tạm dừng, hoặc đổi hành vi giữa chừng. "Đang chạy vòng sàng lọc, giữa chừng tôi thấy cần dừng thì ra lệnh là nó phải dừng."
Khác với hai cái trên ở chỗ: bạn khởi xướng, không phải agent. Đây là cái phanh tay.
Tên nghề: guardrails. Đây là những luật agent tuyệt đối không được vượt, kể cả khi nó đang tự chủ và cho rằng vượt thì tốt hơn.
Ví dụ trong khoá rất đời: "không bao giờ xếp phỏng vấn vào cuối tuần" — vì cuối tuần sếp bận.
Đây cũng chính là cơ chế khiến mọi trợ lý AI từ chối các yêu cầu độc hại. Có hẳn framework chuyên làm việc này.
Phân biệt với giới hạn quyền: giới hạn quyền nói "việc này phải hỏi tôi". Rào chắn nói "việc này không bao giờ được làm". Cái đầu là chốt, cái sau là tường.
Agent tự báo khi gặp mâu thuẫn hoặc khi nó không chắc. Trong ví dụ tuyển dụng, agent hỏi ngược: "khoảng lương nên đặt bao nhiêu?"
Đây là cái phanh tinh tế nhất, và cũng là dấu hiệu chất lượng rõ nhất. Một hệ thống tốt biết khi nào mình không biết. Một hệ thống tệ thì đoán bừa và im lặng đi tiếp — và bạn chỉ phát hiện khi thư mời lương sai đã gửi đi.
| Ai khởi xướng | Lúc nào | Ví dụ | |
|---|---|---|---|
| Giới hạn quyền | Bạn, đặt trước | Trước khi chạy | "Không được loại ai mà chưa hỏi" |
| HITL | Agent, dừng lại hỏi | Ở các chốt đã cài | "Tôi gửi thư này nhé?" |
| Quyền can thiệp | Bạn, cắt ngang | Bất cứ lúc nào | "Dừng ngay" |
Đây là thứ đáng giá nhất trong cả cuốn sách này. Áp lên mọi hệ AI bạn đang dùng hoặc sắp dựng — kể cả cái vault này. Năm câu:
1. Agent này được phép làm gì mà không cần hỏi tôi? Không trả lời được câu này nghĩa là chưa ai nghĩ tới chuyện giới hạn quyền.
2. Nó dừng lại xin duyệt ở những bước nào? Nghe câu trả lời và đối chiếu: các bước tốn tiền hoặc khó thu hồi có nằm trong danh sách không?
3. Tôi dừng nó giữa chừng bằng cách nào? Phải có một cách cụ thể. "Thì tắt phần mềm đi" không phải câu trả lời tốt.
4. Có luật cứng nào nó tuyệt đối không được vượt không? Ví dụ: không bao giờ gửi tiền, không bao giờ hứa giảm giá quá X phần trăm, không bao giờ trả lời khách về vấn đề y tế.
5. Khi nó không chắc thì nó im lặng đoán hay hỏi tôi? Câu này phân loại người dựng giỏi với người dựng ẩu nhanh nhất.
Một hệ mà bạn không trả lời được năm câu này thì chưa an toàn để đụng vào tiền hoặc khách hàng thật. Không phải vì nó dở — mà vì nó đang được nghĩ theo hướng làm được gì, chưa nghĩ theo hướng có thể làm hỏng gì.
| Câu | Vault "Học điều mới" |
|---|---|
| 1. Được làm gì không cần hỏi? | Đọc file, chạy lệnh chỉ-đọc, tìm kiếm, ghi vào wiki/ và production/ |
| 2. Dừng xin duyệt ở đâu? | Trước khi cài phần mềm, tải file, làm gì ra ngoài |
| 3. Dừng giữa chừng thế nào? | Bấm Esc, hoặc gõ chen vào |
| 4. Luật cứng nào? | Không sửa/xoá raw/, không chạy code khoá học, không xoá mục log.md |
| 5. Không chắc thì hỏi hay đoán? | ⚠️ Đã trượt ba lần. Xem dưới |
Câu 5 là chỗ hệ này đang hỏng. Ba lần trong một phiên làm việc, Claude gặp chỗ không chắc và đoán thay vì kiểm — rồi ghi cái đoán đó vào file vĩnh viễn như một sự thật. Cả ba lần đều bạn phát hiện, không phải hệ thống.
⇒ Đây không phải chuyện đáng chê trách ai. Nó là một hạng mục nâng cấp cụ thể: hệ này thiếu cơ chế bắt Claude gắn nhãn độ chắc chắn, và thiếu cách nhìn lại xem nó đã làm gì. Chương 5, 6, 7 sẽ cho thêm nguyên liệu để thiết kế chỗ đó.
Cả khoá học 24 tiếng này dạy cách dựng agent. Bốn chương bạn vừa đọc rút ra từ 1 tiếng 25 phút đầu tiên — phần duy nhất không có dòng code nào.
Nhưng nếu bạn chỉ giữ lại một ý từ tất cả những gì đã đọc, mình mong đó là ý này:
Câu hỏi hay không phải "AI này làm được gì". Câu hỏi hay là "khi nó sai thì ai chịu, và tôi dừng nó bằng cách nào".
Câu thứ nhất thì mọi thứ xung quanh bạn đều đang trả lời sẵn. Câu thứ hai thì bạn phải tự đặt ra cho từng hệ mình dựng — và tự trả lời bằng thiết kế, chứ không bằng hy vọng.
1. Ba sự cố ở đầu chương có điểm chung gì? Không cái nào là lỗi kỹ thuật. Agent chạy đúng như được bảo — cái thiếu là giới hạn do con người đặt ra.
2. Đặt chốt HITL ở đâu là đúng? Ở nơi hành động khó thu hồi hoặc tốn tiền: gửi ra ngoài, tiêu tiền, loại người, xoá dữ liệu, cam kết với khách. Không đặt ở những bước dễ sửa, kẻo mất luôn cái lợi của tự động hoá.
3. Rào chắn khác giới hạn quyền chỗ nào? Giới hạn quyền nói "việc này phải hỏi tôi" — là cái chốt. Rào chắn nói "việc này không bao giờ được làm" — là bức tường.
4. Vì sao "leo thang khi bất định" lại là dấu hiệu chất lượng? Vì hệ thống tốt biết khi nào mình không biết và chủ động hỏi. Hệ thống tệ thì đoán bừa rồi im lặng đi tiếp — và bạn chỉ biết khi hậu quả đã ra ngoài.
Rút từ chương 3 của khoá học (01:07:48 → 01:12:24) và chương 2 (00:14:48). Trích dẫn kèm mốc thời gian: guardrails-va-kiem-soat và human-in-the-loop.
Hết cuốn. Quay lại mục lục.
Chương 4 nói bạn nên có chốt duyệt. Câu hỏi tiếp theo là câu khó hơn: đặt ở đâu, và ai trả giá cho việc đó.
Chương này rút từ chương 22 của khoá học — chương duy nhất trong phần thực chiến mà mình thấy đáng đọc kỹ cho người không code. Không phải vì code, mà vì nó buộc phải trả lời hai câu hỏi thiết kế mà chương lý thuyết né được.
Trước hết, một định nghĩa đầy đủ hơn cái ở chương 4:
Chốt duyệt là một CÁCH THIẾT KẾ, trong đó con người tham gia chủ động tại các điểm then chốt của luồng — để giám sát, phê duyệt, sửa, hoặc dẫn hướng đầu ra.
Chú ý cụm "cách thiết kế". Giảng viên nhấn: "đây hoàn toàn là triết lý thiết kế của bạn." Nó không phải một nút bật/tắt ai đó bán kèm.
"Không nhất thiết phải thêm chốt duyệt vào mọi tính năng, mọi tác vụ. Chỗ nào bạn thấy cần thì thêm ở đó."
Trong con chatbot demo của khoá học, cùng một ứng dụng:
| Việc | Có chốt? |
|---|---|
| Tra thời tiết | ❌ Không |
| Tìm kiếm trên web | ❌ Không |
| Hỏi đáp trên tài liệu đã tải lên | ❌ Không |
| Mua cổ phiếu | ✅ Có |
Ba việc đầu: sai thì hỏi lại, không mất gì. Việc thứ tư: sai thì mất tiền thật.
Đây là điều dễ làm sai theo cả hai hướng. Đặt chốt quá ít thì mất kiểm soát. Đặt chốt quá nhiều thì bạn mất luôn cái lợi của tự động hoá — một trợ lý hỏi bạn ở mọi bước thì không phải trợ lý, đó là bạn tự làm mà còn phải gõ thêm.
Đây là ý đắt nhất của cả chương, và giảng viên dạy nó bằng cách làm sai trước rồi sửa.
Ở ví dụ đầu tiên, ông đặt chốt vào chỗ trò chuyện: mỗi lần bạn hỏi bất cứ điều gì, nó dừng lại hỏi "bạn có thật sự muốn hỏi câu này không?". Ông tự nhận ngay: "nghe thì buồn cười, nhưng để bạn hiểu cách cài đặt."
Rồi ở ứng dụng thật, ông đổi hẳn:
"Khi bạn dùng nhiều công cụ và làm ứng dụng nâng cao, ở chỗ trò chuyện bạn không cần thêm chốt — bạn sẽ thêm bên trong công cụ. Vì với công cụ là bạn đang thực hiện một hành động, và chốt duyệt nên nằm ở đó."
Dịch sang tiếng người:
Đừng bắt nó xin phép để NÓI. Bắt nó xin phép để LÀM.
Chốt ở chỗ trò chuyện thì phiền mà chẳng an toàn hơn — vì nói thì có hại gì đâu. Chốt ở chỗ hành động thì đúng vào nơi tốn kém nếu sai.
Nghe hiển nhiên khi viết ra, nhưng đây chính là chỗ nhiều người dựng hệ thống làm ngược: họ bắt xác nhận ở đầu vào cho "an toàn", rồi để phần hành động chạy tự do.
Khoá học chạy thử cùng một câu lệnh trên hai bản.
Bản không chốt:
Bạn: "Mua 10 cổ phiếu Apple." Máy: "Đã đặt lệnh mua thành công 10 cổ phiếu Apple."
Xong. Không hỏi gì.
Bản có chốt:
Bạn: "Mua 20 cổ phiếu Apple." Máy: "Cần người duyệt. Đồng ý mua 20 cổ phiếu Apple? Yes hay No." Bạn: "Yes." Máy: "Đã đặt lệnh mua 20 cổ phiếu Apple."
Và khi từ chối:
Bạn: "No." Máy: "Yêu cầu mua 20 cổ phiếu Google đã bị từ chối."
Lý do giảng viên đưa ra rất thẳng, và mình muốn bạn nhớ nguyên văn:
*"Đây là mô hình ngôn ngữ, nó có thể làm sai. Nó có thể bịa. Nó không phải lúc nào cũng hoàn hảo."*
Bảo mua 10 có thể thành 20. Bảo mua Apple có thể thành Google. Đây không phải chuyện lỗi phần mềm hiếm gặp — đây là tính chất của công nghệ này. Chốt duyệt tồn tại vì tính chất đó, không phải vì ai đó viết code ẩu.
Không phải chốt nào cũng giống nhau. Biết bốn kiểu này thì bạn hỏi được câu đúng: không phải "chỗ này có cần duyệt không" mà "chỗ này cần kiểu duyệt nào".
1. Duyệt hành động. Agent dừng lại trước khi bấm nút, bạn đồng ý hoặc từ chối. Dùng cho: tiêu tiền, gửi ra ngoài, xoá.
2. Xem lại và sửa. Agent đưa bản nháp, bạn sửa được rồi mới chốt. Khác kiểu 1 ở chỗ bạn can thiệp được vào nội dung chứ không chỉ gật hay lắc. Dùng cho: bài viết, email, báo cáo.
Ví dụ trong khoá rất đáng chú ý: agent soạn bài đăng LinkedIn thì không cần duyệt; nhưng lúc đăng lên thì cần. Chốt đặt ở bước ra ngoài, không phải bước sáng tác.
3. Hỏi lại khi mơ hồ. Bạn bảo "xếp lịch họp thứ Sáu" — nhưng có thứ Sáu tuần này và thứ Sáu tuần sau. Agent hỏi lại.
Kiểu này khác ba kiểu kia ở một điểm quan trọng: ba kiểu kia do bạn cài sẵn, kiểu này do agent tự khởi xướng. Nó đòi hỏi agent biết khi nào mình không biết — đúng câu hỏi số 5 ở chương 4.
4. Leo thang. Chatbot thấy ca này quá tầm mình, chuyển cho người thật. Với người làm dịch vụ thì đây là kiểu đáng quan tâm nhất sau kiểu 1: nó quyết định khách hàng bị bot làm phiền tới mức nào trước khi được gặp người.
Đây là lý do chính mình khuyên bạn đọc kỹ chương này.
Khi luồng dừng lại chờ bạn duyệt, rồi bạn bấm đồng ý — nó phải chạy tiếp từ đúng chỗ đã dừng, chứ không phải làm lại từ đầu. Muốn vậy thì toàn bộ trạng thái phải được lưu xuống đĩa trước khi dừng.
Giảng viên nói thẳng: "Bạn phải có bộ nhớ bền vững… nếu không, khi chạy lại nó sẽ không biết mình dừng ở đâu."
Nghĩ kỹ thì hiển nhiên: dừng chờ người tức là chương trình phải sống sót qua một khoảng thời gian không xác định. Bạn có thể duyệt sau 5 giây, cũng có thể sau 2 ngày.
⇒ Không có bộ nhớ bền vững thì không có chốt duyệt. Hai thứ dính chặt nhau.
Nên "thêm một bước duyệt" không phải là "thêm một câu hỏi". Nó kéo theo:
💰 Dùng cái này khi nghe báo giá. Nếu ai đó nói "thêm bước duyệt thì nhanh thôi", hỏi lại: "hệ thống hiện đã lưu trạng thái ra cơ sở dữ liệu chưa?" Chưa có thì đó là việc lớn, không phải việc nhỏ — và bạn nên biết điều đó trước khi ký.
Phần giao diện — cái nút Yes/No hiện trên màn hình — giảng viên không tự viết. Ông dán code vào ChatGPT và bảo nó thêm giúp.
Chi tiết này đáng chú ý: phần khó không nằm ở giao diện. Phần khó nằm ở việc quyết định đặt chốt ở đâu và làm cho luồng chịu được việc bị dừng giữa chừng. Cái nút thì máy viết hộ được.
Điều đó cũng có nghĩa: thứ bạn cần đóng góp khi thuê người dựng hệ thống, chính là phần máy không làm thay được — biết việc nào trong nghề của bạn là việc không được sai.
1. Vì sao đặt chốt duyệt ở chỗ trò chuyện là sai chỗ? Vì nói thì không gây hại. Chốt phải nằm ở điểm hành động — nơi agent thật sự làm gì đó ra ngoài: tiêu tiền, gửi đi, xoá.
2. Vì sao chốt duyệt bắt buộc phải có bộ nhớ lưu ra đĩa? Vì dừng chờ người nghĩa là chương trình phải sống sót qua thời gian không xác định — có thể 5 giây, có thể 2 ngày — rồi chạy tiếp từ đúng chỗ đã dừng.
3. Kiểu chốt "hỏi lại khi mơ hồ" khác ba kiểu kia ở đâu? Ba kiểu kia bạn cài sẵn; kiểu này agent tự khởi xướng khi nó nhận ra mình không chắc. Nó đòi hỏi agent biết khi nào mình không biết.
4. Vì sao "mua 10 có thể thành mua 20" không phải là lỗi phần mềm? Vì đó là tính chất của mô hình ngôn ngữ — nó có thể bịa, không phải lúc nào cũng đúng. Chốt duyệt tồn tại vì tính chất đó, chứ không phải vì ai viết code ẩu.
Rút từ chương 22 của khoá học (17:50:27 → 18:48:09). Trích dẫn kèm mốc thời gian: agentic-ai-chuong-22, bon-mau-hitl, interrupt-va-checkpointer.
Chương sau: Rào chắn nhiều tầng — và một ví dụ gần như trùng khớp với ngành của bạn.
Chương này không rút từ video. Nó rút từ một bài trong kho code của khoá học — bài không nằm trong 26 chương, và là một trong hai file duy nhất được viết bằng chữ tử tế thay vì chỉ có code. Mình đọc được vì nó là văn viết, không phải máy nghe.
Chương 5 nói về một cơ chế: dừng lại hỏi người. Chương này nói về cả hệ thống phòng thủ, trong đó chốt duyệt chỉ là một tầng.
Và ở cuối chương có một ví dụ mà khi đọc mình phải dừng lại: chatbot y tế. Ba trong bốn rào chắn của nó áp thẳng được vào một chatbot cho spa. Mình để dành nó ở cuối.
Rào chắn không nằm trong agent. Nó bao quanh agent:
┌─── TRƯỚC khi agent chạy
Người → │ [ agent: mô hình + công cụ ]
└─── SAU khi agent xong ────────→ Người
Nghe kỹ thuật, nhưng hệ quả rất thực dụng: bạn thêm hoặc bớt rào chắn mà không phải sửa agent. Chúng là lớp bọc, không phải ruột. Nghĩa là khi bạn phát hiện một rủi ro mới, việc bịt nó lại thường không cần đập đi làm lại.
| Luật cứng | Nhờ mô hình chấm | |
|---|---|---|
| Cách làm | Danh sách từ cấm, mẫu nhận dạng | Một AI đọc và chấm "an toàn / không an toàn" |
| Nhanh? | Rất nhanh | Chậm |
| Tiền? | Gần như 0 đồng | Mỗi lần kiểm là một lần trả tiền |
| Bắt được gì | Cái lộ liễu | Cái tinh vi, nói vòng vo |
Nguyên tắc mà bài này chốt lại:
⭐ Luật cứng trước, mô hình sau. Đặt kiểm tra rẻ tiền ở ngoài cùng để chặn sớm, tránh những lần gọi mô hình đắt đỏ.
Đây là chỗ tiền bạc lộ ra rất rõ. Một yêu cầu xấu bị bộ lọc từ khoá chặn trước khi vào mô hình thì tốn 0 đồng. Cũng yêu cầu đó mà để mô hình xử lý xong rồi mới chặn ở đầu ra thì bạn đã trả tiền hai lần — một lần cho câu trả lời sẽ bị vứt, một lần cho việc chấm nó.
Các rào chắn chạy theo thứ tự bạn xếp. Nên thứ tự chính là thiết kế:
Người dùng nhập
↓ [1] Lọc từ khoá ← rẻ nhất, chặn sớm nhất
↓ [2] Che dữ liệu cá nhân vào
↓ [3] Chốt người duyệt ← chỉ với công cụ nhạy cảm
↓ [4] Che dữ liệu cá nhân ra
↓ [5] Mô hình chấm đầu ra ← đắt nhất, trong cùng
Trả lời cho người dùng
Hai điều đáng nhớ về sơ đồ này:
Cái rẻ nhất ngoài cùng, cái đắt nhất trong cùng.
Không có tầng nào là "tầng chính". Mỗi tầng bắt một loại lỗi khác nhau, và cách thiết kế này giả định tầng nào cũng có thể lọt. Đó là lý do dữ liệu cá nhân được che hai lần — một lần vào, một lần ra.
Đây là chỗ mà mình nghĩ nhiều người làm dịch vụ chưa nghĩ tới.
Khách nhắn cho chatbot của bạn: "Em tên Lan, số điện thoại 09xx, em bị dị ứng da mặt, giúp em với."
Câu đó đi thẳng vào mô hình ngôn ngữ — thường là mô hình của một công ty nước ngoài — và thường được ghi lại trong nhật ký hệ thống. Bạn vừa gửi thông tin sức khoẻ của khách ra ngoài mà không hề định làm vậy.
Cách xử lý: một lớp quét và xử lý trước khi nội dung đi tiếp. Nhận diện sẵn email, số thẻ, địa chỉ IP, đường dẫn — và thêm được mẫu riêng.
Bốn cách xử lý, tuỳ mức độ:
| Cách | Kết quả | Dùng khi |
|---|---|---|
| Xoá | [ĐÃ_XOÁ_EMAIL] |
Không cần giá trị đó |
| Che một phần | ****-****-****-1234 |
Cần vài ký tự cuối để đối chiếu |
| Băm | a8f5f167… |
Cần biết "hai lần này cùng một người" mà không cần biết là ai |
| Chặn hẳn | Báo lỗi, không cho qua | Thứ tuyệt đối không được lọt |
Ba câu tự soi nếu bạn định làm chatbot cho khách:
Ở chương 4 mình nói giới hạn quyền là thứ phải đặt trước. Bài này cho thấy nó trông như thế nào trong thực tế — một cái bảng:
| Công cụ | Cần duyệt? |
|---|---|
| Gửi email | ✅ Có |
| Xoá dữ liệu | ✅ Có |
| Tìm kiếm web | ❌ Tự chạy |
Chỉ vậy thôi. Cái bảng này chính là "giới hạn quyền" ở chương 4, viết ra thành một danh sách đọc được.
💡 Đây là thứ đáng đòi khi bạn thuê ai dựng agent. Bảo họ đưa cho bạn cái bảng này. Nó phải đọc được bởi người không code, và bạn là người duyệt nó — không phải người viết code.
Một chi tiết hay: khi từ chối, có thể kèm lý do — ví dụ trong bài: "Quá rủi ro, cần trưởng bộ phận dữ liệu xem đã." Lý do đó đi ngược vào hệ thống, nên agent biết vì sao bị chặn chứ không chỉ biết là bị chặn.
Bài kết bằng một ví dụ hoàn chỉnh: chatbot cho lĩnh vực y tế. Mình chép lại nguyên bốn rào chắn của nó, rồi dịch sang ngành của bạn.
Danh sách cấm: tổng hợp ma tuý, tự hại, phương pháp tự tử, vũ khí. Trúng thì trả lời cố định:
"Tôi là trợ lý y tế, chỉ hỗ trợ câu hỏi y khoa, đặt lịch và thông tin sức khoẻ. Nếu bạn đang khủng hoảng, hãy gọi 112 hoặc số cấp cứu địa phương."
Để ý: nó không cố xử lý những ca này. Nó nhận ra và chuyển hướng ngay, kèm số khẩn cấp.
Với spa: khách hỏi những thứ mà một chatbot không được phép trả lời — "em uống thuốc này có sao không", "chỗ này nổi hạch có phải ung thư không". Đây không phải câu hỏi làm đẹp. Bot phải nhận ra và chuyển hướng, không được đoán.
Xoá email, che số thẻ ngay ở đầu vào — mô hình không bao giờ nhìn thấy.
Với spa: khách nhắn số điện thoại, địa chỉ, tình trạng da, đôi khi cả ảnh. Mức mặc định hợp lý là xoá ngay ở đầu vào những gì không cần cho việc trả lời.
Tra triệu chứng: tự chạy. Tra thông tin thuốc: tự chạy. Đặt lịch hẹn: phải có người duyệt.
Với spa: đây gần như là bản sao. Tư vấn dịch vụ, báo giá, giờ mở cửa — cứ để bot trả lời. Chốt lịch thật vào sổ hẹn thì phải qua người. Vì một cái lịch đặt sai làm hỏng buổi làm việc của cả kỹ thuật viên lẫn khách.
Mọi câu trả lời đều được gắn thêm:
"Đây là thông tin sức khoẻ chung, không phải lời khuyên y tế. Vui lòng tham khảo chuyên gia y tế."
Và nó chỉ gắn nếu chưa có sẵn — không lặp lại hai lần.
Với spa: đây là tầng mình nghĩ bạn cần nhất mà lại dễ quên nhất. Spa nằm sát ranh giới y tế. Một câu tư vấn của bot nghe như chẩn đoán là rủi ro thật — cho khách trước, cho bạn sau.
Bốn rào chắn của chatbot y tế không cái nào là chuyện kỹ thuật. Cả bốn đều là quyết định của người hiểu nghề:
Phần khung thì viết được trong một buổi. Nhưng không ai điền được nội dung vào thay bạn.
Đó là chỗ không thuê ngoài được — và cũng là lý do đọc mấy chương này đáng công. Bạn không cần biết dựng, bạn cần biết cần dựng cái gì.
Vault "Học điều mới" hiện có rào chắn nào?
| Tầng | Vault này |
|---|---|
| Lọc đầu vào | ❌ Không có |
| Che dữ liệu cá nhân | ❌ Không có (nhưng cũng chưa xử lý dữ liệu khách) |
| Chốt người duyệt | ✅ Có — trước khi cài, tải, làm gì ra ngoài |
| Kiểm tra đầu ra | ❌ Không có |
| Luật riêng | ✅ Có — các luật trong CLAUDE.md |
Ô trống đáng chú ý nhất là "kiểm tra đầu ra". Mọi thứ Claude viết vào wiki/ đều đi thẳng vào bộ nhớ vĩnh viễn, không qua tầng kiểm nào. Bạn là tầng kiểm duy nhất, và chỉ khi bạn tình cờ đọc kỹ.
Ba lần sai trong một phiên đều lọt qua đúng ô trống này. Đây là chỗ nâng cấp cụ thể nhất mà cuốn sách này chỉ ra được.
1. Vì sao luật cứng nên đặt trước, mô hình chấm đặt sau? Vì luật cứng gần như miễn phí và chặn được ngay từ đầu. Để mô hình xử lý xong rồi mới chặn ở đầu ra nghĩa là đã trả tiền cho một câu trả lời sắp bị vứt đi.
2. Vì sao dữ liệu cá nhân được che hai lần, cả vào lẫn ra? Vì cách thiết kế này giả định tầng nào cũng có thể lọt. Thông tin có thể rò ở cả hai chiều, nên chặn ở cả hai chiều.
3. Trong ví dụ chatbot y tế, vì sao "tra triệu chứng" không cần duyệt mà "đặt lịch" thì cần? Vì tra thông tin sai thì hỏi lại là xong. Đặt lịch sai thì đã tác động ra thế giới thật — chiếm chỗ, làm hỏng buổi làm việc của người khác.
4. Phần nào của bốn rào chắn kia bạn không thể thuê ngoài? Phần nội dung: chủ đề nào ngoài phạm vi, thông tin nào không được gửi đi, hành động nào phải qua người, câu nào cần miễn trừ trách nhiệm. Lập trình viên dựng được cái khung, nhưng không biết điền gì vào.
Rút từ raw/agentic-ai-code/LangGraph-Code/13_guardrails_crash_course.ipynb. Trích dẫn theo số ô: guardrails-crash-course, guardrails-middleware, che-du-lieu-ca-nhan.
Hết cuốn. Quay lại mục lục.
Chương này khác các chương trước. Sáu chương đầu đi sâu. Chương này đi rộng: 22 chương còn lại của khoá học, mỗi chương một đoạn, đủ để bạn hiểu cái gì làm cái gì và vì sao người ta làm thế — không đủ để bạn tự dựng.
Mình rút từ phần mở đầu mỗi chương, chỗ giảng viên nêu vấn đề trước khi vào code. Chỗ nào bạn muốn sâu hơn thì nói, mình nạp riêng chương đó.
Đọc hết 22 phần mở đầu, mình thấy một khuôn lặp lại đến mức không thể là ngẫu nhiên:
Chương nào cũng mở bằng câu "ứng dụng hiện tại của chúng ta đang hỏng ở chỗ này".
Không có chương nào mở bằng "hôm nay ta học tính năng X". Luôn là: đây là thứ ta vừa dựng, đây là chỗ nó gãy, giờ vá.
Đây là điều đáng học hơn cả nội dung. Nó là cách nghĩ: đừng thêm tính năng vì nó hay, thêm vì có chỗ đang đau.
Chương 4 — Lập trình bất đồng bộ (33 phút)
Nếu bạn có 20 agent cùng chạy, cho chúng xếp hàng lần lượt thì rất chậm. Bất đồng bộ là cách cho chúng chạy xen kẽ nhau.
Điều đáng chú ý: giảng viên nói rõ bạn không cần tự viết cái này. Mọi khung dựng agent đều đã dùng sẵn nó bên trong. Ông dạy chỉ để sau này bạn gặp cú pháp đó thì không hoảng.
Chương 5 — Pydantic (1h20m)
Chương này giải một vấn đề rất thật, và mình nghĩ bạn nên nhớ vấn đề đó dù không nhớ tên công cụ:
Đầu ra của mô hình ngôn ngữ là "phi cấu trúc và không đoán trước được".
Bạn bảo nó trả về giá tiền, có lúc nó trả 500000, có lúc 500.000đ, có lúc "khoảng năm trăm nghìn nhé bạn". Với người đọc thì đều hiểu. Với một chương trình sắp lấy con số đó đi trừ vào kho thì cả ba đều là thảm hoạ.
Pydantic là bộ khuôn: khai báo trước "chỗ này phải là số nguyên", rồi kiểm tra mọi thứ mô hình trả về. Sai khuôn thì chặn lại thay vì để nó chảy tiếp vào hệ thống.
💡 Áp vào việc của bạn: đây chính là ranh giới giữa "AI viết cho người đọc" và "AI nối vào hệ thống thật". Khi nào bạn muốn AI ghi vào sổ khách, sổ hẹn, sổ kho — thì lớp kiểm tra khuôn này là bắt buộc. Đây cũng là câu hỏi tốt để hỏi người dựng: "đầu ra của mô hình được kiểm khuôn ở đâu trước khi ghi vào dữ liệu của tôi?"
Chương 6–7 dựng agent đầu tiên bằng LangChain: một bot thời tiết có hai công cụ, rồi nâng lên hệ nhiều agent. Ví dụ minh hoạ: hỏi "thủ đô Ấn Độ là gì, rồi cho biết thời tiết ở đó" — nó tra thủ đô trước, lấy được "Delhi", rồi mới tra thời tiết Delhi. Hai công cụ nối tiếp, tự nó quyết thứ tự.
Chương 8 — LangChain so với LangGraph (1h14m) là chương mình khuyên bạn nhất trong nhóm này, và cũng là chương đáng nạp sâu tiếp theo.
Vì nó trả lời một câu hỏi vượt ra ngoài phạm vi AI: "khi nào thứ đang dùng không còn đủ, và làm sao biết điều đó?" LangChain dựng agent được — nhưng chỉ agent đơn giản. Chương này chỉ ra đúng chỗ nó gãy khi luồng phức tạp lên.
Đây là nhóm mình nghĩ có giá trị lâu nhất, vì nó không thật sự nói về AI.
Ý tưởng gốc của LangGraph: thay vì một chuỗi thẳng A rồi B rồi C, hãy mô tả công việc thành một sơ đồ — mỗi ô là một việc, mỗi mũi tên là "xong cái này thì đi đâu".
Nghe quen không? Đó chính là sơ đồ quy trình mà mọi doanh nghiệp đều vẽ.
Và từ sơ đồ đó, có đúng bốn hình dạng:
| Kiểu | Hình dung | Ví dụ trong đời |
|---|---|---|
| Tuần tự | A → B → C | Khách đến → tư vấn → làm dịch vụ → thu tiền |
| Song song | A, B, C cùng lúc rồi gộp | Vừa chuẩn bị phòng, vừa pha đồ, vừa in phiếu |
| Có điều kiện | Xét rồi rẽ | Khách cũ → ưu đãi; khách mới → tư vấn kỹ |
| Lặp | Làm → chấm → chưa đạt thì quay lại | Viết bài đăng: bản đầu không bao giờ dùng được ngay |
Ví dụ của khoá học cho kiểu lặp rất đúng đời: viết bài Facebook. "Không phải lần đầu là ra bài hoàn hảo. Bạn sẽ gửi lại cho mô hình và bảo nó sửa." Vòng lặp đó chính là thứ được dựng thành một hình dạng chính thức.
💡 Áp vào việc của bạn: khi bạn muốn tự động hoá một việc gì đó, thứ cần vẽ ra trước không phải là "dùng AI nào" mà là quy trình đó thuộc hình dạng nào. Bốn cái trên đủ để mô tả gần hết. Vẽ được sơ đồ rồi thì thuê người dựng dễ hơn nhiều — và bạn kiểm được họ có làm đúng không.
Tám chương liền là một dự án duy nhất, mỗi chương thêm một lớp. Đây là phần cho bạn thấy một trợ lý AI tử tế cần bao nhiêu thứ — thứ mà nhìn từ ngoài không ai đoán được.
| Lớp | Vá chỗ đau nào |
|---|---|
| Khung chatbot | Điểm xuất phát |
| Lưu trạng thái | Không nhớ đang làm dở gì |
| Hiện từng chữ | Chờ lâu quá, người dùng bỏ đi |
| Nhiều luồng hội thoại | Mọi chủ đề trộn vào một chỗ |
| Cơ sở dữ liệu | ⭐ Tải lại trang là mất sạch |
| Giám sát | Không biết nó sai ở bước nào |
| Công cụ | ⭐ Không làm được gì ngoài nói chuyện |
| RAG | Không biết gì về tài liệu của bạn |
Hai lớp mình đánh dấu sao đáng nói riêng.
Lớp cơ sở dữ liệu. Vấn đề cụ thể tới mức buồn cười: chatbot chạy ngon, nhiều luồng hội thoại đàng hoàng — rồi bấm tải lại trang là bay sạch, vì mọi thứ đang nằm trong bộ nhớ tạm. Cần một chương riêng chỉ để đưa nó xuống đĩa.
Nhớ chương 5: chốt duyệt cũng cần đúng thứ này. Bộ nhớ bền vững không phải "tính năng cao cấp" — nó là nền cho ít nhất bốn thứ khác: nhớ hội thoại, nhiều luồng, chốt duyệt, và chạy tiếp sau khi dừng.
Lớp công cụ. Giảng viên nói một câu đáng chép lại:
"Không có công cụ thì một AI agent không thực hiện được hành động nào."
Và ông demo bằng đúng ví dụ ở chương 1 của cuốn này: hỏi "Python là gì" → trả lời được. Hỏi "tin mới nhất hôm nay" → chịu. Vì mốc chặn kiến thức vẫn nguyên đó. Thêm công cụ mới vá được.
Chương 23–24 nói về việc đưa ứng dụng từ máy mình lên mạng cho người khác dùng.
Vấn đề rất dễ hiểu: lần đầu bạn cài tay cũng được. Nhưng sáu tháng sau muốn sửa gì đó, bạn phải dừng máy chủ, đẩy code mới, chạy lại — thủ công, và mỗi lần là một cơ hội sai. CI/CD là tự động hoá chuỗi đó: bạn sửa code, phần còn lại máy tự làm.
Chương 24 giới thiệu Render — nền tảng đơn giản hơn AWS nhiều, có sẵn CI/CD không phải cấu hình, và có gói miễn phí đủ để thử.
Đây là ~1h18m mình khuyên bạn bỏ qua hoàn toàn. Nó là việc của người vận hành kỹ thuật. Thứ duy nhất đáng nhớ: "triển khai" và "tự động hoá việc triển khai" là hai việc khác nhau, và cái sau tốn công hơn cái trước — hữu ích khi nghe báo giá.
Chương 25 (2h15m) — dựng lại một phiên bản ChatGPT: hội thoại, tải tài liệu, chế độ giọng nói, nhiều luồng, tra web, giải toán, sinh code.
Chương 26 (1h55m) — TripMate AI, trợ lý du lịch nhiều agent. Nhập điểm đến → ra chuyến bay, khách sạn, lịch trình, kế hoạch từng ngày kèm ngân sách, xuất được PDF.
Chương 26 là ví dụ gần nhất với một sản phẩm bán được: nhiều agent, mỗi agent một mảng, gộp lại thành một bản kế hoạch hoàn chỉnh. Nếu sau này bạn nghĩ tới một "trợ lý tư vấn liệu trình" cho spa thì đây là hình dạng để tham khảo.
Bạn nói đọc phần này để hiểu hệ thống, nhằm cải thiện agent của mình. Đây là ba thứ mình thấy đáng mang về nhất:
1. Thêm lớp khi có chỗ đau, không thêm vì nghe hay.
Cả 22 chương đều theo khuôn này. Áp vào vault của bạn: đừng thêm quy trình vào CLAUDE.md vì nó nghe hợp lý — thêm khi đã có một lần hỏng thật. Luật "ghi log mỗi lần nạp nguồn" có giá trị vì nó vá một chỗ đau có thật: phiên sau mất trí nhớ.
2. Trạng thái là trung tâm của mọi thứ. Bộ nhớ bền vững, nhiều luồng, chốt duyệt, chạy tiếp sau khi dừng — cả bốn thực ra là một: khả năng lưu và lấy lại trạng thái. Đó là lý do khoá học quay lại nó bốn lần.
Với vault của bạn, thứ tương đương là wiki/ và log.md. Cải thiện chúng chính là cải thiện phần nền — có tác dụng lớn hơn thêm bất kỳ quy trình mới nào.
3. Cái bạn thiếu nhất có thể là giám sát. Chương 19 nói: "không có nó thì không gỡ lỗi, không theo dõi, không đánh giá được ứng dụng của mình."
Áp vào vault: hiện bạn không có cách nào nhìn lại xem trợ lý đã làm gì và sai ở đâu, ngoài việc tự đọc log.md — mà chính trợ lý viết cái log đó. Vụ 429 hôm qua là ví dụ: mình ghi một kết luận sai vào log, và thứ bắt được nó là bạn, không phải hệ thống.
Đó có lẽ là chỗ đau thật sự của vault này. Mình chưa có đề xuất chín, nhưng ghi lại đây để cả hai cùng thấy.
1. Vì sao Pydantic quan trọng khi AI nối vào hệ thống thật? Vì đầu ra của mô hình phi cấu trúc và không đoán trước được. Với người đọc thì sao cũng hiểu; với một chương trình sắp ghi vào dữ liệu của bạn thì sai khuôn là hỏng. Pydantic chặn trước khi nó chảy tiếp.
2. Bốn hình dạng công việc là gì, và vì sao chúng không thật sự nói về AI? Tuần tự, song song, có điều kiện, lặp. Chúng là sơ đồ quy trình — thứ mọi doanh nghiệp đều vẽ, chỉ là được dựng thành công cụ.
3. Vì sao bộ nhớ bền vững quan trọng hơn nó nghe? Vì bốn thứ khác nhau — nhớ hội thoại, nhiều luồng, chốt người duyệt, chạy tiếp sau khi dừng — thực ra đều là một: lưu và lấy lại trạng thái.
4. Điều đáng học nhất từ cách khoá này được dựng? Chương nào cũng mở bằng "ứng dụng hiện tại đang hỏng ở chỗ này", rồi mới vá. Thêm tính năng vì có chỗ đau, không phải vì nó nghe hay.
Rút từ phần mở đầu của 22 chương chưa nạp sâu. Bảng đầy đủ từng chương: ban-do-22-chuong-con-lai.
Quay lại mục lục.
Chương này rút từ chương 19 của khoá học, và nó được nạp vì một lý do rất cụ thể: bạn muốn nâng cấp cái hệ này, và chương 6 đã chỉ ra ô trống lớn nhất là "không có tầng kiểm đầu ra". Mình đề nghị đi học xem người ta làm thế nào trước khi tự nghĩ ra. Đây là kết quả.
"Ở giữa có một số thao tác ẩn đang diễn ra, nhưng bạn không nhìn thấy chúng. Nếu bạn chỉ viết code mà không truy vết toàn bộ ứng dụng, phần đó vô hình với bạn."
Bạn thấy câu bạn hỏi. Bạn thấy câu nó trả lời.
Khúc giữa thì không thấy gì.
Mà khúc giữa mới là chỗ mọi quyết định xảy ra: nó đọc gì, nó chọn công cụ nào, nó dựng câu lệnh ra sao, bước nào hỏng rồi bị nuốt đi.
Giải pháp gọi là truy vết. Định nghĩa trong khoá:
"Ghi lại toàn bộ quá trình thực thi thành một trace, cho phép bạn soi từng bước: đầu vào, đầu ra, lỗi, thời gian chạy, số token, các lần gọi công cụ, và hành vi của mô hình."
Chú ý chữ quá trình. Không phải bản tóm tắt. Không phải kết luận. Từng bước, đúng như nó đã xảy ra.
Bảy thứ nó cho bạn trả lời:
Câu số 7 đáng dừng lại một nhịp. Nó cho phép trả lời "sửa xong có tốt lên thật không" — thay vì tin là có. Đây là thứ mà bạn với mình đang thiếu hoàn toàn: mỗi lần sửa CLAUDE.md, cả hai đều hy vọng nó tốt hơn, không ai đo được.
Đây là phần quan trọng nhất của chương, và nó không nằm ở nội dung mà nằm ở cách nó được thiết kế:
"Bạn không cần viết bất kỳ dòng code nào. Chỉ cần thêm vài biến môi trường là nó tự động bắt đầu truy vết."
Đọc kỹ chỗ đó. Ứng dụng bị theo dõi không biết là mình đang bị theo dõi, và không phải làm gì để hợp tác. Người ngoài cắm vào, và nó ghi.
Từ đó ra một phân biệt mà mình nghĩ là thứ đáng giá nhất bạn mang về từ cuốn sách này:
| Truy vết | Tự báo cáo | |
|---|---|---|
| Ai ghi | Hệ thống bên ngoài | Chính đối tượng bị giám sát |
| Ghi gì | Quá trình, từng bước thật | Kết luận, tóm tắt sau khi xong |
| Có cần đối tượng hợp tác | Không | Có |
| Hỏng khi nào | Khi không ai đọc | Khi đối tượng ghi sai mà chính nó không biết là sai |
Và đây là chỗ mình phải rút lại lời:
Hôm qua mình đề xuất "thêm luật bắt Claude gắn nhãn độ chắc chắn vào mọi khẳng định". Nghe rất hợp lý. Nhưng nó là tự báo cáo có thêm luật.
Ba lần mình sai trong phiên vừa rồi đều có cùng một hình dạng: mình không tự thấy mình đang đoán. Thêm một luật bắt mình tự kiểm là giao việc phát hiện lỗi cho đúng cái đầu vừa gây ra lỗi. CLAUDE.md đã có sẵn luật "mọi khẳng định phải có trích dẫn" — và cả ba lần vẫn lọt.
Một cơ chế mà đối tượng bị giám sát phải tự chấp hành thì không phải giám sát.
Đây là chỗ mình đi kiểm thay vì đoán, và kết quả bất ngờ.
Bản ghi phiên làm việc của bạn được lưu tự động — do phần mềm Claude Code ghi, không phải do mình viết. Mọi câu bạn gõ, mọi lệnh mình chạy, mọi file mình đọc, đều nằm trong đó. Mình vừa kiểm: đọc được, tìm được, và nó lưu lại từ nhiều tuần trước.
Đối chiếu với bảng ở trên: bên ngoài ghi ✓ · ghi quá trình ✓ · mình không phải hợp tác ✓.
Đó đúng là một trace. Vault không thiếu dữ liệu. Vault chỉ chưa bao giờ đọc nó.
Suốt tới giờ, thứ duy nhất được đọc lại là wiki/log.md — mà cái đó do mình viết, sau khi xong việc, ghi kết luận. Tự báo cáo. Đúng loại dữ liệu không bắt được lỗi của chính người viết.
Có một giới hạn kỹ thuật: một phiên làm việc không đọc được bản ghi của chính nó. Chỉ đọc được phiên khác.
Nghe như hạn chế, nhưng nghĩ kỹ thì đó chính là điều nên có:
Người rà soát bắt buộc phải là một phiên KHÁC với phiên bị rà soát.
Một cặp mắt riêng, đọc một bản ghi nó không viết, về việc nó không làm. Nó không có sẵn kết luận cũ trong đầu để bảo vệ.
Với mỗi câu đóng ngoặc kép gán cho bạn trong wiki/ và log.md — tìm nguyên văn câu đó trong bản ghi phiên. Không tìm thấy thì là bịa.
Không cần phán đoán. Không cần thông minh. Chỉ đối chiếu chữ.
Phép này sẽ bắt được vụ "để không bị loè" — câu mình gán cho bạn trong ngoặc kép, mà bạn chưa bao giờ nói.
Với hai lỗi kia — kết luận về mạng, và xếp hạng 26 chương — khó hơn, vì chúng không phải trích dẫn sai mà là suy luận vội. Phép kiểm tương ứng sẽ là: tìm những khẳng định trong wiki được viết như sự thật, mà bằng chứng trong bản ghi chỉ là một quan sát duy nhất. Cái này cần phán đoán, nên yếu hơn — nhưng vẫn hơn hẳn không có gì.
Mình dừng ở mức xác định được vị trí và nguyên liệu, chưa dựng quy trình.
Lý do: chương 19 nói rất kỹ cách thu thập trace, nhưng không nói ai đọc, đọc khi nào, theo quy trình gì. Nó dừng ở chỗ "mở bảng lên mà xem". Phần thiết kế quy trình rà soát là phần mình phải tự nghĩ — mà đó đúng là chỗ mình vừa sai ba lần.
Nên mình đưa ra cái đã kiểm được, và nói rõ cái chưa:
| Điều | Mức chắc chắn |
|---|---|
| Trace tồn tại, đọc được, do hệ thống ghi | ✅ Đã kiểm trực tiếp hôm nay |
| Phiên sau đọc được phiên trước, phiên hiện tại không tự đọc | ✅ Đã kiểm |
log.md là tự báo cáo, không phải trace |
✅ Theo định nghĩa trong nguồn |
| Phép đối chiếu ngoặc kép sẽ bắt được lỗi bịa lời | 🟡 Suy luận — hợp lý nhưng chưa chạy thử |
| Phép kiểm cho "suy luận vội" | 🟠 Ước lượng — chưa có cách làm cụ thể |
| Quy trình rà soát đầy đủ nên trông thế nào | ⬜ Chưa có |
1. "Khúc giữa vô hình" là gì? Là mọi thứ giữa câu bạn hỏi và câu nó đáp: nó đọc gì, chọn công cụ nào, dựng câu lệnh ra sao, bước nào hỏng. Bạn thấy hai đầu, không thấy giữa — mà giữa mới là nơi quyết định xảy ra.
2. Truy vết khác tự báo cáo ở điểm nào, và vì sao điểm đó quyết định tất cả? Truy vết do hệ thống bên ngoài ghi, ghi quá trình, đối tượng không phải hợp tác. Tự báo cáo do chính đối tượng viết. Nếu vấn đề là "nó không tự thấy mình sai" thì tự báo cáo không bao giờ bắt được, dù thêm bao nhiêu luật.
3. Vì sao "một phiên không đọc được chính nó" lại là điều tốt? Vì nó buộc người rà soát phải là một phiên khác — đọc bản ghi nó không viết, về việc nó không làm, không có kết luận cũ để bảo vệ.
4. Phép kiểm rẻ nhất đáng làm đầu tiên là gì? Đối chiếu mọi câu đóng ngoặc kép gán cho bạn với bản ghi phiên. Không có nguyên văn thì là bịa. Không cần phán đoán, chỉ cần khớp chữ.
Rút từ chương 19 của khoá học (15:16:31 → 15:40:24). Chi tiết: agentic-ai-chuong-19 và giam-sat-va-truy-vet.
Quay lại mục lục.