Tessl: Ai nên nắm quyền sở hữu 'ngữ cảnh' trong kỷ nguyên AI Agent?

Mọi người thường nói về chuyển đổi tác tử (agentic transformation) như thể phần khó nhất chính là các tác tử. Thực tế không phải vậy. Các tác tử đang tự cải thiện qua từng tháng mà không cần bạn giúp đỡ. Phần thực sự khó khăn nằm ở mọi thứ điều hướng chúng: ngữ cảnh (context), quy trình làm việc (workflows), quy trình vận hành (processes), các thành phần tạo tác (artifacts), và hơn hết là câu hỏi mà hầu như chẳng ai đặt ra một cách rõ ràng: ai là người sở hữu chúng?

Nếu làm sai điều này, bạn sẽ rơi vào một trong hai kiểu thất bại. Hoặc là một nhóm nền tảng trung tâm sở hữu toàn bộ ngữ cảnh và trở thành nút thắt cổ chai mà không ai tin tưởng và mọi người đều tìm cách né tránh; hoặc là tình trạng "mạnh ai nấy làm", nơi mỗi kỹ sư tự xây dựng lại cùng một thiết lập, chỉ khác biệt một chút và kém hiệu quả hơn một chút. Nếu làm đúng, đòn bẩy mang lại sẽ rất lớn, lớn hơn nhiều so với những gì hầu hết các tổ chức nhận ra trước khi họ thực sự trải nghiệm nó.

Đây là bài viết về cách thực hiện điều đó một cách đúng đắn. Nó không tập trung nhiều vào công cụ mà tập trung vào mô hình vận hành xoay quanh các công cụ đó – phần mà theo kinh nghiệm của chúng tôi, thực sự quyết định liệu một quá trình chuyển đổi tác tử sẽ phát triển mạnh mẽ hay bị đình trệ.

Trước tiên, hãy mở rộng khung nhìn: ngữ cảnh, quy trình làm việc, quy trình vận hành, các thành phần tạo tác.

Rất dễ để chỉ tập trung vào "ngữ cảnh", nhưng câu hỏi về quyền sở hữu bao hàm một phạm vi rộng hơn: ngữ cảnh bạn cung cấp cho tác tử, quy trình làm việc mà chúng thực hiện, các quy trình vận hành xoay quanh chúng, và các thành phần tạo tác mà chúng tạo ra cũng như tiêu thụ. Chúng không hoạt động giống nhau, và sự khác biệt đó chính là chìa khóa cho toàn bộ mô hình.

Quy trình làm việc và quy trình vận hành có tính linh hoạt cao. Cách bạn định hình một ticket, cách bạn thực hiện đánh giá, các giai đoạn mà một thay đổi phải trải qua – những thứ này có thể khái quát hóa giữa các nhóm và có thể được chuẩn hóa, chia sẻ mà không gặp nhiều trở ngại. Chúng tương đối dễ di chuyển.

Ngữ cảnh thì khác, và đây là khía cạnh thú vị nhất. Ngữ cảnh là kiến thức chuyên môn đặc thù của một lập trình viên hoặc một nhóm: dịch vụ này thực sự làm gì, tại sao ràng buộc khó chịu này lại tồn tại, thế nào là "tốt" trong trường hợp cụ thể này. Nó không thể khái quát hóa. Và đây chính xác là thứ mà các tác tử sẽ làm sai nếu thiếu nó. Sự kết hợp giữa giá trị cao nhất và khó chia sẻ nhất chính là lý do tại sao ngữ cảnh là thứ bạn cần một mô hình sở hữu rõ ràng nhất, và cũng không phải ngẫu nhiên, đây là thứ mà các nhóm thường để ở trạng thái ngầm định và không có chủ sở hữu. (Việc chia sẻ ngữ cảnh giữa các nhóm là một chủ đề gai góc hơn; chúng tôi cố tình để dành nó cho một dịp khác.)

Chúng tôi đã từng làm điều này trước đây: sự tương đồng với DevOps và SRE.

Nếu tất cả những điều này nghe có vẻ quen thuộc thì đúng là như vậy, chúng ta đã từng trải qua dạng vấn đề này trước đây. Mọi sự thay đổi nền tảng trước đó, từ agile đến DevOps rồi SRE, đều buộc một tổ chức phải trả lời hai câu hỏi tương tự. Nhóm trung tâm nên có quan điểm cứng rắn đến mức nào? Và họ nên làm bao nhiêu phần việc thay cho mọi người so với việc trao quyền để mọi người tự làm?

Lời khuyên mạnh mẽ nhất của chúng tôi là: hãy tuân theo lập trường mà tổ chức của bạn đã áp dụng cho những lần chuyển đổi trước đó. Một tổ chức đã tập trung hóa DevOps mạnh mẽ, với một nhóm nền tảng vững chắc đặt ra các quy tắc, sẽ mong đợi và chấp nhận một chức năng hỗ trợ tác tử trung tâm mạnh mẽ, và sẽ bác bỏ cách tiếp cận "laissez-faire" (để mặc) như một sự thoái thác. Một tổ chức đã đẩy quyền sở hữu xuống các nhóm tự chủ thì cũng nên làm như vậy ở đây, nếu không mọi thứ sẽ trở nên xa lạ và bị lờ đi một cách lặng lẽ. Bạn không lựa chọn trong môi trường chân không; bạn đang lựa chọn trong một nền văn hóa đã có ký ức về cách các quá trình chuyển đổi này diễn ra.

