Các tác nhân luôn là nhân viên ngày đầu. Đã đến lúc chúng ta thiết kế cho chúng.

Đến năm 2027, 74% các công ty dự kiến sẽ sử dụng các tác nhân ở một mức độ nào đó, theo một nghiên cứu gần đây của Deloitte. Trong nhiều năm, chúng tôi đã thiết kế và xây dựng phần mềm để cải thiện trải nghiệm con người khi duyệt các ứng dụng, trang web, hệ điều hành và tài liệu. Bây giờ, người dùng không còn là con người nữa. Điều này có những tác động rộng hơn so với việc chuyển từ các bảng điều khiển và quy trình làm việc được kiểm soát mà chúng ta thiết kế cho các nhiệm vụ của con người. Chúng ta đang ở thời điểm cần thiết kế môi trường hoạt động cho các tác nhân, trong khi cũng thiết kế quy trình làm việc của con người để hướng dẫn hiệu quả trải nghiệm của tác nhân trong những môi trường này.  

Chúng tôi vẫn đang ở giai đoạn đầu trong việc tìm hiểu các tác nhân thực sự cần gì từ chúng tôi để đạt được thành công lặp lại và đáng tin cậy. Phản xạ tự nhiên là coi việc tích hợp tác nhân chỉ là một vấn đề về lời nhắc hoặc giao diện người dùng. Thiết kế một môi trường thực thi được quản lý tốt là một lĩnh vực mới đối với chúng tôi như một nền văn hoá. Tuy nhiên, các nguyên tắc nền tảng của thiết kế tốt và quản lý tốt không thay đổi: chúng tôi nợ các tác nhân bối cảnh rõ ràng, chỉ dẫn không mơ hồ và ý định cụ thể.

Context: Why Coding Came First

Bối cảnh có lẽ là yếu tố quan trọng nhất nếu chúng ta muốn các tác nhân lặp lại việc cung cấp kết quả ở mức chúng ta mong muốn. Phát triển phần mềm có nhiều tài liệu ghi lại hơn hầu hết các lĩnh vực khác: kho mã, sơ đồ API, mối quan hệ giữa các hệ thống, đánh giá mã và các cuộc thảo luận cộng đồng. Vì vậy, việc các phòng thí nghiệm AI tiên phong bắt đầu với lập trình là hợp lý. Đây là một trong số ít các lĩnh vực mà một lượng lớn bối cảnh đã được ghi chép sẵn. 

Nhưng như bất kỳ nhân viên mới nào trong một đội phần mềm sẽ nói, ngay cả khi có tất cả dữ liệu đó, các tác nhân vẫn sẽ thiếu ký ức tổ chức được nhúng trong các quy tắc không viết ra mà không ai từng ghi lại. Khoảng trống này lan rộng: 43% nhà phát triển lo ngại rằng các công cụ AI thiếu bối cảnh đủ về dự án hoặc cơ sở mã cụ thể của họ. Kiến thức tiềm tàng bao phủ mọi thứ từ các quy ước hàng ngày, như thư viện ưa thích cho các nhiệm vụ cụ thể, đến những “bóng ma” vận hành quan trọng: một bản sửa lỗi đêm muộn kéo dài mãi mãi, hoặc một cột dữ liệu dường như trống nhưng thực chất là nền tảng cho báo cáo doanh thu tùy chỉnh. Bối cảnh này tồn tại trong đầu của kỹ sư cao cấp, trong một chuỗi tin nhắn Slack gần đây, hoặc không ở đâu cả. Nó hiếm khi có trong chính cơ sở mã.  

Nếu điều này đúng trong phần mềm, một trong những lĩnh vực được ghi chép tốt nhất, thì dễ hiểu tại sao các tác nhân gặp khó khăn trong việc hoạt động hiệu quả ngay từ ngày đầu ở nhiều ngành khác. Trong y tế và pháp luật, phần lớn kiến thức tổ chức định hình công việc hằng ngày được học và nội hoá. Nó tồn tại trong kinh nghiệm của con người hơn là trong tài liệu chính thức. Một tác nhân pháp lý có thể không biết cấu trúc, tông giọng hoặc cách lập luận ưa thích của một đối tác cụ thể cho một bản tóm tắt, trong khi một tác nhân y tế có thể không hiểu quy trình làm việc địa phương và các thực hành leo thang mà một phòng khám bận rộn sử dụng để hỗ trợ phân loại do bác sĩ dẫn dắt. Tài liệu đơn độc không thể lấp đầy khoảng trống đó, vì thách thức không chỉ là truy cập thông tin; mà là chuyển giao bối cảnh. Để cung cấp cho các tác nhân những gì chúng cần để thành công, chúng ta phải đưa chúng vào môi trường như khi chúng ta tuyển dụng một nhân viên mới.

