docs: 重构智能创作系统产品方案

智能创作构建系统产品方案.md

@@ -1,647 +1,1229 @@
 # 智能创作构建系统产品方案
 
-> 文档定位：纯产品方案
-> 产品形态：主 Agent 集中规划、动态任务树、一层 Worker 执行、独立 Validator 评估
-> 最新需求基线：2026-07-18
-> 实施状态：通用 Agent 框架 V1 已实现；本文中的创作 Host、业务工具、正式成果和产品页面尚待业务项目接入
-> 核心变化：从固定创作 Workflow，升级为“主 Agent 规划—Worker 执行—Validator 评估—主 Agent 重新规划”的智能创作系统
+> 文档范围：只讨论脚本创作阶段的系统能力、产品策略、业务流程、数据与工具使用，不讨论商业化、品牌、组织和底层工程实现。
+>
+> 事实基线：上一代 ScriptBuild 真实代码 + 本项目现有 Agent 框架，审查日期 2026-07-18。
 
-## 一、结论先行
+## 0. 产品定义与硬约束
 
-新的创作构建系统不再规定每篇内容必须经过几轮、每轮必须生成几路、接下来必须调用哪个角色。
+### 0.1 一句话定义
 
-系统只固定一条质量控制链路：
+智能创作构建系统沿用上一代 ScriptBuild 的输入、输出、数据源和创作工具，把“固定 Round、固定多路、固定角色调用顺序”改为：主 Agent 根据当前缺口动态创建任务，专业 Worker 执行，独立 Validator 核验，主 Agent依据证据持续重规划，最终仍交付与老版兼容的一个结构化脚本表。
+
+### 0.2 五条硬约束
+
+1. **输入不换**：仍从选题表、账号创作画像、策略、资料源和素材开始，不要求业务团队重做上游数据。
+2. **输出不换**：仍输出老版结构化脚本，而不是一组聊天文本、Task 结果或候选分支。
+3. **能力不丢**：老版 Pattern、历史脚本解构、外部搜索、知识检索、图片理解、账号模式、结构化写稿等能力均可继续使用。
+4. **编排方式改变**：不再强制每篇脚本经过相同轮次、相同多路竞争和相同角色链，由主 Agent 根据真实缺口决定下一步。
+5. **质量责任加强**：创作结果必须由独立角色验证；失败后依据问题类型返修、重试、改题、拆题、补证或阻塞，而不是机械重跑。
+
+### 0.3 关于“选题表”和“脚本表”的事实纠偏
+
+老版代码中的脚本阶段合同是：
 
 ```text
-主 Agent 制定或调整任务树
-        ↓
-Worker 完成一次有边界的执行
-        ↓
-Validator 独立检查真实结果
-        ↓
-主 Agent 根据评估报告重新规划
+已完成的选题表 + 账号创作画像 + 策略/资料
+                         ↓
+                  结构化脚本表
 ```
 
-创作步骤是动态的，质量控制责任是明确的：
+脚本阶段不是“输出一个选题表”。选题表是输入；输出是由段落、主题/形式/作用/感受四列、原子点、脚本元素及其关系构成的脚本表。若业务未来需要 Agent 生成选题表，应作为上游选题系统的独立 Mission，不改变本方案的脚本创作合同。
+
+代码证据：`prompts/script/script_build_system_v2.md:3-19`、`models.py:480-499,528-598`。
+
+## 1. 新旧系统的变化边界
+
+### 1.1 保持不变的部分
+
+| 范畴 | 保持不变的业务合同 |
+|---|---|
+| 发起对象 | 一次构建仍绑定一个 execution、一个 topic build、一个具体 topic |
+| 内容输入 | 完整选题、账号创作画像/段落模式、策略、资料源、参考素材 |
+| 创作产物 | 一份可由下游直接读取的正式结构化脚本 |
+| 脚本结构 | 一级/二级段落，主题/形式/作用/感受四列及原子点，实质/形式元素，段落—元素关系 |
+| 取数能力 | Pattern & Relation、Decode Case、External Search、Knowledge |
+| 辅助能力 | 图片理解、策略按需加载、领域事实、证据选择、脚本统计与快照读取 |
+| 质量原则 | 先取证后创作、候选与正式成果隔离、评估角色不直接改稿 |
+| 下游兼容 | 下游仍读取正式脚本表，不需要理解 Mission、Task、Attempt 或 Validation |
+
+### 1.2 被替换的部分
+
+| 老版固定机制 | 新系统策略 |
+|---|---|
+| 开始创作后固定进入 Round | 主 Agent 先判断当前最重要缺口，再创建必要任务 |
+| 每轮必须登记 multipath plan | 只有方向不确定且并行探索有价值时才建立多个候选任务 |
+| 实现 Agent 再嵌套调用取数 Agent | 复杂取数成为主 Agent 直接派发的专业任务；简单查询仍可作为只读工具使用 |
+| 固定“实现→多路评估→合并→整稿评估” | 每次任务提交后独立核验，主 Agent 按结果选择下一动作 |
+| 最多 15 个 Round | 没有业务轮次上限；由任务价值、完成条件和运行约束共同收束 |
+| 有段落/元素即可兜底成功 | 必须验证同一份完整正式脚本，Root 通过并被主 Agent 接受才完成 |
+| 通过 rewind 改写历史 | 用返修、重试、修订和替代保留过程版本，不覆盖已发生的事实 |
+
+### 1.3 不能混为一谈的对象
+
+| 老版业务对象 | 新框架对象 | 正确关系 |
+|---|---|---|
+| Round | Task | 不等价。Round 是旧版批次；Task 是当前要解决的业务问题 |
+| Branch | Attempt | 不等价。Branch 是并存候选工作区；Attempt 是同一任务的一次执行 |
+| merge | ACCEPT | 不等价。ACCEPT 表示任务结果被主 Agent 接受；正式脚本版本的写入与冻结仍由业务 Host 完成 |
+| Script 表 | Artifact Snapshot | 不等价。Artifact Snapshot 只证明提交了哪个不可变版本；正文仍在业务脚本数据中 |
+| Trace | 业务状态 | 不等价。Trace 用于解释执行过程，正式业务状态仍来自脚本表与任务运行状态 |
+
+## 2. 老版输入合同：新系统必须完整接住什么
+
+### 2.1 标准发起输入
 
-- 主 Agent 是唯一规划者，对创作总目标和任务树负责；
-- Worker 只执行本次 Task，不自行创建孙 Agent；
-- Validator 只评估，不改作品、不改任务树、不决定 Task 完成；
-- Task 是否完成、是否换人、是否改题、是否拆题，最终都由主 Agent 决定。
+上一代 `POST /api/pattern/script_builds` 的业务输入如下。新系统可以用新的任务入口承接，但不得丢字段语义。
 
-一句话定义：
+| 输入 | 是否核心 | 业务作用 | 新系统使用方式 |
+|---|---:|---|---|
+| `execution_id` | 是 | 绑定上游 Pattern execution | 用于任务归属、查询和结果回写 |
+| `topic_build_id` | 是 | 绑定选题构建记录 | 装配完整选题上下文和账号配置 |
+| `topic_id` | 是 | 指定要转成脚本的选题 | 本次脚本 Mission 的核心内容对象 |
+| `agent_type` | 兼容 | 老版执行器类型，固定为 `AigcAgent` | 兼容入口可继续接受，新系统内部不依赖它决定流程 |
+| `agent_config` | 可选，有默认 | 主模型、创作/评估/四类取数模型、温度、迭代限制 | 保留缺省补全语义，再转换为各专业角色的运行配置 |
+| `data_source_url` | 可选，有默认 | 资料库、Pattern 等数据访问根地址 | 保留默认源，并提供给只读取数能力 |
+| `strategies_always_on` | 可选 | 全程必须遵守的脚本策略 ID | 任务启动时全文装配为强约束 |
+| `strategies_on_demand` | 可选 | 按需加载的脚本策略 ID | 先提供名称和说明，必要时读取全文 |
 
-> 智能创作构建系统，是一个围绕创作总目标持续发现问题、安排执行、独立验证并动态重规划的 Agent System，而不是一条预先写死的创作流水线。
+代码证据：`pattern_server.py:1452-1523,1614-1665`。
 
-## 二、为什么不再做固定 Workflow
+### 2.2 选题表不是一句标题
 
-固定 Workflow 适合步骤稳定、输入明确、结果标准化的问题，例如“收集资料—生成初稿—审核—发布”。
+新系统读取的“选题表”必须保留以下业务层次：
 
-高质量创作的真实缺口却不固定：
+| 选题对象 | 关键内容 | 对创作的作用 |
+|---|---|---|
+| TopicBuildRecord | 用户需求、约束、策略、`personal_config` | 确定任务背景、账号和不可违反的条件 |
+| TopicBuildTopic | 选题方向、评分配置、结果、状态 | 确定脚本要展开的核心选题 |
+| TopicBuildPoint | 灵感点、目的点、关键点及点描述 | 提供脚本必须回应的内容支点 |
+| CompositionItem | 实质/形式/意图维度、元素名称、说明、分类路径、推导方式 | 提供可进入脚本四列和元素层的候选材料 |
+| ItemRelation | 选题元素之间的推导关系 | 帮助形成结构和论证链 |
+| ItemSource | 帖子、项集、分类、用户输入等来源 | 为创作与验证提供来源证据 |
+
+因此，主 Agent 不能只收到“请写一篇关于 X 的脚本”这种扁平 Prompt。它必须能读取完整选题结构，并允许专业 Worker 和 Validator 对原始点、元素、关系和来源进行核验。
+
+代码证据：`models.py:180-349`；`get_topic_detail` 的真实合同见 `script_build_tool_schemas.json`。
+
+### 2.3 人设表的兼容定义
 
-- 有的选题缺可信证据；
-- 有的事实充足，但没有形成新判断；
-- 有的观点成立，但表达没有力量；
-- 有的局部段落很好，整篇脉络却不成立；
-- 有的正文已经完成，只差标题或结尾；
-- 有的不是写得不好，而是任务定义或创作方向本身错了。
+产品层统一称为“人设/账号创作画像输入”，但需要忠于老版真实链路：
 
-如果所有内容都走同一套轮次和角色链，就容易出现：
+1. 账号名来自 `TopicBuildRecord.personal_config`；
+2. 创作人设点来自账号的 persona point records；
+3. 段落模式来自账号的 section main dimension template；
+4. 人设点按“创作阶段”和覆盖率筛选后提供给脚本构建。
 
-1. 明明不需要重新研究，却为了走流程重复检索；
-2. 明明只需修一个局部，却重新生成整篇；
-3. 每轮都机械制造多个相似候选；
-4. 到流程末尾才发现前面的证据或判断不成立；
-5. 看起来有很多 Agent，真正的下一步仍由固定程序决定。
+老代码虽然存在 `account_persona` 数据表，但当前脚本运行时并非直接查询该表。因此，新系统应提供一个统一“人设输入视图”，兼容账号名、创作人设点和段落模式，而不能假称旧版已经以某一张人设 DB 表为唯一真源。
 
-新系统不是不要秩序，而是把秩序分成两层：
+代码证据：`script_build_agent_common.py:201-213`、`script_build_agent_tools.py:1510-1594`、`pattern_service.py:3282-3335`。
 
-- 创作层：主 Agent 根据实际缺口动态规划；
-- 运行层：Worker 成功提交后必须经过独立评估和主 Agent 决策；未提交或运行异常则直接回到主 Agent 重规划。
+### 2.4 上传选题 JSON 入口
 
-## 三、产品目标与边界
+新系统继续支持第二种等价入口：上传已经解构的选题 JSON，再适配成同一种标准选题输入。
 
-### 3.1 产品目标
+最低兼容规则：
 
-系统需要具备五种能力：
+- 根对象必须包含非空“选题融合”；
+- 可从 `target_post.channel_account_name` 读取账号名，显式修订值优先；
+- 解析灵感点、目的点、关键点；
+- 从实质、形式、意图中提取元素；
+- 同一点内按“维度 + 元素名”去重；
+- 完全没有可解析元素时拒绝启动；
+- 适配完成后形成 TopicBuildRecord、Topic、Points、CompositionItems 和 Point—Item Relations，再进入与标准入口相同的 Agentic 流程；该入口不会凭空补出 ItemRelation 或 ItemSource。
 
