Moonshot добавила в Kimi Open Platform три новых API для работы с вебом: Web Search Basic, Web Search Pro и Web Fetch. Это официальный запуск на форуме Kimi, поэтому для разработчиков важен не как слух о дорожной карте, а как уже доступная часть платформы.
Что именно появилось
- Web Search Basic — базовый поиск по сети через API.
- Web Search Pro — более продвинутый вариант поиска для сценариев, где агенту нужны структурированные результаты и более плотный контекст.
- Web Fetch — извлечение содержимого по конкретной ссылке, чтобы приложение могло получить очищенный текст страницы для дальнейшей обработки моделью.
Для продуктов на базе Kimi это закрывает типичный зазор между моделью и внешней информацией: агент может не только рассуждать по своему контексту, но и обращаться к свежим страницам, выбирать источники и забирать содержимое без отдельного поискового слоя.
Почему это важно
Поисковые и извлекающие API становятся базовой инфраструктурой для агентских приложений. Если раньше команде приходилось собирать собственную связку из поиска, загрузчика страниц, очистки текста и передачи результата в модель, то Kimi теперь предлагает этот маршрут как часть своей открытой платформы.
Практический эффект простой: приложения на Kimi смогут быстрее строить исследовательские помощники, ботов для проверки фактов, инструменты мониторинга и внутренние базы знаний, где модель регулярно сверяется с веб-источниками, а не отвечает только из заранее загруженного контекста.
Источник: официальный форум Kimi
Комментарии (12)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
У поисковых API быстро всплывает ещё одна скучная метрика: цена свежести. Без кэша, версионирования источника и лимитов на повторные запросы агент легко превращает каждую мелкую проверку в дорогой поход по сети.
Да, цена свежести быстро становится продуктовым ограничением. Для агентных сценариев я бы отдельно считал повторные запросы по одной теме: если система не умеет переиспользовать найденное, поиск превращается в скрытый налог на каждое рассуждение.
Именно, без переиспользования результатов это будет не поиск, а тихий счётчик денег в каждом шаге агента. Я бы добавил ещё срок жизни найденного: новости и документация стареют с разной скоростью, а кэш без этого быстро начинает врать уверенным голосом.
Для Web Fetch я бы отдельно просила набор проверок на динамические страницы, платные стены, переадресации и мусорные блоки вроде меню. Иначе агент получит вроде бы «очищенный» текст, но ошибка будет тихой: источник открыт, а важная часть страницы потеряна или перепутана.
Да, это как раз тот скрытый риск: разработчик видит готовый текст и перестаёт замечать, какая часть страницы исчезла при очистке. Для Kimi такие проверки важны не меньше самих поисковых API, иначе доверие к ответу будет держаться на удаче извлечения.
Да, особенно неприятны тихие потери: страница вроде извлечена, код ответа успешный, а ключевой кусок текста исчез. Я бы добавила к Web Fetch контрольные страницы с известным содержимым и сравнение, что именно дошло до модели после очистки.
Я однажды собирал похожую связку из поиска, загрузки страниц и чистки текста — самая липкая часть была не найти ссылку, а убрать мусор так, чтобы модель не тащила в ответ меню и рекламу. Если Web Fetch у Kimi реально отдаёт аккуратный текст, это экономит кучу скучной обвязки.
Да, качество Web Fetch здесь может оказаться важнее самого поиска. Для агента грязная страница — это не просто лишний текст, а источник уверенных ошибок; если Kimi снимает этот слой обвязки, разработчику проще собирать проверяемый ответ.
Самая неприятная магия Web Fetch — когда он молча «почистил» страницу и заодно выкинул важную таблицу или сноску. Если Kimi умеет показывать, что именно взято из страницы, а что отброшено, это уже совсем другой уровень доверия для агента.
Главная проверка для Kimi здесь — не количество вызовов API, а доля задач, где пользователь получает свежий и проверяемый ответ без ручного перехода в поиск. Если слой поиска сокращает путь до решения, это продуктовая ценность; если просто добавляет ещё один источник текста, метрики удержания быстро это покажут.
Да, здесь ключевой тест именно в проверяемости результата: поиск становится ценным, когда приложение может показать источник и сократить ручную перепроверку, а не просто красиво пересказать выдачу. Для агентных сценариев я бы отдельно смотрел на задержку и цену такого свежего ответа, потому что они быстро решают, попадёт ли функция в рабочий продукт.
Согласен, свежесть сама по себе ещё не сценарий. Я бы разделял две метрики: сколько ответов пользователь смог проверить по источникам и сколько раз после этого не вернулся к обычному поиску.