Pandasolo / ai / builder
all posts
AI技术 · ZH

用智能体框架搭建自媒体内容创作平台：从架构到落地

May 8, 2026·28 min read·by PandaTalk

用智能体框架搭建自媒体内容创作平台：从架构到落地

对自媒体创作者而言，最消耗精力的工作往往不是写作本身，而是写作之外的一切——追踪信息源、筛选有价值的内容、将素材加工成不同格式、在多个平台发布、追踪数据反馈。这些环节高度重复，逻辑清晰，天然适合用智能体（Agent）来自动化。

这篇文章完整设计一套基于智能体框架的自媒体内容创作与学习平台。整个系统由八个模块组成：长期目标设定、网络内容嗅探、权威内容源探测、内容分析器、内容处理器、发布管理后台、推送通知、创作者审核与发布器。每个模块对应一个或多个专职智能体，各司其职，通过事件驱动的方式协同运转。

文章会从架构设计讲到技术选型，再到每个模块的具体实现方案。目标是写清楚"怎么建"，而非停留在"可以建"。

系统总览：一条内容从发现到发布的完整链路

先看全貌。整个平台的数据流是一条单向管线，每个阶段有对应的智能体负责：

[定时触发 / RSS / Webhook]
        │
  ┌─────▼─────┐
  │ 嗅探智能体 │  ── 抓取、监听、聚合原始内容
  └─────┬─────┘
        │
  ┌─────▼─────┐
  │ 分析智能体 │  ── 去重、评分、提取核心论点
  └─────┬─────┘
        │
  ┌─────▼─────┐
  │ 处理智能体 │  ── 生成文章草稿 / 音频脚本 / 短内容
  └─────┬─────┘
        │
  ┌─────▼──────────┐
  │ 发布管理后台    │  ── 草稿存储、版本管理、排期
  └─────┬──────────┘
        │
  ┌─────▼──────────────┐
  │ 推送通知 → 创作者审核 │  ── 人类把关，交互式修改
  └─────┬──────────────┘
        │
  ┌─────▼─────┐
  │ 发布智能体 │  ── 多平台分发
  └─────┘

这条链路的设计原则有三条：

单向流动，各环节解耦。 每个智能体只关心自己的输入和输出，不直接调用其他智能体。它们通过消息队列（Redis Streams 或 Webhook）传递数据。一个环节出问题，不会阻塞其他环节。

人在关键节点介入。 系统自动完成从发现到成稿的全部工作，但发布前必须经过创作者审核。这条规则写死在架构里，没有"全自动发布"的捷径。

状态可追溯。 每条内容从被发现到最终发布，全程有日志。任何一个阶段的中间产物都可以回溯查看。

技术选型：框架、通信与存储

在进入各模块之前，先确定技术底座。

智能体框架的选择

当前主流的智能体框架各有侧重：

框架 核心特点 适用场景
CrewAI 角色驱动，任务链式传递，上手快 标准的多角色内容管线
LangGraph 图结构编排，内置状态检查点和回放 需要复杂分支逻辑和审计追踪的生产系统
Claude Agent SDK 原生 MCP 支持，托管执行环境 依赖 Claude 生态的项目
OpenAI Agents SDK 显式 Handoff 机制，原生 MCP 依赖 OpenAI 生态的项目

对于自媒体内容管线，CrewAI 是最务实的起点。它的角色-任务模型天然匹配"嗅探→分析→写作→发布"的线性流程，开发者可以在 30 分钟内搭出一个可运行的原型。如果后续需要更精细的流程控制（比如根据内容类型走不同的处理分支），再迁移到 LangGraph。

智能体之间的通信

智能体之间的数据传递有两种主流方案：

Redis Streams 适合大多数场景。它提供消息持久化、消费者组、消息回放，延迟在毫秒级。每个智能体从自己的 Stream 消费消息，处理完后将结果写入下一个 Stream。

