ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

首页/资讯中心/资讯详情

AI Agent评测新范式：从结果到过程，构建可审计的智能体运行合同

发布时间：2026/8/16 23:07:02 拓冰企业网站定制
AI Agent评测新范式：从结果到过程，构建可审计的智能体运行合同

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可能会经历以下步骤：

  1. 内部思考：识别序列中的模式（如旋转、颜色交替、形状增减）。
  2. 子问题分解：将整体模式拆解为位置、形状、颜色等独立维度分别分析。
  3. 假设与验证：生成一个可能的规则，并用前面的序列进行验证。
  4. 生成答案：应用验证通过的规则，预测下一个形状。

如果只记录最终答案“一个红色的三角形”，那么一个靠运气猜对的笨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 quarter=3），返回数据摘要。
  • Agent C（工具Agent）：接收数据和“生成图表”指令，调用Matplotlib库生成图片。

完整的合同能清晰展示数据流的边界、每个Agent的权限范围，以及是否存在越权或危险操作（如尝试执行DELETE语句）。这对于满足Agent安全和合规性要求至关重要。

3. 技术实现剖析：如何构建“运行合同”记录体系？

理解了“为什么”，接下来就是“怎么做”。构建一套能记录Agent完整运行合同的评测体系，并非简单地开启日志功能，它需要从架构设计、数据规范到评测指标进行全链条的革新。

3.1 架构设计：在Agent核心循环中植入可观测层

一个典型的现代Agent架构（如基于Agent框架与编排工具如LangChain、AutoGen或自定义框架）包含感知、规划、执行、反思等循环。要记录合同，必须在每个环节注入可观测性。

  1. 感知/输入层：记录原始任务指令、上下文信息以及来自环境的初始状态。
  2. 规划/推理层：这是记录的核心。必须捕获Agent的“内心独白”——即其内部语言模型（LLM）产生的完整思考过程（Chain-of-Thought）。这通常需要调用LLM时启用相关参数（例如OpenAI的Chat Completions API中的logprobs或结构化输出，或专门为记录设计的Responses API模式）。
  3. 行动/工具调用层：详细记录每次工具调用的请求参数、被调用工具的名称和版本、调用的时间戳、执行耗时、返回结果（或错误信息）。这对于理解Agent Skill的运用至关重要。
  4. 观察/反思层：记录Agent对工具执行结果的解读，以及基于结果对后续规划的调整（反思过程）。
  5. 最终输出层：记录最终答案以及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 requests

4.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.steps

4.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( name="WebSearch", func=web_search, description="用于搜索互联网上的最新信息。输入是一个搜索查询字符串。" ), ] # 3. 初始化LLM和Agent llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) # 4. 为本次任务创建合同记录器 session_id = f"task_{datetime.utcnow().strftime('%Y%m%d_%H%M%S')}" contract_recorder = ContractRecorderCallback(session_id) # 5. 初始化Agent，并传入回调处理器 agent = initialize_agent( tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, # 使用ReAct范式，便于产生思考过程 verbose=True, # LangChain的verbose也会输出一些信息，但我们主要依靠自己的回调 callbacks=[contract_recorder], # 关键：挂载我们的记录器 handle_parsing_errors=True ) # 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可以通过设置stream=True并解析流式返回的delta内容来更精细地捕获思考过程。一些专门为Agent设计的API（如传闻中的Responses API）可能会原生提供更结构化的中间步骤输出。我们的自定义回调器需要根据实际的API响应格式进行调整。

5. 评测体系构建：从记录到分析与评分

有了记录合同的能力，下一步就是建立一套基于合同的评测体系。这不仅仅是技术活，更是一个设计活。

5.1 设计过程性评测指标

基于我们记录的合同数据，可以定义一系列可量化的指标：

  • 推理链质量：
    • 连贯性得分：使用另一个LLM或规则，判断相邻两步思考之间是否存在逻辑关联。
    • 相关性得分：判断每一步思考是否紧密围绕任务目标，是否出现无关的“胡思乱想”。
  • 工具使用效能：
    • 工具选择准确率：针对给定任务，Agent选择的工具是否是最佳工具？
    • 工具调用冗余度：是否重复调用了相同工具？是否存在可合并的调用？
    • 工具异常率：工具调用失败（超时、错误）的比例。
  • 效率指标：
    • 步骤经济性：完成同类任务的平均步骤数。越少越好，但需与成功率权衡。
    • 时间经济性：总耗时。可以细分为思考耗时和工具调用耗时。
  • 任务成功率：最终输出是否符合预期。这仍是基础指标，但现在我们可以分析失败任务的具体断点在哪一步。

5.2 实现自动化评分流水线

