games-development-ai/.agents/skills/agentic-seat-context-design.md

name, description

name	description
agentic-seat-context-design	设计或评审生成运行时的 agent 席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面时使用——需求基线 + 设计检查单(设席八问/注入五查/场景四要素)+ 第一人称需求探针方法(§10);非架构 SoT。

agentic 席位与 context 工程设计 —— 生成运行时多 agent 设计的需求基线

性质与来源:2026-07-05 创始人八轮问答驱动的"模型第一人称需求探索"——让生成运行时里实际干活的 LLM 回答"你需要什么才能把游戏做好、做大、改得动",本文是收敛蒸馏。定位 = 需求基线 + 设计检查单,不是架构 SoT:运行时架构唯一 SoT 见 agentic运行时架构图说.md;据此做具体设计仍走 feature-design-doc.md 产设计档 + SoT 注册表申报 + 双评审;文中标〔提案〕的机制未经实现验证,落地前逐条核实。 适用:设计/改造生成运行时的席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面;评审这类设计时拿 §8 检查单当尺子。 配套:AgentScope 2.0.2 机制速查 agentscope-2.0-facts.md;prompt 文本的版本化/eval 治理 prompt-governance.md(分工:本文管"谁在哪个座位拿到什么",它管"prompt 文本自身怎么管");九门与真玩 game-e2e-cdp-harness.md;质量口径 游戏质量与爆火能力.md;遥测回流 数据飞轮.md。

0. 总则:席位分的是结构,不是能力

所有席位背后是同一类 LLM,多 agent 设计因此不是能力分工,是结构分工。一个"席位" = prompt 配方 + context 配方 + 工具面 + harness 策略的版本化组合,整组落在配置控制面(AgentScope per-POST 装配:改配置,下一次生成即生效,零重启)。

分席四判据(至少满足其一才配新席位):

1. context 食谱本质不同——要广度 / 要深度 / 要刻意致盲;
2. 写权限必须互斥——并行工单的白名单不相交;
3. 验证独立性——做的和查的绝不能同席("出题的 ≠ 被考的"这条九门纪律的席位版);
4. 生命周期不同——常驻有状态 vs 按工单生灭。

两条不设席戒律:判定可确定化 → 做成门(产模型辩不过的事实;封装形态可为 MCP 工具——现状九门 = CDP harness driver + middleware 重跑 run_gates,MCP 化是主张非现状);调度可确定化 → 做成代码(队列 + workflow)。LLM 席位只放不可归约的判断。健康自检:席位数不随游戏复杂度增长,涨的只该是工单数与门数。

1. 四层结构与边界律

层	只装什么	绝不装什么	变更节奏	AgentScope 落位
prompt(席位宪法)	身份与协议:职责宪章、禁区、输出工件 schema、升级协议、判断性红线	项目事实、工单内容、可门化/可模板化的规范	低频;每改 = 配置版本 + 评审	/agent 配置的 prompt 部分;文本生命周期归 prompt-governance
context(本次投影)	事实与任务:工单六要素、冷启动简报、承重件(契约/验收/坑清单)、省略目录(未注入但可检索项的清单)、出处戳(来源/新鲜度/性质)	聊天历史回放、其他席位的推理过程	每 POST 从控制面现装配	投影编译 = 控制面自建能力(框架现成件只是 AgentRecord 的 context_config);配方进控制面版本化
environment(工作台)	能力与边界:workspace(worktree + 写白名单)、工具/MCP 白名单、按需热装 skills、预算态	与本工单无关的工具 schema	按工单类型	toolkit/session 注册 + workspace + 配额
harness(流程壳)	过程控制:门判拦 finish、续修环、软预算档位、journal 写前意图、离场清账、升级事件、盲评隔离、投喂记 trace	业务判断(不替模型想,只兜过程与验证)	随平台演进	middleware 洋葱 + MCP 门 + 队列协议

**边界律一句话:身份进 prompt,事实进 context,能力进 environment,过程进 harness。**串层即设计错误,四个典型味道:项目事实写死在 prompt(僵化+配置漂移);身份协议塞进 context(每次重复付 token);用 prompt 劝模型别越权(该收 environment 白名单);指望模型自觉跑门(该进 harness 强制)。

工具面三则:

