Loop Runner · Product Concept & Butler Reference

Loop Runner 热梗场景：产品方案、交互原型与管家能力参考

这份页面主要说明我们为什么这样整理产品方案、用户会怎样使用，以及 Sozai 已经验证过的管家能力能带来什么启发。交互仍以 Loop Runner rev12 为基准；具体工程实现可以结合现有代码继续评估。

2026-07-16 · 产品方案基线 system-overview rev12 · Sozai 管家核对 origin/st/test@05e8fff · 供开发讨论参考

交互基线Loop Runner rev12

首页、确认页、Task Workspace、产物详情都沿用已对齐方案。

能力参考Sozai 管家

重点参考定位、上下文、工具、事件、确认卡与真实回执。

事实来源Runner / Review

管家不自己判状态，也不替代 Stage 审查和 Handoff。

上下文范围每版本一个

同一形象可以跨版本，但会话与记忆建议按 Iteration 隔离。

先把讨论边界说清楚：页面看 rev12，管家能力看 Sozai

现有 Loop Runner 已经有 Stage、Auto Review、重试、Handoff 和 Iteration 等完整运行概念。这版产品方案不打算缩减这些逻辑，只是尝试给用户增加一层更容易理解的组织方式。当前开发版本更细的实现仍以代码为准，本页不代替技术设计。

KEEP · LOOP RUNNER

继续作为运行事实

  • Agent、Task、Iteration、Stage、Artifact
  • Auto Review、Checkpoint、Retry、Exit
  • Handoff、预算、状态机与来源追溯
  • Stage 内多轮 Loop 与失败修复
→

ADD · PRODUCT LAYER

让用户知道为什么这样跑

  • 版本创意基因：正式规则快照
  • 阶段策略：每个 Stage 的人话入口
  • 迭代记忆：本版本运行学习
  • 版本管家：理解、解释与发起动作
Loop Runner 层级热梗场景里的例子与当前 Sozai 的关系
平台 Agent热梗 Agent，可被多个用户反复使用更接近 Sozai 整套热梗能力的模板，不对应 Sozai 列表里的某一个 Agent
Task“解压视频转化”“高薪恶搞热梗”等具体长期创作任务对应 Sozai 当前的单个 Agent / crawl_slot
IterationTask 下的 V1、V2、V3Sozai 目前有任务级更新和学习，但没有把版本层级完整呈现给用户
Stage创意源、方案制作、成片生成Sozai 已有流程雏形，Loop Runner 会进一步明确阶段策略、审查与 Handoff
参考边界：Sozai 当前的反馈中心、任务中心、抽屉布局，以及“每个 crawl_slot 一个管家”的作用范围，都属于 Sozai 自己的产品结构。这里主要借鉴管家逻辑，不建议把这些页面形态直接搬进 Loop Runner。

三个产品对象把分散字段整理成人能理解的东西

它们不是新增三套底层配置，而是把当前 Brief、Skill、Check、Review、反馈计划和 Memory 重新组织。

VERSION CREATIVE GENE

版本创意基因 Vn

当前版本正式生效的完整规则，也是用户确认与回看的唯一版本快照。

任务级内容
任务目标 · 全局要求 · 最终输出数量 · 用户确认的长期规则
Stage 01 阶段策略目标 · 执行要求 · 验收要求
Stage 02 阶段策略目标 · 执行要求 · 验收要求
Stage 03… 阶段策略由具体 Agent 定义数量与内容

ITERATION MEMORY

Vn 迭代记忆

只服务当前版本，不属于正式规则。

  • 用户对产物的行为与文字反馈
  • 用户与管家的对话
  • 系统完成、失败、阻塞等事件
  • 审查结果、失败修复和有效经验
  • 可绑定 Stage 与 Artifact 的证据
Vn 迭代记忆›筛选高价值学习›下一版计划›管家生成 Gene 草稿›用户确认后成为 Vn+1
用户概念回答什么底层主要映射能否被记忆直接改写
创意基因这一版整体按什么长期创作目标、全局约束、Stage 策略引用、输出数量不能，需生成新版本草稿并确认
阶段策略这个 Stage 做什么、怎么做、怎样算通过Skill / Check / Review / Schema / Exit / Routing不能，当前修复与长期规则更新分开
迭代记忆这一版运行中学到了什么反馈、行为、系统事件、审查证据、学习候选它本身就是学习，但不等于正式规则

