Когда Vercel анонсировал Chat SDK с поддержкой Notion, я сначала подумал — ещё одна точка интеграции, которую никто не будет использовать. Но после тестов оказалось, что это один из тех редких случаев, когда адаптер действительно решает конкретную боль. Вот что выяснилось на практике.
Почему Notion — не просто ещё один мессенджер
Главное преимущество Notion adapter в том, что он не создаёт очередной silo для бота. Ваш агент, уже работающий в Slack/Discord/GitHub, получает доступ к обсуждениям в Notion без переписывания кода. Всё, что нужно — подключить новый адаптер к существующей логике бота.
Технически это реализовано через стандартную для Chat SDK модель:
- Страница = канал
- Тред комментариев = тред сообщений
Но есть нюансы:
// Пример обработки комментария в Notion
bot.on('commentCreated', async (ctx) => {
if (ctx.message.text.includes('@review-bot')) {
await ctx.reply(`Here's my analysis: ${analyzeContent(ctx.pageTitle)}`);
}
});
В отличие от Slack, где бот может реагировать на всё подряд, в Notion разумнее использовать explicit mentions — иначе рискуете заспамить историю комментариев. Особенно важно это для workspace, где бот имеет доступ ко всем страницам.
Что работает из коробки (а что нет)
Работает хорошо:
- Треды сохраняются автоматически — не нужно изобретать систему reply_to
- Поддержка файлов (до 3 вложения)
- История сообщений (но только открытых комментариев)
- Триггеры: @mentions, ключевые слова или все комментарии
Ограничения, которые стоит учесть:
- Нет кнопок и модалок — только plain text/markdown
- Карточки (например, из Jira) приходят как markdown
- Нельзя ответить на выделенный текст — только на блок или страницу целиком
- Редактирование сообщений есть, но нет реакций
На практике это значит, что сложные интерактивные сценарии (типа approve/reject через кнопки) придётся переводить в текстовые команды. Для агентов, которые просто отвечают на вопросы или комментируют изменения, этого хватает.
Сценарии, где это действительно полезно
Из тестовых кейсов лучше всего зашли три варианта:
Code review в Notion
Когда PR-описание ведётся в Notion, бот может:
- Автоматически комментировать требования к коду
- Предлагать улучшения при @упоминании
- Синхронизировать статус с GitHub
Documentation QA
Агент, обученный на вашей документации, может:
- Отвечать на вопросы в комментариях
- Предлагать related pages
- Помечать устаревшие разделы
Meeting notes follow-up
После митинга бот:
- Выделяет action items
- Предлагает добавить недостающие темы
- Интегрируется с календарём
Главное преимущество перед тем же Slack — контекст привязан к документу, а не растворяется в потоке сообщений.
Подводные камни интеграции
-
History limitations
Если комментарий закрыли — бот его не увидит. Это проблема для аудита и сквозного анализа. -
No rich interactions
Привычные для Slack-ботов интерактивные элементы не работают. Придётся имитировать их через text commands. -
Permission granularity
Бот либо имеет доступ ко всему workspace, либо ни к чему. Fine-grained permissions пока нет.
Для наших проектов критичным оказался первый пункт — часть workflow требует доступа к закрытым комментариям. Пришлось дублировать важные обсуждения в базу данных при первом упоминании.
Что пробовать, если решили внедрять
-
Начните с простого агента-ассистента, который отвечает на вопросы по документации — минимальный риск, видимый результат.
-
Для code review сценариев подключите RAG с вашей codebase — так бот сможет ссылаться на конкретные модули.
-
Если нужно больше интерактивности, используйте hybrid approach: бот в Notion даёт текстовую сводку, а подробности предлагает обсудить в Slack через deep link.
Лично мне адаптер кажется удачным для медленных, контекстно-зависимых обсуждений. Он не заменит Slack для оперативных чатов, но отлично дополняет workflow, где важно привязывать обсуждение к документу. Главное — не пытаться запихнуть в него сценарии, рассчитанные на rich-интерфейсы.
Попробуй сам: Vercel — Edge Functions и serverless деплой.