# 脚本构建第三版：递归 Agent 架构演进策略

> 文档状态：架构建议稿 0.2（已经两路独立校验并修订）  
> 日期：2026-07-16  
> 适用范围：脚本创作系统的宏观 Agent 架构、递归业务协议、运行时边界与演进路线  
> 暂不讨论：当前 Agent SDK 已完成到什么程度、具体框架迁移工作量、数据库表和 API 的最终实现

## 1. 结论摘要

第三版不应把旧的固定 Workflow 改名为“多 Agent 系统”，也不应预先固定为：

```text
目标 Agent → 脉络 Agent → 元素 Agent → 装配 Agent → 评估 Agent
```

建议建设一个“递归创作内核”：

- 固定的是递归协议、父子责任、验收合同、预算、安全边界和可恢复机制；
- 动态的是局部目标、任务树、执行顺序、Agent 数量、所需 traits、工具组合和修正方向；
- `目标`、`脉络`、`元素`、`文稿`不再是必须依次经过的工序，而是运行中可创建、引用、修订、分叉和合并的 Artifact；
- 每个业务节点都可在任意深度运行同一套闭环，并在完成一次动作后选择：横向补充、继续下钻或者返回父层；
- 子节点完成不等于父节点完成。父节点必须重新进入判断，决定是否创建下一个同层节点、继续细化、修改方向或向上交付；
- 多 Agent 只用于高价值、可并行、高不确定的探索，不用于所有节点。强顺序、强共享上下文的叙事推演应尽量保持单 Agent 连续执行；
- Agent SDK 适合作为模型、工具、会话、追踪和子 Agent 调用的执行层，但不应拥有业务递归树的最终语义。

一句话概括：

> 第三版要建设的是“固定协议、动态计划”的递归创作系统，而不是一条更复杂的智能流水线。

### 阅读路径

- 业务和产品决策：先读 1、2、9、16、19 节；
- 架构和实现：重点读 5–8、12–15 节；
- 评价和试验：重点读 10、11、16–18 节。

文档中最容易混淆的几个词：

| 词 | 大白话含义 |
|---|---|
| `RootIntent` | 用户最终想要什么，以及不能被下游擅改的边界 |
| `GoalSpec` | 某个局部责任要达成的结果，是不可变的版本化对象 |
| `WorkNode` | 对一个 GoalSpec 负责到底的业务节点，不等于一次模型调用 |
| `NodeAttempt` | WorkNode 的一轮“判断—执行—验证”，返工会产生新 Attempt |
| `Artifact` | 目标、脉络、证据、元素、草稿等可持久化业务产物 |
| `Trait` | Agent “倾向怎么做”的软性行为策略，不是权限或固定角色 |

本文的字段和枚举是架构级协议草案，用于固定边界和语义；进入开发前还应单独产出可执行的 Schema、事件定义和 ADR。

---

## 2. 为什么旧系统需要从 Workflow 演进为递归 Agent System

旧系统围绕“创作表”逐步落数据，主要执行顺序是：

```text
制定目标
→ 产生脉络
→ 产生元素
→ 将元素填入脉络
→ 整体评估
→ 修补
```

它已经具备不少智能能力：

- 能读取选题和账号约束；
- 能从 Case、Data、Knowledge 中检索材料；
- 能建立段落、元素和段落—元素关联；
- 能整体评估并补字段、补内容或补层级；
- 新版本还能进行多分支实现、比较和合并。

但它仍然是 Workflow，根本原因不是 Agent 数量不够，而是业务责任仍集中在主编排器：

- 主编排器拥有全局目标、下一步决策、写入权和收口权；
- 其他 Agent 主要返回候选或评价，没有自己负责到底的局部业务目标；
- 任务不能在任意深度使用同一种父子协议继续递归；
- 子节点完成后，父节点缺少强制重入、重新验收和重新规划的业务语义；
- `build_workflow` 混合了“作品最终怎么展开”和“系统如何把作品造出来”两类不同概念。

第三版需要把“创作表”从控制平面降级为 Artifact 的一种投影视图：系统如何思考，不再由表格字段的填写顺序决定；表格只负责呈现已经形成的创作结果。

---

## 3. 架构目标与非目标

### 3.1 架构目标

1. 任意深度的业务节点都使用同一种 `WorkNode` 合同。
2. 节点能够在运行时自主发现缺口、创建子目标和调整局部计划。
3. 父节点拥有直接子节点的创建、验收、合并和关闭责任。
4. 目标、脉络、元素能够相互影响，而不是只能单向流动。
5. 创作候选和中间版本完整保留，支持比较、组合、回选和回滚。
6. 运行时能够根据任务特征选择单 Agent、并行候选、生成—评价循环或人工介入。
7. 每棵递归树都有深度、宽度、Token、时间、工具、修订次数等整体预算。
8. 长任务能够 checkpoint、暂停、恢复、重放和定位失败节点。
9. 每个结果都能追溯到目标、节点、Agent、工具、来源和评价记录。
10. 架构可以适应模型能力变化，而不需要每次模型升级都重写固定 Workflow。

### 3.2 非目标

- 不让 Agent 自由改变用户的最终意图；
- 不追求每个步骤都由多个 Agent 参与；
- 不追求一个完全无约束、可以无限生成子 Agent 的 Swarm；
- 不允许生产运行中的 Agent 自己修改、批准并发布自己的系统 Prompt 或调度策略；
- 不把 LLM 的自我评价当成唯一验收标准；
- 不在第一阶段解决通用 AGI 或任意领域的自治问题；
- 不要求一次重构就替换所有旧工具和业务数据能力。

---

## 4. 来自外部系统和论文的关键启示

### 4.1 Anthropic Research：动态探索，而不是预设完整路径

[Anthropic 多 Agent Research 系统](https://www.anthropic.com/engineering/multi-agent-research-system)采用 Lead Agent 动态派生并行 Subagent：Lead 根据中间发现决定下一批探索方向，子 Agent 使用隔离上下文搜索并返回压缩后的结果。

值得吸收的原则：

- 开放问题无法提前硬编码完整路径；
- 子任务必须有明确目标、边界、输出格式、工具和来源要求；
- 子 Agent 应直接写入持久化 Artifact，向父 Agent 返回引用和结论，避免多层“传话”损失；
- 并行数量和工具调用量应随问题复杂度变化；
- 长任务依赖 checkpoint、retry、恢复执行和完整 tracing；
- 评价应重视最终状态和关键 checkpoint，而不是要求每次运行走同一条过程。

需要避免照搬的部分：Anthropic 当前公开的 Research 架构主要仍是 Lead → Subagent 两层动态 fan-out，不等于任意层业务递归。

### 4.2 WriteHERE：创作最接近的动态递归案例

[WriteHERE](https://github.com/principia-ai/WriteHERE)及其[论文](https://arxiv.org/abs/2503.08275)不要求写作先完成固定大纲，再依序检索和创作；它把任务动态分成检索、推理、创作三类节点，并交错进行规划与执行。

对第三版最重要的启示是：

- “检索、思考、表达”是可调用的能力类型，不是固定流水线阶段；
- 当前执行结果可以改变后续计划；
- 脉络可以在创作过程中继续生长，而不是必须先一次性冻结；
- 长文创作需要结构化任务图和上下文控制，不能只依赖一段不断增长的对话历史。

### 4.3 ROMA：递归需要 Atomizer 和向上聚合

[ROMA](https://github.com/sentient-agi/ROMA)及其[2026 年论文](https://arxiv.org/abs/2602.01848)把递归拆成四类职责：

```text
Atomizer：判断当前目标是否已足够原子化
Planner：把非原子目标拆成有依赖关系的子目标
Executor：执行原子目标
Aggregator：把子结果压缩、验证并上升为父目标的结果
```

第三版应吸收 `Atomizer` 和 `Aggregator` 两个思想：

- 不是所有目标都需要继续拆；
- 子节点的原始输出不能简单拼接，父层必须重新解释、压缩、验证和形成自己的业务结论。

但第三版不能只停留在“拆—做—汇总”。创作还需要候选分叉、局部修正、方向切换、父目标重开和版本回选。

### 4.4 Anthropic Generator–Evaluator：生成者和评价者分离

[Anthropic 长任务 Harness 工程实验](https://www.anthropic.com/engineering/harness-design-long-running-apps)显示：让生成者评价自己，尤其在主观创作任务中，容易产生过度肯定；把生成和评价分离，并用明确 rubric 与样例校准评价者，更容易形成有效修正。这是对本系统有价值的工程假设，不应被当成所有任务上的普适定律。

同时需要吸收两个反直觉结论：

- 评价后既可以继续精修，也可以彻底 pivot；
- 最后一轮不一定最好，中间版本可能更优，因此每轮结果必须版本化保存，不能覆盖式更新。

### 4.5 Google Co-Scientist：让候选群体进化

[Google AI Co-Scientist](https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/)通过 Generation、Reflection、Ranking、Evolution 和 Meta-review 等机制，让候选假设不断生成、比较和进化。

对应到创作系统：

- 创作目标、叙事主张和表达方案都可以形成候选群体；
- 评价不只是指出问题，还应决定把后续算力投给哪些候选；
- 优秀候选可以组合，不必只选唯一胜者；
- 对主观创作不应只保留一个总分，而应维护多维质量向量和 Pareto 候选集。

### 4.6 Google Agent Scaling：多 Agent 必须与任务结构匹配

[Google 对 Agent System 的控制实验](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)显示：可并行任务适合中央协调的多 Agent，而严格顺序任务使用多 Agent 会因沟通和上下文割裂显著退化。该结论来自特定 benchmark，并未直接验证脚本创作，因此只应作为第三版初始调度假设，后续必须用自有 Eval 验证。

因此第三版不能采用“每个 WorkNode 默认生成多个 Agent”的策略。是否多 Agent，应由节点特征决定，而不是由层级深度或角色模板决定。

### 4.7 OpenAI Symphony：给目标，不给死路径

[OpenAI Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/)的启示是：把业务目标和可观察状态固定下来，把完成目标的具体路径交给 Agent，并允许 Agent 提出后续工作。Symphony 自身仍使用明确工作状态和 `WORKFLOW.md`，它不是任意层递归业务树的现成实现。

第三版应固定“目标、协议和护栏”，而不是固定“每一步业务动作”。

---

## 5. 总体架构

```mermaid
flowchart TB
    U["用户与上游 Topic"] --> RI["RootIntent\n最终意图、账号约束、事实边界、禁区"]
    RI --> RK["Recursive Work Kernel\nWorkNode、父层重入、调度、预算、恢复"]

    RK --> NP["Node Policy\n判断粒度、缺口与执行形态"]
    NP --> AR["Agent Runtime\n模型、工具、traits、上下文、结构化输出"]
    NP --> CH["Child WorkNodes\n可顺序、并行或依赖执行"]

    AR --> AS["Artifact/Candidate Store\n目标、脉络、证据、元素、草稿、评价"]
    CH --> AS
    AS --> EV["Evaluation Router\n硬校验、目标、连贯、原创、受众、事实"]
    EV --> PR["Parent Re-entry\n接纳、修正、补同层、下钻、回退、升级"]
    PR --> RK

    RK --> ES["Event & Checkpoint Store\n完整历史、恢复、重放、审计"]
```

建议分成七层：

1. **Intent 层**：保存用户最终意图和不可被子 Agent 擅改的全局约束。
2. **Recursive Kernel 层**：定义 WorkNode、父子协议、树级预算和父层重入。
3. **Policy 层**：判断是否拆分、是否并行、调用什么能力、何时停止。
4. **Agent Runtime 层**：运行模型、工具、traits、会话和结构化输出。
5. **Artifact 层**：保存所有目标、脉络、元素、证据、候选和版本关系。
6. **Evaluation 层**：进行硬约束和创作品质验证，产生可执行反馈。
7. **Durability/Observability 层**：事件日志、checkpoint、恢复、追踪和成本统计。

---

## 6. 核心业务对象

### 6.1 RootIntent：允许自治，但不能目标漂移

“Agent 自己划定目标”不意味着 Agent 可以改变用户的最终目的。

应区分三层目标：

- `RootIntent`：用户或上游业务给出的最终意图，原则上不可由普通节点擅自修改；
- `GoalSpec`：在 RootIntent 下生成的局部期望状态、约束和质量标准，不可变且带版本；
- `CreativeIntent`：尚在探索的创作目标 Artifact。只有被有权父节点接纳并提升后，才会形成新的 GoalSpec。

WorkNode 不内嵌一段可被静默改写的 objective，而是保存 `objective_ref = GoalSpec@version`。Replan 会产生新 GoalSpec 和新 NodeContract，旧 Attempt 被标记为 `SUPERSEDED`。

RootIntent 建议明确区分：

```text
hard_constraints
  用户最终诉求、事实与来源边界、禁区、必须条件

negotiable_preferences
  受众偏好、语气、长度、形式、创意风险偏好

autonomy_scope
  系统可自主划定哪些局部目标，可调动什么资源

human_gates
  哪些高主观、高风险或不可逆决定必须由人批准
```

当下游发现 RootIntent 冲突或信息不足时，只能产生 `RootIntentChangeProposal`。`RootAuthority` 是人类或明确授权的业务策略；只有它能批准 hard constraints 的改变。根 Agent 可以提议，不能自行批准。最终关闭由 `RootCompletionGate` 对 RootIntent、最终 Artifact Projection、风险和人工门禁做验收。

### 6.2 WorkNode：递归业务责任的最小单元

WorkNode 不是一次 LLM Call，也不是一条表格记录。它表示一个需要负责到底的局部业务目标。

建议字段：

```text
node_id / parent_node_id
objective_ref = GoalSpec@version
contract_ref = NodeContract@version
scope / owns / forbids
facts / hypotheses / unknowns
owning_parent / dependencies / children
artifact_refs / evidence_refs
required_capabilities
behavioral_preferences / forbidden_behavior
node_profile
capability_lease / budget_lease
status / state_revision
attempt_ids / progress / stall_count
```

`owning_parent` 和 `dependencies` 必须分开：一个 WorkNode 只有一个负责验收的直接父节点；跨分支依赖只影响调度和 Artifact 失效传播，不改变所有权。

其中 `node_profile` 用于调度判断：

```text
decomposability          是否容易拆成相互独立的部分
sequential_dependency    前一步对后一步的依赖强度
shared_context_need      多个执行者共享同一上下文的必要程度
uncertainty              当前方向和答案的不确定性
verifiability            是否存在可靠的外部验证方式
tool_density             需要协调多少工具
expected_value           继续投入的预期价值
subjectivity             多大程度依赖品味和受众感受
```

### 6.3 NodeAttempt：返工不覆盖上一轮

`NodeAttempt` 是 WorkNode 的一轮完整尝试：

```text
attempt_id / node_id
objective_ref / contract_ref
input_snapshot_ref
base_artifact_versions
decision
agent_run_refs / tool_run_refs
artifact_proposal_refs
evaluation_refs
started_at / ended_at
status / termination_reason
```

`ChildDisposition=REQUEST_REVISION` 会创建新 Attempt，而不是清空旧尝试。这样才能回放“为什么改、改了什么、质量是否真的提升”。

### 6.4 NodeContract：父子开始工作前先约定“完成是什么”

父节点创建子节点时，必须同时提供不可变、带版本的可检查合同：

```text
contract_id / contract_version
objective_ref
为什么需要这个子节点
它拥有和不得修改的范围
必须读取的 Context/Artifact 引用
期望交付物及结构
验收维度和最低通过条件
来源与证据要求
必需业务能力 required_capabilities
行为偏好 behavioral_preferences / forbidden_behavior
授权与副作用边界
预算与截止条件
失败时允许采取的动作
返回父层必须说明的未解决问题
```

子节点可以接受合同，也可以返回 `CONTRACT_CHALLENGE`：指出目标冲突、上下文缺失、验收不可验证或者预算不足。父节点如果接纳，必须创建新合同版本，不能就地改动旧合同。

合同的价值不是把步骤写死，而是固定责任边界，让子节点可以自主选择实现路径。

### 6.5 Artifact 与 Candidate：结果不能只存在于聊天消息中

建议把以下内容都建模为 Artifact：

```text
CreativeIntent         创作目标候选
AudienceModel          受众状态和预期变化
NarrativeGraph         主张、证据、情绪与行动的叙事关系
EvidenceItem           事实、案例、实验和来源
ElementCandidate       人物、场景、概念、方法、视觉、形式元素
CompositionCandidate   某个局部表达或段落方案
Draft                   文稿或执行稿版本
EvaluationReport        评价结果与修正建议
DecisionRecord          父节点的取舍与理由
```

Artifact 应采用不可变版本或 append-only 变更：

- 每次修改产生新版本，不覆盖旧版本；
- 记录 `derived_from`、贡献节点、使用来源和评价；
- 父节点可以 `accept / merge / park / reject / supersede`；
- 当前最佳版本只是一个指针，不等于删除其他候选；
- 最终创作表由已接受 Artifact 投影生成。

`Candidate` 不是另一种与 Artifact 并列的业务对象，而是“尚未被 owner 提升为当前权威版本”的 Artifact 版本状态。执行者不直接写权威指针，而是提交 `ArtifactProposal/ChangeSet`：

```text
proposal_id
artifact_type / artifact_id
expected_base_version
new_version_ref / patch
rationale / evidence_refs
affected_refs
idempotency_key
```

父节点或 Artifact owner 通过 compare-and-swap / 事务接纳，避免并发子节点静默覆盖彼此。

### 6.6 ReturnEnvelope：子节点向父节点交付的统一协议

子节点不能只返回一段自然语言总结。建议统一返回：

```text
run_id
node_id
attempt_id
contract_id / contract_version
parent_goal_ref
parent_contract_ref
spawn_generation
spawned_from_parent_revision      # 追踪用，不直接决定语义失效
input_snapshot_ref
base_artifact_versions
budget_lease_id
idempotency_key
completion_status
return_reason
deliverable_refs
artifact_proposal_refs
evidence_refs
validation_reports
assumptions_made
unresolved_gaps
risks
sibling_proposals
parent_assumptions_to_reconsider
recommended_disposition
budget_used
trace_ref
```

`completion_status` 表示交付完成程度：

```text
SATISFIED
PARTIAL
UNSATISFIED
FAILED
CANCELLED
SUPERSEDED
```

`return_reason` 表示为什么现在返回：

```text
NORMAL
CONTRACT_CHALLENGE
ESCALATION
BUDGET
DEADLINE
RISK
DEPENDENCY_BLOCKED
```

任何结果都可以合法返回，不是只有“已完成”才能交付。父节点先检查 `parent_goal_ref + parent_contract_ref + spawn_generation` 的语义有效性，再检查 Artifact 基线版本；语义陈旧的返回只能 rebase、park 或 reject，不得静默合并。单纯因另一子节点先返回而导致父状态 revision 增长，不等于这个子结果已过时。检查通过后，父节点必须重新进入 deliberation，而不是由框架自动把父节点标记为完成。

---

## 7. Goal、Capability 与 Traits 如何耦合

### 7.1 先划清“要什么、能做什么、怎么做”

这几个对象不能混在 Trait 或 Agent 角色里：

| 对象 | 职责 | 不应包含 |
|---|---|---|
| `GoalSpec` | 期望状态、约束、质量标准 | 模型名、工具名、Trait 名 |
| `Capability` | 有类型输入输出的业务能力，如 `search_evidence`、`compare_candidates`、`compose_narrative` | 具体 Agent 人设 |
| `Tool` | Capability 的一种具体实现或外部动作接口 | 是否有权调用自己的决定 |
| `Trait` | “倾向怎么做”的软性行为策略 | 权限、硬验收、输出 Schema |
| `AuthorizationPolicy / CapabilityLease` | 可使用哪些能力、资源范围、副作用、预算、是否可继续委派 | 创作风格偏好 |
| `ContextRecipe` | 本次读哪些上下文与 Artifact | 给 Agent 新的业务权限 |
| `OutputContract / ValidatorSet` | 必须交付什么、如何验收 | 软性人设 |

Trait 不应只是一句 Prompt 形容词，例如“你要有创造力”或“你要严谨”。它应是一份可版本化、可组合、可评价的行为策略模块：

```text
trait_id / version
purpose
activation_conditions
behavioral_rules
compatible_traits / conflicting_traits
cost_and_latency_hint
```

Trait 永远不能授予权限，也不能绕过 RootIntent、NodeContract、Schema 或确定性护栏。

脚本创作可能需要的 Traits：

| Trait | 作用 | 典型使用位置 |
|---|---|---|
| `creative_divergence` | 主动生成差异化候选，避免过早收敛 | 创作目标、角度、形式探索 |
| `evidence_grounded` | 所有事实和案例保留来源，区分事实与推断 | 机制、实验、案例节点 |
| `causal_reasoning` | 检查主张、原因、证据和结论的因果链 | 机制解释、知识内容 |
| `narrative_continuity` | 维护上下文、段间承接和受众认知变化 | 脉络与连续写作 |
| `audience_empathy` | 从目标受众视角预测理解、情绪和行动 | 目标、表达和整体评价 |
| `account_consistency` | 约束账号语言、价值和表现习惯 | 目标、形式与最终文稿 |
| `skeptical_evaluator` | 主动寻找遗漏、模板化和虚假完成 | 独立评价节点 |

`evidence_grounded` 可以影响推理风格，但“来源必须可追溯”是硬合同；“不直接覆盖主版本”和“权限最小化”是 Kernel Policy，不应伪装成 Trait。

### 7.2 Goal 不应直接绑定 Agent 或 Trait

不建议这样设计：

```text
GoalType = 产生脉络
固定调用 OutlineAgent
OutlineAgent 固定带 narrative_trait
```

建议增加中间层：

```text
GoalSpec + NodeContract + NodeProfile
→ CapabilityResolver
→ TraitComposer
→ ModelRouter / ToolBinder
→ 与 AuthorizationPolicy / CapabilityLease 求交集
→ ContextBuilder + OutputContract + ValidatorSet
→ ExecutionProfile
→ 临时 AgentInstance
```

`ExecutionProfile` 可以理解为本次执行的完整配方：

```text
model_class
instructions
capabilities
traits
tools
capability_lease
context_recipe
output_contract / output_schema
validators
budget
```

最终运行的 Agent 是一次临时实例化：

```text
AgentInstance
= Model
+ Tools
+ Traits
+ CapabilityLease
+ Scoped Context
+ Output Schema
+ Budget
```

这个公式只描述执行配方，不赋予 AgentInstance 业务所有权。WorkNode 才是持久责任主体；AgentInstance 可以在暂停、恢复、模型更换后被重建。

这样有几个好处：

- 同一个目标可以先用探索型 Agent 生成候选，再用因果型 Agent 深化；
- 同一个 Trait 可以被不同目标复用；
- 模型升级或工具变化不会迫使业务目标模型跟着变化；
- 不会因为预先创建了几十个角色，而让系统退化成固定组织架构。

### 7.3 Trait 的继承规则

子节点应继承全局硬约束、父合同和权限上限，不是父 Agent 的全部 Traits。

决策时先合并硬约束：

```text
Safety / AuthorizationPolicy
∩ RootIntent hard_constraints
∩ NodeContract
∩ Parent CapabilityLease
```

任一硬约束冲突都应返回 ContractChallenge 或 Escalation，不由软性 Trait 决胜。硬约束通过后，再按 `Domain behavioral defaults → Task behavioral preferences → 模型默认行为` 组合 Trait，且越靠前优先级越高。

例如：

```text
父节点：探索“谷歌效应”创作目标
  traits = creative_divergence + audience_empathy

子节点：验证认知卸载机制
  traits = evidence_grounded + causal_reasoning

子节点：形成连续叙事
  traits = narrative_continuity + account_consistency

评价节点：检查原创性和逻辑漏洞
  traits = skeptical_evaluator
```

创作发散和怀疑式评价通常存在行为冲突，最好由不同 Agent 实例承担，而不是要求同一个模型在同一次调用中既大胆发散又立即否定自己。

---

## 8. 父子节点机制

### 8.1 所有权原则

- 父节点只拥有自己的直接子节点；
- 子节点可以创建自己的子节点，但不能直接创建自己的兄弟节点；
- 子节点可以通过 `sibling_proposals` 建议父节点创建 `1.1.2`；
- 是否创建 `1.1.2`，最终由 `1.1` 决定；
- 子节点不得直接修改父节点已接受的 Artifact，只能提交 Candidate/Patch；
- 父节点负责对子结果进行验收、合并、驳回、停车或要求返工。

### 8.2 三个树方向

用户提出的三个方向应保留为产品语言，但不宜直接做成一个状态机枚举：

```text
横向细化
  子节点返回 sibling_proposals，父节点验收后自己决定 SPAWN_CHILDREN

向下
  当前节点的 ParentNextAction=SPAWN_CHILDREN，拆出自己负责的下一层

回退 / 向上
  当前节点的 ParentNextAction=RETURN，通过 CompletionStatus + ReturnReason 把当前责任交给上层
```

因此“横向”不是子节点直接改树的权限，而是一次向上返回中的建议。`SPAWN_CHILDREN` 已表达“继续拆分”，不再另设与它重叠的 `DECOMPOSE_AFTER_FAILURE`。

### 8.3 结果处置维度

一次父层重入必须明确下面四轴，不把“结果怎样”、“为什么返回”、“如何处置子责任”和“父节点自己下一步做什么”混在一起：

```text
CompletionStatus
  SATISFIED | PARTIAL | UNSATISFIED | FAILED |
  CANCELLED | SUPERSEDED

ReturnReason
  NORMAL | CONTRACT_CHALLENGE | ESCALATION | BUDGET |
  DEADLINE | RISK | DEPENDENCY_BLOCKED

ChildDisposition
  ACCEPT | REQUEST_REVISION | PARK | REJECT | CANCEL | SUPERSEDE

ParentNextAction
  EXECUTE_LOCAL | SPAWN_CHILDREN | WAIT_CHILDREN |
  PIVOT | REPLAN | REASSIGN | RETURN
```

`ESCALATION` 是当前节点向上返回的原因，不是父节点对子责任的处置。父节点如果也无法解决，再选择自己的 `ParentNextAction=RETURN` 和 `ReturnReason=ESCALATION`。

ChildDisposition 与 NodeStatus 的确定性映射为：

| ChildDisposition | 子 WorkNode 下一状态 | 附加动作 |
|---|---|---|
| `ACCEPT` | `COMPLETED` | 记录父层验收证据 |
| `REQUEST_REVISION` | `READY` | 创建新 NodeAttempt，保留旧 Attempt |
| `PARK` | `SUSPENDED` | 保留恢复条件和预算归还记录 |
| `REJECT` | `REJECTED` | 保留结果与驳回理由 |
| `CANCEL` | `CANCELLED` | 取消未完成副作用或进入补偿 |
| `SUPERSEDE` | `SUPERSEDED` | 关联新 GoalSpec / NodeContract / spawn generation |

Artifact 处置仍是独立的 `ACCEPT | MERGE | PARK | REJECT | SUPERSEDE | REQUIRE_REVALIDATION`。一个子节点可以交付三个 Artifact，父节点接纳两个、停放一个；因此 Artifact 处置不能反向代表整个节点状态。

### 8.4 父层重入

每个子节点返回都先以 `idempotency_key` 写入 append-only `ChildReturnInbox`，不拿子节点启动时看到的旧 parent revision 直接做 CAS。调度器可合并同一批返回，然后读取父节点当前的 `state_revision`，生成完整 `ParentReentryContext`：

```text
parent_snapshot / parent_state_revision
parent_goal_ref / parent_contract_ref / active_spawn_generation
received_envelopes / pending_children / child_return_inbox
child_group_policy
artifact_base_versions
accepted_child_artifacts / unresolved_gaps
sibling_proposals
evaluation_reports / conflicts
remaining_budget / marginal_value
```

子节点组策略至少支持：

```text
ALL          等所有直接子节点
QUORUM       达到足够有效结果
FIRST_VALID  第一个通过合同即可收敛
DEADLINE     到截止时间用已有结果整合
STREAMING    每个返回都允许父层重入并调整计划
```

父节点必须先产生一等对象 `IntegrationPlan`，执行后得到 `IntegrationResult`：

```text
IntegrationPlan
  expected_parent_state_revision
  selected_envelopes
  conflict_resolution
  artifact_changesets
  children_to_wait / cancel / revise
  gaps_after_integration

IntegrationResult
  committed_artifact_versions
  rejected_or_parked_refs
  invalidated_refs
  remaining_gaps
parent_contract_validation
```

提交 ParentDecision / IntegrationPlan 时才使用 `expected_parent_state_revision` 做 CAS。如果另一次父层重入已经推进 revision，当前 IntegrationPlan 重读 inbox 和新快照后重算，而不是将后返回的合法子结果判为陈旧。只有 `parent_goal_ref`、`parent_contract_ref` 或 `spawn_generation` 不再活跃时，子结果才是语义陈旧；Artifact 的 `expected_base_version` 冲突则单独走 rebase / merge / reject。

完成整合后，`1.1` 才决定要求 `1.1.1` 修订、创建 `1.1.2`、自己执行、重新规划，或确认当前合同完成并返回 `1`。当 QUORUM、FIRST_VALID 或 DEADLINE 已满足时，IntegrationPlan 必须明确等待、取消还是停放其余子节点，不得让它们在背景继续无限消耗。

```mermaid
sequenceDiagram
    participant P as 父 WorkNode
    participant K as Recursive Kernel
    participant C as 子 WorkNode
    participant A as Artifact Store
    participant E as Evaluator
    P->>K: 提交 ChildSpec + NodeContract + BudgetLease
    K->>C: 启动独立、持久化 Child Run
    C->>A: 提交 Candidate / ChangeSet
    C-->>K: ReturnEnvelope
    K->>K: 幂等写 ChildReturnInbox，校验语义来源
    K->>P: 以当前 state_revision 恢复 ParentReentryContext
    P->>E: 评价待整合结果
    P->>K: IntegrationPlan + expected_parent_state_revision
    K->>A: CAS + 事务执行 ChangeSets
    P-->>K: 继续执行 / 新建子节点 / 返回上层
```

这个“返回事件 → 版本检查 → 父层整合 → 父合同重验”闭环，才是第三版区别于普通 GoalTree 的核心语义。

### 8.5 节点生命周期

节点运行状态、父层处置和 Artifact 处置必须分开。`NodeStatus` 固定的是协议状态，不是业务工序：

```text
PROPOSED
→ CONTRACTING
→ READY
→ RUNNING
→ WAITING_CHILDREN 或 SYNTHESIZING
→ READY_TO_RETURN
→ RETURNED
→ COMPLETED / SUSPENDED / REJECTED / CANCELLED / SUPERSEDED
```

父层 `REQUEST_REVISION` 会让同一 WorkNode 创建新 NodeAttempt 并回到 `READY/RUNNING`；Replan 创建新 GoalSpec 和 NodeContract，旧 Attempt 及其陈旧返回被 `SUPERSEDED`。`CompletionStatus=FAILED` 只说明本次交付失败，父层仍可选择 REQUEST_REVISION、PARK 或 REJECT，因此它不直接等于 WorkNode 终态。`RETURNED` 也不等于 `COMPLETED`，只有 owning parent 接纳责任，或 RootCompletionGate 通过，节点才最终关闭。

任何层级都运行这套协议。不同节点的业务步骤可以完全不同，严禁用 `GOAL_STAGE → OUTLINE_STAGE → ELEMENT_STAGE` 一类枚举驱动节点状态机。Artifact 类型是数据 Schema，不是流程阶段。

---

## 9. 创作领域如何动态运行

### 9.1 目标、脉络、元素不是固定顺序

旧系统倾向于：

```text
先定目标 → 再建完整脉络 → 再找齐元素 → 再装配
```

第三版允许出现：

```text
发现受众矛盾
→ 下钻验证矛盾是否真实
→ 形成一个创作目标候选
→ 建立初步叙事主张
→ 发现证据缺口
→ 创建检索子节点
→ 新案例带来更强的表达元素
→ 元素反向触发脉络重排
→ 连续写作
→ 评价发现目标本身过于普通
→ 返回目标父层，保留旧稿并生成新方向
```

固定的是 Artifact 类型和父子协议，不是 Artifact 出现的先后顺序。

### 9.2 目标建模

建议把创作目标建模为“受众变化”，而不是一句抽象口号：

```text
受众当前认知/情绪/行为
→ 作品希望造成的变化
→ 核心主张和信息增量
→ 为什么适合这个账号
→ 可以怎样验证是否实现
```

根节点可以并行生成若干 `CreativeIntent Candidate`，再由父层按目标价值、原创性、账号一致性、可证据化程度和可执行性选择或组合。

### 9.3 脉络建模

脉络不应首先等同于 P1–P5 段落。建议先表示为 `NarrativeGraph`：

```text
受众初始状态
→ 矛盾/悬念
→ 核心主张
→ 解释或证据
→ 情绪桥
→ 行动或价值收束
→ 受众目标状态
```

段落结构是 NarrativeGraph 的一种表现形式。NarrativeGraph 变化后，可以重新投影为不同的段落数量、层级和顺序。

### 9.4 元素建模

元素应围绕“叙事需要”出现，而不是进入统一的元素生产阶段：

| 当前缺口 | 可能创建的元素节点 |
|---|---|
| 缺可信度 | 事实、实验、数据、真实案例 |
| 缺理解 | 概念、类比、机制解释、反例 |
| 缺情绪 | 人物、生活场景、冲突、细节 |
| 缺行动 | 方法、步骤、工具、检查表 |
| 缺记忆点 | 金句、视觉意象、形式结构 |
| 缺账号感 | 历史表达、语言习惯、视觉习惯 |

元素与脉络是双向关系：脉络发现缺口后请求元素；强元素也可以反向改变主张和段落结构。

### 9.5 跨分支影响：元素不能静默篡改脉络

当子节点发现自己的结果会改变另一分支时，它不直接改对方的 Artifact，而是提交：

```text
ImpactProposal
  source_artifact_version
  target_artifact_refs
  relation:
    SUPPORTS | CONTRADICTS | REQUIRES_CHANGE | INVALIDATES
  rationale / evidence_refs
  proposed_change
  affected_dependents
```

审批者是目标 Artifact 的 owner；如果涉及多个 owner，由最近公共父节点协调。接纳后生成新 Artifact 版本，Artifact Graph 只沿 `DERIVED_FROM / USES / PROJECTED_FROM` 等 DependencyEdge 把真正下游标记为 `STALE` 或 `REVALIDATION_REQUIRED`；`SUPPORTS / CONTRADICTS` 等 SemanticEdge 只触发评价或 ImpactProposal，不自动级联失效。

例如：

```text
Evidence v1
→ 否定 NarrativeClaim v1
→ 1.3.1 提交 ImpactProposal
→ 最近公共父节点重开 1.2
→ 产生 NarrativeGraph v2
→ Draft v1 标记 STALE
→ 产生 Draft v2
→ 重新验证 CreativeIntent 是否仍成立
```

如果 RootIntent 或 GoalSpec 本身版本改变，所有尚在运行的旧子 Attempt 回来时都先做版本检查，不能用陈旧结果把新方向改回去。

### 9.6 一个示例递归树

```text
1 完成“谷歌效应”脚本创作
├── 1.1 划定最有价值的创作目标
│   ├── 1.1.1 探索受众真实矛盾
│   │   ├── 1.1.1.1 检索数字失忆场景
│   │   └── 1.1.1.2 验证断网焦虑是否适合主线
│   └── 1.1.2 验证目标与账号定位是否匹配
├── 1.2 构建叙事主张
│   ├── 1.2.1 解释认知卸载机制
│   └── 1.2.2 建立从机制到行动的过渡
├── 1.3 为叙事缺口寻找元素
│   ├── 1.3.1 Betsy Sparrow 实验
│   └── 1.3.2 主动提取练习
└── 1.4 连续创作与整体收口
```

这只是某一时刻的树快照，不是启动前固定的阶段。它可能由 `1.1.1` 的结果逐步生长，`1.3.1` 也可能让父层重新修改 `1.2`。为避免实现者又照抄成“目标 → 脉络 → 元素”流水线，最少应将下面三类非线性路径做成架构一致性测试：

```text
证据先行：先发现强案例 → 再提炼 CreativeIntent → 再生长 NarrativeGraph
元素反推：强 Element → 推翻 NarrativeClaim → 必要时重开 GoalSpec
整体回跳：终局评价 → 跨过当前稿件节点 → 返回上两层重定局部目标
```

---

## 10. 如何选择单 Agent、多 Agent 和工具执行

建议由 `ExecutionModePolicy` 根据 NodeProfile 选择：

| 节点特征 | 推荐执行形态 |
|---|---|
| 高可分解、低顺序依赖、高不确定 | 父节点中央协调，多候选子 Agent 并行 |
| 高顺序依赖、高共享上下文 | 单 Agent 连续执行，必要时只调用工具 |
| 有可靠硬验证器 | Generator → Validator → Revision Loop |
| 高主观、需要多样性 | 多候选生成 + 独立评价 + Pareto 保留 |
| 工具多、调用复杂但目标明确 | 一个主 Agent 统一调用工具，避免多 Agent 协调税 |
| 连续无进展 | 更换 traits/模型/方法，或回到父层重规划 |
| 高风险或评价分歧大 | 请求人类确认 |

创作中的推荐划分：

适合并行：

- 创作目标和角度候选；
- 受众洞察假设；
- Case、Knowledge、Data 和证据检索；
- 元素和表现形式候选；
- 不同创意方向的草案；
- 从事实、原创、账号、受众等不同视角评价。

适合连续单 Agent：

- 一条已选叙事链的因果推演；
- 一个段落内部的连续展开；
- 强依赖前文语气和节奏的写作；
- 最终全篇一致性修订；
- 需要大量共享上下文的装配任务。

---

## 11. 评价与递归自动修正

### 11.1 评价分层

建议拆成可动态路由的评价能力：

```text
Hard Validator
  字段、结构、长度、禁区、来源、事实冲突、权限和副作用

Goal Critic
  当前 Artifact 是否真正完成局部目标

Coherence Critic
  与父目标、兄弟结果和整篇叙事是否连贯

Originality Critic
  是否模板化、陈词滥调或过度借用

Audience Simulator
  目标受众会如何理解、感受和行动

Account Critic
  是否符合账号价值和表达习惯

Meta Reviewer
  多个评价者冲突时进行裁决或请求人工
```

并非每个节点都调用所有评价者。Evaluator Router 应根据风险、主观性、Artifact 类型和历史失败动态选择。

### 11.2 多维质量，而不是单一总分

建议至少记录：

```text
goal_achievement
factual_grounding
narrative_coherence
information_gain
originality
account_fit
audience_effect
actionability
cost_efficiency
```

总分可以用于粗筛，但不能作为唯一决策依据。系统应保留在不同维度占优的 Pareto 候选，避免所有内容被一个 rubric 推向同一种安全风格。

### 11.3 修正阶梯

发现问题后，不要只做机械 retry。自动修正应复用第 8 节的正交协议，不再发明一套重叠枚举：

```text
1. 局部修订
   父节点自己修改：ParentNextAction=EXECUTE_LOCAL
   让原子节点修改：ChildDisposition=REQUEST_REVISION

2. 方向切换
   ParentNextAction=PIVOT，保留旧 Candidate

3. 局部重规划
   ParentNextAction=REPLAN，生成新 GoalSpec / NodeContract / spawn generation

4. 继续向下拆分
   ParentNextAction=SPAWN_CHILDREN

5. 更换执行配方
   ParentNextAction=REASSIGN，重新解析模型、Traits 和能力实现

6. 向上返回或升级
   ParentNextAction=RETURN
   例如 CompletionStatus=UNSATISFIED + ReturnReason=CONTRACT_CHALLENGE / ESCALATION
```

### 11.4 停止条件

递归系统最危险的不是不会继续，而是不知道何时停止。每轮至少检查：

- 父合同是否通过；
- 最近若干轮是否仍有真实质量提升；
- 是否出现已有能力回归；
- 是否只是复杂度增加，质量没有增加；
- 评价者是否发生无法解决的分歧；
- 剩余预算是否值得继续；
- 是否缺少可靠验证器；
- 是否已经进入必须依赖人类品味的区域。

终止原因应被结构化记录：

```text
ACCEPTED_BY_PARENT
MARGINAL_GAIN_TOO_LOW
STALL_LIMIT_REACHED
BUDGET_EXHAUSTED
RISK_ESCALATION
HUMAN_JUDGMENT_REQUIRED
NO_RELIABLE_VALIDATOR
```

---

## 12. 三棵图和四类状态必须分开

第三版至少需要维护三套相互关联但不能混为一体的结构：

### 12.1 WorkNode Tree

回答：为什么做、谁对什么目标负责、父子如何收敛。

### 12.2 Artifact/Candidate Graph

回答：实际产生了哪些目标、脉络、证据、元素、草稿和版本，它们如何派生、组合和被淘汰。

Artifact 不一定严格是树，因为一个证据可以被多个段落使用，一个元素也可能支持多个候选。但图中两类边必须分开：

```text
SemanticEdge
  SUPPORTS | CONTRADICTS | ANALOGOUS_TO | ALTERNATIVE_TO
  用于推理和评价，不自动传播 STALE

DependencyEdge
  DERIVED_FROM | USES | PROJECTED_FROM
  表示产物真正依赖的基线，上游失效时才自动传播 STALE / REVALIDATION_REQUIRED
```

否则 `A SUPPORTS B`、`B CONTRADICTS C` 一类双向语义网络可能形成循环失效，把整张 Artifact Graph 无意义地全部重开。

### 12.3 Execution Trace Tree

回答：哪个 Agent、模型、Prompt、工具和调用产生了某个结果，成本、延迟和错误在哪里发生。

此外还要区分四类状态：

| 状态 | 用途 |
|---|---|
| Session/Event History | 完整、append-only、不可因上下文压缩而丢失的运行历史 |
| Working Context | 当前节点本轮真正需要送进模型的最小高信号上下文 |
| Artifact Store | 目标、脉络、元素、文稿和评价等业务产物 |
| Checkpoint | 可恢复执行所需的节点、消息、预算和待处理动作快照 |

模型上下文可以压缩或重建，但 Session 和 Artifact 不能随模型上下文一起消失。

为了让“临时 AgentInstance”与“连续创作所需的语境”同时成立，建议增加：

```text
ContextManifest
  本轮使用的 RootIntent、GoalSpec、Artifact 版本、摘要和来源引用

SessionContinuityPolicy
  REUSE_CONTROLLED_SESSION | REBUILD_FROM_MANIFEST | ISOLATED_FRESH_CONTEXT
```

强顺序的叙事节点可复用受控会话，并行探索则使用隔离上下文。恢复时优先从 ContextManifest 重建，不把 SDK Session 当成唯一业务真相。

---

## 13. Agent SDK 应承担什么

结论：应该使用 Agent SDK，但只把它当作执行底座，不把业务递归语义交给 SDK。

### 13.1 SDK 适合负责

- Agent/模型调用循环；
- Function Tool、MCP 和业务工具调用；
- 原子、短时、无独立生命周期的 Agent-as-tool 执行；
- 结构化输出和 Schema 校验；
- Session、上下文注入和流式事件；
- Guardrail、人工审批和工具权限；
- Trace、Span、Token 和延迟统计；
- 模型切换、重试和基础错误处理。

SDK 可执行 Guardrail 和工具权限，但权限上限由 Kernel 签发的 CapabilityLease 决定；SDK 不能自行扩大委派、Artifact 写入或预算权限。

### 13.2 Recursive Kernel 必须自己负责

- WorkNode 树及稳定 node_id；
- 父子 NodeContract；
- 子节点完成后的父层重入；
- 直接子节点的所有权；
- 全树深度、宽度、Token、工具和修订预算；
- Artifact/Candidate 的提交、比较、合并、停车和回滚；
- 业务级 checkpoint 和幂等副作用；
- Capability、Traits、CapabilityLease 与执行配方的解析；
- 动态执行模式选择；
- 父合同的最终验收责任。

### 13.3 正式父子节点由 Kernel 管理 Child Run

以 [OpenAI Agents SDK 的编排模型](https://openai.github.io/openai-agents-python/multi_agent/)为例：

- `Handoff`：用于用户会话或当前 Run 的控制权转移，不是父子交付；
- `Agent-as-tool`：适合短时、同步、可视为原子能力、不需要独立 checkpoint 的叶子调用；
- `Kernel-managed Child Run`：适合有 `node_id`、合同、预算、独立生命周期、可暂停恢复且可再递归的正式业务节点。

第三版的默认父子机制必须是第三种：

```text
父 WorkNode
→ 持久化 ChildSpec / NodeContract / BudgetLease
→ Kernel 启动独立 Child Run，父节点挂起或继续可并行工作
→ 子 WorkNode 内部可继续递归、checkpoint、暂停和恢复
→ ReturnEnvelope 作为事件返回 Kernel
→ Kernel 校验版本与幂等后恢复父 WorkNode
```

不要把正式 WorkNode 嵌套在一次父 Agent 的同步调用栈中，也不要依赖 SDK 默认 Handoff 模拟业务父子关系。Agent-as-tool 是局部优化，不是 Recursive Kernel 的生命周期基础。

### 13.4 推荐的抽象接口

```text
NodeDecisionPort.propose(node_id, parent_state_revision) -> NodeDecision
KernelCommandPort.apply(command, idempotency_key) -> Events
ChildRunPort.spawn(child_specs, leases) -> ChildHandles
ChildReturnInbox.append(ReturnEnvelope, idempotency_key)
ParentReentryPolicy.decide(ParentReentryContext) -> ParentDecision
IntegrationPort.apply(IntegrationPlan, expected_parent_state_revision) -> IntegrationResult
CapabilityResolver.resolve(goal, contract, profile) -> CapabilityPlan
TraitComposer.compose(behavioral_preferences) -> Traits
AgentRuntimePort.execute(ExecutionProfile) -> AgentResult
ArtifactPort.propose(ChangeSet) / commit(IntegrationPlan)
EvaluationPort.evaluate(artifact_refs) -> EvaluationReports
CheckpointPort.save(run_state) / restore(checkpoint_ref)
```

LLM 可以提出 `NodeDecision`，但由确定性的 Kernel 校验权限、Schema、依赖、版本和预算后才能执行。Kernel 依赖上面这些 Port，OpenAI Agents SDK 或其他框架只在 Adapter 层实现 Port；模型负责提出计划，内核负责授权和落地。

---

## 14. 推荐模块边界

```text
recursive_kernel/
  work_node
  goal_spec
  node_contract
  node_attempt
  node_state_machine
  child_return_inbox
  parent_reentry
  integration
  child_scheduler
  budget_ledger
  decision_policy
  root_completion_gate

ports/
  agent_runtime_port
  child_run_port
  artifact_port
  evaluation_port
  checkpoint_port
  event_port

agent_runtime/
  sdk_adapters
  agent_runner_adapter
  model_router
  tool_runtime
  capability_resolver
  capability_lease
  trait_resolver
  context_builder
  structured_output

script_build_domain/
  root_intent
  creative_intent
  narrative_graph
  element_candidate
  composition_candidate
  domain_capabilities
  domain_traits
  domain_evaluators

artifacts/
  artifact_store
  candidate_repository
  changeset
  impact_proposal
  lineage
  invalidation_propagation
  merge_policy
  projection

durability/
  event_store
  checkpoint_store
  idempotency
  recovery

observability/
  traces
  node_timeline
  cost_metrics
  decision_explanations
```

依赖方向建议为：

```text
script_build_domain → recursive_kernel abstractions
recursive_kernel → ports
SDK / model / tool adapters → ports
artifact / durability adapters → ports
```

箭头表示源码依赖方向：具体 Adapter 实现 Kernel 声明的 Port，Kernel 不引用某个 SDK 的 Agent 类。业务领域也不能反向依赖具体模型 SDK，否则业务递归会再次被框架实现绑死。

---

## 15. 初始预算和护栏建议

以下仅作为第一轮实验默认值，不是最终业务规则：

```text
max_depth: 5
max_children_per_node: 4
max_total_nodes: 40
max_parallel_children: 4
max_revisions_per_node: 3
max_stalls_per_node: 2
```

预算必须由父向子分配：

- 子节点不能绕过父预算无限扩展；
- 子节点未用完的预算可以归还父层；
- 高价值候选可以申请追加预算，但必须说明预期收益；
- 并行分支应设置最慢节点超时和部分结果收敛策略；
- 根节点同时维护 Token、金额、时间、工具调用和总节点数预算。

---

## 16. 演进路线

### 阶段 0：先建立评价基线

目标：在改变架构前，明确什么叫“比旧 Workflow 更好”。

建议：

- 使用真实案例 388 重放旧流程；
- 建立覆盖不同账号、选题类型和素材稀疏度的代表性任务集；
- 保存旧流程的质量、成本、时长、工具数、修补轮数和人类偏好；
- 定义目标达成、事实、连贯、原创、账号适配和受众效果 rubric；
- 确立人工盲评和自动评价的校准方法。

工程门禁：

- 初始 Eval 集至少 20 个真实任务，覆盖不同账号、选题类型、素材稀疏度和质量风险；
- 旧 Workflow 对每个任务至少重复 3 次，记录质量和成本方差；
- 核心样本由至少 2 位人工盲评者重叠评分，评审一致性达到预先约定的门槛；
- 自动评价与人工判断的相关或一致标准在看新系统结果之前锁定。

### 阶段 1：实现最小 Recursive Kernel

目标：先打通真正的父子业务递归，不追求复杂多 Agent。

至少实现：

- GoalSpec / WorkNode / NodeContract / NodeAttempt / ReturnEnvelope；
- 父节点创建直接子节点；
- 子节点返回后父层强制重入；
- CompletionStatus、ReturnReason、ChildDisposition、ParentNextAction 四轴分离，Artifact 处置另行独立；
- 全树预算；
- Event、Artifact 和 Trace 分离；
- checkpoint 与恢复；
- 旧固定 Workflow 作为一条 `baseline policy` 运行在新内核上。

工程门禁：

- 真实演示 `1 → 1.1 → 1.1.1 → 返回 1.1 → 创建 1.1.2 → 返回 1`，且子节点返回不自动关闭父节点；
- 先实现顺序 Child Run 和基础 `ALL` 聚合；用两个来自同一 spawn generation 的模拟返回验证：父 `state_revision` 推进后，第二个合法结果仍能幂等进入 inbox；
- 父合同或 GoalSpec 升版后，旧 Attempt 返回必被 rebase、park 或 reject，不得直接接纳；
- checkpoint 恢复后不重复执行已成功的副作用，Event 可重放得到同一节点状态，所有预算不越界；
- 根节点只能通过 RootCompletionGate 关闭，Agent 不能自批 RootIntent 硬约束变更。

### 阶段 2：引入动态创作 Artifact

目标：让目标、脉络和元素不再是固定工序。

至少实现：

- CreativeIntent Candidate；
- NarrativeGraph；
- Evidence/Element Candidate；
- 不可变版本和 lineage；
- 父层 accept/merge/park/reject；
- 创作表 Projection；
- 元素反向触发脉络修改；
- 评价触发目标或父层重开。

工程门禁：

- 同一选题能产生并回选至少两种不同创作路径，lineage 从最终稿可追溯到 GoalSpec、证据、节点和评价；
- 真实演示“证据或强元素提交 ImpactProposal → 修改 NarrativeGraph → 下游 Draft 失效 → 重写和重验”；
- 通过证据先行、元素反推和整体回跳三类非线性架构一致性测试。

### 阶段 3：自适应单/多 Agent 调度

目标：让 Agent 数量由任务结构决定。

至少实现：

- NodeProfile；
- CapabilityResolver、TraitComposer、CapabilityLease 和 ExecutionProfile；
- 可并行候选 fan-out/fan-in；
- 强顺序节点单 Agent 连续执行；
- Evaluator Router；
- stall 检测和 revise/pivot/replan/reassign；
- 异步子节点、取消、超时和部分结果返回。
- `ALL / QUORUM / FIRST_VALID / DEADLINE / STREAMING` 子节点组策略。

工程门禁：

- 每次动态路由都能解释为什么选单 Agent、多候选或评价循环；
- 与 `always-single`、`always-multi` 两个简单策略在同一 Eval 上对照，动态路由在质量—成本 Pareto 上有预先约定的收益；
- 高级子节点组策略均能确定性选择整合、等待、取消或停放其余子节点；
- 取消、超时、部分返回和恢复执行均不产生重复 Artifact 写入或预算泄漏。

### 阶段 4：离线系统自我改进

目标：从真实 Trace 中改进 traits、Prompt、调度策略和评价标准。

建议参考 [AFlow](https://proceedings.iclr.cc/paper_files/paper/2025/hash/5492ecbce4439401798dcd2c90be94cd-Abstract-Conference.html)这类把 Agent Workflow 优化视为搜索问题的工作，但只允许在离线评测环境中进行：

```text
收集失败和成功 Trace
→ 生成策略/Prompt/Trait 候选
→ 在固定 Eval 集回放
→ 比较质量、成本和稳定性
→ 人工或发布门禁批准
→ 版本化上线
```

生产中的 Agent 不能同时担任规则修改者、评价者和发布批准者。

工程门禁：新策略必须通过从未参与调参的 holdout Eval，关键质量维度无回归，经人工或发布策略批准后才能上线，且必须能一键回滚到上一个已验证版本。

---

## 17. 验证指标

### 17.1 作品质量

- 创作目标达成率；
- 事实和来源准确率；
- 叙事连贯性；
- 信息增量；
- 原创性和非模板化程度；
- 账号一致性；
- 受众理解、情绪和行动效果；
- 人类最终偏好。

### 17.2 Agent System 质量

- 父合同一次通过率；
- 修订后通过率；
- 目标漂移率；
- 无效子节点比例；
- 重复工作比例；
- 平均/最大递归深度；
- 节点数、分支数和被 Park 的候选数；
- stall、replan、reassign 和 escalate 次数；
- checkpoint 恢复成功率；
- Artifact 来源可追溯率；
- Token、金额、延迟和工具调用量；
- 相对旧 Workflow 的质量收益/成本比。

### 17.3 必须保留的调试证据

对于任一最终段落，应能回答：

```text
它服务哪个 RootIntent 和局部目标？
由哪个 WorkNode 产生？
使用了哪些 traits、工具和上下文？
引用了哪些证据和元素？
经历了哪些候选和修订？
谁评价过？
父节点为什么接纳它？
如果重跑，能够从哪个 checkpoint 继续？
```

---

## 18. 主要风险与控制措施

| 风险 | 表现 | 控制措施 |
|---|---|---|
| Agent 爆炸 | 节点无限下钻和 fan-out | 父预算继承、最大深宽、预期收益检查、全树节点上限 |
| 目标漂移 | 子节点解决了另一个更容易的问题 | RootIntent 不可静默修改、NodeContract、父层验收 |
| 评价自我确认 | 生成者和评价者互相放水 | 生成/评价分离、硬验证、样例校准、人工抽检 |
| 风格收敛 | 所有内容被同一总分推成模板 | 多维评价、Pareto 候选、保留中间版本和多样性 |
| 顺序任务被打碎 | 段落衔接和因果链断裂 | NodeProfile 判断，强顺序任务保持单 Agent 连续上下文 |
| 上下文污染 | 全量历史塞给每个子 Agent | Context Recipe、Artifact 引用、按需检索、阶段摘要 |
| 子结果传话损失 | 多层摘要丢失原始细节 | 子 Agent 直接写 Artifact，ReturnEnvelope 只传引用和关键结论 |
| 无限修订 | 复杂度上升但质量不再提升 | 边际收益、stall、revision budget 和停止条件 |
| 并发冲突 | 多子节点同时覆盖同一产物 | 不可变候选、Patch 提交、父层单点合并、幂等键 |
| SDK 绑架业务 | 业务树受限于某框架的 handoff/goal 语义 | 自研 Recursive Kernel，SDK 只做执行适配 |
| 线上自修改失控 | Agent 修改 Prompt 后自行宣布成功 | 离线优化、固定 Eval、人工/发布门禁、版本回滚 |

---

## 19. 关键架构决策

1. **固定递归协议，动态生成业务计划。**
2. **RootIntent 硬约束不可被 Agent 自批改动，局部 GoalSpec 可在父层授权下动态创建和升版。**
3. **父节点拥有直接子节点；子节点只能建议兄弟节点。**
4. **子节点完成不自动完成父节点；父层重入是强制过程。**
5. **CompletionStatus、ReturnReason、ChildDisposition 和 ParentNextAction 是四个正交轴。**
6. **语义来源版本与并发 CAS state_revision 必须分开，合法的后返回子结果不能被误杀。**
7. **GoalSpec 与 Agent 解耦，通过 Capability、NodeProfile、Traits、CapabilityLease 和 ExecutionProfile 临时组装。**
8. **Trait 是版本化软性行为策略，不是固定角色、权限包或 Prompt 形容词。**
9. **目标、脉络、元素和文稿都是版本化 Artifact，不是固定阶段。**
10. **WorkNode Tree、Artifact Graph 和 Execution Trace 必须分开。**
11. **并行只用于可分解、高价值的探索；顺序创作保持连续上下文。**
12. **生成者和评价者分离，硬验证优先于模型自评。**
13. **多维评价和候选保留优先于单一总分和覆盖式修改。**
14. **Agent SDK 是执行适配层，Recursive Kernel 才是业务控制层，正式子节点必须是 Kernel-managed Child Run。**
15. **运行时自我修正与离线系统自我改进严格分开。**

---

## 20. 参考资料

- [Anthropic: How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)
- [Anthropic: Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
- [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [OpenAI: An open-source spec for Codex orchestration — Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/)
- [OpenAI Agents SDK: Agent orchestration](https://openai.github.io/openai-agents-python/multi_agent/)
- [Google Research: Towards a science of scaling agent systems](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)
- [Google Research: AI Co-Scientist](https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/)
- [WriteHERE: Beyond Outlining](https://arxiv.org/abs/2503.08275)
- [WriteHERE GitHub](https://github.com/principia-ai/WriteHERE)
- [ROMA: Recursive Open Meta-Agent Framework](https://arxiv.org/abs/2602.01848)
- [ROMA GitHub](https://github.com/sentient-agi/ROMA)
- [MASC: Metacognitive Self-Correction for Multi-Agent Systems](https://arxiv.org/abs/2510.14319)
- [Recursive Multi-Agent Systems](https://arxiv.org/abs/2604.25917)
- [Recursive Self-Improvement in AI Survey](https://arxiv.org/abs/2607.07663)
- [AFlow: Automating Agentic Workflow Generation](https://proceedings.iclr.cc/paper_files/paper/2025/hash/5492ecbce4439401798dcd2c90be94cd-Abstract-Conference.html)

---

## 21. 最终建议

第一阶段不要先讨论要创建多少个 Agent、每个 Agent 叫什么，也不要先把旧流程拆成更多角色。

应先把以下四件事做对：

```text
1. WorkNode 与父子责任
2. GoalSpec、NodeContract、NodeAttempt 与 ReturnEnvelope
3. 父层重入、正交控制协议和 Kernel-managed Child Run
4. Artifact 候选、版本、失效传播和评价闭环
```

这四件事成立以后，Agent、模型、工具、traits 和 SDK 都可以成为可替换的执行资源；否则即使增加很多 Agent，系统仍会回到“一个主编排器控制固定创作表 Workflow”的旧形态。