用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个标题，花费不小且响应慢；专用小模型速度快、成本低，虽然语言多样性差一点，但在这个场景下足够用。等于把“需要创造力的活儿”和“需要执行力的活儿”分开处理。

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

这三者的分工逻辑类似一个成熟的内容