AI Agent on Zampo Blog

Hermes Kanban 实战：别再用聊天记录管理多 Agent 团队

Wed, 13 May 2026 15:36:00 +0800

你把任务卡创建好了，researcher、writer、coder 也都分配了。

然后什么都没发生。

这不是 bug。恰恰相反，这是 Hermes Kanban 最容易被误解、也最值得讲清楚的地方：创建 card，不等于启动 worker。

很多人把多 Agent 系统想得太像“开几个聊天窗口”。一个负责调研，一个负责写稿，一个负责代码，大家各干各的。听起来很美，真跑起来就会发现：谁先干？谁等谁？谁审核？交付物放哪？失败了谁接？

靠聊天记录和几个 Markdown 文件也能凑合跑。但只要任务链稍微长一点，协作就开始变脆。

Hermes Kanban 解决的不是“让 Agent 更聪明”。它解决的是另一个更工程的问题：

把 Agent 的工作，放进一条可追踪、可审核、可恢复的流水线里。

这篇不讲概念安利，只讲怎么用。

先记住一句话：Kanban 是任务系统，不是魔法按钮

Hermes Kanban 是一块持久化的任务板。你可以用它创建任务、分配 assignee、声明 parent/child 依赖、绑定 workspace、记录 comment、阻塞等待审核、完成后给下游传 handoff。

它适合管这种任务：

一个任务需要多个 profile 接力，比如 researcher → writer → default；
下游必须等上游交付后才能开始；
交付物必须有路径、有验证、有审核记录；
任务失败后不能靠人翻聊天记录猜状态；
你希望 worker 不只是“答一句”，而是按岗位技能执行。

它不适合管这种任务：

你只是问一句命令怎么写；
任务几分钟就能完成，没有上下游；
没有明确交付物，也不需要审核；
你还没把需求想清楚，只是随手丢一个念头。

这也是为什么 Hermes Kanban 的六列看板很重要。它不是装饰，它是任务生命周期。

六列可以这样理解：

列	含义	你该做什么
Triage	原始想法，还不是可执行任务	点 Specify，或用 `hermes kanban specify` 补成任务简报
Todo	任务已创建，但依赖未满足或还没分配	等 parent 完成，或补 assignee
Ready	已经可执行，等 dispatcher 或人工 claim	检查 gateway/dispatcher 是否在跑
In Progress	worker 已 claim，正在执行	看 heartbeat、runs、log
Blocked	等审核、等补料、或断路器触发	看 block reason，决定 unblock 还是打回
Done	任务完成	看 summary 和 metadata，给下游消费

不要小看这六列。多 Agent 协作最大的问题，不是 Agent 不会做事，而是状态没人管。

Agent 越会写代码，你越需要一块看板

Wed, 13 May 2026 12:25:00 +0800

你创建了 5 张 Agent 任务卡，以为系统会自动开干。

结果过了十分钟，什么也没发生。

不是模型不行，也不是任务拆得不够细。问题更尴尬：卡片创建，不等于任务执行。

这就是我这两天把文案线从 TASK_BOARD.md + inbox/active/done 文件流迁到 Hermes Kanban 时，最直接的体感。

以前我们用 Markdown 看板管 researcher、writer、coder。任务从 inbox 移到 active，再从 active 移到 done。听起来很朴素，也确实能跑。但一旦任务变多，问题马上冒出来：状态同步靠人记，交付物路径靠人写，谁能开始、谁在等审核、谁依赖谁，经常要翻半天聊天记录。

换成 Kanban 以后，事情并没有神奇地全自动。恰恰相反，我更清楚地看到一个事实：

Agent 越会干活，越需要一套严肃的任务面板。

多 Agent 的难点，已经不只是“让它写代码”。而是它写完之后，谁来审？失败之后，谁来接？上游没交齐素材，下游凭什么开工？任务卡完成了，交付物有没有真的落盘？

这才是 2026 年 Agent 工具真正开始分化的地方。

瓶颈换地方了

Vibe Kanban 的 README 里有一句话很准：Your Engineering Bottleneck Has Shifted。

过去，工程瓶颈在编码速度。

你有一个需求，开发者理解、写代码、调试、提 PR。AI 编码工具出现后，很多环节被加速了。Claude Code、Codex、Cursor Agent、Gemini CLI 这类工具，已经能承担相当一部分实现工作。

但加速之后，新的瓶颈露出来了。

不是没人写代码，而是没人稳定地规划、分发、审查、合并、回滚。

这也是为什么 Vibe Kanban 这种工具会火。它不是又一个聊天框，而是把编码 Agent 放进任务面板里：一个 issue 可以启动一个 agent workspace，配 git worktree、终端、预览和 diff review。人不再守着一个对话框等回答，而是像管理一组实习生一样管理 Agent。

别为了 Agent 而 Agent：2026 年多 Agent 工作流实战指南

Sat, 25 Apr 2026 10:00:00 +0800

一个团队花了两周，搭了三 Agent 流水线——研究员搜集数据、写作者整理报告、审核者把关质量。

跑起来之后发现：每次执行花 40 秒，API 账单涨了 3 倍，调试时根本不知道哪个 Agent 说了什么。

