三阶段Agent管道的生产级架构：研究-写作-改写

如果你构建的所谓「内容 Agent」，本质上只是给一次 chat completion 调用套了个 system prompt，那么这篇文章就是写给你的。这不是在推销什么框架——而是我实际用于生产环境、支撑每周内容运营的 pipeline 架构。其中包括：当我用一个大而全的 Agent，而不是三个职责明确的 Agent 时，具体出现了哪些失败模式，以及最终如何通过 Review gate 解决这些问题。

几个月以来，我的内容 pipeline 都是一个 Agent、一条 system prompt、每个任务调用一次：研究主题、撰写初稿、针对各个平台重新排版，所有工作都在一次没有日志记录的处理中完成。它看起来是这样的：

prompt = f"Research and write a full article about {topic} in my voice, then create a LinkedIn post, an X thread, and a Substack note."
response = model.generate(prompt)

从快速生成内容的角度看，它确实能用。但没过几周，内容风格就开始偏离品牌调性；它至少引用过两个根本没有真实来源的统计数据；而且绝大多数时候，产出的内容都需要接近全文重写。这套 pipeline 完全没有把「模型是否找到了真实可信的论断」「模型是否写出了好文章」「模型是否按照平台要求正确排版」区分开来——三个不同的工作，被压缩进了一次未经 Review 的调用中。

解决方案：缩小每个 Agent 的职责范围，并记录交接过程

现在，这套 pipeline 由三个依次运行的 Agent 组成。每个 Agent 只负责一项工作，并通过结构化数据完成交接：

Topic / Source List
      ↓
Agent 1: Research Collector
   — extracts {claim, source, date} tuples only, no prose
      ↓
Research Digest (structured JSON)
      ↓
Agent 2: Draft Writer
   — writes only from digest claims, in defined voice + structure spec
   — cannot introduce a claim not present in the digest
      ↓
Full Draft
      ↓
Human Review Gate
      ↓
Agent 3: Repurposer
   — 4 platform-specific posts from the approved draft only

下面是一份最简的摘要 schema，Draft Writer 只能依据其中的内容进行创作：

{
  "claims": [
    {
      "claim": "Freelancers using structured AI workflows cut deliverable time from 6h to 2.5h",
      "source": "Selfemployed.com",
      "date": "2026",
      "verified": true
    }
  ],
  "contradictions": []
}

Draft Writer 的 system prompt 中包含一条硬性约束：每一个陈述事实的句子，都必须能够映射到 claims 中的某一条记录。如果无法映射，就必须将其标记出来，而不能悄悄润色过去。

真正能够发现幻觉的 Review gate

有一条规则比任何 prompt engineering 技巧都更重要：除非某项论断能够追溯到一个明确、具名且带日期的来源，否则它就不能进入初稿。不能写「研究表明」，也不能写「报告显示」——必须始终给出名称和日期。仅凭这一条约束，我就在初稿中发现了更多虚构的统计数据，其效果超过了任何程度的人工校对。

而且，Review 不能只检查初稿内容。它还必须向上延伸一层，检查那些决定 Draft Writer 究竟采用哪个模型的论断。2026 年 7 月 16 日至 20 日这一周，三个实验室或消息源——Moonshot、Alibaba，以及一位援引 GPT-5.6 的匿名发帖者——分别发布了一项能力声明，但其验证要么缺失、要么被推迟、要么被拒绝公开：一个刚登上排行榜却没有任何独立复现的模型；一个声称「仅次于 frontier model」却没有给出 benchmark 表格的模型；以及一项声称实现数学突破、却将 prompt 保密的成果。如果仅凭这样的标题就更换生产环境中的模型，而不检查其方法论，那么你就是在决定所有下游初稿质量的关键环节中，让 Agent 在没有 Review 的情况下直接运行。

Memory：真正让错误率随时间下降的部分

每个 Agent 在开始任务之前，都会加载一份持续更新的纠错文件：

2026-05-12: banned "leverage" — appears 3x in flagged drafts this week
2026-06-02: source "TechRumorBlog" downweighted — produced 2 unverifiable claims
2026-06-19: Draft Writer kept opening with "In today's fast-moving AI world" — added to banned-opener list

刚开始使用时，这份文件只有四行。现在已经超过了一百行。虽然底层使用的模型始终完全相同，但与三个月前相比，现在的首版初稿明显需要更少的修改。如果没有持久化保存的纠错文件，每个 session 都会从零开始，无休止地重复同样的错误——无论模型质量如何，这正是大多数单 session「AI 内容 Agent」方案在结构上缺失的部分。

我暂时还没有自动化的部分

经过大约两个月的人工 Review，并且没有任何未经验证的论断漏网之后，Research Collector 和 Repurposer 现在已经开始按照计划自动运行。但 Draft Writer 的输出仍然每次都必须经过完整的人工 Review，只有通过后，内容才能进入 Repurposing 阶段。

原因在于：如果 Research Collector 误读了来源，它会生成一份存在缺陷的摘要，但 Review 可以在初稿生成之前发现问题。如果 Repurposer 没有正确设置帖子的格式，它只会产出一篇难看的帖子，我可以直接删除。但如果 Draft Writer 用流畅、自信的文字陈述了一项错误论断，并且没有 Review gate 将其拦截，最终得到的就是一篇署着我的名字、却包含明确错误的已发布文章。

每个阶段出现故障时付出的代价并不相同，因此，在决定是否自动化时，也不应该把它们当成代价相同的环节。

完整框架

完整框架（Cowork Loop™，全部六个阶段，端到端应用）：如何构建一支 AI 内容团队

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。