Agent-System/docs/superpowers/specs/2026-09-09-longtask-governance-router-and-adhoc-design.md

长任务运行时治理、执行路由与自由任务体系设计（Task Runtime Governance & Router）

• 归档路径: docs/superpowers/specs/2026-09-09-longtask-governance-router-and-adhoc-design.md
• 编制日期: 2026-09-09
• 当前状态: 设计定稿待评审 (Draft for Review)
• 关联模块: internal/squad · internal/agent · internal/intent · internal/coordinator · internal/ctxmgr · internal/kb · pi-agent bridge · web/src

---

1. 背景与目标

系统当前已具备：模板化多步工作流（planner.go）、子沙箱隔离（WorkspaceEngine）、动态加步/跳步（evaluator.go）、终局质量门禁与自动修复（quality_gate.go）、黑板事实总线（blackboard.json）、分级权威上下文（context/）、SHA-256 防篡改清单（Manifest）、断点续跑（ResumeOrModifyWorkspace）、非标任务自主规划（planAutonomousAdhoc）。

但随着任务时长与自由度提升，暴露出六类治理缺口（任务拆解无契约、状态无状态机、调用无预算、重复无检测、验收无阶段化、上下文无治理），以及两类路由缺口（复杂自由任务被单轮对话消化、简单请求可能误启动小队）。

本设计目标：

1. 建立统一的长任务运行时治理内核（状态机 / 预算 / 轨迹 / 验收 / 归档），覆盖固定 workflow 任务与自由任务；
2. 建立"对话助手 ↔ 智能体小队"的执行路由层，让任务按交付形态与复杂度进入正确通道；
3. 建立自由任务（ad-hoc）的复杂度分级、目标澄清与契约化拆解体系；
4. 全程可观测、可审计、可标定，不引入外部工作流引擎，全部基于标准库与现有依赖实现。

2. 现状盘点（基于代码事实）

#	关注点	已有资产	关键缺口
1	任务拆解	StepSpec（Needs/Accept/SubWorkspace）、子沙箱物理隔离、evaluator 动态加步/跳步	Accept 为纯文案无机器校验；步骤完成无归档锁定（runOneStep 中 leader 预置 baseline 属隐式跨沙箱写）；无终止条件字段
2	状态机	docgov/state_machine.go 教科书级 FSM（状态+守卫+审计+锁定）	小队层无 FSM：step.Status/wf.Status 为裸字符串直接赋值（workflow.go L255 等），无迁移校验、无状态×操作白名单
3	调用阈值	limiter.go 并发信号量（默认 8）、AgentTimeout、质量修复 maxRetries=2	零调用计数；pi-agent 容器内 agent loop 对 Go 层为黑盒（bridge stdout 仅回 ok/fallback_reason/stderr）
4	重复识别	无	无轨迹记录、无重复/停滞/振荡检测；EnsureQualityOrRepair 同一缺陷可能机械空转（其 repair TASK.md 还硬编码指向 tasks/02_draft）
5	任务验收	终局三层校验+自动闭环修复、Manifest 防篡改、evaluator 步骤评估	仅终局格式校验，无中间产物验收、无主目标漂移检测、引用真实性未校验、修复循环无成本控制
6	上下文治理	分级权威上下文（引用式注入）、黑板总线、ctxmgr/decay.go 半衰期+里程碑豁免、dialogueHistoryMax=8 硬截断	中间产物无蒸馏归档；对话清理无语义过滤；黑板 Gaps/Assumptions 无生命周期
7	执行路由	意图类型→通道硬编码映射（CASUAL/AMBIGUOUS→对话 LLM；TRIGGER_TASK(7 标准任务)/ADVANCE_STAGE→小队；QUERY_*→模板）	单维映射无复杂度/交付形态维度；自由任务在对话中提出时坠入 AMBIGUOUS 被单轮硬答
8	自由任务	planAutonomousAdhoc（4 阶段流水线 + 关键词派生专家角色 + 自动模板）	拆解固定 4 步不随复杂度变化；无目标澄清协议；无契约化验收锚点；对话入口无法触发

