ingest: agent-judge-layer-production-control
This commit is contained in:
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "AI Agent Judge Layer — контроль агентов в продакшне"
|
||||
slug: agent-judge-layer-production-control
|
||||
source: "https://natesnewsletter.substack.com/p/agent-judge-layer-production-control"
|
||||
date_published: 2026-05-11
|
||||
date_processed: 2026-05-18
|
||||
type: video
|
||||
author: "Nate Jones"
|
||||
themes:
|
||||
- "[[Agentic Workflow]]"
|
||||
- "[[Implementation Layer]]"
|
||||
- "[[Audit Trails]]"
|
||||
- "[[Evals]]"
|
||||
frameworks:
|
||||
- "[[Judge Layer]]"
|
||||
- "[[Action Classification]]"
|
||||
- "[[Proposal Pattern]]"
|
||||
terminology:
|
||||
- "[[Agentic Workflow]]"
|
||||
- "[[Implementation Layer]]"
|
||||
- "[[Audit Trails]]"
|
||||
- "[[Evals]]"
|
||||
- "[[Systems of Record]]"
|
||||
- "[[Business Object]]"
|
||||
- "[[Workflow Completion]]"
|
||||
- "[[Memory Governance]]"
|
||||
---
|
||||
|
||||
## Суть
|
||||
|
||||
Серьёзные сбои агентов в продакшне не выглядят как взлом. Они выглядят как письмо, отправленное потому что тред подразумевал одобрение; запись клиента, обновлённая потому что старое значение казалось устаревшим; pull request, открытый потому что тесты прошли. Ни одно из этих действий не требует, чтобы модель вела себя плохо — это и делает риск невидимым.
|
||||
|
||||
> "The next serious agent failure won't look like a jailbreak. It'll look like an email sent because the thread seemed to imply approval, a customer record updated because the old value looked stale, a pull request opened because the tests passed and the change looked done."
|
||||
> *Следующий серьёзный сбой агента не будет выглядеть как jailbreak. Он будет выглядеть как письмо, отправленное потому что тред, казалось, подразумевал одобрение; запись клиента, обновлённая потому что старое значение казалось устаревшим; pull request, открытый потому что тесты прошли.*
|
||||
|
||||
---
|
||||
|
||||
## Ключевая идея: Suggestion Space vs Consequence Space
|
||||
|
||||
| Режим | EN | Описание |
|
||||
|-------|-----|---------|
|
||||
| Пространство предложений | Suggestion Space | Чат-демо: модель набрасывает, суммирует, предлагает — если ошиблась, пользователь отвергает. Цена ошибки локальна. |
|
||||
| Пространство последствий | Consequence Space | Продакшн-агент: уведомляет, раскрывает данные, меняет записи в [[Systems of Record]], тратит деньги. Цена ошибки системна. |
|
||||
|
||||
---
|
||||
|
||||
## Почему стандартные решения не работают
|
||||
|
||||
| Решение | Почему не работает |
|
||||
|---------|--------------------|
|
||||
| Лучший промпт | Один промпт не может одновременно *выполнять задачу* и *полицировать себя* — структурное противоречие, не проблема формулировки |
|
||||
| Модальные окна одобрения (approval modals) | Пользователи кликают по привычке или перестают использовать систему; UX-налог убивает ценность |
|
||||
|
||||
---
|
||||
|
||||
## Архитектура: [[Judge Layer]]
|
||||
|
||||
Отдельный компонент, обёрнутый вокруг актора (actor), который решает — должно ли каждое предложенное действие пройти к исполнению.
|
||||
|
||||
```
|
||||
[Задача] → [Агент-актор] → [Предложенное действие] → [Judge] → [Выполнить / Заблокировать]
|
||||
```
|
||||
|
||||
Ключевое разграничение, которое часто путают:
|
||||
|
||||
| Понятие | EN | Место в стеке |
|
||||
|---------|----|--------------|
|
||||
| Оркестрация | Orchestration | Координация агентов между собой |
|
||||
| Суждение | Judgment | Оценка допустимости конкретного действия |
|
||||
|
||||
Это разные задачи — они не должны жить в одном компоненте.
|
||||
|
||||
---
|
||||
|
||||
## Builder Toolkit (набор строителя)
|
||||
|
||||
| Компонент | EN | Описание |
|
||||
|-----------|----|----------|
|
||||
| [[Action Classification]] | Action Classification | Классификация действий по уровню риска до выполнения |
|
||||
| [[Proposal Pattern]] | Proposals | Агент предлагает → судья оценивает перед исполнением |
|
||||
| Специализированные судьи | Specialist Judges | Разные judge-инстанции для разных типов действий |
|
||||
| [[Evals]] для судьи | Judge Eval | Тестирование самого judge layer как самостоятельной системы |
|
||||
| [[Memory Governance]] | Memory Governance | Управление тем, что агент помнит и пишет между сессиями; провенанс (provenance) решений |
|
||||
|
||||
Практический гайд из материала: 5 промптов от «my agent acts» до рабочего judge на самой рискованной границе + спецификация для подключения к durable memory и structured write-back.
|
||||
|
||||
---
|
||||
|
||||
## Примеры из практики
|
||||
|
||||
- **Lindy** — многоканальный агент-продукт; столкнулся с failure mode, характерным для каждой продакшн-системы → архитектурный fix через judge layer
|
||||
- **JP Morgan** — упомянут как пример применения паттерна (детали за пейволлом)
|
||||
- **OpenAI** — OpenBrain Judge Extender guide как референсная имплементация
|
||||
|
||||
---
|
||||
|
||||
## Что использовать для нашего портфеля
|
||||
|
||||
Мы строим [[Implementation Layer]] поверх [[Frontier Labs]] для клиентов — это Consequence Space по определению, не Suggestion Space. Judge Layer прямо применим в четырёх точках:
|
||||
|
||||
1. **Мутации [[Business Object]]** — любой агент, меняющий данные в [[Systems of Record]] клиента (CRM, ERP, финансы), нуждается в judge layer перед записью. Незаметные, трудно обратимые ошибки — именно тот риск, который блокирует adoption в Enterprise.
|
||||
|
||||
2. **Гейты [[Workflow Completion]]** — перед финальным шагом любого [[Agentic Workflow]] (отправить письмо, закрыть тикет, инициировать платёж) нужна точка суждения, а не просто техническая проверка корректности.
|
||||
|
||||
3. **[[Audit Trails]] как побочный продукт** — judge layer естественно генерирует трейлы: что было предложено, что заблокировано, почему. Продаётся как compliance-функция Enterprise-клиентам; снижает барьер согласования с юридическим и ИБ.
|
||||
|
||||
4. **PE-канал ([[Forward Deployed Engineer]])** — внедрение judge layer как первого артефакта в engagement снижает воспринимаемый риск клиента и создаёт точку зависимости от нашего [[Harness]] и [[Implementation Fabric]].
|
||||
|
||||
**Открытый вопрос**: Стоит ли выделить judge layer в отдельный продаваемый модуль [[Implementation Fabric]] или встраивать в каждый workflow неявно — и что из этого лучше защищает [[Moat]]?
|
||||
|
||||
---
|
||||
|
||||
## Терминология
|
||||
|
||||
| RU | EN | Wikilink |
|
||||
|----|----|---------|
|
||||
| Слой судьи | Judge Layer | [[Judge Layer]] |
|
||||
| Пространство предложений | Suggestion Space | — |
|
||||
| Пространство последствий | Consequence Space | — |
|
||||
| Классификация действий | Action Classification | [[Action Classification]] |
|
||||
| Паттерн предложения | Proposal Pattern | [[Proposal Pattern]] |
|
||||
| Управление памятью агента | Memory Governance | [[Memory Governance]] |
|
||||
| Специализированный судья | Specialist Judge | — |
|
||||
| Актор (агент-исполнитель) | Actor | — |
|
||||
| Провенанс | Provenance | — |
|
||||
| Оркестрация | Orchestration | — |
|
||||
|
||||
---
|
||||
|
||||
*Источник закрыт (paid). Данные извлечены из публичного preview и page metadata.*
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user