Beyond the Harness: A Journey Towards Adaptive Engineering

1. Một bác sĩ nói về tương lai của AI engineering

Rajiv mở đầu bằng việc giới thiệu bản thân: anh là một bác sĩ đang hành nghề tại London, và mấy năm gần đây làm thêm AI engineering. Thứ anh quan tâm nhất là ứng dụng trong thế giới thật, và cái mà anh gọi là tương lai: sự cộng tác multi-agent, multi-human, multi-institutional, tức nhiều agent, nhiều con người và nhiều tổ chức cùng làm việc với nhau. Anh theo đuổi hướng này qua một công ty tên là Annicha Labs.

Tiền đề của cả talk là giới thiệu một triết lý thiết kế mới cho tương lai của AI engineering: đi qua khỏi harness, hay chính xác hơn là đi qua khỏi một harness cố định, tĩnh, để tiến tới cái anh gọi là adaptive engineering.

Anh nói thẳng rằng slide thứ hai tóm tắt toàn bộ bài nói. Nó bắt đầu từ paradigm AI engineering hiện tại: dùng fixed harness để lái agent. Chúng ta hoặc dùng, hoặc tự build một harness có sẵn như Pi, Claude Code, Cursor, Codex, gì cũng được, và làm việc đó trước runtime. Harness ấy giữ khá ổn định suốt quá trình engineering, và phần lớn bị ràng buộc bởi role, tool và thứ tự công việc cố định. Những thứ đó ta có thể chỉnh, nhưng là chỉnh trước, ở đầu quá trình. Kết quả là công việc rất đáng tin cậy và ngăn nắp, và cách này rất tốt cho phần lớn các bài toán và ý tưởng engineering. Vai trò của một AI engineer lúc này vì vậy là: dùng harness và steer agent.

Nhưng tương lai sẽ khác, theo ít nhất hai cách. Thứ nhất, model sẽ mạnh tới mức các fixed harness hiện có liên tục lỗi thời. Thứ hai, sẽ có một sự tiếp xúc rất lớn với thế giới thật. Hiện nay phần lớn AI engineering là phần mềm, nằm sau một cái màn hình. Nhưng khi model mạnh hơn, chúng ta sẽ chạm vào thế giới thật, và anh cho rằng đó mới là nơi có những thách thức thật sự. Thế giới thật thì động và bừa bộn: đầy multi-agent, multi-human, xuyên tổ chức, và còn chạm vào cả thế giới vật lý. Điều đó có nghĩa là một fixed harness khá giòn (brittle).

Đó là lúc bước vào khái niệm mà anh đặt tên là adaptive engineering: bạn để cho harness tự nảy sinh và thích nghi ngay giữa quá trình engineering, để nó tìm ra vị trí và cấu trúc tối ưu nhất. Vai trò của engineer khi đó là thiết kế một số constraint, giống như luật chơi, và để cho harness nảy sinh, ổn định, thay đổi, rồi cuối cùng tan đi, trong suốt runtime của quá trình engineering.

2. Paradigm hiện tại: harness engineering

Trước hết, anh nhìn vào paradigm hiện tại. Về cơ bản, harness là phương tiện chính để dẫn dắt một LLM, thứ vốn thường stateless, và biến nó thành một thứ khá hữu dụng.

Harness có vài thành phần, anh không đi vào chi tiết. Có system prompt, do nhà cung cấp harness đặt ra, nên người dùng không sửa được; nó nói cho harness biết được làm gì và không được làm gì. Có các file AGENTS.md, hay CLAUDE.md nếu bạn dùng Claude Code, được nạp vào mọi context window ở đầu mỗi session. Có tool calling.

Rồi tới sự ra đời của agent: những thực thể chuyên biệt đã được "đóng harness", được trao những năng lực riêng, và nhờ đó phân biệt được với các agent khác. Các năng lực này thường hiện ra dưới dạng các skill cụ thể: role, typology, capability, rule. Nhờ vậy agent tạo ra những output có mục tiêu và được định rõ, dù đó là code, tài liệu, issue hay handoff.

Gần đây nhất, chúng ta còn thấy sự ra đời của các loop. Loop engineering đã thành một thứ có tên tuổi. Cuối cùng ta đạt được một outcome nào đó, một feature, một vấn đề được giải, và cuối cùng được một con người review.

