Агентная инженерия сначала уточняет контекст и датчики.

Глядя на группу дискуссий, посвященных Harness Engineering в наши дни, наиболее интуитивным ощущением является не то, что «Агент добавил новый уровень возможностей», а то, что фокус инженерных дискуссий изменился. Раньше мы часто спрашивали, достаточно ли сильна модель. Теперь мы сначала сосредоточимся на том, какой объем контекста нужно вставить, как долго вставить файл правил и какой сигнал подает датчик. Модель все еще находится посередине, но что действительно начинает определять стабильность, так это внешняя подвеска.

Чем больше контекстное окно, тем стабильнее будет внимание.

Кто-то на ретрите упомянул, что agents.md следует контролировать до менее 200 строк. Эта цифра не претенциозна и не преклонение перед номером строки, а скорее напоминание о бюджете. Чем больше контекстное окно, это лишь означает, что в него можно втиснуть больше контента, но это не означает, что модель будет более стабильно схватывать ту часть, которую следует уловить. Модели часто фокусируются только на небольшой части контекста, и даже если остальной контент находится в окне, не весь он может быть в фокусе.

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

Датчик снова не подает бревно

Еще одно очевидное изменение заключается в том, что обсуждение начало переходить к вычислительным датчикам. Датчики здесь не просто закопаны, и системные журналы не вставлены в модель неповрежденными, а статус времени выполнения сжимается в небольшое количество полезных сигналов. Что он делает, так это фильтрует шум, а не создает новую контекстную нагрузку.

Вот почему говорят «перейдите на Rust вместо Python». Основное внимание уделяется не принятию чьей-либо стороны в отношении языка, а контролю. Как только датчик полагается на границы времени выполнения, ограничения ресурсов, пути исключений и детерминированный вывод для обеспечения качества, язык и среда выполнения перестают быть просто деталями реализации, а являются частью самого датчика. Если сигнал нестабильный, независимо от того, насколько сильна модель, она будет только предполагать нестабильный входной сигнал.

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

Обязанность жгута — разрезать мир на части, которые можно скормить модели.

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

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

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