projectId: cmpge0uk100xxad0hc6gggadq
最新完整主链样本
顶层 cp-mining-agent
trace 最终总成本
用于聚合当前活跃 prompt / tool
从封面到故事成稿
如果把这条链路看成一个故事编辑部：它不是拿到封面后立刻写文案，而是先判断“这个封面在暗示什么故事、还缺哪些关键证据”，再去补证据、提出几种故事读法、拼装候选故事版本、做一轮编辑审稿，最后才把通过的版本改写成可发的 caption。
手机端查看主链图时可左右滚动，正文和结论区块会正常纵向堆叠。
点击主链里的任一模块，可以展开看这个环节在创作里负责什么、当前 prompt 是怎么定义的，以及最近 3 条相关 trace。
cp-react-decide-next-action
故事总编排器。它不是在直接写故事，而是在判断现在该先补哪种证据、什么时候可以进入讲故事、什么时候该评分收尾。
默认先展开当前主链里最核心的决策节点。
最近 3 条相关 trace
按 observation 时间倒序，并去重 traceId。
Active 支线
这是一条更短的“封面即故事”支线，不经过 cp-mining-agent 主创作主链。
story-generation.active.cover-caption
最近一次可见样本是 trace 19c6bc49fae7c120c0f78928aed25d4d，对应 active-write-cover-caption@v7 一次 generation。它不是先找 pin 再讲故事，而是直接把单张封面翻译成一句可发 caption，适合“封面自己就足够成立”的轻量场景。
V2 状态
这更像一条潜在的新工作流：更细粒度地分工观察、决策和执行，但最近活跃流量里还没看到它接管主链。
已上库但未接最近流量
最近 1000 条 observations 里，没有看到 cp-v2-worker-decide-next-action@v1 或 cp-v2-observe-contact-sheet@v1 的调用。也就是说，这种“先分工观察 contact sheet，再让 worker 小步执行”的创作方式目前还停留在 prompt 库里，线上真正跑的仍是 V1 / ReAct planner 主链。
最近 1000 条 Observation 的 prompt 活跃度
这组聚合能看出系统把时间花在故事创作的哪一步：是大量时间用来想“下一步该干嘛”，还是用来真正组装故事、做审稿或写文案。
最近 1000 条 Observation 的 tool 活跃度
这些 tool 不是在写故事，而是在给故事补上下文证据：补事件线、补同一人物、补物件关系、补时间邻近、补地点活动。当前主链仍是 lane-search 式补证据，而不是 contact-sheet worker 式逐格观察。
这条最新 trace 是怎么一步步把故事做出来的
把它按“创作动作”翻译后会更容易理解：系统先想故事缺什么，再找证据，再提出故事角度，再把角度拼成故事版本，再做审稿，最后才让 writer 把批准后的故事写成成品。当前最重的地方不只是 synthesis，而是前面反复想和反复试的回环。
先开一个完整的创作回合
cp-mining-agent 像总导演一样包住整次运行；内部的 agentic.recall_planning_loop 负责反复追问：现在这个封面要讲成故事，还缺哪一类证据和哪一种读法。
loop 159.412s
先补“主角是谁、是不是同一个人”
planner 第一次决策后调用 query_same_person_lane。这一步的作用不是推进文案，而是先把人物连续性补起来，让后面的故事至少围绕同一个主角展开，而不是一堆散乱图片拼接。
0.042s
planner 反复判断“下一步该怎么把故事做下去”
cp-react-decide-next-action@v5 一共跑了 10 次，总成本约 $0.072555。它的职责像总编排期：决定现在应该继续补证据、继续试故事角度，还是已经可以进入组合和审稿。它不是轻量路由器，而是在主导故事节奏。
$0.072555
反复提出“这组图到底可以往哪个故事方向讲”
cp-plan-hypotheses@v9 在这条 trace 里跑了 7 次，总成本约 $0.0613065。它的作用是把封面可能暗示的故事角度拆成几种 lane，比如揭示、反差、关系、过程、前后变化。反复重做说明系统还在试图找到一个更像样、回报更高的读法。
$0.0613065
真正把线索组装成候选故事版本
cp-synthesize-top-n@v9 只跑 1 次，单次就花了 $0.0446175、37.164s。这一步才是把封面、候选 pin、前面提出的故事角度一起捏成几个可讲的候选故事版本，所以它很像创作里真正的“成稿前拼装台”。
37.164s
对候选故事做编辑审稿
cp-score-criteria@v9 连跑 3 次，说明本轮有 3 个候选故事版本进入严格评分。它审的不是“文笔好不好”，而是这个故事讲不讲得通、有没有信息增量、有没有超出证据、值不值得为了这组 pin 付出多图复杂度。
$0.0181425
writer 把通过的故事翻译成可发成品
cp-write-captions@v9 只跑一次，说明故事组合在 writer 前已经定稿。writer 的工作不是重新选图或改故事方向，而是把批准后的故事逻辑翻译成最终能发出去的英文 gossip caption。
$0.015063
最后只做定稿和封装
evaluator 和 final-story-build 在最新样本里都是无 prompt 的收尾 SPAN。到这里系统已经不再创造新故事，只是在把入选版本打包成最终结果，结束这一次创作回合。
< 0.01s each
现状结论
如果只用一句话描述现在这套系统，可以直接用下面这句。
现在它是怎样创作故事的
现在主流链路仍是 cp-mining-agent 下的 ReAct planner 主链：先判断故事缺什么证据，再补证据，再提出几种故事读法，再把这些读法组装成候选故事版本，接着用评分把讲不通或价值不高的版本筛掉，最后才由 writer 把通过的版本写成成品文案。最近主流并不是 V2 worker orchestration。
风险与观察
如果从故事创作效果看，最该关注的是这些问题。
三个最明显的点
第一，系统现在花了很多力气在“想这个故事该怎么讲”和“要不要再试一个角度”，所以 planner 和 hypotheses 回环很多次，拖慢了整体成稿速度。第二，cp-synthesize-top-n@v9 虽然只跑一次，但它承担的是把线索真正拼成故事的重活，所以单次依旧很重，也是历史 ERROR 里出现过 timeout 的节点。第三，active-write-cover-caption@v7 最近样本里有延迟但 usage / cost 为 0，看起来像埋点缺口，不像标准计费轨迹。