SRE Agent 设计笔记 10：Context Engineering 的实践：知识分层与加载策略

文章目录

1. 状态：大纲
2. 核心论点
3. 大纲
   1. 1. 问题：575 行 monolithic skill.md 怎么拆
   2. 2. 三种知识的本质区别
   3. 3. 加载策略与 Context Window Budget
   4. 4. 为什么 Facets 不做成 Skills
   5. 5. 为什么 Knowledge 不放进 Facets
   6. 6. 从 blog 08 到 blog 10 的关系
   7. 7. 实践中的验证
4. 涵盖的 Topic
5. 源文件引用

状态：大纲

核心论点

Agent 的知识不是一坨 prompt 塞进去就行。Skills / Facets / Knowledge 是三种不同抽象层次的知识，对应不同的加载策略和变更频率。这个分层不是分类学上的洁癖，是被两个实际力驱动的：context window 预算管理和维护责任分离。从四原语的视角看，Skills 是 Spec 组件，Facets 是 Loop 的方法论，Knowledge 是 Loop 执行时的领域数据。Blog 08（Prompt to Skill）讲了「Skill 是持久化的 Spec」，本篇回答它的 follow-up：除了 Spec 以外，agent 还需要什么，以及这些东西为什么不能也做成 Skill。

大纲

1. 问题：575 行 monolithic skill.md 怎么拆

起点是一个具体的工程问题：oncall triage agent 的 skill.md 有 575 行，每次全量注入 context。里面混着验收标准、输出格式模板、MCP 查询安全规则、调查方法论、case 路由表。全塞进去浪费 context，不塞又怕遗漏。

直觉反应是「拆成小文件」，但拆的维度是什么？按文件大小拆？按使用频率拆？按主题拆？不同的拆法导致不同的架构。

2. 三种知识的本质区别

	Skills	Facets	Knowledge
回答的问题	怎么工作（meta）	怎么调查（method）	调查什么（domain）
四原语映射	Spec 组件	Loop 的方法论	Loop 执行时的领域数据
举例	验收标准、输出格式、查询安全规则	信号提取方法、日志分析步骤、Pod 检查流程	case 库、runbook、debug tree、routing table
变更驱动力	agent 设计迭代（低频）	方法论改进（中频）	每次 case 积累（高频）
维护者	agent 设计者	SRE / 方法论 owner	oncall 团队 / 自动积累

区分标准不是「内容是什么」，是「什么力量驱动它变化」和「谁负责维护它」。

3. 加载策略与 Context Window Budget

三种知识对应三种加载机制，根本原因是 context window 是稀缺资源：

Skills → Claude Code 原生注册机制

• 自动注入（frontmatter skills 字段）：每次都需要且体量小（< 50 行），agent 启动即加载
• 按需加载（/skill-name）：体量大或条件性使用
• 为什么用原生机制：Skills 定义了 Spec（终态），agent 从第一步就需要知道 done 长什么样

具体拆分：

Skill	行数	加载方式	理由
acceptance-criteria	30	自动注入	每次都需要，agent 启动即知终态
query-safety	17	自动注入	每次 MCP 查询都需要
output-format	172	按需	只在写输出时需要
data-tools	103	按需	只在查特定数据源时需要
compound-learning	78	按需	只在调查结束后需要

auto-inject 的判据：每次都需要 + 体量小（< 50 行）。两个条件同时满足才自动注入，否则按需。

Facets → Agent 通过 Read 按需加载

• 不注册为 Claude Code skills，原因：太碎片、条件性太强
• 按告警类型条件触发（Routing 告警 → 加载 signal_extraction facet，Pod 问题 → 加载 compute_pods facet）
• Agent 自己决定何时加载哪个 facet（声明式：routing table 定义了告警类型和对应 facet 的映射，agent 自行匹配）

Knowledge → Agent 通过 Read 按需加载

• 和 Facets 同样是 Read 加载，但驱动力不同
• Knowledge 随 case 积累持续增长（34 cases、21 runbooks、15 cards……），全量注入不现实
• Agent 通过 routing table 定位到具体 case/runbook/debug-tree，只读需要的部分

