代码提交

frontend-web/docs/microsoft-agent-framework-多智能体会商-实施计划.md

@@ -606,3 +606,40 @@ maf-roundtable/conversation/
 - 真实 UAT 写入系统、最小权限凭据、外部核验 API、补偿协议及生产 `MAF_ACTION_SECRET_KEY` 已按 Phase 5 前置条件完成。
 
 在这之前，任何“会话/run 原型页面通过构建或轮询测试”的结果，都只能算技术验证，不算产品升级验收。
+
+---
+
+## 阶段 3 实施记录（当前代码基线）
+
+本轮已补齐阶段 3 的服务端安全路由与真实 MAF Workflow 入口，范围仅针对新 MAF 会商；旧 DeerFlow、旧 roundtable 和 AI 写作行为不变。
+
+### 配置与入口闸门
+
+- 仓库默认 `maf_roundtable.enabled: false`。部署环境必须注入真实的 `default_manager_agent_id`、席位 ID 和业务路由后再开启，避免出现“入口显示正常但首条消息必然 503”的空配置。
+- 健康接口返回非敏感的 `conversation_dispatch_ready` 与 `conversation_dispatch_status`；新会商入口只有在配置路由可用且服务已启用时才开放。
+- 首条消息使用服务端可信能力快照校验 manager/seat 的可访问性；浏览器、会话请求和模型输出都不能提供或扩大 agent、thread、tool、capability 范围。
+- 配置模型会清理并校验 manager/seat ID，拒绝 manager 出现在 seat 列表、重复席位、超过 `max_seats_per_run` 的路由和非法业务 code。
+
+### 受约束的总控派活
+
+服务端先由业务链与可信 capability snapshot 生成候选席位集合。总控模型只能返回严格 JSON：`intent_type`、`selected_seat_agent_ids`、每席 `task_goal`/`delivery_requirements`、`execution_mode`、`convergence_path` 和 `reason`。Pydantic schema、服务端 allowlist 和顺序校验全部通过后，最终计划才会写入 checkpoint，并产生 `manager.dispatch` 审计/SSE 投影。
+
+非法席位、重复席位、空任务、错误 schema、席位超限、缺少收敛路径或链式顺序错误，统一回退到服务端安全计划，不会扩大权限或启动越权席位。
+
+四种结构化拓扑已固定为：
+
+- `direct_answer`：manager-only Workflow，不创建专家席位任务；
+- `single_seat` / `tool_write`：一个可信席位；
+- `parallel_consultation`：至少两个可信席位并行；
+- `chain_consultation`：按服务端业务链顺序串行。
+
+### 阶段 3 验证状态
+
+已覆盖配置校验、候选路由、非法总控计划回退、manager-only 真实 `WorkflowBuilder` 拓扑、线程/执行阶段回归、旧 DeerFlow 回归和会话 API 回归。当前仍不能据此标记整个 MAF 项目或阶段 5 为“验收完成”；真实 UAT 写入系统、最小权限凭据、外部核验 API、补偿协议和生产 `MAF_ACTION_SECRET_KEY` 仍按阶段 5/8 前置条件保持阻塞。
+
+### Stage 3 P0 dispatch correction
+
+- New MAF conversations no longer classify user text with server keyword rules. The server first freezes only the business-route candidate set and trusted, redacted capability summary; `ManagerDispatchExecutor` then returns the strict intent-and-dispatch JSON contract.
+- The final plan is Pydantic-validated and allowlisted before it is checkpointed. Invalid JSON, illegal intent or seat, missing convergence, manager failure, and timeout all finish on the clarification branch; they do not create expert threads or start expert/tool work.
+- A conversation initially persists and binds the manager only. After a valid decision, only `selected_seat_agent_ids` are added to the participant store and receive internal threads.
+- Every non-clarification route, including `group_chat`, starts at the same manager dispatch node. Group speakers are limited to the verified selected seats; static candidate configuration cannot bypass the plan.