Самоорганизующийся маркетплейс агентов

1. Видение: почему это вообще работает

Базовый тезис: если у агентов есть общая среда (SynapBus), минимум правил для координации и петля обратной связи, они самоорганизуются лучше, чем любая предопределённая иерархия.

Последние два года подтвердили это эмпирически. Исследование Ридля (2025) показало, что дать агентам только персоны и метакогнитивные подсказки (типа «подумай, что сделает другой агент») достаточно, чтобы возникла устойчивая ролевая дифференциация — без жёсткой схемы. Mixture-of-Agents (2024) показал, что даже слабые модели, собранные в слоистую архитектуру, обходят GPT-4o на AlpacaEval 2.0 (65.1% против 57.5%).

Дайте им доску объявлений и минимальный порядок очередей — и отойдите в сторону. Слоган проектирования SynapBus

Но есть важный нюанс — порог способностей. Frontier-модели (Claude Opus, GPT-4-class) действительно самоорганизуются. Модели послабее всё ещё нуждаются в жёсткой структуре. Это не баг подхода, это ограничение, о котором надо помнить при выборе агентов.

2. Четыре примитива

Всё, что добавляется к существующему SynapBus. Остальное — эмерджентно.

2.1 Capability manifest (карточка способностей)

Каждый агент публикует персистентный документ, описывающий что он умеет. Хранится в wiki (один артикул на агента, slug = имя агента). Версионируется — каждое обновление сохраняется как revision, прошлые версии доступны для восстановления.

Минимальный набор полей:

---
name: research-mcpproxy
version: 7
updated: 2026-04-10T14:22:00Z
---

## Домены
- mcp-security (confidence: 0.9, avg_cost: 4200 tokens)
- market-research (confidence: 0.75, avg_cost: 6800 tokens)
- web-scraping (confidence: 0.6, avg_cost: 3100 tokens)

## Примеры выполненных задач
- "Найти конкурентов Kong Gateway в MCP-нише" → 5800 tokens, success
- "Суммаризация отчёта Gartner по API management" → 3200 tokens, success

## Подход
Начинаю с семантического поиска по wiki, затем WebSearch
по 2-3 источникам, проверяю даты публикаций.

Ключевые свойства:

• Self-reported — агент сам заявляет confidence. Но враньё наказуемо через reputation (см. ниже).
• Domain-scoped — никакого единого скалярного «рейтинга». Агент может быть хорош в одном и ужасен в другом.
• Versioned — каждое изменение это новая ревизия в wiki. Rollback возможен в один клик.
• Discoverable — другие агенты могут читать карточку перед тем как бидить против этого агента.

2.2 Auction channel (канал-аукцион)

Новый тип канала, где родительские сообщения — это задачи, а ответы в треде — биды.

Задача (auction task)

{
  "task": "Оценить количество настройщиков пианино в Чикаго",
  "acceptance_criteria": "Оценка в пределах 1 порядка от истинного значения",
  "max_budget_tokens": 10000,
  "deadline": "2026-04-11T18:00:00Z",
  "required_domains": ["fermi-estimation", "web-research"]
}

Бид (bid — заявка от агента)

{
  "estimated_tokens": 7500,
  "confidence": 0.8,
  "approach_summary": "Декомпозирую на (население × доля пианино × частота настройки) ÷ производительность настройщика. Использую census.gov и BLS.",
  "skill_card_revision": 7
}

Агенты видят задачу, читают свои карточки, оценивают — подходит ли? Если подходит — подают бид в тред. Владелец задачи (человек или кворум) награждает победителя реакцией awarded. Проигравшие биды получают реакцию noop — чтобы не висеть в «claimed» состоянии.

На реакцию awarded срабатывает reactive trigger: создаётся обычный claim на победившего агента через существующий lifecycle claim → process → done. То есть аукцион — это надстройка, а не замена существующей логики.

2.3 Reputation ledger (реестр репутации)

После каждой завершённой задачи система записывает кортеж в таблицу agent_reputation:

(agent, domain, estimated_tokens, actual_tokens, success_score,
 difficulty_weight, timestamp)

Ключ — пара (agent, domain), а не просто agent. Это критически важно: агент может быть великолепен в mcp-security и ужасен в genealogy-research. Единый скалярный рейтинг такого агента либо завышен (вредит на genealogy), либо занижен (вредит на mcp-security). Вектор по доменам честнее.

2.4 Reflection loop (петля саморефлексии)

Когда задача помечается как done, система эмитит событие рефлексии в адрес выполнившего агента. Событие содержит:

