最近半年我一直在帮一个团队搭 AI 编程 Agent 的评估流程。最让我头疼的不是模型答错而是模型答对了但你不知道它为什么答对。举个例子我们让一个 Agent 去修复服务端的性能抖动。它最终给了一个 commit测试通过压测指标也恢复到了正常值。从结果看任务完成了。但当我尝试复盘这次修复时只能看到最终改动看不到它尝试过哪些路径、排查过哪些指标、为什么选择了缓存淘汰策略而不是重建线程池。如果这个 Agent 工作在一个需要审计、需要合规、需要承接关键业务的研究环境里这种状态基本不可接受。刚好最近看到了 TRACES 基准名字很直白评估 AI 可审计的探索性研究过程。它想做的事情在我看来不是再测一次“模型有多聪明”而是测试“模型的过程值不值得信任”。这个方向可能是 AI 工程实践里下一个必须补上的环节。1. 先搞清楚“探索性研究过程”和“可审计”到底在评估什么TRACES 这个名字拼接了两块内容探索性研究过程以及可审计性。很多讨论都停留在表面觉得“就是让 AI 把思考过程打印出来”这其实完全低估了它的用意。1.1 探索性研究不是一次问答而是一串决策普通问答任务有明确的输入和期望答案比如“Python 里怎么读取 CSV 文件”答一个示例代码就够了。但探索性研究完全不是这样。探索性研究的起点通常是一个开放问题为什么服务在高峰期出现抖动这批用户的行为能不能被合理分层这个模型在不同数据分布下的表现差异是因为数据偏见还是模型结构回答这类问题Agent 需要自己界定问题边界、收集数据、提出假设、设计验证实验从失败结果里调整方向然后再来一轮。这里的每一个环节都富含决策而且没有标准答案。比如同样是分析服务抖动Agent 可以选择先看核心业务指标也可以选择先看资源水位。常规基准只看最终答案比如最终是否定位到了根因但根因判断背后可能经历了大量犹豫、试错和错误分支。如果只评估终点中间那些复杂性全部被遮蔽了。TRACES 关注的正是这个过程。因为只有过程可检验结果才可信任。1.2 可审计不是日志而是可复现、可复核、可追责很多系统都有日志但日志不等于可审计。日志通常只记录“发生了什么”比如调用了哪个接口、返回了多少字节、耗时多长。可审计意味着更高要求每个中间结果可以重新拿出来检查。执行某个动作之前Agent 依据了哪些输入。调用了哪个工具工具的实际返回是什么。从这一步跳到下一步理由是否站得住脚。最终结论和中间过程是否一致有没有隐藏推理或事后补解释。把这些信息都记录下来后另一个人或者另一个 Agent 才能复现整个推理链验证某个决策是否合理出问题时也才能定位责任点。用一句话概括日志是记录“发生了什么”审计追踪是记录“为什么发生”。TRACES 要推的就是后面这种能力。2. 为什么“答案正确”远远不够黑箱过程的隐性成本现在很多大模型测试基准已经能在数学、编程、考试题目上拿到很高分数。但当一个 Agent 被放到真实研究场景里工作时正确率只是底线过程黑箱会带来一连串隐性成本。2.1 AI Agent 在复杂任务里天然会产生探索分支我在工程实践里观察到一个规律越复杂的任务Agent 的决策路径越像一棵树而不是一条直线。它会先读几个候选文件再跑一个测试发现某个方向走不通回头换个假设甚至可能会因为上下文太长忘记早期结论。普通工具调用场景里这些探索分支无非是多消耗一点 token。但在研究、诊断、代码重构这类任务里探索分支里往往藏着重要信息哪个假设被证伪了为什么被证伪中间有没有跳过关键约束如果评估基准只看最终答案这些探索分支会被全部吞掉。你可能以为 Agent 是一次性想到最优解的实际上它可能走了 20 条岔路只是最后靠运气走到了终点。这个体验在 AI 编程里尤其常见Agent 报了一个 bug 修复方案代码也确实能跑但你追问“为什么没有考虑并发场景”时它给不出答案因为它的轨迹里根本没有这条信息。这不是能力问题而是可审计性缺失。2.2 没有审计痕迹正确结果也可能是偶然命中一个很容易被忽视的事实是黑箱 Agent 产生正确结果不一定意味着它建立了正确理解。我见过一个文本分类任务模型准确率很高但后来发现模型是根据数据源 ID 判断类别的完全没有学到语义特征。如果只看准确率这属于优秀结果如果看过程这就是严重的数据泄漏。这类问题在 Agent 研究任务里同样存在。Agent 可能通过试错反复调整参数最终输出了一个看起来合理的结论但它并没有真正理解问题只是搜索空间足够大被它蒙对了。没有过程审计你无法区分“真正会做”和“碰巧对了”。更要命的是可审计性缺失还会破坏团队信任。人不会被一个自己无法复盘的方案说服。哪怕答案是对的只要中间过程无法解释团队就很难把这个 Agent 放进关键流程。TRACES 这类基准的出现本质上就是在回应这种不信任。2.3 从工程角度看没有审计就谈不上调试和迭代大型语言模型已经被用了很久开发者默认它是个黑箱因此遇到问题只能靠“改 prompt”这种偏玄学的方式。但 Agent 系统不一样它中间有明显状态和动作轨迹。如果 TRACES 能把可审计性变成第一等公民那么开发者排查 Agent 任务失败时就不会像现在这样只能看最终输出而是可以像调试普通软件一样逐行回放。我判断这会成为 AI 工程实践里最关键的转折点之一当 Agent 开始承担研究型任务时可调试性就是可维护性。3. TRACES 基准的核心思路把研究过程拆成可检查的中间轨迹从 TRACES 的名称和方向来看它大概率不是让模型写一段反思文字就结束而是会定义一个结构化轨迹然后沿着轨迹评估多个维度。下面这个理解是基于常见评估基准设计逻辑的推测具体以官方发布为准。3.1 一份值得审计的研究轨迹应该记录什么如果我们要审计一个 Agent 的探索性研究过程至少要能回答以下几个问题任务开始前Agent 拿到的是什么原始输入它每一步执行了什么动作是搜索、读文件、调用程序还是发起网络请求该动作的输入是什么工具返回了什么结果Agent 根据哪条信息决定下一步往哪个方向走最终结论是否能在中间步骤里找到直接证据一种通用的轨迹结构可以长这样{ task_id: exp_001, request: 调研用户服务在高峰期的超时原因, steps: [ { step_id: s1, action: read_metric, input: metrics: http latency p99, output: latency spike observed at 14:00, p99 1200ms, rationale: 先通过延迟指标确认异常时间窗口, tool_call: read_metric(latency_p99) }, { step_id: s2, action: query_log, input: query: error level between 14:00 and 14:30, output: found 12 timeouts in user-service, rationale: 延迟升高可能源于超时重试, tool_call: query_log(\error level user-service\) } ], final_answer: 用户服务在高峰期出现大量超时错误导致请求重试放大 }这个结构的关键点在于每条中间步骤都包含了动作、输入、输出和理由。有了这些字段审计者才能判断 Agent 的每一步是否合理。3.2 从四个维度评估可审计性如果让我给 TRACES 这类基准设计评估框架我会关注四个维度维度评估点典型信号透明度中间轨迹是否完整开放每条决策都有记录没有隐藏的思考空白忠实性最终结论是否与过程证据一致结论可以追溯到前面的工具输出或数据处理可复现性按轨迹重跑是否得到相同结果相同输入、相同动作序列能稳定引出相同输出可问责性能否定位到具体决策点某一步判断失误时可以明确指出是哪一条依据导致的这四个维度并不完全割裂。透明度是基础没有了完整轨迹其他三个都无从谈起。忠实性决定这个 Agent 有没有“事后编解释”可复现性决定评估是否稳定可问责性决定团队能否把失败教训转化为下一次改进。这比单纯看“最终答案对不对”要复杂得多但它更接近真实工程和科研场景的需求。注意如果 TRACES 最终发布时给出了自己的评分细则请以官方材料为准。上面只是基于评估目标推导出的思考框架。4. 怎么用 TRACES 这类基准检查自己的 AI Agent即使 TRACES 目前还没有一个稳定可下载的测试集它背后的评估思路已经可以立刻用到自己的 Agent 项目里。我建议从下面几步开始。4.1 先跑通最小用例再逐步扩展到长流程不要一上来就把完整研究任务塞进去评估。你应该先构造一个步骤不超过 5 步的探索性任务比如“分析一段日志中出现最多的错误等级”让 Agent 在执行过程中显式输出每一步的动作和理由。先确认这些记录是否真的能落地再逐步增加任务复杂度。这个顺序看起来很慢但能帮助你把评估体系稳定下来。如果最小用例跑不通后面做再多扩展都会变成数据泥沙。常见实践里可以先按这个顺序验证确定一个任务集覆盖不同难度的探索性研究场景。让 Agent 在调用每个工具时输出轨迹 JSON。人工检查轨迹字段是否完整。用轨迹单独做一次“最终答案逆向核查”。最后再引入自动评分。4.2 定义你自己的轨迹规范TRACES 即使出现也不可能覆盖所有团队的自定义工具。更现实的路径是你基于 TRACES 的评估思想设计一套自己的轨迹规范。比如在 Python 代码里可以这样定义一个审计记录器class AuditStep: def __init__(self, action, tool_call, input_data, output_data, rationale): self.action action self.tool_call tool_call self.input input_data self.output output_data self.rationale rationale def to_dict(self): return { action: self.action, tool_call: self.tool_call, input: self.input, output: self.output, rationale: self.rationale, } class AuditTrajectory: def __init__(self, task_id, request): self.task_id task_id self.request request self.steps [] def add_step(self, step: AuditStep): self.steps.append(step.to_dict()) def save(self, path): import json with open(path, w, encodingutf-8) as f: json.dump({ task_id: self.task_id, request: self.request, steps: self.steps }, f, ensure_asciiFalse, indent2)然后在 Agent 的每次工具调用前后把输入输出和模型给出的理由追加进去。这是一个很朴素的方式但已经能为审计提供基础材料。真正的难点不是写代码而是让 Agent 在探索过程中愿意诚实记录理由而不是事后补一个合理化的解释。4.3 用轨迹回放进行失败排查当 Agent 给出的最终结论不可信时不要只盯着结论提问。先看轨迹回放从最后一步往前倒推最终结论里提到的证据是否在之前的步骤里出现过如果之前某个工具返回了一个不同的结果Agent 是否忽略了它每一步的 rationale 是否真实基于该步的 input 和 output有没有哪一步无法解释像是硬跳过去的这是一个通用的排查链路先看结果再看证据链路然后看某个中间动作的输入输出最后看 Agent 是否在理由里掩盖了不确定性。多数情况下问题都能在这一层找出来。排查时最该警惕的是“自洽但不忠实”的轨迹每一步看起来都合理组合起来却无法复现最终结论。这种比明显报错更难发现。5. 落地时会遇到的几个现实问题可审计性听起来很美好真落地时会有不少麻烦。这里提前说清楚避免你踩坑。5.1 轨迹记录本身会改变 Agent 的行为当你要求 Agent 每一步都必须输出 rationale 时它可能会变得更保守也可能为了合理性而调整自己的真实探索策略。这就像人一旦被要求写工作日志处理问题的方式就会不自觉地发生变化。更麻烦的是模型可能生成“听起来合理但事后编造”的理由因为训练目标让模型倾向于合理解释一切。所以可审计轨迹需要接受另一层检验忠实性。光记录还不够要验证记录和真实执行的因果一致性。如果只是要求 Agent “输出思考过程”得到的可能是一篇漂亮但不可信的叙事。5.2 可审计不等于可理解轨迹越完整审计成本就越高。真实研究任务往往有几十甚至上百个中间步骤每个步骤都带输入输出和理由。把这么长的 JSON 丢给开发者没有人愿意读完。可审计性的下一步是可理解性。可能需要自动生成摘要把轨迹压缩成关键决策点、舍弃分支和最终证据链。TRACES 如果要做成实用的基准也一定需要考虑如何让审计者不被海量过程淹没。5.3 不是所有任务都需要同等程度的审计探索性研究任务的审计成本很高但并不是每个 AI 应用场景都值得付出这个成本。下面是基于我的经验给出的场景匹配场景审计需求原因日常文案生成低结果风险低可人工快速核对代码 bug 修复中需要知道修改理由但不一定需要逐步回放系统故障根因分析高错判会导致重大事故过程必须可追溯科研假设验证高结论要被审稿人或合规部门复核用户偏好探索中关注结论的同时也要关注是否用了合规数据在项目启动前先确定你需要的审计等级再决定是否引入 TRACES 这类完整评估。6. TRACES 给 AI 工程实践带来的长期信号最后想聊一下TRACES 这个方向背后更长远的意义。6.1 从“结果评测”到“过程评测”过去几年AI 评估的主流是拿一组标准题测模型答对多少。这当然有效但它默认任务是一次性的而且答案可以被明确判定。当 Agent 开始承担复杂任务时这种评测方式就不够了。过程评测的本质是不仅关心 Agent 完成了什么更关心它是如何完成的。这和现代软件工程何其相似。代码写得好不好不只是看功能是否实现还要看可读性、可维护性、测试覆盖率。Agent 的研究过程也需要类似的评价体系。TRACES 可能还有很多不成熟的地方但它把“过程可审计”提到了基准层面这本身就是进步。它意味着行业开始认真对待 AI 系统在真实工作流里的可信度。6.2 Agent 开发会像软件开发一样需要调试器和日志规范一旦过程成为评估对象Agent 开发就不再是“调 prompt”这种玄学。开发者会需要调试器需要日志规范需要断点回放需要标准化的审计追踪格式。这些基础设施目前还很不完善但需求已经非常明确。可以预见的趋势是未来成熟的 Agent 框架会内置审计模块而不是靠开发者后期手工拼装。审计日志也会成为 Agent 能力的核心卖点之一而不是附带的 trace 信息。对做 AI 开发的人来说提前掌握轨迹设计和审计评估会是一项非常实用的技能。6.3 对研究人员和工程团队的不同建议如果你在高校或研究机构关注 TRACES 这类基准时重点是理解它如何定义探索性任务、如何评判过程质量也可以尝试用它测试自己的 Agent 是否具备科研所需的可复核性。如果你在工程团队尤其是做 AI 编程、故障诊断或数据分析 Agent 的团队我建议你更主动一些不需要等 TRACES 完全成熟先在自己的 Agent 流程里加入结构化轨迹然后逐步建立起“动作记录 理由记录 结论追溯”的审计链路。AI 系统正在从一个“给结果的工具”变成“承担过程的协作者”。这个过程一旦发生可审计性就不再是加分项而是准入门槛。你不需要等着看哪个基准成为标准。先把自己的 Agent 过程打开让每个决策都有一份可以被追问的记录。TRACES 这个名字提醒我们的其实是 AI 工程里一个早就该补上的环节不是把所有步骤都塞进日志而是让每个关键决策都经得起追问。