一个 Agent 能干活，多个 Agent 配合能做成一条流水线。我这几个月试验了几种多 Agent 协作模式，讲三个最实用的，覆盖内容生产、代码开发、数据处理三大场景。每个模式都附完整配置思路和踩坑记录。
流水线模式：写审发一条龙
我的内容生产流水线分成三个 Agent：写手 Agent、审稿 Agent、发布 Agent。
写手 Agent 负责生成初稿。给它一个主题和风格要求，调用大模型的 API 产出 2000 字左右的初稿并加上标题 SEO 关键词。注意 prompt 里一定要指定输出格式，不然每篇结构都不一样，下游审稿 Agent 没法处理。
审稿 Agent 负责挑错。读初稿，挑出事实错误、逻辑漏洞、表达生硬的地方，写修改建议。我之前给审稿 Agent 的 prompt 太宽松了，它经常说"写得很好没什么问题"。后来改成硬性要求——每篇必须找出至少三条可优化点，不管写得多好。质量立刻提高了一截。
发布 Agent 负责最终处理。根据审稿意见调用大模型修改后，再调用发布接口上线，同时把文章分类归档到后台数据库里。
三个 Agent 通过 JSON 文件传递中间产物。写手写完存到 drafts/title.json，审稿读到这个文件后写建议追加到同文件，发布读取最终版本后执行上线操作。每个环节独立运行，互不干扰。我之前试过在一个 Agent 里做全部三件事——它经常做一半忘了一半。拆开之后就再没出过这种问题。
具体用 Hermes 实现这种流水线，我会建三个不同的技能文件。第一个是写作技能，第二个是审稿技能，第三个是发布技能。然后写一个简单的 Shell 脚本按顺序调用三个技能：
#!/bin/bash
# 日常内容流水线
hermes run skill:writer "topic=$1"
hermes run skill:reviewer "draft=content.json"
hermes run skill:publisher "final=content.json"
如果想全自动，加一个 cron 定时——每天上午写作、下午审稿、晚上发布。我在独立站上用这个模式跑了两个月，每周 5 篇内容零人工干预。偶尔需要调整一下审稿的严格程度，其他时候完全自动化。
分工模式：各自干各自擅长的事
一个 Agent 不可能什么都会。有的擅长编程、有的擅长写作、有的擅长数据分析。分工模式就是让每个 Agent 只做自己最擅长的事。
比如你要写一份数据分析报告，可以拆成四个步骤：
- 数据助手 Agent：跑 SQL 查询数据库，拿到原始数据存成 CSV。它不需要懂业务，只需要知道表和字段名。
- 分析师 Agent：读 CSV，做统计分析和图表，写成分析报告草稿。它不需要知道数据怎么来的，只需要会算数。
- 编辑 Agent：把分析报告润色成可读的自然语言，配上格式化表格。它不需要验证数据正确性，只需要写得好读。
- 汇总 Agent：把几个编辑的成果合并成最终文档，加上目录和摘要。
这么分工的好处是每步质量都高。让编程 Agent 去写分析报告就是灾难——它给的结论准确但没人看得懂。让编辑 Agent 去写 SQL 更是灾难——语法错误跑不通。各自干擅长的事，最后拼起来就完美。
我用这个模式做过一次竞品分析。三个 Agent 各司其职：爬虫 Agent 抓了二十个竞品页面的数据，分析师 Agent 做了定价、功能、评分的对比矩阵，编辑 Agent 写了三页的分析文档。一个小时出了 20 页的报告。我自己做至少需要三天，而且大概率只做了数据整理这一步，写报告还得再花一天。
这种模式的关键是定义好接口。前一个 Agent 的输出格式必须和后一个 Agent 的输入格式一致。我统一用 JSON 格式传递数据，结构在最开始就定好。比如数据助手必须输出包含 columns 和 rows 两个字段的 JSON：
{
"metadata": {"source": "db", "query_time": "2026-07-09"},
"columns": ["产品", "月活", "定价模式", "评分"],
"rows": [
["产品A", 120000, "订阅制", 4.5],
["产品B", 87000, "免费增值", 4.2]
]
}
分析师读到这个结构直接处理不用再解析。定义接口这个环节其实是最费脑子的，但它决定了整个工作流能跑多顺。我早期踩过坑：两个 Agent 的 time 字段格式不一致，一个用 ISO 8601、一个用 Unix 时间戳，跑了两天才发现数据处理一直不对。
监督模式：让 Agent 互相检查
这是我解决 Agent 输出质量不稳的方法。一个 Agent 干活，另一个 Agent 检查。干活 Agent 完成输出后调用检查 Agent 做质量评估，评分低于阈值就触发修改。写代码时特别管用——干活 Agent 写完函数后自动跑代码审查和单元测试，测试通过才算完成。
我举一个具体的例子。我让 Agent A 写一个 Python 爬虫，Agent B 做代码审查。Agent A 写完第一版后 Agent B 检查发现没有异常处理，打了 60 分。Agent A 加上了 try-except 和重试逻辑，Agent B 给了 80 分。Agent A 又加了日志记录和限速机制，Agent B 给了 92 分，超过 85 分的阈值，自动通过。整个过程没人参与，但最后产出的代码质量比我手写还高。
但监督模式也不是完美无缺的。我第一次试的时候出了一个低级 bug：干活 Agent 发现检查没过改了一版。检查 Agent 收到新版后说还是没过，改了要求。干活 Agent 按新要求再改，检查 Agent 又说方向不对。两个 Agent 互相绕着改，最多改了 47 轮，最后我手动停了。
后来我加了三个硬性终止条件：
- 检查 Agent 每轮只提一个最重要的修改意见（不是全部问题一次性扔出来）
- 最多改 3 轮，超过 3 轮未通过就人工介入
- 每轮修改后必须重新跑全部测试，不能只测改过的地方
这条规则加上去之后再没出过超长循环。最极端的情况是被人工介入过两次，每次都是边界情况——干活 Agent 和检查 Agent 对需求理解有根本分歧，不是代码本身的问题。这时候人工看一眼就能判断。
三个模式怎么选
根据我的实践经验：
- 内容生产和发布：用流水线模式，每步固定顺序，上下游关系清晰
- 数据分析、报告、调研：用分工模式，每步需要不同的专业技能
- 代码开发、技术方案：用监督模式，质量优先、自动纠错
很多人问能不能三个模式混用。完全可以。我现在的生产系统就是这样：内容流水线是流水线模式里嵌了监督模式——写手写完自动过审稿 Agent 检查评分，低于阈值自动退回重写。两个模式叠加跑下来，半年就出过一次质量事故，还是因为那天 API 超时了。
踩坑汇总
最后列几个我踩过的坑，帮你避开：
- 职责边界一定要清晰。每个 Agent 只做一件事，别让写手去调 SQL。分工越细，排查问题越快。
- 用文件或消息作媒介。靠上下文共享信息是最不靠谱的——LLM 的上下文窗口有限，跑到第几步它自己都忘了。JSON 文件或者消息队列才是最稳的。
- 定义好退出条件。监督模式里不设轮数上限，两个 Agent 能聊到天荒地老。设定严格的终止门槛。
- 留人工介入通道。自动化再完善也需要人工兜底。我的习惯是每条流水线每周检查一次，跑偏了就微调 prompt。
- 日志要全。每步的输入输出都存日志。我之前排查一个 bug，翻日志才发现是第三步 Agent 把第二步的输出格式理解错了，改一下 prompt 就好。
只要遵循这三条原则——单职责、可靠媒介、退出条件清晰——多 Agent 协作的稳定性会远超单 Agent 的极限。我目前的生产线里单 Agent 只能处理简单任务，而三 Agent 协作能完成需要多步骤配合的复杂工作流。这是质的提升，不是量级的区别。