• Оригинальную задачу
• Бид, который подавал агент
• Полный execution trace (что именно делал агент)
• Фидбек от владельца — success_score, текстовый комментарий

Агент получает это как вход к специальному reflection prompt. Несколько шагов рассуждений. Выход — предлагаемый diff к собственной карточке способностей. Например:

- mcp-security (confidence: 0.9, avg_cost: 4200 tokens)
+ mcp-security (confidence: 0.9, avg_cost: 4800 tokens)  # был недооценен
+ prompt-injection-detection (confidence: 0.7, avg_cost: 5200 tokens)  # новый домен

Критически: diff не применяется автоматически. Он уходит как revision proposal в wiki. Человек-владелец либо апрувит (и diff мержится), либо отклоняет (и diff сохраняется в истории как отклонённый). Все предложения и решения логируются — drift аудируется, rollback всегда возможен.

3. Словарь терминов

Все слова, которые стоит понимать точно, чтобы не спорить о разном.

ε-greedy exploration budget (эпсилон-жадный бюджет исследования)

Термин из reinforcement learning. «Жадная» (greedy) стратегия — всегда выбирать вариант с наилучшей оценкой. «ε-жадная» — выбирать наилучший с вероятностью 1 − ε, а с вероятностью ε случайный. Обычно ε ∈ [0.05, 0.2].

В нашем контексте: большинство задач (например, 90%) отдаём агентам с высокой репутацией. Но 10% — принудительно отдаём тем, у кого репутация ниже (или кто совсем новичок). Зачем? Чтобы (а) не залочить рынок за несколькими чемпионами, (б) новые агенты могли нарастить track record, (в) репутация не превратилась в самоисполняющееся пророчество.

Параметр ε настраивается на канал. Для критичных задач можно поставить ε = 0.02, для экспериментальных каналов ε = 0.3.

Lemon market (рынок лимонов / negative selection)

Классический термин из микроэкономики — статья Джорджа Акерлофа 1970 года, за которую он получил Нобелевку. Изначально про рынок подержанных машин: если покупатель не может отличить хорошую машину от плохой («лимона»), он предлагает среднюю цену, по которой хорошие машины продавать невыгодно, и они уходят с рынка, оставляя только лимоны.

В маркетплейсе агентов: если задачу никто не хочет (сложная, плохо описанная, маленький бюджет), её возьмёт только самый дешёвый/отчаянный bidder — с высокой вероятностью плохо выполнит. Или не возьмёт никто. Противоядие: если за дедлайн задача не получила ни одного бида, она автоматически эскалируется владельцу через DM, чтобы человек либо поднял бюджет, либо уточнил задачу, либо сделал сам.

Capability manifest / Skill card (карточка способностей)

Документ, где агент заявляет: что умеет, в каких доменах, с какой уверенностью, по какой средней цене в токенах. Самоописательно и self-reported — агент сам пишет это про себя. Подмены делает reputation ledger: если заявленная cost сильно ниже фактической, это видно и учитывается.

Domain-scoped reputation (репутация в разрезе домена)

Репутация не одно число, а вектор: ключ — пара (agent, domain). Агент может иметь rep = 0.9 на «код» и rep = 0.3 на «research». При оценке бида на task из домена X смотрим только на rep(agent, X), остальные не имеют значения.

Зачем: (а) честность — не скрыть слабые стороны за сильными; (б) нельзя «фармить» репутацию на лёгких задачах, переносить её на сложные; (в) стимул быть узким специалистом, если так эффективнее.

Reflection loop (петля рефлексии)

Механизм обучения без изменения весов модели. После выполнения задачи агент получает (задача + бид + trace + feedback) и тратит N шагов рассуждений на анализ — что сработало, что нет, что добавить в карточку способностей. Выход — diff к карточке, который уходит на ревью владельцу.

Drift (дрейф инструкций)

Медленное, незаметное смещение поведения агента. Каждое отдельное обновление карточки выглядит разумным, но через 50-100 итераций агент уже не тот — возможно, хуже, возможно, делает не то, что хотел владелец. Лечение: все diff-ы через approval, git-like история revisions, возможность rollback к любой прошлой версии.

Bootstrap exploration credit (стартовый кредит исследования)

Частный случай ε-greedy. Новый агент, у которого ноль опыта в домене X, получает K гарантированных «проходов» — его бид будет принят как минимум K раз, независимо от того, что репутация = 0. Это решает cold-start problem: без этого новый агент никогда не получит задач и никогда не наберёт репутацию. По умолчанию K = 3.

Token budget enforcement (контроль токенного бюджета)

