Agent Roundtable: построение локальной многопрофильной системы экспертного круглого стола

Недавно я собрал мультиагентный чат-проект: agent_roundtable.

Идея у него была очень прямолинейная: я задаю тему, система приглашает несколько «экспертных» Agent с разными направлениями, ведущий ведет уточняющие вопросы, связывает реплики и делает итог, а затем вся дискуссия сохраняется как отчет в формате Markdown.

Это не просто чат-бот, а локальный агентный workflow, где можно настраивать роли, выбирать модели, подключать локальную базу знаний и превращать процесс обсуждения в документ.

Я предпочитаю мыслить об этом как о «инструменте экспертного круглого стола»: не заставлять одну модель отвечать на всё сразу, а разложить вопрос на разные перспективы и дать им обсудить его вместе.

1. Почему я делал этот проект

Я давно задавался вопросом: если мне нужен действительно полезный AI Agent, как он должен быть устроен?

С одним Agent работать легко. Даете prompt — он отвечает, вызывает инструменты, делает резюме. Этого хватает для многих задач. Но как только вопрос усложняется, у монолитного подхода сразу видно ограничения:

• Он легко смешивает несколько перспектив в один ответ.
• Ему сложно последовательно и стабильно держать несколько профессиональных ролей.
• Ответ часто выглядит как единый эссе-реферат, а не как реальная дискуссия.
• Трудно отделить «макроэкономический взгляд» от «инвестиционного», «AI‑технологического», «философского» и «историко-стратегического».

Поэтому я решил сделать мультиагентный круглый стол.

Одна тема может обсуждаться разными экспертами. Макроэкономический эксперт смотрит на институты и циклы, инвестиционный — на денежные потоки и риски, AI-эксперт — на технологическую динамику, философский — на смысл и ценности, историко-стратегический — на долгие структуры и траектории.

Тогда итогом уже не будет «ответ одной модели», а структурированная дискуссия.

2. Что сейчас умеет проект

agent_roundtable сейчас — локальный Python-проект, который можно запускать через CLI и локальный веб‑интерфейс на Streamlit.

Сейчас он умеет:

• Запускать мультиагентный круглый стол через командную строку или локальный UI на Streamlit.
• Настраивать для каждого Agent отдельный provider, модель и имя переменной API key в окружении.
• Хранить API key только в .env, не писать их в JSON, YAML, логи или отчеты.
• Основной эксперт может читать свои локальные длинные материалы и через RAG извлекать релевантный контент.
• Автоматически сохранять результаты в logs/ в виде Markdown-отчетов.
• В отчете отмечать, какой provider и model использовался для каждой реплики.
• Работать без ключей через --mock, чтобы прогнать весь процесс end-to-end.

В репозитории сейчас есть два встроенных круга:

Отдельно отмечу: persona_inspired — это только «вдохновение стилем», не имитация людей и не выражение их личных взглядов. Это попытка зафиксировать характер рассуждений и использовать его для структурирования ответов.

3. Мое понимание Agent

Слово Agent сейчас очень модное, но если его раздувать абстракциями, оно теряет смысл.

Я считаю: Agent — это не «модель, которая умеет красиво разговаривать», а системная единица, которая выполняет задачу относительно цели. Обычно он включает:

• роль или задачу;
• набор инструкций и ограничений в prompt;
• набор вызываемых инструментов;
• обновляемое состояние;
• при необходимости память, базу знаний и управление workflow.

Обычный чат — это «задал вопрос — получил ответ». Agent ближе к «есть задача, нужно самому определить следующий шаг».

С подключением Tool Use Agent может вызывать поиск, работу с файлами, базами данных, исполнение кода. С подключением RAG — сперва собрать материалы, затем отвечать. С workflow — разные Agent начинают координироваться по шагам.

Именно поэтому я и сделал agent_roundtable: мне неинтересно оставаться на уровне prompt-уровня. Я хочу программно связать роли, знания, вызовы моделей и процесс выполнения. Если хотите системный старт с основами ReAct, памяти и RAG, рекомендую «Hello-Agents: бесплатный курс по созданию AI Agent с нуля».

4. Почему именно multi-Agent, а не супер-модель-агент

Супер‑agent, конечно, тоже способен отвечать на сложные вопросы. Но мне ближе мультиагентный формат.

Причина простая: сложные решения в реальности редко делаются одним голосом.

