场景 A：传统耦合模式 —— 业务规则焊死在代码里
在一个类里同时装着框架管道 + 业务规则 + 审查逻辑。想改规则，就要改代码。
一个类 = 全部（伪代码）
class K8sAgent {
String PROMPT = "你是K8s专家..."; // 业务知识写死
List<Tool> tools = [kubectl_describe...];
String reviewRule = "代码风格用空格"; // 审查规则写死
String loopCode = "..."; // 管道逻辑写死
}
想改一条审查规则：
- 改 Java 代码 → 编译 → 测试
- 代码评审 → 审批 → 发版
- 周期：2 周
- 业务团队完全被卡在研发排期里
三个致命问题：① 智能与框架耦合——改规则=改代码发版；② 无法「换脑」——想换行为只能重写类；③ 无法 A/B——不能同一套代码跑两套规则。
场景 B：Harness / Payload 分离 —— 控制反转
公共管道（Harness）写一次；业务知识（Payload = Prompt/Skill 文件）由业务团队维护，改文件即热更新。
Harness 骨架
输入/工具/循环/权限
注入
Skill 包
系统提示 + 规则 + 工具清单
→
热加载
改文件即生效
Harness（工程管道，写一次）
- 输入接收 / 输出格式化
- 工具调用调度
- 权限检查（Hook 拦截）
- 上下文管理
Payload（业务知识，业务团队维护）
- System Prompt（身份/风格）
- Skill 文件（规则/流程）
- 审查规则 / 代码风格
- 改文件 = 热更新 = 5 分钟
核心收益对比
| 维度 | 传统耦合 | Harness/Payload 分离 |
|---|
| 改规则周期 | 2 周（改代码+发版，特定团队经验值） | 5 分钟（改文件+热加载，经验值；仍需评测/灰度） |
| 换行为 | 重写类，牵一发动全身 | 换一个 Skill 文件 ≈ 换行为；工具/权限/运行时不变 |
| A/B 测试 | 不行，同一代码只能一套逻辑 | 同代码，A 组 Prompt-A / B 组 Prompt-B |
| 谁维护业务 | 研发团队 | 业务团队自助（改 Prompt 不碰代码） |
五个关键决策：① 提示词放文件 vs 常量（→ 文件，可热更新）；② Harness 客户端 vs 云端（多租户企业偏云端；单机/IDE 用客户端）；③ 上下文分层压缩；④ 权限 Hook 拦截（Allow/Ask/Deny 三级）；⑤ Eval 四层测试（组件/轨迹/端到端/生产）。
代码对比：规则硬编码 vs Prompt 热更新
✗ 硬编码（改=发版）
public String getReviewPrompt() {
return "代码风格: 用空格缩进, 行宽80,
禁止魔法数字, 禁止 System.out...";
}
改风格 → 改 Java → 编译 → 测试 → 发版 → 审批 → 上线 = 2 周
✓ Prompt 文件（改=热更新）
# code-review-skill.md
你是资深代码评审专家。
风格规范:
- 使用空格缩进
- 行宽 80 字符
- 禁止魔法数字
- 禁止 System.out
运营改文件 → Harness 检测到变更 → 热加载 = 5 分钟