Telegram里养8个AI打工仔:n8n智能体军团省出20小时

为什么把 8 个 Agent 塞进 Telegram?

平时处理邮件、日历、报销、旅行规划、资料调研、文案输出、社媒发帖、联系人维护,每项都要切换 App、粘贴提示词、等模型回复,累得像在玩“打地鼠”。Reddit 上一位开发者把这些场景全收编进一个 Telegram 对话框,靠 n8n 搭建的 n8n智能体军团,声称每周能省出 20 小时以上,inbox zero 直接实现。虽然数据来自帖主自述,未经第三方验证,但架构思路值得拆解。

Telegram里养8个AI打工仔:n8n智能体军团省出20小时

核心编排器如何分发任务

整套系统只有一个 GPT‑4.1 级别的“总指挥” Agent,它接收用户的文字或语音消息,先做意图识别,再把子任务路由给对应的专家 Agent。路由逻辑在 n8n 的 Workflow 里用 Switch 节点配合 Function 节点完成,关键伪代码如下:

if (intent === 'email') return 'EmailAgent';
if (intent === 'calendar') return 'CalendarAgent';
...
return 'ResearchAgent';

因为 n8n 本身是可视化流程引擎,编排器不需要写大量胶水代码,修改路由只需在画布上拖线,调试时还能直接在 Telegram 里发“/debug”查看当前分支。

专家智能体的协作与记忆流转

八个专家 Agent 分别对接 Google Workspace、Airtable、SerpAPI、Tavily、Perplexity、Replicate 等外部 API。它们共享一张 PostgreSQL 表作为长期记忆,字段包括 user_id、session_id、task_type、result_json。每次子任务结束,专家把结构化结果写回表,总指挥下一轮读取即可拿到上下文,实现“跨 Agent 记忆”而不依赖单一模型的上下文窗口。

记忆表结构示例

CREATE TABLE agent_memory (
  id BIGSERIAL PRIMARY KEY,
  user_id TEXT,
  session_id TEXT,
  task_type TEXT,
  payload JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

自托管 vs 云端:真实成本账单

n8n 社区版自托管免费、无限执行,但你需要自备服务器、PostgreSQL、SSL 证书、定时备份,运维成本往往被低估。官方 Cloud 方案分 Starter 年付 €20/月(2,500 次/月)和 Pro €50/月(10,000 次/月),云端没有永久免费版,只有 14 天试用。如果每天跑 200 次工作流,Starter 额度早就不够,升级 Pro 一年约 €600,加上 OpenAI API 费用、SerpAPI、Tavily 等第三方调用,实际月账单很容易破百欧元。作者在帖子里称“运行成本难以量化”,まさに因为这些隐形项没算进去。

重度使用下,账单可能比你想象的贵

  • Telegram Bot Token 明文存放在 n8n 环境变量,生产环境请用 Secret Manager 或 Vault。
  • 语音消息需先通过 Whisper 或类似 ASR 转文字,再喂给总指挥,延迟约 1‑2 秒,体验不如纯文本。
  • 专家 Agent 并发过高会触发外部 API 限流,建议在 n8n 里加 Rate Limit 节点做削峰。
  • PostgreSQL 连接池未调优时,高峰期会出现 “too many connections” 报错,导致整个编排卡死。

把这套东西跑起来的最小步骤

  1. 在 VPS 上用 Docker Compose 启动 n8n + PostgreSQL(参考 官方仓库 的 docker-compose.yml)。
  2. 创建 Telegram Bot,拿到 Token 并设置 Webhook 指向 n8n 的 /webhook/telegram 路径。
  3. 在 n8n 里新建 Workflow,导入社区分享的 “8‑Agent Personal Assistant” 模板(见 agentusecases 解读页)。
  4. 配置各专家节点的 API Key(Google、Airtable、SerpAPI、Tavily、Perplexity、Replicate、OpenAI)。
  5. 跑一遍测试,发送 “帮我订下周去东京的机票和酒店”,观察总指挥如何拆解、调度、回写记忆。

跑通后,你就拥有了一个随叫随到的 “AI 打工仔军团”,但别指望零成本、零维护。把它当作原型验证,再决定是否把核心流程迁移到自建 Kubernetes 集群,才是比较靠谱的节奏。