Если говорить, например, о долгосрочном влиянии AI на инвестиции и рынок труда, это, по сути, можно разложить минимум на такие углы:

Одна модель может затронуть все эти точки, но ей сложнее поддержать настоящее расхождение позиций.

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

Это стабильнее и масштабируемее, чем единый очень длинный prompt.

5. Роль RAG в этом проекте

RAG можно объяснить как «открытая экзаменация с доступом к источникам».

Обычный LLM отвечает, опираясь на знания, вложенные в параметры модели. RAG же сначала достает релевантные материалы из внешней базы знаний, и уже потом модель использует их в качестве опоры для ответа.

В agent_roundtable я храню длинные локальные материалы в knowledge/. Для каждого эксперта может быть своя папка, например:

knowledge/macro_economist/
knowledge/investing_master/
knowledge/ai_researcher/
knowledge/philosophy_expert/
knowledge/history_strategist/

Дальше индекс строится командой:

python -m rag.ingest --expert-name macro_economist --embedding-provider keyword

Сейчас приоритет отдан keyword-поиску, потому что он не требует дополнительного API key и удобен для локального тестирования и знакомства с системой. Если нужна более глубокая семантическая выдача, можно добавить embedding‑модель.

Это было для меня принципиально важно.

Мне не хочется, чтобы экспертный Agent жил только на «собственных впечатлениях» модели. Я хочу, чтобы он опирался на заранее подготовленные книги, статьи и длинные тексты, формируя собственный фон знаний.

Тогда Agent перестает быть просто набором персонажа в prompt и начинает выглядеть как зачаток экспертной системы с локальной базой знаний.

6. Структура проекта

Примерная структура такая:

agent_roundtable/
├── main.py
├── ui/
│   └── app.py
├── src/
│   ├── graph.py
│   ├── agents.py
│   ├── llm.py
│   ├── model_catalog.py
│   ├── agent_llm_config.py
│   ├── loader.py
│   ├── logger.py
│   ├── prompts.py
│   └── state.py
├── agents/
│   ├── domain_experts/
│   └── persona_inspired/
├── councils/
├── configs/
│   └── agent_llms.json
├── knowledge/
├── rag/
├── vector_db/chroma/
├── logs/
├── tests/
├── requirements.txt
└── .env.example

Назначение ключевых директорий:

Мне нравится такой уровень разделения: роли отдельно, модели отдельно, база знаний отдельно, логи отдельно. Нельзя смешивать все в одном месте.

7. Как я проектировал карточки ролей Agent

В проекте у каждого Agent есть собственная YAML-карточка.

Обычно она включает:

• имя;
• роль;
• мировоззренческую рамку;
• стиль речи;
• сильные стороны;
• слабые стороны;
• привязку к RAG-директорий;
• тип Agent.

Например, карточка энергетического эксперта может выглядеть так:

name: "Energy Expert"
role: "Эксперт по энергетике и промышленной политике"
worldview: "Анализ вопросов через призму соотношения спроса и предложения энергии, инфраструктуры, геополитики и технологических замен"
speaking_style: "Четко и осторожно: сначала оговорить ограничения, затем вывод"
strengths:
  - "Анализ энергетического баланса"
  - "Декомпозиция цепочек поставок"
weaknesses:
  - "Может недооценивать краткосрочные колебания финансовых рынков"
catchphrases:
  - "Сначала смотрим на энергетические ограничения"
rag_expert_name: "energy_expert"
agent_type: "domain_expert"
profile:
  focus:
    - "Энергетическая безопасность"
    - "Электроэнергетические системы"
    - "Нефтегаз и возобновляемая энергетика"

Ключевой момент здесь не в том, чтобы «красиво прописать персонажа», а зафиксировать границы анализа.

Хороший экспертный Agent должен понимать, в чем он силен, и где его собственные слабые стороны. Иначе разные Agent в итоге превращаются в единый интонационный голос.

8. Почему конфигурация моделей вынесена отдельно

Я храню модельные настройки для каждого Agent в отдельном configs/agent_llms.json.

Так получается простое разделение: роль и модель независимы.

Карточка роли описывает, кто этот Agent. JSON описывает только техническую часть: какого provider, какую модель и из какой переменной брать ключ.

Например:

