用Agent工作流构建AI内容生产线：从选题到成文的工程实践

1. 这个项目的起点：为什么我要做“百考通AI”

先说结论：这不是一个靠“套壳大模型”就交差的Demo，而是要把从选题到成文的整条内容流水线，都用AI重新梳理、接管、优化一遍的工程实践。

做这个项目之前，我的状态是典型的“每天都在写，但效率越来越低”。手头同时要维护好几个内容渠道，每个渠道都需要稳定的选题、初稿、润色、配图、发布节奏。传统的做法是开一堆浏览器标签页：搜热点、看竞品、翻资料、用文档写稿、再用另一个AI工具改稿。链条断得很厉害——选题灵感在A平台，素材在B平台，初稿在C工具里，最后排版又回到D软件。来回切换的成本，比我实际写一篇文章的时间还高。

所以我一直想做一套东西，把“查热点、找角度、定框架、产初稿、润色校对、起标题、配摘要”这些环节串起来，让我在一个入口里完成大部分工作。这就是“百考通AI”的雏形。

另一个动机是，市面上现成的AI写作工具很多，但绝大多数只解决“给我一段文字，帮我改写/扩写”这种点状需求，没人解决“从0到1把一篇文章从想法变成成品”这条线性流程。就算有一些号称全流程的工具，用起来也有个通病：太死板，选题逻辑是固定的，生成腔调是固定的，稍微复杂一点的指令就听不懂。

所以这个项目从一开始就没打算做成“又一个AI写作助手”，而是走了一条更工程化的路：用一个Agent工作流串起多个AI能力节点，每个节点只做一件事，但组合起来是一条完整的生产链路。

2. 整体设计思路与方案选型

2.1 核心架构：Agent编排，而不是单模型调用

如果只用一个大模型API做“输入提示词→输出文章”，整个项目半小时就能写完，但它解决不了流程问题。我需要的不是“一个会写文章的大模型”，而是“一个能把文章从选题一路推到成文的自动化系统”。

所以架构上，我采用了多个职能Agent + 共享工作区的方式。什么叫职能Agent？就是每个Agent只负责一个专业环节：

• 选题Agent：负责爬取热点、分析趋势、从用户输入的关键词延展出候选题目。
• 大纲Agent：接收题目后，生成文章的大纲结构和核心论点。
• 资料Agent：围绕大纲，去检索相关资料、摘要、案例，组织成素材包。
• 写作Agent：基于大纲+素材包，生成初稿。
• 审校Agent：对初稿进行事实核查、逻辑校验、润色改写、格式整理。
• 发布Agent：最后一步，产出适合不同平台的内容格式（标题、摘要、标签、封面文案等）。

这些Agent之间不是割裂的，而是通过一个共享工作区传递中间产物。比如选题Agent生成的题目，会写入工作区；大纲Agent读取题目后，产出大纲再放回去；写作Agent再读大纲……整个流程像一条流水线，每一步的产物都是下一步的输入。

这里要解释一下为什么不用“单次提示词”搞定。我试过把“从选题到成文”整个需求塞进一次提示词里，让大模型一口气输出。效果是：它确实能输出，但质量很飘，要么过于泛泛，要么某些段落深某些段落浅，而且完全无法中途干预、调整方向。一旦某个环节不满意，只能全部推翻重来。拆成Agent之后，每一步都能单独调优——选题不满意就只换选题，大纲不行就只改大纲，其余环节不用重跑，成本和可控性完全不是一个量级。

2.2 工具选型：为什么是“通用大模型 + 专用小模型 + 规则引擎”三件套

刚开始我也纠结过，是不是应该直接找一个最强的商业大模型，把整个系统建立在一个底座上。考虑两天之后，我决定不搞“单模型迷信”，而是采用“通用大模型 + 专用小模型 + 规则引擎”的混合架构。

通用大模型负责语言理解、生成、润色这类需要“智能”的环节。这个没什么好说的，现在的通用大模型在语言层面的能力已经很强了。

专用小模型负责某些具体场景，比如短标题生成、标签提取、摘要生成。为什么要用专用小模型？因为这些环节输出格式极其固定、大批量处理时成本敏感。让通用大模型批量生成100个标题，花费不小且响应慢；专用小模型速度快、成本低，虽然语言多样性差一点，但在这个场景下足够用。等于把“需要创造力的活儿”和“需要执行力的活儿”分开处理。

