一个 Agent 能干活，多个 Agent 配合能做成一条流水线。我这几个月试验了几种多 Agent 协作模式，讲三个最实用的，覆盖内容生产、代码开发、数据处理三大场景。每个模式都附完整配置思路和踩坑记录。

流水线模式：写审发一条龙

我的内容生产流水线分成三个 Agent：写手 Agent 负责生成初稿。给它一个主题和风格要求，它产出 2000 字的初稿。审稿 Agent 负责挑错。读初稿，挑出事实错误、逻辑漏洞、表达生硬的地方，写修改建议。发布 Agent 负责最终处理。根据审稿意见修改后，调用发布接口上线，同时把文章分类归档到后台。

三个 Agent 通过 JSON 文件传递中间产物。写手写完存到 drafts/title.json，审稿读到这个文件后写建议追加到同文件，发布读取最终版本后执行上线操作。每个环节独立运行，互不干扰。我之前试过在一个 Agent 里做全部三件事——它经常做一半忘了一半。拆开之后就再没出过这种问题。

具体用 Hermes 实现这种流水线，我会建三个不同的技能文件。第一个是写作技能，第二个是审稿技能，第三个是发布技能。然后写一个简单的 Shell 脚本按顺序调用三个技能。如果想全自动，甚至可以加一个 cron 定时——每天上午写作、下午审稿、晚上发布。我在独立站上用这个模式跑了两个月，每周 5 篇内容零人工干预。偶尔需要调整一下审稿的严格程度，其他时候完全自动化。

分工模式：各自干各自擅长的事

一个 Agent 不可能什么都会。有的擅长编程、有的擅长写作、有的擅长数据分析。分工模式就是让每个 Agent 只做自己最擅长的事。比如你要写一份数据分析报告：数据助手 Agent 跑 SQL 查询数据库，拿到原始数据存成 CSV。分析师 Agent 读 CSV，做统计分析和图表，写成分析报告草稿。编辑 Agent 把分析报告润色成可读的自然语言，配上格式化表格。汇总 Agent 把几个编辑的成果合并成最终文档。

这么分工的好处是每步质量都高。让编程 Agent 去写分析报告就是灾难——它给的结论准确但没人看得懂。让编辑 Agent 去写 SQL 更是灾难——语法错误跑不通。各自干擅长的事，最后拼起来就完美。我用这个模式做过一次竞品分析，三个 Agent 各司其职，一个小时出了 20 页的报告。我自己做至少需要三天。

这种模式的关键是定义好接口。前一个 Agent 的输出格式必须和后一个 Agent 的输入格式一致。我统一用 JSON 格式传递数据，结构在最开始就定好。比如数据助手必须输出包含 columns 和 rows 两个字段的 JSON，分析师读到这个结构直接处理不用再解析。定义接口这个环节其实是最费脑子的，但它决定了整个工作流能跑多顺。

监督模式：让 Agent 互相检查

这是我解决 Agent 输出质量不稳的方法。一个 Agent 干活，另一个 Agent 检查。干活 Agent 完成输出后调用检查 Agent 做质量评估，评分低于阈值就触发修改。写代码时特别管用——干活 Agent 写完函数后自动跑代码审查和单元测试，测试通过才算完成。

我第一次试监督模式出了一个低级 bug：干活 Agent 发现检查没过改了一版。检查 Agent 收到新版后说还是没过，改了要求。干活 Agent 按新要求再改，检查 Agent 又说方向不对。两个 Agent 互相绕着改最多改了 47 轮，最后我手动停了。后来加了终止条件：检查 Agent 每轮只提最重要的一个修改意见，最多改 3 轮。超过 3 轮未通过就人工介入。这条规则加上去之后再没出过超长循环。

三个模式的共同原则：每个 Agent 只做一件事。职责边界一定要清晰。以文件或消息作为可靠传递媒介而不是靠上下文共享信息。定义好退出条件防止死循环或无限改进。只要遵循这三条原则，多 Agent 协作的稳定性会远超单 Agent 的极限。我目前的生产线里单 Agent 只能处理简单任务，而三 Agent 协作能完成需要多步骤配合的复杂工作流。这是质的提升，不是量级的区别。