大模型落地一年，我悟了：Harness才是护城河——从O(n²)复杂度看Harness的必然

你听过“驯马”和“赛车”的故事吗？今天咱们聊聊AI界的“Harness”之争。

如果你有一匹能日行千里的神马，但它脾气火爆、不听指挥，动不动就尥蹶子，你能用它来送快递吗？

显然不能。首先得先给它套上缰绳/脚手架（Harness）。

在AI的世界里，大模型就是那匹神马，而Harness，就是那套“控制装备”：包括提示词工程、RAG（检索增强生成）、函数调用、多智能体协作等等。它的作用就是让大模型听懂人话、调用工具、访问数据，最后踏踏实实地把活干完。

近期AI圈对于harness和大模型底层能力的讨论异常热烈。

01 两种世界观：一个要统一宇宙，一个要搭建生态

左派——“Big Model吃掉一切” 相信 Scaling Laws 的终极威力。随着参数、数据和算力的增长，模型会涌现出更强的推理能力和通用性。未来不需要复杂的编排，一个超大模型就是“世界模拟器”，能端到端处理所有任务——一个模型就是整个操作系统。

右派——“Harness为王” 则认为，当前及可预见的未来，大模型存在幻觉、成本高昂、实时性差、无法访问私有数据等固有限制。真正的价值在于如何通过Harness去约束、增强和串联模型能力——RAG、提示工程、函数调用、多智能体协作。

02 大模型单打独斗的天然短板

① 上下文窗口限制与注意力机制的二次方诅咒

现在模型厂商疯狂吹上下文：1M tokens、10M tokens，随便进一个大模型的pricing 报价页面就能深刻感受到厂商要吞下一座图书馆的气魄。

但是，Transformer的注意力机制具有O(n²)的复杂度。当序列长度翻倍，计算量和内存占用要翻四倍。

以4050亿参数的模型为例，128k Token上下文所需的激活值内存，是8k Token场景的16倍。

而且，众所周知，模型会有“lost in the middle”现象这种天生缺陷。

那业界怎么突破百万Token的？常用的手段是上下文并行（Context Parallelism）和环形注意力（Ring Attention）。

将序列拆分到多台GPU上，通过环形拓扑让每台设备在计算本地注意力的同时，向下一台传递键值对，实现计算与通信的重叠。但这需要NVIDIA NVLink（1.8TB/s）或InfiniBand这样的高速互联，否则通信就成了瓶颈。

还有更前沿的：Lizard线性化框架引入亚二次方复杂度的注意力机制，用门控线性注意力+滑动窗口注意力的混合架构，试图逼近softmax attention的效果。在5-shot MMLU上，Lizard比以往方法高出18个点。

简而言之，想用一个模型记住企业所有历史数据？那是跟O(n²)复杂度过不去。Harness里的RAG技术通过向量数据库实时检索最相关的上下文，用有限的窗口处理无限的知识，这才是工程学的智慧。

② 实时性与成本：KV Cache与异构并行的经济学

假如你查个天气都要动用千亿参数的Transformer跑一遍推理，成本得多高？

推理成本的核心瓶颈之一是KV Cache。

在自回归解码中，每一步都要用到之前所有token的键值对，缓存大小随序列长度和并发数线性增长。

阿里云的Mooncake开源项目正是为了解决这个问题：以共享KVCache为中心，实现上下文复用与内存池化，避免重复计算。这套架构在真实业务中据说QPS提升超3倍，GPU利用率从不足40%提升至约75%，内存占用下降约40%（这里待大家自己适配后验证实际情况）。

PagedAttention则是另一种优化，借鉴操作系统的虚拟内存思想，将KV Cache分页管理，减少内存碎片，提升吞吐。

Harness体系里的“路由机制”正是基于这些底层优化：简单问题扔给轻量模型，复杂推理交给大模型，精确计算直接调传统API。让合适的模型干合适的事，边际成本才能降下来。

③ 模型天生没手脚：Function Calling的概率性与确定性鸿沟

大模型本质是“概率预测器”，你让它生成JSON格式的API调用参数，它可能今天输出{ "city": "北京" }，明天就输出{ city: "北京" }。

