Fusion 运行时

Fusion Runtime 是定义驱动执行链路，不等同于默认聊天编排器。它的核心目标不是“持续对话”，而是按 definition version 的输入 / 输出合约跑一条可持久化、可治理、可复盘的执行图。

当前执行顺序

flowchart LR
  Ledger[queued FusionRun + persisted inputs] --> Load[load_definition]
  Load --> ValidateContract[validate_definition_contract]
  ValidateContract --> ValidateInputs[validate_run_inputs]
  ValidateInputs --> PersistInputs[persist_validated_inputs(no-op)]
  PersistInputs --> ResolveBindings[resolve_capability_bindings]
  ResolveBindings --> PrepareArtifacts[prepare_file_artifacts]
  PrepareArtifacts --> Retrieve[retrieve_context]
  Retrieve --> Prompt[build_prompt]
  Prompt --> Plan[plan_tool_usage]
  Plan --> Tools[invoke_tools]
  Tools --> Model[invoke_model]
  Model --> Normalize[normalize_outputs]
  Normalize --> ValidateOutputs[validate_outputs]
  ValidateOutputs --> PersistOutputs[persist_outputs]
  PersistOutputs --> Finalize[finalize_run]

每个阶段在做什么

1. 加载 definition version

运行时不是直接读 definition 草稿，而是加载 immutable version：

input_contract
output_contract
execution_policy
prompting_config
capability_bindings

这保证同一个 run 有可复现的定义快照。

2. 校验输入

Fusion V2 里输入校验分成两段：

enqueue 阶段：FusionRunService.create_run() 先校验 contract 与输入，并持久化 FusionRunInput
execution 阶段：runtime 再次基于 persisted inputs 做一致性校验，确保 worker 只依赖 ledger 真相

因此 persist_validated_inputs_node() 在 worker-led 路径里只保留兼容职责，不再是首次写库入口。

3. 解析 capability bindings

resolve_capability_bindings_node() 会把 definition 中的 binding 配置解析成运行时可执行能力。

当前支持的 binding 至少包括：

model
rag
mcp
storage
image_generation

而且这一步还会结合 persisted governance context 和关联 Agent 信息，而不是只看 definition 上写死的 JSON。

4. 文件准备与上下文获取

输入里如果有文件或图片，运行时会先准备 storage artifact；如果绑定了 RAG，则会在这里做 context retrieval。

这意味着 Fusion Runtime 不是“先全量拼 prompt 再说”，而是先把外部依赖解析成中间能力输入。

5. Prompt / Tool / Model

当前运行时会分开处理：

prompt 构建
tool usage planning
tool invocation
model invocation

这和聊天编排器类似地体现出“先规划再执行”的结构，但它的输入输出边界由 definition contract 决定。

6. 输出归一化与校验

模型输出不会直接作为最终结果返回，而是会经过：

normalize_output_candidate_list
output contract 校验
FusionRunOutput 持久化

这保证最终 run 输出是“对齐 output slots 的结构化结果”，而不是松散文本。

当前运行时的现实边界

这是定义驱动运行时，不等同于默认聊天编排器
现有老 Agent API 继续保留，两套运行时并存
某些 binding 可以继承关联 Agent 上已有的挂载配置
runtime 的主要单位是 run，不是长期 session
POST /agents/{agent_id}/fusion-runs 只创建 queued run；实际执行由 FusionRunWorkerService 的 dispatcher / supervisor 从 DB ledger claim
run ledger 现在显式持有 attempt_count、lease_token、last_attempt_started_at、worker_heartbeat_at
如果进程中断导致任务遗留在 queued / pending / running，supervisor 会按 worker_stale_seconds 回收并标记为 failed

为什么说它已经不是 demo 级功能

从当前实现看，Fusion Runtime 已经具备：

immutable version
governance context
persisted input / output
file artifact object key
capability binding resolution
output contract validation

这说明它已经是平台里的正式运行时之一，而不是原型区能力。

想改什么去哪里

想改图顺序

看 ai_service/fusion/infrastructure/runtime/graph.py

想改 binding 解析

看 resolve_capability_bindings_node() 和 ai_service/fusion/infrastructure/adapters/

想改 prompt 组装

看 ai_service/fusion/infrastructure/runtime/prompt_builder.py

想改输出结构

看：

ai_service/fusion/infrastructure/runtime/output_mapper.py
validate_output_payloads()

想改 run 持久化行为

看：

persist_validated_inputs_node()
persist_outputs_node()
ai_service/storage/model_domains/fusion.py
ai_service/fusion/infrastructure/workers/fusion_run_worker.py