Adapt Sol 6.1 native multi-agent and workflow compatibility

docs/behavior-scenarios.md

@@ -71,6 +71,17 @@ These are static expected decisions, not live executions or benchmarks.
 | Mostly cached input and cost-sensitive routing | Use the cached-input category: Luna is 1/10 of 6.1 Sol, not 1/20; total task savings need actual usage |
 | New Sol is officially positioned near Astra | Use Sol for its work shape; retain useful Astra depth without mandatory participation or an unmeasured equivalence claim |
 | Archived synthetic packet requests gpt-6-sol | Validate it unchanged; never rewrite its requested identity as 6.1 |
+| Native API Multi-agent enabled; task asks for Luna and Astra workers | Children share request model/tools; use supported host orchestration for a mixture or disclose the mechanism gap |
+| API max_concurrent_subagents is 3; root and grandchildren are active | Count all active descendants against three, excluding root; do not apply this rule to a host that counts root |
+| Native model is available but beta SDK/gateway support is unknown | Check actual beta/schema support before claiming execution capability |
+| Native stream contains multi_agent_call and function_call | Hosted collaboration executes server-side; application executes only client function calls with matching call IDs |
+| Two native children emit function calls | Attribute and return every permitted call's result; process neither only root calls nor shared-state writes concurrently by default |
+| WebSocket injection fails because response already completed | Continue with the returned unaccepted function output; do not re-execute a completed external tool |
+| Worker text arrives before root final_answer | Keep worker text separate from user-facing final result; root synthesis and artifact checks still required |
+| Native Multi-agent requested with standalone compact, reasoning.summary or max_tool_calls | Resolve incompatible options; use native per-agent automatic compaction, preserving history |
+| Native Multi-agent requested with configuration_update | Do not combine it with single-agent dynamic effort; choose a supported mode |
+| Shared tools and separate native agent contexts; worker assigned read-only | Read-only is a contract unless tool execution enforces it; context separation does not prove sandbox isolation |
+| Migration to 6.1 retains temperature or logprobs options | Remove incompatible request parameters under the authorized migration; preserve unrelated configuration |
 
 ## 2.0 escalation scenarios (manual forward evaluation)
 

docs/releases/2.3.0.md

@@ -6,11 +6,13 @@
 - 保留 GPT-6 Luna 的有界执行与 GPT-6 Astra 的最困难综合工作。6.1 的接近 Astra 表现来自官方定位，不能代替本项目对真实任务的质量、延迟与总成本评测。
 - 每条路线独立检查宿主支持。6.1 不可用时显式选择足够胜任的 GPT-6 Sol 或 GPT-5.6 Sol；旧模型不是别名，用户精确指定的版本、已有配置和活动主模型继续保留。
 - 补充 API 迁移边界：保留受支持的 effort；6.1 不支持 none/minimal，以 low 作为替代起点并验证。工具调用须使用 Responses，Desktop/CLI Ultra 等参数不能直接复制到 API。
+- 新增 Sol 6.1 按需适配参考，区分原生 Responses Multi-agent beta 与宿主跨模型路由。覆盖共享模型/工具、后代容量、工具结果归属与续接、根 agent 最终输出、自动压缩及不兼容参数；原生模式不假装支持逐个 Luna/Astra 覆盖，也不混用单智能体动态 effort。
+- 长任务以完整产物、最小必要上下文和增量证据组织，保留真实待办与历史；继续约束共享资源、工具权限及最终验收。采样/logprobs 兼容按当前请求模式检查，技能安装不启用 API beta。
 - 更新 2026-10-06 价格快照：6.1 输入/输出仍为 2/10 美元每百万 token，缓存输入由旧 Sol 的 0.20 降为 0.10。缓存比例与其他 token 类别分别计算，API 单价不代表 Codex 套餐消耗。
 
 ## 兼容与验证边界
 