-1. 知道当前为什么还不能完成创作；
-2. 知道下一步最值得解决什么问题；
-3. 在执行前说清楚什么结果才算合格；
-4. 不依赖 Worker 自述，能够独立检查真实产物和证据；
-5. 失败后能换人、改题、拆题或补证据，而不是机械重跑。
+代码证据：`script_build_agent_common.py:250-433`、`pattern_server.py:1668-1769`。
 
-### 3.2 产品价值
+### 2.5 可选而非新增必填的输入
 
-对创作者和运营人员而言，系统应该带来：
+用户临时补充的素材、禁止项、时限、人工指令可以作为本次 Mission 的附加约束，但不能把以下内容反向变成老业务的新必填表单：
 
-- 创作不是“模型说写完了”，而是有独立证据证明局部问题已解决；
-- 能看懂系统为什么创建当前 Task；
-- 能看懂 Validator 为什么通过、拒绝或无法判断；
-- 局部失败优先局部返工；
-- 多个候选有真实差异，而不是同义改写；
-- 用户可以随时调整目标、约束和优先级；
-- 最终作品能够追溯到相关 Task、执行尝试、评估证据和主 Agent 决策。
+- 受众状态变化；
+- 成本预算；
+- 渠道经营目标；
+- 新的人设字段；
+- 预先写死的创作步骤。
 
-### 3.3 明确不做什么
+主 Agent 可以从选题、账号画像和策略中推导这些创作判断；证据不足时再创建澄清或补证任务。
 
-第一阶段不追求：
+## 3. 老版输出合同：最终必须交付什么
 
-- Worker 创建孙 Agent；
-- 每个 Task 自己运行一套局部规划系统；
-- Validator 接管任务树；
-- Validator 直接修改被评作品；
-- Validator 说通过就自动完成 Task；
-- 默认长期复用同一个 Worker 上下文；
-- 为了显得智能而默认大规模并行或多 Validator 辩论；
-- 用更复杂的固定 Workflow 替代旧 Workflow。
+### 3.1 对业务方只有一个正式脚本
 
-## 四、系统中的四类参与者
+系统内部可以有多个任务、多个尝试和多个候选，但正式交付必须收束为一份旧格式兼容的结构化脚本。下游不应自行拼接多个 Agent 结果。
 
-### 4.1 用户
+老版正式读取规则是：读取 `branch_id=0` 且 `is_active=true` 或历史兼容值 `NULL` 的段落和元素；一级父段落未进入结果时，其二级段落也被过滤；段落—元素关系只保留两端都在有效结果中的记录。新系统可以用版本化候选保护验证一致性，但最终被接受版本必须映射为相同的正式读取语义。
 
-用户负责提供和修正业务意图：
+代码证据：`pattern_server.py:2280-2312`。
 
-- 想影响谁；
-- 希望受众产生什么理解、感受或行动变化；
-- 发布场景、账号定位和表达风格；
-- 必须使用或禁止使用的素材；
-- 时间、成本和风险约束；
-- 必要时对关键方向和最终作品做人工裁决。
+### 3.2 构建概况
 
-用户不需要提前设计 Agent 如何协作。
+`ScriptBuildRecord` 等价的构建概况继续保留：
 
-### 4.2 主 Agent
+- execution、topic build、topic 标识；
+- 运行状态；
+- `summary` 与失败原因；
+- `script_direction`；
+- 使用的策略和模型配置；
+- 段落数、元素数；
+- Token、成本、起止时间；
+- 关联的运行追溯标识。
+- 旧兼容字段 `build_workflow`。
 
-主 Agent 是唯一 Planner，也是创作结果的最终责任者。
+`build_workflow` 只作为旧读取合同保留，可以为空或提供只读的高层计划摘要；它不再驱动固定 Round，也不能成为 TaskLedger 之外的第二套规划状态。
 
-它负责：
+运行状态可以由新框架管理，但对旧消费者必须提供兼容投影。
 
-- 理解并守住创作总目标；
-- 读取当前成果、任务树和历史评估；
-- 发现当前最大的创作缺口；
-- 创建、修订、拆分、排序、阻塞/解除阻塞或取消 Task；
-- 决定使用一个 Worker 还是多个独立 Worker 发散；
-- 读取 Validator 的证据和结论；
-- 决定接受、返修、换 Worker、改 Task、拆 Task 或停止；
-- 作出哪些候选可被接纳的决策；由 Host 根据 Decision 把候选组合或晋升为正式成果；
-- 判断整项创作何时可以收束。
+代码证据：`models.py:492-525`、`pattern_server.py:2405-2442`；下游读取证据：`production_build_agent_tools.py:351-364`。
 
-主 Agent 可以参考 Validator 的建议，但不能把最终判断外包给 Validator。
+### 3.3 正式结构化脚本
+
+#### 段落表
+
+每个正式段落至少保持：
+
+| 字段组 | 内容 |
+|---|---|
+| 层级与顺序 | `paragraph_index`、一级/二级 `level`、父段落、名称 |
+| 素材范围 | `content_range`，指明文字、图片或素材位置 |
+| 四列文本 | `theme`、`form`、`function`、`feeling` |
+| 四列原子点 | `theme_elements`、`form_elements`、`function_elements`、`feeling_elements` |
+| 描述 | `description`、`full_description` |
+| 状态 | active/停用状态 |
 
-### 4.3 Worker（执行 Agent）
+#### 元素表
 
-Worker 是一次执行尝试的承担者，只完成主 Agent 交付的边界明确的 Task，例如：
+每个脚本元素至少保持：
 
-- 查证一个事实；
-- 探索一种创作方向；
-- 形成一个观点或脉络候选；
-- 写出一个段落、标题或结尾；
-- 根据已经确定的标准做局部改写；
-- 整理完成任务所需的证据。
+- 名称；
+- 一级维度：实质/形式；
+- 二级维度；
+- 共性分析；
+- 对选题的支撑；
+- 权重；
+- 支撑元素；
+- active/停用状态。
 
-Worker 可以报告新发现和风险，但不能：
+#### 段落—元素关系
+
+正式脚本必须保留段落与元素的显式关联，不能只把元素名字写进一段自然语言总结。
+
+代码证据：`models.py:528-598`。
+
+### 3.4 过程结果与正式结果分层
+
+| 结果 | 是否正式输出 | 用途 |
+|---|---:|---|
+| Retrieval 结果 | 否 | 提供 Pattern、案例、外部材料、知识和图片证据 |
+| 创作候选 | 否 | 某个局部或整稿的候选版本 |
+| Validator 报告 | 否 | 判断候选是否满足验收条件 |
+| Planner Decision | 否 | 记录接受、返修、重试、修订、拆分等决定 |
+| 正式脚本版本 | 是 | 被整体验证并最终接受的 Paragraph/Element/Link 集合 |
+| 构建概况 | 是 | 状态、方向、总结、计数和运行信息 |
+
+### 3.5 旧状态兼容与 success 门禁
+
+| 新系统事实 | 旧状态投影 | 说明 |
+|---|---|---|
+| Mission 已创建，仍有可执行或待重规划任务 | `running` | 包括 pending、running、needs_replan、waiting_children |
+| 正在执行用户停止 | `stopping` | 停止完成后转 `stopped` |
+| 用户停止且不再执行 | `stopped` | 已有候选仍保留，但不是正式成功 |
+| 暂时缺资料、权限或人工决定 | `running` 或显式阻塞说明 | 旧枚举没有 blocked；不得误报 success |
+| 运行失败且没有可交付正式版本 | `failed` | 保留失败原因和已发生的尝试 |
+| 达到护栏，只能交付明确标注的不完整正式版本 | `partial` | 必须经过整体验证，并明确缺口；不能只因有段落就 partial |
+| Root 已接受，且同一业务版本已发布、读回一致 | `success` | 唯一成功条件 |
 
-- 改变创作总目标；
-- 修改全局任务树；
-- 自行把 Task 拆成下级 Task；
-- 创建新的孙 Agent；
-- 评价自己这次执行是否已经合格；
-- 把候选结果直接写成正式成果。
+Host 对“已验证版本→旧正式读取”的发布必须幂等，并绑定 Root 接受的同一版本。发布或读回失败时，对旧消费者不得返回 `success`，应进入可重试的交付恢复状态；不能创建另一份正文偷偷替换被验证版本。
 
-### 4.4 Validator（独立评估 Agent）
+### 3.6 旧详情响应的兼容范围
 
-Validator 与主 Agent 共用完整 AgentRunner，是一个完整的单 Agent 运行时。它可以在一次 Validation 内自主规划“如何核验”，进行多轮推理，并多次调用已授权的只读工具。
+正式业务产物仍是构建概况、Paragraph、Element 和段落—元素关系。若承诺旧详情接口不改，下列辅助字段也必须继续返回：
 
-但它不是业务 Planner。“可以规划本轮核验步骤”不等于“可以规划任务树”。
+- `topic`；
+- `decision_traces`；
+- `post_datas`；
+- `script_datas`；
+- Paragraph 内嵌的 `linked_element_ids`、`linked_elements` 和 `sub_paragraphs`。
 
-但它的职责只有评估：
+新系统可以把已接受的 Decision/Evidence 投影成这些兼容辅助字段，但不能要求旧下游改为读取通用框架对象。新的 Mission 观测响应本身不增加 Round、Branch、Workflow 或页面节点；这与旧详情中的兼容字段 `build_workflow` 是两个不同合同。
 
-- 按执行前约定的验收条件逐项检查；
-- 直接查看真实产物，而不是相信 Worker 的总结；
-- 必要时独立查询已授权的 DB、API、文件、网页和证据来源；
-- 说明哪些通过、哪些不通过、哪些无法判断；
-- 指出问题发生在证据、判断、产物还是任务定义；
-- 给主 Agent 提供可选的处理建议。
+## 4. 老版能力资产盘点：新系统必须能用什么
 
-Validator 默认并不开箱提供 DB、API 或网页工具。Host 必须把业务查询工具标注为 `read` capability，并加入自定义 validator preset 白名单；未分类工具在 explicit 模式下默认拒绝。
+### 4.1 能力保留原则
 
-Validator 不能：
+老版工具分为三类，新系统的处置方式不同：
 
-- 规划业务下一步或修改任务树；
-- 新建、拆分或关闭 Task；
-- 派发 Worker 或 Validator；
-- 修改被评产物；
-- 派生新的 Agent；
-- 直接把 Task 标记为完成。
+1. **业务读取与取数能力：完整保留**；
+2. **结构化脚本写入能力：完整保留，但只能由创作 Worker 使用**；
+3. **旧 Workflow 编排工具：不再作为新产品必经步骤，仅在兼容旧存储时由 Host 内部使用**。
 
-每次 Validation 都创建新 Trace。Validator 在一轮内必须且只能成功调用一次 `submit_validation`，提交后当前 Agent Loop 立即结束。它不能自己发起第二轮验证；重新验证只能由主 Agent 在上一轮 error/stopped/expired 后发起。
+### 4.2 选题、账号、策略与当前成果读取
 
-它的产品原则是：**能力同级、职责独立、写权限受限。**
+| 能力 | 代表接口 | 使用者 | 使用时机 |
+|---|---|---|---|
+| 完整选题读取 | `get_topic_detail` | Planner、Worker、Validator | 启动判断、创作、核验选题契合度 |
+| 创作人设点 | `get_account_script_persona_points` | Planner、创作 Worker、Validator | 判断账号一致性和内容选择 |
+| 账号段落模式 | `get_account_script_section_patterns` | 创作 Worker、Validator | 结构设计与账号历史模式核验 |
+| 策略按需加载 | `load_strategy` | Planner、Worker、Validator | 需要读取 on-demand 策略全文时 |
+| 当前脚本读取 | `get_script_snapshot` | Planner、Worker、Validator | Planner 读当前成果；Worker/Validator 必须按任务提交绑定的版本读取 |
+| 脚本统计 | `get_script_stats` | Planner、Validator | 检查结构规模和完整性 |
+| 创作方向 | `get_script_direction` | Planner、Worker、Validator | Planner 读当前方向；Worker/Validator 按固定引用读取 |
+| 领域事实 | `get_domain_info` | Planner、Worker、Validator | Planner 读当前事实；Worker/Validator 只核验提交绑定的事实版本 |
 
