编排框架分析与优化

入口

用户表达诉求后，主代理判定意图：

统一流程

1. 明确意图 — 按入口表判定，模糊则追问
2. 收集证据 — a) 读取当前代码（src/core/）、agent 定义（assets/agents/）、skill 定义（assets/skills/）、治理原则（AGENTS.md），提取约束清单 b) 有 sessionID 时，按 reference/session-evidence.md 分派子代理收集 session 证据
3. 分析 — 按意图执行对应分析方法
4. 方案复核 — 分派独立子代理交叉验证方案合理性、治理原则遵循、完整性。违规则回退
5. 输出报告 — 纯段落，不落盘 5.5 确认与收尾 — 向用户展示报告摘要，询问是否实施改进项。不实施则总结关键发现并结束。实施则以报告改进项清单+用户确认为交接载体，进入步骤 6。
6. 实施 — 按 reference/implementation.md 编排实施流水线。完成后按 implementation.md 完成输出格式展示结果。

分析方法

5-Why 根因分析

从问题表象逐层追问"为什么"，每层基于事实（文件内容、约束清单）。最终落点必须是系统性根因——skill 某章节描述不清、agent 指令缺乏约束力、工具校验有漏洞、阶段缺少退出条件。不落个案操作失误。根因指向文件须读对应章节交叉验证。

现状-差距-方案分析

1. 理解优化动机（复述确认，模糊则追问）
2. 现状分析（基于已读文件的当前实现）
3. 目标状态（基于动机描述期望状态）
4. 差距识别（按维度拆解 gap）
5. 推荐方案（改动范围 + 影响评估 + 风险权衡）

方案复核

拟定建议后、输出前执行：

1. 建议 + AGENTS.md 治理原则 + 用户反馈打包
2. 分派全新子代理
3. 复核：方案合理性、治理原则遵循、完整性
4. 通过→输出；违规→回退

输出格式

## 编排<会话分析|优化项分析>报告
<**Session**: <ID> — 有 session 时出现>

### N. <问题简述>
#### 根因                        ← 问题诊断用
<结论>

#### 现状与差距                  ← 改进优化用
<结论>

#### 方案
<改动意图（含文件路径和章节/行号）>

约束

• 分析阶段不修改文件；实施阶段仅子代理改文件，主代理不得直接改
• 改进建议必须指名具体文件路径和章节/行号
• 5-Why 必须落到系统性根因
• 有 sessionID 时 session 证据收集必须由子代理执行，主代理禁止直接执行导出脚本或读取 session JSON
• 工具逻辑以源码为准，但声明式行为与运行时行为可能有差异
• 每个优化项的方案必须分别说明后端会话与前端会话下的影响：同一份改动在 backend 会话与 frontend 会话中是否都生效、差异在哪（如按栈分组的必做清单在两端命中项不同、skill 在两端是否被加载、视图与门禁在两端是否同口径），以及各自需要改动的落点。只写单栈结论、把某一种会话的形态当通用方案，视为分析未完成

技术栈影响评估

框架面向前后端两种会话，同一处改动常只在一种会话下生效。评估影响时按下面的顺序逐项过，不要从某一种会话的实现直接推广：

1. 该改动落在共用层还是栈专属层：workflow 配置、工具逻辑、agent 定义在两种会话共用；skill 的 stacks/frameworks 声明、按栈分组的必做清单只在命中的会话生效
2. backend 会话下的表现：命中哪些 skill、必做清单实际展开成哪几项、视图与门禁给出的要求是什么
3. frontend 会话下的表现：同上逐项对照，指出与 backend 的差异项
4. 各自要改的落点：两端都需要改的，分别列出文件与章节；只在单端生效的，说明另一端的等价物是什么、是否同样需要调整

评估结论并入报告对应优化项的「方案」小节，不单开章节。

简洁输出原则

• 结论至上：只输出问题与方案，不展示分析过程。5-Why 只给根因结论，不给追问链条
• 扁平结构：不使用多层章节嵌套
• 引用不赘述