Điều bạn thấy ở đây là: trước khi chạy quá trình engineering, toàn bộ harness đã được định sẵn, hay được engineer từ trước. Đó chính là harness engineering. Và nó đã cực kỳ hiệu quả trong việc khai thác tối đa các model mới nhất.

3. Harness là gì, và vì sao có hàng trăm loại

Lùi lại một bước để định nghĩa chính xác harness là gì. Về bản chất, model là động cơ, còn harness là mọi thứ được xây quanh để động cơ đó trở nên hữu dụng.

Có rất nhiều loại harness, thực ra là hàng trăm, nhưng phổ biến nhất có thể kể: CLI coding như Claude Code, Codex, Pi; IDE như Cursor; multi-agent orchestration qua LangChain; và những thứ như Hermes, Cline và Goose.

Chúng khác nhau, thứ nhất, ở các thuộc tính và cách chúng được cấu hình. Nhưng quan trọng hơn, thứ hai, chúng khác nhau ở triết lý thiết kế và engineering mà mỗi cái tin vào. Điều làm chúng tuyệt vời và khác biệt là chúng opinionated, ít hoặc nhiều, và vì thế phục vụ những use case khác nhau. Tuỳ tính khí của bạn khi làm engineer, bạn sẽ chọn cái này thay vì cái kia.

4. Mọi thứ được định sẵn: ba lợi ích và Taylorism cho AI

Nhưng điểm chung ở tất cả các harness này là mọi thứ đều được định nghĩa trước. Tất nhiên bạn có thể tuỳ biến chúng. Ví dụ Pi Agent là loại tối giản và có khả năng mở rộng tối đa. Nhưng mọi thứ vẫn được định trước: role, output cố định, protocol về thứ tự công việc, cách memory được tạo ra.

Anh muốn nói thật rõ chỗ này: anh không có ý rằng bạn không thể tuỳ biến harness. Tất nhiên là có thể. Nhưng việc tuỳ biến diễn ra trước runtime của engineering, chứ không phải giữa chừng, và phần lớn do chính con người chúng ta điều khiển.

Với một người như anh, bắt đầu làm AI engineering khoảng hai năm trước, đây có lẽ là phương pháp mạnh nhất và dễ đoán nhất. Nó có ba lợi ích:

• Đáng tin cậy: cùng một input dẫn tới một tập output tương tự. Tất nhiên vẫn có biến thiên.
• Audit được: bạn kiểm tra được chính xác cái gì đã thay đổi và khi nào.
• Nhân quả tuyến tính: nếu có gì hỏng, bạn lần ngược được về tận nguồn.

Nhưng đây giống một dây chuyền nhà máy. Hãy nghĩ tới Taylorism áp vào AI. Cũng như một dây chuyền lắp ráp, mọi trạm đều được engineer từ trước. Mỗi agent có một việc, một vị trí cố định, một thứ tự, và có thể là một handoff đã định sẵn cho agent tiếp theo.

Rõ ràng có những ứng dụng tuyệt vời cho cách này. Factory engineering cho bạn độ chính xác, tốc độ, khả năng tái lập, và hành vi có thể chứng nhận được. Nó thật sự toả sáng trong những hệ đóng, tất định, nơi bạn có một sản phẩm, một bài toán đã định nghĩa rõ, bạn biết loại feature mình muốn build, biết loại giải pháp mình cần.

5. Cái giá của độ tin cậy: trần novelty và brittleness

Nhưng có một cái bẫy, và đó là một trade-off thật: độ tin cậy ấy không miễn phí. Bạn mua nó bằng cách đè nén variance, thứ mà anh cho rằng novelty, cái mới, cần có. Tính tất định và emergence kéo về hai hướng ngược nhau.

Đây là chỗ phải chuyển sang thế giới thật. Trong các tình huống đời thật, khi việc AI xử lý các kịch bản thật trở thành bình thường, với nhiều agent, nhiều người, nhiều tổ chức tương tác và còn chạm vào thế giới vật lý, sẽ có một trần cứng về novelty. Vì thế giới thật bừa bộn và liên tục thay đổi, nên một fixed harness bắt đầu đổ vỡ.

