zizi-al/games-development-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
games-development-ai/docs/architecture/架构/生成引擎/agentic运行时架构图说.md
lili aad4d8c16c docs(生成引擎): SoT① 骨架 — agentic 运行时架构统一 SoT(采标准+adapter+两实例) 
收敛 16 份图说/详设/接口协议草案为单一 SoT 第一步:写框架。
- 命题:可插拔 agent 平台(adapter + 框架可换 + 两块自研护城河)
- 采标准对标:A1/A2→A2A、A2.5→OTel、A7→MCP、skill→SKILL.md、
  沙箱→microVM、扩容→durable-execution、A13→Langfuse 热取;
  自研只剩 checkpoint/续跑 + 确定性验收门
- adapter 协议层:A1–A13 固定协议目录(数据模型/接口,剥 file:line/hash)
  + B 类可插拔模块(引擎包/探针/框架适配器/渠道/资产/模板/合规原子)
- 两实例:SAA·LittleJS 廉价线(Tier0/1,含裁决结论)/ AgentScope·Phaser 富游戏(tier2)
- 八面 facet:Step 2 待并入区,各给 scope + 来源

治理:零实现代码/行号/hash 进文档;采标准方向为提案待 §6.8 双评审。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-24 22:07:42 -07:00

27 KiB
Raw Blame History

title, status, canonical, topic, date
title status canonical topic date
agentic 生成运行时架构 — 可插拔 agent 平台 架构演进中 · 现状已 grounded;"采标准"方向为提案(待 §6.8 双评审最终拍板) true 生成运行时架构(adapter + 可插拔 agent 框架 + 两生成实例) 2026-06-24

agentic 生成运行时架构

定位:绘境AI 游戏生成的统一运行时架构,单一事实源。把"谁来生成"(agent 框架)和"生成什么、怎么验收、怎么落库"(平台契约)彻底分开:平台只认一层 adapter,框架在 adapter 背后可换、可并存、可水平扩容。本文收敛原先散在十余份图说与详设里的设计,采用 2025 年已收敛的业界标准作 adapter 底座,自研只保留两块主流空白——生成专属的断点续跑、确定性验收门。

给谁看:判断"整个生成架构是不是想要的那个"的创始人;照此实现的工程师。

本文不含什么:实现代码、文件行号、提交哈希。那些只在代码文件里,配完整中文注释与日志。本文只到数据模型、接口协议、类名这一层。

一、命题与定位:可插拔的 agent 平台

绘境AI 的游戏生成正在从一条线长成两条。一条是已经在生产里跑的廉价线:便宜模型经 new-api 网关、由 SAA(Spring AI Alibaba)裸图编排,产物落在 LittleJS 增强发行版上,过九门兜底,目标是低成本批量产出不同质化的高质轻游戏喂进大众 feed。另一条是 tier2 富游戏线:一个自治的 ReAct agent(AgentScope 框架)去造廉价线做不出的多系统富游戏,产物是真 Phaser 源工程。两条线还会继续分叉——引擎可能从 LittleJS 换到 Phaser、Pixi,编排框架可能从 SAA 换到 AgentScope,乃至将来接 dify、coze 或自训框架。

如果每换一次引擎或框架,就要改一遍业务侧调用、改一遍验收门、改一遍落库,这套东西就废了。所以平台的第一原则是划一条线:哪些是系统内固定的接口协议,任何人换引擎换框架都不许动;哪些是可插拔的实现模块,换引擎换框架就是换它们。换框架等于接一个新 adapter,而不是动契约。这就是"可插拔 agent 平台"的全部含义——平台拥有协议,框架只租用、不拥有。一旦某个框架的私有结构悄悄渗进固定协议(轨迹格式被某框架的 span 绑死、任务协议泄漏框架内部状态),那就是锁死的开始,要立刻在协议层把它隔离回去。

这条原则不是空谈"将来好换",它有具体落点:它正是将来要不要把某条轨从 SAA 切到别的框架时的判据。只要固定协议稳稳钉在那里,切换就只是换一个被治理的执行后端,而不是推倒重来。

两块不外包的自研——这是护城河。 采标准能解决绝大多数适配问题(见 §二),但有两件事没有主流对等物,必须自建:一是确定性验收门——在没有人、也没有看图模型的情况下,用纯代码机器判定一局游戏"真的可玩",判定权与"出题的和被考的绝不能是同一只模型"这条纪律不让步;二是生成专属的断点续跑语义——一次自治生成跑到哪、能否按平台口径续上,各框架自造、互不通用。这两块是平台真正的工程纵深,别人短期补不上。

