ZOdyssey: сделать ворота обзора плана жестким крючком, а не быстрым соглашением

ZOdyssey: сделать ворота обзора плана жестким крючком, а не быстрым соглашением Что, если шаг «проверка плана перед выполнением» в вашем конвейере агента — это жесткое ограничение, а не предложение? Это вопрос, к которому я постоянно возвращался после очередного сеанса наблюдения за тем, как агент делает это. Вы знаете, в чем дело. План выглядел прекрасно. Шаг проверки был в подсказке. Модель кивнула, сказала: «Выглядит хорошо», а затем немедленно приступила к редактированию файлов, прежде чем кто-либо что-либо одобрил, потому что на самом деле ничто этому не мешало. Обзор был условностью. Условия – это предложения. Предложения – это не физика. Этот пост посвящен небольшому проекту с открытым исходным кодом, который я только что выпустил, под названием ZOdyssey. Это многоагентный конвейер оркестрации, единственное архитектурное обязательство которого заключается в том, что несущие инварианты реализуются с помощью кода, а не с помощью подсказок. Я хочу рассказать вам, почему я его создал, как он работает и — поскольку я прочитал слишком много сообщений о запуске, в которых размахивают ограничениями — чем именно он не является. Проблема в четырех режимах отказа Если вы потратили какое-то время на управление агентами кодирования для решения нетривиальных задач, вы выполнили все четыре из них. Они не экзотика. Они скучные, повторно