编排能力目录：意图识别与规划者/小队领导的配合（设计思考）

状态：待审（设计结论，未实施）；owner：weichen。触发：用户对 Squad/Native 分工的模型与核心疑问——理想状态下规划者/领导把任务拆解为单一意图步骤下发给 Native 执行；领导可通过 HITL 收集信息后生成单一意图指令；但未接入意图识别时，领导如何知道要通过 HITL 收集哪些信息？ 关联：2026-09-29-scope-boundaries-compound-slots-dialog.md、2026-09-29-decoupling-and-llm-layering.md。

一、先校正分工事实（对齐用户模型）

准确表述是："机制在 Squad，智能在 Native 之上"：

能力	机制（脚手架）	智能（谁在思考）
任务拆解	Squad：Planner 接口、蓝图、flowDriver	跑在 Native 上的规划者（LLMPlanner）或领导 Agent（leader 委派循环）
任务分配	Squad：编制、BackendResolver、委派协议	领导 Agent（delegation 决策）或规划器
任务执行	Native：循环、工具、工作区、交付物落盘、失败分类	执行 Agent
结果校验	Squad：Checker/Evaluator、质检 HITL、黑板	质检 Agent / 规则检查器

所以"Squad 是组织功能模组"成立——但拆解/分配/校验的机制确实在 Squad；被组织的"智能体"全部跑在 Native 上。这个校正很重要：它决定了意图知识应该注入的位置是 Squad 的规划入口（PlanInput / 领导上下文），而不是 Native 内部。

二、"意图识别与 Native 配合"的准确形态

用户理想：被分配的 Native 角色只收到单一意图的输入。正确，且落地形态是——下发给执行的每一步只有两种：

系统功能步：意图已识别、槽位已填齐 → 直接调 handler（不打模型、不进 agent 循环）；
Agent 步：单一明确目标的简报（不含可被系统功能短路的部分），上下文完整。

注意"单一意图"对 agent 步意味着"单一明确目标"，不必然是系统功能意图（调研/撰写类步骤天然开放）。

三、核心问题：领导如何知道要问什么？

现状（未接入目录）

规划者/领导只看得见角色目录（RoleRegistry：谁会干什么，Keywords/Responsibilities）与蓝图关键词。它看不见系统有哪些可直接调用的功能，因此：

拆解时无法把子任务短路给系统功能（明明有 taskrun.query_status，却派了个 agent 去"想办法查"）；
HITL 提问只能自由发挥（leader 的 escalate 是自由文本）：要么问不到点（缺的字段没收集），要么问错（问了不存在的字段）；
收集到的信息没有契约校验（字段真伪/枚举合法与否无人把关）。

答案：意图注册表就是能力目录（Capability Catalog）

IntentSpec 天然携带目录所需的全部声明：

id / description        → 有哪些系统能力（人话，供 LLM 匹配）
slots[].required        → 每项能力缺什么信息（HITL 提问清单的来源）
slots 的约束/标签       → 问什么、怎么问、什么算合法答案（E2/E4 扩展）
risk / requires_confirm → 哪些能力执行前必须确认（对齐 HITL 确认门）
handler / metadata      → 短路调用方式与路由提示

对称性很有说服力：角色目录回答"谁能干活"，意图目录回答"有哪些系统能力不必干活（直接调用）"。今天规划者只有前者；补上后者，拆解才是完备的。

三触点架构（意图在 Squad×Native 栈中的完整位置）

用户目标
  │
  ▼
[触点 1] 入口闸门（Squad gate，已建）
  │   整句确定性识别：守卫拒绝 / 整句命中系统功能 → 短路 handler / 其余放行
  ▼
规划者 / 领导 Agent（跑在 Native 上）
  │   注入[触点 2] 能力目录（本篇新增的关键件）：
  │     · 拆解时把子任务匹配到系统功能（不派 agent）
  │     · 按 slots[].required 生成定向 HITL 提问（不再自由发挥）
  │     · 产出计划后经确定性校验：意图存在？必填槽齐？枚举合法？——fail-closed 打回
  ▼
步骤下发
  ├─ 系统功能步：handler 直调（槽位已填齐，无 agent）
  └─ Agent 步：单一目标简报 → Native 执行
        │
        ▼
      [触点 3] 执行防线（Native intentgate 装饰器，已建）
          步骤 prompt 兜底拦截：守卫命中 / 意外命中系统功能 → 合成结果，模型零调用

触点 1 与 3 已建成并验证；缺的是触点 2。它同时解决上一轮"复合指令"的执行侧：整句可短路则触点 1 直接办；混合指令由领导携目录拆解；领导拆解结果再被确定性校验——LLM 负责语义匹配，规则负责契约把关，各居其位。

防"领导幻觉"的闭环

领导（LLM）可能提议不存在的功能或漏填槽位。确定性校验（用本模块的 SpecByID + 槽位约束）构成闭环：不通过 → 打回重拆或转 HITL 补问，绝不带着残缺契约执行。这与 Squad"未知 backend fail-closed"的既有边界同构。

四、落地差距清单

#	差距	归属	性质
G1	目录渲染：把 Snapshot 渲染为规划者/领导可消费的目录文本（Markdown/JSON，含 slot 标签与提问建议）	agent-intent（建议 E4：`Catalog()` 助手）或宿主自渲染	小
G2	SlotSpec 增加人类可读 `label` / `question`（HITL 提问生成直接可用）；配合 E2 的 enum/range 约束做答案校验	agent-intent（E2 扩展的一部分）	小
G3	PlanInput / 领导 prompt 注入目录；计划输出经确定性校验（意图存在、必填槽齐、确认门对齐 risk）	Agent-Squad 演进项	中（规划器/leader 提示与校验逻辑）
G4	系统功能步的执行通道：计划步骤 → handler 调用（不经 BackendResolver/agent）	Agent-Squad 演进项	中
G5	领导 HITL 提问模板：由 slot question 生成澄清请求（复用既有 HitlClarification/HitlEscalation 机制）	Agent-Squad 演进项	小

agent-intent 侧只需 E2/E4 两个小扩展（保持机制化、确定性）；重头在 Squad 侧的 G3–G5，属"目录驱动的编排"演进。

五、结论

用户模型成立，校正后更准确：机制在 Squad、智能在 Native 之上；意图知识的注入点是 Squad 的规划入口，不是 Native 内部。
"领导如何知道问什么"的答案：意图注册表即能力目录——slots 声明了缺什么、risk 声明了要不要确认、description 声明了有什么；当前缺的是目录暴露（G1/G2）与消费侧（G3–G5）。
三触点齐备后：整句短路（触点1）、目录化拆解 + 定向 HITL + 契约校验（触点2）、执行兜底（触点3）——复合指令、槽位收集、单一意图下发在此架构下闭环，且每一触点都保持"规则定契约、LLM 做匹配"的分工。

7.0 KiB Raw Blame History Unescape Escape