24 KiB
24 KiB
子代理分工、模型分级路由与任务沙箱：调研与方案
状态：proposed（2026-10-10）；owner：weichen；方向来源：用户 2026-10-10 会话 （①充分利用子代理；②复杂任务用 dmxapi 的 Sonnet/Opus，常规任务用 MiniMax-M2.7-highspeed； ③记录并规划毫秒/亚秒级任务沙箱，暂不实现；④对「体感不如 codex/claude code/kimi」的判断）。 本文是这四件事的主记录；未经评审的部分一律为「待确认」，不因被记录而视为已批准。
依据级别：本机实测为 SELF（命令与输出见任务卡 evidence 与 §7 复现脚本）；外部资料为 一手页面抓取（访问日 2026-10-10，URL 在 §8）；推断明确标注「推断」。
0. 结论先行
- 方向对，落点要改。 子代理只在「读多写少、可并行、输出冗长」的环节净收益为正； 交付物的写作与关键决策保持单线程（单一写者）。把复杂任务整单交给 Claude，会把最贵、 最慢的模型放在 token 最多的工具循环里——A/B 里 opus-5-5 耗时约 4.7 倍、工具失败更多。 证据更支持按阶段/角色路由：Claude 只做 token 少、杠杆大的环节（复杂任务的规划简报、 终稿综合、独立核查），检索、阅读、抽取、跑 Python、排版留给 MiniMax。
- 「体感差」不能主要归因于 MiniMax。 同一模型换 harness 的分差与相邻代际换模型同量级 （MiniMax-M2.1 换 harness 差 7.0 分；同 harness 换成 Opus 4.5 差 3.9–7.4 分 [H11]）。 本机实测还发现两处直接拖累体感的协议层问题（§1.2），应先修再下结论。
- 「编造数字」更像模型属性，但可以用机制压住。 同 harness 下 7→0 支持这一点；但 24 个相关观测里「0 处」的 95% 置信上界约 12.5%，不足以宣称清零（§1.3）。数字溯源闸门 比换模型便宜，且两者可叠加。
- 沙箱：现在的需求表述里有三处需要修正（§4.1）——overlay 不是快照、快照只是把冲突 推迟到合并、「立即销毁」必须先留存审计材料。修正后，本机条件下 bwrap + 冻结基底 + overlay 能做到约 7ms 启动（实测），足够作为默认档；microVM 档只在需要更强隔离时启用。
1. 现状核实（SELF，2026-10-10）
1.1 已有能力（源码，backend 421fee8，其 deps/agent-native 3b92cb6）
| 能力 | 现状 | 位置 |
|---|---|---|
| 子代理委派 | 模型可调 delegate_task，参数 agent∈{general,explore,research,plan,verify,writer}、task、background；深度 1（子不能再派） |
internal/runtime/llm.go:310、internal/runtime/llm_direct.go:668、internal/runmgr/runmgr.go:1462 |
| 子代理模型 | 由画像 frontmatter 决定：writer 用 chat 档，其余 7 个用 lightweight 档；调用方不能指定模型 |
internal/prompts/library/agent-sub-*.md、internal/runtime/sub_loop.go:48 |
| 模型档位 | 只有两档：models.chat 与 models.lightweight（轻量档空则回落主档），另有 models.chat.fallbacks 回退链 |
internal/runtime/model.go:54,84、internal/settings/settings.go:73-84 |
| 评审/验证 | review_findings 并行 1–3 个审查子代理再逐条验证；验证子代理输出 VERDICT |
internal/runtime/llm.go:311、agent-sub-verify.md |
| LLM 协议 | 后端恒走 OpenAI chat 协议（openLLMClient 不设 Protocol）；内核已实现 Anthropic Messages 客户端（含 cache_control）但产品未接线 |
internal/runtime/llm.go:491、deps/agent-native/runtime/llm/anthropic.go |
| 工具并行 | 内核支持 ExecParallel，直连路径未设置 → 默认串行执行同一回合的多个工具调用 |
deps/agent-native/runtime/loop.go:203,596、internal/runtime/llm_direct.go:268 |
| 执行隔离 | EXT-16：run_shell/run_python 可选 bwrap 档（断网、只读根、tmpfs 遮蔽 /home /tmp、仅会话目录可写、ulimit、超时杀命名空间）；缺省 direct |
internal/tools/exec_backend.go |
1.2 本机实测发现的问题
| # | 发现 | 影响 | 证据 |
|---|---|---|---|
| F1 | 子代理结论被压成 160 字：直连路径 delegate_task 只把 res.Summary 回给父，而 Summary 是子代理全文的前 160 字（全文在 res.Text 里，被丢弃） |
子代理做完的检索/调研结论，父代理只看到开头一句；这与「上下文防火墙」的用法正好相反，也会诱发父代理凭摘要补细节 | llm_direct.go:697-700、runmgr.go finishChild（Summary = truncate(fullText, 160)） |
| F2 | MiniMax 思考内容混在正文流里：OpenAI 兼容流式接口默认把思考放进 content 的 <think> 块；后端在回合结束时才剥离 |
回合进行中前端收到的 message.delta 先是一大段思考原文，界面上「正文」区域先显示推理过程；思考计时也不准。官方提供 reasoning_split=true，实测开启后思考改走独立的 reasoning_content/reasoning_details 字段（3/3 次），TTFT 中位数 0.69s |
llm_direct.go:418-475；probe2 实测（§7） |
| F3 | sandbox 档下交付物生成跑不通：python-docx/openpyxl/python-pptx 装在 ~/.local，被 --tmpfs /home 遮蔽；run_python 描述里「缺失时 pip install --user」在断网档也失效 |
RDM 计划 G3-7 切 sandbox 时，docx/xlsx/pptx 生成会直接失败；EXT-16 的「docx 生成任务成功」验收用的是 printf 桩，未覆盖真实库 |
bench2/bench3 实测：EXT-16 同形参数下 import docx → ModuleNotFoundError；只读挂载依赖层后 import docx, openpyxl, pptx 成功 |
| F4 | Claude 走兼容协议丢能力：经 dmxapi/lmuai 的 OpenAI 兼容接口，4 个 Claude 型号都不返回思考字段；改走 dmxapi 的 /v1/messages 原生接口，第二次调用 cache_read_input_tokens=5043（缓存生效） |
A/B 中 Claude 一侧每步按全价重算前缀、没有思考回传——47 分钟的耗时与工具失败部分可归因于此（推断，需日志确认） | anthropic_probe 实测（§7） |
| F5 | 直连路径工具串行 | 模型一次发出多个独立检索时逐个等待；4 个被测模型都能在一个回合里给出 2 个并行 tool_calls | probe 实测（§7） |
1.3 A/B 数据的正确读法
内部 A/B（.task/model-ab/ab-opus.json 对 .task/phase05-eval/after-p5.json，4 任务 6 回合）：
MiniMax 编造数字 7、约 10 分钟、工具 97/失败 19；opus-5-5 编造 0、约 47 分钟、工具 99/失败 33。
- 样本小且相关：「0 处」的 95% 置信上界约 3/24≈12.5%（rule of three）[R39]，不能宣称清零。
- 两侧都不在最佳状态：Claude 一侧走兼容协议（F4）；MiniMax 一侧思考回传已实现
（
context.thinkReplay=auto，ctxasm.go:206），但流式分流有 F2 问题。 - 速度：公开测速两者相近（opus-5-5 约 96 t/s [H25]，M2.7-highspeed 官方约 100 TPS [H4]； 本机短文本实测 48.9 对 50.7 t/s），所以 4.7 倍耗时更可能来自思考量、步数、重试与无缓存（推断）。
- Vectara 有据摘要幻觉率 M2.7 12.9%、Opus 4.6 12.2%、Sonnet 4.6 10.6% [R40]：「读懂原文」差距 不大；差距更可能出在「缺数据时去猜」（推断）。
1.4 其余现状（补充核实，SELF）
- 评测：
eval/live是 go test（env：AGENT_EVAL_BASE实例地址、AGENT_EVAL_TASKS过滤、AGENT_EVAL_TURN_TIMEOUT），golden 任务 4 个（tasks.json）；A/B 工具eval/ab.go、switch.go。 - 打断/插话：有
CancelRun（停止按钮）与子代理中断续跑；没有「运行中用户输入排队、 当前工具结束后本轮送达」的 steering 队列（未找到实现）。 - 检查点：文件写入有改前快照日志（
runmgr/rewind.goNoteFileCheckpoint）。 - 直连路径声明 13 个工具；提示词库 base-* 共约 6.7KB（base-deliverables 5.2KB 最大）。
2. 子代理分工：证据与方案
2.1 证据要点（外部，来源见 §8）
- 有益面：广度优先检索（Anthropic 多智能体研究系统：主+子比单 Opus 高 90.2%，复杂查询 耗时最多降 90%，代价 token 约 15 倍 [R13]）；上下文防火墙——18 个模型都随输入变长退化 [R14]，子代理只回 1–2k token 摘要 [R17]；fresh-context 审阅（Devin Review 均 2 bug/PR， 58% 严重 [R20]）。
- 有害面：写入耦合（并行写手风格冲突，「多代理贡献智能、写入保持单线程」是当前可行解 [R19][R20]）；顺序任务 −39%~−70%、单代理基线 >45% 时加代理为负收益、无中心校验时误差 放大 17.2 倍 [R21]；Claude Code 官方也建议迭代密集/共享上下文/延迟敏感时留在主会话 [R1]。
- 契约：委派带目标/输出格式/工具面/边界/预算；回传浓缩结论 + 证据指针（文件/行）， 大产物落盘只回引用 [R13][R17]；限额：禁嵌套、并发 3–5、按复杂度分档 [R7][R13][R21]。
2.2 方案（增量，每项独立任务卡）
| # | 内容 | 验收（可判定） |
|---|---|---|
| D1 | 修 F1：delegate_task 回传改为「子代理全文（上限 4k 字）+ 超长落盘 subagent-result.txt 只回指针 + 工件摘要行」——内核 subagent.CapParentText 已有此语义（backend 侧没走它） |
eval/live 前后对照：父代理引用子代理结论的回合，其终稿中来自子代理的事实不再凭摘要补齐；单测覆盖超长截断 |
| D2 | 委派简报规范：delegate_task 描述与 base-method 提示补「简报四要素」（目标、输出格式、工具/来源边界、完成判据），禁止把大块原文粘进 task |
提示词 diff + eval/live 计划/委派质量指标不回退 |
| D3 | 并行工具执行：直连路径设置 ToolExecution=parallel（读类工具并发、写类串行的区分后续再议） |
同回合多工具调用 wall-time 下降（评测记录）；事件序号仍单调 |
| D4 | 证据账本子代理：research/explore 画像的输出格式改为「结论 + 原文引用（文件/页/行）+ source_id」，数字必须带 source_id 或 Python 计算 ID；终稿前由确定性校验拦截（接质量计划 P5 的事实一致性检查） | 编造数字在闸门处被拦且计数；子代理回传含引用率 100% |
| D5 | 角色×模型矩阵（依赖 §3 R2）：新增/调整画像的 model: 支持 claude-* 档；writer 保持 chat 档，新增 composer（终稿综合）与 planner-complex（复杂任务规划简报）画像走强模型档 |
画像 frontmatter 生效（SubagentSpec 解析）；评测 A3/A5 组可配置 |
边界：子代理深度维持 1（现状即禁嵌套）；并发上限维持产品侧 3；本方案不引入子代理间通信。
3. 模型分级路由：证据与方案
3.1 证据要点
- 整单路由不划算：我们的 A/B 中 opus-5-5 耗时约 4.7 倍、工具失败 33 vs 19；公开测速两者 相近（§1.3）。Devin Fusion 的教训：强模型当全程主控只降本 33%，且「判断即交付物」的难题 上掉分 [R30][R31]。
- 按阶段/角色路由有正证据：Sonnet 执行 + Opus 顾问 +2.7pp 且降本 11.9%；Haiku + Opus 顾问 在 BrowseComp 19.7%→41.2% [R32]；Aider「强规划+便宜编辑」$13.29 得 64.0% 胜 o1 单跑 $186.5 得 61.7% [R12]。反例也存在（BrowseComp-Plus 上弱编排+强子代理更好 [R21]）——放哪一层必须 实测，这正是 R3 实验的目的。
- 协议与缓存：Claude 经 OpenAI 兼容层不回思考、不支持缓存、忽略 strict（官方文档 [H37]， 本机 F4 实测缓存恢复）；缓存按 tools→system→messages 前缀匹配，中途改工具集会整缓存失效 [R35][R36] → 模型切换只应发生在阶段边界，每角色固定 system/tools 前缀。
3.2 方案
| # | 内容 | 验收 |
|---|---|---|
| R1 | Claude 原生协议接线：models.chat.protocol = openai-chat | anthropic（设置项），anthropic 时用内核现成的 llm/anthropic.go 客户端（base 指向 dmxapi /v1/messages 根），回传 thinking 块与 signature、挂 cache_control 断点、usage 记缓存读写（N3 计费拆分已有字段） |
同会话第二次调用 cache_read_input_tokens>0（SELF 复现 F4 的探针即验收集）；thinking 块原样回传（删改会 400 [H24]） |
| R2 | 角色路由表：设置新增 models.<role>（role∈composer/planner/verifier，缺省回落 chat 档）；画像 frontmatter model: <role或具体型号>。默认建议：chat=MiniMax-M2.7-highspeed（不变）、composer=claude-sonnet-5（dmxapi，原生协议）、verifier=异模型（deepseek-v4-flash 或 claude）、复杂任务 planner=claude。Opus 系列留给最难任务手动指定 |
角色解析链单测；models 列表来自各端点 /v1/models（已核实 dmxapi 有 sonnet-4-6/sonnet-5/opus-4-6/opus-5-5 等，见任务卡 evidence） |
| R3 | 路由 A/B 实验（扩展现有 eval/ab.go）：组别 A0 全 MiniMax / A2 MiniMax+数字闸门 / A3 A2+Claude 终稿 / A4 A2+Claude 核查 / A5 Claude 规划+终稿+核查、MiniMax 执行；关键组加 Sonnet 变体。指标：无来源数字占比、含编造交付物比例、pass^3、p50/p95 耗时、分角色成本（含缓存）、工具失败分类。样本：30–50 任务×3 次（宣称编造率<5% 需 ≥60 份零编造样本 [R39]）；<3pp 差异慎下结论 [R49] | 选型报告入任务卡，来源 GATE/SELF 标注 |
| R4 | 升级规则进 harness（不依赖模型自觉 [R20]）：连续 N 次工具失败、闸门拦截无来源数字、检索「未找到」三类事件触发 advisor 咨询或角色升级 | 评测中升级触发可观测；误升级率记录 |
运维事实（2026-10-10，SELF）：lmuai 月额度已耗尽（$1303.32/$1300，2026-11-05 重置）——R1/R3 的 Claude 侧建议先走 dmxapi（余额 ¥0.48，需充值，此前 A/B 卡估算全量对照 ¥50–100）。
4. 任务沙箱：记录与规划（不立即实现）
4.1 对原始思路的三处修正
- 「overlay 隔离他人变更」不成立：内核文档明确「下层在挂载期间被修改的行为是未定义的」 [S1]；本机实测运行中的沙箱能看到下层后续修改（bench2 第 5 段）。一致视图必须来自不可变 基底（冻结副本或 git commit 物化），而不是叠在活动目录上的 overlay。
- 快照只是把冲突推迟到合并：Codex cloud/container-use/Cursor 都以 diff/PR 回收，冲突在 写回时用基线校验暴露 [S23][S28][S26]。「互不影响」的成本是写回时的三方合并与人工兜底， 设计里必须显式包含这一步，否则快照只是把失败挪到了最后。
- 「立即销毁」与审计有张力：销毁的应是计算资源与可写层；转录、diff、工件哈希、环境 清单要按 TTL 封存（Codex 删前存快照 [S23]、container-use 留命令史 [S28]、Cursor 留工件 [S26]）。本仓的证据门禁（AGENTS.md）同样要求可复核输出——封存记录是硬约束。
另一处简化：硬链接克隆（cp -al）对「原子替换写入」是安全的（rename 换 inode），但对原地 写入会穿透（共享 inode）——本机实测（bench3 第 3 段）。只可作为「可检测」方案并配 sha256/mtime 清单复核，不可当作完整快照。
4.2 目标形态（任务工作区沙箱）
一次任务 = 冻结基底（会话/项目材料的不可变视图）+ 私有可写层 + 确定性依赖层 + 出口管控 + 回收（diff 与工件清单）+ 封存后销毁。智能体在其中任意折腾不破坏原始资料；产出经校验写回。
4.3 分层架构与延迟预算（本机实测，SELF）
| 层 | 机制 | 启动 | 适用 | 备注 |
|---|---|---|---|---|
| L0 进程沙箱 | bwrap（EXT-16 现状）+ 依赖层只读挂载 | p50 7.3ms（/bin/true，n=30）；带 overlay 同为 ~7ms | 默认：解释器执行、交付物生成 | 修 F3 后 python-docx 全链路可用（import 60ms、1 页 docx 76ms） |
| L0.5 工作区沙箱 | L0 + --overlay-src <冻结基底> --overlay <宿主upper> |
~7ms（实测） | 多任务并发、需要一致基底与可回收 diff 时 | upper 即增量；快照语义来自冻结基底而非 overlay |
| L1 容器 | docker（overlayfs 驱动） | run --rm p50 142ms（redis:7 true，n=10） |
依赖隔离更强、镜像化环境 | 可加 warm pool 压冷启动；单机自托管无障碍 |
| L2 microVM | Firecracker/gVisor | 未实测；E2B 等托管方当前文档只称 "fast Linux VM"（量化数字已不可得，未经证实） | 不可信代码、最强隔离 | 本机有 /dev/kvm；引入与维护成本高，暂缓 |
支撑件（与层正交）：
- 冻结基底：git 材料以 commit SHA 物化（同 SHA 只物化一次、多任务只读共享）；非 git 材料 用 cp -al + sha256 清单（写回前复核，变了即判基底失效）。git worktree add 实测 192 文件 11ms，overlay 直接盖工作树 ~10ms，两者都够快。
- 依赖层：项目 venv / site-packages 只读 bind（实测修复 F3；RDM 方案 §3.4 原有此意）。
- 数据库：SQLite 用
VACUUM INTO取一致快照 [S32]；PG 用零连接模板库克隆（PG18 XFS 上 有 CLONE，ext4 上是复制 [S11][S37]——量级以库大小为准，必要时评估独立 XFS 卷给 reflink）。 - 网络：默认无网（现状）；将来要放开时，按 sandbox-runtime 的形态做出口代理白名单 + 代理侧凭据注入（密钥不进沙箱）[S-RT]。
- 回收与写回：沙箱退出后读 upper → 生成
git diff --binary补丁 + 工件 sha256 清单； 写回用 CAS（目标当前哈希==基底哈希 → 原子替换；不等 →git merge-file三方合并，冲突停给 人）；写回前留前像。git 目标用update-ref <ref> <new> <old>（本身就是 CAS）[S46]。 - 封存：base SHA、补丁、工件哈希、转录指针、环境清单（依赖层版本）、退出码，按 TTL 留存 后销毁工作区目录。
4.4 与现网的关系
- EXT-16 sandbox 档是进程级隔离（单次命令）；本节是任务级工作区，两者叠加而非替代。
首个落地形态：ExecSpec 增加工作区概念，sandbox 档把「会话目录 bind」换成「冻结基底 overlay
- 私有 upper」。
- 已知缺口顺带记录：小队内核 ExecConfig、工作流 ScriptCommand 仍 direct（EXT-16 卡内遗留）； 沙箱档覆盖它们是前置条件之一。
4.5 非目标与开放问题
- 不做多租户硬隔离与 OS 级安全声明（沿用质量计划 §5 边界）。
- 开放：是否划独立 XFS 卷换 reflink；gVisor 试用；warm pool 是否值得（L0 已 7ms，大概率不值）； Windows/macOS 不在范围。
5. 分期与验收总表
| 增量 | 内容 | 依赖 | 备注 |
|---|---|---|---|
| E1（P0 快修）✅ | F1 委派回传、F2 reasoning_split、F5 并行工具、F3 依赖层 | 无 | 已完成（2026-10-10）：Agent-Native #42/#43/#44 + Backend #127 + Dev PR（任务卡 feature/agent-e1-parallel-fixes）。验证：F2 实测正文 0 泄漏、F3 sandbox 实测 IMPORTS-OK、F5 实测同回合并发重叠；eval 对照工具失败 19→11，未核实数字 7→12（E3 待做，见任务卡） |
| E2 | R1 Claude 原生协议 + 缓存观测 | E1（F2 同类协议改动可同批） | dmxapi 需充值 |
| E3 ✅ | D4 证据账本 + 数字闸门 | 无（接质量计划 P5） | 已完成（2026-10-10）：Backend #130、Dev #311（任务卡 feature/agent-e3-evidence-gate）。标注感知豁免（分句判定）+ 两轮修正（变化才二拦）+ base.deliverables v6 数字溯源规则 + 子代理引用格式；eval 对照未核实数字 12→5（未标注 3）、工具调用 93→63 |
| E4 ✅（R4+账本） | R2 角色路由 + D5 画像 | E2 | R4 与账本已完成（2026-10-11，MiniMax 版）：Backend #131–#134、Dev #315（任务卡 feature/agent-e4-escalation-ledger）——滑窗失败提醒（端到端日志实证）、检索空命中提醒、source_id 账本（83 标记）；Claude 角色档按模型指示暂缓；eval 四轮对照无恶化 |
| E5 ✅（R3 部分） | R3+R4 路由 A/B 与升级规则 | E2–E4 | R3 已完成（2026-10-10，MiniMax 家族版）：Dev #313（任务卡 feature/agent-e5-model-ab）三臂对照（hs / 全M3 / hs+M3轻量）——建议默认 chat=MiniMax-M3（未标注编造 1、失败最少、时长持平、单价减半）；R4 升级规则仍待做 |
| S0-1 ✅ | §4.4 首个落地形态：冻结基底 overlay + CAS 回收 + 变更摘要（--exec-workspace overlay） | 用户 2026-10-11「继续完成下一步」 | 已完成（2026-10-11）：Backend #135/#136、Dev #318（任务卡 feature/agent-s0-workspace-overlay）——bwrap 集成 3 + live 端到端（失败零落地/新增/修改/-ws 清理）；S0-2（fs 联合读/任务级工作区/封存）待授权 |
6. 与既有规划的关系
- 智能体工作流质量改进：本文是其「模型 A/B」 结论的后续与 P4/P5 的延伸（D4 与 P5 合流；E5 继承 A/B 方法论并扩大样本）。
- EXT 申请包 G1：E1-F3 修复其 sandbox 档的交付物 缺口；§4 工作区沙箱是 EXT-16 的演进方向。
- RDM 阶段总案：G3-7 切 sandbox 前置依赖 F3 修复。
- Agent 栈 N2 WP5（子代理/后台派生）：D1–D5 在产品层消费其内核端口，不改内核契约。
7. 本机实测的复现要点（SELF，脚本存于任务卡 evidence 同目录说明）
- 启动延迟：bwrap 命名空间 / +overlay / +持久 upper 各 30 次（bench.sh、bench2.sh §3）。
- F2：
reasoning_split=true前后各 3 次流式（probe2.py，观察 delta 字段分布）。 - F3：EXT-16 同形参数下
import docx失败 vs 只读挂载~/.local/.../site-packages后成功 （bench2 §1–2、bench3 §1–2）。 - F4：dmxapi
/v1/messages连续两次调用，第二次cache_read_input_tokens=5043。 - overlay 非快照：运行中沙箱读到下层并发修改（bench2 §5）；cp -al 对 rename 安全、对原地写 穿透（bench3 §3）。
- docker 冷启动 10 次（bench.sh）。
8. 来源（除标注 SELF 外均为 2026-10-10 抓取的一手页面）
- [S1] Linux 内核 overlayfs 文档：https://docs.kernel.org/filesystems/overlayfs.html
- [S11] BoringSQL instant database clones：https://boringsql.com/posts/instant-database-clones/
- [S23] Codex environments/git-worktrees：https://learn.chatgpt.com/docs/environments/git-worktrees
- [S26] Cursor cloud agent：https://cursor.com/docs/cloud-agent
- [S28] container-use CLI：https://container-use.com/cli-reference.md
- [S32] SQLite VACUUM INTO：https://www.sqlite.org/lang_vacuum.html
- [S37] PostgreSQL 18 release notes：https://www.postgresql.org/docs/release/18.0/
- [S46] git-update-ref：https://git-scm.com/docs/git-update-ref
- [S-RT] Anthropic sandbox-runtime（Linux=bwrap+seccomp、网络默认全拒+代理白名单+凭据注入、 Apache-2.0）：https://github.com/anthropics/sandbox-runtime
- [S-CX] Codex sandboxing（Linux 用 bwrap；read-only/workspace-write/danger-full-access）： https://learn.chatgpt.com/docs/sandboxing
- [H4] MiniMax 定价与速度：https://platform.minimax.io/docs/pricing/overview 、 https://platform.minimax.io/docs/guides/text-generation
- [H24] Claude thinking 块回传要求：https://platform.claude.com/docs/en/build-with-claude/extended-thinking
- [H25] Artificial Analysis（opus-5-5 96.4 t/s 等）：https://artificialanalysis.ai/models/claude-opus-5-5
- [H37] Claude OpenAI SDK 兼容层限制：https://platform.claude.com/docs/en/api/openai-sdk
- [R1][R12][R13][R14][R17][R19][R20][R21][R30][R31][R32][R35][R36][R39][R40][R49] 子代理与 路由调研来源清单见任务卡「调研来源」节（Claude Code docs、Anthropic/Cognition 工程博客、 arXiv 2512.08296 等，URL 全量随卡保存）。