😣 Самая умная модель не спасёт кривой harness
У разработчиков новый спорт: сравнение AI-моделей. Одна лучше пишет код. Другая глубже рассуждает. Вчерашний победитель сегодня уже в запасе.
Тут выясняется неприятное. В обычном чате модель тупит. Она видит одну процедуру без остальной конфигурации. Пробелы заполняет догадками. Иногда с уверенностью ведущего архитектора.
В агентной среде та же модель получает доступ к файлам. Она читает XML-метаданные и BSL-модули. Вызывает инструменты. Запускает проверки.
Разница в контексте и harness.
Что такое harness?
Harness, или харнес, это программная обвязка вокруг модели. Он собирает инструкции и контекст. Даёт разрешённые инструменты. Проверяет права. Выполняет вызовы. Возвращает пути, файлы, diff, stdout или ошибку.
Модель изучает результат и выбирает следующий шаг. Harness снова его обрабатывает. Это agent loop: рабочий цикл модели и инструментов.
Без харнеса модель умная, разговорчивая и совершенно безрукая.
Возьмём задачу 1С. В чат вставили процедуру проведения документа. Модель объяснила код и построила гипотезу.
Подписки на события, общие модули и регистры она не видит. Модель может угадать. Но проверить гипотезу нельзя. Получается гадание по одной процедуре.
Агент с доступом на чтение работает иначе. Он находит объект метаданных и его модули. Потом просматривает вызовы и регистры. При наличии разрешения запускает проверку. В ответе показывает фактический результат.
Модель та же. Одной дали клочок кода, второй выдали рабочее место.
А потом граждане удивляются разным ответам.
Только не надо запихивать в слово harness весь AI-зоопарк.
- AGENTS.md содержит инструкции проекта.
- Спецификация фиксирует требования и ограничения.
- Навыки описывают процедуры.
- MCP подключает к агенту внешние источники данных и команды.
- Выгрузка содержит код и метаданные.
- Проверки возвращают обратную связь.
- Memory Bank сохраняет решения.
Нет правила в контексте? Модель его не соблюдёт.
Нет команды проверки? Harness ничего не запустит.
Закрыт доступ к файлам? Модель проект не прочитает. Астральный MCP пока тоже не завезли.
После первого неудачного ответа юное дарование проводит древний технический обряд. Оно немедленно меняет модель. Контекст, права и проверки остаются прежними. Они ведь ни при чём.
Иногда замена помогает. Иногда дорогую модель меняют на ещё более дорогую. Мусор остаётся прежним. Только написан увереннее.
Старая модель выдавала ерунду за минуту. Новая думает над ней все 20. Солидно. Сразу видно: reasoning effort расходовали.
Только зря. Контекст, инструменты и проверка не изменились. Получили тот же тупой ответ. Просто ждали дольше.
Перед заменой модели проверьте слабые слои контура:
- ошибка в рассуждении: модель и режим рассуждения;
- выдуманные объекты: контекст, файловый поиск (нашёл ли агент нужный модуль или регистр) и MCP;
- нарушение стандартов: загрузка правил проекта (AGENTS.md, стандарты 1С) и приоритет инструкций;
- отклонённый вызов: sandbox (изолированная среда выполнения) и разрешения (доступ к конфигуратору или EDT, запуск синтаксического контроля);
- победа без доказательств: проверка и критерии готовности (тестовое проведение документа, а не рассказ о нём);
- потерянные решения: состояние задачи и проектная память.
Есть и противоположный ритуал. Можно установить побольше всего. Например, десять MCP-серверов, пятьдесят навыков и конфигуратор с EDT в довесок.
Контекст растёт. Выбор усложняется. Ответ приходится ждать дольше. Всё мигает, токены горят. Документ как не проводился, так и не проводится.
Новый инструмент должен закрывать конкретный дефицит. Он добавляет недостающий факт, разрешённое действие или проверку. Иначе это очередная иконка на рабочем столе.
Инструменты будут меняться. Модель помогает рассуждать. Harness доводит рассуждение до проверяемого действия.
Поэтому harness решает. Но результат принимает разработчик. Он за него и отвечает.
А какой harness у вас?
#статья
TG | YouTube
У разработчиков новый спорт: сравнение AI-моделей. Одна лучше пишет код. Другая глубже рассуждает. Вчерашний победитель сегодня уже в запасе.
Тут выясняется неприятное. В обычном чате модель тупит. Она видит одну процедуру без остальной конфигурации. Пробелы заполняет догадками. Иногда с уверенностью ведущего архитектора.
В агентной среде та же модель получает доступ к файлам. Она читает XML-метаданные и BSL-модули. Вызывает инструменты. Запускает проверки.
Разница в контексте и harness.
Что такое harness?
Harness, или харнес, это программная обвязка вокруг модели. Он собирает инструкции и контекст. Даёт разрешённые инструменты. Проверяет права. Выполняет вызовы. Возвращает пути, файлы, diff, stdout или ошибку.
Модель изучает результат и выбирает следующий шаг. Harness снова его обрабатывает. Это agent loop: рабочий цикл модели и инструментов.
Без харнеса модель умная, разговорчивая и совершенно безрукая.
Возьмём задачу 1С. В чат вставили процедуру проведения документа. Модель объяснила код и построила гипотезу.
Подписки на события, общие модули и регистры она не видит. Модель может угадать. Но проверить гипотезу нельзя. Получается гадание по одной процедуре.
Агент с доступом на чтение работает иначе. Он находит объект метаданных и его модули. Потом просматривает вызовы и регистры. При наличии разрешения запускает проверку. В ответе показывает фактический результат.
Модель та же. Одной дали клочок кода, второй выдали рабочее место.
А потом граждане удивляются разным ответам.
Только не надо запихивать в слово harness весь AI-зоопарк.
- AGENTS.md содержит инструкции проекта.
- Спецификация фиксирует требования и ограничения.
- Навыки описывают процедуры.
- MCP подключает к агенту внешние источники данных и команды.
- Выгрузка содержит код и метаданные.
- Проверки возвращают обратную связь.
- Memory Bank сохраняет решения.
Нет правила в контексте? Модель его не соблюдёт.
Нет команды проверки? Harness ничего не запустит.
Закрыт доступ к файлам? Модель проект не прочитает. Астральный MCP пока тоже не завезли.
После первого неудачного ответа юное дарование проводит древний технический обряд. Оно немедленно меняет модель. Контекст, права и проверки остаются прежними. Они ведь ни при чём.
Иногда замена помогает. Иногда дорогую модель меняют на ещё более дорогую. Мусор остаётся прежним. Только написан увереннее.
Старая модель выдавала ерунду за минуту. Новая думает над ней все 20. Солидно. Сразу видно: reasoning effort расходовали.
Только зря. Контекст, инструменты и проверка не изменились. Получили тот же тупой ответ. Просто ждали дольше.
Перед заменой модели проверьте слабые слои контура:
- ошибка в рассуждении: модель и режим рассуждения;
- выдуманные объекты: контекст, файловый поиск (нашёл ли агент нужный модуль или регистр) и MCP;
- нарушение стандартов: загрузка правил проекта (AGENTS.md, стандарты 1С) и приоритет инструкций;
- отклонённый вызов: sandbox (изолированная среда выполнения) и разрешения (доступ к конфигуратору или EDT, запуск синтаксического контроля);
- победа без доказательств: проверка и критерии готовности (тестовое проведение документа, а не рассказ о нём);
- потерянные решения: состояние задачи и проектная память.
Есть и противоположный ритуал. Можно установить побольше всего. Например, десять MCP-серверов, пятьдесят навыков и конфигуратор с EDT в довесок.
Контекст растёт. Выбор усложняется. Ответ приходится ждать дольше. Всё мигает, токены горят. Документ как не проводился, так и не проводится.
Новый инструмент должен закрывать конкретный дефицит. Он добавляет недостающий факт, разрешённое действие или проверку. Иначе это очередная иконка на рабочем столе.
Инструменты будут меняться. Модель помогает рассуждать. Harness доводит рассуждение до проверяемого действия.
Поэтому harness решает. Но результат принимает разработчик. Он за него и отвечает.
А какой harness у вас?
#статья
TG | YouTube