规则引擎处理的是那些不需要模型能力的环节，比如格式校验、字数统计、敏感词检测、排版转换。用规则而不是模型，是因为规则确定性高、零幻觉风险。比如你要求文章必须有“开头、主体、结尾”三段结构，或者不允许出现某类词汇，这种需求用规则最稳，不需要大模型“猜”。

这三者的分工逻辑类似一个成熟的内容团队：主笔负责创意表达（通用大模型），助理负责批量整理和格式化（专用小模型），质检负责流程审核（规则引擎）。各司其职，出现问题也能快速定位是哪个环节的锅。

2.3 全流程覆盖：这条流水线到底铺了多远

“全流程覆盖”不是口号，我落地到了这几个节点：

原本我计划连“配图生成”也纳入流程，但实际测试后发现，当前的AI绘图模型对文字类内容配图的把握还不够稳定——有时候生成的图片很好看，但和文章的调性完全对不上。所以我暂时把配图放到了人工环节，只提供“配图提示词建议”，而不是直接生成。这是一个务实的取舍。

3. 核心模块解析与实操要点

3.1 选题Agent：不是玄学，是用数据喂出来的“网感”

选题是整个流程的起点，也是决定文章生死的一步。很多写作者在选题上的问题不是“没想法”，而是“想法太多但不知道哪个能写、哪个值得写”。

我的选题Agent做了三件事：热点捕捉、趋势判断、角度生成。

热点捕捉用的是一个最朴素可行的方案：接入公开的热搜榜单数据源（比如各大平台的热榜、指数类数据），定时抓取并存入数据库。这里要注意，抓热榜不是简单存个标题就完了，我会额外记录四个维度：出现时间、排名变化、上榜持续时长、相关讨论热度趋势。为什么要记录这些？因为“刚上榜10分钟的新鲜话题”和“已经在榜上挂了48小时的成熟话题”，它们的流量红利是完全不同的——前者适合抢时效，后者适合做深度。

趋势判断的原理更简单。如果一个关键词在三天内反复出现在不同平台的热榜上，说明它具备“跨圈层传播”的潜力，值得深挖。如果只在一个平台上短暂出现，那大概率是垂直圈子里的小热点，写出来的受众面会比较窄。

角度生成是我认为最有价值的部分。同一个热点话题，不同媒体会从不同角度切入。AI在这里的作用不是凭空发明角度，而是基于已有的相关文章标题，做差异化的反向思考。比如大家都写“AI会不会取代程序员”，选题Agent就会从“哪些程序员最不容易被取代”“AI编程工具的实际体验到底如何”“普通企业落地AI编程的成本真相”这些角度找切口。这种“找到别人没写透的方向”的能力，光靠人肉刷信息流真的效率很低。

实操中有个坑必须提醒：热点数据源要定期检查和更新。榜单接口经常变动，有时候改个参数、加个字段，你的解析代码就挂了。我为此写了一个监控脚本，每天自动检测数据源状态，解析失败会自动告警。这个细节看起来不起眼，但能避免你早上起来发现整个系统空转了一天。

3.2 大纲Agent：给文章画一个不容易跑偏的骨架

有了题目之后，下一步是生成大纲。这一步看起来简单，但实际上是最能体现“结构化能力”的环节。

我调优过很多版提示词，最后发现大纲生成的关键不是“让AI列几个标题”，而是让AI明确回答三个问题：

• 这篇文章的核心目标是什么？（科普、教程、观点输出、还是流量驱动？）
• 目标读者是谁？他们已有的认知水平如何？
• 读者读完这篇文章，最应该带走的一个信息是什么？

这三个问题被前置之后，大纲的质量完全不一样。没有这三个约束的时候，AI经常给出“这是什么东西、有什么好处、未来趋势”这种极水极空的三段式框架。而加上这些约束之后，大纲的针对性会明显增强，后续写作也会顺利很多。

另外，我会要求大纲必须标注每个小节的大致篇幅比例。比如一节只铺500字的浅层内容，就没必要让写作Agent写出2000字来。这个过程我用的是规则引擎：写完后检查各小节的字数是否在大纲要求的范围内，偏离超过30%就标记为异常。这大大减少了写出来的稿子头重脚轻的情况。

3.3 写作Agent：提示词工程在实战里到底该怎么搞

写作Agent是整个系统里最核心的环节，也是我花时间最多的地方。

我的第一版方案很天真，想让大模型直接“把大纲扩写成文章”，效果很一般——输出的文字是通顺的，但读起来异常枯燥，每个段落都像同一个模板套出来的。后来我把写作拆成了“初始生成”和“风格注入”两步：先生成一个结构完整但风格中性的版本，再用一个风格文本作为参考，让AI按照目标风格重写一遍。

