作为一名大部分时间都在终端和聊天应用中度过的软件工程师，我对臃肿的软件即服务设置、复杂的云架构以及失控的订阅账单感到极度疲惫。我想要一个个人人工智能助手，它恰好存在于我已经工作的地方：电报。不是另一个网页仪表板，不是斯莱克机器人，也不是我会忘记打开的命令行界面工具。只有我、一个聊天线程，以及一个真正能够做事的人工智能。
我将电报用于工作、私人聊天、通知以及所有事务。这是我唯一从不关闭的应用程序。因此，这很合理：与其构建一个我必须记得去访问的独立人工智能工具，不如构建一个出现在我现有消息流中的工具。我可以要求这个机器人检查我的电子邮件，提醒我在下午六点给某人打电话，记住我喜欢在早上进行异步沟通，或者总结我未读的消息——所有这些都不需要离开我的聊天列表。
以下是我如何构建它的过程，包括底层架构、安全模型、调度管道，以及我为保持完全零基础设施而做出的权衡。
技术栈：Bun、Telegraf、Composio
技术选择受限于一个严格的约束：零基础设施。无需部署服务器，无需多克尔容器，无需云账单。它必须能在五美元的虚拟专用服务器或我的笔记本电脑上运行。整个技术栈必须适应单个进程，使用基于文件的数据库，并且除了其调用的应用程序接口外，没有外部依赖项。
运行时：Bun。启动速度快，原生支持类型脚本，内置轻型的结构化查询语言数据库，以及用于后台任务的网络工作者。它是一个单一的二进制文件，运行时没有
node_modules目录。Bun的bun:sqlite比better-sqlite3更快，且不需要任何原生编译。机器人框架：Telegraf v4。成熟稳定，采用轮询模式（无需网络钩子服务器），以及精简的中间件模型。它处理
getUpdates循环，在网络错误时自动重试，并为每条消息提供干净的ctx对象。人工智能软件开发工具包：开放人工智能软件开发工具包 v6。带有流式传输功能的聊天补全应用程序接口。我手动管理工具调用循环——模型响应文本或函数调用，我执行它们，将结果反馈回去，并循环最多N步。没有框架包装，没有魔法。
工具平台：Composio。拥有两百多个预建集成（吉邮件、斯莱克、日历、吉特哈布、吉拉、诺申）。它处理开放授权流程、会话管理、应用程序接口重试和速率限制。我将其封装在一个自定义工具中，暴露
search（查找工具标识符）和execute（通过标识符运行工具）功能。数据库：通过
bun:sqlite使用的轻型结构化查询语言数据库。没有对象关系映射，使用原始查询，采用预写日志模式以支持并发读取。六个表，零配置，没有迁移框架——只是一个按顺序运行的、带有版本跟踪的CREATE TABLE语句数组。调度：用于轮询循环和人工智能任务执行的Bun网络工作者。没有cron定时任务，没有雷迪斯，没有BullMQ，没有外部调度器。两个工作者共享同一个轻型结构化查询语言数据库文件。
架构：轮询，而非服务
大多数电报机器人作为HTTP服
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