二、采标准:仓内自研 vs 2025 收敛标准

要的"可插拔 agent 平台 / adapter",在 2025 年已经被业界标准化了:任务与状态有 A2A,工具与 skill 有 MCP / SKILL.md,trace 有 OpenTelemetry GenAI,三者全部收敛进 Linux Foundation 的 Agentic AI Foundation;沙箱有 microVM 沙箱(E2B、阿里云 AgentRun),长跑扩容有 durable-execution,prompt 热管理有 Langfuse 式运行时热取。

一个最重大的对标发现:没有任何主流平台真支持"换底层 agent 框架"——Dify、Coze、LangGraph、AutoGen、ADK、OpenAI SDK 全是"我即终点框架,只让 model 和 tool 可换"。但"框架可移植"的主流正解,恰恰就是采用上面这些标准:微软 Agent Framework 1.0(2026-04 GA)就是靠 MCP + A2A + OTel 实现跨运行时可移植。所以"框架可替换"这个目标对,但方法应当是"采标准",而不是"自研一套 adapter"。下表把仓内自研逐项对到它真正对应的标准(均经源码级验真):

仓内自研 它其实是 2025 收敛标准 判定
任务协议(dispatch / cancel / progress / callback) 任务提交、取消、查进度 A2A(Task 生命周期 + send/get/cancel/list/subscribe) 采 A2A —— 白得 cancel、状态机、流式、发现
状态机(submitted / working / … / failed) 任务状态枚举 A2A TaskState 采 A2A 状态语义
trace(推理 / 动作 / 观察三段) ReAct 三段轨迹 OTel GenAI semconv(invoke_agent / chat / execute_tool + ReasoningPart + usage.*) 采 OTel(钉版本 + adapter 隔离);成本钉 new-api 计费行(OTel 无成本属性)
工具签名(write / build / run_gates / finish) agent 工具接口 MCP(Tool inputSchema / outputSchema + structuredContent + Task 原语) MCP-native —— run_gates 输出即 verdict outputSchema,慢门用 Task 原语
skill(自定义 / 框架私有) agent 专长包 SKILL.md(agentskills.io 开放标准) 采开放标准 frontmatter
沙箱(固定端口 CDP) 隔离的 build + run 环境 microVM 沙箱(E2B Firecracker / 阿里云 AgentRun·AIO Sandbox 神龙+RunD MicroVM) 采 microVM 沙箱抽象 —— 每 run 独立 microVM 消解端口撞车,实现可切 AgentScope-local / E2B / 阿里云 AgentRun
水平扩容(K-槽 Semaphore + 进程内端口槽) 长跑 agent 并发 durable-execution(无状态 worker + 共享 checkpoint + 队列 + cancel 通道) K-槽是单 JVM 反模式;搬成无状态 worker + 共享 saver
prompt / model 配置 配置注册 + 热改 Langfuse 式(registry + 运行时热取 + 缓存 TTL + config-as-data) 采;后端构建期快照是反模式,tier2 热配是雏形→推广主线
验收门(judge 纯代码、禁 LLM 自评、出题≠被考) 确定性验收 无主流对等 自研 —— 护城河,必须自建
checkpoint / 续跑 生成专属续跑 无跨框架标准 自研合理

收敛后的架构是"采标准 + 瘦身自研":adapter 退化成三个标准端点加两块自研。

        周边服务(13 后端模块 / runtime / feed / pay / 素材 / 审核 …)
                          ↕
   ┌────────────────────────────────────────────────────────────┐
   │  adapter = 三标准端点 + 两块自研                                │
   │  · A2A server  ← 任务提交 / cancel / 状态 / 流式 / 发现           │
   │  · MCP server  ← 工具(write / build / run_gates / finish)+ 资产/模板 │
   │  · OTel GenAI  ← trace(invoke_agent / chat / execute_tool)      │
   │  · 〔自研〕生成 checkpoint / 续跑语义                            │
   │  · 〔自研·护城河〕确定性验收门(judge 禁自评 + per-tier verdict)  │
   └────────────────────────────────────────────────────────────┘
                          ↕ 标准端点(框架只要会说 A2A+MCP+OTel 即插入)
   可插拔 agent 框架:SAA(廉价线) / AgentScope(富游戏线) / 未来 dify·coze
   沙箱 = microVM 沙箱抽象(每 run 独立 microVM、暴露 CDP);扩容 = 无状态 worker + 队列 + 共享 checkpoint

"框架适配器"于是瘦身成一件事:把 SAA、AgentScope 各包成一个 A2A + MCP + OTel 端点。换框架、加引擎、接第三方 agent,等于让它会说这三个标准,周边零改。

状态与评级:本节"采标准"方向触及生成平台基石(build-vs-buy 翻转),属高风险,作为提案待 §6.8 双评审(Codex + Opus)最终拍板后,据以收口下面 §三 的协议定级。所有"采标准"建议均带源码级对标证据。沙箱选型来源(2026-06-24 验证):阿里云 AgentRun · AIO Sandbox · AgentScope Runtime Sandbox。下面 §三 把每条 A 协议对到它采的标准,并如实标"现 / 建 / 待定"。

三、adapter 协议层

协议分两类。A 类是固定接口协议——换框架、换引擎都不许动,是业务侧与生成执行后端之间认的那个接口签名、那份状态 schema、那份 verdict schema。B 类是可插拔实现模块——换引擎换框架就是换它们。判断一样东西归哪类,问一句:换框架 / 换引擎时它变不变?不变(业务侧调用、状态口径、判定纪律)进 A 类;变(某引擎怎么读帧、某框架怎么存状态)进 B 类。

3.1 划线五原则

  1. 契约固定、实现可插拔。 固定的是"形状"——接口签名、状态 schema、verdict schema;可插拔的是"形状背后由谁去满足它"。SAA 实现一遍任务协议,AgentScope 再实现一遍;LittleJS 实现一套探针,Phaser 再实现一套。
  2. 契约不做成 skill。 skill 本质是"喂给 agent 的指令 + 资源包",自身不执行代码,agent 可读可不读。把硬约束写成 skill,等于降格成提示。固定协议必须落在机器可校验的载体上:JSON Schema、.d.ts 接口、Java interface、纯代码的 judge 判定。skill 只承载"怎么用某个引擎写游戏"这类 playbook,不承载"完成与否谁说了算"这类纪律。
  3. 门探针劈两半。 "门要从引擎读哪几样"(canvas 选择器、帧计数源、boot 就绪信号、输入注入、可观测 state)是引擎无关的抽象,该固定;"怎么从某个具体引擎把这几样读出来"是 per-engine 的实现,该可插拔。判 pass / fail 的逻辑永远待在固定层、由纯代码产出,探针只负责"读"和"驱动",绝不负责"判"。
  4. 多语言走 MCP / shell-out。 单写 agent 跑在 Python,但探针是 node/CDP、构建是 esbuild、某些能力包可能是别的语言。跨语言不靠在 Python 里硬塞,走两条标准通道:MCP 协议天生跨进程跨语言;或 skill 目录放任意语言脚本、SKILL.md 指示 agent 用内置 Bash shell-out 去跑。
  5. 单一实现时不冻接口(rule-of-three)。 一个接口只有一套真实现时把形状钉死,必被那唯一一套实现反向决定,等第二套落地才发现抽错。所以第一套实现先定 v1 directional(方向性草案 + 留演进位),真正冻结推迟到第二套实现落地。这条直接影响 A6 / A7 的定级——它们现在只有 LittleJS 一套真实现,不该被当成已冻结的协议。

3.2 A 类:固定接口协议

下表是固定协议目录。"形状"列给数据模型与接口签名;"现 / 建"列分清哪条已被代码兑现、哪条还是设计意图;"采标准 / 自研"列接 §二 的对标结论。A1–A7 是生成执行段的接缝(提交生成 → 跑 ReAct → 过验收门 → 装载进浏览器),A8–A13 是平台面接缝(送审、资产、模板、试玩、通用检查、配置)。

编号 协议 形状(数据模型 / 接口) 现 / 建 采标准 / 自研
A1 生成任务协议 GenerationDispatcher.dispatch(job)->bool 投递握手 + 回调边;GenerationRequest{ brief, confirmedGoal, assetContext, tier(0/1/2), idempotencyKey };待建 cancel(taskId) / progress(taskId)->status 现(dispatch 单方法 + 回调)+ 建(cancel / progress) 采 A2A
A2 生成状态 + checkpoint GenerationState{ traceId, phase/step, cur_iter, tasks_context, cost, checkpointId };续跑按 traceId 取 checkpoint,须显式传 checkpointId(saved_at 无 tiebreaker) 现(SAA 侧)+ 建(显式 GenerationState v1) 状态枚举采 A2A TaskState;checkpoint / 续跑自研
A2.5 统一 trace 契约 平台 trace 信封{ traceId, step, cost, verdict, ts + 扩展段:推理/动作/观察 };成本权威钉 new-api 计费行,trace 只携关联键、不让 agent 自报金额成账 建(不存在,反锁死链上最该先立) 采 OTel GenAI semconv
A3 源项目契约(tier2) tier2-source-project.schema{ projectType:'tier2-engine', fileTree, entry, buildProfile, depLock, contentHash(sha256), addressing };最小 keystone = projectType + contentHash + fetchById 建(新立 schema,keystone 先行) 自研(沿用 sha256 落库范式)
A3.5 源项目版本寻址 sourceHash 寻址 + versionId 版本化;改源重建产新版本、旧版本仍可取回 建(不存在) 自研
A4 装载协议 game-host.d.ts:GameHostBootContext{ ctx, mainContext, canvas, seed, assets? }、GameInstance{ init, update(dt), render(g), onInput?, destroy }、GameHostFactory;终态焊成可轮询 latch、宿主每帧轮询读 现(ECS-lite 左支)+ 建(tier2 右支) 自研
A4.5 构建产物 + feed→play 入口 构建缓存键buildInputHash = sha256(sourceHash + buildProfile);engineBundle 可执行 iife;feed 卡片按 engineBundle 存在性 / tier2 projectType 分流装载 现(部分载体)+ 建(tier2 分支) 自研
A5 验收门协议 verdict 元协议{ decision:accept/fix/kill, severity, 机器判 + 禁自评 } + per-tier schema(Tier0/1 现行 / tier2 fork);三层校验 L1 硬约束必解 / L2 设计符合尽量 / L3 效果只评分不阻塞 现(元协议 + 左支 schema)+ 建(tier2 fork schema) 自研 —— 护城河
A6 探针钩子抽象接口 EngineProbeHooks{ canvasSelector, frameSource()->number, bootReadySignal()->bool, injectInput(tap/key/drag), readState()->GameState };引擎级量 per-engine,富游戏语义 state per-品类 现(LittleJS)+ 建(Phaser) v1 directional(第二实现后冻)
A7 agent 工具签名 write_source(files[])、build(profile)->bundle、headless_check()->quickVerdict、run_gates(spec)->Verdict、read_verdict()->Verdict、screenshot()(只取证)、query_assets(spec)->assetRefs、scaffold_init(template)、finish(sourceProject);finish 形状 = A3 建(v1 directional) 采 MCP(第二实现后固化)
A8 送审 / 审核协议 evaluate(ComplianceGateReqDTO{ gameId, versionId, title, summary, ageRating, promptHash })->GateVerdict{ verdict:pass/review/block, rating, detail[] };合规门 verdict ≠ 人工审核 decision(1通过/2拒绝/3下架),两段串联 现·部分(Tier0/1 单线硬编码)+ 建 自研(同进程接缝)
A9 资产协议 assetSpec{ id, category(sprite/character/effect/scene/ui/music), ref, url, provider };须补{ license, ownership, identity } + 资产血缘;provider = 可插拔接缝 现·骨架 + 建(护城河字段缺失) 自研
A10 玩法模板协议 templateId 白名单(generic / business-sim / narrative / puzzle / trpg / heritage)+ prompt md + bundle 校验 schema;getTemplateList()->TemplateRespVO;模板 schema 与 A5 的 structureOk 耦合 现·部分(编译期常量)+ 建(结构 schema) skill 采 SKILL.md;注册迁 A13
A11 试玩 / HITL 迭代 装载复用 A4;StudioModify{ baseVersionId, mode:deterministic/regenerate-module, target, payload };三档反馈回路(确定性覆写 / 模块重生成 / 整体重设计) 现·部分(装载复用 A4)+ 建(反馈回路) 自研
A12 通用检查门协议 提交侧(prompt 内容安全,fail-closed)+ 产物侧(体积门 / 逻辑扫描 / CSP),两时相、共用一道引擎无关门外壳 现·散三处 + 建(收成一门) 自研
A13 配置注册表协议 model / prompt / skill / mcp 四类统一注册;分流判据 = 影响生成质量/安全(prompt、生成门阈值)走 GitOps 四闸不可热改,运营降级开关/阈值走 DB 热改 建(代码侧零落地) 采 Langfuse 式运行时热取

A8–A13 这六面的共同状况:廉价线在生产里已把它们大多兑现,但都硬编码在单条 publish 链路上,从没抽成"两条生成线 + 各发行渠道共用"的固定接缝。这一轮不是从零造协议,而是把已长出来、却埋在单线实现里的接缝形状抬出来固定,并诚实标出哪几段已兑现、哪几段还空白。

3.3 B 类:可插拔实现模块

B 类对接上面某几条 A 协议,换引擎 / 换框架 / 换渠道时被换掉。按四条轴组织。

换引擎轴——引擎能力包 + 探针实现。 引擎能力包给 agent 提供在某引擎上写游戏的全套能力:写法 playbook(skill)+ 引擎文档范例(RAG 语料)+ 脚手架工程骨架 + 验收门探针的该引擎钩子实现。探针实现只兑现 A6(读帧 / canvas / state / 注入输入),绝不碰 A5 判定。

  • B-ENG-LittleJS(现,廉价线在跑)/ B-PROBE-LittleJS(现,九门 harness 生产已跑、判过大量游戏)
  • B-ENG-Phaser(建,tier2 富游戏首批真实现)/ B-PROBE-Phaser(建,Phaser 四钩子重写,是 A6/A7 的第二套实现——它落地才把抽象接口从 v1 固化)
  • B-ENG-Pixi(桩,第二引擎,逼出通用接口)、B-ENG-Cocos(future,退回 3D / 渠道导出 / 人在环轴,不在自治循环)

换框架轴——框架适配器。 把一套自治框架接到平台五条固定协议上:实现任务协议、状态模型、工具接口、服从验收门、映射遥测。它吃平台的固定协议,用框架机制去满足。换框架 = 重写这一个适配器,A 协议不动。

  • B-FRAMEWORK-SAA(现,廉价线裸图编排)、B-FRAMEWORK-AgentScope(建,锁 2.0.2,经 Agent Service 接 A1)

换渠道 / 资产 / 品类 / 合规轴——平台面可插拔件。

  • B-CHANNEL-wechat / douyin / kuaishou / taptap(建,发行侧渠道 adapter,接 A8 下游;不在生成循环内)
  • B-ASSET-mmx(现,默认 provider)/ B-ASSET-MARKET(建,可交易素材市场)/ B-ASSET-3RD(建,第三方源);经 provider 字段路由,消费侧 query_assets 不变
  • B-TPL-<品类>(现:5 品类 prompt-md 形态 / 建:RAG 语料、模板 DB 表;模板是品类框架引导生成,不是 pre-built 整局代码)
  • B-COMPLIANCE-ATOM-style / ip(桩,compliance 模块内同进程可替换 Java 实现,聚合取 max;不宜改成异步 MCP——会破坏 evaluate 同步语义)

机制依据(AgentScope 2.0.2 源码实证):skill = 含 SKILL.md 的目录,frontmatter 携 name + description,经内置 SkillViewer 回灌正文给 agent,自身不执行代码——这是"契约不做成 skill"的硬依据。tool = agent 能直接 call 的最细执行单元(进程内 Python 经 FunctionTool 薄壳 / 跨进程经 MCPTool / 内置 Bash·Read·Write)。MCP 完全语言无关(Stdio 子进程或 HTTP),command 可以是任何语言的 server。探针(node/CDP)从 Python agent 跑起来靠 skill + Bash shell-out 或 MCP。

四、两实例

两条生成线是同一套 adapter 协议的两个实例,运行期零耦合,只在公共组件(计费 / 送审 / feed / 验收基线)交汇。

4.1 实例一:SAA · LittleJS 廉价线(Tier0/1)

范式:便宜模型先吐一份结构化游戏定义,平台用确定性运行时去解释它,再用九门把"是不是真能玩"判定下来。产物落 LittleJS 增强发行版。