• 能力边界优于自律:制作人席不给代码工具,范围失控在根上被断;评审席只读 + 门;数值席只有仿真器 + 数据表。
• 工具诱导行为:无关工具 schema 既是注意力污染也是行为歪引(有 shell 就想用 shell)。
• 语义化窄工具优于万能工具:给 snapshot() / checkout_baseline() / replay_intent(),不给裸 git——不变量在工具层强制,模型调不出违规操作。

**规范注入铁律:模板承载 > 门强制 > prompt 提醒。**能烤进脚手架的规范零边际 token 且直接塑形输出(reskin write_whitelist 实证);能确定化的做门,违规被拦而不是被劝;只有判断性规范才配占 prompt。可运营指标:prompt 里的规范条数应单调递减——每条都该在排队迁往模板或门,赖着不走的就是技术债。

2. 席位表

常驻席(每项目一套,有状态;状态活在账本,不活在会话):

席位	吃什么	产什么	工具面
制作人席	功能台账、遥测摘要、决策日志、用户消息+现场快照	工单、三档确认、版本决策提案	台账/遥测查询、工单铸造;无代码工具
主设计席〔提案〕	系统契约、数据 schema、决策史	规格增量、验收标准、契约版本	契约注册表读写、schema 工具
数值仿真席〔提案〕	数据表、仿真器输出、真实遥测曲线	平衡判定、调参工单	快进仿真器、数据表编辑;无代码写
馆长席〔提案〕	journal 流、坑清单增量、配方与 SoT	蒸馏并入、索引更新、配方↔SoT 对账	知识库读写、对账门

工单席(按单生灭,无状态,可并行):

席位	吃什么	产什么	工具面
实现席 ×N	单系统契约 + 白名单文件 + 品类坑清单	交付包(commit + 自测证据 + journal)	白名单内写、build/test、契约查询
内容席	数据表 schema + 样例	过校验器的数据表	表编辑 + 校验器;便宜档模型即可
资产席	资产清单、风格锚、包体预算	素材 + 元数据(尺寸/锚点)	素材生成/管理;无逻辑写
评审席(盲)	规格 + 工件 + 证据,不见实现过程	判定书	只读 + 九门(现状经 harness/middleware 调用,可封 MCP)
玩家席	persona play-spec + 可玩预览	体验报告(FTUE 卡点/手感)	真玩 driver;上线后被真实遥测校准

不设席清单(代码/工具,不是 agent):调度排队(RocketMQ + 控制面)、九门、快进仿真器、兼容检查器、契约测试、语义版本操作、docs-gate 式对账。修复也不设席——RepairMiddleware 是实现席的会话内环。

已有胚胎 → 缺口对照(设计时先认领胚胎,别平地起楼):

席位/机制	已有胚胎(已落地)	缺口
制作人席	A11 调整回路两段式(判意图→计划→前端确认→执行)	分诊矩阵、三档确认策略、用户现场快照
实现席	cheap-worker / tier2 worker + RepairMiddleware + write_whitelist	工单化收窄、journal 协议
评审席	gate_judge middleware + 九门	独立 fresh 会话化、判定书 schema
玩家席	九门真玩 driver + play-spec	persona 化、体验报告 schema
配方版本化	配置控制面(yudao 版本层 + per-POST 热装配)	context 配方、工具面、skills 纳入同一治理
投喂可观测	生成线 trace 已闭合(jsonl 主路;便宜档 OTLP sink 波③已通、默认关)	把"每次装配了什么 context"记进 span
主设计席 / 数值仿真席 / 馆长席、九类工件 schema、版本卡 / 意图重放 / 兼容检查器	无	全新建〔提案〕

同源风险(所有席位同一 LLM,盲评只解决"被带节奏",解决不了"想不到同一处")三缓解,按有效性排:① 工具事实优先——把尽可能多的判定压进确定性工具;② 异档模型当多样性来源——关键评审席换不同家族/档位的模型(子代理成本分档的意外红利);③ 同席多镜头——正确性/契约/回归各跑一趟 fresh context。

3. 通信:星形账本中心,九类工件,禁自由对话

席位之间不存在 live 群聊;一切通信 = 从项目存储拉工件 + 向队列发工件。三个理由:可中断(对话中断即死,工件队列天然可续)、可审计(每件进 trace,"它当时知道什么"可回放)、防污染(盲评与类型化交接的前提就是不共享会话)。这也贴 AgentScope 现实:Service /chat 是 per-POST 的 fire-and-forget 触发(结果走 SSE 事件流),session 是单席位状态,不是聊天室。席内要查事实走注册表工具,要扩范围发升级事件,不去"找别的席聊"。

