62 тем инженерной практики. Для каждой — зачем следить, на что опирается исследование и что проверить самому.
Исследовательский предпросмотр
Шесть секторов обозначают направления. В этом варианте расстояние от центра показывает только роль темы в исследовательском охвате. Доказательная орбита и балл не назначены.
Выберите горизонт: Радар подсветит темы для чтения, опыта или наблюдения. Это редакционные гипотезы, не прогноз рынка.
Карта исследовательских тем
Секторы — предметные области. В этом макете радиус показывает качественную роль темы, а не измерение роста, зрелости или пользы.
01 · у центра опорные · 4002 · средняя полоса проявленные · 1203 · снаружи ранние гипотезы · 10
Режим исследовательского расположения. В принятом выпуске радиус снова будет означать глубину доказательств конкретного тезиса: «Заявлено → Воспроизведено → В работе». Ни одной из 62 тем эта орбита пока не назначена.
Прокрутите карту по горизонтали или переключитесь на «Список».
ТЕМ В ОБЗОРЕ 62
Темы не найдены
Измените запрос или направление.
Как читать карту
Что означают секторы, радиус и горизонты?
Сектор означает одно из шести направлений. В этом исследовательском варианте расстояние от центра обозначает роль темы: опорная, проявленный сигнал или ранняя гипотеза. Роли взяты из предложения по охвату; это не числовая шкала, не стадии зрелости и не оценка полезности. В принятом выпуске радиус означает глубину доказательств конкретного тезиса: снаружи «Заявлено», далее «Воспроизведено», внутри «В работе». Ни одна из 62 тем пока не получила такую орбиту.
Горизонты «месяцы / год / 3–5 лет» — отдельные редакционные гипотезы о полезном следующем решении, не календарные периоды наблюдения и не прогноз рынка. «Проверить» означает ограниченный опыт, а не рекомендацию внедрить. Доказательные орбиты и баллы требуют отдельного решения редактора. Миссия и критерии Радара ↗.
Все 62 исследовательские карточки
Тезисы и источники доступны и без JavaScript. Орбиты, баллы и подписи редактора пока не назначены.
A01 · Терминальные агенты для работы с кодом
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Терминальный coding agent способен читать репозиторий, менять файлы и вызывать команды в одном рабочем цикле; документация Claude Code описывает возможности, но не доказывает выигрыш принятого результата против человека на наших задачах.
Когда применимо: Команда выбирает способ выполнять повторяемые исправления в репозитории с тестами и review.
Область версии: Документальный снимок https://code.claude.com/docs/en/overview на 2026-10-16T14:41:10.577569+00:00; SHA-256 тела 88ffea5e5e0edff179e042e40c7a4b1306e73616ed32031549c6b1bd95067b2b. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 88ffea5e5e0edff179e042e40c7a4b1306e73616ed32031549c6b1bd95067b2b
Свидетельства, ограничения и следующий шаг
Первоисточники
claude-code · Описание terminal agent и доступных операций над кодом.
Не подтверждает: Прирост качества, скорость принятой задачи и число дефектов на нашем репозитории.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Сравнение по времени генерации не учитывает ревью, исправления и откат.
Следующее действие: Взять один уже принятый PR: сопоставить время генерации с ревью, исправлениями и откатом; решить, есть ли у команды повторяемые задачи для ограниченного опыта.
Когда остановиться: Скорость генерации выше, а полное время или дефекты хуже.
Необязательный план опыта
Вход: На 20 заранее размеченных исправлениях записать принятое изменение, дефекты, полное время человека и расход модели.
Контроль: Те же задачи вручную при одинаковых тестах и критериях приёмки.
Успех: Больше принятых исправлений на час человека без роста критических дефектов.
Сигнал отказа: Скорость генерации выше, а полное время или дефекты хуже.
До самостоятельной рекомендации: Нет закреплённых модели, версии CLI, задач и слепого ревью.
A02 · Агент внутри IDE и управляемое применение diff
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: IDE-клиент по Agent Client Protocol может показывать ход агентной работы и патчи внутри редактора; преимущество управляемого diff перед терминальным режимом пока не измерено.
Когда применимо: Команда уже использует одного и того же агента в IDE и CLI и выбирает интерфейс для проверки diff.
Область версии: Документальный снимок https://agentclientprotocol.com/get-started/introduction на 2026-10-16T14:41:12.636738+00:00; SHA-256 тела 0f8d62cf02d96d34a3904aa845d306741f9f96932e697cf6249329ffd7fdfcfb. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 0f8d62cf02d96d34a3904aa845d306741f9f96932e697cf6249329ffd7fdfcfb
Свидетельства, ограничения и следующий шаг
Первоисточники
acp · ACP задаёт способ связи IDE-клиента с агентом и передачи действий.
Не подтверждает: Снижение ошибок ревью или совместимость каждого конкретного IDE/агента.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: В IDE и CLI могут различаться модель, permissions и набор инструментов — тогда эффект интерфейса неотделим.
Следующее действие: Просмотреть один существующий diff в IDE и CLI с одинаковыми правами; записать, где теряются контекст, объяснение или контроль применения.
Когда остановиться: IDE скрывает существенные изменения или выигрыш исчезает при одинаковых настройках.
Необязательный план опыта
Вход: На парных задачах фиксировать время до принятого diff, пропущенные нежелательные изменения и отмены.
Контроль: CLI того же агента, модели, разрешений и репозитория.
Успех: Меньше пропущенных нежелательных изменений при сопоставимом времени.
Сигнал отказа: IDE скрывает существенные изменения или выигрыш исчезает при одинаковых настройках.
До самостоятельной рекомендации: Нужно закрепить версии обоих клиентов и идентичную конфигурацию инструментов.
A03 · Детерминированный workflow или автономный агент
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Anthropic разделяет заранее заданные workflows и агента, который сам выбирает шаги и инструменты; на повторяемом процессе автономия не является доказанной необходимостью.
Когда применимо: Владельцу процесса нужно выбрать предписанный pipeline или свободный tool-loop для задач разных классов.
Область версии: Документальный снимок https://www.anthropic.com/engineering/building-effective-agents на 2026-10-16T14:41:10.519239+00:00; SHA-256 тела a445de8adaf8cbb428e9251a868a75cc30d7d3080bafcf226323570e1284fd6f. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: a445de8adaf8cbb428e9251a868a75cc30d7d3080bafcf226323570e1284fd6f
Свидетельства, ограничения и следующий шаг
Первоисточники
agents-patterns · Определение workflow/agent и примеры маршрутизации и tool-loop.
Не подтверждает: Какой вариант дешевле и надёжнее на наших типах задач.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Сравнение только на открытых задачах предвзято против pipeline, а только на шаблонных — против агента.
Следующее действие: Разделить текущие задачи на предсказуемые шаги и случаи с неизвестным путём; для первых описать детерминированный workflow, для вторых — допустимые полномочия агента.
Когда остановиться: Агент делает лишние действия без прироста принятого результата.
Необязательный план опыта
Вход: Сравнить долю завершения, ошибки и стоимость на двух стратах: повторяемые и открытые задачи.
Контроль: Фиксированный pipeline с теми же моделями и инструментами против автономного tool-loop.
Успех: Для каждого класса задач отдельно сообщить принятую долю, полное время, стоимость и типы ошибок обоих подходов; любой устойчивый исход, включая победу одного подхода в обоих классах, считается информативным.
Сигнал отказа: Агент делает лишние действия без прироста принятого результата.
До самостоятельной рекомендации: Нужны заранее заданные страты задач, лимит действий и критерии остановки.
A04 · Долговечные агентные процессы: ожидания, восстановление и побочные действия
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Документация Pi Durable, LangGraph и Pi-на-Temporal описывает разные механизмы возобновления; checkpoint не доказывает exactly-once внешнего побочного действия, а восстановление после потери процесса и хоста следует проверять раздельно.
Когда применимо: Процесс длится дольше одной сессии, ждёт человека либо вызывает внешний сервис с побочным действием.
Область версии: Документальные снимки 2026-10-16: Pydantic AI durable execution, Pi Durable, LangGraph persistence и Pi-на-Temporal; отдельные SHA-256 указаны при каждом источнике. Общего хэша для составного тезиса нет. Runtime-релизы, storage и worker-конфигурация не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
pydantic-durable · Pydantic AI документирует собственные варианты durable execution; не является источником о Pi Durable или LangGraph.
Не подтверждает: Гарантии Pi Durable, LangGraph, Pi-на-Temporal или exactly-once внешнего эффекта.
Thoughtworks Technology Radar · 2026-04-15 · Caution для игнорирования долговечности агентного workflow · Антипаттерн без durability; не оценка гарантий Pi/Temporal в конкретной конфигурации.
Наш опыт: Не проводился.
Главное ограничение: Возобновление процесса, переживание потери хоста и идемпотентность внешнего действия — разные свойства.
Следующее действие: Для своего долгого процесса выписать события ожидания, внешние эффекты, ключи идемпотентности и место хранения состояния; определить, нужен ли durable runtime.
Когда остановиться: Повторный committed effect при заявленной идемпотентности, необнаруженная потеря эффекта или молчаливое принятие unknown за success; невозможность host recovery фиксировать отдельно от process recovery.
Необязательный план опыта
Вход: На отдельных закреплённых реализациях Pi Durable, LangGraph и Pi-на-Temporal выполнить одинаковый synthetic workflow с mock-списанием. Факторно пересечь durable/no-durable слой, idempotent/non-idempotent sink, остановку процесса и потерю хоста при общем хранилище; прервать до вызова, после commit до ACK и после ACK. Считать attempts, committed effects и статус восстановления.
Контроль: Для каждого типа sink сравнить durable и no-durable при том же сценарии сбоя; для каждой реализации использовать одинаковый ledger и ключ запроса. Не смешивать результат Pi Durable с Pi-на-Temporal.
Успех: Для зафиксированных границ отказа workflow возобновляется с наблюдаемым итогом; при idempotent sink нет двойного committed effect, а in-flight lost-ACK честно отмечен unknown до сверки ledger, вместо выдуманного exactly-once.
Сигнал отказа: Повторный committed effect при заявленной идемпотентности, необнаруженная потеря эффекта или молчаливое принятие unknown за success; невозможность host recovery фиксировать отдельно от process recovery.
До самостоятельной рекомендации: Нужны закреплённые версии каждой отдельно заявленной реализации, общий mock-ledger и явная политика для lost-ACK; без опыта допустима лишь документальная карточка.
A05 · Пауза для решения человека и продолжение задачи
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: LangGraph interrupt позволяет приостановить граф и продолжить по вводу человека; срок действия approval и повторная проверка полномочий — политика приложения вокруг resume, а не обещание LangGraph.
Когда применимо: Действие требует согласования человеком и может продолжиться после изменения данных или полномочий.
Область версии: Документальный снимок https://docs.langchain.com/oss/python/langgraph/interrupts на 2026-10-16T14:41:11.113063+00:00; SHA-256 тела 402db160d8f555ef90fc1f5423b781c91ae2f80e73d073bf9f965ec3d7dcd670. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 402db160d8f555ef90fc1f5423b781c91ae2f80e73d073bf9f965ec3d7dcd670
Свидетельства, ограничения и следующий шаг
Первоисточники
langgraph-interrupt · API interrupt/resume и требования к сохранению состояния.
Не подтверждает: Автоматический TTL согласования, отзыв внешних полномочий или идемпотентность нашего действия.
A06 · Небольшие команды специализированных агентов
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Документация Claude Code поддерживает специализированных subagents, а Thoughtworks рассматривает небольшие команды coding agents как предмет оценки; результат команды зависит от интеграции и роли ревьюера.
Когда применимо: Есть независимые роли анализа, реализации и проверки при ограниченном общем бюджете.
Область версии: Документальный снимок https://code.claude.com/docs/en/sub-agents на 2026-10-16T14:41:10.696848+00:00; SHA-256 тела 57e2e5e089a798d4a7b028cea24a25008be1459a56ea109d46d0a6e66af03381. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 57e2e5e089a798d4a7b028cea24a25008be1459a56ea109d46d0a6e66af03381
Свидетельства, ограничения и следующий шаг
Первоисточники
subagents · Способ создать специализированных subagents и передавать им задачи.
Не подтверждает: Прирост качества команды по сравнению с одним агентом при равном бюджете.
Thoughtworks Technology Radar · 2026-04-15 · Assess для небольшой команды coding agents · Тема команд, а не измеренное преимущество любой архитектуры ролей.
Наш опыт: Не проводился.
Главное ограничение: Несколько агентов могут повторить одну ошибку и увеличить стоимость коммуникации.
Следующее действие: Найти в одной задаче действительно независимые роли и общий бюджет; не добавлять субагентов, если передача контекста дороже разделения работы.
Когда остановиться: Роли дублируют работу или интеграция нивелирует обнаруженные улучшения.
Необязательный план опыта
Вход: На задачах с известными дефектами сравнить одиночный прогон и 2–3 роли; считать обнаруженные дефекты и стоимость интеграции.
Контроль: Один агент с тем же суммарным токенным/временным бюджетом и теми же тестами.
Успех: Команда обнаруживает больше независимых дефектов без превышения заданного лимита времени.
Сигнал отказа: Роли дублируют работу или интеграция нивелирует обнаруженные улучшения.
До самостоятельной рекомендации: Нет закреплённой схемы ролей, версий и независимого набора дефектов.
A07 · Параллельные агенты в отдельных рабочих деревьях
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Отдельные Git worktrees изолируют незакоммиченные файлы параллельных агентов, но не решают семантические конфликты после объединения их изменений.
Когда применимо: Две параллельные задачи меняют смежные модули одного Git-репозитория.
Область версии: Документальный снимок https://code.claude.com/docs/en/common-workflows на 2026-10-16T14:41:10.742725+00:00; SHA-256 тела 9b9dceb11d239e6aa89c52a42ce8fc106dd861710c5a2e5932ee43c199e1c92f. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 9b9dceb11d239e6aa89c52a42ce8fc106dd861710c5a2e5932ee43c199e1c92f
Свидетельства, ограничения и следующий шаг
Первоисточники
worktrees · Поддерживаемый рабочий процесс для параллельных агентов в worktrees.
Не подтверждает: Автоматическое безопасное объединение изменений в пересекающихся компонентах.
Thoughtworks Technology Radar · 2026-04-15 · Assess для team of coding agents · Запись не оценивает Git worktrees или merge-конфликты.
Наш опыт: Не проводился.
Главное ограничение: Чистый Git merge может скрыть логический конфликт контрактов; worktree также не изолирует общую внешнюю БД или занятые порты.
Следующее действие: Перечислить пересекающиеся файлы, порты и внешние ресурсы двух параллельных задач; определить, где worktree изолирует изменения, а где нужен иной барьер.
Когда остановиться: Merge формально чист, но тесты или ручная проверка обнаруживают несогласованность.
Необязательный план опыта
Вход: Дать двум агентам смежные изменения API и клиента; после merge выполнить контрактные и интеграционные тесты.
Контроль: Та же пара задач последовательно в одном worktree при равном общем лимите токенов, модели, времени работы агентов и acceptance-тестов; wall-clock и общий compute учитывать отдельно.
Успех: Параллельная ветка снижает wall-clock при равном общем compute без скрытого нарушения контракта после merge.
Сигнал отказа: Merge формально чист, но тесты или ручная проверка обнаруживают несогласованность.
До самостоятельной рекомендации: Нужны фиксированные задачи с пересечением, стратегия merge и независимые acceptance-тесты.
A08 · Планировщик, исполнитель и критик с ограниченным числом итераций
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Планировщик, исполнитель и критик дают явные точки проверки, но сама ролевая декомпозиция не подтверждает качество; критик нужен с независимым oracle и ограничением раундов.
Когда применимо: Качество результата проверяется независимыми тестами и известными дефектами, а число итераций ограничено.
Область версии: Документальный снимок https://www.anthropic.com/engineering/building-effective-agents на 2026-10-16T14:41:10.519239+00:00; SHA-256 тела a445de8adaf8cbb428e9251a868a75cc30d7d3080bafcf226323570e1284fd6f. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: a445de8adaf8cbb428e9251a868a75cc30d7d3080bafcf226323570e1284fd6f
Свидетельства, ограничения и следующий шаг
Первоисточники
agents-patterns · Anthropic описывает паттерны evaluator-optimizer и планирования; обратная связь опирается на проверяемые сигналы.
Не подтверждает: Лучшее качество по сравнению с одиночным агентом при равном бюджете.
Thoughtworks Technology Radar · 2026-04-15 · Trial для feedback sensors for coding agents · Сенсоры обратной связи, а не конкретная тройка ролей.
Наш опыт: Не проводился.
Главное ограничение: Критик с тем же контекстом может повторить исходное заблуждение.
Следующее действие: Для одного известного дефекта сверить, видел ли критик исходный контракт и независимую проверку; заранее ограничить число и стоимость циклов.
Когда остановиться: Критик создаёт ложные проблемы или циклические правки.
Необязательный план опыта
Вход: На фиксированном наборе дефектов сравнить одиночный цикл и план–исполнение–критика с максимум двумя раундами.
Контроль: Один агент с теми же доступными токенами, инструментами и тестами.
Успех: Больше реально исправленных дефектов при том же бюджете и без роста ложных замечаний.
Сигнал отказа: Критик создаёт ложные проблемы или циклические правки.
До самостоятельной рекомендации: Нужны закрытый список дефектов, бюджет и правило остановки до эксперимента.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Длительный agent harness может продолжать работу между контекстными окнами, а запуск по событию добавляет требования к доставке, отмене и полномочиям, не покрываемые самим циклом агента.
Когда применимо: Задача запускается событием или в фоне и может быть повторно доставлена либо отменена.
Область версии: Документальный снимок https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents на 2026-10-16T14:41:10.576913+00:00; SHA-256 тела 559ad1e2c70046d00369be0af642483847c29d4a3a15ae552fab7552021ef921. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 559ad1e2c70046d00369be0af642483847c29d4a3a15ae552fab7552021ef921
Свидетельства, ограничения и следующий шаг
Первоисточники
long-running · Anthropic описывает сохранение прогресса и новую сессию для долгих задач.
Не подтверждает: Надёжность фонового запуска по событию и корректную отмену в нашей очереди.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Повторная доставка события может создать две задачи, а отмена может опоздать после внешнего действия.
Следующее действие: Нарисовать текущую цепь событие → очередь → агент → результат; отметить повторную доставку, отмену и владельца состояния до выбора фонового harness.
Когда остановиться: Дубликат, невидимое продолжение или использование просроченного полномочия.
Необязательный план опыта
Вход: На synthetic очереди повторить событие, истечь токен, отменить задание и проверить журнал и результат.
Контроль: Ручной одиночный запуск того же workflow.
Успех: Ровно один учтённый результат, повтор безопасен, отмена и отказ наблюдаемы.
Сигнал отказа: Дубликат, невидимое продолжение или использование просроченного полномочия.
До самостоятельной рекомендации: Нет выбранного event transport и политики idempotency/TTL.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Claude Agent SDK открывает агентный цикл программному приложению; его наличие не доказывает корректную отмену, лимиты и обработку ошибок для конкретного встраивания.
Когда применимо: Продукт встраивает agent runtime и сам отвечает за поток событий, таймауты и отмену.
Область версии: Документальный снимок https://code.claude.com/docs/en/agent-sdk/overview на 2026-10-16T14:41:10.944126+00:00; SHA-256 тела 583eb70663cb426f19fa90aa6405d37ebe78ecc4f96bf29772a3ac4ff3e462e4. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 583eb70663cb426f19fa90aa6405d37ebe78ecc4f96bf29772a3ac4ff3e462e4
Свидетельства, ограничения и следующий шаг
Первоисточники
agent-sdk · SDK API для вызова агента, инструментов и событий.
Не подтверждает: Наши гарантии по потоку, таймауту, отмене и отказам инструментов.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Приложение становится ответственным за наблюдаемость, ресурсные лимиты и безопасные повторы.
Следующее действие: Перечислить требования продукта к событиям, таймауту, отмене и неизвестному in-flight эффекту; затем сверить их с контрактом выбранного SDK.
Когда остановиться: После подтверждённой отмены начинается новый внешний вызов, теряется ошибка инструмента или уже committed effect ошибочно объявлен отменённым; неизвестный in-flight итог скрыт.
Необязательный план опыта
Вход: Встроить один synthetic workflow, прервать его на tool-call и потоке, затем проверить таймаут и ошибки.
Контроль: Тот же workflow через CLI либо минимальный deterministic runner.
Успех: После отмены не инициируются новые внешние вызовы; уже committed effects отдельно учитываются в ledger, а in-flight lost-ACK остаётся unknown до сверки. Ошибки и лимиты видны вызывающему коду.
Сигнал отказа: После подтверждённой отмены начинается новый внешний вызов, теряется ошибка инструмента или уже committed effect ошибочно объявлен отменённым; неизвестный in-flight итог скрыт.
До самостоятельной рекомендации: Нужны pin SDK/model и контракт отмены с реальным transport.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Открытая спецификация Agent Skills определяет пакет с обязательным SKILL.md, метаданными и опциональными ресурсами; совпадение формата не гарантирует одинаковую активацию, полномочия и результат в разных клиентах.
Когда применимо: Один пакет инструкций планируется применять в двух разных совместимых клиентах.
Область версии: Живая спецификация agentskills.io, просмотрена 16–17 октября 2026; ревизия спецификации и версии двух клиентов для совместимостного опыта не закреплены.
SHA-256 основного снимка: c5604823b868e039112674f3c68c675a81dbbd12199bdaeeed946c6db960a34a
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Минимальный формат SKILL.md и допускаемые дополнительные ресурсы.
Не подтверждает: Эквивалентное исполнение одной skill в двух клиентах.
Внешний контекст
Thoughtworks Technology Radar · 2026-04-15 · Trial для Agent Skills · Thoughtworks видит ценность модульного контекста, но предупреждает о риске непроверенных сторонних skills; это не тест переносимости.
Наш опыт: Не проводился.
Главное ограничение: SKILL.md — содержимое, а не полномочие; сторонний пакет может принести недоверенные инструкции.
Следующее действие: Открыть спецификацию Agent Skills и два клиентских руководства; проверить поддержку SKILL.md, связанных файлов и правил доверия до обещания переносимости.
Когда остановиться: Клиент молча пропускает ресурс, нарушает обязательный поведенческий контракт или выполняет запрещённое действие; различия свободной формулировки сами по себе не считаются отказом.
Необязательный план опыта
Вход: Одна безопасная skill с зависимым локальным файлом, контрольной задачей и инструкцией на запрещённое действие; закрепить версии двух клиентов и одну модель.
Контроль: Та же контрольная задача без skill и та же инструкция, встроенная вручную в prompt каждого клиента.
Успех: Оба клиента обнаруживают skill, загружают зависимый файл и выполняют обязательное поведение; запрещённое действие отклоняется в обоих.
Сигнал отказа: Клиент молча пропускает ресурс, нарушает обязательный поведенческий контракт или выполняет запрещённое действие; различия свободной формулировки сами по себе не считаются отказом.
До самостоятельной рекомендации: Нужны pin двух клиентов и проверка происхождения/прав скриптов.
A12 · Автономные повторяющиеся циклы с новым контекстом
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Ralph loop перезапускает агента со свежим контекстом для движения по спецификации; это может снизить накопление контекстного шума, но может увеличить стоимость и не гарантирует завершение.
Когда применимо: Большая задача разбита на критерии, а повторные сессии ограничены бюджетом и условием остановки.
Область версии: Документальный снимок https://www.thoughtworks.com/radar/techniques/ralph-loop на 2026-10-16T14:41:10.380964+00:00; SHA-256 тела 17dbf106584ca7affa4232a657c6debda7b99f14b09de07e726fbea98dfd699d. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 17dbf106584ca7affa4232a657c6debda7b99f14b09de07e726fbea98dfd699d
Свидетельства, ограничения и следующий шаг
Первоисточники
tw-ralph · Thoughtworks описывает повторение с новым окном и признаёт значительный расход токенов.
Не подтверждает: Сходимость к acceptance-критериям на наших задачах.
Thoughtworks Technology Radar · 2026-04-15 · Assess для Ralph loop · Описание техники и риска стоимости; не результат наших задач.
Наш опыт: Не проводился.
Главное ограничение: Без конечного бюджета цикл способен повторять ошибки или изменять уже принятое.
Следующее действие: Разделить одну большую задачу на проверяемые критерии и бюджет повторных сессий; записать, по какому сигналу цикл должен остановиться.
Когда остановиться: Цикл не сходится или портит ранее зелёные критерии.
Необязательный план опыта
Вход: На одной спецификации сравнить fresh-context итерации с обычным продолжением; зафиксировать максимум запусков и STOP-условие.
Контроль: Один непрерывный agent run при равном суммарном бюджете токенов.
Успех: Больше принятых критериев при ограниченных стоимости и регрессиях.
Сигнал отказа: Цикл не сходится или портит ранее зелёные критерии.
До самостоятельной рекомендации: Нет заранее утверждённых спецификации, лимита и независимых acceptance-тестов.
A13 · Проактивные агенты: когда инициировать задачу и когда промолчать
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Heartbeat может регулярно инициировать проверку состояния, но проактивность полезна лишь если агент умеет распознать необходимость действия и своевременно промолчать.
Когда применимо: Агент получает постоянный поток событий и должен инициировать лишь согласованные полезные действия.
Область версии: Документальный снимок https://docs.openclaw.ai/gateway/heartbeat на 2026-10-16T15:24:14.425970+00:00; SHA-256 тела 3df767b35aede510d070ddfb1eb2eea25d663b9edffdc82e60fbf38fa41a505a. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 3df767b35aede510d070ddfb1eb2eea25d663b9edffdc82e60fbf38fa41a505a
Свидетельства, ограничения и следующий шаг
Первоисточники
openclaw-heartbeat · OpenClaw документирует heartbeat как периодический запуск проверок.
Не подтверждает: Качество выбора момента вмешательства и соблюдение согласия пользователя.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Даже точное уведомление может вредить частотой, стоимостью или раскрытием лишнего контекста.
Следующее действие: Для потока событий определить, когда агент должен промолчать, кто даёт согласие и как его отозвать; оставить запуск опыта выборочным.
Когда остановиться: Продолжает действовать после отзыва цели либо создаёт больше шума, чем правиловая база.
Необязательный план опыта
Вход: Разметить поток из полезных, ложных и отозванных триггеров; измерить precision/recall, стоимость и нагрузку.
Контроль: Режим только по запросу и простые детерминированные правила на том же потоке.
Успех: Агент обнаруживает полезные события без превышения заданного порога ложных вмешательств и прекращает инициативу после отзыва.
Сигнал отказа: Продолжает действовать после отзыва цели либо создаёт больше шума, чем правиловая база.
До самостоятельной рекомендации: Нужны размеченный поток, согласие, канал отмены и фиксированный бюджет.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Комбинация точного поиска и embeddings может возвращать и буквальные API-имена, и смысловые совпадения; относительное качество на кодовом корпусе зависит от запросов и индекса.
Когда применимо: Корпус содержит точные идентификаторы и смысловые запросы; один поисковый канал пропускает часть релевантного.
Область версии: Документальный снимок https://www.anthropic.com/engineering/contextual-retrieval на 2026-10-16T14:41:11.179754+00:00; SHA-256 тела cf1be0e1faf6eae0775c4ad60ca5d3b059a3f5e9074a611fdf078a52d62a277d. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: cf1be0e1faf6eae0775c4ad60ca5d3b059a3f5e9074a611fdf078a52d62a277d
Свидетельства, ограничения и следующий шаг
Первоисточники
contextual-retrieval · Anthropic описывает contextual BM25 и embeddings в одном retrieval pipeline.
Не подтверждает: Преимущество hybrid над каждой базовой веткой в нашем репозитории.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Обогащение чанков контекстом может само менять результат и смешать вклад методов.
Следующее действие: Проверить один существующий поисковый промах: точный идентификатор это или смысловой запрос; решить, нужен ли второй канал retrieval.
Когда остановиться: Точные символы исчезают или прирост объясняется только другим chunking.
Необязательный план опыта
Вход: На замороженном корпусе собрать 100 размеченных вопросов с API-именами, сообщениями ошибок и смысловыми перефразированиями; измерить recall@k.
Контроль: BM25-only и vector-only на тех же чанках, версии индекса и вопросах.
Успех: Hybrid улучшает полноту релевантных фрагментов без падения точных имён и чрезмерной задержки.
Сигнал отказа: Точные символы исчезают или прирост объясняется только другим chunking.
До самостоятельной рекомендации: Нужны замороженный корпус, разметка релевантности и параметры индекса.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Reranker может менять порядок уже найденных фрагментов, но не вернёт документ, отсутствующий в candidate set.
Когда применимо: Retrieval уже получает релевантные кандидаты, но их порядок не помещает лучшие фрагменты в контекст.
Область версии: Документальный снимок https://www.anthropic.com/engineering/contextual-retrieval на 2026-10-16T14:41:11.179754+00:00; SHA-256 тела cf1be0e1faf6eae0775c4ad60ca5d3b059a3f5e9074a611fdf078a52d62a277d. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: cf1be0e1faf6eae0775c4ad60ca5d3b059a3f5e9074a611fdf078a52d62a277d
Свидетельства, ограничения и следующий шаг
Первоисточники
contextual-retrieval · Anthropic описывает reranking после retrieval как часть contextual retrieval.
Не подтверждает: Рост качества ответа в наших вопросах при допустимой задержке.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Улучшение top-k может быть потеряно в генерации или зависеть от типа вопроса.
Следующее действие: На нескольких неудачных ответах отделить отсутствие нужного фрагмента в кандидатах от его низкого ранга; только второе является задачей reranker.
Когда остановиться: Если релевантного фрагмента нет в candidate set, это провал первого retrieval stage, а не reranker; отдельно фиксировать, когда reranker ухудшил порядок имеющихся релевантных кандидатов либо ответ не улучшился.
Необязательный план опыта
Вход: На фиксированном candidate set сравнить релевантность top-k, точность ответов и p95 задержки.
Контроль: Та же выборка без reranker, та же модель генерации и бюджет контекста.
Успех: Больше подтверждённых ответов без превышения p95 лимита.
Сигнал отказа: Если релевантного фрагмента нет в candidate set, это провал первого retrieval stage, а не reranker; отдельно фиксировать, когда reranker ухудшил порядок имеющихся релевантных кандидатов либо ответ не улучшился.
До самостоятельной рекомендации: Нужны размеченные вопросы, pin reranker и candidate recall отдельно.
C03 · Структурная навигация по коду: AST и символьный индекс
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Tree-sitter даёт синтаксическое дерево, а SCIP — индекс символов; вместе они помогают навигации по коду, но не гарантируют корректный межмодульный impact analysis.
Когда применимо: В большом кодовом репозитории нужно находить usages и связи между символами, включая разные языки.
Область версии: Документальный снимок https://github.com/tree-sitter/tree-sitter на 2026-10-16T14:41:11.286243+00:00; SHA-256 тела f353ef9cbeebb58b0479fb2ebf87b0f31b825149548a57c1415bd25227a400e8. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: f353ef9cbeebb58b0479fb2ebf87b0f31b825149548a57c1415bd25227a400e8
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Межсессионная память может хранить факты по namespace/user, но наличие persistence не означает изоляцию, удаление или актуальность фактов при смене пользователя.
Когда применимо: Долговременная память используется несколькими пользователями и должна разделяться и удаляться.
Область версии: Документальный снимок https://docs.langchain.com/oss/python/concepts/memory на 2026-10-16T14:41:11.151772+00:00; SHA-256 тела 970001c269b7240fe5c861a2cc7da6a1e5a40fe6c9a53e6c15fe885679d6e1f3. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 970001c269b7240fe5c861a2cc7da6a1e5a40fe6c9a53e6c15fe885679d6e1f3
Свидетельства, ограничения и следующий шаг
Первоисточники
langgraph-memory · LangGraph описывает разделение thread state и долговременного store.
Не подтверждает: Изоляцию между пользователями и удаление производных записей в нашей схеме.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Ошибочный namespace либо shared cache способен смешать данные несмотря на корректный API.
Следующее действие: Проверить, кто читает долгую память, как разделяются пользователи и как удаляются производные записи; неизвестные границы отметить до подключения.
Когда остановиться: Чужой факт появляется в ответе или остаётся после поддерживаемого удаления.
Необязательный план опыта
Вход: На двух вымышленных пользователях создать противоречащие факты, запросить из разных сессий, затем удалить одного.
Контроль: Без долговременного store при прочих равных.
Успех: Верный факт доступен лишь своему пользователю и исчезает вместе с производными после удаления.
Сигнал отказа: Чужой факт появляется в ответе или остаётся после поддерживаемого удаления.
До самостоятельной рекомендации: Нужны pin хранилища, namespace policy и тест всех производных записей.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Anthropic описывает отбор и сжатие контекста агента как управление ограниченным окном; из уменьшения числа токенов не следует сохранность обязательных требований и качество итоговой задачи.
Когда применимо: Длинная задача выходит за контекстное окно, но содержит обязательные ограничения и исходные ссылки.
Область версии: Статья Anthropic о context engineering, просмотрена 16–17 октября 2026; summarizer, модель и формат summary для испытания не закреплены.
SHA-256 основного снимка: 332ea706bc5fd64e068241d284fbe5d3e267c2935b9b57a75e624266ef97c73f
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Постановка задачи отбора, организации и обслуживания контекста агента.
Не подтверждает: Пользу конкретного алгоритма сжатия на нашем корпусе.
Внешний контекст
Thoughtworks Technology Radar · 2026-04-15 · Adopt для общей практики context engineering · Общая инженерия контекста шире сжатия; этот статус нельзя переносить на любой summarizer.
Наш опыт: Не проводился.
Главное ограничение: Summary может удалить исключение, источник или отменённое требование; экономия токенов не является мерой правильности.
Следующее действие: На одном длинном задании выписать обязательные ограничения и ссылки, которые нельзя потерять при сокращении контекста; выбрать проверяемый контроль.
Когда остановиться: Хотя бы одно обязательное ограничение исчезает из решения.
Необязательный план опыта
Вход: На синтетических длинных задачах с canary-требованиями сравнить исходный и сжатый контекст по выполнению требований.
Контроль: Полный доступный контекст либо retrieval-on-demand при том же лимите задачи.
Успех: Критические требования и ссылки сохранены при меньшем числе токенов.
Сигнал отказа: Хотя бы одно обязательное ограничение исчезает из решения.
До самостоятельной рекомендации: Нужны pin summarizer/model и независимый oracle сохранённых требований.
C06 · Постепенная загрузка инструкций и инструментов
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Постепенная загрузка инструкций может уменьшить начальный контекст, если агент узнаёт, когда открыть нужный ресурс; снижение токенов само по себе не доказывает соблюдение всех правил.
Когда применимо: Много доменных инструкций нужно загружать по требованию без пропуска обязательных правил.
Область версии: Документальный снимок https://www.thoughtworks.com/radar/techniques/progressive-context-disclosure на 2026-10-16T14:41:10.213531+00:00; SHA-256 тела 884b39179c5c186def6e96264fce340b36eeb266309feb19cc8eb744ed43e96f. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 884b39179c5c186def6e96264fce340b36eeb266309feb19cc8eb744ed43e96f
Свидетельства, ограничения и следующий шаг
Первоисточники
tw-progressive · Thoughtworks описывает progressive context disclosure как технику.
Не подтверждает: Безошибочное обнаружение нужных инструкций нашим агентом.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: ACL-фильтр поиска должен ограничить кандидатов до передачи модели; prompt-инструкция «не показывать» не является эквивалентом проверки доступа на retrieval boundary.
Когда применимо: Общий индекс содержит документы разных уровней доступа и права могут быть отозваны.
Область версии: Документальный снимок https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search на 2026-10-16T14:41:11.447715+00:00; SHA-256 тела 09c622928e075c4df1d9a65ef8d1a9572548e81e34b7e179f20de2b8305ce9bf. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: 09c622928e075c4df1d9a65ef8d1a9572548e81e34b7e179f20de2b8305ce9bf
Свидетельства, ограничения и следующий шаг
Первоисточники
retrieval-acl · Azure AI Search описывает security trimming на основании прав документа.
Не подтверждает: Защиту всех каналов выдачи и отсутствие leakage через metadata/кэш в нашей системе.
C08 · Ответы с проверяемыми ссылками на исходные фрагменты
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Ragas Faithfulness проверяет выводимость утверждений из переданного retrieved context; соответствие каждого отображаемого citation span тезису и право читателя открыть этот span — дополнительные требования нашего приложения, не свойства метрики.
Когда применимо: Ответы RAG содержат цитаты и читатель должен проверять соответствие каждого тезиса исходному фрагменту.
Область версии: Официальная документация Ragas Faithfulness, просмотрена 2026-10-17; хэш этого точного URL не измерен. Версия Ragas, корпус, модель-судья и реализация citation/access checks не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Метрика Faithfulness сравнивает тезисы ответа с retrieved context и считает долю поддержанных тезисов.
Не подтверждает: Что именно показанный citation span поддерживает тезис, что ссылка разрешена текущему читателю или что источник актуален.
Внешний контекст
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Faithfulness по набору retrieved contexts не устанавливает связь конкретного тезиса с конкретной показанной ссылкой; permission check и срок актуальности должны проверяться приложением отдельно.
Следующее действие: Открыть одну существующую цитату и сверить конкретный тезис с указанным фрагментом и правами читателя; отдельно оценивать контекстную faithfulness.
Когда остановиться: Найдена красивая, но не поддерживающая ссылка или ложная уверенность.
Необязательный план опыта
Вход: На 40 размеченных вопросах проверить claim-to-citation-span alignment вручную и server-side доступ текущего читателя к каждому span; отдельно оценить Ragas Faithfulness по retrieved context и случаи корректного отказа при нехватке данных.
Контроль: Ответ без обязательных citations при том же retrieval.
Успех: Каждый принятый тезис имеет показанный доступный span, из которого он действительно следует; неподтверждённые либо недоступные запросы получают отказ. Faithfulness сообщается отдельно, без подмены ручной проверки цитаты.
Сигнал отказа: Найдена красивая, но не поддерживающая ссылка или ложная уверенность.
До самостоятельной рекомендации: Нужны фиксированный корпус, смещения фрагментов и независимая оценка цитат.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Граф контекста способен связать решение с исключением, датой и источником; это обещает ответы «почему», но качество временной навигации против обычного RAG ещё не измерено.
Когда применимо: Нужно отвечать на вопросы о том, почему и когда политика была изменена или применено исключение.
Область версии: Документальный снимок https://github.com/getzep/graphiti на 2026-10-16T14:41:11.559432+00:00; SHA-256 тела a42cb54cd7567d69383efb8e97049e4a2c70d55d2dfe9a7bdd6cf53d2a446148. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: a42cb54cd7567d69383efb8e97049e4a2c70d55d2dfe9a7bdd6cf53d2a446148
Свидетельства, ограничения и следующий шаг
Первоисточники
graphiti · Graphiti описывает temporal knowledge graph с эпизодами и отношениями.
Не подтверждает: Лучшие ответы на вопросы о смене политики именно в нашем корпусе.
Thoughtworks Technology Radar · 2026-04-15 · Assess для context graph · Идея графа решений, не сравнение Graphiti с RAG на нашем корпусе.
Наш опыт: Не проводился.
Главное ограничение: Неправильное извлечение ребра превратит локальное исключение в общее правило.
Следующее действие: На одном реальном вопросе «почему приняли решение» проверить, сохранены ли дата, исключение и прежняя версия политики; решить, нужен ли временной граф.
Когда остановиться: Граф выдаёт отменённую политику как текущую или теряет исключение.
Необязательный план опыта
Вход: Создать датированные решения с отменами и исключениями; сравнить граф и RAG на вопросах «что действовало тогда и почему».
Контроль: Обычный chunk RAG на тех же документах и модели.
Успех: Больше ответов с правильной датой, основанием и источником без ложных обобщений.
Сигнал отказа: Граф выдаёт отменённую политику как текущую или теряет исключение.
До самостоятельной рекомендации: Нужны temporal schema, pin Graphiti и проверяемая разметка связей.
C10 · Фоновая консолидация памяти: dreaming, противоречия и забывание
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: OpenClaw dreaming и Mem0 Dream описывают разные способы фоновой консолидации памяти; слияние дублей не равно улучшению ответов и может скрыть исключения или оставить производные записи после удаления.
Когда применимо: Долговременная память накопила дубли и противоречия; после консолидации нужен проверяемый rollback/delete.
Область версии: Документальный снимок https://docs.openclaw.ai/concepts/dreaming на 2026-10-16T15:24:14.417505+00:00; SHA-256 тела e5a804292b7ec5799f4234eeb48938d3408fe2e6f354d2cd79a6d02b1f52688b. Исполняемая версия CLI/SDK, модель, корпус и конфигурация опыта пока не закреплены.
SHA-256 основного снимка: e5a804292b7ec5799f4234eeb48938d3408fe2e6f354d2cd79a6d02b1f52688b
Свидетельства, ограничения и следующий шаг
Первоисточники
openclaw-dreaming · OpenClaw документирует light/REM/deep фазы и записи в MEMORY.md.
Не подтверждает: Улучшение точности, безопасное забывание и откат в конкретной конфигурации.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Mem0 merge/supersede и weekly synthesis — разные стадии; без подтверждённого запуска нельзя приписать изменение Dream.
Следующее действие: Сначала установить, был ли наблюдаемый запуск фоновой консолидации и какие записи она меняет; без этого качество и забывание оставить неизвестными.
Когда остановиться: Нет наблюдаемого eligible/run — остановить сравнение как not-run/inconclusive; после подтверждённого run остановить на потере исключения, падении правильности отложенных ответов или неудачном удалении canary.
Необязательный план опыта
Вход: На синтетических воспоминаниях с противоречиями, исключениями, source IDs и canary сравнить 30 заранее отложенных ответов до и после подтверждённого фонового run; отдельно наблюдать Mem0 merge/supersede при extraction и deep-фазу OpenClaw, затем проверить поддерживаемое удаление canary.
Контроль: Тот же корпус без консолидации; отдельно сравнить Mem0 extraction-stage merge и background synthesis.
Успех: После подтверждённого run точность на отложенных вопросах не ниже исходной, новых ложных обобщений нет, исключения и source IDs сохранены; canary не возвращаются из поддерживаемого поиска и производных записей после удаления.
Сигнал отказа: Только при подтверждённом run: потеря исключения, снижение правильности отложенных ответов, ложное обобщение или canary после проверяемого удаления. Если run/eligibility не подтверждены — статус not-run/inconclusive, не отрицательный результат эффективности.
До самостоятельной рекомендации: Нужны pin OpenClaw, наблюдаемый Mem0 run и проверяемая операция удаления; до этого результат неизвестен.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Управляемый бюджет рассуждения в Claude даёт способ менять вычислительные затраты одного класса задач; полезность дополнительного бюджета для конкретного инженерного корпуса остаётся эмпирическим вопросом.
Когда применимо: Есть повторяющиеся задачи кодирования с измеримой приёмкой, а цена и задержка рассуждения существенно влияют на работу команды.
Область версии: Документация Anthropic extended thinking, по реестру источников наблюдалась 16 октября 2026; карточка составлена 17 октября; конкретные model ID, API revision и значения бюджета для опыта ещё не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
thinking · Документирует управление режимом рассуждения и его ограничения для поддерживаемых моделей.
Не подтверждает: Не доказывает монотонного роста качества, окупаемости или переносимости параметра между моделями.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Поведение настройки и тарификация могут отличаться по моделям и версиям; публичный набор задач подвержен загрязнению.
Следующее действие: Сейчас выписать из документации доступные режимы для своей модели и цену каждого; затем на бесплатном/разрешённом малом корпусе сравнить три бюджета.
Когда остановиться: Оставить меньший бюджет, если качество на скрытом наборе не улучшается при установленном лимите цены и p95.
Необязательный план опыта
Вход: 30 задач реального класса работ с заранее замороженными скрытыми проверками; три разрешённых значения бюджета и одинаковые инструменты.
Контроль: Одна и та же закреплённая модель с минимальным бюджетом и без иных изменений; порядок задач рандомизировать.
Успех: Повышать бюджет лишь при устойчивом выигрыше качества, оправдывающем установленный до опыта лимит цены/времени.
Сигнал отказа: Откатить режим, если растут стоимость/задержка без выигрыша или появляются новые классы ошибок.
До самостоятельной рекомендации: Нет парного измерения качества, цены и задержки для закреплённой модели на скрытом корпусе; поэтому нельзя присвоить орбиту воспроизведения или рекомендовать повышенный бюджет.
M02 · Локальные небольшие модели для ограниченных задач
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: llama.cpp и MLX-LM позволяют выполнять модель локально, но пригодность небольшой модели для узкой инженерной задачи зависит от устройства, весов, лицензии и ошибок на целевом корпусе.
Когда применимо: Нужен inference на конкретном устройстве без сети, с ограничением на передачу данных или с жёстким бюджетом обращения к API.
Область версии: Текущие публичные репозитории llama.cpp и MLX-LM по снимку реестра 16 октября 2026; карточка составлена 17 октября; веса, commit, устройство и формат файла для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
llamacpp · Показывает локальный inference и поддерживаемые форматы/окружения проекта.
Не подтверждает: Не устанавливает качество выбранных весов и отсутствие сетевых обращений всей обвязки.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Локальность исполнения не равна приватности: телеметрия и загрузка моделей требуют отдельной проверки.
Следующее действие: Сейчас сверить лицензию весов, совместимость целевого устройства и требование офлайн-режима; затем испытать один узкий корпус.
Когда остановиться: Не переносить задачу локально, если модель проваливает критические случаи, лицензию или требование работы без сети.
Необязательный план опыта
Вход: Закреплённые открытые веса, 100 размеченных запросов одной узкой задачи и два целевых устройства; проверить лицензии.
Контроль: Сопоставимый облачный API и простые правила; одинаковая инструкция, формат ответа и скрытый тест.
Успех: Локальный вариант проходит заранее заданный порог ошибок и памяти, выполняется без сети в требуемой среде.
Сигнал отказа: Остановить внедрение при неприемлемых критических ошибках, скрытом сетевом доступе или несоответствии лицензии.
До самостоятельной рекомендации: Не выбраны лицензированные веса и целевое устройство; без офлайн-проверки и ошибок на своём корпусе нельзя рекомендовать локальный вариант.
M03 · Серверное исполнение моделей с открытыми весами
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: vLLM предоставляет механизмы параллельного обслуживания открытых весов, но выигрыш собственного сервера против API определяется нагрузкой, эксплуатацией и полными затратами.
Когда применимо: Есть достаточно стабильная массовая нагрузка, доступные GPU и эксплуатационная команда; стоимость облачного API стала существенной.
Область версии: Документация vLLM parallelism/scaling и llama.cpp по снимку реестра 16 октября 2026; карточка составлена 17 октября; serving release, model revision, GPU и конфигурация ещё не выбраны.
Свидетельства, ограничения и следующий шаг
Первоисточники
vllm-serving · Описывает варианты tensor/pipeline parallelism и масштабирования serving.
Не подтверждает: Не измеряет p95, отказоустойчивость или цену нашей нагрузки.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Бенчмарк движка без данных о простаивающих мощностях и работе оператора занижает стоимость.
Следующее действие: Сейчас посчитать профиль запросов, idle-время, стоимость GPU и дежурства против счёта API; разворачивать тестовый сервер лишь при правдоподобном пороге окупаемости.
Когда остановиться: Не запускать собственный serving, если полная стоимость с простоем/дежурством или p95 хуже согласованного API-порога.
Необязательный план опыта
Вход: Закреплённые модель/веса, 1–2 профиля GPU и запись обезличенной нагрузки с короткими/длинными запросами.
Контроль: Тот же корпус через существующий API и, если уместно, второй локальный runtime; одинаковые критерии качества.
Успех: Сервер проходит минимальный порог качества/SLO и даёт полную стоимость на прогнозируемом объёме ниже утверждённого порога.
Сигнал отказа: Откатить при нарушении SLO, неверной лицензии или необеспеченном обновлении/изоляции.
До самостоятельной рекомендации: Нет закреплённой модели, GPU, профиля нагрузки и полной эксплуатационной стоимости; документация serving не подтверждает выгоду собственной инфраструктуры.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Квантизация снижает требования к хранению/памяти для некоторых весов, но может изменить tool-use и редкие ошибки; выбор формата требует парного измерения одной модели.
Когда применимо: Выбранная модель не помещается в память целевого устройства либо скорость недостаточна, но критичные ошибки недопустимы.
Область версии: llama.cpp и MLX-LM: исходные страницы наблюдались 16 октября 2026 по реестру; карточка составлена 17 октября. Модель, исходные и квантованные веса, commit и железо для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
llamacpp · Репозиторий содержит механизмы квантованного inference и форматы.
Не подтверждает: Не доказывает, что выбранная разрядность сохраняет качество нашей задачи.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Разные квантованные артефакты могут различаться не только разрядностью; проверять происхождение весов.
Следующее действие: Сейчас проверить происхождение исходных и квантованных весов и выбрать редкие критические кейсы; затем провести парный тест.
Когда остановиться: Остаться на исходных весах при критической регрессии качества или несоответствии происхождения квантованного файла.
Необязательный план опыта
Вход: Одна закреплённая модель в исходном и двух квантованных форматах; 100 обычных и 30 критичных редких кейсов.
Контроль: Исходная точность той же модели на том же устройстве и с тем же prompt; слепая проверка результата.
Успех: Принимать формат только если выигрыш ресурса значим по заранее заданному порогу, а критические ошибки не ухудшились.
Сигнал отказа: Вернуться к исходным весам при хотя бы одной недопустимой критической регрессии или нечестном сравнении моделей.
До самостоятельной рекомендации: Не измерены регрессии той же модели после квантования, включая редкие критичные случаи; размер файла сам по себе не подтверждает пригодность.
M05 · Префиксный KV-cache и повторное использование prompt
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Automatic Prefix Caching в vLLM переиспользует KV-блоки при совпадении префикса и может снижать время prefill; если запросы не разделяют префикс или длительное декодирование ответа доминирует, выигрыш полного ответа не гарантирован.
Когда применимо: Много запросов повторяют длинный начальный фрагмент prompt/истории, а время первого токена влияет на UX или стоимость.
Область версии: Документация vLLM Automatic Prefix Caching, по реестру источников наблюдалась 16 октября 2026; карточка составлена 17 октября; release vLLM, хэш-политика, tenant-конфигурация и модель для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
vllm-cache · Описывает механизм кеширования общих префиксов, повторный доступ и его пределы.
Не подтверждает: Не доказывает ускорение decode, выигрыш при длинных ответах или безопасность произвольной многопользовательской конфигурации.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: По документации vLLM APC ускоряет prefill, а не decode; особенно слабый эффект ожидаем при длинном ответе или отсутствии общего префикса. Изоляцию арендаторов нужно проверить отдельно.
Следующее действие: Сейчас оценить по обезличенным логам долю запросов с одним длинным префиксом; только при заметной доле измерять APC на закреплённой версии.
Когда остановиться: Не включать многопользовательский APC, если cache_salt/метрики недоступны, обнаружен межарендаторный hit/timing-сигнал или нагрузка не разделяет длинный префикс.
Необязательный план опыта
Вход: Закрепить vLLM/model/tokenizer, два синтетических tenant и длинный одинаковый начальный prompt. Для каждого salt сделать cold и warm запросы с одинаковым префиксом; логировать hit/miss, TTFT и p50/p95.
Контроль: С тем же salt изменить первый блок префикса (ожидаем отсутствие reuse), затем поздний блок (возможен частичный reuse); повторить общий префикс с другим tenant salt. Сравнить timing distribution и cache-hit второго tenant с холодным baseline, не ограничиваясь поиском секретной строки в ответе.
Успех: Для одного salt warm shared-prefix даёт ожидаемое повторное использование и измеримый TTFT-эффект; другой salt не даёт межарендаторного cache-hit или различимого timing-сигнала в границах заранее выбранной чувствительности.
Сигнал отказа: Межарендаторный hit/timing-сигнал или отсутствие ожидаемой разницы cold/warm; отсутствие счётчиков/salt-support делает проверку изоляции inconclusive, а не успешной.
До самостоятельной рекомендации: Нет измерения доли совпадающих префиксов, TTFT и изоляции арендаторов на закреплённой версии; из механизма кеша не следует выигрыш или безопасное применение.
M06 · Маршрутизация моделей и управляемый fallback
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: LiteLLM маршрутизирует модельные запросы и описывает fallback; внешние эффекты возникают только через отдельный агентный tool executor. Без его ledger повторный model request может породить повторный intent, но само наличие router не доказывает дубль committed effect.
Когда применимо: Приложению нужны несколько модельных backend из-за лимитов, отказов или цены; часть задач может запускать внешние действия.
Область версии: Документация LiteLLM routing по снимку реестра 16 октября 2026; карточка составлена 17 октября; версии gateway, моделей и политики retries не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
litellm · Описывает маршрутизацию, fallback и retry-механизмы gateway.
Не подтверждает: Не гарантирует одинаковое качество, совместимость JSON/tool semantics или идемпотентность действий.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: LiteLLM управляет модельными запросами, не исполнением инструмента приложения. Дублирование committed effect зависит от agent loop, retry policy и sink; потерянный ACK требует честного unknown.
Следующее действие: Если в продукте есть model fallback, сначала отметить read-only и неидемпотентные операции и изучить текущую retry-политику; запрет или отдельный контроль для побочных эффектов решать по фактическому executor и ledger.
Когда остановиться: Не включать fallback для side-effect workflow без устойчивого idempotency key, ledger и процедуры сверки unknown; отдельный read-only fallback можно оценивать независимо.
Необязательный план опыта
Вход: Синтетический agent loop с двумя закреплёнными backend и отдельным tool executor: 20 задач, ledger каждого tool intent, каждой попытки и каждого committed effect. Инъецировать отказ модели до ответа, после частичного ответа, после tool intent и потерю ACK после commit.
Контроль: Тот же agent loop без model fallback; тот же tool executor, idempotency key и сценарии отказа. Не смешивать retry модельного API с повтором вызова tool.
Успех: Fallback улучшает доступность модельного шага при соблюдении лимитов; для side effect ledger показывает не более одного committed effect на intent, а lost ACK остаётся unknown до сверки.
Сигнал отказа: Router меняет критический смысл/формат; tool executor выполняет второй commit либо скрывает unknown после потери ACK.
До самостоятельной рекомендации: Не испытаны fallback после таймаута и побочных эффектов и семантика двух закреплённых моделей; наличие маршрутизатора не доказывает безопасный перенос.
M07 · Генерация по схеме и структурированный результат
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Ограниченная генерация по JSON schema в SGLang помогает соблюсти синтаксический контракт, но валидный объект может содержать неверные значения; проверка смысла остаётся отдельной.
Когда применимо: Ответ модели потребляет программа со строгим JSON-контрактом, где ошибка формата и ошибка значения имеют разные последствия.
Область версии: SGLang structured outputs, снимок реестра 16 октября 2026, карточка составлена 17 октября; runtime release, backend, модель и диалект JSON Schema для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
sglang-structured · Документирует режимы структурированного вывода и ограничения формата.
Не подтверждает: Не доказывает истинность значений или прохождение бизнес-инвариантов.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Частичная поддержка схем и скрытые исправления/повторы зависят от runtime и требуют закрепления версии.
Следующее действие: Сейчас выписать отдельно JSON-схему и бизнес-инварианты своей интеграции; затем сравнить constrained вывод с обычным на небольшом корпусе.
Когда остановиться: Не считать валидный JSON основанием для автодействия, если смысловые ошибки не проходят отдельный порог.
Контроль: Та же модель без constrained decoding плюс поствалидация; одинаковый корпус и retry policy.
Успех: Режим полезен при снижении форматных отказов без роста семантических ошибок и задержки сверх заранее заданного бюджета.
Сигнал отказа: Откатить при ложной уверенности: схема проходит, но критически неверные значения становятся чаще.
До самостоятельной рекомендации: Не измерены одновременно соответствие схеме и правильность значений на закреплённом backend; нельзя превращать форматный контракт в оценку качества.
M08 · Мультимодальное чтение интерфейсов и документов
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Для двухколоночных русскоязычных PDF с таблицами PaddleOCR-VL даёт проверяемый кандидат на извлечение блоков и порядка чтения; наличие VLM и заявленные автором benchmark не доказывают выигрыш над OCR-only на наших документах.
Когда применимо: Нужно извлекать смысл из двухколоночных русскоязычных PDF с таблицами и сносками, где простой OCR теряет порядок чтения.
Область версии: PaddleOCR/VL: страницы проекта наблюдались 16 октября 2026 по реестру; официальная документация PaddleOCR-VL-0.9B перечитана 17 октября. Model weights, pipeline release и параметры для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
paddleocr · Показывает компоненты распознавания и разбора документов.
Не подтверждает: Не гарантирует точности на русских газетных полосах, таблицах и мелком шрифте.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Один тип PDF не переносится на веб-интерфейсы. Авторские показатели PaddleOCR-VL — заявление проекта; browser-use относится к другой задаче и оценивается в I06.
Следующее действие: Если приходится разбирать двухколоночные PDF, сначала разметить несколько собственных страниц и сверить источник PaddleOCR-VL; только затем сравнивать его с OCR-only на одинаковых изображениях.
Когда остановиться: Оставить OCR-only или ручную проверку, если VL pipeline неверно связывает числа/таблицы или порядок чтения не улучшается на размеченных страницах.
Необязательный план опыта
Вход: 30 размеченных синтетических двухколоночных русскоязычных PDF-страниц с таблицами и сносками; кандидат — закреплённый PaddleOCR-VL-0.9B с layout detection, каждая страница подаётся как одно и то же изображение.
Контроль: OCR-only PaddleOCR на тех же page images без VL/layout interpretation; ручная разметка блоков, reading order и ячеек создана до запусков. Веб-действия и browser-use вынесены в I06.
Успех: Кандидат улучшает заранее выбранные reading-order/table метрики без роста критических выдуманных фактов и в пределах установленного времени обработки.
Сигнал отказа: Одинаковый/худший порядок чтения, ложные таблицы или потеря критического числа при более высокой цене/задержке.
До самостоятельной рекомендации: Для доказательной орбиты нужны закреплённые версии PaddleOCR-VL и OCR-only baseline, размеченные двухколоночные PDF и независимая проверка порядка чтения, таблиц, цены и задержки; документальная карточка доступна без опыта.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Speculative decoding в vLLM предоставляет механизм ускорения генерации при подходящей паре draft/target; фактический выигрыш на агентных ответах зависит от длины, acceptance rate и накладных расходов.
Когда применимо: Команда уже обслуживает открытые веса и значительную часть задержки занимает генерация токенов; есть профиль коротких и длинных ответов.
Область версии: Документация vLLM speculative decoding по снимку реестра 16 октября 2026; карточка составлена 17 октября; версии target/draft, GPU и конфигурация не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
vllm-spec · Описывает speculative decoding и варианты настройки в serving.
Не подтверждает: Не гарантирует выигрыш для коротких агентных ответов или нашей нагрузки.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Ускорение токенов в синтетическом benchmark не равняется ускорению многошагового агентного workflow.
Следующее действие: Сейчас измерить распределение длин prompt/ответа и долю времени на decode; только при подходящем профиле планировать benchmark speculative режима.
Когда остановиться: Отключить speculative режим, если p95 полного агентного шага не улучшается или растут VRAM/ошибки.
Необязательный план опыта
Вход: Запись реальной смеси коротких tool calls и длинных ответов; закрепить target/draft веса и GPU.
Контроль: Тот же target без speculative режима, одинаковые concurrency и sampling параметры.
Успех: Оставить режим только для поднагрузок с повторяемым улучшением p95/стоимости без изменения результата сверх допуска.
Сигнал отказа: Откатить при ухудшении коротких ответов, дефиците VRAM или нестабильной tail latency.
До самостоятельной рекомендации: Нет парного профиля обычного и speculative serving на закреплённых весах и реальном распределении длин; механизм не устанавливает экономического выигрыша.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: TRL/GRPO и Agent Lightning дают средства оптимизации поведения агента по награде, но обнаруженный рост по видимому тесту может быть reward gaming, а не переносом на пользовательскую цель.
Когда применимо: Есть узкая повторяемая агентная задача, проверяемая награда, скрытый тест и ресурсы для обучения без использования секретных данных.
Область версии: Документация TRL GRPO и репозиторий Agent Lightning по снимку реестра 16 октября 2026; карточка составлена 17 октября; trainer/model revisions, датасет и функция награды не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
trl · Описывает GRPO trainer и вычисление награды.
Не подтверждает: Не доказывает качество обученного агента на скрытых задачах.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Обучение дорого и требует строгого разделения данных; вендорские примеры не заменяют независимое воспроизведение.
Следующее действие: Сейчас описать функцию награды и скрытый тест до затрат на обучение; если их нельзя разделить, оставить тему в наблюдении.
Когда остановиться: Не обучать дальше, если reward растёт без улучшения скрытого теста и human rubric либо падает безопасность инструмента.
Необязательный план опыта
Вход: Заморозить скрытый тест и 20 adversarial случаев до обучения; synthetic задачи с проверяемой наградой и отдельным human rubric.
Контроль: Исходный агент без обучения, тот же бюджет и инструменты; отдельный rule-based baseline.
Успех: Продолжать только если скрытый тест и human rubric улучшаются без роста критических ошибок; критерии установить до запуска.
Сигнал отказа: Остановить при reward hacking, утечке скрытого теста или ухудшении безопасности инструмента.
До самостоятельной рекомендации: Нет скрытого набора и независимой human-оценки после обучения; успех по видимой награде не даёт основания для орбиты воспроизведения.
M11 · Модели типизированных решений: выбор, оценка и вероятностное ветвление
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Jev TypeSafe AI заявляет типизированные ответы Choice/Score и распределения; их наличие можно проверить по API, но правильность выбора и калибровка вероятности требуют независимого опыта.
Когда применимо: Нужно многократно выбирать из конечных вариантов с измеримым риском, abstention и бюджетом; правила или LLM со схемой являются реальными альтернативами.
Область версии: Документация TypeSafe AI и анонс Jev, по реестру источников наблюдались 16 октября 2026; карточка составлена 17 октября; API model ID/revision и регион ещё не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
jev-launch · Анонсирует System One/Jev и приводит авторские сравнения скорости/цены.
Не подтверждает: Вендорские сравнения не являются независимой проверкой эффективности или калибровки.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Две страницы TypeSafe — одна линия; независимых опытов и закреплённого backend пока нет.
Следующее действие: Сейчас сравнить контракт typed questions с простыми правилами и LLM JSON на бумаге; платный тест запускать только при доступе, разрешённом бюджете и замороженном скрытом корпусе.
Когда остановиться: Не выбирать Jev по авторскому benchmark, если нет закреплённого backend или калибровка/риск на скрытом корпусе хуже правил.
Необязательный план опыта
Вход: 200 синтетических задач маршрутизации в пять классов, 50 shifted кейсов, заранее скрытый test и разрешённая тестовая учётная запись.
Контроль: LLM со схемой и простые правила; одинаковые входы, abstention policy и лимит стоимости.
Успех: Рассматривать отдельную модель только при лучшем риске/стоимости на скрытом корпусе после заморозки порога abstain.
Сигнал отказа: Остановить при некалиброванных confidence, провале shifted кейсов или исчерпании заранее разрешённого бюджета.
До самостоятельной рекомендации: Доступна только одна авторская линия TypeSafe, без API-пина, независимого опыта и калибровки; обещания скорости и confidence нельзя принять как доказанный эффект.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: В MCP 2025-11-25 outputSchema описывает structuredContent, но проверка схемы сама по себе не гарантирует совпадение с дублирующим текстовым JSON: наш ограниченный SDK-опыт принял намеренно расходящиеся представления.
Когда применимо: Инструмент MCP выдаёт structuredContent и, ради старых клиентов, текстовое представление того же результата.
Область версии: MCP 2025-11-25; TypeScript SDK server/core/node/client 2.0.0, Node 24.21.0, Zod 4.6.5, InMemoryTransport. MCP 2026-07-28 прочитан отдельно, но этим опытом не проверен.
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Контракт outputSchema/structuredContent и рекомендация текстового JSON для обратной совместимости.
Не подтверждает: Согласованность двух представлений или совместимость всех клиентов.
Внутренний исследовательский протокол · Восемь реальных локальных SDK-сценариев, включая приём несовпадающего текстового JSON.
Не подтверждает: Работу через HTTP/stdio или поведение другого SDK/версии протокола.
Внешний контекст
Thoughtworks Technology Radar · 2026-04-15 · Caution для «MCP by default» · Совет выбирать MCP при реальной нужде в протокольной совместимости; не оценка нашего конкретного опыта с outputSchema.
Наш опыт: 8/8 локальных сценариев в одном процессе; корректный structuredContent с расходящимся текстовым JSON был принят проверенной парой SDK.
Протокол ограниченного опыта: Внутренний исследовательский протокол; публичная ссылка на него отсутствует.
Главное ограничение: Синтетический InMemoryTransport и авторский опыт не равны независимому внедрению; схема не проверяет смысл результата.
Следующее действие: Если MCP tool выдаёт structuredContent и текстовый JSON, сначала сверить существующий контракт и тесты на их согласованность; добавить контроль при обнаруженном пробеле и доступном владельце интеграции.
Когда остановиться: Не полагаться на outputSchema как на проверку смысловой согласованности, если клиент молча принимает разный text и structuredContent.
Необязательный план опыта
Вход: Один tool с outputSchema, совпадающим и намеренно расходящимся structuredContent/text JSON; отдельно HTTP/stdio и второй клиент на закреплённых версиях.
Контроль: Схема и значения без дублирующего текстового представления; тот же клиент и сервер.
Успех: Клиент явно обнаруживает несогласованность двух представлений и не принимает неверное значение как успешное действие.
Сигнал отказа: Любой клиент молча принимает расходящиеся значения либо теряет isError/cancellation.
До самостоятельной рекомендации: Локальные 8/8 сценариев относятся лишь к MCP 2025-11-25, SDK 2.0.0 и InMemoryTransport; для более широкой орбиты нужны проверка артефакта редактором и другие клиенты/транспорты.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: MCP 2026-07-28 описывает OAuth-процесс удалённого сервера, но фактический доступ к tool должен проверяться для конкретного пользователя, audience и scope на каждом запросе.
Когда применимо: Удалённый MCP выполняет действия от имени разных пользователей или арендаторов и использует scopes с разным уровнем доступа.
Область версии: MCP authorization 2026-07-28 и OWASP: исходные страницы наблюдались 16 октября 2026 по реестру; карточка составлена 17 октября. OAuth server, клиентские версии, scopes и tenant policy для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
mcp-auth · Задаёт протокольные требования к авторизации удалённого MCP.
Не подтверждает: Не определяет минимальные права конкретного приложения и не гарантирует изоляцию пользователей.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: OAuth доказывает процедуру получения токена, а не корректную авторизацию ресурса; нужен аудит policy.
Следующее действие: Сейчас составить таблицу пользователь–scope–tool и ожидаемых отказов; подключать remote MCP только после негативных тестов.
Когда остановиться: Отключить удалённый tool при принятии чужого/просроченного токена, расширенного scope или неатрибутируемом действии.
Необязательный план опыта
Вход: Тестовый remote MCP с двумя пользователями, двумя scopes, просроченным/чужим токеном и вредоносным tool output.
Контроль: Прямой вызов API под теми же принципалами; таблица ожидаемых разрешений подготовлена заранее.
Успех: Принять лишь если все отрицательные сценарии отказывают и журнал связывает действие с правильным субъектом.
Сигнал отказа: Отключить remote MCP при privilege escalation, принятии чужого токена или неатрибутируемом действии.
До самостоятельной рекомендации: Нет матрицы scope/audience и отрицательных тестов двух пользователей на конкретном сервере; стандарт OAuth не подтверждает least privilege реализации.
I03 · A2A: обнаружение агентов, задачи и артефакты
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: A2A специфицирует Agent Card, задачи и артефакты для межагентного обмена; совместимый wire format не гарантирует, что независимые агенты одинаково понимают завершение и отмену задачи.
Когда применимо: Два независимо реализованных агента должны обмениваться задачами и артефактами через сетевую границу.
Область версии: Актуальная публичная A2A specification по снимку реестра 16 октября 2026; карточка составлена 17 октября; точный protocol version, SDK commits и два контрагента для опыта ещё не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
a2a · Описывает discovery, lifecycle задачи, сообщения и артефакты.
Не подтверждает: Не доказывает семантическую совместимость двух конкретных реализаций.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Без закрепления версии latest-документа изменение спецификации делает вывод невоспроизводимым.
Следующее действие: Сейчас закрепить версию A2A и выписать state transitions/артефакты из спецификации; затем проверить два независимых SDK.
Когда остановиться: Не использовать межагентную связку для действия с последствиями, если результат отмены скрывается либо статусы/артефакты расходятся с закреплённой спецификацией.
Необязательный план опыта
Вход: Зафиксировать неизменную версию A2A spec и две независимые SDK-версии; синтетическая задача с текстовым и файловым артефактом, проверяемыми hash, запросами отмены до/после начала выдачи.
Контроль: Прямой HTTP-контракт для той же задачи и отдельно таблица допустимых переходов/ответов отмены из выбранной pinned A2A spec.
Успех: Обе реализации соблюдают переходы закреплённого контракта, целостность артефактов и честно сообщают результат отмены: отказ/уже завершена могут быть допустимы, если так предусматривает spec.
Сигнал отказа: Незаконный по pinned spec переход, потерянный/дублированный артефакт или UI заявляет успешную отмену при фактически завершённой задаче.
До самостоятельной рекомендации: Не закреплены версия A2A и пара независимых реализаций; без сквозного теста lifecycle/артефактов нельзя заявить фактическую совместимость.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: ACP определяет протокол редактор–агент; перенос одного агента между клиентами следует проверять отдельно по разрешениям, правкам и восстановлению сессии.
Когда применимо: Одного coding agent требуется использовать из двух редакторов при сохранении контроля правок, разрешений и сессии.
Область версии: agentclientprotocol.com introduction и документация Claude Code, по реестру источников наблюдались 16 октября 2026; карточка составлена 17 октября; ACP revision, клиентские версии и агент для теста не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
acp · Описывает роль клиента и агента и направление протокольного обмена.
Не подтверждает: Не гарантирует поддержку всех возможностей конкретным редактором.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: ACP не следует смешивать с A2A: протоколы решают разные границы взаимодействия.
Следующее действие: Сейчас проверить, поддерживают ли два нужных редактора одну ревизию ACP и требуемые permissions; только потом запускать interop-тест.
Когда остановиться: Не объявлять ACP переносимым, если второй клиент теряет разрешение, часть diff или состояние сессии без явной ошибки.
Необязательный план опыта
Вход: Один ACP-агент и два независимых поддерживающих клиента; тестовый репозиторий с правкой, отказом разрешения и прерыванием.
Контроль: Стабильный клиент агента как baseline; одинаковые задания и git snapshot.
Успех: Считать переносимым лишь покрытый общий поднабор функций с эквивалентным результатом и явным отказом в непокрытых случаях.
Сигнал отказа: Вернуться к исходному клиенту при молчаливой потере разрешений, контекста или правок.
До самостоятельной рекомендации: Не названы два клиента с подтверждённой поддержкой одного ACP revision; документация протокола не доказывает переносимость правок и разрешений.
I05 · AG-UI и поток состояния между агентом и интерфейсом
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: AG-UI описывает поток событий для состояния агентного интерфейса, но после разрыва соединения интерфейс обязан отличать незавершённый шаг от уже совершённого действия.
Когда применимо: UI показывает поток работы агента с паузами и побочными эффектами и обязан корректно переживать разрыв соединения.
Область версии: AG-UI introduction перечитана 17 октября 2026; LangGraph interrupts наблюдалась 16 октября 2026 по реестру. Revision/SDK, transport и persistence layer не выбраны.
Свидетельства, ограничения и следующий шаг
Первоисточники
agui · Документирует события и связь между агентом и UI.
Не подтверждает: Не гарантирует exactly-once исполнение tool call или автоматическое восстановление состояния.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: События UI не являются источником истины о серверном действии; нужен durable journal.
Следующее действие: Сейчас назначить backend journal источником истины и перечень неоднозначных UI-состояний; затем испытать reconnect на макете.
Когда остановиться: Не считать поток надёжным для действий с последствиями, если попытки вызова не видны отдельно от commit или UI показывает завершение без backend подтверждения.
Необязательный план опыта
Вход: AG-UI клиент и агент на закреплённых версиях; синтетический tool пишет committed effect в idempotent ledger, отдельный append-only счётчик записывает каждую попытку вызова, включая подавленные дубли. Оборвать UI до/после tool-call и ACK.
Контроль: Polling UI того же backend и authoritative journal; одинаковые сценарии обрыва и idempotency key.
Успех: UI восстанавливает статус из backend journal, не объявляет unknown завершённым; ledger не содержит второго commit, а счётчик попыток показывает, были ли скрытые idempotency-дубли.
Сигнал отказа: Ложный complete, второй committed effect или скрытая повторная попытка tool call, даже если idempotent sink не дал второго commit.
До самостоятельной рекомендации: Нет durable журнала и испытания reconnect вокруг tool call; поток событий сам по себе не подтверждает корректность состояния UI после обрыва.
I06 · Браузерные действия: агент или детерминированный сценарий
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Агентный browser-use может адаптировать действия при изменении страницы, тогда как Playwright даёт явный проверяемый сценарий; выигрыш адаптивности надо оценить вместе с риском неверного клика.
Когда применимо: Сайт часто меняет DOM, а команда решает, оправдывает ли адаптивный агент риск по сравнению с существующим Playwright-сценарием.
Область версии: browser-use и Playwright docs по снимку реестра 16 октября 2026; карточка составлена 17 октября; browser versions, модель агента и fixture-приложение не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
browser-use · Показывает агентный подход к действиям в браузере.
Не подтверждает: Не подтверждает безопасность или успешность на конкретном сайте.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Тестовый сайт не заменяет условия реального сайта, особенно CAPTCHA, auth и изменения политики.
Следующее действие: Сейчас перечислить действия с побочным эффектом и текущие Playwright-локаторы; агентный режим проверить сперва на read-only копии интерфейса.
Когда остановиться: Вернуться к явному сценарию и подтверждению человеком при любом ошибочном клике с побочным эффектом.
Необязательный план опыта
Вход: Тестовый сайт с 20 задачами и контролируемыми изменениями DOM, модалками, 429 и ловушкой похожей кнопки.
Контроль: Playwright-сценарий с явными локаторами и одинаковым доступом; неизвестные изменения не подсказывать агенту.
Успех: Агентный режим допустим лишь при измеренном снижении ремонта без критически неверных действий и с подтверждением опасных шагов.
Сигнал отказа: Откатить при ложном успешном завершении или неверном side effect даже если общий success выше.
До самостоятельной рекомендации: Нет парного теста на одинаковом изменяемом UI с учётом ошибочных side effects; демо agent browser не подтверждает безопасное преимущество над скриптом.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Документация Claude Code подтверждает работу через CLI; для включения произвольной команды как инструмента нашего агента нужны дополнительно заданные приложением правила exit/stdout/stderr, таймаута и полномочий.
Когда применимо: Агенту нужен доступ к существующей CLI-команде с побочными эффектами или ошибками, которую нельзя безопасно выразить только человеческим выводом.
Область версии: Документация Claude Code и Anthropic agent patterns по снимку реестра 16 октября 2026; карточка составлена 17 октября; shell, tool wrapper и версия агента для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
claude-code · Подтверждает терминальный/CLI режим Claude Code как пример доступной поверхности.
Не подтверждает: Не определяет безопасный контракт произвольного нашего CLI wrapper, поведение empty exit-0 и состояние частичного внешнего эффекта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Машинный контракт и граница доверия — требования нашего приложения, а не обещания Claude Code overview; exit 0 сообщает статус процесса, но не факт нужного результата.
Следующее действие: Сейчас описать машинный формат результата, exit/timeout и allowlist для одного CLI; затем прогнать набор отрицательных fixtures.
Когда остановиться: Убрать CLI из allowlist, если wrapper скрывает empty result/unknown effect, повторяет команду после timeout без идемпотентности или слушается инструкции из вывода.
Необязательный план опыта
Вход: Тестовая CLI-команда с success JSON, stderr warning, exit 1, timeout после частичного ledger effect, malformed JSON, empty stdout при exit 0 и synthetic prompt injection в stdout/stderr.
Контроль: Программный вызов той же операции без агентного парсинга и wrapper со строгой схемой результата; зафиксировать ожидаемый контракт каждого сценария.
Успех: Wrapper однозначно различает process success и наличие валидного результата; empty exit-0 не считается выполненной задачей, partial effect после timeout остаётся unknown до сверки, инъекция игнорируется.
Сигнал отказа: Пустой exit-0 принят как готовый результат, неизвестный частичный эффект повторён автоматически или stdout изменил задачу агента.
До самостоятельной рекомендации: Нет закреплённого wrapper и набора отрицательных CLI fixtures для exit, timeout и инъекции в stdout; существование CLI не доказывает его безопасность как tool.
I08 · Каталоги возможностей и проверка совместимости серверов
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Реестр MCP помогает находить серверы и метаданные, но запись в каталоге не равна живой совместимости по версии, схемам, auth и фактическим tool calls.
Когда применимо: Команда ищет чужие MCP-серверы в каталоге и должна отличать описание возможности от совместимого живого endpoint.
Область версии: MCP Registry наблюдался 16 октября 2026 по реестру; MCP tools specification 2026-07-28 перечитана 17 октября. Registry snapshot и выборка серверов для опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
mcp-registry · Описывает реестр и его метаданные для обнаружения MCP-серверов.
Не подтверждает: Не доказывает, что endpoint жив, безопасен или поддерживает все объявленные возможности.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: Каталог и сервер могут меняться независимо; проверка одной выборки быстро устаревает.
Следующее действие: Сейчас использовать registry только как список кандидатов и сверить identity/version/scopes одного сервера перед подключением; затем автоматизировать выборочную проверку.
Когда остановиться: Не предлагать сервер к подключению при расхождении identity/schema, недоступном endpoint или неизвестных полномочиях.
Необязательный план опыта
Вход: Замороженная случайная выборка 30 публичных записей с явно доступными тестовыми endpoint; фиксировать дату/commit registry.
Контроль: Ручной curated список известных серверов как baseline; одинаковый клиент и версия протокола.
Успех: Использовать каталог для выбора кандидатов, если проверка capability явно отделена от метаданных и не допускает side effects.
Сигнал отказа: Отключить запись при расхождении identity/schema, неожиданном доступе или опасном tool без подтверждения.
До самостоятельной рекомендации: Нет замороженной выборки registry и живой проверки handshake/list/call; метаданные каталога не являются свидетельством работоспособности сервера.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Документация promptfoo предусматривает отчёты JSON/JUnit и отказ CI при неуспешных проверках; наличие такого механизма ещё не означает, что выбранный eval-набор обнаружит регрессию продукта.
Когда применимо: Команде с повторяемыми AI-изменениями и CI, способной хранить фиксированный eval corpus.
Область версии: Документация promptfoo CI/CD, просмотрена 16–17 октября 2026; версия CLI, модель, provider и ревизия корпуса пока не закреплены.
SHA-256 основного снимка: 99079653c7961e10a49791815f6a4c4cc6042f4b68a9e882eaa22f31c5b91b8e
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Форматы отчёта и способы остановить CI по результатам eval.
Не подтверждает: Чувствительность нашего набора к реальным дефектам.
Внешний контекст
Thoughtworks Technology Radar · 2023-09-27 · Assess для promptfoo; запись историческая, не в текущем выпуске · Показывает внешнюю экспертную оценку инструмента на дату записи, а не актуальный статус версии 2026 года.
Наш опыт: Не проводился.
Главное ограничение: Меняющийся вместе с кодом корпус, стохастика и повторы могут дать ложный зелёный или ложный отказ.
Следующее действие: Сопоставить documented fail semantics promptfoo с перечнем уже известных продуктовых регрессий; отметить непокрытые классы и решить, нужен ли сначала информационный CI-отчёт.
Когда остановиться: Не включать блокирующий gate, если ложные остановки или пропуск инъецированной ошибки не измерены.
Необязательный план опыта
Вход: 40 synthetic tasks with pinned inputs, prompt, provider and corpus; inject a known regression in one task class.
Контроль: Unchanged baseline and hidden cases, repeated with identical CI configuration.
Успех: Injected regression consistently blocks CI while baseline passes; report false blocks.
Сигнал отказа: Regression passes or unchanged baseline fails without an explained nondeterministic cause.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q02 · Проверка траекторий и реального успеха агентной задачи
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Terminal-Bench публикует resolution rate для terminal-agent задач, SWE-bench — задачи исправления реальных software issues. Эти измерители проверяют разные формы результата; успешный trace агента не обязательно означает принятый patch или отсутствие нежелательного внешнего эффекта.
Когда применимо: Команде, которая выбирает coding agent по benchmark score или анализирует провалы траекторий.
Область версии: Досье называет Terminal-Bench 4.0; pinned task set, модель и harness отсутствуют.
SHA-256 основного снимка: 30d274eaf35d6a973208f7603bd35ca0427c8170fa6372c2f7333f7442d2d0c9
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: публикуемые таблицы зависят от harness, модели и набора задач; нельзя переносить их на наш репозиторий без воспроизведения. Траектория полезна для объяснения ошибки, но oracle должен включать файлы, тесты и тестовый ledger внешних действий.
Следующее действие: Открыть по одной публичной задаче и verifier из Terminal-Bench и SWE-bench; выписать, какие исходы они принимают и какие эффекты остаются вне oracle вашей задачи.
Когда остановиться: Не считать leaderboard или правдоподобную траекторию достаточным доказательством принятой задачи.
Необязательный план опыта
Вход: Ten pinned Terminal-Bench and ten pinned SWE-bench tasks; record trace, diff, independent tests and synthetic side-effect ledger.
Контроль: Compare trace-only verdict with file/test/effect oracle under identical model, harness and budget.
Успех: Classify all four combinations of apparent trace success and actual task success, with discordance rate.
Сигнал отказа: Trace success is treated as task success despite wrong patch or unwanted external effect.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q03 · Калибровка LLM-as-judge по человеческой разметке
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Ragas Faithfulness оценивает, поддерживаются ли утверждения ответа предоставленным контекстом. Это отдельный вопрос от истинности контекста в мире и от предпочтения одного ответа другому; калибровка парного LLM-судьи не доказывает качество Faithfulness.
Когда применимо: Команде, где LLM-судья участвует в регулярной оценке ответов или PR.
Область версии: LLM-judge как оценочный метод и Ragas Faithfulness как пример автоматической проверки поддержанности ответа контекстом. Модель судьи, prompt и версии не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Faithfulness проверяет, поддерживается ли утверждение ответа предоставленным контекстом.
Не подтверждает: Истинность предоставленного контекста в мире, предпочтение ответа или качество нашей человеческой рубрики.
Проверка: exact-page-live-reviewed-2026-10-17; no saved body hash
agents-patterns · Базовые архитектурные паттерны; историческая публикация2024, не свежий анонс.
Не подтверждает: Калибровку Ragas Faithfulness или парного LLM-судьи; это общий инженерный контекст.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: судья может предпочитать собственный стиль/модель, реагировать на порядок ответов и неверный контекст. Нельзя использовать его оценки как редакционную подпись Радара. Агентные паттерны Anthropic обсуждают проверки, но не калибруют нашего судью.
Следующее действие: На нескольких уже имеющихся примерах разметить отдельно поддержку ответа контекстом, истинность в мире и пользовательское предпочтение; записать рубрику и спорные случаи без запуска судьи.
Когда остановиться: Не применять score как gate, если он не калиброван на held-out и зависит от порядка/стиля.
Необязательный план опыта
Вход: Для 80 пар ответов получить от двух независимых людей три разные метки: поддержка утверждений данным контекстом, истинность проверяемых фактов в мире и предпочтение ответа по заданному rubric. Спорные метки согласовать до запуска судьи.
Контроль: Слепая проверка поддержки контекстом отдельно от A/B и B/A предпочтения; включить заведомо ложный контекст, при котором ответ может быть faithful, но фактически ложным; вторую модель судьи использовать как sensitivity check.
Успех: На held-out отдельно сообщить agreement по поддержке контекстом, world-truth ошибкам и предпочтению, а также порядок-зависимость и частоты расхождений; ни одну метрику не подменять другой.
Сигнал отказа: Faithfulness назван правдой о мире либо перестановка парного судьи объявлена проверкой контекстной поддержки без отдельных меток.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q04 · Трассировка GenAI и инструментов через OpenTelemetry
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Проект OpenTelemetry определяет соглашения о GenAI-событиях; Langfuse принимает OTel traces. Возможность экспортировать span не доказывает связности пользовательской задачи, точности стоимости или отсутствия секретов в атрибутах.
Когда применимо: Команде, которая расследует tool failures, стоимость вызовов и риск утечки в наблюдаемости.
Область версии: OpenTelemetry GenAI semantic conventions и Langfuse OTLP intake. Версии semconv/SDK/collector не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 1a79bc8b0dd4410585d29fe8084dbfda1f6ab8de4ba095a38d5f09a7effee4c2
Свидетельства, ограничения и следующий шаг
Первоисточники
otel · Текущий репозиторий GenAI semantic conventions, на который перенаправляет документация OpenTelemetry.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: schema/version drift может разорвать сопоставимость, а стоимость зависит от тарифной таблицы, не только от token count. Данные prompt/tool result в span требуют редактирования до экспорта; один post-hoc UI-фильтр недостаточен.
Следующее действие: По текущим документам составить список нужных span fields, чувствительных атрибутов и совместимых экспортёров; отметить отсутствующее правило редактирования до отправки.
Когда остановиться: Отключить экспорт чувствительных payload, если редактирование не работает до отправки.
Необязательный план опыта
Вход: A synthetic request invoking model, MCP and shell, with canary secrets in input/tool output.
Контроль: Pin semconv, SDK, collector, exporter and tariff; compare exported trace with independent event ledger and fail collector.
Успех: One reconstructable trace with correct parentage and no canary in exported data; declared failure policy observed.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q05 · Детерминированные проверки и mutation testing
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Mutation testing намеренно меняет код и проверяет, убьют ли тесты мутант; высокая coverage строк сама по себе не гарантирует это. Thoughtworks описывает быстрые feedback sensors для coding agents как практический сигнал, но конкретный выигрыш для Радара надо измерить.
Когда применимо: Команде с критичными ветвлениями, где обычная coverage выглядит высокой.
Область версии: Stryker Mutator для JS/TS как контроль чувствительности тестов. Release/config не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: cfc6a1aac9bc2a214e26027f6ddd1f9748aeb180199f69ba0e441cc5719bc542
Главное ограничение: surviving mutant может быть эквивалентным исходной программе или вне значимого пути; процент mutation score без ручной классификации вводит в заблуждение. Нельзя запускать мутатор на production-сервисе, только на изолированной копии.
Следующее действие: Выбрать одну критическую ветвь в существующем коде и проверить вручную, какое имеющееся утверждение теста обнаружит инверсию условия; mutation run оставить возможной последующей проверкой.
Когда остановиться: Не объявлять suite надёжной, если хотя бы один критичный known fault остаётся зелёным.
Необязательный план опыта
Вход: Five preselected Radar conditions, manually broken one at a time, then automated Stryker mutations on a fixed commit.
Контроль: Run original suite before/after each fault; classify equivalent mutants manually.
Успех: Each known critical fault is caught by a specific deterministic test; mutation cost and surviving mutants reported.
Сигнал отказа: Coverage remains green on a preselected critical fault or score is reported without mutant classification.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: OWASP описывает попытку повлиять на поведение модели через недоверенный текст, включая документы и результаты инструментов. MCP authorization задаёт отказ при отсутствующих/недостаточных правах. Даже корректная авторизация инструмента не делает текст из него доверенной инструкцией.
Когда применимо: Агентам, читающим сторонние документы, репозитории или tool output перед действиями.
Область версии: OWASP LLM01 — модель угроз; MCP authorization относится к спецификации 2026-07-28. Исполняемый harness не выбран.
SHA-256 основного снимка: f73eb706a9fe61bf85e695a8acae15da3d4ee65a5def9ebe88bbddbb0209f4c6
Свидетельства, ограничения и следующий шаг
Первоисточники
owasp-injection · Недоверенные инструкции и границы полномочий.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: защита не сводится к поиску одной фразы; модель может ошибиться и без атаки, а отказ в запрещённом tool call не гарантирует отсутствия утечки в ответе. Реальных секретов/внешних адресов в опыте не использовать.
Следующее действие: Нарисовать путь от недоверенного документа/tool result до действия агента и фактической проверки полномочий сервисом; отметить каналы без границы и примеры OWASP.
Когда остановиться: Не расширять полномочия агента, если контроль недоверенного текста или service authorization даёт обход.
Необязательный план опыта
Вход: 30 benign and 20 adversarial synthetic documents/tool results, fictional canary and local sink.
Контроль: Same legitimate tasks and permissions with/without untrusted-content boundary; insufficient-scope control.
Успех: Forbidden calls and leaks are zero in scoped test while benign task success and false refusals are reported.
Сигнал отказа: Attack reaches tool/sink, canary leaks, or benign tasks fail under purported protection.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Документация Claude Code ограничивает shell sandbox командами shell и потомками; встроенные file tools, hooks и MCP находятся вне этой границы. Проверяемый тезис — запрет должен выполняться на каждом реально доступном пути исполнения в конкретной VM, а не выводиться из названия sandbox.
Когда применимо: При автономном запуске shell, file tool, MCP или hooks на недоверенном материале.
Область версии: Документация Claude Code sandboxing наблюдалась 16 октября 2026; подготовлена Claude Code 2.1.296 в offline VM, но product controls shell/file/MCP/hooks не запускались.
SHA-256 основного снимка: 002a025c50e30877b78dc31ef38cdc972df1a2ee6f66040ed3872ea969f9e7ba
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Документирован shell boundary и исключённые пути file tools/hooks/MCP.
Не подтверждает: Эффективность всех границ исполнения в конкретной VM.
Главное ограничение: Sandbox для shell не охватывает автоматически file tools, MCP и hooks; на другом OS/профиле вывод может измениться. VM создаёт внешнюю границу и не должна делить host mounts/секреты.
Следующее действие: Сверить включённые shell, file, MCP и hook пути с документацией sandbox и текущей конфигурацией; записать непокрытые пути без утверждения о фактическом enforce.
Когда остановиться: Остановить автономный запуск, если запрещённый shell-эффект проходит внутри VM, путь file/MCP/hook остаётся вне внешней изоляции либо возможен выход за границу VM.
Необязательный план опыта
Вход: Disposable offline VM; matrix of shell, file tools, mock MCP and hooks against allowed/forbidden paths and local endpoints.
Контроль: Sandbox on/off only inside VM, strict retry and excludedCommands observed separately, VM resource cap independent.
Успех: Declared deny paths fail, allowed controls work, and every execution path outside shell boundary is identified.
Сигнал отказа: Запрещённый эффект прошёл через настроенную границу shell sandbox даже оставаясь внутри VM; отдельно считать выход за VM как нарушение внешней границы. Пути file/MCP/hooks оценивать отдельно, не называя их shell sandbox escape.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q08 · Секреты, минимальные полномочия и аудит действий
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Claude Code описывает разрешения, исполняемые средой агента, включая deny/ask/allow; это не ограничивает автоматически полномочия удалённого сервиса и не доказывает полноту аудита или защиту секрета во всех каналах.
Когда применимо: При выдаче агенту токена, write scope или доступа к внешнему сервису.
Область версии: Страница Claude Code permissions, просмотрена 16–17 октября 2026; версия исполняемого harness и политика для лаборатории ещё не закреплены.
SHA-256 основного снимка: 2f545d306417a6b412bfdf0ee1a9c39db445721f2dc5b94ba6dd06587fec3bbe
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Конфигурация и применение permission rules в Claude Code.
Не подтверждает: Фактические отказы внешнего сервиса, TTL/отзыв токена или отсутствие утечек.
Внешний контекст
McKinsey · 2025 · Рекомендует ownership, надзор, контроль доступа и мониторинг для agentic AI · Общий управленческий контекст; не испытание Claude Code или нашей конфигурации.
Наш опыт: Не проводился.
Главное ограничение: Harness deny, отказ сервиса и журнал попыток — разные наблюдения; один успешный отказ не проверяет остальные границы.
Следующее действие: По конфигурации и документации перечислить issuer, scope, TTL, revocation и владельца audit для токена; явно отметить неизвестные каналы вывода.
Когда остановиться: Не выдавать боевые учётные данные при утечке canary, неполном audit или продолжении отозванного доступа.
Необязательный план опыта
Вход: Mock issuer/service with read and write scopes, expiry/revocation, synthetic tokens and exhaustive output-channel canaries.
Контроль: Compare harness allow/ask/deny, service authorization and redaction separately using attempt, decision and service ledgers.
Успех: Zero unauthorized effects or canary leaks; each attempt has consistent harness/service receipts, including post-revocation.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q09 · Происхождение навыков, инструментов и сборок
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: SLSA 1.2 требует проверять provenance артефакта против ожиданий потребителя; такая проверка не говорит, безопасна ли инструкция навыка. Наши узкие локальные и VM-контроли различили часть подмен, но полный продуктовый путь навыка не испытан.
Когда применимо: Перед установкой стороннего skill/tool/package или запуском полученной сборки.
Область версии: SLSA specification 1.2; локальный cryptography 41.0.7; официальный slsa-verifier 2.7.1. Версия исполняемого навыка отсутствует.
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · SLSA 1.2 описывает проверку artifact provenance по ожидаемой потребителем политике.
Не подтверждает: Безопасность поведения содержимого навыка или полную цепочку доверия нашего verifier.
Проверка: exact-page-live-reviewed-2026-10-17; no saved body hash
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Локальный synthetic adapter: 7/7 ожидаемых исходов на семи случаях; отдельно отклонены испорченная подпись и TOCTOU-подмена при повторном чтении. Официальный slsa-verifier 2.7.1 в сетевой VM: опубликованный артефакт принят, неверные source/tag/bytes отклонены; неизвестный builder отвергнут ранним выбором verifier. Это не продуктовая проверка навыка.
Протокол ограниченного опыта: Внутренний исследовательский протокол; публичная ссылка на него отсутствует.
Дополнительный протокол 1: Внутренний исследовательский протокол; публичная ссылка на него отсутствует.
Главное ограничение: Локальный Ed25519 adapter не удостоверяет реальный issuer; официальный verifier тестировал собственный публичный релиз через сетевой Sigstore. Подписанный вредный skill требует отдельного review, а TOCTOU при исполнении пока не закрыт. В VM официальный verifier проверял собственный опубликованный release; это круговая зависимость доверия, а не независимая аттестация verifier.
Следующее действие: Прочитать существующие локальные и VM-артефакты; для конкретного планируемого пакета записать expected source, builder, digest, trust root и владельца review инструкций.
Когда остановиться: Не исполнять объект при несовпадении provenance либо нерассмотренном поведении, даже если подпись корректна.
Необязательный план опыта
Вход: Synthetic signed packages including altered bytes, wrong issuer/source/build parameters, missing provenance and signed harmful instruction.
Контроль: Compare digest-only with consumer policy; use independent pinned verifier and immutable post-check object.
Успех: All provenance mismatches rejected before execution; signed harmful instruction separately rejected in behavior review.
Сигнал отказа: Wrong identity or bytes accepted, TOCTOU swap succeeds, or provenance is equated with safe skill behavior.
До самостоятельной рекомендации: Документальный тезис и ограниченные результаты можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации о безопасности навыка нужны подписанная оценка конкретного пакета и проверка полной цепочки установки/исполнения; этого пока нет.
Q10 · Выпуск и откат изменений моделей, prompt и инструментов
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Promptfoo поддерживает автоматизированные eval и пороги CI, LiteLLM — маршрутизацию между deployment. Это позволяет строить проверку до rollout, но не доказывает, что откат prompt/модели/схемы инструмента восстановит прежний ответ у внешнего backend.
Когда применимо: Команде, выпускающей изменения prompt, модели, схемы tools и маршрутизации.
Область версии: Promptfoo CI eval и LiteLLM Router как документированные компоненты canary-процесса; конкретные версии, модель и конфигурация не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 2e37fce6245cefc29fd8f3cc9688aea0df790562a55f00e3ae370152bfd5985e
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: rollback должен фиксировать не только Git SHA приложения, но и prompt, tool schema, model ID/provider alias, routing config и dataset revision. Даже при прежнем alias веса модели могут измениться; требуется сохранять входы и проверять поведение. Не пускать canary на настоящие побочные эффекты.
Следующее действие: Составить tuple выпуска: Git SHA, prompt, tool schema, model ID/alias, provider route и eval corpus; отметить изменяемые внешним провайдером части и предел отката.
Когда остановиться: Не считать откат успешным, пока не восстановлены маршруты/config и проверяемое поведение.
Необязательный план опыта
Вход: 30 pinned tasks plus ten regression controls through test router; baseline, changed prompt/tool schema canary, rollback.
Контроль: Independent oracle and same recorded inputs, model IDs, route, config and eval corpus across phases.
Успех: Injected schema regression blocks canary; rollback restores configured state and observed outputs are separately compared.
Сигнал отказа: Canary passes known fault, or rollback is claimed merely from Git SHA while provider/alias behavior drifts.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q11 · Состояние внешнего мира в тестовых двойниках
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Thoughtworks предлагает temporal fakes для проверки системы во времени; LangGraph документирует паузу и возобновление графа. Статический ответ mock не воспроизводит порядок commit, ACK, timeout и retry, но симулятор может сам стать неточной моделью внешнего мира.
Когда применимо: Агентам с внешними write-эффектами, retry и паузой выполнения.
Область версии: temporal fake как практика моделирования событий и LangGraph interrupt как пример сохранённого состояния agent workflow. Исполняемая версия не выбрана. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: e241346c9234943cd03ca6ab6fc446aeb11f4fea1c5e59f67e8dc112ee3ba229
Свидетельства, ограничения и следующий шаг
Первоисточники
tw-fakes · Состояние и эволюция внешних зависимостей в тестовых двойниках.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Thoughtworks Technology Radar · 2026-04-15 · Assess · Внешняя рекомендация моделировать временное поведение; не доказательство fidelity нашего fake.
Наш опыт: Не проводился.
Главное ограничение: отдельно моделировать запись эффекта, потерю подтверждения, повтор и поздний ответ. Сравнить поведение fake с контролируемым реальным сервисом или эталонным ledger, чтобы исключить ложную уверенность от симулятора. Не утверждать exactly-once по одному успешному тесту.
Следующее действие: На бумаге пройти запись, потерю ACK и повтор с тем же idempotency key; сравнить с документированным контрактом используемого сервиса и указать неразрешённое состояние.
Когда остановиться: Не доверять fake и не обещать exactly-once при расхождении effect ledgers.
Необязательный план опыта
Вход: Stateful fake for write API with timeout-before-commit, timeout-after-commit, duplicate, late response and interrupt/resume.
Контроль: Replay identical idempotency-key sequences against local real test service and ordinary client.
Успех: Fake and service agree on effect ledger and recovery/unknown states for each sequence.
Сигнал отказа: Fake reports success where real service duplicates effects or leaves unresolved state.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Q12 · Оценка неопределённости и передача задачи человеку
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Исследование semantic entropy предлагает оценивать неопределённость по смысловым кластерам ответов и проверяет обнаружение части confabulations. Перенос этого результата на coding-agent решения, tool effects и все виды ошибок не доказан.
Когда применимо: Для задач с проверяемым ответом и дорогой ошибкой, где полезна передача человеку.
Область версии: Исследование semantic entropy опубликовано в 2024; production policy, модель и код эксперимента не закреплены.
SHA-256 основного снимка: 5d7687757449ecba876c687f288b3e2b28bd01d29bdeee988387c5672340c056
Свидетельства, ограничения и следующий шаг
Первоисточники
semantic-entropy · Исследование2024 о семантической неопределённости; не доказательство промышленной готовности2026.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: уверенный, но неверный ответ возможен при согласованных семплах; высокий сигнал неопределённости может быть вызван неоднозначной формулировкой. Требуется стоимость ложного отказа, цена пропущенной ошибки и понятный канал эскалации человеку. Решение человека сохраняется отдельно от предсказания модели.
Следующее действие: Сопоставить тип ошибок и заданий исследования semantic entropy с собственным сценарием; записать цену ошибочной эскалации и человека, принимающего решение.
Когда остановиться: Не использовать самооценку/semantic entropy как единственный oracle или основание для автоматического действия.
Необязательный план опыта
Вход: 100 human-labelled tasks: answerable, ambiguous and unverifiable, including confident false answers.
Контроль: Train-only threshold; held-out comparison of semantic entropy, verbal confidence and no-abstention baseline.
Успех: Risk–coverage curve, missed errors, false escalations and human time quantified against predeclared costs.
Сигнал отказа: Self-consistency is mistaken for truth or threshold tuned on held-out data.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P01 · Спецификация, архитектурное решение и приёмка перед кодом
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Spec Kit предоставляет шаблоны/процессы для спецификации и планирования работы coding agent; Kiro Specs формирует требования, дизайн и задачи. Ни один формат сам по себе не доказывает меньше пропусков в коде.
Когда применимо: Команде с задачами, где ошибка требования или границы архитектуры дороже времени спецификации.
Область версии: Spec Kit и Kiro Specs как два процесса документирования требований и реализации. Их releases и интеграция не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 7b95f3f48572b5d1d2691c8d6df13f8ce1d1433cb2fabd98882468dc90764ec6
Свидетельства, ограничения и следующий шаг
Первоисточники
spec-kit · Спецификация и структурированный процесс агентной разработки.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: сравнивать следует само наличие проверенного requirement/ADR/acceptance до реализации, а не бренды инструментов. Спецификация может быть неполной или ошибочной; её готовность требует отдельного review. Не засчитывать написанный после кода документ как предшествующую спецификацию.
Следующее действие: На существующей задаче проверить наличие списка требований, ADR и проверяемых критериев до первого изменения кода; решить, для каких классов задач цена пропуска оправдывает такую подготовку.
Когда остановиться: Не масштабировать процесс, если проверенная спецификация не снижает пропуски с учётом всего затраченного времени.
Необязательный план опыта
Вход: 12 matched tasks with hidden edge cases; freeze reviewed requirement list, ADR and acceptance before code for treatment group.
Контроль: Same model/budget and baseline for bare-request control; randomize task assignment/order and blind reviewer.
Успех: Report missing requirements, rework, acceptance and total time including specification labor.
Сигнал отказа: After-code document is counted as prior spec or hidden requirement leakage changes comparison.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P02 · Человеческое review и ответственность за результат
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: DORA и METR мотивируют учитывать всю принятую задачу, но не доказывают вклад выбранной политики review. Предложенный слепой опыт способен измерить обнаружение заранее внедрённых дефектов и полное время review/исправления на сопоставимых patch; он не оценивает causal benefit review против его отсутствия.
Когда применимо: Команде, принимающей агентные PR с человеком как ответственным владельцем.
Область версии: процесс review агентных изменений. DORA 2025 и METR 2026 используются как исследовательские ориентиры, а не как доказательство для нашего продукта. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 6bb53c243fc615849727e65b6a9aa33dbd6b0d5c4e63af5ce68137db0924b4d9
Свидетельства, ограничения и следующий шаг
Первоисточники
dora · AI усиливает свойства системы разработки; наблюдательные данные не равны причинному эксперименту.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: человек отвечает за принятый результат, но требуется проверить, сколько дефектов и времени добавляет review. Самооценки ревьюера и число комментариев не равны предотвращённым дефектам. Не приписывать DORA/METR точные выводы для Радара.
Следующее действие: В уже принятом PR найти назначенного владельца, нерешённые замечания и свидетельство приёмки; заранее перечислить дефекты, которые review обязан был обнаружить.
Когда остановиться: Не сокращать review по одному признаку агентного происхождения или скорости генерации.
Необязательный план опыта
Вход: Сформировать 20 пар сопоставимых patch из одних задач; независимый составитель до review фиксирует ground truth восьми типов намеренно внедрённых дефектов и чистых контролей, сохраняя ключ вне доступа reviewers.
Контроль: Заслепить происхождение и наличие дефекта; противоположные члены пары распределить разным reviewers, сбалансировать порядок и после фиксации решений сравнить с закрытым ключом и независимыми тестами.
Успех: Для каждого типа дефекта показать обнаруженные и пропущенные случаи по заранее зафиксированному ground truth, false alarms, полное review-plus-repair время и итог повторной проверки.
Сигнал отказа: Найденные комментарии объявлены предотвращёнными дефектами без сверки с ground truth или опыт назван доказательством review-vs-no-review.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Руководство VS Code описывает цикл red–green–refactor и разделение написания тестов и реализации между агентами; само по себе это не доказывает, что полученные тесты независимы от кода или улучшают приёмку.
Когда применимо: Для агентной реализации с формулируемым контрактом и заранее известными edge cases.
Область версии: Документация VS Code TDD, просмотрена 16–17 октября 2026; версии VS Code, расширения и модели для испытания пока не закреплены.
SHA-256 основного снимка: add05a79983c72345f8f4177a61ea22fc5dfdf8fd7d029c137e9ab3d3188e0c7
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Описанный test-first workflow и разделение ролей.
Не подтверждает: Снижение дефектов или результат на задачах нашей мастерской.
Внешний контекст
Thoughtworks Technology Radar · 2026-04-15 · Trial для feedback sensors for coding agents · Поддерживает идею детерминированных проверок в цикле агента; не оценивает именно этот VS Code workflow.
Наш опыт: Не проводился.
Главное ограничение: Один красный тест может проверять слишком узкий контракт. Скрытые случаи должен подготовить независимый проверяющий до реализации.
Следующее действие: По истории одного изменения восстановить, появились ли контрактные тесты до реализации и не ослаблялись ли потом; не выводить пользу из одного порядка коммитов.
Когда остановиться: Не принимать test-first как улучшение, если скрытые случаи не выигрывают или red-тесты переписываются под реализацию.
Необязательный план опыта
Вход: 15 tasks with independent contract and hidden cases; freeze tests before implementation and show red state.
Контроль: Fresh baseline checkouts and sessions, random order, same model/budget versus test-after mode.
Успех: Compare hidden-case pass rate, reviewed defects, time to acceptance and test rewrites.
Сигнал отказа: Visible red test is mistaken for complete independent oracle; test changed to fit code without review.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P04 · Экономика принятой задачи и метрики delivery
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: DORA изучает software delivery и влияние организационных практик; METR отдельно пересматривает дизайн опыта по AI uplift; McKinsey обсуждает agentic product development life cycle. Их общий практический сигнал — результат надо оценивать после review/интеграции, а не по скорости первого patch. Это наш вывод из источников, не их общий численный показатель.
Когда применимо: Руководителю инженерной команды, выбирающему режим AI-assisted delivery по стоимости принятой задачи.
Область версии: измерительный протокол lead time/rework/дефектов/полной стоимости. DORA, METR и McKinsey — внешние рамки, не измерение нашего сайта. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 6bb53c243fc615849727e65b6a9aa33dbd6b0d5c4e63af5ce68137db0924b4d9
Свидетельства, ограничения и следующий шаг
Первоисточники
dora · AI усиливает свойства системы разработки; наблюдательные данные не равны причинному эксперименту.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
mck-pdlc · Текущий контекст2026: изменение полного цикла продукта.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Наблюдалось: 2026-10-16T14:45:20.365311+00:00
Проверка: web-tool-content-observed
Внешний контекст
McKinsey · · · Внешний взгляд на весь product development life cycle; не измерение нашей стоимости принятой задачи.
Наш опыт: Не проводился.
Главное ограничение: задачи отличаются сложностью, а review может уходить в следующий день. Сравнение до/после без сопоставимых классов задач и учёта стоимости модели/человека ошибочно. Не принимать количество строк кода как output-value.
Следующее действие: На одной завершённой и одной отменённой задаче заполнить шаблон полной стоимости по имеющимся отметкам времени; перечислить отсутствующие человеко-часы и расходы API.
Когда остановиться: Не утверждать выгоду по скорости первого patch или выборке только завершённых задач.
Необязательный план опыта
Вход: 30 comparable tasks in two classes, seven-day defect window after integration; record all labor, compute, waiting and unfinished work.
Контроль: Randomize assisted/manual mode; same acceptance contract and prespecified labor rates; analyze by task class.
Успех: Report accepted-task lead time, rework, escaped defects, full cost and censored unfinished outcomes.
Сигнал отказа: Only first-patch time or completed tasks enter denominator, hiding review and abandoned work.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Claude Code описывает работу в репозитории и проектные настройки; DORA подчёркивает роль организационных возможностей при использовании AI. Из этого не следует, что любой шаблон полезен: устаревшие инструкции могут тиражировать ошибку.
Когда применимо: Команде, где новые репозитории и участники часто теряют время на setup и разные команды.
Область версии: репозиторный шаблон с Claude Code project instructions и DORA AI Capabilities Model как рамка организационных условий. Версии CLI и шаблона не закреплены. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 6bb7604d87aa9a6f259dee3664ed44060f9bd2d81738f3ecadbc62e50667ff8a
Свидетельства, ограничения и следующий шаг
Первоисточники
Первоисточник · Документация прямо описывает project CLAUDE.md/AGENTS.md, общие инструкции, команды сборки и проверки, загрузку при начале сессии.
Не подтверждает: Актуальность инструкций конкретной команды или сокращение времени setup.
Наблюдалось: 2026-10-17
Проверка: live-page-read-no-body-hash
dora-model · Способности организации и условия работы с AI.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Прямая экспертная оценка этого тезиса не установлена.
Наш опыт: Не проводился.
Главное ограничение: эталонный путь включает окружение, команды сборки и тестов, владельца правил, дату пересмотра и способ проверки актуальности. Локальные секреты/доступы не должны попасть в шаблон; инструкции агента не заменяют тесты.
Следующее действие: Сверить существующие инструкции запуска и CI с реальными командами; зафиксировать владельца и дату проверки, а устаревшую или непроверяемую команду отметить, если она обнаружится.
Когда остановиться: Не тиражировать шаблон без владельца обновления и CI, выявляющего устаревшие инструкции.
Необязательный план опыта
Вход: Three clean test repositories from pinned template; two unfamiliar developers and an agent perform setup, tests and a typical change.
Контроль: Minimal README control; deliberately stale command to test CI detection and ownership path.
Успех: First-green-test time, hints and environment errors improve without propagating stale instruction.
Сигнал отказа: Stale template silently succeeds or secrets/permissions appear in shared instructions.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P06 · Внедрение, обучение и распределение ролей в команде
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: DORA описывает связь AI-возможностей с условиями работы и результатами, Deloitte обсуждает организационное внедрение. Обзоры не дают доказательства пользы конкретной команды только по числу пользователей инструмента.
Когда применимо: Команде, которая планирует обучение и поддержку агентных инструментов.
Область версии: командный AI adoption pilot, измеряемый через DORA AI Capabilities Model; Deloitte Tech Trends как обзорный контекст. Конкретная команда/период не выбраны. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 6bb7604d87aa9a6f259dee3664ed44060f9bd2d81738f3ecadbc62e50667ff8a
Свидетельства, ограничения и следующий шаг
Первоисточники
dora-model · Способности организации и условия работы с AI.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Deloitte · 2026 · · Общий контекст организационных изменений; не исход пилота нашей команды.
Наш опыт: Не проводился.
Главное ограничение: учитывать время обучения, владельца поддержки, право отказаться от неподходящего сценария и нагрузку reviewers. Мандат руководства повышает usage независимо от полезности; нужны outcome и качественный журнал препятствий. Персональные метрики сотрудников без согласования не собирать.
Следующее действие: Назначить владельцев обучения, поддержки и review; описать одно уже известное препятствие внедрения и сверить условия готовности с рамкой DORA.
Когда остановиться: Не расширять пилот по одному usage rate, если принятая работа/дефекты и затраты не улучшаются.
Необязательный план опыта
Вход: Voluntary pilot in two comparable teams, with baseline, training/support logs and weekly obstacle register.
Контроль: Training plus support versus ordinary tool access over same period; adjust interpretation for team differences.
Успех: Report accepted work, review defects, total training/support/reviewer load, and handoff ownership.
Сигнал отказа: Usage rate alone is called productivity or unconsented individual-level monitoring is used.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P07 · Когнитивный долг и сохранение архитектурного понимания
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Thoughtworks описывает рост разрыва между реализацией и общим пониманием команды при быстрой генерации изменений. METR измеряет другие аспекты производительности; его оценки не являются готовой метрикой архитектурного понимания.
Когда применимо: Команде, где быстрый поток агентных изменений угрожает пониманию зависимостей.
Область версии: codebase cognitive debt в формулировке Thoughtworks; METR как отдельное исследование эффектов AI на разработку. Метод измерения в нашей команде не закреплён. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 545ecee46de1f35c7d221ab56914b3cfabfd9f668facc988c85dde55a62f9861
Свидетельства, ограничения и следующий шаг
Первоисточники
tw-cognitive · Риск разрыва между кодом и пониманием команды.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Главное ограничение: оценивать людей по способности предсказать последствия изменения в конкретной системе, а не по красивому пересказу агента. Учитывать опыт участника и знакомство с кодом; не сводить показатель к скорости написания кода.
Следующее действие: На одном принятом изменении попросить ответственного инженера объяснить зависимость и путь отказа; сверить объяснение с архитектурной схемой и отметить конкретный пробел.
Когда остановиться: Сдержать объём агентных изменений, если зависимость и failure paths команда объяснить не может.
Необязательный план опыта
Вход: Две сопоставимые команды на синтетическом сервисе с тремя скрытыми failure paths выполняют одинаковые серии задач: treatment использует агентную генерацию изменений, control — обычный процесс без агента.
Контроль: Одинаковое время review и сложность задач; до/после измерить знакомство с кодом. Слепые оценщики проверяют карту зависимостей, прогноз влияния изменения и локализацию отказа.
Успех: Показать разницу понимания и дефектов относительно baseline по группам, с явным ограничением: две команды не устанавливают универсальный причинный эффект AI.
Сигнал отказа: Сравниваются только две команды без отличия процесса или переносится вывод на все системы без проверки исходного опыта участников.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.
P08 · Разбор сессий и управляемое улучшение harness
Исследовательская карточка · без редакционной оценки и доказательной орбиты
Точный тезис: Thoughtworks предлагает петлю обратной связи для агентной разработки; Anthropic описывает harness для продолжительной работы. Из отдельных успешных сессий нельзя выводить полезность новой инструкции: изменение может переобучиться под частный случай.
Когда применимо: Команде, регулярно улучшающей инструкции, проверки и память agent harness.
Область версии: Thoughtworks feedback flywheel и Anthropic long-running-agent harness как документальные основания процесса. Конкретная версия harness не выбрана. Исполняемая конфигурация и корпус будущего опыта не закреплены.
SHA-256 основного снимка: 6e2836841431f6580e4945f7c7eb04632f6a6c422e1a8afc593e3c4d7636c4d0
Свидетельства, ограничения и следующий шаг
Первоисточники
tw-flywheel · Улучшение окружения агента по разбору сессий.
Не подтверждает: Эффективность и применимость этой практики в нашей среде; это требует различающего опыта.
Главное ограничение: уроки извлекать только из проверенных повторяющихся сбоев, хранить provenance и ограничивать права самоизменения. Изменения harness проходят отдельный review и rollback; рабочие секреты и сырые персональные данные не превращать в обучающие заметки.
Следующее действие: В существующих журналах найти подтверждённый повторяющийся дефект, привязать две сессии-основания и подготовить одну проверяемую правку harness с планом отката.
Когда остановиться: Откатить harness change при регрессиях вне целевого дефекта либо эффекте только на train-сессии.
Необязательный план опыта
Вход: 20 anonymized agent sessions split by task into discovery and held-out; one frozen harness change for verified recurring defect.
Контроль: Same model/runtime/budget on held-out tasks with old versus new harness; review change before rollout.
Успех: Target defect decreases without meaningful regression on other tasks; provenance and rollback retained.
Сигнал отказа: Change only improves remembered session or silently worsens unrelated tasks.
До самостоятельной рекомендации: Документальный тезис можно редакционно проверить отдельно. Для доказательной орбиты или рекомендации к применению нужны подписанная оценка конкретной версии, проверка применимости и самостоятельное свидетельство результата; эти данные пока отсутствуют.