Direction: Why Osmosis Doesn’t Work

Việc đưa một đồng đội mới vào làm không chỉ là cung cấp tài liệu và quyền truy cập phù hợp. Khi chúng ta quan tâm tới thành công của những người xung quanh, chúng ta cung cấp chỉ dẫn vững chắc về cách sử dụng tài liệu và quyền truy cập mới: mong đợi, sự rõ ràng về mục tiêu, và phản hồi trong suốt quá trình. Tôi mang cùng tư duy này khi thiết kế cho các tác nhân. Tôi đưa ra chỉ dẫn rõ ràng, cụ thể (liên quan tới nhiệm vụ hiện tại). Điều này áp dụng cho bất kỳ đồng đội nào, bất kể thâm niên. Tuy nhiên, trong trường hợp tuyển dụng mới, chỉ dẫn phải đi xa hơn, vì họ chưa có bất kỳ bối cảnh tổ chức nào.

Hãy nghĩ về một tác nhân như một nhân viên mới không bao giờ ngừng là mới. Nó háo hức và có khả năng (và thực tế, có năng lượng vô hạn), nhưng không thể tiếp thu và lưu giữ nhiều quy tắc không viết ra như một con người theo thời gian. Con người học qua quá trình thẩm thấu và kinh nghiệm, trong khi các tác nhân học từ kiến trúc được xây dựng một cách rõ ràng trong môi trường làm việc của chúng.

Với một nhân viên mới, bạn có thể thu hẹp khoảng trống đó theo thời gian bằng các câu hỏi, phản hồi và những hiểu biết mới mà họ thu thập về quy trình và sở thích của tổ chức. Những cuộc trò chuyện bên máy pha cà phê hoặc bữa trưa nhóm. Với một tác nhân, bạn phải xây dựng việc thu hẹp khoảng trống ngay trong thiết kế. Điều này có thể bao gồm: 

• Cung cấp cho tác nhân một cửa sổ bối cảnh có cấu trúc, tách biệt các quy tắc bền vững, các thực tế riêng nhiệm vụ và lịch sử liên quan, thay vì ném một đống tài liệu vào tay nó.
• Xác định trước các quyền hạn và ranh giới quyết định của nó: những gì nó có thể thực hiện độc lập, những gì cần phê duyệt, và những gì nó không bao giờ được truy cập.
• Nhúng một vài ví dụ cụ thể về đầu ra mạnh mẽ trực tiếp trong trải nghiệm, để tác nhân có mô hình rõ ràng về cách thực hiện công việc.
• Chia sẻ những dead‑end trước đây mà bạn đã gặp.

Thiết kế một môi trường tác nhân được quản lý tốt không phải là để làm công việc dễ hơn cho mô hình. Nó là để bảo vệ đội kỹ sư con người khỏi nợ kỹ thuật vô hình. Nhưng ngay cả một tác nhân được chỉ dẫn tốt cũng có thể thực hiện đúng mọi chỉ dẫn mà vẫn bỏ lỡ mục tiêu. Chỉ dẫn cho nó biết phải làm gì, nhưng không cho nó biết “tốt” trông như thế nào. Khoảng trống đó là nơi mà ý định xuất hiện.

Intent: Why Agents Drift to The Middle

Cần nhớ rằng các tác nhân là những cỗ máy khớp mẫu, được đào tạo trên khối lượng kiến thức khổng lồ và tự nhiên có xu hướng đưa ra kết quả trung bình thống kê. Nếu không có ý định rõ ràng, cụ thể, kết quả trung bình đó chính là những gì một tác nhân sẽ trả về. Yêu cầu một tác nhân “thêm một endpoint xác thực người dùng,” và nó sẽ tạo ra một route Express textbook với mã băm mật khẩu cơ bản. Nó hoạt động, nhưng hoàn toàn bỏ qua dịch vụ xác thực tùy chỉnh của đội bạn, bỏ qua việc ghi nhận telemetry cần thiết, và phá vỡ định dạng lỗi chuẩn của bạn. Trên giấy tờ, đó là một tính năng đủ, nhưng tùy vào bối cảnh, nó lại là một lỗi kiến trúc trong thực tế. Độ dễ dàng mà các “lỗi” như vậy được đưa vào không thể đánh giá quá cao.