-## 五、核心产品对象
+### 4.3 四类功能性取数 Agent
 
-### 5.1 创作总目标
+四类取数 Agent 是必须保留的核心能力，不是被通用框架替换掉的旧负担。
 
-创作总目标不是“生成一篇文章”，而是作品希望带来的受众变化。它至少需要说明：
+| 专业 Agent | 核心接口 | 输入 | 输出 | 典型用途 |
+|---|---|---|---|---|
+| Pattern & Relation Agent | `query_pattern_qa` | 自然语言取数问题、当前脚本上下文 | 结构化 Pattern、Relation、相关帖子信息 | 查账号高频结构、元素搭配、段落关系 |
+| Decode Case Agent | `search_script_decode_case` | 查询词、账号/维度/列过滤、数量 | 真实历史脚本的解构片段 | 找可借鉴的开场、转折、形式或作用结构 |
+| External Search Agent | `external_search_case`、`load_images` | 关键词、平台、数量、图片 URL | 外部帖子、正文、图片及图片理解 | 补时效案例、事实素材、视觉表达参考 |
+| Knowledge Agent | `search_knowledge` | 知识查询词、数量 | 创作方法、垂类知识、形式规则 | 补创作方法、结构规则和概念解释 |
 
-- 目标受众是谁；
-- 受众当前处于什么状态；
-- 希望作品带来什么理解、感受或行动变化；
-- 内容发布在哪里；
-- 哪些约束不可违反；
-- 最终作品满足什么条件才值得发布。
+仓库内 Decode 索引并非空接口：当前样本清单记录 115 篇帖子、45,972 个 chunks、323,632 tokens。证据：`script_embedding_search/index/manifest.json:1-11`。
 
-创作总目标是任务树的根。任何 Task 都必须说明自己如何推进它。
+#### 在新系统中的两种使用方式
 
-### 5.2 动态任务树
+- **复杂取数**：主 Agent 创建一个独立取数任务，由对应专业 Agent 执行并由 Validator 验证；当它是后续创作任务的直接子任务时，被接受的结果会在父 Attempt 创建时成为固定输入；其他关系必须由 Host 显式提供不可变结果引用。
+- **简单查询**：创作 Worker 或 Validator 可以直接调用已授权的只读查询工具，不必为一次小查询机械创建任务。
 
-任务树表达“为了完成总目标，目前发现了哪些问题、正在解决什么、已经确认了什么”。
+新系统不允许创作 Worker 私自生成新的业务 Agent 或修改任务树。需要多步检索、独立验收或会影响后续多个任务的取数，必须回到主 Agent 建立专业任务。
 
-它不是预先生成的流程图，而是在创作过程中逐步生长：
+### 4.4 参考资料与明细能力
 
-- 主 Agent 发现缺口时创建 Task；
-- 一个问题过大时拆成子 Task；
-- 一个方向存在多种高价值可能时创建多个候选 Task；
-- 新证据推翻原判断时修订或替代受影响 Task；
-- 因用户、权限或外部条件暂时无法继续的 Task 可以阻塞等待；已失去价值的 Task 可以直接取消；
-- 总目标验收通过后，整棵树才收束。
+除四类核心 Agent 外，老版工具资产还包含：
 
-树的层级表示业务问题关系，不表示 Agent 递归关系。所有任务都由主 Agent 规划，再交给一层 Worker。
+- 参考脚本与帖子：`get_reference_scripts`、`get_topic_related_posts`、`get_post_details`；
+- 历史脚本搜索：`search_post_scripts`、`search_post_scripts_by_topic_name`、`get_post_script_decode`；
+- Topic/Script Pattern：meta、按名称查询、关联查询、帖子明细；
+- Paragraph Pattern：meta、按名称查询、帖子明细；
+- Script Sequence：meta、list、detail、按类别搜索；
+- 类别信息：`get_category_detail`。
 
-### 5.3 Task 任务卡
+这些能力可以作为 Pattern、Decode 或创作 Worker 的细化只读工具，但不要求业务用户理解每个底层接口。
 
-每个 Task 在交给 Worker 前，需要把“做什么”和“怎样才算做好”说清楚：
+### 4.5 图片理解
 
-| Task 内容 | 产品含义 |
+`load_images` 是独立的多模态辅助能力，不在 57 个 JSON Schema 工具清单中。使用规则：
+
+- 当图片本身影响形式、构图、情绪或素材范围判断时调用；
+- 只有文字说明已足够时不批量加载图片；
+- 图片观察结论必须与图片来源一同进入证据；
+- Validator 可只读复核，不允许改写脚本。
+
+### 4.6 结构化脚本写入能力
+
+创作 Worker 必须继续能够写出旧版结构，而不是只提交 Markdown：
+
+| 动作 | 老版代表工具 | 产品语义 |
+|---|---|---|
+| 创建段落 | `create_script_paragraph` | 创建一级/二级层级、内容范围和初始四列原子点 |
+| 追加四列原子点 | `append_paragraph_atoms` | 向主题/形式/作用/感受追加原子元素 |
+| 删除错误原子点 | `delete_paragraph_atom` | 做局部、可解释的删除 |
+| 创建脚本元素 | `create_script_element` | 建立实质/形式元素 |
+| 更新脚本元素 | `update_script_element` | 修订元素名称、一级/二级维度或 active 状态 |
+| 建立段落—元素关系 | `batch_link_paragraph_elements` | 形成结构化关联 |
+| 删除错误关系 | `delete_paragraph_element_links` | 解除错误支撑关系 |
+| 批量更新段落 | `batch_update_script_paragraphs` | 做局部结构和文本修订 |
+
+同时保留：
+
+- `save_domain_info`：追加已核实领域事实；
+- `record_data_decision`：记录采用/舍弃哪些资料及其理由；
+- 当前脚本快照与候选读取：保证 Worker 修改的是明确版本。
+
+需要注意一个真实能力缺口：老版 Element 数据模型虽然包含 `commonality_analysis`、`topic_support`、`weight_score`、`support_elements`，但当前 `create_script_element` / `update_script_element` 工具只允许写名称、一级/二级维度以及 active 状态。新系统第一阶段必须保持这些输出字段可读和兼容，不能声称旧 Worker 已能填满它们；若业务要求非空，应把“补齐元素分析字段的受控写入”列为业务能力增强，并纳入 Validator 验收。
+
+还要保留一个兼容门禁：老版实现 Worker 在 `branch_id>0` 的候选分支首次调用 `create_script_paragraph` 或 `create_script_element` 前，要求存在 `record_task_plan`；base、调试和主 Agent 场景有放行。新系统不能让这份旧计划变成第二套规划真源。推荐由 Host 把当前框架 Task 自动映射为最小兼容执行清单，并同步必要的 step 状态；长期可改造旧写工具直接以框架 Task 作为门禁。无论采用哪种方式，验收都必须证明 Creative Worker 不需要人工再维护一套旧 Workflow 才能写稿。
+
+代码证据：`script_build_tool_schemas.json` 中的 `create_script_element/update_script_element` 合同；写入门禁见 `script_build_agent_tools.py:2454,2991-2995,3106`。
+
+### 4.7 评估能力
+
+老版两类评估知识继续保留，但由新框架的独立 Validator 承载：
+
+| 老版角色 | 新系统承接方式 |
 |---|---|
-| 局部目标 | 这次具体解决什么问题 |
-| 产生原因 | 为什么现在值得做 |
-| 与总目标关系 | 它如何推进创作总目标 |
-| 已知结论 | 已经确认、无需重复研究的内容 |
-| 工作上下文 | Worker 真正需要的材料和约束 |
-| 交付要求 | 必须交付什么可观察结果 |
-| 验收标准 | Validator 要检查什么 |
-| 证据要求 | 哪些结论必须能被独立核验 |
-| 依赖关系 | 哪些任务完成后才能开始 |
-| 成本边界 | 最多尝试、候选或投入多少 |
+| `script_multipath_evaluator` | 当确有多个候选时，沉淀为比较 Worker 的领域方法，以及后续 Validator 的核验规则 |
+| `script_evaluator` | 作为局部脚本核验和 Root 整稿核验的领域评估规则 |
+
+核验至少覆盖：
+
+- 选题核心前提和创作方向；
+- 账号人设与段落模式一致性；
+- 领域事实和引用可靠性；
+- 段落结构与叙事关系；
+- 主题/形式/作用/感受四列质量；
+- 元素质量、元素与段落关联；
+- 具象可执行性、信息扩展度；
+- 写入内容是否能回溯到被采用的证据。
 
-这是创作产品的理想任务卡，不是 Framework V1 已内建的全部字段。当前通用 TaskSpec 只固定 objective、acceptance criteria 和 context refs；产生原因、业务依赖图、候选数和成本边界需由创作 Host 扩展，或在 V2 纳入通用策略。V1 内核直接支持的结构关系是父子 Task，不是通用 DAG 依赖引擎。
+### 4.8 57 个 Schema 工具资产与实际启用能力的区别
 
-如果主 Agent 改变了 Task 的目标或验收标准，就形成一个新的任务版本。旧版本及其执行历史仍然保留，不能为了让结果看起来通过而悄悄改标准。
+`script_build_tool_schemas.json` 有 57 个工具 schema；`load_images` 另由运行时提供。但 57 个工具并不等于每个角色都能使用全部工具。实际权限由角色白名单裁剪。
 
-### 5.4 一次执行尝试
+产品规则：
 
-同一个 Task 可以有多次执行尝试：
+- Planner 默认只读和任务控制，不直接写脚本；
+- Retrieval Worker 只读，不写脚本；
+- Creative Worker 可读、取数并写候选脚本；
+- Validator 只读和提交核验结论；
+- 业务终态、正式版本接受和运行控制由 Host/主 Agent 的明确决定驱动。
 
-- 第一次由 Worker A 完成；
-- 未通过后，可以换 Worker B 重做同一 Task；
-- 也可以在条件合适时让 Worker A 做一次局部修补。
+完整资产清单见附录 A。
 
-每次 Attempt 的记录和 Snapshot 都独立保留；repair 可以续用同一 Worker Trace，但仍会生成新 Attempt 和 Snapshot。Worker 正式调用 `submit_attempt` 只代表提交候选结果，不代表 Task 已通过；未提交、失败、停止或过期的 Attempt 会直接回到需重规划。
+## 5. 新系统的角色设计
 
-### 5.5 评估报告
+### 5.1 业务 Host
 
-评估报告由 Validator 产生，至少让用户和主 Agent 看懂：
+业务 Host 负责把老版业务资产装配到通用框架中：
 
-- 对照的是哪个 Task 版本和哪次执行；
-- 每条验收标准是通过、不通过还是无法判断；
-- 结论依据了哪些真实证据；
-- 是否存在未核实的说法；
-- 问题属于局部小修、路线错误、证据不足还是任务定义不清；
-- Validator 建议主 Agent 考虑哪些动作。
+- 从旧输入装配选题、人设、策略和资料上下文；
+- 注册旧读取、取数、图片和脚本写入能力；
+- 为不同角色配置可用工具；
+- 保存候选脚本和正式脚本版本；
+- 把最终被接受版本投影为旧版兼容输出；
+- 对业务方提供任务状态、正式结果和追溯信息。
 
-评估报告是决策输入，不是最终业务决策。
+框架不会自动理解 Topic、Persona、Paragraph 或 Element，这部分仍由脚本业务团队负责。
 
-### 5.6 主 Agent 决策
+### 5.2 主 Agent / Planner
 
-收到评估报告后，主 Agent 必须明确选择一种动作：
+主 Agent 是唯一业务规划者，负责：
 
