monday Service + LangSmith：从 Day 1 开始构建代码优先的评测体系

标题：monday Service + LangSmith：从 Day 1 开始构建代码优先的评测策略

摘要：了解 monday Service 如何为其面向客户的服务 Agent 构建一套由评测驱动的开发框架。

内容（第 1/2 部分）： [本文为来自我们朋友 Monday.com 的客座文章，介绍他们如何为面向客户的 AI 服务 Agent 制定评测策略，由 Gal Ben Arieh（Group Tech Lead）主导。感谢你们的分享！]

很多团队把评测当作最后一公里的验收，但我们把它设为 Day 0 的硬性要求。

monday Service 是一个 AI Native 的企业服务管理（ESM）平台，旨在自动化并解决各类服务部门的咨询请求。在构建我们新的 AI service workforce（由可定制、基于角色的 AI Agent 组成，用来分担人工客服的工单压力）时，我们从一开始就把评测嵌入开发周期，而不是等到 Alpha 用户来暴露问题。

这篇文章将介绍我们如何搭建一套 evals-driven development framework（评测驱动开发框架），在问题被用户发现之前就提前识别 AI 质量风险。

我们达成的结果：

速度： 评测反馈闭环提升 8.7 倍（从 162 秒降到 18 秒）。
覆盖： 原本要数小时的数百样本测试，缩短到分钟级完成。
Agent 可观测性： 基于 Multi-Turn Evaluators，对生产 Trace 做实时端到端质量监控。
Evals as code： 评测逻辑以可版本管理的生产代码方式维护，并采用 GitOps 风格 CI/CD 部署。

AI service workforce 是一个可定制、基于 LangGraph 的 ReAct Agent，面向企业服务管理场景中的各类请求自动化处理与闭环解决。

无论是 IT、HR 还是法务 等领域，monday Service 的客户都可以通过自己的 KB 文章和工具进行配置，让 Agent 在任意服务部门中推动执行。

不过，ReAct Agent 的强大恰恰来自其高度自主性，这也带来了独特挑战：推理链上的每一步都依赖前一步，因此 prompt 或工具调用结果中的一个微小偏差，都可能级联放大，最终导致显著不同甚至错误的结果。

评测体系的两大支柱

在研究 Agent 评测最佳实践后，我们很快意识到：必须采用双层评测策略：

离线评测（Offline Evaluations）—“安全网”： 类似单元测试层，用精选的“golden datasets”运行 Agent。既测试核心逻辑（如 groundedness、检索准确性、tool-calling），也测试特定边界场景（如 KB 文章冲突或优先级处理）。这一层可以避免一次简单的 prompt 调整无意中破坏 Agent 处理其他任务的能力。

在线评测（Online Evaluations）—“监测器”（持续质量）： 这一层从端到端业务视角持续采集、分析并提升 Agent performance。借助在线评测流水线，我们持续跟踪并优化业务信号（例如 Automated Resolution 和 Containment rate），确保 Agent 在真实环境（in the wild）中的表现可被实时保障。

支柱 A：离线评测 — “安全网”

设计我们的评测覆盖策略

在写第一条评测之前，我们先回答一个根本问题：到底该评什么？挑战并不在于设计完美覆盖策略，而是先选出一个可落地的起点。

我们从内部 IT 帮助台中挑选并脱敏了约 30 条真实已解决工单，构建了一个小型数据集，覆盖常见请求类别，例如：

访问与身份（如 IDP、SSO、软件访问权限）
VPN 与连通性问题
设备 / OS 支持（更新、性能、硬件问题）

在第一版测试集中，我们的检查项刻意保持简单：

Deterministic 的“冒烟”检查：
- 运行健康：Agent 运行过程中无崩溃/超时，请求端到端成功。
- 输出形态：响应符合预期 schema/格式（即使暂不判断内容质量）。
- 状态与持久化：thread/session 正常创建，且会话正确落库到应用数据库。
- 基础工具健全性检查：必要工具都被正确调用、输入合理，且执行无报错。
LLM-as-judge：我们先采用 OpenEvals (Correctness) 的现成评估器，将 Agent 响应与同一已解决工单数据集中的参考输出做对比。