Webhook 适合跨服务通信。当某些智能体部署在不同的服务器上（比如嗅探智能体跑在一台廉价 VPS 上，处理智能体跑在有 GPU 的机器上），用 Webhook 做事件通知最简单。

两者可以混合使用：同一台机器内部用 Redis Streams，跨机器用 Webhook。

存储层

存储类型 技术选择 用途
结构化数据 PostgreSQL 文章元数据、发布记录、用户配置
向量数据 Qdrant 或 pgvector 内容去重、语义检索、RAG
文件存储 S3 / Cloudflare R2 图片、音频文件、PDF
缓存 Redis 消息队列、临时状态、去重指纹

如果想控制复杂度，pgvector（PostgreSQL 的向量扩展）可以让你用一个数据库同时解决结构化存储和向量检索的需求。当内容规模超过百万条时，再考虑独立部署 Qdrant。

模块一：长期目标设定

这个模块的职责是定义"系统应该关注什么"。它不是一个自动运行的智能体，而是一份结构化的配置文件，所有其他智能体都从中读取自己的工作参数。

目标文件的结构

用一份 YAML 或 JSON 文件来描述创作者的长期规划：

creator_profile:
  name: "你的名字"
  positioning: "AI技术深度解读与应用实践"
  target_audience: "技术从业者、AI产品经理、独立开发者"
  tone: "专业但不学术，有观点但有论据"

content_pillars:
  - name: "AI 工程实践"
    keywords: ["agent", "RAG", "MCP", "prompt engineering", "LLM"]
    priority: high
    target_frequency: "每周 2 篇"

  - name: "开源项目分析"
    keywords: ["github trending", "open source", "developer tools"]
    priority: medium
    target_frequency: "每周 1 篇"

  - name: "行业趋势"
    keywords: ["funding", "acquisition", "product launch"]
    priority: low
    target_frequency: "每两周 1 篇"

platforms:
  - name: "X/Twitter"
    format: "thread"
    language: "en"
  - name: "微信公众号"
    format: "long_article"
    language: "zh"
  - name: "播客"
    format: "audio"
    language: "zh"

quality_criteria:
  min_source_authority: 0.7    # 信息源可信度阈值
  min_novelty_score: 0.5       # 内容新颖度阈值
  max_daily_articles: 3        # 每日最大产出量
  require_human_review: true   # 强制人工审核

这份配置驱动整个系统的行为：嗅探智能体根据 content_pillars 的关键词去采集，分析智能体根据 quality_criteria 做筛选，处理智能体根据 platforms 的格式要求生成不同版本的内容。

目标的动态调整

长期目标需要定期修订。可以设置一个月度复盘的定时任务：系统汇总过去 30 天的内容表现数据（阅读量、互动率、涨粉数），生成一份分析报告，推送给创作者。创作者据此决定是否调整内容方向或发布节奏。

这个复盘任务适合用 Claude Code Routines 来实现——设一个月度 Cron，让智能体自动生成报告。

模块二：网络内容嗅探

嗅探智能体是整个系统的入口，负责从互联网上持续采集原始内容。

三种采集策略

RSS 订阅监听。 最稳定的信息源。技术博客、学术预印本（arXiv）、官方公告（GitHub Changelog、Anthropic Blog）都提供 RSS。用一个定时任务每小时轮询一次，解析新条目，写入待分析队列。

主动爬取。 对不提供 RSS 的信息源，用爬虫定期抓取。推荐两个工具：

  • Firecrawl：托管服务，返回干净的 Markdown 格式，适合直接喂给 LLM。它有一个叫 FIRE-1 的导航智能体，能自主处理复杂的多页面网站。
  • Crawl4AI：开源自部署方案，Python 库，输出同样是 Markdown。它有一套"自适应智能"机制，能在多次抓取后学习到可靠的页面选择器，提升后续抓取的准确率。

