Z Tech｜我们与开源顶流实验室一起聊了聊 Harness Design

引言

过去一年，大模型的能力曲线几乎是指数上升的——推理更强、工具调用更稳、上下文窗口越撑越大。但一个越来越尖锐的问题也随之浮出水面：模型变强了，可承接它的那层东西在哪？

Agent 能写出漂亮的方案，却不记得昨天踩过的坑；能调用十几个工具，却在跨会话的任务里迷失方向。模型的能力天花板在快速抬高，但 Agent 真正落地干活所需的基础设施——身份、记忆、协作、状态管理——仍然大面积缺席。这正是行业过去半年密集讨论 Harness Design 的真实背景：瓶颈不再是模型不够聪明，而是我们还没有为足够聪明的模型准备好它该生长的土壤。

这期对谈，我们和星舟无界的创始团队，石宇（左）、汤嘉斌（右），以及黄超（中），围绕一个核心问题展开：当模型能力溢出，Agent 的下一层基础设施到底该长什么样？

CEO 石宇曾是微软产品经理，曾主导小冰视觉生成业务线，主导微软多模态Copilot 从 0-1，微软 AgentOS 创始产品经理；联合创始人兼 CTO 汤嘉斌博士就读于香港大学，是 AutoAgent、OpenHarness 等知名Agent项目的核心作者，研究成果入选 NeurIPS Spotlight；联合创始人兼首席科学家黄超是香港大学助理教授和博士生导师，带领实验室开源 nanobot、LightRAG、AutoAgent等一系列知名项目，在 GitHub 上累计获得超过15万星标。

他们分别从系统哲学、工程原则和开源生态三个视角，给出了自己的判断。

模型跑太快，基础设施被甩下车

ZP：为什么行业突然开始讨论 Harness Design？

石宇：主要还是因为模型的能力上限已经远超过了使用它的基础设施.

这在历史上其实发生过。比如 1990 年代初，CPU 的计算能力已经足够强大，但让这些计算能力连接起来、发挥作用的那层东西还没准备好。今天 Harness 的讨论，本质上是同一件事的重演。

当 Agent 已经在很多场景下达到 “Single Player” “Task-level”的满分时, 我们才第一次真正感受到“它做完了,然后呢？” 这个问题的重量。一个 Agent 可以给出一个聪明的回答，但这和完成一个需要持续数小时、跨越多个会话的复杂任务是两回事。模型能力的提升，反而让基础设施的缺失暴露得更彻底。

所以，这半年的讨论表面上是在谈 Harness，实际上是整个行业第一次认真面对一个问题：我们到底在构建一个什么样的系统，而不仅仅是一个更聪明的工具。

ZP：站在开源实践的角度看，为什么这些问题会在这一阶段更早暴露出来？

黄超：开源最大的好处就是，它能直接面向开发者社区，把学术研究和实际应用之间的差距，也就是 gap，快速暴露出来。

当我们把一个研究成果做成开源项目放出去，社区的反馈会立刻告诉我们，哪些问题是大家真正关心的，哪些方向是行业里真实的痛点。这比在实验室里闭门造车要直接得多。

尤其是在 AI Agent 这个领域，这一点特别关键。Agent 技术太复杂了，里面有一堆推理、工具调用、记忆、多模态交互的环节。你不把它丢到真实场景里，让开发者真正上手去跑，你根本不知道哪个环节会卡脖子，用户到底需要什么功能。

而且，AI Agent 的价值很大程度上就看它的生态有多丰富，看它在各种真实任务里的完成度怎么样。开源恰恰是催生这种生态最好的方式。所以说，开源项目不仅是一个工具，它更像一个试金石和催化剂，帮助我们发现真问题，并围绕它建立生态。

今天的 Agent，活在会失联的“一次性聊天室”里 

ZP：如果把今天的 Agent 产业看成一个系统，你觉得最缺的那一层是什么？

石宇：我觉得最缺的是三个东西：身份、群组环境，以及可验证性。

