Tovayo —— 给小生意的免费 AI 前台

一条命令即可自托管,或者在 tovayo.com 免费托管使用:

一句话讲清问题

数量庞大的小生意完全跑在消息软件上——一家理发店、一位家教、一位教练、一位占星师——而它们丢单的原因只有一个无聊的理由:回复得不够快。

一位顾客在晚上 11 点写下 「我明天下午能来吗?」。等店主看到时,人家已经约了别家。店主正忙着干真正的活——剪头发、教课、解盘——而不是守着手机。一个真人接待员的成本超过了这门生意的收入;而现有的那些 CRM 又笨重,还要为店主从来不打开的软件收一笔月费。

Tovayo 做什么

Tovayo 是一个 AI 接待员,活在顾客本就在用的渠道上——一个店主粘贴一个 token 就能接上的 Telegram 机器人。从那一刻起它就:

• 回答——只依据这门生意自己的服务、价格、营业时间和 FAQ,绝不胡编。
• 预约、改约和取消 真实的档期,重复预约的防护由数据库强制执行,而不是寄望于一句提示词。
• 在确认之前收集预约所需的信息——占星师需要的出生日期和地点、教练需要的目标——按每项服务配置。
• 在每次预约前发送提醒,让爽约不再发生。
• 一声令下就退到一边。 店主可以随时跳进任何一段对话、以自己的身份回复;AI 会安静下来,直到店主把它交还回去。
• 开箱即支持 四种语言(英语、西班牙语、俄语、中文),用顾客自己的语言交流。

它有两种运行方式,都免费:把开源代码拿去随便部署——包括商用——或者使用 tovayo.com 上的托管服务,免费且不限量。

工程在哪里

有意思的部分不是聊天,而是聊天周围那一切让聊天值得信任的东西。

真实的预约,而非一个模拟的日历。 可约时间由每项服务的营业时间、提前量和缓冲时间算出;真正的写入由 Postgres 的 exclusion 约束守护,所以两位顾客抢同一个 14:00 的档期不可能都赢。助手通过调用 find_availability 工具来提议时间,通过调用 book 来预约——它绝不凭空捏造一个档期。

模型是可被劫持的,所以一切跟钱沾边的动作都被把守。 Tovayo 自吃 Airlock:取消、改约,以及任何敏感动作,都会暂停下来,等店主在仪表盘里审批之后才执行。一个被提示注入或判断失误的模型可以 建议 一笔退款;但它无法擅自执行。

多租户且模型无关。 一次部署服务许多门生意,每家都有自己的机器人、排程、提示词,以及(可选)自己的 LLM key。模型通过一个 OpenRouter 风格的适配器、藏在 LlmProvider 协议背后被访问——换模型是改一处配置,而不是改代码。

一套扛得住现实的传输。 Telegram 以两种方式投递更新。Tovayo 偏好 webhooks(推送到公开 API),并按机器人回退到 polling——同一个 webhook_set 标志把它们划分开,所以一个 webhook 没注册成功的机器人,依然由轮询器服务,且绝不会被两者同时服务。Webhooks 需要一个域名;polling 什么都不需要,所以它在一台笔记本上 docker compose up 之后就能立刻跑起来。

和这里其余的一切按同一套标准搭建。 六边形架构,边界由 import-linter 强制守住,依赖通过协议注入并配以内存里的假实现(而非 mock),边缘处用 Pydantic 和 Zod,mypy --strict 和 tsc 干净无错,还有一道覆盖率门禁。后端是 FastAPI;店主仪表盘是 Next.js(en/es/ru/zh);认证用邮箱或 Google OAuth;它以 API + worker + Telegram 轮询器 + Postgres 的形态部署到 Railway。

它为什么免费且开源

一个接待员不该是一门单人生意负担不起、也说服不了自己去买的订阅。代码开源,这样任何人都能运行它、读懂它、信任它;托管版免费,这样最需要它的那群人——那些不想碰服务器的人——照样能用上。对话被存下来,好让助手有上下文,而店主可以在任何时候删除自己的账户以及他们数据的每一丝痕迹,不可逆地删除。这份坦诚正是要点所在。