Tiêu đề gốc: The Orchestration Tax

Tác giả gốc: Addy Osmani

Biên dịch: Peggy

Lời tòa soạn: Khi các AI Agent ngày càng rẻ và dễ dàng gọi, 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 bao nhiêu Agent nữa, mà là liệu con người có đủ sự tập trung để quản lý, đánh giá và tổng hợp kết quả đầ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 một Agent rất thấp, chỉ cần một câu Prompt hoặc một cú nhấp chuột; nhưng thứ thực sự đắt đỏ lại là các công đoạn 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 code nào có thể được đưa vào nhánh chính. Những công việc này không thể đơn giản song song hóa, mà vẫn phải quay về 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í nhà phát triển như "GIL" trong hệ thống AI Agent, tức là khóa đơn luồng 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 cùng lúc, nhưng ngay khi bước vào giai đoạn đánh giá kiến trúc, xem xét code và hợp nhất xung đột, mọi thứ phải quay lại qua bộ não của nhà phát triển. Do đó, càng nhiều Agent chưa chắc đã đồng nghĩa với năng suất cao hơn, mà có thể chỉ khiến hàng đợi tác vụ cần xem xét dài hơn, đẩy nhà phát triển vào tình trạng chuyển đổi ngữ cảnh thường xuyên hơn và mệt mỏi nhận thức.

Đây cũng là đ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 tế không phải lúc nào cũng giống nhau. Một bảng điều khiển Agent đầy màn hình có thể tạo ra ảo giác "sản xuất cao"; nhưng nếu nhà 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 có thể tích lũy 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ự không bàn 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ự tập trung của con người". Trong kỷ nguyên Agent, năng lực then chốt không chỉ là biết đặt câu hỏi, biết phân công nhiệm vụ, mà là biết nhiệm vụ nào có thể giao cho máy xử lý song song, nhiệm vụ nào phải dành cho con người phán đoán; khi nào nên review hàng loạt, khi nào nên dừng điều phối và tập trung lại vào một vấn đề cốt lõi.

AI đang mở rộng khả năng đồng thời của sản xuất phần mềm, nhưng sự tập trung của con người vẫn là tài nguyên khan hiếm nhất và khó sao chép nhất trong hệ thống. Một quy trình làm việc 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à giống như thiết kế một hệ thống sản xuất, phải thiết kế nghiêm túc kiến trúc tập trung của chính mình.

Hiện tại, việc khởi chạy nhiều AI Agent đã trở nên rất dễ dàng. Nhưng việc có nhiều Agent chạy đồng thời không có nghĩa là "bạn" cũng tăng 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 để định hướng chúng, đánh giá kết quả và hợp nhất các chỉnh sửa cuối cùng vẫn phải đi qua cùng một bộ xử lý tuần tự – đó chính là bạn.

Cái gọi là "thuế điều phối" (orchestration tax), về bản chất, chính là cái giá bạn phải trả khi quên mất điều này. Và giải pháp thực sự duy nhất là bắt đầu thiết kế sự tập trung của chính bạn, giống như cách bạn thiết kế bất kỳ hệ thống đồng thời nào.

Trước đây, tôi đã tham gia một buổi thảo luận bàn tròn tại Google I/O, cùng với Richard Seroter, Aja Hammerly và Ciera Jaspan, nói về diện mạo hiện tại của kỹ thuật phần mềm và cách nó có thể phát triển tiếp theo. Gần cuối buổi, Richard hỏi chúng tôi: Điều duy nhất mà các nhà phát triển nên mang theo và thay đổi sau khi nghe xong là gì?

Tôi đã nói ra một điểm mà tôi đã suy nghĩ nhiều tháng qua: Cảm thấy mình bận rộn hoàn toàn không đồng nghĩa với việc thực sự có output. Bạn có thể chạy 20 Agent cùng lúc và cảm thấy mình bận rộn tột độ. Nhưng điều đó không có nghĩa là bạn đã giao được khối lượng công việc tương ứng với 20 Agent.

Đầu buổi trò chuyện đó, Richard đã đặt tên cho vấn đề này. Anh ấy nói: "Những gì bạn vừa đề cập thực chất là thuế điều phối. Bạn không thể quản lý thành công 20 Agent trong đầu mình."

Anh ấy nói hoàn toàn chính xác. Tôi muốn phân tích khái niệm này một cách đầy đủ hơn, bởi vì đây không phải là vấn đề về kỷ luật, mà là vấn đề về kiến trúc.

Trong buổi thảo luận bàn tròn đó, có một câu tôi gần như nói ra một cách ngẫu nhiên, nhưng sau đó cứ ám ảnh tôi: Chạy nhiều Agent không có nghĩa là trên 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

