Capability Shape and Harness Value：什么时候该用 Primitive、Skill、Subagent 或 Workflow？

[tt-a1i]

这是 OpenPI 产品哲学总纲 #299 的能力形态专题。

前面的专题已经讨论工具定义怎样进入上下文、模型怎样发现和获得授权、能力怎样跨越 Context lifecycle，以及怎样评价净收益。但还有一个更上游的问题：

一项需求为什么应该成为 OpenPI 能力？它应该是 Pi primitive、Tool、Skill、Session policy、Child Session、Subagent、Workflow，还是只应该出现在 Operator UI？

这决定 OpenPI 是让模型获得更大杠杆，还是逐渐长成第二套 Agent OS。

先区分能力形态

Pi primitive

例如 read/bash/edit/write 以及 Pi 已经拥有的 Session、Trust、Provider/Model 选择和扩展生命周期。

适合：模型可以直接组合，且生命周期已经由 Pi 正确拥有的通用机制。OpenPI 不应复制一份平行实现。

Tool

一个窄、结构化、可校验的动作接口。

适合：Runtime 需要执行、校验或留下 receipt 的原子操作。Tool 应尽量正交，避免把完整推理 Workflow 塞进一个万能参数。

Skill

按需读取的知识、方法、约定或操作说明。

适合：需要指导模型判断，但不需要新的 Runtime 权限或生命周期。Skill 不能承担必须 fail-closed 的不变量。

Session mode / Runtime policy

例如权限、费用、并发、资源或能力开关。

适合：必须在多轮和恢复后保持一致、不能只靠 Prompt 遵守的约束。

Child Session / Subagent

一个具有独立上下文、权限交集、生命周期和结果边界的 Pi Session。

只有在以下机制确实产生价值时才值得使用：

• 可验证的并行 wall-time 收益；
• 上下文、Trust 或权限隔离；
• 失败隔离；
• 独立 coverage 后再由父模型综合；
• 长任务不会污染交互 Session。

“把任务分几段”本身不足以证明需要 Subagent；强模型直接使用 Pi primitive 仍应是基线。

Workflow

具有明确阶段、持久状态、暂停/恢复、重放或人工检查点的执行结构。

只有当这些生命周期事实本身是需求时，Workflow 才有独立价值。若只是把模型本可自由决定的步骤固化，固定 Workflow 更可能成为负担。

Background capability

当任务需要跨交互 turn 继续运行、可取消、可查询并最终发出完成事件时使用。后台状态属于 Runtime，不应靠父模型一直保持一个同步 wait。

Operator projection

面向人类的进度、日志、审批、成本和证据视图。它可以投影 Runtime canonical state，但不应因为 UI 需要就把全部信息注入模型上下文。

Provider-native capability

例如 tool search、deferred definitions、server-side state 或 compaction。优先复用其传输和序列化能力，但 Provider feature 不是 OpenPI 的权限、Trust 或恢复合同。

什么时候 Harness 是模型杠杆？

Harness 的净价值来自模型单独调用基础 primitive 难以稳定获得的机制收益：

并行 / 隔离 / 生命周期 / 恢复 / 权限 / 证据

更好的模型应能更好地决定何时使用这些小而正交的机制，而不需要 OpenPI 规定一条固定推理过程。

什么时候 Harness 只是负担？

• 重复模型已经能可靠完成的判断；
• 为了“像 Agent 系统”而强制固定阶段；
• 新增模型调用，却没有独立 coverage 或 task outcome 增益；
• Parent 轨迹看似变短，实际成本被转移到未计量的 Child；
• Tool Schema、Prompt、状态机和维护面持续扩张；
• 能力在 Benchmark 中可见，却从未真正加载或使用；
• 模型升级后，旧抽象仍被机械保留；
• 一个 UI 展示需求反过来污染模型上下文；
• Provider 已经提供更小的原生 primitive，OpenPI 仍重复实现整套控制面。

能力形态决策测试

新增或保留能力前，至少回答：

