runtime-contract §3.3：拉起触发链标为「提案待确认」，不冻结（Refs #16）

回应 HM 复审（#16）：§3.3 此前把「AM 拉起（HM 触发）」写成已定论超前了——该触发链
（谁调 AM、何时拉起、agent 池由谁提供）尚未与 AM(@azgy)/HM(@zsbgnw12) 敲定。本次：
- 顶部加冻结状态说明：env 字段清单已稳定，触发链未冻结、待确认。
- 澄清 §1「派发」= 指派给已连入 agent，非编排器拉 pod（§1 与 §3.3 不矛盾，但都未定义拉起方）。
- 把拉起流程明确标为「提案」：去中心化下无 per-run agent 清单；agent 为 per-user 常驻池，
  由 HM 触发 AM 拉起（AM 无批量接口则 HM 循环调模板 POST /agents）。

仅文档。Refs #16

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/integration/runtime-contract.md

@@ -58,9 +58,13 @@ create 响应 `data`：`deployment_id`、`runtime_deployment_id`、`manager_depl
 
 ### 3.3 蜂群专家 agent 拉起环境契约（agent launch env，回应 agent_swarm#16）
 
-**关键拓扑事实**：编排器（swarm runtime）**不拉起 agent、无 AM 客户端、不持有模型 key**。专家 agent 是**外部进程主动出站**连编排器 WS（`/ws/{agent_id}`，见 §5/security-boundary §6）。因此 agent pod 由 **Agent 平台（AM）拉起**（由 HM 触发，与模板 Agent 同构：HM `mintAgentModelToken` → 经 AM 注入 env），模型 key 全程 **HM→AM**，**不经编排器 create 请求体**（满足 §3.1「请求体不得含明文密钥」）。
+> **冻结状态**：下表的 **env 字段清单本身已稳定**（`agent/main.py` 实读，无异议）；但**「拉起触发链」（谁调 AM、何时拉起、agent 池由谁提供）仍为提案，待 @azgy(AM) + @zsbgnw12(HM) 确认**（见 #16），**未冻结**。在触发链敲定前，本节按「env 契约已定、触发流程待定」对待。
 
-AM 拉起每个蜂群专家 agent 时，**必须注入以下进程环境变量**（本仓 `agent/main.py` 实读，为接线清单）：
+**关键拓扑事实**：编排器（swarm runtime）**不拉起 agent、无 AM 客户端、不持有模型 key**。专家 agent 是**外部进程主动出站**连编排器 WS（`/ws/{agent_id}`，见 §5/security-boundary §6）。注意 §1「分解→派发→执行」里的「派发」= 把任务指派给**已连入**的 agent，**不是**编排器拉起 agent pod——§1 与本节不矛盾，但二者都未定义「谁拉起 pod」（即 #16 的缺口）。
+
+**拉起触发链（提案，待确认，见 #16）**：去中心化模型下编排器只播种单一种子任务、agent 自选+自主分解，**无「按 run 分解算出 agent 数/角色」这一步**；故 agent 是**按用户的常驻池**（能力多样），**由 HM 触发 AM 拉起**（HM 持 per-user `sk-` + 已有 AM 客户端；若 AM 无批量接口则 HM 循环调模板 `POST /agents`）。模型 key 全程 **HM→AM**，**不经编排器 create 请求体**（满足 §3.1）。`ORCHESTRATOR_URL` 为部署期常量，由 HM 注入。
+
+AM 拉起每个蜂群专家 agent 时，**须注入以下进程环境变量**（本仓 `agent/main.py` 实读，为接线清单——此部分无异议）：
 
 | env | 含义 | 来源 |
 |---|---|---|