Có một sự bất đối xứng ẩn trong quy trình làm việc của Agent.

Khởi chạy một Agent rất rẻ. Bạn chỉ cần gõ một phím hoặc viết một Prompt. Nhưng hoàn thành vòng lặp của Agent lại không hề rẻ. Luôn có người phải kiểm tra xem kết quả nó trả về có chính xác không, và phối hợp lại với những nội dung đã bị các Agent khác thay đổ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 bài "Giới hạn Agent song song của bạn", chủ yếu thảo luận về loại lo lắng về môi trường: bạn không biết luồng song song nào đang thất bại âm thầm. Bài viết này muốn nói về cấu trúc đằng sau chi phí này.

Khi bạn bắt đầu xem việc phát triển Agent như một hệ thống đồng thời, bạn sẽ nhận ra rằng bản thân con người chỉ là một thành phần trong hệ thống đó. Một thành phần tuần tự rất chậm.

Bạn chính là tài nguyên đơn luồng đó

Nếu bạn đã từng viết mã đồng thời, thực ra bạn đã có trực giác để hiểu vấn đề này. Chỉ là trước đây bạn đã áp dụng trực giác đó sai chỗ.

Python có Global Interpreter Lock, hay GIL. Bạn có thể tạo bao nhiêu luồng tùy thích, nhưng chỉ một luồng có thể thực thi bytecode Python tại một thời điểm, vì tất cả đều phải giành được khóa này.

Bạn chính là GIL của AI Agent của bạn.

Tất cả chúng đều có thể chạy đồng thời. Nhưng ngay khi công việc của chúng cần hiểu thực sự về 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 giành được khóa này. Và chỉ có một khóa duy nhất, do bạn nắm giữ.

Định luật Amdahl mô tả điều này rất chính xác: giới hạn tăng tốc từ song song hóa phụ thuộc vào phần công việc vẫn phải thực hiện 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ì dù bạn có đầu tư bao nhiêu lõi, cuối cùng bạn cũng sẽ chạ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ỉ làm cho 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 là nút thắt cổ chai sẽ không cải thiện 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 cổ chai.

Thêm Agent tối ưu hóa phần vốn dĩ không phải là ràng buộc. Ràng buộc thực sự là khâu review, và thông lượng của toàn bộ hệ thống chính xác bằng thông lượng của khâu này.

Thuế điều phối (Orchestration Tax) là khoảng cách cấu trúc giữa năng suất sản xuất của Agent và những gì bạn thực sự có thể hợp nhất. Nó xảy ra khi bạn để một tài nguyên đơn luồng quản lý một hệ thống đồng thời.

Cố gắng chịu đựng không giải quyết được giới hạn cấu trúc

Trong buổi tọa đàm đó, 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 mệt mỏi như bây giờ.

Cả hai cảm giác này đều hoàn toàn có thật, và chúng đến từ cùng một nguyên nhân.

Sự mệt mỏi này có một nguồn gốc rất cụ thể: đó là cảm giác khi bạn liên tục ép một bộ xử lý tuần tự lên 100% mà không để lại bất kỳ khoảng trống nào.

Mỗi lần bạn quay lại kiểm tra một Agent đã rời khỏi tầm chú ý của mình, bạn phải trả một khoản chi phí chuyển đổi ngữ cảnh. Bạn phải xóa sạch bộ nhớ, rồi tải lại một bối cảnh khác từ đầu.

CPU có thể làm điều này trong micro giây, dù vậy, các kiến trúc sư vẫn cố gắng tránh chuyển đổi thường xuyên. Còn bạn mất vài phút để hoàn thành, và không bao giờ khôi phục lại ngữ cảnh một cách hoàn hảo.

5 Agent không phải là 1 khối lượng công việc lặp lại 5 lần. Nó là 5 lần tải lại ngữ cảnh kiểu khởi động nguội, cộng với một tiến trình não bộ chạy ngầm liên tục lo lắng xem bây giờ bạn nên kiểm tra Agent nào.

Bạn không thể giải quyết một giới hạn cấu trúc bằng cách "cố gắng hơn". Khoản thuế này luôn phải trả.

Nếu bạn cố gắng chịu đựng, cuối cùng nó sẽ xuất hiện dưới một hình thức khác: hoặc là code review ngày càng hời hợt, hoặc bạn rơi vào trạng thái "đầu hàng nhận thức" – vì việc hình thành phán đoán của riêng mình quá tốn sự chú ý, bạn đơn giản chấp nhận code mà Agent viết ra.

Bạn hoặc chủ động trả khoản thuế này, hoặc để nó từ từ phá hủy sự hiểu biết của bạn về hệ thống của chính mình trong bóng tối.