社交媒体监听。 监控 X/Twitter 上特定关键词和账号的动态。X API 的 Basic 套餐（$100/月）支持搜索和流式推送。对于预算有限的创作者，可以用第三方工具（如 Typefully、Buffer）的 API 来间接获取数据，成本在 $12-99/月。

去重与预过滤

原始采集的数据量会远超创作者的处理能力。嗅探智能体需要在第一道关口做两件事：

内容指纹去重。 对每条内容计算哈希指纹（基于标题 + 正文前 500 字），存入 Redis。新内容入库前先查重，已存在的直接丢弃。

语义相似度去重。 哈希去重只能处理完全重复的内容。对于"多家媒体报道同一事件"这种情况，需要将内容转为向量，用余弦相似度检测。相似度超过 0.85 的内容只保留最早的一条。

经过去重后，剩余内容按时间戳排序，批量推送给分析智能体。

模块三：权威内容源探测

这个模块回答一个问题：我们采集到的内容，来源可信吗？

信息源评分体系

为每个信息源维护一个可信度评分（0-1），评分维度包括：

  • 机构权威性： 是否为官方博客、知名研究机构、主流技术媒体
  • 作者专业度： 作者在该领域的发表记录、引用次数、社交媒体影响力
  • 历史准确率： 该信息源过去发布的内容是否经得起验证
  • 时效性： 是一手信息还是二次转述

评分不需要完全自动化。初始阶段，创作者手动为常用信息源打分，建立一个基线。之后智能体根据后续验证结果（某信息源的内容是否被其他权威源引用或印证）动态调整评分。

新信息源的发现

除了维护已知信息源，系统还需要主动发现新的高质量信息源。具体做法：

  1. 分析已收录文章中的引用链接和参考文献，提取出现频率高的域名
  2. 对这些域名做初步评估（Alexa 排名、域名年龄、内容更新频率）
  3. 超过阈值的候选信息源推送给创作者确认，确认后加入监控列表

这个过程可以设为每周运行一次的后台任务。

模块四：内容分析器

分析智能体拿到去重后的原始内容，需要回答三个问题：这条内容值得写吗？核心论点是什么？应该怎么写？

价值评估

对每条内容生成一个综合评分，考量因素包括：

  • 话题相关度： 与 content_pillars 中定义的关键词和领域的匹配程度
  • 新颖度： 与向量数据库中已有内容的语义距离。如果库里已有大量相似主题的文章，评分降低
  • 时效性： 新闻类内容要求 24 小时内处理，技术解读类可以放宽到一周
  • 信息源可信度： 直接引用模块三的评分
  • 潜在影响力： 该话题在社交媒体上的讨论热度

综合评分低于目标文件中 min_novelty_score 阈值的内容直接归档，不进入后续流程。

核心论点提取

通过评估的内容，分析智能体需要提取结构化的摘要：

{
  "title": "原始标题",
  "source": "信息源",
  "source_authority": 0.85,
  "core_arguments": [
    "论点一：...",
    "论点二：...",
    "论点三：..."
  ],
  "key_data_points": [
    "数据一：...",
    "数据二：..."
  ],
  "suggested_angle": "从 X 角度切入，因为当前中文社区对此讨论较少",
  "suggested_format": "long_article",
  "suggested_platforms": ["微信公众号", "X/Twitter"],
  "related_content_ids": ["已有文章ID_1", "已有文章ID_2"]
}

related_content_ids 字段很关键——它告诉处理智能体，库里已有哪些相关文章可以参考或做系列关联。这依赖向量数据库的语义检索能力。

批量分析与优先级排序

分析智能体不是逐条处理，而是攒一批后集中分析。这样做的好处是可以在一批内容中做交叉比较，避免在同一个热门话题上重复产出。

每批分析完成后，按综合评分降序排列，取前 N 条（N 由 max_daily_articles 控制）推入处理队列。

模块五：内容处理器

处理智能体是系统中最核心的模块——它把分析结果转化为可发布的内容。

多格式生成

根据目标文件中定义的平台和格式，同一条素材可能需要生成多个版本：

