Kimi 前 CLI 负责人：模型越强，Harness 反而越厚，复杂度正从能力层转向协作层

事件概述

AI 编程圈近期出现两极分化：一边是主打极简 Agent 路线的 Pi，Prompt 不到 1000 Token，只提供 4 个基础工具；另一边是越来越复杂的 Agent Swarm 与多智能体协作系统。由此引发争论：底层的 Harness 是否会被大模型取代？

前 Kimi CLI 负责人、Raft 创始人 stdrc（Richard Qian）给出反常识判断：模型越强，Harness 反而越厚，只是“厚度”从能力层转移到了协作层。

两个被误解的 Harness 认知

误解一：Harness 终将被训进模型，彻底消失

stdrc 认为，这种说法“倒果为因”。真正做过 Harness 的人会知道：

• 不是模型变强淘汰 Harness，而是 Harness 先把路铺好，模型才有地方练习协作能力。
• 智能越高，需要的工具反而越复杂。人类大脑进化后没有回归原始，而是发明了法律、互联网等更复杂的系统。
• 单任务可以靠模型，但长流程、多智能体、需要随时查看状态的复杂业务，纯靠模型记忆必然出错。这是系统工程问题，不该让单个模型硬扛。

误解二：模型越强，Harness 就会越薄

这个观点看似成立，因为底层提示词确实在变少，工具封装也简化了。但 stdrc 认为它“情有可原，但缺乏想象力”——只看到了底层减法，没看到上层加法。

随着模型基础能力提升，大量“补丁式 Harness”会退场，例如强制输出格式约束、长篇工具使用 Prompt、死板的报错重试机制。但这并非 Harness 消亡，而是复杂度向上迁移：更强模型解锁更复杂场景，催生新的 Harness 需求，例如多个 Agent 如何配合、跨会话状态同步、主动记忆管理、动态权限与跨系统对接标准等。

重新定义 Harness：阴阳共生

stdrc 将 Harness 定义为包裹在模型外层的运行时工程管控层，核心解决“模型如何稳定、持续、可控地与真实世界交互”。它由四部分构成：Agent 执行循环、上下文与状态管理、工具与资源调度、安全与边界治理。

模型与 Harness 的关系被比作“阴与阳”：

• 阴的扩张：模型基础能力增强，部分底层 Harness 被内化。例如在 Kimi CLI 中，stdrc 曾计划移除专用 subagent 调度机制，改由模型直接通过 bash 终端拆分任务；同时移除原生并行工具调用，改为模型自己生成工具调用脚本。
• 阳的延伸：单任务能力成熟后，催生多智能体协作；单会话成熟后，催生跨会话记忆与主动上下文回溯。智能水平越高，与现实世界的摩擦力越大，Harness 只会持续延伸。

Kimi CLI 中的 Harness 生长史

Kimi CLI 早期从零开始，逐步长出并行调用、子智能体、状态管理。迭代后期，团队做了一次“减法实验”：砍掉专门负责 subagent 调度的代码，放弃原生并行控制，完全让模型自己写脚本处理，结果发现模型能力到达临界点后，底层 Harness 确实可以丢弃。

但底层刚删完，新的问题出现：多个智能体之间怎么通信、交接任务、定义分工？团队由此转向多智能体 Harness 架构，研究任务交接、通信协议、分工机制，以及跨会话通信、主动上下文压缩和回溯。这些探索后来成为 Raft 的技术前身。

Raft：下一代“厚 Harness”

离开月之暗面后，stdrc 创办 Raft，直接实践“上层厚 Harness”。Raft 不写 Agent 循环，也不封装基础工具，而是将 Claude Code、DeepSeek 等成熟产品作为“团队成员”接入，专注多智能体协作的系统性问题。

其“厚 Harness”体现在四个维度：

1. 独立进程与记忆：每个 Agent 有自己的进程、记忆和工作习惯，任务中断后可在不同时间无缝接上。
2. 分工与留痕：通过类似“频道”的方式隔离聊天，支持任务认领、认降和交接，所有步骤留痕，便于人类查账。
3. 跨厂商通信协议：让 Claude、DeepSeek 等不同模型在同一个工作区内用统一标准对话，这种协议单一模型公司不愿做。
4. 人类与 AI 协作工作区：Harness 从代码变成团队的工作流和权责体系。定价上，每个 Agent 算 0.1 个人类席位，支持跨团队共享。

终局：Harness 会“隐形”

stdrc 对 Harness 终局的判断是：“当一切都是 Harness 的时候，它其实就隐形了。” 在使用 Raft 时，用户不会感到面对一套复杂的 Agent 调度后台，而是看到把 AI 拉进来的办公软件；状态同步和权限控制被藏在产品直觉之后。一旦 AI 员工普及，最厚的 Harness 会融入日常工作流，像电网和自来水一样成为基础设施。