Agent Harness Foundations

Khoá học này mang lại gì cho bạn

Sau khoá học, bạn nhìn một Agent theo cách khác. Thay vì hỏi “model có đủ giỏi không”, bạn hỏi “phần khung quanh model đã đúng chưa”. Cụ thể, bạn sẽ:

• Phân biệt ba kiểu ứng dụng AI — LLM Call, Workflow và Agent — bằng một tiêu chí rõ ràng: model được phép ảnh hưởng tới control flow đến đâu, chứ không phải nó “nghe có vẻ thông minh”.
• Quyết định khi nào bài toán thật sự cần Agent, và chọn mức tự chủ nhỏ nhất vẫn giải được phần chưa biết. Chọn không dùng Agent cũng là một quyết định tốt.
• Lần theo hành trình của một Agent — từng đề xuất, hành động, kết quả và bước chuyển state — để hiểu vì sao nó ra kết quả đó.
• Debug đúng chỗ: đọc một dấu hiệu để biết lỗi đang nằm ở control flow, ở state, ở permission hay ở evidence, để không đổi nhầm thứ.
• Kiểm chứng một Agent bằng hành vi chạy lại được qua nhiều tình huống, chứ không bằng cảm giác từ một lần demo may mắn.
• Trình bày được cách Agent của bạn vận hành bằng một bản đồ trách nhiệm, thay vì “model sẽ tự hiểu”.

Đây là khoá học về nền tảng và tư duy. Nó không phụ thuộc ngôn ngữ, framework hay model, nên những gì bạn học vẫn đúng khi bạn đổi runtime hay đổi sang một model mới.

Khoá học cung cấp những nền tảng nào

Toàn bộ chương trình xoay quanh một khái niệm: Harness — phần khung mà application dựng lên quanh model để lo prompt, memory, tools, kết quả trả về, rồi quyết định nên tiếp tục hay dừng. OpenAI gọi phần đó là model-native harness khi nói về hướng đi mới của Agents SDK; Anthropic phân tích cách một Harness hiệu quả giúp Agent giữ tiến triển qua nhiều context window; Cloudflare định nghĩa Harness là vòng lặp bao quanh model. Ba nguồn, một ý: năng lực nằm ở model, còn việc nó chạy có kiểm soát hay không nằm ở Harness.

Bạn sẽ đi qua sáu nhóm nền tảng, sắp theo đúng cách một builder dần nhìn rõ Harness:

1. Ba kiểu ứng dụng AI, và khi nào mới thật sự cần Agent

Tóm tắt một email, phân loại phản hồi rồi rẽ nhánh theo rule, và để model dùng kết quả mới tự chọn bước tiếp theo — ba thứ đó vận hành hoàn toàn khác nhau dù cùng được gọi là “app có Agent”. Bạn học cách tách LLM Call, Workflow và Agent bằng một tiêu chí: model có được ảnh hưởng đến control flow hay không, và tới đâu. Từ đó là câu hỏi thực dụng hơn: khi nào bước tiếp theo không thể gói trong một rule viết sẵn mà cần model cân nhắc dựa trên kết quả vừa quan sát được.

2. Model tạo ra năng lực, Harness quyết định năng lực đó chạy thế nào

Cùng một model: trong khung chat nó chỉ có thể khuyên; đặt vào một application có tools, chính lời đề xuất của nó lại có thể dẫn tới tác động thật. Ở nhóm này bạn gặp hai cơ chế nền. Agent Loop: làm một bước, đưa kết quả trở lại, cập nhật state rồi mới đi tiếp — một vòng lặp chỉ tạo tiến triển khi feedback thật sự làm state đổi. Tool: model đề xuất một hành động, Harness quyết định có chạy không, còn executor mới là bên thực thi.

3. Lời model nói không phải bằng chứng, và làm được không có nghĩa là được phép

Ba ranh giới đắt giá nhất với người mới:

