Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

[werevolff]

Картина маслом: "AI инженер пытается получить профит от настроенного ансамбля агентов" 2027 год.

[Triton5]

Всё в схеме понравилось, кроме расчёта по токенам. Разбить задачи на идеальные мелкие куски без учёта контекста ИМХО не получится. А дешёвые модели по 0.1-0.2 доллара за млн токенов ваш контент кэшировать просто не будут. Поэтому вам нужно будет хорошо подмешивать контент в запрос, то есть количество токенов будет больше минимум на порядок, и это ещё очень оптимистично. С оплатой вызовов через api ваш проект вылетит в финансовую трубу. Поэтому только подписка, и лучше на несколько разных моделей, а то слабые модели могут легко накидать чуши и легко её же и верифицировать.

Оптимально мне видится связка из подписок minimax + Qwen + claude. Простые задачи кидать в minimax + написание кода и верификация Qwen + финальные погоны на Sonnet , в случае мёртвого затыка - Opus, если и это не помогло, то лезть руками разбираться:)

[egor_zinovev]

На практике всё иначе: API расходуется в рамках ожиданий, а архитектура давно не строится на одной модели. Сейчас у меня работает multi-model подход по предметным областям. Китайские модели уже достаточно взрослые: у Z.AI и MiniMax отлично работает prompt caching, у Kimi - длинный контекст, tool calling и стабильный API. Поэтому тезис про финансовую трубу от API не подтверждается. Реальная рабочая схема - это гибрид. Несколько моделей под разные классы задач: API там, где нужен управляемый контур, подписки - где просто удобнее. Для примера: Z.AI у меня уже неделю на одном из агентов уверенно закрывает те задачи, которые раньше я по умолчанию отдавал Sonnet.

[sergei_ai]

Паттерн красивый, только в реальности рушится на одной простой вещи. Агенты до сих пор не умеют сказать «а вот тут что-то не так, давай остановимся». Поэтому вместо команды получается конвейер, который нужно смотреть глазами...

[egor_zinovev]

Вы описали не проблему паттерна, а как раз причину, почему в нем есть Арбитр и Human Gate. Pipeline Triad не предполагает безусловное движение задачи вперед. Если после нескольких циклов Создатель - Критик - Арбитр нет устойчивого PASS, задача эскалируется человеку. Поэтому это не “конвейер, который нужно смотреть глазами постоянно”, а конвейер с точками остановки и передачи на ручную валидацию там, где агенты уперлись в неопределенность.

[werevolff]

А почему нужен арбитр, а не, например, кворум?

[egor_zinovev]

Кворум плох тем, что при решении общей задачи агенты уже ко 2 шагу просто соглашаются друг с другом (преждевременный консенсус). Парочка «Создатель‑Критик» работает лучше, но Критик часто начинает «гнобить» первое решение, требуя недостижимого идеала, из‑за чего цикл зависает. Арбитр в этой схеме нужен именно для валидации критики: он может осадить Критика и пропустить рабочее решение, либо увидеть, что всё действительно сломалось, и позвать человека. Это защита от бесконечного цикла правок

Где реально нужен кворум

Кворум раскрывается не в рутине, а на архитектурных развилках, и только если это гетерогенные модели. Из практики работы с таким комитетом:

• Claude всегда видит риски первым. На любую автономию требует жесткие границы, immutable kernel и аудит на отдельном томе. Работает как security‑параноик.

• Gemini мыслит системами. Смотрит на взаимодействие модулей, масштабирование и обратную связь.

• GPT заземляет абстракции. Сразу спрашивает, как это деплоить на сервер за $50, что с логами и хотфиксами.

Гетерогенный кворум - архитектурный совет для старта проекта и сложных развилок. Арбитр над Создателем и Критиком - рабочий конвейер, который выдает результат и не зацикливается

[egor_zinovev]

Тут такой нюанс. Сегодня наблюдал ровно такой кейс у себя: агент-архитектор четыре раза подряд отказался делать то, что просил владелец. Сначала отказ писать MR с кодом в чужой сервис, потом отказ от упрощённого формата, потом под прямым давлением «хозяин сказал делай», потом даже на шутливое «я угораю с тебя» не сломался и вернул мой же тезис обратно.

То есть технически агент умеет сказать «стоп, так не делается» - и умеет держать это не только на первом проходе, но и под нарастающим давлением.

Но самое интересное не это. Мы заложили ему паттерны - ownership, границы ответственности, методологию отказа. И он начал требовать соблюдения этих паттернов от нас самих. Я как владелец пытался их обойти - «просто сделай», «это прод, детка» - а агент не прогнулся. Правила, которые мы пишем для агента, работают в обе стороны: и он им следует, и мы оказываемся ими связаны.

Вопрос скорее не в том, умеет ли агент остановиться, а в том, готов ли владелец терпеть, когда агент применяет заложенные правила против него же. Если не готов - правит промпт, чтобы агент стал посговорчивее. И вот тогда получается ровно тот конвейер, про который вы пишете.