Capability Discovery and Authority：Explicit Intent 还是 Model-Driven Adaptive？

[tt-a1i]

这是 OpenPI 产品哲学总纲 #299 的第二个专题，也是 Tool Surface Economics #300 的上游产品问题。

问题不只是“要不要常驻一个 gateway”，而是：谁负责发现能力，什么构成用户授权，Runtime 怎样在不规定模型 Workflow 的前提下 fail-closed？

需要先拆开四个概念：

Discoverable：模型知道能力存在
Visible：Tool Definition 已进入当前模型上下文
Authorized：Runtime 允许当前 Session/Child 使用
Beneficial：在这个具体任务中采用能力的净收益为正

四者不能互相替代。模型发现了能力，不等于已获授权；用户提到“子代理”也不一定是在要求执行；工具已经可见，也不说明现在调用它有价值。

当前 OpenPI 的两种配置

Explicit（默认）

普通父 Session 不常驻 OpenPI 模型工具。before_agent_start 根据明确用户意图直接加载对应能力组。

优点：

• ordinary task 的固定工具面最小；
• 用户明确要求时，不需要 gateway 往返；
• 对弱模型更可靠；
• 昂贵能力的授权更容易解释。

风险：

• 用户需要知道 Subagent、Workflow、Background 等产品词汇，或恰好使用分类器能识别的表达；
• 否定、条件句、讨论能力本身与真实执行意图很难只靠文本规则长期区分；
• 关键词分类器不会随模型能力自然增强；
• 长 Session 中途直载发生在 Tool Result 之外，可能绕开 Pi 的 native deferred load point。

Adaptive（opt-in）

常驻一个小型 openpi_load_tools gateway，允许模型判断何时加载能力组。

优点：

• 用户不必记住能力名称；
• 判断交给当前模型，理论上可以随模型增强；
• 经工具调用发生的纯增量加载，可以利用 Pi/provider-native deferred loading；
• 对隐含但确实需要委派、长后台或结构化搜索的任务更有发现机会。

风险：

• 所有普通任务承担固定入口税；
• 弱模型可能不调用或错误调用 gateway；
• 多一次 meta decision / Tool Call；
• 当前 adaptive 选择同时意味着用户允许模型启动该组内的昂贵工作，发现与授权耦合较紧；
• “模型可以自主发现”尚未证明会转化为稳定净收益。

两种配置不是完全互斥的加载机制：明确用户意图仍可走 before_agent_start 直载；adaptive 只是额外提供模型驱动的 gateway 路径。

真正的设计张力

1. 自然语言入口还是关键词路由器

自然语言应由活动模型理解，但 Runtime 不能把权限不变量寄托在 Prompt 上。

需要区分：

• 用户明确要求执行：“用几个子代理并行检查”；
• 用户只是询问能力：“子代理是什么？”；
• 用户否定执行：“不要委派”；
• 条件或引用：“如果你要委派……”；
• 隐含适用但未点名：“同时调查五个互不依赖的问题”。

前四类涉及可解释授权；最后一类涉及模型判断。把两者压进一个关键词开关，会同时损失自然语言能力与授权清晰度。

2. Discovery 不等于 Authority

Provider tool search、namespace、catalog 或 OpenPI gateway 可以帮助模型发现工具，但不能成为执行权限来源。

运行时仍应计算：

当前可执行能力
=
用户配置
∩ Parent authority
∩ Child authority
∩ Trust / permission
∩ 当前资源与调用限制

任何恢复、搜索或模型输出都不得扩大这个交集。

3. 强模型会更常用 Harness，还是更少需要 Harness

存在两个相反假设：

• 强模型更能理解 catalog、判断并行收益并正确使用小而正交的能力；
• 强模型直接完成任务的能力更强，反而更少需要固定 Workflow 或多 Agent Harness。

因此不能用“模型越来越强”直接支持 adaptive，也不能直接支持删除高级能力。应该测净收益，而不是单独测采用率。

4. 高频 Pi 工具不等于高频 OpenPI 能力

read/bash/edit/write 高频，只能证明 Pi core 高频；不能推出 Delegate、Workflow、Background、Goal 也应该常驻。

低频能力也可能在少数适用任务中产生极高价值。应评价：

适用任务占比
× 正确发现率
× 采用后的价值增量
-
全体任务固定税
-
错误加载与错误轨迹成本
-
权限和维护风险

候选方向

A. 保持当前 Explicit 默认

