Frank 抓到了 Loop 最本质的问题——它不是 Agent。ai-loop skill 没有自己的 runtime engine，靠 LLM 读 3000 行 SKILL.md 调起 Python CLI 脚本。本方案给出：现状架构、目标 Agent 架构、5 个技术选型对比、推荐的 LangGraph 路径、4 阶段改造路线、团队需要补的能力。
ai-loop skill 自己没 scripts 目录，ls skills/ai-loop/scripts/ 是空的。运行完全靠 LLM 在 IDE 里"读 prompt 调脚本"。
每次都要 Frank 或 LLM 主动说"用 ai-loop 跑一遍"。没有 cron、没有事件触发、没有"自动醒来"机制。
Loop 状态只在 history.jsonl 里追加，LLM 每次都要从零读起。无法"上次的经验指导这次"。
数据回来后 LLM 不主动分析。要 Frank 看到异常再 prompt 问。策略调整延迟以"天"为单位。
LLM "知道有什么 skill"靠 SKILL.md 提示，工具集是软描述不是注册表。新增/替换工具要改 SKILL.md。
任务失败后 LLM 不主动重试/切换。AI Cut 持续 0 播放时不会自动切人工。
100 账号 × 多变量实验的并行全靠 LLM 脑内串。无法做"100 个剪任务并发跑、自动负载均衡"。
运行状态只在 history.jsonl 里。无法可视化"哪个任务卡在哪个阶段"、"为什么没出单"。
所有"决策"都是 SKILL.md 里硬编码的规则。LLM 不会"根据数据"动态修改 SKILL.md。
一句话总结：当前 Loop = "CodeX 在 LLM 提示词里硬塞了 4 阶段流程"，没有自主运行能力。要变成真正的 Agent，需要引入 runtime engine + 持久记忆 + 反馈回路 + 动态工具。
不再需要 LLM 主动触发。cron 每 3 小时跑一次 + 订单/播放异常事件触发即时分析
PostgreSQL 存结构化状态 + pgvector 存历史经验/出单案例。Agent 跨 run 共享"上次为什么爆"
每次 run 不是固定流程。LLM 根据数据反馈决定：今天跑 5 剧还是 10 剧、剪什么手法、发什么平台
新增工具只需要注册一个 Python function + JSON schema，不需要改 SKILL.md
发现 AI Cut 持续 0 播放 → 自动切人工；发现某剧爆了 → 自动加码跟发；不依赖 Frank 提醒
AI Cut 失败自动切 Manus → Vidu；连 3 次失败告警 Frank；不是"LLM 看到错才能反应"
100 个剪任务并发跑、自动负载均衡、自动失败重派。LLM 不用脑内串
Langfuse 记每步决策依据；Dashboard 看实时 run 状态；飞书异常告警
| 维度 | A. LangGraph | B. CrewAI / AutoGen | C. CodeX Agent SDK | D. 完全自研 | E. 当前方式 (LLM + CLI) |
|---|---|---|---|---|---|
| 控制力 | 高（图结构） | 中（多 agent 协议） | 中（prompt 驱动） | 极高 | 低 |
| 图结构表达 | 原生支持 | 通过 agent 协作 | 不支持 | 完全自定义 | 靠 prompt 描述 |
| 长期记忆 | 内置 checkpointer | 需自建 | 无 | 完全可控 | jsonl 追加 |
| 工具注册 | Tool decorator | Tool wrapper | Tool schema | 完全自定义 | 硬编码 SKILL.md |
| Human-in-the-Loop | 原生 interrupt | 弱 | 中 | 完全可控 | 靠 Frank 主动 |
| 可观测性 | LangSmith / Langfuse | 弱 | 弱 | 完全可控 | jsonl 翻日志 |
| 并发执行 | Send() API + async | 通过 task 异步 | 顺序 | 完全可控 | LLM 脑内串 |
| LLM 切换 | 多 provider | 多 provider | 绑定 CodeX | 任意 | 绑定 |
| 迁移成本 | 中（包装 CLI） | 中（重写编排） | 低 | 高（2-3 人月） | —（现状） |
| 维护成本 | 中 | 中-高 | 低 | 极高 | 高（SKILL.md 维护） |
| Loop 适配 | ★★★★★ | ★★★ | ★★ | ★★★★ | ★ |
| 团队学习曲线 | 中（Python 友好） | 中 | 低 | 高（架构师级） | 低 |
| 推荐度 | ★ 首推 | 备选 | 不推荐 | 长期可演进 | 被替代 |
推荐：LangGraph 为骨架（短期）+ 自研 Runtime Engine（长期）。LangGraph 解决 80% 问题（持久记忆/工具/HITL/可观测/并发），剩下 20%（业务特定调度、AB 编排）用自研 wrapper 补。
图结构 + checkpointer + interrupt + Send() 并发。Loop 的 4 阶段 = 4 个 node + 条件边。
6/3 短剧全流程会议已经决定生产环境切阿里云，国内稳定 + 不封号。Phase 3 引入推荐算法时加一个 BGE-M3 做 embedding。
结构化状态（run records、用户画像、账号池）+ 向量记忆（出单案例、剪辑手法 embedding）。LangGraph checkpointer 直接用。
每个 CLI 脚本包成 FastAPI service + LangGraph @tool 包装。新增工具 = 新增一个 Python 文件，零改 SKILL.md。
cron 任务 + 异步任务队列 + 失败重试。100 账号并行剪任务、3 小时爬虫、每日播报。
trace 每次 run 的每步决策依据 + 异常告警 + 数据看板。CEO 群每天 8:30 自动播报。
短期跑在 Frank 那台 Mac 即可，2 周内迁到云。Q4 跑 100+ 账号并行时必须上云。
# ai-loop-agent/graph.py from langgraph.graph import StateGraph, END from langgraph.checkpoint.postgres import PostgresSaver from langgraph.prebuilt import ToolNode # 状态：每个 run 的完整上下文 class LoopState(TypedDict): run_id: str feedback: dict # 最近 7 天的数据 candidates: list[dict] # 候选剧 selected: list[dict] # 选中的剧 owned_tasks: list[dict] # 已领取激活 cut_outputs: list[dict] # 剪辑输出 publish_results: list[dict] # 发布结果 errors: list[dict] human_decisions: list[dict] # Frank 拍板记录 # 4 个核心节点 builder = StateGraph(LoopState) builder.add_node("perceive", perceive_node) # 拉取数据 + 加载记忆 builder.add_node("plan", plan_node) # LLM 动态生成 run plan builder.add_node("act", act_node) # 执行 4 阶段（send 并发） builder.add_node("reflect", reflect_node) # 反思 + 更新记忆 # 5 条条件边 builder.add_conditional_edges("perceive", lambda s: "need_human" if s["anomaly_score"] > 0.8 else "plan") builder.add_edge("plan", "act") builder.add_conditional_edges("act", lambda s: "retry" if s["errors"] else "reflect") builder.add_conditional_edges("reflect", lambda s: "perceive" if s["should_continue"] else END) # interrupt：关键决策点暂停，等 Frank 拍板 app = builder.compile(checkpointer=PostgresSaver(...), interrupt_before=["plan"])
python -m ai_loop_agent 启动 Agent，自动跑完一次完整 loopai-loop-agent/ 目录）@tool（不改 Python 逻辑，只加 wrapper）perceive → plan → act → reflect 4 节点 + 基础条件边interrupt：关键决策点暂停等 Franktool_router 根据 plan 选工具（AI Cut vs 人工 vs Vidu）if AI Cut 0播放率 > 30% → 自动切人工Send() 实现 100 任务并发熟悉 LangGraph / LangChain / LlamaIndex。有真实 Agent 上线经验，能搭 runtime + checkpointer + tool。能跟子明对接口。
搭 PostgreSQL + pgvector + Celery + Redis + Langfuse。负责数据基建 + 监控告警。能跟博恒对接。
匹配算法 v1→v2（ML 模型）。6/3 短剧自动化分发会议已经说要招，宋健推荐。
从"写 Python 脚本"升级为"写 LangGraph tool"。学 LangGraph 1 周即可上手。
从"看板"升级为"实时数据 pipeline + 向量记忆库"。学 pgvector 1 周。
从"Excel 选剧"升级为"提示词工程 + 案例库管理"。学 prompt + embedding。
关键人力瓶颈：招聘 1（LLM 应用工程师）是必须的。子明是 Python 强但 LangGraph 经验 0。Phase 1 启动前必须到岗，否则 2 周 MVP 跑不通。
短期推荐 Qwen-Max（国内稳定 + 成本低 + 6/3 已经定调）。如果考虑长期跨语言 / 多模态更强可以混 GPT-4o。
推荐 Phase 1 MVP（2 周跑通 1 部剧），不要一开始就想"全量替换"。Agent 化是渐进过程。
推荐 LangGraph 起步 + 长期演进到自研 Runtime。不要一开始就完全自研（成本高 2-3 人月）。
没有这个人 Phase 1 跑不通。Q3 窗口期不等人，建议把招聘提到 P0 级别。
R1 · LangGraph checkpointer 写 PostgreSQL 高并发性能未知。100 账号 × 每 run 100 状态写入 = 1 万次/小时，可能需要 Redis 中间层。Plan B：前期用 SQLite，10 账号规模验证后再上 PG。
R2 · Qwen-Max 工具调用稳定性未验证。6/3 短剧全流程会议有提，但 1 个月实操数据没有。Plan B：准备 Qwen-Plus + Qwen-Coder 兜底，关键路径双重 LLM。
R3 · 子明 + 博恒 改造期产能下降。Phase 1-2 需要他们边跑业务边搭 Agent，必然分散精力。Plan B：招到 LLM 工程师后立即接手 CLI 维护，子明只做 review。
R4 · Frank 拍板频率问题。Agent 大量使用 interrupt 等待 Frank 拍板，可能拖慢执行。Plan B：设置"低风险决策 Agent 自主 + 高风险决策 Frank 拍板"的两层机制。
R5 · 既有 SKILL.md 投资不能浪费。3000+ 行 SKILL.md 写了大量业务知识，Agent 化后这些是 prompt 资产。Plan B：把 SKILL.md 当"业务规则手册"，让 LLM 持续引用，不删除。
Q1 · 部署在哪里？Frank Mac 跑 / 阿里云 / 火山引擎？影响 Docker + 网络配置。
Q2 · 多 LLM 切换的运维成本？Qwen + GPT-4o 混用，账户 / 计费 / 监控怎么管？需要 Frank 协调 1 个固定的云账号 owner。