从薄Harness到厚协作：大模型时代的新基建
只有真正在一线开发过CLI、调试过Agent Swarm的从业者才会明白：大模型并不能解决所有问题。
当前AI编程领域正出现明显的两极分化：一边是Pi这类主打极简Agent的路线，只用少量Prompt和基础工具，主张精简流程、控制成本，让大模型自主发挥；另一边则是Agent Swarm、多智能体协作方向，系统架构越来越复杂。这引发了行业内广泛讨论的核心问题：底层的Harness是否终将消失？
不少人认为Pi的爆火印证了“模型派”的观点，觉得随着大模型能力不断增强，外部的Harness迟早会被彻底淘汰。但前Kimi CLI负责人、Raft创始人stdrc提出了反常识的核心观点：模型越强，Harness反而越厚，只是这层“厚度”的内涵发生了变化。
过去的Harness更多是为模型弥补能力短板，比如填充大量Prompt、封装基础工具来修正模型的输出问题；而未来的Harness则会转向解决复杂业务场景下的协作与管控需求，复杂度从“能力补全层”转移到了“协作管理层”。
被误解的Harness
要理清Harness的演化逻辑，首先需要破除行业内普遍存在的两层认知误区。
误解一：Harness终将被训进模型，彻底消失
很多人觉得未来大模型能力无敌，Harness会被完全整合进模型内部。但从一线工程实践来看，这一观点完全是倒果为因。stdrc曾直言：“说harness会被训到模型里的人，肯定是没做过harness的。”他从三个维度拆解了这一误区：
首先，并非模型变强淘汰Harness，而是Harness先搭建框架，模型才有了学习和实践的场景。就像人类社会先有了分工制度，才逐步学会协作，Harness是模型的训练场，没有外部框架的支撑，模型根本无法练习协作能力。
其次，智能水平越高，所需的工具和管控框架反而越复杂。人类大脑进化后并没有退化成原始状态，反而催生了法律、互联网等复杂的协作系统。模型能力提升后，解锁的真实业务场景也更加复杂，底层能力被内化的同时，上层会出现更多需要Harness管控的新场景。
最后，单任务场景可以依赖模型，但复杂业务场景完全不现实。面对长流程、多智能体、需要持续追踪状态的真实业务，仅靠单个大模型的记忆能力必然会出现遗漏、错误甚至逻辑冲突的问题。这并非模型聪明与否的问题，而是系统工程的边界问题，本就不该让单个模型硬扛所有任务。
误解二：模型越强，Harness就会越薄
还有一种流传很广的说法：模型能力越强，Harness就会越薄。这种观点看似合理，因为现在的底层提示词确实在减少，很多复杂的工具封装也不再必要。但stdrc认为，这种观点“情有可原，但缺乏想象力”，它只看到了底层Harness的减法，却忽略了上层Harness的加法。
不可否认，随着模型基础能力提升，大量“补丁式Harness”会逐步退场：比如为了防止模型格式报错设置的强制约束、为了教会模型使用工具编写的长篇Prompt、以及死板的报错重试机制等。这些为了弥补模型缺陷的底层设计，确实会越来越薄，甚至完全消失。
但这并非Harness的消亡，而是复杂度的向上迁移。当模型不再需要人类程序员“擦屁股”时，反而需要建立一套全新的协作法则。更强的模型会解锁更复杂的任务场景，进而催生出新的Harness需求：比如如何让多个Agent互相配合、跨会话状态如何同步、如何实现主动的记忆管理、动态权限与不同系统的对接标准如何制定等。这些需求在弱模型时代根本不会出现，自然也不会被纳入大众对Harness的传统认知。
重新理解Harness：一场“阴阳共生”的动态演化
纠正这些误解后，需要回到核心问题：如何定义真正的Harness？大众常将Harness窄化为“System Prompt + 工具调用封装”，但从完整的工程定义来看，Harness是包裹在模型外层的运行时工程管控层，核心解决的是“模型如何稳定、持续、可控地与真实世界交互”的问题，它由四个核心要素构成：Agent执行循环、上下文与状态管理、工具与资源调度、以及安全与边界治理。
Harness的范围一直在动态扩大：从早期模型能力较弱时，仅负责拼装简单提示词；到中期模型变强后，演化出多工具并行、子智能体调度等能力；再到如今模型能力极强的阶段，Harness开始涉足智能体集群、跨系统状态同步、多Agent任务交接等更上层的场景。
stdrc将模型与Harness的关系比作“阴与阳”，这是一种此消彼长、共同进化的动态关系：
局部功能的“内化”，是阴的扩张。当模型基础能力增强，一部分底层Harness会被模型取代。比如在Kimi CLI的实践中，stdrc曾计划移除专用的subagent调度机制，改为由模型直接通过bash终端实现子任务拆分；同时移除原生的并行工具调用，改为由模型生成工具调用脚本来实现并行。这是模型能力向外扩张的必然结果，也是外界感知到“Harness变薄”的真实原因。
上层需求的“生长”，是阳的延伸。模型能力每提升一个台阶，就会解锁更复杂的业务场景，进而催生出更上层的Harness需求。单任务能力成熟后，催生了多智能体协作需求；单会话能力成熟后，催生了跨会话记忆与主动上下文回溯需求。在这场阴阳博弈中，智能水平越高，与现实世界的交互摩擦力就越大。
这个过程没有终点，就像人类大脑比猿类更发达后，催生了语言、文字、计算机、互联网等更复杂的交互系统。智能水平越高，与世界的交互方式就越复杂，Harness作为Agent智能的“交互基础设施”，只会随智能升级而持续向外延伸。
有开发者从哲学层面评价Pi的方案本质是“薄层提示词 + 厚层Harness”，并指出模型如同狄俄尼索斯式的混沌与创造力，而Harness则是阿波罗式的秩序与结构，二者是永恒的互补。无论是从工程演化的视角，还是本质定义的视角，Harness都将必然存在，不会消失。
从0到1的验证：Kimi CLI里的Harness生长史
stdrc的“复杂度迁移”理论并非纸上谈兵，而是基于Kimi CLI从0到1的完整工程实践。早期的Kimi CLI没有参考任何开源框架，完全从零搭建，从基础的单工具调用，逐步演化出并行调用、子智能体调度、状态管理等功能。
到了迭代后期，团队做了一次大胆的“减法实验”：移除了专门用于subagent调度的代码，也放弃了原生的并行控制机制，完全交由模型自行通过脚本处理。结果证明，只要模型能力达到临界点，底层的Harness确实可以被丢弃。
但底层代码刚移除完毕，团队就遇到了更棘手的问题：Harness的边界不能仅停留在单个Agent内部，多个智能体之间如何通信、如何交接任务、如何制定统一的通信协议和分工规则？于是，团队开始向上层扩展，提出了多智能体Harness的架构概念，搭建了Agent任务交接、通信协议、分工机制，同时研究跨会话通信、主动上下文压缩、上下文回溯等状态管理技术。这些探索正是后来Raft的技术前身，也与后续Claude推出跨会话对话、行业集体转向多智能体的趋势高度吻合。
正是这种从零开始的演化经历，让团队能够清晰观察到Harness复杂度的迁移规律，而非被某一个静态阶段的认知所局限。
创业践行：Raft就是下一代“厚Harness”
离开原团队后，stdrc创办了Raft。如果说Kimi CLI是一次Harness演化的实验，那么Raft就是对“上层厚Harness”架构的直接实践。在开发Raft的过程中，stdrc大胆移除了自己曾经搭建的单Agent运行时，既不编写Agent循环，也不封装基础工具，而是直接将市面上成熟的Claude Code、DeepSeek等产品作为“团队成员”接入平台。
他的逻辑很清晰：底层的单Agent能力已经足够成熟，模型已经能够内化这部分Harness的功能，再重复造轮子没有价值。Harness的下一个战场，不在单个Agent内部，而在多个Agent之间的协作层面。Raft的全部研发精力都集中在解决多智能体协作的系统性难题上，具体体现在四个核心维度：
1. 给AI赋予独立身份与记忆能力：模型仅能处理单次回答，但Raft负责让每个Agent拥有独立的进程、记忆和工作习惯，即使任务中途中断，后续也能无缝接续。
2. 建立协作规则与分工机制：模型本身不会主动发起团队协作，Raft借鉴了人类职场的协作模式，通过类似工作群的“频道”隔离聊天场景，支持任务认领、调整和交接，所有操作步骤都留有痕迹，方便相关人员随时查阅。
3. 打破厂商间的通信壁垒：Raft开发了一套跨厂商的统一通信协议，让不同模型厂商的产品可以在同一个工作区内按照标准对话，这一工作单靠某一家模型公司是无法完成的。
4. 打造人机协同的工作区：在这里，Harness不再只是一段代码，而是演变为整个团队的工作流和权责体系。平台的定价模式也很特别，每个Agent仅按0.1个人类席位计算，支持跨团队共享。到这一步，Harness已经从单纯的技术工具，转变为团队日常沟通和协作的规则本身。
最后，stdrc对Harness的终局提出了一个有趣的观点：“当一切都是Harness的时候，它其实就隐形了。”比如在使用Raft时，用户不会觉得自己在面对一套复杂的Agent调度后台，它看起来更像是一款将AI纳入协作的办公软件，所有的状态同步、权限控制都隐藏在产品的直观操作背后。
就像我们日常在公司上班时，不会时刻念叨“公司制度、法律是人类社会的Harness”一样。当AI员工真正普及后，这层最厚的Harness会彻底融入日常工作流，成为像电网、自来水一样的基础设施。
回头看最开始的问题——“到底是模型吞噬一切还是Harness持续生长”，或许我们都低估了技术演进的维度。真正的行业老手都会着眼于更高维度的竞争：如何在更上层的协作场景和复杂业务中，打造出别人无法复制的核心壁垒。