-- 接受本次结果，完成 Task；
-- 让原 Worker 在原上下文中做一次局部修补；
-- 保持 Task 不变，换新 Worker 重新执行；
-- 修订 Task 的目标、上下文或验收标准；
-- 把 Task 拆成多个更小的子 Task；
-- 用 `task_plan` 创建补证据 Task，或使用 split/revise/block 组合表达；
-- 暂时阻塞，等待用户或外部条件；
-- 解除阻塞后回到重规划；
-- 取消或用新 Task 替代旧 Task。
+- 理解本次选题、账号画像、策略和当前脚本；
+- 判断现在缺的是资料、方向、结构、局部表达、元素关系还是整稿收束；
+- 创建、排序、拆分、修订、阻塞、替代或取消任务；
+- 决定是否值得并行探索多个候选；
+- 选择适合的 Retrieval Worker、Creative Worker 或核验方式；
+- 阅读 Validator 结论并作出接受、返修、重试、修订、拆分等决定；
+- 派发 Root 整合任务并最终接受整稿。
 
-V1 没有独立 `request_evidence` DecisionAction。`task_decide` 的原子动作是 accept、repair、retry、revise、split、block、unblock、cancel 和 supersede；Validator 运行异常后的 revalidate 通过独立 `validate_attempt` 工具发起。
+主 Agent 不直接逐行写脚本，也不能用自由文本“我完成了”结束 Mission。
 
-### 5.7 候选产物与正式成果
+上述动作受状态约束：Root 不能取消或被替代；普通任务只有在接受前的可决策状态才能原地修订或替代。已经 ACCEPT 的任务是历史事实，不能原地改写；如果其结果后来失效，应创建纠偏/综合任务，让上层只消费新的统一结果，必要时启动新的 Mission。
 
-Worker 交付的观点、结构、段落、标题和脚本首先都是候选。
+### 5.3 专业取数 Worker
 
-只有经过 Validator 评估，并由主 Agent 明确接纳后，候选才具备进入正式创作成果的资格。Framework V1 的 accept 只把 Task 标记为 completed，不会自动把 Artifact 写入业务“正式成果”；候选晋升、组合和发布由 Host 根据 PlannerDecision 执行。候选可以被：
+四类专业 Worker 分别承接 Pattern、历史解构、外部搜索、知识检索。其任务边界必须说明：
 
-- 接纳；
-- 与其他候选组合；
-- 暂存；
-- 退回修改；
-- 淘汰，并保留淘汰理由。
+- 要回答的具体问题；
+- 允许使用的来源；
+- 所需返回结构；
+- 如何判断召回足够；
+- 哪些结论仍然不确定；
+- 证据如何被后续脚本引用。
 
-## 六、一次完整运行怎样发生
+取数结果是证据候选，不自动成为脚本事实。
+
+### 5.4 创作 Worker
+
+创作 Worker 只处理明确边界的任务，例如：
+
+- 形成创作方向候选；
+- 设计开场结构；
+- 写一个一级段落及其二级段落；
+- 补主题/形式/作用/感受原子点；
+- 创建并关联脚本元素；
+- 修正 Validator 指定的局部缺陷；
+- 汇总已接受的子任务结果，形成完整正式候选。
+
+创作 Worker 可以使用简单只读工具，但不能自行更改全局目标、创建新业务任务或宣布自己的结果合格。
+
+### 5.5 Validator
+
+Validator 独立读取任务要求、同一份候选版本和证据，逐项核验：
+
+- 每个验收条件是否通过；
+- 哪些证据直接支撑结论；
+- 哪些内容无法核实；
+- 风险发生在资料、事实、创作、结构还是任务定义；
+- 建议主 Agent 返修、重试、修订、拆分或阻塞，但不替主 Agent作决定。
+
+Validator 不改脚本、不创建任务、不派发 Agent、不把任务直接标记完成。
+
+## 6. Agentic 脚本创作主流程
+
+### 6.1 流程总览
 
 ```text
-读取总目标、正式成果和任务树
-        ↓
-主 Agent 判断当前最重要的缺口
-        ↓
-创建或修订 Task，冻结交付与验收条件
-        ↓
-启动一个新的 Worker 执行尝试
-        ↓
-Worker 提交候选产物、证据和执行说明
-        ↓
-Validator 用独立上下文查验真实结果
-        ↓
-Validator 提交评估报告
-        ↓
-主 Agent 做最终决策并重新规划
-        ↓
-继续执行、换人、改题、拆题，或完成总目标
+老版兼容输入
+  选题表 + 人设/账号画像 + 策略 + 资料源
+                  ↓
+Host 装配一次脚本 Mission 与整稿验收条件
+                  ↓
+主 Agent 读取当前事实，识别最重要缺口
+                  ↓
+按需创建取数 / 方向 / 结构 / 局部创作 / 修复 / 比较任务
+                  ↓
+专业 Worker 执行并提交候选版本与证据
+                  ↓
+独立 Validator 核验同一候选版本
+                  ↓
+主 Agent 接受 / 返修 / 重试 / 修订 / 拆分 / 阻塞 / 替代
+                  ↓
+Root Worker 消费已接受结果，写出完整正式候选版本
+                  ↓
+Root Validator 核验完整脚本表，主 Agent 最终接受
+                  ↓
+输出老版兼容 ScriptBuildRecord + Paragraph + Element + Link
 ```
 
-触发主 Agent 重新规划的事件包括：
+### 6.2 启动：把旧输入装配成一次 Mission
+
+启动时不要求用户填写新的创作流程。Host 完成四件事：
+
+1. 校验 execution/topic build/topic 的挂载关系；
+2. 装配完整选题、账号画像、策略、资料源和已有脚本；
+3. 建立 Root 目标：“为该选题形成满足账号、策略、结构和证据标准的一份正式结构化脚本”；
+4. 建立整稿验收条件，至少覆盖输入一致性、结构完整性、事实证据、账号一致性和正式输出可读性。
+
+`script_direction` 不是第二个 Mission 状态。它是创作过程中形成并可验证的业务成果；接受前可随任务修订，接受后如果失效则建立新的纠偏/综合任务，不能改写原接受事实。Root 目标描述整项交付使命。
+
+### 6.3 主 Agent 初判：先找缺口，不先套流程
 
-- Worker 未正式提交、运行失败、停止或过期；
-- Validator 完成评估；
-- Validator 无法判断或执行异常；
-- 新证据推翻已有判断；
-- 用户修改目标或约束；
-- 多个候选发生冲突；
-- 某个 Task 连续失败；
-- 成本接近限制；
-- 当前作品已经具备收束条件。
+主 Agent 首次读取：
 
-## 七、Task 状态与完成边界
+- 完整选题点、元素、关系和来源；
+- 账号创作人设点与段落模式；
+- always-on 策略和 on-demand 策略摘要；
+- 当前脚本快照、方向、统计和领域事实；
+- 已经完成、失败或被接受的任务。
 
-用户看到的 Task 状态建议使用直接可懂的语言：
+然后只创建当前必要任务。例如：
 
-| 状态 | 含义 |
+| 当前情况 | 主 Agent 动作 |
 |---|---|
-| 待执行 | 已规划，尚未交给 Worker |
-| 执行中 | Worker 正在完成一次尝试 |
-| 待评估 | Worker 已提交，等待 Validator |
-| 评估中 | Validator 正在独立查验 |
-| 待主 Agent 决策 | 已有评估报告，等待最终处理 |
-| 需重规划 | 不能直接接受，需要换人、改题或补证据 |
-| 等待子任务 | 原 Task 已拆分，等待下级问题解决 |
-| 已完成 | 主 Agent 已明确接受结果 |
-| 已替代 | 主 Agent 用新 task_id 取代了旧 Task；同 task_id 的 revise 只会增加 spec_version 并回到待执行 |
-| 已阻塞 | 需要用户或外部条件才能继续 |
-| 已取消 | 主 Agent 或用户决定不再继续 |
-
-必须明确四件不同的事：
+| 选题事实与来源已经充分 | 不创建重复检索任务，直接进入方向或结构任务 |
+| 核心事实没有可信来源 | 创建 Pattern/External/Knowledge 取数任务 |
+| 不确定账号常用开场结构 | 创建账号 Pattern 或 Decode Case 任务 |
+| 方向明确、只缺一个段落 | 只创建局部段落任务，不重写整稿 |
+| 两种方向都可能显著更好 | 创建两个并列候选任务，再建立比较/综合任务 |
+| Validator 指出一个关系错误 | 只修关系，不机械再跑全流程 |
+| 选题前提本身被证据推翻 | 修订 Root/相关任务，必要时等待人工确认 |
 
-```text
-Worker 运行结束
-≠ Worker 结果合格
-≠ Validator 判断通过
-≠ Task 已完成
-```
+### 6.4 专业任务执行与独立验证
 
-只有主 Agent 明确接受，Task 才完成。
+每个任务在执行前要明确：
 
-## 八、Validator 怎样评估
+- 这次解决什么问题；
+- 为什么现在要解决；
+- 输入引用哪些选题、人设、策略、证据或已接受子结果；
+- 交付什么候选结果；
+- 每条验收条件；
+- 允许使用哪些工具；
+- 不允许改动哪些范围。
 
-### 8.1 先检查能被客观验证的部分
+Worker 完成后提交候选版本、摘要和证据。Validator 必须核验提交时冻结的同一版本，不能在内容变更后沿用旧报告。
 
-例如：
+### 6.5 主 Agent 重规划动作
 
-- 是否真的交付了要求的段落或金句；
-- 必填内容是否完整；
-- 引用和事实是否能找到来源；
-- 数据库或接口中是否真的存在对应结果；
-- 是否违反长度、格式、禁用词和账号约束；
-- 产物是否仍包含占位提示。
+| 动作 | 适用条件 | 产品行为 |
+|---|---|---|
+| 接受 | 结果满足条件且值得进入上层任务 | 固定为后续任务可消费的已接受结果 |
+| 返修 | 方法大体正确，只有有限局部问题 | 在同一任务上明确缺陷和修复边界 |
+| 重试 | 任务定义正确，但本次运行异常或执行质量偶发失败 | 启动新的执行尝试，不覆盖旧尝试 |
+| 修订 | 目标、验收条件或上下文本身不正确 | 形成新版本任务再执行 |
+| 拆分 | 问题过大或多个失败原因耦合 | 拆成更小、可独立验证的子任务 |
+| 阻塞 | 缺权限、缺关键资料或需人工决定 | 保存原因和解除条件，等待外部输入 |
+| 替代 | 新证据使旧方向失效 | 保留旧历史，用新任务取代 |
+| 取消 | 任务不再推进 Root 目标 | 停止继续投入 |
 
-这些问题优先依靠工具和明确规则验证。
+这组动作替代固定 Round 自增。
 
-### 8.2 再评价需要判断的创作质量
+### 6.6 Root 整合与最终收口
 
-例如：
+当所有后代都已收束为 completed、cancelled 或 superseded，且 Root 所需的直接子任务均已接受后：
 
-- 是否真正推动创作总目标；
-- 核心判断是否成立；
-- 表达是否适合目标受众；
-- 候选是否有实质差异；
-- 新颖性、可理解性和整体兼容性如何；
-- 局部产物是否兑现了任务承诺。
+1. 创建 Root Attempt 时，框架按直接子任务 `display_path` 顺序冻结它们的 ACCEPT Decision；Root Worker 只消费这组绑定结果；
+2. 更深层的取数、方向和局部结果必须先由其直接父任务吸收，不能让 Root 扫描任意后代；
+3. Root Worker 使用旧结构化写入能力，把方向、段落、四列、元素和关系整合成一份完整、可重读的业务候选版本；
+4. Host 先把该版本写入隔离的 staging/候选工作区，并用旧正式读取规则做兼容预检；未通过 Root Validation 前不得进入 `branch_id=0` 正式结果；Root Validator 核验的必须是这同一 staging 版本；
+5. 主 Agent ACCEPT Root 只确认该版本满足 Mission，不会自动 merge 或发布业务数据；Host 必须以该 ACCEPT 绑定版本为键做幂等发布；
+6. 只有发布成功、旧详情读回一致、Root 已接受三者同时成立，业务状态才投影为 `success`；发布失败进入交付恢复，不生成另一份正文；
+7. 已接受版本不可修改。发布后如需改正文，应启动新的 Mission 或独立修订运行，不能重开已 completed 的 Root 或沿用旧 Validation。
 
-Validator 不只给一个笼统总分，而应逐项说明依据。
+### 6.7 全局收敛护栏
 
