「Agent = 模型 + Harness」，这个简化公式在 2026 年的技术圈已经流传很广，但多数人说不清后半部分到底是什么。Earendil 最近发了一篇科普长文，用攀岩装备做类比给出了目前最清晰的解释 [1]：攀岩时安全带把你和绳索、快挂连接起来，承托你、约束你、还能挂上粉袋和工具；agent harness 对模型做的正是同一件事——托住它、限住它、给它挂上工具。
这个类比值得展开，但更重要的是把文章没说透的部分说透：为什么同一个模型在不同产品里表现天差地别？答案几乎总在 harness 这一半。
四个部件
按原文的拆解，一个 agent harness 由四部分组成。
系统提示词是新员工入职手册：模型没有内化这些规则，但知道上班时要遵守。它随每轮对话注入，框定模型的行事方式。
工具是用代码写成的能力——联网搜索、执行代码、发邮件。关键设计在于：harness 只描述工具、提供工具，不替模型决定什么时候用。选择权在模型手里。
循环是 harness 的灵魂。用户提一个需求，模型搜索、发现结果不够好、自己决定再搜一次、写代码做成表格、核对数据是否满足原始请求、不满意就回头重来——这个「自我评估再行动」的闭环就是 agentic loop。没有它，模型只是问答机；有了它，模型才成为能交付结果的 agent。
翻译层最不起眼，却可能是最有战略意义的部件：它让同一套 harness 可以接不同的模型。今天用 A 家，明天换 B 家或开源权重模型，工作流不变。
文章没说的工程账单
原文把四个部件讲成了功能清单，但没有算背后的成本账。而 harness 设计的好坏，恰恰体现在这张账单上。HN 评论区对这篇的讨论也集中在实践侧 [2]。
每次调用都要把全部工具的 schema 发给模型——工具越多，每次请求越贵、首 token 越慢。所以成熟的 harness 会严格控制核心工具数量，宁可让大部分能力走插件和技能扩展，也不往核心里堆。系统提示词必须在整个会话周期保持字节级稳定，否则缓存失效，同样的对话成本翻几倍。上下文管理决定了长会话会不会「失忆」，错误恢复机制决定了 agent 失败后是重试、降级还是静默烂尾。
说白了：模型决定能力的上限，harness 决定体验的下限。用户感知到的「这产品好不好用」，大半是在和 harness 的工程质量打交道，而不是在和参数量打交道。
一篇有立场的科普
需要指出，这篇文章不是中立的技术综述。Earendil 自己就在做一款名为 Pi 的开源 harness，文末从「你可以拥有自己的 harness」自然滑向了产品推介——Pi 用户分享了五千多个扩展、Pi 运行在你自己的笔记本上。
但这不等于论证无效。「所有权」叙事背后有实打实的技术含义：会话记录留在本地、换模型不用换工作流、可以并排对比不同模型在同一任务上的表现和成本。翻译层把议价能力从 AI 实验室手里挪回用户手里——这是结构性的判断，不因作者是利益相关方而失效。读这类文章的正确姿势是把事实和立场分开，两边的成色这篇都够格。
反方观点：harness 会被模型吸收吗
评论区有一条值得认真对待的反驳 [3]：方向可能相反——随着模型变强，harness 正在变薄。评论者举的例子是 Claude Code：据他观察，新版模型发布后其系统提示词删掉了数百行不再需要的补丁。如果模型在训练时就见过某种 harness 架构，通用 harness 反而难做。
这条质疑击中了要害，但只击中一半。会消失的是「给模型打补丁」的那部分 harness：格式纠正、行为约束、提示词胶水——模型越强，这些越多余。不会消失的是「产品本身」的那部分：权限边界、错误恢复、上下文预算、多步任务的断点续跑。后者不是模型能力的补偿，而是用户需求的直接表达，模型再强也不会自动长出来。
所以 harness 不是铁板一块的概念，它同时是过渡期的脚手架和长期存在的产品层。押注「harness 即护城河」的公司，护城河必须在后半段。
选型时的三个问题
对企业用户，这套理解可以直接变成采购问题。评估 agent 产品时，别只问「用的什么模型」——翻译层存在的时代，这个问题越来越不重要。该问的是：失败之后发生什么（重试策略、降级路径、谁来兜底）；上下文怎么管（长任务会不会悄悄丢信息）；以及我的数据和会话记录在哪里（托管在厂商那边，还是留在我自己机器上）。
第一个问题筛掉演示级产品，第二个决定它能不能干长活，第三个关乎两年后的自由度。模型能力是租来的，harness 的工程质量才是你每天真正住在里面的房子。
参考文献
[1] Earendil. What is a Harness?, 2026-08-20
评论 (0)
发表评论
请先登录后发表评论