智能体评估准备清单

来源: https://www.langchain.com/blog/agent-evaluation-readiness-checklist 抓取时间: 2026-07-21 16:23:53

可观测性与评估 LangSmith

智能体评估准备清单

Victor Moreira 2026年3月27日 22 分钟 返回博客 创建智能体 分享 作者：Victor Moreira，LangChain部署工程师 本清单是《智能体可观测性驱动智能体评估》的实用配套指南，该文章阐述了为什么智能体评估不同于传统软件测试，介绍了核心可观测性原语（运行、追踪、会话），并解释了它们如何映射到评估层级。如果你是智能体评估新手，请先阅读那篇文章。 本文聚焦于如何做——一个构建、运行和交付智能体评估的分步清单。 **从能给你信号的最简单评估开始。**几个测试智能体是否完成核心任务的端到端评估会立即给你一个基线，即使你的架构仍在变化。只有当有证据表明更简单的方法遗漏了真实故障时，才增加复杂性。 🤔 不想深入研究？直接跳到完整清单。

构建评估之前

0:00 /0:421× 使用 LangSmith 从追踪到注释队列，再到数据集和实验 ☑️ 在构建任何评估基础设施之前，手动审查 20-50 条真实智能体追踪 ☑️ 为单个任务定义明确的成功标准 ☑️ 区分能力评估与回归评估 ☑️ 确保你能够识别并清晰解释每个故障发生的原因 ☑️ 将评估所有权分配给单个领域专家 ☑️ 在归咎于智能体之前，排除基础设施和数据管道问题

深入探讨

在构建任何评估基础设施之前，手动审查 20-50 条真实智能体追踪

使用 LangSmith 从追踪到注释队列，再到数据集和实验。 在构建任何基础设施之前，花 30 分钟阅读真实的智能体追踪。你会从中学到比任何自动化系统更多的故障模式。LangSmith 的追踪和注释队列非常适合这个目的。

为单个任务定义明确的成功标准

如果两个专家无法就通过/失败达成一致，该任务需要细化：

• 不明确的成功：「很好地总结这个文档。」
• 明确的成功：「从这份会议记录中提取 3 个主要行动项。每个应少于 20 字，如果提到负责人则包含在内。」

区分能力评估与回归评估

你两者都需要，因为它们服务于不同的目的。能力评估通过衡量困难任务的进展来推动你的智能体向前发展，而回归评估保护已经有效的东西。没有这种区分，你要么因为只守护现有行为而停止改进，要么因为只追求新能力而引入回归。

• _能力评估_回答「它能做什么？」
  • 从低通过率开始，给你一个需要攀登的山丘。
• _回归评估_回答「它还能工作吗？」
  • 应该有接近 100% 的通过率，并捕获倒退。

确保你能够识别并清晰解释每个故障发生的原因

如果你无法解释为什么某些东西失败了，你需要在构建自动化评估之前进行更多错误分析。这是你应该花费60-80% 评估精力的地方。遵循此流程：

1. 收集追踪：从生产或测试中收集有代表性的故障
2. 开放式编码：与领域专家一起审查追踪，记录你看到的每个问题而不预先分类（或使用我们的注释队列让主题专家自行审查追踪）
3. 分类：将问题分组到故障分类法中（提示问题、工具设计问题、模型限制、工具故障、数据缺口等）
4. 迭代：继续审查，直到你停止发现新的故障类别

一旦分类，修复取决于根本原因：

• 提示问题：智能体误解了，因为你的指令不清楚 → 修复提示
• 工具设计问题：工具界面使智能体容易犯错 → 重新设计参数、添加示例、澄清边界
• 模型限制：指令清晰，但 LLM 无法推广到边缘情况 → 添加示例、尝试不同的架构或使用不同的模型
• 还不知道：你还没有查看足够多的故障来发现模式 → 首先进行更多错误分析

将评估所有权分配给单个领域专家

