36 小时前，一切从这里开始。
我已经做了 9 年的增长实验：增长黑客、分发、转化优化。循环永远是同一个：提出假设、测试、衡量、保留或砍掉、重复。
问题从来不在点子，而在速度。一个人类团队一周也许只能跑 2–5 个实验。你大多数时间都花在协调上，而不是执行上。研究不跟数据分析互通。写作者不知道上周什么有效。上下文活在人的脑子里，最后死在 Slack 线程里。
我试过用 AI agents 来修这个问题。试过 OpenClaw。试过带工具调用的独立 agents。试过整套“AI 员工”的玩法。
它总是因为同一个原因而失败。
没有团队的 agent，不过就是一个没有上下文的 prompt。
没人会雇一个没有研究团队、没有数据分析、没有战略、没有反馈回路的写作者。你不会雇个体。你会搭团队。
所以我就这么做了。
teams/growth/ ← live now
teams/trading/ ← next
teams/influencer/ ← planned
teams/your-team/ ← you tell me
我搭了什么
一个 swarm 框架，让多个 agent 像一个团队一样协同工作。每个 agent 都有自己的角色、工具、MCP 访问、专用 LLM 模型，以及上下文窗口。它们共享知识、交接工作，并从彼此的结果里学习。
hermes 位于上层，充当操作中枢。它能控制 swarm、覆写动作、委派任务，而且它会从底下的 agents 身上学习。hermes + swarm 会一起变得更聪明。
┌────────────────┐
│ HERMES │
│ (operator) │
└───────┬────────┘
│
┌───────▼────────┐
│ ORCHESTRATOR │
└──┬──────────┬───┘
│ │
┌──────────────────▼──┐ ┌────▼───────────────────────┐
│ PHASE 1: PLAN │ │ PHASE 2: EXECUTE │
│ (sequential) │ │ (parallel, after approval) │
│ │ │ │
│ research → plan │ │ writers · designers · │
│ → approve/reject │ │ video · newsletter · │
└─────────────────────┘ │ repurpose │
└─────────────────────────────┘
┌─────────────────────────────────────────────┐
│ SHARED LAYER │
│ knowledge store · model router · │
│ experiment engine · task management │
└─────────────────────────────────────────────┘
核心想法：一个文件夹 = 一个团队。
python
# experiment.py
VERDICT_THRESHOLD = 0.20 # 20% improvement = meaningful
def evaluate_experiment(self, experiment, results):
if len(results) < experiment.sample_size_needed:
return "running"
avg_metric = sum(r.metric_value for r in results) / len(results)
improvement = (avg_metric - experiment.baseline) / experiment.baseline
if improvement > self.VERDICT_THRESHOLD:
return "keep"
elif improvement < -self.VERDICT_THRESHOLD:
return "discard"
else:
return "inconclusive"
建一个文件夹，写好配置，启动引擎。就这样。
为什么是 Hermes，而不是 OpenClaw？
我说实话。从纸面上看，这两个很像：都是持久化 agents；都有 SOUL.md；都有 skills、cron、memory、多平台消息、MCP；也都能自托管。
我们大概都试过 openclaw，对吧？有人爱它，有人恨它。
但这就是我切换的原因。
Python vs Node。
openclaw 是 node/JS。hermes 是 python。做 ML/AI 基础设施——多模型路由、实验闭环、知识库、异步编排——python 才是原生栈。我需要的库（httpx、asyncio、apscheduler、必要时还有 numpy）基本都是 pip install 一步到位。在 node runtime 之上搭我的引擎，意味着每一步都要跟生态较劲。光这一点就占了我决策的 60%。
执行沙盒。
openclaw 跑在一个绑定 localhost 的 node 进程里。hermes 给你五种执行后端：local、docker、SSH、singularity、modal。容器加固包括：只读根文件系统、丢弃 capabilities、命名空间隔离。当你在 VPS 上跑 30+ 个带工具权限的 agents——能写文件、能调 API、还能执行代码——这道差距很关键。hermes 把沙盒当作核心基础设施，而不是事后补丁。
子代理隔离。
hermes 会生成彼此隔离的 subagents：各自有对话、终端，以及 python RPC 脚本。上下文成本为零——子代理在跑时，父级不会丢上下文。openclaw 也有多代理路由，但它是会话级隔离，不是执行级隔离。当我的增长负责人要并行把调研委派给三个写手时，hermes 原生就能搞定，而且不会污染任何上下文窗口。
记忆架构。
openclaw 的 memory 是基于文件的 markdown（对话日志 + 精选长期记忆）。单代理用起来没问题。但它默认在重启时会清空 working memory——有个已知问题：人们会因为静默压缩而丢掉好几天的 agent 上下文。hermes 有持久化记忆 + 自动生成、重启后也能保留的 skills。再加上我的 QMD 知识库（BM25 + 向量 + LLM 重排），整体记忆架构就是：hermes 记得怎么操作 + QMD 记得团队学到了什么。两层，都是持久化的。
SOUL.md：同一个概念，不同的执行方式。
两边都有 SOUL.md。但 hermes 每条消息都会重新加载它。我凌晨两点更新 swarm roster，hermes 下一次交互就能读到。无需重启、无需重新编译、无需处理缓存失效。openclaw 的某些配置变更需要重启进程。当你在迭代一个由 11 个 agents 组成的 swarm 时，热重载不是锦上添花——它是你保持理智的方式。
研究与 RL 管线。
hermes 支持批量轨迹生成：并行 workers、checkpointing，以及与 Atropos 的 RL 训练集成；还支持 ShareGPT 导出用于微调。这是 NousResearch 的 DNA——他们做的是训练基础设施。如果你希望你的 operator 最终能用你自己的任务数据做微调，hermes 有这条 pipeline；openclaw 没有。
诚实的取舍。
openclaw 的面向消费者的 UX 更好，生态更大；就目前而言，它对个人助理用例打磨得更完善。
但我不是只在做一个个人助理。我在做的是一台引擎：在 5 个模型之上编排近乎无限数量的专用 agents，带实验闭环和共享知识库。为此，hermes 的 python 栈、执行隔离、以及研究管线才是关键。
hermes 是 operator。swarm 是团队。你和 hermes 对话，hermes 协调底下的一切。
引擎：它实际上是怎么跑的
每天两阶段循环：暂时如此。
phase 1 每天早上自动运行。research analyst 扫描，growth lead 选角度并分配工作。然后它停下来等你。 你喝着咖啡，通过 telegram 审批。
phase 2 点火——写手并行执行，视觉素材被生成，所有东西都保存进知识库。
你是被设计成的瓶颈。直到你足够信任它，愿意把 auto_approve=True 打开。
karpathy 模式（QMD + program.md）
这是最重要的部分。
我把 karpathy 的 autoresearch loop——他用来做自动化 ML 研究的模式——应用到了增长上。
每个 agent 都有三个文件：
-
program.md-- 不可变的目标 + 单一北极星指标 -
strategy.md-- 会随结果演化的“可编辑内容” -
results.tsv-- 只追加的实验日志
循环是这样：agent 读它当前的 strategy，提出一个实验，执行，衡量结果。指标提升了？保留这次 strategy 的改动。没提升？回滚，记录失败，再试别的。
这正是 QMD 发光的地方。每一份产物——研究扫描、内容草稿、性能数据、实验结论、策略决策——都会被保存进一个共享知识库。QMD 用混合检索（BM25 + 向量 + LLM 重排）为它建立索引。本地运行。
当任何一个 agent 运行时，它看到的不只是自己的历史。它还能看到团队里其他所有 agent 产出的东西：
swarm 变聪明不是因为模型变强了，而是因为策略会一步步棘轮式锁定进步。第 1 天将是它此后最糟的一天。
为什么这对增长尤其重要：手动跑了 9 年实验之后，我知道瓶颈从来不是“我们没有点子”，而是“我们从自己已经试过的东西里学得不够快”。这种架构让每一次实验的结果，都会永久地对每一个 agent 可用。
多模型路由
不是每个任务都需要 claude。把每类任务路由到能胜任的最便宜模型，成本就能从几百降到个位数。
当你把它们路由到合适的任务上时，小模型能做出大模型 2–3 倍的产出。mistral nemo 以 $0.02/M 做路由与结构化。qwen 以 $0.26/M 做创意写作。只有会产生级联影响的决策，才调用 claude。
11 个 agents 的一次完整循环：$0.009。但现实里我认为，一旦为质量做过 fine tuned，数字会跳高一些。但依然很便宜。
它如何嵌入真实工作流
这不是玩具。它能接入团队真正的工作方式。
swarm 可以和 ClickUp（或 Notion，或你用的任何 PM 工具）集成。交付物会落到那里。如果没有分配任务，agents 就去做自己的工作——调研、实验、优化，朝着你为它们设定的北极星指标前进。如果有紧急事情进来，你通过 hermes（telegram、slack、CLI）分配，它会把任务委派给 swarm 里合适的 agent。
随着时间推移，你会在团队上构建一张社交图谱。hermes + swarm 会更懂这些 agents，更懂什么有效，一起变聪明。
你能搭哪些团队？
引擎不关心团队做什么。它只关心：agents、tools、metrics、experiments。
-
增长团队（现在正在跑的）
-
内容 swarm
-
战略 swarm
-
AI influencer 团队
-
discord / 社区运营 swarm
-
工程团队
-
量化交易 swarm
-
任何你能想象的东西
归根结底，就是对 swarms 做 finetuning，并通过实验循环训练它们。写好配置，定义北极星指标，让 autoresearch 模式发挥作用。
诚实地谈谈 agents
我想说一句，在 AI agent 圈子里没人愿意说的话。
如果你一直在用 AI agents 搭东西……你知道它们真实是什么样的。不是内容农场描述的那样，不是“完全自治”的幻想，而是现实。
agents 还做不到把复杂工作从头到尾 100% 完成。不是今天。要我说，如果你期待一个架构良好的 swarm 承担 50–75% 的重活，这是现实的。随着模型与工具继续进步，也许我们会走向 100%。但现在，假装已经到了那一步，就是不诚实。
95% 的人用 AI。也许只有 5% 能从中看到真实、可叠加的结果。
我想回答的问题是：怎么把这个数字往上推？怎么从“只有 5% 看到真实结果”，走到 10%、15%、20%？
我的赌注是：不在更好的模型，而在更好的架构。协同。共享上下文。实验闭环。会学习、也不放弃的团队。
所有人都在解“让单个 agent 更聪明”。我认为杠杆在于：让 agents 一起工作，并且从彼此身上学习。
现在能跑的和还不能跑的
这是一个为 hackathon 做的两天冲刺。我会坦白说清楚：什么能跑，什么不能。
端到端跑通：
-
两阶段循环的 orchestrator（research、plan、approve、execute）
-
多模型路由器（通过 openrouter 调用 5 个模型）
-
research analyst（perplexity + DeFi 数据丰富 + 结构化）
-
growth lead（通过 claude sonnet 做战略规划）
-
linkedin writer + twitter writer（qwen 3.5 plus）
-
含 7 个 QMD collections 的知识库
-
19 个 MCP tools 接入 hermes（stdio + HTTP）
-
通过 telegram / slack 的审批流
-
ClickUp 集成用于任务管理
还需要更多工作：
-
experiment ratcheting（基础设施已接好，需要 30+ 个 cycles 才有真实数据）
-
升级单个 agent 的 skill、tools 和 models。
架构是真的。协作能跑起来。引擎在跑。我会花更多时间打磨它，把它做成 production-ready，再公开分享。
这是个大工程。
更大的图景
这段旅程起点，是想给我工作里的团队做点东西。然后我意识到：这个模式是通用的。
如果你的北极星指标是 X，swarm 就会持续为它优化。从错误中学习。跨 agent 共享上下文与经验。每一次循环、每一个实验、每一次失败，都会让下一次跑得更好。
agent 时代的重点，不是造出更强的单个 agent，而是造出能协同、能学习、能复利的团队。
teams/rabin/
├── program.md # mission + constraints + voice rules
├── brand-kit.md # brand identity for writers
├── agents/
│ ├── research-analyst/
│ │ └── config.json # model, tools, metric, schedule, lenses
│ ├── growth-lead/
│ ├── linkedin-writer/
│ ├── twitter-writer/
│ ├── visual-designer/
│ ├── analytics-agent/
│ └── ...11 agents
└── results/
└── [agent-id]/
├── strategy.md # evolves over time
└── results.tsv # experiment log
同一个引擎，不同的配置。一个会随你成长的 swarm。
自托管。基于 @NousResearch @Teknium 的 hermes + 由 @tobi 实现的 QMD + @karpathy 的 autoresearch 模式。
重要的是引擎。重要的是 MCPs。重要的是实验闭环。
去自己搭一个；不然就等我把 repo 公开并开源。
gg
