В некоторых продуктах, которые мы создаем, сервер приложений Codex больше не является просто инструментом разработчика. Агентский цикл является частью продукта. Он может проверять состояние, выбирать инструменты, изменять постоянные данные, запрашивать одобрение, восстанавливаться после сбоев и достигать...
В некоторых продуктах, которые мы создаем, сервер приложений Codex больше не является просто инструментом разработчика. Агентский цикл является частью продукта.
Он может проверять состояние, выбирать инструменты, изменять постоянные данные, запрашивать одобрение, восстанавливаться после сбоев и достигать одного и того же действительного результата разными путями.
Когда мы увеличили эту автономию, я начал замечать странный дисбаланс.
Код продукта, конечно, рос. Но количество кода и механизмов проверки росло по-другому.
Не только модульные тесты или E2E.
Мы начали собирать оценки, фаззеры, детерминированные верификаторы, независимые оракулы, определения возможностей, трассировки, повторы, политики, аудиторские доказательства и шлюзы выпуска.
Сначала я назвал все это «тестовым кодом». Довольно быстро это перестало казаться точным.
Лучшее название — инфраструктура проверки.
Я не имею в виду буквально, что каждое агентское приложение будет иметь больше тестовых LOC, чем продуктовых LOC. Более интересная закономерность заключается в том, что относительно небольшой объем реализации теперь может выявить удивительно большое количество поведения.
Это меняет то, что нам нужно проверить.
Небольшая среда выполнения агента может создать большую поведенческую поверхность.
Традиционное программное обеспечение CRUD