3. 总体架构

用户输入
  │
  ▼
L1 意图识别 (intent.Recognizer，规则四级漏斗，保持不变)
  │
  ▼
L1.5 任务路由层 TaskRouter (新增，internal/coordinator/router.go)
  │   信号: 意图类型 × 任务画像(交付形态/复杂度/时效/预算档) × 会话状态
  │   输出: 通道判定 {DIALOGUE | SQUAD_FIXED | SQUAD_ADHOC | TEMPLATE}
  │         + confidence + reason + 升级建议(可选)
  ▼
L2 协调引擎 (coordinator.ProcessIntent，按通道分发)
  │
  ├─ DIALOGUE ──────→ 对话助手 (generateDialogueReply，单轮，现状不变)
  ├─ TEMPLATE ──────→ 模板/KB 直答 (现状不变)
  ├─ SQUAD_FIXED ───→ 标准任务小队 (bizdev.SupportedTasks，现状不变)
  └─ SQUAD_ADHOC ───→ 自由任务小队 (Task Brief → 契约化动态拆解)
        │
        ▼
   治理内核 TaskGov (internal/squad/gov/，挂在 WorkflowDriver)
     StepFSM │ BudgetLedger │ LoopDetector │ AcceptanceRunner │ Archiver
        │
        ├─ trace.jsonl   执行轨迹(重复检测/审计/阈值标定数据源)
        ├─ ledger.json   预算账本
        └─ manifest.json 步骤级防篡改指纹(扩展现有 Manifest)

设计原则：

• 沿用 docgov FSM 风格（显式状态 + 守卫 + 审计），不引入 Temporal 等外部引擎；
• 治理事件全部走现有 stream.EmitPhase / SSE 推给前端 PhaseEventStrip，可观测性不新造轮子；
• 所有新字段 omitempty 向后兼容，旧 workflow.json 可读入并自动升级；
• 阈值先测量后标定（观测 P95 × 2，软硬两级），不拍脑袋。

4. 任务路由层设计（TaskRouter）

4.1 问题陈述：两个今天已经存在的真实缺陷

现有分流是"意图类型 → 通道"的单维硬编码映射：

CASUAL_CHAT / AMBIGUOUS_FALLBACK ──→ 对话 LLM（单轮 pi-agent，3min）
TRIGGER_TASK(仅 7 个标准任务关键词) / ADVANCE_STAGE ──→ 小队（多步，30min）
QUERY_PROGRESS / QUERY_REGULATIONS 等 ──→ 模板/KB 直答

• 下行缺陷（质量损失）：用户在对话中提出复杂自由任务（例："帮我做一份掌上超声竞品横向对标，并给出 V0.5 阶段的定价策略建议"）。matchTriggerTask 只认"需求收集表/调研报告/报价单"等 7 个标准关键词，不命中 → 坠入 AMBIGUOUS_FALLBACK → 由单轮对话 LLM 硬答长任务 → 深度、结构化、可追溯性全部不足。该缺陷当前已存在，路由层是修复它，而非引入新风险。
• 上行缺陷（成本损失）：简单可单轮回答的请求若被误判为 TRIGGER_TASK → 启动整套小队（4+ 步 × pi-agent × 30min 预算）→ 慢且贵。

4.2 双维判定模型：意图类型 × 任务画像

路由不再是意图类型的单维函数，而是 语义维度（意图，已有）× 执行维度（任务画像，新增） 的二维判定：

// internal/coordinator/router.go
type TaskProfile struct {
    DeliverableForm string  // answer(对话答复) | document(受控文档产物) | data(结构化表格/多文件)
    ComplexityScore int     // 0-100，由确定性规则信号加权得出
    ComplexitySignals []string // 命中的复杂度信号（供 reason 展示）
    LatencyExpect   string  // immediate(用户在等) | background(可后台长跑)
    BudgetClass     string  // light(单次 LLM) | medium(多步小队) | heavy(多文档研究型)
}

