Vị trí của vòng đời phát triển tác nhân (Agent Development Lifecycle)

AI tác nhân: Vị trí của Vòng đời Phát triển Tác nhân Phối hợp phát triển năng lực tác nhân với ứng dụng mà nó hỗ trợ Andrew Hinton Ngày 2 tháng 10 năm 2026 11 phút đọc Được tạo bằng AI Giới thiệu Thảo luận của Harrison Chase về vòng đời phát triển tác nhân (ADLC) tại sự kiện Interrupt26 NYC đã thúc đẩy tôi suy nghĩ kỹ hơn về vị trí của vòng đời này. Một tác nhân có thể điều tra một email, nhưng ứng dụng sẽ quyết định cách cuộc điều tra đó đi vào hàng đợi, đến tay một nhà phân tích hoặc dẫn đến một hành động. Việc cải thiện cuộc điều tra và thay đổi quy trình làm việc là những hoạt động có liên quan, với các câu hỏi thiết kế khác nhau và bằng chứng tiến bộ khác nhau. Quan điểm của tôi là chúng ta nên phối hợp ADLC một cách riêng biệt nhưng đồng thời với quá trình phát triển ứng dụng mà nó hỗ trợ. Sự phân biệt này rất quan trọng vì một tác nhân có thể thay đổi độc lập và hành vi của nó ảnh hưởng đến cả thiết kế và kết quả của ứng dụng trong một vòng lặp phát triển gắn kết chặt chẽ. Trong bài viết này, tôi giải thích cách chúng ta có thể tổ chức vòng lặp đó thông qua các cuộc điều tra thiết kế rõ ràng, các yêu cầu chung và các trường hợp đánh giá theo dõi kết quả của tác nhân vào ứng dụng. Cùng một nhóm có thể chịu trách nhiệm cho cả hai mảng, nhưng mỗi mảng cần phải được duy trì rõ ràng và riêng biệt trong kế hoạch phát triển. Tìm hiểu từng bước với lộ trình AI Agents tương tác. Bối cảnh Hướng dẫn Chu trình Phát triển Ứng dụng (ADLC) hiện có bao gồm các công việc thiết kế và thử nghiệm đáng kể. Harrison Chase mô tả các so sánh giữa các lời nhắc (prompts), mô hình (models), chiến lược truy xuất (retrieval strategies), lược đồ công cụ (tool schemas) và các mẫu điều phối (orchestration patterns) trong các giai đoạn Xây dựng, Thử nghiệm, Triển khai và Giám sát [1]. Salesforce bắt đầu với Giai đoạn Ý tưởng và Thiết kế, đồng thời mô tả một vòng lặp phát triển nội bộ và một vòng lặp giám sát bên ngoài [2]. Tôi xây dựng trên nền tảng đó bằng cách đặt câu hỏi về những thay đổi khi tác nhân (agent) là một hệ thống con trong một ứng dụng lớn hơn, với các yêu cầu và quyết định phát hành mà hai nỗ lực phát triển phải phối hợp. Các bài viết trước đây của tôi đã xem xét công trình khoa học đằng sau sự phát triển năng lực. Bài viết "Giai đoạn còn thiếu trong Kỹ thuật Hệ thống Tác nhân" (The Missing Phase in Agentic Systems Engineering) lập luận về thời gian và bằng chứng rõ ràng trước khi cam kết với một thiết kế [3], và "Hiểu biết là tiền tệ của Khoa học Dữ liệu" (Insight Is the Currency of Data Science) xem xét cách thử nghiệm tạo ra sự hiểu biết về hành vi của tác nhân [4]. Cuộc điều tra đó tiếp tục khi một ứng dụng phát triển, bao gồm cả những trường hợp khi bằng chứng thách thức các giả định đằng sau thiết kế của nó. Học tập vòng lặp kép của Argyris cũng tương tự yêu cầu chúng ta xem xét lại các giả định chi phối khi các hành động khắc phục tỏ ra không đủ [9]. Kỹ thuật hệ thống kết nối các yêu cầu và thiết kế của từng bộ phận với mục đích của hệ thống hoàn chỉnh trong suốt vòng đời của nó và đã được ghi nhận và sử dụng rộng rãi. Đáng chú ý, Sổ tay Kỹ thuật Hệ thống do Cơ quan Hàng không và Vũ trụ Quốc gia (NASA) xuất bản mô tả sự phối hợp này trên các cấp độ của một hệ thống [5]. Trong phần mềm, các hợp đồng theo định hướng người tiêu dùng (consumer-driven contracts) cũng làm cho các nghĩa vụ của nhà cung cấp trở nên rõ ràng thông qua các kỳ vọng do người tiêu dùng cung cấp [10]. Cùng nhau, những ý tưởng đã được thiết lập này tạo thành cơ sở của cơ chế phối hợp mà tôi đề xuất trong bài viết này. Việc coi tác nhân là một hệ thống con có nghĩa là phát triển năng lực của nó một cách rõ ràng và kiểm tra sự đóng góp cũng như tác động của nó đối với ứng dụng. Ở đây, chúng ta sẽ xem xét ranh giới hệ thống, sau đó là vòng lặp phát triển của tác nhân. Các phần về yêu cầu và phối hợp tiếp theo sẽ giải thích cách các trường hợp đánh giá chung kết nối công việc, và cuối cùng phần Thảo luận sẽ xem xét chi phí và giới hạn của việc tách biệt các vòng đời, với phần Kết luận đưa ra các bước thực tế. ··· Tác nhân là một hệ thống trong ứng dụng Trước hết, cơ sở của bài viết này là coi tác nhân như một hệ thống riêng biệt trong ứng dụng, với các bộ phận nội bộ mà sự tương tác của chúng định hình khả năng thực hiện một nhiệm vụ. Để hiểu rõ hơn, Hình 1 chuyển từ một sinh vật sang một tế bào để minh họa rằng sự phức tạp có thể tồn tại ở nhiều hơn một quy mô. Tế bào có các quá trình nội bộ và tham gia vào một hệ thống lớn hơn, giống như một tác nhân có các tương tác nội bộ và đóng góp vào kết quả của một ứng dụng. Việc vẽ tác nhân như một hộp duy nhất có thể che giấu một vấn đề phát triển đáng kể bên trong nó. Bộ điều phối của tác nhân điều phối mô hình, bộ nhớ, công cụ và bất kỳ tác nhân con nào, tập hợp ngữ cảnh và kiểm soát việc thực thi. Ngữ cảnh cung cấp thông tin cho bước hiện tại, và bộ nhớ lưu giữ thông tin để truy xuất sau này. Một cuộc điều tra có thể phụ thuộc vào việc phục hồi bằng chứng đã thu thập trước đó, vì vậy hiệu suất phụ thuộc vào những gì đã được lưu giữ, những gì đã được truy xuất và cách nó đến được mô hình. Việc chuyển giao giữa các tác nhân con đặt ra thêm câu hỏi về việc liệu bằng chứng có tồn tại khi công việc di chuyển giữa các bộ phận hay không. Đánh giá tác nhân kiểm tra năng lực được tạo ra bởi sự kết hợp đó, và đánh giá ứng dụng theo dõi kết quả của nó thông qua quy trình làm việc hoàn chỉnh. Cả hai cấp độ đều cần dựa trên các bằng chứng về yêu cầu và mục đích sử dụng của chúng. Ứng dụng vẫn giữ trách nhiệm về nhận dạng, ủy quyền và các kiểm soát vận hành ngay cả khi thiết kế nội bộ của tác nhân thay đổi, điều này khiến ranh giới trở thành một chủ đề phát triển liên tục. Hình 1. Quan điểm từ cấp độ sinh vật đến tế bào minh họa sự phức tạp trên nhiều quy mô. Quan điểm từ ứng dụng đến tác nhân làm lộ rõ cơ chế điều khiển và các bộ phận mà nó phối hợp, sử dụng cùng một cách phân tách như Hình 4. Kết quả được trả về quy trình làm việc của ứng dụng, nơi tác động của chúng đối với kết quả tổng thể được đánh giá. Tác nhân cần một vòng lặp phát triển ADLC (Vòng đời phát triển tác nhân) kết nối quá trình phát triển với việc học hỏi từ quá trình sử dụng thực tế, và công việc thử nghiệm của nó có thể bao gồm các thay đổi đối với thiết kế [1, 2]. Tôi sẽ làm rõ quyết định xem xét lại thiết kế đó. Hình 2 cho thấy sự quay lại từ giai đoạn "Kiểm tra và đánh giá" đến "Xây dựng" đối với các thay đổi trong giả thuyết hiện tại, và quay lại giai đoạn "Lập kế hoạch" khi bằng chứng đặt ra nghi vấn về giả thuyết hoặc sự phân tách nhiệm vụ. Lập kế hoạch xác định cuộc điều tra tiếp theo và các tiêu chí chấp nhận của nó, bao gồm bất kỳ giả định nào cần thảo luận với nhóm ứng dụng. Một cuộc điều tra liên tục mất bằng chứng giữa