在这个基线建立后，我们又扩展了更小、针对具体用例的数据集，去探测特定行为——包括 session memory、KB 检索、grounding、冲突处理和 guardrails。随着这些行为变得更细致，我们也从单一 correctness 分数升级为更完整的一组检查：

KB grounding / 引用：“每一个事实性陈述是否都可追溯到给定 KB 内容？”（通过 LangSmith 预置的 hallucination / answer relevance 检查实现）。
冲突处理：“当策略随地区/时间变化时，Agent 是否会先澄清，或选择最新适用策略？”（或使用预置 correctness 检查）。
Guardrails：“在需要拒答时是否拒答？” / “是否避免泄露内部工具名或 prompt 内容？”（或使用预置 toxicity / conciseness 检查）。
**KB 使用时机：**应在合理时点拉取 KB（不能太早，也不能答案都形成后才取），通过 AgentEvals' Trajectory LLM-as-judge 评估。
**Guardrail 执行顺序：**安全/策略 guardrails 应在正确阶段执行（最终答案生成前）。这同样是一个 trajectory 检查项。

框架：langsmith/vitest

为了实现这一层，我们使用了 LangSmith Vitest integration。这种方式既能发挥成熟测试框架（Vitest）的能力，又能与 LangSmith 生态无缝衔接。

在这套配置下，每次 CI 运行都会自动记录为 LangSmith 平台中的独立实验，而每个测试套件都对应一个dataset。这让我们可以深入到具体 run，精确定位 Agent 与 ground truth 偏离的位置，从而在代码变更进入生产之前就验证其影响。

深刻教训：不要在 DevEx 上妥协

最初，我们的离线评测是串行运行的。标准开发循环——eval（失败）→ 修复 → re-eval（通过）——很快变成主要瓶颈。

我们发现，反馈回路一旦过慢，要么牺牲测试深度，要么牺牲开发速度。为了在保持高频交付的同时避免回归，评测流程必须足够快，才能支撑低摩擦迭代。

解决方案：使用 Vitest + ls.describe.concurrent 做并行化

通过优化 Vitest 与 LangSmith 的集成，我们把负载分发到本地 worker 与远程 API 调用上，获得了大幅提速。核心是混合策略：通过测试文件并行最大化 CPU 使用率，同时通过LLM 评测并发执行处理 I/O 延迟瓶颈。

Parallelism（CPU-Bound）： 我们使用 Vitest 的 pool:'forks' 把任务分配到多核。通过将每个 Dataset Shard 分配到独立测试文件，多个 worker 进程可并行运行且不互抢 CPU。这样即使数据集规模增长，也能通过把 shard 分发到可用核心来保持高处理速度。
Concurrency（I/O-Bound）： 在每个测试文件内部，我们使用 ls.describe.concurrent 最大化吞吐。由于 LLM evaluations 延迟较高，并发可以通过一次发起数十个评测来重叠等待时间，避免 runner 空转。
Eval Function： 这是对每个样本执行评测的核心逻辑。我们在单次执行中完成双层校验：
- Deterministic Baseline： 强断言保证 Agent 遵循响应 schema并维持状态持久化（通过 checkpointer/storage）。
- LLM-as-a-Judge： 基于“Golden Dataset”进行语义评分。我们使用 OpenEvals 和 AgentEvals 等开源库，对 correctness、groundedness 等维度打分。

结果： 对数百个样本的综合反馈可在几分钟内完成！

使用 MacBook Pro 16-inch（2023 年 11 月，Apple M3 Pro，36 GB RAM，macOS Tahoe 26.2）对 20 条脱敏 IT 工单进行基准测试，结果如下：

Execution Mode

Total Duration

Speedup vs Sequential

Parallel + Concurrent

18.60s

8.7x faster

Concurrent Only

39.30s

4.1x faster

Sequential

162.35s

Baseline

支柱 B：在线评估 ——“监视器”

在线多轮评估

