После того, как Агент возьмет на себя задачу, первое, что нужно подтянуть – это рабочий блок.

В последнее время читаю много обсуждений об Агенте, и в итоге всегда возвращаюсь к одному и тому же вопросу: Кому отдать работу, как ее упаковать перед сдачей и как ее примут после возврата. Как только эта проблема возникает в проекте, первое, что часто возрастает, — это не стоимость модели, а сложность рабочей единицы. Если задача слишком большая, модель будет выглядеть «как будто ее можно выполнить»; настоящие проблемы обычно заключаются в откате, воспроизведении и принятии.

Сначала рабочая единица должна быть принята

За последние несколько дней, после объединения фрагментированных заметок Мартина Фаулера и нескольких дискуссий на семинаре Thoughtworks Future of Software Development Retreat, наиболее очевидным ощущением было то, что разговор на встрече был поверхностно разрозненным, но на самом деле он вращался только вокруг одного — передачи большого куска работы Агенту.

Завершение Киф Моррис является самым простым. На различных сессиях обсуждались обзор кода, несчастные случаи на производстве, разделение труда в группах и маршрутизация моделей. Вроде бы говорили о разном, но вывод оказался один: люди корректируют размер «работы подразделения». Чем больше объект, тем легче его будет передать; чем больше отряд, тем труднее будет его принять после того, как он вернется. Дело не в том, что модель не может этого сделать, а в том, что последующая ссылка подтверждения не может удержаться первой.

Вот почему обвязка упоминается снова и снова. Управление контекстом, вычислительные датчики, тестирование на основе свойств, формальные методы — все это звучит как дополнительные инструменты, но на самом деле они собирают рабочие единицы. Некоторые люди ограничивают agents.md размером менее 200 строк не для того, чтобы добиться аккуратности в форме, а для того, чтобы заставить систему получать только ту часть информации, которая действительно полезна и действительно может быть проверена. Контекст слишком свободен, конечно, Агент может работать; но после запуска никто не знает, какой слой ограничений он поглотил.

Самостоятельное размещение расширяет возможности управления

Обсуждения самостоятельных моделей также указывают на то же самое. После того, как токены станут дороже, требования соответствия станут более строгими, а утечка данных станет невозможной, модели с открытым исходным кодом и локальные модели, естественно, станут более привлекательными. Но как только вы переносите модель самостоятельно, у вас также возникают проблемы: графический процессор, комната вывода, маршрутизация, откат, точная настройка и выбор модели. Это не сами возможности модели, но они будут определять, будет ли система в конечном итоге стабильной.

Такие затраты часто недооцениваются. Многие команды изначально сосредоточились на том, «является ли модель более сильной», но позже обнаружили, что на самом деле время отнимает стабильная передача рабочих единиц между несколькими моделями. Когда использовать большую модель, когда использовать облегченную модель, а когда просто использовать локальную модель, это зависит не от словесных предпочтений, а от слоя контрольной поверхности, который можно использовать для отвлечения внимания и сокрытия. Без этого уровня самостоятельный хостинг перейдет от «взятия на себя инициативы» к «самому взятию на себя всех сложностей эксплуатации и обслуживания».

Саймон Уиллисон упомянул, что позволяет более сильным моделям выбирать более мелкие модели для выполнения работы. Эта идея также очень похожа на то, что делает плоскость управления. Сама модель не обязательно знает границы затрат команды, но система знает. Рассматривать модель как посредника и использовать ее для распределения задач ближе к реальной реализации, чем слепо следовать единой модели комплексной доставки.

Принятие и цели не могут быть переданы на аутсорсинг

Песня Сэма Руби «Принеси мне камень» выявила еще одну проблему. Передача работы модели эквивалентна добавлению исполнителя; ответственность не исчезает. Менеджеры могут использовать LLM для исследования и позволить ему сначала выдать кучу возможных решений, но окончательные критерии приемки все равно должны попасть в руки человека. Скрытые цели доставляют больше всего беспокойства. Разрешения, конфиденциальность, деструктивные действия и утечка контекста часто не включены в первоначальные требования.

Таким образом, тесты на соответствие часто более полезны, чем спецификации. Спецификации хорошо описывают «то, что требуется», а тесты лучше раскрывают «то, чего не может произойти». Это особенно актуально для агентских систем. Модель может очень хорошо компенсировать явные цели, но неявные границы необходимо проверять путем более тщательной проверки. Пока условия приемки остаются в расплывчатых описаниях, чем больше агент делает, тем больше система будет выглядеть так, как будто она делает ставку на вероятность.

Поэтому проверка кода, обработка инцидентов и назначение задач, которые раньше были очень похожими на человеческие задачи, теперь начинают принимать другие формы. Менеджеры используют модель напрямую. На первый взгляд кажется, что эффективность повышается, но на нижнем уровне фактически меняется метод управления: от методов управления к управлению целями. Если цель четко сформулирована, у модели будет шанс сработать; если цель неясна, модель только усилит неопределенность для других.

Опыт и навыки чтения продолжают улучшаться

Опыт взаимодействия и сопутствующий опыт, упомянутые Дэном Дэвисом, также очень важны для этих изменений. Модель может прочитать много материалов и сделать адекватные выводы, но для того, чтобы система была стабильной, все равно должен быть кто-то, кто сможет прочитать спецификации, увидеть результаты и понять, что не так. Ключевым моментом здесь является не то, что люди должны соревноваться с моделью, чтобы увидеть, кто умнее, а то, что люди должны продолжать занимать позицию, определяющую границы.

Этот вопрос более прост, когда речь идет о доставке программного обеспечения. После того, как агент возьмет на себя управление, человеческая работа будет меньше зависеть от ручного выполнения и больше от сегментации задач, определения границ, проектирования приемки и обработки исключений. Возможность передачи задач четко определяет, стоит ли выполнять последующее управление контекстом, маршрутизацию модели и оркестровку инструментов. Если блок не ясен, сколько бы слоев ни было, это только отодвинет проблему назад.

После прочтения этих фрагментов за последние несколько дней в моей голове осталось не определенное название модели и не новый фреймворк, а более простое суждение: первое, что нужно подтянуть системе Агента, — это не возможности модели, а рабочая единица. Если единица меньше, приемка строже, а разрешения строже, система будет иметь возможность удерживать сложность в контролируемом диапазоне.