Như anh đã nói, trần novelty tồn tại vì độ tin cậy của fixed harness dựa trên việc đè nén variance. Thêm vào đó, model sẽ tiếp tục tăng tốc. Hôm nay bạn có thể build một harness cẩn thận, hoặc dùng một cái có sẵn, nhưng nó có thể trở nên vô nghĩa ngay tháng sau: model giỏi lên tới mức không còn cần thứ scaffolding đó nữa.

Từ đó dẫn tới cả một thế khó về brittleness: mỗi tình huống bạn không lường trước đều cần một con người vá lại harness. Harness càng gặp nhiều thế giới thật, bạn càng gắn thêm nhiều rule, và rốt cuộc harness trở nên phức tạp hơn cả chính bài toán mà bạn cần giải.

Nếu có một takeaway ở phần này thì đó là: phương pháp nhà máy là câu trả lời đúng cho một bài toán cố định, và là câu trả lời sai cho một bài toán đang chuyển động.

6. Thế giới thật làm bằng gì: hai paradigm

Vậy hãy xem xét thật kỹ thế giới thật là gì, và anh báo trước sẽ đi theo một lối hơi triết học. Như đã nói, các hệ agentic rồi sẽ va chạm với thế giới thật, và điều đó đặt ra một câu hỏi: thế giới thật thực ra được làm bằng gì? Có hai cách trả lời.

Paradigm thứ nhất là góc nhìn reductionist hay analytical, thứ mà chúng ta đều rất quen. Nó nói: để hiểu cái toàn thể, một bài toán lớn, một hệ thống, hay một thứ lớn như một tổ chức, ta phải tháo nó ra và nghiên cứu từng phần riêng lẻ. Thế giới, theo cách nhìn này, gồm toàn những bộ phận riêng lẻ, là những thứ ổn định, còn thay đổi chỉ là điều thỉnh thoảng xảy ra với những thứ ổn định đó. Quan hệ giữa các thứ là thứ yếu, là chuyện tính sau. Đây chính là siêu hình học của nhà máy, và của gần như mọi phần mềm chúng ta build: làm ra các component, nối chúng lại, và có sản phẩm.

Paradigm thứ hai là góc nhìn systems hay relational. Nó rời trọng tâm khỏi việc có những thứ hay component tách biệt, và đặt cái mà anh gọi là trọng tâm bản thể học (ontological emphasis) lên quan hệ giữa các thứ. Nó đảo ngược thứ tự: thế giới thật không hề được làm bằng các thứ. Nó được làm bằng các quá trình và quan hệ, và chúng có trước.

Cái chúng ta gọi là một thứ ổn định thực ra chỉ là một pattern chậm trong một dòng chảy liên tục. Hãy nghĩ tới một sinh vật: nó giống một ngọn lửa hơn là một tinh thể. Ngọn lửa trông như một vật thể, nhưng không phải. Nó là một pattern được giữ lại từng khoảnh khắc bởi một quá trình. Dừng quá trình lại thì thứ đó không còn tồn tại.

7. Emergence: độ ướt của nước và đàn chim

Hiểu paradigm này mang lại một phần thưởng rất đáng giá. Khi nhìn thế giới theo cách ấy, bạn bắt đầu nhận ra một điều đáng chú ý: khi có những luật cục bộ đơn giản giữa các hạt, giữa con người, hay giữa các sinh vật, thì tương tác cục bộ đó sinh ra một tầng trật tự hoàn toàn mới, không thể đoán trước từ các thành phần, và không thành phần nào thiết kế nó từ trước.

Ví dụ thứ nhất là nước. Nước có thuộc tính "ướt", nhưng các thành phần của nó, oxy và hydro, thì không ướt. Chính việc chúng kết hợp với nhau, tức là một lần nữa đặt trọng tâm vào quan hệ, mới là nơi một thuộc tính mới lạ xuất hiện: độ ướt.

Ví dụ thứ hai là một đàn chim. Không con chim nào thức dậy mỗi sáng với ý định tạo thành một đàn. Mỗi con có lẽ chỉ theo ba luật cục bộ đơn giản: đi cùng hướng với con bên cạnh, đừng đâm vào chúng, và ở gần nhau. Thế thôi. Luật cục bộ, tương tác cục bộ, và từ đó bạn có một đàn: một pattern mới, sống động và phối hợp, thứ mà bạn không bao giờ hiểu được bằng cách tháo nó ra và nghiên cứu một con chim, vì không con chim nào có một đàn ở bên trong. Đàn chim sống trong các quan hệ, không phải trong các bộ phận.

