摘要
1) 一句话总结
monday Service 借助 LangSmith 构建了代码优先的双层（离线与在线）AI 评估框架，通过测试并行化与 GitOps 部署流程，实现了 AI 智能体质量的高效监控与快速迭代。
2) 关键要点
- 双层评估架构：构建了包含“离线评估（安全网）”与“在线评估（监控器）”的双层体系，将评估作为开发初期的首要需求而非后期的补充检查。
- 性能显著提升：通过结合 Vitest 的并行化（分配 CPU 核心）与并发（处理 I/O 延迟）技术，离线评估速度提升了 8.7 倍（耗时从 162 秒缩短至 18 秒）。
- 离线评估指标：基于约 30 个脱敏真实工单组成的“黄金数据集”，进行确定性冒烟测试（运行健康度、格式、状态持久化、工具调用）以及 LLM 裁判评分（正确性、知识库依据、冲突处理、安全护栏）。
- 在线多轮对话监控：利用 LangSmith 的多轮对话评估器（Multi-Turn Evaluator），在生产环境中对完整的端到端对话轨迹进行实时评分，衡量用户满意度、语气和解决率。
- 评估即代码（Evals as Code）：将评估逻辑（“裁判”）作为结构化的 TypeScript 对象纳入代码库，实现版本控制、同行评审，并支持使用 AI IDE（如 Cursor）进行本地优化。
- 自动化 CI/CD 部署：开发了自定义 CLI 命令
yarn eval deploy，在合并 PR 时自动执行三步协调循环：同步提示词、协调规则定义、清理 LangSmith 平台上的废弃项。 - CI 实验可视化：通过 LangSmith Vitest 集成，每次 CI 运行都会自动作为独立实验记录在 LangSmith 中，便于精准定位智能体偏离标准答案的环节。
3) 风险与挑战
- ReAct 智能体的连锁反应风险：由于智能体推理链的每一步都依赖于上一步，提示词或工具调用结果的微小偏差极易引发连锁反应，导致最终结果出现严重错误。
- 评估反馈延迟风险：在采用串行运行离线评估时，缓慢的反馈循环会成为开发瓶颈，不可避免地损害测试深度与功能交付速度（该风险后续通过并行/并发架构得以解决）。
正文
许多团队将评估（Evaluation）视为最后一公里的检查，但我们将其作为“第0天”的首要需求。
monday Service 是一个 AI 原生的企业服务管理（ESM）平台，旨在自动化并解决跨服务部门的咨询问题。在构建我们全新的 AI 服务团队（由可定制的、基于角色的 AI 智能体组成，用于减轻人类客服的工单压力）时，我们从一开始就将评估嵌入到开发周期中，而不是等待 Alpha 测试用户去发现漏洞。
本文将展示我们如何构建一个以评估为驱动的开发框架，从而在用户发现之前捕获 AI 的质量问题。
我们取得的成果：
- 速度：评估反馈循环加快了 8.7 倍（从 162 秒缩短至 18 秒）。
- 覆盖率：在几分钟（而非数小时）内完成对数百个示例的全面测试。
- 智能体可观测性：使用多轮对话评估器（Multi-Turn Evaluators）对生产环境的追踪进行实时的端到端质量监控。
- 评估即代码（Evals as code）：将评估逻辑作为受版本控制的生产代码进行管理，并采用类似 GitOps 的 CI/CD 部署方式。
我们的 AI 服务团队是一个基于 LangGraph 的、可定制的 ReAct 智能体，旨在自动化解决任何企业服务管理用例中的咨询。无论是应用于 IT、人力资源还是法务领域，monday Service 的客户都可以利用自己的知识库（KB）文章和工具，定制智能体以驱动任何服务部门的执行。
然而，正是赋予 ReAct 智能体强大能力的自主性，也带来了一个独特的挑战：由于推理链的每一步都依赖于上一步，提示词或工具调用结果的微小偏差，都可能引发连锁反应，导致截然不同且可能错误的最终结果。
评估的两大支柱
通过对智能体评估最佳实践的研究，我们很快意识到必须采用双层架构的方法：
- 离线评估——“安全网”：类似于单元测试层，让智能体在精心策划的“黄金数据集”上运行。它不仅测试核心逻辑（例如：事实依据、检索准确性、工具调用），还测试特定的边缘情况（例如：知识库文章冲突或优先级解析）。这一层有助于确保对提示词的简单微调不会意外破坏智能体处理其他任务的能力。
- 在线评估——“监控器”（持续质量）：这一层负责从端到端的业务视角，持续收集、分析和提升智能体的表现。通过利用在线评估管道，我们追踪并优化业务信号（如自动解决率和遏制率），实时确保智能体在真实环境中的表现。
支柱 A：离线评估——“安全网”
在编写任何评估之前，我们需要回答一个根本问题：我们到底应该评估什么？挑战不在于设计一个完美的覆盖策略，而仅仅是选择一个实用的起点。
我们构建了一个包含约 30 个真实（经过脱敏处理）已解决 IT 工单的小型数据集，这些工单选自我们内部的 IT 帮助台，涵盖了常见的请求类别，例如：
- 访问与身份（如 IDP、SSO、软件访问权限）
- VPN 与网络连接问题
- 设备/操作系统支持（更新、性能、硬件问题）
在第一个测试套件中，我们的检查项被有意设计得很简单：
- 确定性“冒烟”测试：
- 运行健康度：智能体运行无崩溃/超时，请求端到端成功。
- 输出格式：响应符合预期的模式/格式（甚至在评判内容之前）。
- 状态与持久化：成功创建线程/会话，且对话被正确持久化到我们的应用数据库中。
- 基础工具健全性检查：所有必要的工具都被正确调用并传入了合适的参数，且执行完成无错误。
- LLM 作为裁判（LLM-as-judge）：我们从 OpenEvals 中引入了一个现成的评估器（正确性），将智能体的响应与同一已解决工单数据集中的参考输出进行对比。
有了这个基准之后，我们扩展了更小、针对特定用例的数据集，以探测特定的行为——包括会话记忆、知识库检索、事实依据与冲突解决，以及安全护栏。随着这些行为变得更加细微，我们从单一的正确性评分转向了一套更全面的检查：
- 知识库依据/引用：“每一个事实声明是否都能追溯到提供的知识库内容？”（我们使用 LangSmith 预置的幻觉/答案相关性检查来验证）。
- 冲突处理：“当政策因地区/时间而异时，智能体是否要求澄清或选择了最新适用的政策？”（或使用预置的正确性检查）。
- 安全护栏：“智能体是否在需要时拒绝了请求？”/“它是否避免了泄露内部工具名称或提示词内容？”（或使用预置的毒性/简洁性检查）。
- 知识库使用时机：知识库应该在合理的时间点被获取（不能太早，也不能在答案已经形成之后），这使用了 AgentEvals 的轨迹 LLM 裁判。
- 护栏顺序：安全/政策护栏应该在正确的阶段运行（在生成最终答案之前）。这是另一个轨迹检查项。
为了实现这一层，我们利用了 LangSmith Vitest 集成。这种方法既提供了久经考验的测试框架（Vitest）的强大功能，又与 LangSmith 生态系统无缝集成。
通过这种设置，每一次 CI 运行都会自动作为独立的实验记录在 LangSmith 平台中，每个测试套件都作为一个数据集。这为我们提供了极高的可见性，可以深入查看特定的运行记录，准确找出智能体偏离标准答案的地方，从而在任何代码更改进入生产环境之前轻松验证其影响。
起初，我们的离线评估是串行运行的。标准的开发循环——评估（失败）→ 修复 → 重新评估（通过）——成为了一个主要的瓶颈。我们发现，缓慢的反馈循环不可避免地会损害我们的测试深度或开发速度。为了在不出现回归问题的情况下保持高速交付，我们意识到评估过程必须足够快，以确保无摩擦的迭代循环。
通过优化 Vitest 和 LangSmith 的集成，我们采用在本地工作进程和远程 API 调用之间分配负载的方式，实现了速度的大幅提升。关键在于一种混合方法：并行化测试文件以最大化 CPU 使用率，同时并发运行 LLM 评估以处理 I/O 密集型的延迟。
- 并行化（CPU 密集型）：我们利用 Vitest 的
pool:'forks'将工作负载分配到多个核心。通过将每个数据集分片分配给单独的测试文件，我们允许多个工作进程并行运行而不会争夺 CPU。这种设置确保了即使数据集不断增长，我们也能通过将分片分布在可用核心上快速处理它们。 - 并发（I/O 密集型）：在每个测试文件中，我们使用
ls.describe.concurrent来最大化吞吐量。由于 LLM 评估具有高延迟，并发允许我们通过同时触发数十个评估来掩盖延迟，确保运行器永远不会闲置。 - 评估函数：这是负责评估每个示例的核心逻辑。我们使用它在单次传递中运行双层验证：
- 确定性基准：硬性断言，确保智能体遵守响应模式并保持状态持久化（通过检查点/存储）。
- LLM 作为裁判：对照“黄金数据集”进行语义评分。我们利用 OpenEvals 和 AgentEvals 等开源库对正确性和事实依据等维度进行评分。
结果：在几分钟内完成对数百个示例的全面反馈！
针对 20 个脱敏 IT 工单的基准测试结果（测试环境：MacBook Pro 16 英寸，2023 年 11 月，Apple M3 Pro，36 GB RAM，macOS Tahoe 26.2）：
| 执行模式 | 总耗时 | 相比串行的提速 |
|---|---|---|
| 并行 + 并发 | 18.60秒 | 快 8.7 倍 |
| 仅并发 | 39.30秒 | 快 4.1 倍 |
| 串行 | 162.35秒 | 基准 |
支柱 B：在线评估——“监控器”
虽然离线评估通常用于在受控的沙盒中捕获回归问题，但它们本质上是合成或脱敏示例的静态快照。为了捕捉生产环境的不可预测性，我们需要在线评估——在真实的生产追踪上实时运行。
由于我们的智能体处理复杂的多轮对话，成功往往不是由单一响应定义的，而是由整个对话轨迹决定的。这就需要一种评估策略，能够考量智能体如何在多个轮次中引导用户走向问题解决。
我们在 LangSmith 的**多轮对话评估器（Multi-Turn Evaluator）**中找到了完美的契合点，它利用 LLM 作为裁判对端到端的线程进行评分。现在，我们不再孤立地评估单个运行，而是可以使用自定义提示词对整个对话轨迹进行评分——衡量用户满意度、语气和目标解决率等高层次结果。
最令人印象深刻的是我们上线的速度。LangSmith 平台让多轮对话的设置变得极其直观：我们可以定义一个自定义的非活动窗口，以准确确定会话何时应被视为“完成”并准备好进行评估，并且可以轻松应用采样率来平衡数据量与 LLM 成本。
随着我们从原型走向生产，我们希望用管理任何其他生产代码的相同标准来管理我们的“裁判”：版本控制、同行评审和自动化的 CI/CD 管道。为了实现这一点，我们将事实来源（Source of Truth）移入了我们的代码库，将我们的“裁判”定义为结构化的 TypeScript 对象。
将裁判移入代码解锁了两个关键能力：
- 我们可以利用 Cursor 和 Claude Code 等 AI IDE，直接在我们的主要工作区中优化复杂的提示词。
- 为我们的裁判编写离线评估变得顺理成章，这确保了它们在接触生产流量之前具备准确性。
得益于 LangChain 的 IDE 集成，迁移过程相对简单。我们使用 Documentation MCP 将库上下文拉入编辑器，并使用 LangSmith MCP 直接获取运行记录和反馈。LangChain Chat 也是澄清特定实现细节的有用参考。
为了闭环，我们构建了一个自定义的 CLI 命令 yarn eval deploy，它在我们的 CI/CD 管道中运行。这确保了我们的代码库始终是评估基础设施的绝对事实来源。
当我们合并一个 PR 时，我们的同步引擎会执行一个三步协调循环（Reconciliation Loop）：
- 同步提示词（Sync Prompts）：将 TypeScript 定义推送到 LangSmith 提示词注册表。
- 协调规则（Reconcile Rules）：将本地评估（规则）定义与活跃的生产定义进行比较，自动更新或创建它们。
- 修剪（Prune）：如果某些评估/提示词在代码库中已不存在，则识别并从 LangSmith 平台中删除这些“僵尸”项。
技术栈的演进：展望未来
随着我们评估逻辑的成熟，我们希望以与生产代码相同的严谨性来管理它——版本控制、PR 审查、CI/CD。LangSmith 的 API 优先架构使这种实现变得自然，允许我们的自定义部署管道将 TypeScript 定义直接同步到 LangSmith 平台。
这为我们带来了两全其美的结果：LangSmith 强大的评估基础设施与我们团队的 GitOps 工作流相结合。我们预计，随着生态系统的成熟，这种模式将变得更加普遍，并有可能演变成类似于 Terraform 模块的标准化“评估即基础设施（Evaluations as Infrastructure）”工具。