Và tốc độ sẽ thay đổi câu trả lời. Bạn càng cần di chuyển nhanh, bạn càng nên chuẩn hóa trước và mở rộng sau. Bạn không thể chuyển đổi nhanh chóng và tùy chỉnh (bespoke) cùng một lúc, đó là cách khiến bạn bị mắc kẹt. Nếu tốc độ là ưu tiên, hãy chọn một tiêu chuẩn, đưa mọi người vào đó, và giành quyền khác biệt sau này. Nếu sự phù hợp sâu sắc tại địa phương quan trọng hơn tốc độ, bạn có thể cho phép các nhóm định hình mọi thứ ngay từ đầu. Chỉ cần chọn một cách có chủ đích, thay vì khám phá lựa chọn của mình một cách tình cờ.

Mô hình sở hữu.

Quy tắc rõ ràng nhất mà chúng tôi tìm thấy rất đơn giản và nó khớp trực tiếp với khung nhìn ở trên: quyền sở hữu đi theo đơn vị tổ chức.

Dòng kẻ giữ cho toàn bộ hệ thống này lành mạnh là: nhóm hỗ trợ (enablement team) cung cấp công cụ, không phải quyền sở hữu. Nhiệm vụ của họ là giúp những người phù hợp dễ dàng mã hóa, cải thiện và duy trì ngữ cảnh của chính họ, chứ không phải trở thành "cái cổ chai" duy nhất mà mọi thay đổi ngữ cảnh đều phải đi qua. Ngay khi nhóm hỗ trợ sở hữu ngữ cảnh, bạn đã vô tình tái tạo chính cái nút thắt cổ chai mà bạn đang cố gắng thoát khỏi, chỉ là với một cái tên mới.

Kỹ thuật ngữ cảnh (Context engineering) vs. Kỹ thuật vòng lặp (Loop engineering).

Cần tách biệt hai thuật ngữ thường bị gộp chung này, vì chúng được sở hữu và vận hành theo những cách khác nhau.

Kỹ thuật ngữ cảnh là công việc tối ưu hóa chính ngữ cảnh đó: markdown, các trình xác thực (verifiers), các hook, quy tắc linting, mọi thứ trong repo điều hướng một tác tử trong một lần chạy cụ thể. Đó là công việc mang tính nội bộ, cục bộ và thuộc về những người có kiến thức chuyên môn.

Kỹ thuật vòng lặp thì rộng hơn. Nó bao gồm các tác tử bảo trì và cải tiến nhà máy tự động giúp toàn bộ hệ thống tốt hơn theo thời gian, vòng lặp bên trong của một lần chạy, vòng lặp giữa phân tích hành vi tác tử qua nhiều lần chạy và đề xuất cải tiến, và vòng lặp bên ngoài đặt câu hỏi liệu tính năng được triển khai có thực sự thúc đẩy chỉ số kinh doanh mà nó nhắm tới hay không.

Lý do sự phân biệt này quan trọng đối với quyền sở hữu: các vòng lặp thường có thể được vận hành tập trung hơn, nhưng ngữ cảnh bên dưới chúng thì thường không thể. Vì vậy, khi thiết kế mô hình vận hành, đừng vô tình giao thứ mang tính cục bộ sâu sắc (ngữ cảnh) cho nhóm được thiết lập để chạy thứ mang tính trung tâm (các vòng lặp). Đó là những công việc khác nhau với những chủ sở hữu tự nhiên khác nhau.

Nhóm hỗ trợ thực sự làm gì?

Nếu nhóm hỗ trợ không sở hữu ngữ cảnh, thật công bằng khi hỏi họ tồn tại để làm gì. Hóa ra là rất nhiều, đó chỉ là đòn bẩy thay vì quyền sở hữu.

Một nhóm hỗ trợ tác tử (hoặc nền tảng) tốt sẽ xây dựng "con đường trải nhựa" (paved road): công cụ giúp mọi người khác dễ dàng mã hóa và cải thiện ngữ cảnh của riêng họ. Đó là nơi đăng ký (registry) lưu trữ và quản lý phiên bản cho các kỹ năng và lăng kính, nền tảng đánh giá (eval platform) cho phép mọi người chứng minh rằng một thay đổi đối với ngữ cảnh của họ thực sự hữu ích, các vòng lặp đánh giá và bảo trì vận hành trên toàn tổ chức, và công cụ chỉnh sửa giúp các thay đổi ngữ cảnh trở nên ít ma sát hơn đối với những người không phải chuyên gia nền tảng. Đó là tư thế "mua để xây": cung cấp cho các nhóm cơ sở hạ tầng chung để họ không phải xây dựng lại hệ thống ống nước, và để họ tự mô hình hóa góc thế giới của riêng mình trên nền tảng đó.