1. 哪个 Pi primitive 或 extension seam 已经拥有这个生命周期？
2. 这是模型判断，还是 Runtime 必须执行的不变量？
3. 为什么一个 Skill 或窄 Tool 不够？
4. 为什么需要独立 Session、Workflow 或后台状态？
5. 能否用一个更小、更正交的机制表达？
6. 更强模型能否直接使用底层 primitive，而无需框架重写？
7. 成功、失败、取消、不确定和清理分别留下什么 receipt？
8. Parent 与全部 Child/Workflow 的完整成本怎样计量？
9. 用户怎样授权、检查、停止、撤销和恢复？
10. 什么证据会让我们把它降级为 Skill、合并进 Pi，或直接删除？

两个必须同时保留的模型升级假设

假设 A：强模型更会使用 Harness

强模型可能更能理解 catalog、判断并行收益、选择正交工具并综合多个结果，因此小而深的能力会随模型增强而升值。

假设 B：强模型更少需要 Harness

强模型也可能直接完成过去需要 Workflow、重 Prompt 或多 Agent 才能完成的任务，使旧 Harness 变成额外调用、历史回放和维护负担。

模型变强不能直接支持“多加能力”，也不能直接支持“删除能力”。每次重要模型升级都应重新测净收益。

建议的候选方向

A. Primitive-first

能由 Pi 原语直接完成的事情不新增 OpenPI abstraction。优点是简单；风险是忽略真实的并行、隔离和生命周期需求。

B. Layered capability

优先顺序不是绝对规则，但应默认从小到大论证：

Pi primitive
→ Skill
→ narrow Tool
→ Runtime policy / Session mode
→ Child / Background
→ Workflow

只有下层无法满足可验证需求时，才引入更重形态。

C. Harness as orthogonal runtime service

Subagent、Background、Workflow 只提供执行与生命周期事实；任务拆解、调用时机和综合仍由父模型决定。

D. Provider-native first, Pi lifecycle retained

序列化、tool search、server state 等优先使用 Provider/Pi 原生能力；OpenPI 只保留 Provider 无法拥有的权限交集、资源限制、恢复与 receipt。

当前更值得验证的是 B + C + D，而不是建设统一 Agent Workflow 框架。

最小实验矩阵

对每种候选能力，至少比较：

1. 强模型直接使用 Pi primitive；
2. 只提供 Skill 或窄 Tool；
3. 提供完整 OpenPI Harness；
4. Provider-native 机制可用时的最小包装。

任务应真正要求对应机制，例如：

• 多个相互独立且必须全部覆盖的调查面；
• 需要权限或上下文隔离的子任务；
• 需要跨时间继续、取消和收尾的后台任务；
• 需要暂停、恢复、重放或人工检查点的流程。

同时报告：

• task success 与独立 verifier；
• mechanism 是否真的采用；
• Parent + 全部 Child/Workflow usage；
• wall-time 与总计算量；
• 隔离、取消、恢复和清理 receipt；
• 用户是否理解为什么发生了额外执行；
• 模型升级后的结果是否仍成立。

与其他专题的边界

• #300 Tool Surface Economics：已经决定存在的 Tool 怎样进入上下文，以及它的完整表面成本；
• #312 Capability Discovery and Authority：能力怎样被发现、展示和授权；
• #311 Tool lifecycle across context epochs：动态能力怎样跨 Compaction、Resume 和 Provider 变化重新投影；
• #313 Evidence and Evaluation：什么证据足以新增、默认、保留、重构或删除能力。

非目标

• 不为每种任务建立固定 Workflow；
• 不以“模型会忘记”作为增加控制面的充分理由；
• 不把采用率当作价值；
• 不因一次 Benchmark 未采用就删除能力；
• 不把 Provider feature 当作权限来源；
• 不让 Operator UI 成为第二份 canonical state；
• 不预设强模型一定更需要或更不需要 Subagent。

希望本专题最终形成一个可执行判断：

给定一个真实需求，OpenPI 应暴露什么最小能力形态，才能让模型能力增长时获得更多杠杆，同时让 Runtime 继续拥有权限、生命周期和确切证据？