У меня пока проблема в плоскости заставить перейти на один инструмент, сейчас команда на проекте пользуется разными AI решениями. К консенсусу еще не пришли.
Эта методология мне кажется гибка и масштабируема, главное все должны ей придерждиваться и выработать внутренние правила работы с ней. Проблемы в самой методологии пока не вижу.
Решается двумя способами: 1) С помощью ТЗ - мы прям в тз прописываем путь к файлам, где какие компоненты лежат и как их использовать, в статье в примере это есть блок с ### Ключевые компоненты для реализации. Базовые схемы, такие как BatchCommandRequest, уже реализованы в core/src/schemas.py
2) Это создать в memory_bank файл с навигацией по архитектуре проекта. Прям указывать пути к файлам с описанием, что там лежит и зачем это можно использовать. Такую спеку по проекту так же можно сделать через Gemini
Мне кажется вы не дооцениваете workflow где мы прописываем инструкции для каких-то дейтсвий: исправение бага, новая фича, или других задач.
Например субагент, который после завершения задачи запускается и проверяет по некоторому своему workflow всё ли агент сделал. Сделал ли новую ветку, закомиттел, добавил ли описание в документацию, обновил ли канбан-доску и т.д. И под каждую специфичную задачу или требование можно реализовывать свой workflow.
Это правда, тут придется под каждый проект свой pipeline разрабатывать для создания ТЗ. Можно итеративно отдавать в Gemini только те модули, которые потенциально необходимы в разработке для конкретной задаче, потом суммировать и получать общую картину.
Да, это было бы интересно, но пока моей целью было изучить сам Claude Code - как он работает, что у него под капотом, чтобы лучше понимать, как ставить задачи.
Там нет сравнения, попросил его на последнем шаге удалить предыдущие todo и оставить последний шаг, система это пропустила, был лист из 5-ти действий, оставила одно.
Т.е. у агента есть возможность редактировать Todo по мере выполнения задачи, добавлять шаги, удалять, изменять. И это с одной стороны понятно, ведь агент мог что-то не учесть. Но все-таки это должно происходить более контролируемо.
Если мы используем Structured Output (SO) — такого просто не быть. В этом и заключается суть подхода: мы не «уговариваем» модель сгенерировать корректный JSON, а заставляем её. Это достигается за счёт механизма, называемого ограниченное декодирование (constrained decoding).
В этом контексте, ограниченное декодирование — это метод, который манипулирует процессом генерации токенов генеративной модели, чтобы ограничить ее предсказания следующих токенов только теми токенами, которые не нарушают требуемую структуру выходных данных.
Пока я доведу эту реализацию до ума - пройдет еще много времени, а так это уровень первого класса.)
Да, идея в том то и была, взять тот же учебник по математике, переработать все задания в инструкции для LLM. Если в задании присутствует элемент интерактивности - с помощью той-же LLM сгенерировать интерактивную среду. Кстати эта таблица тоже была написана с помощью LLM (за 20 минут). Так что да, вектор понятен.
У меня пока проблема в плоскости заставить перейти на один инструмент, сейчас команда на проекте пользуется разными AI решениями. К консенсусу еще не пришли.
Эта методология мне кажется гибка и масштабируема, главное все должны ей придерждиваться и выработать внутренние правила работы с ней. Проблемы в самой методологии пока не вижу.
Решается двумя способами:
1) С помощью ТЗ - мы прям в тз прописываем путь к файлам, где какие компоненты лежат и как их использовать, в статье в примере это есть блок с
### Ключевые компоненты для реализации.Базовые схемы, такие как BatchCommandRequest, уже реализованы в core/src/schemas.py2) Это создать в memory_bank файл с навигацией по архитектуре проекта. Прям указывать пути к файлам с описанием, что там лежит и зачем это можно использовать. Такую спеку по проекту так же можно сделать через Gemini
Мне кажется вы не дооцениваете workflow где мы прописываем инструкции для каких-то дейтсвий: исправение бага, новая фича, или других задач.
Например субагент, который после завершения задачи запускается и проверяет по некоторому своему workflow всё ли агент сделал. Сделал ли новую ветку, закомиттел, добавил ли описание в документацию, обновил ли канбан-доску и т.д. И под каждую специфичную задачу или требование можно реализовывать свой workflow.
Это правда, тут придется под каждый проект свой pipeline разрабатывать для создания ТЗ. Можно итеративно отдавать в Gemini только те модули, которые потенциально необходимы в разработке для конкретной задаче, потом суммировать и получать общую картину.
Признателен за наводку, спасибо - добавлю это ограничение в статью!
Да, вероятнее всего он только ANTHROPIC_BASE_URL подменяет, остальное остается
Да, это было бы интересно, но пока моей целью было изучить сам Claude Code - как он работает, что у него под капотом, чтобы лучше понимать, как ставить задачи.
Там нет сравнения, попросил его на последнем шаге удалить предыдущие todo и оставить последний шаг, система это пропустила, был лист из 5-ти действий, оставила одно.
Т.е. у агента есть возможность редактировать Todo по мере выполнения задачи, добавлять шаги, удалять, изменять. И это с одной стороны понятно, ведь агент мог что-то не учесть. Но все-таки это должно происходить более контролируемо.
Кинул в чат claude инструмент TodoWrite, тоже пошел генерировать весь список задач, и даже шаги, которым он не меняет статус.
По моему опыту это улучшает генерацию ответа.
И во многих фреймворках для локального инференса это упоминяется, например в vLLM https://docs.vllm.ai/en/v0.8.4/features/structured_outputs.html#:~:text=While not strictly necessary%2C normally it´s better to indicate in the prompt that a JSON needs to be generated and which fields and how should the LLM fill them. This can improve the results notably in most cases.
Но это, дейтсвительно, не обязательно, ответ все равно придет в нужном формате.
Ты говоришь о ReAct агенте. Есть реализованный такой агент на LangGraph https://langchain-ai.github.io/langgraph/agents/agents/
Если мы используем Structured Output (SO) — такого просто не быть. В этом и заключается суть подхода: мы не «уговариваем» модель сгенерировать корректный JSON, а заставляем её. Это достигается за счёт механизма, называемого ограниченное декодирование (constrained decoding).
В этом контексте, ограниченное декодирование — это метод, который манипулирует процессом генерации токенов генеративной модели, чтобы ограничить ее предсказания следующих токенов только теми токенами, которые не нарушают требуемую структуру выходных данных.
Пока я доведу эту реализацию до ума - пройдет еще много времени, а так это уровень первого класса.)
Да, идея в том то и была, взять тот же учебник по математике, переработать все задания в инструкции для LLM. Если в задании присутствует элемент интерактивности - с помощью той-же LLM сгенерировать интерактивную среду. Кстати эта таблица тоже была написана с помощью LLM (за 20 минут). Так что да, вектор понятен.