大家在内容创作时应该都有过类似体验素材找了一上午文章改了七八遍发布后数据平平一周后再复盘发现当初的选题方向本身就偏了。更麻烦的是这些环节彼此孤立选题、写作、分发、数据复盘之间没有形成反馈闭环导致每次创作几乎都是从零开始。如果能把 AI 智能体AI Agent引入到内容生产的完整链路中让四个各司其职的智能体分别负责选题调研、内容创作、平台适配、数据分析并通过工作流串联起来整个流程就能变成一条可复用、可监控、可迭代的自动化流水线。本文将围绕“AiToEarn”的思路完整拆解四个 AI 智能体的分工设计、平台搭建、提示词模板、工作流编排与 Python 调用示例帮你从零落地一套内容全链路自动化方案。本文适合以下读者想用 AI 提升内容产能的新媒体运营、正在做内容中台的技术开发、对多智能体协作感兴趣的大模型应用开发者。读完你会理解四个智能体各自的职责边界能在 Dify 平台上搭建完整工作流也能用代码方式调用智能体 API 实现批量生产。1. 背景为什么内容全链路需要“多智能体协作”1.1 单 Agent 的局限早期的 AI 内容生产往往是“一个对话框完成所有事”让大模型写文章、起标题、生成摘要、找选题。这种方式在简单场景下确实能用但一旦进入正式的创作流程就会暴露很多问题。一个模型实例同时处理选题调研、素材收集、正文撰写、平台适配容易导致提示词上下文过长。当 prompt 超过一定长度后模型会遗忘前文指令输出质量明显下降同时把“搜索实时信息、查数据库、读平台规范、格式化输出”全部塞进同一个 Agent工具调用逻辑也会变得混乱排错时难以定位问题到底出在哪一步。更关键的是单 Agent 不具备“分工后的专业化”。写技术教程的提示词和写小红书文案的提示词应该完全不同做数据分析的工具调用和做选题挖掘的工具调用也应该完全分离。强行放到一个 Agent 里只能得到“什么都会一点但什么都不精”的结果。1.2 内容全链路的四个核心环节我们把一条完整的内容生产线拆开通常包含四个步骤第一选题与素材调研。这一步要回答“写什么、有什么热点、有哪些可引用的资料”需要联网搜索能力、资讯抓取能力、知识库检索能力。第二内容创作与编辑。这一步要完成文章初稿、标题、摘要、段落结构、内容润色需要稳定的大模型写作能力以及可配置的输出模板。第三多平台适配与发布。同样的内容发布到公众号、知乎、掘金、小红书格式和风格完全不同需要做标题改写、正文分节、标签生成、SEO 关键词提取。第四数据分析与优化。内容发布后要持续跟踪阅读量、收藏量、转化率分析哪类选题表现更好再把结论反馈到下一步选题形成闭环。把这四个环节交给四个不同的 AI 智能体每个智能体只负责一件专业的事配合工作流引擎实现状态流转和数据传递整体系统的稳定性和可维护性都会大幅提升。1.3 AiToEarn 思路下的价值所谓“AiToEarn”本质上不是让用户不劳动而是通过 AI 智能体把重复性工作自动化让人把精力集中在选题判断、内容审核和策略决策上。这样做的好处有三点一是内容产能提升原来一天只能产出一篇文章现在可以在智能体辅助下完成多平台矩阵内容二是质量可控每个环节都有独立 Agent 和独立提示词调优某个环节不会影响其他环节三是数据可闭环第四个智能体把复盘结论自动反馈给第一个智能体选题会越来越贴近用户真实需求。2. 整体架构设计2.1 四个智能体的职责定义在正式搭建之前我们先把四个智能体命名清楚方便后面配置工作流时引用。智能体名称核心职责关键工具Agent 1选题调研员热点挖掘、选题评估、素材收集联网搜索、RSS 抓取、知识库Agent 2内容创作员文章撰写、摘要提炼、标题优化大模型、结构化输出、模板库Agent 3平台适配员多平台格式转换、SEO 优化、标签生成平台规范库、关键词工具Agent 4数据分析员数据采集、指标计算、策略报告数据接口、Excel 导出、图表这里要注意不同 Agent 之间不建议共用同一个系统提示词因为各自的“专业身份”差异太大。Dify 等智能体平台允许为每个 Agent 独立配置人设、工具和知识库这是多智能体落地的基础。2.2 数据流转与协作链路四个智能体之间的协作不是“一个调用一个”的链式传递而是带有反馈回路的循环结构。主链路是Agent 1 输出选题报告 → Agent 2 根据选题报告生成正文 → Agent 3 把正文转换为不同平台版本 → Agent 4 采集发布后的数据并生成分析报告。反馈链路是Agent 4 的分析结论回传给 Agent 1Agent 1 在下一轮选题时参考上一轮高曝光、高转化的话题特征从而实现选题策略的自适应进化。为了让数据能够在不同智能体之间顺畅流转每个智能体的输出建议采用 JSON 结构化格式。比如 Agent 1 输出{ topic: AI智能体在多平台内容生产中的落地实践, angle: 四智能体协作架构, keywords: [AI Agent, 多智能体, Dify], materials: [链接1, 链接2], suggested_title: 用四个AI智能体跑通内容全链路我总结了一套可复用的工作流 }后续 Agent 2 可以直接读取这些字段而不需要再从长文本中重新解析。2.3 技术选型建议实现多智能体工作链路的方案有很多这里提供三种常见路线第一种纯平台路线。使用 Dify、Coze 这类可视化智能体平台通过拖拽节点完成 Agent 编排。优点是上手快、调试直观、内置知识库和工具插件适合运营人员和初级开发者。第二种代码路线。使用 LangChain、LangGraph 或 Spring AI 等框架把四个 Agent 写成 Python/Java 类通过代码控制流程。优点是灵活、可定制性强适合需要深度集成到业务系统的开发者。第三种混合路线。用 Dify 搭建智能体和工作流对外暴露 API再用 Python/Java 编写调度脚本定时触发或响应事件调用。这是目前企业落地最常见的做法既保留了可视化调试的便利性又具备外部系统集成能力。本文接下来将以混合路线为主平台部分以 Dify 为例代码部分使用 Python 调用 API 完成串联。3. 环境准备与基础配置3.1 部署 Dify 智能体平台Dify 是一个开源的大模型应用开发平台支持知识库、Agent、工作流等核心能力。你可以选择云端版本也可以在自己的服务器上通过 Docker 部署社区版。Docker 部署方式如下先准备一个项目目录例如dify-agent-demo然后在目录中创建docker-compose.yaml并启动服务mkdir -p dify-agent-demo cd dify-agent-demo curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml cp docker-compose.yaml docker-compose.yaml.bak docker compose up -d启动后通过浏览器访问http://localhost按引导完成管理员账号初始化。首次部署需要拉取多个镜像耗时取决于网络环境。版本变化较快请以官方仓库最新文档为准。如果只是想快速体验注册 Dify 云端服务也可以功能差别不大本文重点演示配置思路部署方式不影响后续操作。3.2 接入大模型 API在 Dify 管理后台的“模型供应商”页面可以接入各个大模型服务商。国内用户常用的有通义千问、DeepSeek、智谱 GLM、百度千帆等基本都提供 OpenAI 兼容的接口形式。配置时重点确认三件事一是 API Key 从哪个服务商获取建议使用单独的 Key 并在环境变量中保存不要直接写在代码仓库里。二是模型名称要与服务商实际提供的模型一致。以 DeepSeek 为例通常可以填写类似deepseek-chat的模型标识。三是确认平台支持的功能类型比如 Agent 流程需要工具调用能力就要选择支持 function calling 的模型而不是纯文本对话模型。如果你同时测试多个模型建议统一命名规范例如把模型名维护在配置文件中避免后期切换时还要改多处代码。3.3 准备知识库与素材库内容生产链路中Agent 1 和 Agent 2 比较依赖知识库。可以提前把以下内容导入 Dify 知识库历史高阅读量文章作为选题和风格的参考素材。行业报告、产品文档用于丰富内容素材。平台运营规范例如公众号正文格式、知乎回答排版规范供 Agent 3 适配时检索。上传文档后Dify 会做文本分段和向量化。分段长度建议按默认或适当缩短例如每段 300 到 500 字符便于检索命中。知识库命名建议与用途对应例如“历史爆文库”“平台规范库”“产品素材库”。3.4 示例项目结构为了方便后续代码调用建议创建如下项目结构ai-to-earn-demo/ ├── config/ │ ├── settings.py # 统一配置 API 地址、Key、模型名 │ └── agent_config.json # 四个 Agent 的应用 ID 配置 ├── agents/ │ ├── agent1_research.py # 调用选题调研智能体 │ ├── agent2_write.py # 调用内容创作智能体 │ ├── agent3_adapt.py # 调用平台适配智能体 │ └── agent4_analyze.py # 调用数据分析智能体 ├── schemas/ │ └── topic_schema.json # 数据结构定义 ├── workflows/ │ └── full_chain.py # 编排完整链路 └── requirements.txt后面第 8 节的代码会按这个结构给出。4. Agent 1选题与素材调研智能体4.1 工作流程设计选题调研智能体承担整个链条的“输入口”。它的工作流程大致为第一步接收用户输入的方向或指令例如“生成 5 个关于 AI 智能体的技术选题”。第二步调用联网搜索工具获取近一周的行业热点、讨论趋势和热门问题。可以接入搜索引擎插件或 RSS 工具。第三步检索知识库中的历史爆文分析哪些选题方向过去表现较好。第四步把热点信息、历史数据、素材链接整合成结构化选题报告。4.2 提示词模板在 Dify 中创建第一个 Agent命名为“选题调研员”系统提示词可以这样设计你是一名资深的内容策略分析师擅长从海量信息中挖掘高潜力的内容选题。 你的任务 1. 根据用户给出的领域方向结合实时搜索结果提炼 3-5 个有差异化角度的选题。 2. 每个选题必须说明目标读者、内容切入点、差异化优势、预计可引用的资料。 3. 输出格式必须为 JSON包含 topic、angle、keywords、target_audience、materials 字段。 4. 优先选择讨论热度上升中、但搜索竞争度不高的细分话题。 注意 - 只输出 JSON 内容不要输出解释性文字。 - 如果没有检索到足够信息明确标注信息不足不要编造。 - materials 中的链接必须来自真实搜索结果。这段提示词的关键点在于“只输出 JSON”和“没有检索到就标注不足”这两个约束可以避免后续 Agent 收到脏数据。4.3 工具与知识库配置在 Agent 设置里为“选题调研员”启用联网搜索工具并关联“历史爆文库”知识库。知识库检索的召回数量可以设置为 5 到 10 条召回分数阈值建议不低于 0.5避免低相关文档污染模型判断。如果发现检索结果不准确优先检查文档分段是否合理、关键词是否过于抽象。该 Agent 输出结果示例{ topic: 多智能体协作的内容生产实践, angle: 从单Agent到四Agent协作的架构演进, keywords: [多智能体, 内容生产, Agent协作], target_audience: 技术博主、内容运营、大模型应用开发者, materials: [ https://example.com/dify-docs, https://example.com/agent-workflow ] }5. Agent 2内容创作与编辑智能体5.1 结构化输入与输出Agent 2 接收 Agent 1 的选题报告它不需要重新搜索而是专注于写作。为了保证输出质量建议给 Agent 2 设置两段式流程第一段根据选题报告生成文章大纲。大纲要细到每个章节的核心观点和可展开的素材。第二段根据大纲生成完整正文。正文使用 Markdown 格式包含标题层级、代码块、列表等结构化元素。拆成两段的原因是直接让模型从“一个选题”生成“一篇长文”容易导致结构松散先写大纲再展开模型相当于先做规划再做执行输出质量会稳定很多。5.2 提示词模板在 Dify 中创建第二个 Agent命名为“内容创作员”系统提示词示例你是一名技术内容创作者擅长将复杂的技术概念写成通俗易懂的文章。 你会收到一份选题调研报告JSON 格式请按以下步骤完成创作 第一步根据 topic、angle、keywords 生成文章大纲包含引言、核心章节、示例代码、常见问题、总结五个部分。 第二步按照大纲撰写完整正文。要求 - 使用 Markdown 格式H2 标题用 ##H3 标题用 ###。 - 每个技术概念先用通俗语言解释再补充技术细节。 - 代码示例必须带语言标签如 python。 - 文章开头要说明适用读者结尾要给出下一步建议。 第三步为文章生成 3 个备选标题和 1 段 150 字以内的摘要。 输出格式 {summary: 文章摘要, titles: [标题1, 标题2, 标题3], content: 文章正文} 注意 - 不要编造事实、数据、API 名称。 - 如果选题报告中材料不足明确说明需要补充哪些材料。 - content 中的正文必须是完整可发布的文章不能是提纲。这个提示词有几个设计细节要求模型不要编造事实是为了避免常见的大模型幻觉问题要求输出 Markdown 正文是为了后续 Agent 3 做格式转换时更省事。5.3 质量检查节点虽然我们用了智能体但完全交给模型“裸奔”仍然有风险。推荐在 Agent 2 后增加一个“内容质量检查”节点可以通过 Dify 工作流中的条件判断或代码节点实现。检查规则可以包括正文长度是否大于 800 字。是否包含至少两个代码块或列表。是否包含备选标题和摘要。结尾是否有明确的下一步建议。如果检查不通过可以让工作流把内容返回 Agent 2 重新生成最多重试两次超过两次则标记为人工处理。这个设计能防止小概率的低质量内容流入发布环节。6. Agent 3多平台适配与发布智能体6.1 多平台差异适配同样的文章直接复制粘贴到所有平台并不是好方案。每个平台都有固定的阅读习惯和格式要求。公众号正文更强调排版和开头引入段落不能太长知乎回答需要论点清晰、结构严谨最好有“先说结论”小红书笔记偏向口语化、重情感表达、强调真实体验技术社区如掘金、CSDN 则偏好代码清晰、技术点密集、有可复现的操作步骤。Agent 3 的作用就是根据目标平台把 Agent 2 生成的正文转换为对应风格的版本。6.2 提示词模板在 Dify 中创建第三个 Agent命名为“平台适配员”系统提示词示例你是一名多平台内容运营专家熟悉公众号、知乎、小红书、掘金、CSDN 等主流内容平台的发布规范与用户偏好。 你会收到一篇 Markdown 格式的文章正文以及目标平台名称。请完成以下转换 1. 调整标题根据平台风格改写标题公众号标题要吸引点击知乎标题要突出专业感小红书标题要口语化、带情绪词。 2. 调整正文结构拆分过长的段落公众号版本每段不超过 150 字小红书版本开头直接给结论多用换行和表情符号。 3. 生成平台标签小红书版本输出 5-10 个话题标签格式为 #关键词。 4. 提取 SEO 关键词技术平台版本输出 title、description、keywords 三个字段用于站点优化。 输出格式 {platform: 平台名称, title: 适配后标题, content: 适配后正文, tags: [标签], seo: {title: SEO标题, description: SEO描述, keywords: [关键词]}} 注意 - 保持原文事实不变只做格式和风格调整。 - 不删除代码示例不改变代码内容。 - 如果原文质量过低简单说明问题并原样返回。调用时通过工作流的变量传入目标平台名称例如把platform设置为xiaohongshu或csdn。如果需要同时发布到多个平台可以让一个内容并行进入多个 Agent 3 实例每个实例处理一个平台。6.3 发布队列与格式转换Agent 3 输出的是格式化文本真正发布时还需要转换成平台要求的格式比如 plain text、HTML 或带指定标签的文本。这里建议用一个队列任务来管理发布动作。简单实现可以基于 Redis 列表把 Agent 3 的输出 push 到队列中再由发布任务消费。复杂场景可以引入 Celery 或 XXL-Job但刚开始不建议过度设计先把链路跑通更重要。小规模场景下也可以直接把适配后的内容保存到本地文件人工复制发布。这样能在初始阶段建立内容质量基线。7. Agent 4数据分析与优化智能体7.1 数据源接入内容发布之后要跟踪数据表现。常见的数据来源包括各平台后台导出的 Excel、第三方数据平台的 API、自建网站的访问日志。在 Dify 中创建第四个 Agent命名为“数据分析员”并上传最近一周的数据样本让 Agent 理解数据字段含义。字段可以包括发布日期、平台名称、标题、阅读量、点赞量、收藏量、评论量、转发量、转化率。如果平台没有开放 API最简单的做法是每周手动导出 CSV再上传到知识库或直接在对话中作为附件传给 Agent。7.2 指标计算与报告生成Agent 4 的核心价值不是“展示数字”而是从数字中提炼结论。例如它可以计算哪类选题的平均阅读量最高。哪个平台的内容表现波动最大。标题中包含哪些关键词时打开率更高。发布时间与阅读量之间的分布关系。系统提示词示例你是一名内容数据分析师擅长从数据中定位问题并提出可执行的优化建议。 你会收到一张内容表现数据表请完成以下任务 1. 按选题方向聚合阅读量、收藏量、转化率按表现排序。 2. 对比不同平台的互动率找出最有效的内容分发渠道。 3. 分析标题关键词对打开率的影响提炼出 Top 5 的高效关键词。 4. 输出结构化分析报告 JSON包含 best_topics、best_platforms、keyword_insights、action_items 四个字段。 action_items 字段必须给出下个周期可以直接执行的 3 条建议例如“优先创作 xx 方向内容”“在小红书增加 xx 类型选题”“标题前 15 个字尽量包含 xx 关键词”。 注意 - 不要只罗列数据要给出结论。 - 如果数据量不足明确说明结论置信度有限。7.3 反馈闭环设计Agent 4 的分析报告不只是一份“给人看”的周报。在自动化链路中它应该成为 Agent 1 下一轮选题的输入。实现方式有两种一种是自动回填。通过 Python 脚本把 Agent 4 的输出存在一个feedback.json文件里Agent 1 启动时自动读取这个文件作为选题参考。另一种是人工确认后回填。数据分析结果先发送到团队协作工具如钉钉、飞书、企业微信人工确认后再写入 Agent 1 的知识库或上下文。建议前期采用第二种方式。完全自动化的闭环可能出现“数据冷启动 模型幻觉”导致的错误归因人工确认可以让反馈质量更高。8. 用 Dify Workflow 串起完整链路8.1 工作流节点设计在 Dify 中创建一个新工作流命名为“内容全链路生产”把四个 Agent 作为节点串联起来。核心节点如下开始节点接收用户输入包括内容方向、目标平台、是否启用数据分析。Agent 1 节点调用“选题调研员”。条件分支节点判断 Agent 1 是否成功返回 JSON不成功则结束并返回错误信息。Agent 2 节点调用“内容创作员”输入为 Agent 1 的 JSON。质量检查节点用代码节点校验 content 字段长度与完整性。Agent 3 节点根据目标平台数量并行调用“平台适配员”多个实例。结束节点汇总各平台适配结果。8.2 变量传递与分支规则工作流中的变量命名要统一建议使用 snake_case例如topic_report、article_content、platform_version。条件分支规则示例判断topic_report是否包含topic字段以及article_content的字符长度是否大于 800。如果判断失败可以输出“需要人工干预”的提示而不是直接继续向下传递避免下游 Agent 处理垃圾数据。8.3 Python 调用 Dify API 实现自动化可视化工作流搭好后我们可以用 Python 脚本调用 Dify 的 API 来触发整个流程。这样可以结合定时任务、消息队列或 Web 事件。先安装依赖pip install requests编写基础调用函数# 文件路径ai-to-earn-demo/config/api_client.py import os import requests class DifyClient: def __init__(self, base_url: str, api_key: str): self.base_url base_url.rstrip(/) self.api_key api_key self.headers { Authorization: fBearer {api_key}, Content-Type: application/json, } def run_workflow(self, inputs: dict, user: str content-bot): url f{self.base_url}/v1/workflows/run payload { inputs: inputs, response_mode: blocking, user: user, } resp requests.post(url, headersself.headers, jsonpayload, timeout300) resp.raise_for_status() return resp.json()调用工作流# 文件路径ai-to-earn-demo/workflows/full_chain.py from config.api_client import DifyClient client DifyClient( base_urlos.getenv(DIFY_BASE_URL, https://your-dify-host), api_keyos.getenv(DIFY_WORKFLOW_KEY, app-xxxxxxxx), ) result client.run_workflow( inputs{ direction: AI智能体的技术落地, platforms: [csdn, xiaohongshu], use_analysis: false, } ) print(result.get(data))需要说明的是Dify API 的响应结构在不同版本中可能存在差异实际字段名请以你部署版本 Swagger 文档为准。上面代码是调用思路演示不是固定不变的模板。8.4 运行验证与预期结果工作流运行成功后你会得到类似下面的结构化响应{ workflow_run_id: xxx, status: succeeded, outputs: { csdn_version: { title: 用四个AI智能体跑通内容全链路架构设计与实践, content: ## 背景..., seo: { title: AI智能体内容生产全链路教程, description: 从选题到发布再到数据分析的完整方案, keywords: [AI Agent, 多智能体, Dify] } }, xiaohongshu_version: { title: 四个AI智能体帮我搞定一周内容越用越香, content: 姐妹们..., tags: [#AI工具, #智能体, #内容创作] } } }验证时可以重点检查三件事每个平台版本是否生成成功字段结构是否完整平台风格区分是否明显。如果多个平台结果差异不大说明 Agent 3 的提示词约束力度不够需要增加平台风格参考。9. 常见问题与排查思路在实际运行过程中最容易出问题的不是“模型能力不足”而是编排细节不到位。下面整理了一份高频问题清单。问题现象常见原因解决思路Agent 1 返回的不是 JSON提示词约束不够强增加“只输出 JSON”的强约束并在下游增加 JSON 解析异常处理Agent 2 生成的文章内容空洞选题报告中的素材不足检查 Agent 1 的搜索工具是否生效知识库召回数量是否过少多平台适配结果高度雷同Agent 3 缺少平台风格参考为每个平台维护独立的风格说明文档并挂载到知识库工作流运行超时模型生成长文本耗时过长拆分 Agent 2 的生成任务或改用更快的模型API 调用返回 401API Key 配置错误检查app-前缀是否完整确认 Key 是否在有效期Agent 4 分析结论不准确样本数据量少或字段理解错误在知识库中补充字段说明增加数据量变量传递后内容被截断上下文长度达到模型上限优先精简输入或选择支持更长上下文的模型结果中出现编造的链接模型幻觉在提示词中明确“链接必须来自搜索结果”并增加链接校验节点排查建议不要直接改大模型先看工作流的输入输出。把上一个节点的输出原样保存下来检查是否包含解析所需的关键字段。大部分问题都是数据传递和字段映射造成的而不是模型本身的问题。10. 最佳实践与工程建议10.1 安全与合规边界使用 AI 智能体自动生成内容时必须考虑两个边界。第一内容版权风险。AI 生成的内容可能与其他文章高度相似发布前建议做去重检测涉及引用他人观点时明确标注来源。不要抱着“AI 生成内容无需负责”的心态账号权重和合规风险最终还是由运营者承担。第二数据安全边界。如果内容链路中涉及企业内部资料或用户隐私数据不要直接上传到云端模型服务。可以先做脱敏再进入智能体流程涉及数据库操作时严格遵循最小权限原则只开放必要字段的读取权限。10.2 成本与性能控制多智能体链路每次运行会消耗多次模型调用成本是单次对话的数倍。建议从三个角度控制成本。一是模型分级。简单环节如格式转换使用较廉价的模型创意要求高的环节如选题和正文使用更强模型。不要所有 Agent 都用同一个顶级模型。二是缓存策略。对于固定平台的格式转换结果、常见选题的素材聚合结果可以设置缓存避免重复调用。三是失败重试机制。不要把工作流变成无限重试的循环建议每个节点最多重试两次失败后进入人工处理队列避免异常流量造成成本飙升。10.3 质量与人工审核自动化不等于无人化。内容全链路中至少保留两个人工审核节点第一个节点在选题报告生成后人工确认选题方向是否符合账号定位第二个节点在内容发布前人工检查正文事实、代码示例和平台格式。完全去掉人工审核可能会带来短期产出提升但长期看账号内容质量的稳定性会下降。更推荐的做法是机器生产 80 分的基础内容人工用 20% 的精力把它提升到 90 分。10.4 可持续迭代内容生产链路不是一次配好就不管了。平台规则在变用户偏好也在变。建议每月做一次链路 review重点看三个方面各 Agent 的提示词是否还能满足当前平台规范知识库是否需要补充新的爆文和行业报告Agent 4 的反馈是否有效指导了选题迭代。另外可以把每次运行的工作流日志保存下来积累到一定量后用数据判断哪个环节最值得优化。通常来说优先优化瓶颈环节而不是平均用力。写在最后四个 AI 智能体跑通内容全链路本质上是把内容生产拆成“可独立优化”的专业环节再用工作流把环节串起来。它不是一篇讲“AI 替代人”的文章而是讲“如何让人从重复劳动中解放出来把精力放在真正需要判断力的地方”。动手建议先从最小版本开始只搭 Agent 1 和 Agent 2跑通“选题到初稿”的链路稳定后再加 Agent 3 做平台适配最后接入 Agent 4 形成数据闭环。每一步都跑熟再往下一步走比一次性搭完四个 Agent 更容易定位问题。你可以接着尝试把工作流接入定时任务每天自动生成一批选题或者把分析报告接入飞书/钉钉机器人让团队每周一早上自动收到内容复盘。内容自动化的想象空间不小先跑通第一个闭环后面就顺了。 用四个AI智能体跑通内容全链路：从选题到数据闭环的自动化实践
大家在内容创作时应该都有过类似体验素材找了一上午文章改了七八遍发布后数据平平一周后再复盘发现当初的选题方向本身就偏了。更麻烦的是这些环节彼此孤立选题、写作、分发、数据复盘之间没有形成反馈闭环导致每次创作几乎都是从零开始。如果能把 AI 智能体AI Agent引入到内容生产的完整链路中让四个各司其职的智能体分别负责选题调研、内容创作、平台适配、数据分析并通过工作流串联起来整个流程就能变成一条可复用、可监控、可迭代的自动化流水线。本文将围绕“AiToEarn”的思路完整拆解四个 AI 智能体的分工设计、平台搭建、提示词模板、工作流编排与 Python 调用示例帮你从零落地一套内容全链路自动化方案。本文适合以下读者想用 AI 提升内容产能的新媒体运营、正在做内容中台的技术开发、对多智能体协作感兴趣的大模型应用开发者。读完你会理解四个智能体各自的职责边界能在 Dify 平台上搭建完整工作流也能用代码方式调用智能体 API 实现批量生产。1. 背景为什么内容全链路需要“多智能体协作”1.1 单 Agent 的局限早期的 AI 内容生产往往是“一个对话框完成所有事”让大模型写文章、起标题、生成摘要、找选题。这种方式在简单场景下确实能用但一旦进入正式的创作流程就会暴露很多问题。一个模型实例同时处理选题调研、素材收集、正文撰写、平台适配容易导致提示词上下文过长。当 prompt 超过一定长度后模型会遗忘前文指令输出质量明显下降同时把“搜索实时信息、查数据库、读平台规范、格式化输出”全部塞进同一个 Agent工具调用逻辑也会变得混乱排错时难以定位问题到底出在哪一步。更关键的是单 Agent 不具备“分工后的专业化”。写技术教程的提示词和写小红书文案的提示词应该完全不同做数据分析的工具调用和做选题挖掘的工具调用也应该完全分离。强行放到一个 Agent 里只能得到“什么都会一点但什么都不精”的结果。1.2 内容全链路的四个核心环节我们把一条完整的内容生产线拆开通常包含四个步骤第一选题与素材调研。这一步要回答“写什么、有什么热点、有哪些可引用的资料”需要联网搜索能力、资讯抓取能力、知识库检索能力。第二内容创作与编辑。这一步要完成文章初稿、标题、摘要、段落结构、内容润色需要稳定的大模型写作能力以及可配置的输出模板。第三多平台适配与发布。同样的内容发布到公众号、知乎、掘金、小红书格式和风格完全不同需要做标题改写、正文分节、标签生成、SEO 关键词提取。第四数据分析与优化。内容发布后要持续跟踪阅读量、收藏量、转化率分析哪类选题表现更好再把结论反馈到下一步选题形成闭环。把这四个环节交给四个不同的 AI 智能体每个智能体只负责一件专业的事配合工作流引擎实现状态流转和数据传递整体系统的稳定性和可维护性都会大幅提升。1.3 AiToEarn 思路下的价值所谓“AiToEarn”本质上不是让用户不劳动而是通过 AI 智能体把重复性工作自动化让人把精力集中在选题判断、内容审核和策略决策上。这样做的好处有三点一是内容产能提升原来一天只能产出一篇文章现在可以在智能体辅助下完成多平台矩阵内容二是质量可控每个环节都有独立 Agent 和独立提示词调优某个环节不会影响其他环节三是数据可闭环第四个智能体把复盘结论自动反馈给第一个智能体选题会越来越贴近用户真实需求。2. 整体架构设计2.1 四个智能体的职责定义在正式搭建之前我们先把四个智能体命名清楚方便后面配置工作流时引用。智能体名称核心职责关键工具Agent 1选题调研员热点挖掘、选题评估、素材收集联网搜索、RSS 抓取、知识库Agent 2内容创作员文章撰写、摘要提炼、标题优化大模型、结构化输出、模板库Agent 3平台适配员多平台格式转换、SEO 优化、标签生成平台规范库、关键词工具Agent 4数据分析员数据采集、指标计算、策略报告数据接口、Excel 导出、图表这里要注意不同 Agent 之间不建议共用同一个系统提示词因为各自的“专业身份”差异太大。Dify 等智能体平台允许为每个 Agent 独立配置人设、工具和知识库这是多智能体落地的基础。2.2 数据流转与协作链路四个智能体之间的协作不是“一个调用一个”的链式传递而是带有反馈回路的循环结构。主链路是Agent 1 输出选题报告 → Agent 2 根据选题报告生成正文 → Agent 3 把正文转换为不同平台版本 → Agent 4 采集发布后的数据并生成分析报告。反馈链路是Agent 4 的分析结论回传给 Agent 1Agent 1 在下一轮选题时参考上一轮高曝光、高转化的话题特征从而实现选题策略的自适应进化。为了让数据能够在不同智能体之间顺畅流转每个智能体的输出建议采用 JSON 结构化格式。比如 Agent 1 输出{ topic: AI智能体在多平台内容生产中的落地实践, angle: 四智能体协作架构, keywords: [AI Agent, 多智能体, Dify], materials: [链接1, 链接2], suggested_title: 用四个AI智能体跑通内容全链路我总结了一套可复用的工作流 }后续 Agent 2 可以直接读取这些字段而不需要再从长文本中重新解析。2.3 技术选型建议实现多智能体工作链路的方案有很多这里提供三种常见路线第一种纯平台路线。使用 Dify、Coze 这类可视化智能体平台通过拖拽节点完成 Agent 编排。优点是上手快、调试直观、内置知识库和工具插件适合运营人员和初级开发者。第二种代码路线。使用 LangChain、LangGraph 或 Spring AI 等框架把四个 Agent 写成 Python/Java 类通过代码控制流程。优点是灵活、可定制性强适合需要深度集成到业务系统的开发者。第三种混合路线。用 Dify 搭建智能体和工作流对外暴露 API再用 Python/Java 编写调度脚本定时触发或响应事件调用。这是目前企业落地最常见的做法既保留了可视化调试的便利性又具备外部系统集成能力。本文接下来将以混合路线为主平台部分以 Dify 为例代码部分使用 Python 调用 API 完成串联。3. 环境准备与基础配置3.1 部署 Dify 智能体平台Dify 是一个开源的大模型应用开发平台支持知识库、Agent、工作流等核心能力。你可以选择云端版本也可以在自己的服务器上通过 Docker 部署社区版。Docker 部署方式如下先准备一个项目目录例如dify-agent-demo然后在目录中创建docker-compose.yaml并启动服务mkdir -p dify-agent-demo cd dify-agent-demo curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml cp docker-compose.yaml docker-compose.yaml.bak docker compose up -d启动后通过浏览器访问http://localhost按引导完成管理员账号初始化。首次部署需要拉取多个镜像耗时取决于网络环境。版本变化较快请以官方仓库最新文档为准。如果只是想快速体验注册 Dify 云端服务也可以功能差别不大本文重点演示配置思路部署方式不影响后续操作。3.2 接入大模型 API在 Dify 管理后台的“模型供应商”页面可以接入各个大模型服务商。国内用户常用的有通义千问、DeepSeek、智谱 GLM、百度千帆等基本都提供 OpenAI 兼容的接口形式。配置时重点确认三件事一是 API Key 从哪个服务商获取建议使用单独的 Key 并在环境变量中保存不要直接写在代码仓库里。二是模型名称要与服务商实际提供的模型一致。以 DeepSeek 为例通常可以填写类似deepseek-chat的模型标识。三是确认平台支持的功能类型比如 Agent 流程需要工具调用能力就要选择支持 function calling 的模型而不是纯文本对话模型。如果你同时测试多个模型建议统一命名规范例如把模型名维护在配置文件中避免后期切换时还要改多处代码。3.3 准备知识库与素材库内容生产链路中Agent 1 和 Agent 2 比较依赖知识库。可以提前把以下内容导入 Dify 知识库历史高阅读量文章作为选题和风格的参考素材。行业报告、产品文档用于丰富内容素材。平台运营规范例如公众号正文格式、知乎回答排版规范供 Agent 3 适配时检索。上传文档后Dify 会做文本分段和向量化。分段长度建议按默认或适当缩短例如每段 300 到 500 字符便于检索命中。知识库命名建议与用途对应例如“历史爆文库”“平台规范库”“产品素材库”。3.4 示例项目结构为了方便后续代码调用建议创建如下项目结构ai-to-earn-demo/ ├── config/ │ ├── settings.py # 统一配置 API 地址、Key、模型名 │ └── agent_config.json # 四个 Agent 的应用 ID 配置 ├── agents/ │ ├── agent1_research.py # 调用选题调研智能体 │ ├── agent2_write.py # 调用内容创作智能体 │ ├── agent3_adapt.py # 调用平台适配智能体 │ └── agent4_analyze.py # 调用数据分析智能体 ├── schemas/ │ └── topic_schema.json # 数据结构定义 ├── workflows/ │ └── full_chain.py # 编排完整链路 └── requirements.txt后面第 8 节的代码会按这个结构给出。4. Agent 1选题与素材调研智能体4.1 工作流程设计选题调研智能体承担整个链条的“输入口”。它的工作流程大致为第一步接收用户输入的方向或指令例如“生成 5 个关于 AI 智能体的技术选题”。第二步调用联网搜索工具获取近一周的行业热点、讨论趋势和热门问题。可以接入搜索引擎插件或 RSS 工具。第三步检索知识库中的历史爆文分析哪些选题方向过去表现较好。第四步把热点信息、历史数据、素材链接整合成结构化选题报告。4.2 提示词模板在 Dify 中创建第一个 Agent命名为“选题调研员”系统提示词可以这样设计你是一名资深的内容策略分析师擅长从海量信息中挖掘高潜力的内容选题。 你的任务 1. 根据用户给出的领域方向结合实时搜索结果提炼 3-5 个有差异化角度的选题。 2. 每个选题必须说明目标读者、内容切入点、差异化优势、预计可引用的资料。 3. 输出格式必须为 JSON包含 topic、angle、keywords、target_audience、materials 字段。 4. 优先选择讨论热度上升中、但搜索竞争度不高的细分话题。 注意 - 只输出 JSON 内容不要输出解释性文字。 - 如果没有检索到足够信息明确标注信息不足不要编造。 - materials 中的链接必须来自真实搜索结果。这段提示词的关键点在于“只输出 JSON”和“没有检索到就标注不足”这两个约束可以避免后续 Agent 收到脏数据。4.3 工具与知识库配置在 Agent 设置里为“选题调研员”启用联网搜索工具并关联“历史爆文库”知识库。知识库检索的召回数量可以设置为 5 到 10 条召回分数阈值建议不低于 0.5避免低相关文档污染模型判断。如果发现检索结果不准确优先检查文档分段是否合理、关键词是否过于抽象。该 Agent 输出结果示例{ topic: 多智能体协作的内容生产实践, angle: 从单Agent到四Agent协作的架构演进, keywords: [多智能体, 内容生产, Agent协作], target_audience: 技术博主、内容运营、大模型应用开发者, materials: [ https://example.com/dify-docs, https://example.com/agent-workflow ] }5. Agent 2内容创作与编辑智能体5.1 结构化输入与输出Agent 2 接收 Agent 1 的选题报告它不需要重新搜索而是专注于写作。为了保证输出质量建议给 Agent 2 设置两段式流程第一段根据选题报告生成文章大纲。大纲要细到每个章节的核心观点和可展开的素材。第二段根据大纲生成完整正文。正文使用 Markdown 格式包含标题层级、代码块、列表等结构化元素。拆成两段的原因是直接让模型从“一个选题”生成“一篇长文”容易导致结构松散先写大纲再展开模型相当于先做规划再做执行输出质量会稳定很多。5.2 提示词模板在 Dify 中创建第二个 Agent命名为“内容创作员”系统提示词示例你是一名技术内容创作者擅长将复杂的技术概念写成通俗易懂的文章。 你会收到一份选题调研报告JSON 格式请按以下步骤完成创作 第一步根据 topic、angle、keywords 生成文章大纲包含引言、核心章节、示例代码、常见问题、总结五个部分。 第二步按照大纲撰写完整正文。要求 - 使用 Markdown 格式H2 标题用 ##H3 标题用 ###。 - 每个技术概念先用通俗语言解释再补充技术细节。 - 代码示例必须带语言标签如 python。 - 文章开头要说明适用读者结尾要给出下一步建议。 第三步为文章生成 3 个备选标题和 1 段 150 字以内的摘要。 输出格式 {summary: 文章摘要, titles: [标题1, 标题2, 标题3], content: 文章正文} 注意 - 不要编造事实、数据、API 名称。 - 如果选题报告中材料不足明确说明需要补充哪些材料。 - content 中的正文必须是完整可发布的文章不能是提纲。这个提示词有几个设计细节要求模型不要编造事实是为了避免常见的大模型幻觉问题要求输出 Markdown 正文是为了后续 Agent 3 做格式转换时更省事。5.3 质量检查节点虽然我们用了智能体但完全交给模型“裸奔”仍然有风险。推荐在 Agent 2 后增加一个“内容质量检查”节点可以通过 Dify 工作流中的条件判断或代码节点实现。检查规则可以包括正文长度是否大于 800 字。是否包含至少两个代码块或列表。是否包含备选标题和摘要。结尾是否有明确的下一步建议。如果检查不通过可以让工作流把内容返回 Agent 2 重新生成最多重试两次超过两次则标记为人工处理。这个设计能防止小概率的低质量内容流入发布环节。6. Agent 3多平台适配与发布智能体6.1 多平台差异适配同样的文章直接复制粘贴到所有平台并不是好方案。每个平台都有固定的阅读习惯和格式要求。公众号正文更强调排版和开头引入段落不能太长知乎回答需要论点清晰、结构严谨最好有“先说结论”小红书笔记偏向口语化、重情感表达、强调真实体验技术社区如掘金、CSDN 则偏好代码清晰、技术点密集、有可复现的操作步骤。Agent 3 的作用就是根据目标平台把 Agent 2 生成的正文转换为对应风格的版本。6.2 提示词模板在 Dify 中创建第三个 Agent命名为“平台适配员”系统提示词示例你是一名多平台内容运营专家熟悉公众号、知乎、小红书、掘金、CSDN 等主流内容平台的发布规范与用户偏好。 你会收到一篇 Markdown 格式的文章正文以及目标平台名称。请完成以下转换 1. 调整标题根据平台风格改写标题公众号标题要吸引点击知乎标题要突出专业感小红书标题要口语化、带情绪词。 2. 调整正文结构拆分过长的段落公众号版本每段不超过 150 字小红书版本开头直接给结论多用换行和表情符号。 3. 生成平台标签小红书版本输出 5-10 个话题标签格式为 #关键词。 4. 提取 SEO 关键词技术平台版本输出 title、description、keywords 三个字段用于站点优化。 输出格式 {platform: 平台名称, title: 适配后标题, content: 适配后正文, tags: [标签], seo: {title: SEO标题, description: SEO描述, keywords: [关键词]}} 注意 - 保持原文事实不变只做格式和风格调整。 - 不删除代码示例不改变代码内容。 - 如果原文质量过低简单说明问题并原样返回。调用时通过工作流的变量传入目标平台名称例如把platform设置为xiaohongshu或csdn。如果需要同时发布到多个平台可以让一个内容并行进入多个 Agent 3 实例每个实例处理一个平台。6.3 发布队列与格式转换Agent 3 输出的是格式化文本真正发布时还需要转换成平台要求的格式比如 plain text、HTML 或带指定标签的文本。这里建议用一个队列任务来管理发布动作。简单实现可以基于 Redis 列表把 Agent 3 的输出 push 到队列中再由发布任务消费。复杂场景可以引入 Celery 或 XXL-Job但刚开始不建议过度设计先把链路跑通更重要。小规模场景下也可以直接把适配后的内容保存到本地文件人工复制发布。这样能在初始阶段建立内容质量基线。7. Agent 4数据分析与优化智能体7.1 数据源接入内容发布之后要跟踪数据表现。常见的数据来源包括各平台后台导出的 Excel、第三方数据平台的 API、自建网站的访问日志。在 Dify 中创建第四个 Agent命名为“数据分析员”并上传最近一周的数据样本让 Agent 理解数据字段含义。字段可以包括发布日期、平台名称、标题、阅读量、点赞量、收藏量、评论量、转发量、转化率。如果平台没有开放 API最简单的做法是每周手动导出 CSV再上传到知识库或直接在对话中作为附件传给 Agent。7.2 指标计算与报告生成Agent 4 的核心价值不是“展示数字”而是从数字中提炼结论。例如它可以计算哪类选题的平均阅读量最高。哪个平台的内容表现波动最大。标题中包含哪些关键词时打开率更高。发布时间与阅读量之间的分布关系。系统提示词示例你是一名内容数据分析师擅长从数据中定位问题并提出可执行的优化建议。 你会收到一张内容表现数据表请完成以下任务 1. 按选题方向聚合阅读量、收藏量、转化率按表现排序。 2. 对比不同平台的互动率找出最有效的内容分发渠道。 3. 分析标题关键词对打开率的影响提炼出 Top 5 的高效关键词。 4. 输出结构化分析报告 JSON包含 best_topics、best_platforms、keyword_insights、action_items 四个字段。 action_items 字段必须给出下个周期可以直接执行的 3 条建议例如“优先创作 xx 方向内容”“在小红书增加 xx 类型选题”“标题前 15 个字尽量包含 xx 关键词”。 注意 - 不要只罗列数据要给出结论。 - 如果数据量不足明确说明结论置信度有限。7.3 反馈闭环设计Agent 4 的分析报告不只是一份“给人看”的周报。在自动化链路中它应该成为 Agent 1 下一轮选题的输入。实现方式有两种一种是自动回填。通过 Python 脚本把 Agent 4 的输出存在一个feedback.json文件里Agent 1 启动时自动读取这个文件作为选题参考。另一种是人工确认后回填。数据分析结果先发送到团队协作工具如钉钉、飞书、企业微信人工确认后再写入 Agent 1 的知识库或上下文。建议前期采用第二种方式。完全自动化的闭环可能出现“数据冷启动 模型幻觉”导致的错误归因人工确认可以让反馈质量更高。8. 用 Dify Workflow 串起完整链路8.1 工作流节点设计在 Dify 中创建一个新工作流命名为“内容全链路生产”把四个 Agent 作为节点串联起来。核心节点如下开始节点接收用户输入包括内容方向、目标平台、是否启用数据分析。Agent 1 节点调用“选题调研员”。条件分支节点判断 Agent 1 是否成功返回 JSON不成功则结束并返回错误信息。Agent 2 节点调用“内容创作员”输入为 Agent 1 的 JSON。质量检查节点用代码节点校验 content 字段长度与完整性。Agent 3 节点根据目标平台数量并行调用“平台适配员”多个实例。结束节点汇总各平台适配结果。8.2 变量传递与分支规则工作流中的变量命名要统一建议使用 snake_case例如topic_report、article_content、platform_version。条件分支规则示例判断topic_report是否包含topic字段以及article_content的字符长度是否大于 800。如果判断失败可以输出“需要人工干预”的提示而不是直接继续向下传递避免下游 Agent 处理垃圾数据。8.3 Python 调用 Dify API 实现自动化可视化工作流搭好后我们可以用 Python 脚本调用 Dify 的 API 来触发整个流程。这样可以结合定时任务、消息队列或 Web 事件。先安装依赖pip install requests编写基础调用函数# 文件路径ai-to-earn-demo/config/api_client.py import os import requests class DifyClient: def __init__(self, base_url: str, api_key: str): self.base_url base_url.rstrip(/) self.api_key api_key self.headers { Authorization: fBearer {api_key}, Content-Type: application/json, } def run_workflow(self, inputs: dict, user: str content-bot): url f{self.base_url}/v1/workflows/run payload { inputs: inputs, response_mode: blocking, user: user, } resp requests.post(url, headersself.headers, jsonpayload, timeout300) resp.raise_for_status() return resp.json()调用工作流# 文件路径ai-to-earn-demo/workflows/full_chain.py from config.api_client import DifyClient client DifyClient( base_urlos.getenv(DIFY_BASE_URL, https://your-dify-host), api_keyos.getenv(DIFY_WORKFLOW_KEY, app-xxxxxxxx), ) result client.run_workflow( inputs{ direction: AI智能体的技术落地, platforms: [csdn, xiaohongshu], use_analysis: false, } ) print(result.get(data))需要说明的是Dify API 的响应结构在不同版本中可能存在差异实际字段名请以你部署版本 Swagger 文档为准。上面代码是调用思路演示不是固定不变的模板。8.4 运行验证与预期结果工作流运行成功后你会得到类似下面的结构化响应{ workflow_run_id: xxx, status: succeeded, outputs: { csdn_version: { title: 用四个AI智能体跑通内容全链路架构设计与实践, content: ## 背景..., seo: { title: AI智能体内容生产全链路教程, description: 从选题到发布再到数据分析的完整方案, keywords: [AI Agent, 多智能体, Dify] } }, xiaohongshu_version: { title: 四个AI智能体帮我搞定一周内容越用越香, content: 姐妹们..., tags: [#AI工具, #智能体, #内容创作] } } }验证时可以重点检查三件事每个平台版本是否生成成功字段结构是否完整平台风格区分是否明显。如果多个平台结果差异不大说明 Agent 3 的提示词约束力度不够需要增加平台风格参考。9. 常见问题与排查思路在实际运行过程中最容易出问题的不是“模型能力不足”而是编排细节不到位。下面整理了一份高频问题清单。问题现象常见原因解决思路Agent 1 返回的不是 JSON提示词约束不够强增加“只输出 JSON”的强约束并在下游增加 JSON 解析异常处理Agent 2 生成的文章内容空洞选题报告中的素材不足检查 Agent 1 的搜索工具是否生效知识库召回数量是否过少多平台适配结果高度雷同Agent 3 缺少平台风格参考为每个平台维护独立的风格说明文档并挂载到知识库工作流运行超时模型生成长文本耗时过长拆分 Agent 2 的生成任务或改用更快的模型API 调用返回 401API Key 配置错误检查app-前缀是否完整确认 Key 是否在有效期Agent 4 分析结论不准确样本数据量少或字段理解错误在知识库中补充字段说明增加数据量变量传递后内容被截断上下文长度达到模型上限优先精简输入或选择支持更长上下文的模型结果中出现编造的链接模型幻觉在提示词中明确“链接必须来自搜索结果”并增加链接校验节点排查建议不要直接改大模型先看工作流的输入输出。把上一个节点的输出原样保存下来检查是否包含解析所需的关键字段。大部分问题都是数据传递和字段映射造成的而不是模型本身的问题。10. 最佳实践与工程建议10.1 安全与合规边界使用 AI 智能体自动生成内容时必须考虑两个边界。第一内容版权风险。AI 生成的内容可能与其他文章高度相似发布前建议做去重检测涉及引用他人观点时明确标注来源。不要抱着“AI 生成内容无需负责”的心态账号权重和合规风险最终还是由运营者承担。第二数据安全边界。如果内容链路中涉及企业内部资料或用户隐私数据不要直接上传到云端模型服务。可以先做脱敏再进入智能体流程涉及数据库操作时严格遵循最小权限原则只开放必要字段的读取权限。10.2 成本与性能控制多智能体链路每次运行会消耗多次模型调用成本是单次对话的数倍。建议从三个角度控制成本。一是模型分级。简单环节如格式转换使用较廉价的模型创意要求高的环节如选题和正文使用更强模型。不要所有 Agent 都用同一个顶级模型。二是缓存策略。对于固定平台的格式转换结果、常见选题的素材聚合结果可以设置缓存避免重复调用。三是失败重试机制。不要把工作流变成无限重试的循环建议每个节点最多重试两次失败后进入人工处理队列避免异常流量造成成本飙升。10.3 质量与人工审核自动化不等于无人化。内容全链路中至少保留两个人工审核节点第一个节点在选题报告生成后人工确认选题方向是否符合账号定位第二个节点在内容发布前人工检查正文事实、代码示例和平台格式。完全去掉人工审核可能会带来短期产出提升但长期看账号内容质量的稳定性会下降。更推荐的做法是机器生产 80 分的基础内容人工用 20% 的精力把它提升到 90 分。10.4 可持续迭代内容生产链路不是一次配好就不管了。平台规则在变用户偏好也在变。建议每月做一次链路 review重点看三个方面各 Agent 的提示词是否还能满足当前平台规范知识库是否需要补充新的爆文和行业报告Agent 4 的反馈是否有效指导了选题迭代。另外可以把每次运行的工作流日志保存下来积累到一定量后用数据判断哪个环节最值得优化。通常来说优先优化瓶颈环节而不是平均用力。写在最后四个 AI 智能体跑通内容全链路本质上是把内容生产拆成“可独立优化”的专业环节再用工作流把环节串起来。它不是一篇讲“AI 替代人”的文章而是讲“如何让人从重复劳动中解放出来把精力放在真正需要判断力的地方”。动手建议先从最小版本开始只搭 Agent 1 和 Agent 2跑通“选题到初稿”的链路稳定后再加 Agent 3 做平台适配最后接入 Agent 4 形成数据闭环。每一步都跑熟再往下一步走比一次性搭完四个 Agent 更容易定位问题。你可以接着尝试把工作流接入定时任务每天自动生成一批选题或者把分析报告接入飞书/钉钉机器人让团队每周一早上自动收到内容复盘。内容自动化的想象空间不小先跑通第一个闭环后面就顺了。