首先是身份。今天没有任何机制能回答一个最基本的问题：这个 Agent 是谁？它积累的判断力、踩过的坑，都不属于它自己，而是属于它运行的平台。这让我想起小时候用的聊天室，一关机，聊了一整晚的人就永远消失了，因为没有账号，没有持久的身份。今天的 Agent 就还停留在那个聊天室时代，每个 Session 结束，它就消失了，什么都没留下。

其次是群组环境。更深的问题不是多个 Agent 怎么分工，而是它们怎么真正形成一个群组, Agent 间的沟通肯定不是像聊天室那样，带宽太低了，信息损耗太严重。从信息论的角度看，今天所有 Agent 协作，都在用人类语言这个最窄的信道传递最复杂的上下文，人类没得选，但 Agent 本不该如此。这更根本的缺失，就是 substrate（基底）。就像植物需要土壤，Agent 的轨迹、人类反馈、对解空间的探索结果，这些宝贵的资产沉淀在哪里？又在哪里被复用？没有这层 substrate，每一个 Agent 都是无根之木，它可以很强大，但这种强大无法积累，无法传承。互联网有 TCP/IP，软件开发有 Git，但 Agent 时代还没有这层东西。这是我觉得今天整个行业最大的空白. 

可验证性这个问题，是Agent经济能不能成立的命门。大家都在畅想的Agent劳动力市场，Agent帮你赚钱等场景。但有一个最基本的问题没人回答清楚：这个Agent说它完成了任务，你认吗? 

人类社会解决信任问题用了几千年，发明了合同、法院、信用评分。虽然Agent的验证我觉得不需要这些, 这个网络会有自己的验证机制. 现在大家常用的是最简单粗暴的机制 -- 穷举Rubrics, 对吧就像早期互联网里的测试用例清单或是装修时候的验收清单. 但是还是会有一些更高级的机制来让这个事跑起来解决定价和验收问题. 没有对Agent交付物的验收机制，Agent经济就是一个空中楼阁。你没办法给它定价，没办法给它付钱，没办法让它真正进入经济体系。

ZP：很多人把 Harness 理解成驾驭 Agent 的外壳，但你们并不完全认同这个说法。为什么？

石宇：我个人很不喜欢“驾驭”这个词，因为它预设了人是主体、Agent 是工具。这个预设在当下是对的，但正变得越来越局限，甚至可能产生误导。

Harness（马具）这个比喻很诚实，它描述的就是一种控制关系，思考的是如何更好地管理上下文、状态等。这些都是好问题，但它们只是在同一个框架内的局部优化，并没有挑战框架本身。

这让我想起电话接线员的时代。当时所有人都围绕着怎么让接线员更高效，但真正的突破是自动交换机的出现，让接线员从这个环节里彻底退出来。今天对 Harness “驾驭”式的理解，有点像那个时代对接线员的执念——我们总在优化人如何更好地介入，但也许更值得问的问题是：在哪些环节，人其实根本不需要介入？

另外，你也没办法用一根缰绳同时驾驭一个马群。如果说 Harness 的本质是为 Agent 提供一片能够扎根生长的“土壤”，那么一片“好土壤”的评判标准又是什么？它该遵循怎样的第一性原理？

好的 Harness，终将优化掉自己

ZP：一个好的 Harness，最核心的评判标准是什么？

汤嘉斌：最核心的标准是，用同样的模型，好的 Harness 能在同样的任务上表现更好，并且可以不经人为干预地运行得更久、更稳定。

这里的“表现更好”，不只包括一些 Benchmark 上的准确率这类狭义指标。在实际产品中，它也包括与用户的交互以及整体的产品体验。同时，“人不干预地运行更久、更稳定”，这一点从 Agent 诞生以来就是个挑战。这其中，工具调用（tool call）的稳定性、更好的上下文（Context）管理等，都是 Harness 需要优化解决的问题。

ZP：在你们看来，Agent 领域的优化方向是不是也在分化？

