Harness Engineering（三）：Parametric vs. Externalized — 那条移动的边界

在上一篇文章中，我们深入分析了两篇关于 Harness Engineering 的奠基性论文（arXiv:2604.08224 和 arXiv:2604.14228）。其中论文一提出的核心框架——「Externalization（外化）」——揭示了当代 AI Agent 系统最根本的设计问题：一个认知负担应该放在模型权重里，还是应该外化到基础设施中？这不是二选一的哲学问题，而是一个需要在四个工程维度上持续做判断的系统分界问题。

理解「外化」：从 Norman 的认知人工物说起

Externalization 框架的理论锚点是 Donald Norman 在 1991 年提出的「认知人工物（Cognitive Artifacts）」概念。核心洞见是：外部辅助工具不是在增强不变的内部能力，而是在改变任务本身的结构。一张购物清单不是扩充生物记忆，而是把一个困难的回忆问题变成了简单的识别问题。一张地图不是让导航「更强」，而是把隐藏的空间关系转化为可见的结构。

论文将这个逻辑应用于 LLM Agent 设计：

论文的核心主张：可靠 Agent 能力越来越不来自模型本身，而来自系统性重构任务需求——让内部能力（参数化）和外部基础设施（外化）联合覆盖完整的能力谱系。你在 Hermes 的 config.yaml 里调整 compression_threshold，本质上就是在管理「外化 infrastructure 占多少上下文预算」这个系统工程决策。

四维决策框架

论文 §7.3 给出的框架可以用一个组合图来概括：

维度 1: 更新频率与时效性衰减

论文原文: "Fast-changing knowledge and procedures are strong candidates for externalization. APIs, organization structures, and live environment state decay too quickly to maintain reliably in model weights."

这个维度最直观。判断公式：

关键警示: 论文明确指出，不能靠「多 fine-tune 几次」来解决时效性问题——continual fine-tuning 会导致 catastrophic forgetting，而且跟不上一周甚至几天的更新频率。这就是为什么 Hermes skill 系统存在的根本原因：改 skill 文件即刻生效，不需要重训模型。

维度 2: 复用半径与跨 Agent 可移植性

论文原文: "If a capability is repeatedly needed across tasks, users, or agents, externalization improves portability and composition. ... One-off or highly idiosyncratic behavior may not justify the overhead."

这是最实用的工程决策维度。量化公式：

实例分析:

Paper 2（Claude Code 源码分析）验证了这一点：CLAUDE.md 的四层 hierarchy（Managed → User → Project → Directory）正是按复用半径分层的——每一层覆盖的 agent/user 范围不同，外化深度也不同。

维度 3: 可审计性与治理——最被低估的维度

论文原文: "Alignment fine-tuning provides probabilistic behavioral shaping, but externalized constraints provide deterministic enforcement at the interface level."

论文区分了两种「安全」：

Paper 2 的具体验证: Claude Code 的七种 permission 模式、deny-first 规则引擎、ML 分类器、hook pipeline——全部是外化治理层。而且 Anthropic 发现了一个关键事实：用户批准了 93% 的权限提示——这意味着审批疲劳使人类不可靠，安全必须独立于人类警觉。

工程规则:

• 如果某个行为约束是「绝对不能做」（如删除生产数据库）→ 必须外化为声明式 deny 规则，不能只靠 RLHF
• 如果某个行为约束是「最好别这样」（如代码风格偏好）→ 参数化 + 外化（lint rules）组合

维度 4: 延迟、简单性与上下文成本——外化的代价

论文原文: "For ultra-fast, low-variance, or purely semantic tasks, allowing the model to rely on its internal parametric knowledge remains substantially simpler and often more reliable."

这是外化的代价面。外化不是在「加功能」——每个外化模块都会消耗计算和认知资源。论文识别了三种具体 failure mode：

1. Memory over-retrieval: 检索过多边际相关的记忆，淹没上下文
2. Skill verbosity: 技能文件过长或过多，挤占 token budget
3. Tool sprawl: 工具数量膨胀，把 action selection 变成不必要的消歧义问题

决策启发式:

