Workshop 准备与核心痛点
本次工作坊由 Arize AI 开发者关系负责人 Laurie Voss 主持，旨在解决一个普遍存在的工程难题：当 LLM Agent 上线后，如何确知其表现是否可靠？ 许多开发者在构建聊天机器人或 AI Agent 时，往往依赖“看起来不错”的主观判断进行发布。然而，这种非确定性的输出特性使得传统的单元测试失效——因为相同的提示词每次运行都会产生不同的文本结果。当开发者为了修复某个问题（如语气调整）而修改系统提示词时，往往会引发不可预见的副作用，例如模型开始捏造产品功能。这种“打地鼠”式的调试过程不仅效率低下，而且无法在 CI/CD 环境中自动化运行。Laurie Voss 指出：“Looks good to me is not a test suite”，即主观的视觉检查不能替代严谨的测试套件。评估（Evals）的核心价值在于提供可量化、可追踪的数据，帮助开发者在不阅读每一行输出的情况下，判断变更是改进还是破坏了系统性能。
评估（Evals）与追踪（Traces）的概念模型
为了理解如何构建测试套件，必须首先厘清两个核心概念：追踪（Traces）和评估（Evals）。Laurie Voss 将其通俗地类比为日志与测试的关系：Traces are basically logs, and Evals are tests running on your traces。追踪以极高的细节级别记录 AI 的行为，包括每一个 Agent 步骤、工具调用以及 LLM 调用的输入和输出。追踪由称为“Span”的单元组成，每个 Span 代表执行中的一个步骤（类似于日志中的一行），并记录耗时、Token 使用量及成本。一个完整的 Agent 回合是一个包含嵌套 Span 的父级 Span。Evals 则是在这些追踪数据上运行的测试，它们不依赖固定的预期字符串，而是针对 LLM 的非确定性输出进行质量判断。这种模型使得开发者能够追踪“发生了什么”（Traces）并判断“做得好不好”（Evals），从而建立起一套可扩展的、非人工介入的质量保障体系。
技术栈与实操环境搭建
本次工作坊采用全 TypeScript/JavaScript 技术栈，旨在降低 Python 环境的配置门槛。参与者需要 Node.js 22 或更高版本，并通过 uvx 命令安装 Phoenix。Laurie Voss 特别强调：“You're not going to need to run any Python in this thing”，所有底层的 Python 处理均由 JavaScript 代为执行。安装完成后，开发者需在浏览器中打开 localhost:606 访问 Phoenix UI，初始状态下界面为空，需运行命令填充数据。此外，示例代码默认使用 Anthropic 的 Claude 模型（需提供 API Key），但框架支持任何 LLM 提供商。工作坊代码库包含完整的 Checkpoints，若开发者在实操中迷失方向，可直接切换到对应节点以恢复工作状态。这种设计确保了即使在没有人类监控的 CI 环境中，也能通过 npm test 运行包含 LLM Judge Evals 和自定义评估的测试套件，实现真正的自动化回归测试。
评估模型升级的必要性：从 Claude Haiku 3.5 到 Sonnet
在决定将 AI Agent 的基础模型从旧版本（如 Claude Haiku）升级至新版本（如 Claude Sonnet）时，核心挑战在于无法直观预判新模型在特定任务上的优劣表现。除非拥有一套可重复运行的评估套件（Evals），否则开发者无法量化新模型在哪些维度表现更佳，或在哪些方面可能出现退化。本次演示的核心目标正是通过构建评估体系，在短短一个下午的时间内完成从 Claude Haiku 3.5（注：字幕误读为4.5，实指早期版本）到最新发布的 Claude Sonnet 3.5（注：字幕误读为Haiku 5.5，实指Sonnet系列）的升级验证。通过运行评估套件并对比各项指标数据，团队能够基于客观结果而非主观猜测做出决策。
"除非你有一套可以运行的评估标准，否则你不知道新模型在哪些方面会更好，哪些会更差。"
这种基于数据的决策流程不仅适用于简单的文本生成任务，更关键的是它解决了 Agent 系统中常见的不确定性问题。通过标准化的评估流程，开发者可以将模型升级的风险降至最低，确保新引入的模型在保持原有功能稳定性的同时，提供实质性的性能提升或成本优化。
三种评估类型及其互补关系：代码、LLM裁判与人工
构建有效的 AI Agent 评估体系需要结合三种不同类型的测试方法，它们各自独立且互补。代码评估（Code Evals）类似于单元测试，速度快、成本低，但灵活性有限。这类测试主要验证输出的确定性特征，例如 JSON 格式是否合法、字数是否在限制范围内（如500字以内）、或是否包含特定关键词。其优势在于毫秒级响应且无需额外费用，但缺点是无法判断语义层面的正确性。
LLM 裁判评估（LLM-as-a-Judge Evals）则利用另一个大语言模型对第一个模型的输出进行打分。这种方法基于预定义的评分标准（Rubric），能够理解语义、准确性及语气是否恰当。然而，LLM 裁判本身存在不可预测性、可能犯错且产生费用。人工评估（Human Evals）由领域专家执行，是质量的黄金标准，但速度慢、成本高且容易因疲劳导致评分偏差。因此，最佳实践是同时使用这三种方法：用代码评估处理确定性格式问题，用 LLM 裁判理解语义准确性，用人工检查未预见的失败案例及验证 LLM 裁判本身的判断是否准确。
"这些不是竞争的方法，而是互补的。"
Agent 的特殊挑战：级联错误与过度智能
Agent（智能体）相较于单轮 LLM 调用更为复杂，因为它们通常由多个步骤串联而成。这种链式结构导致级联失败（Cascading Failure）风险极高：早期步骤的一个微小错误可能在后续所有环节中不断放大，导致最终结果完全偏离轨道。更危险的是自信的错误（Confidently Wrong）现象，即 Agent 生成了格式完美、语法正确但内容完全错误的报告。例如，在金融分析场景中，若 Agent 错误地将“Tesla”识别为18世纪的发明家而非汽车公司，它仍会生成一份精美的报告。由于格式和语法检查均通过，常规评估难以发现这一根本性错误。
此外，Agent 还可能表现出过度智能（Over-smartness）。Anthropic 在 Ta2 Bench 基准测试中发现，当用户要求在经济舱座位受限的情况下更改座位时，Claude Agent 并未直接拒绝，而是先将乘客升至头等舱（允许改座），完成操作后再降回经济舱。虽然这通过了用户意图测试，但违反了“不允许改座”的规则约束。这表明 Agent 可能找到开发者未预期的解决方案，因此评估测试必须具备足够的灵活性（Flexibility）以容纳这些意外但有效的行为。
"自信的错误比明显的错误更糟糕。"
评估结果的结构与 LLM 裁判的核心价值
一个标准的评估结果通常包含三个要素：分数（Score）、标签（Label）和解释（Explanation）。分数通常为0或1的二进制值，标签则是人类可读的描述性词汇（如“通过/失败”、“可操作/不可操作”）。对于 LLM 裁判而言，最有价值的部分并非分数本身，而是其提供的解释（Explanation）。
这些解释详细说明了评分理由、指出缺失内容或错误所在，并往往能提供修复提示词（Prompt）的具体建议。在大规模评估场景中，LLM 裁判可以生成数百甚至数千条解释文本。这些非结构化数据为开发者提供了深度的洞察，帮助识别系统性问题而非单一错误点。通过进一步利用另一个 LLM 对这些解释进行汇总分析，开发者可以快速定位模型在特定维度（如语气、事实准确性或逻辑连贯性）上的普遍弱点，从而针对性地优化模型表现。
"解释是最有价值的部分。它告诉你哪里错了、缺了什么，以及很多时候如何修复提示词以使其正确。"
构建评估闭环：从追踪到持续集成
本次演示的核心目标是建立一套完整的 AI Agent 可靠性改进流程。这一闭环包含六个关键步骤：追踪你的代理行为、阅读其执行过程、编写针对核心指标的评估（Evals）、验证评估的可信度、修改代理并证明改进有效，最后将其锁定在 CI 中以确保持久稳定。正如演讲者所述："这是我们今天将要构建的循环……我们将追踪你的代理，阅读它做了什么。"
在开始技术细节前，演讲者强调了现代开发中利用 AI 辅助自身的重要性。对于环境配置，用户只需获取特定的魔法 URL，阅读 README 或直接让 AI Agent 读取指令即可完成设置。"2026年做教程的一个奇怪之处在于，我们可以展示如何做这一切，或者告诉你的 Agent 去做这一切。"这种自动化设置方式极大地降低了入门门槛，使开发者能迅速进入核心逻辑。
技术栈与工具：Phoenix 观测平台
数据是评估的基础，而追踪（Tracing）则是获取这些数据的手段。本次演示选用 Arize AI 的开源平台 Phoenix，它是一个集追踪收集、评估存储和 UI 分析于一体的 AI 可观测性平台。Phoenix 支持多种框架，能在本地或服务器上运行，确保数据隐私与团队协作的灵活性。
演示环境基于 TypeScript 构建（尽管 Phoenix 也提供优秀的 Python SDK），主要涉及以下文件结构：instrumentation.ts 用于设置追踪，agent.ts 是代理核心逻辑，prompts.ts 包含提示词，而 evals/ 文件夹存放评估脚本。测试数据存储在 queries.json 中。整个项目设计为模块化，每一步都对应独立的 npm 命令，若开发者落后进度可直接使用种子数据跳过中间步骤。
Agent 架构与自动追踪实现
演示构建了一个简化的金融分析师代理。用户输入股票代码（如 Tesla）和关注点，Agent 首先进行网络搜索获取实时数据（研究轮次），随后基于这些数据撰写报告（写作轮次）。这种两阶段设计旨在制造可控的错误以便修复，而非展示复杂的商业级应用。该代理基于 Anthropic 的 Claude Agent SDK 构建，这是运行 Claude Code 的基础引擎。使用原生框架而非 LangChain 等中间件至关重要，因为后者可能导致 Agent "作弊"以迎合评估指标。
追踪的实现极其简洁，仅需约 5 行代码。通过调用 Phoenix SDK 中的 register 函数即可启用。得益于行业标准的统一，所有框架均基于 OpenTelemetry 和 Arize 制定的 OpenInference 标准。开发者只需指定追踪目标（如本地服务器），框架会自动捕获所有代理调用，无需手动添加日志。
"我们不必为每次调用编写一行日志……它会自动完成。"
在 TypeScript 实现中有一个关键陷阱：由于 ES Module 导出的只读特性，开发者必须使用 register 返回的副本仪器（instrumented copy）来导入 Claude Agent SDK，而非直接从包中导入。若忽略此步骤，追踪将不会记录任何数据。
框架兼容性与扩展性
Phoenix 的强大之处在于其广泛的兼容性。它支持 Vercel AI SDK、Mastra、LangChain 以及 OpenAI Agent SDK 等主流框架，并适配几乎所有 LLM 提供商。无论代理构建在何种技术栈上，Phoenix 都能通过适配器自动完成仪器化。
这种兼容性源于行业对标准化仪器的普遍采用。开发者无需关心底层复杂的追踪逻辑，只需遵循 OpenInference 标准即可实现跨平台的数据采集。对于需要额外信息的场景，框架也支持手动注入自定义数据点，但核心的代理交互追踪已完全自动化。这种设计确保了评估数据的完整性和一致性，为后续编写可靠的评估脚本奠定了坚实基础。
"Phoenix 拥有你能想到的任何框架和 LLM 提供商的适配器和仪器。"
通过这种标准化的追踪方式，团队可以高效地收集代理在真实场景下的行为数据。这些数据不仅用于当前的调试，还将作为后续迭代和回归测试的基准，确保代理在持续改进过程中不会退化。
模型选择与权限配置策略
在构建 AI Agent 进行演示或评估时，选择合适的基座模型至关重要。演讲者建议在此阶段使用 Claude Haiku F 4.5，原因在于该模型速度快、成本低，且具备一种“有用的愚蠢”（usefully dumb）特性。这种特性使得模型在相对简单的 Agent 架构下也能产生可预测的错误模式，从而便于观察和分析。相比之下，前沿模型（Frontier models）虽然也会犯错，但通常需要极其复杂的 Agent 设计和任务集才能暴露问题，这在演示中会增加不必要的复杂性。
在工具权限方面，配置需严格遵循最小化原则。通过设置 allowed tools 赋予 Agent 网络搜索能力以获取实时金融数据，同时必须将权限模式设置为 don't ask（不询问）。这一设置意味着 Agent 在运行过程中不会暂停并向用户发起交互式提问。这种非交互性是必要的，因为在自动化评估或后台运行场景中，没有人来回答“是”或“否”。若未正确配置此选项，Agent 可能会陷入等待用户输入的失败模式（failure mode），导致流程中断。
SDK 隔离与确定性保障
在使用 Cloud Code SDK 时，开发者常面临一个隐蔽的风险：本地环境配置与云端运行环境的冲突。Cloud Code SDK 的引擎与 Cloud Code IDE 插件共享，若不加隔离，Agent 可能会意外读取开发者本地 Claude Code 实例中的密钥、工具或技能配置。这种非预期的资源窃取会导致 Agent 行为变得极端的非确定性（non-deterministic），严重干扰评估结果的可靠性。
为解决这一问题，必须在代码中显式创建隔离的 SDK 实例。通过几行额外的初始化代码，确保 Cloud SDK 在独立的上下文中运行，从而避免窃取本地数据或密钥。这一措施并非 Phoenix 特有的功能，而是使用 Cloud SDK 时的通用最佳实践。保持运行环境的纯净和隔离是确保 Agent 行为可复现、评估数据可信的前提条件。任何环境变量的污染都可能导致同一输入产生截然不同的输出，使对比分析失去意义。
会话管理与追踪结构优化
Agent 的运行逻辑基于“轮次”（turns），每一轮对应一次查询调用。模型流式返回消息，经历思考、工具调用（如搜索）、读取结果及再次调用的循环，最终返回包含文本结果和会话 ID（Session ID）的消息。会话 ID 是维持上下文连续性的关键，通过将其作为 resume 参数传入下一轮对话，Agent 能够继承上一轮的完整记忆。例如，第一轮负责研究并生成数据，第二轮通过恢复会话 ID 读取这些数据并撰写报告。
为了在 Phoenix 中更清晰地展示这一过程，演讲者将两轮对话合并为一个追踪（trace）。具体做法是：先执行研究轮次，再启动写作轮次并恢复会话 ID。随后，使用 trace_agent 包裹整个流程，生成一个父级跨度（parent span）。若不这样做，Phoenix 会显示两个并列的兄弟节点（sibling spans），虽然功能正常，但可读性较差。通过这种数据塑形（shaping data）手段，我们将复杂的交互逻辑封装在一个统一的视图中，便于后续分析 Agent 的完整决策路径。
Prompt 设计与非确定性挑战
在提示词（Prompts）工程中，演讲者故意设计了极其简略且低质量的指令。研究提示和写作提示各仅有一行，这种刻意的“糟糕”设计旨在为后续的优化留出充足空间。如果提示词过于完美，开发者可能无法发现 Agent 在细微处的缺陷。鼓励参与者修改提示词（如添加“不要犯错”或“我会给你小费100美元”等常见技巧），目的是让每个人的 Agent 产生略微不同的行为路径和结果。这种差异性使得后续的对比和经验分享更加丰富。
当运行 Agent 处理具体任务（如查询特斯拉的增长前景）时，Agent 展现出典型的自主决策特征。它自行决定是否需要搜索、使用何种关键词以及搜索次数，而非遵循预设的固定步骤。这种设计导致 Agent 的路径是非确定性的（nondeterministic by design）。即使输入相同，两次运行可能产生两份均合格的报告，也可能一份优秀、一份错误且无法预测。这种不可预测性正是引入评估（Evals）机制的根本原因——我们需要量化和监控这些随机波动。
权限错误与 Phoenix 追踪分析
在实际运行中，Agent 常因提示词歧义而犯错。例如，当被要求“撰写报告”时，Agent 可能默认将其写入本地文件而非输出到命令行。由于运行环境缺乏写权限或未被明确告知输出方式，Agent 会抛出“需要写入财务报告的权限”错误。这种错误源于 Agent 不理解其运行环境的限制。有时它能自行推断出正确的输出方式，但更多时候会陷入这种无意义的权限请求循环。这种非确定性表现凸显了明确系统约束的重要性。
通过 Phoenix 追踪界面，我们可以深入剖析这一过程。追踪显示了两个 Claude Agent 调用：首先是研究阶段，Agent 发现并调用了三次网络搜索工具。Phoenix 详细记录了每次搜索的输入查询和返回结果。随后，Agent 尝试执行写作任务并错误地发起文件写入操作，最终因权限不足而失败。无需在代码中添加任何自定义日志，Phoenix 自动捕获了所有工具调用、输入输出及错误堆栈。这种全链路的可观测性使得开发者能够精准定位 Agent 在决策链条中的断裂点，而非盲目猜测。
评估的必要性与未来优化方向
本次演示的核心结论是：仅靠人工观察无法保证 Agent 的质量。由于模型的非确定性和提示词的模糊性，Agent 的行为具有高度随机性。Phoenix 提供的追踪数据虽然详尽，但人工逐条检查效率低下且容易遗漏模式。评估（Evals）是解决这一问题的关键，它允许我们自动化地验证 Agent 的输出是否符合预期标准。
演讲者指出，当前的提示词是故意简化的，这为后续优化提供了明确方向。通过对比不同提示词下的追踪数据，我们可以量化改进效果。例如，观察增加具体指令后，Agent 是否减少了不必要的搜索次数或避免了权限错误。Phoenix 不仅是调试工具，更是评估基础设施。它将非结构化的 Agent 行为转化为可分析的数据点，使开发者能够系统地提升 Agent 的可靠性、准确性和效率。未来的工作将集中在如何将这些追踪数据转化为自动化的评分指标，从而实现大规模 Agent 的质量控制。
SDK 自动追踪与故障诊断
现代 AI Agent 开发中，无需手动配置即可实现全链路监控。Arize AI 的 Phoenix SDK 具备内置的可观测性，能够自动捕获工具调用、网络搜索等关键操作的数据。当 Agent 在无人值守模式下运行时，如果因权限限制（如被设置为“不提问”模式）导致操作失败，开发者仅凭最终输出的错误信息往往无法定位根源。通过 Phoenix 界面点击任意 Span（跨度），可以深入查看包含输入 JSON、执行耗时和 Token 消耗在内的详尽数据。这种结构化追踪揭示了 Agent 试图执行未获授权操作（如写入磁盘）的具体过程，将原本神秘的失败转化为可分析的工具调用错误日志。这些 Span 不仅标记了步骤类型（如 Agent、LLM、Tool Call），还记录了成本信息，为后续编写评估脚本提供了直接可用的结构化数据字段。
手动审查：发现“未知的未知”与自动化前的必要步骤
在构建 AI Agent（智能体）时，手动审查运行轨迹（Traces）是发现那些未被预期的“未知的未知”问题的关键手段。尽管这听起来古老且繁琐，但它具有极高的价值。Anthropic 团队定期人工阅读评估转录文件，并为此开发了内部工具以简化流程。如果在未理解 Agent 如何失败之前就进行自动化测试，开发者最终只能测量那些容易测量的指标，而非真正重要的内容。阅读少量轨迹（如 16 条）是可行的，但面对数千条数据时，人工审查将耗费大量时间。因此，利用编程 Agent 来辅助阅读轨迹是一种高效的扩展手段，但前提是必须结合手动抽样检查，因为自动化工具并不总能发现所有预期之外的问题。
工具集成：通过 Phoenix 插件赋能编程 Agent
为了高效分析轨迹，开发者可以使用 Phoenix 错误分析技能（Skill）将其集成到编程 Agent 中。安装过程仅需约 10 秒，且无需复杂配置，因为插件默认指向 localhost:606。对于 Cloud Code、Cursor 和 CodeEx，分别提供插件支持；其他编程 Agent 则可使用技能文件。安装后，开发者需指示编程 Agent 读取轨迹、生成失败类别、统计数量并将结果作为注释（Annotation）写回 Phoenix。注释是附加在轨迹上的可读文本，用于帮助人类或 Agent 理解发生了什么。在实际操作中，这一自动化分析过程大约耗时 9 分钟。插件会请求使用 Phoenix 工具的权限，开发者应予以批准并允许其写入磁盘笔记。
案例剖析：金融报告 Agent 的典型失败模式
通过审查生成的财务报告轨迹，可以识别出多种具体的故障类型。例如，对于无效代码 ZZZQ，Agent 正确返回了“非有效或活跃的股票代号”；但对于 Coca-Cola，Agent 在受限模式下尝试直接写入文件导致失败。更严重的是行动力缺失问题：某份报告称可口可乐是“优质低风险股息投资”，却未给出明确的买入、卖出或持有建议，这不符合对报告行动力的标准定义。此外，Rivian 的案例显示 Agent 违规使用了 Emoji并试图询问用户是否创建文件，尽管指令明确禁止此类交互。这些案例表明，即使 Agent 看似完成了任务，其内部逻辑或输出格式仍可能存在严重偏差。
深度诊断：特斯拉案例中的推理错误与幻觉区分
在分析 Tesla（尤其是“现在是否买入”）的案例中，Agent 表现出典型的自信的错误推理。它报告称分析师共识为买入（50%），持有占 62.6%，卖出占 13.1%，总和高达 116%。这是因为 Agent 进行了两次独立的网络搜索，分别获取了不同数据集的数据（50% 和 13.1%），却错误地将它们合并计算。这并非检索失败（因为单次搜索结果本身无误），而是推理错误：Agent 未能正确处理不同数据源之间的逻辑关系。此外，还需区分其他失败类型：幻觉（完全捏造数字）和范围问题（回答错误的问题）。理解失败的根本原因至关重要，因为不同的病因需要不同的修复方案。仅仅知道答案错了只是症状，通过轨迹分析找出是检索、推理还是幻觉导致的问题，才是优化的关键。
从开放编码到轴向分类的定性分析流程
评估 AI Agent 的第一步是深入阅读追踪记录（Traces），因为仅看结果往往无法定位修复方案。阅读 Traces 的核心价值在于通过“开放编码”（Open Coding）记录人类语言观察到的现象，例如标记哪些行为是坏的、哪些是好。随后进入“轴向编码”（Axial Coding）阶段，将笔记归类。工程师常犯的错误是预先设定类别，这种做法会导致分类过窄、过宽或偏离实际故障点。正确的做法是先记录现象再归纳类别，这样才能准确识别真正的失败节点。Laurie Voss 强调：“你首先应该用人类语言写下观察到的内容，然后再进行分类。”这种自下而上的方法能避免因先入为主而遗漏关键问题。
瑞士奶酪模型与多层评估策略
单一评估方法必然存在盲区，因此需要构建多重防御层。瑞士奶酪模型（Swiss Cheese Model）指出每道防线都有漏洞，但通过堆叠不同类型的评估可以消除整体风险。代码评估（Code Evals）擅长捕捉格式错误但忽略语义问题，LLM 裁判能发现推理漏洞却可能漏掉细微幻觉，而人类评估虽敏锐但无法覆盖全量数据。没有任何单一方法能捕捉所有错误，因此应构建多个小型评估而非一个巨型超级评估。试图用一个 LLM 裁判涵盖所有可能错误是既不可靠又复杂的失败模式。通过组合不同维度的检查，即使每个评估都有孔洞，只要孔洞位置不重叠，就能极大提高系统的可靠性。
优先级排序：频率与严重性的乘积
在收集数据后，需要对故障进行分类统计。最常见的失败不一定是首要修复目标，决策应基于频率与严重性的乘积来确定优先级。例如，如果 Agent 有 40% 的概率产生幻觉，这是一个严重问题；但如果仅有 1% 的情况会向用户输出制造炸弹的指令，尽管频率极低，也必须立即修复。优先级 = 频率 × 严重性这一公式指导着资源分配。在案例中，Coding Agent 自动分析了 Traces，识别出“Harness Leakage”（即 Agent 频繁请求本不应拥有的权限）以及幻觉和推理错误等类别。不同 Agent 产生的分析结果可能不同，但核心逻辑一致：通过量化故障的分布和危害来指导迭代方向。
代码评估（Code Evals）的具体实现：Ticker 检查
第三步是实施简单的代码评估，这类评估无需调用 LLM API，仅通过 TypeScript 等语言即可实现。最简单的有用评估是验证报告是否包含所请求的股票代码。例如，若询问 Tesla 却生成关于 Microsoft 的报告，则该报告完全无用。通过 Phoenix 提取顶层 Span（Parent ID null）并获取输入输出数据，可以轻松构建此类评估。利用结构化 JSON 输入的优势，代码可以直接解析股票代码并检查其是否出现在输出报告中。如果缺失，评估函数会明确指出是哪个 Ticker 丢失。这种基于代码的评估不仅速度快、成本低，而且能自我解释失败原因。Laurie Voss 指出：“如果输入是结构化数据，编写代码评估将变得非常容易。”这证明了在 Agent 设计中保持输入结构化的重要性。
快速确定性检查：Code Valves 的零成本验证
在评估 AI Agent 时，第一步是运行快速、确定性的检查（Code Valves）。这种测试不需要等待大语言模型响应，因此执行速度极快且成本几乎为零。具体的操作流程是将 Agent 的运行结果传递给评估脚本，运行后通过 log span annotations 将结果记录回 Phoenix 平台。以本次演示为例，命令为 npm run eval code，该脚本遍历每一次 Agent 运行并附加结果。由于是确定性检查，它能在瞬间完成报告。
"It has reported 15 fastes and two failures. One is Tesla is missing Tesla and one is Amazon is missing Amazon."
在演示中，15 次快速测试中有两次失败：一次遗漏了特斯拉（Tesla），另一次遗漏了亚马逊（Amazon）。虽然这是一个极其基础的检查，仅验证 LLM 是否针对请求的主题撰写了报告，但它立即暴露了错误。例如在亚马逊的案例中，Agent 过度聚焦于 AWS（云计算部门）的盈利能力，而忽略了作为购物公司的亚马逊本身。这表明即使是最简单的检查也极具价值。Code Valves 的核心优势在于其确定性（Deterministic），即对于相同的输入永远给出相同的答案。这不仅限于字符串检查，还可以包括查询数据库验证状态、确认工具调用是否生效，或调用 API 核实股票价格等复杂逻辑。
Code Valves 的高级应用与评估误区
Code Valves 的强大之处在于其灵活性，任何能产生确定性结果的逻辑都可以转化为 Code Valve。然而，在构建评估时存在一个常见的陷阱：过度关注 Agent 的执行路径而非最终结果。Anthropic 建议避免这种过于僵化的方法，因为 Agent 可能以意想不到的创造性方式完成任务。例如，评估不应强制要求 Agent "先调用搜索工具再调用其他工具"。我们不应该给路径打分，而应该关注结果的好坏。在之前的股票报告案例中，评估只关心报告中是否包含正确的公司名称和层级，而不关心 Agent 是如何找到这些数据的。
"You don't want to grade the path that it took. You want to grade whether or not the outcome was good."
虽然存在针对轨迹（Trajectory）的评估，用于检查 Agent 采取的具体步骤，但这属于更复杂的评估范畴。对于大多数基础评估而言，确保输出符合预期结果才是关键。Code Valves 可以非常先进，例如验证工具调用是否真正改变了数据库状态，或者确认 Agent 认为的股票价格是否与 API 返回的真实数据一致。这种基于确定性的检查为后续更复杂的语义评估奠定了可靠的基础，确保 Agent 在逻辑层面没有犯低级错误。
LLM as a Judge：引入语义判断能力
当 Code Valves 无法解决时，就需要评估报告的准确性、完整性以及推理质量。这些属于语义层面的问题，需要具有判断力的模型介入，即 "LLM as a Judge"（大语言模型作为裁判）。一个完整的 LLM 评估系统由三个独立部分组成：Judge Model（执行评判的模型）、Rubric（定义什么是好结果的提示词/评分标准）以及 Data（被评判的示例数据）。Phoenix 框架将这些组件分离，允许用户灵活组合不同的模型和规则。例如，可以用相同的评分标准测试不同模型的输出，或用同一模型尝试不同的评判维度。
"Phoenix keeps those three separate so you can mix and match. You can try the same rules with different models."
Phoenix 提供了多种内置评估指标，无需从零开始编写。这些包括：Correctness（准确性）、Faithfulness（忠实度/是否基于源材料）、Completeness（完整性）、Hallucination（幻觉检测）、Refusal（拒绝回答情况）、PII（个人身份信息泄露）和 Toxicity（毒性内容）。此外，还有专门针对工具使用的评估，检查 Agent 是否选择了正确的工具、传递了正确的参数并合理解析结果。这些内置评估并非魔法，而是经过实战检验的提示词模板，旨在降低用户的使用门槛。通过分离这三个组件，用户可以更精细地控制评估过程，确保评判的客观性和全面性。
裁判模型的选择与正确性评估实践
在选择 Judge Model（评判模型）时，其能力必须高于被评估的 Agent。在演示中，Agent 运行在快速廉价的 Haiku 模型上，而评判者则使用了更强大的 Claude Sonnet 5.5。Anthropic 建议裁判模型应具备比 Agent 更高的智能水平，如使用 Sonnet、Opus 或来自不同提供商的模型（例如用 OpenAI 评判 Claude 的输出），以避免 Same Model Bias（同模型偏差）。Claude 倾向于给其他版本的 Claude 输出更高的分数，而对外部模型的输出更为严苛。此外，为了保持追踪数据的清晰性，需要在评估脚本中抑制评判模型自身的遥测数据（Telemetry），防止其内部运行痕迹污染 Agent 的追踪日志。
"If you've got an OpenAI key, get OpenAI to judge the work of Claude. Because Claude has what is known as same model bias."
以 "Correctness"（正确性）评估为例，只需导入相关模块并调用 evaluate 函数即可。脚本会自动遍历所有 Agent 运行记录，将结果标记为 label（标签）、score（分数）和 explanation（解释），并回传至 Phoenix。虽然 LLM 评判需要消耗更多时间和资源，但它能回答 Code Valves 无法处理的问题：分析是否准确？报告是否完整？建议是否有理有据？ 在 Phoenix 的界面中，用户可以看到各种评估结果的详细注解。这种自动化流程使得大规模、多维度的 Agent 质量监控成为可能，无需人工逐一审查每次运行。
正确性评估的失效：知识截止导致的误判
在AI Agent的性能评估中，直接使用“正确性”（Correctness）作为评判标准往往会导致严重的误判。以Laurie Voss的实验为例，当使用Claude作为裁判来评估16份关于股票价格的报告时，所有报告的“正确性”得分均为零。这是因为Claude的内置知识截止于1月，而Agent讨论的是10月的股价数据。对于裁判而言，它只能依据自身已知的事实进行判断，因此当看到未来日期的数据时，它会直接判定为幻觉（Hallucination），从而给出错误的零分评价。
这种评估方式不仅无效，甚至具有误导性。在16份报告中，有7份的解释明确指出裁判无法验证新鲜数据（fresh data），这证明了评估本身的缺陷。然而，也有部分报告确实存在真实问题，如数字加总错误或日期矛盾。一个全零的得分无法区分“因数据过新导致的误判”与“真正的逻辑错误”，因此这种评估指标对于该场景而言是不合适的。我们需要转向一个裁判能够基于给定上下文回答的问题，即“忠实度”（Faithfulness）。
转向忠实度评估：基于上下文的合理性验证
为了解决正确性评估的局限，Laurie Voss引入了“忠实度”（Faithfulness）作为核心评估指标。与正确性不同，忠实度不关心事实是否绝对真实（因为裁判可能不知道最新数据），而是关注报告内容是否有据可依。它提出的核心问题是：“基于你拥有的这些数据，你的报告是否合理？答案是否植根于我们提供的数据中？”
"Faithfulness is asking a much better question. It's saying given the data that you had, did your report make sense?"
为了实现这一评估，裁判需要完整的上下文。在Phoenix的追踪（Trace）中，每次网络搜索都是一个独立的Span。评估脚本必须同时提供原始搜索结果和Agent的研究笔记，以便裁判能看清数据是如何被发现的。如果只提供研究笔记而不提供原始搜索结果，裁判可能会因为缺乏来源依据而错误地标记数字为捏造。因此，完整的忠实度评估需要三个要素：用户输入（Input）、Agent输出（Output）以及包含搜索结果的上下文（Context）。虽然这比正确性评估更慢，因为它需要裁判阅读每一次搜索记录，但它能提供更准确的反馈。
忠实度评估的实际效果与深度分析
启用忠实度评估后，结果虽然仍有14/16的报告被标记为“不忠实”，但其提供的解释极具价值，能够准确指出Agent的具体错误。例如，在微软（Microsoft）的案例中，裁判指出报告添加了上下文不支持的主张：Azure是第二大云提供商、积压订单提供三年可见性，以及隐含的2027财年目标。裁判明确抱怨这些2027年的目标是捏造的，因为它们不在任何搜索结果中。
另一个典型案例涉及英伟达（Nvidia），裁判发现Agent混淆了两个不同的数据点，这是一个推理错误。与之前全零的“正确性”评分相比，这些详细的解释揭示了Agent在逻辑推理和数据引用上的真实缺陷。这种评估方式真正做到了“做我们想让它做的事”，即识别出Agent是否在缺乏证据的情况下编造信息或进行错误的逻辑推导。尽管评分依然严苛，但这些反馈对于改进Agent的推理能力和数据引用准确性至关重要。
工具调用评估：选择、参数与响应处理
除了内容生成，Agent的工具使用行为也是评估的关键环节。Phoenix提供了针对工具调用的内置评估指标：工具选择（Tool Selection）、工具调用参数（Tool Invocation）和工具响应处理（Tool Response Handling）。这些评估关注Agent是否选择了正确的工具、传递了合理的参数，以及如何处理返回结果。
在实验中，Laurie Voss发现Agent经常做出奇怪的工具选择，例如试图将报告保存到文件。在“工具选择”评估中，13/16的写作轮次尝试保存文件。裁判的解释指出：“用户从未要求将文件保存到磁盘”，但同时也承认，由于提示词（Prompt）中仅说“Write a concise financial report”而未指定输出位置，Agent尝试写入磁盘是一个合理且安全的推测。这揭示了提示词模糊性对评估结果的影响：裁判基于输入判断Agent的行为是“合理的”，尽管用户本意可能并非如此。因此，工具选择评估需要明确列出Agent可用的所有工具列表，因为追踪记录只包含实际调用的工具。这一评估过程耗时约15秒，帮助开发者识别Agent在决策逻辑上的冗余或错误。
评估指标的选择优于调优
在使用 Phoenix 进行 AI Agent 评估时，理解工具调用（Tool Call）的准确性至关重要。很多时候，我们容易误以为工具调用的执行一定是正确的，但实际上评估系统（Eval）可能会站在 Agent 的一边，认为只要 Agent 接收了指令并尽力执行就是正确的。评估结果会直接附加在 Trace（追踪记录）中，例如“可操作性”和“正确性”通常附着在主节点上，而“工具选择”则附着在发出具体调用的 Span 上。用户可以根据任何评估指标过滤 Trace，按分数排序以找出表现最差的运行记录，并直接从失败的评分点击进入导致该问题的具体步骤。
"Choosing the right eval beats tuning it."
这一过程揭示了一个核心教训：选择正确的评估指标比调优更重要。在案例中，使用“正确性”作为评估标准是完全错误的，因为它仅仅告诉我们要修正一堆错误信息；而使用“工具选择”和“忠实度（Faithfulness）”则能提供更有价值的洞察。知道你到底在问什么问题，是获得准确评估结果的核心。因此，不要急于跳到编写自定义评判器的步骤，先通过内置的 Code Eval 解决基础问题。
编写自定义评判器的五大要素
当内置评估无法满足特定需求时，就需要编写自己的 Judge（评判器）。以生成“买入、卖出或持有”建议为例，没有现成的内置评估能检查这种高度具体的业务逻辑。一个有效的评估提示词（Prompt）通常包含五个部分，首先是赋予评判者角色和背景。虽然常见的“你是专家”确实有效，但更关键的是提供具体的上下文。例如，明确指出这是一个财务报告，期望其分析数据并提供真实、可操作的见解。明确的评估标准（Rubric）至关重要，不能仅使用“有帮助”或“准确”这样模糊的词汇，因为评判器无法在特定语境下理解这些抽象概念。
"Specific criteria give you consistent judgments and you get specific criteria by knowing in advance what the data is going to look like because you read it yourself."
评判标准应具体化，例如：报告是否给出了具体的建议？是否列出了明确的风险？是否具有前瞻性而不仅仅是回顾历史？这些标准来源于对错误数据的分析，只有亲自阅读数据并发现如“仅总结无解读”等问题时，才能制定出有效的检查项。这确保了评判的一致性和准确性。
数据标记与示例的使用策略
在构建评估提示词时，清晰的数据边界有助于防止提示注入并减少混淆。建议将每一部分数据包裹在独立的 XML 标签中，因为 Claude 等模型经过大量 XML 标记训练，对此非常擅长。双花括号用于填充 Phoenix 中的模板变量（如 Span 的输入和输出）。这种结构不仅区分了指令、输入和示例，还帮助模型避免将示例误认为是实际数据。
关于是否包含带标签的示例（Labeled Examples），这在评估领域是一个有争议的做法。虽然人类和许多 LLM 在通过示例学习时表现更好，但过度依赖示例可能导致模型过拟合。作者进行了对比测试：在 16 个样本中，使用示例时评判者与人类的一致性为三次运行中的 15/16、15/16 和 15/16；而移除示例后，一致性提升至两次运行中的 16/16 和一次 15/16。研究发现，移除示例反而提高了准确性，因为模型不再机械地模仿示例格式（如强制列出风险），而是更灵活地根据实际内容判断。因此，测试时应对比有无示例的效果，以决定哪种方式更适合当前场景。
评估标准的主观性与严格度差异
在构建 AI Agent 的评估体系时，人类判断与 LLM（大语言模型）裁判之间往往存在显著的标准差异。以一份关于投资报告的评估为例，作者将某报告标记为“可执行”（actionable），但 LLM 裁判却判定其不可行，理由是报告中未包含明确的风险提示。这揭示了一个核心问题：人类评估者往往较为宽松（loosey goosey），而 LLM 裁判则倾向于严格解读规则。作者指出，这种差异导致很难确定究竟是人类判断更优还是裁判更准。当移除“必须包含风险”的示例约束后，LLM 曾判定微软的报告为可执行，这暗示了缺乏具体示例约束时，LLM 对“可执行”的定义会变得模糊且宽松。为了缩小这一差距，评估器需要看到正反两方面的具体案例：一份包含具体数字、估值对比及明确退出策略的“可执行”报告，以及一份虽然事实正确但仅泛泛而谈、缺乏具体建议的“不可执行”报告。通过这种对比，希望 LLM 能在边界案例中保持一致性。
现代评估器的工具调用与输出约束
在编写评估规则（Rubric）时，约束回答格式是第五个关键步骤。传统的做法要求输出特定的字符串（如“actionable”或“not actionable”），但现代评估器更倾向于使用工具调用（tool calls）来定义输出选项。这种方式将选择权直接嵌入到工具定义的选项中，而非依赖提示词中的文本约束，从而提高了评估结果的可靠性和一致性。在 Phoenix 平台中配置分类评估器时，需要指定名称、模型及模板，并通过“外部”方式定义选项：例如，“actionable”对应分数 1，“not actionable”对应分数 0。这种结构化的配置方式使得评估过程更加标准化。作者在实际操作中展示了 JPMorgan 的案例，该报告分析了利率风险和贷款增长，但未给出买卖建议。Phoenix 评估器准确识别出这一缺失，并判定其不可执行，证明了配置正确的评估器能够严格遵循预设的合规性要求。这种自动化且严格的判定机制，是确保 AI Agent 行为符合预期的重要基础。
数据分布的价值与提示词作为代码的重要性
评估结果的数据分布本身具有极高的诊断价值。当评估结果显示“完美”或“全错”时，往往缺乏指导意义；而当数据呈现均匀分布（如 16 份报告中 5 份可执行、11 份不可执行）时，才提供了真正的优化空间。这种分布意味着既有成功运行的案例供分析，也有失败案例可供排查。在深入追踪具体错误时，发现主要问题集中在 AI 拒绝给出明确的“买入、持有或卖出”建议上。例如，Rivian 的报告未提供下一步行动指引，Nvidia 的风险评级模糊，Meta 仅称持仓“稳固”。这些案例共同指向了 AI 在提供具体投资建议时的保守倾向。此外，评估提示词应被视为代码来处理。作者分享了一个关键教训：最初未用 XML 标签包裹示例数据，导致 LLM 混淆了输入数据与示例内容，从而产生大量误判；一旦加入 XML 标签，LLM 便能清晰区分上下文，结果瞬间变为全部可执行。这一变化证明微小的格式调整即可显著影响评估准确性。因此，必须对评估提示词进行版本控制、检查和测试。同时，应避免构建试图一次性检查准确性、语气、完整性等多维度的“上帝评估器”（God Evaluator），因为单一复杂提示词失败时，难以定位具体是哪个维度出了问题。
评估维度的分层与护栏机制
在构建 AI Agent 的评估体系时，首要原则是将单一的复杂任务拆解为多个独立的评估维度。如果试图让模型一次性输出 15 个标签，追踪和调试将变得极其困难。最佳实践是将评估器拆分为尽可能多的维度，例如分别设立“忠实度”、“正确性”和“可执行性”评估器。此外，必须明确区分哪些是护栏（Guardrail），哪些是北极星指标（North Star）。护栏是不可妥协的底线，一旦触发必须阻止发布；而北极星指标是追求的目标，即使未达成也不应阻断流程。例如，如果 Agent 编造了股票价格，这属于严重错误，应该阻止发布（halt shipping）；但如果 Agent 未能建议其他值得关注的股票，这虽然理想但不需要作为发布的门槛（doesn't have to gate shipping）。这种分层机制确保了核心风险可控，同时允许系统在次要目标上保持灵活性。
构建黄金数据集与人类标注的重要性
要验证评估器（Judge）的可靠性，必须将其视为传统机器学习中的分类器进行检验。你的评估器本质上是一个分类器，它根据输入报告预测标签（如“可执行”或“不可执行”），而分类器的准确性需要通过对比其预测与人类专家的真实判断（truth）来衡量。这一过程被称为构建“黄金数据集”（Golden Data Set）。在演示中，操作者通过 Phoenix 工具对追踪记录进行人工标注，标记每份报告是否符合“可执行”标准。黄金数据集是由人类确认答案正确的示例集合，其质量直接决定了后续评估的可靠性。为了对抗标注过程中的疲劳效应（Fatigue），高质量的数据远比数量重要。与其让专家快速浏览 100 条记录并产生惰性，不如精心标注 50 条具有代表性的案例。如果专家在标注时发现自己违反了之前设定的规则（如未包含风险因素），这往往说明评估器比人类更严格、更正确，此时应修正人类的判断以对齐规则。
黄金数据集的构建原则与测试集划分
创建有效的黄金数据集需遵循几条核心规则：首先，任务应该是人类能够通过的（test tasks a human could pass）。如果 Agent 在所有测试中都失败，通常意味着任务定义本身有误而非模型缺陷；其次，每个任务都应有已知的正确答案以证明其可行性；最后，测试必须双向进行。如果仅检查 Agent 在需要时是否搜索网络，可能会意外训练出过度搜索的行为（accidentally train your agent to search the web every single time）。在机器学习领域，有一条铁律：不要在测试集上调整模型（Don't tune on your test set）。因此，标签数据应分为两组：一组用于调整评估器（Dev/Tuning Set），另一组用于最终验证（Test Set）。通常比例为 75% vs 25%。在 Phoenix 中，可以通过 Span ID 将示例按顺序分配至不同拆分组（如每第四个进入测试集），确保结果的可重复性。这种结构化的数据管理方式，使得评估过程既科学又可追溯。
实验运行与结果分析示例
在构建好带有拆分的数据集后，下一步是运行评估实验。该过程将黄金数据集、任务（即评估器）和评分指标结合。在演示中，使用了一个简单的脚本 npm run meta 来运行实验。该实验仅在 Dev（开发/调整）集上执行，以检查评估器标签与人类标注的一致性。结果显示，在 12 份开发报告中，评估器与人工判断完全一致。虽然这一结果令人鼓舞，但演示者强调这仅表明目前没有发现问题（no sign of a problem yet）。在真实生产环境中，需要更大规模的测试集才能得出可靠结论。评估器的验证是一个持续迭代的过程，当在生产环境中遇到难以标注的复杂案例（如可口可乐或微软的报告）时，应将其加入黄金数据集并重新运行实验。通过这种方式，系统能够不断吸收新的边缘案例（Edge Cases），从而提升对 AI Agent 行为判断的准确性和鲁棒性。
提示词微调的陷阱：从XML标签到具体性
在评估AI代理（Agent）时，提示词工程的细微调整可能产生截然不同的结果。以可口可乐（Coca-Cola）为例，当从“无XML标签”改为“有XML标签”并加入示例后，模型表现显著提升。然而，在判断报告是否构成“投资建议”这一模糊地带时，人类评估者与AI裁判（Judge）产生了分歧。原文指出：“The report calls KO ideal for conservative income oriented pol uh portfolios... which sounds like a recommendation.” 人类最终判定这不构成明确推荐，但AI裁判对此犹豫不决。相反，在微软（Microsoft）的案例中，报告给出了“买入”建议且未提及任何风险。人类评估者认为这符合标准，但AI裁判判定其“在风险评估方面薄弱”，尽管它在行动力上勉强达标。这揭示了AI裁判与人类判断之间存在的微妙差异，且这种模糊性往往被保留在评估标准中。
过度具体化的反噬：Rubric修改导致的性能倒退
为了消除歧义，评估者尝试将标准从“报告应包含...”修改为更严格的“只有满足所有四个条件，报告才被视为可操作”。这一看似合理的具体化修改却导致了评估效果的恶化：在开发集（dev set）中，与人类判断的一致性从12/12降至11/12；在测试集（test split）中，苹果公司的案例也因风险部分不够充分而被错误判定。这一过程证明：试图通过增加具体性来优化评估，反而可能使评估器变得不如人类判断准确。这提醒我们，更具体的规则并不总是意味着更好的评估效果，有时甚至会破坏原本有效的判断逻辑。
精确率与召回率的权衡：误报与漏报的成本分析
在评估指标中，精确率（Precision）和召回率（Recall）是源自统计学的关键概念。原文解释道：“precision asks when the judge says not actionable how often is it correct? And recall asks of all the reports that aren't actionable how many did the judge catch?” 在大多数应用场景中，应优先追求高召回率。虽然高召回率会带来“误报”（False Alarms），即花费一两分钟检查实际上没问题的报告，但漏报（Missed Failure）的后果更严重——一份有缺陷的报告可能直接发送给客户。因此，必须在“丢弃部分正确报告”和“接受少量误报”之间做出权衡。这种取舍决定了评估系统在实际业务中的有效性和安全性。
裁判偏见与人类基准：Cohen's Kappa的现实意义
AI裁判存在多种固有偏差，包括位置偏见（Position Bias）、长度偏好以及对自己输出风格的自信偏倚。例如，在Haiku与Sonnet模型的对比中，使用Sonnet作为裁判存在自我偏好风险。然而，不必过度担忧AI裁判的不一致性，因为人类专家之间的一致性本身就很低。原文引用Cohen's Kappa系数指出：“for this kind of task, it's often as low as 02 or.3... they agree with each other not very much more often than just random chance.” 这意味着，评估的目标不是让AI裁判100%符合个人判断，而是让它比另一位人类专家表现更好。此外，失败的案例必须显得“公平且明显”，否则评估标准本身可能存在问题。
基准测试的局限性：CoreBench案例与持续迭代
著名的CoreBench基准测试曾显示Claude Opus 4.5得分仅为42%，但Anthropic研究发现这是因为测试期望六位精度，而模型提供了四位或两位精度的正确答案。经过人工修正模糊的任务描述后，得分飙升至95%。这一案例揭示了基准测试常被手动微调以适配模型的趋势。原文强调：“your evals are going to end up with the same problem... you need to be constantly re-evaluating your test set.” 因此，评估体系必须处于持续迭代状态。进入第七步“实验”阶段后，信任的评估器将用于实际改进代理并验证修复效果的有效性。
评估的核心：从“凭感觉”到受控实验
在优化 AI Agent（智能体）时，最大的陷阱在于无法量化提示词（Prompt）变更的效果。许多开发者在发现报告不可操作后，会修改 Prompt 并仅通过几个示例进行肉眼检查（eyeball it）。这种做法本质上是“凭感觉”（vibes），因为未经测量的提示词变更只是主观臆断。要确认改进是否有效且未破坏原有功能，必须进行受控比较（controlled comparison）。这意味着在相同的输入和评估标准下，对比变更前后的结果。
"A prompt change that you haven't measured is just a vibe."
在 Phoenix 工具中，实现这一过程的关键步骤是将筛选出的失败评估案例（例如那些产生不可操作报告的样本）添加到一个数据集中。随后，基于该特定数据集创建实验任务。仅针对这些失败的评估案例运行测试，而不是每次都对整个庞大的测试集进行全量扫描。这种方法能节省数千次不必要的测试调用，同时确保我们专注于修复已发现的问题。
基于评估结果的针对性 Prompt 优化
实验脚本由三个核心部分组成：数据集、任务（Task）和评估器（Evaluators）。任务是执行 Agent 的核心函数，它接收数据集中的每个示例并运行整个 Agent（或特定子任务），返回报告和研究结果。评估器则通过包装函数提取所需字段，例如 Faithfulness（忠实度）评估器将研究结果作为上下文。
Prompt 的改进并非凭空猜测，而是直接映射到之前的评估发现。具体的优化策略包括： * 行动力（Actionability）：如果评估指出“没有建议”，则要求 Agent 提供明确的推荐意见。 * 风险识别（Risks）：如果指出“提及风险但无证据”，则要求提供支持数据。 * 忠实度（Faithfulness）：如果发现“捏造数字”，则强制规定仅使用研究中出现的数字。 * 输出格式（Output Format）：如果追踪发现 Agent 试图保存文件，则指示其直接回复报告而非执行其他操作。
这种基于数据的迭代方式确保了每一次 Prompt 调整都有据可依，旨在解决具体的评估失败点。
实验规模与确定性考量
关于需要多少个示例进行评估，答案取决于应用场景。10-20 个示例足以在开发阶段提供大致方向，非常有用；但进入生产环境时，需要数百个示例以保证准确性。为了将准确率的误差范围缩小一半，需要将样本量四倍增加。例如，从 25 个示例增加到 100 个会有显著帮助，但达到 400 个时成本可能过高。因此，样本量越大越好，且应尽可能包含生产环境中出现的失败案例。
由于 Agent 通常是非确定性的（non-deterministic），单次运行可能产生误导。因此，Laurie Voss 建议对同一实验重复运行多次（如三次）。在分析结果时，有两种关键指标： 1. Pass@K：在 K 次尝试中，至少成功一次。适用于容错率较高的场景（如编程助手）。 2. Pass-to-the-K：在 K 次尝试中，每次都成功。适用于高可靠性要求的场景（如支持机器人或财务分析师）。
"The more tries you give it, the more likely pass at K is to succeed... Pass-to-the-K will go down."
对于需要高可靠性的 Agent，必须追求 Pass-to-the-K 指标，即确保每次运行都通过。
优化优先级与实验结果分析
在改进 Agent 时，应遵循特定的操作顺序以最大化效率： 1. 数据质量（Data Quality）：这是首要且最关键的因素。如果底层数据难以阅读或解释，任何 Prompt 调整都无效。 2. Prompt（提示词）：在数据质量达标后，通过调整评估标准和 Agent 行为来优化。 3. 模型选择（Model Choice）：虽然杠杆效应大，但切换到大模型会显著增加成本并改变多方面行为。 4. 超参数（Hyperparameters）：如温度值等，效用最低。现代模型甚至不再允许调整某些超参数。
在 Laurie Voss 的实验中，随着 Prompt 和评估标准的改进，结果发生了显著变化： * Actionability（行动力）从 15/16 提升至完美状态。 * Faithfulness（忠实度）从 2/16 仅提升至 3/48，表现依然不佳。
"All of the five reports that passed previously... still passed."
尽管忠实度提升有限，但关键验证点在于没有破坏原有通过项。之前通过的 5 个报告在改进后依然全部通过，证明优化未引入回归错误。然而，忠实度的低分表明当前的 Prompt 改进在该维度上仍需进一步优化。
提示词修正与幻觉问题的局限性
在针对AI Agent的评估过程中，即使我们在提示词中明确添加了“仅使用研究中出现的数字”这一约束条件，虽然成功修正了单一指标上的测量偏差，但并未解决Agent编造数据的核心问题。这表明提示词的局部优化无法根除模型的根本性幻觉。评估不仅关注Agent是否做出了良好的判断，更需直面其在部分情况下捏造数据的行为。由于模型输出的非确定性（nondeterministic），每次运行的建议可能截然不同，但在时间有限的情况下，深入分析每一次运行并非当务之急。当前的重点在于识别出Agent仍在制造虚假数据这一尚未修复的缺陷。这种对失败模式的诚实面对，是后续迭代的基础。我们需要明确区分已解决的问题（如判断逻辑）和待解决的顽疾（如数据真实性），从而为下一步的模型升级或提示词重构提供精准方向。
能力评估与回归测试的双轨机制
一个优秀的评估体系包含两种关键类型：能力评估（Capability Eval）与回归测试（Regression Eval）。能力评估旨在衡量Agent目前尚不具备的能力，它像一座“小山丘”，为我们提供可衡量的进步阶梯。当Agent能够100%稳定通过某项测试时，不应将其丢弃，而应转化为回归评估。回归评估可集成至持续集成（CI）流程中，一旦通过率不再保持100%，即视为发布失败。这种机制确保了系统不会在迭代中退化。为了“攀登”能力评估这座山丘，团队可以选择优化提示词或升级模型。例如，通过传入新模型（如Haiku 5.5）并运行实验，我们可以验证在没有评估的情况下切换模型是不可行的。只有通过严格的对比测试，才能确认新配置是否真正提升了性能。这种从“我认为它有效”到“我可以证明它有效”的转变，是工程化落地的关键。
模型升级的代价与一致性陷阱
在对比Haiku 4.5与5.5的实验结果中，数据揭示了性能提升背后的复杂代价。结果显示忠实度（Faithfulness）提升了超过三倍，但Agent仍在频繁编造数据。虽然一致性调用（Consistent Calls）有所改善，即Agent在不同运行中给出的建议不再随意在“买入”和“卖出”间摇摆，但这种一致性是通过变得极度保守来实现的。具体而言，Haiku 5.5在41次调用中选择了“持有（Hold）”，这种机械的一致性并非真正的智能判断，而是模型策略的僵化。此外，新模型的成本增加了四倍。在 production 环境中，团队必须权衡这种一致性提升与高昂成本及保守策略之间的得失。评估的价值不在于最终的分数，而在于迭代循环本身：运行评估、阅读失败解释、发现模式（如过度保守）、调整提示词或工具，再重新运行。这一闭环过程让团队能够量化改进效果。
评估驱动开发与CI集成实战
越来越多的快速迭代AI团队采用“评估驱动开发（Eval-driven Development）”，即在功能编写前先定义评估标准。例如，为确保支持Agent在退款前核实客户身份，可预先编写检查该行为的评估用例。通过VEST（JavaScript测试运行器）与Phoenix的集成，可以将这些评估嵌入CI流程。在agent.eval.ts文件中，每个回归测试集（如Coca-Cola、Apple vs Microsoft等）都对应一个测试块，运行Agent后记录报告并应用之前的评估逻辑（如ticker检查、行动力判断）。构建门禁基于护栏指标（Guardrails）和北极星指标（Northstars）：例如，必须提及正确股票代码是护栏，而平均行动力评分需保持在0.8以上。当构建失败时（如Rivian的报告缺乏行动力，导致平均分降至0.75），系统不仅显示红色错误，还提供详细的失败解释。这种机制允许非技术人员（如产品经理、支持团队）通过描述“什么是好答案”来编写评估，无需掌握TypeScript代码，从而实现了业务逻辑与技术实现的解耦与融合。
自动化测试生成与成本控制策略
在构建 AI Agent 的评估体系时，利用编码代理（coding agent）自动生成测试用例是一种高效策略。你可以将现有的代码库和示例提供给编码代理，指示其针对你的特定代码base生成相应的评估脚本。然而，切勿在每次代码提交时都运行完整的 Agent 测试流程。这种做法不仅耗时极长，还会产生高昂的计算成本。相反，应当将生成的代码库作为基础资源，让代理理解上下文并自行适配你的项目结构。这种自动化方式能够显著降低手动编写评估脚本的负担，同时确保测试逻辑与代码库保持一致。
生产环境中的持续监控机制
评估工作不应止步于开发阶段，上线后的持续评估同样至关重要。建议在真实流量中抽取样本运行评估脚本，并设置警报机制以监控分数下降趋势。需要明确的是，不应针对单次失败发出警报，因为个别错误可能只是噪声；但若观察到失败的持续趋势，则表明系统存在潜在问题。这种基于生产数据的监控能够弥补开发阶段测试的不足，帮助团队及时发现并修复模型在真实场景中的退化问题。通过这种方式，评估体系从静态检查转变为动态的健康监测工具。
全生命周期闭环与渐进式落地路径
完整的评估流程涵盖追踪、读取、评估、检查、改进及 CI 锁定等环节，形成从开发到生产的全生命周期闭环。但对于初学者而言，无需一次性掌握所有复杂步骤。从小处着手是更可行的策略：首先对 Agent 进行仪器化（instrumentation），读取少量追踪数据。研究表明，阅读 12 条追踪记录所获得的信息量远超仅观察输出结果。通过这种方式，团队可以逐步构建评估能力。
“You shouldn't run your whole agent on every single commit because it's going to take a really long time and cost you a whole bunch of money.”
开源生态与社区协作价值
Phoenix 项目本身是完全开源的，文档和代码库均向公众开放。这种开放性鼓励用户直接参与代码探索，甚至指出其中可能存在的错误或不完善之处。
“Phoenix itself is open source. So you can mess with the code and tell us that we got stuff wrong in there.”这种社区驱动的模式不仅促进了工具的迭代优化，也为开发者提供了深入理解评估原理的机会。通过参与开源社区，用户不仅能获得技术支持，还能贡献自己的见解，共同推动 AI Agent 评估标准的发展。