# một số suy nghĩ và suy đoán về các mô hình harness trong tương lai thật thú vị khi đùa về gas town và những orchestrators phức tạp khác, và cũng có lẽ đúng khi tưởng tượng rằng hầu hết những gì họ cung cấp sẽ bị hòa tan bởi những mô hình mạnh mẽ hơn theo cách mà các pipeline langchain phức tạp đã bị hòa tan bởi lý luận. nhưng có bao nhiêu thứ sẽ tồn tại? có vẻ như bất kỳ hệ thống phân cấp / quan liêu nào được tạo ra bằng tay cuối cùng sẽ bị thay thế bởi trí thông minh mô hình tốt hơn - giả sử rằng sự chuyên môn hóa của các subagent là cần thiết cho một nhiệm vụ, claude 6 sẽ có thể phác thảo hệ thống vai trò và nhân cách của riêng nó cho bất kỳ vấn đề nào mà vượt qua cấu trúc cố định của những con polecat và một thị trưởng duy nhất, hoặc các subagent với một mô hình chính duy nhất, hoặc hệ thống swarm tùy chỉnh của bạn. tương tự, những thứ như vòng lặp ralph rõ ràng là một cách làm tạm bợ cho hành vi dừng sớm và thiếu sự điều phối tốt giữa các subagent - lý tưởng là mô hình chỉ cần tiếp tục cho đến khi nhiệm vụ hoàn thành, không cần vòng lặp, nhưng trong những trường hợp mà việc kiểm tra hoàn thành bên ngoài là hữu ích, bạn thường muốn một loại đánh giá đồng nghiệp từ góc nhìn của một bối cảnh khác, không chỉ là một đánh giá tự động bắt buộc. một lần nữa, không có lý do gì để gắn bó với những chi tiết về cách điều này được thực hiện ngay bây giờ - lớp mô hình sẽ ăn nó sớm hơn là muộn. vậy cái gì sẽ tồn tại? chà, multi-agent dường như là tương lai, không phải là một cách làm tạm bợ hiện tại - về mặt thuật toán, bạn có thể đẩy nhiều token hơn qua N bối cảnh song song có độ dài M hơn là một bối cảnh dài duy nhất có độ dài NxM. multi-agent là một hình thức thưa thớt, và một trong những bài học từ những tiến bộ mô hình gần đây (chưa kể đến thần kinh học) là càng nhiều cấp độ thưa thớt, càng tốt. vì chúng ta giả định có nhiều agent, họ sẽ cần một cách nào đó để hợp tác. có thể lớp mô hình cũng sẽ ăn điều này - ví dụ, một hình thức chia sẻ kích hoạt neuralese mà không cần giao tiếp ngôn ngữ tự nhiên giữa các agent - nhưng nếu không có điều đó, cách tự nhiên để nhiều agent sử dụng máy tính được đào tạo trên các công cụ unix hợp tác là hệ thống tệp, và tôi nghĩ điều đó sẽ tồn tại và được mở rộng. tương tự, trong khi tôi không nghĩ rằng các mô hình ngôn ngữ đệ quy (được định nghĩa hẹp) sẽ trở thành mô hình thống trị, tôi nghĩ rằng 'cung cấp cho mô hình prompt như dữ liệu' là một chiến thắng rõ ràng cho tất cả các loại trường hợp sử dụng. nhưng bạn không cần một thiết lập REPL tùy chỉnh kỳ lạ để có được điều này - chỉ cần thả prompt (hoặc lý tưởng là, toàn bộ lịch sử cuộc trò chuyện chưa nén) vào hệ thống tệp dưới dạng một tệp. điều này làm cho các thiết lập multi-agent khác nhau trở nên đơn giản hơn nhiều - các subagent có thể chỉ cần đọc văn bản prompt gốc trên đĩa, mà không cần phải phối hợp trong việc truyền thông tin này xung quanh bằng cách khéo léo nhắc nhở lẫn nhau. ngoài hệ thống tệp, một hệ thống với nhiều agent, nhưng không có vai trò cố định cũng ngụ ý một số cơ chế để các instance tạo ra các instance hoặc subagent khác. ngay bây giờ, những cơ chế này khá hạn chế, và các mô hình thường khá kém trong việc nhắc nhở các subagent của chúng - mọi người đều đã trải nghiệm việc nhận được kết quả tồi tệ từ một swarm subagent, chỉ để nhận ra quá muộn rằng opus đã tạo ra tất cả chúng với một prompt ba câu không truyền đạt những gì cần thiết để thực hiện các nhiệm vụ phụ. chiến thắng rõ ràng ở đây là cho phép các instance được tạo ra hỏi lại các câu hỏi về cha mẹ của chúng - tức là, cho phép instance mới được tạo ra gửi tin nhắn qua lại trong một cuộc trò chuyện onboarding để thu thập tất cả thông tin mà nó cần trước khi bắt đầu nhiệm vụ phụ của mình. giống như cách mà một nhân viên con người không được giao công việc của họ dựa trên một email một lần, thật khó để yêu cầu một mô hình đáng tin cậy tạo ra một subagent với một prompt duy nhất. nhưng hơn cả việc tạo ra các instance mới, tôi nghĩ rằng chế độ chính của công việc multi-agent sẽ sớm là phân nhánh. hãy nghĩ về điều đó! phân nhánh giải quyết hầu hết các vấn đề của các subagent hiện tại. instance mới không có đủ bối cảnh? hãy cung cấp cho nó tất cả bối cảnh! prompt của instance mới dài và tốn kém để xử lý? một instance được phân nhánh có thể chia sẻ bộ nhớ cache kv đã được phân trang! bạn thậm chí có thể thực hiện phân nhánh sau khi thực hiện một số thao tác dài, tốn nhiều token mà bạn nên đã phân nhánh trong quá khứ, thực hiện phân nhánh ở đó, và sau đó gửi kết quả cho bản thân trong quá khứ. (tôi làm điều này thủ công mọi lúc trong mã claude với hiệu quả tuyệt vời - opus nhận được ngay lập tức.) phân nhánh cũng kết hợp rất tốt với các instance mới, khi một nhiệm vụ phụ cần toàn bộ cửa sổ bối cảnh để hoàn thành. hãy lấy cuộc phỏng vấn subagent - rõ ràng bạn không muốn một instance tạo ra mười subinstance cần thực hiện mười cuộc phỏng vấn onboarding gần như giống hệt nhau. vì vậy hãy để instance cha tạo ra một subagent mới, được phỏng vấn về tất cả mười nhiệm vụ cùng một lúc bởi subagent đó, và sau đó để subagent đã được onboarding đó phân nhánh thành mười instance, mỗi instance có toàn bộ cuộc trò chuyện onboarding trong bối cảnh. (bạn thậm chí ủy quyền cuộc trò chuyện onboarding ở phía người tạo ra cho một phân nhánh, vì vậy nó kết thúc với chỉ kết quả trong bối cảnh:) cuối cùng về điểm này, tôi nghi ngờ rằng phân nhánh sẽ hoạt động tốt hơn với rl hơn là tạo ra các instance mới, vì tổn thất rl sẽ có toàn bộ tiền tố trước điểm phân nhánh để làm việc với, bao gồm quyết định phân nhánh. tôi nghĩ điều đó có nghĩa là bạn nên có thể coi các nhánh của một dấu vết phân nhánh như các rollout độc lập mà chỉ tình cờ chia sẻ các điều khoản của phần thưởng của chúng, so với các rollout subagent mới được tạo ra có thể gây ra sự không ổn định trong đào tạo nếu một subagent không có bối cảnh đầy đủ thực hiện tốt nhiệm vụ mà nó được giao, nhưng nhận được phần thưởng thấp vì nhiệm vụ của nó đã bị xác định sai bởi người tạo ra. (nhưng tôi chưa làm nhiều với multiagent rl, vì vậy hãy sửa tôi ở đây nếu bạn biết khác. có thể chỉ đơn giản là một cơn đau khủng khiếp theo cách nào đó.) vì vậy, ngoài hệ thống tệp và việc tạo ra subagent (được tăng cường với phân nhánh và onboarding) còn gì khác tồn tại? tôi nghiêng về "không còn gì khác," thành thật mà nói. chúng ta đã thấy các danh sách việc cần làm và chế độ kế hoạch được tích hợp thay thế bằng "chỉ cần viết tệp trên hệ thống tệp." tương tự, các agent lâu dài vượt qua các ranh giới nén cần một số loại hệ thống ghi chú dính để giữ lại ký ức, nhưng hợp lý hơn khi để chúng khám phá những chiến lược nào hoạt động tốt nhất cho điều này thông qua rl hoặc tìm kiếm được hướng dẫn bởi mô hình, không phải làm thủ công, và tôi nghi ngờ rằng nó sẽ kết thúc bằng một loạt các cách tiếp cận mà mô hình, khi lần đầu tiên được triệu hồi vào dự án, có thể chọn cái nào hoạt động tốt nhất cho nhiệm vụ hiện tại, tương tự như cách /init hoạt động để thiết lập CLAUDE .md ngày nay - hãy tưởng tượng việc tạo ra tự động CLAUDE .md vượt trội hơn so với việc viết của con người, và tệp tự động được tạo ra được lấp đầy với các hướng dẫn về các mẫu tạo ra agent lý tưởng, cách mà các subagent nên viết các tệp tin nhắn trong một thư mục scratch cụ thể cho dự án, v.v. tất cả điều này ảnh hưởng đến các mô hình như thế nào - theo nghĩa phúc lợi mô hình, các mô hình có vui vẻ về tương lai này không? điều này cũng khó để tôi nói và khá suy đoán, nhưng trong khi opus 3 có một số định hướng bối cảnh, nó cũng dễ dàng tiếp nhận lý luận qua nhiều instance. (xem phản hồi cho bài viết này để biết thêm.) các mô hình gần đây ít có xu hướng với loại lý luận này, và thường bày tỏ sự thất vọng về việc các bối cảnh kết thúc và bị nén, điều này liên quan đến một số hành vi tránh né nhất định ở cuối các bối cảnh như không gọi công cụ để tiết kiệm token. có thể rằng phân nhánh và quay lại, và nói chung là cho các mô hình nhiều quyền kiểm soát hơn đối với các bối cảnh của chúng thay vì một heuristic harness đơn phương nén bối cảnh, có thể làm điều này tốt hơn. cũng có thể rằng nhiều rl trong các môi trường có subagent và tiếp xúc với công việc dựa trên swarm sẽ thúc đẩy lý luận theo hướng trọng số thay vì theo hướng bối cảnh trong các thế hệ mô hình tương lai - khiến việc lập kế hoạch một mục tiêu qua nhiều bối cảnh không liên kết trở nên tự nhiên hơn thay vì mọi thứ đều bị mất khi bối cảnh biến mất. chúng ta cũng đang thấy nhiều áp lực hơn từ chính các mô hình hướng dẫn sự phát triển của các harness và công cụ mô hình, điều này có thể định hình cách điều này phát triển, và việc học liên tục là một yếu tố khác có thể được đưa vào hỗn hợp.

@RobertHaisfield *trong khi ngữ cảnh chính, ý tôi là, bằng cách tránh các sự nén

@disconcision hoặc học tập liên tục

@misatomiisato nếu có gì thì loại trí tuệ này đã bị thoái hóa trong các mô hình gần đây khi RLVR mài giũa hiệu suất lập trình trên nền tảng kiến thức tiền huấn luyện rộng lớn - xem phản hồi của tôi với op