Sự tương tự tốt nhất là thứ chúng ta đã tin tưởng từ phần mềm thông thường: một nhóm hỗ trợ đối với một nhà máy cũng giống như trình biên dịch, trình linter và nền tảng kiểm thử đối với việc viết mã. Không ai tranh cãi rằng trình biên dịch nên sở hữu logic kinh doanh của bạn. Đó là bộ máy đáng tin cậy bên dưới, còn logic của bạn, ngữ cảnh của bạn, nằm ở trên và do bạn sở hữu. Hãy đẩy "con đường trải nhựa" đi đủ xa và bạn sẽ có các mặc định hợp lý cho một nhóm chỉ muốn nhấp vào "tiếp theo", trong khi vẫn cho phép một nhóm có quan điểm riêng được tách ra và cấu trúc mọi thứ theo cách của họ mà không cần xây dựng lại các nền tảng chung.

Cụ thể, cách tiếp cận theo từng cấp độ diễn ra như sau trong thực tế. Một nhóm hỗ trợ triển khai công cụ và thực hiện trình diễn cho một nhóm đã thấy được giá trị. Đối với nhóm thứ hai đang quan tâm nhưng bị quá tải, họ tự thực hiện bước đầu tiên về ngữ cảnh, soạn thảo các kỹ năng, kết nối các trình xác thực, nhưng không có gì được hợp nhất cho đến khi nhóm đó xem xét và phê duyệt, vì vậy quyền sở hữu không bao giờ rời khỏi các chuyên gia trong lĩnh vực. Chỉ đối với một nhóm hoàn toàn bị đình trệ, sau khi giao tiếp thực sự không mang lại kết quả, họ mới can thiệp và thực hiện thay đổi trực tiếp, và ngay cả khi đó họ coi đó là sự can thiệp tạm thời, không phải là chuyển giao quyền sở hữu. Cùng công cụ, cùng con đường, ba mức độ thúc đẩy khác nhau tùy thuộc vào vị trí thực tế của mỗi nhóm.

Căng thẳng mà không ai có thể thoát khỏi.

Có một sự đánh đổi thực sự, không thể loại bỏ ở trung tâm của tất cả những điều này, và việc giả vờ như không có chính là cách các chương trình này thất bại.

Tự động hóa quá nhiều, làm tất cả mọi thứ cho mọi người, thì mức độ áp dụng tăng lên nhưng sự hiểu biết và quyền sở hữu thực sự lại giảm xuống. Bạn sẽ kết thúc với các kỹ sư vận hành trên ngữ cảnh mà họ không hiểu và không thể duy trì, điều này có vẻ như là tiến bộ cho đến khi nó không còn như vậy nữa. Không làm gì cả, để mọi kỹ sư tự xoay xở, và họ sẽ bị nhấn chìm, vì đây là một việc đòi hỏi khắt khe chồng chất lên mọi thứ khác mà họ đang quản lý. Không thái cực nào hiệu quả cả.

Cách vượt qua là đi theo từng cấp độ, và đó là cùng một thang leo mà các nhóm hỗ trợ tốt luôn sử dụng, chỉ là chủ đề thì mới mẻ:

Đo lường một cách nhẹ nhàng.

Có một sự cám dỗ mạnh mẽ là sử dụng các chỉ số thực thi (enforcement metrics), và rất đáng để chống lại điều đó. Bản năng tốt hơn là theo dõi thứ gì đó như hoạt động kỹ thuật ngữ cảnh trên mỗi kỹ sư, không phải như một cây gậy, mà là một cách để nhận ra ai có thể đang gặp khó khăn và bắt đầu một cuộc trò chuyện thay vì đưa ra mệnh lệnh. Hãy coi đó là đo lường từ xa (telemetry) của kỹ thuật vòng lặp: nó thúc đẩy sự tương tác giữa người với người – thứ thực sự làm mọi thứ chuyển động – thay vì tạo ra sự tuân thủ giả tạo. Khoảnh khắc một chỉ số như vậy trở thành mục tiêu cứng, quyền sở hữu mà bạn đang cố gắng vun đắp sẽ lặng lẽ tan biến, và bạn quay lại với việc mọi người chơi trò "đối phó với con số" thay vì quan tâm đến ngữ cảnh của họ.

Ba điều cần rút ra.

Các tác tử sẽ tiếp tục trở nên tốt hơn cho dù bạn có giải quyết bất kỳ điều nào trong số này hay không. Việc đó có làm cho tổ chức của bạn nhanh hơn một cách đáng kể, hay chỉ trở nên lộn xộn hơn ở tốc độ cao hơn, gần như hoàn toàn phụ thuộc vào một câu hỏi nghe có vẻ hành chính nhưng thực tế lại mang tính chiến lược: ai sở hữu ngữ cảnh?