Sự chuyển dịch từ trả lời sang hành động
Trong vài năm qua, phần lớn chúng ta đã liên hệ với các mô hình ngôn ngữ theo cách giống như cách ta liên hệ với một đồng nghiệp rất am hiểu. Bạn đặt một câu hỏi, bạn nhận được một câu trả lời, và điều gì xảy ra tiếp theo là do bạn quyết định. Cách làm đó lặng lẽ đang được thay thế. Những vấn đề thú vị hiện nay không còn nằm ở việc làm sao để một mô hình nói đúng điều. Chúng nằm ở việc làm sao để có được một hệ thống làm đúng điều, xuyên suốt nhiều bước, với các công cụ thật, trong những môi trường lộn xộn nơi mà kế hoạch đầu tiên hiếm khi sống sót khi chạm thực tế.
Đó là điều kỹ nghệ tác nhân (agentic engineering) hướng tới. Đây là kỷ luật thiết kế, xây dựng và vận hành các hệ thống, trong đó mô hình không chỉ tạo ra văn bản mà còn thực hiện hành động, xem xét kết quả và quyết định bước tiếp theo cho đến khi đạt được mục tiêu. Mô hình vẫn nằm ở trung tâm của mọi thứ, nhưng giờ đây nó chỉ là một thành phần trong một cỗ máy lớn hơn, và phần khó khăn thực sự chủ yếu nằm ở mọi thứ xung quanh nó.
Sự chuyển dịch này quan trọng vì kỹ năng là khác nhau. Viết prompt thưởng cho cách diễn đạt khéo léo. Kỹ nghệ tác nhân thưởng cho những thứ vốn luôn làm phần mềm trở nên đáng tin cậy: giao diện rõ ràng, khả năng quan sát (observability) tốt, xử lý lỗi hợp lý và một vòng lặp chặt chẽ giữa thứ bạn triển khai và thứ bạn học được. Thành phần mới thực sự duy nhất là yếu tố không thể đoán trước nằm ngay giữa tất cả.
Tác nhân thực sự là gì
Thuật ngữ “tác nhân” (agent) bị kéo giãn để bao phủ gần như mọi thứ, vì vậy đáng để nói chính xác. Tác nhân là một hệ thống theo đuổi mục tiêu bằng cách lặp đi lặp lại việc chọn các hành động dựa trên những gì nó quan sát được, thay vì bám theo một kịch bản cố định. Điểm đặc trưng là vòng lặp, không phải mức độ thông minh. Một bộ điều nhiệt tuân theo một quy tắc. Một tác nhân thì quyết định.
Giúp ích nếu nhìn quyền tự chủ như một dải (spectrum) thay vì chỉ có “có” hoặc “không”. Ở một đầu là một lần gọi mô hình duy nhất để phân loại một email. Xa hơn một chút, một quy trình (workflow) ghép chuỗi nhiều lần gọi theo một thứ tự cố định—điều này hữu ích nhưng vẫn mang tính kịch bản. Xa hơn nữa, mô hình sẽ chọn gọi công cụ nào và khi nào, rồi tiếp tục cho đến khi nó đánh giá rằng công việc đã xong. Ở đầu xa nhất, hệ thống tự đặt các mục tiêu con, quản lý bộ nhớ của riêng nó và chạy trong nhiều giờ. Phần lớn hệ thống sản xuất ngày nay nằm đâu đó giữa, và thường đó là vị trí đúng, bởi vì quyền tự chủ hoàn toàn hiếm khi là thứ mà bài toán thực sự cần.
Quyết định hệ thống của bạn nằm ở đâu trên dải này là một trong những điều làm bạn sáng tỏ nhất ở giai đoạn sớm. Nó cho bạn biết mức độ bạn có thể dựa vào phán đoán của mô hình, bạn cần áp đặt bao nhiêu cấu trúc, và rủi ro sẽ tập trung ở đâu.
Vòng lặp của tác nhân
Bỏ qua tên gọi framework và lớp vỏ marketing, thì hầu như mọi tác nhân đều chạy cùng một vòng lặp. Nó thu thập ngữ cảnh về tình huống của mình, suy luận về việc cần làm gì, thực hiện một hành động và quan sát điều gì đã xảy ra. Rồi nó lặp lại lần nữa, sử dụng những gì vừa học được, cho đến khi đạt được mục tiêu hoặc nó bỏ cuộc.
Mỗi lượt đi qua vòng lặp này là một điểm ra quyết định, và các điểm ra quyết định là nơi mọi thứ có thể diễn ra đúng hoặc sai. Một vòng lặp tác nhân tốt không phải là vòng lặp có prompt “khéo” nhất. Nó là vòng lặp mà mỗi giai đoạn có vừa đủ thông tin để đưa ra lựa chọn đúng đắn và không hơn. Nếu bạn đưa cho mô hình toàn bộ lịch sử của mọi thứ đã xảy ra, nó sẽ bị đứt mạch. Nếu bạn cho quá ít, nó sẽ hành động như thể mù. Một phần lớn “tay nghề” nằm ở việc quyết định mô hình được thấy gì ở mỗi lượt.
Vòng lặp cũng giải thích vì sao việc xây dựng tác nhân lại có cảm giác khác xa so với phần mềm thông thường. Trong mã thông thường, bạn có thể suy luận về mọi nhánh. Ở đây, mô hình có thể chọn một nhánh mà bạn chưa từng nghĩ tới, khôi phục khỏi một lỗi theo cách mà bạn không hề lên kế hoạch, hoặc đi lạc theo một hướng trông có vẻ hợp lý trong ba bước rồi sau đó mới vỡ ra. Bạn không viết “con đường” đó. Bạn đang định hình không gian các con đường có thể xảy ra và cố gắng làm cho các con đường tốt dễ tìm nhất.
Giải phẫu của một tác nhân
Giúp ích nếu hình dung một tác nhân như một tập nhỏ các thành phần, mỗi thành phần làm đúng một việc. Có mô hình, cung cấp suy luận và ngôn ngữ. Có công cụ, giúp hệ thống tác động lên thế giới và đọc ngược lại từ thế giới đó. Có bộ nhớ và ngữ cảnh, mang thông tin liên quan vào từng quyết định. Và có phần điều phối (orchestration) bao quanh tất cả: nó chạy vòng lặp, áp đặt giới hạn và quyết định khi nào thì dừng.
Điều nổi bật, sau khi bạn xây được vài cái như vậy, là việc phần lớn “công việc khó” lại chẳng liên quan nhiều đến chính mô hình. Mô hình chủ yếu là một lựa chọn cố định. Bạn chọn một cái, bạn “prompt” nó, rồi bạn chuyển sang bước tiếp theo. Nỗ lực kỹ thuật lại nằm ở những phần xung quanh nó. Những công cụ tốt, khả năng xử lý ngữ cảnh tốt và điều phối tốt là thứ tách một bản demo chạy được một lần khỏi một hệ thống mà bạn có thể để chạy liên tục. Những đội cứ chăm chăm vào cách viết prompt và bỏ qua các phần này thường xây ra những thứ trông ấn tượng vào thứ Ba và bị hỏng vào thứ Sáu.
Công cụ và ngữ cảnh là bề mặt thực sự
Nếu vòng lặp là bộ khung xương, thì công cụ và ngữ cảnh là nơi mà kỹ nghệ thực sự diễn ra.
Công cụ là “đôi tay” của mô hình. Nó là cách tác nhân đọc một cơ sở dữ liệu, gửi một tin nhắn, chạy một truy vấn, hoặc di chuyển một tệp. Chất lượng công cụ của bạn đặt ra một “trần” cứng cho những gì tác nhân có thể làm, và thiết kế công cụ hóa ra cũng là một nghề riêng. Một công cụ tốt làm đúng một việc rõ ràng, có tên và mô tả giúp mô hình biết chính xác khi nào thì cần dùng nó, kiểm tra đầu vào của nó, và trả về kết quả dễ để hành động theo. Một công cụ mơ hồ với mô tả mập mờ còn tệ hơn cả việc không có công cụ, vì mô hình sẽ dùng nó một cách tự tin nhưng sai. Mức độ cẩn trọng mà bạn đặt vào việc thiết kế một giao diện cho một đồng nghiệp có năng lực nhưng còn mới mẻ gần như là mức cẩn trọng mà một công cụ xứng đáng nhận được—bởi vì đó gần như là tình huống tương tự.
Ngữ cảnh là nửa còn lại. Mô hình chỉ biết những gì được đặt trước nó, nên trong mỗi lượt bạn đang trả lời một câu hỏi nhỏ lặng thầm: mô hình cần thấy gì ngay lúc này để chọn tốt? Đây là nơi thuật ngữ “context engineering” (kỹ nghệ ngữ cảnh) bắt nguồn, và nó đã trở thành một trong những vấn đề trung tâm của lĩnh vực. Cách tiếp cận ngây thơ là nhét thêm mọi thứ vào cửa sổ: thêm lịch sử, thêm tài liệu, thêm chỉ dẫn. Cách đó không mở rộng được. Sự chú ý bị loãng đi, chi phí tăng lên, và mô hình bắt đầu bỏ lỡ đúng thứ mà thực sự quan trọng. Cách tốt hơn coi ngữ cảnh như một ngân sách cần chi đúng mục đích. Bạn truy xuất phần liên quan, tóm tắt phần cũ, bỏ đi phần đã xong, và giữ cho “tập làm việc” nhỏ gọn, sắc nét. Làm đúng điều này thường là khác biệt giữa một tác nhân vẫn mạch lạc qua một nhiệm vụ dài và một tác nhân dần đánh mất phương hướng.
Vì sao tác nhân lại khó
Dưới đây là một sự thật khó chịu mà mọi đội cuối cùng rồi cũng nhận ra. Một lần gọi mô hình đơn lẻ có độ tin cậy tương đối cao. Ghép chuỗi hai mươi lần gọi đó lại và các tỷ lệ lỗi nhỏ sẽ cộng dồn thành những hệ thống thất bại nhiều hơn là thành công.
Số học này rất nghiệt ngã. Nếu mỗi bước trong một nhiệm vụ gồm mười bước đúng 95% thời gian, thì cả nhiệm vụ chỉ thành công vào khoảng 60% thời gian, và điều đó giả định rằng các lỗi là độc lập—trong thực tế thường không phải vậy. Một quan sát sai ở giai đoạn đầu có thể đầu độc mọi quyết định sau đó. Sự cộng dồn này là lý do lớn nhất khiến những tác nhân làm “choáng” trong demo lại gặp khó khăn khi triển khai vào sản xuất. Demo chỉ là một đường đi hạnh phúc. Sản xuất là mười nghìn đường đi, và phần “đuôi dài” chứa những kiểu đầu vào mà không ai nghĩ tới để cân nhắc.
Các dạng thất bại phát triển “tính cách riêng” sau khi bạn đã thấy đủ nhiều. Tác nhân bị mắc kẹt trong các vòng lặp, gọi cùng một công cụ hết lần này đến lần khác và vẫn kỳ vọng một câu trả lời khác. Chúng bịa ra một công cụ hoặc một kết quả