-### 8.3 允许无法判断
+取消固定 15 Round 不等于无限执行。每次 Mission 启动时必须设置产品级运行护栏：
 
-当证据不足、外部服务不可用或验收标准不清时，Validator 应返回“无法判断”，不能为了给答案而猜测。
+- 最大总尝试数和各类专业任务尝试数；
+- 最大总运行时间及单任务超时；
+- 同一任务定义最多一次 repair；repair 后仍失败必须 revise、split、block 或停止；
+- 连续若干次 Validation 没有改善时停止原方法；
+- 外部检索的最大查询次数和空召回容忍次数；
+- 用户停止与人工裁决触发条件；
+- 达到护栏后的收口规则：无可交付版本为 failed；有经整体验证但明确不完整的版本才可 partial；依赖仍可能补齐则 block。
 
-“无法判断”不等于 Task 失败。主 Agent 可以补证据、修订 Task，或者请求用户介入。
+护栏限制运行，不规定脚本必须走哪些创作阶段。
 
-如果 Validator 本身运行异常、被停止或过期，这不是 failed/inconclusive 结论。主 Agent 可通过 `validate_attempt` 对未变 Snapshot 启动新 Validator Trace；已有效返回 failed/inconclusive 时则必须重新规划，不能用重验证刷结论。
+## 7. 动态任务库：可选能力，不是固定 Workflow
 
-## 九、Task 1.1 未通过以后怎么办
+以下是主 Agent 可选择的任务类型。它们是“工具箱”，不是每篇脚本都必须执行的阶段。
 
-假设 Task 1.1 是“为结尾写出一句让读者立即行动的金句”。
+| 任务类型 | 解决的问题 | 常用输入 | 产出 |
+|---|---|---|---|
+| 输入一致性检查 | 选题、人设、策略是否齐全、互不冲突 | Topic/Persona/Strategy | 缺失项或可执行上下文 |
+| 事实补证 | 核心说法是否可信 | Topic Sources、Pattern、External、Knowledge | 带来源的事实包 |
+| 账号模式研究 | 账号常用结构与表达是什么 | Persona、Section Pattern、Decode | 账号模式摘要与适用边界 |
+| 创作方向 | 这份选题应如何转成脚本 | 选题、账号、策略、事实 | `script_direction` 候选 |
+| 结构设计 | 一级/二级段落如何组织 | 方向、案例、账号模式 | 段落骨架候选 |
+| 局部段落创作 | 完成特定段落 | 骨架、证据、已接受子结果 | Paragraph 候选 |
+| 四列补全 | 主题/形式/作用/感受缺口 | 段落、Pattern、Decode | 四列文本和原子点 |
+| 元素与关联 | 哪些实质/形式元素支撑哪些段落 | Topic items、段落 | Element 与 Link 候选 |
+| 局部修复 | 修复 Validator 指定问题 | 原候选、失败报告 | 新候选版本 |
+| 候选比较 | 多个高价值候选如何选或组合 | 已验证候选 | 比较 Worker 产出差异/风险/采用建议，Validator 再核验 |
+| 整稿组合 | 把接受的子结果形成完整脚本 | 已接受 Decision/Artifact | 完整正式候选 |
+| 整稿验收 | 完整脚本是否可交付 | 正式候选、全部输入和证据 | Root Validation |
 
-Worker A 返回的内容只有：“这里应该补一句有力量的金句。”
+主 Agent 可以跳过、重复、拆分或合并这些任务，只要每个动作能说明其对 Root 交付的价值。
 
-Validator 读取真实结尾后判断：没有交付实际金句，核心验收项不通过。
+任务树设计必须服从直接子结果规则：父 Attempt 自动绑定的只是其直接子任务的 ACCEPT Decision；更深层结果要先由直接父任务吸收。Root 的直接子任务应是少量可组合的最终贡献，不应把所有检索和局部任务平铺到 Root 下。已经接受但后来失效的结果不会消失，应由新的综合任务显式解释新旧关系，并只把统一后的结果交给上层。
 
-主 Agent 可以有四种不同处理方式。
+## 8. 取数与证据策略
 
-### 9.1 Task 没问题，Worker 路线不好
+### 8.1 先判断问题类型，再选择数据源
 
-主 Agent 保持 Task 1.1 不变，创建第二次执行尝试，换 Worker B 重做。
+| 问题 | 首选能力 | 不足时补充 |
+|---|---|---|
+| 账号常用元素、搭配和关系 | Pattern & Relation | Decode Case |
+| 真实脚本如何完成某种结构 | Decode Case | 参考脚本明细、Paragraph Pattern |
+| 时效案例、外部事实、平台表达 | External Search | 图片理解、Knowledge |
+| 创作方法、垂类概念、形式规则 | Knowledge | External/Pattern 交叉核实 |
+| 账号一致性 | Persona Points、Section Patterns | 账号 Decode Case |
+| 选题来源和推导 | Topic detail、Item Sources/Relations | Pattern/External |
+| 视觉构图与素材范围 | `load_images` | 帖子文字和图片理解文本 |
 
-### 9.2 只是明确的局部小修
+### 8.2 证据结果的最低结构
 
-如果 Worker A 已经完成其他部分，只遗漏一句具体表达，主 Agent 可以让它沿用原 Worker Trace 补一次，但仍创建新 Attempt 和 Snapshot，再交给新的 Validator Trace 评估。
+每个被创作任务采用的资料至少说明：
 
-### 9.3 Task 定义有问题
+- 来源类型；
+- 来源标识或可重读引用；
+- 来源内容摘要；
+- 它回答了哪个问题；
+- 采用、改写或舍弃的原因；
+- 可信范围和未知项；
+- 它将支撑哪个段落、四列原子点或脚本元素。
 
-如果“有力量”太模糊，主 Agent 保留旧任务历史，形成新的 Task 1.1 版本，补充受众、语气和行动要求，再交给新 Worker。
+模型记忆不能作为事实来源。取证为空时，不把推测写进正式脚本；应补证、降低表述强度或阻塞相关任务。
 
-### 9.4 Task 太大，需要拆分
+### 8.3 事实与创作表达分离
 
-主 Agent 把 Task 1.1 设为“等待子任务”，拆成：
+新系统把两类判断分开：
 
-```text
-Task 1.1.1：确认结尾要触发的具体情绪和行动
-Task 1.1.2：根据已确认约束写出实际金句
-```
+1. **事实是否成立**：由来源、领域知识和交叉核验决定；
+2. **如何转成脚本**：由选题、人设、策略、结构和表达目标决定。
 
-运行过程是：
+已核实的领域事实可以进入领域信息，供后续任务复用；是否写入脚本仍需要创作任务决定。
 
-```text
-1.1.1 → Worker → Validator → 主 Agent 接受
-        ↓
-主 Agent 再启动 1.1.2
-        ↓
-1.1.2 → Worker → Validator → 主 Agent 接受
-        ↓
-主 Agent 回到 1.1，判断两个子结果是否真正解决原问题
-```
+### 8.4 被接受的子结果如何进入上层任务
+
+复杂取数、方向或候选任务被接受后，后续父任务使用的是明确的接受决定及其对应版本，而不是“扫描当前最新结果”。这样可避免：
+
+- 子任务在父任务执行中途变化；
+- 父任务错误使用尚未验证的候选；
+- 重试后无法解释到底用了哪个证据版本；
+- 多个同名结果发生隐式覆盖。
+
+## 9. 发散、比较与收束策略
+
+### 9.1 什么时候值得多候选
+
+仅在以下情况创建并列候选：
+
+- 方向选择会显著改变整稿；
+- 资料存在两种合理但冲突的解释；
+- 结构、语气或形式方案之间有真实差异；
+- 单一路径失败代价高，提前对冲更划算；
+- Validator 认为原方案到达局部上限，需要换解法而非小修。
+
+以下情况不应机械多路：
+
+- 只需查一个确定事实；
+- 只需修一个字段或关系；
+- 两个候选只是同义改写；
+- 验收条件本身尚未明确；
+- 成本和时间约束不允许，而单路已足够。
+
+### 9.2 候选必须真正独立
+
+候选任务要明确差异轴，例如：
+
+- 证据路径不同；
+- 叙事结构不同；
+- 开场承诺不同；
+- 形式载体不同；
+- 账号表达策略不同。
+
+不能只要求“再写一个版本”。
+
+### 9.3 比较结果不是自动合并
+
+候选比较由只读比较 Worker 先产出比较结果，至少给出：
+
+- 各自解决了什么；
+- 各自未解决什么；
+- 证据可靠性；
+- 与选题、人设和策略的一致性；
+- 是否可以组合；
+- 组合会产生哪些冲突；
+- 推荐采用、返修、淘汰或保留的理由。
+
+Validator 只核验该比较结果是否完整、证据是否成立、是否公平覆盖各候选；主 Agent 决定采用哪些结果；Root Worker 才负责形成完整脚本版本。
+
+## 10. 验证与质量门禁
+
+### 10.1 每个任务都要有可核验条件
+
+好的验收条件必须指向可观察结果。例如：
+
+| 模糊要求 | 可核验改写 |
+|---|---|
+| “开场更吸引人” | 首个一级段落明确选题冲突；作用列说明注意力机制；引用至少一个账号/案例证据 |
+| “符合人设” | 采用的人设点可回溯；不得违反账号禁用特征；结构与账号段落模式差异有理由 |
+| “有事实支撑” | 每个领域事实有来源引用；无法核实的说法已删除、降级或标为未知 |
+| “结构完整” | 一级/二级关系有效；四列与原子点齐全；元素与段落关系无孤立或跨版本引用 |
 
-子 Task 都完成，父 Task 也不能自动完成。主 Agent 仍需要做一次整体判断。
+### 10.2 局部 Validator 的核验顺序
 
-## 十、Worker 什么时候释放，什么时候继续使用
+1. 身份与版本：是否是当前任务要求的同一候选；
+2. 结构完整：提交结果是否能读取、字段是否齐全；
+3. 证据闭合：结果是否引用允许且真实存在的资料；
+4. 逐条验收：每条条件分别通过、失败或无法判断；
+5. 越界检查：是否修改了任务之外的正式内容；
+6. 风险说明：未核实说法、冲突、遗漏和建议动作。
 
-产品默认策略是：**一次执行尝试使用一个干净 Worker 上下文。**
+### 10.3 Root 整稿验收
 
-Worker 提交后，本次 Agent Loop 结束。Trace 和消息会持久保留，但系统默认不在下一次 Attempt 续用这份上下文。系统保留：
+Root Validator 必须针对完整正式候选，而不是最后一个局部结果，至少检查：
 
-- Task 和任务版本；
-- 执行过程；
-- 产物和证据；
-- Validator 报告；
-- 主 Agent 决策。
+- 输入挂载和选题核心前提正确；
+- `script_direction` 与整稿一致；
+- 账号人设和段落模式符合或有合理偏离说明；
+- 领域事实和引用可重读；
+- 段落层级、顺序、四列和原子点完整；
+- Element 字段完整且与选题相关；
+- Paragraph—Element 关系有效；
+- 正式版本中不存在未接受候选的隐式内容；
+- 构建摘要和计数与正式版本一致；
+- 下游可以按老版合同读取。
 
-大白话就是：**不删除本次对话记录，只是下一次默认换一份干净上下文。**
+Validator 报告通过不自动结束 Mission；主 Agent 仍需确认该结果值得接受。
 
-只有同时满足以下条件，才适合继续使用原 Worker：
+## 11. 异常、失败与恢复策略
 
