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

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

1. 结论摘要

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

目标 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

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

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

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

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

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

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

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

3. 架构目标与非目标

3.1 架构目标

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

3.2 非目标

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

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

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

Anthropic 多 Agent Research 系统采用 Lead Agent 动态派生并行 Subagent：Lead 根据中间发现决定下一批探索方向，子 Agent 使用隔离上下文搜索并返回压缩后的结果。

值得吸收的原则：

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

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

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

WriteHERE及其论文不要求写作先完成固定大纲，再依序检索和创作；它把任务动态分成检索、推理、创作三类节点，并交错进行规划与执行。

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

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

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

ROMA及其2026 年论文把递归拆成四类职责：

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

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

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

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

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

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

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

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

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

Google AI Co-Scientist通过 Generation、Reflection、Ranking、Evolution 和 Meta-review 等机制，让候选假设不断生成、比较和进化。

对应到创作系统：

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

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

Google 对 Agent System 的控制实验显示：可并行任务适合中央协调的多 Agent，而严格顺序任务使用多 Agent 会因沟通和上下文割裂显著退化。该结论来自特定 benchmark，并未直接验证脚本创作，因此只应作为第三版初始调度假设，后续必须用自有 Eval 验证。

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

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

OpenAI Symphony的启示是：把业务目标和可观察状态固定下来，把完成目标的具体路径交给 Agent，并允许 Agent 提出后续工作。Symphony 自身仍使用明确工作状态和 WORKFLOW.md，它不是任意层递归业务树的现成实现。

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

5. 总体架构

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完整历史、恢复、重放、审计"]

建议分成七层：

Intent 层：保存用户最终意图和不可被子 Agent 擅改的全局约束。
Recursive Kernel 层：定义 WorkNode、父子协议、树级预算和父层重入。
Policy 层：判断是否拆分、是否并行、调用什么能力、何时停止。
Agent Runtime 层：运行模型、工具、traits、会话和结构化输出。
Artifact 层：保存所有目标、脉络、元素、证据、候选和版本关系。
Evaluation 层：进行硬约束和创作品质验证，产生可执行反馈。
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 建议明确区分：

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

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

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

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

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

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

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

建议字段：

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 用于调度判断：

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

6.3 NodeAttempt：返工不覆盖上一轮

NodeAttempt 是 WorkNode 的一轮完整尝试：

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：父子开始工作前先约定“完成是什么”

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

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

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

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

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

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

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：

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：子节点向父节点交付的统一协议

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

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 表示交付完成程度：

SATISFIED
PARTIAL
UNSATISFIED
FAILED
CANCELLED
SUPERSEDED

return_reason 表示为什么现在返回：

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 形容词，例如“你要有创造力”或“你要严谨”。它应是一份可版本化、可组合、可评价的行为策略模块：

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

不建议这样设计：

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

建议增加中间层：

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

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

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

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

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

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

这样有几个好处：

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

7.3 Trait 的继承规则

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

决策时先合并硬约束：

Safety / AuthorizationPolicy
∩ RootIntent hard_constraints
∩ NodeContract
∩ Parent CapabilityLease

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

例如：

父节点：探索“谷歌效应”创作目标
  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 三个树方向

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

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

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

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

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

8.3 结果处置维度

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

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

8.4 父层重入

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

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

子节点组策略至少支持：

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

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

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 必须明确等待、取消还是停放其余子节点，不得让它们在背景继续无限消耗。

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 固定的是协议状态，不是业务工序：

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 目标、脉络、元素不是固定顺序

旧系统倾向于：

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

第三版允许出现：

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

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

9.2 目标建模

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

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

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

9.3 脉络建模

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

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

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

9.4 元素建模

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

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

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

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

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

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，不自动级联失效。

例如：

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

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

9.6 一个示例递归树

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。为避免实现者又照抄成“目标 → 脉络 → 元素”流水线，最少应将下面三类非线性路径做成架构一致性测试：

证据先行：先发现强案例 → 再提炼 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 评价分层

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

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

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

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

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

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

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

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

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

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

建议至少记录：

goal_achievement
factual_grounding
narrative_coherence
information_gain
originality
account_fit
audience_effect
actionability
cost_efficiency

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

11.3 修正阶梯

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

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 停止条件

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

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

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

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

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”与“连续创作所需的语境”同时成立，建议增加：

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 的编排模型为例：

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

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

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

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

13.4 推荐的抽象接口

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. 推荐模块边界

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

依赖方向建议为：

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. 初始预算和护栏建议

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

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这类把 Agent Workflow 优化视为搜索问题的工作，但只允许在离线评测环境中进行：

收集失败和成功 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 必须保留的调试证据

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

它服务哪个 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. 关键架构决策

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

20. 参考资料

21. 最终建议

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

应先把以下四件事做对：

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

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

agent-architecture-evolution-strategy.md 57 KB Trvalý odkaz Historie Surový

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

1. 结论摘要

阅读路径

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

3. 架构目标与非目标

3.1 架构目标

3.2 非目标

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

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

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

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

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

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

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

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

5. 总体架构

6. 核心业务对象

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

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

6.3 NodeAttempt：返工不覆盖上一轮

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

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

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

7. Goal、Capability 与 Traits 如何耦合

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

7.2 Goal 不应直接绑定 Agent 或 Trait

7.3 Trait 的继承规则

8. 父子节点机制

8.1 所有权原则

8.2 三个树方向

8.3 结果处置维度

8.4 父层重入

8.5 节点生命周期

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

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

9.2 目标建模

9.3 脉络建模

9.4 元素建模

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

9.6 一个示例递归树

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

11. 评价与递归自动修正

11.1 评价分层

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

11.3 修正阶梯

11.4 停止条件

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

12.1 WorkNode Tree

12.2 Artifact/Candidate Graph

12.3 Execution Trace Tree

13. Agent SDK 应承担什么

13.1 SDK 适合负责

13.2 Recursive Kernel 必须自己负责

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

13.4 推荐的抽象接口

14. 推荐模块边界

15. 初始预算和护栏建议

16. 演进路线

阶段 0：先建立评价基线

阶段 1：实现最小 Recursive Kernel

阶段 2：引入动态创作 Artifact

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

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

17. 验证指标

17.1 作品质量

17.2 Agent System 质量

17.3 必须保留的调试证据

18. 主要风险与控制措施

19. 关键架构决策

20. 参考资料

21. 最终建议

agent-architecture-evolution-strategy.md 57 KB

Trvalý odkaz Historie Surový