type RouteDecision struct {
    Channel      string  // DIALOGUE | TEMPLATE | SQUAD_FIXED | SQUAD_ADHOC
    Confidence   float64
    Reason       string            // 人话理由，入 trace 可审计
    UpgradeHint  *UpgradeSuggestion // 仅 DIALOGUE 通道且画像偏重时携带
}

复杂度信号（确定性规则，可解释可测试）：

信号	加权	判定来源
明确交付物词（"报告/方案/文档/清单/对比表/核算"）	+30	关键词规则（扩展现有 matchTriggerTask 字典）
多对象/多维度（"对比 A 和 B"、"竞品+定价+风险"）	+20	连词与并列结构计数
需要外部检索（"查一下最新/检索/文献/标准号"）	+10	现有 searcher 角色特征词典复用
需要多角色视角（法规+工程+商务并提）	+15	角色特征词典命中数（复用 roles.go 特征字典）
材料依赖（"根据我上传的/结合附件"）	+10	会话材料状态
篇幅期望（"详尽/完整/成体系/立项级"）	+10	篇幅词
追问深化（同一主题第 N 轮且前轮已给出初答）	+15	会话轨迹（RecentDialogue）

4.3 判定流程：四级漏斗（对齐 L1 意图识别哲学）

R0 确定性路由表：意图类型 × 明确信号 → 通道（覆盖 ≥90% 流量）
   TRIGGER_TASK(标准7)/ADVANCE_STAGE          → SQUAD_FIXED   （现状，不变）
   CASUAL/AMBIGUOUS 且 ComplexityScore < 40    → DIALOGUE      （现状，不变）
   QUERY_PROGRESS/QUERY_REGULATIONS/SECURITY.. → TEMPLATE      （现状，不变）
R1 规则画像升级：CASUAL/AMBIGUOUS 但 ComplexityScore ≥ 60 且
   DeliverableForm ∈ {document, data}         → DIALOGUE + UpgradeHint
   （先给即时初答，同时挂"升级为小队任务"期望选项）
R2 低置信 LLM 仲裁：仅 R0/R1 判定分歧或信号矛盾时，调用对话 LLM 做一次
   结构化路由判定（输出 JSON：channel + confidence + reason）
   （与 L1 的规则优先、LLM 兜底哲学一致；失败回退 R0 默认）
R3 用户终审：升级必须经用户确认，系统永不擅自把对话切成长任务

4.4 升级通道：完全复用 PendingExpectation 机制（零新交互范式）

UpgradeSuggestion 不发明新 UI，直接构造 PendingExpectation：

{
  ExpectedIntent: IntentTriggerTask,        // 或新增 IntentTriggerAdhocTask
  TargetAction:   "launch_adhoc_task",
  ContextSnippet: "刚才我给出的初答覆盖了 X/Y 两个方面；升级为小队任务可获得：多角色交叉论证、受控文档与质量门禁、可追溯引用",
  DefaultOption: {OptionID: "1", Title: "升级为小队正式任务（预计 N 步，约 M 分钟）",
                  Intent: IntentTriggerAdhocTask, Slots: {task_brief: "<本轮对话提炼的任务简报>"}},
  Options: [
    {OptionID: "2", Title: "仅补充深化当前回答的某一方面", Intent: IntentCasualChat},
    {OptionID: "3", Title: "暂不升级", Intent: IntentDeclineExpectation},
  ],
  AllowAffirmative: true,
}

用户回复"好/1" → 走现有分支 1（EXPECTATION_HIT）极速兑现 → 创建自由任务工作区。与三分支意图消解、交互卡片、TTL 轮次消退机制天然融合。

4.5 对现有系统效果与执行质量的影响分析（防回归三原则）

用户关切"路由层是否会影响当前系统的效果和执行质量"，结论与保障：

