最近 AI 圈讨论度最高的一组词不是某个模型的参数量而是“Opus 5 通关 ARC-AGI-3”和“harness”。放在两年前一个通用大模型能在 ARC-AGI 这种抽象推理基准里拿到好成绩是足够上头条的新闻。但今天圈内人更在意的不是“模型能不能做对题”而是“把模型接进真实系统之后它还能不能这么聪明”。后者就是 harness 的战场。我的判断很明确模型智力这条曲线还在往上走但真正挡住 AI 落地效率的已经不是模型本身而是包裹在模型外面的那层工程骨架。harness 原本是保证模型在可控范围内工作的安全绳可一旦设计得过度、僵化、不透明它就会从保护绳变成捆住模型的绳子。这篇文章想拆清楚ARC-AGI-3 到底考什么harness 在 AI 工程里扮演什么角色以及它为什么正在成为新的性能瓶颈。1. 这篇文章真正要解决的问题先看开发者的真实处境。现在做大模型应用最让人头疼的往往不是“模型不够聪明”而是一堆看似外围的问题同一个模型单次问答效果很好一接入 Agent 流程就反复失败还不知道是模型错了还是工具调用错了。上下文管理一塌糊涂会话稍微长一点模型就把前面的关键信息忘干净。工具权限设得太保守模型每一步都在“被拒绝”设得太宽松又怕它执行危险操作。评测链路不稳定同一个 prompt 跑三次三次分数都不一样无从判断模型升级到底有没有效果。这些问题的共同指向就是 harness——把模型能力封装、约束、编排起来的那套工程体系。可以说模型是发动机harness 是底盘、转向和制动系统。发动机只有 100 马力时大家关注的是发动机本身发动机到了 500 马力决定一辆车好不好开的反而是底盘和悬架。AI 领域正在经历同样的转折。这篇文章适合三类读者。第一类是做 AI 应用和 Agent 的技术负责人你需要理解为什么团队的时间总是消耗在模型之外。第二类是做模型评测、Prompt 工程和平台工程的开发者你会看到一张更完整的能力版图。第三类是正在调研“模型能力越来越强为什么产品还是不好用”的产品和技术决策者这篇文章能给你一个清晰的判断框架。2. ARC-AGI-3 与 Opus 5模型能力的一次标志性跃迁2.1 ARC-AGI 到底考什么ARC-AGI 全称是 Abstraction and Reasoning Corpus由 François Chollet 提出目的是测试 AI 系统的抽象推理能力而不是背诵能力。它的题目长得像小时候做过的图形推理题给一个或多个彩色网格作为输入要求模型观察规律预测输出网格。常见规律有旋转、镜像、颜色映射、边界填充、计数等。这类题目对大型语言模型并不友好原因有三题目高度抽象。语言模型擅长处理文本模式但 ARC 的输入是网格结构必须转化为模型能理解的描述或坐标序列。每道题都是“新概念”。同一个规律不会在训练数据里反复出现模型很难靠记忆取巧。答案必须精确。网格里错一个格子就算错不像开放问答那样可以“意思对就行”。因此ARC-AGI 被看作衡量“通用智能”的一个参考基准。它能区分“记住答案的模型”和“真正在推理的模型”。2.2 ARC-AGI-3 的难度含义ARC-AGI 系列一直在变难。ARC-AGI-2 发布时很多模型的成绩相比第一代出现了明显下滑原因是题目设计刻意避开大模型的“套路化能力”引入更多组合推理和反直觉规律。ARC-AGI-3 延续了这个趋势从社区讨论来看它进一步提高了规律组合的复杂度和干扰项数量对模型的抽象归纳能力提出了更高要求。也就是说能在 ARC-AGI-3 上实现突破不是“模型又背住了一批题”而是模型在“从少量样例中归纳规律”这件事上确实又前进了一步。2.3 通关信号而不是终点宣言Opus 5 在 ARC-AGI-3 上取得进展传递的真实信息不是“AGI 已经到来”而是“纯模型能力这条曲线还在往上走”。这值得我们对基础模型的潜力保持乐观。但更值得关注的是随之而来的落差模型智力上涨的速度和工程系统消化模型能力的速度已经出现了明显剪刀差。一个能在抽象推理基准上拿分的模型放进真实业务系统依然可能被上下文截断、工具权限、异常重试、解析失败这些工程问题拖住。这意味着什么意味着模型之外的 harness正在成为真正的胜负手。3. 什么是 Harness从“测试台架”到“AI 工程骨架”3.1 Harness 的本义Harness 在英文里有“马具、挽具”的意思在软件工程里则常被翻译成“测试台架”。传统上测试台架是指为了运行测试而搭建的一套环境它会替被测对象准备好输入数据、模拟外部依赖、收集执行结果、统计断言是否通过。举个例子你要测一个订单接口不可能真的每测一次就生成一单、发一次物流。你会写一个 harness负责构造请求、mock 外部服务、校验返回结果。被测对象是接口而 harness 是围绕着接口的整套辅助工程。3.2 AI 领域的 Harness 是什么在大模型时代harness 的含义扩大了。它不再只是测试工具而是包裹在模型外层的完整工程体系至少包括四层能力层次作用失败的后果模型访问层统一通信协议、鉴权、超时、重试、限流调用不稳定服务不可用上下文管理层历史消息维护、滑窗、摘要、长期记忆模型遗忘关键信息产出不一致工具执行层函数调用、命令执行、沙箱隔离、权限校验Agent 无法完成任务或误操作评测与观测层记录 trace、计算指标、成本统计、质量回归无法定位问题无法证明模型升级有效现在舆论里经常出现的 Codex Harness、DeepSeek Harness本质上是同一类东西围绕某个模型或某个 Agent 场景把模型能力封装成可控、可观测、可回滚的调用链。比如 Codex Harness 的思路是给 Agent 一个隔离执行环境让它能在受控容器里跑命令、验证代码、根据报错自我修正。这样的设计不是为了“限制模型”而是为了让模型在一个安全边界内充分施展。3.3 一个直观类比把模型比作 F1 发动机。发动机本身可以爆发出上千马力但你不能把一台裸发动机直接装进民用车。你需要变速箱、传动轴、悬挂、刹车、电子稳定系统、安全笼。这些就是 harness。发动机的马力决定一辆车的理论极速但真正决定圈速的往往是底盘调校和电子系统的配合。大模型领域正在发生同样的变化模型负责“智力”harness 负责“把智力变成可靠的能力输出”。如果 harness 拖后腿再强的模型也跑不出应有的成绩。4. 为什么说 Harness 正在变成捆住模型的绳子“harness 正在变成捆住模型的绳子”这不是标题党而是一个正在被工程实践反复验证的观察。它有四个层面的证据。4.1 评测瓶颈从“模型得分”转移到“评测管线稳定性”以前跑模型评测最紧张的是最终分数。现在跑评测最大的风险往往来自评测管线本身上下文超限、工具调用超时、输出格式解析失败、网络抖动导致重试风暴。一个评测任务跑挂了你很难立刻分清是模型能力不够还是 harness 没有把环境准备好。从工程经验看很多 Agent 项目的失败发生在工具层的比例远高于模型推理层。模型可能已经给出了正确的意图判断但工具没有返回可用的结果或者反馈格式让模型误解了下一步。这类问题很难靠换一个更大的模型解决只能靠改进 harness。4.2 重试、缓存、并行策略直接决定可用性大型模型的 API 延迟和成本决定了我们不可能每次调用都苦等。好的 harness 会在几个维度上做文章对确定性要求高的请求做缓存命中后秒回。对可并行的评测任务做并发调度而不是串行排队。对超时请求做指数退避重试而不是无限重试把系统拖垮。对成本做实时统计发现超出预算阈值时自动熔断。这些机制听起来像是后端的陈旧功课但在大模型场景里它们的实现细节会直接影响模型输出的质量和用户体验。一个不会缓存、不会流控、不会重试的 harness会以肉眼可见的速度把产品体验拖下水。4.3 安全约束过度模型被“五花大绑”这是最讽刺的一层。harness 设计得太“安全”反而会让模型变成一个聪明但无能的巨人。常见表现包括工具白名单过窄模型明明有完成任务的能力却没有完成任务所需的工具。每一步工具调用都需要人工审批Agent 流程被切成碎片推理链条断裂。上下文被过度精简模型失去判断全局所需的背景信息。安全审查只拦危险的也把正常动作误伤导致大量无意义的拒绝。安全边界当然需要但它应该像护栏而不是手铐。护栏的作用是防止坠落手铐的作用是让人什么都做不了。过度约束的 harness正在把越来越多的模型变成“高分低能”的接口。4.4 harness 不透明问题无从排查还有一个容易被低估的问题harness 本身缺少可观测性。很多团队只有一个简单的调用日志没有 trace没有指标没有调用链还原。当 Agent 在某一步出错时团队只能猜。高效的 harness必须能在问题发生时回答三个问题模型这一步看到了什么它决定调用哪个工具工具的返回是什么。没有这三个信息AI 应用的质量优化就无从谈起。这也解释了为什么行业内越来越强调 harness engineering。它是一门关于“如何约束、观测、迭代模型行为”的工程学科。模型是智商harness 是执行力。智商再高执行力跟不上落地效果就是不行。5. Harness 工程化的核心模块与配置实践理解了 harness 的作用下面看它应该由哪些模块组成以及如何用配置把行为固定下来。5.1 模型访问层这是最基础的一层负责统一模型 API 的调用方式。它需要覆盖协议适配、鉴权、超时、重试、限流、计费等能力。不同模型可能提供不同的 SDK 和接口格式harness 应该对外暴露统一的接口让上层业务不感知模型差异。5.2 上下文管理层语言模型是无状态的每次调用只接收你传过去的内容。上下文管理的核心是维护“该给模型看什么”。常见策略有滑动窗口、历史摘要、长期记忆向量库、多轮任务裁剪等。上下文管理做得好的 harness能让模型在长任务中保持一致性。5.3 工具执行层Agent 场景下模型需要调用外部工具才能完成任务。工具执行层的职责包括注册工具、定义入参输出格式、执行鉴权、在沙箱里运行命令、把结果反馈给模型。关键设计点有两个一是白名单和黑名单机制二是最大迭代次数限制防止 Agent 陷入死循环。5.4 评测与观测层评测与观测层负责记录每一次调用的输入输出、Token 消耗、耗时、错误类型并支持结果回放。它是定位问题的核心依据也是评估模型升级效果的客观数据源。下面是一个最小可用的 harness 配置示例# config/harness.yaml harness: model: provider: openai-compatible model_name: deepseek-chat base_url: https://api.deepseek.com/v1 temperature: 0.2 max_tokens: 4096 timeout_seconds: 60 retry: max_retries: 3 backoff_base: 2 context: max_history_rounds: 20 memory_type: sliding_window summary_on_overflow: true tools: enabled: true allowlist: - search_docs - execute_python - read_local_file denylist: - delete_production_data - update_access_policy safety: max_iterations: 10 prompt_injection_guard: true observability: enable_tracing: true metrics_exporters: - console - prometheus这份配置体现了几个工程判断allowlist和denylist分开既允许必要工具又显式拦截危险操作。max_iterations设置 10防止 Agent 在同一个错误上反复打转。观测层同时输出到console和prometheus保证开发和线上都能发现问题。配置与代码分离意味着你能在多个环境之间复用同一套 harness 逻辑只切换配置。6. 完整示例用 Harness 模式跑一个 AI 评测任务下面用一个最小但完整的示例演示 harness 如何承载一次模型评测。这里使用的任务格式借鉴了 ARC-AGI 风格的网格推理但只是一道演示题不代表真实基准题目。6.1 环境准备Python 3.10 及以上。安装 OpenAI SDK因为多数兼容接口都采用 OpenAI 协议。pip install openai准备好模型 API Key并导出环境变量export OPENAI_API_KEYsk-xxxx export OPENAI_BASE_URLhttps://api.deepseek.com/v1如果你的模型只有专属 SDK把下面ModelHarness.complete方法里的调用换成对应 SDK 即可harness 的整体结构不变。6.2 创建项目结构harness-demo/ ├── config/ │ └── harness.yaml ├── eval/ │ ├── arc_sample_task.py │ └── run_eval.py └── harness/ └── harness_core.py6.3 实现 ModelHarness 核心类# harness/harness_core.py import logging import time from dataclasses import dataclass from typing import Dict, List, Optional logger logging.getLogger(harness) dataclass class HarnessConfig: model_name: str deepseek-chat temperature: float 0.2 max_tokens: int 4096 timeout_seconds: int 60 max_retries: int 3 max_history_rounds: int 20 class ModelHarness: 统一模型调用入口自带重试、超时、上下文管理和成本统计。 def __init__(self, config: HarnessConfig): self.config config self.history: List[Dict[str, str]] [] self.total_prompt_tokens 0 self.total_completion_tokens 0 def complete(self, prompt: str, system: Optional[str] None) - str: messages [] if system: messages.append({role: system, content: system}) messages.extend(self.history) messages.append({role: user, content: prompt}) import openai client openai.OpenAI() last_error None for attempt in range(1, self.config.max_retries 1): try: resp client.chat.completions.create( modelself.config.model_name, messagesmessages, temperatureself.config.temperature, max_tokensself.config.max_tokens, timeoutself.config.timeout_seconds, ) content resp.choices[0].message.content self.total_prompt_tokens resp.usage.prompt_tokens self.total_completion_tokens resp.usage.completion_tokens self.history.append({role: user, content: prompt}) self.history.append({role: assistant, content: content}) if len(self.history) self.config.max_history_rounds * 2: self.history self.history[-self.config.max_history_rounds * 2:] return content except Exception as exc: last_error exc logger.warning(调用失败第 %s 次重试错误%s, attempt, exc) time.sleep(2 ** attempt) raise RuntimeError(f模型调用最终失败: {last_error}) def cost_report(self) - dict: return { prompt_tokens: self.total_prompt_tokens, completion_tokens: self.total_completion_tokens, }这段代码的核心意义在于把模型调用的稳定性问题收敛到一处。上层业务不再需要关心重试和超时只需要调用complete方法。评测任务、Agent 流程、生产路由都可以复用同一个 harness 实例。6.4 定义评测任务# eval/arc_sample_task.py SAMPLE_TASKS [ { id: arc_demo_01, prompt: ( 观察输入网格的规律请输出变换后的网格 以 JSON 二维数组形式返回不要额外解释。\n 输入网格\n [[1, 2, 3],\n [4, 5, 6],\n [7, 8, 9]]\n 输出 ), } ]6.5 编写评测运行脚本# eval/run_eval.py import json from harness.harness_core import HarnessConfig, ModelHarness from eval.arc_sample_task import SAMPLE_TASKS def parse_grid_output(raw: str): 从模型输出里解析 JSON 二维数组解析失败则返回 None。 text raw.strip() if text.startswith(): lines text.splitlines() lines [line for line in lines if not line.startswith()] text \n.join(lines) try: return json.loads(text) except json.JSONDecodeError: return None def run_eval(): config HarnessConfig( model_namedeepseek-chat, temperature0.0, max_tokens1024, ) harness ModelHarness(config) for task in SAMPLE_TASKS: raw_output harness.complete(task[prompt]) parsed parse_grid_output(raw_output) if parsed is None: print(f{task[id]}: 输出格式解析失败原始输出{raw_output[:100]}) else: print(f{task[id]}: 解析成功网格{parsed}) print(Token 统计:, harness.cost_report()) if __name__ __main__: run_eval()6.6 运行与验证python eval/run_eval.py预期输出可能是arc_demo_01: 解析成功网格[[9, 8, 7], [6, 5, 4], [3, 2, 1]] Token 统计: {prompt_tokens: 148, completion_tokens: 96}如何判断成功脚本没有抛出运行时异常说明重试和超时机制正常工作。模型输出被成功解析为 JSON 二维数组说明输出格式约束有效。Token 统计有数据说明成本记录生效。如果运行失败先检查 API Key 是否正确再检查网络连通性和模型名称是否正确。评测场景下把temperature固定为 0.0能让结果更稳定这是评测可复现性的关键一步。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型返回空字符串max_tokens 太小、服务端流式截断查看原始响应体调大 max_tokens增加 max_tokens开启重试同一任务分数忽高忽低temperature 未固定、历史上下文污染固定 temperature 和 seed任务间隔离实例评测场景 temperature 设为 0.0Agent 反复调用同一个错误工具缺少工具结果反馈或没有迭代上限打开 trace查看每次工具返回增加 max_iterations强制反馈摘要上下文超过模型窗口限制历史会话太长单轮入参过大检查 prompt token 占用使用滑窗和摘要必要时清理历史工具权限不足导致全部失败allowlist 过严或鉴权配置错误查看鉴权日志和错误码按最小权限原则放行保留审计评测成本突增缺少缓存、重试过多、任务量上涨按任务和模型分组统计 cost_report加缓存、流控和预算告警输出 JSON 解析失败模型加了额外解释或输出被 Markdown 包裹打印原始输出检查格式在 prompt 中约束格式解析前剥离代码块8. Harness 工程的最佳实践8.1 把 Harness 当作一等工程制品harness 不是临时写的胶水代码它应该像后端服务一样有自己的仓库、版本、测试和变更记录。模型会升级工具会变prompt 会迭代这些都对应到 harness 的版本变更。把 harness 纳入版本管理是保证 AI 应用质量的基础。8.2 配置与代码分离模型名称、temperature、超时时间、工具白名单这些参数应该放在配置文件中而不是散落在代码里。不同环境开发、预发、生产用不同配置避免“本地能跑生产跑不了”的经典问题。8.3 建立回归评测集每次做三件事之前都必须跑一遍回归评测集模型升级、harness 变更、prompt 调整。回归评测集不需要很大几十个有代表性的任务就能暴露大部分问题。它承担的是 CI 的作用防止“修了一个 bug引出三个 bug”。8.4 固定评测参数评测场景下temperature、seed、系统提示词都要固定。任何概率性波动都会让评测结果失去对比意义。如果发现结果仍然不稳定优先检查是否存在并发共享 history 的污染问题。8.5 观测优先而不是分数优先与其关心“这轮评测得了多少分”不如关心“这轮评测失败在哪里”。给 harness 加上 trace记录每次调用的输入、输出、Token 消耗、耗时和错误类型。问题定位能力决定了 AI 工程团队的天花板。8.6 安全与自由度平衡安全边界要明确但不要过度约束。允许哪些工具、拒绝哪些操作应该由风险评估决定而不是图省事一刀切。给模型完成任务必需的“手脚”同时保留审计和回滚能力才是生产环境的成熟做法。8.7 成本预算与熔断大模型调用是实打实的成本。在 harness 里加入 token 统计、预算阈值和熔断机制防止某个异常任务把月度成本打穿。成本可观测才能做到心里有数。9. 总结关心“绳子怎么系”比关心“马力多大”更紧迫Opus 5 在 ARC-AGI-3 上的表现是一个醒目的信号模型本身的抽象推理能力还在突破。与此同时大量团队仍然困在上下文管理、工具编排、评测不稳定、成本失控这些 harness 问题上。两者叠加真正的结论是模型能力决定系统的理论天花板harness 决定系统的实际交付地板而不幸的是后者正在被严重低估。harness 正在变成捆住模型的绳子——这句话不是劝人拆掉 harness恰恰相反它提醒我们把 harness 当回事。绳子系得好模型被约束在安全边界内同时还能发挥出应有的能力绳子系得差再强的模型也会被拖在原地。下一步可以做的事很清楚梳理你现有系统的模型调用链路补上 trace固化配置建设回归评测集然后把 harness 当成基础设施长期维护。模型会越来越聪明那个“能把聪明发挥出来”的工程骨架才是你的产品真正拉开差距的地方。