Thiết kế sự chú ý của bạn như thiết kế một hệ thống

Vì vậy, bạn phải coi 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 các nút thắt cổ chai. 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 Agent dựa trên khả năng review, không phải dựa trên khả năng UI.

Một hệ thống đồng thời tốt sử dụng cơ chế phản áp lực để tránh hàng đợi tăng vô hạn. Nhà sản xuất phải giảm tốc độ để 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 chính xác là số lượng bạn có thể hoàn thành code review một cách nghiêm túc. Đối với hầu hết mọi người, con số này thường chỉ là một chữ số đơn lẻ thấp.

Công cụ AI tất nhiên sẽ sẵn lòng cho bạn khởi động 20 Agent, nhưng đó chỉ là một tính năng UI, không có nghĩa là bạn thực sự có khả năng quản lý chúng.

Phân loại nhiệm vụ.

Khi Richard hỏi tôi cách xử lý việc này, tôi đã đề cập đến phương pháp này. Tôi chia nhiệm vụ thành hai đống.

Đống đầu tiên là những công việc tương đối độc lập, tôi sẵn sàng giao cho các Agent chạy nền trên đám mây. Những nhiệm vụ này có thể thực thi không đồng bộ, thường chỉ cần tôi kiểm tra lần cuối.

Đống thứ hai là những nhiệm vụ phức tạp, bản chất công việc thực sự là phán đoán. Ví dụ như một lỗi kỳ lạ, hoặc một thiết kế kiến trúc.

Sai lầm lớn nhất là cố gắng song song hóa cả loại nhiệm vụ thứ hai. Xử lý song song nhiều nhiệm vụ phức tạp không làm tăng sản lượng của bạn, mà chỉ khiến chiếc khóa đó bị tranh giành liên tục, cuối cùng mọi kết quả đều 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 tốn chi phí rất cao. Ngồi xuống review kết quả của 4 Agent cùng một lúc sẽ rẻ hơn nhiều so với xem cái trước, làm việc khác, rồi khởi động lại để xem cái tiếp theo.

Hãy cho Agent dây cương dài hơn. Để công việc tích lũy một chút, rồi xử lý chúng như một lô.

Chỉ dùng chiếc 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à máy móc có thể tự xác minh. Hãy để Agent viết các bài kiểm tra có thể vượt qua, hoặc tạo ảnh chụp màn hình.

Hãy để chúng tự chứng minh 80% phần nhàm chán nhưng có thể kiểm chứng. Như vậy, sự tập trung khan hiếm của bạn chỉ cần dành cho 20% thực sự cầ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ổ chai cần thời gian tốt nhất của bạn, chứ không phải những mảnh 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à ngừng hoàn toàn việc điều phối: tắt chiếc máy tính đầy Agent, chỉ tập trung suy nghĩ một vấn đề, và giữ chặt chiếc khóa đó trong suốt quá trình.

Đ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 rằng khả năng kiến trúc hiện đã 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, và nhiệm vụ nào quá lớn đối với nó.

Tôi muốn bổ sung thêm một điều: bản thân bạn cũng là một thành phần trong hệ thống này. Sự tập trung 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 âm thầm hạ thấp tiêu chuẩn của bạn.

Bận rộn không đồng nghĩa với 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 hầu như không thể nhận thấy đối với chính bạn.

20 tác nhân đang chạy sẽ mang lại 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 chuyển động. Nhưng cảm giác này đã bị tách rời khỏi việc thực sự hợp nhất mã chất lượng cao vào nhánh chính.

Bạn có thể bận rộn đến mức tối đa, nhưng hầu như không có đầu ra thực sự. Từ góc nhìn trải nghiệm nội bộ, 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.

Không trả "thuế điều phối" sẽ khiến bạn tích lũy cả hai loại nợ này cùng lúc.

Bạn hợp nhất những thứ mà bạn chưa đọc kỹ. Mô hình tinh thần của bạn về cơ sở mã đã hoàn toàn lỗi thời. Những vấn đề này hôm nay không xuất hiện trên bảng điều khiển. Chúng sẽ lộ ra khi hệ thống gặp sự cố trong môi trường sản xuất – lúc đó bạn nhìn vào hệ thống và đột nhiên nhận ra mình không còn biết nó thực sự hoạt động như thế nào nữa.

Vì vậy, kết luận thực sự là: Khởi chạy tác nhân không phải là năng lực. 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 đó chính là sự tập trung của bạn.

Hãy thiết kế nó như cách bạn thiết kế bất kỳ thành phần quan trọng nào phụ thuộc vào môi trường sản xuất.

[Liên kết gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia