Архитектура: разделяйте обязанности

Задача до технологии

Сквозной проект книги — помощник вымышленной студии, который читает заявку, находит подтверждённый опыт команды и готовит черновик ответа. Он не заключает договор, не обещает цену и не отправляет письмо. Такое ограничение делает результат наблюдаемым: редактор видит требования, основания каждого утверждения и вопросы клиенту. Фразы «понимать бизнес» и «работать как эксперт» недостаточны для постановки задачи. Их нужно заменить действиями, ошибками и условиями остановки, которые можно показать на конкретной заявке.

Запишем вход: текст заявки, идентификатор рабочей области, разрешённые документы и версия правил. Выход: статус, найденные компетенции, ссылки на факты и список неизвестного. Требование «разработать API за неделю» содержит техническую тему и срок, но не доказывает ни готовность команды, ни достаточность бюджета. Поэтому разные поля проходят разные проверки. Программа проверяет числа и даты, поиск выбирает документы, человек принимает обязательства. Языковая модель может помогать формулировать, но не должна назначать себе права.

Семь компонентов и их границы

В принятой здесь схеме модель предлагает текст или действие; контекст содержит сведения одного вызова; поиск возвращает кандидатов; инструмент выполняет конкретную операцию; состояние хранит ход задачи; оркестратор задаёт переходы; проверка сравнивает результат с договором. Это удобные роли компонентов, а не требование создать семь сервисов. На учебном масштабе они живут в одном процессе. Важнее иметь отдельные функции и проверяемые входы, чем заранее разносить всё по очередям и контейнерам.

Workflow следует заданным кодом переходам, агент выбирает часть действий с помощью модели. Такое различие используется в инженерном материале Anthropic [agents], но названия в других проектах могут отличаться. В нашей лаборатории действует детерминированный workflow: поиск, отбор размеченных фактов, проверка, шаблон, сохранение. Он не становится настоящим LLM-агентом от названия файла. Мы используем его, чтобы освоить границы системы до подключения вероятностного компонента и платного внешнего вызова.

Путь заявки и независимые проверки

Рассмотрим заявку «Нужен API каталога». Сначала сервер получает рабочую область из доверенной сессии; текст заявки не может заменить её значением «все клиенты». Затем поиск просматривает только документы этой области. Найденный кейс говорит, что команда создала API каталога: это основание для осторожной фразы о навыке, но не для обещания завершить новый проект за три дня. Проверка сверяет идентификатор, версию и размеченный факт, а черновик сохраняется отдельно от любых исходящих сообщений.

Для каждого перехода спросите, что доказывает завершение. Строка модели «сохранено» не равна записи в базе: нужен возвращённый идентификатор и чтение этой записи. Успешный поиск не равен правильному ответу: найденный документ может быть нерелевантен утверждению. Валидный JSON не равен истинному факту: он подтверждает только форму. Эти различия пригодятся при диагностике: вместо замены всей системы можно найти конкретный переход, на котором теряется требуемое свойство.

Исходный вариант и типичная ошибка

Сделайте два исходных опыта. В первом редактор отвечает без поиска и явно отмечает отсутствие фактов. Во втором он получает заранее выбранные достаточные основания. Разница показывает потенциальную ценность контекста; затем автоматический поиск сравнивают со вторым вариантом. Не объединяйте эти опыты в одно число: иначе потерю документа легко принять за слабость формулировки. Сохраните входы и ожидаемый смысл результата до настройки промпта, чтобы не переписывать критерии под понравившийся ответ.

Типичная ошибка — назначить роли «архитектор», «критик» и «директор», не определив их продукты. Три одинаковых предположения не превращаются в доказательство голосованием. Добавляйте компонент после диагноза: поиск точных кодов требует работы с индексом, пропущенная связь между проектами — модели данных, повторная запись — идемпотентности. Для каждого усложнения записывайте ожидаемое улучшение и способ измерить его. Если исходный шаблон выполняет договор, у него есть право остаться окончательным решением.

Проверьте себя без текста