Phương pháp nhà máy trong engineering giả định một thế giới gồm các bộ phận. Nhưng thế giới không phải máy móc, và anh cho rằng AI đang ở ngay ngưỡng bước vào đó, là một thế giới của các pattern, của những pattern emergence đang chuyển động. Và điều đó phản ánh loại bài toán mà chúng ta đối mặt trong một thế giới đang chuyển động, bừa bộn như thế này.

8. Mess của Russell Ackoff, và complicated khác complex

Có một câu của Russell Ackoff mà anh rất thích. Ackoff nói rằng người quản lý không được giao những bài toán gọn gàng, tách biệt. Họ được giao những tình huống động, những mớ bài toán liên tục thay đổi và liên tục va vào nhau. Ackoff đặt cho nó một cái tên: a mess.

Một mess không chỉ là một đống bộ phận rời rạc. Nó thực sự là một hệ quan hệ đang chuyển động. Đó chính là lý do cách engineering kiểu nhà máy, dựa trên fixed harness, sẽ chật vật khi va chạm với các kịch bản sống trong thế giới thật. Bạn không thể chia một mess thành những chiếc hộp gọn gàng rồi giải từng hộp, vì chúng không phải các bộ phận riêng lẻ. Chúng là một pattern quan hệ đang chuyển động.

Từ đó ta có thể nhìn các bài toán qua một phân biệt. Engineering là chuyện giải bài toán, và nói thật đơn giản, theo anh có hai loại bài toán: complicated và complex.

Một hệ hay một bài toán complicated giống như việc chế tạo một chiếc máy bay jumbo, hay một chiếc đồng hồ. Có những bộ phận thụ động, nhưng chuyên gia có thể tháo chúng ra, phân tích, lập kế hoạch, dự đoán, viết tài liệu. Khó, nhưng biết được, và nó vận hành theo một cách rất dễ đoán.

Ngược lại, một hệ hay một bài toán complex, như đàn chim, một thị trường, một tổ chức con người, thì hơi khác. Các bộ phận của nó liên tục tương tác và thích nghi với nhau, nên cái toàn thể không thể suy ra từ việc phân tích các bộ phận. Vì vậy bạn không phân tích và lập kế hoạch cho một hệ complex. Thay vào đó, bạn probe, sense và respond: thăm dò, cảm nhận, rồi phản hồi.

Đây có lẽ là một trong những sai lầm đắt giá nhất trong thiết kế và engineering hiện đại: chúng ta đối xử với một bài toán complex như thể nó là complicated. Mọi thứ hỏng không phải vì thiếu khả năng thực thi, mà về bản chất là vì đã phân loại sai không gian bài toán. (Lối phân biệt complicated và complex với probe, sense, respond cũng là nền của khung Cynefin.)

9. Thành phần của một complex adaptive system

Đi sâu thêm một bước vào một complex system. Nguyên liệu của nó gồm:

• Một tập agent đa dạng, hay các actor là con người nếu đó là một tổ chức. Không phải những bản sao, mà khác nhau theo một cách nào đó, vì sự đa dạng chính là nhiên liệu.
• Tương tác cục bộ: không agent nào, không cá nhân nào, không component nào nhìn thấy cái toàn thể. Mỗi cái chỉ phản ứng với thứ ở ngay cạnh nó, giống như con chim đi cùng hướng với con bên cạnh.
• Học một cách đệ quy: chúng thích nghi, rồi thích nghi với kết quả của chính việc thích nghi đó, và vòng lặp cứ thế tiếp diễn, trong quan hệ với nhau và với môi trường. Mọi thứ chuyển động để đáp lại mọi thứ khác, và không có gì đứng yên.

Từ tất cả những tương tác cục bộ, thích nghi, lặp vòng đó, bạn có một thứ gọi là emergence, một khái niệm then chốt của complexity science. Về cơ bản, đó là một pattern, một cách tổ chức hay một hành vi mới lạ mà không bộ phận đơn lẻ nào tự thiết kế, và không thể giải thích bằng cách chia cái toàn thể thành các phần rồi nghiên cứu chúng. Lại nghĩ tới đàn chim: không con chim nào có một đàn ở bên trong. Nghĩ tới độ ướt của nước: không phân tử oxy hay hydro riêng lẻ nào chứa độ ướt, vậy mà kết hợp lại dẫn tới một thứ hoàn toàn mới.

