AI投流产品架构v5.3 · 三视角拆分版

把 v5.2 中混画的"结构 / 角色 / 行为"拆成三张独立视图，每张只回答一个问题。

为什么拆？ v5.2 把"系统由哪些模块组成（结构）"、"Agent 之间谁指挥谁（拓扑）"、"系统什么时候动（循环）"塞进同一张图，视觉上像"整合"，其实混淆了三个不同维度。 三张图对应三个独立问题： 图 A 回答"系统有几层，每层装什么"； 图 B 回答"Agent 角色坐在哪，互相怎么协作"； 图 C 回答"系统节拍是什么，什么时候做什么"。
A · 系统静态分层
B · Agent 协作拓扑
C · 运行时循环（PRAL）
回答的问题 系统由哪些模块组成？每层装什么？
视角 静态结构 · 像一张建筑楼层图。不涉及"谁在跑""什么时候动"。
1
感知层 · Perception — 数据与事件的入口 （在产品里就是运营后台：Studio / Distribution / Insight / 审核工作台）
内容生产工作台
Studio：填方向 → AI 出文案 → 选配图 → 提交审核
投放管理看板
Distribution：管投放、补浏览量 / 互动量 / 消耗
数据洞察看板
Insight：看跳转 UV / 帖子浏览量 / 互动率，对比渠道
审核工作台
运营提交 → 审核员通过 / 驳回 → 投放标记
▼▼▼
2
编排层 · Orchestration — 决策 / 调度 / 流程控制
任务编排引擎
n8n / Airflow 驱动的 DAG 工作流
审核状态机
draft → pending → approved / rejected → published
决策规则
hook 策略选择、是否触发迭代的判定
投放标记与归因
把内容与渠道跳转绑定
▼▼▼
3
能力层 · Capability — 原子 AI 能力（被调用，不做决策）
文案生成
Qwen-Plus
图片生成
万相 / 通义
视频合成
HeyGen / Wan
翻译 / 多语言
韩语 / 英 / 日 / 泰
审核 / 合规
敏感词 / 品牌一致性
▼▼▼
4
基础层 · Infrastructure — 存储 / 监控 / 运行时工具
存储
关系库 D1 / 向量 DB / 对象存储
可观测
SLS / Prometheus / 日志 / 指标
评估
A/B / 内容分级 S/A/B/C
运行时
Cloudflare Workers / 内部 HSF
这张图只回答"系统有什么"。至于"谁在跑这些模块""什么时候触发"，请看图 B 与图 C。
回答的问题 Agent 角色之间谁指挥谁？数据怎么流转？
视角 运行时的角色拓扑 · 角色跨越多个结构层存在（Orchestrator 在编排层，Workers 跨编排 + 能力层）。
感知层（在产品里就是运营后台 · 不驻留 Agent） 编排层（Orchestrator 与 Workers 的控制流） 能力层（Workers 在这里调用原子 AI 能力） 基础层（共享记忆 + Harness） 运营点击"生成内容" 审核员通过 / 驳回 投放看板数据更新 某条内容效果异常告警 Orchestrator Orchestrator Agent 决策大脑 · 任务拆解 · 策略选择 决定是否迭代 · 派单给 Workers 唯一决策入口 Creator Worker Creator Worker 内容创作执行 · 接 Orchestrator 指令 调用下层文案 / 图片 / 视频能力 只向上汇报，不与其他 Worker 通信 Analyst Worker Analyst Worker 数据分析执行 · 归因 / 异常检测 调用下层数据查询 / 聚合能力 结论写回共享记忆，由 Orch 读取 派单 派单（数据分析任务） 调 LLM / 生图 / 视频 调数据查询 文案 / 生图 视频合成 翻译 / 审核 数据查询 / 聚合 共享记忆 · Shared Memory 短期 Session 上下文 · 长期向量 DB · 策略 pattern 沉淀 · Orchestrator↔Worker 的交换空间 读 / 写 写生产结果 写分析结论
关键约束： ① Orchestrator 是 唯一决策入口，所有派单都从它发出； ② Workers 之间不直接通信，只通过共享记忆间接协调； ③ Workers 坐在 编排层 + 能力层的交界：它们的控制流在编排层，调用能力在能力层； ④ Agent 不在能力层里——能力层里只有原子能力（文案 / 图片 / 视频 / 翻译 / 审核 / 数据查询），Agent 是调用它们的角色。
这张图只回答"谁指挥谁、数据怎么流转"。至于"什么时候触发这个协作"，请看图 C。
回答的问题 系统什么时候动？为什么动？节拍是什么？
视角 运行时循环 · PRAL 循环不是新的一层，而是跨越 4 层的事件流，每个阶段落在不同的结构层。
P
Perceive
感知层（运营后台）
+ 基础层
有人或有个动作触发了系统。系统不主动动，要有人操作或有数据变化，它才开始跑。
运营点了按钮在后台点"生成内容""重新分析""重新投放"
审核员审核了把一条内容通过 / 驳回，下游状态变了
数据变了投放看板每日刷新，某条内容 UV 掉了一截 / 互动率突然爆表
定时任务每天凌晨跑一次快照，每周跑一次深度归因
这些动作和数据变化会被后台记录下来，作为 "这一轮要处理的事" 进入下一步。
↓ 事件到达 Orchestrator
R
Reason
编排层
Orchestrator 推理与决策。读取共享记忆（历史策略 / 当前状态）+ 当前事件 → 决定下一步。
决策 1要不要启动新一轮内容生产？（看爬坡期目标缺口）
决策 2选什么 hook 策略 / 什么渠道组合 / 什么内容形式？
决策 3要不要触发"优化迭代"？（看 Analyst 结论是否显著）
决策 4要不要通知人工介入？（阈值超限时兜底）
决策结果 = 一组下发给 Workers 的任务指令。
↓ 任务下发给 Workers
A
Act
编排层 + 能力层
Workers 执行具体动作。Creator Worker 与 Analyst Worker 各自独立跑。
Creator Worker调 LLM 出 3 段文案 → 调生图 / 视频能力 → 产出内容草稿 → 进审核状态机 → 人工审核 → 投放
Analyst Worker调数据查询 → 跑归因 / 异常检测 → 产出分析报告（含显著性判断）
产出全部 写回共享记忆，不直接回 Orchestrator。
↓ 执行结果沉淀到记忆
L
Learn
基础层 + 编排层
学习沉淀，更新策略 pattern。这一阶段决定"下一轮生产更聪明"。
内容分级S / A / B / C 自动标注（按 UV + 互动率阈值）
策略 pattern把"哪类 hook 在哪个渠道效果好"沉淀到向量 DB
Prompt 优化运营人审 Analyst 报告 → 手动调整 KB / Prompt（注意：这里是人工断点，不是自动调 Prompt）
下一轮受益下一轮 Reason 时 Orchestrator 能检索到更新的 pattern
🔄 回到 P： Learn 沉淀完 → 系统等待下一个事件（数据更新 / cron / 阈值 / 手动触发）→ 新一轮 PRAL 启动。
节拍：不固定。日常 = cron 驱动的日 / 周循环；紧急 = 阈值事件即时触发；人工 = 运营随时点"重新分析"。
人工断点：Learn 阶段的 Prompt 优化、Act 阶段的内容审核，都必须有人介入。这是 v5.3 与 v5.2 的关键区别——v5.2 把这两步画成"自动"，工程上不靠谱。
这张图只回答"什么时候动、谁动、动完沉淀什么"。至于"动在哪些模块里发生"，请看图 A。