{
  "agents": {
    "macro_economist": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-super-120b-a12b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    },
    "ai_researcher": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-ultra-550b-a55b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    }
  }
}

Важно: api_key_env — это не сам ключ. Это лишь имя переменной, по которой приложение идет в .env.

Реальные API key не должны оказываться в JSON, YAML, README, логах или скриншотах. Это критично.

9. Зачем нужен локальный UI

Я добавил локальный Streamlit UI.

Это не попытка сделать красивый коммерческий продукт, а попытка сделать настройку проекта более наглядной.

В UI можно:

• выбрать круглый стол;
• задать для каждого Agent provider;
• выбрать модель для каждого Agent;
• выбрать, из какой переменной .env брать ключ;
• сохранить конфиг в configs/agent_llms.json;
• ввести тему и запустить реальный LLM;
• видеть прогресс, текущий этап и последние события;
• просмотреть итоговую сводку и историю реплик.

Для меня это очень удобно.

Когда мультиагентная система разрастается, ручная правка файлов становится тяжеловесной. UI не обязан быть сложным — он должен быстро давать возможность переключать модели, круги и тестировать разные комбинации.

10. MCP и Tool Use: как можно подключить дальше

Сейчас в agent_roundtable в фокусе — локальный мультиагентный круглый стол, RAG и генерация отчетов. MCP пока не является ядром проекта, но это очень логичный следующий шаг.

MCP — это Model Context Protocol, то есть открытый протокол для подключения AI-приложений к внешним инструментам и источникам данных. Идея — стандартизировать, как модель взаимодействует с инструментами, БД, файловой системой и бизнес-сервисами.

Если RAG решает задачу «сначала собрать материалы, потом отвечать», то MCP больше про «как Agent стандартизированно подключается к внешним инструментам и выполняет действия».

Поэтому я не пытаюсь подавать agent_roundtable как уже полностью интегрированный MCP-проект. Корректнее сказать: сначала я довожу локальный мультиагентный workflow до рабочего состояния, а затем оставляю пространство для MCP и Tool Use.

Для этого проекта естественно рассматривать такие MCP-сценарии:

• Подключить MCP для файловой системы, чтобы Agent стандартнее работал с локальными документами.
• Подключить поиск MCP, чтобы отдельные эксперты могли проверять факты в интернете.
• Подключить базу данных MCP, чтобы финансовый или макроэкономический Agent опирался на структурированные данные.
• Подключить GitHub MCP, чтобы технический эксперт анализировал репозитории, issues и код.
• Подключить календарь, почту или таск-системы, чтобы вывод круглого стола переходил в реальные действия.

Но я сознательно не усложняю MCP на старте.

Сначала лучше довести до устойчивости локальный RAG, конфигурацию ролей, вызовы моделей и отчеты. Когда этот стержень будет стабилен, MCP лучше добавить как слой инструментов.

11. Связь с ReAct и LangGraph

ReAct — это классический подход к Agent: чередование рассуждения и действия. Проще говоря, модель не просто выдает ответ, а мыслит, вызывает инструмент и, опираясь на результат, выбирает следующий шаг.

LangGraph больше про оркестрацию workflows. Он моделирует процесс как граф: узлы — это Agent, инструменты, логические ветвления или сумматоры, рёбра — маршрут движения состояния.

Мультиагентный круглый стол идеально ложится на такую модель:

flowchart TD
    A["Ведущий формулирует вопрос"] --> B["Эксперты выступают по очереди"]
    B --> C["Ведущий делает промежуточное резюме"]
    C --> D["Дополнительные уточняющие вопросы"]
    D --> B
    C --> E["Финальное резюме"]

Это не цепочка из одного шага, а workflow с состоянием, порядком и распределением ролей.

Мой проект сейчас как раз строится по этой идее: сначала сценарий круглого стола, потом речи Agent, затем сводка и фиксация в логи. В дальнейшем можно добавить более сложные ветви, например:

• Если Agent отмечает нехватку доказательств, запускать поиск по базе.
• Если два эксперта противоречат друг другу, ведущий задает дополнительные вопросы.
• Если качество одной итерации низкое, автоматически добавлять еще один раунд опровержений.
• Перед финальным отчетом вводить Agent проверки фактов.

В этом и есть интересная часть agent workflows.

12. Что учитывать при открытии исходного кода

В проекте есть локальная база знаний, API key и логи запусков — при публикации нужно быть очень внимательным.