需要有人拥有评估流程：维护数据集、校准裁判、分类新的故障模式，并决定「足够好」是什么意思。理想情况下，一位领域专家作为模糊案例的质量仲裁者，而不是通过委员会设计。

在归咎于智能体之前，排除基础设施和数据管道问题

Witan Labs 团队发现，一个单一的提取错误将他们的基准从 50% 提升到 73%。基础设施问题（超时、格式错误的 API 响应、过时的缓存）经常伪装成推理失败。首先检查数据管道。

选择你的评估层级

单步 vs. 完整轮次 vs. 多轮评估 并非所有评估都测试相同的东西。将你的评估与正确的智能体行为层级匹配。关于每个层级的深入探讨，请参阅《智能体可观测性驱动智能体评估》。

单步 vs. 完整轮次 vs. 多轮评估

☑️ 理解三个评估层级：单步（运行）、完整轮次（追踪）和多轮（会话） ☑️ 从追踪级（完整轮次）评估开始，然后根据需要分层加入运行级和会话级

深入探讨

单步评估

这些回答：「智能体选择了正确的工具吗？」「它生成了有效的 API 调用吗？」它们最容易自动化，但需要稳定的智能体架构；如果你仍在更改工具定义，运行级评估可能会中断。

完整轮次评估

这是大多数团队应该开始的地方。从三个维度对完整追踪进行评分：

• 最终响应：输出是否正确且有用？
• 轨迹：智能体是否采取了合理的路径？（不一定是你预期的_确切_路径，只是一个有效的路径）
• 状态变化：智能体是否创建了正确的工件？（写入的文件、更新的数据库、安排的会议等）

状态变化评估经常被忽视，但对于_做事_而不仅仅是_说话_的智能体至关重要。例如，如果你的智能体安排会议，不要只检查它说「会议已安排！」。验证日历事件是否确实存在，时间、与会者和描述是否正确。如果它编写代码，运行代码。如果它更新数据库，查询行。最终响应可能说「完成！」而实际状态是错误的。

多轮评估

最难实现的层级，在你的追踪级评估稳定后分层加入。 💡 **实用提示：**使用 N-1 测试。从生产中获取真实对话前缀（前 N-1 轮），让智能体只生成最后一轮。这避免了完全合成多轮模拟的复合错误问题。

从追踪级（完整轮次）评估开始，然后根据需要分层加入运行级和会话级

追踪级每次评估给你最多的信号。运行级对于调试特定步骤很有用。当你的智能体有多轮对话时，会话级很重要。

数据集构建

☑️ 确保每个任务都是明确的，并有一个证明其可解的参考解决方案 ☑️ 测试正面案例（应该发生的行为）和负面案例（不应该发生的行为） ☑️ 确保数据集结构与你选择的评估层级匹配 ☑️ 根据你的智能体类型（编码、对话、研究）定制数据集 ☑️ 如果你缺乏生产数据，生成种子示例 ☑️ 来自内部测试错误、适配的外部基准和手写行为测试 ☑️ 建立追踪到数据集的飞轮以持续改进

深入探讨

确保每个任务都是明确的，并有一个证明其可解的参考解决方案

• 模糊：「给我找去纽约的好航班。」
• 明确：「查找从 SFO 到 JFK 的往返航班，12 月 15-17 日出发，22 日返回，400 美元以下，经济舱。」

如果智能体不可能成功（信息缺失、不可能的约束），那么任务是坏的，不是智能体。为每个任务包含参考解决方案，以便你可以证明它是可解的并有一个评分的基线。

测试正面案例（应该发生的行为）和负面案例（不应该发生的行为）

如果你只测试「它应该搜索时搜索了吗？」，你会优化一个搜索一切的智能体。也要测试负面案例。包括旨在证伪你假设的示例，而不仅仅是确认预期行为。

确保数据集结构与你选择的评估层级匹配

