内容分发工作流 三段式 Agent Factory
把"抓源 → 双平台中文改写 → 发布"做成一条老板可控的内容流水线。每一段都是一个独立工段：自己的 Creator 生成专用 Agent、自己的 DB 当状态总线、自己的人工介入节点。
全貌：一图看懂三段式
三段速览
数据源
找源 → 抓原文
定时跑 RSS / sitemap，从白名单源更新索引 → 按 source-specific agent 抓取 top N 优质内容。
- 1.1 index Updater v01
- 1.2 source Creator v01
- 1.3 launch Getter v01
- 1.4 Orchestrator v01
内容改写
同源 → 多平台中文草稿
每平台一份 prompt profile + 风格规则；改写带 AI 味自评，自评不达标自动重写，达标进 draft_db。
- 2.1 target Creator 人工
- 2.2 launch translator v01
- platform profile git
- multi_lang_cache 30d
平台发布 · v0.2
发布 + 看板雏形
v0.1 只跑 mock：通过看板点"模拟发布"，把真实平台 API 接入留到 v0.2+ 再做。
- 3.1 draft prepare mock
- 3.2 publish v02
- 看板（飞书多维表格） v01
- 真实平台 API v02
① 数据源 · 子 Agent 详情
1.1 + 1.2 创建与索引
触发定时 + DB 反查 · 产物source_db / agent_factory- 1.1 index Updater
- 每天跑一次，对白名单源拉最近 30 天的索引；只跑 RSS / sitemap，不爬虫未列白名单的站。
- 1.2 source Creator
- 扫
source_db.agent_status=none的源，调用 Creator 即时寻找可解析字段，filter 语言读前 X 行验证，生成 Getter Agent 写入agent_factory。 - filter 语言
- v0.1 退化为 YAML 配置（关键词 + 时间窗 + 排除词），不用真 NL；理由：稳定可控、可解释。
- v0.1 范围
- 2-3 个英文技术站点（HN / Reddit 等），手工写解析规则；Creator 在 v0.1 先是"模板工厂"。
1.3 + 1.4 抓取与调度
触发手动 + 每日 cron · 产物content_db- 1.3 launch Getter
- 按
source_id+ 过滤参数调用持久化的 Getter Agent，起一次抓 → 拿{url, title, ts, hash, snippet}列表。 - 1.4 Orchestrator
- 每日 cron 触发；按平台/语言过滤策略筛 top 3，写入
content_db(status=raw)，默认全归档（即"微分享"）。 - 失败处理
- 抓取失败进
failed_log，不阻塞主流程；人工按需补。 - DB 增量
- 每条进
content_db同时算quality_score（v0.1 启发式即可），用于 ② 段优先级。
② 内容改写 · 这是 v0.1 的核心
2.1 target-specific Creator 人工介入
一次性添加平台/语言时触发- 做什么
- 人工在 db 登记"待创建的平台/语言"，Creator 生成
platform_prompt+style_rules落到agent_factory。 - 为什么需要人
- 风格 prompt 是核心资产 —— 一旦交给 LLM 自创，可解释性掉到零；人工模板 + 反例/正例对更稳。
- v0.1 决定
- Creator 退化为模板工厂：每个平台一份 base prompt，人工写风格增量；v0.3 再让 LLM 自创。
2.2 launch translation Agent
触发手动 / 抓取完后自动跟 · 产物draft_db- 输入
content_id+(platform, lang)；只处理translate_status=raw。- 处理流程
- 拉最新 markdown → parse 段落 + meta → 查
multi_lang_cache→ 命中复用 / 未命中跑 prompt → 输出body_md+ meta。 - 降 AI 味
- 两轨并用：① 反 AI 句式替换表（"值得注意的是"→ 直接删）；② 平台风格 prompt 加口语化语气词。
- 质量门
- 改写完带
ai_smell_score (1-5)，> 3 自动重写一次，仍 > 3 进draft_db.status=draft等人工看。 - 缓存 key
sha1(url + platform + lang + prompt_version)，TTL 30 天；不注入 time-sensitive 字段以保持可复用。
wechat_mpxiaohongshu表格里的差异最终落到 prompt 上时是「反例 + 正例对」（"不要 X，要 Y"），单纯形容词撑不起降 AI 味。
③ 平台发布 · v0.1 mock
v0.1 不真实发布，先验证"改写 + 看板节奏"
v0.2+ 接公众号 + 小红书 API- 3.1 draft prepare
- v0.1 用 mock：看板里手动注入平台特殊字段（公众号封面/首图/摘要、小红书封面/话题）。
- 3.2 publish 人工确认
- v0.1 mock（点"模拟发布"即成功）；v0.2 接真实 API，公众号走微信公众平台 + 图文素材上传，小红书走第三方专业号 API。
- 看板
- 飞书多维表格起步，三列：抓取池 / 改写池 / 发布池；带 AI 味评分列，方便反哺 ① 的过滤策略。
为什么这么搭
稳定性
段间不互相调用
源挂了不影响改写；改写挂了不影响抓取；改平台不影响源。任何一段都能独立重启、独立排错。
可观测
每段单独看板
每段都能看吞吐、失败率、人工介入次数。三段不会一个黑盒覆盖另一个黑盒。
可演进
逐段升级
v0.1 mock ③ 时 ①② 完全不用动；v0.2 接真实 API 不回头改 creator。
v0.1 五周路线
-
W1跑通 ① 数据源基线
1.1 + 1.2 + 1.3 落地；手工接入 2 个源。验收：每天定时抓到 top 3 原文落 content_db。
-
W2跑通 ② 的 platform profile
2.1 落地，公众号 + 小红书两个 prompt 模板入 git，可切换可回滚。
-
W3跑通 ② 改写执行
2.2 落地；同一份原文产出两版，AI 味自评 ≤ 3。
-
W4飞书看板 + 30 篇样本
看板雏形 + 你本人照看板节奏跑 5 天不掉链子，验证价值。
-
W5+③ 真发布接入
公众号/小红书 API 调研与接入；做简版数据看板。
开干前要决定的 5 件事
Creator 要不要让 LLM 自创 prompt？
v0.1 走人工 prompt 模板最稳，可解释、可回滚；v0.3 再升 AI 生成。
建议：v0.1 用人工模板。
filter 语言 NL 还是 YAML？
"通 Creator 即时寻找 + filter 语言读 X 行"这个点的工程决策。
建议：v0.1 YAML，v0.2+ 升级 NL。
cache 是否带 time-sensitive 字段？
一旦注入"今日热点"等字段，cache key 就要带日期，可复用性会大幅下降。
建议：v0.1 不注入，保持可复用。
prompt 库放 DB 还是 git？
风格 prompt 是核心资产，不能让它在 DB 里悄悄漂。
建议：进 git，单人维护，可回滚。
"你本人不喜欢的样本"回灌机制
AI 味自评终究是机器打分，老板自己的不喜欢才是真信号。
建议：加一个"被老板标记不喜欢"的回灌池，做 prompt 迭代。
一句话目标
做出一个双平台中文改写工作台，让"找源 → 抓原文 → 改写"全自动，让"选平台风格"和"最终发布"留给人决策——验证价值最快的那一段。
策略：先验证价值，再做全自动化发布。