10. Attractor, và nhìn lại chặng đường

Những hệ này không văng ra thành hỗn loạn. Chúng có xu hướng ổn định vào các attractor, về cơ bản là những trạng thái ổn định; chúng cứ bị kéo về một trạng thái cân bằng nào đó. Ví dụ, nước ổn định ở nhiệt độ phòng. Vậy là bạn có một thế giằng co rất đẹp: thay đổi liên tục ở tầng cục bộ, nhưng các pattern ổn định, nhận ra được, ở tầng toàn hệ. Và điều cốt yếu là: không ai cầm lái ở đây. Nó tự tổ chức. Đó là toàn bộ bí ẩn, và theo anh cũng là toàn bộ cơ hội cho thiết kế và engineering.

Đây là chỗ anh muốn giới thiệu triết lý thiết kế và engineering mới gọi là adaptive engineering. Nhưng trước đó, anh tổng kết lại một chút.

Mọi thứ nói tới giờ đều nằm trong một khung cụ thể: fixed harness, hay factory harness. Engineer con người thiết kế mọi thứ từ đầu: thứ tự công việc, role, capability. Đó thực sự là mô hình nhà máy, và nó hoạt động. Chúng ta đã thấy điều đó: với những không gian bài toán complicated nhưng dễ đoán, nó chính xác là cách đúng. Và anh cho rằng với phần lớn bài toán engineering, đó là phương pháp hoàn hảo.

Nhưng khoảnh khắc AI trở nên tốt hơn theo cấp số nhân và va chạm với thế giới thật, thứ mà như ta đã thấy là bừa bộn và complex chứ không chỉ complicated, chúng ta cần một thứ thực sự mới, một ý niệm khác về việc thế nào mới là thiết kế và engineering tối ưu.

Tất nhiên điều đó dựa trên hai giả định: model sẽ tốt lên theo cấp số nhân, và AI sẽ ra khỏi tình trạng chạy trong sandbox, để engineering thực sự diễn ra theo thời gian thực, tiếp xúc với môi trường xã hội và vật lý. Nói gọn lại: harness phải thích nghi giữa dòng chảy, và đó là cốt lõi của adaptive engineering.

11. Định nghĩa adaptive engineering

Nếu phải kết tinh lại thành một định nghĩa: adaptive engineering là môn thiết kế các constraint tới mức harness tự nảy sinh, ổn định và thích nghi khi cần, để đáp lại môi trường đang thay đổi, theo những cách mà bạn không thể chỉ định trước. Về bản chất, harness trở thành output liên tục chứ không còn là input.

Để cụ thể hơn, trong thực tế điều này có nghĩa là: vì agent có năng lực tương tác với nhau, nên một cách tổ chức nảy sinh từ chính những tương tác đó, để đáp lại môi trường hay một mục tiêu, sao cho xuất hiện những tầng trật tự mới, những tầng mà bạn không bao giờ có thể chỉ định từ đầu.

Hãy nghĩ "con chim và đàn chim", rồi nghĩ "agent và harness". Các agent thực sự đang tạo ra harness, giống như những con chim quan hệ với nhau để đàn chim có thể hình thành. Bạn không build harness nữa. Bạn để các agent tạo nên harness khớp nhất với môi trường ở thời điểm đó, trong bối cảnh đó. Harness khi đó trở thành một multi-agent system tự tổ chức, liên tục tiến hoá.

12. Mô phỏng: từ agent rời rạc tới specialization

Anh thử mô phỏng xem điều đó có thể trở thành gì, vì đây là chuyện của lúc agent đã mạnh hơn nhiều. Ban đầu bạn có các agent đồng dạng (isomorphic), chưa phân hoá, nhưng hoàn toàn có khả năng tương tác, học và thay đổi.

Bạn để các agent đó tương tác. Ban đầu chẳng có gì, chỉ vài trao đổi lẻ tẻ chỗ này chỗ kia. Nhưng việc coupling (gắn kết) tiếp tục và chậm rãi tăng lên, cho tới một điểm mà trung bình mỗi agent có khoảng một kết nối, và bỗng nhiên bạn bắt đầu thấy một cái toàn thể nảy ra, có thể gọi là một hệ thống.