• 纯语义判断（情绪分类、意图识别）→ 参数化即可
• 需要精确 schema 的 API 调用 → 必须外化 protocol schema，否则幻觉
• 简单 shell 命令（ls/cat/grep）→ tool description 够用，不需要 skill
• 复杂多步骤工作流（CI/CD、数据库迁移）→ 必须外化，靠 prompt 每次重建不可靠

边界是动态的：The Expanding Frontier

论文最深刻的洞察是：参数化与外化的边界不是静态的，它在双向移动。

向内收缩: 当模型自身能力提升时，一些原本需要外化的负担可以回撤到参数化。比如当模型的上下文窗口从 128K 扩展到 1M 时，memory 架构可以从精细的分层检索退化为更简单的整体加载。

向外扩展: 三个当前仍在模型内的认知工作最可能被外化：

Paper 2 提供了量化锚点: Claude Code 的 98.4% 代码是 operational harness，仅 1.6% 是决策逻辑。这说明当前最优分界点已经极度偏向外化——几乎所有东西都在 harness 里，模型只是被调用的推理引擎。

两个关键风险与治理

外化的悖论: 你增加模块来减轻模型的认知负担，但模块本身也在增加认知负担。过度外化时，"the model spends more effort discovering, parsing, and coordinating modules than solving the task itself"。

论文提出的三项缓解策略:

1. Minimal sufficiency: 不是最大化外化，而是最小化足够——只外化真正减少负担的部分
2. Lazy loading / progressive disclosure: 技能详细指导只在任务结构需要时才加载
3. Budget-aware routing: 把上下文分配当作显式优化变量，按任务阶段动态调整 memory/skill/protocol 的占比

安全风险的教训对实际运维者尤其重要：你从社区安装的每个 Hermes skill / MCP server 都是潜在的攻击面。这就是为什么 skill 来源验证和 tap 信任机制如此关键——Paper 2 指出 Claude Code 的多个 CVE 恰恰利用了 pre-trust 阶段的 hook 和 MCP 服务器初始化。

工程实践指南

基于两个论文的框架，总结了五条操作规则：

Rule 1: 四问决策法

每当你考虑「这个能力要不要外化成一个 skill / config / protocol」，依次问四个问题。四个维度都指向同一个方向时决策明确；方向冲突时（比如高频变更 + 低延迟），就需要工程权衡。

Rule 2: 最小充分性

不是最大化外化。一个好的 harness 简化模型的决策问题，而非创造第二个需要模型去理解的复杂系统。新加一个模块前，先问：它真的减少了认知负担吗，还是只是多了一层抽象？

Rule 3: 区分描述性外化与规范性外化

• 描述性（memory/context）: 帮助模型知道「现在是什么状态」
• 规范性（skills/policies）: 告诉模型「应该怎么做」
• 两者共享上下文预算，混合时注意竞争——planning 阶段需要更多 memory，execution 阶段需要更多 skill

Rule 4: 边界是动态变量

模型升级后审计：哪些外化组件可以回撤到参数化？新能力出现后审计：哪些参数化负担应该外化？这就是为什么每次 Hermes 版本升级后，都应该重新审视 config.yaml 里的 compression_threshold 和 skill 加载策略。

Rule 5: 治理层与外化层同步设计

引入一个新 skill 的同时，就设计它的验证机制、回滚策略和版本管理。这是 Hermes skill curator + config backup cron job 存在的深层工程原因——不是运维便利，是架构必需。

实践对照：你的系统已经在外化什么？

你的每一个配置文件本质上都是在做「这个 burden 放在哪里最合适」的系统工程决策——即使你之前没有用 Externalization 这个术语。

总结

论文的核心论点用一句话概括：

Agent 能力的真正分界线不是模型大小，而是「什么留在权重里、什么外化到基础设施中」。决定一个认知负担放在哪里，不看它重不重要，而看四个维度：更新频率、复用半径、治理需求、延迟/上下文成本。边界在双向移动——模型变强时回撤外化，基础设施成熟时新增外化。工程上不是追求最大化外化，而是追求最小充分性：只外化真正减少认知负担的部分。

Harness Engineering 的核心不再是「给模型加更多工具」，而是设计一个认知环境——其中 memory 让 recall 变成 recognition、skill 让生成变成组合、protocol 让自由交互变成结构化契约、permission 让行为约束从概率性变成确定性。