一个周末，我把日更文章交给了三个 AI

上个月，我一个做技术公众号的朋友老周找我诉苦。他一个人维护一个号，每周要产三篇原创，还得自己排版、配图、校对，说每天晚上十一点还在码字。他问我：有没有办法让 AI 不只帮我写，而是帮我管整个流程？我说有，你需要的不是单个聊天机器人，而是一套能分工协作的多 Agent 流水线。 那周我花了半天时间，用 Hermes 这个开源框架帮他搭好了一条内容生产线。现在他的流程是：Agent A 当天早上从行业新闻源里抓取热点，Agent B 根据热点生成选题和框架，Agent C 负责写初稿，Agent D 做事实核查和风格润色，最后他本人只花十五分钟审一遍、排版发布。从「周末全天耗进去」变成了「每天半小时」。今天我把这套搭建过程完整写出来，用的全部是真实命令和配置文件，你照着敲就能跑通。 我用的环境是 macOS 14.5，Python 3.11.4，Hermes 版本是 0.8.6。Hermes 最让我喜欢的是它不需要你去折腾复杂的编排平台，一切都在本地配置文件里搞定，够轻量。先给你看整体架构：我们有四个 Agent，分别承担「选题策划」「初稿创作」「编辑审核」「数据反馈」这四个环节，Agent 之间的消息通过 Hermes 自带的事件总线传递。 在开始之前，先安装 Hermes。注意它需要 Python 3.10 以上版本，建议用虚拟环境： ```bash python3 -m venv hermes-venv source hermes-venv/bin/activate pip install hermes-agent==0.8.6 ``` 装完后，第一次启动会用 `hermes init` 初始化目录结构，所有配置会生成在 `~/.hermes/` 下面。这里面最重要的两个东西：`config.yaml` 是全局配置，`skills/` 目录放每个 Agent 的技能脚本。

第一步：定义三个核心 Agent，让它们各司其职

打开 `~/.hermes/config.yaml`，你要在这里定义每个 Agent 的身份、模型参数和职责边界。别小看这一步——多 Agent 协作最容易翻车的点，就是 Agent 之间职责模糊，结果两个 Agent 同时去写初稿，或者互相覆盖对方的内容。 我建议你一开始只定义三个 Agent，跑通再加第四个。老周那套配置我简化了一下，核心内容长这样： ```yaml agents: researcher: model: "gpt-4o-mini" temperature: 0.3 system_prompt: "你是一个资深内容策划。你负责从新闻源中提炼3个今日热点，结合目标读者画像，输出选题列表。每个选题需包含：标题方向、核心论点、目标读者痛点。" skills: - fetch_news - keyword_analysis writer: model: "gpt-4o" temperature: 0.7 system_prompt: "你是一个科技自媒体作者。根据选题方案撰写1500字左右的初稿，要求逻辑清晰、有具体案例、口语化表达。不要使用'首先其次最后'这类连接词。" skills: - draft_writer editor: model: "gpt-4o" temperature: 0.2 system_prompt: "你是资深编辑。审校初稿，检查事实错误、逻辑漏洞、敏感词，并优化表达。输出最终版本，附上修改说明。" skills: - fact_check - style_optimize ``` 注意到 `temperature` 参数的区别了吗？research 和 editor 用低温度，保证输出稳定；writer 用 0.7，让它写出来的内容有变化、不死板。配置里的 `skills` 字段指向 `~/.hermes/skills/` 下的脚本文件，每个 skill 实际上就是一个 Python 或 Shell 脚本，负责执行特定的子任务。 配置文件写好后，用 `hermes agent test` 命令验证一下每个 Agent 是否能正常响应。这一步很重要，我一开始就吃过亏：research Agent 模型参数写错了，结果整个流水线到第三步就卡住。 验证通过后，用 `hermes skill add` 为每个 Agent 挂载对应的技能脚本。比如给 research 挂载「抓取 RSS 新闻源」的脚本： ```bash hermes skill add researcher fetch_news --script ~/.hermes/skills/fetch_news.py ``` 你的 `fetch_news.py` 里，本质上就是用 `feedparser` 库抓取几个科技新闻源的 RSS，把标题和链接汇总成结构化文本。Hermes 的 skill 机制不限制语言，写你想写的就行。

第二步：用 event bus 把 Agent 串成流水线