Với vai trò engineer, đòn bẩy mới của bạn là tốc độ coupling: bạn vặn nó lên, hay hãm nó xuống? Một lần nữa, con đường adaptive tập trung vào các tương tác.

Tiếp theo, các agent bắt đầu chuyên môn hoá trong quan hệ với nhau. Giả sử có hai agent làm cùng một việc ở cùng một chỗ: đó chỉ là dư thừa, và môi trường biết điều đó, các áp lực từ môi trường biết điều đó. Nên môi trường thưởng cho bất cứ thứ gì phá được thế hoà. Một khác biệt nhỏ xíu, ai tới trước, ai giỏi hơn một chút, được feedback khuếch đại lên cho tới khi hai agent không còn thay thế được cho nhau nữa. Khi đó tập agent thôi đồng nhất và phân ra thành các niche.

Insight then chốt ở đây là: danh tính của agent không phải thứ bạn trao cho nó. Nó chính là vị trí, role hay capability mà agent chiếm được trong tương quan với các agent khác và với môi trường. Specialization nảy sinh từ tương tác.

13. Cluster, convention và một trật tự mới

Đi thêm một bước nữa, các agent thôi kết nối ngẫu nhiên. Chúng bắt đầu làm việc tốt với nhau theo từng cluster. Những đường ranh giới đầu tiên xuất hiện, và điều cốt yếu là chính hệ thống vẽ ra chúng, chứ không phải bạn, engineer, vẽ từ trước. Đó là các cluster emergent.

Cho tới khi một convention mới kết tinh lại: một sự phân chia chuẩn mực và protocol, và hệ thống tạo ra một mức governance mà không cần người cai quản. Convention nảy sinh tự phát từ sự phối hợp cục bộ, không có quyền lực trung tâm nào, vì như ta đã thấy, quyền lực trung tâm có thể dẫn tới brittleness trong một môi trường đang thay đổi. Chỉ cần vừa đủ tương tác lặp lại để đẩy cả nhóm sang một chuẩn mực chung.

Điều này cực kỳ quan trọng, vì nó có nghĩa là hệ thống có thể tiếp tục thích nghi theo cách phi tập trung, dựa trên môi trường hay không gian bài toán đang thay đổi.

Và về cơ bản, một trật tự emergent mới xuất hiện. Từ những tương tác nhỏ bé giữa các agent, bạn có một tầng tổ chức mới, khá ổn định cho tới lần lặp kế tiếp, cho tới khi môi trường thay đổi và trật tự đó buộc phải tự tái cấu trúc.

14. Engineer không biến mất, chỉ dời trọng tâm

Câu hỏi đặt ra là: vậy vai trò của engineer là gì? Trong adaptive engineering, bạn không xoá bỏ engineer, bạn chỉ dời trọng tâm của engineering.

Nếu bạn khai thác được năng lực của model, để các agent về cơ bản có thể tương tác, học và thay đổi, thì việc bạn làm với vai trò engineer là khám phá và đặt ra các constraint, tức luật chơi. Bạn không quyết định điều gì nên xảy ra, hay điều bạn muốn xảy ra; bạn cho agent không gian để khám phá cái sân đó. Rồi khi harness emergent bắt đầu thành hình, bạn cảm nhận nó và phản hồi lại nó, thay vì dừng cả quá trình engineering và làm lại từ đầu.

15. Một continuum, không phải hai lựa chọn: Hermes và Pi

Slide tiếp theo, theo anh, thể hiện một điều: đây không phải chuyện nhị phân, không phải chọn cái này hoặc cái kia. Thực ra nó là một continuum. Không có cách làm thuần fixed harness, và cũng không có cách làm hoàn toàn adaptive, hoàn toàn tự trị.

Ở một đầu, fixed engineering về cơ bản là chỉ định cấu trúc mà các agent chạy trong đó, và bạn hiếm khi đổi cấu trúc giữa chừng. Ở đầu kia của thang, adaptive engineering cho phép các agent tương tác tự do, và để harness, tức cấu trúc dẫn dắt chúng, được chính chúng tạo ra và thay đổi giữa chừng.

Nên đây không phải một bầy agent thả rông, không có role, rồi một thứ trí tuệ kỳ diệu tự xuất hiện. Và cũng không phải một cách tốt hơn cách kia. Chúng chỉ có hai use case khác nhau.