Để ngăn chặn điều này, chỉ dẫn phải đi kèm với việc xác minh và ghi nhật ký ý định một cách chủ động. Các rào cản không chỉ kiểm tra mã có biên dịch hay không, mặc dù điều này cũng quan trọng. Các rào cản phải thực thi một cách rõ ràng các tiêu chuẩn có quan điểm, các quy tắc trường hợp biên, và bối cảnh miền mà nâng đầu ra chung thành công việc sẵn sàng sản xuất. Ghi nhật ký quan trọng như một chỉ báo trạng thái hệ thống cho chúng ta, con người. Khả năng truy vết này là yếu tố then chốt cho niềm tin. 

Trong tương tác con người, có rất nhiều không gian cho sự không chắc chắn. Ai đó có thể chia sẻ phiên bản đầu tiên với bạn, và cùng nhau bạn có thể thảo luận những gì mạnh và những gì cần cải thiện. Điều này hoạt động vì chúng ta không mong đợi đồng nghiệp con người của mình là những máy tự động. Để thực sự khai thác sức mạnh và tiềm năng của các đồng nghiệp tác nhân (mà chúng ta cần để chúng hoạt động tự chủ hơn…), chúng ta có thể thiết kế nhiều kiểm tra chỉ dẫn này. Cuộc trao đổi qua lại vẫn cần diễn ra, nhưng không thể hoàn toàn dựa vào nỗ lực thủ công. Bằng cách đặt trước các tiêu chí chấp nhận rõ ràng và các quy tắc xác minh, bạn cho phép tác nhân tự vận hành các vòng phản hồi nội bộ. Thiết kế để ngăn ngừa lỗi là một nguyên tắc UX hợp lý khác mà chúng ta có thể áp dụng trong thế giới mới này: cho phép các tác nhân đánh dấu độ tin cậy thấp trước khi thực hiện hành động, thay vì im lặng đưa ra giả định tốt nhất.

Where the Metaphor Breaks

Cách so sánh với nhân viên mới hoạt động, cho đến khi không còn. Với một nhân viên con người, kinh nghiệm tạo ra năng lực, năng lực tạo ra phán đoán. Việc quan sát nhân viên mới nội hoá “tại sao” đằng sau bối cảnh và chỉ dẫn là những gì xây dựng niềm tin theo thời gian, và nói chung, đây là quá trình tích lũy. Một tác nhân không có nơi nào để tích lũy và lưu trữ kinh nghiệm này.

Tuần đầu tiên và tuần trăm của một nhân viên mới trông khác nhau. Nhiệm vụ đầu tiên và nhiệm vụ ngàn thứ của một tác nhân lại giống hệt nhau, trừ khi bạn thiết kế và xây dựng điều gì đó để làm chúng khác nhau. Đây là thách thức thiết kế mới của chúng ta.

Agent Responsibility Hinges on Design

Nếu trách nhiệm không thể tồn tại trong tác nhân, nó phải tồn tại trong khung xương xung quanh nó. Điều này trở lại ba câu hỏi tôi sẽ đặt ra trước khi giao việc cho bất kỳ nhân viên mới nào: Họ có bối cảnh gì? Tôi đã đưa ra chỉ dẫn gì? Ý định thực sự của tôi là gì?

Lần tới khi bạn giao một nhiệm vụ cho một tác nhân, đừng chỉ kiểm tra đầu ra. Hãy kiểm tra các đầu vào của chính bạn trước. Bạn đã cung cấp cho nó bối cảnh mà một nhân viên mới cần vào ngày đầu chưa? Chỉ dẫn của bạn có đủ cụ thể để chịu được việc bị hiểu theo nghĩa đen không? Ý định của bạn có đủ rõ ràng để “câu trả lời trung bình” không phải là kết quả tốt nhất có thể?

Với hướng dẫn rõ ràng trong tay (theo byte?), một điều thú vị xảy ra: một tác nhân không cần một thời gian dài để trở nên đáng tin cậy. Bối cảnh, chỉ dẫn và xác minh mà bạn xây dựng từ đầu định nghĩa cách nó hoạt động trên mỗi nhiệm vụ. Một nhân viên mới kiếm được niềm tin của bạn theo thời gian; một tác nhân phải kiếm được niềm tin mỗi lần thông qua hệ thống mà bạn đã thiết kế. Trách nhiệm không phải là thứ nó phát triển dần, mà được nhúng sẵn từ đầu. Câu hỏi không phải là khi nào tác nhân của bạn sẽ sẵn sàng cho nhiều trách nhiệm hơn. Mà là liệu bạn đã thiết kế nó để kiếm được trách nhiệm đó trên mỗi nhiệm vụ duy nhất.