1. 默认即现状（保守原则）：R0 确定性路由表与现有硬编码映射完全等价——不加路由层时走什么通道，加了之后依然走什么通道。路由层只新增一条路径（R1 升级建议），而升级建议本身也是"对话助手先给完整初答"（DIALOGUE 通道行为不变），只是追加一个期望选项。因此：已有效果（意图识别准确率、模板回复、对话 LLM 质量、标准小队任务）理论上零回归，回归测试按"通道判定黄金用例集"锁定。
2. 确定性优先（可解释原则）：路由判定 90%+ 流量由确定性规则完成（可单测、可解释、可审计），LLM 仲裁仅处理低置信分歧且失败自动回退默认——与 L1 规则漏斗同构，不会引入"路由玄学"。
3. 升级需确认 + 预算封顶（成本原则）：长任务通道切换必须用户确认；澄清阶段（Task Brief 协议，见 §5.2）设最大澄清轮数（默认 3 轮），防止"澄清无限聊"变相把 DIALOGUE 通道拖成长任务；升级后的任务进入 BudgetLedger 管控。

正向收益：修复下行缺陷（复杂任务不再被单轮硬答——这是当前最大的质量洼地）；修复上行缺陷（简单请求不会误启动小队）。

4.6 意图识别层配套扩展

• internal/intent/recognizer.go 新增候选意图 IntentTriggerAdhocTask（TRIGGER_ADHOC_TASK）：命中"升级为小队任务"期望选项（分支 1 走 MatchedOption 兑现，无需新规则）或自由任务显式动词（"立项一个任务/组建小队/正式做一份"）；
• matchTriggerTask 词典与 TaskProfile 信号词典分离维护：前者管"标准任务语义"，后者管"复杂度画像"，避免互相污染置信度；
• 路由判定结果（channel/confidence/reason）写入 IntentRecognitionResult 附加字段并随 SSE EventStatus 下发，前端可展示"为何走了这条通道"。

5. 自由任务（Ad-hoc）治理设计

5.1 复杂度三级与通道对应

现有 planAutonomousAdhoc 对任何非标任务一律生成固定 4 阶段流水线（organize → specialist → writer → leader）。本设计引入复杂度分级，拆解深度随级别伸缩：

级别	特征	拆解策略	预算档
A1 轻量咨询	单主题、无交付物、即问即答	不建工作区，DIALOGUE 通道直答（ComplexityScore < 40）	light
A2 单文档交付	明确单一交付物、单领域深挖	保留现有 4 阶段骨架，全部契约化（§6.1）	medium：步骤 ≤6、修复轮 ≤2、WallClock 30min
A3 多文档研究型	多对象多维度、需检索/多角色交叉、可能多产物	动态拆解：organize → Task Brief 澄清 → 按维度生成 N 个 specialist 契约子任务（可并行）→ 汇总 writer → leader 终审	heavy：步骤 ≤12、并行度 ≤4（受 MaxConcurrentAgents 约束）、修复轮 ≤3、WallClock 90min

A2/A3 的拆解产物统一进 WorkflowPlan（PlanningMode 维持 PlanModeAutonomousAdhoc），下游治理（FSM/预算/轨迹/验收/归档）与固定 workflow 任务完全共用同一套内核——"自由任务不豁免治理"是核心原则。

5.2 Task Brief 目标澄清协议（自由任务的验收锚点）

固定任务以 template.md 为验收锚点；自由任务没有，因此必须在拆解前显式构造锚点：

type TaskBrief struct {
    Objective       string   // 用户确认过的单句目标
    Deliverables    []string // 交付物清单（文档标题/表格名）
    MustCover       []string // 必须覆盖的要点（用户提出或澄清确认）
    Constraints     []string // 约束（预算口径/标准范围/不要做什么）
    SuccessCriteria []string // 用户视角成功判据（生成验收 rubric 的种子）
    ConfirmedBy     string   // user | auto（逐条确认 or 低风险自动基准）
}

澄清流程（升级确认后触发，挂 PendingExpectation 收敛，最大澄清轮数默认 3）：

1. TaskRouter 的 UpgradeHint 已从本轮对话提炼 Brief 草案（slots.task_brief）；
2. 小队启动前 organizer 角色对草案做缺口判定：关键缺口 ≤2 → 单轮卡片式澄清（复用 InteractiveCardPayload，选项化而非开放问答，降低用户负担）；缺口为 0 → 用户一键确认开工；
3. 确认后 Brief 冻结（进 manifest），成为后续 drift 检测与终局验收的基准；
4. maxClarifyRounds 耗尽 → 按行业基准自动补齐并标注 ConfirmedBy: auto（与现有"基准假设替代填空"产品哲学一致：不阻塞、先兜底、留确认清单）。