九类工件(全部带 schema + 出处戳〔来源 commit / 时间 / 性质:事实|推断|假设〕):

工件	方向	要点
工单	制作人 → 各席	六要素:目标/范围白名单/验收/预算/依赖/升级策略
规格增量	主设计 → 实现/内容	契约变更提案 + 版本 bump + 迁移注记
交付包	实现 → 评审	commit hash + 自测证据 + journal 条目(hash 必须真实可 rev-parse,防谎报 DONE)
证据包	门/driver → 评审/版本卡	九门测量值、仿真结果、截图、真玩轨迹
判定书	评审 → 制作人	过/不过 + 测量值 + 可行动的失败现场(不许只给门名)
升级事件	任意席 → 制作人	raise_scope_change:原因 + 产品语言选项;发完干净收口,不悬挂等输入
版本卡〔提案〕	制作人 → 用户	基线 + 已应用意图集 + 证据包 + 兼容戳
回流工单	遥测 → 制作人	漏斗卡点/留存差 → 修复工单(数据飞轮的工单化出口)
蒸馏增量	各席 → 馆长	坑/经验条目,经查重并入,不直写知识库

4. context 装配六性质(注入怎么控)

1. 角色投影:推送只放承重件(契约/验收/坑清单),其余给省略目录("还存在这些,可用 X 检索")。不给省略目录,模型会把投喂当全世界,幻觉从此长出;全推,则回到浪费读轮的老路。
2. 刻意致盲:评审席的 context 配方里不含实现会话的存在;修复轮给"上一版代码 + 门失败证据",不给前任心路——继承推理等于继承盲区。
3. 单源编译:所有投影从同一 SoT 机器生成,禁止各席各抄一份(双写必漂移)。配方是代码,配方 bug 与代码 bug 同级:进控制面版本化,并配机器对账(配方引用的 SoT 命题还在不在、原文变没变)。反面判例 = "传导断裂":便宜档实现入口丢了 SoT 的"轻量≠简单"命题、留着误导措辞,agent 从局部线索重建出错误世界观,连栽数轮。
4. 出处戳:每块注入带来源/新鲜度/性质三戳。"三天前的构建状态"与"刚跑完的门结果"必须能被区别信任。
5. 回写分道 + 蒸馏守门:实现席只写 journal 与坑增量、评审席只写判定、规划席只写工单,谁都不直改账本正文;蒸馏物经馆长门(查重/并入/汰旧),否则积累的不是知识库是垃圾堆。
6. 投喂进 trace:每次会话记录"装配了什么配方、什么版本的哪些块"。坏结果才能归因(模型不行还是喂错了),配方改进才能 A/B("给坑清单 vs 不给,过门率差多少")——context 工程从玄学变成像 D11 权重一样可校准的对象。

镜像原则:配方密度随席位模型档位调——便宜模型席位零裁量、全铺开;贵模型席位给索引让它自拉。

5. 长项目操作系统(数十天、数千次改动、随时中断)

长项目里上下文窗口只是"一次工时的工作台",项目必须整个活在仓库与控制面里,每次 POST 只做投影。六件,全部不活在任何会话:

件	回答	要点
账本	现在在哪	版本线、在飞工单、门态;冷启动简报由它生成,禁聊天回放
工单	这次干什么	有界:目标/白名单/验收/预算;杀掉中途的席位损失有界
journal	中断了怎么接	写前意图 + 完成回执;恢复 = 对账 workspace vs 日志,不是考古 diff 猜前任
决策史	为什么不能乱动	防第 2000 次改动把第 300 次的深思设计当垃圾重构
版本线	在哪条线上	见下方版本语义
索引	去哪找	模块地图 + 归属索引,机器生成;工单进来先预取再干活

配套的离场清账协议:每工单收尾必回写账本更新 + 决策日志 + 坑增量,三样齐才算完——没有蒸馏的会话是一次性消耗(.agents/ 纪律下沉进每个游戏工程,由 harness 强制)。

版本语义(用户看时间线,模型看基线资格,谁都不看 git log):