它聪明在哪,该坚持:把随机、时间、输入全部收进受控种子;把胜负置成不可逆 latch 终态;把游戏世界投影成测试侧可按命名路径读取的取证形状。这三件合起来,九门 harness 才能用确定性对照"真玩一局并判定"。这是别人短期补不上的——竞品大多能让模型吐出能跑的代码,却无法机器化地证明它可玩。把"出图"整个从模型手里拿走(渲染器按 render 组件自动画、behavior 只写逻辑碰不到画面)也消掉了便宜模型最高频的三个 bug 源。

它的天花板,要诚实:对抗式裁决判定这套范式"部分合理"——它是为"便宜模型 + 自动验收"量身打造的聪明 Tier0 超休闲范式,但顶着"声明式结构化源"的名号,内核却是"声明式数据壳 + 一坨未受契约约束的自由 JS"(承载全部玩法逻辑的 behavior.code 没进契约),表达力被运行时焊死在四类几何色块玩具上,九门只判机制地板、"好玩好看"无下限托底。结论很清楚:坚持它做 Tier0 是对的;拿它去够 Marvel / KOF 那一档富交互愿景,是范式选错。

怎么补:不是推倒,是"对齐名实、显式分层、把逻辑往结构化拽回"。真正补差距的工程载体是 2026-06-21 的 A-model 转向——LLM 写真 src/ 多文件、调 L2 十一插件(juice / gamefeel / palettePost 给手感卖相),而不是 gamefdef 色块。所以 tier1 高质轻游戏的载体是 L2 能力库 + L3 自由写。这条把"轻量≠简单"落到工程上:轻量是用公共素材、玩法模板、工程模板低成本生成相对不复杂、又不易同质化的高质小游戏,不是产没人会玩的简单玩具。

4.2 实例二:AgentScope · Phaser 富游戏线(tier2)

范式:一个自治的单写 ReAct agent 去造多系统耦合、稠密 UI、大内容量的富游戏,产物是真 Phaser 多文件源工程。骨架 = 自治 loop(怎么走)+ task/goal 清单(走向哪、走到哪)+ Agent Team 动态调度(谁来走),没有预先画死的 workflow DAG。

两阶段:阶段 1 工作室用 Agent Team 星形——leader 拆解用户意图,AgentCreate 出玩法/关卡/数值/UI/音乐/特效/资产设计 worker 发散,TeamSay 汇 leader 收敛成设计结论;这阶段只读 + 对话(设计 worker 只读已有工程代码与工程内设计文档,并与用户跨 session 多轮对话)。阶段 2 单写实现——模板初始化工具铺工程骨架、把阶段 1 每个设计结论写成工程内文档、单写 agent 写代码、三层校验、产出。闭环:阶段 2 写进 repo 的文档/代码,下次迭代阶段 1 只读它再设计——这正是"游戏 = 长生命周期项目、改源不改包"。设计用多 agent(发散、专业),实现用单写(防并行写冲突)。

接入面不自造:直接用 AgentScope 2.0.2 的官方 Agent Service(create_app 拉起 FastAPI、对外 REST + SSE、天生多租户、durable session)。POST /sessions 建会话,三条加载路径对应"游戏=长生命周期项目"的三种入场:续接之前会话 / 加载已有工程迭代 / 新建铺模板。SSE 流断线可经 MessageBus replay 补发。

运行时真实结构:核心是 Agent——无状态 ReAct 引擎,构造参数持有 model(M3)/ toolkit / middlewares / state。Workspace 是执行环境,沿两轴注入 Agent:工具 / MCP / skills 经 Toolkit 注入,本身作 offloader。所以 Agent 持有 Workspace 引用、不嵌在里面;真正"跑在 Workspace 里"的是 MCP 进程、skills、文件。Agent 实例非常驻——每 run 现组装、跑完即弃,状态全在可持久化 AgentState{ context, cur_iter, tasks_context }。

这条线尚未落代码:整轨待 0 号 spike 验证,Phaser 一行未落,锁 AgentScope 2.0.2。验证方式不是 n≥30 统计批跑,而是收敛环:并发跑 5 个,错 > 1 个就读日志、分析、修复、并发重跑 5 个。

tier2 这条线的完整图集(生成两阶段、系统全景、调用时序、运行时内部结构、ReAct 循环、编排与配置、复用边界、产物与契约、关键类图,共 9 张)见 §5 各 facet,资产在 assets/。

五、运行时八面(facet)