-- 还是同一个 Task；
-- 目标和验收标准没有变化；
-- Validator 指出的是局部、明确的小修；
-- 原方案总体成立；
-- 当前 TaskSpec 尚未使用过 repair 续用；V1 默认每个版本最多一次。
+| 场景 | 产品判断 | 下一步 |
+|---|---|---|
+| 取数为空 | 不是创作失败，而是证据不足 | 换查询、换数据源、降低表述或阻塞 |
+| Worker 运行异常 | 任务定义可能仍正确 | 新 Attempt 重试，不覆盖旧记录 |
+| 结果局部不合格 | 方法大体正确 | 限定范围 repair |
+| 同一任务定义的一次 repair 后仍不合格 | 方法或任务定义可能错误 | revise、split、block 或建立纠偏任务；不在原 spec 上循环 repair |
+| Validator 无法判断 | 验收条件或证据不足 | 补证、修订条件或换确定性检查 |
+| 候选冲突 | 不能静默按顺序覆盖 | 创建比较/综合任务，显式选择 |
+| 选题前提被推翻 | Root 目标或方向失效 | 修订相关任务，必要时人工确认 |
+| Root 接受前，正式候选写入后又变化 | 原验证失效 | 冻结新版本并重新整体验证 |
+| Root 接受后要求修改正文 | 原 Mission 已完成且版本不可变 | 启动新 Mission 或独立业务修订运行 |
+| Root 已接受但旧输出发布/读回失败 | 框架完成不等于业务交付成功 | 不返回 success；按同一版本幂等重试发布并对账 |
+| 权限、资料或人工决定缺失 | 当前不可继续 | block 并记录解除条件 |
+| 用户停止 | 停止新增执行，不删除历史 | 保留候选、证据、验证和决定，允许续跑 |
+
+系统恢复时以当前任务状态、被接受结果和正式业务版本为依据，不通过猜测“最新子任务”或改写旧 Trace 恢复。已提交的 Attempt 从 Validation/Decision 继续；已开始但未提交的 Attempt 不续跑其模型上下文，而是按失败后重规划；升级前遗留的 RUNNING Attempt 若没有子结果绑定记录，按协议失败处理，绝不猜测输入。
+
+## 12. 一个完整、代码忠实的业务示例
+
+以下 ID 和文本为说明性示例，字段和能力形状来自老版代码；不声称是生产数据库记录。
+
+### 12.1 输入
+
+已有选题入口：
+
+```json
+{
+  "execution_id": 12,
+  "topic_build_id": 34,
+  "topic_id": 56,
+  "agent_type": "AigcAgent",
+  "agent_config": {
+    "model_name": "claude-sonnet-5",
+    "model_name_implementer": "claude-sonnet-5",
+    "model_name_script_evaluator": "claude-sonnet-5",
+    "model_name_means_pattern_relation": "gemini-3-flash-preview",
+    "model_name_means_case": "gemini-3-flash-preview",
+    "model_name_means_data": "gemini-3-flash-preview",
+    "model_name_means_knowledge": "gemini-3-flash-preview",
+    "temperature": 0.3,
+    "max_iterations": 120
+  },
+  "data_source_url": "https://library.example.invalid",
+  "strategies_always_on": [1],
+  "strategies_on_demand": [2]
+}
+```
+
+选题内容摘要：
+
+- 选题融合：“用一次反差经历说明为什么出发前要做功课”；
+- 人设账号：“账号A”；
+- 灵感点：“反差开场”；
+- 目的点：“让读者意识到错误预期的代价”；
+- 关键点：“功课不是堆资料，而是提前识别关键变量”；
+- 实质元素：“人物A”“目的地信息”；
+- 形式元素：“反转”“前后对照”；
+- always-on 策略：“先给具体经历，再抽象方法”；
+- on-demand 策略：“图片叙事规则”。
 
-以下情况应启动新 Worker：
+### 12.2 主 Agent 初判
 
-- Task 目标或验收条件变了；
-- 原路线或核心假设错误；
-- Task 被拆成新的子 Task；
-- 上下文已经过长或混入太多旧信息；
-- 需要一个不受旧方案影响的新候选；
-- 原 Worker 一次 repair 后仍未通过：原 Trace 不得再 repair；如继续执行必须使用新 Worker，主 Agent 也可选择改题、拆题或阻塞。
+主 Agent 读取选题、人设、策略和空脚本后，判断：
 
-Validator 每次评估也默认使用全新上下文，避免上一轮结论形成锚定。
+1. 选题核心明确，不需要重新生成选题；
+2. “错误预期—真实结果”的事实素材不足，需要外部案例；
+3. 账号A的开场节奏需要账号历史模式证据；
+4. 两项证据通过后才能确定方向和开场结构。
 
-## 十一、怎样实现发散，而不是堆 Agent
+它不创建固定 Round，而是先创建“方向综合任务”，再把两个取数任务建成它的直接子任务：
 
-发散来自候选空间和重新规划，不来自 Agent 多层递归。
+- 方向综合 Task：吸收被验证的研究结果，产出 `script_direction` 候选；
+  - Task A：用 Decode Case 找账号A真实脚本中“预期—反转”的开场结构；
+  - Task B：用 External Search 找可核实的出发前准备失误案例。
 
-适合创建多个并行候选的情况：
+### 12.3 专业取数与验证
 
-- 存在多个明显不同的受众心理解释；
-- 创作方向影响大，过早选择风险高；
-- 需要从不同事实、案例或叙事方法寻找突破；
-- 当前方案成立，但缺少惊喜和差异；
-- 各候选可以独立完成，互不依赖。
+Task A 的 Decode Worker 调用 `search_script_decode_case`，返回：
 
-主 Agent 不能只说“再来三版”，而要指定真实不同的探索方向，例如：
+- 命中的历史脚本片段引用；
+- 开场所在列和段落位置；
+- “先给错误判断、再用具体结果反转”的结构摘要；
+- 适合借鉴之处和不可照搬之处。
 
-- 从损失感出发；
-- 从身份认同出发；
-- 从反常识事实出发；
-- 从具体人物场景出发；
-- 从立即可执行的方法出发。
+Task B 的 External Worker 调用 `external_search_case`；如果图片对“预期与现场差异”关键，再调用 `load_images`，返回：
 
-候选返回后，每个 Validator 只绑定一个固定 Attempt Snapshot，可按统一标准分别评估。主 Agent 再读取多份报告横向选择；如果需要一个 Agent 专门做跨候选比较，应另建“候选比较”Task，而不是让单次 Validator 越界读取其他 Attempt。最终选择、组合或淘汰仍由主 Agent 决定。
+- 帖子/素材引用；
+- 可核实的事件事实；
+- 图片观察；
+- 无法确认的说法。
 
-严格依赖的任务不应为了多 Agent 而并行。例如 1.1.2 依赖 1.1.1 的结论，就应顺序执行。
+各自的 Validator 检查来源存在、结论没有超出证据、返回结构完整。主 Agent 接受两项取数结果。
 
-## 十二、创作如何收束
+### 12.4 方向与结构任务
 
-系统不能因为还可以继续优化，就无限创建 Task。
+当 Task A、Task B 被接受后，主 Agent 派发它们的直接父任务“方向综合 Task”。该 Attempt 自动冻结两项直接子 ACCEPT Decision；原始选题、人设和策略则以不可变上下文引用提供。
 
-主 Agent 可以在以下条件下提出收束：
+Creative Worker 形成方向候选：
 
-- 创作总目标的发布前验收已经通过；
-- 所有高优先级问题都已解决；
-- 剩余问题不会显著影响目标效果；
-- 新探索的预期价值低于成本；
-- 用户接受当前版本；
-- 已达到时间、成本、候选或尝试次数限制。
+> 用“我以为查了很多就是做了功课—到现场才发现关键变量没查”的具体反差开场；中段拆解三个关键变量；结尾把“资料数量”升级为“决策变量识别”。表达保持账号A的第一人称、短句和具体场景。
 
-收束前，主 Agent 或 Host 应显式创建一个覆盖完整正式成果的整体验收 Task，而不是只检查最后一个局部 Task。Framework V1 不会自动启动一个“最终 Validator”。整体验收产生 passed 报告后，主 Agent 再结合总目标决定是否收束。
+Validator 检查它是否覆盖选题关键点、是否符合账号模式、是否只采用已证实事实。通过后主 Agent 只作 ACCEPT Decision；Host 根据该决定，把同一 direction artifact 幂等提升为当前 `script_direction`，Planner 本身不调用业务写工具。
 
-## 十三、用户看到的产品体验
+随后主 Agent 创建结构任务，而不是再强制发散多路。Creative Worker 产出：
 
-本章是创作 Host 的目标产品体验，不是 Framework V1 已提供的内置页面。V1 当前只提供 Python 内核、Agent 工具、Trace/Ledger/Snapshot/Event 数据，没有新增 Task/Attempt/Validation HTTP API。
+1. 一级段落：错误预期；
+2. 一级段落：现场反差；
+3. 一级段落：三个关键变量；
+4. 一级段落：方法收束。
 
-### 13.1 总目标区
+### 12.5 局部创作与结构化写入
 
-展示受众、预期变化、发布场景、账号约束和最终验收要求。用户修改目标时，系统提示哪些已有 Task 和成果可能失效。
+主 Agent 可以把高风险开场和其余段落拆成两个任务。旧工具要求先创建段落结构和原子点，再单独更新四列文本。经过这两步后，开场候选的业务行形状可以是：
 
-### 13.2 动态任务树
+```json
+{
+  "paragraph_index": 1,
+  "level": 1,
+  "name": "错误预期",
+  "content_range": {"标题": true, "正文": "开头三段", "图片": ["1", "2"]},
+  "theme": "我以为资料收藏得够多，就等于做好了出发准备。",
+  "form": "第一人称经历 + 现场反转 + 前后图片对照",
+  "function": "制造认知冲突并引出真正需要确认的关键变量",
+  "feeling": "从自信到错愕，再到警醒",
+  "theme_elements": [
+    {"原子点": "资料数量不等于有效准备", "维度": "核心判断", "维度类型": "主维度"}
+  ],
+  "form_elements": [
+    {"原子点": "反转", "维度": "叙事结构", "维度类型": "主维度"},
+    {"原子点": "前后对照", "维度": "画面关系", "维度类型": "从维度"}
+  ],
+  "function_elements": [
+    {"原子点": "吸引注意", "维度": "段内作用", "维度类型": "主维度"},
+    {"原子点": "引出方法", "维度": "段间衔接", "维度类型": "从维度"}
+  ],
+  "feeling_elements": [
+    {"原子点": "错愕", "维度": "情感"},
+    {"原子点": "警醒", "维度": "认知"}
+  ]
+}
+```
+
+脚本元素由 `create_script_element` 建立名称与维度；如需修订名称、维度或 active 状态，再调用 `update_script_element`。按老版当前真实工具合同，候选行可以是：
 
-用户能看到：
+```json
+{
+  "name": "关键变量识别",
+  "dimension_primary": "实质",
+  "dimension_secondary": "方法",
+  "is_active": true
+}
+```
 
-- 每个 Task 为什么产生；
-- 当前由哪个 Worker 执行；
-- 正在等待 Validator 还是等待主 Agent；
-- 已经尝试了几次；
-- 当前 spec_version、旧版本是否已失效，以及 Task 是否被新 task_id supersede；
-- 为什么拆成了子 Task；
-- 父子 Task 关系和主 Agent 当前安排的先后顺序；通用 DAG 依赖可视化需 Host/V2 扩展。
+然后用段落—元素关系把它关联到“现场反差”和“三个关键变量”段落。Validator 逐项检查字段、证据、关系和修改边界。
 
-### 13.3 执行尝试历史
+### 12.6 返修分支
 
-同一 Task 的每次尝试都可查看，不能只保留最后一版。用户可以比较不同 Worker 的结果和失败原因。
+假设 Validator 发现：“现场限制”没有可重读来源，但其他内容合格。
 
-### 13.4 评估与决策区
+主 Agent 不重跑整篇，也不进入下一个固定 Round，而是：
 
-分成两个清晰部分：
+1. 对该局部任务发起 repair；
+2. 要求补充来源或删除/降级“现场限制”；
+3. Worker 提交新候选版本；
+4. Validator 重点回归修订点和影响面，同时重新报告该 Task 当前全部硬验收条件；
+5. 通过后主 Agent 接受新版本。
 
-- Validator：逐项结论、证据、无法判断项和建议；
-- 主 Agent：最终动作、重规划理由，以及是否采纳 Validator 建议。
+### 12.7 Root 整稿与最终输出
 
-### 13.5 候选与正式成果区
+在任务树中，更深层的证据已被方向/段落任务吸收，段落与元素结果又由一个 Root 直接子“整稿准备任务”统一组合。Root Worker 只消费这个已接受的直接子结果，形成一份完整正式候选。Root Validator 检查整张表后，主 Agent接受 Root；Host 随后只发布该 ACCEPT 绑定的同一版本，并以旧详情读回一致作为业务 `success` 门禁。
 