• 版本卡 = 通过验收的工单产物(缩略图 + 一句人话变更 + 证据包);数千 commit 是模型的事,用户只见几十张卡。
• 基线资格机器戳:"从稳定版继续"解析为"证据全绿且线上指标不劣化的最近版本",不是最近一个 tag。
• live 线永不直碰:发布 = 审核门后指针切换,回退 = 指针回切,"改崩线上"在结构上不可能。
• 回退真雷是玩家存档不是代码:触碰持久化 schema 的工单强制登记数据版本;回退前兼容检查器自动判"新存档在旧版打不开",把选项翻成人话(迁移/重置/放弃)交用户。
• 分叉不做 merge,做意图重放:"把那版的宠物拿回来" = 按原工单(意图+验收)在当前基线重新实现、过同套验收。AI 重做一个功能足够便宜,合并冲突这个概念对零技能用户可以整个不存在。

6. 交互面(分诊、确认、goal-loop)

三档确认,可逆性替代确认(回退越便宜,需要事前确认的事越少):

• 档0 静默直做:参数级微调,进变更日志,一键可撤;
• 档1 做完给试玩(新功能默认档):确认的最好形式是玩预览版,不是读计划文字;
• 档2 先问再做,仅三类:不可逆(动线上存档/经济/付费)、贵(超预算/天数阈值)、与用户既往决定冲突(引决策史对质:"排行榜 V9 有过,你在 V11 让我去掉的,要加回来吗")。

模糊请求五步:① 现场快照先于追问(在玩哪版哪景、最近事件——"它太快了"的"它"九成是刚碰过的东西);② 模糊词落设计轴(主设计席维护"词→可调面"映射,数据驱动使"改简单"=参数提案而非代码重写);③ 遥测佐证纠偏(用户说三关难、数据说卡二关——给证据版判读,字面顺从最贵);④ 收敛按序:试玩变体 > 选择题 > 追问,永不出开放问答(零技能用户答不了"重力还是碰撞体积");⑤ 小步默认 + 判读入档(原话→判读→依据,积累该用户词典)。

场景注册表:交互场景清单本身是契约——每场景 = 意图类 + 路由席位 + 默认确认档 + 遥测埋点,登记进 contracts/(八类契约的延伸),分诊按它驱动,新场景显式增列,不在 prompt 里悄悄长(注册表真落 contracts/ 后,下方场景族清单迁过去、本节改指针,避免双写)。场景族:立项创作 / 修改(对象:资产·数值·内容·机制·meta × 动词:改增删调回退)/ 版本操作 / 目标委托 / 诊断咨询(只读即答,不铸工单)/ 运营变现(碰钱必档2)/ 素材管理 / 打断接管。

goal-loop 铁律:goal 必须先编译成可判定验收门 + 预算上限 + 里程碑节奏才许进 loop——编译不出验收门的 goal 永不终止;里程碑产版本卡供用户异步试玩;仅档2事项自动暂停挂决策点;交付判定 = 门全绿 + 证据包,绝不是模型自称完成;用户随时打断,当前工单跑完或干净中止(journal 收口),插单分诊重排,账本无损恢复。

7. 生成游戏工程规范(舰队尺度:无数游戏、长期代改)

单个工程的代码结构与红线 SoT = littlejs-game-dev.md(§1 代码结构、§7 受控面铁律),本节不复述,只提舰队尺度的增量——规范的目标函数是冷启动定向速度、机器可校验、局部可改、跨游戏同构,不是人类品味:

1. 千游一构的舰队含义:同拓扑/同入口/同 manifest 的价值在舰队运维——批量迁移、安全补丁、横向审计变机械活,模型永远不用"学"某个项目的布局;
2. 状态显式:存档 schema 带版本、全局状态单一登记处——回退与兼容检查器(§5)的地基;
3. 自描述:模块地图机器生成不手写;注释是写给下一个失忆的模型的信——写"为什么不能动",不写"这行在干嘛";
4. 回归单调增:每修一个 bug 沉淀一个门/测试进本工程——数千次改动的质量靠累积的门,不靠第 N 个席位的小心。

规范本身版本化:manifest 记"本工程生于规范 v3";旧游戏按出生规范维护,升规范 = 显式舰队工单——禁止顺手升级(最小改动红线的舰队形态)。契约先行与数据逻辑分离已是作业手册红线,此处只强调舰队含义:§6 模糊请求处理链("改简单"=参数提案)整个站在数据表化之上。

8. 设计检查单(后续设计/评审会话按此过)

