Коротко
Автор создал агента, который ищет типизированные факты AWS в Sanity, выбирает значение по явным правилам приоритета источников и проверяет его через доступные API AWS. Важный результат — вместо уверенного, но потенциально устаревшего ответа агент показывает актуальную запись, вытесненные данные и расхождения с реальным аккаунтом.
Контекст
Автор — разработчик, подавший проект на Sanity Challenge, Path One. Он столкнулся с тем, что официальная документация, консоль Service Quotas и другие официальные страницы могут указывать разные значения AWS, а обычный поиск способен поставить устаревший результат выше актуального. Проект использует Amazon Nova Pro на Bedrock, Strands Agents для Python и Sanity Context Knowledge Base.
Главное
- Стек проекта: Amazon Nova Pro на Bedrock, Strands Agents (Python), Sanity Context Knowledge Base и read-only проверки AWS API.
- Каждый факт — типизированный документ
awsFact; пример gp3 указываетcurrentValue: "80000",unit: "IOPS",effectiveDate: "2026-01-15"и источникserviceQuotasConsole. - Правило сверки отдаёт приоритет консоли и странице цен, затем changelog, официальной документации и блогу; при равном приоритете выбирается более поздняя дата действия.
- Контекстные данные агент запрашивает инструментами
knowledge_base_searchиknowledge_base_read; путь без токена использует публичный датасет через анонимный GROQ. - Модель не может самостоятельно выбрать итоговое число: сверка выполняется функцией, а guard заменяет ответ Nova, если тот расходится с результатом.
- На примере EBS gp3 устаревшие 16 000 IOPS выигрывают у актуальных 80 000 в TF-IDF-поиске: 0.8626 против 0.2026.
- EC2 демонстрирует три разных значения одной квоты: 32 в старом руководстве, 5 в сверенной записи и 16 в live-аккаунте; итог — DRIFT.
- В остальных примерах S3 совпадает на $0.023/GB-месяц; RDS PostgreSQL расходится (13 в записи против 11 live); Graviton4 (R8g) совпадает по доступности.
- Для EBS IOPS и Lambda live-значение обозначается как unavailable, если соответствующей квоты для проверки нет; автор не подставляет выдуманные данные.
- Запуск локальной сверки:
python -m agent.reconcile_offline --service EBS --type limit --region us-east-1; baseline-поиск:python -m agent.baseline "maximum IOPS per volume general purpose SSD".
Как сделано
Факты хранятся в Sanity как документы типа awsFact с полями service, factType, region, key, currentValue, unit, effectiveDate и данными об источнике. Knowledge Base индексирует записи, а агент получает их через Context MCP: knowledge_base_search, затем knowledge_base_read. Для сценария без токена предусмотрен анонимный GROQ-запрос к публичному датасету.
Значение выбирает обычная детерминированная функция: источники с более высоким приоритетом побеждают, а при равном приоритете решает более поздний effectiveDate. Nova Pro формулирует ответ, но не определяет победивший факт: защитная проверка сравнивает текст модели с результатом сверки и при несоответствии подменяет его детерминированным ответом. Если типизированный запрос не находит фактов, предусмотрены повторный поиск по сервису и региону и серверное сохранение результатов последнего настоящего извлечения.
После сверки агент выполняет read-only проверку через AWS API, включая Service Quotas, Price List API, EC2 и RDS. Эта проверка помечается отдельно от данных Sanity и зависит от AWS-аккаунта. Без модели и токена можно запустить python -m agent.reconcile_offline --service EBS --type limit --region us-east-1; для проверки слабости поиска есть python -m agent.baseline "maximum IOPS per volume general purpose SSD".
Результаты
В примере с EC2 квотой On-Demand Standard документация указывала 32 vCPU, запись после сверки — 5, а live-проверка аккаунта — 16: результат помечен как DRIFT. Для максимума IOPS на EBS gp3 актуальная запись содержит 80 000, устаревший SSD guide — 16 000; live-квота недоступна, поэтому значение отмечено как доверенное без такой проверки. Базовый TF-IDF-поиск ранжировал устаревшие 16 000 выше актуальных 80 000: оценки 0.8626 и 0.2026 соответственно. В таблице также показаны совпадение цены S3 ($0.023/GB-месяц), расхождение по старейшей основной версии RDS PostgreSQL (запись 13, live 11), недоступная live-проверка лимита Lambda и совпадение доступности Graviton4 (R8g). Автор сообщает, что проверка защитой исправила неудачную формулировку Nova в одном запуске.
Ограничения
Это демонстрационный набор данных, а не исчерпывающая база AWS. Live-значения относятся к конкретному AWS-аккаунту и могут отличаться у других пользователей; для EBS IOPS и Lambda соответствующая live-квота не нашлась. Автор не показывает скриншот разрешённого Issue в Sanity: Knowledge Base выдала записи с обоими источниками, а очередь Issues осталась пустой. В начале разработки модель теряла аргументы инструмента и ошибалась в factType; описанные исправления — fail-closed, серверный кэш последней выборки и повторный поиск — не заменяют независимую оценку качества на широком наборе запросов. Количественных данных о стоимости, задержке и систематической точности нет.
Что взять себе
- Когда источники могут конфликтовать, храните факты с типом, датой и происхождением, а не только в виде прозы.
- Пусть модель объясняет результат, но фиксированное правило и проверка определяют, какое значение допустимо сообщать.
- Разделяйте документированное значение и live-проверку: последняя может быть доступна не для каждого факта и зависит от аккаунта.
- Показывайте вытесненные значения и источники — это помогает выявить устаревшие записи, не маскируя неопределённость.
Читать оригинал, если…
Откройте оригинал, если нужны репозиторий и README, инструкции по настройке Bedrock и Sanity Context, полный вывод команд или подробности по отдельным фактам и API.