5.3 动态拆解生成（A3 级）

planAutonomousAdhoc 扩展为两阶段：

• 阶段一（规划步）：新增 mode: "plan" 的 specialist 规划步骤（StepSpec.Mode 已支持 plan/replan 语义），输入 Task Brief + 材料 + KB 命中，输出结构化拆解 JSON（子任务清单：每项含 Objective/Output/Acceptance/Budget 切片）；
• 阶段二（构造）：AdaptivePlanner 对拆解 JSON 做守卫校验（JSON Schema 级 + 步骤数/并行度/预算档上限），非法则回退 A2 骨架并记录 fell_back_to_skeleton——LLM 产出永不直接生效，必须过守卫（与 L1→L2 终审同构）；
• 拆解结果入 workflow.json，后续由 evaluator 的动态加步/跳步能力继续自适应。

5.4 自由任务的验收基准

• L1 步骤契约验收：与固定任务共用（§6.5），标准来自拆解 JSON 中每个子任务的 Acceptance；
• L3 终局验收的锚点替换：固定任务锚点 = template.md 章节；自由任务锚点 = Task Brief 的 MustCover 要点覆盖率（关键词 + 语义嵌入双检，复用 kb/embed.go）+ SuccessCriteria 生成式 rubric（leader 按 Brief 逐条自评 + 门禁规则复核）；
• 交付后 Brief 与终稿一起进 manifest.json，用户可追溯"当时要的是什么、拿到了什么"。

6. 六大治理机制（固定任务与自由任务共用内核）

6.1 任务拆解契约化：StepSpec → TaskContract

type TaskContract struct {
    Objective  string                // 单句目标（注入 prompt 开头，防漂移锚点）
    Output     OutputSchema          // 必填章节/字段/文件清单（复用 template 提取逻辑）
    Acceptance []AcceptanceCriterion // 结构化验收标准（§6.5，机器可判定）
    Term       TerminationPolicy     // 成功判据 | 超时 | 预算耗尽 | 上游失效
    Deps       []string              // 显式依赖步骤 ID（替代弱约定的 Needs 路径）
    Budget     BudgetView            // 本步预算切片（§6.3）
    Sandbox    SandboxSpec           // 可读白名单/可写目标/禁改清单
}

• 归档锁定（freeze）：步骤进 archived 态时由 Archiver 生成步骤级 manifest（SHA-256，复用 GenerateManifest），后续写操作被 FSM 拒绝；重开须显式 Reopen(reason) 写审计日志（docgov IsLocked 语义平移到小队层）；
• 低耦合强制：步骤间通信仅两条通道——黑板 + 归档产物只读引用；runOneStep 中 leader 预置 baseline 的隐式跨沙箱写收口为显式 InheritFrom: [step_id]（由 Archiver 拷贝并记录）。

6.2 有限状态机：StepFSM

pending → ready → executing → verifying ─┬→ archived（锁定）
                    ↑          │          ├→ repairing（预算内 ≤N 轮）→ verifying
                    └──────────┴──────────┴→ failed_terminal / aborted（用户/超预算/超时）
archived → reopened（仅显式，带审计）

• 迁移表 + 守卫函数，消灭裸字符串赋值（workflow.go 所有 Status = "completed" 改为 fsm.Transition(...)），非法迁移返回 error；
• 状态 × 角色 → 能力矩阵：verifying 态仅允许只读+校验工具；archived 态拒绝一切写；executing 态按 AgentSpec.Tools/BashPermission 收敛——现有声明字段从"文档"变成"被强制执行"；
• workflow.json 持久化时校验迁移合法性（防手改出鬼状态）。

6.3 调用阈值：三级预算账本 + 软硬两级

