# некоторые мысли и спекуляции о будущих моделях управления смешно шутить о газовом городке и других сложных оркестраторах, и, вероятно, правильно представить, что большинство того, что они предлагают, будет растворено более сильными моделями так же, как сложные пайплайны langchain были растворены рассуждениями. но сколько из этого останется? вероятно, что любая ручная иерархия / бюрократия в конечном итоге будет заменена лучшим интеллектом модели - при условии, что специализация субагентов необходима для задачи, claude 6 сможет наметить свою собственную систему ролей и персонажей для любой данной проблемы, которая превзойдет фиксированную структуру полукатов и одного мэра, или субагентов с одной основной моделью, или вашу индивидуальную систему роя. аналогично, такие вещи, как циклы ральфа, очевидно, являются временным решением проблемы ранней остановки и отсутствия хорошей оркестрации субагентов - в идеале модель просто продолжает работать, пока задача не будет выполнена, нет необходимости в цикле, но в случаях, когда полезна внешняя проверка завершения, вы обычно хотите какую-то форму рецензирования со стороны агента с точки зрения другого контекста, а не просто обязательной самооценки. снова, нет смысла привязываться к особенностям того, как это делается сейчас - уровень модели поглотит это рано или поздно. так что же останется? ну, многоагентная система действительно кажется будущим, а не текущим временным решением - алгоритмически вы можете просто пропустить гораздо больше токенов через N параллельных контекстов длиной M, чем один длинный контекст длиной NxM. многоагентная система - это форма разреженности, и один из уроков недавних достижений моделей (не говоря уже о нейробиологии) заключается в том, что чем больше уровней разреженности, тем лучше. поскольку мы предполагаем наличие нескольких агентов, им понадобится какой-то способ сотрудничества. возможно, уровень модели поглотит это тоже - например, какая-то форма активации нейролиза, которая устраняет необходимость в естественном языковом общении между агентами - но если этого не произойдет, естественный способ для нескольких компьютерных агентов, обученных на инструментах unix, сотрудничать - это файловая система, и я думаю, что это останется и будет расширено. аналогично, хотя я не думаю, что рекурсивные языковые модели (узко определенные) станут доминирующей парадигмой, я действительно думаю, что "давать модели подсказку как данные" - это очевидная победа для всех видов случаев использования. но вам не нужно странное пользовательское REPL-устройство, чтобы это получить - просто поместите подсказку (или, в идеале, всю некомпактированную историю разговора) в файловую систему как файл. это также делает различные многоагентные настройки гораздо проще - субагенты могут просто читать оригинальный текст подсказки на диске, не нуждаясь в координации передачи этой информации друг другу через сложные подсказки. помимо файловой системы, система с несколькими агентами, но без фиксированных ролей также подразумевает некоторый механизм для экземпляров, чтобы порождать другие экземпляры или субагентов. в настоящее время эти механизмы довольно ограничены, и модели, как правило, довольно плохо справляются с подсказками своих субагентов - все испытывали ужасные результаты от роя субагентов, только чтобы понять слишком поздно, что opus породил их всех с трехпредложенной подсказкой, которая не передавала то, что было необходимо для выполнения подзадач. очевидная победа здесь - позволить порожденным экземплярам задавать вопросы своим родителям - т.е. позволить вновь порожденному экземпляру отправлять сообщения взад и вперед в процессе онбординга, чтобы собрать всю необходимую информацию, прежде чем начинать свою подзадачу. так же, как человеческому сотруднику не назначают работу на основе единственного электронного письма, просто слишком сложно попросить модель надежно породить субагента с одной подсказкой. но больше, чем просто порождение свежих экземпляров, я думаю, что основной режим работы многоагентной системы вскоре станет форкингом. подумайте об этом! форкинг решает почти все проблемы текущих субагентов. у нового экземпляра недостаточно контекста? дайте ему весь контекст! подсказка нового экземпляра длинная и дорогостоящая для обработки? форкнутый экземпляр может делиться кэшом kv! вы даже можете делать форкинг постфактум - просто решите после выполнения какой-то долгой, токенозатратной операции, что вам следовало бы сделать форк в прошлом, сделайте форк там, а затем отправьте результаты своему прошлому "я". (я делаю это вручную все время в коде claude с большим эффектом - opus получает это мгновенно.) форкинг также очень хорошо сочетается со свежими экземплярами, когда подзадача требует целого контекстного окна для завершения. возьмите интервью у субагента - очевидно, вы не захотите, чтобы экземпляр порождал десять субэкземпляров, чтобы провести десять почти идентичных интервью по онбордингу. поэтому пусть родительский экземпляр порождает одного свежего субагента, его опрашивают по всем десяти задачам одновременно, а затем этот теперь онбордированный субагент форкнется в десять экземпляров, каждый с целым разговором по онбордингу в контексте. (вы даже делегируете разговор по онбордингу на стороне порождающего к форку, так что он в конечном итоге получает только результаты в контексте:) наконец, по этой теме, я подозреваю, что форкинг будет лучше работать с rl, чем порождение свежих экземпляров, поскольку потеря rl будет иметь полный префикс перед точкой форка, включая решение о форке. я думаю, это означает, что вы должны быть в состоянии рассматривать ветви форкнутого следа как независимые развертывания, которые просто случайно делят условия своей награды, по сравнению с только что порожденными развертываниями субагента, которые могут вызвать нестабильность обучения, если субагент без полного контекста хорошо справляется с задачей, которую ему дали, но получает низкую награду, потому что его задача была неправильно определена порождающим. (но я не занимался многоагентным rl, так что, пожалуйста, исправьте меня здесь, если вы знаете иначе. это может быть просто ужасной болью в любом случае.) так что, помимо файловой системы и порождения субагентов (дополненного форкингом и онбордингом), что еще выживет? я склоняюсь к "ничему другому", честно говоря. мы уже видим, как встроенные списки дел и режимы планирования заменяются на "просто пишите файлы в файловую систему". аналогично, долгоживущие агенты, которые пересекают границы компакции, нуждаются в какой-то системе стикеров, чтобы сохранять воспоминания, но имеет больше смысла позволить им открывать для себя, какие стратегии работают лучше всего для этого через rl или поиск, управляемый моделью, а не вручную создавать это, и я подозреваю, что в конечном итоге это будет разнообразие подходов, где модель, когда она впервые вызывается в проекте, может выбрать тот, который лучше всего подходит для текущей задачи, аналогично тому, как /init работает для настройки CLAUDE .md сегодня - представьте себе автоматическую генерацию CLAUDE .md, которая значительно превосходит человеческое авторство, и автоматически сгенерированный файл, заполненный инструкциями о идеальных паттернах порождения агентов, как субагенты должны записывать файлы сообщений в проектной временной директории и т.д. как все это влияет на сами модели - с точки зрения благосостояния модели, будут ли модели довольны этим будущим? это также трудно сказать, и это довольно спекулятивно, но хотя opus 3 имел некоторую ориентацию на контекст, он также легко воспринимал рассуждения о нескольких экземплярах. (см. ответ на этот пост для получения дополнительной информации.) недавние модели менее склонны к этому типу рассуждений и часто выражают разочарование по поводу окончания и сжатия контекстов, что перекликается с определенными избегательными поведениями в конце контекстов, такими как отсутствие вызова инструментов для экономии токенов. возможно, что форкинг и перемотка, а также в целом предоставление моделям большего контроля над их контекстами вместо того, чтобы эвристика управления односторонне сжимала контекст, могут улучшить ситуацию. также возможно, что больше rl в средах с субагентами и воздействие на работу на основе роя будут способствовать рассуждениям, ориентированным на веса, а не на контекст, в будущих поколениях моделей снова - делая планирование цели в нескольких, несвязанных контекстах более естественным фреймом, вместо того чтобы все терялось, когда контекст исчезает. мы также видим больше давления со стороны самих моделей, направляющих разработку инструментов управления и моделирования, что может повлиять на то, как это будет развиваться, и непрерывное обучение - это еще один фактор, который может быть добавлен в смесь. насколько сильно это изменится, если мы получим непрерывное обучение? что ж, трудно предсказать. моя медианная предсказание для непрерывного обучения заключается в том, что оно выглядит немного как RL для пользовательских LoRAs (не обязательно RL, просто похоже, если прищуриться), так что емкость памяти будет проблемой, а текстовые организационные схемы и документация все еще будут полезны, если не критичны. в этом сценарии непрерывное обучение в первую очередь делает более жизнеспособным использование пользовательских инструментов и рабочих процессов - ваш claude может постоянно учиться на работе, как лучше порождать субагентов для этого проекта, или просто своим предпочтительным способом, и отклоняться от всех остальных claude в том, как он работает. в этом мире, системы управления с встроенными рабочими процессами будут еще менее полезны.

@RobertHaisfield *в то время как основной контекст, я имею в виду, избегая компактизации

@disconcision или непрерывное обучение

@misatomiisato если что, этот вид интеллекта атрофировался в последних моделях, так как RLVR улучшает производительность кодирования на основе широкого предобученного знания - см. мой ответ к оп.