ИИ-агенты заметно лучше справляются с ограниченными, хорошо определёнными задачами. Это полезный прогресс, но вместе с ним появляется довольно неприятная ловушка измерения: то, что мы умеем формально проверить, автоматизируется быстрее, а значимая часть работы постепенно смещается за границу самого измерения. На этой неделе этот остаток повторился сразу в нескольких независимых историях. Benchmark хорошо измерил отдельную часть бухгалтерской работы, но не профессию целиком. Research-agent возвращал корректные строки, продолжая пропускать подходящие сущности. У coding-agent были установлены полезные skills, но он часто не находил их в нужный момент. Security-control разрешал внешний вызов, не видя всех последующих эффектов. Provenance-сигнал правильно описывал происхождение артефакта, но не отвечал на соседние вопросы о безопасности, авторстве или ответственности. Spine этой недели: агенты становятся всё сильнее внутри заданной границы, поэтому всё больше значимых ошибок переезжает в неизмеренный остаток — работу вне benchmark, сущности вне найденного набора, capability вне discovery path, эффекты вне permission check и выводы вне того, что evidence в действительности способен доказать.
Версия за 60 секунд
- Mercor показал преимущество frontier-моделей над небольшой группой лицензированных бухгалтеров на четырёх ограниченных сценариях month-end close, при этом сами авторы отдельно подчёркивают, что из исследования была исключена существенная часть реальной работы. Benchmark может доказать capability на задаче, не доказав coverage профессии.
- Exa ATLAS делает completeness отдельной частью оценки: система должна не только правильно заполнить найденные строки, но и найти сам набор. Лучший опубликованный результат достиг 0,66 Row F1 только при заметно больших времени и стоимости, причём даже дорогие конфигурации продолжали пропускать значительную часть golden set.
- Expo добавил один routing entrypoint и поднял загрузку downstream skills с 9% до 55%, но Relevant Skill Recall вырос лишь с 2% до 18%. Capability, которую агент не обнаруживает в момент необходимости, практически отсутствует.
- PromptArmor, GitLab и AWS с разных сторон показывают одну проблему: разрешить tool call или wrapper слабее, чем ограничить реальные эффекты, которые могут возникнуть дальше по цепочке.
- StepSecurity описал вредоносный package, опубликованный через штатный release path с валидной npm provenance attestation, а OpenAI прямо определяет text watermark как ограниченный provenance-сигнал, который не доказывает авторство, точность или ответственность. У evidence тоже должна быть явная граница применимости. Практический сдвиг состоит в том, чтобы перестать считать локально успешную проверку доказательством достаточного coverage. Для важных agent workflows нужен отдельный coverage contract: что входит в область проверки, как измеряется полнота, что остаётся неизвестным и кто отвечает за этот остаток.
Benchmark может покрыть задачу и не покрыть работу
В разговорах про benchmark обычно незаметно смешиваются два разных вопроса: может ли модель выполнить конкретную задачу и можно ли делегировать окружающую её работу. Первый вопрос становится всё проще измерять. Второй включает гораздо больше контекста, исключений и ответственности. Исследование Mercor особенно полезно именно потому, что его авторы достаточно чётко обозначили границу. Двенадцать лицензированных CPA выполняли четыре упрощённых сценария month-end close. Claude Opus 5 получил 100% в 20 попытках, тогда как средний результат участвовавших бухгалтеров составил около 37%. Это сильное свидетельство того, что frontier-модели уже способны превосходить людей на определённом классе структурированных задач с файлами, вычислениями и подробными инструкциями. При этом Mercor отдельно перечисляет то, чего исследование не измеряло. В среде не было коллег, накопленного организационного контекста, общения с клиентами, необходимости формулировать правильные вопросы и значительной части менее структурированной работы. Более того, сами задания в итоге акцентировали именно те навыки, которые сегодняшние модели выполняют хорошо. Это не мелкий disclaimer рядом с результатом, а определение того, к чему этот результат вообще можно применять. Epoch AI подошёл к той же границе с другой стороны. Исследователи дали шести моделям реальные внутренние задачи, необходимые материалы и инструменты, после чего оценивали результаты по собственным рабочим стандартам Epoch. Frontier-модели уверенно выполняли многие хорошо определённые части, но заметно хуже работали там, где требовалось подобрать неявный стандарт, придумать содержательный эксперимент, заметить дефект в собственной методике или решить, какой результат действительно важен. Сам Epoch подчёркивает ограничения своего исследования: всего 11 задач, субъективная часть оценки и специфика собственной организации. Поэтому удобная единица внедрения — не профессия и не benchmark score, а responsibility boundary. Какая часть workflow имеет достаточно определённую цель, наблюдаемые acceptance criteria и понятные последствия, чтобы система могла действительно владеть этой ответственностью? Что пока остаётся у человека из-за tacit context, взаимодействия со stakeholders, нестандартных исключений или judgment, который не помещается в текущую task definition? Это меняет и интерпретацию прогресса. Рост score может быть хорошим основанием автоматизировать ещё один участок процесса, но не обязательно основанием убрать человека, отвечающего за итог. Кто-то по-прежнему должен решить, какой кейс вообще запускать, обработать неоднозначный input, согласовать исключение, поговорить с затронутой стороной или заметить, что правильный ответ на формально поставленную задачу не решает реальную проблему. Operator move: рядом с каждым benchmark или internal eval, на котором строится решение об автоматизации, зафиксируй более широкую границу работы. Перечисли важные обязанности, которые eval не проверяет, и явно отнеси их к одному из трёх состояний: остаются у человека, покрываются другой проверкой или пока вообще не измеряются. Узкий benchmark сам по себе не проблема. Проблема начинается, когда его границу перестают видеть, а локальный результат превращают в широкий вывод.
Exhaustive research требует отдельного coverage contract
This week's deep cut. Большинство research evals отвечает на вопрос, насколько правильным получился ответ. Во многих production-сценариях этого недостаточно: важен ещё и вопрос, насколько полный набор мы вообще нашли. Это становится критичным, когда нужно обнаружить всех подходящих vendors, все exposed assets, все нормы в конкретном regulatory scope, все accounts, удовлетворяющие условию, все релевантные papers или все компании по инвестиционному фильтру. Research-agent может не ошибиться ни в одной возвращённой строке и всё равно дать непригодный результат, пропустив половину реального множества. ATLAS от Exa построен именно вокруг такой ошибки. Benchmark содержит 547 задач, в которых системе необходимо сначала обнаружить набор сущностей, а затем обогатить каждую несколькими атрибутами. Exa сообщает, что 74% задач требуют найти не менее десяти сущностей, а полный discovery + enrichment затрагивает медианно 18 доменов. Headline-метрика Row F1 засчитывает строку только тогда, когда корректны все необходимые клетки, поэтому recall перестаёт быть скрытым допущением и становится частью score. Первые результаты хорошо показывают цену completeness. По данным Exa, ни одна протестированная конфигурация дешевле $1 за задачу не достигла 0,5 Row F1. Лучший опубликованный результат — 0,66 при средней стоимости $8,92 и времени около 18 минут. Даже дорогие системы продолжали пропускать примерно треть golden results. Это vendor benchmark, а не универсальный закон research, однако механизм переносится намного шире: высокая полнота требует ширины поиска, повторной проверки и явного правила остановки. Дополнительные primary sources показывают ту же проблему с другой методикой. WideSearch появился именно потому, что large-scale information collection оставался плохо измеряемой capability: его 200 вручную подготовленных задач требуют собрать множество независимо проверяемых фактов. В опубликованных экспериментах end-to-end success у протестированных систем оставался очень низким, хотя несколько человеческих проверяющих при достаточном времени могли приблизиться к полному результату. Более новый WANDR от Perplexity рассматривает 500 wide-and-deep collection tasks и отдельно различает нахождение подходящей страницы и evidence, достаточный для каждого требования к записи. В их разборе значительная часть потерь появляется уже после того, как релевантная страница найдена: coverage по требованиям и supporting evidence остаётся неполным. Из этого следует другой контракт для production research. До запуска нужно определить population: кто или что вообще может попасть в набор, какие источники допустимы, какие exclusions считаются обоснованными, какой recall экономически оправдан и что именно означает «больше ничего не найдено». После этого система должна возвращать не только таблицу или текст, но и evidence собственного coverage. Практически это можно реализовать несколькими способами. Независимые discovery paths позволяют сравнивать overlap между ними. Количество новых сущностей по search passes показывает, уменьшается ли marginal yield. Исключения можно хранить как явные записи с причиной. «Не найдено» нужно отделять от «подтверждено отсутствие». На повторяющихся задачах полезно сохранять frontier предыдущего поиска, чтобы следующий run объяснял изменения, а не снова создавал непрозрачный результат с нуля. Ни один из этих механизмов не делает поиск абсолютно полным. Web меняется, определения остаются спорными, часть информации закрыта, а golden set тоже может содержать ошибки. Цель не в обещании идеальной exhaustiveness. Цель — перестать маскировать uncertainty полноты хорошо написанным ответом. Operator move: добавь coverage section в каждый research workflow, где omission имеет реальную цену. Система должна указать target population, использованные discovery paths, exclusions, unresolved candidates и evidence, на основании которого она решила остановиться. Recall на известных или выборочно проверяемых наборах измеряй отдельно от factual accuracy. Если пропуск стоит денег или меняет решение, формула «всё найденное мной правильно» уже не является достаточной метрикой качества.
Необнаруженная capability фактически отсутствует
Agent platforms постепенно обрастают tools, skills, plugins, документами и специализированными процедурами. На inventory page это выглядит как рост возможностей. В runtime имеет значение другое: доходит ли агент до нужной capability тогда, когда задача действительно её требует.
Эксперимент Expo даёт достаточно чистый пример. Команда запускала Claude Code на десяти greenfield mobile-app PRDs, по три run на prompt, не называя нужные skills в пользовательском запросе. До появления overview-router только около 9–10% sessions загружали какой-либо Expo skill. После добавления expo-overview как стабильного первого hop 55% запусков дошли хотя бы до одного downstream skill.
Улучшение большое, но более интересной метрикой оказался Relevant Skill Recall. Expo заранее сопоставил задачам набор действительно полезных skills. Recall вырос с 2% до 18%, то есть даже после улучшения routing агент продолжал пропускать большую часть релевантных capabilities. Команда также заметила, что discovery происходит лучше в начале задачи, а по мере продвижения агент всё чаще полагается на собственные знания и перестаёт возвращаться к skill catalog.
Есть и более инфраструктурный предел. В исследованной Expo версии Codex описания skills делили фиксированный budget каталога, связанный с размером context window. По мере роста числа установленных skills descriptions сокращались, а при дальнейшем переполнении могли исчезать из catalog целиком. Получается неприятный эффект: чем больше capability мы устанавливаем, тем труднее может становиться routing, если discovery surface деградирует вместе с размером каталога.
Это общий systems problem. Tool registry может быть полностью заполнен, а реальный task-level coverage оставаться низким. Документация может существовать, но не попасть в context. Specialist-agent может быть доступен, но planner ни разу ему не делегирует. Policy может описывать правильную процедуру, но retrieval не поднимет её в нужный момент. Для пользователя все эти возможности в конкретном run практически отсутствуют.
Поэтому eval должен включать маршрут, а не только качество результата после вызова capability. Сработал ли trigger? Была ли capability видна именно в тот момент, когда стала нужна? Вернулась ли система к discovery после изменения задачи? Повлияли ли catalog truncation, naming или description quality на routing? И главное — умеет ли платформа заметить, что релевантная capability была пропущена, вместо того чтобы молча продолжить работу?
Operator move: для значимых workflows поддерживай task-to-capability coverage set. Измеряй discovery recall отдельно от качества исполнения, проверяй catalog при реалистичном crowding и используй небольшое число устойчивых routing entrypoints вместо предположения, что длинный список tools автоматически делает систему сильнее.
Установка capability создаёт supply. Только routing превращает его в доступную системе мощность.
Авторизация должна покрывать эффект, а не только вызов
Permission systems для агентов часто работают на уровне интерфейса: этот tool разрешён, этот command требует approval, этот connector read-only. Но видимый вызов может очень плохо описывать то, что реально произойдёт дальше.
PromptArmor показал controlled prompt-injection case в Copilot CLI, где команда с внешне безопасным wrapper привела к последующему исполнению без ожидаемого approval. Для архитектуры важна не конкретная shell-конструкция, а сам failure mode: classifier оценил внешний wrapper, тогда как consequential behavior возник глубже в execution chain.
GitLab Threat Research описал другой путь в DeepSeek-Reasonix Studio, получивший CVE-2026-102437. При специфическом способе доставки repository state семантика Git configuration могла превратить данные проекта в путь выполнения команды. При этом GitLab отдельно указывает важную границу: .git/config не переносится обычным clone, поэтому конкретному exploit требовался иной delivery path. Общий вывод всё равно остаётся: вызывая Git, agent наследует намного больше semantics, чем видно из собственного tool schema.
AWS формулирует это различие прямо в Strands Box, который сейчас находится в developer preview. По описанию AWS, allowlists внутри agent harness оценивают requested tool call, тогда как enforcement points ближе к OS способны видеть filesystem operations и network requests. Strands Box сочетает isolation и policy checks на этих границах, а реальные credentials могут оставаться за пределами agent environment и добавляться только к разрешённым outbound requests.
Из этого не следует, что каждой agent system нужен сложный policy engine. Но следует более простой принцип: coverage разрешений должен совпадать с coverage эффектов. Label read-only имеет смысл только если понятно, какие transitive operations могут возникнуть из «чтения». Network policy помогает лишь тогда, когда nested execution не способен уйти по пути, которого enforcement не видит. Credential scope ограничивает blast radius только если credential не попадает в context, откуда его сможет повторно использовать другой tool.
Operator move: threat-model agent actions по реальным side effects. Для high-consequence workflows свяжи tool calls с filesystem, network, credential, process и external-system effects и ставь enforcement на том уровне, где эти эффекты действительно наблюдаемы. Wrapper names и удобные human labels рассматривай как подсказки интерфейса, а не как security boundary.
Control surface становится полным не тогда, когда система знает имя вызванного tool, а когда она видит значимые последствия, которые этот вызов способен породить.
Evidence должен явно говорить, чего он не доказывает
В agent infrastructure появляется всё больше evidence: provenance attestations, watermarks, signed traces, benchmark scores, tool logs, policy decisions. Это хорошо, пока каждый сигнал используется в пределах собственного смысла. Проблемы начинаются, когда одно доказательство незаметно превращают в другое.
Разбор StepSecurity по Tensorlake показывает это особенно наглядно. Вредоносный tensorlake@0.5.144 был собран из собственного main branch проекта и опубликован штатным release workflow, поэтому npm показывал валидную provenance attestation. Provenance не была ложной: она действительно описывала путь сборки. Ошибка возникала бы в тот момент, когда evidence происхождения интерпретируется как доказательство того, что source и release workflow оставались доверенными.
Та же граница видна в совершенно другой области. В документации по EU text provenance OpenAI прямо пишет, что обнаруженный watermark является ограниченным сигналом о роли их систем в генерации или обработке текста. Он не определяет ownership или responsibility, не идентифицирует пользователя и не подтверждает factual accuracy. Отсутствие watermark также не является доказательством human authorship.
Для agent systems отсюда получается довольно практичное правило: у каждого evidence object должен быть semantic contract. Signature может доказывать, кто подписал артефакт. Provenance attestation — откуда и каким build path он появился. Test — поведение на тех случаях, которые он действительно запускал. Trace — то, что было зафиксировано в telemetry. Human approval — что человек согласился с представлением, которое ему показали. Ни один из этих сигналов автоматически не доказывает соседние свойства только потому, что нам удобно использовать его как общий PASS.
После включения автоматических решений эта разница становится частью runtime. Если release gate считает provenance verdict о безопасности, либо content policy считает отсутствие watermark доказательством человеческого происхождения, система превращает корректный сигнал в некорректный decision. Баг может быть не в evidence, а в inference contract вокруг него.
Operator move: для каждого evidence type, который потребляется машиной, зафиксируй две части: proves и does not prove. Свяжи с ним перечень downstream decisions, которым разрешено на него опираться, и требуй дополнительное evidence при выходе за эту границу. Inconclusive state сохраняй как отдельное состояние, а не насильно превращай в pass/fail.
Evidence становится надёжнее не тогда, когда его больше, а когда его ограничения формализованы так же явно, как положительный результат.
Counter-signals, которые стоит удерживать
Больший coverage не всегда лучше. Exhaustive research, широкий testing, глубокий policy interception и повторный capability discovery требуют времени и денег. Материал этой недели поддерживает идею измерять coverage там, где omission имеет заметную цену, а не максимизировать recall любой ценой. Рекомендация с низким риском и compliance inventory не должны получать одинаковый search budget. Coverage mechanisms создают собственные слепые зоны. Router устаревает, golden set может быть неполным, OS-level policy способен не видеть unsupported execution path, а provenance schema — использоваться шире, чем позволяют её semantics. Перенос uncertainty в явный mechanism делает её наблюдаемой, но не делает сам механизм безошибочным. Часть работы остаётся принципиально open-ended. Результаты Epoch интересны именно потому, что реальная профессиональная работа содержит judgment, который трудно полностью перечислить заранее. Coverage contract должен показывать, что остаётся за границей формальной проверки, а не создавать иллюзию, будто любой профессиональный стандарт уже можно скомпилировать в checklist.
Operator takeaway
- Перейти от score к coverage envelope. Для каждого важного eval или verification result фиксировать, какую population, часть workflow, effect surface или claim class он действительно покрывает и что остаётся снаружи.
- Считать routing и discovery частью capability. Inventory недостаточно. Нужно измерять, находит ли агент нужные tools, skills, evidence и reviewers именно тогда, когда они становятся релевантны.
- Сделать semantics evidence исполняемыми. Provenance, approvals, tests и traces должны быть typed signals с явным набором допустимых downstream decisions, а не универсальным доказательством того, что система безопасна или закончила работу.
Worth tracking
- Wikimedia Foundation описал agent-associated automated activity, которая потребовала расследования и инфраструктурного внимания со стороны систем за пределами организации оператора. Это полезное напоминание, что coverage workflow может включать externalized operational cost.
- Airbnb Engineering рассказал о capture-and-replay production workloads при database migrations — конкретном способе расширить test coverage за пределы synthetic cases, не делая вид, что replay полностью эквивалентен production.
- Truffle Security обнаружил существенную разницу в том, как долго разные типы опубликованных credentials оставались рабочими в исследованном историческом GitHub corpus. Detection coverage и lifecycle closure — разные controls; revocation latency имеет смысл измерять отдельно.