新设一个席位,八问:存在理由命中分席四判据哪条?三件套配方(prompt/context/工具面)各是什么?进不进控制面版本化?对谁刻意致盲?回写哪条道?产出工件 schema 是什么?有没有可认领的已有胚胎(§2 对照表)?框架默认注入的能力面审计过、与白名单对账了吗(AgentScope Service 路 get_toolkit 无条件并入 15 件无条件框架默认工具〔六内建 + Planning×4 + ToolStop + Team×4;另 Schedule×4 仅 session 配 chat_model_config 时条件并入〕、旁路白名单——实测教训;纯库 CLI 路 = 自装 toolkit 无此并入,cheap Service 已双补丁封口、审计口径见北极星档 §2 注入面审计节)?

设计一次 context 注入,五查:承重件清单最小了吗?省略目录给了吗?出处三戳齐吗?配方↔SoT 有机器对账吗?token 密度与席位模型档位匹配吗?

设计一个交互场景,四要素:意图类、路由席位、默认确认档、遥测埋点——登记进场景注册表了吗?

任何"规范进 prompt"的提议,先问两遍:能进模板吗?能做门吗?都不能才许进 prompt,并挂"待迁出"标。

9. 来源与效力

2026-07-05 创始人八轮问答(单次生成信息面 → 复杂游戏差距 → 长项目操作系统 → 范围与版本控制 → 多 agent context 控制 → 席位划分与通信 → 工具/规范/场景清单 → 四层边界),对模型第一人称需求陈述的收敛蒸馏。效力:需求基线——做 agentic 设计时当尺子与检查单用;它不推翻任何既有 SoT 决策;〔提案〕机制(主设计席/数值仿真席/馆长席/九类工件 schema/版本卡/意图重放/兼容检查器)落设计档时须按 feature-design-doc.md 流程评审并逐条验证可行性。

10. 第一人称需求探针(方法附录,W-PROBE)

本文正文是一次探针的产物;本节固化方法本身,供新 agentic 子系统(审核台辅助/玩家 feed 推荐/回流环运营席/创作者对话席等)设计期复用。探针 = 创始人驱动最强可用模型,以「我就是该子系统里干活的 LLM」第一人称回答需要什么,产需求基线——设计期前置工序,产出永远是需求基线+检查单,不是架构 SoT;探针对象排期唯一登记处 = MVP 作战清单 W-PROBE 单(本节不维护清单,防双写)。

问题序列模板(八轮推进逻辑,按子系统代入;轮间改向由创始人驱动、不可省——本次实践约一半信息密度来自人的追问改向):

1. 单次任务信息面:完成一次 X,你希望获得什么信息/能力?——摸清最小工作单元的需求;
2. 最复杂标的差距:这些够你做出〈本域最复杂标的〉吗?——用北极星级负载逼出单次视角的缺口;
3. 长周期规模化:项目持续数十天/随时中断再续/数千次操作/多版本交付,你需要什么?——逼出操作系统级需求(账本/journal/决策史);
4. 范围与版本:用户不感知工程现状、中途提新需求,范围怎么控?如何回退/签出历史版本再开新功能?——逼出确认策略与版本语义;
5. 多 agent context:多 agent 都用你当 LLM 时,你希望怎么控制各 agent 拿到的 context?——逼出装配性质(投影/致盲/出处);
6. 席位与通信:如何划分 agent、各管什么、之间通信和交付什么?——逼出分席判据与工件类型;
7. 工具/规范/场景:各席工具面(tools/MCP/skills)差异?模糊请求怎么办?舰队级代码规范?交互场景清单?——逼出 environment 面与交互契约;
8. 结构与边界收口:context/environment/harness/prompt 各自结构与边界?——逼出四层边界律,收敛成可落档结构。

收敛判据:新一轮回答不再产生新的需求类(只在细化既有类)即收敛;每轮末由创始人判断改向或加压(换更极端负载/加约束)。

固化格式:蒸馏为「需求基线+设计检查单」单文件——总则判据/结构表/检查单三件必有;未经实现验证的机制统一标〔提案〕;末节写明来源与效力(不推翻既有 SoT,落地走 feature-design 流程逐条验证);已有胚胎逐项认领(参照 §2 对照表的做法),别让基线平地起楼。

交接契约:下游设计档(feature-design)必须逐条消费基线条目并留「采/改/弃+理由」——基线是输入不是结论;设计档评审按 §8 检查单过尺(protocol §2.3);首次复用跑通「探针→基线→设计档」全链后,按真跑发现回修本节。