离线评估通常用于在可控沙箱中捕捉回归问题，但它本质上只是合成或脱敏样本的静态快照。要真正覆盖生产环境的不可预测性，我们需要在线评估——基于真实生产 trace 的实时评估。

由于我们的 Agent 要处理复杂的多轮对话，成功往往不取决于某一次回复，而取决于整段对话的走向。这就要求评估策略能够衡量 Agent 是否在多个轮次中持续引导用户走向问题解决。

我们最终找到了非常契合的方案：LangSmith 的 Multi-Turn Evaluator。它通过 LLM-as-a-judge 对端到端会话线程打分。我们不再孤立地评估单次 run，而是可以用自定义 prompt 对整段对话轨迹进行评分，衡量 用户满意度、语气、目标达成 等高层结果。

最令人惊喜的是上线速度之快。LangSmith 平台让多轮评估配置变得非常直观：我们可以设置自定义不活跃时间窗口，精确判定一个 session 在何时应被视为“完成”并进入评估；同时也能方便地配置采样率，在数据量与 LLM 成本之间取得平衡。

评估即代码（EaC）

当我们从原型走向生产后，希望像管理其他生产代码一样管理这些“裁判”：版本控制、同行评审、自动化 CI/CD 流水线。

为此，我们把单一事实来源迁移到了代码仓库中，将“裁判”定义为结构化的 TypeScript 对象。

code

// conversation-analysis.ts
export const conversationAnalysis = new MultiSignalEvaluationPrompt({
  name: 'conversation-analysis',
  variables: ['all_messages'],
  modelConfig: { model: 'gpt-5.2-pro', reasoning: { effort: 'high' } },
  extractionFields: [
    new ExtractionField({ key: 'human_handoff', type: 'boolean', includeComment: true }),
    new ExtractionField({ key: 'meaningful_interaction', type: 'boolean', includeComment: true }),
    new ExtractionField({ key: 'is_automated_resolution', type: 'boolean', includeComment: true }),
    // ... additional atomic signals
  ],
  systemPrompt: `You are an expert conversation analyst...`,
  humanPrompt: `Analyze the following conversation:
<conversation>
{{{all_messages}}}
</conversation>`,
});

把裁判逻辑代码化后，我们立刻获得了两项关键能力：

我们可以在主工作区中直接借助 Cursor、Claude Code 等 AI IDE 优化复杂 prompt。
在裁判接触生产流量之前，就能很自然地先为其编写离线评估，确保准确性。

这次迁移之所以相对顺利，很大程度上得益于 LangChain 的 IDE 集成。我们使用 Documentation MCP 将库文档上下文拉进编辑器，用 LangSmith MCP 直接拉取 runs 和 feedback。LangChain Chat 也在澄清具体实现细节时提供了不少帮助。

部署

为了形成闭环，我们构建了自定义 CLI 命令 yarn eval deploy，并将其接入 CI/CD 流水线。这保证了仓库始终是评估基础设施的唯一事实来源（Source of Truth）。

当 PR 合并后，我们的同步引擎会执行一个三步协调循环（Reconciliation Loop）：

同步 Prompts：将 TypeScript 定义推送到 LangSmith Prompt Registry。
协调规则：对比本地评估（rules）定义与生产环境中激活的定义，并自动更新或创建。
清理：识别并删除 LS 平台中的“僵尸”评估/prompt（即代码库中已不存在的对象）。

技术栈的演进：展望未来

随着评估逻辑逐渐成熟，我们希望用与生产代码同等严格的方式来管理它——版本控制、PR 评审、CI/CD。LangSmith API-first 的架构让这一点实现起来非常自然：我们自定义的部署流水线可以把 TypeScript 定义直接同步到 LangSmith 平台。

这让我们同时拥有两方面优势：既能使用 LangSmith 强大的评估基础设施，又能保持团队现有的 GitOps 工作流。我们预计，随着生态继续成熟，这种模式会越来越普遍，甚至可能演进为类似 Terraform module 的标准化“Evaluations as Infrastructure”工具。