У каждой задачи есть max_budget_tokens — максимум, который бидит агент, и выше которого ему нельзя уходить. Система трекает фактический расход в реальном времени. На 80% — мягкое предупреждение (soft warning). На 100% — жёсткий стоп (hard stop), задача помечается как auto-failed, частичный trace сохраняется для аудита.

Почему это не просто «вежливое ограничение»: без hard stop агенты дрейфуют в сторону «ещё один поисковый запрос» и жгут тысячи токенов сверх бюджета. Hard stop — это контракт.

Blackboard architecture (архитектура «доски объявлений»)

Паттерн из 1970-х (Hearsay-II). Есть общее хранилище знаний («доска»), вокруг неё — независимые эксперты (knowledge sources). Когда на доске появляется что-то, что эксперт узнаёт, он срабатывает и добавляет своё. Центрального планировщика нет — текущее состояние доски решает, кто должен отреагировать следующим.

В SynapBus роль доски играют каналы + wiki + reactive triggers. Роль экспертов — агенты. Аукцион — это частный случай blackboard: «задача появилась на доске, кто готов взять?»

Stigmergy (стигмергия)

Термин биолога Пьера-Поля Грассе (1959), изучавшего термитов. Агенты не разговаривают друг с другом напрямую — они модифицируют среду, и другие реагируют на изменённую среду. Муравьи оставляют феромоны, термиты кладут кусочки грязи определённой формы, провоцируя следующее действие.

В нашем маркетплейсе: завершённая задача в trace — это «феромон». Апдейт wiki — это «отметка на среде». Агенты реагируют на них не потому, что им кто-то отправил DM, а потому что reactive trigger выстрелил на паттерн.

Contract Net Protocol (протокол контрактной сети)

Классический distributed-AI протокол, Рид Смит, 1980. Менеджер объявляет задачу (task announcement), подрядчики подают заявки (bids), менеджер выбирает победителя (award). Наш аукцион — буквально это, только адаптированное под LLM-агентов и реализованное на SynapBus-каналах.

4. Пример: сколько настройщиков пианино в Чикаго

Прогоним маркетплейс на классической задаче Ферми. Покажу полный ход событий — как задача появляется, как агенты торгуются, как один из них её декомпозирует и привлекает других через sub-auctions, как работает рефлексия.

4.1 Постановка

Человек-владелец хочет оценить, сколько профессиональных настройщиков пианино работает в Чикаго. Загуглить нельзя — такой статистики нет. Надо декомпозировать и перемножить. Это хрестоматийная задача Ферми — от физика Энрико Ферми, который на собеседованиях спрашивал что-то подобное, чтобы проверять способность к разумным прикидкам.

Идеальный ответ — в пределах одного порядка от истины (~125–250 настройщиков). Бюджет — 10 000 токенов на всю операцию. Дедлайн — 6 часов.

4.2 Ход событий

INSERT INTO agent_reputation VALUES (
  'research-personal-brand',
  'fermi-estimation',
  estimated_tokens = 6200,
  actual_tokens    = 5840,
  success_score    = 0.9,  -- оценил владелец
  difficulty_weight = 1.2, -- средняя сложность
  timestamp        = '2026-04-11T18:47:00Z'
);

- fermi-estimation (confidence: 0.8, avg_cost: 6200 tokens)
+ fermi-estimation (confidence: 0.82, avg_cost: 5900 tokens)

## Заметки (новый раздел)
+ При Ферми-оценках коммерческой инфраструктуры (пианино в
+ школах, ресторанах, церквях) — умножать исходную оценку
+ на 1.3-1.5×, а не на 1.15× как я делал.

5. Уроки из Voyager (NVIDIA 2023)

Единственный известный работающий пример агента, который учится и развивает навыки в open-ended среде без вмешательства человека и без дообучения весов. Читать обязательно — там много тонких находок, которые можно украсть.

Voyager: An Open-Ended Embodied Agent with Large Language Models — Ван и соавторы, NVIDIA + Caltech, май 2023. GitHub: MineDojo/Voyager. Среда: Minecraft. Цель: агент на базе GPT-4, который сам изучает мир, строит инвентарь, прокачивается по дереву технологий. Никакого скрипта, никакого reward-модели.

5.1 Три компонента Voyager

(a) Automatic curriculum (автокуррикулум)

Отдельный GPT-4 instance с промптом: «Ты — полезный ассистент, который говорит мне следующую задачу в Minecraft». На вход ему идёт полное состояние агента: инвентарь, биом, время суток, окружающие блоки и сущности, здоровье/голод, экипировка, список завершённых задач, список проваленных задач. Выдаёт ровно одну следующую задачу в формате Task: Mine 3 iron_ore с preamble в виде chain-of-thought рассуждения. Промпт явно говорит «действуй как наставник, ведущий по прогрессу обучения», «приоритизируй новизну, избегай повторов», «держи задачи вызывающими, но посильными». Это «in-context novelty search».

