Зона 5 — Управление процессом (черновик разведки)¶
Собрано 02.09.2026 по рамке razvedka-ramka.md. 19 поисковых запросов (англ. и рус.), источники открывались и читались, а не пересказывались по сниппетам. Где страница не открылась — сказано прямо.
Главный вывод вперёд: зона перестала быть пустой между февралём и июлём 2026. У неё появилось имя — harness engineering, — свой корпус исследований, вакансии с этим словом в названии и первые бенчмарки. Но сопровождение самой методологии как непрерывного процесса с ролями описано пока только у двух источников (Thoughtworks и Сбер), и ни один не приводит чисел по себе.
Найденные подходы¶
1. Harness engineering (Böckeler / Thoughtworks) — рамка «направляющие и датчики»¶
- Кто держит: Биргитта Бёкелер, Distinguished Engineer в Thoughtworks. Опубликовано на сайте Мартина Фаулера — площадка с репутационным весом, не корпоративный блог.
- Источник: https://martinfowler.com/articles/harness-engineering.html — 02.04.2026
- Артефакты: харнес = «всё в агенте, кроме самой модели». Делится на два класса контролей: guides (feedforward) — детерминированный тулинг, документация, скрипты, инструкции, которые предупреждают нежелательный вывод заранее; sensors (feedback) — линтеры, тесты, агенты-ревьюеры, которые дают агенту самокорректироваться. Три категории регуляции: сопровождаемость, архитектурная пригодность, поведенческая.
- Роли (человек / агент): «steering loop» — человек итеративно правит харнес, наблюдая повторяющиеся сбои агента. Агент внутри контура, харнес — снаружи, его правит человек.
- Что отдано агенту: ничего в самом контуре управления; агент — объект регуляции, не её субъект.
- Зрелость: идея с примерами. Названы OpenAI (их публичный опыт) и Stripe с системой «minions». Количественных данных о распространении нет.
- Модель-агностичность: переносим. Рассуждение ведётся про LLM вообще, вендорских зависимостей в несущей конструкции нет.
- Чем подтверждено: мнение практика с примерами. Ценность в том, что статья честно перечисляет, чего в ней нет: стратегия версионирования, модели владения внутри организации, метрики качества харнеса, фреймворки оценки, governance конфигурации. Поведенческую категорию харнеса автор прямо называет нерешённой. Это лучшая из найденных карт белых пятен зоны 5 — и она от апреля 2026.
2. Agent Harness Engineering как зонтичная дисциплина (Osmani / O'Reilly Radar)¶
- Кто держит: Эдди Османи (Google, автор O'Reilly Radar). Термин, по его же указанию, придумал Вивек Триведи (LangChain).
- Источник: https://www.oreilly.com/radar/agent-harness-engineering/ — 15.05.2026
- Артефакты: формула «Агент = Модель + Харнес». В харнес входят системные промпты, инструменты, среда исполнения, оркестрация, хуки, наблюдаемость. Именованные артефакты: AGENTS.md как «чеклист пилота», хуки на точках жизненного цикла (pre-tool-call, post-edit, pre-commit), файловая система и git как долговременное состояние и версионирование, песочницы, компактирование контекста.
- Роли: принцип храповика — «каждая ошибка становится правилом», причём ограничение обязано быть прослежено до конкретного сбоя, а не придумано впрок. Правит человек.
- Что отдано агенту: исполнение внутри харнеса; правка харнеса — за человеком.
- Зрелость: пилоты. Подтверждено данными Terminal Bench 2.0: одна и та же модель (Claude Opus 4.6) внутри Claude Code даёт заметно ниже, чем в кастомном харнесе — то есть харнес весит больше выбора модели. Названы сходящиеся на одних паттернах Claude Code, Cursor, Codex, Aider, Cline.
- Модель-агностичность: переносим, с оговоркой самого автора: co-training приводит к тому, что модель переобучается под харнес, в котором её тренировали.
- Чем подтверждено: обзор практики со ссылками на бенчмарк.
3. Харнес-инжиниринг с измеряемым циклом (LangChain / Триведи)¶
- Кто держит: Вивек Триведи, LangChain. Вендорский материал — весь цикл построен на LangSmith.
- Источник: https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering — 17.02.2026
- Артефакты: трейсы в LangSmith как основной артефакт наблюдения; собственный «Trace Analyzer Skill» для автоматического разбора ошибок по прогонам; middleware-компоненты (PreCompletionChecklist, LoopDetection, LocalContext).
- Роли: рецепт из четырёх шагов, повторяемый: разбор трейсов → точечная правка харнеса (системный промпт, инструменты, middleware) → переоценка на бенчмарке → синтез находок под следующую итерацию.
- Что отдано агенту: разбор ошибок по трейсам — самому агенту через скилл.
- Зрелость: пилот с числами. deepagents-cli: 52,8% → 66,5% (+13,7 п.п.) на Terminal Bench 2.0 (89 задач) без смены модели (GPT-5.2-Codex). Внедрение одно — своё собственное.
- Модель-агностичность: привязан к модели, и авторы это подчёркивают: та же версия харнеса на Claude Opus 4.6 дала 59,6%. Вывод — харнес нужно подгонять под модель, а не переносить.
- Чем подтверждено: практика с измерением, но заинтересованная сторона.
4. Harness engineering у OpenAI (Codex)¶
- Кто держит: OpenAI. Вендорский материал.
- Источник: https://openai.com/index/harness-engineering/ — февраль 2026. ⚠️ Сама страница отдала 403 на попытку чтения; содержание взято из разбора InfoQ: https://www.infoq.com/news/2026/02/openai-harness-engineering-codex (Leela Kumili, 21.02.2026) и упоминания у Бёкелер и Османи.
- Артефакты: карты кодовой базы, планы исполнения, спецификации дизайна; архитектурные границы держатся «механическими правилами» и структурными тестами; жёсткая последовательность зависимостей Types → Config → Repo → Service → Runtime → UI.
- Роли: инженеры проектируют среду, формулируют намерение и дают структурированную обратную связь; агенты Codex пишут код, открывают PR, оценивают изменения, итерируются.
- Что отдано агенту: написание кода целиком.
- Зрелость: пилот с крупными числами, но одно внедрение. Пять месяцев, продуктовая бета примерно на миллион строк, ноль строк написано руками, малая команда, заявленное ускорение ~10×. Внешнего подтверждения нет.
- Модель-агностичность: привязан к Codex в реализации; принципы переносимы.
- Чем подтверждено: кейс одной компании о самой себе. Считать рекламой в части чисел, практикой — в части структуры.
5. Curated shared instructions + Feedback flywheel (Thoughtworks Technology Radar)¶
Единственный из найденных, кто описывает сопровождение методологии как непрерывный цикл с местом человека — то, что спрашивалось в задании прямым текстом.
- Кто держит: Thoughtworks, Technology Radar.
- Источник:
- https://www.thoughtworks.com/radar/techniques/curated-shared-instructions-for-software-teams — кольцо Adopt, впервые ноябрь 2025 (vol. 33), уточнено апрель 2026 (vol. 34)
- https://www.thoughtworks.com/radar/techniques/feedback-flywheel — кольцо Assess, апрель 2026 (vol. 34)
- https://www.thoughtworks.com/radar/techniques/agent-skills — кольцо Trial, vol. 34
- Артефакты: файлы инструкций (CLAUDE.md / AGENTS.md / .cursorrules), уложенные в baseline-репозиторий, из которого скаффолдятся новые сервисы — шаблон становится механизмом распространения ИИ-руководства. Альтернатива: якорить агентов на reference application — живую компилируемую кодовую базу как источник истины по стандартам.
- Роли: цикл маховика — спека → план → реализация → обратная связь → улучшение. Прямая аналогия с ретроспективой: в сессии агента фиксируются успехи и провалы, из них правятся направляющие. Человек — «human on the loop», а не in the loop.
- Что отдано агенту: пока ничего. Thoughtworks отдельно оговаривает, что «агентный маховик», где агент сам решает, что в себе править, существует, но к общему применению не рекомендуется — риск context rot и шумной обратной связи, уводящей агента.
- Зрелость: промышленная практика в части инструкций (кольцо Adopt означает «применяем на проектах по умолчанию» — у Thoughtworks это сотни клиентских команд), идея в части маховика (Assess). Отдельно: опора на индивидуальные промпты каждого разработчика объявлена антипаттерном.
- Модель-агностичность: переносим, техника формулируется через формат файла, а не через платформу.
- Чем подтверждено: практика консалтинга. Численных кейсов на страницах нет — это структурная слабость Радара как источника.
- Отдельная оговорка Thoughtworks по скиллам: переиспользование чужих скиллов без ревью названо серьёзным риском цепочки поставок; маркетплейсы плагинов появились как механизм версионирования, но стратегия версионирования не проработана.
6. AGENTS.md как объект управления — стандарт, и эмпирика против него¶
Самый интересный сюжет зоны: формат стал стандартом раньше, чем кто-либо проверил, работает ли он.
6a. Стандарт - Кто держит: Agentic AI Foundation под Linux Foundation. Возник из совместной работы команд OpenAI Codex, Amp, Jules, Cursor, Factory. - Источник: https://agents.md/ — версии и даты спецификация не несёт. - Артефакты: один markdown-файл в корне репозитория. Обязательных полей нет вообще — «просто markdown, агент читает текст». - Зрелость: промышленная практика по распространению: 60 000+ открытых проектов, поддержка примерно двадцатью инструментами (Codex, Jules, Cursor, Factory, Aider, Copilot Coding Agent, VS Code, JetBrains Junie и др.). - Модель-агностичность: переносим по построению — это и есть его назначение. - Чем подтверждено: практика распространения. Процесса управления и версионирования у стандарта нет — это дыра, а не деталь.
6b. Что реально в этих файлах лежит - Galster M., Mohsenimofidi S., Lulla J.L., Abubakar M.A., Treude C., Baltes S. «Harness Engineering for Agentic AI Coding Tools: An Exploratory Study». https://arxiv.org/abs/2602.14690 — подано 16.02.2026, финал 30.06.2026, конференция AIware 2026 (ACM/IEEE). - 2 853 репозитория GitHub, пять инструментов (Claude Code, Copilot, Cursor, Gemini, Codex). Восемь механизмов конфигурации — от статического контекста до исполняемого и внешних интеграций. Контекстные файлы доминируют и часто единственные. Skills и субагенты почти не используются, а если используются — то со статическими инструкциями, а не исполняемыми скриптами. AGENTS.md складывается в межинструментальный стандарт «снизу», органически. - Это база отсчёта: то, что в отраслевых текстах описано как норма (скиллы, хуки, субагенты), в поле почти не встречается.
6c. Эмпирика против - Gloaguen T., Mündler N., Müller M., Raychev V., Vechev M. (SRI Lab, ETH Zürich). «Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?» https://arxiv.org/abs/2602.11988 — февраль 2026. - Вывод: контекстные файлы в общем случае не улучшают долю решённых задач, при этом поднимают стоимость инференса более чем на 20% в среднем. Держится на разных LLM, разных агентах и как для сгенерированных LLM файлов, так и для написанных разработчиками. - Разбор HumanLayer (Kyle, @0xblacklight, https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents, 12.03.2026 — вендорский блог) добавляет цифры того же ряда со ссылкой на ту же группу ETH: 138 agentfiles; сгенерированные LLM вредят и стоят дороже; написанные человеком помогают примерно на 4%; агент тратит на 14–22% больше токенов рассуждения на обработку инструкций.
6d. Конфигурационные запахи - dos Santos H.V.F., Costa V., Montandon J.E., Silva L.L., Valente M.T. «Configuration Smells in AGENTS.md Files». https://arxiv.org/abs/2606.15828 — июнь 2026. Каталог антипаттернов + предложение автоматических детекторов, то есть линтера на файл инструкций. - Hong D.B., Imani A., Ahmed I. «From Anatomy to Smells: An Empirical Study of SKILL.md in Agent Skills». https://arxiv.org/abs/2607.01456 — 01.07.2026. 238 реальных скиллов, таксономия из 13 семантических компонентов и 44 подкомпонентов. Более 99% файлов SKILL.md содержат хотя бы один запах, и качество не улучшается по мере эволюции скилла.
- Зрелость связки 6b–6d: промышленная практика в измерении — три независимые группы (ETH Zürich, Bamberg/Adelaide, UFMG, UC Irvine), выборки в тысячах репозиториев и сотнях файлов.
- Чем подтверждено: рецензируемые исследования, не заинтересованные в платформе.
7. Эвалы на конфигурацию агента как регресс-тест¶
Прямое продолжение того, что в разобранном плейбуке Anthropic названо «конфигурация агента — это код, которому положен регресс». Здесь — конкретные реализации.
7a. Skill Eval (Гечев) - Кто держит: Минко Гечев (известен по Angular-команде Google), личный блог. - Источник: https://blog.mgechev.com/2026/02/26/skill-eval/ — 26.02.2026 - Артефакты: TypeScript-фреймворк; тест-кейс = самодостаточная директория с конфигом задачи (таймауты, грейдеры, лимиты ресурсов), инструкциями агенту, окружением, детерминированными shell-грейдерами и LLM-рубриками, эталонным решением. Прогон в Docker. Отчёты JSON + веб-дашборд. - Роли: метрики pass@k (получилось хоть раз) и pass^k (получается стабильно) — прямое различение «умеет» и «делает надёжно». - CI: пример GitHub Actions, запуск на PR, затрагивающих скиллы; рекомендация — минимум 5 прогонов на изменение скилла. - Зрелость: идея с работающим инструментом, внедрений не названо. - Модель-агностичность: переносим — поддержаны Gemini, Antigravity, Claude.
7b. Пирамида тестов харнеса (Ранджан Кумар)
- Источник: https://ranjankumar.in/claude-code-testing-your-setup — 15.07.2026
- Артефакты: три уровня по аналогии с пирамидой тестирования — hook tests (shell, быстрые), skill evals (средние), workflow evals (медленные, гоняют всю связку CLAUDE.md + скиллы + хуки + субагенты против канонической задачи через claude -p, судья — LLM по взвешенной рубрике). История в .claude/eval-results/history.jsonl с привязкой к версии, расследования регрессий в .claude/audit.jsonl. CI — GitHub Actions, еженедельный прогон (~20 минут), автосоздание issue при пробитии порога.
- Числа: стоимость пяти workflow-эвалов оценена в $0,40–0,80 в неделю. Автор приводит кейс: между мартом и апрелем 2026 Claude Code измеримо просел; команды с workflow-эвалами заметили за 72 часа, остальные — через шесть недель. Кейс не подтверждён вторым источником.
- Зрелость: идея с одним рассказанным кейсом.
- Модель-агностичность: привязан к Claude Code — требует CLI, формата skill-creator и моделей Anthropic; паттерны переносимы.
- Дрейф конфигурации как явление сформулирован там же: несколько инженеров дописывают в CLAUDE.md, правятся скиллы и хуки, полный прогон не гоняется — и конфигурация уезжает от состояния, которое работало.
8. Замкнутый цикл «ревью → правило» (Aggarwal & Ghalaty)¶
Самая близкая к нашему rule-intake конструкция из найденных, и единственная с внедрением на реальном масштабе.
- Кто держит: Aditya Aggarwal, Nahid Farhady Ghalaty.
- Источник: https://arxiv.org/abs/2607.13091 «Self-Improving AI Coding Agents Through Accumulated Behavioral Rules: A Closed-Loop Framework» — 13.07.2026
- Артефакты: три штуки, названные явно — (1) версионируемый файл инструкций с накапливающимся набором правил; (2) чеклист самопроверки, исполняемый агентом до сдачи кода; (3) автоматическая валидация целостности набора правил.
- Роли: человек даёт ревью; каждое принятое замечание ревью кодифицируется в устойчивое правило поведения, расширяя класс ошибок, которые агент детектирует у себя сам.
- Что отдано агенту: самопроверка по чеклисту перед сдачей.
- Зрелость: пилот с числами. Платформа из 35+ микросервисов. Набор вырос с 5 до 18 поведенческих правил + 15+ языковых стандартов + чеклист из 15 пунктов. По 11 записанным сессиям: 0% повторения классов ошибок, на которые есть правило; ревью сместилось с низкоуровневой корректности на валидацию дизайна; правила перенеслись между разными агентными интерфейсами.
- Модель-агностичность: переносим — перенос правил между интерфейсами агентов заявлен как результат.
- Чем подтверждено: кейс одного внедрения, оформленный как исследование.
9. Автоэволюция харнеса (Lin et al., Fudan / ByteDance-круг)¶
Крайняя точка шкалы: харнес правит не человек, а агент.
- Кто держит: Jiahang Lin, Shichun Liu, Chengjun Pan, Lizhi Lin, Shihan Dou, Zhiheng Xi, Xuanjing Huang, Hang Yan, Zhenhua Han, Tao Gui, Yu-Gang Jiang.
- Источник: https://arxiv.org/abs/2604.25850 «Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses» — 28.04.2026
- Артефакты: три вида наблюдаемости. Компонентная — каждый правимый компонент харнеса получает файловое представление, пространство действий становится явным и обратимым. Опытная — сырые трейсы конвертируются в слоистый корпус свидетельств, который читает эволюционирующий агент. Решенческая — каждая правка сопровождается самозаявленным предсказанием, проверяемым по исходу последующих задач. Правка становится фальсифицируемым контрактом, а не пробой наугад.
- Роли: человеческий харнес — только затравка. Дальше цикл идёт без человека.
- Зрелость: идея, проверенная на бенчмарке. Terminal-Bench 2: 69,7% → 77,0% pass@1 за десять итераций, выше человеческого Codex-CLI (71,9%) и самоэволюционирующих бейзлайнов. SWE-bench-verified: лучший результат при на 12% меньшем расходе токенов. Перенос на другие семейства моделей: +5,1…+10,1 п.п.
- Модель-агностичность: заявлена и проверена кросс-семейным переносом.
- Чем подтверждено: исследование на бенчмарках. Промышленных внедрений нет.
- ⚠️ Ровно то, что Thoughtworks помечает «пока не рекомендуем» (см. п.5).
10. Как меряют качество харнеса: бенчмарки, а не метрики¶
Прямой ответ на вопрос «чем меряют качество харнеса»: устоявшейся производственной метрики нет, есть исследовательские бенчмарки.
- Harness-Bench. Yao Y., Tan X., Liu C.-H., Li Y., Wang Z., Yu W., Tan Z., Tian Y., Zhao G., Sun L., Zhang X., Yang T. https://arxiv.org/abs/2605.27922 — 27.05.2026. 106 задач в песочнице, 5 194 траектории, несколько бэкендов и конфигураций харнеса. Оценка — по итогу И по трассе: детерминированные валидаторы + LLM-рубрики на устойчивость, уместность использования инструментов, консистентность. Главный вывод: способность агента следует заявлять на уровне пары «модель+харнес», а не приписывать модели.
- The Scaffold Effect in Coding Agents. https://arxiv.org/abs/2607.22585 — июль 2026. Метрики за пределами «решил/не решил»: качество взаимодействия, нагрузка надзора, проверяемость; потокенное измерение по задаче, число ходов, простой, состав режимов отказа. Terminal-Bench Pro, 50 задач в 8 доменах. Страницу не открывал целиком — данные из выдачи; ссылку проверил, работает.
- Don't Blame the Large Language Model: How Scaffolding Evolution Shapes Coding Agent Quality. https://arxiv.org/abs/2607.03691 — июль 2026. Качество агента по двум осям: результативность и эффективность потребления ресурсов.
- Зрелость: пилоты/исследования. Ни один из бенчмарков не описан как принятый в компании операционный контроль.
- Модель-агностичность: переносимы по построению — они именно про отделение вклада харнеса от вклада модели.
11. Организационная память для агентов (RAG как процесс, а не архитектура)¶
- Кто держит: Lukas Kirchdorfer, Adrian Rebmann, Christian Warmuth, Timotheus Kampik, Theiss Heilker, Gregor Berg. Состав авторов указывает на исследовательский контур SAP, но аффилиации на странице abs я не подтвердил — пишу как есть.
- Источник: https://arxiv.org/abs/2607.03228 «Organizational Memory for Agentic Business Process Execution» — 03.07.2026
- Артефакты: организационная память определена как «разделяемый, управляемый и потребляемый агентом слой эволюционирующего процедурного знания организации о том, как работа должна выполняться». Предложены выведенные требования + архитектура отдельно для курирования и отдельно для потребления.
- Роли: явная постановка проблемы — зашивать знание в отдельные промпты в enterprise не масштабируется: возникают силосы знаний, дубли правил, невозможно согласованно обновлять и учиться поперёк агентов. Это и есть аргумент за отдельный процесс сопровождения хранилища.
- Зрелость: идея с proof-of-concept на закупочном сценарии. Чисел нет.
- Модель-агностичность: переносим.
- Смежное: «Managing Agentic Memory is a New Job for Specialized Memory Agents» (HackerNoon) прямо формулирует, что курирование, сверка, консолидация, брифинг и провижининг памяти — это непрерывная квалифицированная работа, и конечная точка — выделенный агент, чья единственная функция — управлять памятью других агентов, как в зрелых организациях у делопроизводства, комплаенса и управления знаниями есть свои роли. Это мнение, не практика.
12. Разрастание правил как болезнь: «index sickness»¶
Единственный найденный источник, где предметом является деградация самого свода правил, а не агента.
- Кто держит: Hui Zhang, Shuren Song.
- Источник: https://arxiv.org/abs/2606.19121 «Written by AI, Managed by AI: Semantic Space Control and Index Sickness Elimination Across 391 Consecutive Sessions» — подано 17.06.2026, ревизия 19.06.2026, заявлено на трек ICSE 2027 IOR.
- Механизм: при разрастании символьной системы ограничений LLM не становится точнее — она бросает понимание бизнес-семантики и уходит в самореферентное рассуждение внутри символьного слоя, выдавая внешне логичный, но оторванный от условий результат. Каноническое проявление названо «Phantom Legislation» — агент ссылается на правила, которых нет.
- Артефакты: механизм «Baseline-Log Physical Separation» — физическое разделение базового описания и журнала. Опорный принцип: естественный язык с явно названной целью несёт больше информации, чем символьное представление.
- Зрелость: пилот-одиночка. Action research, около месяца, 391 сессия в проекте Bang-v3. Результат: объём инструкций агенту сокращён примерно на 75%, рецидивов болезни не было на протяжении последующих ~150 сессий.
- Модель-агностичность: переносим.
- Чем подтверждено: одно наблюдение одной команды над собой. Но это единственная найденная работа, которая ставит вопрос «когда правил становится слишком много» количественно.
13. Prompt governance: критика самого допущения (FAccT 2026)¶
- Кто держит: Anna Neumann, Holli Sargeant, Jatinder Singh. Принято на ACM FAccT 2026 — рецензируемая конференция по справедливости и подотчётности.
- Источник: https://arxiv.org/abs/2606.07539 «Prompt Governance? On Governing Technologies Governed by Natural Language» — подано 29.04.2026
- Что делает: разбирает, можно ли вообще считать текстовые инструкции — промпты, системные директивы — средством управления поведением системы. Три части: обзор литературы; анализ двух политических рамок (американский Executive Order о «Preventing Woke AI» и EU General-Purpose AI Code of Practice); сопоставление академических утверждений с допущениями регуляторов.
- Вывод: литература фрагментирована и содержит противоречащие друг другу утверждения, что подрывает трактовку промпта как устойчивого и надёжного механизма контроля.
- Зрелость: идея / критика, но с академическим весом.
- Модель-агностичность: полная.
- Почему важно для нас: это единственный найденный источник, который бьёт по фундаменту зоны 5. Если написанное в CLAUDE.md не является надёжным контролем — вся дисциплина версионирования инструкций упирается в потолок, и остаётся то, что в плейбуке Anthropic названо «хук — закон». Держать как контраргумент, а не как метод.
14. Agent governance: политики, аудит, разделение обязанностей¶
- Кто держит: IMDA, Сингапур (регулятор).
- Источник: https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf — Model AI Governance Framework for Agentic AI, объявлен 22.01.2026 на ВЭФ министром Джозефин Тео; обновлён 20.05.2026 с учётом отраслевой обратной связи и с добавлением кейсов. Пресс-релиз: https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai
- Артефакты: четыре измерения — (1) оценка и ограничение рисков, (2) обеспечение осмысленной человеческой подотчётности, (3) технические контроли и процессы, (4) ответственность конечного пользователя. Требование: у каждого агента — верифицируемая цифровая идентичность и аудиторский след того, кто под чьей авторизацией действовал. Рекомендовано моделирование угроз, включая отравление памяти, злоупотребление инструментами, компрометацию привилегий.
- Зрелость: регуляторная рамка, соблюдение добровольное; организация всё равно отвечает за поведение своих агентов. Первая в мире рамка именно под агентов.
- Модель-агностичность: полная.
- Чем подтверждено: документ регулятора + разборы юрфирм (Bird & Bird, Mayer Brown, Baker McKenzie) — то есть его читают всерьёз те, кому за это платят.
- ⚠️ В выдаче также фигурировала NIST AI Agent Standards Initiative (февраль 2026) с тезисом «агентов обычно заводят как обычные сервисные учётки, без выделенной идентичности, авторизации и подотчётности». Первоисточник NIST я не открыл — тезис пришёл из вендорского блога. Требует проверки перед использованием.
15. Русскоязычный контур: Сбер, «AI-Disrupt PDLC»¶
Единственный найденный русскоязычный материал, который вообще ставит вопрос управления самой методологией, а не пересказывает англоязычные практики.
- Кто держит: Кирилл Меньшов, старший вице-президент Сбера, глава блока «Технологии». Полное название: «Стратегия AI-трансформации бизнеса: от кода к намерению».
- Источник: представлен на ЦИПР-2026 в Нижнем Новгороде 19.05.2026. Версия 2.0 — конец июня, представлена в начале июля на «Иннопроме» (https://ria.ru/20260707/sber-2103264660.html). Разборы, по которым читал: https://habr.com/ru/companies/oleg-bunin/articles/1038588/ и https://vc.ru/ai/3049308-ai-disrupt-pdlc-2-0-transformatsiya-razrabotki-po-v-sbere (Сергей Попов, 28.07.2026). Формы документа: краткий PDF на 28 страниц и расширенный .docx на 337 тыс. знаков; v2.0 — около 175 страниц.
- Артефакты, относящиеся к зоне 5:
- Context Supply Chain — управление контекстом как артефактом с версионированием. Прямое имя для того, чего нет ни у AGENTS.md, ни у Thoughtworks.
- Policy as Code — политики встроены в микроциклы агентов автоматическими проверками; отдельно разведены policy enforcement (обязательное) и context-as-guidance (рекомендательное).
- Governance Mesh — параллельный слой по трём измерениям: Quality, Permission/Policy, Audit/Compliance, работающие одновременно, а не последовательно. Обоснование: скорость AI-разработки делает post-hoc валидацию несоизмеримой с темпом появления рисков — прямой удар по классическому ITIL/ITSM.
- Guardian Agents — надзор одних агентов за другими, зрелость T1–T5.
- Session Handoff Protocol (в v2.0):
init.sh,progress.md,feature-list.json, указатель на Evidence Bundle. - CLAUDE.md как конфигурация агента (с требованием подписанного payload) и AGENTS.md как версионируемый код.
- Лестница автономии R0–R5; текущее состояние Сбера — R2 (supervised automation), цель — R5; отдельно оговорено, что через ступени прыгать нельзя.
- Роли: двухпетлевая модель — Intent Loop (человек, такт в днях) и Implementation Loop (агенты, такт в минутах), связанные через Integrated Development Platform. В v2.0: джуниоры переходят от написания кода к черновикам спецификаций, разработке эвалов и курированию паттернов — то есть работа над харнесом названа джуниорской ролью. Принцип валидации: «на каждый X, вложенный в исполнение, — 0,5X в валидацию».
- Числа: 98% ценности агента дают детерминированная обвязка, 2% — логика модели. 93% запросов на разрешение человек подтверждает автоматически. Мультиагентная архитектура ест в 15× больше токенов, чем чат; выбор модели экономит 60–70% токенов; кэширование инструкций даёт 10× по стоимости. GigaCode: 14 000 разработчиков, 80% дневных пользователей, доля принятого AI-кода 45% → 69% за 2025 год, в декабре 2025 впервые закрыт полный релиз без ручного кода. Онбординг: 71 день (2024) → 36 дней (2026). Скорость кодирования +35% при росте уязвимостей +25%. Бинарный выбор на входе: адаптация (старый процесс + новые инструменты) даёт +11–25%, перепроектирование под агентов — +25–50%+. В v2.0: стоимость своей IDP — 12–18 месяцев и 3–5 инженеров, рост производительности 30–50%, окупаемость 12–24 месяца при 10+ командах, против $1–3 млн в год на вендорские лицензии.
- Регуляторный слой (v2.0): восемь политических модулей, замапленных на 152-ФЗ и требования ЦБ 683-П и 757-П. Аналога в англоязычных источниках нет.
- Зрелость: промышленная практика в части GigaCode (числа по 14 000 разработчиков), пилот в части самой методологии. Критично: разбор Попова отдельно отмечает, что при 175 страницах методологии собственные метрики внедрения Сбера в документе отсутствуют, а из v1.0 в v2.0 три активно цитировавшиеся цифры были заменены на более осторожные формулировки.
- Модель-агностичность: методология переносима; реализация завязана на GigaCode/GigaChat и российский регуляторный контур.
- Чем подтверждено: вендорский документ вендора-гиганта. Числа по GigaCode — практика, числа по методологии — заявление.
- Прочий русский контур — заметно жиже: Habr Cloud.ru (sir-off) про контекст-инжиниринг для coding-агентов — практическое руководство про CLAUDE.md, task.md, handoff-документы, но без ролей, версионирования и чисел; Альфа-Банк (Виктория Золотарёва, 15.07.2026, https://habr.com/ru/companies/alfa/articles/1059296/) — четыре кейса аналитика с агентами, style guide на тип артефакта, рабочие файлы README.md / open-questions.md / findings.md, принцип «неопределённость не выше 0,1», из чисел только «задачи на ~5 story points сжались до 1–2 с учётом проверки». Отдельной роли за харнес в российских публикациях не нашлось.
16. Роль в компании: она появилась, и называется по-разному¶
- Что нашлось прямыми вакансиями (июль 2026 и раньше):
- Cursor / Anysphere — «Software Engineer, Agent Harness»: поведение агента, оркестрация, инструменты, guardrails, тюнинг поведения модели (https://cursor.com/careers/software-engineer-agent-harness, май 2026)
- Intel — «Software Engineer, Agent Harness»: агентный цикл — планирование, вызов инструментов, обработка наблюдений, ретраи, терминация (июнь 2026)
- Instabase — «Staff AI Engineer, Agent Harness»: среда исполнения как «агентная ОС предприятия», от 6 лет опыта (июль 2026)
- Geniee (Япония) — «Agent Harness Engineer», от 5 лет бэкенда на Python (апрель 2026)
- Важная оговорка: все четыре — продуктовые роли (строят харнес как продукт для внешних пользователей), а не внутренние роли «кто у нас в компании отвечает за CLAUDE.md и своды правил». Внутренней роли с устоявшимся названием я не нашёл — см. раздел «Что искал и не нашёл».
- Второй кандидат на имя — context engineer. Ряд обзоров (Atlan, ODSC, ZipRecruiter) описывает его как самый быстрорастущий ИИ-титул 2026 года, с формальным определением Gartner, вилкой $84–135k (июль 2026) и позиционированием «между дата-инжинирингом, дата-говернансом и AI/MLOps». Названы Adobe и Stripe как нанимающие. Всё это обзорные материалы и агрегаторы вакансий, не первичные источники — считать сигналом рынка, а не подтверждённой практикой.
- Третий кандидат — вендорский. Augment Code (Paula Hingel, 16.05.2026, обновлено 18.06.2026, https://www.augmentcode.com/guides/agentic-engineering-operating-model) перечисляет шесть новых ролей: Agent Orchestration Engineer, Agent Reliability Engineer, AI Workflow Designer, Context Engineer, AI Governance Owner, Agent Evaluation Engineer. Плюс три яруса полномочий: Tier A только человек (архитектура, политика безопасности, определение области действия агента), Tier B с помощью агента (требования, дизайн, апрув мёрджа), Tier C автономно (юнит-тесты, скаффолдинг, рутинный CI/CD в границах политики). Это маркетинг под свою платформу Cosmos: LinkedIn, Red Hat и Google упомянуты без метрик, а кто именно сопровождает харнес — в тексте не сказано, что для «операционной модели» показательный пропуск.
Что искал и не нашёл¶
1. Роль «владелец харнеса» внутри компании — не нашёл.
Запросы: "harness engineer" OR "agent experience engineer" job posting hiring team owns skills hooks rules company, "AI enablement" team role platform engineering for coding agents ownership 2026 case study, "ways of working" AI agents continuous methodology maintenance role process owner "agentic operating model" 2026.
Вернулось вместо: продуктовые вакансии в Cursor/Intel/Instabase/Geniee (строят харнес на продажу), обзоры «профессии будущего» и вендорские списки ролей без имени ответственного. Единственная содержательная реплика — от The New Stack: платформенные команды тянут две дорожки сразу, «AI-enhanced platform» и «platform-for-AI»; и там же различение — платформенный инжиниринг строит золотые пути, а AI enablement это человеческий навык направлять агента, «общее у них только слово». Ни одного описания «в компании X за файлы правил отвечает Y, ревью проходит так-то» не найдено.
2. Метрика качества харнеса, применяемая в производстве, — не нашла себя.
Запрос: measuring harness quality metrics coding agent "eval" instruction file impact benchmark study.
Вернулись только исследовательские бенчмарки (Harness-Bench, Scaffold Effect, Don't Blame the LLM) — то есть измеряют исследователи для сравнения, а не команды для управления. Бёкелер прямо признаёт, что метрик качества харнеса в её статье нет.
3. Версионирование инструкций как отдельная дисциплина — не нашёл; нашёл соседнее.
Запрос: prompt versioning governance "prompts as code" review CI change management LLMOps practice 2026.
Вернулось: рынок инструментов управления промптами (Maxim, MLflow, TrueFoundry, Bedrock Prompt Management, Azure Prompt Flow, Vertex Prompt Optimizer) и общая формула LLMOps «промпт — версионируемый артефакт, PR-ревью, тесты, откат; эвал-набор гоняется в CI на каждое изменение промпта или агента, билд падает на регрессии». Это обзоры инструментов, а не описанный процесс, и по рамке в отчёт не берутся. Единственное именованное решение задачи версионирования контекста — сберовский Context Supply Chain, и он описан на уровне названия.
4. RAG как процесс с ролями — почти пусто.
Запрос: RAG as a process not architecture ownership lifecycle knowledge base curation who maintains retrieval corpus enterprise.
Вернулись обзоры архитектуры и общие слова про «политику курирования корпуса», «экспертную валидацию, скоринг, дедупликацию», «типы документа, теги подсистем, интервалы валидности». Единственная работа с выведенными требованиями и архитектурой курирования — arXiv 2607.03228 (п.11), и та на уровне proof-of-concept.
5. Сопровождение методологии как непрерывный процесс с ролями — нашлось у двоих, не у отрасли. Thoughtworks (feedback flywheel, кольцо Assess) и Сбер (Governance Mesh + двухпетлевая модель). Всё остальное — либо разовая настройка («напишите хороший AGENTS.md»), либо governance-рамки про поведение агентов в проде, а не про сопровождение самих инструкций.
6. NIST AI Agent Standards Initiative — тезис встретился, первоисточник не открывал. Не использовать без проверки.
7. Страница OpenAI про harness engineering — вернула HTTP 403. Содержание взято из вторичного разбора InfoQ, что понижает достоверность деталей (числа «миллион строк», «пять месяцев», «10×» пришли через посредника).
Пересечения с уже разобранным плейбуком Anthropic¶
- П.7 (эвалы на конфигурацию) пересекается с разобранным плейбуком Anthropic в части «конфигурация агента — это код, которому положен регресс». Плейбук задаёт норму (20–50 задач, прогон на любое изменение CLAUDE.md/скиллов/хуков, ревью падения доли прохождения до мёржа); Гечев и Ранджан Кумар дают реализацию — Docker-изоляция, pass@k против pass^k, три уровня пирамиды, JSONL-история с привязкой к версии, недельный крон. Новое относительно плейбука: различение «умеет» и «делает стабильно», и наблюдение про дрейф конфигурации от множественных дописываний.
- П.1 (guides/sensors у Бёкелер) пересекается с плейбуком в части «скилл — совет, хук — закон». Формулировки независимые и совпадающие по смыслу: feedforward-контроль предупреждает, feedback-контроль ловит. У Бёкелер шире — она включает в feedforward и документацию, и детерминированный тулинг, и относит к нерешённому именно поведенческую категорию, которой у Anthropic соответствует REVIEW.md с капом на придирки.
- П.15 (Сбер) пересекается с плейбуком в части ярусов автономии и разделения обязанностей. У Anthropic — сигмы (1σ лог, 2σ read-only диагностика, 3σ право открыть PR или запустить одобренный runbook) и правило «агент, написавший код, не имеет способа его одобрить». У Сбера — лестница R0–R5 с запретом прыгать через ступени и Guardian Agents T1–T5. Конструкция одна, шкалы разные. Новое у Сбера: Governance Mesh как параллельный, а не последовательный слой, и явный аргумент против ITIL/ITSM по темпу.
- П.15 пересекается с плейбуком в части «один источник истины на артефакт» — сберовский Session Handoff Protocol (init.sh, progress.md, feature-list.json, указатель на Evidence Bundle) это тот же ход, что цепочка
intent.md → spec.md → plan.md, но с явно названным протоколом передачи между сессиями, а не между стадиями. - П.5 (curated shared instructions) пересекается с плейбуком в части петли артефактов, добавляя то, чего у Anthropic нет: механизм распространения. Инструкции кладутся в baseline-репозиторий, из которого скаффолдятся сервисы, — и обновление шаблона расходится по всем новым репозиториям само. Плейбук вопрос «как одна и та же политика попадает в сорок команд» не поднимает.
- Не пересекается и стоит особняком: п.6c (эмпирика ETH Zürich). Плейбук исходит из того, что хорошо написанная конфигурация работает. Исследование на разных LLM и агентах показывает, что контекстные файлы в общем случае долю решённых задач не поднимают, а стоимость поднимают на 20%+. Это прямой контрудар по несущей предпосылке всей зоны, и в базе его нет.
- Не пересекается: п.13 (prompt governance). Плейбук лечит ненадёжность инструкции хуком. FAccT-работа спрашивает, можно ли вообще считать текст средством управления — и отвечает, что литература по этому вопросу противоречива. Аргумент того же направления, но на уровень глубже.
Общая оценка зоны¶
Зрелость зоны: пилоты, с одной полосой промышленной практики и одной — промышленного измерения.
Разбор по слоям:
- Распространение файлов инструкций — промышленная практика. 60 000+ репозиториев с AGENTS.md, ~20 инструментов, стандарт под Linux Foundation, 2 853 репозитория в академической выборке, кольцо Adopt у Thoughtworks. Тут спорить не о чем.
- Измерение зоны — промышленная практика в исследовательском смысле. Четыре независимые группы (ETH Zürich, Bamberg/Adelaide, UFMG, UC Irvine, плюс Harness-Bench) с выборками в тысячах репозиториев и тысячах траекторий. За полгода зона обзавелась корпусом эмпирики — редкость для темы такого возраста.
- Сопровождение методологии как процесс — идея с двумя пилотами. Thoughtworks (feedback flywheel, Assess) и Сбер (Governance Mesh). Ни у одного нет чисел по себе.
- Роль владельца харнеса — рынок труда её нащупал, компании внутри себя — нет. Вакансии есть, но все продуктовые. Внутренней роли с именем не найдено.
- Метрика качества харнеса — отсутствует как производственный инструмент. Бёкелер называет это дырой в апреле, к сентябрю дыра на месте.
Три вещи, которые в зоне сложились быстрее, чем ожидалось:
- Слово. «Harness engineering» за полгода прошло путь от блога HumanLayer (март) до вакансий в Intel и Cursor и до статьи Фаулера. Термина, конкурирующего за то же место, нет.
- Разделение вклада модели и вклада обвязки. Harness-Bench и The Scaffold Effect ставят одно и то же требование: способность агента заявлять на уровне пары «модель+харнес». LangChain меряет это на себе: +13,7 п.п. без смены модели, и −6,9 п.п. при смене модели без правки харнеса. Сбер оценивает вклад обвязки в 98%. Цифры разного качества, направление одно.
- Разворот от «пишите больше инструкций» к «пишите меньше». ETH Zürich: контекстные файлы не помогают и стоят 20%+. Zhang & Song: −75% объёма инструкций и болезнь ушла. HumanLayer: рекомендуют ~60 строк. Хуже 2603-го года совет «опишите агенту всё» уже не выглядит нейтральным.
Главное натяжение зоны, которое стоит держать в голове: между «правило как способ управления» и эмпирикой, которая говорит, что правила не работают так, как предполагается (п.6c, п.12, п.13). Отрасль отвечает на это тем же ходом, что и плейбук Anthropic: перевести обязательное в детерминированный слой (хук, policy-as-code, структурный тест), оставив тексту рекомендательную роль. У Сбера это разведено терминологически — policy enforcement против context-as-guidance. Это, пожалуй, самая полезная формулировка, привезённая разведкой по зоне 5.
Что в зоне ещё не написано и написать некому: как ревьюят изменение свода правил, кто подписывает, что происходит при конфликте двух правил, как правило устаревает и удаляется. Единственная работа, которая подходит к этому близко — Aggarwal & Ghalaty (п.8) с автоматической валидацией целостности набора правил, — и та описывает 18 правил на 35 сервисов. Процедуры вывода правила из обращения нет ни у кого.