• 运行级（单步）评估需要参考工具调用或决策
• 追踪级（完整轮次）评估需要预期的最终输出和/或状态变化
• 会话级（多轮）评估需要具有预期上下文保留的多轮对话序列

根据你的智能体类型（编码、对话、研究）定制数据集

• 编码智能体：包括确定性测试套件（通过/失败的单元测试）以及质量指标
• 对话智能体：包括多维标准、任务完成_和_交互质量（同理心、清晰度）
• 研究智能体：包括事实性检查（主张是否有来源支持？）和覆盖率检查（是否包含关键事实？）

如果你缺乏生产数据，生成种子示例

定义任务的关键变化维度（查询复杂性、主题、边缘情况类型）。手动创建约 20 个涵盖这些维度的示例输入，通过你现有的智能体运行它们，审查并修改它们以存储为可靠的地面实况。 💡 **实用提示：**你有信心的 20-50 个人工审查示例将胜过数百个你未验证的合成示例。这里质量胜于数量！

来自内部测试错误、适配的外部基准和手写行为测试

一旦你度过了冷启动阶段，你需要一个持续的管道来发现新的评估。三种策略配合得很好：

1. 每天内部测试你的智能体，并将每个错误变成一个评估。这不同于生产监控；这是你的团队有意在真实工作流中对智能体进行压力测试。
2. 从外部基准如Terminal Bench或BFCL中提取并适配任务。不要汇总运行完整基准；精心挑选测试你关心的能力的任务，并为你的智能体适配它们。
3. 为你认为重要的特定行为手动编写重点测试，例如「智能体是否并行化工具调用？」或「它是否为模糊请求提出澄清问题？」

请参阅《我们如何为深度智能体构建评估》以获取此方法的具体示例。

评分器设计

☑️ 为每个评估维度选择专门的评分器：默认使用基于代码的客观检查，LLM 作为裁判进行主观评估，人类处理模糊情况，成对比较用于版本比较 ☑️ 区分护栏（内联、运行时）与评估器（异步、质量评估） ☑️ 偏好二进制通过/失败而非数字量表 ☑️ 将 LLM 作为裁判的评分器校准到人类偏好 ☑️ 对结果评分，而不是确切路径，并为渐进式进展建立部分信用 ☑️ 使用从你的错误分析中得出的自定义评估器，而不是通用的现成指标

深入探讨

为每个评估维度选择专门的评分器

| 护栏 | 评估器 ---|---|--- 何时 | 执行期间，用户看到输出之前 | 生成后，异步 速度 | 毫秒（必须快） | 秒到分钟（可能昂贵） 目的 | 阻止危险或格式错误的输出 | 衡量质量并捕获回归 示例 | PII 检测、格式验证、安全过滤器 | LLM 作为裁判评分、轨迹分析 当存在客观正确答案时，默认使用基于代码的评估器。针对客观任务的 LLM 作为裁判评分可能不可靠，不一致的判断可能掩盖真实回归。切换到确定性比较通常可以消除不一致并提供更好的信号。保留 LLM 作为裁判用于真正主观的评估。 💡 **实用提示：**与其尝试创建一个_正确性_评估器，不如将评估分解为每个维度的专门评分器，而不是一个单一的评分器。例如：Witan Labs 团队构建了 5 个专门的评估器（内容准确性、结构、视觉格式、公式场景、文本质量），每个都有适用于维度的阈值。这让你更清晰地了解实际失败的是什么！

区分护栏与评估器

-Judge 评分、轨迹分析

偏好二进制通过/失败而非数字量表

1-5 的量表引入了相邻分数之间的主观差异，需要更大的样本量才能获得统计显著性。二进制迫使更清晰的思考：智能体要么成功，要么失败。你总是可以将复杂任务分解为多个二进制检查。 注意：最近的研究表明，当专门使用 LLM 作为裁判时，短量表（0-5）可能产生更强的人类-LLM 对齐，但二进制对于人类审查者仍然更简单，迭代更快。

