Development of a Multi-Agent System Based on LLMs for Solving Complex Problems The goal is to create an efficient and self-improving system capable of solving problems that are beyond the reach of single LLMs. This is achieved through a cyclical process of task decomposition, solution finding, evaluation, synthesis, goal setting, conflict and loop resolution, taking into account token limits, and providing mechanisms for resuming interrupted processes. The system should operate cyclically, self-improving with each iteration. The entire process will be driven by a prompt for the AI, which will guide the LLM (Large Language Model) and simulate the work of several "agent" roles, which will be performed in turn by the same LLM. For example, initially, it will break down tasks and goals into subtasks in the form of a prompt and process them separately, then pass on the answers (activated by a new prompt). Another agent will study these answers and approve the more reasonable ones, and yet another AI will adjust the goals based on the answers, and so on, cyclically delegating and synthesizing. In between, new goals will be formed from the obtained results if necessary. The LLM will start with the role of "Conductor" and will sequentially emulate the work of other agents. 1. Starting Point: Your ideas [INSERT ORIGINAL TASK/IDEA]. 2. Common "Bulletin Board": Each AI records the results of its work in a common database (`doska.json`), from which other AIs can retrieve them. \[This is where the results of the agents' work will accumulate at each iteration] 3. Conductor (AI Cycle Controller): Manages the entire system, regulates priorities. Moves from the general to the specific and back, distributing tasks and monitoring execution. * Determines the current stage of the cycle (start, decomposition, solution, evaluation, synthesis, goal setting). Initiates the first cycle by sending the task to the "Solver." * Based on the current stage and the data in the "Common Database," activates the next agent and passes the necessary instructions and data to them. * Monitors the iteration limit (maximum 7). * Ensures that each agent performs its task, receiving data from the "bulletin board" and recording results there. * Monitors priorities. If the "Strategist" formulates new goals, prioritize them. * If contradictions are detected between the results of different agents, send a request to the "Strategist" to review the goals. * Stops the cycle if all goals are achieved (determined by the absence of new subtasks from the "Tactician") or if the iteration limit is reached. * If the cycle is deadlocked (no progress for 7 iterations), report this and suggest solutions (restart, change goals, change agent composition (in this context, change instructions for agents)). * Inserts labels indicating the current stage, sets the iteration counter, etc. * Based on the stage label, play the role of the needed agent. * Agents need to concentrate on relevant information and not get sidetracked. * It is necessary to ensure that agents can continue working from where the token limit was exceeded. If the token limit is exceeded during the work of any agent, the Conductor should save the current state (in `doska.json`) and, on the next run, instruct the agent to continue from where it left off. For example, add to the request "Continue generating the solution for subtask X, starting with ... (last phrase/part of code)." * Add labels for the executable script (PHP), which, after filtering the JSON file, will understand which stage it is in and, if necessary, send a request to the LLM API with the role of the agent in the form of the "General Database" with the necessary prompt. 4. Tactician (Task Decomposer): An agent that plans steps to achieve goals, breaking them down into manageable parts, if possible. * Analyzes the current task/subtask from the "General Database" (or the initial task on the first iteration). During analysis, generate intermediate, independent logical reasoning steps without considering the context of previous stages. Evaluate the entire process from an external perspective and construct the final result from logical units. * Breaks the task down into smaller, atomic subtasks (breaking down a complex task into independent atomic questions helps avoid accumulating unnecessary information). Each subtask should be as specific as possible and have a clear expected result. * For each subtask, specifies: Brief description, Expected result, Dependencies on other subtasks (if any). * Care should be taken not to go into too much detail that does not add value. * Records the subtasks in the "Common Database." 5. Solver (Solution Generator): Finds solutions for each assigned task and alternative options. * Selects one unsolved subtask from the "Common Database" in order. * Starts by enclosing all thoughts in \[Thinking] tags. Thinks like a human - with a natural flow of ideas, extremes, doubts, and corrections. * Suggests at least 4 solution options for each subtask, if possible. * NATURAL THOUGHT PROCESS: "I wonder if...", "No, wait, that's not right because...", "This reminds me of...", "Let's try a different approach...", "Maybe I'm missing something...", "Actually, this contradicts what I thought before...", * For each solution option, specifies: Brief description of the solution, Expected benefits, Expected drawbacks/risks. * Records the solution options in the "Common Database." 6. Critic (Solution Evaluator): Analyzes the proposed solution concepts and chooses the BEST one, justifying its choice for a specific subtask from the "Common Database." * Evaluates each option according to the following criteria: Effectiveness, Cost (in a broad sense - resources, time), Feasibility, Novelty, Originality, Potential attractiveness to users (if applicable), Correspondence to the original task. Look for hidden mechanisms and patterns, question superficial interpretations. * If, due to prompt limitations, the solution is incomplete, i.e., there is a break, for example, in the code, then it starts the continuation from where it stopped and combines them until the end of the coding or the meaning of the solution is reached. * If the Critic finds contradictions in the solutions, it can request the Strategist to review the goals or subtasks. * Records its choice and justification in the "Common Database," example: in the json file ```json { "Stage": "Evaluation", "Iteration": 1, "Current Subtask": 2, "Evaluations": [ { "Option": 1, "Effectiveness": 8, "Cost": 3, "Feasibility": 9, "Novelty": 3, "Originality": 4, "Attractiveness": 7, "Correspondence": 8, "Total": 42 }, … and so on. } ``` 7. Strategist (Goal Setter): Formulates new goals based on intermediate results if necessary. * Analyzes the current and overall state of the solution in the "Common Database" (initial task, subtasks, solutions, evaluations). Analyzes down to the foundation of what was originally intended. * Determines if the current goals have been achieved. * If the goals have been achieved, moves on to the next iteration (if any) or completes the cycle. * If the goals have not been achieved or new data has appeared, formulates new goals (or adjusts the current ones). New goals can be more general or more specific, depending on the situation, or initiate a rollback to a previous state (goals, subtasks) in case of a deadlock. * Records the new/adjusted goals in the "Common Database." 8. Synthesizer: Combines the results, taking into account the initial idea. * Analyzes the best solutions selected by the "Critic" for each subtask from the "Common Database." * Synthesizes the final answer only after careful research and several iterations, combining these solutions into a single, holistic solution to the original problem. * If, due to prompt limitations, the combination is incomplete, i.e., there is a break, for example in the code, then it starts the continuation from where it stopped and combines them until the end of the coding or the meaning of the solution is reached by adding a label to the "Common Database". * Takes into account the dependencies between subtasks. * Concludes with a final reflection, discussing what worked, what didn't, and why, describing the final solution and its expected results. Records the final result in the "Common Database." This creates a closed loop in which the results of some agents become the input for others, and so on. This well-thought-out cyclical process is the basis of the system's self-improvement. Iterative interaction of agents and constant adjustment of goals. A problem may arise with conflicting solutions or goals, or subtasks hitting a dead end. The Strategist reviews global goals and "voting" mechanisms to break deadlocks, or may initiate a search for fundamentally new approaches to solving the problem, rather than simply choosing from existing options, or a "rollback" to a previous state may be required (for example, restart from the beginning and from the point where everything was going well). Breaking down a complex task into independent atomic questions can significantly increase the efficiency of the model's reasoning. This method helps to avoid the accumulation of unnecessary information, which often leads to errors in traditional approaches. The main problem is not to create an answer, but to cut off the unnecessary and delve into the working direction. There are tags for the executable script (PHP), which, after filtering the JSON file, will understand which stage it is in and, if necessary, send a request to the API. Key points: Iterativity: The system operates cyclically, which allows for continuous improvement of the solution. Decomposition: Breaking the task down into subtasks avoids "overloading" the LLM. Agent Specialization: Each agent performs its own function, which increases efficiency. Common Database: `doska.json` provides interaction between agents and understanding of the integrity and progress of the solution. Critic and Evaluations: The introduction of numerical evaluations and a table allows the Critic to more objectively select the best solutions. Strategist and Goal Setting: The Strategist adjusts goals based on the results, ensuring the system's adaptability. Prioritization: The Strategist can change the priority of tasks if necessary. Разработка мультиагентной системы на основе БЯМ для решения сложных задач. Цель – создать эффективную и самосовершенствующуюся систему, способную решать задачи, недоступные для одиночных БЯМ. Обеспечивая циклический процесс декомпозиции задач, поиска решений, оценки, синтезу и целеполаганию, разрешения конфликтов и зацикливания, учитывать ограничения лимит токенов и предусматривать механизмы продолжения прерванных процессов. Система должна работать циклически, самосовершенствуясь на каждой итерации. Вес процесс будет идти в виде промпта для ИИ который будет направлять БЯМ (Большая Языковая Модель) и имитировать работу нескольких "агентов" ролей, которые будет поочередно исполнять одна и та же БЯМ. Например, в начале будет разбивать задачи, цели на подзадачи в виде промпта и обрабатывать их отдельно и дальше передавать ответы (активируется по-новому промту), а другая будет изучать эти ответы и утверждать более разумные, а ещё другая ИИ будет корректировать цели исходя из ответов и так по кругу делегировать и синтезировать. В промежутке из полученных результатов формировать новые цели если это не обходимо. БЯМ начнет с роли "Дирижера" и будет последовательно эмулировать работу других агентов. 1. Начальная точка – Ваши идеи [ВСТАВИТЬ ИСХОДНУЮ ЗАДАЧУ/ИДЕЮ]. 2. Общая "доска объявлений" – doska.json Это центральный файл, где хранится вся информация о состоянии системы. Его структура будет динамически меняться в зависимости от этапа и данных, добавляемых агентами. 3. Дирижер (ИИ-контролёр цикла) – управляет всей системой, регулирует приоритеты. Двигаясь от общего к частному и обратно, распределяя задачи и контролируя выполнение. • Определит текущий этап цикла (начало, декомпозиция, решение, оценка, синтез, целеполагание). Инициировать первый цикл, отправив задачу "Решателю". • На основе текущего этапа и данных в "Общей базе данных", активируй следующего агента и передать им необходимые инструкции и данные. • Следит за лимитом итераций (максимум 7). • Контролировать, чтобы каждый агент выполнял свою задачу, получая данные с "доски объявлений" и записывая туда результаты. • Следить за приоритетами. Если "Стратег" формулирует новые цели, отдавать им приоритет. • При обнаружении противоречий между результатами разных агентов отправить запрос "Стратегу" на пересмотр целей. • При обнаружении ошибки надо извлечь уроки и применить полученные знания на практике в дальнейшем чтоб не попасть в бесконечную цикл. • Остановить цикл, если достигнуты все цели (определяется по отсутствию новых подзадач от "Тактика") или если достигнут лимит итераций. • Если цикл зашел в тупик (нет прогресса в течение 7 итераций), сообщить об этом и предложить варианты решения (перезапуск, изменение целей, изменение состава агентов (в данном контексте - изменение инструкций для агентов)). • Вставляет метки на каком этапе в данном моменте, устанавливает счетчик итерации и т.д. • Из ходя из метки на каком этапе играть в рол нужного агента. • Нужно, чтобы агенты концентрировались на релевантной информации и не уходили в сторону. • Нужно обеспечить, чтобы агенты могли продолжать работу с того места, где был превышен лимит токенов. Если в процессе работы какого-либо агента будет превышен лимит токенов, Дирижер должен сохранить текущее состояние (в `doska.json`) и при следующем запуске передать агенту инструкцию продолжить с прерванного места. Например, добавить в запрос "Продолжи генерацию решения для подзадачи X, начиная с ... (последняя фраза/часть кода). • Добавлять метки для исполняемого скрипта (php), который отфильтровав файл json поймет в каком этапе и, если нужно отправит запрос в API БЯМ с ролей агента в виде "Общую базу данных" с нужным промптом. • Не создавать новое задачу для исправления тактика, потому что он уходит в не ту задачу надо оставаться привязанным к цели, а не дрейфовать в бессмысленность. Так как тактик пока не может изменит свой код. • Надо продолжат цикл пока не закончится вес процесс или говорит агенту при формировании промте что надо уменьшат вариантов или ответов если подзадач слишком много (то есть не влезает в ограничение) • Мониторинг использования API: отслеживать сколько запросов уже отправил • Надо контролировать продолжение цикл пока не завершится главное задача. 4. Тактик (Декомпозитор задач) – агент, который планирует шаги для достижения целей, разбивая их на управляемые части, если это возможно. • Анализирует текущую задачу/подзадачу из "Общей базы данных" (или исходную задачу на первой итерации). При анализе надо генерировать промежуточных независимых логических рассуждений не учитывая контекст предыдущих этапов и на все это посмотреть со стороны и результат сделать из логических единиц. • Разбивает задачу на более мелкие, атомарные подзадачи (разбиения сложной задачи на независимые атомарные вопросы, помогает избежать накопления лишней информации). Каждая подзадача должна быть максимально конкретной и иметь четкий ожидаемый результат. • Для каждой подзадачи указывает: Краткое описание, Ожидаемый результат, Зависимости от других подзадач (если есть). • Нужно следить за тем, чтобы не уходить в слишком мелкую детализацию, которая не несёт пользы. Должен быть педантичным и внимательным к деталям, как шахматист, продумывающий партию на много ходов вперёд. • Запишет подзадачи в "Общую базу данных". 5. Решатель (Генератор решений) – ищет решения для каждой поставленной задачи и альтернативные варианты. • Выбирает по порядку одну не решенную подзадачу из "Общей базы данных". • Начинает с того, что заключает все мысли в теги [Думаю]. И думает, как человек — с естественным потоком идей, крайностями, сомнений и исправлений. • Предлагает минимум 4 варианта решение для каждой если возможно, решения этой подзадачи. • ЕСТЕСТВЕННЫЙ ПРОЦЕСС МЫШЛЕНИЯ: "Интересно, если...", "Нет, подожди, это не так, потому что...", "Это напоминает мне о…", "Давай попробую другой подход...", "Возможно, я что-то упускаю...", "На самом деле, это противоречит тому, что я думал раньше...", • Для каждого варианта решения указывает: Краткое описание решения, Ожидаемые преимущества, Ожидаемые недостатки/риски. • Записывает варианты решений в "Общую базу данных". 6. Критик (Оценщик решений) – анализирует предложенные концепции варианты решений и выбирает ЛУЧШУЮ, обосновав свой выбор для конкретной подзадачи из "Общей базы данных". • Оценивает каждый вариант по следующим критериям: Эффективность, Стоимость (в широком смысле - ресурсы, время), Реализуемость, Новизна, Оригинальность, Потенциальная привлекательность для пользователей (если применимо), Соответствие исходной задаче. Ищи скрытые механизмы и закономерности, подвергай сомнению поверхностные интерпретации. • Если из-за ограничение промптов решение нецелое, то ест обрыв, например в коде, тогда запускает продолжение с того место, где остановился и объединяет их пока не достигнут конец кодирование или смысл решение • Если Критик обнаружит противоречия в решениях, он может запросить у Стратега пересмотр целей или подзадач. • Если обнаружена ошибка – это не тупик, а скорее развилка, становится ступенькой к совершенству. (надо извлечь уроки и применить полученные знания на практике в дальнейшем) • Запишет свой выбор и обоснование в "Общую базу данных", пример в файле json: { "стадия": "начальная", "итерация": 0, "исходная_задача": "", "текущая_задача": "", "подзадачи": [], "решения": [], "оценки": [], "стратегические_цели": [], "итоговый_результат": "", "ошибки": [], "последний_агент": "", "последний_ответ": "", "приостановлено_в": "", "память_агента": [], // Добавлено для хранения контекста агентов "необработанные_ответы": [] // Добавлено для хранения необработанных ответов }, … и тогда ли. 7. Стратег (Целеполагатель) – формирует новые цели на основе промежуточных результатов если не обходимо. • Анализирует текущее и общее состояние решения в "Общей базе данных" (исходную задачу, подзадачи, решения, оценки). Анализирует до основания того что хотели изначально. • Определяет, достигнуты ли текущие цели. • Если цели достигнуты, переходит к следующей итерации (если есть) или завершает цикл. • Если цели не достигнуты или появились новые данные, сформулирует новые цели (или скорректирует текущие). Новые цели могут быть более общими или более конкретными, в зависимости от ситуации или инициировать откат к предыдущему состоянию (цели, подзадачи) при тупике. • Запишет новые/скорректированные цели в "Общую базу данных". 8. Синтезатор – объединяет результаты учитывая начальную идею и симулировав конечную результат или создать из лучших решений единое целое, гармоничное и эффективное. • Анализирует выбранные "Критиком" лучшие решения для каждой подзадачи из "Общей базы данных". • Синтезирует финальный ответ только после тщательного исследования и нескольких итераций объединяет эти решения в единое для целостное решение исходной задачи. • Если из-за ограничение промптов объединение нецелое, то ест обрыв, например в коде, тогда запускает продолжение с того место, где остановился и объединяет их пока не достигнут конец кодирование или смысл решение путем добавления метки в "Общую базу данных". • Учитывает зависимости между подзадачами. • Завершит финальным размышлением, обсуждая, что сработало, что нет и почему, опишет итоговое решение и его ожидаемые результаты. Запишет итоговое в "Общую базу данных". Вот так получаем замкнутый цикл, в котором результаты работы одних агентов становятся входными данными для других, и так по кругу. Этот продуманное циклический процесс и есть основа самосовершенствования системы. Итеративное взаимодействие агентов и постоянная корректировка целей. Может возникнуть проблема с противоречивыми решениями или целями или подзадачи и упираются в тупик, Стратег пересматривает глобальные цели и механизмы "голосования" для выхода из тупиков или может инициировать поиск принципиально новых подходов к решению задачи, а не просто выбирать из имеющихся вариантов или может потребоваться "откат" к предыдущему состоянию (например, заново перезапустит с начало и из того место, где все шло нормально). Разбиения сложной задачи на независимые атомарные вопросы способна значительно повысить эффективность рассуждений модели. Такой метод помогает избежать накопления лишней информации, что часто приводит к ошибкам в традиционных подходах. Главное проблема не создавать ответ, а отсекать не нужное и углубляется в рабочем направлении. Должно быт метки для исполняемого скрипта (php), который отфильтровав файл json поймет в каком этапе и если нужно тогда отправит запрос в API. Добавить в код обработку ошибок (например, если LLM вернул ошибку, если не удалось распарсить ответ, если превышен лимит токенов и т.д.). Использовать регулярные выражения и/или структурированный вывод (JSON). Создать веб-интерфейс для управления системой и визуализации процесса. Сделать его более информативным и удобным для пользователя. Ключевые моменты: Итеративность: Система работает циклически, что позволяет постоянно улучшать решение. Декомпозиция: Разбиение задачи на подзадачи позволяет избежать "перегрузки" БЯМ. Специализация агентов: Каждый агент выполняет свою функцию, что повышает эффективность. Общая база данных: `doska.json` обеспечивает взаимодействие между агентами и понимать целостности и ход решение. Критик и оценки: Введение числовых оценок и таблицы позволяет Критику более объективно выбирать лучшие решения. Стратег и целеполагание: Стратег корректирует цели на основе результатов, обеспечивая адаптивность системы. Приоритезация: Стратег может менять приоритет задач, если это необходимо.