AI 的另一半：生产级智能体系统中那 98.4% 的非模型工程

一个很少被讨论的事实是：在 Claude Code 的代码仓库中，真正的模型决策逻辑只占了 1.6%。剩下的 98.4%，是一套精密的工程机械装置——权限系统、五层上下文压缩、工具路由、安全护栏、生命周期钩子、成本观测回路。

Anthropic 把这套结构叫做 Agentic Harness，社区把围绕它的工程实践叫做 Harness Engineering。这是继 Prompt Engineering、Context Engineering 之后的第三代表工程范式，也是 2026 年 AI 工程领域最值得深入理解的方向。

三代工程范式的演进

回顾过去三年 AI 工程的演变路径，能看到一条清晰的递进链：

Prompt Engineering（2022-2024）——核心关注单次输入的措辞。工程师的工作是让模型"听懂"我们的意图：写一个更好的 system prompt，加几个 few-shot 例子，用 chain-of-thought 引导推理方向。这是第一代的工作方式，本质上是把 AI 当成一个指令驱动的函数。

Context Engineering（2024-2026 上半年）——视野从单条 prompt 扩展到了模型在整次会话中能"看到"的全部信息。RAG 检索注入、工具定义编排、记忆压缩与注入、对话历史管理。Anthropic 在 2025 年 9 月发布的 "Effective Context Engineering for AI Agents" 把这个范式正式概念化。

Harness Engineering（2026 中期至今）——Martin Fowler 在 2026 年 2 月明确提出，对于真正的 agentic 系统，需要关注的不只是 context（模型能看到什么），还包括 harness（模型周围的机械执行环境）。Hooks、Permission Gates、Sandbox、Verification Loops——这些确定性的、不依赖模型判断的工程机制。

这三个阶段不是替代关系，而是层层包含。Prompt Engineering 是 Context Engineering 的子集，Context Engineering 是 Harness Engineering 的子集。核心洞察是：决定一个 AI Agent 能否可靠产出的，不是模型本身的能力，而是包裹在模型外面的那套东西。

LangChain 团队做过一个实验：同一个 GPT-4 模型，仅修改 harness 层面（不换模型），任务完成率从 52.8% 提升到 66.5%。提升了将近 14 个百分点。模型没变，变的是环境。

成本工程：Prompt Caching 的真实威力

在 LLM 应用的成本结构中，有一个长期被忽视但影响巨大的优化方向：Prompt 缓存。

典型 LLM 应用的每次请求载荷结构是这样的：系统提示（通常几千 token）、知识库内容（可能几万 token）、工具定义（几百 token），再加上用户的新消息。如果你有一万个活跃用户每天对话十次，那那些重复的系统提示会被重复处理十万次——每次都要消耗算力、产生费用、增加延迟。

Prompt 缓存解决的就是这个问题：重复使用的上下文部分只处理一次，后续请求直接复用 KV Cache。

实际工程数据：

• 缓存命中的 token 成本降低 70-90%（Claude 提供 90% 折扣，GPT-4o 提供 50% 折扣）
• 首 Token 延迟降低 20-70%（取决于缓存命中率和命中位置）

前缀约束的工程权衡

Prompt 缓存有一个关键的工程约束：只对前缀完全相同的内容生效。这意味着架构决策既影响功能，也直接影响成本。

最佳实践是把稳定不变的内容（系统提示、工具定义、知识库文档）放在前面，动态内容（用户消息、实时数据）放在后面。如果系统提示中包含了时间戳或随机化内容，整个前缀的缓存命中率会瞬间归零。

这对系统设计有深远影响：你不能简单地在 system prompt 里加 "今天的日期是 {date}"，而需要通过工具调用让模型获取实时信息，或者把动态信息放在 conversation 的末尾而非前缀中。

KV Cache 与推理成本

从底层来看，Prompt 缓存复用的是 Transformer 推理过程中计算的 Key-Value 矩阵。理解 KV Cache 的成本结构对架构设计至关重要：

KV Cache 显存占用 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 数据类型字节数

以 LLaMA-3 70B 为例（80 层、64 头、128 维 head_dim、4096 序列长度、FP16），单个请求的 KV Cache 就接近 11GB。这意味着在 80GB 的 A100 上，不做优化的情况下并发处理能力极为有限。

vLLM 的 PagedAttention 借鉴了操作系统的虚拟内存管理思想：不为每个请求预分配连续的最大长度显存，而是按需分配、动态回收。这将显存利用率从传统实现的约 20-40% 提升到接近 100%，吞吐量直接翻倍。

更进一步，KV-cache aware 路由让推理集群智能地将请求路由到已经缓存了相同前缀的 GPU 节点，避免不必要的重复计算。这相当于在负载均衡层增加了缓存一致性的语义。

非确定性：AI 工程的核心挑战

如果说成本问题是有确定解的优化（缓存命中就是省了钱），非确定性才是 AI 工程中真正的"hidden half"——它无法被"解决"，只能被"管理"。

不确定性的三个来源

模型采样的内在随机性：LLM 的推理本质上是一个采样过程。即使 temperature 设为 0，GPU 硬件的浮点运算非确定性（并行归约顺序差异、CUDA atomic 操作等）也会导致微小差异被放大。