-未评估或未被主 Agent 接受的结果始终显示为候选。Host 只把已有有效 accept Decision 的内容晋升为正式成果，并保留到 Task、Attempt、Validation 和 Decision 的追溯。
+对业务消费者，输出仍是：
 
-## 十四、与旧脚本构建的产品区别
+```json
+{
+  "topic": {"id": 56, "topic_direction": "反差经历与出发准备……"},
+  "build": {
+    "status": "success",
+    "script_direction": "用具体反差说明真正的准备是识别关键变量……",
+    "build_workflow": null,
+    "summary": "完成4个一级段落及其元素关系，事实引用和账号模式已通过整体验证。",
+    "paragraph_count": 4,
+    "element_count": 6
+  },
+  "paragraphs": ["正式段落对象，内含 linked_element_ids/linked_elements……"],
+  "elements": ["正式元素对象……"],
+  "decision_traces": ["兼容决策记录……"],
+  "post_datas": {"引用帖子ID": "帖子详情……"},
+  "script_datas": {"引用脚本ID": "脚本详情……"}
+}
+```
 
-| 对比项 | 旧脚本构建 | 新智能创作系统 |
+Task、Attempt、Validation、Decision 和 Trace 可用于解释这份脚本如何产生，但不要求下游拿它们拼装正式脚本。
+
+## 13. 业务团队如何基于现有框架构建
+
+### 13.1 业务团队需要提供的五类装配
+
+| 装配项 | 业务团队责任 | 框架提供的能力 |
 |---|---|---|