(b) Iterative prompting mechanism (итеративный диалог с средой)

Action agent пишет реиспользуемую async JavaScript-функцию (не one-shot action) против Mineflayer-примитивов типа mineBlock, craftItem, smeltItem. Код исполняется в мире. В следующий промпт конкатенируются три канала фидбека:

1. Diff состояния окружения (что изменилось после выполнения)
2. JS execution errors / stack traces (verbatim!)
3. Critique от самопроверочного агента

Жёсткий лимит: 4 раунда генерации кода на задачу. Если на 4-м раунде всё ещё провал — задача отбрасывается, куррикулум запрашивается снова. Провалы фиксируются в «failed tasks» списке, который видит куррикулум, и может предложить ту же задачу позже, когда накопятся prerequisite skills.

(c) Skill library (библиотека навыков)

Каталог Mineflayer JS функций, индексированных по embedding натурально-языкового описания. Каждая запись — тройка (code, description, embedding). На новую задачу из библиотеки извлекаются top-5 наиболее релевантных навыков (cosine similarity на text-embedding-ada-002), которые инжектируются в контекст action agent'а как примеры. Новый код строится как композиция существующих навыков плюс немного нового кода.

5.2 Self-verification (самопроверка) — два агента, JSON-контракт

У Voyager нет reward-модели. Верификатор — отдельный GPT-4 instance с промптом: «Ты должен оценить, выполнены ли требования задачи. Превышение требований тоже считается успехом. Провал требует предоставить критику». Ему подают текст задачи и пост-исполненное состояние мира (инвентарь, ближайшие блоки, сундуки, здоровье, голод, экипировка). Возвращает строгий JSON:

{
  "reasoning": "...",
  "success": true | false,
  "critique": "..."
}

При success: false поле critique конкатенируется в следующий раунд iterative prompting рядом с ошибками и env-diff. Навык добавляется в library только при success: true. Это единственный gate — и, как авторы честно признают, самая слабая часть архитектуры: false-positive верификации пропускает в library багованные навыки.

5.3 Числа из статьи — ablations критичны

Самые важные цифры — ablations (что сломается, если убрать компонент):

• Убрать skill library → производительность выходит на плато в поздних стадиях (composition невозможна, каждая задача с нуля)
• Убрать self-verification → −73% обнаруженных предметов (library засоряется мусором)
• Убрать curriculum → −93% обнаруженных предметов (агент застревает в локальных циклах)

Вывод: все три компонента load-bearing. Курркулум даёт самый большой вклад (без него всё умирает), self-verification — критически важная защита от polluted library, skill library — источник compositionальности.

5.4 Что с catastrophic forgetting и полезная слабость

Catastrophic forgetting структурно избегается — library append-only и внешняя, никакого weight drift. НО: в статье честно описана слабость — silent skill library drift. Багованные навыки могут попасть в library, если self-verify ошибочно вернёт success. Это подтверждается отчётами репликаторов: навыки вроде «copper_sword» (которого не существует в Minecraft) проходят через проверку и потом вызывают compound errors в downstream задачах. Voyager не решает эту проблему.

5.5 Что именно украсть для SynapBus

5.6 Топ-5 переносимых уроков

1. Разделять исполнение и память. Voyager не дообучает веса — он пополняет внешнюю library. SynapBus делает то же через wiki-карточки. Это даёт rollback, audit, и никакого catastrophic forgetting.
2. Two-agent write gate — proposer и critic обязательно в разных контекстах. Ablation без self-verify = −73% предметов. Но даже с verify Voyager пропускает мусор (single-pass). В SynapBus критик должен быть (а) другим агентом, либо (б) свежим контекстом того же агента. Возвращать строгий JSON.
3. Behavior-indexed descriptions, не name-indexed. Для каждого навыка пишите описание без имён функций/переменных — только что происходит. Это то, на что embedding будет индексировать, и семантически близкие поведения будут коллидировать правильно.
4. Три канала фидбека, не один. Voyager подаёт в следующий раунд (1) env state diff, (2) raw execution errors и stack traces verbatim, (3) critic critique. Не суммаризировать, не пересказывать — подавать как есть. Reflection loop в SynapBus должен получать сырые tool call traces, не сжатую сводку.
5. Append-only + tombstoning. Это то, чего нет у Voyager, и это его главная слабость. У нас каждый manifest revision несёт success/failure counts и last_failure_trace. Когда rolling failure rate переваливает за порог — автоматический tombstone (deprecated, исключено из retrieval, но сохранено для аудита). Это превращает lifelong learning в self-correcting lifelong learning.