type Budget struct {
    StepTurns    int           // 单步容器内 agent 循环轮次（需 bridge 上报）
    AgentCalls   int           // 单角色累计调用数
    TaskCalls    int           // 全任务调用数
    RepairRounds int           // 质量修复轮（收编现有 maxRetries）
    WallClock    time.Duration // 收编现有 Timeout
}

• BudgetLedger（ledger.json）：Execute 前检查、后入账；超限 → 该步 aborted(超预算) + SSE 事件 + partial output 仍归档（半成品有价值）；
• 软硬两级（"留足余量"的工程化答案）：80% 软线注入"预算收敛提示"（"已用 X 轮，请直接产出而非继续探索"）+ 前端提示；100% 硬停；
• 标定：P0/P1 落 trace 后按观测 P95 × 2 设定，不拍脑袋；
• bridge 改造前的降级近似：以「步数 × 修复轮 × 并发」外层乘积近似总额度，已能挡住最恶性失控。

6.4 重复识别：Trace + 三类检测器 + 先提示后终止

每次 backend.Execute 追加 trace.jsonl：

type TraceEntry struct {
    Seq, StepID, Role          string
    Timestamp                  time.Time
    PromptDigest, OutputDigest string   // simhash（中文 n-gram shingling，标准库可实现）
    SimilarityToPrev           float64  // 同步骤上轮产物 Jaccard/MinHash
    TurnCount, DurationMs      int
}

检测器（纯函数易测试）：原地打转（同步骤连续 2 次 digest 相同）、收敛停滞（修复轮相似度 > 0.98 连续 M 次）、振荡（digest 在 A/B 两值循环）。

响应分级（比直接杀更省成本）：首次命中 → 注入反重复提示（已尝试方案 + 失败原因列表进 prompt："你已尝试 X，因 Y 失败，勿重复"）→ 再命中 → 强制终止该步转 repairing/aborted。检测器同时喂给 EnsureQualityOrRepair：同一违规两轮未修好即换策略（升级 prompt 或换角色），杜绝机械空转。

6.5 任务验收：三层金字塔 + 漂移检测

• L1 步骤契约验收（verifying 态跑）：AcceptanceCriterion{Kind: section_present|field_nonempty|file_exists|citation_check|numeric_range|length_range, Target, Params}，报告带证据（标准/行号）；现有 extractHeadings/禁语检查收编为 criterion 类型；
• L2 交叉验收（使用即验收）：下游步骤 ready 前先验收上游归档产物，失败触发上游 repairing——比终局更早拦截，天然挂在现有 evaluator 插入点；
• L3 终局门禁扩展：主目标漂移检测（固定任务锚点 = template 章节；自由任务锚点 = Task Brief MustCover 覆盖率 + kb/embed.go 语义相似度）；引用真实性校验（〔材料: 文件名 §章节 p.页码〕 指向的文件/章节真实存在）；修复循环接入预算账本与循环检测器。

6.6 上下文与结果治理：蒸馏 → 归档 → 瘦身

• 产物蒸馏：归档时生成 digest.md（要点提炼，ExtractAdvisorBriefing 已是先例），后续步骤默认注入 digest 而非全文，细节按 context/index.json 权威等级回读（新增 digest 权威等级）；
• 对话治理：替换 dialogueHistoryMax=8 硬截断 → 里程碑轮豁免（复用 decay 的 MilestoneExempt 思想）+ 语义相关性 top-k（复用 embed）+ 旧轮折叠为 summary 轮；
• 黑板生命周期：Gaps resolved 清除、rejected Assumptions 归档、条目按现有半衰期衰减权重，防膨胀污染后续 prompt；
• 工作区瘦身：archived 后子工作区仅保留 output.md + manifest hash，过程文件移 archive/，磁盘与注入双降；
• 结果沉淀闭环（已有，保持）：advisor_brief.json → ctxmgr 记忆 → 相似案例库反哺。

7. 横切：可观测性与审计三件套

• 全部治理事件（状态迁移 / 预算消耗 / 循环命中 / 验收结果 / 路由判定）走 stream.EmitPhase 与 SSE，前端 PhaseEventStrip 直接展示；可扩展 EventGovernance 事件类型携带结构化 payload（预算余量、检测结果、路由 reason）；
• trace.jsonl + ledger.json + manifest.json 构成事后审计与阈值标定数据源，支撑定期回归分析调参（建议纳入 .doc/test-reports 报告惯例）。