产品交互只以 rev12 为准

用户进入 Task 后，首屏只回答三件事：现在是哪版、做到哪、我能做什么。Sozai 的逻辑被装进右侧管家，不改变这个页面层级。

平台 Agent：热梗 / Task：解压视频转化当前版本只保留一条生产主线
V1 · 已完成
V2 · 运行中
＋ 发起 V3
STAGE 01 · DONE创意源8 个通过
STAGE 02 · RUNNING方案制作当前查看
STAGE 03 · WAITING成片生成等待 Handoff
GENE V2创意基因

目标、全局规则与三个阶段策略

方案制作

全部 10通过 3待修复 2未通过 5
前轮通过 · LOOP 01

反差开场

保留为候选，Handoff 前统一复核。

当前通过 · LOOP 02

即时释放

审查通过，可以进入下游输入池。

待修复 · LOOP 02

场景代入

品牌线索出现太晚，需要局部重做。

CREATE / NEXT VERSION

左基因，右管家

新建 Task 与发起新版本共用确认页。左侧是只读 Markdown 预览，右侧通过对话和差异卡更新；用户直接确认最终输出数量。

WORKSPACE

产物按有效状态看

Stage 是主导航，产物按通过、待审、未通过、阻塞组织。Loop 轮次只是来源信息，不做主要分组。

ARTIFACT DETAIL

先结论，再证据

默认展示内容、来源、自动审查结论与人话理由。评分矩阵、Review 方法和 Checkpoint 证据按需展开。

管家的定位：版本级用户代理，不是第二套 Runner

它的价值不是多一个聊天框，而是让用户用自然语言安全地使用复杂系统。每一次“看过、记下、建议、执行完成”都有真实工具与事实支撑。

USER用户对话 · 页面操作 VERSION SESSIONV2 创意管家理解 · 核实 · 建议 · 调工具 COMMAND API命令与权限层校验 · 幂等 · 确认 · 回执 EXECUTIONLoop RuntimeStage · Retry · Handoff REVIEWReviewer审查 · 证据 · 路由建议 TRUTH STORE结构化事实状态 · 产物 · 事件 · 记忆 LEGEND · 墨蓝 = 用户的统一代理 · 运行与审查仍由确定性系统负责

关键原则：消息是解释与事件投影，状态是结构化事实。管家可以发起命令，但不能靠一句自然语言把 Stage 标成通过。

管家负责

  • 理解当前用户意图与作用范围
  • 先核实对象、规则和运行状态
  • 记录反馈、行为与系统事件
  • 生成基因 / 策略更新建议
  • 发起结构化动作并解释真实回执
  • 总结本版本并准备下一版草稿

管家不负责

  • 自行改变 Stage 状态或审查结论
  • 绕过预算、权限、幂等与确认
  • 用聊天转述代替结构化 Handoff
  • 把一次反馈直接写进长期规则
  • 把 V2 对话与记忆带进 V3
  • 替代 Agent Builder 发布新 Agent

Sozai 现有管家能力：不只是聊天，而是能读取事实并发起动作

下面列的是当前 Sozai 创意管家已经具备的工具能力。具体工具名不需要原样搬到 Loop Runner，但它说明了一个管家要真正有用，至少需要能看对象、读证据、记反馈、给建议，并把用户确认后的意图交给系统执行。

Sozai 当前工具现在能做什么对 Loop Runner 的参考价值
read_gene读取当前任务的检索需求与创意规则可以对应版本创意基因，以及各 Stage 当前采用的阶段策略
view_object(type, id)查看素材、方案、成片等真实对象与来源关系让管家围绕 Artifact 回答和操作，不只依赖标题或聊天上下文
analyze_video对具体视频进行内容理解和分析垂直 Agent 可以注册自己的对象分析能力，管家负责选择和解释
read_performance读取产出表现及相关效果数据未来可用于版本总结、产物比较和迭代方向判断
read_behavior读取用户选择、删除、反馈等行为信号为版本记忆提供真实证据，同时避免一次操作直接变成长期规则
record_feedback把用户原话与对象关系结构化记录下来在 Loop Runner 中可进一步明确 Version、Stage、Artifact 等作用范围
propose_gene_card生成基因修改建议卡，等待用户确认可参考为创意基因或阶段策略的差异建议，而不是让聊天直接改规则
order_search对已确认的检索任务正式下单说明聊天与执行可以解耦，动作由后台任务和真实状态承接
propose_order先生成高成本动作确认卡，再由用户决定是否执行可以参考到补搜、重做、继续生成等有成本或影响范围的动作

