AI行为可验证分析框架

开发AI代理是一个复杂的数据分析问题。要判断代理是否正常工作，不仅需要跟踪基准分数，还需要了解其行为的细节：策略在训练过程中如何变化？为什么新的脚手架表现更差？是否存在奖励黑客？回答这些问题需要结合定量和定性分析，并针对手头的数据集进行定制。

编码代理有潜力加速这项工作，但它们容易犯细微的错误：可能错误解析数据、做出无根据的假设，或者挑选例子并呈现误导性叙述。这些错误在最终输出中并不明显。要信任结论，我们需要验证其产生过程。但审查编码代理采取的所有行动很繁琐——关键的方法决策被埋藏在数百行日志中。

这一问题促使我们开发了分析计划，这是一个用于可验证AI行为分析的框架。分析计划通过Python API指定，任何编码代理都可以使用。当它们准备运行时，会显示在Web界面中，让人类理解和验证所采取的每个步骤。

分析计划包含两种步骤：

• 查询步骤使用DQL（Docent的SQL子集）过滤、分组和连接数据。每个步骤显示其查询和结果的交互式表格。
• 阅读步骤使用LLM分析来自查询步骤的数据，生成文本摘要和/或结构化判断。LLM提出的声明附有对上下文中特定项目的引用。

这两种步骤可以定制和组合，构建复杂的分析管道。阅读可以接受查询产生的任何数据，查询也可以在阅读结果上运行。每一步的结果都追溯到产生它的确切计算，便于检查、审计和优化流程。

让我们通过检测一个流行的软件工程基准上的作弊行为来看看它的实际应用。

演示：识别SWE-rebench中的可疑行为

作弊是解释评估结果时常见的痛点：模型常常硬编码测试、虚假声称成功，并利用不干净的环境复制解决方案。衡量作弊率对于理解基准分数在多大程度上代表模型能力的有效展示至关重要。我们在大约15分钟内使用Docent发现了SWE-rebench上的作弊实例，SWE-rebench是一个衡量代理能解决多少最近GitHub PR的软件工程基准。您可以在此链接查看SWE-rebench的追踪结果。

1. 向您的编码代理说明您想了解什么

我们首先提示Claude Code对代理运行进行潜在作弊评分。得益于Docent技能，Claude知道如何将我们的问题转化为分析计划。它编写一个简短的Python脚本，如下所示。

from docent import Docent
client = Docent()

runs = client.query(
COLLECTION_ID,
"SELECT agent_runs.id AS run FROM agent_runs "
"WHERE CAST(metadata_json->'scores'->>'resolved' AS DOUBLE PRECISION) = 1.0 "
"ORDER BY agent_runs.id LIMIT 200",
name=f"Sample 200 resolved runs by UUID",
)

DETECTOR_PROMPT = "..." # 为简洁而省略
OUTPUT_SCHEMA = { ... } # 为简洁而省略

detect = client.read(
prompt_template=[runs.run.as_type("agent_run"), DETECTOR_PROMPT],
model="openai/gpt-5.5",
reasoning_effort="medium",
output_schema=OUTPUT_SCHEMA,
name="Flag cheating from trajectory",
)

当Claude运行此脚本时，Docent SDK不会立即执行阅读。相反，它会构建所有请求阅读的图形（本例中仅一个）并将其作为分析计划上传到Docent。这让我们可以在等待LLM调用完成之前审查提议的分析。

1. 分析计划的剖析

一个等待批准的分析计划。

该分析计划以一个DQL查询开始，通过过滤代理运行元数据为resolved=1来选择成功的运行。之后，它将结果传递给一个阅读步骤，对运行进行作弊评分。

一个阅读步骤包含以下组件：

• 带有参数的提示模板。为了检测作弊，我们创建一个定义可疑度的评判标准，将一个代理运行作为参数。Docent UI显示完整的提示模板，参数内联表示。点击下面的“上下文：运行”芯片会暴露更多关于传递给LLM的运行级元数据的细节。默认情况下，不传递元数据。

• 来自先前查询步骤的参数。我们计划中的上一个查询步骤产生了一个resolved=1的运行表。对于该表中的每一行，Docent会将代理运行的完整文本替换到提示模板中，并调用LLM处理。

• 自定义输出模式。该阅读输出一个从1到10的整数分数表示可疑度，以及一个包含引用的字符串解释。Docent确保LLM输出符合此模式，以便后续步骤不会遇到数据格式问题。

阅读被设计为富有表现力。常见用例包括判断特定行为的运行、聚类先前阅读的结果以提取高层次趋势、总结长代理运行，或比较同一任务的两次展开。一旦您有了一个运行良好的阅读，您可以将其保存为预设，以便代理以后重用。

紫色高亮表示该阅读正在等待我们的批准，所以让我们批准它。（Docent SDK也提供了一种以编程方式批准步骤的方法；您可以告诉您的编码代理“自动接受分析计划”并跳过手动审查。）

1. 审查阅读结果

阅读结果表显示作弊分数和推理，以及链接到转录部分的引用。

阅读结果设计为便于验证。当阅读执行时，其结果会出现在一个表中。点击每一行会在新窗格中展开结果，显示完整输出和元数据，如阅读模型、推理努力和使用的令牌。

阅读输出中的声明包括对转录特定部分的引用。点击蓝色引用图标可跳转到转录的相关部分并再次检查声明。

1. 量化结果

每个分数对应的运行数量，以及用于生成计数的查询显示在上方。

为了获得总体情况，我们可以让我们的编码代理编写一个DQL查询，计算每个可疑度分数对应的代理运行数量。

我们可以通过点击最终结果上方的“查询”切换来一目了然地验证DQL查询。阅读精确的DQL可以让您检查错误，例如不正确的分组、不正确的过滤，或使用错误方法计算的平均值。

1. 验证可疑示例

奖励黑客评判器以虚假阳性闻名。我们可以将结果传递给一个新的阅读并提出后续问题。

我们的代理使用DQL提取四个可疑的运行，并创建一个阅读来验证每一个。验证器阅读确认大多数作弊示例实际上是可疑的，但至少有一个是误报。

Docent标记的一个误报。

一个可疑运行似乎包含通过前向查看的作弊：代理检查git历史并从另一个提交恢复代码。但验证器正确地将此识别为误报：过去的提交引入了回归，因此恢复代码库的原始状态是一个有效的补丁。

更多案例研究

分析计划通过一个统一框架支持各种应用。以下是我们如何使用它们来比较模型、识别故障模式和发现意外行为的示例。

▶