8. 实施路线图

阶段	内容	依赖	验收要点
P0	① StepFSM 收口裸字符串赋值 ② BudgetLedger 外层近似额度 ③ 步骤级 manifest 归档锁定	无（纯 Go 层）	go test ./... 全绿；旧 workflow.json 兼容读入并自动升级状态
P1	④ TaskRouter（R0/R1 规则路由 + 升级建议复用 PendingExpectation） ⑤ bridge 协议扩展（上报 turns_used/tool_calls，Request 增加 max_turns 硬限） ⑥ trace.jsonl + 循环检测器	P0 的 FSM/Archiver	路由黄金用例集：复杂自由任务给出升级选项且即时初答完整；标准任务/闲聊/查询通道行为与现状逐例等价（零回归锁定）
P2	⑦ IntentTriggerAdhocTask + Task Brief 澄清协议 + A3 动态拆解 ⑧ 结构化验收 + 交叉验收 + drift 检测 ⑨ 产物蒸馏 + 对话语义过滤 + 黑板生命周期	P1	自由任务端到端：对话升级 → 卡片澄清 → 小队动态拆解 → 门禁 → 归档全程可观测可追溯

排期理由：P0 无外部依赖、纯防御性收口，立即降低存量风险；路由层放 P1 而非 P0，因其黄金用例集需要 P0 的 trace 基础设施记录判定依据；bridge 改造与 TaskRouter 并行立项（bridge 是外部仓库协作，周期不可控，先行启动）。

9. 风险与开放问题

1. bridge 黑盒是第一性约束：StepTurns 精确值依赖 bridge 改造完成；P0/P1 期间以「步数 × 修复轮 × 并发」外层近似，需接受粒度损失并在 trace 中标注 budget_mode: approximate；
2. 路由黄金用例集维护成本：需持续收集真实对话样本回放锁定行为，防止规则词典腐化；
3. A3 动态拆解的规划步本身是 LLM 产出：守卫失败回退 A2 骨架的策略可能掩盖规划质量问题，需在 trace 中单独标记 fell_back_to_skeleton 观测回退比例；
4. 自由任务与 docgov 受控治理的关系：自由任务产物是否强制进入 drafting→reviewing→approving 流转暂定为"可选接入"（升级选项中增加"是否走受控审批"），留待产品决策；
5. simhash 中文方案：字符 n-gram 无需分词器，但停滞线（0.98）等阈值可能需按任务类型分档，以实测误报率为准；
6. 升级建议的打扰度：R1 升级提示频率需设冷却（同一会话未采纳后 N 轮内不再提示），避免推销感——对齐"参谋不强推"的产品人设。

---

附录 A：本设计引用的现有代码资产清单

资产	位置	在本设计中的角色
docgov FSM	internal/docgov/state_machine.go	StepFSM 的风格模板与锁定语义来源
质量门禁+自动修复	internal/squad/quality_gate.go	L3 验收收编对象；修复循环接入预算与循环检测
动态加步/跳步	internal/squad/evaluator.go	L2 交叉验收插入点；A3 自适应延续
并发信号量	internal/agent/limiter.go	BudgetLedger 的并发维度基础
分级权威上下文	internal/squad/context.go	蒸馏注入的权威等级扩展宿主
时间衰减	internal/ctxmgr/decay.go	黑板/对话里程碑豁免的算法来源
语义嵌入	internal/kb/embed.go	drift 检测与对话语义过滤复用
挂起期望/交互卡片	internal/intent/types.go	升级建议与卡片式澄清的交互宿主
非标自主规划	internal/squad/planner.go planAutonomousAdhoc	A2 骨架保留；A3 动态拆解扩展点
SHA-256 清单	internal/squad/quality_gate.go GenerateManifest	步骤级归档锁定的指纹机制
断点续跑	internal/squad/service.go ResumeOrModifyWorkspace	aborted/failed_terminal 态的恢复入口