EVIDENCE FIRST

先核实对象

Sozai 当前会先读取真实对象，再讨论内容、数量、来源和表现。这个习惯很适合继续保留。

REAL ACTION

区分“说了”和“做了”

只有工具真正执行并返回结果后，管家才会表达“已经记录、已经发起”。这能让用户更信任对话里的动作。

CONFIRMATION

重要改变先确认

基因更新和高成本动作先形成卡片，让用户看清影响范围后再确认，交互会比直接暴露底层配置轻松很多。

时间流只承接交流，Workspace 承接状态和产物

可以参考 Sozai 的“三个方向各说一件事”，但它发生在 rev12 右侧管家里。Stage 进度、产物和审查仍留在左侧 Workspace。

左 · 管家方案 04 没通过品牌融合。审查理由是品牌出现太晚。
右 · 用户与页面行为针对方案 04：保留前半段，只重做后半段。
左 · 确认卡即将在 Stage 2 发起局部重做，不修改长期阶段策略。
✓ 方案 04 已重做并通过审查 · 查看产物

右侧时间流的边界

  • 左侧：管家的判断、解释、建议与确认卡
  • 右侧：用户消息和页面操作留痕
  • 居中：系统真正完成或失败的终态事件
  • 排队、百分比等变化状态不刷屏
  • 运行状态以 Workspace 与 Runner 为准
  • 管家红点只表示有新话或待确认卡
事实归属页面投影管家怎样使用
Stage 状态、Loop、预算Loop RuntimeWorkspace 的 Stage 状态只读查询，不能自行改写
产物与来源Artifact Store产物卡与详情页view_object 后回答与操作
审查结论与证据Reviewer / Checkpoint结论优先，证据折叠解释原因，提出修复动作
用户行为与反馈Behavior / Feedback Ledger右侧时间流的留痕按需读取，不因一次点击主动打扰
正式规则Version Gene Snapshot创意基因与阶段策略只通过确认卡提出修改
版本学习Iteration Memory迭代记录与下一版计划本版本总结，不跨版本直接召回
上下文建议：为了避免不同版本互相污染，可以让消息和事件始终明确关联 task_id、iteration_id，需要时再关联 stage_id、artifact_id、run_id、review_id。切换 V2 到 V3 时，管家的视觉形象可以不变，但读取的上下文应随版本切换。

Sozai 的参考方式：保留有效机制，再适配 Loop Runner 的对象层级

远端最新核对：origin/st/test@05e8fff，管家主干 origin/pmvibe-st-agent@adae908。下面主要用来帮助理解哪些机制已经被验证，哪些地方因为两个产品对象不同，可能需要进一步评估。

REFERENCE

值得参考

  • 对象核实后再回答
  • 行为、反馈、系统终态进入同一上下文
  • 消息是投影，结构化表是事实
  • 基因与下单都使用确认卡
  • 聊天与后台执行通过任务表解耦
  • 工具权限、幂等、TTL 与真实回执
  • 断线恢复、历史回放、版本冲突保护

ADAPT

可能需要适配

  • Sozai 单个 Agent / crawl_slot → Loop Runner 单个 Task
  • Sozai 的 Task 级管家体验 → Loop Runner 保留同一入口，并按 Iteration 隔离会话与记忆
  • 两份基因字段 → 任务全局 + 全部 Stage 策略
  • 素材/方案/成片 → 通用 Artifact Adapter
  • order_search → 通用 Runtime Command
  • Agent 行为账本 → 版本、Stage、产物三层归属
  • 任务终态 → Stage / Artifact / Version 作用范围

