核心 GUIDE
Model Capability Envelope
Model 拥有与 Workload 相关的 Capability Envelope；超出经过测试的边界时，应先降低 Confidence，而不是先扩大 Autonomy。
核心心智模型
Capability 不是一个 Scalar Score。应该把它看成覆盖 Task Type、Language、Context Size、Tool Pattern、Modality、Latency Budget 与 Error Cost 的 Envelope，并在真正部署的 Harness 下测量。
为什么重要
一个 Model 可能擅长某类 Coding Task，却在另一类不可靠；Short Context 很强，但 Long Tool Chain 容易失控；Aggregate Average 很高，却在 High-impact Slice 上失败。团队只有知道 Performance 在哪些条件下真正被证明，才能把超出这些条件的使用当成 Explicit Risk。
01
按 Representative Slice 绘制 Capability
定义 Workload 关键 Dimension：Task Family、Difficulty、Language、Context Length、Tool Steps、Structured-output Demand 与 Error Consequence。使用 Production Harness 对 Representative Slice Evaluation，并记录哪些区域通过 Required Threshold。这个 Envelope 可以直接驱动 Routing、Escalation 与 Product Scope，而不是假设一个 Benchmark 能代表所有情况。
02
例子：只在 Bounded Repository Change 上可靠的 Agent
Coding Model 在 Single-service Bug Fix + Executable Test 上表现稳定，但 Cross-repository Migration 与 Ownership Ambiguity 会明显下降。Product 因此允许前一类 Autonomous Edit，而后者必须 Plan + Human Review。Boundary 来自 Observed Capability，而不是一个泛化 Model Label。
常见失败模式
- 把 Benchmark Rank 当成 Universal Capability Score。
- 没有 Evaluation 新 Task Class 就扩大 Autonomy。
- 忽略 Harness、Context 与 Tool Design 对 Observed Capability 的影响。
工程启发
- 用 Workload Slice 与 Acceptance Threshold 定义 Capability。
- 像记录 Strong Area 一样显式记录 Missing Evidence Area。
- Model、Prompt 或 Tool 发生实质变化后重新测 Envelope。
关键结论
- 01Capability 依赖 Workload 与 System Context。
- 02Tested Envelope 比“这个模型很聪明”更有工程价值。
- 03Autonomy 与 Routing 应尊重已经证明的 Capability Boundary。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。