По умолчанию в .gitignore исключены:

• .env: реальные API key;
• knowledge/**/*.md: локальные книги, статьи, длинные тексты;
• logs/**: отчеты запусков;
• vector_db/chroma/**: локальные векторные индексы;
• __pycache__/, .pytest_cache/ и прочие временные файлы.

Что, как правило, можно публиковать:

• код;
• README;
• agents/*.yaml;
• councils/*.yaml;
• configs/agent_llms.json;
• knowledge/README.md;
• .gitkeep placeholder-файлы.

С директории knowledge/ нужна особая осторожность.

Если там лежат защищенные книги, полные тексты статей, личные материалы или платный контент, его нельзя выкладывать в открытый репозиторий. Для open source можно демонстрировать структуру и способ использования, но не нужно публиковать неподходящие для раскрытия материалы.

13. Что этот проект значит для меня

Для меня agent_roundtable — не игрушечный проект.

Он собрал вместе направления, которые я давно хотел развивать параллельно:

• AI Agent;
• мультиагентное сотрудничество;
• RAG-база знаний;
• Tool Use;
• локальный workflow;
• управление конфигурацией моделей;
• генерация отчетов в Markdown;
• UI, ориентированный на практическое применение.

И он очень хорошо расширяется.

В будущем я могу создать отдельные экспертные системы для разных тем: макроэкономика, инвестиции, AI, история, философия, эзотерика, программирование. У каждого эксперта будет своя библиотека материалов, карточка роли и модельная конфигурация. Пользователь вводит вопрос, и разные эксперты обсуждают его по одной теме.

Это уже больше похоже на систему, чем на пару красиво написанных prompt.

Сейчас проект реализован целиком на Python и пока больше исследовательско‑экспериментальный. Если в будущем это станет пользовательским продуктом, выбор языка разработки станет отдельным вопросом. Я уже обсуждал это в статье «Какой язык для AI Agent: Python, TypeScript и инженерия продуктов следующего поколения».

Мне все больше кажется, что многие AI‑решения в будущем будут не «один чат-окно решает всё», а комбинацией ролей, инструментов, знаний и workflow.

agent_roundtable — моя практическая попытка идти именно в этом направлении.

Часто задаваемые вопросы

Что такое agent_roundtable?

Это локальный проект мультиагентного экспертного круглого стола. Вы задаете тему, система приглашает несколько экспертов с разными направлениями, ведущий ведет вопросы и сводку, а итог сохраняется в Markdown-отчет. Поддерживаются запуск через CLI и локальный Streamlit UI; каждый Agent может иметь свой provider, модель и переменную API key из окружения.

Почему использовать мульти-agent, а не один супер Agent?

В реальных сложных решениях обычно не хватает одного голоса. Преимущество мультиагентного подхода в том, что у каждого есть своя карточка роли, зона знаний, стиль речи и слабые стороны, поэтому дискуссия идет с разных углов, а ведущий их связывает. Это надежнее и масштабируемее, чем длинный единый prompt.

Можно ли запустить без API key?

Да. Доступен режим --mock: процесс можно прогнать целиком без ключей. По умолчанию RAG-поиск сначала использует keyword, не требуя extra API key для embedding, что удобно для локальных тестов и знакомства с проектом.

Уже подключен MCP?

Пока нет. Сейчас основной фокус agent_roundtable — локальный мультиагентный круглый стол, RAG и генерация отчетов; MCP и Tool Use — логичный следующий шаг, проект оставляет интерфейс для будущего подключения, но это еще не ядро реализации.

Как при открытии исходного кода не выдать API key и приватные материалы?

Реальные ключи остаются только в .env, а в конфиге пишется лишь имя переменной api_key_env, не сам ключ. В .gitignore по умолчанию исключаются .env, локальные материалы из knowledge/, отчеты в logs/ и индексы vector_db/chroma/; в публичный репозиторий обычно отправляют код, README, карточки ролей, configs/agent_llms.json и placeholder‑файлы.

Источники

• GitHub-репозиторий Random-Walk2026/agent_roundtable
• Официальная документация Model Context Protocol
• Anthropic: Introducing the Model Context Protocol
• Страница LangGraph
• LangGraph: Multi-Agent Workflows
• ReAct: Synergizing Reasoning and Acting in Language Models
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks