文档：同步智能创作产品方案与框架 V1 边界

明确 Validator 是完整单 Agent 运行时但不是业务 Planner，并补充 Worker 未提交、repair/revalidate、父子任务与候选成果的准确产品语义。

区分框架 V1 已实现能力、创作 Host 待接入内容和 V2/V3 后续能力，避免把正式成果晋升、最终验收、业务工具与产品页面误写成框架现成功能。

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

@@ -1,8 +1,9 @@
 # 智能创作构建系统产品方案
 
-> 文档定位：纯产品方案  
-> 产品形态：主 Agent 集中规划、动态任务树、一层 Worker 执行、独立 Validator 评估  
-> 最新需求基线：2026-07-17  
+> 文档定位：纯产品方案
+> 产品形态：主 Agent 集中规划、动态任务树、一层 Worker 执行、独立 Validator 评估
+> 最新需求基线：2026-07-18
+> 实施状态：通用 Agent 框架 V1 已实现；本文中的创作 Host、业务工具、正式成果和产品页面尚待业务项目接入
 > 核心变化：从固定创作 Workflow，升级为“主 Agent 规划—Worker 执行—Validator 评估—主 Agent 重新规划”的智能创作系统
 
 ## 一、结论先行
@@ -56,7 +57,7 @@ Validator 独立检查真实结果
 新系统不是不要秩序，而是把秩序分成两层：
 
 - 创作层：主 Agent 根据实际缺口动态规划；
-- 运行层：每次执行都必须经过提交、独立评估和主 Agent 决策。
+- 运行层：Worker 成功提交后必须经过独立评估和主 Agent 决策；未提交或运行异常则直接回到主 Agent 重规划。
 
 ## 三、产品目标与边界
 
@@ -119,11 +120,11 @@ Validator 独立检查真实结果
 - 理解并守住创作总目标；
 - 读取当前成果、任务树和历史评估；
 - 发现当前最大的创作缺口；
-- 创建、修订、拆分、排序、暂停或取消 Task；
+- 创建、修订、拆分、排序、阻塞/解除阻塞或取消 Task；
 - 决定使用一个 Worker 还是多个独立 Worker 发散；
 - 读取 Validator 的证据和结论；
 - 决定接受、返修、换 Worker、改 Task、拆 Task 或停止；
-- 决定哪些候选进入正式创作成果；
+- 作出哪些候选可被接纳的决策；由 Host 根据 Decision 把候选组合或晋升为正式成果；
 - 判断整项创作何时可以收束。
 
 主 Agent 可以参考 Validator 的建议，但不能把最终判断外包给 Validator。
@@ -150,25 +151,32 @@ Worker 可以报告新发现和风险，但不能：
 
 ### 4.4 Validator（独立评估 Agent）
 
-Validator 在技术能力上可以与主 Agent 同级：能够推理、调用工具、读取文件、查询数据库和接口、检查网页、查看产物和 Trace。
+Validator 与主 Agent 共用完整 AgentRunner，是一个完整的单 Agent 运行时。它可以在一次 Validation 内自主规划“如何核验”，进行多轮推理，并多次调用已授权的只读工具。
+
+但它不是业务 Planner。“可以规划本轮核验步骤”不等于“可以规划任务树”。
 
 但它的职责只有评估：
 
 - 按执行前约定的验收条件逐项检查；
 - 直接查看真实产物，而不是相信 Worker 的总结；
-- 必要时独立查询 DB、API、文件、网页和证据来源；
+- 必要时独立查询已授权的 DB、API、文件、网页和证据来源；
 - 说明哪些通过、哪些不通过、哪些无法判断；
 - 指出问题发生在证据、判断、产物还是任务定义；
 - 给主 Agent 提供可选的处理建议。
 
+Validator 默认并不开箱提供 DB、API 或网页工具。Host 必须把业务查询工具标注为 `read` capability，并加入自定义 validator preset 白名单；未分类工具在 explicit 模式下默认拒绝。
+
 Validator 不能：
 
-- 规划下一步；
+- 规划业务下一步或修改任务树；
 - 新建、拆分或关闭 Task；
+- 派发 Worker 或 Validator；
 - 修改被评产物；
 - 派生新的 Agent；
 - 直接把 Task 标记为完成。
 
+每次 Validation 都创建新 Trace。Validator 在一轮内必须且只能成功调用一次 `submit_validation`，提交后当前 Agent Loop 立即结束。它不能自己发起第二轮验证；重新验证只能由主 Agent 在上一轮 error/stopped/expired 后发起。
+
 它的产品原则是：**能力同级、职责独立、写权限受限。**
 
 ## 五、核心产品对象
@@ -196,7 +204,7 @@ Validator 不能：
 - 一个问题过大时拆成子 Task；
 - 一个方向存在多种高价值可能时创建多个候选 Task；
 - 新证据推翻原判断时修订或替代受影响 Task；
-- 已失去价值的 Task 可以暂停或取消；
+- 因用户、权限或外部条件暂时无法继续的 Task 可以阻塞等待；已失去价值的 Task 可以直接取消；
 - 总目标验收通过后，整棵树才收束。
 
 树的层级表示业务问题关系，不表示 Agent 递归关系。所有任务都由主 Agent 规划，再交给一层 Worker。
@@ -218,6 +226,8 @@ Validator 不能：
 | 依赖关系 | 哪些任务完成后才能开始 |
 | 成本边界 | 最多尝试、候选或投入多少 |
 
+这是创作产品的理想任务卡，不是 Framework V1 已内建的全部字段。当前通用 TaskSpec 只固定 objective、acceptance criteria 和 context refs；产生原因、业务依赖图、候选数和成本边界需由创作 Host 扩展，或在 V2 纳入通用策略。V1 内核直接支持的结构关系是父子 Task，不是通用 DAG 依赖引擎。
+
 如果主 Agent 改变了 Task 的目标或验收标准，就形成一个新的任务版本。旧版本及其执行历史仍然保留，不能为了让结果看起来通过而悄悄改标准。
 
 ### 5.4 一次执行尝试
@@ -228,7 +238,7 @@ Validator 不能：
 - 未通过后，可以换 Worker B 重做同一 Task；
 - 也可以在条件合适时让 Worker A 做一次局部修补。
 
-每次尝试的产物、证据和过程都独立保留。一次尝试结束只代表 Worker 已提交结果，不代表 Task 已通过。
+每次 Attempt 的记录和 Snapshot 都独立保留；repair 可以续用同一 Worker Trace，但仍会生成新 Attempt 和 Snapshot。Worker 正式调用 `submit_attempt` 只代表提交候选结果，不代表 Task 已通过；未提交、失败、停止或过期的 Attempt 会直接回到需重规划。
 
 ### 5.5 评估报告
 
@@ -252,15 +262,18 @@ Validator 不能：
 - 保持 Task 不变，换新 Worker 重新执行；
 - 修订 Task 的目标、上下文或验收标准；
 - 把 Task 拆成多个更小的子 Task；
-- 先创建补证据 Task；
+- 用 `task_plan` 创建补证据 Task，或使用 split/revise/block 组合表达；
 - 暂时阻塞，等待用户或外部条件；
+- 解除阻塞后回到重规划；
 - 取消或用新 Task 替代旧 Task。
 
+V1 没有独立 `request_evidence` DecisionAction。`task_decide` 的原子动作是 accept、repair、retry、revise、split、block、unblock、cancel 和 supersede；Validator 运行异常后的 revalidate 通过独立 `validate_attempt` 工具发起。
+
 ### 5.7 候选产物与正式成果
 
 Worker 交付的观点、结构、段落、标题和脚本首先都是候选。
 
-只有经过 Validator 评估，并由主 Agent 明确接纳后，候选才能进入正式创作成果。候选可以被：
+只有经过 Validator 评估，并由主 Agent 明确接纳后，候选才具备进入正式创作成果的资格。Framework V1 的 accept 只把 Task 标记为 completed，不会自动把 Artifact 写入业务“正式成果”；候选晋升、组合和发布由 Host 根据 PlannerDecision 执行。候选可以被：
 
 - 接纳；
 - 与其他候选组合；
@@ -292,6 +305,7 @@ Validator 提交评估报告
 
 触发主 Agent 重新规划的事件包括：
 
+- Worker 未正式提交、运行失败、停止或过期；
 - Validator 完成评估；
 - Validator 无法判断或执行异常；
 - 新证据推翻已有判断；
@@ -315,7 +329,7 @@ Validator 提交评估报告
 | 需重规划 | 不能直接接受，需要换人、改题或补证据 |
 | 等待子任务 | 原 Task 已拆分，等待下级问题解决 |
 | 已完成 | 主 Agent 已明确接受结果 |
-| 已替代 | 新任务版本或新任务已经取代它 |
+| 已替代 | 主 Agent 用新 task_id 取代了旧 Task；同 task_id 的 revise 只会增加 spec_version 并回到待执行 |
 | 已阻塞 | 需要用户或外部条件才能继续 |
 | 已取消 | 主 Agent 或用户决定不再继续 |
 
@@ -364,6 +378,8 @@ Validator 不只给一个笼统总分，而应逐项说明依据。
 
 “无法判断”不等于 Task 失败。主 Agent 可以补证据、修订 Task，或者请求用户介入。
 
+如果 Validator 本身运行异常、被停止或过期，这不是 failed/inconclusive 结论。主 Agent 可通过 `validate_attempt` 对未变 Snapshot 启动新 Validator Trace；已有效返回 failed/inconclusive 时则必须重新规划，不能用重验证刷结论。
+
 ## 九、Task 1.1 未通过以后怎么办
 
 假设 Task 1.1 是“为结尾写出一句让读者立即行动的金句”。
@@ -380,7 +396,7 @@ Validator 读取真实结尾后判断：没有交付实际金句，核心验收
 
 ### 9.2 只是明确的局部小修
 
-如果 Worker A 已经完成其他部分，只遗漏一句具体表达，主 Agent 可以让它沿用原上下文补一次，再交给新的 Validator 重新评估。
+如果 Worker A 已经完成其他部分，只遗漏一句具体表达，主 Agent 可以让它沿用原 Worker Trace 补一次，但仍创建新 Attempt 和 Snapshot，再交给新的 Validator Trace 评估。
 
 ### 9.3 Task 定义有问题
 
@@ -413,7 +429,7 @@ Task 1.1.2：根据已确认约束写出实际金句
 
 产品默认策略是：**一次执行尝试使用一个干净 Worker 上下文。**
 
-Worker 提交后，系统释放本次运行上下文，但保留：
+Worker 提交后，本次 Agent Loop 结束。Trace 和消息会持久保留，但系统默认不在下一次 Attempt 续用这份上下文。系统保留：
 
 - Task 和任务版本；
 - 执行过程；
@@ -421,7 +437,7 @@ Worker 提交后，系统释放本次运行上下文，但保留：
 - Validator 报告；
 - 主 Agent 决策。
 
-大白话就是：**销毁的是本次对话现场，不销毁工作记录。**
+大白话就是：**不删除本次对话记录，只是下一次默认换一份干净上下文。**
 
 只有同时满足以下条件，才适合继续使用原 Worker：
 
@@ -429,7 +445,7 @@ Worker 提交后，系统释放本次运行上下文，但保留：
 - 目标和验收标准没有变化；
 - Validator 指出的是局部、明确的小修；
 - 原方案总体成立；
-- 连续修补不超过一到两次。
+- 当前 TaskSpec 尚未使用过 repair 续用；V1 默认每个版本最多一次。
 
 以下情况应启动新 Worker：
 
@@ -438,7 +454,7 @@ Worker 提交后，系统释放本次运行上下文，但保留：
 - Task 被拆成新的子 Task；
 - 上下文已经过长或混入太多旧信息；
 - 需要一个不受旧方案影响的新候选；
-- 原 Worker 连续小修仍未通过。
+- 原 Worker 一次 repair 后仍未通过：原 Trace 不得再 repair；如继续执行必须使用新 Worker，主 Agent 也可选择改题、拆题或阻塞。
 
 Validator 每次评估也默认使用全新上下文，避免上一轮结论形成锚定。
 
@@ -462,7 +478,7 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 - 从具体人物场景出发；
 - 从立即可执行的方法出发。
 
-候选返回后，Validator 可以按统一标准分别评估；需要横向选择时，也可以进行候选比较。最终选择、组合或淘汰仍由主 Agent 决定。
+候选返回后，每个 Validator 只绑定一个固定 Attempt Snapshot，可按统一标准分别评估。主 Agent 再读取多份报告横向选择；如果需要一个 Agent 专门做跨候选比较，应另建“候选比较”Task，而不是让单次 Validator 越界读取其他 Attempt。最终选择、组合或淘汰仍由主 Agent 决定。
 
 严格依赖的任务不应为了多 Agent 而并行。例如 1.1.2 依赖 1.1.1 的结论，就应顺序执行。
 
@@ -479,10 +495,12 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 - 用户接受当前版本；
 - 已达到时间、成本、候选或尝试次数限制。
 
-收束前，最终 Validator 需要检查完整正式成果，而不是只检查最后一个局部 Task。主 Agent 再结合总目标决定是否完成整项创作。
+收束前，主 Agent 或 Host 应显式创建一个覆盖完整正式成果的整体验收 Task，而不是只检查最后一个局部 Task。Framework V1 不会自动启动一个“最终 Validator”。整体验收产生 passed 报告后，主 Agent 再结合总目标决定是否收束。
 
 ## 十三、用户看到的产品体验
 
+本章是创作 Host 的目标产品体验，不是 Framework V1 已提供的内置页面。V1 当前只提供 Python 内核、Agent 工具、Trace/Ledger/Snapshot/Event 数据，没有新增 Task/Attempt/Validation HTTP API。
+
 ### 13.1 总目标区
 
 展示受众、预期变化、发布场景、账号约束和最终验收要求。用户修改目标时，系统提示哪些已有 Task 和成果可能失效。