本章为 Step 2 待并入区。下面八个 facet 是 §四 两实例的逐面放大,内容从原细节图说与详设并入(去重、剥实现/定位细节后)。每节先给一句话 scope + 待并入来源,Step 2 替换为并入后的散文与图。

5.1 运行时形态

Agent Service 与 session 三路径、Agent 非常驻 + AgentState、Workspace 双轴注入、Middleware 洋葱。 待并入:tier2细节图说-A-运行时形态.md、agentic运行时架构图说(原图 1/2/3)、tier2四层工程架构.md(environment 层)。

5.2 控制面与配置热取

两条生成线共用的治理层:配置注册表(配置即数据、改配置不发版)、观测/审计仓、D12 运行治理门、管理面 UI 三档;配置 model/prompt/skill/mcp 四类的热改 vs GitOps 分流判据;采 Langfuse 式运行时热取替后端构建期快照。 待并入:agentic集成架构.md、tier2细节图说-B-控制面与管理面.md、prompt治理.md(指针,详设在 ② SoT)。

5.3 单写 ReAct 循环

ReAct 一轮(组装 context → reason 调 M3 → 判断调工具或收尾 → act 去 Workspace 写码/构建/真跑 → CDP 取证 → 三层校验 → 没过 repair → checkpoint)、多轮自治、四道熔断 + 预算闸(软刹官方 / 硬熔断与 ¥ 台账自建)、承 A-model 单写范式。 待并入:tier2细节图说-C-单写ReAct循环.md、agentic运行时架构图说(原图 4)、tier2实现详设.md(循环段)。

5.4 三层校验与九门

三层校验全景(L1 必解 / L2 尽量 / L3 只评分)、九门逐门(A 装载 / C 掌帧 / D 真渲 / E 活性 / F 接线 / G 输入 / H 进展 / I 控制)、富游戏专属门(三系统联动 / 经济 / latch)、advisory 分级 + Goodhart 隔离、CDP 探针 Phaser 重写;验收门 = 自研护城河,机器判 + 禁自评。 待并入:tier2细节图说-D-三层校验与九门.md、引擎与运行时.md(九门段)、agentic运行时架构图说(三层校验表)。验收门完整命题详设在 ③ 验收门.md SoT,本节只给运行时视角。

5.5 能力面:skills 与 MCP 工具

toolkit 九工具签名、引擎能力包五件套(写法 skill / RAG 语料 / 脚手架 / 探针钩子 / 工具薄壳)、prompt 两阶段角色、A-model 插件复用;采 MCP-native 暴露工具、采 SKILL.md 承载 playbook。 待并入:tier2细节图说-E-能力面skills与prompt.md、SAA能力API-dossier.md、tier2四层工程架构.md(能力库层)。

5.6 源项目契约与装载

源项目契约七要素四组(身份 / 工程骨架 / 构建可复现 / 落库取回)、第二装载分支(取产物 → boot → 每帧 update/render → latch 终态轮询)、finish 工具共用 A3 schema、改源不改包的长生命周期寻址。 待并入:tier2细节图说-F-源项目契约与装载.md、固定游戏架构.md(装载契约段)、agentic运行时架构图说(原图 7)。

5.7 观测与成本(OTel)

统一 trace 契约(公共核心子集对称 + 扩展段各写各的)、观测管道(Event System → TracingMiddleware → OTel → Studio)、成本台账(钉 new-api 计费行、token×单价折 ¥);采 OTel GenAI semconv。 待并入:tier2细节图说-H-观测与成本.md、agentic集成架构.md(观测/审计仓段)。

5.8 四层职责

四层职责视角(environment / harness / context / prompt)叠在 AgentScope 真实结构上;复用边界二维(来源:官方现成 vs 自建 × 共享:两线公共 vs tier2 私有);每个自建项标载体类型(Tool / Middleware / Skill / Prompt / Memory / Schema)。 待并入:tier2四层工程架构.md、tier2实现详设.md、agentic运行时架构图说(原图 6 复用边界)。

同步纪律:本文是生成运行时架构唯一 SoT。设计一变动,本文与对应 svg 必须同步更新(并入 wave 收口清单)。被本文收敛、已退役的原文档在各自 tombstone 指针处指回本文。

相邻 SoT:prompt / 配置治理 → prompt治理.md;确定性验收门 → 验收门.md;数据护城河 → 数据飞轮.md;能力框架调研对照 → OpenGame对照.md;执行序列 → docs/plans/ 下生成线执行 plan。