将 LLM 作为裁判的评分器校准到人类偏好

• 从使用 LangSmith 的对齐评估器功能的 20+ 个标记示例开始，然后增长到约 100 个以获得生产级信心
• 在裁判的输出中包含推理；这提高了准确性，并让你审计_为什么_它给某个东西打分（Anthropic 的《揭秘评估》也强调了这一点）
• 定期重新校准；评分器会随时间漂移，没有单个评分器在所有基准上都一致可靠
• 使用少样本示例来提高评估器的一致性；在 LangSmith 中，修正可以自动作为少样本示例填充

对结果评分，而不是确切路径，并为渐进式进展建立部分信用

智能体找到创造性的解决方案。正如 Anthropic 在《揭秘评估》中所说：「不要对智能体采取的路径评分，对它产生的东西评分。」如果你要求「必须按该顺序调用工具 A → B → C」，你会让找到更智能路线的智能体失败。更好的做法是：「会议安排正确了吗？」而不是「它在 create_event 之前调用了 check_availability 吗？」 正确识别问题但在最后一步失败的智能体比立即失败的智能体更好。建立部分信用，以便你的指标反映渐进式进展。

使用从你的错误分析中得出的自定义评估器，而不是通用的现成指标

像「有用性」或「连贯性」这样的现成指标会产生虚假的信心。重要的评估器是那些捕获_你的_特定故障模式的评估器，通过上述错误分析过程发现。

运行与迭代

☑️ 区分离线、在线和临时评估，并使用所有三种 ☑️ 每个任务运行多次试验以考虑非确定性 ☑️ 手动审查失败评估的追踪以验证评分器公平性 ☑️ 确保每次试验在干净、隔离的环境中运行，没有共享状态 ☑️ 按能力类别标记评估，记录每个测量的内容，并跟踪效率指标（步数、工具调用、延迟）以及质量 ☑️ 识别通过率何时趋于平稳并相应发展你的测试套件 ☑️ 只保留直接测量你关心的生产行为的评估 ☑️ 投资于工具界面设计和测试，而不仅仅是提示优化 ☑️ 区分任务失败（智能体弄错了）和评估失败（评分器弄错了）

深入探讨

区分离线、在线和临时评估并使用所有三种

本清单的大部分重点是离线评估，这是有意的。离线评估是你改进的地方：精选数据集、受控实验、在交付之前迭代。一旦你的智能体投入生产，你还需要在线和临时评估。

生产就绪部分下面详细介绍了设置在线评估和安排临时追踪探索。

每个任务运行多次试验以考虑非确定性

模型输出在运行之间有所不同。如果成本不高，使用多次重复。当运行多次试验时，在宣布改进之前计算置信区间——单次运行基准是有噪声的。对于非确定性智能体，考虑使用通过率@k（k 次尝试中至少一次成功）或通过率^k（所有 k 次尝试都成功）指标，具体取决于你的产品要求。 跟踪运营指标以及质量：采取的轮数、令牌使用、延迟、每个任务的成本。一个准确率为 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 智能体时，他们花在优化工具上的时间比花在提示上的时间更多。测试模型实际如何使用你的工具：尝试不同的参数格式（差异与完全重写、JSON 与 Markdown），重新设计界面以使错误更难发生，并投资于带有示例的清晰文档。目标是使错误在结构上不可能，而不仅仅是不太可能。例如，要求绝对文件路径消除了一整类导航错误。

区分任务失败（智能体弄错了）和评估失败（评分器弄错了）

明确跟踪运行状态（完成、错误、超时）。将超时标记为「不正确推理」的评分器会污染你的信号。将任务失败与评估失败分开，以保持指标清洁。

生产就绪

☑️ 将具有持续高通过率的能力评估推广到你的回归套件中 ☑️ 将回归评估集成到你的 CI/CD 管道中，并带有自动化质量门 ☑️ 捕获用户反馈 ☑️ 为生产流量设置在线评估 ☑️ 安排定期手动探索超出自动检查的生产追踪 ☑️ 与代码一起版本化你的提示和工具定义 ☑️ 确保生产失败反馈到数据集、错误分析和评估改进中