三个 Agent 定义好之后，你得解决一个核心问题：它们之间怎么传递消息？是让 researcher 直接把结果写到文件里，writer 再去读文件？还是用一个消息队列？Hermes 的答案是 event bus——事件总线。 在 `~/.hermes/config.yaml` 里，加一段 pipeline 配置： ```yaml pipeline: name: content_factory trigger: cron cron_schedule: "0 8 * * *" steps: - agent: researcher action: produce_topics output: event_topic "raw_topics" - agent: writer action: compose_draft input: event "raw_topics" output: event_topic "draft_created" - agent: editor action: review_and_finalize input: event "draft_created" output: event_topic "final_article" ``` 这段配置明确了一个链条：每天早上 8 点，researcher 先跑，产出选题列表后发到 `raw_topics` 这个事件主题；writer 收到该事件后开始写稿，完成后发到 `draft_created`；最后 editor 取到稿件，审校完发布到 `final_article`。这样的好处是解耦——你随时可以替换中间某一环的 Agent，不影响上下游。 这里有个小坑：配置里的事件名一定要确认拼写一致，否则 Agent 之间会「各聊各的」。我第一次就是把 `raw_topics` 写成了 `raw_topics_event`，结果 writer 那边一直等不到消息，整个流水线空转了十分钟。 如果你想先手动跑一次流程测试，不要等定时触发，用这个命令： ```bash hermes pipeline run content_factory --manual ``` Hermes 会依序执行三个 Agent，并在终端输出每一步的状态。当你看到 `[editor] produced final_article in 3.2s` 这样的日志，就说明整条链路通了。 通了之后，把你自己的角色加进去。我最喜欢的用法是：editor 完成后，自动把最终文章发到你的邮箱，或者推送到特定的 Slack 频道。在 Hermes 里，两种做法都行——你可以写一个 `notify` skill，在 pipeline 的末尾加一个对应动作。老周选了邮件，因为他不喜欢手机上多一个消息 App： ```yaml - agent: notifier action: send_email input: event "final_article" ``` `send_email` 脚本里就两行 SMTP 配置，把收件人设成老周自己的邮箱。跑起来后，他每天早上只要等邮件到了，打开复制到公众号后台排版发布就行。

第三步：每个 Agent 内部，skill 是怎么工作的

可能有读者会问：我这个 Agent 的 skill 到底是什么样子的？这很重要，因为 Hermes 的灵活性全靠这个机制。拿 `draft_writer` 这个 skill 举例，它在 `~/.hermes/skills/draft_writer.py` 里，核心逻辑非常简单：读取上游传过来的选题文件，拼好提示词，调用大模型接口。 但真正让它好用的，不是代码有多复杂，而是我们给模型的结构化输入。看这段实际代码： ```python import json import sys from hermes.sdk import llm_call def main(input_file): with open(input_file, "r", encoding="utf-8") as f: topics = json.load(f) prompt = f"""根据以下选题，写一篇完整文章。 需要遵循：标题直接准确、正文口语化、每个观点带具体案例、结尾提出一个开放问题。 选题信息：{topics} 请输出正文内容，不要输出任何前后缀说明。""" result = llm_call( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.7 ) # 这里故意让模型只输出正文，减少后续清理成本 print(result.strip()) ``` 这里有个细节：我们让模型的输出「不要任何前后缀说明」，这能避免大部分情况下 AI 给你来一句「好的，这是您要求的文章」导致的下游解析问题。另外用 `json.load` 解析上游的选题文件时，我会用一个技巧——让 researcher Agent 输出的选题不是纯文本，而是标准 JSON。这样可以大大减少解析异常。 我在 `fetch_news.py` 末尾会加一行：把处理完成的热点列表写到一个 JSON 文件里，这样 writer 端读取时格式永远是稳定的。 ```python with open("topics.json", "w") as f: json.dump(topics_list, f, ensure_ascii=False, indent=2) ``` Hermes 有个默认的上下文目录，放在 `~/.hermes/workspace/`，所有 skill 的临时文件都会放这里。你在调试时如果怀疑某个环节出了问题，直接去这个目录看有没有生成对应的中间文件就懂了——极大降低排查成本。

第四步：加上记忆和能力成长，让系统越用越顺手

