别只记录模型：智能体时代需要一份可移植的 Harness 说明书

导语

当人们比较两个智能体系统时，通常首先关注底层模型的名称、参数规模或基准成绩。但大模型本身并不会直接完成任务，它必须通过提示词、工具、执行环境、权限控制和反馈机制等基础设施与外部世界交互。论文《Towards Portable Specification of the Agent Harness》将这套围绕模型运行的基础设施称为“Harness”，并认为它应当像模型一样被明确描述、版本化和复现。

这项工作并不是提出一个新的智能体产品，而是试图解决一个日益突出的描述与比较问题：当研究者声称某个模型在某项任务上表现良好时，读者是否知道它究竟是在什么样的运行框架中取得这一结果？

核心要点

• Harness 不等于简单的运行器。 在论文的框架中，Harness 是决定模型如何接收信息、调用工具、执行动作并获得反馈的周边系统。它影响模型能够完成的任务，也影响错误和失败以何种形式出现。
• 作者提出八类功能组件。 论文将 Harness 分解为八个可以单独描述和比较的功能部分。素材没有列出这些组件的具体名称，但这一拆分的目标是让不同系统之间具备共同的描述语言，而不是继续使用含义模糊的“智能体框架”概念。
• 同一模型不一定对应同一成绩。 论文指出，不同 Harness 配置可能让同一个模型得到数倍差异的报告分数。因此，只公开模型名称和最终得分，无法充分解释评测结果，也容易把基础设施带来的优势误归因于模型本身。
• Harness 也是重要的攻击面。 智能体的风险并不只来自模型权重或训练数据。工具权限、执行环境、配置管理和外部交互方式同样可能扩大系统的攻击面，尤其是在智能体可以修改自身工具或配置的场景中。
• 一次运行内部也可能发生变化。 现有模型卡和智能体卡通常提供发布信息或操作说明，却未必记录一次运行中实际生效的配置序列。Harness 可能随版本、不同运行批次，甚至同一运行过程而变化，因此需要保留相应的时间和版本信息。

意义与影响

这项提议首先会影响智能体评测。未来的基准测试如果只公布模型和分数，信息可能仍然不完整；更有价值的报告应同时说明模型在哪个 Harness 中运行，以及该环境使用了哪些工具、权限和配置。这样，研究者才能区分模型能力、工程编排和外部工具带来的贡献。

对开发者而言，规格化记录也有助于调试和回归测试。当系统升级工具链或修改配置后，团队可以判断性能变化究竟来自模型更新，还是来自 Harness 的改变。对安全团队而言，版本化的配置记录则能帮助追踪一次运行中的权限变化与潜在攻击路径。

论文还提醒，法律法规中已经存在与特定人工智能系统相关的文档义务，但这些规定受适用范围和生效时间限制，并没有统一规定本文所倡议的 Harness 记录格式。因此，行业仍需要通过开放规格、评测实践和工程工具逐步形成共识。

更重要的是，这一框架改变了人们描述智能体的方式：智能体不应被视为“模型加一个界面”，而应被看作模型与 Harness 共同构成的系统。只有把两者放在同一份可复核记录中，跨系统比较、风险分析和结果复现才更可靠。

来源：arXiv