这个“风格参考”是从哪里来的？不是随便给一句“请写得风趣幽默一点”，而是从目标平台挑选3-5篇表现最好的文章，提炼出它们共同的风格特征——句子平均长度、脑洞指数、专业术语密度、情绪表达方式、段落节奏——然后用这些量化的特征去引导大模型。

举个例子，如果一个平台的文章普遍是短段落、每段不超过三行、多用口语词和问句开头，我就会把“段落平均行数不超过3行”“每段以问题或场景描述开头”“使用口语化连接词”这些要求写入提示词。这样生成出来的初稿至少不会一眼就被看出是AI写的。

还有一个重要的点是防止AI写作的“正确废话”。“AI永远正确、永远平庸”是最大的通病。为此我在审校环节加了一个专门的检测器：扫描全文里那些“虽然……但是……总而言之……”式的车轱辘话，把它们标记出来，提示用更直接的事例或数据替换掉。

这里分享一个可以直接抄走的提示词片段（以写作Agent的System Prompt为例）：

text复制你是资深内容主编。你的任务是基于给定的大纲和素材，写出一篇适合目标平台的文章。
写作要求：
1. 遵守大纲的小节顺序与篇幅比例，不得自行增删章节。
2. 标题、小标题要具体可感知，禁止使用“xxxx的研究与应用”这类宽泛表述。
3. 每段内容必须有信息增量，禁止只用连接词扩展而无实质内容。
4. 优先使用具体案例、数字、操作步骤替代抽象描述。
5. 段落之间避免机械过渡，允许直接切换话题。
6. 全文不出现“随着xxx的发展”“综上所述”等模板化句式。

这套提示词配合几轮调优之后，写作Agent的输出质量基本能达到“可以作为初稿直接进入人工编辑”的水平。

3.4 审校Agent：给AI写的内容再做一遍“质检”

很多人忽略审校环节，让AI生成完就直接用。我个人的经验是：这是最危险的做法。

AI生成内容有个天然问题：它的语言是流利的，但逻辑不一定严密，事实不一定是真的，格式不一定符合要求。如果没有审校环节，你可能带着一个错误的数据、一个逻辑漏洞就发布了。

审校Agent做了三层检查：

• 表层检查：错别字、标点符号、格式规范、字数范围。用规则引擎就能完成，没有任何技术门槛。
• 逻辑检查：段落间的因果关系是否成立、论据是否支持论点、是否存在前后矛盾。这一层需要大模型的能力，但要让大模型检查逻辑，前提是给它一个“逻辑检查清单”。没有清单的话，它只会泛泛地说“文案整体比较流畅”。
• 与平台的匹配度检查：这套稿子在目标平台上的表现预期如何。这里我用了两种方式：一是规则上检查字数分布、标题长度是否在平台推荐范围内；二是调通用大模型做一次“读者视角”评估，模拟目标读者看完这篇文章后的感受、疑问和行动意愿。

逻辑检查这里我需要多说一句。我实际用的不是让AI直接给结论，而是让AI把文章拆成“论据-论点”结构，逐条判断每个论据是否有效支撑对应论点。这样能有效避免AI走马观花式地检查。把所有论据列出来之后，哪些是站得住的、哪些是支撑不足的、哪些是根本没用的，一目了然。

3.5 发布Agent：同一篇文章，在不同平台的“变体”

最后一个环节也是很多同类系统忽视的环节：发布适配。

同一个内容，发公众号、发知乎、发小红书、发头条，最合适的标题、摘要、标签和排版是完全不一样的。公众号标题讲究悬念和共鸣，知乎标题讲究信息量和可信度，小红书标题讲究关键词覆盖和情绪价值。

发布Agent做的事情，就是基于同一篇文章，生成多套“平台适配包”。每一套包含：平台专属标题（通常给3-5个备选）、摘要文案、标签推荐、甚至开头的改写建议。这样我就不用在每个平台各写一遍适配文案，系统一次性都给出来。

这个环节也踩过坑。最初我是让大模型直接生成的，但它经常会给出很套路的标签，比如“干货分享”“学习成长”“生活方式”，放着没毛病，但也没有任何爬升流量的价值。后来我换了个思路：从平台已有的高赞内容里抓取热门关键词集合，再让模型从集合里选词组合，效果立刻不一样了。所以这里的建议是：凡是涉及“关键词优化”的环节，尽量用真实数据做筛选，不要依赖模型的凭空想象。