-| 组织方式 | 固定 Round 和多路径分支 | 主 Agent 动态任务树 |
-| 下一步产生方式 | 沿固定环节进入下一轮 | 根据 Validator 报告和全局目标重新规划 |
-| Agent 层级 | 实施/评估 Agent 还可继续委派取数 Agent | 只有主 Agent + 一层 Worker/Validator |
-| 多候选 | 每轮的重要组织形式 | 只在值得发散时创建 |
-| 评价时机 | 分支横评和整稿评估 | 每次 Task Attempt 后独立验证 |
-| 最终裁决 | 主 Agent 做分支合并和收口 | 主 Agent 决定接受、换人、改题或拆题 |
-| 返工方式 | 常进入下一轮 | 返回真正失败的证据、判断、产物或 Task 定义 |
-| Worker 生命周期 | 角色和轮次绑定 | 默认每次 Attempt 新上下文，局部小修可有限续用 |
-| 完成条件 | 评估或轮次收口，代码中还存在弱门禁 | Validator 有证据地评估，主 Agent 显式接受 |
-
-旧系统值得保留的是：角色隔离、候选隔离、证据留痕、独立评估和主 Agent 最终决策。
-
-新系统要去掉的是：固定轮次、固定角色链、每轮必经多路径，以及只依赖 Prompt 的完成门禁。
-
-## 十五、落地范围与当前状态
-
-### 15.1 通用框架 V1 已实现
-
-- 主 Agent 唯一 Planning 和 Decision 权限；
-- Task、Attempt、Validation、Decision 独立状态和历史；
-- 一层本地 Worker 与独立 Validator Sub-Trace；
-- `submit_attempt` 和 `submit_validation` 结构化 terminal 提交；
-- passed 后仍必须由主 Agent accept，failed/inconclusive 不能 override；
-- repair、retry、revise、split、block/unblock、cancel、supersede 和异常后 revalidate；
-- 子 Task 全部完成后父 Task 只进入 needs_replan；
-- Worker 默认新 Trace，同 TaskSpec 默认最多一次 repair 续用；
-- Validator 每次新 Trace，只读 capability 和一次结构化报告；
-- 独立 Task 批量并行、逐 Task 异常隔离和有序返回；
-- 文件 TaskLedger、Snapshot manifest、JSONL Event 和 GoalTree 兼容投影；
-- `legacy_auto` 与 `explicit_validation` 隔离，框架内核无创作业务 import。
-
-这些是框架能力，不等于创作产品已上线。框架 `RunConfig` 默认仍是 `legacy_auto`；创作 Host 必须显式使用 planner preset + `explicit_validation`，并装配 Coordinator。
-
-V1 只支持本地 Sub-Trace、同步 `dispatch_tasks` 闭环和单进程文件存储，没有新增 Task/Attempt/Validation HTTP API。一次 dispatch 内可并行多个独立 Task，但主 Agent 不会在某个 Worker/Validator 仍运行时提前拿回控制权继续规划。
-
-### 15.2 创作 Host 仍需接入
-
-- 创作总目标录入、Prompt、Skill 和业务任务卡扩展；
-- 创作专用 Worker/Validator preset 与只读 DB、API、网页证据工具；
-- 产物的不可变 version/digest、候选存储、正式成果晋升和发布逻辑；
-- 根据 PlannerDecision 执行候选组合和正式成果更新；
-- 总目标、动态任务树、Attempt、Validation、Decision 和成果页面；
-- 用户介入、修改约束和受影响 Task 重规划交互；
-- 完整作品的整体验收 Task 与创作收束策略；
-- 全过程解释“为什么做、依据什么判断、下一步为什么这样规划”。
-
-### 15.3 框架 V2/V3 后续增强
-
-- 后台 start/poll/event/stop/resume，让主 Agent 在 Worker 或 Validator 运行时继续规划；
-- 远程 Worker/Validator、共享 Store、跨进程幂等和重启恢复；
-- 按任务风险选择轻量检查、完整 Validator、第二模型或人工复核；
-- 通用 Task 依赖/预算策略、成本上限和无限循环治理；
-- 根据历史数据优化任务拆分和 Worker 选择；
-- 发布后效果回流，但不自动等同于单篇作品质量。
-
-## 十六、产品成功指标
-
-### 16.1 创作质量
-
-- 最终作品人工验收通过率；
-- 占位内容、未兑现表达和逻辑断裂的漏检率；
-- Validator 对明显缺陷的漏检率；
-- 合格产物被误退回的比例；
-- 关键判断的证据覆盖率；
-- 候选之间的实质差异度。
-
-### 16.2 创作效率
-
-- 失败后局部修复成功率；
-- 因局部问题重跑整篇的比例；
-- 同一 Task 的平均尝试次数；
-- 换 Worker 后解决问题的比例；
-- 无效候选、重复检索和重复生成比例；
-- Validator 增加的成本与减少返工的收益比。
-
-### 16.3 可控与可理解
-
-- 每个 Task 是否都有清晰产生原因和验收条件；
-- 每次 Validator 结论是否有真实证据；
-- 每次主 Agent 决策是否有明确理由；
-- 无法判断和证据不足是否被正确暴露；
-- 用户介入后，受影响任务是否被正确重规划；
-- 最终成果是否能追溯到 Task、Attempt、评估和决策。
-
-## 十七、最终产品原则
-
-1. 创作总目标高于固定步骤。
-2. 所有任务规划和任务树修改只属于主 Agent。
-3. Worker 只执行，不自评、不拆任务、不创建孙 Agent。
-4. Validator 可自主规划本轮核验步骤，但只评估：不改产物、不改任务树、不派生 Agent、不完成 Task。
-5. Worker 跑完不等于结果合格，Validator 通过也不等于 Task 自动完成。
-6. 只有主 Agent 可以显式接受 Task。
-7. 同 Task 的目标或验收标准改变必须形成新 spec_version；用新 task_id 取代旧 Task 才使用 supersede。
-8. 默认一次 Attempt 一个干净上下文，局部小修才有限续用。
-9. 发散来自不同候选和动态重规划，不来自 Agent 多层递归。
-10. 子 Task 完成后，父 Task 必须回到主 Agent重新判断。
-11. 能客观验证的先用真实工具验证，主观质量再交给 Validator 判断。
-12. 未经评估和接纳的输出永远只是候选。
-13. 局部失败优先局部修正，不默认重跑整篇。
-14. 创作 Host 必须先补充预算和停止条件；Framework V1 当前只硬限制 repair 续用次数，完整成本治理在 V2。
-
-最终系统需要持续回答六个问题：
-
-> 为什么现在还不能完成？  
-> 当前最值得解决的问题是什么？  
-> 这次交付怎样才算合格？  
-> Validator 找到了什么真实证据？  
-> 主 Agent 应该接受、换人、改题还是拆题？  
-> 下一步怎样最有效地推进创作总目标？
+| 输入适配 | 把旧 Topic/Persona/Strategy/Source 装配成任务上下文 | 承载 Root 目标和可版本化任务 |
+| 工具注册 | 接入旧读取、取数、图片、结构化写入和验证工具 | 按 Planner/Worker/Validator 隔离权限 |
+| 产物协议 | 定义候选脚本和正式脚本的可重读版本 | 固定一次 Attempt 提交的产物与证据引用 |
+| 领域验证 | 把旧评估知识变成逐条验收标准 | 独立 Validation 和结构化报告 |
+| 结果投影 | 把被接受的正式版本写成旧版兼容输出 | 保存 Task/Attempt/Decision 因果和 Mission 完成状态 |
+
+### 13.2 框架已经解决的产品问题
+
+- 一次脚本交付有唯一 Root 使命；
+- Root 和普通任务在接受前的可决策状态可以修订并保留版本；已 ACCEPT 的任务不可原地改写；
+- 主 Agent 可以动态创建、拆分、返修、重试、阻塞、取消和替代任务；
+- 每次 Worker 执行都有独立尝试；只有成功提交后才形成固定候选版本；
+- 父任务只消费明确接受的直接子结果；
+- Validator 独立核验同一候选版本；
+- Validator 通过不自动完成，仍由主 Agent 决定；
+- 整个 Mission 的任务、尝试、验证、决定和运行事件可以统一观察；
+- 可以按角色、任务、尝试、验证和操作关联实际运行过程。
+
+### 13.3 业务团队仍需完成的产品能力
+
+- 老版输入适配与挂载关系校验；
+- 四类取数 Agent 和其他数据工具接入；
+- 结构化脚本候选版本与正式版本管理；
+- 旧写入工具的候选隔离与冲突规则；
+- ScriptBuildRecord、Paragraph、Element、Link 兼容输出；
+- 领域验收规则和账号/策略校验；
+- 被接受版本到正式读取结果的业务一致性；
+- 业务启动、停止、人工干预和结果查询入口。
+
+框架不会自动提供 Topic、Persona、Round、Branch、Paragraph、Element 或页面节点，也不会自动把旧 Branch 当成 Attempt。
+
+## 14. 产品控制与观测
+
+业务团队使用系统时，至少应能回答以下问题：
+
+| 问题 | 所需视图 |
+|---|---|
+| 这次在为哪个选题生成什么正式脚本？ | Mission 概况 + 旧输入摘要 |
+| 当前为什么还没完成？ | 当前焦点任务 + 阻塞/失败原因 |
+| 主 Agent 为什么创建这个任务？ | 任务原因、与 Root 的关系、验收条件 |
+| 使用了哪些选题、人设和策略？ | 输入引用与版本 |
+| 调用了哪些取数能力？ | Retrieval 任务/工具和证据结果 |
+| 某段脚本由什么支撑？ | Paragraph/Element → Decision → Evidence 追溯 |
+| 为什么接受或拒绝某候选？ | Validation + Planner Decision |
+| 当前正式结果是哪一版？ | 正式脚本版本、摘要、计数和整体验证 |
+| 停止或恢复后会从哪里继续？ | 当前任务状态、已接受结果和待执行项 |
+
+事件只用于提示“某个任务、尝试、验证或决定发生了变化”，完整事实仍从统一 Mission 状态和业务脚本版本读取。
+
+## 15. 分阶段产品落地
+
+### 阶段 0：冻结兼容合同
+
+- 用真实老版字段形成输入、输出和工具清单；
+- 明确 `branch_id=0` 正式读取语义；
+- 校正 base 计数、最终验收、候选冲突等旧缺陷；
+- 建立同一输入在新旧系统间的对照样本。
+
+### 阶段 1：接入只读数据与取数 Agent
+
+- 接入 Topic、Persona、Strategy、脚本快照；
+- 接入四类专业取数能力和图片理解；
+- 用独立取数任务验证“查询—证据—接受—后续消费”链路；
+- 不改变正式脚本输出。
+
+### 阶段 2：接入结构化创作 Worker
+
+- 创作 Worker 使用旧段落、四列、元素和关系写入能力；
+- Host 自动从框架 Task 生成旧写工具所需的最小 `record_task_plan` 兼容清单，或先移除该旧门禁；不得让人工维护第二套计划；
+- 每次任务写候选版本，不直接污染正式结果；
+- Validator 可重读并核验同一候选；
+- 局部 repair/retry/revise 可保留旧版本。
+
+### 阶段 3：Root 整稿与兼容输出
+
+- Root Worker 组合已接受结果；
+- Root Validator 覆盖完整正式候选；
+- 被验证的同一 staging 版本已通过旧读取规则预检，Root 接受后 Host 才幂等激活为 `branch_id=0` 的 ScriptBuildRecord + Paragraph + Element + Link，并用旧详情读回对账；
+- 下游不改接口即可读取新系统产物。
+
+### 阶段 4：切换动态编排
+
+- 取消固定 Round 和每轮强制 multipath；
+- 按缺口动态创建任务；
+- 只在有价值时发散候选；
+- 停止、恢复、阻塞和人工修订均以任务状态为依据。
+
+## 16. 系统验收标准
+
+### 16.1 输入兼容
+
+- 已有 `execution_id/topic_build_id/topic_id` 入口可启动；
+- 上传选题 JSON 可适配成同一种标准输入；
+- 完整选题点、组成元素、关系和来源不丢失；
+- 账号名、创作人设点和段落模式可读取；
+- always-on/on-demand 策略语义不变；
+- 资料源和模型角色配置可沿用。
+
+### 16.2 能力覆盖
+
+- 四类功能性取数 Agent 均有真实用例；
+- 简单只读查询和复杂专业取数两种模式均可用；
+- 图片需要时可被模型实际查看；
+- 结构化段落、四列原子点、元素和关系均可创建、更新和删除；
+- Validator 能使用相同只读事实独立核验；
+- 旧评估维度已转成可检查的任务/整稿条件。
+
+### 16.3 输出兼容
+
+- 最终只暴露一个被接受的正式脚本版本；
+- ScriptBuildRecord 的方向、摘要、状态和计数与正式版本一致；
+- Paragraph、Element、ParagraphElement 字段和读取语义兼容；
+- `build_workflow`、topic、decision_traces、post_datas、script_datas 及 Paragraph 内嵌关系按第 3.6 节兼容；
+- 候选任务、失败尝试和未接受结果不混入正式脚本；
+- 旧下游无需理解 Agent 框架对象即可读取。
+
+### 16.4 Agentic 行为
+
+- 没有固定 Round 门禁；
+- 没有每轮必须多路的门禁；
+- 每个任务都能说明当前缺口和验收条件；
+- 失败后能区分 repair、retry、revise、split、block 和 supersede；
+- 同一 TaskSpec 最多一次 repair，达到全局尝试/时长/无改善护栏时能确定性收口；
+- 父任务使用的是明确被接受、固定版本的子结果；
+- Root 必须通过同一完整脚本版本的独立验证；
+- 主 Agent 的接受决定可追溯到真实 Attempt、Validation、Artifact 和证据。
+
+### 16.5 必测黑盒场景
+
+1. 使用同一老版选题、人设和策略输入启动 Mission；
+2. Decode 取数 v1 证据不足，Validator 不通过；
+3. 主 Agent 修订取数任务，v2 通过并接受；
+4. 创作方向在接受前因新证据发生修订；若已接受，则建立新的纠偏/综合任务；
+5. 局部 Worker 使用固定的已接受取数结果写候选；
+6. Validator 发现一个无来源元素，只返修该局部；
+7. Root 更深层结果先由直接父任务吸收，Root Worker 只按冻结的直接子 ACCEPT 结果写出完整脚本；
+8. Root Validator 核验同一版本，主 Agent 接受；
+9. Host 对同一版本幂等发布；模拟首次发布失败时不得返回 success，恢复后读回一致；
+10. 消费方只通过业务入口读取旧格式正式输出及兼容辅助字段；
+11. 能从正式 Paragraph/Element 追溯到采用决定、执行、验证和证据；
+12. 新的 Mission 观测响应与正式脚本对象不新增 Round、Branch、Workflow 或页面节点；旧详情的 `build_workflow` 兼容字段仍按第 3.6 节保留。
+
+## 17. 明确不做
+
+本方案不做：
+
+- 商业化、定价、品牌和市场策略；
+- 重新设计选题系统或上游人设生产流程；
+- 把脚本阶段错误改成输出选题表；
+- 为业务团队强制新的固定 Workflow；
+- 让 Worker 任意递归创建 Agent 或修改全局任务树；
+- 让 Validator 直接改稿或自动决定完成；
+- 把 Task、Attempt、Validation、Event 或 Trace 塞入正式脚本表；
+- 默认每次生成多个候选；
+- 把旧 Round、Branch 直接改名为 Task、Attempt；
+- 用模型自述替代真实数据、产物和证据核验；
+- 在本产品文档中规定底层服务、数据库迁移、SDK 调用和部署拓扑。
+
+## 18. 最终原则
+
+1. 老版输入进，新版仍产出老版脚本表。
+2. 旧能力可复用，旧固定编排不照搬。
+3. 下一步由主 Agent 根据缺口和验证结果决定。
+4. 复杂取数是可独立验收的专业任务，简单查询是只读工具。
+5. Worker 产候选，Validator 验同一版本，主 Agent 作决定。
+6. 候选必须隔离，正式结果必须唯一。
+7. 先证据后创作；事实正确与表达质量分开验证。
+8. 局部问题局部修，根本问题才修订方向或 Root。
+9. Root 负责整稿交付，不能以最后一个局部任务代替整体验收。
+10. 业务团队看到的是可直接使用的结构化脚本，框架对象负责让过程可控、可验证、可恢复。
+
+---
+
+## 附录 A：57 个脚本工具 Schema 资产清单
+
+> 说明：这是 `script_build_tool_schemas.json` 的资产库存，不代表每个角色实际拥有全部权限；`load_images` 是额外运行时工具。
+
+### A.1 规划、轮次、候选与决策
+
+- `think_and_plan`
+- `begin_round`
+- `record_multipath_plan`
+- `record_multipath_decision`
+- `list_branches`
+- `get_branch_snapshot`
+- `get_branch_data_decisions`
+- `merge_branch`
+- `park_branch`
+- `discard_branch`
+- `record_task_plan`
+- `update_task_plan_step`
+- `get_task_plan`
+- `record_data_decision`
+
+其中 Round、multipath、merge/park/discard 属于老版 Workflow/候选存储能力，不作为新系统的固定业务步骤。
+
+### A.2 核心输入与当前脚本
+
+- `get_topic_detail`
+- `get_account_script_persona_points`
+- `get_account_script_section_patterns`
+- `get_script_snapshot`
+- `get_script_stats`
+- `get_script_direction`
+- `save_script_direction`
+- `get_domain_info`
+- `save_domain_info`
+- `load_strategy`
+
+### A.3 结构化脚本写入
+
+- `create_script_paragraph`
+- `append_paragraph_atoms`
+- `delete_paragraph_atom`
+- `create_script_element`
+- `update_script_element`
+- `batch_link_paragraph_elements`
+- `delete_paragraph_element_links`
+- `batch_update_script_paragraphs`
+
+### A.4 四类核心取数
+
+- `query_pattern_qa`
+- `search_script_decode_case`
+- `external_search_case`
+- `search_knowledge`
+
+### A.5 Pattern、Relation、Paragraph Pattern 与 Sequence
+
+- `get_topic_script_pattern_meta`
+- `find_topic_script_patterns_by_names`
+- `find_topic_script_relation_by_names`
+- `get_topic_script_pattern_posts`
+- `get_paragraph_pattern_meta`
+- `find_paragraph_patterns_by_names`
+- `get_paragraph_pattern_posts`
+- `get_script_sequence_meta`
+- `get_script_sequence_list`
+- `get_script_sequence_detail`
+- `search_script_sequence_by_category`
+- `get_category_detail`
+
+### A.6 参考帖子与历史脚本
+
+- `get_reference_scripts`
+- `get_topic_related_posts`
+- `get_post_details`
+- `get_post_script_decode`
+- `search_post_scripts`
+- `search_post_scripts_by_topic_name`
+
+### A.7 状态、总结与遗留评估入口
+
+- `update_script_status`
+- `write_execution_summary`
+- `evaluate_script_build`
+
+`evaluate_script_build` 存在于 schema 资产，但不在当前主角色白名单主路径中；新系统的正式质量判断由独立 Validator 承担。
+
+## 附录 B：老版实际角色白名单
+
+### B.1 主 Agent
+
+静态业务工具集中在：选题/人设/脚本/方向/领域读取，Round 与 multipath 编排，候选读取与 merge/park/discard，base 清理，决策、方向、状态和总结。真实运行时还会加入通用 `agent` 委派能力、并发多路 `implement_paths`；存在 on-demand 策略时加入 `load_strategy`。
+
+### B.2 Implementer
+
+静态业务工具集中在：任务计划，选题/账号/脚本/方向/领域读取，领域事实追加，段落/原子点/元素/关系写入，数据决策和图片理解。老运行时还允许 Implementer 通过通用 `agent` 委派四类 `retrieve_data_*`；on-demand 策略由主 Agent 加载后随任务上下文提供，Implementer 白名单不直接加入 `load_strategy`。
+
+### B.3 Retrieval Agents
+
+- Pattern：`think_and_plan`、`get_script_snapshot`、`query_pattern_qa`；
+- Decode：`think_and_plan`、`get_script_snapshot`、`search_script_decode_case`；
+- External：`think_and_plan`、`get_script_snapshot`、`external_search_case`、`load_images`；
+- Knowledge：`think_and_plan`、`search_knowledge`。
+
+### B.4 Evaluators
+
+- 候选评估：读取候选分支、取数决策、base、选题、人设、方向和领域信息；
+- 整稿评估：读取正式脚本、统计、选题、人设、方向和领域信息；
+- 老运行时允许两者通过通用 `agent` 委派四类 `retrieve_data_*` 做补充核验；
+- 两者都不拥有正式写稿和最终接纳权。
+
+新系统保留这四类检索能力，但不照搬“Implementer/Evaluator 自行递归派生业务 Agent”的控制结构：复杂检索由主 Agent 建立一层专业任务，简单查询以只读工具提供。
+
+角色白名单证据：`script_build_tool_runtime.py:24-140`。
+
+## 附录 C：事实证据入口
+
+老版代码根目录：
+
+`/home/sam/image_article_comprehension/aiddit/pattern/patter_from_global_and_build`
+
+建议核对顺序：
+
+1. `prompts/script/script_build_system_v2.md`：输入目标、正式输出和角色责任；
+2. `models.py`：选题、ScriptBuildRecord、Paragraph、Element、ParagraphElement；
+3. `pattern_server.py`：标准入口、上传入口和详情输出；
+4. `script_build_agent_common.py`：输入装配、策略和上传 JSON 解析；
+5. `script_build_tool_runtime.py`：各角色真实工具白名单；
+6. `script_build_tool_schemas.json`：57 个工具接口合同；
+7. `script_build_agent_tools.py`：账号数据、结构化写稿、领域事实和候选操作；
+8. `prompts/script/script_implementer.md`：先取证后创作与写入纪律；
+9. `prompts/script/script_build_eval_agent.md`：候选/整稿评估维度；
+10. `script_embedding_search/index/manifest.json`：真实 Decode 数据资产规模。
+
+本项目 Agent 框架事实入口：
+
+1. `agent/agent/orchestration/models.py`：Mission、Task、Attempt、Validation、Decision；
+2. `agent/agent/orchestration/coordinator.py`：动态决策、验证与 Root 收口；
+3. `agent/agent/orchestration/policy.py`：角色能力边界；
+4. `agent/agent/orchestration/wire.py`：统一 Mission 读取视图；
+5. `agent/tests/test_framework_observation_e2e.py`：Root 修订、子结果固定绑定与全链闭合的黑盒事实。