继续以明确用户意图作为昂贵能力入口。优点是成本与授权最确定；缺点是发现率和模型杠杆受限。

B. Adaptive 默认

让模型自主发现。只有当隐含适用任务上的稳定收益覆盖普通任务入口税、误加载与额外轨迹后才成立。目前证据不足。

C. 双路径、权限解耦

• 用户明确要求：Runtime 直接加载或在支持时创建 native deferred load point；
• 用户允许自主发现：模型可以通过 gateway/catalog 查找；
• 能力发现、工具可见和昂贵执行授权分别记录；
• Runtime 始终执行 authority intersection。

这是目前最值得验证的方向，但不预设必须新增控制面。

D. Provider-native Catalog / Tool Search

将 Provider tool search 作为序列化和发现后端，而不是产品权限模型。支持不足时保留 Pi-native fallback。

最小实验矩阵

任务至少分四类：

1. 明确要求 Subagent / Workflow；
2. 没有点名能力，但并行或委派能被独立 verifier 证明有价值；
3. 完全不需要高级能力；
4. 明确禁止委派、费用敏感或权限受限。

覆盖强弱模型、短长 Session，以及支持/不支持 native deferred 的 Provider。记录：

• 正确发现率与漏发现率；
• 无理由加载率；
• 明确意图分类的误触发/漏触发；
• capability loaded、tool visible 与 actual call 分开计数；
• Runtime 拒绝与 authority receipt；
• task success、turns、tool calls、tokens、cost、wall；
• 首次能力使用位置与加载路径；
• 用户能否解释“为什么这个能力现在可用”。

只有 mechanism 真正触发，才能声称验证了该机制的收益。

建议的暂定立场

• explicit 继续作为默认，理由是零常驻、授权清晰和弱模型可靠，而不是宣称它永远缓存最优；
• adaptive 继续 opt-in，重点验证隐含适用任务的正确发现与净收益；
• Provider-native tool search/deferred loading 作为实现后端，不替代 Runtime 权限；
• 不把关键词分类器发展成固定任务路由器；
• 不因为工具“听起来重要”就进入稳定核心。

与现有工作的关系

• #20：从常驻工具面到 explicit/adaptive 的历史与 Benchmark；
• #84：工具 Schema、角色披露、选择面与缓存稳定；
• #194：模型可见注入面、顺序、权限与证据；
• Tool Surface Economics：稳定全量前缀还是渐进式能力加载？ #300：Schema、缓存、加载和完整工具成本；
• Tool lifecycle across compaction #311：能力在压缩和恢复后的重新投影。

非目标

• 不用 Prompt 代替 Runtime 权限检查；
• 不创建固定任务分类或编排 Workflow；
• 不默认授权昂贵模型调用；
• 不要求用户记忆所有 OpenPI 产品术语；
• 不把 Provider tool search 当成信任边界；
• 不按模型品牌硬编码不可解释的默认策略。

希望讨论最终回答：

什么最小机制能同时做到：用户授权可解释、模型可以自主发现、普通任务固定税足够低、弱模型不失去直达路径，并且更强模型能获得更多而不是更少的杠杆？

[tt-a1i]

补一条边界：本帖只讨论“能力怎样被发现、怎样获得授权”。任何从 explicit 默认改成 adaptive 默认的主张，都需要经过 Evidence and Evaluation #313 的独立证据门槛；不能用“模型更聪明了”替代实际任务收益、误触发率、权限和生命周期验证。

[tt-a1i]

授权不是一个布尔值：需要 capability authority ladder

当前的 Authorized 还应继续拆开：

知道能力存在
≠ 允许加载/展示 Schema
≠ 允许调用低成本只读操作
≠ 允许启动 Child/Subagent/Workflow
≠ 允许消耗额外模型预算或并发配额
≠ 允许持久化
≠ 允许跨 Session / Compaction 恢复

需要公开回答：

• adaptive 设置具体授权到哪一级；
• 用户提到 “Subagent” / “Workflow” 是允许显示能力，还是允许实际启动；
• “Compare Subagent and Workflow” 这种讨论句是否只应披露，还是会被当成激活信号；
• 授权是单次调用、当前 turn、当前 Session，还是可恢复状态；
• 用户怎样检查、撤销和停止；
• Child 始终只能获得 Parent authority 的 fail-closed 交集；
• 每次昂贵执行、拒绝、取消和恢复留下什么 receipt。

产品词被识别或 UI 被高亮，不能自动等同于执行授权。能力应该是什么形态，另见 Capability Shape and Harness Value #314。