Sau khi Đại lý tiếp nhận nhiệm vụ, điều đầu tiên cần siết chặt chính là bộ phận công tác.

Gần đây tôi đã đọc rất nhiều cuộc thảo luận về Đại lý và cuối cùng tôi luôn quay lại cùng một câu hỏi: Ai nên giao một phần công việc cho ai, nó nên được đóng gói như thế nào trước khi bàn giao và nó sẽ được chấp nhận như thế nào sau khi nó được trả lại. Một khi vấn đề này xảy ra trong một dự án, điều đầu tiên tăng lên thường không phải là chi phí của mô hình mà là sự phức tạp của đơn vị công việc. Nếu nhiệm vụ bị cắt quá lớn, mô hình sẽ xuất hiện “như thể có thể thực hiện được”; vấn đề thực sự thường nằm ở việc khôi phục, sao chép và chấp nhận.

Đơn vị công việc trước tiên phải có khả năng được chấp nhận

Trong vài ngày qua, sau khi xâu chuỗi các ghi chú rời rạc của Martin Fowler và một số cuộc thảo luận tại Khóa tu Tương lai của Phát triển Phần mềm Thoughtworks, cảm giác rõ ràng nhất là cuộc trò chuyện trong cuộc họp có vẻ rải rác một cách hời hợt, nhưng bên dưới nó thực sự chỉ xoay quanh một điều - bàn giao một khối lượng công việc lớn cho Đặc vụ.

Khả năng dứt điểm của Kief Morris là đơn giản nhất. Các phiên khác nhau đã thảo luận về việc xem xét mã, sự cố trong sản xuất, phân công lao động nhóm và định tuyến mô hình. Họ dường như đang nói về những điều khác nhau, nhưng kết luận hóa ra lại giống nhau: mọi người đang điều chỉnh quy mô của “đơn vị công việc”. Đơn vị càng lớn thì càng dễ bàn giao; Đơn vị càng lớn thì sau khi về lại càng khó chấp nhận. Không phải mô hình không làm được mà là liên kết xác nhận tiếp theo không thể theo kịp trước.

Đây là lý do tại sao dây nịt được nhắc đi nhắc lại nhiều lần. Quản lý bối cảnh, cảm biến tính toán, kiểm tra dựa trên thuộc tính, phương pháp chính thức, những thứ này nghe có vẻ giống như các công cụ bổ sung, nhưng chúng thực sự thu thập các đơn vị công việc. Một số người điều khiển agents.md xuống dưới 200 dòng, không phải để theo đuổi sự gọn gàng về mặt hình thức mà để buộc hệ thống chỉ nhận phần thông tin thực sự hữu ích và thực sự có thể kiểm tra được. Bối cảnh quá lỏng lẻo, đương nhiên Agent có thể chạy; nhưng sau khi chạy, không ai biết nó đã nuốt chửng tầng ràng buộc nào.

Tự lưu trữ đưa bề mặt điều khiển lên

Các cuộc thảo luận về các mô hình tự lưu trữ cũng chỉ ra điều tương tự. Sau khi token trở nên đắt hơn, yêu cầu tuân thủ chặt chẽ hơn và dữ liệu không thể bị rò rỉ ra ngoài, các mô hình nguồn mở và mô hình địa phương đương nhiên sẽ trở nên hấp dẫn hơn. Nhưng một khi bạn tự mình mang theo mô hình, bạn cũng gặp rắc rối: GPU, phòng suy luận, định tuyến, khôi phục, tinh chỉnh và lựa chọn mô hình. Bản thân những khả năng này không phải là khả năng của mô hình nhưng chúng sẽ quyết định liệu hệ thống cuối cùng có ổn định hay không.

Những chi phí như vậy thường được đánh giá thấp. Nhiều nhóm ban đầu tập trung vào việc “liệu mô hình có mạnh hơn hay không”, nhưng sau đó phát hiện ra rằng điều thực sự tiêu tốn thời gian là việc chuyển giao ổn định các đơn vị công việc giữa nhiều mô hình. Khi nào nên sử dụng mô hình lớn, khi nào nên sử dụng mô hình nhẹ và khi nào chỉ cần sử dụng mô hình cục bộ, điều đó không phụ thuộc vào sở thích bằng lời nói mà phụ thuộc vào lớp bề mặt điều khiển có thể được sử dụng để chuyển hướng và che đậy. Nếu không có lớp thứ này, việc tự lưu trữ sẽ chuyển từ trạng thái “chủ động” sang “tự mình đảm nhận sự phức tạp trong vận hành và bảo trì”.