Anh lấy vài harness hiện có làm ví dụ. Đầu tiên là Hermes: trên website, nó tự giới thiệu là một AI agent tự cải thiện (self-improving), tạo skill từ kinh nghiệm và học từ đó. Rõ ràng đây là một bước tiến lớn theo hướng adaptive. Nhưng anh muốn phân biệt một điều: sự thích nghi đó là dạng vertical intelligence, tức làm cho từng agent riêng lẻ thông minh hơn. Thứ anh nói tới trong talk này là horizontal intelligence: các nhóm agent phối hợp với nhau như thế nào. Hai hướng này phần nào vuông góc với nhau. Luận điểm anh đưa ra là horizontal intelligence mới là phương pháp thích nghi nhất, nhanh nhạy nhất, và có thể nói là điểm đòn bẩy cao hơn so với vertical.

Ví dụ thứ hai là Pi: một harness rất tốt, về cơ bản là tối giản nhưng mở rộng được tối đa, nên tuỳ biến được hoàn toàn ở một mức nào đó. Bạn có thể xếp nó vào loại adaptive, nhưng một lần nữa có một sự phân biệt. Có kiểu adaptive ở giai đoạn thiết kế, khi bạn chuẩn bị cho quá trình engineering, lúc engineer tuỳ biến được và công cụ khá mềm dẻo. Còn adaptive engineering là chuyện thích nghi trong runtime, khi hệ thống tự tổ chức lại trong lúc đang chạy để đáp lại không gian bài toán đang thay đổi của môi trường. Pi là một ví dụ mạnh của kiểu thứ nhất, và nó không hề tự nhận là gì khác. Nó chưa phải là một multi-agent system tự tổ chức.

16. Ba việc của adaptive engineer: capability, constraint, sense and respond

Anh nói sẽ lướt qua một phần chi tiết vụn vặt về ý nghĩa thực tế của chuyện này. Đầu tiên là agent capability: rõ ràng agent cần tương tác, học và thay đổi. Đó là điều kiện tiên quyết của adaptive engineering, và anh không nghi ngờ rằng điều đó sẽ thành hiện thực khi model mạnh lên theo cấp số nhân.

Trên slide, ba năng lực này được ghi thành ba thẻ. Interact: cảm nhận các agent bên cạnh đang làm gì, trao đổi message theo dạng chúng hiểu được, và mô hình hoá chúng, tức hình thành kỳ vọng về cách các agent khác sẽ hành động; không có tương tác thì không có hệ thống, chỉ có những bản sao song song không bao giờ thành một tổng thể. Learn: sinh ra các biến thể, giữ cái hiệu quả, bỏ phần còn lại (variation, selection, retention), giỏi lên từ kinh nghiệm ngay ngoài thực địa, liên tục, thay vì chờ một lần retrain offline. Change: sửa không chỉ việc nó làm mà cả việc nó là gì, tức role, mục tiêu và self-model, để chuyên môn hoá vào một niche các agent khác bỏ trống; đây là năng lực sâu nhất, và nguy hiểm nhất, vì đó cũng là nơi value-drift trú ngụ.

Thứ hai là những việc mà người thiết kế thực sự làm được, dưới dạng constraint. Anh không liệt kê hết mọi loại constraint, vì phần lớn chúng được quyết định bởi các thuộc tính đã nói, như role, thứ tự công việc và memory; đó đều là các nhóm thuộc tính của một harness. Nhưng về cơ bản, có những câu hỏi bạn có thể tự đặt ra với vai trò engineer:

• Bạn muốn mở cho agent nhiều hơn, hay muốn đóng chúng lại, cai quản chúng nhiều hơn, cho thêm guardrail?
• Bạn thưởng cho chúng khi chúng gắn kết hướng về một mục tiêu cụ thể, hay bạn phạt chúng khi chúng rơi ra ngoài một container nào đó?
• Bạn muốn mọi thứ diễn ra nhanh hay chậm tới đâu? Tốc độ là bao nhiêu, ví dụ như tốc độ coupling?

Đó là một số tinh chỉnh engineering bạn có thể làm trong adaptive engineering.

Cuối cùng, với cái harness emergent liên tục định hình và định hình lại theo không gian bài toán, bạn thực sự chỉ có thể cảm nhận và phản hồi lại nó. Bạn sẽ không thể chỉnh sửa nó hoàn toàn theo kiểu engineering cứng, vì điều đó không có lợi cho chính bạn với tư cách một adaptive engineer.