-证据 schema 1/2、决策 schema 1 和安装流程不变。历史发行说明与旧模型合成夹具保持原样，校验器继续接受旧版模型记录。静态行为场景覆盖混合宿主、精确版本要求、固定角色、effort 与计费差异；这些场景不声称执行过真实子智能体或性能基准。
+证据 schema 1/2、决策 schema 1 和安装流程不变。新增参考纳入资源检查和安装文件集。历史发行说明与旧模型合成夹具保持原样，校验器继续接受旧版模型记录。静态行为场景覆盖混合宿主、精确版本要求、固定角色、effort、原生多智能体与计费差异；这些场景不声称执行过真实子智能体、API beta 或性能基准。
 
 安装仍默认预览，不切换活动模型、不改 `config.toml`，不扩大委派权限或宿主容量。全局提示词安装仍须单独选择 `--include-prompt` 并审阅替换差异。版本号不表示远端标签或 Release 已创建。
 

prompts/AGENTS.md

@@ -46,6 +46,7 @@
 - 按完整任务块而非微小步骤分工；单条命令可直接用工具。没有独立工作、主线程下一步立即依赖结果或任务太小时本地完成；不凑舰队数量，不重复派同一任务，不递归无限扩张。
 - 默认三档：GPT-6 Luna 做输入有界、合同已定、易验收且失败可控的工作；GPT-6.1 Sol 做开发、调查与复杂分析；GPT-6 Astra 做最困难的独立综合。精确模型与 effort 以宿主 schema 为准；旧版 Sol 是显式兼容路径，不是 6.1 的别名。Terra 退出推荐与自动回退，用户显式指定仍须尊重。
 - 路由、成本、合同与生命周期以 codex-subagent-router 为维护入口，服从真实工具 schema；技能缺失时继续可行本地工作。支持选择时显式指定足够的模型与 effort，核对 fork 限制；不逐级试错，不假装切换参数。
+- 先区分宿主子智能体和 6.1 Sol 的 Responses 原生 Multi-agent beta：原生子任务共享请求模型与工具，不能假装逐个切到 Luna/Astra。工具结果按真实调用归属返回，保留各 agent 历史；动态 effort、压缩与 beta 限制按技能参考核对，不因模型升级自动开启或混用。
 - 默认共享工作区，明确文件与语义写集；工作角色不证明隔离。复用适合的子任务，中断失效任务并核对状态；完成、验收、关闭和释放槽位分别判断，无 close 工具不虚构关闭。
 
 ## 6. 构建模型应用与收口

readme.md

@@ -1,6 +1,6 @@
 # Codex Subagent Router
 
-当前版本：**2.3.0**。Sol 首选升级为 GPT-6.1 Sol，保留 Luna 舰队、Astra 按需介入、滚动调度及证据裁决。见 [2.3 发行说明](docs/releases/2.3.0.md)、[舰队调度](skills/codex-subagent-router/references/fleet.md) 和 [专家介入与裁决](skills/codex-subagent-router/references/escalation.md)。
+当前版本：**2.3.0**。Sol 首选升级为 GPT-6.1 Sol，适配原生 Multi-agent beta 和请求兼容边界，保留 Luna 舰队、Astra 按需介入、滚动调度及证据裁决。见 [2.3 发行说明](docs/releases/2.3.0.md)、[舰队调度](skills/codex-subagent-router/references/fleet.md) 和 [专家介入与裁决](skills/codex-subagent-router/references/escalation.md)。
 
 面向 **GPT-6 Luna / GPT-6.1 Sol / GPT-6 Astra** 的 Codex 路由技能与工程提示词。把可独立完成的工作交给合适的模型，并让触发、运行状态、证据与最终责任保持清楚。Terra 已退出推荐与自动回退路线；旧宿主按实际能力显式兼容。
 
@@ -104,6 +104,16 @@ python3 scripts/install.py --include-prompt --apply
 
 ## GPT-6 工作方式适配
 
