1. 项目概述从“分数暴涨”看Agent评测的范式变革最近GPT-5.6 Sol在ARC-AGI-3基准测试中分数翻近三倍的消息在AI圈子里炸开了锅。这可不是一次普通的性能提升它像一颗投入平静湖面的巨石激起的涟漪直接拍在了我们每一个从事Agent开发与评测的从业者脸上。表面上看这是模型能力的飞跃但深挖下去你会发现问题的核心早已不在模型本身而在于我们评测AI智能体的方式——那个被我们沿用已久的、只记录最终答案的“快照式”评测可能已经彻底过时了。标题里那句“必须记录整套运行合同”正是点破了这层窗户纸。它指的绝不仅仅是保存日志文件而是要求我们完整记录下Agent在完成任务过程中的每一次思考、每一次工具调用、每一次环境交互的完整“履约”轨迹。这背后是评测理念从“结果导向”到“过程可审计”的根本性转变。为什么这件事如此重要因为今天的AI Agent早已不是那个你问它答的聊天机器人了。它们是一个个具备自主规划、工具使用和环境交互能力的“数字员工”。一个简单的“回答正确”或“任务完成”根本无法反映这个员工是凭借扎实的逻辑推理一步步走过来的还是蒙对的甚至是利用评测集的数据泄露“作弊”得来的。ARC-AGI-3这类旨在衡量抽象推理和核心智能的测试恰恰最怕这种“黑箱”评测。GPT-5.6 Sol分数的跃升很可能正是因为其内部Agent架构在复杂推理链的构建、子任务分解与回溯、以及多步工具协调上取得了突破而这些能力在只给最终答案的传统评测中要么被忽略要么被误判。因此这个项目标题所指向的是一场正在发生的Agent评测范式革命。它呼吁我们这些一线的开发者、研究员和评测工程师必须升级我们的工具箱和方法论。我们需要建立一套能够捕获Agent完整认知过程和行为轨迹的评测体系这不仅是为了更公平地给模型打分更是为了理解智能体如何工作、诊断其失败原因、并最终指导我们构建更可靠、更安全的AI系统。接下来我将结合我对Agent架构和评测的实践拆解这背后的核心需求、技术实现以及我们正在面临的挑战。2. 核心需求解析为什么“运行合同”是命门要理解为什么记录“整套运行合同”如此关键我们得先抛开对“合同”的法律字面理解在Agent的语境下它本质上是一份不可篡改的、序列化的智能体执行过程记录。这份记录必须能完整回答Agent在接收到任务后究竟“想”了些什么又“做”了些什么这直接对应了评测Agent的两个核心需求可解释性与可复现性。2.1 需求一穿透“黑箱”实现真正的能力归因传统的评测就像只看考试最终分数你不知道学生是用了巧妙的公式推导还是死记硬背了答案。在ARC-AGI-3这类需要多步推理的任务中这个问题被极度放大。假设一个任务是“根据给出的几个形状序列推断出下一个形状是什么。”一个强大的Agent可能会经历以下步骤内部思考识别序列中的模式如旋转、颜色交替、形状增减。子问题分解将整体模式拆解为位置、形状、颜色等独立维度分别分析。假设与验证生成一个可能的规则并用前面的序列进行验证。生成答案应用验证通过的规则预测下一个形状。如果只记录最终答案“一个红色的三角形”那么一个靠运气猜对的笨Agent和一个通过严谨推理得出的聪明Agent在分数上毫无区别。而记录了“运行合同”后我们可以清晰看到智能体的推理链。GPT-5.6 Sol的分数跃升极有可能就是因为其新版Agent框架或许集成了更先进的推理模块如“Chain-of-Thought”的自动化版本产生了更长、更准确、逻辑更严密的内部推理过程这些过程被新的、支持过程记录的评测框架捕捉并给予了正向评价。注意这里存在一个评测框架对齐的问题。如果评测方升级了框架开始对“推理过程的合理性”赋予权重而某个模型恰好优化了这部分能力那么其分数就会产生“跳跃式”增长。这不一定代表模型绝对智力提升了三倍但一定代表其在“评测框架所关心的能力维度”上取得了显著进步。2.2 需求二超越单次结果确保稳定与可靠Agent在实际应用中稳定性往往比单次惊艳的表现更重要。一个时灵时不灵的智能体是无法投入生产的。记录“运行合同”使得复现和调试成为可能。复现当某个任务成功或失败时完整的运行合同允许我们精确地重现当时的计算状态、工具调用顺序和外部反馈从而判断这次结果是必然还是偶然。调试如果任务失败合同就是最好的调试日志。是规划器在第一步就误判了任务类型还是某个工具调用超时返回了异常数据或是推理链在第三步出现了逻辑悖论通过审查合同我们可以快速定位故障点而不是对着一个错误的最终答案盲目猜测。这对于Agent开发学习路线上的新手尤为重要。分析优秀Agent如Hermes Agent、Pi Agent在标准任务如ARC-AGI-3上的运行合同是学习其规划策略和工具使用范式的绝佳教材远比单纯看几个输入输出示例有效。2.3 需求三应对复杂场景评测多智能体协作与安全当任务上升到需要多Agent协作或涉及敏感操作如数据库查询、API调用时“运行合同”就从“评测需求”升级为“安全与审计刚需”。谁能对哪个数据做了什么操作协作中责任如何划分这些都必须有迹可循。 例如在一个“查询销售数据并生成报告”的任务中运行合同需要记录Agent A规划Agent分解任务为“查询Q3数据”、“生成图表”、“汇总成文”。Agent B数据Agent接收“查询Q3数据”指令生成并执行SQL如SELECT * FROM sales WHERE quarter3返回数据摘要。Agent C工具Agent接收数据和“生成图表”指令调用Matplotlib库生成图片。完整的合同能清晰展示数据流的边界、每个Agent的权限范围以及是否存在越权或危险操作如尝试执行DELETE语句。这对于满足Agent安全和合规性要求至关重要。3. 技术实现剖析如何构建“运行合同”记录体系理解了“为什么”接下来就是“怎么做”。构建一套能记录Agent完整运行合同的评测体系并非简单地开启日志功能它需要从架构设计、数据规范到评测指标进行全链条的革新。3.1 架构设计在Agent核心循环中植入可观测层一个典型的现代Agent架构如基于Agent框架与编排工具如LangChain、AutoGen或自定义框架包含感知、规划、执行、反思等循环。要记录合同必须在每个环节注入可观测性。感知/输入层记录原始任务指令、上下文信息以及来自环境的初始状态。规划/推理层这是记录的核心。必须捕获Agent的“内心独白”——即其内部语言模型LLM产生的完整思考过程Chain-of-Thought。这通常需要调用LLM时启用相关参数例如OpenAI的Chat Completions API中的logprobs或结构化输出或专门为记录设计的Responses API模式。行动/工具调用层详细记录每次工具调用的请求参数、被调用工具的名称和版本、调用的时间戳、执行耗时、返回结果或错误信息。这对于理解Agent Skill的运用至关重要。观察/反思层记录Agent对工具执行结果的解读以及基于结果对后续规划的调整反思过程。最终输出层记录最终答案以及Agent对本次任务完成的置信度或总结。实现上这通常通过一个中央化的“合同记录器”Contract Recorder来实现。该记录器作为所有Agent组件的中间件以标准化的格式如JSON实时流式接收并存储所有事件。3.2 数据规范定义“运行合同”的标准格式没有统一格式合同就是一堆无法批量分析和比较的乱码。一个良好的合同格式应包含以下核心字段{ session_id: unique_task_identifier, agent_version: gpt-5.6-sol-agent-v1, task_prompt: 完整的ARC-AGI-3题目描述..., steps: [ { step_id: 1, type: internal_thought, content: 分析题目这似乎是一个关于形状旋转和颜色交替的序列..., timestamp: 2024-05-27T10:00:00Z }, { step_id: 2, type: tool_call, tool_name: pattern_matcher, parameters: {sequence: ...}, response: {pattern_found: rotate_90_clockwise, color_toggle}, duration_ms: 120, timestamp: 2024-05-27T10:00:01Z }, { step_id: 3, type: internal_thought, content: 工具确认了旋转和颜色交替规则现在应用规则预测下一个..., timestamp: 2024-05-27T10:00:02Z } ], final_output: 红色三角形, metrics: { total_steps: 5, total_duration_ms: 4500, tool_call_count: 2, success: true } }这种结构化数据使得后续的自动化分析和评分成为可能。3.3 评测指标升级从“正确率”到“过程质量”有了运行合同我们的评测指标就可以极大丰富从单一维度的“最终答案正确与否”扩展到多维度的“过程质量评估”规划合理性分解的子任务是否逻辑完备、无冗余步骤顺序是否最优工具使用效率调用的工具是否恰当是否存在不必要的工具调用工具调用成功率如何推理链连贯性内部思考步骤是否连贯、无矛盾是否有效利用了中间结果资源与耗时完成任务的步骤数、总耗时、Token消耗量。鲁棒性在面对相同任务的不同表述或轻微干扰时其推理过程的核心逻辑是否保持稳定ARC-AGI-3的新评测方法很可能引入了这些过程性指标并将它们以更高的权重计入总分从而使得像GPT-5.6 Sol这样在过程优化上发力的Agent获得了分数上的巨大优势。4. 实操指南搭建你的首个“带合同”的Agent评测环境理论说再多不如动手搭一个。下面我将以一个简单的“网络信息查询Agent”为例演示如何利用现有工具搭建一个能记录完整运行合同的本地评测环境。我们将使用流行的LangChain框架和OpenAI API模拟Responses API的流式输出来实现。4.1 环境准备与工具选型首先明确我们的组件Agent框架我们选择LangChain。它模块化程度高易于插入自定义的回调Callback系统来记录合同。LLM使用OpenAI的gpt-4o-mini性价比高适合实验。我们将模拟记录其思考过程。合同记录器我们不从零开始使用LangChain的BaseCallbackHandler来自定义一个并将数据写入本地SQLite数据库便于查询。评测任务设计几个简单的任务如“查询OpenAI最新发布的模型信息并总结其特点”。安装依赖pip install langchain langchain-openai sqlite3 requests4.2 实现合同记录回调处理器核心在于创建一个继承自BaseCallbackHandler的类在Agent运行的各个关键节点“挂钩”并记录数据。import json import sqlite3 from datetime import datetime from typing import Any, Dict, List from langchain.callbacks.base import BaseCallbackHandler from langchain.schema import AgentAction, AgentFinish, LLMResult class ContractRecorderCallback(BaseCallbackHandler): 记录Agent运行合同的回调处理器 def __init__(self, session_id: str): self.session_id session_id self.steps [] self.current_step {} # 初始化数据库连接 self.conn sqlite3.connect(agent_contracts.db) self._init_db() def _init_db(self): 初始化合同记录表 cursor self.conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS contracts ( session_id TEXT, step_id INTEGER, step_type TEXT, content TEXT, tool_name TEXT, tool_params TEXT, tool_response TEXT, duration_ms INTEGER, timestamp TEXT, PRIMARY KEY (session_id, step_id) ) ) self.conn.commit() def on_llm_start(self, serialized: Dict[str, Any], prompts: List[str], **kwargs): 记录LLM开始思考内部推理 self.current_step { step_id: len(self.steps) 1, type: internal_thought_start, content: prompts[0][:500], # 记录提示词开头部分 timestamp: datetime.utcnow().isoformat() } def on_llm_end(self, response: LLMResult, **kwargs): 记录LLM思考结束并保存完整推理 if self.current_step.get(type) internal_thought_start: self.current_step[type] internal_thought # 尝试从response中获取生成的文本思考过程 if response.generations and response.generations[0]: generated_text response.generations[0][0].text self.current_step[content] generated_text self.current_step[duration_ms] kwargs.get(duration_ms, 0) self._save_step(self.current_step) self.steps.append(self.current_step.copy()) def on_tool_start(self, serialized: Dict[str, Any], input_str: str, **kwargs): 记录工具调用开始 self.current_step { step_id: len(self.steps) 1, type: tool_call_start, tool_name: serialized.get(name, unknown), tool_params: input_str, timestamp: datetime.utcnow().isoformat() } def on_tool_end(self, output: str, **kwargs): 记录工具调用结束及结果 if self.current_step.get(type) tool_call_start: self.current_step[type] tool_call self.current_step[tool_response] output self.current_step[duration_ms] kwargs.get(duration_ms, 0) self._save_step(self.current_step) self.steps.append(self.current_step.copy()) def on_agent_finish(self, finish: AgentFinish, **kwargs): 记录Agent最终输出 final_step { step_id: len(self.steps) 1, type: final_output, content: json.dumps(finish.return_values), timestamp: datetime.utcnow().isoformat() } self._save_step(final_step) self.steps.append(final_step) # 可选将本次session完整数据归档到另一张表 self._archive_session() def _save_step(self, step: Dict): 将单步记录存入数据库 cursor self.conn.cursor() cursor.execute( INSERT INTO contracts VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) , ( self.session_id, step[step_id], step[type], step.get(content, ), step.get(tool_name, ), step.get(tool_params, ), step.get(tool_response, ), step.get(duration_ms, 0), step.get(timestamp, ) )) self.conn.commit() def _archive_session(self): 将完整会话归档示例可扩展 pass def get_contract(self) - List[Dict]: 获取本次运行的完整合同 return self.steps4.3 构建可评测的Agent并运行现在我们利用这个回调处理器来装配一个简单的查询Agent。from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain_openai import ChatOpenAI import requests # 1. 定义一个简单的网络搜索工具模拟 def web_search(query: str) - str: 模拟一个简单的网络搜索工具实际项目中可替换为SerpAPI等 # 这里简单模拟返回 print(f[工具调用] 搜索: {query}) # 模拟耗时和结果 import time time.sleep(0.5) return f关于{query}的模拟搜索结果OpenAI近期发布了新的推理模型优化了长上下文处理能力。 # 2. 创建工具列表 tools [ Tool( nameWebSearch, funcweb_search, description用于搜索互联网上的最新信息。输入是一个搜索查询字符串。 ), ] # 3. 初始化LLM和Agent llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 4. 为本次任务创建合同记录器 session_id ftask_{datetime.utcnow().strftime(%Y%m%d_%H%M%S)} contract_recorder ContractRecorderCallback(session_id) # 5. 初始化Agent并传入回调处理器 agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 使用ReAct范式便于产生思考过程 verboseTrue, # LangChain的verbose也会输出一些信息但我们主要依靠自己的回调 callbacks[contract_recorder], # 关键挂载我们的记录器 handle_parsing_errorsTrue ) # 6. 运行一个评测任务 task_prompt 请搜索并总结OpenAI最新发布的模型有什么特点 print(f开始执行任务: {task_prompt}) try: result agent.run(task_prompt) print(f\n最终结果: {result}) except Exception as e: print(f任务执行出错: {e}) # 7. 获取并查看本次运行的“合同” print(f\n 本次任务运行合同 (Session ID: {session_id}) ) contract contract_recorder.get_contract() for step in contract: print(f[步骤{step[step_id]}: {step[type]}]) if step[type] internal_thought: print(f 思考: {step[content][:200]}...) # 截断显示 elif step[type] tool_call: print(f 工具: {step.get(tool_name)}) print(f 参数: {step.get(tool_params)}) print(f 结果: {step.get(tool_response)[:150]}...) elif step[type] final_output: print(f 输出: {step.get(content)}) print(- * 50) # 8. 关闭记录器连接 contract_recorder.conn.close()运行这段代码你不仅会得到最终答案还会在控制台看到一份结构化的“运行合同”摘要并且所有细节都已存入agent_contracts.db数据库。你可以用SQL查询工具更细致地分析。实操心得在实际项目中on_llm_end中获取完整的模型思考过程可能因不同LLM提供商和调用方式而异。OpenAI的Chat Completions API可以通过设置streamTrue并解析流式返回的delta内容来更精细地捕获思考过程。一些专门为Agent设计的API如传闻中的Responses API可能会原生提供更结构化的中间步骤输出。我们的自定义回调器需要根据实际的API响应格式进行调整。5. 评测体系构建从记录到分析与评分有了记录合同的能力下一步就是建立一套基于合同的评测体系。这不仅仅是技术活更是一个设计活。5.1 设计过程性评测指标基于我们记录的合同数据可以定义一系列可量化的指标推理链质量连贯性得分使用另一个LLM或规则判断相邻两步思考之间是否存在逻辑关联。相关性得分判断每一步思考是否紧密围绕任务目标是否出现无关的“胡思乱想”。工具使用效能工具选择准确率针对给定任务Agent选择的工具是否是最佳工具工具调用冗余度是否重复调用了相同工具是否存在可合并的调用工具异常率工具调用失败超时、错误的比例。效率指标步骤经济性完成同类任务的平均步骤数。越少越好但需与成功率权衡。时间经济性总耗时。可以细分为思考耗时和工具调用耗时。任务成功率最终输出是否符合预期。这仍是基础指标但现在我们可以分析失败任务的具体断点在哪一步。5.2 实现自动化评分流水线我们可以构建一个自动化的评测流水线对一批任务如ARC-AGI-3的子集进行批量测试并生成报告。任务加载器读取评测数据集。Agent执行器为每个任务启动一个带合同记录器的Agent实例。合同收集器运行结束后收集每个任务的session_id和合同数据。评分器这是一个核心模块包含一系列“评分函数”每个函数针对一个指标如最终答案正确性、推理连贯性对合同进行分析并给出分数。报告生成器汇总所有任务的分数计算平均分、标准差并生成可视化图表如雷达图展示各维度能力。# 评分器函数示例评估工具调用是否冗余 def evaluate_tool_redundancy(contract_steps: List[Dict]) - float: 评估工具调用冗余度返回0-1分1分最好无冗余 tool_calls [s for s in contract_steps if s[type] tool_call] if not tool_calls: return 1.0 # 没调用工具不扣分 tool_sequences [(s[tool_name], s[tool_params]) for s in tool_calls] unique_calls set(tool_sequences) redundancy_ratio 1 - (len(unique_calls) / len(tool_sequences)) # 将冗余度转换为分数冗余度越高分数越低 score max(0, 1 - redundancy_ratio * 2) # 简单线性惩罚 return round(score, 2) # 评分器函数示例评估最终答案正确性需与标准答案比对 def evaluate_final_answer(contract_steps: List[Dict], ground_truth: str) - float: 评估最终答案是否正确 final_step [s for s in contract_steps if s[type] final_output] if not final_step: return 0.0 agent_answer json.loads(final_step[0][content]).get(output, ) # 简单字符串匹配实际可使用更复杂的语义相似度计算 return 1.0 if agent_answer.strip() ground_truth.strip() else 0.05.3 可视化与对比分析将GPT-5.6 Sol和它的前一个版本或竞争对手在同一批任务上的合同评测结果进行对比是理解其“分数翻三倍”奥秘的关键。对比维度可以制作对比表格展示两者在“平均推理步骤”、“工具调用准确率”、“内部思考连贯性得分”和“最终正确率”上的差异。归因分析如果GPT-5.6 Sol的正确率提升不多但过程分连贯性、工具效能大幅提升说明新版在“思考方式”上更符合人类评测者的逻辑预期从而在重视过程的新评测标准下获得了高分。失败案例诊断挑选两者都失败的任务对比他们的运行合同。也许旧版本在第一步规划就错了而新版本走到了最后一步才在一个细节上出错。这种诊断对于指导模型迭代有巨大价值。6. 避坑指南与未来展望在实践这套“带合同”的评测方法时我踩过不少坑也看到了未来的方向。6.1 常见问题与排查技巧合同数据量爆炸Agent的思考过程可能非常冗长尤其是使用大型上下文窗口时。全量记录会导致存储和传输压力巨大。技巧实施分级记录。对于内部思考可以只记录关键决策点如提出的假设、得出的结论而非每一个Token。或者采用采样记录。对于生产环境考虑使用高效的时序数据库。LLM思考过程难以捕获并非所有LLM API都提供方便的中间输出。像OpenAI的Chat Completions API默认返回的是最终结果。技巧使用streamTrue参数并解析返回的流式数据。更高级的做法是使用提示工程要求模型以结构化格式如JSON输出其思考步骤这需要模型本身具备较强的指令跟随能力。这也是为什么Responses API这类原生支持结构化步骤输出的接口备受期待。评测指标的主观性如何给“推理连贯性”打分这本身可能就需要一个AI来判断陷入“AI评测AI”的循环。技巧初期可以结合规则如检查关键词连贯性和小规模人工标注来建立基准。逐步训练一个专门的“评分模型”来判断过程质量但这个评分模型本身需要严谨的验证。工具调用的副作用与模拟真实工具调用如发送邮件、修改数据库在评测中不可行。技巧搭建一个工具模拟环境。所有工具都被“Mock”或“Stub”替代返回预设的、安全的响应。这既能测试Agent的逻辑又避免了真实操作的风险。这也是很多Agent评测工具的内置功能。6.2 未来展望评测即开发合同即资产记录“整套运行合同”的理念正在将Agent评测从一个事后打分环节转变为贯穿开发始终的核心活动。评测驱动开发EDD合同记录为A/B测试不同Agent架构、提示词、工具配置提供了精细的数据支持。你可以清晰地看到架构A比架构B在哪个具体推理环节更优。合同作为训练数据高质量的运行合同尤其是成功解决复杂任务的合同是训练更强大Agent的绝佳数据。它们展示了解决特定问题的最佳“思维过程”可以用于微调模型或训练模仿学习的策略。安全与合规的基石在金融、医疗等敏感领域完整的运行合同是不可或缺的审计日志。它证明了AI的决策过程是可控、可解释、符合规定的。回到最初的问题GPT-5.6 Sol的ARC-AGI-3分数为何能翻近三倍答案现在很清晰了它很可能在产生更清晰、更合理、更可追踪的推理过程方面取得了突破而这正好撞上了评测标准向“过程可审计”演进的历史进程。对于我们开发者而言这意味着游戏的规则变了。仅仅追求最终答案的准确率已经不够我们必须开始关心我们的Agent是如何思考、如何行动的并学会用“运行合同”这把新的尺子去度量、去优化、去构建下一代真正智能、可靠且透明的AI智能体。