Комментарии 9
Для меня самое ценное здесь — независимая проверка с чистым контекстом: пересказ тех же пунктов договора разными формулировками ловит именно те ошибки, которые тесты автора не видят. В автоматизации бизнес-процессов (агенты, обработка заявок и документов) вижу то же: проверять нужно на формулировках, которых не было в примерах, и закладывать в систему право на «нет данных / сомневаюсь» вместо уверенного угадывания. Вопрос по практике: как вы разделяете параллельные пакеты на общих файлах — очерёдность задаёт оркестратор сам или вы вручную утверждаете порядок?
Спасибо! Вы очень точно сформулировали про право на "нет данных / сомневаюсь".
По поводу параллельных пакетов - порядок задаёт оркестратор, человек только согласовывает или корректирует. В этом, собственно, смысл оркестрации. В статье есть как раз описание этой ситуации - когда я спросил, можно ли ускориться, оркестратор сам предложил, как разрезать работу: какие пакеты идут параллельно, у кого какие пути и какие файлы общие. Перед запуском каждого пакета оркестратор проверяет пересечения путей. Общие файлы (в кейсе это были package.json и lock-файл) держатся замком: правит тот, у кого замок, остальные ждут. Слияния тоже идут очередью, и ведёт её именно оркестратор.
Я бы ещё отдельно проверял повторную доставку уже принятой работы. У меня в конвейере обычная сборка документов вызывала гейт, а скрипт обновления уже отданного документа шёл мимо него. Проверка существовала, но на этом пути вообще не запускалась. Нашёл это аудитом, после чего поставил такой же запрет на повторную доставку. Приёмка первой версии эту дыру не ловила: она появлялась, когда я обновлял документ по прежней ссылке.
Сайт не на beget был?
Представил очередь код-агентов в КодГрифоне к package.json: «Я только спросить, мне две строчки»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оркестрация ИИ‑агентов: когда нужно поправить в одном месте и не сломать всё остальное