深入探讨

将具有持续高通过率的能力评估推广到你的回归套件中

一旦你攀登了山丘，就保护它。曾经测试「我们能做到吗？」的任务变成了「我们还能做到吗？」

将回归评估集成到你的 CI/CD 管道中，并带有自动化质量门

典型流程：

1. 代码或提示更改触发管道（通过 git push、PromptHub 更新或手动触发）
2. 离线评估运行单元测试、集成测试，并使用廉价、快速的评分器针对精选数据集进行评估
3. 预览部署如果离线评估通过则启动
4. 在线评估运行使用 LLM 作为裁判的评分器，用实时数据针对预览运行
5. 推广到生产只有当所有质量门都通过时才这样做，否则将失败的追踪路由到注释队列并提醒团队

在 CI 中为每次提交使用廉价的基于代码的评分器。保留昂贵的 LLM 作为裁判的评估用于预览/生产评估。有关使用 GitHub Actions 的完整实现示例，请参阅 LangSmith 的 CI/CD 管道指南。

为生产流量设置在线评估

安全检查、格式验证、质量启发式。你会在生产中发现你从未预料到的故障模式（请参阅《在你的智能体投入生产之前，你不知道它会做什么》）

捕获用户反馈

一旦你的智能体投入生产，用户反馈就成为你最有价值的信号之一。自动化评估只能捕获你已经知道的故障模式。用户会发现你不知道的：你的数据集遗漏的边缘情况、技术上正确但无用的输出，以及以你从未预料到的方式破坏的工作流。 以结构化方式捕获此反馈使你能够将其反馈到你的数据集中，根据现实世界的期望校准你的评分器，并优先考虑对实际使用你的智能体的人重要的改进。

安排定期手动探索超出自动检查的生产追踪

不要仅仅依赖自动化的通过/失败。定期探索生产追踪以寻找你的评分器未涵盖的意外模式或故障模式、令人惊讶的用户行为或改进机会。我们的洞察智能体是做到这一点的好方法！

版本化你的提示和工具定义

LangSmith 使版本化你的提示变得容易。没有这个，你就无法将评估结果与特定更改相关联，或知道哪个编辑导致了回归。

确保生产失败反馈到数据集、错误分析和评估改进中

生产成功和失败应该反馈到你的数据集、错误分析和评估改进中。这是使你的智能体随时间变得更好的飞轮！ 你不需要在第一天就拥有所有这些项目。选择与你当前所在位置匹配的部分，做好这些项目，然后从那里扩展。交付可靠智能体的团队不是那些拥有最复杂评估基础设施的团队——而是那些尽早开始评估并从未停止迭代的团队。

完整清单

构建评估之前

⬜️ 在构建任何评估基础设施之前，手动审查 20-50 条真实智能体追踪 ⬜️ 为单个任务定义明确的成功标准 ⬜️ 区分能力评估与回归评估 ⬜️ 确保你能够识别并清晰解释每个故障发生的原因 ⬜️ 将评估所有权分配给单个领域专家 ⬜️ 在归咎于智能体之前，排除基础设施和数据管道问题

选择你的评估层级

⬜️ 理解三个评估层级：单步（运行）、完整轮次（追踪）和多轮（会话） ⬜️ 从追踪级（完整轮次）评估开始，然后根据需要分层加入运行级和会话级

数据集构建

⬜️ 确保每个任务都是明确的，并有一个证明其可解的参考解决方案 ⬜️ 测试正面案例（应该发生的行为）和负面案例（不应该发生的行为） ⬜️ 确保数据集结构与你选择的评估层级匹配 ⬜️ 根据你的智能体类型（编码、对话、研究）定制数据集 ⬜️ 如果你缺乏生产数据，生成种子示例 ⬜️ 来自内部测试错误、适配的外部基准和手写行为测试 ⬜️ 建立追踪到数据集的飞轮以持续改进