很多人搭完流水线后就停手了，但我建议你加最后一个东西：记忆。Hermes 自带 `memory` 命令，作用是把每个 Agent 的运行历史和关键结论存下来，以后再次运行时可以参考。 你可能会想：「AI 不是有上下文窗口吗？为什么还需要额外记忆？」因为上下文窗口每次对话结束后就清空了，而 `hermes memory` 存的是长期数据。举个例子：老周运行了两周后，发现 researcher 每周五推荐的选题都比平时质量差。我们打开记忆看，发现周五的新闻源更新频率低，热门话题少。我们就把周五的触发时间从早上 8 点改到 9 点半，并让 researcher 在周五额外抓取一个「深度报道」的 RSS 源。这个优化的依据，就来自 `memory` 命令的记录。 具体操作： ```bash hermes memory list --agent researcher hermes memory add --agent researcher --key "friday_news_source" --value "https://example.com/analysis/rss" ``` 第一条命令查看 researcher 这边积累的历史总结，第二条命令写入一个经验值。这条经验会在 researcher 每次启动时自动加载到它的 system prompt 里。 另外，你还需要考虑模型调用成本。Hermes 支持按 Agent 设置不同的模型，像我刚才写的，researcher 用 `gpt-4o-mini`，便宜快速；writer 和 editor 用 `gpt-4o`，质量优先。跑一个月的实际成本，老周说每天花不到三块钱，这个数字他很满意。 如果你用本地模型，比如通过 Ollama 跑 `qwen2.5:14b`，也可以直接在配置里写： ```yaml model: "ollama/qwen2.5:14b" ``` Hermes 会自动把请求转发到本地的 `http://localhost:11434`。这适合对数据隐私有要求的人。

第五步：定时任务和异常处理——让它真正无人值守

流水线跑通后，最后一步是让它每天自动执行。上面配置里我用 `cron_schedule` 定了每天早八点，但 Hermes 还给你提供了一套更精细的命令行工具来管理定时任务。 首先，把流水线注册成一个 cron job： ```bash hermes cron create --name content_factory --schedule "0 8 * * *" --pipeline content_factory ``` 如果你不确定 cron 表达式怎么写，Hermes 支持一个友好的交互式参数，输入 `hermes cron create --interactive` 然后按提示选时间和频率，它会自动帮你转换。 无人值守最怕什么？最怕中途报错，然后系统停在那里不跑了。我会建议你在 config.yaml 里加个 `on_error` 配置： ```yaml pipeline: on_error: "telegram" telegram_chat_id: "123456789" ``` 意思是如果某一个 Agent 运行失败，Hermes 会往你的 Telegram 发一条消息，附上错误日志。它默认支持五种通知方式，`telegram`、`email`、`slack`、`webhook` 和 `log_only`。老周选了 email，因为他不想装 Telegram。 你还可以用 `hermes cron list` 查看所有已注册的任务，用 `hermes cron logs content_factory` 查看历史执行记录。我观察过，连续跑一周的稳定率在 90% 左右，偶尔因为上游 API 超时失败，重跑一次就恢复。你可以写一个简单的重试逻辑，在 pipeline 配置里加： ```yaml pipeline: max_retries: 2 retry_delay: 30 # 单位：秒 ``` 这样即使某个模型 API 偶尔抖动，也会自动重试两次。两条经验给我省了很多事：第一，所有外部 API 都设置超时时间，避免某个请求卡死整条链路；第二，每个 skill 脚本输出时增加一个时间戳，方便回溯。 跑起来了之后，你会发现真正该花精力的是持续调整提示词和 skill 脚本，去适配你自己的内容风格。多 Agent 流水线不是「建完就完事」的静态系统，它需要你像带新人一样，时不时给它反馈、调整节奏。 搭建整个内容生产流水线的核心就一句话：把内容生产拆成独立环节，每个环节用一个 Agent 负责，用事件总线串起来，用 crontab 定时跑。你不需要先学会 Kubernetes，不需要容器编排，你只需要一台上网的电脑和半小时配置时间。

💬 你用过哪些AI工具？

好啦，讲到这儿，我这个「老父亲」级别的流水线就全盘托出了。你最近有没有用过什么特别顺手的 AI 工具？或者你在自己的内容生产流程里踩过什么坑？我特别想知道你的想法——是像我一样搭了一套多 Agent 流水线，还是直接用 ChatGPT 一条道走到黑？ 如果你对 Hermes 这套方案感兴趣，建议先去 AI House 排行榜（aibunkhouse.com/rankings/）看看目前各家大模型的最新排名，里面各个模型实时跑分的反馈能帮你挑到最适合你流水线里那几环的模型——毕竟 research、writer、editor 各自对模型的要求差异还是挺大的。去给你喜欢的模型投一票，也让后来者少走点弯路。 如果这篇文章对你有帮助，欢迎在评论区分享你的使用体验，咱们一起把内容生产的效率卷到新高度。