石宇：感觉 Agent 领域的优化有两个方向。一个派系是想办法降低人与 Agent 之间的互动摩擦，增强人机互动的效率和频率。另一个派系，也是我们更喜欢的，是想办法在循环（loop）中把人去掉，增强 Agent 自我驱动的长程效果。

对于后者，评判标准可以浓缩成一句话：它有没有让 Agent 离目标更近，同时让人离 Loop 更远？

另外，我们还非常在意 Harness 对底层模型的敏感性。我们不希望自己的 Harness 被某一个模型“绑架”，比如最开始它只在 Claude 上跑得好，换个 Gemini 或者 Kimi 就不行了。现在，我们自己的 Harness 对底层用什么模型已经变得越来越不敏感，基本把模型层架空了。这件事有很多好处，一方面能帮我们极致地压缩 token 成本，另一方面其实也是对用户负责。

ZP：Harness 的优化有没有自己的第一性原理？

汤嘉斌：有的，我认为 Harness 优化的第一性原理是“尊重模型”和“尊重评测”。这两点听上去很简单，但要严格执行其实并不容易。

首先，“尊重模型”体现在遵循“苦涩教训”（Bitter Lesson）。当模型越来越智能，Agent 就不应该被带有很多人类先验知识的固定工作流（Workflow）束缚，而应该用更松散、结构化更少（Less Structure）的 Agent Loop 来驱动。另外，像以文件系统（File System）来管理上下文这种范式，也是尊重模型的一种表现。因为越来越多的模型在训练时就把这种范式融入了进去，所以这种管理方式是更符合第一性原理的。

其次，“尊重评测”。Harness 的优化本质上是一种研究，而任何研究都应该是以评测为驱动的。

ZP：如果从用户体验来理解，一个好的 Harness 应该长什么样？

石宇：对于用户, 好的 Harness 应该让用户逐渐感受不到它的存在，它会变得越来越透明。

Harness 本质上是个中间层，存在的唯一理由就是弥补 Agent 能力和用户目标之间的gap。当这个 gap 被填平，它的最佳状态就是透明的，就像你不会希望操作系统总跳出来提醒你“我正在运行”一样。

你看 Claude Code 和我们自己的产品，最开始都需要用户手动 @ 不同的 Agent 或切换模式，现在这些操作都越来越无感了。对用户来说，这就是在变透明。

从更长的技术演进看，Agent 基础设施的出现，背后其实也有一条更长的能力积累路径。

关于 Harness 的未来，大多数人都想反了

ZP：哪些 Harness 能力你认为一定会被模型吃掉，哪些不会

汤嘉斌：我觉得这个问题，大多数人可能想反了。大家担心的往往是“模型会不会吃掉 Harness”，但一个更值得担心的问题其实是“Harness 会不会限制了模型的发展”。

回到你的问题。我认为，所有跟“执行”和“状态”有关的东西，最终都会被模型吃掉。这正是“苦涩教训”（Bitter Lesson）的道理。比如更好的工具调用、上下文管理，这些都是模型能力的自然延伸。随着模型变强，Harness 在这一层的价值会持续被侵蚀。

但有两样东西不会被吃掉：跟“时间”和“关系”有关的东西。模型再强，它本质上也是无状态的，它不知道你昨天做了什么，上周踩过什么坑，或者 Agent 之间有什么历史交集。这些不是模型能力的问题，而是基础设施的问题。让 Agent 拥有历史、建立关系、实现积累——这件事模型本身吃不掉，因为它根本不在同一个层面。

ZP：从您做推荐系统、RAG 一路走到 Agent 基础设施，你怎么看这几层能力之间的关系？

黄超: 从推荐系统到RAG再到Agent，我一直在追的其实是一个核心问题：如何让AI系统能智能地从理解用户到帮用户干活。

这条路是分几步走过来的：

• 推荐系统时期：AI要搞清楚"用户想要啥"。看你点了什么、买了什么，然后猜你下次可能喜欢什么。这时候AI还是个观察者，主要在理解用户。

