谈谈多Agent并发与Openclaw

B站最近流行这样一个东西——“AI 工作流”：把一个写文案的活，拆成“策划 Agent → 写作 Agent → 润色 Agent → 审核 Agent”，一个人操控一个团队，着实是做爽了老板瘾。

问题来了，这样做真的高效吗？真正让我想通的，不是某个教程，而是我自己搭一套系统时发生的取舍。

我一开始本来打算用 OpenClaw 调度 Codex、Claude Code、Grok 组个团队协作，后来放弃了。

多 Agent 真正贵在哪

开一个子 Agent，要把足量的上下文灌输进去，每个 Agent 都得重新加载指令，跑完再把结果汇总回主 Agent。这些是重复开销，任务越碎，“灌上下文”占比越高。

多个 agent 开会，纯浪费。

先把单 Agent + Tools 用到极限，再考虑拆多 Agent。简单、可组合的 workflow，通常比复杂 Agent 框架可靠。5 个 Agent × 重复读取项目上下文 × 互相解释 × 交接 × 总结 × 反思 = Token 火葬场。

但浪费不是绝对的。任务能真正并行时，多 Agent 反而省——比如同时查十份资料，子 Agent 各查各的，互不打扰，最后只汇总结论，避免主会话上下文越滚越大。

所以判断标准就一条：拆开之后，每个子任务是不是真的独立、有没有各自的上下文需求？如果拆完大家看的还是同一份材料、干的还是同一件事，那就是纯杂技，单 Agent 一把梭更划算。

我的服务器只有 2G 内存，部署着两个 Java 服务和一个静态博客，装不下 Uptime Kuma 这类监控面板。

一个探活脚本每十分钟访问三个公网地址，全绿就静默，有服务挂了就退出码 1。探到异常时，OpenClaw 才被唤醒——自动 SSH 上服务器查 systemctl status 和 journalctl，把“哪个服务挂了、可能原因、建议”发到微信。

关键点：监控的采集是脚本做的，不是 AI。 AI 只做“收到告警后判断该看什么、怎么解释”。平时零 token 消耗，只在出事时才动用智能，响应也快一个数量级。

博客是 Astro 静态站。以前发文章要手动 SSH 上传，现在用 GitHub Actions：push 到 main 分支，自动构建、SSH 上传、原子切换服务器目录。整个发布是确定性的，构建绿了就上线，红了就失败，没有中间地带。

这一步我没让任何 Agent 掺和。部署是“规则明确、可验证”的活，交给工具比交给 AI 可靠得多。AI 在这里唯一的角色，是构建失败时读日志、定位原因。

写作这块我反而让 AI 参与得多一点，但边界很清晰。日常记录随手追加进日志文件（几乎零成本），只有当我明确说“整理成文”时，AI 才把零散日志提炼成结构化草稿。写作本身是我的活，AI 只帮忙把素材从碎片变成提纲。

这条链是：想到什么十秒钟记下来 → 定期让 AI 整理成草稿 → 我在编辑器里打磨 → push 自动上线。

不再追求“几个角色开会”，而是让 OpenClaw：

最重、最确定的活，交给传统工具：部署给 CI，监控采集给探活脚本，AI 只做决策和解读。

这套跑起来之后，AI 的角色回归到它该在的位置：记录、整理、改写、发布，而不是掌控整个系统。想到东西十秒钟能记下来，想发博客几分钟能整理，代码 push 后自己上线。这比再加五个 AI Agent 提升大得多。

我至今没搞 CEO Agent，也没上十几个角色。原因很简单：那些是表演，而我要的是能把一件事真正做完的系统。