最后他们回到单 Agent，5 行代码解决了同样的问题。

这不是个例。2026 年，多 Agent 工作流成了 AI 圈最热的方向。但很多团队的问题不是不会搭多 Agent，而是根本不需要。

能单 Agent 解决的，别拆成三个。

如果你看完这篇，判断自己的场景确实需要多 Agent——这篇能帮你选对框架、跑通示例、避开坑。如果判断不需要——恭喜你，省了两周围绕三个 Agent 转的日子。

先判断：你到底需不需要？

Agent 越多，调试越难，成本越高。

该用的场景：

复杂多步骤工作流，有分支、循环、暂停恢复——单 Agent 写出来像意大利面
需要不同"角色"各司其职——研究员、写作者、审核者，每个角色的 system prompt 差异很大
需要人类在环审批——跑到一半暂停，等人确认后再继续
编码任务需要沙箱隔离——Agent 生成的代码不能直接在宿主机跑

不该用的场景：

简单问答/单步任务——引入多 Agent 是过度工程，直接用单 Agent 或 OpenAI API
高确定性流水线——对话式控制流不可预测，用传统状态机/工作流引擎
实时性要求高——LLM 调用延迟 + 多轮累积延迟，用缓存 + 异步处理
无 LLM 的纯规则引擎——不需要 LLM 能力，用 transitions、state_machine 等库
严格合规/审计——对话路径难以完全预测和审计，用确定性工作流引擎

一句话判断： 如果你的任务可以写成"输入 → 处理 → 输出"三步，别用多 Agent。如果需要分支、循环、多角色协作、人类审批，再考虑。

别一上来就折腾大平台了，QClaw v2 更适合你先把 AI 用起来

Sat, 11 Apr 2026 09:35:00 +0800

很多老板现在对 AI 工具最大的顾虑，不是贵，也不是不会用。

而是另一件更现实的事：你买回去，团队热闹两天，最后发现它只是个演示玩具。

能聊天，能写两段话，能给你看几个很唬人的 demo。真到了日常工作里，要么接不上流程，要么没人愿意学，要么装完就放着吃灰。

所以我看 QClaw v2，最在意的不是它又加了多少功能，也不是“腾讯出品”这四个字本身有多响。

我真正看重的是：它很适合拿来做一次低成本验证——如果你就是想先试试，AI 到底能不能真的进入团队日常，这东西比一上来就上大而全平台更轻。

Qwen3.6-Plus 爆火这一周，开发者先吵的不是它强不强

Fri, 10 Apr 2026 12:15:00 +0800

大家都在问：Qwen3.6-Plus 到底有没有超过 Claude？

说实话，这不是这次发布里最值得看的问题。真正该盯住的是另一件事：阿里这次发的，已经不只是一个“更强一点的 Qwen”，而是在把自己往 hosted agent model 的位置上推。1M context、agentic coding、多模态、preserve_thinking，这套词不是在卖聊天模型，是在抢开发者工作流。

Qwen3.6-Plus 这次最值得看的，不是谁赢了谁，而是阿里开始认真抢 hosted agent 这张桌子上的位置。

官方信息里，能确认的部分并不含糊。Qwen3.6-Plus 在 4 月 2 日正式发布，走的是托管 API 路线，不是开放权重模型；默认给到 1M context，主打 agentic coding 和多模态推理，还专门加了一个 preserve_thinking，明确就是冲着多步 agent 任务去的。单看这组信号，方向已经很清楚了：它想证明自己不是“Qwen 家族里又一个新型号”，而是一个更接近真实工程任务的工作模型。

问题在于，宣传口径和开发者真正关心的东西，从来不是一回事。

这次声量为什么大，我觉得有三个原因。第一，1M context 这种数字天生适合传播，哪怕很多人短期根本用不到。第二，agent coding 这几个字现在太敏感了，只要谁敢往这个方向喊，开发者都会看两眼。第三，也是最现实的一点：只要市场相信它有机会用更低成本去碰一线模型的活，哪怕还没坐实，试用流量就会先冲上来。

所以它爆火，不光是因为能力，也因为想象空间够大。

但第一波开发者反馈，很快就把想象空间拉回了地面。

最典型的争议，不是“它写代码到底比谁强 3 分还是 5 分”，而是 benchmark 口径。官方公开表格里，Qwen3.6-Plus 在 Terminal-Bench 2.0 上给出的分数是 61.6，高于表中 Claude Opus 4.5 的 59.3；在 SWE-bench Verified 上是 78.8，低于表中 Claude Opus 4.5 的 80.9。这个信息本身可以转述，但社区真正盯着看的不是数字漂亮不漂亮，而是：为什么拿 4.5 对比，不是更新的 4.6？

龙虾代运营月入 45 万？先算完这笔账再决定要不要入局

Tue, 07 Apr 2026 18:30:00 +0800

核心就一句话：当所有人都在讨论"怎么用 AI 赚钱"时，最先赚到钱的，永远是那群"教人怎么用 AI"的人。

昨天晚上，有个读者在后台问我：

“Zampo，现在入局龙虾代运营还来得及吗？”