17. Factory và forest: bảng so sánh hai triết lý

Slide này là một so sánh chi tiết hơn giữa hai cách tiếp cận. Anh nhấn mạnh lại: cái này không tốt hơn cái kia, chúng chỉ là hai triết lý thiết kế và engineering khác nhau.

Một bên là mô hình nhà máy: cấu trúc được engineer áp đặt từ đầu, nên harness trở thành input. Bên kia là con đường adaptive: harness nảy sinh, và về bản chất là output.

Một điểm then chốt ở đây là trong con đường adaptive, quyền kiểm soát được phi tập trung, nằm ngoài thực địa và diễn ra liên tục. Lý do là khi AI, hay AI engineering, rời khỏi màn hình để đi vào thế giới thật, không gian bài toán sẽ liên tục thay đổi. (Chữ "Red Queen" trên slide trỏ tới Red Queen hypothesis trong sinh học tiến hoá: phải liên tục thích nghi chỉ để giữ nguyên vị trí.)

18. Failure modes, và takeaway

Điều quan trọng cần hiểu là cách này có những use case riêng, nhưng cũng có rất nhiều failure mode. Anh liệt kê vài cái.

Thứ nhất, emergence nghiêng về sự ổn định, cái ta gọi là attractor, nơi bạn tìm được một cấu trúc có cảm giác ổn định và tối ưu. Nhưng ổn định không có nghĩa là tốt nhất.

Thứ hai, bạn cần một selection pressure thật sự. Hãy hình dung trong thế giới xã hội, thế giới vật lý hay thế giới tự nhiên, môi trường đặt lên chúng ta những áp lực nhất định, và đó là thứ thúc chúng ta thích nghi. Đó chính là tiến hoá. Ở đây cũng cần một kiểu selection pressure như vậy, và chúng ta, với tư cách một cộng đồng, cần tìm ra nó cho adaptive engineering, nếu không bạn sẽ chỉ có drift, trôi dạt.

Thứ ba, có rủi ro monoculture: bạn không có sự đa dạng thật sự giữa các agent, vì chúng đều được train trên cùng một loại dữ liệu.

Thứ tư, legibility sụp đổ: khi khả năng thích nghi tăng lên, bạn không thể xác định hay giải thích mọi thứ rõ ràng như trước. Và đó lại là một đặc điểm của complex system: bạn không thể thực sự ghim chúng lại.

Và hiển nhiên là không còn khả năng dự đoán trước runtime, vì mọi thứ liên tục chuyển động.

Đó là những failure mode thật mà chúng ta phải nắm được, vì anh thực sự cảm thấy adaptive engineering là thứ chúng ta sẽ ngày càng nghiêng về, và nó sẽ lao nhanh về phía trước trong tương lai.

Takeaway của anh: khi model cải thiện theo cấp số nhân, AI engineering sẽ đi vào các kịch bản của thế giới thật, nơi nó chạm vào không gian vật lý một cách liên tục, tiếp xúc với nhiều agent thuộc nhiều tổ chức khác nhau, tiếp xúc với nhiều con người. Có một ngưỡng thật sự ở đây mà AI đang tiến tới. Vì vậy môn thiết kế và engineering sẽ bị buộc phải tự suy nghĩ lại quanh việc sản xuất liên tục (continual production).

Yếu tố giới hạn, đúng là bây giờ đã vậy nhưng có lẽ càng đúng hơn trong tương lai, sẽ không phải sức mạnh của model, mà là khả năng thích nghi của harness. Và khả năng thích nghi ở đây thực sự có nghĩa là multi-agent, tức là chuyện phối hợp giữa các agent: một kiểu multi-agent orchestration phi tập trung, không phải thích nghi trước runtime, mà bắt đầu trở nên thích nghi ngay giữa runtime, hay trong suốt cả một quá trình engineering. Anh cho rằng đó là trí tuệ thật. Rồi anh tự nói rõ lại: khi nói "trí tuệ thật", ý anh là thứ trí tuệ nằm ở khả năng thích nghi của harness.

Anh kết thúc bằng lời mời: anh rất muốn nghe suy nghĩ của mọi người về chuyện này, và liệu có ai khác cũng đang khám phá hướng đi này không. Anh mời người nghe liên hệ với anh, rồi cảm ơn.