我们可以构建一个自动化的评测流水线，对一批任务（如ARC-AGI-3的子集）进行批量测试并生成报告。

  1. 任务加载器：读取评测数据集。
  2. Agent执行器：为每个任务启动一个带合同记录器的Agent实例。
  3. 合同收集器：运行结束后，收集每个任务的session_id和合同数据。
  4. 评分器：这是一个核心模块，包含一系列“评分函数”，每个函数针对一个指标（如最终答案正确性、推理连贯性）对合同进行分析并给出分数。
  5. 报告生成器：汇总所有任务的分数，计算平均分、标准差，并生成可视化图表（如雷达图展示各维度能力）。
# 评分器函数示例：评估工具调用是否冗余 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.0

5.3 可视化与对比分析

将GPT-5.6 Sol和它的前一个版本（或竞争对手）在同一批任务上的合同评测结果进行对比，是理解其“分数翻三倍”奥秘的关键。

  • 对比维度：可以制作对比表格，展示两者在“平均推理步骤”、“工具调用准确率”、“内部思考连贯性得分”和“最终正确率”上的差异。
  • 归因分析：如果GPT-5.6 Sol的正确率提升不多，但过程分（连贯性、工具效能）大幅提升，说明新版在“思考方式”上更符合人类评测者的逻辑预期，从而在重视过程的新评测标准下获得了高分。
  • 失败案例诊断：挑选两者都失败的任务，对比他们的运行合同。也许旧版本在第一步规划就错了，而新版本走到了最后一步才在一个细节上出错。这种诊断对于指导模型迭代有巨大价值。

6. 避坑指南与未来展望

在实践这套“带合同”的评测方法时，我踩过不少坑，也看到了未来的方向。

6.1 常见问题与排查技巧

  1. 合同数据量爆炸：Agent的思考过程可能非常冗长，尤其是使用大型上下文窗口时。全量记录会导致存储和传输压力巨大。

    • 技巧：实施分级记录。对于内部思考，可以只记录关键决策点（如提出的假设、得出的结论），而非每一个Token。或者采用采样记录。对于生产环境，考虑使用高效的时序数据库。

  2. LLM思考过程难以捕获：并非所有LLM API都提供方便的中间输出。像OpenAI的Chat Completions API，默认返回的是最终结果。

    • 技巧：使用stream=True参数，并解析返回的流式数据。更高级的做法是使用提示工程，要求模型以结构化格式（如JSON）输出其思考步骤，这需要模型本身具备较强的指令跟随能力。这也是为什么Responses API这类原生支持结构化步骤输出的接口备受期待。

  3. 评测指标的主观性：如何给“推理连贯性”打分？这本身可能就需要一个AI来判断，陷入“AI评测AI”的循环。

    • 技巧：初期可以结合规则（如检查关键词连贯性）和小规模人工标注来建立基准。逐步训练一个专门的“评分模型”来判断过程质量，但这个评分模型本身需要严谨的验证。

  4. 工具调用的副作用与模拟：真实工具调用（如发送邮件、修改数据库）在评测中不可行。

    • 技巧：搭建一个工具模拟环境。所有工具都被“Mock”或“Stub”替代，返回预设的、安全的响应。这既能测试Agent的逻辑，又避免了真实操作的风险。这也是很多Agent评测工具的内置功能。

6.2 未来展望：评测即开发，合同即资产

记录“整套运行合同”的理念，正在将Agent评测从一个事后打分环节，转变为贯穿开发始终的核心活动。

  • 评测驱动开发（EDD）：合同记录为A/B测试不同Agent架构、提示词、工具配置提供了精细的数据支持。你可以清晰地看到，架构A比架构B在哪个具体推理环节更优。
  • 合同作为训练数据：高质量的运行合同（尤其是成功解决复杂任务的合同）是训练更强大Agent的绝佳数据。它们展示了解决特定问题的最佳“思维过程”，可以用于微调模型或训练模仿学习的策略。
  • 安全与合规的基石：在金融、医疗等敏感领域，完整的运行合同是不可或缺的审计日志。它证明了AI的决策过程是可控、可解释、符合规定的。

回到最初的问题：GPT-5.6 Sol的ARC-AGI-3分数为何能翻近三倍？答案现在很清晰了：它很可能在产生更清晰、更合理、更可追踪的推理过程方面取得了突破，而这正好撞上了评测标准向“过程可审计”演进的历史进程。对于我们开发者而言，这意味着游戏的规则变了。仅仅追求最终答案的准确率已经不够，我们必须开始关心我们的Agent是如何思考、如何行动的，并学会用“运行合同”这把新的尺子，去度量、去优化、去构建下一代真正智能、可靠且透明的AI智能体。

网站建设 企业官网 运营推广
返回列表