@@ -495,9 +513,9 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 - 当前由哪个 Worker 执行；
 - 正在等待 Validator 还是等待主 Agent；
 - 已经尝试了几次；
-- 是否被新任务版本替代；
+- 当前 spec_version、旧版本是否已失效，以及 Task 是否被新 task_id supersede；
 - 为什么拆成了子 Task；
-- 哪些 Task 有依赖，哪些可以并行。
+- 父子 Task 关系和主 Agent 当前安排的先后顺序；通用 DAG 依赖可视化需 Host/V2 扩展。
 
 ### 13.3 执行尝试历史
 
@@ -512,7 +530,7 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 
 ### 13.5 候选与正式成果区
 
-未评估或未被主 Agent 接受的结果始终显示为候选。正式成果只展示已经被接纳的内容，并能追溯到相关 Task、Attempt、评估和决策。
+未评估或未被主 Agent 接受的结果始终显示为候选。Host 只把已有有效 accept Decision 的内容晋升为正式成果，并保留到 Task、Attempt、Validation 和 Decision 的追溯。
 
 ## 十四、与旧脚本构建的产品区别
 
@@ -532,30 +550,44 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 
 新系统要去掉的是：固定轮次、固定角色链、每轮必经多路径，以及只依赖 Prompt 的完成门禁。
 
-## 十五、第一阶段产品范围
-
-### 15.1 必须实现
-
-- 创作总目标录入和确认；
-- 主 Agent 维护动态任务树；
-- Task 在执行前冻结交付和验收条件；
-- 一层 Worker 完成 Task Attempt；
-- 独立 Validator 能调用工具查验真实产物、文件、DB 和接口；
-- 逐项、带证据的评估报告；
-- 主 Agent 显式做接受、返修、换人、改题、拆题、补证据、阻塞或取消决策；
-- 同一 Task 的多次 Attempt 历史；
-- Task 修订保留旧版本；
-- 子 Task 完成后父 Task 不自动完成；
-- 候选产物只有被主 Agent 接受后才进入正式成果；
-- Worker 默认新上下文，支持有限续用；
-- 用户可以暂停、介入和修改约束；
+## 十五、落地范围与当前状态
+
+### 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.2 后续增强
+### 15.3 框架 V2/V3 后续增强
 
-- 主 Agent 在 Worker 或 Validator 运行时并行规划其他独立 Task；
-- 按任务风险选择轻量检查、完整 Validator 或人工复核；
-- 高价值任务使用不同模型进行第二次验证；
+- 后台 start/poll/event/stop/resume，让主 Agent 在 Worker 或 Validator 运行时继续规划；
+- 远程 Worker/Validator、共享 Store、跨进程幂等和重启恢复；
+- 按任务风险选择轻量检查、完整 Validator、第二模型或人工复核；
+- 通用 Task 依赖/预算策略、成本上限和无限循环治理；
 - 根据历史数据优化任务拆分和 Worker 选择；
 - 发布后效果回流，但不自动等同于单篇作品质量。
 
@@ -593,17 +625,17 @@ Validator 每次评估也默认使用全新上下文，避免上一轮结论形
 1. 创作总目标高于固定步骤。
 2. 所有任务规划和任务树修改只属于主 Agent。
 3. Worker 只执行，不自评、不拆任务、不创建孙 Agent。
-4. Validator 只评估，不改产物、不改任务树、不完成 Task。
+4. Validator 可自主规划本轮核验步骤，但只评估：不改产物、不改任务树、不派生 Agent、不完成 Task。
 5. Worker 跑完不等于结果合格，Validator 通过也不等于 Task 自动完成。
 6. 只有主 Agent 可以显式接受 Task。
-7. Task 变化必须形成新版本，不能悄悄改变验收标准。
+7. 同 Task 的目标或验收标准改变必须形成新 spec_version；用新 task_id 取代旧 Task 才使用 supersede。
 8. 默认一次 Attempt 一个干净上下文，局部小修才有限续用。
 9. 发散来自不同候选和动态重规划，不来自 Agent 多层递归。
 10. 子 Task 完成后，父 Task 必须回到主 Agent重新判断。
 11. 能客观验证的先用真实工具验证，主观质量再交给 Validator 判断。
 12. 未经评估和接纳的输出永远只是候选。
 13. 局部失败优先局部修正，不默认重跑整篇。
-14. 系统必须有预算和停止条件，不能把无限循环当作智能。
+14. 创作 Host 必须先补充预算和停止条件；Framework V1 当前只硬限制 repair 续用次数，完整成本治理在 V2。
 
 最终系统需要持续回答六个问题：