2026 年，AI 领域最值得注意的一句话不是关于某个新模型，而是 Anthropic、Martin Fowler 以及半个 AI 研究圈在最近几周共同收敛出来的一个公式：
Agent = Model + Harness（智能体 = 模型 + 套件）。
最近如果你在 AI Twitter 上转过，你一定到处都能看到 harness 这个词。普林斯顿发布了 HAL harness，HKUDS 开源了 OpenHarness。一篇新的 Meta-Harness 论文证明：在不动模型权重的前提下， 自动重写一个 Harness，就可以让 TerminalBench-2 的得分提高几个点。Philipp Schmid 把 Agent Harness 称作 “解决长任务模型漂移的首要工具”。
但有件事没人公开讲：2026 年关于 Harness 的几乎所有讨论，对象都是编码 Agent。Claude Code、SWE-bench、终端任务、代码仓库导航。
那除此之外的世界呢？那些不涉及 Git 仓库的 Agent 工作呢？
我们是 Lessie，专门为一个具体任务打造 Harness Agent：找人。 招聘官用我们找候选人；销售用我们找决策者；VC 用我们找创始人；市场团队用我们找创作者。 所以当 Harness 这个话题火起来的时候，我们很想知道一个具体问题：“Harness 比模型更重要”这个论点，离开编码场景后还成立吗？
于是我们做了一个基准测试，跑了一次完整实验。这个基准叫做 PeopleSearchBench，最关键的一个数字是这样的：
在 119 条真实人脉搜索查询上，Lessie 得分 65.2。 跑在 Sonnet 4.6 上的 Claude Code 得分 45.8。 这是 42% 的差距 —— 而唯一改变的变量，就是 Harness。
下面我们把这件事拆开讲清楚。
什么是 Harness Agent，用人话说
OpenHarness 团队给过最简洁的定义：模型是 Agent，代码是 Harness。 Parallel Web 给的定义略长一些：Harness 是包裹模型的一层运行时， 负责拦截它的工具调用、管理它的上下文，并把它持续地拉回任务正轨。
Martin Fowler 把它拆成两个互相配合的半部分。Guides（前馈引导）是前馈控制 —— 在 Agent 行动之前塑造它的行为（系统提示词、工具描述、检索到的上下文、环境快照）。Sensors（反馈传感）是反馈控制 —— 观察 Agent 做了什么，然后把修正喂回去（linter、校验器、验证循环）。 一个好的 Harness 同时具备两者；一个差的 Harness 只有前馈， 眼睁睁看着 Agent 在第 47 轮重复同一个错误。
所以 Harness Agent 是一个完整的组合：模型 + 引导 + 传感 + 工具 + 记忆 + 验证逻辑， 把原始的 Token 预测能力变成一个真正能完成任务的系统。
当下出现了两种 Harness：
- 通用型 Harness，比如 Claude Agent SDK、OpenHarness、以及 Claude Code 内置的 Harness。它们的设计初衷是不绑定具体领域。
- 垂直型 Harness，围绕一个具体任务来构建， 引导和传感都专门针对这个任务的失败模式调优。
你听说过的几乎所有 Harness 基准 —— SWE-bench、TerminalBench-2、USACO、AppWorld —— 测的都是通用 Harness 在编码任务上的表现。据我们所知， PeopleSearchBench 是第一个把垂直 Harness Agent 和通用 Harness 放在非编码任务上对决的基准。
为什么人脉搜索需要专属的 Harness
如果你曾经让一个通用 AI Agent 去 “帮我找柏林 Series B 创业公司里 发过 LLM 产品的资深机器学习工程师”，你应该已经见识过它的几种典型失败。 其中三种特别顽固，并且全部是 Harness 问题，不是模型问题：
1. 跨源实体解析（Entity Resolution）。一个真实的人同时存在于 LinkedIn、X、GitHub、会议演讲、公司主页、学术数据库里。 他们用着不同的名字、不同的头像，有时拼写都不一样。 通用 Harness 没有内置 “这条 LinkedIn 资料和这个 GitHub 账号是同一个人”的概念。一个人脉搜索 Harness 必须在每一次查询里都解决这件事。
2. 验证回路（Verification Loop）。没有传感层的 Agent 会很自信地编造人物。 它会引用一个 “Stripe 柏林的资深 ML 工程师”， 但这个人根本不存在 —— 因为这些 Token 听起来很合理。 修复办法不是换一个更聪明的模型 —— 跑在 Claude Code 里的 Sonnet 4.6 一样会犯。 修复办法是一个 传感器：每一个返回的人都要先用真实网页源核验， 通过之后才会到达用户面前。
3. 人类属性的查询拆解（Query Decomposition）。“柏林 Series B 发过 LLM 产品的 ML 工程师”不是一个查询， 它是一张清单：角色 + 资历 + 公司阶段 + 地点 + 领域 + 近期产出。 通用 Harness 会把整句话原封不动塞进搜索框； 垂直 Harness 会把它拆成多条标准，并行去合适的源里查，再回收、重组、排序。
这三件事，正是 Fowler 所说的 引导 和 传感。 只是它们恰好是没人会专门为通用编码 Harness 去做的引导和传感 —— 因为编码 Harness 用不上。
实证：PeopleSearchBench
我们构建 PeopleSearchBench 是为了诚实地测试这件事。完整方法在论文里，这里给一个简短版本：
- 119 条真实查询，全部来自实际的招聘、销售和研究工作流
- 4 种语言（英语、葡萄牙语、西班牙语、荷兰语）
- 4 类场景：招聘（30）、B2B 拓客（32）、专家 / 确定性查询（28）、 网红 / KOL（29）
- 4 个被测平台：Lessie（垂直 Harness Agent）、Exa（结构化搜索 API）、 Juicebox / PeopleGPT（拥有 8 亿+ 资料的招聘平台）、 Claude Code（跑在 Sonnet 4.6 上的通用 Harness）
- 三个独立维度：Relevance（padded nDCG@10）、 Coverage（任务完成率 × 产出量）、Utility（资料数据完整度）
- 用真实网页搜索验证，而不是 LLM 拍脑袋打分。 每一个被返回的人都会去 LinkedIn、公司主页和公开资料对照核实。 验证 Agent 完全不知道某条结果是哪个平台返回的。
总分如下：
- Lessie：总分 65.2 | Relevance 70.2 | Coverage 69.1 | Utility 56.4
- Exa：总分 54.6 | Relevance 53.8 | Coverage 58.1 | Utility 53.1
- Claude Code：总分 45.8 | Relevance 54.3 | Coverage 41.1 | Utility 42.7
- Juicebox：总分 45.8 | Relevance 44.7 | Coverage 41.8 | Utility 50.9
Lessie 在每一个维度上都排第一。它也是唯一一个把 119 条查询全部跑完的平台 ——100% 的完成率。其他三个平台在偏门搜索上经常什么都返回不了。
但对于 Harness 这个论点，最关键的数字是 Lessie 和 Claude Code 之间的差距。 两边都是 AI Agent，都能调用工具，都能搜网页。Claude Code 跑在地球上最强的几个模型之一上。 最终它在总分上输了 19.4 分，其中 Coverage 单项差距高达 28 分。
这 19.4 分不是模型的差距。它是 Harness 的差距。
单场景里差距最大的是 网红 / KOL 发现：Lessie 62.3，Claude Code 43.2。 网红搜索是通用 Harness 崩得最厉害的地方，因为正确答案同时分布在 TikTok、Instagram、 YouTube 和 X 上，而通用 Harness 不知道怎么把这些源融合起来。 差距最小的是招聘场景，三家平台都跑过了 64 分 —— 招聘是人脉搜索里最成熟的垂直， 行业有多年时间为它打造工具。
规律是一致的：一个场景越需要多源融合和验证，Harness 的重要性就越大。
Lessie Harness 内部长什么样
我们不会公开自己的系统提示词。但 Lessie 的架构有三层， 恰好可以对应到 Guides 和 Sensors 模型。它们值得描述出来， 因为它们大致就是任何垂直 Harness Agent 都需要的结构：
第 1 层 —— 多源编排（Guides）。当一个查询进入系统，Harness 会把它并行路由到职业网络、社交平台、学术数据库和公开记录库。 每个源都有自己的检索策略。模型从来不会看到原始的扇出结果，它只会看到一个统一的候选集。
第 2 层 —— 标准拆解与验证（Sensors）。每个查询都会被拆成显式的标准 —— 角色、资历、地点、公司阶段、相关信号 —— 每一个候选人都要先经过真实网页查询，按这些标准被验证一遍，才会进入排序环节。 这正是 PeopleSearchBench 用来给我们打分的方法学，而这并非巧合： 我们就是围绕这个基准要测的失败模式来构建 Harness 的。
第 3 层 —— 资料增强（Profile Enrichment）。通过验证后，Harness 会再去抓结构化资料 —— 当前职位、近期动态、联系方式、社交存在。 这就是为什么我们的 Utility 分领先全场：返回正确的人但字段全空，没有任何价值， 而通用 Harness 没有理由把 enrichment 当作一个内置步骤。
中间的模型在做模型擅长的事：推理、排序、总结、判断。 Harness 在做剩下的所有事。 把 Harness 拿走，剩下的是聊天机器人；把模型拿走，剩下的是搜索管线。 合在一起，才是一个垂直 Harness Agent。
这件事对 Harness 之争意味着什么
2026 年关于 Harness 的有趣观点是：模型在静态基准上的进步在放缓， 但 Agent 的整体表现还有大量空间，因为剩下的提升大多都活在 Harness 里。 Meta-Harness 通过自动发现更优 Harness 在编码场景印证了这一点； PeopleSearchBench 则从另一个方向印证： 手工搭建的垂直 Harness 可以让一个跑在通用 Harness 里的前沿模型显著落后， 而这个差距是任何模型升级都关不上的。
如果这一点成立，那么有两件事会随之发生。
第一，每一个具备商业价值的 Agent 任务，都会拥有自己的 Harness Agent。人脉搜索是其中之一。法律研究是另一个。 临床推理、金融分析、供应链调查、科学文献综述 —— 每一个都有通用 Harness 永远不会去优化的失败模式， 因为通用 Harness 是在为所有事情同时优化。 垂直 Harness Agent 将吃掉 Agent 工作的长尾， 就像 SaaS 当年吃掉软件的长尾一样。
第二，基准也需要跟上。SWE-bench 和 TerminalBench-2 都很好，但它们只测了 Harness 质量的一个切面。 如果业界真的认真对待 Harness 论点， 就需要为每一个有商业价值的垂直建立 Harness 基准。 PeopleSearchBench 是我们为人脉搜索这个垂直所开的头。 数据集、评测管线、完整结果都已经开源。
模型是引擎，Harness 是车身。我们把这台车造给了一条特定的路。 如果你的工作和找人有关 —— 候选人、客户、投资人、创作者、合作伙伴 —— 试试这台车：lessie.ai。 想看我们到底是怎么在一个原本不是为它而生的任务上击败前沿模型编码 Agent 的， 完整基准和论文在这里。
2026 年，Harness 就是护城河。数据已经替我们说了。