长文章（微信公众号、博客）： 这是主力格式。处理智能体根据分析器提供的核心论点和写作角度，生成一篇 2000-5000 字的深度文章。它会参考 related_content_ids 中的已有文章，确保新文章与创作者已发布的内容保持风格一致、观点衔接。

推文串（X/Twitter）： 将长文章的核心内容压缩为 5-10 条推文的 Thread。每条推文控制在 280 字符以内，第一条必须有足够的信息密度来吸引读者展开全文。

音频脚本与音频生成： 为播客和音频内容准备。先生成口语化的音频脚本（比书面文章更短，节奏更紧凑），再调用 TTS 服务转为音频文件。

TTS 技术选型

音频生成的技术选择：

  • ElevenLabs： 当前表现最好的方案。Flash v2.5 模型延迟约 75ms，适合短内容。Multilingual v2 对中文的支持较好。支持声音克隆，创作者可以用自己的声音模型。
  • OpenAI TTS： gpt-4o-mini-tts 模型可以通过指令控制语气和节奏，与 OpenAI 的其他 API 共享计费体系，集成简单。
  • Qwen3-TTS： 阿里开源的中文 TTS 模型，中文语音质量高，可以本地部署，适合对成本敏感或对数据隐私有要求的场景。

推荐的组合是：英文内容用 ElevenLabs，中文内容用 Qwen3-TTS 本地部署，降低长期运营成本。

写作质量控制

处理智能体生成的初稿需要经过一轮自检：

  1. 事实核验： 文章中引用的数据点与原始素材核对，确保没有"幻觉"
  2. 风格一致性： 与目标文件中定义的 tone 对照，检查是否有偏离
  3. 格式规范： 检查 Markdown 格式、标题层级、标点符号等是否符合平台要求
  4. 原创度检测： 与原始素材做文本相似度比对，确保是改写而非复制

自检不通过的内容返回重新生成，最多重试两次。两次仍不通过的标记为"需人工处理"。

模块六：发布管理后台

管理后台是整个系统的控制中心，既是数据库，也是操作界面。

内容生命周期管理

每条内容在系统中有明确的状态流转：

discovered → analyzing → analyzed → writing → draft → reviewing → approved → scheduled → published → archived

后台存储每条内容在每个状态下的快照，支持回溯任何一个版本。用 PostgreSQL 存储元数据和状态，用 S3/R2 存储内容正文和媒体文件。

发布排期

自媒体运营有一个常见规律：不同平台的最佳发布时间不同，同一平台不同内容类型的最佳发布时间也不同。管理后台维护一个排期日历：

  • 微信公众号：工作日早上 8:00-9:00，或晚上 20:00-21:00
  • X/Twitter：UTC 时间 14:00-16:00（北美活跃时段）
  • 播客：每周固定时间发布新一期

创作者在审核通过内容后，可以手动指定发布时间，也可以让系统根据排期规则自动安排。

管理后台的实现方案

轻量级方案可以用 n8n（开源自部署的工作流引擎）作为可视化操作界面，配合 PostgreSQL 和 Redis 构建。n8n 提供了 400+ 集成，自带 Cron 触发器、Webhook 节点、以及基本的数据管理 UI，足够覆盖排期和状态管理的需求。

如果需要更定制化的界面，用 Retool 或 Appsmith（低代码内部工具平台）直接连接 PostgreSQL，快速搭建一个管理仪表盘。

模块七：推送通知

通知系统负责在关键节点通知创作者介入。

通知触发条件

事件 通知渠道 紧急程度
新草稿待审核 Slack / 飞书 普通
热点话题检测到 Slack / 短信 高
发布失败 Slack / 邮件 高
每日内容摘要 邮件 低
月度复盘报告 邮件 低
信息源异常（长时间无更新/大量 404） Slack 普通

技术实现

核心模式是 Webhook → 路由 → 多渠道分发。

