智能体评估准备清单（上）
这份清单是《Agent Observability Powers Agent Evaluation》的实用配套指南。那篇文章解释了为什么智能体评估不同于传统软件测试，介绍了核心可观测性原语（运行、追踪、线程），并说明了它们如何映射到不同的评估层级。如果你是智能体评估新手，建议先阅读那篇文章。
本文专注于怎么做，提供一份分步清单，指导你如何构建、运行并交付智能体评估。
从能给你带来信号的最简单评估开始。 即使你的架构仍在变动，几个端到端的评估（测试你的智能体是否能完成其核心任务）也能立即给你一个基准线。只有当你有证据表明更简单的方法会遗漏真实失败时，才增加复杂度。
搭建评估系统前
☑️ 在构建任何评估基础设施前，先手动审查 20-50 条真实的智能体轨迹
☑️ 为单个任务定义明确无误的成功标准
☑️ 将能力评估与回归评估分开
☑️ 确保你能识别并清晰说明每次失败的原因
☑️ 将评估所有权分配给单一的领域专家
☑️ 在归咎于智能体之前，先排除基础设施和数据管道问题
深入解析
在构建任何评估基础设施前，先手动审查 20-50 条真实的智能体轨迹
使用 LangSmith 从轨迹转到标注队列，再到数据集和实验。
在构建任何基础设施之前，花 30 分钟阅读真实的智能体轨迹。你从这里学到的失败模式会比从任何自动化系统中学到的都多。LangSmith 的轨迹和标注队列非常适合这项工作。
为单个任务定义明确无误的成功标准
如果两位专家无法就通过/失败达成一致，那么这个任务就需要改进：
- 不明确的标准：“很好地总结这份文档。”
- 明确的标准：“从这份会议记录中提取 3 个主要行动项。每个行动项应少于 20 个词，如果提到负责人则需包含。”
将能力评估与回归评估分开
两者你都需要，因为它们目的不同。能力评估通过衡量在困难任务上的进展来推动你的智能体向前发展，而回归评估则保护已经正常工作的功能。如果不加以区分，你可能会因为只守护现有行为而停止改进，或者因为只追求新能力而引入回归问题。
- 能力评估回答“它能做什么？”
- 开始时通过率较低，给你一个需要攀登的目标。
- 回归评估回答“它还能正常工作吗？”
- 应保持接近 100% 的通过率，并能捕捉到性能倒退。
确保你能识别并清晰说明每次失败的原因
如果你无法清晰说明某次失败的原因，那么在构建自动化评估之前，你需要进行更多的错误分析。你应该将60-80% 的评估精力花在这里。遵循以下流程：
- 收集轨迹：从生产环境或测试中收集有代表性的失败案例。
- 开放式编码：与领域专家一起审查轨迹，记录你看到的每个问题，无需预先分类（或使用我们的标注队列让主题专家自行审查轨迹）。
- 分类：将问题分组，形成失败分类法（提示问题、工具设计问题、模型限制、工具故障、数据缺口等）。
- 迭代：持续审查，直到你不再发现新的失败类别。
一旦完成分类，修复方法取决于根本原因：
- 提示问题：智能体误解是因为你的指令不清晰 → 修复提示。
- 工具设计问题：工具接口导致智能体容易犯错 → 重新设计参数、添加示例、明确边界。
- 模型限制：指令清晰，但 LLM 无法泛化到边缘情况 → 添加示例、尝试不同架构或使用不同模型。
- 尚不清楚：你还没有查看足够多的失败案例来发现模式 → 先进行更多错误分析。
将评估所有权分配给单一的领域专家
需要有人负责评估流程：维护数据集、重新校准评判标准、处理新的失败模式、决定“足够好”意味着什么。理想情况下，应由一位领域专家作为模糊案例的质量仲裁者，而不是由委员会设计。
在归咎于智能体之前，先排除基础设施和数据管道问题
Witan Labs 团队发现，一个单一的数据提取错误就将他们的基准测试结果从 50% 提升到了 73%。基础设施问题（超时、API 响应格式错误、缓存陈旧）经常伪装成推理失败。先检查数据管道。
选择你的评估层级
并非所有评估都测试相同的内容。将你的评估与智能体行为的正确层级相匹配。关于每个层级的深入探讨，请参阅《Agent Observability Powers Agent Evaluation》。
单步评估 vs. 完整轮次评估 vs. 多轮次评估
☑️ 理解三个评估层级：单步（运行）、完整轮次（追踪）和多轮次（线程）
☑️ 从追踪层级（完整轮次）评估开始，然后根据需要引入运行层级和线程层级评估
深入解析
单步评估
这类评估回答：“智能体是否选择了正确的工具？”“它是否生成了有效的 API 调用？”它们最容易自动化，但需要稳定的智能体架构；如果你仍在更改工具定义，运行层级的评估可能会失效。
完整轮次评估
这是大多数团队应该开始的地方。从三个维度对一个完整的追踪进行评分：
- 最终响应：输出是否正确且有用？
- 轨迹：智能体是否采取了合理的路径？（不一定是你期望的确切路径，只要是有效的即可）
- 状态变更：智能体是否创建了正确的工件？（写入的文件、更新的数据库、安排的会议等）
状态变更评估常被忽视，但对于那些做事而不仅仅是说事的智能体来说至关重要。例如，如果你的智能体安排会议，不要只检查它是否说了“会议已安排！”。要验证日历事件确实存在，并且时间、参与者和描述都正确。如果它写代码，就运行代码。如果它更新数据库，就查询行。最终响应可以说“完成！”，而实际状态可能是错误的。
多轮次评估
这是最难实现的层级，应在你的追踪层级评估稳定后再引入。
💡
实用技巧：使用 N-1 测试。从生产环境中获取真实对话前缀（前 N-1 轮），只让智能体生成最后一轮。这避免了完全合成的多轮次模拟中复合错误的问题。
从追踪层级（完整轮次）评估开始，然后根据需要引入运行层级和线程层级评估
追踪层级评估能给你带来最多的信号。运行层级评估有助于调试特定步骤。当你的智能体涉及多轮对话时，线程层级评估就很重要。
数据集构建
☑️ 确保每个任务都明确无误，并有一个参考解决方案证明它是可解决的
☑️ 同时测试正向案例（应该发生的行为）和负向案例（不应该发生的行为）
☑️ 确保数据集结构与你选择的评估层级相匹配
☑️ 根据你的智能体类型（编码、对话、研究）定制数据集
☑️ 如果缺乏生产数据，生成种子示例
☑️ 从内部试用错误、改编的外部基准测试和手写的行为测试中获取数据源
☑️ 建立从轨迹到数据集的飞轮，实现持续改进
深入解析
确保每个任务都明确无误，并有一个参考解决方案证明它是可解决的
- 不明确：“帮我找去纽约的好航班。”
- 明确：“查找从旧金山国际机场到肯尼迪国际机场的往返航班，出发日期 12 月 15-17 日，返回日期 12 月 22 日，经济舱，价格低于 400 美元。”
如果智能体不可能成功（信息缺失、约束条件不可能），那么是任务本身有问题，而不是智能体。为每个任务包含一个参考解决方案，这样你可以证明它是可解决的，并有一个基准来评分。
同时测试正向案例（应该发生的行为）和负向案例（不应该发生的行为）
如果你只测试“它该搜索时是否搜索了？”，你会优化出一个什么都搜索的智能体。也要测试负向案例。包含那些旨在证伪你假设的示例，而不仅仅是确认预期行为。
确保数据集结构与你选择的评估层级相匹配
- 运行层级（单步）评估需要参考工具调用或决策。
- 追踪层级（完整轮次）评估需要预期的最终输出和/或状态变更。
- 线程层级（多轮次）评估需要多轮对话序列以及预期的上下文保留。
根据你的智能体类型（编码、对话、研究）定制数据集
- 编码智能体：包含确定性测试套件（通过/失败的单元测试）以及质量评估标准。
- 对话智能体：包含多维度标准，任务完成度和交互质量（同理心、清晰度）。
- 研究智能体：包含事实对齐检查（主张是否有来源支持？）和覆盖度检查（关键事实是否包含？）。
如果缺乏生产数据，生成种子示例
定义你任务的关键变化维度（查询复杂度、主题、边缘案例类型）。手动创建约 20 个涵盖这些维度的示例输入，通过你现有的智能体运行它们，审查并修改后存储为可靠的基准真值。
💡
实用技巧：20-50 个你确信无误、经过人工审查的示例，其效果会优于数百个你未经验证的合成示例。在这里，质量胜过数量！
从内部试用错误、改编的外部基准测试和手写的行为测试中获取数据源
一旦度过冷启动阶段，你需要一个持续的流程来发现新的评估。以下三种策略结合使用效果很好：
- 每天内部试用你的智能体，并将每个错误转化为一个评估。这与生产监控不同；这是你的团队有意在真实工作流中压力测试智能体。
- 从外部基准测试（如 Terminal Bench 或 BFCL）中提取并改编任务。不要整体运行完整的基准测试；挑选那些测试你关心能力的任务，并为你的智能体进行改编。
- 针对你认为重要的特定行为，手动编写聚焦的测试，例如“智能体是否并行调用工具？”或“对于模糊的请求，它是否会询问澄清性问题？”
关于这种方法的具体示例，请参阅《How we build evals for Deep Agents》。
评分器设计
☑️ 按评估维度选择专用评分器：客观检查默认用代码评分器，主观评估用 LLM-as-judge，模糊情况用人审，版本对比用成对比较
☑️ 区分安全护栏（内联、运行时）与评估器（异步、质量评估）
☑️ 优先采用二元通过/失败，而非数值评分
☑️ 将 LLM-as-a-Judge 评分器校准到人类偏好
☑️ 评估结果而非具体路径，并为渐进式进展设置部分得分
☑️ 使用基于错误分析的自定义评估器，而非通用的现成指标
深入解析
按评估维度选择专用评分器
| 评分器类型 | 最适合场景 | 注意事项 |
|---|---|---|
| 代码评分器 | 确定性检查、工具调用验证、输出格式、执行结果 | 可能对有效但非预期的格式误判失败 |
| LLM-as-judge | 细微质量、基于量规的评分、开放式任务 | 需要与人类校准（参见 Align Evals） |
| 人审 | 校准、主观标准、边缘案例 | 昂贵、缓慢、难以扩展 |
当存在客观正确答案时，默认使用代码评估器。LLM-as-judge 用于客观任务可能不可靠，不一致的判断会掩盖真正的性能衰退。切换到确定性比较通常能消除不一致性并提供更好的信号。将 LLM-as-judge 留给真正主观的评估。
💡 实用建议：与其尝试创建一个“正确性”评估器，不如将评估分解为每个维度的专用评分器，而不是一个单一的整体评分器。
例如：Witan Labs 团队构建了 5 个专用评估器（内容准确性、结构、视觉格式、公式场景、文本质量），每个都有适合维度的阈值。这让你能更清晰地了解实际失败的是什么！
区分安全护栏与评估器
| 特性 | 安全护栏 | 评估器 |
|---|---|---|
| 执行时机 | 执行期间，用户看到输出前 | 生成后，异步 |
| 速度 | 毫秒级（必须快速） | 秒到分钟级（可以较慢） |
| 目的 | 阻止危险或格式错误的输出 | 衡量质量并捕捉性能衰退 |
| 示例 | PII 检测、格式验证、安全过滤器 | LLM-as-judge 评分、轨迹分析 |
安全检查（如 PII 检测）和格式验证是安全护栏，它们应该内联运行。质量评估和回归测试是评估器，它们异步运行。别把两者搞混了。
优先采用二元通过/失败，而非数值评分
1-5 分的评分会引入相邻分数之间的主观差异，并且需要更大的样本量才能达到统计显著性。二元评分迫使思考更清晰：智能体要么成功，要么失败。你总是可以将复杂任务分解为多个二元检查。
注意：近期研究 表明，在使用 LLM-as-judge 时，短尺度（0-5）可能产生更强的人类-LLM 对齐，但二元评分对人类评审员来说更简单，迭代也更快。
将 LLM-as-a-Judge 评分器校准到人类偏好
- 从使用 LangSmith 的 Align Evaluator 功能标注 20+ 个示例开始，然后逐步增加到约 100 个以获得生产级置信度
- 在评分器的输出中包含推理过程；这能提高准确性，并让你能审计它“为什么”这样评分（Anthropic 的 Demystifying Evals 也强调了这一点）
- 定期重新校准；评分器会随时间漂移，并且 没有单一的评分器在所有基准测试中都是可靠的
- 使用 少样本示例 来提高评估器的一致性；在 LangSmith 中，修正可以自动填充为少样本示例
评估结果而非具体路径，并为渐进式进展设置部分得分
智能体总能找到创造性的解决方案。正如 Anthropic 在 Demystifying Evals 中所说：“不要评估智能体采取的路径，评估它产生的结果。”如果你要求“必须按顺序调用工具 A → B → C”，你会让那些找到更聪明路径的智能体失败。更好的做法是：“会议安排正确了吗？”而不是“它是在 create_event 之前调用了 check_availability 吗？”
一个正确识别问题但在最后一步失败的智能体，比一个立即失败的智能体要好。设置部分得分，这样你的指标就能反映渐进式进展。
使用基于错误分析的自定义评估器，而非通用的现成指标
现成的指标如“有用性”或“连贯性”会产生虚假的信心。真正重要的是那些能捕捉到你特定失败模式的评估器，这些模式是通过上述错误分析过程发现的。
运行与迭代
☑️ 区分离线、在线和临时评估，并三者并用
☑️ 每项任务运行多次试验以考虑非确定性
☑️ 手动审查失败评估的轨迹以验证评分器公平性
☑️ 确保每次试验在干净、隔离的环境中运行，无共享状态
☑️ 按能力类别标记评估，记录每个评估的测量内容，并跟踪效率指标（步骤数、工具调用数、延迟）以及质量
☑️ 识别通过率何时趋于平稳，并相应调整你的测试套件
☑️ 只保留直接衡量你关心的生产行为的评估
☑️ 投资于工具接口设计和测试，而不仅仅是提示优化
☑️ 区分任务失败（智能体做错了）和评估失败（评分器做错了）
深度解析
区分离线、在线和临时评估，三者并用
这份清单的大部分内容都聚焦于离线评估，这是有意的。离线评估是你通过以下方式改进的地方：整理数据集、进行受控实验、在发布前迭代。一旦你的智能体进入生产环境，你还需要在线评估和临时评估。
| 评估类型 | 内容 | 使用时机 |
|---|---|---|
| 离线 | 整理数据集，在部署前运行 | 在变更发布前进行测试 |
| 在线 | 对生产环境追踪进行持续评估 | 在真实流量中捕捉故障 |
| 临时 | 对已摄入的追踪进行探索性分析 | 发现你未预料到的模式（参见 Insights） |
下面的“生产就绪”部分将详细说明如何设置在线评估以及安排临时追踪探索。
为每个任务运行多次试验，以考虑非确定性
模型输出在不同运行间会有差异。如果成本允许，使用多次重复。运行多次试验时，在宣布改进之前先计算置信区间——单次运行的基准测试结果是有噪声的。对于非确定性智能体，根据你的产品需求，考虑使用 pass@k（k 次尝试中至少一次成功）或 pass^k（k 次尝试全部成功）指标。
除了质量指标，还要跟踪运行指标：采取的步骤数、token 使用量、延迟、每任务成本。一个准确率 95% 但速度慢 10 倍的智能体可能算不上改进。
按能力类别标记评估，记录每个评估的测量内容，并同时跟踪效率指标
按测试内容而非来源对评估进行分组。像 file_operations、retrieval、tool_use、memory、conversation 这样的类别，能让你在单一总分和单个测试结果之间获得一个“中层视图”的性能概览。为每个评估添加文档字符串，解释它如何衡量智能体的某项能力。这能确保随着评估套件增长，其意图仍然清晰，并允许你运行有针对性的子集（例如，在更改工具定义后只运行 tool_use 评估）。
为每个实验附加元数据，以便你能跨重要维度过滤、分组和比较运行。这让你能轻松回答诸如“从 GPT-4.1 切换到 Claude Sonnet 是否提高了准确率？”或“哪个提示版本在这个数据集上出现了倒退？”这类问题，而无需翻阅日志。LangSmith 在可用时会自动捕获 git 信息，但随着实验数量增长，显式地标记模型和提示元数据会很快带来回报。
一旦质量达标，就对比模型的效率。一个准确率 95% 但速度慢 10 倍的智能体可能算不上改进。跟踪诸如观察步骤数 / 理想步骤数、观察工具调用数 / 理想工具调用数、观察延迟 / 理想延迟等比率。这与“评估结果，而非精确路径”并不冲突：理想轨迹衡量的是效率，而非正确性。你仍然会让一个找到创造性路径的智能体通过，但可以看到它是否花了更长时间。关于具体示例，请参见我们如何为深度智能体构建评估中的指标框架。
手动审查失败评估的追踪，以验证评分器的公平性
一个“失败”的任务实际上可能是你的评分器未预料到的、有创意的有效解决方案。阅读追踪记录是了解你的评分器是否公平的唯一途径。
确保每次试验都在干净、隔离的环境中运行，没有共享状态
如果试验 2 能看到试验 1 的产物，那么你的结果就不是独立的。实际操作中这意味着：
- 编码智能体：每次试验使用新的容器或虚拟机
- 调用 API 的智能体：使用预演环境或模拟服务
- 数据库智能体：在试验之间进行快照和恢复
识别通过率何时达到平台期，并相应演进你的测试套件
当你的通过率达到平台期，并且添加更多同类任务不再能揭示新的失败模式时，就是时候进行演进了：增加更困难的任务、测试新能力，或转向不同的维度。在一个已饱和的评估集上反复打磨是浪费精力。
只保留那些直接衡量你在生产环境中关心的行为的评估
每个评估都会随着时间的推移对你的系统施加压力。盲目添加数百个测试很诱人，但这会造成进步的假象。你最终会优化一个不能反映生产环境重要内容的评估套件。更多的评估不等于更好的智能体。构建有针对性的评估，并定期剔除那些不再提供有效信号的评估。关于这种方法的具体示例，请参见我们如何为深度智能体构建评估。
投资于工具接口设计和测试，而不仅仅是提示优化
工具设计可以消除整类的智能体错误。Anthropic 团队在构建他们的 SWE-bench 智能体时指出，他们花在优化工具上的时间比优化提示更多。测试模型实际如何使用你的工具：尝试不同的参数格式（差异对比 vs 完全重写，JSON vs. markdown），重新设计接口以降低犯错可能性，并投资于带有示例的清晰文档。目标是让错误在结构上不可能发生，而不仅仅是降低可能性。例如，要求绝对文件路径可以消除整类的导航错误。
区分任务失败（智能体做错了）和评估失败（评分器做错了）
显式跟踪运行状态（完成、错误、超时）。一个将超时标记为“推理错误”的评分器会污染你的信号。将任务失败与评估失败分开，以保持指标清晰。
生产就绪
☑️ 将通过率持续较高的能力评估纳入回归测试套件
☑️ 将回归评估集成到你的 CI/CD 流水线中，并设置自动化质量门
☑️ 捕获用户反馈
☑️ 为生产流量设置在线评估
☑️ 定期安排手动探索生产环境追踪，超越自动化检查
☑️ 将你的提示和工具定义与代码一同进行版本控制
☑️ 确保生产环境的失败能反馈到数据集、错误分析和评估改进中
深度解析
将通过率持续较高的能力评估纳入回归测试套件
一旦你攻克了难关，就要守住它。那些曾经测试“我们能做到吗？”的任务，现在变成了“我们还能做到吗？”
将回归评估集成到你的 CI/CD 流水线中，并设置自动化质量门
一个典型的流程：
- 代码或提示变更触发流水线（通过
git push、PromptHub 更新或手动触发） - 运行离线评估：使用廉价、快速的评分器进行单元测试、集成测试以及对整理数据集的评估
- 如果离线评估通过，则进行预览部署
- 使用实时数据对预览版本运行在线评估，使用 LLM 作为评分器
- 仅当所有质量门都通过时，才推广到生产环境，否则将失败的追踪路由到标注队列并提醒团队
在 CI 中为每次提交使用廉价的基于代码的评分器。将昂贵的 LLM 作为评分器的评估留给预览/生产环境评估。关于完整的实现示例，请参见 LangSmith 的 CI/CD 流水线指南。
为生产流量设置在线评估
安全检查、格式验证、质量启发式方法。你会在生产环境中发现你从未预料到的失败模式（参见在投入生产之前，你无法知道你的智能体会做什么）。
捕获用户反馈
一旦你的智能体进入生产环境，用户反馈就成为你最宝贵的信号之一。自动化评估只能捕捉你已经知道的失败模式。用户会揭示那些你不知道的：你的数据集遗漏的边缘情况、技术上正确但无用的输出，以及以你从未预料到的方式中断的工作流。
以结构化的方式捕获这些反馈，可以让你将其反馈到你的数据集中，根据现实世界的期望校准你的评分器，并优先处理对实际使用你智能体的人真正重要的改进。
定期安排手动探索生产环境追踪，超越自动化检查
不要仅仅依赖自动化的通过/失败。定期探索生产环境追踪，寻找你的评分器未覆盖的意外模式或失败模式、令人惊讶的用户行为，或改进的机会。我们的 Insights Agent 是进行此类探索的好方法！
将你的提示和工具定义与代码一同进行版本控制
LangSmith 可以轻松地对你的提示进行版本控制。没有这个，你就无法将评估结果与特定变更关联起来，也无法知道是哪个编辑导致了倒退。
确保生产环境的失败能反馈到数据集、错误分析和评估改进中
生产环境的成功和失败应该反馈到你的数据集、错误分析和评估改进中。这就是让你的智能体随时间变得更好的飞轮！
你不需要在第一天就完成所有这些事项。选择与你当前所处阶段匹配的部分，搞定那些事项，然后在此基础上扩展。那些能交付可靠智能体的团队，并不是拥有最复杂评估基础设施的团队，而是那些很早就开始评估并且从未停止迭代的团队。
完整清单
在你构建评估之前
⬜️ 在构建任何评估基础设施之前，手动审查 20-50 个真实的智能体追踪
⬜️ 为单个任务定义明确无误的成功标准
⬜️ 将能力评估与回归评估分开
⬜️ 确保你能识别并阐明每个失败发生的原因
⬜️ 将评估所有权分配给单个领域专家
⬜️ 在归咎于智能体之前，先排除基础设施和数据流水线问题
选择你的评估级别
⬜️ 理解三个评估级别：单步（运行）、完整轮次（追踪）和多轮次（线程）
⬜️ 从追踪级别（完整轮次）评估开始，然后根据需要加入运行级别和线程级别评估
数据集构建
⬜️ 确保每个任务都是明确的，并有一个参考解决方案证明它是可解的
⬜️ 测试正面案例（行为应该发生）和负面案例（行为不应该发生）
⬜️ 确保数据集结构与你选择的评估级别相匹配
⬜️ 根据你的智能体类型（编码、对话、研究）定制数据集
⬜️ 如果你缺乏生产数据，则生成种子示例
⬜️ 从内部测试错误、改编的外部基准测试和手写的行为测试中获取数据
⬜️ 建立一个从追踪到数据集的飞轮，以实现持续改进
评分器设计
⬜️ 按评估维度选择专用评分器：客观检查用代码方案，主观评估用 LLM 当裁判（LLM-as-Judge），模糊情况用人审，版本对比用成对评估（Pairwise）
⬜️ 分清安全护栏（Guardrails，内联、运行时）和评估器（异步、质量评估）的区别
⬜️ 优先用二元通过/失败，少用数字评分
⬜️ 校准 LLM 裁判，让它跟人的偏好对齐
⬜️ 评分看结果，别死抠执行路径，给渐进式进展留出部分得分空间
⬜️ 用自己错误分析里总结出来的定制评估器，别直接套用通用指标
运行与迭代
⬜️ 分清离线、在线和临时评估，三种都用上
⬜️ 每个任务跑多次试验，消除随机性影响
⬜️ 手动检查失败评估的轨迹，确认评分器是否公平
⬜️ 确保每次试验都在干净、隔离的环境里跑，不共享状态
⬜️ 给评估打上能力标签，写明测什么，同时追踪效率指标（步骤数、工具调用、延迟）和质量指标
⬜️ 通过率停滞时，及时更新测试集
⬜️ 只保留那些直接衡量生产关键行为的评估
⬜️ 多投精力在工具接口设计和测试上，别光调提示词
⬜️ 分清任务失败（智能体搞错了）和评估失败（评分器搞错了）
生产就绪
⬜️ 把通过率稳定高的能力评估，升级到回归测试集里
⬜️ 回归评估集成进 CI/CD 流水线，设自动质量门
⬜️ 收集用户反馈
⬜️ 为生产流量设置在线评估（Online Evaluations）
⬜️ 定期手动检查生产轨迹，别只依赖自动化
⬜️ 提示词和工具定义跟代码一起做版本管理
⬜️ 生产中的失败要反馈到数据集、错误分析和评估改进里
延伸阅读
LangChain：
Witan Labs：
外部基准（用于获取评估任务）：
Anthropic：
OpenAI：
Hamel Husain：
arXiv 论文：
LangSmith 文档：
觉得有用？分享给更多人