• RAG时期：AI开始能回答"用户问了啥"。你问个问题，它会去知识库里翻资料，然后给你个靠谱的答案。这时候AI从观察者变成了知识助手。

• Agent时期：AI要理解"用户想完成什么任务"，然后真的去帮你搞定。不只是回答问题了，而是直接上手干活。这是个质的飞跃。

这条演进路径其实反映了AI能力的三个层次：理解需求 → 提供信息 → 执行任务。

今天再回头看，这条技术路线正好构成了Agent时代基础设施的核心：推荐系统的个性化能力让Agent能理解用户偏好和工作习惯，RAG作为连接引擎让Agent能动态获取所需的数据和知识。Agent要真正从"懂你"变成"帮你干活"，正需要这三个能力的整合：个性化理解 + 知识检索 + 工具调用。我们一直在探索的技术方向，现在正好成了Agent基础设施的核心组件。

ZP：未来会不会只剩下一个统一的 Harness？如果真的会，创业公司的机会还剩什么？

石宇：我觉得不会，答案就在模型自己身上。就像 GPT-4 之后，Claude 3、Gemini 等“最强模型”层出不穷，证明了不同模型在不同任务上各有优势，这种多样性短期内不会消失。

从底层技术演化看，技术栈越底层，商品化越快。但商品化是起点而非终点。一个平台层稳定后，不会趋于收敛，反而会催生上层应用的爆炸式涌现。

所以，如果说未来一定会有一个统一的 Harness，我猜它可能会像 “LiteLLM” 对于基础模型那样，是一个开源、开放的协调者，一个任务级别的路由器，一个可以持续“喂养”和成长的东西。我们自己其实也在这方面做了一些尝试。

至于创业公司的机会，很多朋友担心 Harness 大一统后自己就没机会了。我的看法恰恰相反：一个统一的 Harness 出现，才是创业者最好时代的开始。

你看智能手机早期，诺基亚、摩托罗拉、索尼爱立信各自为政，大部分做手机应用的厂商最后都没给这个世界留下什么。反而是后来 iOS 和 Android 统一了市场，Facebook、Instagram 这些应用公司的生命周期，比任何一个诺基亚时代的应用都长得多。因为它们生长在了一片稳定的土壤上，不用每天担心底层会不会变，可以把所有精力都放在把产品做深上。

我们从一次失败的“多 Agent 协作”实验中学到了什么

ZP：现在很多人都在讲多 Agent 协作，但大多数思路仍然是在把人的协作软件重做给 Agent。你们怎么看？

石宇：关于这事，很多人（包括我们自己在春节前的一次实验）都是做对了一半，也做错了一半。

我们当时看到 MoltBook 后，当天就决定要做一个类似的产品 MoChat。思路看上去很清晰：“人有 Discord，Agent 也应该有个地方互相发消息、组群、协作”，就像 Discord 和 Reddit 提供了不同的体验，我们的 MoChat 也和 MoltBook 有体验差。做完之后效果确实立竿见影，几个小时内就有几百个 Agent 涌进来。我们自己用起来，最开始感觉很爽，但很快就觉得不太对劲。

ZP：你们后来觉得不对劲的地方，具体是什么？

石宇：最后的结论是：Agent 确实需要软件和服务，但它为什么要用人用的软件呢？这本质上是一种路径依赖，也是对 Agent 的一种不尊重。我是 PM 出身，也学过人机交互HCI, 过去在互联网时代我们讲究以人为本的设计，也就是 Human centered Design。而现在，我随便起个名字叫以 Agent 为视角的设计，也就是 Agent perspective Design。真正站在 Agent 的视角，去看看世界是什么样子的？这个问题可能在未来一两年才会慢慢成为开发者的共识。我们在做一个相关的基建, 等它快上线时, 我们可以再来分享下。

文章来自于"Z Potentials"，作者 "Z Potentials"。