引言
我现在越来越觉得，公众号内容生产本身就是一个很适合测试数字员工的真实场景。
因为它不是单纯“写一篇文章”这么简单。真正让我头疼的，往往是三件事混在一起：
资料要有人找。 文章要有人写。 质量要有人审。
以前我会把这三件事塞进一条提示词里：
请你先帮我调研，再帮我写一篇公众号文章，最后顺便自查一下质量。
这种写法看起来省事，实际很容易翻车。
研究和写作混在一起，模型会把“查到的资料”和“自己脑补的判断”揉在一段里。写作和审稿混在一起，它又很难真的打回自己刚写完的稿子。更麻烦的是，如果我想让不同岗位用不同模型，单个对话基本就不适合了。
所以这次我把第四篇的实验换成一个更贴近我们日常工作的版本：
用 Hermes profile 建三个长期员工，一个负责研究，一个负责写作，一个负责质量审计；再给它们分别配不同国产模型，让它们按文件交接，而不是在同一个对话里互相扮演。
这三个员工分别是：
researcher 研究员工，默认 Kimi articlewriter 写作员工，默认 GLM qualityauditor 审计员工，默认 DeepSeek
这次实验的具体目标也很明确：不是让它们随便写一篇文章，而是让它们一起生产一篇关于“内容生产线本身”的公众号草稿。
目标文章的标题先定为：
我用三个 Hermes 员工搭了一条公众号内容生产线：研究、写作、审计分开跑
这篇样稿要回答四个问题：
为什么一个提示词同时做研究、写作、审稿不够用？ Hermes profile 如何把临时角色变成长期员工？ Kimi / GLM / DeepSeek 三种模型如何分别承担研究、写作、审计？ 为什么审计员工必须能打回修改，而不是只说“写得不错”？
我给这次实验设了一个很具体的验收标准：
researcher 必须交资料包，里面要有公开来源链接和不确定点。 articlewriter 必须根据资料包和 style-guide 写草稿，不能自己扩展事实。 qualityauditor 必须按 audit-rubric 给分，列出硬规则、软评分和修改要求。 如果审计提出修改，articlewriter 必须再修一版。 最终发出来的教程里，命令、路径、模型名和输出必须由我用真实结果复核。
换句话说，这次实验不是“让 AI 写文章”这么泛，而是拿我们正在写的这类公众号教程当样品，测试一条可复用的内容生产流水线：先研究，再写作，再审计，再修订。
这次不是只写方案。我实际创建了 profile，绑定了默认模型，跑了最小响应测试，又让三位员工围绕这篇样稿完成了一轮“研究 -> 草稿 -> 审计 -> 修订”。
最终结果也很真实：
研究员工产出了资料包。 写作员工产出了初稿。 审计员工给初稿打了 86/100，并提出 5 条修改要求。 写作员工按审计意见修了一版。 我最后发现，写作员工会把终端输出写得很像真的，所以终稿必须由我替换成真实命令和真实输出。
这最后一点很重要。
数字员工可以帮我推进内容生产，但不能跳过主控验收。尤其是教程类文章，一旦命令输出是“写出来的”，不是“跑出来的”，读者照着做就会踩坑。
这次的流程是这样：
先说清楚：这不是自动化脚本，而是一套 Codex 维护的 SOP
这里有一个容易误会的地方。
我现在还没有写一个脚本，让它自动完成“研究 -> 写作 -> 审计 -> 修订”。也就是说，目前不存在一个 run-content-pipeline.ps1，点一下就把三位员工全部调度完。
这条流程现在真正的维护者，是 Windows 侧的 Codex SOP。
更准确地说：
我负责确定选题、判断文章是否值得做、决定最终能不能发布。 Codex 负责维护流程：拆任务、写 brief、限定边界、启动员工、检查 outbox、整理可复用结论。 Hermes profile 员工负责执行单点任务：研究、写作、审计。 文件系统负责保存状态：inbox 是任务，outbox 是原始结果，reports 是复盘资产。
所以这不是“全自动流水线”，而是“有 SOP 的半自动编辑部”。
这个区别很重要。
如果没有 Codex 维护 SOP，三个 Hermes 员工只是三个能干活的模型；它们不会自动知道下一步谁该接手，也不会自动判断写作员工的命令输出是不是真的。真正让它们变成团队的，是那套可复用的流程：谁先做、谁只能读什么、产物放哪里、谁可以打回、最后由谁验收。
后面这套 SOP 可以继续升级成脚本，比如：
run-content-pipeline.ps1 1. 启动 researcher 2. 等资料包落盘 3. 启动 articlewriter 4. 启动 qualityauditor 5. 如果审计结果是 REVISE，再启动 articlewriter 修订 6. 把本轮文件路径写进 reports
但在这一篇里，我不把它说成已经自动化完成。现在验证的是更底层的东西：三位长期员工能不能按 SOP 分工，能不能留下文件，能不能被 Codex 验收。
为什么这比“一个提示词写完”更像数字员工
“角色提示词”当然有用，但它更像临时开会。
你可以在同一个对话里说：
你现在是研究员。 你现在是写作者。 你现在是审稿人。
问题是，这三个人其实还是同一个上下文、同一个模型、同一套记忆。
研究员刚看过什么，写作者也看过。写作者刚写了什么，审稿人也带着同一段上下文去审。它会变得很“懂自己”，但不一定真的客观。
我这次想要的不是角色扮演，而是岗位分离：
researcher 只能交资料包，不写正文。 articlewriter 只能读资料包和风格规则，不自己扩展事实。 qualityauditor 只读草稿、风格规则和评分表，负责打分和打回。
这就像一个小编辑部。
研究员交资料，作者写初稿，审稿人挑问题。每个人都要留下文件，不能只在聊天里说“我完成了”。
所以我先在安全实验区准备了三份文件：
agent-lab-public/inbox/2026-06-20-content-pipeline-team-brief.md agent-lab-public/projects/content-pipeline-demo/style-guide.md agent-lab-public/projects/content-pipeline-demo/audit-rubric.md
任务单定义岗位和输出路径。
风格规则定义公众号文章的口吻：第一人称实践者视角，不解释幕后身份，不用生硬的商业话术，不虚构客户案例，要有真实命令、真实输出、诚实限制和可复用模板。
评分表则给审计员工用，分成硬规则和软评分。硬规则一旦触犯就必须打回；软评分满分 100，85 分以上才算可以进入人工润色。
这三份文件很普通，但它们让员工不是“随便发挥”，而是按同一套标准交活。
先创建三个长期员工
我先建 profile。
这一步不只是给对话起名字。Hermes 的 profile 是独立的工作目录，每个 profile 都有自己的配置、记忆、会话、skills 和状态。这样 researcher、articlewriter、qualityauditor 才能变成可反复调用的员工，而不是每次 prompt 里临时分配的角色。
创建命令是：
hermes profile create researcher --clone --description 'Content research employee for web search, source collection, evidence notes, and link-backed briefs for public articles.' hermes profile create articlewriter --clone --description 'Article writing employee for turning research briefs and style guides into practical first-person WeChat drafts.' hermes profile create qualityauditor --clone --description 'Content quality audit employee for hard-rule checks, soft scoring, factual risk review, and revision requests for article drafts.'
实际输出里可以看到它们都创建了独立 profile，并生成了 wrapper：
Profile 'researcher' created at /home/wangz/.hermes/profiles/researcher Wrapper created: /home/wangz/.local/bin/researcher Profile 'articlewriter' created at /home/wangz/.hermes/profiles/articlewriter Wrapper created: /home/wangz/.local/bin/articlewriter Profile 'qualityauditor' created at /home/wangz/.hermes/profiles/qualityauditor Wrapper created: /home/wangz/.local/bin/qualityauditor
这里我用了 --clone，让新员工继承当前可用的基础配置和 skills。
但有个边界要记住：clone 会把 .env 也复制到 profile 目录里，所以这些 profile 配置只能留在 WSL 的 Hermes home，不要放到文章资料包里，也不要交给外部模型。
再给三个员工换不同大脑
你前面说的“换个大脑”很对。
如果三个员工都用同一个模型，当然也能跑。但内容生产的三个岗位，对模型的要求并不完全一样：
研究员工：更需要资料整理、链接意识、结构化摘要。 写作员工：更需要中文表达、段落节奏、口吻贴合。 审计员工：更需要挑错、打分、规则执行和不怕得罪人。
这次 OpenRouter 已经重新配置好，所以我直接把默认模型写进各自 profile：
researcher config set model.default moonshotai/kimi-k2.7-code articlewriter config set model.default z-ai/glm-5.2 qualityauditor config set model.default deepseek/deepseek-v4-pro
命令返回：
✓ Set model.default = moonshotai/kimi-k2.7-code in /home/wangz/.hermes/profiles/researcher/config.yaml ✓ Set model.default = z-ai/glm-5.2 in /home/wangz/.hermes/profiles/articlewriter/config.yaml ✓ Set model.default = deepseek/deepseek-v4-pro in /home/wangz/.hermes/profiles/qualityauditor/config.yaml
再看 profile 列表：
Profile Model Alias articlewriter z-ai/glm-5.2 articlewriter qualityauditor deepseek/deepseek-v4-pro qualityauditor researcher moonshotai/kimi-k2.7-code researcher
这一步之后，它们就不只是“调用时临时换模型”，而是 profile 默认模型已经不同。
我又做了三次最小响应测试，不加 --provider，也不加 -m，直接调用 profile 默认模型：
researcher -z 'Reply with exactly: RESEARCHER_DEFAULT_KIMI_OK' articlewriter -z 'Reply with exactly: ARTICLEWRITER_DEFAULT_GLM_OK' qualityauditor -z 'Reply with exactly: QUALITYAUDITOR_DEFAULT_DEEPSEEK_OK'
返回结果是：
RESEARCHER_DEFAULT_KIMI_OK ARTICLEWRITER_DEFAULT_GLM_OK QUALITYAUDITOR_DEFAULT_DEEPSEEK_OK
这就说明三件事都跑通了：
profile 存在。 默认模型已经分别绑定。 OpenRouter 授权可用。
到这里，我才敢在文章里写“不同员工配不同模型”。如果只看文档说支持，但本地没跑通，就不能写成已验证能力。
第一位员工：researcher 只做资料包
我给 researcher 的任务很克制：只做研究，不写文章。
它读取了：
inbox/2026-06-20-content-pipeline-team-brief.md projects/content-pipeline-demo/style-guide.md
然后用公开搜索去查 Hermes profile 和 OpenRouter 的资料，最后写入：
agent-lab-public/outbox/2026-06-20-researcher-content-pipeline.md
实际返回里有这段：
Deliverable saved to: /mnt/c/your-workspace/ColumnCreation/agent-lab-public/outbox/2026-06-20-researcher-content-pipeline.md (14,765 bytes, 134 lines)
资料包里不是一篇文章，而是给写作员工用的素材：
公开来源链接 已核实事实 本地任务单里的事实 不确定点 给写作员工的 8 条建议
它查到的公开来源包括 Hermes profiles 文档、OpenRouter 的 Hermes 集成说明、OpenRouter 模型列表 API、Hermes GitHub 等。
我喜欢这一步的原因是，它把“资料”和“表达”拆开了。
研究员工不用考虑文章好不好看，只要回答：
来源是什么？ 哪些事实可以引用？ 哪些地方还不确定？ 写作员工必须注意什么？
这比让模型一边查一边写可靠得多。
尤其是“不确定点”这一栏很重要。比如 researcher 会明确说：OpenRouter 模型列表更新很快，具体模型 ID 不应该写死成永久可用；Hermes profile 的本地配置不能直接展示密钥文件；生产环境还需要考虑成本、限流和发布 API。
这些提醒会进入下一步，约束写作员工不要写过头。
第二位员工：articlewriter 写初稿，但不直接发布
写作员工读取的是 researcher 的资料包和 style guide。
它不需要自己去搜网页，也不应该越过资料包扩展事实。它的任务是把资料变成一篇可读的公众号草稿。
输出文件是：
agent-lab-public/outbox/2026-06-20-articlewriter-content-pipeline-draft.md
这一版草稿整体方向是对的：它用了第一人称实践口吻，讲清楚了为什么一个提示词不够，怎么拆成三个 profile，为什么审计员工很重要，也有文件路径和复用模板。
但我没有直接用它。
因为这一步暴露了 AI 写教程时一个很常见的问题：为了让文章更顺，它会把终端输出写成“演示效果”。
比如它会写出看起来很像真实命令回显的片段，但命令格式、模型名称、返回内容和我刚才实际跑的并不完全一致。
这件事非常危险。
公众号文章如果只是讲观点，文字顺一点没关系。但教程文章里的命令和输出必须是真的。读者照着敲的时候，差一个参数都可能卡住。
所以我给这类产物定了一个规则：
写作员工可以写叙事和结构。 命令、路径、模型名、返回结果必须由主控从真实日志替换。
这也是为什么你现在读到的这篇正文，不是直接复制 articlewriter 的修订稿，而是我把它的结构拆开以后，用真实实验证据重写了一遍。
第三位员工：qualityauditor 负责打分和打回
我最看重的是第三位员工。
没有审计员工，这条流水线就只是“研究 + 写作”。它也许能产出很多字，但质量上限不稳定。
qualityauditor 读取三份东西：
outbox/2026-06-20-articlewriter-content-pipeline-draft.md projects/content-pipeline-demo/style-guide.md projects/content-pipeline-demo/audit-rubric.md
然后输出审计报告：
agent-lab-public/outbox/2026-06-20-qualityauditor-content-pipeline-audit.md
审计结果是：
Score: 86/100 Decision: PASS
它没有发现 FAIL 级硬规则问题，但标出了两个边界问题：
命令有展示，但缺少真实终端输出支撑。 某个禁用表达即使出现在否定句里，也最好删除。
然后给了 5 条具体修改要求：
补充真实终端输出。 删除禁用表达。 压缩 profile 结构解释，适合手机阅读。 补上文件交接到独立审计之间的过渡。 加入 prompt-only 和 profile 员工的前后对比。
这才是审计员工的价值。
它不是说“写得不错，可以发布”。它会指出文章哪里还不够硬，哪里缺证据，哪里读者会觉得绕。
这次它虽然给了 PASS，但我仍然让 articlewriter 按意见修了一版。
修订稿保存到：
agent-lab-public/outbox/2026-06-20-articlewriter-content-pipeline-revised.md
修订后，写作员工自己汇报：禁用表达已经移除，三条模型自检标记已经补充，审计分数已经写入，前后对比也加上了。
不过就像前面说的，修订稿里的“终端片段”仍然要经过人工验收。审计员工可以发现“缺证据”，但它不一定知道哪些证据是真的。
所以最后还需要 Codex 和我一起做终审：保留结构，替换事实。
这条流水线真正解决了什么
这次实验跑完以后，我觉得这个选题成立。
原因很简单：它不是为了展示 Agent 而临时捏一个场景，而是在拆解我们正在做的工作。
我们不是为了展示 Agent 而捏造一个业务场景，而是在把自己的公众号生产流程拆给数字员工：
我提出选题和边界。 Codex 帮我拆任务、看风险、验收文件。 researcher 用 Kimi 查资料，交资料包。 articlewriter 用 GLM 写草稿。 qualityauditor 用 DeepSeek 按规则审稿。 我再做最终判断，把真实命令和真实输出补进去。
这比单纯说“Agent 可以帮你写文章”具体得多。
更重要的是，它能持续积累。
每次跑完，都会留下这些文件：
brief.md style-guide.md audit-rubric.md research packet draft audit report revised draft final article
下一篇文章不是从零开始，而是复用上一轮的风格规则、审计规则和任务单。
这就是我理解的数字资产：不是某篇文章本身，而是这套可以反复跑、反复改进的流程。
你可以照着做的最小版本
如果你也想搭一个最小版，不需要一开始就弄很多模型。
先准备这几个目录：
agent-lab-public/ inbox/ projects/content-pipeline-demo/ outbox/ reports/
再准备三份文件：
inbox/content-brief.md projects/content-pipeline-demo/style-guide.md projects/content-pipeline-demo/audit-rubric.md
然后创建三个 profile：
hermes profile create researcher --clone --description 'Research employee for source-backed article briefs.' hermes profile create articlewriter --clone --description 'Writing employee for WeChat article drafts.' hermes profile create qualityauditor --clone --description 'Quality audit employee for scoring and revision requests.'
如果你有 OpenRouter，也可以给它们绑定不同模型：
researcher config set model.default moonshotai/kimi-k2.7-code articlewriter config set model.default z-ai/glm-5.2 qualityauditor config set model.default deepseek/deepseek-v4-pro
先做最小响应测试：
researcher -z 'Reply with exactly: RESEARCHER_OK' articlewriter -z 'Reply with exactly: WRITER_OK' qualityauditor -z 'Reply with exactly: AUDITOR_OK'
确认能跑，再开始派工。
派工时记得三条规则：
研究员工不写正文。 写作员工不自己扩展事实。 审计员工必须能打回修改。
这样跑出来的结果才不会变成一个大模型从头写到尾，而是真的像一个小团队在交接。
这次实验的限制
第一，这还不是完整的公众号自动发布系统。
现在它只做到 markdown 草稿，不负责配图、排版、预览、发布和数据回收。后面如果要继续做，可以再加一个“排版员工”或者“发布检查员工”。
第二，研究员工虽然会搜索，但资料包仍然要人工复核。
公开网页可能过期，模型列表也会变。文章里涉及版本号和命令输出的地方，必须回到真实环境确认。
第三，写作员工很容易为了流畅而补齐细节。
这在普通文章里可能只是风格问题，在教程里就是事实风险。所以写作员工不能直接发稿，审计员工也不能代替最终验收。
第四，审计员工的评分不是绝对真理。
这次它打了 86 分 PASS，但我仍然发现修订稿里有些命令片段需要替换成真实输出。审计能提高下限，不能取消人的判断。
结论
这次我更确定了一件事：
真正像数字员工的，不是“一个模型会写很多字”，而是“不同岗位能留下可验收的交付物”。
researcher 留下资料包。
articlewriter 留下草稿和修订稿。
qualityauditor 留下审计报告。
Codex 和我负责把这些东西验收、筛选、整理成最终文章。
这条流程对我来说比单纯追求“一键生成”更有价值。因为它不是把内容生产变成黑盒，而是把每一步拆开，让我能看见：资料从哪里来，文章怎么写出来，质量怎么被打回，最后哪些内容可以发布。
后面我准备继续沿着这条线做两件事：
第一，把 style-guide 和 audit-rubric 继续打磨成稳定模板。 第二，给每篇文章都留下 research packet、draft、audit report、revised draft 四件套。
如果这条流水线稳定下来，我们就不只是“让 AI 写文章”，而是在搭一个能持续改进的内容编辑部。