Khi một AI agent làm việc không tốt, phản xạ đầu tiên thường là đổi mô hình mạnh hơn, hoặc viết lại prompt cho hay hơn. Nhưng trong nhiều trường hợp, vấn đề không nằm ở một chỗ duy nhất. Nó nằm ở cách ba tầng làm việc chồng lên nhau: prompt, context và harness.
Hiểu tổng thể trước sẽ giúp việc sửa chữa chính xác hơn rất nhiều. Ba tầng này không cạnh tranh nhau, mà lồng vào nhau như các lớp của một hệ thống máy tính: mô hình giống như CPU, context giống như RAM, còn harness giống như hệ điều hành. Mỗi tầng đảm nhận một nhiệm vụ khác nhau, và mỗi tầng hỏng sẽ tạo ra một kiểu lỗi khác nhau.
Bài viết này tổng hợp bức tranh chung trước, rồi đi chi tiết từng tầng: mỗi tầng là gì, làm tốt ở đâu, hỏng ở đâu, và cần xây dựng những gì.
Bức tranh tổng hợp
Prompt trả lời câu hỏi: mình muốn mô hình làm gì, theo cách nào, với đầu ra ra sao.
Context trả lời câu hỏi: để làm được việc đó, mô hình cần nhìn thấy những gì ngay lúc này.
Harness trả lời câu hỏi: hệ thống xung quanh mô hình vận hành ra sao để việc đó được thực hiện một cách an toàn, kiểm chứng được và lặp lại được.
Nếu chỉ có prompt tốt mà context thiếu hoặc sai, agent sẽ trả lời trôi chảy nhưng dựa trên thông tin không đủ. Nếu context tốt mà không có harness, agent có thể làm đúng một lần rồi thất bại ở lần sau vì không ai kiểm tra, không ai giới hạn quyền, và không ai ghi lại nó đã làm gì. Ngược lại, một harness chặt chẽ cũng không cứu được một nhiệm vụ được mô tả mơ hồ và thiếu dữ liệu đầu vào.
Vì vậy, thứ tự suy nghĩ đúng không phải là chọn tầng nào quan trọng nhất, mà là xem lỗi đang xảy ra thuộc tầng nào, rồi sửa đúng tầng đó.
Tầng 1: Prompt engineering — nói rõ mình muốn gì
Prompt engineering là tầng gần người dùng nhất. Nó tập trung vào một lần tương tác: cách diễn đạt yêu cầu, vai trò được giao, định dạng đầu ra, ví dụ minh họa và những ràng buộc cần tuân thủ.
Một prompt tốt thường có vài đặc điểm chung. Yêu cầu được viết cụ thể thay vì chung chung. Tiêu chí thành công được nêu rõ, ví dụ đầu ra cần có những mục nào, độ dài ra sao, và điều gì không được làm. Khi cần, prompt đưa thêm một hoặc hai ví dụ đúng để mô hình bắt chước cấu trúc, thay vì chỉ mô tả bằng lời.
Tầng này phát huy tốt nhất với các tác vụ đơn lẻ, ngắn và có đầu ra rõ ràng: viết lại một đoạn văn, tóm tắt một tài liệu, phân loại một yêu cầu, tạo dàn ý. Với những việc này, thay đổi cách diễn đạt đôi khi đủ để thay đổi hoàn toàn chất lượng.
Giới hạn của prompt cũng rất rõ. Prompt không thể bù đắp cho thông tin bị thiếu. Nếu mô hình không được thấy tài liệu cần thiết, nó sẽ tự lấp khoảng trống bằng suy đoán. Prompt cũng không kiểm soát được những gì xảy ra sau khi mô hình trả lời, và không ngăn được việc nó lặp lại cùng một lỗi ở lần chạy tiếp theo.
Dấu hiệu cho thấy lỗi thuộc tầng prompt là: yêu cầu vốn đã có đủ dữ liệu, nhưng đầu ra lệch định dạng, lệch trọng tâm hoặc hiểu sai ý định. Khi đó, việc cần làm là làm rõ yêu cầu, chứ không phải đổ thêm dữ liệu hay viết thêm code xung quanh.
Tầng 2: Context engineering — cho mô hình thấy đúng thứ cần thấy
Khi agent bắt đầu làm việc nhiều bước, prompt không còn đủ nữa. Lúc này, điều quyết định chất lượng là toàn bộ những gì mô hình được đọc ở mỗi bước: hướng dẫn, tài liệu tham khảo, lịch sử trò chuyện, kết quả từ công cụ và ghi chú đã lưu.
Andrej Karpathy từng mô tả context engineering là nghệ thuật và khoa học tinh tế của việc lấp đầy cửa sổ ngữ cảnh bằng đúng thông tin cần thiết cho bước tiếp theo. Định nghĩa này nhấn mạnh hai chữ quan trọng: đúng và bước tiếp theo. Không phải càng nhiều càng tốt, mà là đúng thứ cần cho bước đang làm.
Context của một agent thường đến từ nhiều nguồn khác nhau. Có context làm việc ngắn hạn: yêu cầu hiện tại và kết quả vừa tạo ra. Có bộ nhớ dài hạn: quyết định đã chốt, quy tắc đã thống nhất, hồ sơ và lịch sử liên quan. Có dữ liệu truy xuất từ bên ngoài: tài liệu, cơ sở tri thức, kết quả tìm kiếm. Và có kết quả từ công cụ: những gì hệ thống vừa trả về sau mỗi lần agent hành động.
Vì vậy, công việc của tầng này không chỉ là đưa dữ liệu vào, mà còn là tổ chức dữ liệu. Cần chọn lọc: chỉ nạp phần liên quan nhất cho bước tiếp theo. Cần ghi nhớ ra ngoài: những gì đã chốt nên được lưu thành ghi chú có cấu trúc, có ngày tháng và tra cứu lại được, thay vì bắt mô hình nhớ hết toàn bộ quá trình. Cần nén và tóm tắt: khi lịch sử quá dài, tóm tắt lại những điểm quan trọng thay vì giữ nguyên mọi chi tiết. Cần ghi rõ nguồn: thông tin đến từ đâu, mới hay cũ, đáng tin ở mức nào.
Một lỗi phổ biến ở tầng này là “nhồi” quá nhiều. Cửa sổ ngữ cảnh lớn không đồng nghĩa với khả năng hiểu đồng đều. Khi thông tin quan trọng bị chôn giữa một lượng lớn thông tin thừa, mô hình rất dễ bỏ sót hoặc nhầm lẫn. Một lỗi phổ biến khác là đưa thông tin cũ, thiếu ngày tháng, hoặc không phân biệt được đâu là dữ liệu thật, đâu là suy đoán từ bước trước.
Dấu hiệu cho thấy lỗi thuộc tầng context là: agent trả lời tự tin nhưng dựa trên tài liệu sai, tài liệu cũ, hoặc không có tài liệu nào cả. Hoặc agent làm đúng ở bước đầu, nhưng càng chạy nhiều bước thì càng lệch, vì những gì nó đọc được ngày càng nhiễu.
Tầng 3: Harness engineering — hệ thống xung quanh mô hình
Harness là tầng rộng nhất và cũng là tầng quyết định agent có dùng được trong thực tế hay không. Theo cách diễn đạt của Thoughtworks trên blog của Martin Fowler, công thức là: Agent bằng Model cộng với Harness. Harness là mọi thứ trong hệ thống agent trừ chính mô hình.
Cụ thể, harness bao gồm vòng lặp làm việc: agent lập kế hoạch, hành động, quan sát kết quả rồi quyết định bước tiếp theo như thế nào, và khi nào thì dừng. Nó bao gồm danh mục công cụ: agent được phép gọi những công cụ nào, với đầu vào ra sao, và kết quả được kiểm tra thế nào trước khi dùng tiếp.
Harness cũng bao gồm quyền và ranh giới. Agent được đọc những dữ liệu nào, được thay đổi những gì, và bước nào bắt buộc phải có người xác nhận trước khi thực thi. Đây là phần quan trọng nhất khi agent làm việc với dữ liệu nhạy cảm hoặc hành động có hậu quả thật, ví dụ gửi thông báo, cập nhật hồ sơ hay thay đổi cấu hình.
Tiếp theo là kiểm chứng. Một harness tốt không tin ngay vào lời agent nói. Nó kiểm tra bằng những cách mà máy có thể kiểm tra được trước: chạy test, kiểm tra định dạng, đối chiếu số liệu, kiểm tra quyền. Chỉ khi những kiểm tra mang tính xác định không đủ, mới dùng thêm mô hình để đánh giá. Nguyên tắc này giúp một lỗi nhỏ không lan thành hậu quả lớn.
Harness còn bao gồm khả năng quan sát và đánh giá. Mỗi lần chạy cần lưu lại vết: agent đã thấy gì, đã gọi công cụ nào, đã quyết định ra sao và kết quả kiểm tra thế nào. Không có vết này, việc sửa lỗi gần như là đoán mò. Song song đó là bộ đánh giá: một tập tác vụ chuẩn để chạy lại sau mỗi lần thay đổi, nhằm biết hệ thống đang tốt lên hay xấu đi.
Cuối cùng là giới hạn và xử lý lỗi. Harness cần giới hạn số vòng lặp, thời gian chạy và chi phí, để agent không chạy mãi không dừng. Khi công cụ lỗi, khi dữ liệu thiếu hoặc khi kết quả không đạt, harness cần có cách thử lại có kiểm soát, hoặc dừng lại và báo cho người dùng, thay vì tự bịa ra một kết quả cho xong.
Dấu hiệu cho thấy lỗi thuộc tầng harness rất khác với hai tầng trên. Đó là khi agent làm đúng một lần nhưng không lặp lại được, khi nó tự nhận đã xong trong khi việc chưa hoàn thành, khi lỗi nhỏ không được phát hiện cho tới cuối, hoặc khi hệ thống cứ xuống cấp dần theo thời gian mà không ai biết vì sao.
Ba tầng phối hợp trong một ví dụ
Hãy tưởng tượng một agent được giao nhiệm vụ tổng hợp chính sách làm việc và chuẩn bị bản cập nhật cho đội.
Prompt sẽ định nghĩa rõ: đầu ra là bản tóm tắt có những mục nào, giọng văn ra sao, và điều gì không được tự suy diễn thêm. Context sẽ cung cấp đúng tài liệu chính sách hiện hành, các quyết định đã chốt trước đó và những câu hỏi còn bỏ ngỏ, thay vì toàn bộ kho tài liệu của công ty. Harness sẽ điều phối việc truy xuất tài liệu, kiểm tra xem bản tóm tắt có trích đúng nguồn không, giới hạn quyền chỉnh sửa, và yêu cầu người phụ trách xác nhận trước khi bản cập nhật được gửi đi.
Nếu bản tóm tắt sai định dạng, hãy xem lại prompt. Nếu nó trích nhầm chính sách cũ, hãy xem lại context. Nếu nó tự gửi đi mà không ai duyệt, hoặc không ai biết nó đã dựa vào nguồn nào, hãy xem lại harness.
Nên xây dựng theo thứ tự nào
Với một agent mới, thứ tự thực tế thường là: làm rõ prompt trước, vì đây là cách rẻ nhất để kiểm tra xem nhiệm vụ đã được hiểu đúng chưa. Sau đó xây context, vì phần lớn lỗi của agent nhiều bước bắt đầu từ việc thiếu hoặc thừa thông tin. Cuối cùng mới đầu tư mạnh vào harness, khi agent bắt đầu làm việc thật, với dữ liệu thật và hậu quả thật.
Ngược lại, khi hệ thống đã chạy mà chất lượng không ổn định, đừng bắt đầu bằng việc viết lại prompt lần thứ mười. Hãy chẩn đoán theo tầng: lỗi xảy ra một lần hay lặp lại, lỗi nằm ở thông tin hay ở cách vận hành, và có bằng chứng nào từ log và kiểm tra để chứng minh không. Mỗi câu trả lời sẽ chỉ về một tầng khác nhau.
Kết
Prompt giúp mô hình hiểu mình muốn gì. Context giúp mô hình có đủ thứ để làm đúng. Harness giúp cả hệ thống làm đúng một cách đáng tin, kiểm chứng được và không xuống cấp theo thời gian.
Trong thời gian tới, lợi thế sẽ không chỉ thuộc về đội dùng mô hình mạnh nhất, mà thuộc về đội xây được cả ba tầng một cách cân bằng: nói rõ, thấy đúng và vận hành chặt chẽ. Khi ba tầng này phối hợp tốt, agent không chỉ trả lời hay hơn, mà còn làm việc đáng tin hơn — và đó mới là điều quyết định nó có được dùng lâu dài hay không.
Để lại một bình luận