4. 为什么 Facets 不做成 Skills

表面答案：facets 按告警类型条件加载，不是每次都需要，做成 Skill 会浪费 context。

更深的答案：Skill 是 Spec（终态定义），Facet 是 Loop 的方法论（过程知识）。 它们在四原语中的位置不同。

Skill 定义了「done 长什么样」（验收标准、输出格式），agent 用它判断自己是否完成了。Facet 定义了「怎么做调查」（信号提取的具体步骤、日志分析的查询模板），agent 用它执行调查过程。如果把 facet 做成 skill，就把方法论混进了终态定义，违反了「约束结果不约束过程」的原则。

边界 case：如果某个 facet 很小且几乎每次都用（比如 signal_extraction），是否应该升级为 Skill？判据不是大小和频率，是它回答的问题类型。如果它定义的是「什么算好的信号提取」（终态），升级为 Skill。如果它提供的是「怎么提取信号」（方法），保持为 Facet。

5. 为什么 Knowledge 不放进 Facets

Knowledge 和 Facets 都是 Read 按需加载，为什么还要分开？

变更频率和维护者不同。 Facets 由 agent 设计者维护，随方法论迭代变化（中频）。Knowledge 由 oncall 团队和 agent 自己积累，每次新 case 都可能新增条目（高频）。把它们混在一起，agent 设计者需要在每次 case 积累时 review 整个目录，维护成本高。

增长模式不同。 Facets 的数量大致稳定（调查方法论就那么几种），Knowledge 持续增长（case 库只会越来越大）。分开后，Knowledge 目录可以无限增长而不影响 Facets 的可读性和可维护性。

6. 从 blog 08 到 blog 10 的关系

Blog 08 的结论是：「Skill 是 prompt engineering 的退出路径，把质量约束持久化到 Spec 里。」

本篇追问：如果所有知识都做成 Skill，会怎样？

答案是 context window 爆炸、终态定义和过程知识混淆、维护责任不清晰。所以需要三层分离：Skill（Spec，少量，总是或按需加载）、Facet（Loop 方法论，中量，条件加载）、Knowledge（领域数据，大量，按需读取）。

这三层的关系类比：

• Skill ≈ K8s 的 CRD spec（声明终态）
• Facet ≈ K8s 的 Controller 逻辑（怎么 reconcile）
• Knowledge ≈ K8s 的 ConfigMap / Secret（运行时数据）

7. 实践中的验证

来自 oncall triage agent 的实际数据：

• 自动注入的 acceptance-criteria + query-safety 合计 47 行，每次都用，零遗漏
• 按需加载的 output-format（172 行）只在写输出阶段加载，节省了前期调查阶段的 context
• Facets 按 routing table 条件加载，平均每次调查只加载 1-2 个（共 5+ 个）
• Knowledge 通过 routing table → debug tree 路径定位，平均读取 2-3 个文件（库中 100+ 个）

如果全量注入：47 + 172 + 103 + 78（Skills）+ ~500（Facets）+ ~2000（Knowledge 摘要）≈ 2900 行。实际按需加载后，平均 context 占用 ~400 行。节省约 85%。

涵盖的 Topic

• Topic 新增：Facets / Skills / Knowledge 三种知识组织（从 daily record 2026-04-15 提取）

源文件引用

• /Users/rshao/work/work-harness/agents/sre_oncall_triage_agent/README.md — Section 5（Skills 拆分表）、Section 8（Facets vs Skills vs Knowledge 表）、Directory layout、Knowledge base 统计
• contexts/daily_records/2026-04-15_2135_oncall-agent-architecture-refactor.md — 575 行拆分决策、auto-inject vs on-demand 判据、Facets/Skills/Knowledge 原始定义、三层持久化设计
• contexts/thought_review/agentic_control_theory_primitives_20260413.md — Spec/Loop 原语定义（Skills 映射 Spec，Facets 映射 Loop 方法论）
• contexts/thought_review/agent_ops_competency_model_v1.md — Pillar 3 Context Engineering：prompt architecture、tool schema design、knowledge routing
• 本系列 blog 08（从 Prompt 到 Skill）— 前置依赖，本篇是其 follow-up