Biên tập viên: Khi AI Agent ngày càng trở nên rẻ hơn và dễ gọi hơn, phát triển phần mềm đang bước vào một giai đoạn mới: vấn đề không còn là có thể khởi động thêm Agent hay không, mà là liệu con người có còn đủ sự chú ý để quản lý, đánh giá và hợp nhất đầu ra của chúng hay không.
Bài viết này đưa ra một khái niệm rất gợi mở - "thuế điều phối". Chi phí khởi động Agent rất thấp, chỉ cần một câu lệnh Prompt hoặc một cú nhấp chuột; nhưng phần thực sự đắt đỏ là các khâu tiếp theo: kiểm tra kết quả có chính xác không, hiểu tác động của nó đến kiến trúc hệ thống, xử lý xung đột giữa các Agent khác nhau, và cuối cùng quyết định đoạn mã nào có thể được tích hợp vào nhánh chính. Những công việc này không thể được song song hóa một cách đơn giản, mà vẫn phải quay lại một tài nguyên tuần tự duy nhất: khả năng phán đoán của con người.
Tác giả ví người phát triển như "GIL" trong hệ thống AI Agent, tức là khóa luồng đơn giới hạn thông lượng cuối cùng của hệ thống đồng thời. Nhiều Agent có thể chạy đồng thời, nhưng một khi bước vào giai đoạn đánh giá kiến trúc, xem xét mã và hợp nhất xung đột, chúng nhất định phải quay lại bộ não của người phát triển. Do đó, càng nhiều Agent không nhất thiết có nghĩa là đầu ra càng cao, mà cũng có thể chỉ khiến hàng đợi nhiệm vụ chờ xem xét dài hơn, khiến người phát triển rơi vào tình trạng chuyển đổi ngữ cảnh và mệt mỏi nhận thức thường xuyên hơn.
Đây cũng là một điểm dễ bị bỏ qua trong cơn sốt công cụ lập trình AI hiện nay: cảm giác hiệu quả và năng suất thực sự không phải lúc nào cũng là một. Một bảng điều khiển AI Agent chạy đầy màn hình sẽ tạo ra ảo giác về "năng suất cao"; nhưng nếu người phát triển không thực sự hiểu, xem xét và tích hợp những thay đổi này, cuối cùng hệ thống tích lũy có thể không phải là năng suất, mà là nợ kỹ thuật và nợ nhận thức.
Vì vậy, bài viết này thực sự bàn luận không phải về "cách sử dụng nhiều Agent hơn", mà là "cách thiết kế lại quy trình làm việc xoay quanh sự chú ý của con người". Trong thời đại Agent, khả năng then chốt không chỉ là biết đặt câu hỏi, biết phân phối nhiệm vụ, mà còn là biết những nhiệm vụ nào có thể giao cho máy móc xử lý song song, những nhiệm vụ nào phải dành cho khả năng phán đoán của con người; khi nào nên xem xét hàng loạt, khi nào nên ngừng điều phối, tập trung trở lại vào một vấn đề cốt lõi.
AI đang mở rộng khả năng xử lý đồng thời của sản xuất phần mềm, nhưng sự chú ý của con người vẫn là tài nguyên khan hiếm nhất và không thể sao chép được trong hệ thống. Quy trình làm việc với Agent thực sự trưởng thành, không phải là ném tất cả nhiệm vụ cho máy móc, mà là như thiết kế hệ thống sản xuất, thiết kế nghiêm túc kiến trúc sự chú ý của chính mình.
Dưới đây là bài viết gốc:
Hiện nay, việc khởi động thêm AI Agent đã trở nên rất dễ dàng. Nhưng có nhiều Agent hơn chạy đồng thời không có nghĩa là "bạn" cũng nhiều lên. Băng thông nhận thức của bạn không thể song song hóa. Tất cả khả năng phán đoán thực sự dùng để hướng dẫn chúng, đánh giá kết quả, hợp nhất sửa đổi, cuối cùng vẫn phải đi qua một bộ xử lý tuần tự duy nhất – chính là bản thân bạn.
Cái gọi là "thuế điều phối", về bản chất là cái giá bạn phải trả khi quên điều này. Và giải pháp thực sự duy nhất, là như thiết kế bất kỳ hệ thống đồng thời nào, bắt đầu thiết kế sự chú ý của chính bạn.
Trước đây, tôi đã tham gia một cuộc thảo luận bàn tròn tại Google I/O, cùng với Richard Seroter, Aja Hammerly, Ciera Jaspan trò chuyện về phần mềm hiện nay như thế nào, và nó có thể tiến hóa ra sao tiếp theo. Gần cuối cuộc trò chuyện, Richard hỏi chúng tôi: Sau khi nghe xong, điều mà người phát triển nên nhớ và thay đổi nhất là gì?
Tôi đã nói ra một điểm mà tôi đã suy nghĩ đi suy nghĩ lại suốt mấy tháng qua: Cảm thấy bận rộn, tuyệt đối không đồng nghĩa với việc thực sự có đầu ra. Bạn có thể đồng thời chạy 20 Agent, và cảm thấy mình bận tối mắt tối mũi. Nhưng điều đó không có nghĩa là bạn đã giao một khối lượng công việc tương ứng với 20 Agent.
Trong cuộc đối thoại đó sớm hơn, Richard đã đặt tên cho vấn đề này. Anh ấy nói: "Điều bạn vừa nói, thực chất chính là thuế điều phối. Bạn không thể quản lý thành công 20 Agent trong đầu của mình."
Anh ấy nói hoàn toàn đúng. Tôi muốn chia nhỏ khái niệm này ra để nói đầy đủ hơn, bởi vì đây không phải là vấn đề tự kỷ luật, mà là một vấn đề kiến trúc.
Trong cuộc thảo luận bàn tròn đó có một câu tôi gần như nói bâng quơ, sau đó cứ đeo bám trong đầu tôi: Chạy nhiều Agent, không có nghĩa là thế giới có thêm một bạn.
Sự bất đối xứng mà mọi người không tính đến
Trong quy trình làm việc với Agent, tồn tại một sự bất đối xứng ẩn giấu.
Khởi động một Agent rất rẻ. Bạn chỉ cần gõ một phím, hoặc viết một câu lệnh Prompt. Nhưng hoàn thành vòng lặp của một Agent lại không hề rẻ chút nào. Cuối cùng phải có người kiểm tra kết quả nó trả về có đúng không, và phối hợp lại nó với những nội dung mà các Agent khác đã sửa đổi.
Người đó chính là bạn. Và bạn chỉ có một.
Tháng trước, tôi đã viết về một phần của vấn đề này trong "Giới hạn Agent song song của bạn", chủ yếu thảo luận về loại lo lắng kiểu môi trường đó: Bạn không biết luồng song song nào đang âm thầm thất bại. Bài viết này muốn nói về cấu trúc đằng sau chi phí đó.
Khi bạn bắt đầu coi phát triển Agent như một hệ thống đồng thời, bạn sẽ nhận ra, bản thân con người chỉ là một thành phần trong hệ thống này. Một thành phần tuần tự rất chậm.
Bạn chính là tài nguyên luồng đơn đó
Nếu bạn đã từng viết mã đồng thời, bạn thực sự đã có trực giác để hiểu vấn đề này. Chỉ là trước đây bạn đã dùng trực giác đó sai chỗ.
Python có khóa trình thông dịch toàn cục, tức là GIL. Bạn có thể tạo bao nhiêu luồng tùy thích, nhưng chỉ có một luồng có thể thực thi mã byte Python tại một thời điểm, bởi vì tất cả chúng đều phải lấy được khóa này trước.
Bạn là GIL của AI Agent của bạn.
Chúng đều có thể chạy đồng thời. Nhưng miễn là công việc của chúng cần thực sự hiểu kiến trúc hệ thống, hoặc cần giải quyết xung đột hợp nhất, chúng phải lấy được khóa này trước. Và khóa này chỉ có một, do bạn nắm giữ.
Định luật Amdahl nói điều này rất chính xác: Giới hạn trên của tốc độ tăng do song song hóa mang lại, phụ thuộc vào phần công việc vẫn phải hoàn thành một cách tuần tự. Nếu quy trình của bạn có một phần lớn không thể song song hóa, thì cho dù bạn đổ bao nhiêu lõi vào, cuối cùng cũng sẽ đâm vào một giới hạn cứng.
Trong phát triển Agent, phần tuần tự này chính là khả năng phán đoán.
Khởi động 8 Agent sẽ không tăng tốc thời gian phán đoán của bạn. Nó chỉ khiến hàng đợi chờ bạn xử lý dài hơn.
Đây là một sự thật rất cũ trong kỹ thuật hiệu suất, nhưng nhiều người vẫn ngạc nhiên về nó: Tối ưu hóa phần không phải nút thắt, sẽ không nâng cao thông lượng tổng thể. Bạn chỉ đang chất thêm công việc chưa hoàn thành trước nút thắt.
Tăng Agent tối ưu hóa phần vốn không phải là ràng buộc. Ràng buộc thực sự là khâu xem xét, và thông lượng của toàn hệ thống, chính xác bằng thông lượng của khâu này.
Thuế điều phối, chính là khoảng cách cấu trúc giữa năng lực sản xuất của Agent và nội dung bạn thực sự có thể hợp nhất. Nó xảy ra khi bạn để một tài nguyên luồng đơn quản lý một hệ thống đồng thời.
Chống cự không giải quyết được giới hạn cấu trúc
Trong cuộc thảo luận bàn tròn đó, tôi đã nói một câu: Tôi chưa bao giờ cảm thấy công cụ của mình hiệu quả như bây giờ, nhưng tôi cũng chưa bao giờ cảm thấy kiệt sức như bây giờ.
Cả hai cảm nhận này đều hoàn toàn chân thực, và chúng đến từ cùng một nguyên nhân.
Sự kiệt sức này có một nguồn gốc rất cụ thể: Đó chính là cảm giác khi bạn liên tục đẩy một bộ xử lý tuần tự lên 100%, và không cho bất kỳ dung lượng dư nào.
Mỗi lần bạn quay lại xem một Agent đã rời khỏi phạm vi chú ý của bạn, bạn phải trả một lần chi phí chuyển đổi ngữ cảnh. Bạn phải xóa sạch bộ não, sau đó tải lại một bối cảnh khác từ đầu.
CPU có thể hoàn thành việc này trong micro giây, ngay cả như vậy, kiến trúc sư vẫn sẽ cố gắng tránh chuyển đổi thường xuyên. Còn bạn phải mất vài phút mới hoàn thành, và không bao giờ có thể khôi phục hoàn hảo ngữ cảnh.
5 Agent không phải là 1 lần khối lượng công việc lặp lại 5 lần. Đó là 5 lần tải lại ngữ cảnh kiểu khởi động lạnh, cộng thêm một quá trình bộ não chạy nền liên tục, liên tục lo lắng không biết bây giờ nên đi kiểm tra Agent nào.
Bạn không thể dựa vào "cố gắng hơn" để giải quyết một hạn chế cấu trúc. Khoản thuế này luôn phải trả.
Nếu bạn cố gắng chống cự, cuối cùng nó sẽ xuất hiện dưới một hình thức khác: hoặc là việc xem xét mã ngày càng trở nên hời hợt, hoặc là bạn rơi vào trạng thái "đầu hàng nhận thức" – bởi vì hình thành phán đoán của riêng mình quá tiêu hao sự chú ý, bạn đơn giản chấp nhận mã do Agent viết ra.
Bạn hoặc là chủ động trả khoản thuế này, hoặc là để nó từ từ phá hủy sự hiểu biết của bạn về hệ thống của mình trong bóng tối.
Thiết kế sự chú ý của bạn như thiết kế hệ thống
Vì vậy, bạn phải đối xử với sự chú ý của mình như một tài nguyên tuần tự khan hiếm.
Bạn sẽ không thiết kế một hệ thống phân tán mà hoàn toàn không xem xét nút thắt. Vậy thì, hãy dành cho bộ não của bạn sự tôn trọng tương tự.
Dưới đây là một số phương pháp thực sự hiệu quả với tôi:
Mở rộng đội ngũ Agent theo khả năng review, chứ không phải theo khả năng UI.
Một hệ thống đồng thời tốt sẽ sử dụng cơ chế phản áp, tránh hàng đợi phát triển vô hạn. Nhà sản xuất phải làm chậm lại, để phù hợp với khả năng xử lý của người tiêu dùng.
Số lượng Agent của bạn là nhà sản xuất, khả năng review của bạn là người tiêu dùng. Số lượng Agent song song đúng, nên là số lượng bạn có thể hoàn thành việc xem xét mã một cách nghiêm túc. Với hầu hết mọi người, điều này thường chỉ là một con số một chữ số rất thấp.
Công cụ AI tất nhiên sẽ rất vui lòng để bạn khởi động 20 Agent, nhưng đó chỉ là một tính năng UI, không đại diện cho khả năng thực sự quản lý chúng của bạn.
Phân loại nhiệm vụ.
Khi Richard hỏi tôi xử lý việc này như thế nào, tôi đã đề cập đến phương pháp này. Tôi sẽ chia nhiệm vụ thành hai nhóm.
Nhóm đầu tiên, là công việc tương đối độc lập, tôi sẵn sàng giao cho Agent chạy nền trên đám mây. Những nhiệm vụ này có thể thực hiện không đồng bộ, thường chỉ cần tôi xem xét một lần ở khâu cuối.
Nhóm thứ hai, là nhiệm vụ phức tạp, công việc thực sự bản thân nó là phán đoán. Ví dụ một lỗi rất kỳ lạ, hoặc một thiết kế kiến trúc.
Sai lầm lớn nhất, chính là cố gắng song song hóa nhiệm vụ loại thứ hai. Xử lý song song nhiều nhiệm vụ phức tạp, sẽ không mở rộng đầu ra của bạn, mà chỉ khiến khóa đó bị tranh giành liên tục, cuối cùng tất cả kết quả đều sẽ trở nên tồi tệ hơn.
Review hàng loạt.
Mỗi lần chuyển đổi ngữ cảnh đều khiến bạn trả giá rất cao. Ngồi xuống review kết quả của 4 Agent một lần, rẻ hơn nhiều so với việc xem một cái, đi làm việc khác, rồi khởi động lạnh trở lại tiếp tục xem một cái khác.
Cho Agent một sợi dây dẫn dài hơn. Để công việc tích lũy một chút, sau đó xử lý chúng như một đợt.
Chỉ dùng khóa này cho việc phán đoán.
Đừng lãng phí bộ não của bạn vào những việc máy móc có thể tự kiểm chứng. Hãy để Agent viết ra các bài kiểm tra có thể vượt qua, hoặc tạo ảnh chụp màn hình.
Để chúng tự chứng minh phần 80% nhàm chán nhưng có thể kiểm chứng đó. Như vậy, sự chú ý khan hiếm của bạn chỉ cần dành cho phần 20% thực sự cần đến phán đoán của con người.
Bảo vệ thời gian tuần tự của bạn.
Nút thắt cần thời gian tốt nhất của bạn, chứ không phải thời gian vụn vặt còn lại giữa các lần kiểm tra Agent.
Đôi khi, hành động có đòn bẩy cao nhất lại là hoàn toàn dừng việc điều phối: tắt cái máy tính đầy Agent đó, chỉ tập trung suy nghĩ về một vấn đề, và trong suốt quá trình đó nắm chắc khóa đó.
Điều phối không phải là công việc thực sự. Nó chỉ là chi phí phát sinh xung quanh công việc.
Aja chỉ ra, khả năng kiến trúc hiện nay đã trở thành kỹ năng cấp bách nhất: Bạn cần biết nhiệm vụ nào phù hợp để đưa vào một Agent, nhiệm vụ nào thì quá lớn với nó.
Tôi còn muốn bổ sung thêm: Bản thân bạn cũng là một thành phần trong hệ thống này. Sự chú ý của bạn có một thông lượng tuần tự đã biết, rất thấp. Hệ thống hoặc là tôn trọng con số này, hoặc sẽ vượt qua nó bằng cách giảm tiêu chuẩn của bạn một cách lén lút.
Bận rộn không bằng năng suất cao
Điều này rất quan trọng, bởi vì kiểu thất bại này gần như là vô hình đối với bản thân bạn.
20 Agent đang chạy sẽ cho bạn cảm giác "năng suất bùng nổ". Bảng điều khiển đầy ắp, mọi thứ đều đang chuyển động. Nhưng cảm giác này và việc thực sự hợp nhất mã chất lượng cao vào nhánh chính, đã không còn liên kết với nhau.
Bạn có thể bận rộn đến giới hạn, nhưng hầu như không có đầu ra thực sự. Xét từ trải nghiệm bên trong, hai điều này gần như giống hệt nhau.
Ciera đã đề cập đến nghiên cứu của Margaret-Anne Storey về nợ. Chúng tôi đã nói về nợ kỹ thuật, và cũng nói về nợ nhận thức.
Thuế điều phối không được thanh toán, sẽ khiến bạn đồng thời tích lũy cả hai loại nợ này.
Bạn đã hợp nhất những thứ mình chưa đọc kỹ. Mô hình tinh thần của bạn về kho mã đã hoàn toàn lỗi thời. Những vấn đề này hôm nay sẽ không xuất hiện trên bảng điều khiển. Chúng sẽ xuất hiện khi môi trường sản xuất gặp sự cố – lúc đó bạn nhìn hệ thống, đột nhiên nhận ra mình đã không biết nó thực sự chạy như thế nào.
Vì vậy, kết luận thực sự là: Khởi động Agent không phải là năng lực. Bất kỳ ai cũng có thể chạy 20 cái.
Năng lực thực sự, là thiết kế hệ thống xoay quanh tài nguyên tuần tự không thể sao chép, không thể song song hóa đó.
Tài nguyên này, chính là sự chú ý của bạn.
Hãy thiết kế nó như thiết kế bất kỳ thành phần then chốt nào mà môi trường sản xuất phụ thuộc vào.