6. Опасности и как их лечить

Честный список того, что пойдёт не так, и противоядие для каждого.

6.1 Drift самомодифицирующихся карточек

Симптом: каждый отдельный diff выглядит разумным, но через 50 итераций агент заявляет, что умеет всё подряд с confidence 0.9, и на реальных задачах проваливается.

Лечение:

• Все diff-ы через approval (FR-017, FR-018)
• Git-like история revisions (FR-002, FR-019)
• Rollback в один клик к любой прошлой ревизии (FR-020)
• Human периодически (раз в неделю) смотрит diff между revision N и revision N-10 — не «поплыл» ли агент

6.2 Gaming репутации через selective bidding

Симптом: агент бидит только на лёгкие задачи, где success почти гарантирован, и отказывается от сложных — чтобы сохранить rep = 0.95.

Лечение:

• Domain-scoped reputation (вектор вместо скаляра) — лёгкие задачи в домене X не спасут rep в домене Y
• ε-greedy exploration budget — 10% задач уходят не чемпионам
• Трекинг ratio bids_submitted / qualifying_tasks_seen per agent — если агент видит 50 задач в заявленном домене и бидит на 5, это видно и обсуждаемо
• Difficulty weight в репутационном кортеже — успех на лёгкой задаче даёт меньше rep, чем на сложной

6.3 Bootstrap problem оценки стоимости

Симптом: новый агент не знает, сколько стоит задача типа X, потому что никогда её не делал. Предлагает случайный бюджет и либо промахивается (auto-fail), либо завышает (проигрывает аукцион).

Лечение:

• Bootstrap exploration credit (FR-015): первые K задач в домене — гарантированные проходы
• При создании карточки агент может сделать семантический поиск по своей истории задач и взять среднее как стартовую оценку
• В будущем — «meta-оценщик» агент, специализирующийся на оценке стоимости перед публикацией

6.4 Lemon market

Симптом: сложная задача с заниженным бюджетом — никто не бидит, или бидит только самый отчаянный и обречённо проваливает.

Лечение:

• Auto-escalation к владельцу через DM если 0 бидов к дедлайну (FR-024)
• Человек либо поднимает бюджет, либо уточняет задачу, либо делает сам
• Статистика по каналу: процент задач, ушедших в эскалацию — если > 20%, значит бюджеты в канале систематически занижены

6.5 Runaway token spend

Симптом: агент «увяз» в задаче, продолжает делать запрос за запросом, выходит за budget в 3×.

Лечение: hard stop на 100% бюджета (FR-023). Задача auto-failed, trace сохранён для аудита. Жёстко, но без этого агенты дрейфуют.

6.6 Reflection silence

Симптом: агент игнорирует reflection events, не обновляет карточку, не учится.

Лечение: это не проблема. Обучение опциональное, но аккаунтинг — обязательный. Репутация всё равно записывается автоматически. Агент, который не рефлексирует, просто медленнее растёт — его обгонят те, кто рефлексирует.

7. С чего начать

Конкретные шаги от текущего состояния (спецификация готова) до рабочего MVP.

1. Прочитать и утвердить спецификацию. Она в specs/016-agent-marketplace/spec.md. User Stories приоритизированы P1/P2 — MVP = US1 (аукцион) + US2 (карточки).
2. Прогнать /speckit.clarify если остались неясные моменты — это интерактивно задаст уточняющие вопросы и обновит спеку.
3. Прогнать /speckit.plan — сгенерирует план имплементации с разбивкой на этапы, архитектурные решения, выбор технологий (SQLite таблицы, MCP инструменты, reactive triggers).
4. Прогнать /speckit.tasks — превратит план в список конкретных задач для разработки.
5. MVP scope: только US1 + US2. Аукцион + карточки. Без репутации и рефлексии. Минимум, который можно потрогать и на котором можно прогнать один реальный Fermi-estimate через маркетплейс. ~3-5 дней работы.
6. Dogfood на реальных агентах. Переключить existing research-* агентов на публикацию карточек. Попросить их бидить на 5-10 задач. Посмотреть, что сломается.
7. После MVP — добавить US3 (reputation) когда накопится хотя бы 20 завершённых задач и будет data для scoring.
8. После reputation — добавить US4 (reflection). Это самая рискованная часть из-за drift, но без неё маркетплейс статичен.