PRODUCT BOUNDARY

不建议直接沿用

  • Sozai 的抽屉、任务中心和页面导航
  • search_guidance / steer_text 两字段结构
  • 检索、方案、成片写死在核心工具箱
  • 一次反馈自动成为长期规则
  • 跨所有版本共用一份对话记忆
  • 让聊天消息承担运行状态真相
Sozai 已验证能力放到 Loop Runner 的一种理解可以继续评估的问题
view_object(type,id)Artifact Adapter 提供统一摘要、媒体与 lineageStage、Loop、Review、Handoff 引用
record_feedback反馈绑定版本、Stage 和产物即时修复与长期学习作用范围
propose_gene_cardGene / Stage Strategy 差异卡明确从哪个版本、何时生效
propose_orderRuntime Action 确认卡预算、幂等、版本冲突和回执
read_behaviorIteration 行为与系统事件查询不让历史版本污染当前版本
DO + WebSocket 持久对话版本级 Session Runtime上下文键从 agent_id 改成 iteration_id
agent_runs + 终态事件Runner 状态投影到管家Stage 级状态、Review 与 Artifact 终态

给开发评估的几个连接点：产品希望成立，但实现方式可以继续讨论

热梗场景提供了管家、行为记录和版本学习的经验，现有 Loop Runner 提供了多 Stage、审查、重试和 Handoff 的运行基础。下面只是把两边可能连接的位置摊开，方便开发结合当前实现评估，不代表已经确定技术方案或开发顺序。

产品对象映射

看看当前 Brief、Stage Definition、Review、Memory 怎样映射到创意基因、阶段策略和版本记忆，尽量不影响原有 Runner 行为。

事实读取

管家怎样读取基因、策略、产物、审查、状态和行为，保证回答来自当前版本的真实对象。

动作连接

反馈、补搜、局部重做、继续和停止怎样连接已有任务系统，同时保留确认、幂等和真实回执。

版本进化

版本总结、下一版计划、Gene 差异确认、新 Workspace 和独立管家上下文怎样自然衔接。

可以用这些用户场景一起检查方案是否顺畅

用户场景产品希望用户感受到什么可能需要开发评估的底层连接
创建 Task左侧看 Gene 预览，右侧让管家补问，只需确认关键内容和输出数量现有 Task Brief、Stage 配置与创建接口怎样映射
自动执行在 Workspace 里看 Stage、产物与真实审查状态，不需要持续盯聊天Runner 状态、Review 结果和产物事件怎样投影到页面
围绕产物反馈管家先看懂对象，再把反馈落到正确 Stage 和 Artifact对象读取、反馈归属以及现有行为账本怎样复用
Stage 重试用户能理解为什么重试、改哪里，以及新产物和旧产物的关系失败证据、定向修复、Loop 来源和 Handoff 怎样关联
准备下一版本版学习先变成可读计划，用户看清 Gene V3 的变化后再发起当前 Memory、next_iteration_plan 与新 Iteration 怎样衔接
切换历史版本Gene、Workspace、管家会话和记忆一起切换，不串版本版本上下文键、历史读取和会话隔离怎样实现
成本与失败能看到真实的失败原因、重试结果和最终回执现有预算、任务状态、错误与日志中哪些适合给用户展示
当前讨论范围：这版先聚焦 Task 创建、版本 Workspace、产物反馈、版本记忆与管家体验。完整 Agent Builder、Agent 级自动升级发布、任意 Skill 动态上传等能力可以继续保留在整体框架里，但不在这份热梗交互方案中展开。

参考资料与当前能力核对位置

产品与会议

Loop Runner 产品总览 rev12 · 交互基线 2026-07-16 Loop Runner 开发对齐会 Sozai Agent Native · 原设计 Sozai 创意管家 · 已建成版

远端实现核对

hachimi:/home/ubuntu/workspace/material-board

origin/st/test@05e8fff
origin/pmvibe-st-agent@adae908

  • docs/butler-agent-capabilities.md
  • docs/rfc-butler-task-center-unification.md
  • docs/spec-butler-chat-task-log.md
  • src/lib/agents/prompts/butler-chat.ts
  • src/do/agent-butler-do.ts