• Claim khác với tác động thật trong hệ thống. Model nói “đã đặt lịch xong” không chứng minh lịch hẹn đã được tạo. Bằng chứng phải đến từ một hệ thống có thẩm quyền.
• Hợp lệ khác với được phép. Một biểu mẫu chuyển tiền điền đúng cấu trúc vẫn không nên chạy nếu vượt hạn mức hoặc chưa được xác nhận.
• Đúng nội dung nhưng gắn nhầm chỗ vẫn thành sai. Khi nhiều việc chạy gần nhau, một kết quả đúng bị ghép vào sai yêu cầu vẫn làm hỏng state. Đây là lý do identity và correlation quan trọng.

4. State đang có hiệu lực khác với mọi thứ Agent từng nghe

Bạn đổi ngày đi và giảm ngân sách giữa chừng, cuộc hội thoại vẫn còn nguyên đó, nhưng Agent tiếp tục dùng kế hoạch cũ. Nó không “quên”; nó đang trộn lẫn những gì từng được nói (history), state đang thật sự có hiệu lực, và phần được đưa vào model ở lượt này (context). Quanh trục này là các ranh giới hay bị hiểu nhầm mà chương trình bóc tách riêng: System Prompt cung cấp instruction chứ không sở hữu runtime control; context window không phải memory; RAG cho grounding từ dữ liệu riêng chứ không thay thế state hay memory.

5. Dừng, lần lại được hành trình, và chứng minh Agent đáng tin

Gõ “Stop” trong ô chat chỉ là một input đi theo đường dữ liệu; dừng một run đang chạy cần một đường điều khiển do Harness sở hữu. “Đã dừng” không đồng nghĩa với “đã hoàn thành”, và hủy một việc đang chạy không tự hoàn tác những tác động đã xảy ra. Khi Agent ra kết quả sai, chỉ nhìn câu trả lời cuối bạn không biết nó hiểu sai yêu cầu, chọn nhầm tool hay bỏ qua một bước — bạn cần trace để quan sát lại cả hành trình, và cần eval để tin nó thật sự ổn qua những tình huống chạy lại được.

6. Bản đồ trách nhiệm tối thiểu, và chọn model theo việc cần làm

Cuối cùng, bạn nối các phần rời rạc thành một bản đồ trách nhiệm để tự kiểm tra hệ thống: Harness chuẩn bị context, model đưa ra đề xuất, Harness kiểm tra và quyết định, executor thực thi, environment trả về kết quả quan sát được, rồi Harness cập nhật state và quyết định tiếp tục hay dừng. Và vì đã tách bạch model với Harness, việc chọn model trở về đúng bản chất: một trade-off theo workload — chất lượng, độ trễ, chi phí, độ ổn định của hành vi — chứ không có model nào “tốt nhất” cho mọi việc.

Vì sao 200Lab tạo ra khoá học này

Dựng một Agent biết làm việc giờ dễ hơn bao giờ hết. Vài năm trước, để AI biết đọc email, tra cứu thông tin, gọi API rồi tự lên kế hoạch cho bước tiếp theo, bạn phải ghép rất nhiều thứ lại với nhau. Bây giờ chỉ vài dòng code và một model đủ tốt là bạn đã có một bản demo chạy được, trình bày trước khách hàng cũng khá thuyết phục.

Đây là phần vui, và cũng là phần đánh lừa nhiều người nhất. Một bản demo chạy trơn tru không nói lên điều quan trọng nhất: khi đưa vào vận hành thật, Agent có làm đúng thứ bạn cần, có dừng đúng lúc, có bị chặn lại khi vượt quyền, và khi sai thì bạn có lần ra được vì sao hay không.

200Lab làm việc trực tiếp với các hệ thống có Agent bên trong — từ GoClaw, Agent Brain cho tới Emree — và pattern gặp đi gặp lại không phải “model chưa đủ giỏi”. Model càng ngày càng giỏi. Thứ lặp lại là builder chẩn đoán sai chỗ: dành nhiều ngày tinh chỉnh model cho một lỗi mà gốc rễ nằm ở cách application tổ chức Harness. Khoá học này ra đời để bạn nhìn đúng chỗ ngay từ đầu, trước khi đốt hàng tuần vào việc sửa nhầm chỗ. Góc nhìn là thực chiến, nhưng nhân vật chính vẫn là bạn và hệ thống bạn đang build.