4. 实操过程：从零搭建整个流程

4.1 第一步：搭建工作区与数据层

“百考通AI”不是一个单体程序，而是几个模块的组合协作。我在最开始就先定了模块间数据流转的规范，这一点是整个项目能顺利跑通的基石。

数据层用的是最基础的SQLite + 文件目录的组合，没有引复杂的数据库服务。原因很简单：项目的核心数据量不算大，一篇文章的中间产物也就几十KB级，SQLite完全够用；更重要的是，SQLite不需要单独维护一个数据库服务，部署和备份都极其省事。

共享工作区的目录结构是这样的：

text复制/workspace
  /topics          # 选题Agent的产出
  /outlines        # 大纲Agent的产出
  /materials       # 资料Agent的素材包
  /drafts          # 写作Agent的初稿
  /reviewed        # 审校Agent的完成稿
  /publish         # 发布Agent的适配包

每个产出都有统一的JSON格式头，记录来源Agent、生成时间、上游依赖文件的ID。这样出了问题，我能很快定位是哪个环节的数据导致下游出错。

4.2 第二步：串起每个Agent的调用链

Agent之间的串联，我用的是最朴素的编排方式——状态机 + 定时触发。每个文件有状态：待处理、处理中、已完成、有异常。某个Agent处理完，就更新状态，然后通知下游Agent可以开工。

这样做的好处是：每一步都可以被单独重跑。如果文章到大纲环节没问题，但初稿生成效果差，我只需要把初稿的状态改回“待处理”，重新触发写作Agent，之前环节的产物完全不用动。

具体串起来的调用链长这样：

text复制选题采集 -> 选题评估 -> 大纲生成 -> 素材收集 -> 初稿生成 -> 审校检查 -> 发布适配

每个箭头都是一次API调用，上一环的输出写入工作目录后，下一环读取再输出。全程不需要数据库的事务性操作，用文件就能表达依赖关系。对于一个人工介入频率比较高的半自动流程，“文件即状态”这个方案反而比引入正规任务队列更直观。

4.3 第三步：定义一套稳定的“中间产物格式”

这一步看似不起眼，但实际上决定了整套系统是否可维护。我强烈建议所有做同类项目的朋友，在写第一行Agent代码之前，先把中间产物的数据结构定死。

比如大纲产物，我定的是这种结构：

json复制{
  "title": "标题",
  "target_reader": "目标读者画像",
  "core_message": "本文核心信息",
  "sections": [
    {
      "heading": "小标题",
      "purpose": "本节写作目标",
      "word_count": 800,
      "key_points": ["要点1", "要点2"],
      "source_ids": ["素材ID"]
    }
  ]
}

这保证了每个Agent拿到手的数据都是“整齐的”，写代码的时候不用因为AI返回的JSON结构不稳定而反复做防御性解析。

另外一个很重要的实践是：每个Agent在把数据写回工作区之前，先自己校验一遍JSON结构，如果结构不对就调用一次“修复提示词”让它自己修。这一步能把因为模型输出格式漂移导致的整条链路崩溃率降到极低。

4.4 第四步：给整套系统穿上“半自动”的外衣

全自动是理想，半自动是现实。

我最终交付的形态是：每个环节都可以选择“自动执行”或“人工确认”。比如选题环节，AI给20个候选题目，如果今天时间充裕，我会人工挑3个再进入大纲阶段；如果时间紧，就直接让系统自己按热度排序取前3个跑下去。

这个“人机协作”的姿态也是我踩了很多坑之后才确定的。最初我追求的是全自动——从选题到发布，完全不人工干预。但跑了一周之后发现，全自动生成的文章普遍缺少“灵魂”——它符合所有写作规范，但总感觉跟平台上的真人写的内容隔着一层。而且AI无法感知当下的“真实气氛”——哪个话题真实讨论度正在爆发，哪个话题已经写烂了，AI的判断总是慢半拍。

所以我现在定的节奏是：系统负责产能、速度和标准流程，人工负责判断、审美和关键节点把控。这样既保证了效率，也保留了内容质量的上限。说白了，好的AI工作流不是替代人，而是把人的精力从重复劳动中解放出来，放到更需要判断力的地方。

5. 常见问题与排查技巧实录

5.1 问题一：生成的文章“同质化”严重怎么办

开始的时候，我发现用同一套流程连续生成的几篇文章，读起来像是同一个模子刻出来的。排查下来，问题出在：选题Agent和大纲Agent的提示词太固定，导致不同选题在“表达结构”上过度相似。