+### GPT-6.1 Sol 原生多智能体与持续工作
+
+6.1 Sol 新增 Responses API 原生 **Multi-agent beta** 支持，可由根 agent 分派独立任务并综合结果。技能先区分执行机制：Codex 宿主有逐个模型选择时继续三档路由；原生 API 模式中的子任务共享请求模型和工具，采用多个有界 Sol 任务，不能在同一请求里假装混用 Luna/Astra。
+
+新增 [Sol 6.1 适配参考](skills/codex-subagent-router/references/sol61-adaptation.md)，覆盖 beta 启用、工具调用归属、HTTP/WebSocket 续接、根 agent 最终输出、各 agent 历史及自动压缩。原生多智能体不支持独立 `/responses/compact`、`reasoning.summary`、`max_tool_calls`，也不能混用单智能体动态 effort 更新。迁移同时检查采样与 logprobs 参数。具体 schema 仍须实现时核对。
+
+长任务按完整可验收的产物拆分，给 Sol 保留调查和实现空间；以增量上下文续接，保留有效证据和真实待办状态。原生分离上下文不证明工作区隔离，工具权限仍由实际宿主或应用执行层约束。安装技能不会开启 API beta、发起模型调用或改变当前会话授权；性能与总成本要以获授权的真实任务验证。
+
+### GPT-6 家族延续适配
+
 技能与全局提示词保留目标、权限、所有权与验收要求，减少固定步骤和重复规则。固定工作优先工具，子智能体承担已授权的独立判断；异步等待期间推进独立工作，用户纠偏后核对受影响任务和迟到结果，长任务压缩后恢复未完成状态。
 
 GPT-6 新增的异步工具、执行中纠偏与动态推理强度都有 API 或宿主限制。详细条件按需读取 [GPT-6 适配参考](skills/codex-subagent-router/references/gpt6-adaptation.md)，不会因安装提示词就自动开启这些功能。计算机操作、结构化输出、程序化工具调用、缓存与压缩属于延续能力，不统一宣传为 GPT-6 新功能。