Những vấn đề thường gặp khi phát triển Harness

Khi Agent hành xử sai, phản xạ đầu tiên của phần lớn builder là nhắm vào model: đổi prompt, đổi sang model xịn hơn, nhồi thêm context, gắn thêm RAG. Thử một vòng, thấy đỡ đỡ, rồi vài hôm sau lỗi kiểu khác lại xuất hiện. Đôi khi model thực sự chưa đủ tốt, nhưng rất nhiều lần root cause nằm ở chỗ khác hẳn, và đó là những tình huống chương trình lấy làm điểm xuất phát:

• Agent “quên” giữa chừng — thực ra là history, state và context đang bị trộn vào nhau.
• Model báo “đã làm xong” nhưng hệ thống chưa có gì thay đổi — claim đang bị coi là bằng chứng.
• Một hành động hợp lệ về dữ liệu vẫn chạy dù vượt hạn mức — hợp lệ đang bị coi là được phép.
• Kết quả đúng nhưng gắn nhầm yêu cầu khi nhiều việc chạy song song — thiếu identity và correlation.
• Bấm Stop mà run vẫn chạy, hoặc dừng rồi tưởng là xong — nhầm giữa đường dữ liệu và đường điều khiển.
• Nhìn câu trả lời cuối không biết sai ở bước nào — thiếu trace; tin Agent vì một lần demo — thiếu eval.
• System Prompt bị coi là runtime control, context window bị coi là memory, RAG bị coi là state.

Mỗi vấn đề trên tương ứng với một kiểu chẩn đoán sai, và mỗi kiểu có một bài trong chương trình.

Bạn sẽ học theo cách nào

• Học bằng tình huống, không học thuộc định nghĩa. Mỗi khái niệm khó được đặt vào một tình huống gần gũi trước, rồi mới gọi tên.
• Hình ảnh và hoạt cảnh cho những cơ chế phải thấy mới hiểu. Agent Loop, đường điều khiển, chuyển state được diễn từng bước thay vì mô tả bằng lời.
• Mỗi bài trọn vẹn một ý. Bạn hiểu độc lập từng bài, đồng thời mỗi bài thêm một mảnh vào bức tranh Harness tổng thể.
• Không khóa theo tuần. Bạn học theo nhịp riêng và nộp bài khi sẵn sàng.

Khoá học dành cho ai

1. Builder và vibe coder đã dùng các công cụ AI coding, muốn hiểu, build hoặc cải thiện Harness của mình. Đây là nhóm phù hợp nhất.
2. Developer, senior và architect cần một khung tư duy chung để trao đổi rõ ràng với đồng đội và xem lại hệ thống đang có.
3. Người sắp đưa Agent vào hệ thống thật và muốn biết mình đang tin vào bằng chứng gì trước khi đưa vào vận hành thực tế.

Những điều cần lưu ý

• Đây là chương trình nền tảng và tư duy, không phải một codebase production hoàn chỉnh hay một khóa “enterprise-ready”.
• Nó không phụ thuộc ngôn ngữ, framework hay model; các bài hướng dẫn code chuyên sâu được tách riêng, ngoài phạm vi chương trình này.
• Nó không hứa hẹn cơ hội nghề nghiệp hay một framework “tốt nhất”. Điều bạn nhận được là khả năng tự phân tích và quyết định vững vàng hơn khi đứng trước một Agent thật.

Bắt đầu từ đâu

Nếu bạn từng nhìn một Agent chạy sai mà không biết nên chỉnh chỗ nào, chương trình bắt đầu đúng từ câu hỏi đó. Bài đầu tiên không dạy bạn dựng gì cả — nó giúp bạn tách ba kiểu ứng dụng AI để không gọi nhầm mọi thứ là Agent. Xong bài đó, phần còn lại của Harness sẽ dần rõ ra.