解决办法是给提示词加“变异维度”。每次请求生成大纲时，会随机附一个“结构风格提示”，比如：

• 从“问题-原因-方案-案例”结构切换到“现象-反差-分析-建议”结构；
• 明确禁止使用上次生成时已使用过的开头句式；
• 如果是教程类文章，随机决定“先讲原理”还是“先给操作”。

这个随机性让我在后续测试中明显感受到内容的多样化。同一个选题，让系统生成3个版本的大纲，结构雷同的概率大大降低。

5.2 问题二：模型输出和上游内容对不上

这是Agent工作流最常遇到的问题。比如大纲给了三个章节，写作Agent在初稿阶段可能只写了两个章节，或者把两节合并了。

排查后的根因是：提示词里没说清楚“每一节必须独立成段且不允许自行合并”，而且大纲原始数据里每节的边界信息在传递给写作Agent时，被截断或格式化了。

解决方案有三层：

• 第一层：提示词里用极明确的语言禁止合并章节；
• 第二层：把大纲转成Markdown时，用固定分隔符把每个section隔开；
• 第三层：写作完成后用规则引擎做一次章节数量校验，不一致就打回重写。

这三层叠加之后，“章节丢失”的问题基本消失了。

5.3 问题三：审校环节的“误伤率”很高

我的审校Agent一开始设定的规则比较严格，比如“不允许出现某些词汇”“句子长度不能超过40字”，结果导致很多本来挺好的内容被误判为异常。

后来我调整了策略：把规则分成了“禁止级”和“建议级”。禁止级规则直接拦截，破坏性太强的直接打回；建议级规则只做提示，不阻断流程。同时我加了“审校理由输出”：每次标记一个问题，必须说明违反了哪条规则，具体是什么内容，理由是什么。这样我在人工查看时能快速区分哪些是真的问题、哪些是误报。

这个体验让我意识到，做AI内容生产系统，规则的“阻断逻辑”要比“输出逻辑”更用心设计，因为每次错误阻断都在消耗你对系统的信任感。

5.4 一个通用的排查思路：先看中间产物，再查模型

最后分享一个排查Bug的通用心法：遇到异常，先检查上游数据，再去怀疑模型能力。

很多人在AI系统出问题时，第一反应是“换个更好的模型”或者“调一下提示词”，但真正的问题往往出在更原始的地方——选题数据源挂了、JSON解析失败了、上游某个字段为空了。所以我不会直接改提示词，而是先看：这个Agent读到的输入数据，是不是它“应该读到的数据”？如果输入就是残缺的，模型再强也救不了输出。

我把这个思路固化成了一个调试脚本，可以在任意一个Agent的执行节点前后，把输入和输出都存下来，随时回放。这套“数据快照”机制，省了我大量重复调试的时间。

6. 这个方向可以怎么扩展

“百考通AI”目前的版本已经解决了从选题到成文的主链路，但以我的实际使用体验来看，它还可以在几个方向上继续深挖。

多模态扩展是其中最值得做的一个方向。现在内容平台的竞争已经不只是文字了，图文、短剧、视频都是重要的表达形态。虽然我之前说配图生成暂时交给人工，但AI直接生成短视频脚本、分镜描述、图文卡片的时代已经在路上。尤其在AI短剧、AI漫剧这些新内容形态上，从“文字内容生成”到“可视化内容生成”的链路潜力很大。

垂直领域化也是一个方向。通用内容工作流已经打通了，但不同行业的写作模式差异巨大。科技自媒体和金融账号、法律科普和美食探店，它们的选题逻辑、行文方式、素材来源完全不同。如果能把行业知识库沉淀到系统里，变成一个“垂直领域的内容工厂”，或者更进一步，做成一个聚合多个垂直Agent的AI中台，那这个项目的天花板会高很多。

由内容生产延伸到内容运营是另一个我近期在考虑的扩展方向。发出去的文章，数据表现如何、读者的反馈集中在哪些地方、后续可以做什么跟进内容，这些都是运营层面的问题。AI在这块能做很多事情，比如自动汇总评论区观点、发现读者最关注的话题点、给出下一篇文章的切入建议。这相当于让系统从“写完文章就结束”进化到“写完文章才开始”。

单就当前阶段来说，“百考通AI”给我最大的收获倒不是每天能多产出几篇文章，而是让我重新理解了AI工作流的构建方式——它不是一个“输入-输出”的黑盒，而是一套可以拆分、可以调试、可以逐步优化的人类协作工具。AI负责产能，人负责方向，这件事在内容行业里应该还能走很远。