Harness² 是什么？
Harness² 是 google-research 仓库中的一个研究项目，研究对象是语言模型周围的 harness：提示、工具、记忆和执行协调等机制。它在模型权重保持不变的条件下，尝试改进这层机制。名字中的“平方”对应两层改进，并不是一个“第二代 Google 聊天机器人”。官方项目说明。 本文中的 Harness²、Harness2 与 Harness^2 指向同一项目，并不是三个独立产品。
第一层围绕当前任务，通过“提出修改、执行探查、选择性组合”的循环，观察不同 harness 带来的行为差异。第二层保留采用的 harness 和有证据支持的经验，用于后续改进。值得区分的是：完成一次交付，与知道哪些做法值得再试一次，是两件需要分别判断的事。过去留下的经验，到了新场景仍然需要重新检查。
为什么现在介绍它？这里没有“突然爆火”的结论
本次选题对应的可核验事件，是一个公开的研究代码发布：仓库提供实现、说明文档和论文链接。这篇文章帮助读者理解该发布。我们没有搜索量序列、独立采用率调查或流量证据，因此不会把“搜索暴涨”“全网都在用”作为选题依据。
编辑部认为它值得解释，是因为模型、Agent、Skill 和 MCP 经常被混在一起使用。Harness² 提供了一个具体例子，帮助我们问清楚“究竟改进了哪一层”。这是编辑判断，不是基准测试得出的市场结论。
它不是什么：模型、Skill、MCP 与 harness 的区别
| 层次 | 主要问题 | 与 Harness² 的关系 |
|---|---|---|
| 模型 | 由哪个学习系统生成响应？ | 项目改进 harness 时，模型权重保持不变。 |
| Skill | Agent 应遵循什么可复用步骤？ | Skill 可以是 harness 的组成部分，不等于整个改进系统。 |
| MCP | 如何通过协议连接工具与数据？ | 协议连接本身不负责提出、探查和保留 harness 修改。 |
| Harness | 怎样组织提示、工具、记忆与执行？ | 这是项目重点尝试改进的对象。 |
它不是面向普通用户的聊天网站，不是新模型下载页，也不是万能 Skill 合集或 MCP Server。不要仅凭文档出现熟悉的产品名，就推断任意客户端都能直接接入。实际执行器、端点和运行环境必须逐项对照官方设置；本文不为任意模型或客户端背书兼容性。
一个任务例子：改进重复产生的技术简报
以下是便于理解的假设情境，不是 ToolAha 实测：某工程团队经常根据指定材料整理技术简报，但现有 Agent 偶尔漏掉约束，或没有解释建议与证据的对应关系。团队希望调查，加入证据检查清单和任务专用工具指引，是否能改善交付。
- 先写清任务、允许使用的材料、交付要求与执行权限，再考虑实验。
- 保留基线执行，分别提出一般协调问题与任务专用流程的改进假设。
- 在配置受控的前提下比较候选行为，检查修复是否又引入遗漏或无依据结论。
- 分开审核最终交付与 harness 修改，仅保留有观察记录支持的经验。
示意实验记录（不是命令或 Harness² API）：
任务：根据已授权文档整理技术简报
修改：提出建议前必须完成来源核对
观察：遗漏约束、无依据论断、执行成本
决定：保留、修订或拒绝该流程输入可以理解为任务、既有执行环境与 harness；输出不只是一段答案。官方运行目录可以包含交付文件、执行产物、采用的 harness、反思记录和评测结果。保留轨迹便于检查实验过程，但并不能替代对交付内容本身的独立核验。
适合谁，什么情况下可以不使用？
编辑判断：有重复任务、可检查执行器和评测预算的研究者、Agent 平台工程师，更有理由调查这种方法。他们能够提出一个可证伪的问题，比较流程改动的收益与成本，并有能力审核生成的修改，丢弃不能迁移的经验。
如果只是临时整理一篇材料、使用简单助手，或团队没有时间检查执行记录，这层机制可能没有必要。可以先尝试清楚的提示、现有工作流或一个小型文档化 Skill。如果瓶颈是缺数据、缺权限或模型不适合，增加递归改进不会自动补齐这些条件。这是选型建议，不是我们做过性能对比的结论。
运行前提、账户权限与费用边界
官方安装文档面向 Linux 基准运行，使用 Python 3.12，并需要额外依赖。调用模型的实验要求具备相应供应商与模型的访问权限；部分路径使用 Google Cloud 凭据。可选 Codex 执行器还有桥接或端点配置。这些是文档描述的路径，并不意味着任意模型端点、任意操作系统都得到保证。
仓库代码采用 Apache-2.0，不代表完整实验免费。需要计算执行模型、改进模型、评判模型的调用，以及重复运行、计算和存储成本。小规模任务更容易逐项检查。官方文档说明任务数量上限按领域计算，而非全局总量，因此应先核对选中的领域、任务与重复调用次数，再估算预算。
README 另有本地确定性演示说明，与调用模型的基准实验不同。作者用它在不需要模型凭据的条件下展示流程；我们没有运行该演示。基准数据与适配器还有各自条款，尤其官方基准指南提示了 WorkBuddy 上游许可限制。应根据自己的使用情况查看原始条款，不能用仓库许可证代替所有依赖与数据的使用许可。
权限和实验局限，需要先处理哪些问题？
准备尝试前，先列出执行器能读哪些目录和文档、能写哪些输出、会接触哪些凭据、可以访问哪些网络目标。使用独立测试环境、可丢弃材料和明确预算。不能因为代码开源，就直接放入生产密钥或客户资料。
实验说明讨论了公开评分材料可被网络访问的风险，并要求报告网络限制。理解结果时，需要区分“访问到评分标准”与“解决未见任务”的能力。论文结果来自其特定实验配置，不保证迁移到你的模型、文档或工作流。我们没有复现论文结果，也没有把论文指标写成本站测量。
论文在 WorkBuddy-Bench、JobBench 与 LAB 上，使用 GLM-5、Gemini 3.5 Flash 及 OpenCode、Codex 的配置进行评估。这些是作者的具体研究设置，不能推广为任意模型、任意任务都会获益。模型选择、任务样本、执行预算和评分材料的可访问性，都影响比较结果的解释。
下一步怎么判断？
先看Harness² 资源资料，找到官方仓库、文档、许可证和基本条件。选择运行环境之前，把安装指南与实验指南一起读完。如果已经明确执行器，也有可重复任务，就写一个小型评测方案，分别记录交付质量、费用和权限边界。如果方案还说不清要验证什么，也许暂时不需要加上这层机制。
项目托管在 Google 的研究仓库，但 README 明确说明它不是获得官方支持的 Google 产品。研究发布可以帮助理解方法，不能自动等同于商业支持合同或生产成熟度保证。