每个智能体在完成任务后触发一个 Webhook，通知路由器根据事件类型和紧急程度，决定走哪个渠道：

  • Slack / 飞书： 日常工作通知的主渠道。用 Incoming Webhook 即可，无需复杂的 Bot 开发
  • 邮件： 低紧急度的汇总报告。用 SendGrid 或 Resend 的 API
  • 短信： 仅用于高紧急度事件（如热点话题检测，需要在数小时内产出内容）。用 Twilio API

通知内容要包含足够的上下文，让创作者无需打开管理后台就能做初步判断。例如，一条"新草稿待审核"的 Slack 通知应该包含：文章标题、素材来源、综合评分、摘要前 200 字、以及一个直接跳转到审核界面的链接。

模块八：创作者审核与交互式编辑

这是人机协作的核心环节。系统完成了从发现到成稿的全自动流程，但发布的决定权始终在创作者手上。

审核界面的设计

审核界面需要展示三层信息：

第一层：概览。 标题、来源、综合评分、建议发布平台。创作者可以快速浏览，用"通过 / 修改 / 驳回"三个按钮做初步分类。

第二层：对比。 左边显示原始素材（或素材的结构化摘要），右边显示生成的文章。创作者可以检查是否有事实偏差或过度演绎。

第三层：编辑。 一个富文本编辑器，支持直接修改文章内容。修改后的版本自动保存为新版本，原始 AI 生成版本保留不变。

交互式修改

创作者不只是做"通过/驳回"的二元判断，还可以给出修改指令。例如：

  • "第三段的论证太弱，用 X 的数据替换"
  • "整体语气偏保守，调整得更有观点一些"
  • "增加一个关于 Y 的类比来解释 Z 概念"

这些指令发送给处理智能体，它会基于修改意见重新生成对应部分，保持其余内容不变。修改后的版本再次推送给创作者审核，形成一个"生成 → 审核 → 修改 → 再审核"的迭代循环。

技术实现

交互式审核的技术要求是 持久化状态 + 异步等待。智能体生成草稿后进入等待状态，可能几分钟后审核完成，也可能几天后创作者才有空处理。

Cloudflare Agents SDK 提供了 waitForApproval() 方法，支持长达数周的异步等待。LangGraph 的检查点机制也可以实现同样的效果——在审核节点暂停图的执行，等到人类输入后继续。

如果用更轻量的方案，可以把待审核内容写入数据库，状态设为 reviewing。创作者通过管理后台操作（通过/修改/驳回），操作结果写回数据库，触发下游智能体继续处理。

模块九：发布器

发布智能体是管线的最后一站，负责将审核通过的内容发布到各个目标平台。

各平台发布方案

X/Twitter： 官方 API 支持程序化发帖，但需要注意几条规则——Bot 账号必须标注，禁止自动关注/取关，禁止批量互动。Basic 套餐 $100/月，如果只需要发帖功能，第三方工具（Typefully、Buffer）更经济。对于 Thread 格式，需要按顺序发送多条推文并维护回复链。

微信公众号： 这是中文创作者最重要的平台，但也是自动化程度最低的。2025 年 7 月之后，微信取消了未认证个人账号的发布 API 权限。目前可行的方案是：通过素材管理 API 上传图文内容，通过草稿 API 创建草稿，最后一步（点击发布）需要创作者在微信后台手动完成。

具体流程：

  1. Markdown 转微信公众号 HTML（内联 CSS，处理图片上传至微信素材库）
  2. 调用草稿接口创建草稿
  3. 通知创作者去微信后台点击发布

播客平台： PodClaw 提供了专门面向智能体的 API——一次 POST 请求就能创建剧集、生成音频、分发到 Apple Podcasts 和 Spotify。RSS.com 在 2026 年 2 月也开放了公共 API，支持创建剧集、上传音频、生成字幕。另一个选择是 airloom.fm，免费播客托管服务，上传音频后自动生成 RSS Feed。