实际上，最近的研究表明：LLM 推理中的不确定性并非主要来自 temperature 采样本身，而是来自"内核实现随批次大小/切片策略改变而改变累加顺序"——即缺乏批次不变性（batch-invocation）。同一个请求，在单卡上跑和在大批次中跑，经过的 CUDA kernel 计算路径可能不同，导致浮点结果在数值精度层面就产生了差异。

环境状态的不可控性：生产环境中，模型的输出依赖大量外部状态——API 返回值、数据库内容、文件系统状态、并发时序。这些因素完全不在模型提供商的控制范围内。

上下文窗口的动态性：随着 Agent 运行更多轮次，上下文窗口的内容持续增长和变化。不同的压缩策略会丢弃不同的历史信息，导致模型"看到的世界"发生漂移。

工程应对策略

传统软件的可靠性建立在确定性输入输出关系上：相同输入必定产生相同输出。AI 系统的非确定性意味着传统测试方法几乎全部失效——你不能用一个固定的 expected output 写断言。

分层测试策略被证明是目前最有效的方案：

• 确定性组件 100% 覆盖：Harness 层面的所有逻辑（缓存策略、路由决策、错误回退、权限检查）都是确定性代码，可以用常规单测覆盖，CI 必须全部通过
• 模型输出 语义等价测试：不用 exact match，而是用"语义在误差范围内"的评估方式——对于分类任务用 accuracy，对于生成任务用 similarity embedding，对于 Agent 用行为轨迹匹配
• 对抗性安全测试：红队测试 + 自动化 prompt injection 用例库 + 输出危害性自动评分
• 在线 Shadow Testing：新模型版本使用旧模型的 traffic replay 做对比，不直接影响用户

对于交付严格一致性输出要求的场景（金融、医疗、法律），需要在架构层面实现额外的确定性保障：固定模型和硬件组合、使用 batch-invariant 内核实现、多次采样后投票，或者让模型输出结构化 JSON 后在业务层面做第二轮确定性解析和校验。

基础设施模式：为 AI 而生的工程控制面

2026 年的 AI 生产基础设施，已经演化出一系列专门针对模型系统特性的工程模式。

Circuit Breaker for LLM

传统 Circuit Breaker 保护下游服务不被压垮，AI 场景下的熔断器需要额外考虑几件事：模型响应超时本身就可能是随机波动的（不像 HTTP 500 那样明确），错误分类更困难（什么算"失败"？格式错误？幻觉？内容不适合？），重试需要指数退避和 jitter 防止惊群。

Model Router (LLM Gateway)

一个生产级的 Agent 系统很少只使用一个模型。推理模型（大参数高延迟）负责复杂推理，快模型（小参数低延迟）负责日常对话，专用模型处理特定任务（代码生成、翻译、摘要）。

模型路由器的责任是根据请求的特征——上下文长度、任务类型、用户预算、延迟要求、缓存状态——选择最优模型。这本身是一个在线优化问题，需要在成本、速度、质量之间做实时权衡。

可观测性体系

AI 系统的监控维度远超传统服务：按模型的 token 用量追踪、缓存命中率和节省金额、幻觉检测通过率、工具调用成功率和耗时分布、上下文窗口使用率、输出结构合规率。

更重要的是 trace-level 可观测性：一个复杂 Agent 的完成路径可能嵌套了数十次模型调用和工具调用，每一跳的输入输出都需要被记录，以便事后审计和调试。OpenTelemetry for AI、LangSmith、Helicone 等工具都在这个方向发力。

Harness 作为产品

将视角再拉远一层，我们会发现一个有趣的趋势：Harness 本身正在成为产品。

Cursor 的成功很大程度不是因为模型比别人强，而是因为它的 harness 做得好——文件索引策略、上下文裁剪规则、编辑操作的 diff 精确度、撤销 Guardrails 的设计。Claude Code 在代码生成领域的出色表现，98.4% 的工程基础设施功不可没。

这带来了一个对产品团队的启示：如果你正在构建 AI 产品，不要把所有 Prompt Engineering 的努力都花在那 1.6% 上。真正的竞争壁垒，逐渐转移到了那 98.4% 上——你的缓存架构设计、你的上下文管理策略、你的失败兜底路径、你的成本控制循环。

结语

回到 AI 工程能力框架的 8 个支柱（Prompt、RAG、Context、Fine-tuning、Agents、Deployment、Optimization、Evals/Observability），其中有 6 个属于 Harness 层面的范畴。

这并不意味着模型能力不重要——它永远是一个乘数因子。但当所有厂商的模型能力快速趋同、当开源模型不断追赶闭源时，真正区分优秀 AI 产品和普通 AI 产品的，是那套"包裹一切"的工程机械装置。

Loop Engineering 解决了"如何让 AI 自我改进"的上层问题；Harness Engineering 解决了"如何让 AI 在真实世界中可靠存活"的底层问题。两者共同构成了 2026 年 AI 生产系统的完整图景。

*相关文章推荐：上一篇我们讨论了 Loop Engineering 范式，这次我们将视角下沉到了它得以运行的基础层——正是这套 Hidden Half，让 Loop 能够真正转起来。*