回答的问题
Agent 角色之间谁指挥谁？数据怎么流转？
视角
运行时的角色拓扑 · 角色跨越多个结构层存在（Orchestrator 在编排层，Workers 跨编排 + 能力层）。
感知层（在产品里就是运营后台 · 不驻留 Agent）
编排层（Orchestrator 与 Workers 的控制流）
能力层（Workers 在这里调用原子 AI 能力）
基础层（共享记忆 + Harness）
运营点击"生成内容"
审核员通过 / 驳回
投放看板数据更新
某条内容效果异常告警
Orchestrator
Orchestrator Agent
决策大脑 · 任务拆解 · 策略选择
唯一决策入口
Creator Worker
Creator Worker
内容创作执行 · 接 Orchestrator 指令
只向上汇报，不与其他 Worker 通信
Analyst Worker
Analyst Worker
数据分析执行 · 归因 / 异常检测
结论写回共享记忆，由 Orch 读取
派单
派单
调 LLM / 生图
调数据查询
文案 / 生图
视频合成
翻译 / 审核
数据查询 / 聚合
共享记忆 · Shared Memory
短期 Session 上下文 · 长期向量 DB · 策略 pattern 沉淀 · Orchestrator↔Worker 的交换空间
读 / 写
写生产结果
写分析结论
关键约束：
① Orchestrator 是 唯一决策入口 ，所有派单都从它发出；
② Workers 之间不直接通信 ，只通过共享记忆间接协调；
③ Workers 坐在 编排层 + 能力层的交界 ：它们的控制流在编排层，调用能力在能力层；
④ Agent 不在能力层里 ——能力层里只有原子能力（文案 / 图片 / 视频 / 翻译 / 审核 / 数据查询），Agent 是调用它们的角色。
回答的问题
系统什么时候需要心跳？心跳醒来后具体做了什么？
视角
Loop Engine 驱动机制 · 三种叫醒场景 × 醒来后的动作路径 × 频率控制旋钮 × idle 条件。
⚠️ 一期只实现手动触发（运营点按钮），自动心跳机制为二期规划。
🔄 Loop Engine · 系统持续运转的驱动机制
Loop Engine 不是一个新模块 ，而是让 Orchestrator + Workers 持续被唤醒的心跳器 。
什么时候心跳 （三种叫醒场景）、心跳时做什么 （醒来后的动作路径）、什么时候歇 （idle 条件）。
一次完整心跳 ——每次被唤醒，就跑一轮 P→R→A→L。
一期：全部由运营手动触发 ；二期引入定时 + 阈值自动唤醒；三期实现全自动决策。
1 三种叫醒系统的场景
系统不主动动。设计上有三种叫醒场景，一期只实现第三种（运营操作触发） ，前两种为远期规划。
"该出新内容了"
系统自动检测内容缺口、定时提醒补产。爬坡期日级、稳态周级、大促脉冲。一期运营手动判断，后期再自动化。
"有情况，需要看看"
UV 突然掉了 40%、CAC 连续三天超标、互动率异常好值得追加。一期运营自己盯数据，后期系统自动检测阈值突破。
"有人动了"
运营在后台点"生成内容"、审核员驳回帖子、手动点"重新分析"。一期所有心跳都是运营手动触发 ，最简单也最确定。
2 醒来后做了什么 — 三条场景路径
不同场景叫醒后走不同路径。每条路径都是 P→R→A→! →L，但具体内容不同。
P
看现状 ：活跃内容数 / 各渠道消耗 / 目标缺口
↓
R
Orch 决策 ：产几条 / hook 角度 / 渠道选择 / 翻策略库
↓
A
Creator ：LLM 文案 → 万相配图 / 视频 → 草稿入审核
↓
↓
L 沉淀 ：UV / 互动 → S/A/B/C 分级 → 策略 pattern 入库
P
拉全信号 ：哪条内容 / 渠道 / 跌幅 / 起始时间 / 同期变化
↓
R
Orch 判断 ：正常波动 → 忽略；连续异常 → 派 Analyst
↓
A
Analyst ：归因分析（衰退 / 算法 / 竞品）→ 报告 + 建议
↓
!
人工决策 ：替换？追加？调策略？→ 可触发生产路径
↓
L 沉淀 ："Naver Blog 内容生命周期 ≈ 7 天" → 记忆
P
接收操作 ：Studio 生成 / Insight 分析 / 审核驳回
↓
R
Orch 路由 ：按钮类型 → 生产流程 / Analyst / 重新生产
↓
A
Worker ：按指令跑完 → 产出写回记忆 → 通知运营
↓
L 沉淀 ：同上两条路径的 Learn
共同规律： 每条路径都有 人工断点 ，每条路径的 L 沉淀质量 决定飞轮是否有效。系统做的是"把功课做好摆到你面前"，不是替你做决定。
3 心跳频率怎么控制
一期全部手动触发，不需要任何配置。等运营跑出手感后，二期再逐步引入三个旋钮。
✅ 一期（当前）：运营手动触发
接住运营的操作，跑完 P→R→A→!→L，把结果摆回来 。
🔜 二期设计方向：三个旋钮（运营手感成熟后引入）
以下三个旋钮是未来的配置能力，让运营可以通过调参控制心跳频率，而不需要改代码。
定时任务的执行间隔。运营在设置里改，系统按配置跑。
调节范围
每天 1 次 ←→ 每周 1 次
爬坡期建议：每日 · 稳态建议：每周
数据指标偏离多少才算"异常"。灵敏度越高，系统越容易被叫醒。
调节范围
敏感（跌 10% 就报） ←→ 迟钝（跌 50% 才报）
爬坡期建议：敏感 · 稳态建议：适中
"活跃内容低于 X 条"时自动提醒补产。X 就是控制生产心跳频率的旋钮。
调节范围
X=3（高频补产） ←→ X=20（低频维护）
爬坡期建议：X=5 · 稳态建议：X=15
设计哲学： "业务阶段"是运营用来理解系统行为的人类标签 ，不是系统能自动检测的状态。
旋钮在运营手里 ，不在系统里。
演进路径：
一期（当前） ：全部手动触发。运营点按钮 → 系统跑完 → 结果摆回来。积累体感和判断基准。
二期 ：引入三个旋钮 + 预警通知。系统检测到异常只发通知，核心决策还是人来按按钮。
三期 ：逐步放权给系统自动决策（自动补产、自动调渠道权重），旋钮从"通知参数"变成"自动执行参数"。
4 什么时候 idle — 系统不是一直在跑
一期逻辑很简单：运营没点按钮，系统就是 idle 的。
一期 idle 条件： 运营没有排队中的操作
当前任务已跑完 P→R→A→!→L
Learn 沉淀已写完
二期追加条件： 下一个定时任务尚未到时间 · 无数据异常告警 · 内容池无生产缺口
守护机制（全阶段通用）： 单轮最大 10 步 / 120 秒 超时；死循环检测；置信度 < 0.6 自动升人工。这些是 Loop Engine 的"安全绳"，防止系统跑飞。