作者丨高允毅
编辑丨岑峰
当前 AI 编程领域正呈现显著的两极分化趋势。一端是以 Pi 为代表的“极简 Agent 派”，主张通过少量 Prompt 和基础工具让模型自由发挥；另一端则是日益复杂的 Agent Swarm 和多智能体协作系统。
这一现象引发了行业核心争议：底层的 Harness（管控层）是否会随模型进化而消失？
尽管有人认为大模型的增强将取代外部 Harness，但前 Kimi CLI 负责人、Raft 创始人 stdrc（Richard Qian）提出了反常识观点：模型越强，Harness 反而越厚。
Harness 的“厚度”内涵正在发生转变。过去，厚重的 Harness 旨在弥补模型能力缺陷；未来，其厚度将源于处理复杂脏活累活的需求，即解决多智能体间的协作与上层管控问题。
简而言之，复杂度正从“能力层”向“协作层”迁移。
01 被误解的 Harness
厘清 Harness 的演化逻辑，需先破除行业内普遍存在的两层误解。
误解一：Harness 终将被训进模型并彻底消失
一种主流观点认为，随着大模型能力无敌化，Harness 将被内化至模型中从而消亡。stdrc 指出这是典型的倒果为因：“声称 Harness 会被训入模型的人，往往未曾亲手构建过 Harness。”
从一线工程视角分析，原因有三：
首先，是 Harness 为模型铺路，而非模型淘汰 Harness。如同人类社会先有分工制度才有协作效率，Harness 是模型的训练场。缺乏外部框架，模型无从习得协作能力。
其次，智能越高，所需工具越复杂。人类大脑进化并未导致回归原始，反而催生了法律与互联网。模型能力增强解锁了更复杂的真实场景，底层能力内化后，上层必然涌现新的管控需求。
最后，单任务可依赖模型，复杂业务则不然。面对长流程、多智能体及动态状态的真实业务，仅靠单个模型记忆必然导致遗漏或冲突。这是系统工程问题，不应由单一模型硬扛。
误解二：模型越强，Harness 就会越薄
另一种流行观点认为模型增强会导致 Harness 变薄。stdrc 认为该观点“情有可原但缺乏想象力”，因为它只看到了底层的减法，忽视了上层的加法。
不可否认，随着模型基座能力提升，大量“补丁式 Harness"正在退场：如强制格式约束、冗长的工具教学 Prompt 及死板的重试机制等。这些为弥补模型缺陷而生的底层设计确实在变薄甚至消失。
但这并非 Harness 的消亡，而是复杂度的向上迁移。
当模型不再需要人工“擦屁股”时，亟需建立新法则以应对更强模型解锁的复杂场景：多 Agent 协同配合、跨会话状态同步、主动记忆管理、动态权限及异构系统对接标准等。这些在弱模型时代不存在的需求，构成了新一代 Harness 的核心。
02 重新理解 Harness：一场“阴阳共生”的动态演化
纠正误解后，需回归核心定义：Harness 是包裹在模型外层的运行时工程管控层，旨在解决“模型如何稳定、持续、可控地与真实世界交互”的问题。其四大核心要素包括：Agent 执行循环、上下文与状态管理、工具与资源调度、安全与边界治理。
Harness 的边界持续扩张：从早期拼装简单提示词，到中期演化出多工具并行与子智能体调度，再到如今应对智能体集群、跨系统状态同步及多 Agent 任务交接。
stdrc 将模型与 Harness 的关系比作“阴与阳”，这是一种此消彼长、共同进化的动态关系。
局部功能的“内化”，是阴的扩张
模型基础能力增强促使部分底层 Harness 被取代。例如在 Kimi CLI 实践中，团队曾计划移除专用的 subagent 调度机制，改由模型直接通过 bash 终端拆分任务；移除原生并行调用，改为模型生成脚本实现并行。这是外界感知"Harness 变薄”的真实原因。
上层需求的“生长”，是阳的延伸
模型每上一个台阶，便解锁更复杂业务场景，催生上层 Harness 需求。单任务成熟催生多智能体协作，单会话成熟催生跨会话记忆与主动上下文回溯。
在这场博弈中，智能水平越高，与现实世界的摩擦力越大。如同人类发明语言、文字及互联网以适配发达的大脑，Harness 作为 Agent 智能的“交互基础设施”，必将随智能升级持续向外延伸。
开发者 Monk Zero 从哲学层面评论道：Pi 方案本质是“薄层提示词 + 厚层 Harness"。模型如同狄俄尼索斯式的混沌与创造力，而 Harness 则是阿波罗式的秩序与结构，二者永恒互补。
无论是从工程演化还是本质定义视角，Harness 都必将存在且持续生长。
03 从 0 到 1 的验证：Kimi CLI 里的 Harness 生长史
stdrc 的“复杂度迁移”理论基于 Kimi CLI 从零到一的完整工程实践。早期 Kimi CLI 无参考框架，完全从零生长出并行调用、子智能体及状态管理功能。
迭代后期，团队进行了一次大胆的“减法实验”：砍掉专门负责 subagent 调度的代码及原生并行控制，放手让模型利用脚本自行处理。结果证明，当模型能力达到临界点，底层 Harness 确实可被丢弃。
然而，底层简化后立即暴露出新难题：多智能体间如何通信、交接任务及定义分工协议？团队随即转向“上层加码”，构建多智能体 Harness 架构，探索任务交接、通信协议、分工机制及跨会话状态管理技术。
这些探索成为后来 Raft 的技术前身，其方向判断也与行业转向多智能体的趋势高度吻合。正是这种从零生长的经历，使其清晰观察到 Harness 复杂度的迁移规律。
04 创业践行：Raft 就是下一代“厚 Harness"
离开月之暗面后，stdrc 创办 Raft，直接实践“上层厚 Harness"架构。Raft 摒弃了单 Agent 运行时，不重写 Agent 循环或封装基础工具，而是将 Claude Code、DeepSeek 等成熟产品作为“团队成员”接入。
其逻辑在于：底层单 Agent 能力已足够成熟并可内化相应 Harness，重复造轮子毫无价值。Harness 的新战场在于多智能体之间的系统性协作难题。
Raft 的“厚 Harness"体现在四个核心维度：
1. 赋予 AI 身份与记忆：模型仅负责单次回答，Raft 确保每个 Agent 拥有独立进程、记忆和工作习惯，支持任务中断后的无缝接续。
2. 确立规矩与分工：引入类似工作群的“频道”隔离聊天，支持任务认领、降级和交接，全流程留痕以便追溯。
3. 打破厂商壁垒：建立跨厂商通信协议，使不同模型能在统一标准下于同一工作区对话。
4. 构建人机协作工作区：Harness 在此已演变为团队的工作流和权责体系。每个 Agent 仅计为 0.1 个人类席位，支持跨团队共享。
stdrc 对 Harness 的终局提出有趣观点：“当一切都是 Harness 的时候，它其实就隐形了。”
在使用 Raft 时，用户面对的并非复杂的调度后台，而是一个融入 AI 的办公软件。所有状态同步与权限控制均隐藏在产品直觉之后。
正如人类日常工作中不会时刻提及“公司制度与法律”，一旦 AI 员工普及，这层最厚的 Harness 将彻底融入工作流，成为像电网、自来水一样的基础设施。
回顾最初的问题，“模型吞噬一切”或"Harness 持续生长”或许都低估了技术演进的维度。真正的竞争高地，在于如何在更高维度的上层协作与复杂业务场景中，构建不可替代的新壁垒。
参考链接：https://x.com/istdrc/status/2086540261036007794