生产环境的优化方案包括用流式XML替代Function Call。通过XML标签返回工具名和参数，将思考过程与工具推理步骤合并流式输出，既提升了用户体验，又规避了非所有模型都支持Tool Calls的问题。

更深层的架构是MCP（微服务通信协议）与LLM函数调用的结合。

MCP作为服务注册与调度的中间层，维护所有可调用函数的注册信息，支持RoundRobin、Least Load、Cost-aware等多策略负载均衡。

LLM识别任务意图后，通过Function Router路由到最优服务实例，甚至支持异步并发调用和多结果融合。

Harness在这里扮演“翻译+校验+调度”：把用户意图转成严格的API调用，再把返回的确定性数据润色成自然语言。

④ 多模态只是“对齐”，不是“融合”：编码器解耦的硬核真相

现在的多模态模型看起来很牛，既能看图又能读文。但底层实现里，视觉编码器（如ViT）和文本解码器之间隔着巨大的工程鸿沟。

现代大型多模态模型（LMM）引入了一个独特瓶颈：在任何文本生成开始之前，所有图像必须由视觉编码器处理。

这个编码器阶段（计算密集、高并行度）与文本预填充（高内存带宽、大型GEMM）和解码（极度依赖内存带宽、序列化）的特征截然不同。

在同一GPU上运行三个阶段会导致根本性的效率低下。

解决方案是编码器解耦（Encoder Disaggregation）：

• 将视觉编码器分离为独立的可扩展服务
• 请求N的编码器可以运行，而请求N-1已处于预填充或解码阶段——流水线并行
• 纯文本请求完全绕过编码器，永不等待
• 编码器GPU根据多模态图像量扩展，预填充/解码GPU根据请求率和输出长度扩展

编码器输出还可缓存复用，常用图像的嵌入只算一次，进一步降低首字延迟。

工程上更聪明的做法还是Harness架构：需要看图表时调专门的OCR模型，需要识图时调图像描述模型，最后把结果汇总给大模型。效果往往比一个模型硬啃像素更好。

03 Harness才是让AI落地的“定海神针”

RAG：向量数据库作为“外挂大脑”

RAG的核心流程是：检索-增强-生成。背后的核心技术是向量数据库：通过嵌入模型（如BGE、Sentence-BERT）将文本转化为高维向量，再用余弦相似度等算法实现语义级检索。与传统数据库的关键词匹配不同，向量检索能理解“苹果手机”和“iPhone”是同一回事。

索引算法如HNSW、IVF支持亿级向量的毫秒级检索。混合检索策略（向量+关键词）加上元数据过滤（如按更新时间筛选），再通过CrossEncoder重排，能显著提升检索精度。

Agent：复杂任务的规划与推理失衡矫正

举个简单的例子，“帮我订下周去巴黎的机票和酒店”。

Harness里的Agent框架（如ReAct模式）会把它拆成几步：查日历→查航班→比价→下单。每一步都能观察、能干预、能调试。

但生产环境中会遇到“推理失衡（Reasoning Miscalibration）”问题：模型在不关键的步骤上反复思考（过度思考Overthinking），在真正决定成败的步骤上一带而过（思考不足Underthinking）。

最新研究提出了Plan-and-Budget框架和BAM（Budget Allocation Model）。核心思想是：推理预算应该分配给那些一开始不确定性高、但又确实能通过思考被有效消除的步骤。通过规划拆解子问题，采用前置衰减的预算分配策略——早期关键步骤多分配token，后期确定步骤逐步减少。

04 未来格局：模型当内核，Harness做操作系统

总结下，或许未来的AI系统最终会是分层架构：

• 底层（Model as Kernel）：大模型像Linux内核一样，提供基础的推理、理解、生成能力。它会越来越通用、越来越便宜。“吃掉”的是过去需要多个小模型拼凑的泛化理解能力。
• 上层（Harness as OS）：在模型之上，是一套类似操作系统的Harness层，负责：
  • 内存管理：管理上下文窗口和KV Cache
  • 文件系统：对接外部的向量数据库
  • 设备驱动：通过MCP调用各种外部API和工具
  • 进程调度：协调多个Agent协同工作，实现Plan-and-Budget式的智能算力分配