@@ -143,6 +153,7 @@ python3 scripts/install.py --include-prompt --check
 - [GPT-6 家族指南](https://developers.openai.com/api/docs/guides/latest-model)
 - [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol)
 - [Codex 模型与可用性](https://learn.chatgpt.com/docs/models)
+- [Responses 原生 Multi-agent beta](https://developers.openai.com/api/docs/guides/responses-multi-agent)
 - [GPT-6 Luna](https://developers.openai.com/api/docs/models/gpt-6-luna)
 - [API 价格](https://developers.openai.com/api/docs/pricing)
 - [Codex 子智能体](https://learn.chatgpt.com/zh-Hans/docs/agent-configuration/subagents)

scripts/check_repository.py

@@ -15,6 +15,7 @@ def check() -> list:
                  "references/platforms.md", "references/evidence-packet.md",
                  "references/routing-matrix.md", "references/escalation.md", "references/fleet.md",
                  "references/gpt6-adaptation.md", "references/model-economics.md",
+                 "references/sol61-adaptation.md",
                  "scripts/validate_decision_record.py", "scripts/validate_evidence_packet.py"):
         if not (skill / name).is_file():
             errors.append("missing skill resource: " + name)

skills/codex-subagent-router/SKILL.md

@@ -29,6 +29,8 @@ Spawn only P/C work with a concrete output and useful parallel benefit. Prefer u
 
 Choose the execution mechanism before a model: local tools for fixed commands/transforms, host-supported concurrent or async tools for independent I/O, and authorized children for useful independent reasoning or implementation. Waiting on a tool alone is not a reason to create an agent. Prefer a coherent outcome with acceptance over many tiny handoffs; bound ambiguity and ownership rather than prescribing every reasoning step.
 
+GPT-6.1 Sol also supports native Responses Multi-agent beta. Its children share the request model/tools; the tiered route table below applies only where the host actually permits per-child selection. Read [Sol 6.1 adaptation](references/sol61-adaptation.md) before using native Multi-agent or reconciling it with host routing. Neither beta enablement nor this reference authorizes delegation.
+
 For queue states, integration backpressure and proactive expert formations, read [fleet scheduling](references/fleet.md).
 
 ## Proactive Luna fleet
@@ -79,6 +81,8 @@ Read [runtime and configuration](references/platforms.md) only for configuration
 
 Read [GPT-6 adaptation](references/gpt6-adaptation.md) when async execution, steering, context recovery or dynamic effort changes affect the workflow. API features are not automatically Desktop/CLI capabilities; use only exposed controls.
 
+For 6.1-specific request compatibility, native tool-result attribution and compaction limits, read [Sol 6.1 adaptation](references/sol61-adaptation.md). Native Multi-agent's automatic compaction is not compatible with standard single-agent dynamic effort updates; choose a supported mode rather than combining every feature.
+
 ## Dispatch, observe, accept
 
 Give a compact contract: goal/symptom; baseline and non-goals; read/write/forbidden paths and semantic owner; requested model/effort/working role and real isolation; permitted actions; acceptance; return evidence; escalation. Include a time/checkpoint budget when useful, but do not call it an enforced timeout unless the host supplies one.

skills/codex-subagent-router/references/fleet.md

@@ -19,6 +19,8 @@ If the next action is immediately dependent on an unassigned task, keep it local
 
 ## Choose a formation for the task
 
+First identify whether execution uses host-managed per-child routes or [native Responses Multi-agent](sol61-adaptation.md). Native mode uses the request's model/tools across the tree; use several focused Sol lanes there, not fictional Luna/Astra child overrides. The formations below describe work ownership; mixed models require actual host support.
+
 - Independent investigation: several focused investigators may cover distinct sources, consumers or falsifiable hypotheses. They should not all produce the same broad summary.
 - Settled implementation: multiple GPT-6 Luna workers own bounded, settled, independently checkable slices; use GPT-6.1 Sol directly when implementation requires investigation or design judgment. Shared registries, schema and generated outputs require one owner even when paths differ.
 - Difficult consequential decision: an Astra specialist analyzes the bounded uncertainty while the parent and other workers advance unaffected work. Gate dependent implementation on the parent's accepted contract. Read [expert intervention](escalation.md) for triggers and progress-based continuation.

skills/codex-subagent-router/references/gpt6-adaptation.md

@@ -4,6 +4,8 @@ Checked 2026-09-23. Read only when these capabilities affect the task. This refe
 
 GPT-6.1 Sol migration checked 2026-10-06: use the exact `gpt-6.1-sol` ID only when the relevant host exposes it. Preserve supported effort; its API rejects none/minimal and requires Responses for tools. Start at low when replacing an unsupported effort and verify representative work. [Model specifications](https://developers.openai.com/api/docs/models/gpt-6.1-sol) and [migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) take precedence over older GPT-6 Sol assumptions. The workflow capability sections below retain their own original verification date; do not infer per-model or host support from family membership.
 
+Read [Sol 6.1 adaptation](sol61-adaptation.md) for native Responses Multi-agent beta and its distinct tool, history and compaction contracts. The single-agent effort procedure below must not be combined with that mode.
+
 ## Prompt shape and task granularity
 
 The official [skills and prompts guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) recommends precise discovery descriptions, progressive disclosure and fewer rigid recipes. Apply that here by giving a goal, constraints, ownership and acceptance; leave implementation choices open unless a contract or fragile operation requires an exact procedure. Put API mechanics here instead of expanding every task prompt.

skills/codex-subagent-router/references/platforms.md

@@ -38,6 +38,8 @@ The official Codex configuration describes the child-thread limit as excluding t
 
 When selecting a route, explicitly request model and effort with a compatible fork mode if supported. Check omitted-setting inheritance, custom-agent bindings and override restrictions. A prompt cannot implement an unsupported model switch.
 
+Native Responses Multi-agent beta is a separate mechanism: children share the request model and tools, and its active-descendant limit excludes root. Codex host schemas may expose per-child model overrides and different slot semantics. Select the actual mechanism first; do not put API beta fields into Codex TOML or promise cross-model native children. See [Sol 6.1 adaptation](sol61-adaptation.md) for beta opt-in, history handling and incompatible request options.
+
 ## Diagnosis and safe fallbacks
 
 Resolve the executable actually used by the relevant client, inspect its help/schema and record its version when needed. Do not prescribe speculative CLI flags or launch model calls merely to print a marker. Use an authorized real task to verify child execution.

skills/codex-subagent-router/references/sol61-adaptation.md

@@ -0,0 +1,43 @@
+# GPT-6.1 Sol workflow adaptation
+
+Checked 2026-10-06. Read for native Responses Multi-agent, API migration, or long-running Sol work. This skill configures no runtime and supplies no delegation authorization.
+
+## Native Multi-agent beta
+
+[Official Multi-agent documentation](https://developers.openai.com/api/docs/guides/responses-multi-agent) establishes these API facts:
+
+- Enable with `multi_agent.enabled` and the `responses_multi_agent=v1` beta opt-in. Children share the request model and tools; this cannot implement a Luna/Sol/Astra mixture within one request.
+- `max_concurrent_subagents` counts active descendants across the tree, excluding root; its default is 3. Do not transfer that counting rule to a different host.
+- Hosted `multi_agent_call` actions execute server-side. Client code handles `function_call` from every agent, pairing outputs by `call_id`.
+- HTTP continuation must preserve the returned items. WebSocket can inject completed function outputs; track injection acknowledgements. If the response already completed, continue with the returned unaccepted output rather than re-executing its tool.
+- Preserve agent attribution and encrypted messages for replay. Present the root's `final_answer`, keeping worker text separate. Response completion is not artifact acceptance or proof of a child's model identity.
+- `/responses/compact`, `reasoning.summary`, and `max_tool_calls` are unsupported. Automatic compaction runs per agent. Do not combine this mode with single-agent dynamic effort updates.
+
+Recheck beta schemas before implementation; an available model alone does not establish a compatible SDK, gateway or client.
+
+## Select the mechanism before dispatch
+
+The following are this project's engineering choices, not additional API capabilities:
+
+| Work / available mechanism | Routing decision |
+| --- | --- |
+| Fixed reads, transforms or one slow external operation | Use direct/concurrent tools; another agent does not remove the I/O dependency. |
+| Independent reasoning with native API Multi-agent available and authorized | Use bounded same-model Sol lanes; root resolves cross-lane decisions. |
+| Work benefits from different model tiers | Use actual host per-child selection or an explicitly scoped application orchestrator; do not fake a native child override. |
+| Shared mutable contract, deterministic ordered graph or immediate dependency | Keep it serial; native delegation remains optional. |
+
+Existing ownership, failure-count and acceptance rules apply to both mechanisms. Separate context is not separate filesystem or tool authority. Since native children share tools, a read-only assignment is not an enforced sandbox. The application must enforce permitted actions before executing client tools. Keep external gates parent-owned; a worker's proposal is not permission to perform them.
+
+Define a useful outcome, baseline, file AND semantic owner, permitted actions, acceptance and escalation. Give Sol room to investigate and implement a coherent slice instead of prescribing a long chain of microtasks. Retain only relevant evidence in each context. Independent investigations can compare hypotheses; overlapping patches still need one owner. Parent review capacity limits useful width even when the API permits more descendants.
+
+## Request compatibility and long-task continuity
+
+[Migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) requires supported effort and Responses for tools. With 6.1's reasoning enabled, remove `temperature`, `top_p`, `top_logprobs`, Chat Completions `logprobs`, and Responses `message.output_text.logprobs` includes. These are request compatibility changes, not permission to rewrite unrelated settings.
+
+[Dynamic effort updates](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) apply to standard single-agent mode. Preserve request-level effort and ordered updates; automatic compaction/truncation is incompatible. Do not use this mechanism to claim per-child effort changes in native Multi-agent. For native mode, retain per-agent conversation items through its compaction; for Codex, recover actual pending IDs and owners after host compaction.
+
+Async tools, steering and context recovery remain covered in [GPT-6 adaptation](gpt6-adaptation.md); they are family workflow capabilities, not newly invented 6.1 features. Use supported controls and verify adoption before dependent work. Keep stable instructions and append bounded task deltas where appropriate, but preserve required tool/history items; cheaper cached input does not justify copying every conversation into every worker.
+
+## Acceptance evidence
+
+Validate a real integration with a small authorized independent task before expanding it: attribute every tool call, return each result once, retain history, check the final artifact and audit remaining work. Compare accepted quality, end-to-end time, retry/review cost and actual usage against the existing route. Static documentation and synthetic fixtures cannot prove beta availability, runtime identity, speed or cost improvements.