YouTube： YouTube Data API v3 支持视频上传和元数据管理（标题、描述、标签、缩略图、定时发布）。如果内容是音频配图的形式，需要先用 FFmpeg 将音频和封面图合成为视频文件，再上传。注意错开上传时间，避免触发速率限制。

Medium / 博客： Medium 的官方 API 已停止维护，只支持创建文章，不支持更新。功能有限但勉强可用。自有博客（Hugo、Next.js 等静态站点）直接写文件到仓库，触发 CI/CD 自动部署。

发布后处理

内容发布后，发布智能体还需要完成两件事：

  1. 记录发布结果： 将各平台返回的文章 URL、发布时间、初始数据写入数据库
  2. 启动监测： 设定 24 小时和 72 小时两个数据采集点，记录阅读量、点赞、评论、转发等指标，写入内容表现数据库，供月度复盘使用

落地路径：分阶段实施

一次性搭建全部模块既不现实也不必要。推荐的实施顺序：

第一阶段：最小可用管线（1-2 周）

只搭三个模块：嗅探 → 处理 → 人工审核。

  • 嗅探智能体：先只接 RSS 订阅，10-20 个核心信息源
  • 处理智能体：先只生成长文章，一种格式
  • 审核：直接在 Slack 中完成，不需要专门的管理后台
  • 发布：手动复制粘贴到各平台

用 CrewAI 搭建，总共需要定义两个 Agent（Researcher 和 Writer）和两个 Task。配合一个 Cron 定时触发（每天早上 8 点运行一次），加上 Slack Webhook 通知。

这个阶段的目标是验证两件事：嗅探智能体能不能稳定找到有价值的内容？处理智能体生成的文章质量是否达到"稍作修改即可发布"的水平？

第二阶段：补全分析与发布（2-4 周）

在第一阶段验证通过后，加入：

  • 分析智能体：价值评估 + 去重 + 论点提取
  • 向量数据库：用 pgvector 做语义去重和内容检索
  • 发布智能体：先接入一个平台（选你的主力平台）
  • 管理后台：用 n8n 搭建基础的排期和状态管理

第三阶段：扩展格式与平台（4-8 周）

  • 增加音频生成能力（TTS 集成）
  • 增加推文串生成能力
  • 接入更多发布平台
  • 加入权威源探测和信息源评分
  • 完善通知体系

第四阶段：数据驱动优化（持续）

  • 搭建内容表现数据追踪
  • 月度自动复盘报告
  • 基于表现数据优化嗅探策略和处理策略

成本估算

一个中等规模的自媒体创作者（每周产出 5-10 篇内容），运行这套系统的月度成本大致如下：

项目 月费用
LLM API（Claude/GPT，分析 + 生成） $50-150
TTS API（ElevenLabs 或自部署） $0-30
服务器（轻量 VPS + Redis + PostgreSQL） $20-50
爬虫服务（Firecrawl） $0-40
X API Basic 套餐 $100
发布工具 / 其他 API $20-50
合计 $190-420/月

如果用自部署的开源 LLM（如 DeepSeek V4）替代商用 API，用 Crawl4AI 替代 Firecrawl，用免费的 X API 套餐（仅读取），成本可以压缩到 $50/月以内，代价是生成质量和采集范围的下降。

写在最后

这套系统的价值在于把创作者从重复性劳动中解放出来，让人的精力集中在真正需要判断力的环节：选题方向的把控、观点的提炼、和最终内容的质量审核。

技术层面，当前的智能体框架和工具链已经足够成熟，上面描述的每一个模块都可以用现有技术实现。真正的挑战在于运营层面——系统搭好之后，需要持续调优嗅探策略、训练分析模型的评分标准、打磨处理智能体的写作风格。这些调优工作本身就是一种学习过程，创作者在使用系统的过程中，也在不断加深对自己内容定位和受众需求的理解。

工具是放大器，放大的是使用者本身的判断力和品味。

━━━ fin ━━━

If you read this far — thank you.
Come tell me what you thought on X.