评分器设计

⬜️ 为每个评估维度选择专门的评分器：默认使用基于代码的客观检查，LLM 作为裁判进行主观评估，人类处理模糊情况，成对比较用于版本比较 ⬜️ 区分护栏（内联、运行时）与评估器（异步、质量评估） ⬜️ 偏好二进制通过/失败而非数字量表 ⬜️ 将 LLM 作为裁判的评分器校准到人类偏好 ⬜️ 对结果评分，而不是确切路径，并为渐进式进展建立部分信用 ⬜️ 使用从你的错误分析中得出的自定义评估器，而不是通用的现成指标

运行与迭代

⬜️ 区分离线、在线和临时评估并使用所有三种 ⬜️ 每个任务运行多次试验以考虑非确定性 ⬜️ 手动审查失败评估的追踪以验证评分器公平性 ⬜️ 确保每次试验在干净、隔离的环境中运行，没有共享状态 ⬜️ 按能力类别标记评估，记录每个测量的内容，并跟踪效率指标（步数、工具调用、延迟）以及质量 ⬜️ 识别通过率何时趋于平稳并相应发展你的测试套件 ⬜️ 只保留直接测量你关心的生产行为的评估 ⬜️ 投资于工具界面设计和测试，而不仅仅是提示优化 ⬜️ 区分任务失败（智能体弄错了）和评估失败（评分器弄错了）

生产就绪

⬜️ 将具有持续高通过率的能力评估推广到你的回归套件中 ⬜️ 将回归评估集成到你的 CI/CD 管道中，并带有自动化质量门 ⬜️ 捕获用户反馈 ⬜️ 为生产流量设置在线评估 ⬜️ 安排定期手动探索超出自动检查的生产追踪 ⬜️ 与代码一起版本化你的提示和工具定义 ⬜️ 确保生产失败反馈到数据集、错误分析和评估改进中

进一步阅读

LangChain：

• 《智能体可观测性驱动智能体评估》——本清单的概念配套
• 《在你的智能体投入生产之前，你不知道它会做什么》
• 《评估技能》
• 《我们如何为深度智能体构建评估》

Witan Labs：

• 研究日志：构建 LLM 驱动的电子表格智能体

外部基准（用于获取评估任务）：

• Terminal Bench 2.0
• BFCL（伯克利函数调用排行榜）

Anthropic：

• 揭秘 AI 智能体评估
• 构建有效智能体

OpenAI：

• 使用评估系统地测试智能体技能

Hamel Husain：

• LLM 评估：你需要知道的一切

arXiv 论文：

• 智能体作为裁判：用智能体评估智能体
• LLM 作为裁判综述
• 裁判可靠性工具

LangSmith 文档：

• 可观测性概念
• 评估快速入门
• 管理数据集
• LLM 作为裁判设置
• 少样本评估器
• 成对评估
• 用人类反馈对齐评估器
• 在线评估
• CI/CD 管道示例
• 注释队列
• Polly（追踪分析智能体）
• LangChain 技能
• LangSmith CLI

相关内容

可观测性与评估

IssueBench——我们如何评估 Engine

Nick Bray Arjun Nargolwala 2026年7月20日 6 分钟 概念指南 LangSmith

构建受治理的智能体：成本、控制和合规框架

Martha Janicki 2026年7月20日 15 分钟 概念指南 LangSmith

智能体需要自己的计算机。以下是如何安全地给它们一台。

Amy Ru 2026年7月15日 12 分钟 注册我们的新闻通讯以保持最新 谢谢！你的提交已收到！ 哎呀！提交表单时出了问题。

看看你的智能体到底在做什么

LangSmith，我们的智能体工程平台，帮助开发者调试每个智能体决策、评估更改，并一键部署。 尝试 LangSmith 获取演示