我没直接回答，反问他一个问题：

“你知道装一个 OpenClaw，API 待命成本一天多少钱吗？”

他愣住了。

我又问：“你知道有多少人装了之后，发现每天啥也不干就要烧掉 20 美元吗？”

他不说话了。

这就是我今天要写这篇文章的原因。

最近"养龙虾"（部署 OpenClaw）火得一塌糊涂。淘宝有店家一个月卖出 3000 多单代安装服务，一单 300-500 块，月入三四十万。闲鱼上的兼职，上门装一次 450 块，一天一单就能月入过万。

AI 还没落地，卖铲子的人先赚到了钱。

但我想泼一盆冷水：在你决定入局之前，有些账必须先算清楚。

否则你不是去淘金，是去被收割。

OpenClaw 到底是什么

先说清楚，OpenClaw 到底是什么。

简单讲，它是一个能让你"用 AI 干活"的工具。

以前的 AI，你问它问题，它回答你。OpenClaw 不一样——它能接管你的电脑，自动帮你做事：

自动处理邮件
自动整理文件
自动运行代码
自动发布社交内容
自动采集数据
自动生成投研报告

从"对话智能"到"行动智能"，这是它爆红的核心原因。GitHub 星标不到三个月破 31 万，增长速度超越 Linux。

但问题也在这里。

这东西难装。要配 Node.js 环境，要装依赖，要连云端模型 API，要调环境变量，要处理报错。

对技术人员来说，这是周末花几小时的事。对非技术用户，这是一道跨不过去的坎。

有门槛，就有生意。 代运营出现了。

代运营怎么赚钱

代运营怎么赚钱？三类。

代部署

这是最直接的卖铲子。

服务类型	价格
远程部署	300-500 元/次
上门部署	450-600 元/次
海外标准化部署	$3,000-6,000
月度维护	$200-500/月

淘宝有店家月售 3000+ 单，收入 30-45 万。这是真金白银。

我为什么从 OpenClaw 切到了 Hermes：Agent 世界里，苹果正在赢安卓

Mon, 06 Apr 2026 11:01:15 +0800

最近不少朋友问我，为什么我把主力 Agent 从 OpenClaw 切到了 Hermes。

先说结论：不是 OpenClaw 不好。恰恰相反，OpenClaw 当初最打动我的地方，就是它够猛，够自由，够像一台你可以随便改、随便接、随便折腾的 Agent 引擎。它像安卓，开放、灵活、想象空间大。

但也正因为这样，它很容易一路从“强大”滑向“失控”。

而 Hermes 给我的感觉，是另一条路。它没那么野，但它更完整、更稳、更像一个真正可以长期用、敢交给它跑起来的产品。你可以把它理解成 Agent 世界里的苹果：边界更清晰，系统更收敛，很多能力不是没有，而是已经被整理好了，装进一个更可控的框架里。

这篇文章不是参数对比，也不是功能表。我想从一个真正在两边都用过的人视角，聊聊我为什么最后决定切到 Hermes。

Hermes 的启动页给我的第一感觉就是：系统边界很清楚，信息密度也很高。工具、技能、模型、工作目录，开场就摆在台面上。

OpenClaw 为什么一开始那么让人上头

如果你用过 OpenClaw，大概率能理解那种感觉。

它最吸引人的，不是“能聊天”，而是“能长成任何样子”。

你可以给它做多 agent 架构，可以自己拼工作流，可以接各种插件，可以把不同能力揉成一个有点疯狂、但也很有创造力的个人系统。那种感觉很像第一次认真玩安卓自动化：你会觉得，原来系统还能这么改。

OpenClaw 最强的一面，其实是它给了你一种“这个系统没有天花板”的感觉。

但问题也恰恰出在这里。

当一个系统足够自由，真正的成本不是“不会”，而是“会了之后越来越乱”。

你会开始遇到这些问题：

配置越来越多，但不确定哪些还在生效
插件越来越多，但不知道哪些是稳定资产，哪些是历史包袱
记忆、技能、工作目录、渠道配置互相牵扯
同一个 Agent 今天还像 A，明天又像 B
你以为自己在增强它，结果往往是在制造更多不可预测性

这不是 OpenClaw 独有的问题。所有高度开放的系统，走到后面都会遇到这个坎。

自由，本身就是一种管理负担。

我切换的真正原因，不是功能，而是“系统感”

很多人选 Agent 工具，第一反应是看功能表：谁支持更多模型，谁的浏览器能力更强，谁的插件更多，谁更容易魔改。

但我现在越来越觉得，决定一个 Agent 能不能长期用下去的，不是功能点，而是系统感。

什么叫系统感？

就是它有没有把这些核心问题想明白：

配置边界在哪里
记忆边界在哪里
会话边界在哪里
工作目录边界在哪里
技能是怎么积累、怎么维护、怎么避免腐烂的
网关、消息渠道、CLI、工作区之间到底怎么隔离

OpenClaw 更像一套你可以自己搭的 Agent 操作系统。它很强，但很多系统级规则要你自己补。

Hermes 则明显更像一套已经定义好秩序的产品。它不是不让你扩展，而是先把最重要的边界给你立起来。