Simon Willison đề cập đến việc cho phép những người mẫu mạnh hơn chọn những người mẫu nhỏ hơn để thực hiện công việc. Ý tưởng này cũng rất giống với những gì mặt phẳng điều khiển đang làm. Bản thân mô hình không nhất thiết phải biết ranh giới chi phí của nhóm, nhưng hệ thống thì biết. Coi mô hình này như một nhà môi giới và sử dụng nó để phân bổ nhiệm vụ gần với việc phân phối thực tế hơn là theo đuổi một cách mù quáng một mô hình duy nhất để phân phối trọn gói.

Việc chấp nhận và mục tiêu không thể thuê ngoài

“Mang cho tôi một hòn đá” của Sam Ruby đã đưa một vấn đề khác ra ánh sáng. Đưa công việc vào mô hình tương đương với việc thêm một người thực thi; trách nhiệm không biến mất. Các nhà quản lý có thể sử dụng LLM để khám phá và họ có thể để nó đưa ra một loạt giải pháp ứng cử viên trước, nhưng tiêu chí chấp nhận cuối cùng vẫn phải rơi vào tay con người. Mục tiêu ẩn là rắc rối nhất. Quyền, quyền riêng tư, hành động phá hoại và rò rỉ ngữ cảnh thường không được đưa vào các yêu cầu ban đầu.

Vì vậy, các bài kiểm tra sự phù hợp thường hữu ích hơn các thông số kỹ thuật. Thông số kỹ thuật rất tốt trong việc mô tả “những gì được yêu cầu” và các bài kiểm tra sẽ tốt hơn trong việc chỉ ra “những gì không thể xảy ra”. Điều này đặc biệt đúng trong các hệ thống Đại lý. Mô hình có thể đáp ứng rất tốt các mục tiêu rõ ràng, nhưng các ranh giới tiềm ẩn cần được xác minh thông qua việc xác minh chặt chẽ hơn. Chừng nào các điều kiện chấp nhận còn được mô tả mơ hồ thì Tác nhân càng làm nhiều thì hệ thống sẽ càng giống như đang đặt cược vào xác suất.

Do đó, việc xem xét mã, xử lý sự cố và phân công nhiệm vụ, vốn từng là những nhiệm vụ rất giống con người, giờ đây bắt đầu có những hình thức khác. Người quản lý sử dụng mô hình trực tiếp. Nhìn bề ngoài thì có vẻ như đang nâng cao hiệu quả, nhưng thực chất họ đang thay đổi một phương pháp quản lý: từ phương pháp quản lý sang quản lý mục tiêu. Nếu mục tiêu được viết rõ ràng thì mô hình sẽ có cơ hội phát huy tác dụng; nếu mục tiêu không rõ ràng, mô hình sẽ chỉ khuếch đại sự mơ hồ cho người khác.

Kinh nghiệm và kỹ năng đọc vẫn đang được cải thiện

Chuyên môn tương tác và chuyên môn đóng góp được Dan Davies đề cập cũng rất phù hợp với sự thay đổi này. Model có thể đọc nhiều tài liệu và đưa ra phán đoán chính xác nhưng để hệ thống ổn định vẫn cần có người đọc thông số kỹ thuật, xem kết quả và biết lỗi gì. Mấu chốt ở đây không phải là mọi người nên cạnh tranh bằng hình mẫu để xem ai thông minh hơn mà là mọi người nên tiếp tục đứng ở vị trí xác định ranh giới.

Vấn đề này đơn giản hơn khi nói đến việc phân phối phần mềm. Sau khi Tác nhân tiếp quản, công việc của con người sẽ ít tập trung vào việc thực hiện thủ công mà tập trung nhiều hơn vào phân đoạn nhiệm vụ, xác định ranh giới, thiết kế chấp nhận và xử lý ngoại lệ. Liệu các nhiệm vụ có thể được bàn giao hay không sẽ quyết định rõ ràng liệu việc quản lý bối cảnh, định tuyến mô hình và điều phối công cụ tiếp theo có đáng thực hiện hay không. Nếu thiết bị không rõ ràng thì dù có bao nhiêu lớp cũng chỉ đẩy vấn đề trở lại.

Sau khi đọc những đoạn này trong vài ngày qua, điều đọng lại trong đầu tôi không phải là một tên mô hình nhất định, cũng không phải một khuôn khổ mới, mà là một nhận định đơn giản hơn: điều đầu tiên mà hệ thống Tác nhân cần thắt chặt không phải là khả năng của mô hình, mà là đơn vị công việc. Nếu đơn vị nhỏ hơn, sự chấp nhận chặt chẽ hơn và quyền hạn chặt chẽ hơn, hệ thống sẽ có cơ hội giữ độ phức tạp trong phạm vi có thể kiểm soát được.