Ole Lehmann 第一次打开 Hermes:
"等下,这就是 Claude 或 ChatGPT 套了个 Telegram 外壳,有什么区别?"
20 分钟后他关掉。觉得被骗了。
但他后来意识到问题不是 Hermes——是他没装 integrations。
他的洞察:
把 agent 想象成漂浮在罐子里的脑子。
它聪明、快、乐意说几个小时。但完全跟你的真实生活切断。它其实做不了什么。全是 talk,没有 walk。
Integrations 是你给那个脑子装上的感官和四肢。
4 个 agent 能做的工作类别
每个真正"work"的 Hermes setup 都在做 4 类事:
- Research(查信息、监控、跟踪)
- Action(执行任务、完成任务、自动化)
- Analysis(数据洞察、报告、建议)
- Communication(主动联系、回复、推送)
装 integrations 时按这 4 类配比配——而不是乱装。4 类都至少 1 个 integration,agent 才真的"活"起来。
12 个 integrations 让 Hermes 变 superagent
视觉类
- Firecrawl——给 agent 增强的 web 视觉。它能从任意 URL 抓内容、解析结构、提取数据。Hermes 用 Firecrawl 能"读"任何网站(不用 API key 那种),包括 PDF、JS 渲染的 SPA、表单数据。
听觉类
- Reddit——给 agent 街头听觉。监听 subreddit 的新帖、热门评论、情绪变化。这是趋势跟踪、市场调研、用户反馈的关键数据源。
声音类
- Bland——给 agent 一个能接电话的声音。agent 主动打电话(订餐、客服、问询、survey)。LLM 时代最强的 integration 之一——**从"聊天机器人"到"打电话的机器人"**是质变。
财务类
- Stripe——给 agent 业务视角。Hermes 能查你的 Stripe 收入、订阅变化、churn rate、MRR。配合其他 integration,agent 能主动建议你"砍掉哪个 product line"或"提价哪个 tier"。
长期记忆类
- Obsidian——给 agent 长期记忆。Hermes 能读你 Obsidian vault 里的所有笔记,把对话内容自动写回 vault。这不是简单的 memory——是结构化、可 query 的个人知识库。
其他 7 个
略,具体清单:Notion / Linear / Slack / GitHub / Google Calendar / HubSpot / Telegram Channel(监听多个 channel 聚合)。
装 2 个 vs 装 12 个的质变
Ole 给了关键的"价值曲线"判断:
| 装几个 | agent 状态 | 价值 |
|---|---|---|
| 0 | 漂浮的脑 | 跟普通 chatbot 一样 |
| 1-2 | 单一感官的 agent | 略好于 chatbot |
| 3-4 | 多感官的 agent | 开始有质变——能执行简单 workflow |
| 5-8 | 真 agent | 能跑 5-10 个 daily workflow |
| 9-12 | superagent | 早上解锁手机看到夜间跑完的复杂 workflow |
Ole 自己说:装到 12 个的第二天早上,他看到 Hermes 夜间跑了 5 个 workflow——
- 自动归档昨天的 Slack 重要消息
- 自动总结 Reddit r/AIagents 的 top 50 帖
- 自动给 3 个潜在客户发 follow-up 邮件
- 自动生成昨天的支出报告
- 自动给明天的 calendar 准备 brief
"第一次看到的时候我脑震荡了。"(broke my brain)
4 类工作流具体怎么跑
Ole 给了 4 个具体例子(每个 1-2 个 integration):
Research workflow
监听 Reddit r/AIagents + r/LocalLLaMA
↓
每天早上 7 点自动总结 top 50 帖
↓
自动 push 到 Telegram + 写入 Obsidian 的 "Daily Research" 笔记
Hermes 用 3 个 integration:Reddit(监听)+ Obsidian(写入)+ Telegram(推送)。
Action workflow
每天 17 点查 Stripe 当日收入
↓
如果 > 阈值 → 触发庆祝流程(Slack 发 channel 通知)
如果 < 阈值 → 触发复盘流程(汇总到 Notion)
Hermes 用 3 个 integration:Stripe(数据源)+ Slack(通知)+ Notion(记录)。
Analysis workflow
每周日 22 点拉本周所有数据源
↓
生成 weekly insights report
↓
自动发到你的 email + 写入 Obsidian
Hermes 用 4-5 个 integration:多个数据源 + email + Obsidian。
Communication workflow
每天 18 点查所有未回复邮件
↓
按优先级分类(urgent / fyi / newsletter)
↓
urgent 自动起草回复(你 review)
fyi 写日报
newsletter 归档
Hermes 用 3 个 integration:Email + Slack/Telegram(通知)+ Obsidian(归档)。
装 integrations 的关键判断
不要乱装
Ole 强调:先做 1-2 个 workflow,再装对应 integration。
反模式:装 12 个 integration 但不知道跑什么 workflow。结果是配置时间 2 周,实际使用率 5%。
正确姿势:
- 第一周:装 2-3 个 integration 跑 1 个 workflow
- 跑顺了再加
- 1-2 个月后到 12 个 integration
Integration 之间要互补
12 个 integration 如果都是同质化(如 5 个不同的 email 客户端),价值递减。
正确配比:
- 1 个数据源
- 1 个执行通道
- 1 个长期记忆
- 1 个通知出口
这 4 类至少各 1 个,剩下的按需。
MCP 是 integration 协议
Ole 提到:MCP(Model Context Protocol)是 integration 的标准协议。Anthropic 推的 MCP 正在成为 integration 生态的事实标准——装了 MCP 兼容的 integration 越多,agent 的可组合性越强。
适合谁 vs 不适合谁
适合
- 每天有重复 workflow 的人(销售、运营、咨询、研究)——integrations 的价值是自动化
- 跨多个工具工作的人(Notion + Linear + Slack + GitHub)——agent 能跨工具编排
- 有 long-running task 的人(每天跑 1 次的 pipeline、weekly 报告)——agent 在你睡觉时跑
不适合
- 每天任务都是新类型(创意、探索)——integrations 帮不上忙
- 只用一个工具的人(只用 Notion 或只用 Slack)——装 1-2 个 integration 价值有限
- 隐私敏感场景(agent 读你所有邮件 + 所有笔记)——integration 越多隐私泄露面越大
Ole 没说的两件事
1. Integration 之间的"协议税"。每装一个 integration 都要配置、auth、错误处理、retry 逻辑——这是隐藏的 setup cost。12 个 integration 装满,setup + 维护时间是每月 5-10 小时。对个人用户是负担,对团队需要专人维护。Integration 越多越需要 Ops 角色——这是 AI agent 时代的新工种。
2. Integration 失败时的"沉默错误"。Hermes 装 12 个 integration 后跑夜间 workflow,如果其中一个 integration 静默失败(Stripe API 限速、Reddit 改 schema、Obsidian 写冲突)——整个 workflow 可能半途而废,但你早上才看到。Agent observability 是 superagent 时代的核心问题——目前没有成熟方案,用户只能自己写 retry + alert。
结论
Hermes 的真正价值不是"Telegram 里能用 Claude"——这是表面。
Hermes 的真正价值是"装满 integrations 后的 agent"——它有 12 个感官、4 类工作能力、能在你睡觉时跑完 5-10 个 workflow。
装 2 个是 chatbot,装 12 个是 superagent——这是质变。
SOTA Sync 的判断:未来 12 个月,agent 工具的竞争会从"模型多强"转到"integration 多深"——MCP 兼容的 integration 数量会成为 superagent 的关键指标。装 100+ integration 的 platform(如 Hermes、Claude Desktop、Cursor)会成为新中心——用户不直接用模型,用的是"装满 integrations 后的 agent"。
但 integration 的运维成本是新基建——用户需要从"我装工具"思维转到"我养 agent"思维。这是 LLM 应用层最大的认知转移。