智能体跑得好好的半夜突然收到一条告警邮件说某个 trace 的失败率在五分钟内飙升到了 30%。打开面板一看确实是某个工具调用超时了但等你切到日志详情问题又自己恢复了。这种场景搞过 LangChain 智能体上线的兄弟应该都不陌生。我们搭建智能体应用时往往把大部分精力花在 prompt 调优、工具定义、记忆策略上却容易忽略一件事上线之后怎么第一时间知道它“变坏了”。传统监控只盯着 CPU、内存、磁盘但 LangChain 智能体这种多步骤、带模型调用的应用真正的故障点经常藏在一次成功的 status code 背后。这也是 LangSmith 告警功能存在的意义。这篇文章就围绕 LangSmith 里的告警配置展开讲清楚告警类型有哪些、阈值怎么定、告警风暴怎么降噪、以及遇到“明明问题已经解决了告警却还挂着”这类情况该怎么办。内容偏向实操适合已经用 LangChain 跑过几个 Agent 项目、准备做线上治理的开发者。无论你用的是 LangChain、Dify 还是 CrewAI只要你最终要面对生产环境的 LLM 应用告警这套思路都绕不开。1. 为什么要在 LangSmith 里专门配告警先说一个核心认知LangChain 智能体和传统后端服务在“故障表现”上差别非常大。传统接口出错状态码、堆栈、日志链路都是相对确定的东西阿里云监控、zabbix 这类工具完全可以覆盖。但智能体不一样它一个请求内部可能经历模型推理、工具检索、代码执行、再次推理等多个环节任何一个环节异常最后反映到用户侧的只是一句“对不起我无法完成你的请求”。如果没有 trace 层面的监控你根本没法快速定位到底哪一步出了问题。1.1 智能体开发和传统应用告警的本质区别传统应用里请求路径基本是固定的。用户调一个接口你查数据库做业务逻辑返回结果。延迟和失败率即使有波动也在一个相对可预测的范围内所以像 zabbix 这种以主机指标为核心的监控体系非常有效CPU 高了、磁盘满了、接口响应慢了告警一触发基本就能锁定方向。智能体应用不是这样。同一个问题模型今天的回答路径和昨天可能完全不同。今天它选择调用搜索工具明天它可能直接从上下文里就找到了答案。这种非确定性带来一个很头疼的问题错误不一定以“代码异常”的形式出现。比如模型输出格式突然变了导致后续的 JSON 解析失败比如某次工具返回的内容特别长token 消耗翻倍再比如模型的单次推理时间从 2 秒涨到 8 秒但接口仍然是 200 状态码从 HTTP 层面看一切正常。这些故障传统告警根本看不见。它们不在主机指标里也不在状态码里只存在于 trace 数据中。LangSmith 的告警之所以有用就是因为它直接建立在 trace 和 span 之上监控的是智能体真正的工作过程而不是外围的机器健康状况。1.2 LangSmith 告警真正解决的三个问题第一个问题叫“用户比你更早知道系统坏了”。很多智能体应用刚上线时流量小问题出现未必有人立刻反馈。等你在群里看到用户截图说“机器人开始瞎回答了”往往已经过去了几个小时。LangSmith 告警可以在误差率、延迟、成本这些指标发生异常时主动通知你让你比用户先一步发现问题。第二个问题是“省掉盯盘的人工成本”。我见过不少团队早期没配告警就靠一个人每天刷几次 LangSmith 面板看错误列表、看耗时曲线。这个做法短期可行长期不可持续。告警规则的本质是把“需要持续关注”变成“只在异常时打扰你”。第三个问题是给“我觉得它没问题”提供一个客观判断依据。智能体应用有一种隐蔽性你测试几个 case 都正常就以为全量正常。但模型供应商的波动、prompt 里隐藏的不稳定因素、外部工具接口的偶发故障这些都可能导致某些时段成功率骤降。没有告警指标你只能凭感觉决策有了告警你是拿数据说话。2. 认识 LangSmith 告警的类型与核心配置参数LangSmith 的告警功能我理解下来就是四类指标加一组过滤条件。别一上来就乱配先搞清楚每种告警适合防什么问题再看参数。2.1 五类常用的告警规则按监控指标划分告警大致可以分成下面几类告警类型监控指标适合发现的问题典型配置建议Error rate 告警trace 中 error 数量 / 总 trace 数模型解析失败、工具调用异常、整体不可用窗口 15 分钟阈值 10%最小样本数 20Latency 告警trace 或 span 的平均耗时 / p95 耗时模型推理变慢、工具响应超时、链路串行过长窗口 1 小时阈值取历史 p95 的 1.5 倍Token usage 告警每次 trace 的平均 token 数 / 总 token 数prompt 意外膨胀、输出变长、上下文不断累积窗口 24 小时阈值取历史均值的 1.3 倍左右Cost 告警估算费用 / 项目消耗成本失控、模型被误用为高配版本窗口 24 小时设置美元或人民币阈值自定义过滤告警结合 tag / metadata 过滤后的指标某个特定业务线、某个模型、某个工具的错误率按业务需求配置 filter这里要特别说明一下 Error rate。LangSmith 默认会把 trace 中出现 error 状态的 span 认定为错误。但如果你用很多第三方模型或工具错误不一定都会正确标记到 trace 的 status 上。更严谨的做法是给项目配置一个 run evaluator把“语义不合格”也转化成可量化的指标比如回答包含“抱歉我不能”这类拒答模板或者回答长度异常。这种自定义 evaluator 的结果同样可以作为告警的数据来源。2.2 四个关键参数的含义与选择逻辑不管是哪类告警配置的时候都绕不开四个参数时间窗口、阈值、最小样本数和通知渠道。很多新手一上来只改阈值其他全用默认这是后面告警不准的根本原因。时间窗口Time window。这个参数决定 LLM 统计数据的时间跨度。窗口越短对突发问题越敏感但误报率也越高窗口越长数据越平滑但发现问题越慢。我的建议是错误率和延迟用 15 分钟到 1 小时的短窗口成本和 token 用 24 小时的长窗口。因为成本和 token 看的是趋势不是瞬时波动短窗口只会让你的手机半夜响个不停。阈值Threshold。这是容易被拍脑袋填的数字。正确做法是先看项目跑了一到两周后的数据分布取一个“正常情况下基本不会突破一旦突破就真的有问题”的值。比如某个项目的平均错误率 5%偶尔波动到 8%那么阈值定在 10% 到 15% 之间比较合理。如果定在 5.1%那你不是在配置告警是在配置骚扰。最小样本数Minimum occurrences。这是一个被很多人忽略但极其重要的防误报参数。它的含义是窗口内至少要产生多少条 trace才参与告警判断。假设你设置窗口 5 分钟、阈值 50%如果窗口内只有 2 条 trace 且其中 1 条失败错误率就是 50%告警直接触发。一个测试流量或者个位数请求就能触发告警你会被折磨疯的。所以生产环境里窗口 15 分钟至少要求 10 到 20 条 trace低于这个数量级就不判断。Cooldown period。有的版本里叫冷却时间意思是告警触发后多少分钟内不重复通知。这个参数直接关系到告警风暴。比如同样一个故障持续半小时如果没有冷却时间每 5 分钟窗口滚动一次就发一条通知你一分钟内能收到 6 封一样的邮件。把冷却时间设为 15 分钟或 30 分钟可以有效减少重复轰炸。提示参数之间是联动的。窗口改短了阈值就要适当调高样本数要求高了窗口就要适当拉长。不然要么告警满天飞要么永远不触发。2.3 LangSmith 告警和 zabbix 告警的逻辑差异我之前的工作流里服务器侧用的是 zabbix跑的都是 CPU 使用率、内存剩余量、磁盘 I/O 这类硬件指标。zabbix 的告警非常典型一个触发器绑定一个监控项条件满足就进入“异常”状态恢复条件满足后自动变成“OK”。很多人知道 zabbix 显示“主机问题已解决”之后告警会自动消失这套模型是持续状态模型。LangSmith 告警不一样它更像滚动窗口模型。告警判断的不是“此刻是否异常”而是“过去 N 分钟窗口内的统计值是否超过阈值”。这意味着即使当前请求已经全部正常只要窗口内的高错误率数据还没滑出窗口告警就会继续显示为触发中。想等它自动恢复需要等到窗口完整滚过去并且新的窗口内指标回落到阈值以下。理解这个区别非常重要否则你会碰到一个经典困惑“我看了 LangSmith当前错误率已经降到 2% 了为什么告警还挂着”答案就是窗口还在统计旧数据这不是 Bug是模型设计如此。3. 实际操作配置一条合格的告警规则光讲概念没用直接上手看配置流程。我以 Error rate 告警为例详细走一遍从进入到配置完成的完整操作。3.1 前置条件和入口说明配置 LangSmith 告警账号上要有对应的项目Project并且项目里已经积累了至少一些 trace 数据。如果你连一条 trace 都没有即使配置了告警也不会有任何判断依据。此外告警功能对账号类型有要求免费版能不能用取决于官方当前的政策如果你的账号里找不到 Monitoring 或 Alerts 入口大概率是权限不足升级对应套餐才能解锁。登录 LangSmith 后左侧导航栏找到 Monitoring 或 Alerts 入口不同版本的入口位置会有点区别但逻辑是一样的。有些版本把告警放在每个 Project 详情页的 Alerts 标签下有些版本则是在全局监控维度统一管理。建议用全局的 Monitoring 入口看所有项目的告警这样不会漏。3.2 创建 Error Rate 告警的完整步骤操作环境LangSmith 网页控制台 前置条件拥有项目且已有 trace 数据、账号开通告警权限按下面步骤走进入Monitoring页面的Alerts标签点击Create Alert创建告警。选定监控对象在Project下拉框里选择你要监控的 LangChain 项目。这里注意一个项目对应一组告警规则不同项目业务差异大时不要混在一起配。选择告警类型在 Metric 处选择Error Rate。设置统计维度可以按全部 trace 统计也可以按特定模型、特定 tag 过滤。如果你在 trace 上打了业务维度标签比如 region、user_type这里就可以只监控某一个维度的错误率。填写关键参数时间窗口15 minutes错误率阈值10%最小样本数20。配置通知方式选择邮件、Slack 或 Webhook。我推荐配置 Webhook方便接入自建通知中心。创建测试告警如果系统支持 Test 功能先发一条测试通知确认能收到再保存。这套流程走下来一条最基础的错误率告警就生效了。后续每隔一段时间建议回到这个页面根据真实的错误率分布去修正阈值和窗口。3.3 阈值怎么定才不拍脑袋我见过不少人配告警时阈值填 0.01% 或者 99%完全凭感觉。说实话这种阈值配置之后基本不会产生有效告警。比较靠谱的做法分三步。第一步拉数据。在 LangSmith 的 traces 页面按时间筛选比如最近 7 天看目标指标的总量、平均值、P95 和最大值。注意不要只在流量低谷期拉数据要覆盖业务高峰和高峰后回落的过程。第二步定基线。例如某个客服问答 Agent最近一周平均错误率 2%峰值出现在每天早上 9 点首次请求涌入时大概是 5%。那么基线就是 2%峰值基线是 5%。阈值至少应该设在峰值之上比如 8% 到 10%。因为告警的意义是发现异常而不是报告每一个微小波动。第三步设样本。如果业务本身流量就小比如一天只有几百条 trace你设最小样本数 20、窗口 5 分钟很可能一天只判定一次。这种情况下建议把窗口拉长到 1 小时样本数设成 5 到 10确保告警有一定代表性。有一点要提醒LangSmith 的“错误率”默认统计的是所有发生 error 的 trace 数量除以总 trace 数量。你的业务里如果存在“用户主动中断”或者“你怎么答都不满意”这种非异常路径需要把它们从 error 统计里排除掉否则错误率会虚高。3.4 Webhook 通知跟自己的运维体系打通如果你的团队已经有企业微信、钉钉或者自建告警平台那 LangSmith 的邮件通知肯定不够用。建议走 Webhook。LangSmith 在告警触发时会向配置的 Webhook 地址发送一个 JSON payload里面包含了项目名、告警类型、指标值、触发时间、trace 链接等关键信息。{ alert_name: 客服项目 Error Rate 过高, project: customer-service-agent, metric: error_rate, value: 0.12, threshold: 0.1, window_minutes: 15, status: firing, trace_url: https://smith.langchain.com/..., triggered_at: 2025-01-03T10:15:00Z }拿到这个 payload 之后你可以在自建机器人里做关键词匹配、消息去重、值班人艾特等逻辑。这里多说一句Webhook 是最适合接告警中心的方式因为它保留了最大的灵活性。如果你只是想在电脑上收个弹窗先用邮件就够了。4. 告警降噪把告警从“打扰”变成“信号”告警配置好之后大多数人遇到的第一个问题不是“没收到告警”而是“告警太多了”。这其实是个好事说明你的链路里确实存在需要关注的东西但也说明降噪工作没做到位。4.1 告警风暴是怎么来的告警风暴的原因通常有三个。第一个是阈值设置过低把正常的业务波动也算成了“异常”。第二个是窗口太短导致每 5 分钟就判定一次配合没有冷却时间同一个故障能发十条通知。第三个是规则之间没有做分级error rate 告警、latency 告警、token 告警同时触发本该是一条“模型供应商波动导致整体异常”的消息结果变成了十条互相独立的消息。更深层的原因是很多人把告警当成了“日志工具”希望把所有可疑情况都报出来。但告警的本质是“需要你处理的异常”不是“需要注意的现象”。你不需要对每一次 token 波动都收到提示你只应该收到“这个东西正在导致业务受损请你来处理”的信号。要解决风暴第一步不是增加规则而是收缩规则。先把自己手上的 alert 规则按重要程度排个序只留那些真正影响用户体验或成本的。4.2 告警手动消除和确认的正确姿势回到开头提到的场景“主机问题已经解决但告警还在。”实际上在 LangSmith 里告警并没有提供像 zabbix 那样的“手动消除”按钮。你只能做两件事第一件事是Acknowledge确认。这个动作表示“我已经看到告警了正在处理中”。确认之后如果系统支持它会停止向同一批接收人重复发送这个告警的通知。请注意确认不是关闭确认之后如果你不做修复指标仍然异常下一个窗口依然会触发新的告警。第二件事是等待窗口滚动。因为 LangSmith 判断的是滚动窗口只有当异常数据完全滑出窗口且新窗口内指标恢复正常告警状态才会从 Firing 变成 Resolved。这不是故障是模型特性。所以正确的处理顺序是收到告警 → 打开 trace 详情定位根因 → 修复或等待外部依赖恢复 → 在 LangSmith 里 Acknowledge 这条告警并备注处理结果 → 观察它是否在下一个窗口周期内转为 Resolved。如果它在 Resolved 之后又重新触发说明修复不彻底需要继续排查。注意不要因为嫌吵就把 Acknowledge 当成“堵住嘴巴”的工具。每次确认都应该留下备注。不然团队里其他人看到已确认的告警根本不知道你做了什么事。4.3 降噪三板斧分级、聚合、冷却我在团队里推行过一套降噪方案核心就是三件事。分级。把告警分成 P1、P2、P3 三个级别。P1 是直接影响用户使用的比如错误率超过 20%、项目整体不可用这类告警必须立刻通知到值班人可以通过短信、电话等级别最高的渠道。P2 是潜在风险比如 P95 延迟超过 10 秒、单日成本超过预设值这类发到工作群即可。P3 是趋势类比如 token 用量连续三天缓慢增长这类进告警日报不需要实时打扰。聚合。当多个告警指向同一个根因时尽量让它们在接收端聚合为一条消息。比如模型供应商的 API 波动会导致 error rate、latency、cost 三条规则都触发。你可以选择只配置 error rate 的实时通知其他规则写进日报或者在自建告警中心里按 project 和触发时间做去重只保留第一条。冷却。利用 Cooldown period 或接收端去重避免同一规则在短时间内反复发送。冷却时间本身不解决问题但它能给你喘息的时间去排查而不是每 5 分钟被打断一次。我自己比较喜欢的做法是给每个项目配两条“必配告警”加 N 条“可选告警”。必配的是错误率和成本可选的是延迟和 token 用量。成本告警在 LLM 应用里非常重要因为模型推理费用是实打实的钱不设成本告警一次 prompt 配置失误就可能烧掉几天的预算。5. 常见问题与排查技巧实录配置和使用过程中一定会踩坑。下面按高频程度整理几个问题都是我或团队同事真实遇到过的。5.1 为什么完全没收到告警排查顺序从下往上确认项目里有 trace 数据且有 error 状态的数据确认你的阈值设置没有高到永远不会触发确认最小样本数没有设置得太大确认通知渠道配置正确尤其是 Webhook 的地址是否可达。还有一个隐蔽原因有的告警面板会默认只监控未来开始的数据也就是说你配置完成之前产生的历史数据不会被纳入判断。这种情况下需要等窗口滚动起来过 15 分钟再检查。5.2 告警一直处于 Firing 状态哪怕当前指标已经正常这是前面提到的滚动窗口模型造成的。检查思路是打开告警详情看它计算的是哪个时间范围再对照这个范围内的 trace 原始数据。你会发现虽然当前时刻已经恢复正常但几分钟前的高错误率 trace 仍在窗口内统计结果自然还是高的。耐心的做法是等一个完整窗口周期比如你设的是 15 分钟窗口就等 15 分钟后再看。如果超过两个周期还挂着再检查阈值和指标口径是否变过。5.3 阈值设了但像没设一样告警频繁误报最优先检查最小样本数。如果你的一个测试账号偶尔发起一次请求失败也可能触发比例为 100% 的告警。把最小样本数提高以后个位数请求造成的“假错误率”就会被过滤掉。其次检查阈值相对基线是否有余量。如果历史错误率本身就是 8%你设阈值 8%那它一天触发几次完全正常。最后检查过滤条件有没有不小心把某些本来应该排除的测试 trace 或者人工测试项目也纳入了统计。现象常见原因处理办法收不到告警通知渠道失效 / 最小样本数过高 / 阈值过高测试通知降低样本数要求重新核算阈值告警频繁触发阈值贴近基线 / 窗口太短 / 包含测试流量拉长窗口提高阈值用 tag 过滤掉测试 trace告警一直 Firing滚动窗口未滑出 / 修复未生效等待一个完整窗口检查最新窗口内指标告警太吵没有冷却时间 / 多个规则同时触发配置冷却时间走 Webhook 做去重聚合不知道告警对应哪次调用通知内容里缺少 trace 链接Webhook 解析 payload带上 trace_url 到自建通知5.4 告警里看不到期望的自定义指标LangSmith 自带五类基础指标但如果想监控“回答为空的比例”“拒答率”这类语义层面的东西需要在项目里配置 run evaluator。这个逻辑可以理解成先让 evaluator 判断每条 trace 是否属于“不合格回答”再基于 evaluator 的结果配置告警。很多人走到这一步才发现 LangSmith 真正的门槛不是告警配置而是想清楚“什么叫你的业务异常”。建议先从错误率和延迟这类硬指标开始等跑通了再扩展自定义指标。6. 我的实践心得与建议关于 LangSmith 告警我最后想分享几条实操层面的体会。第一告警规则不是一次配完就一劳永逸的。每次你改 prompt、换模型、调整工具链都要重新审视一遍已有的阈值。否则系统行为已经变了你的告警规则还在按旧基线运作结果是该响的不响不该响的乱响。我把这个事写进了团队的发布 checklist每次版本更新必须检查告警配置是否仍适用。第二先保底再优化。任何新项目上线我的习惯是只配两条规则一条错误率阈值告警一条成本上限告警。这两条能兜住大多数风险。等项目跑了两周积累了真实数据再补充延迟和 token 用量的趋势类告警。一条条加每加一条都确认它能在真实故障场景中产生有效信号而不是制造噪音。第三告警的价值在于能和别人协作。所以通知文案、payload、备注信息的可读性非常重要。你自己能看懂的告警不代表值班的人能看懂。在 Webhook 通知里尽量带清楚项目名、指标值、阈值和 trace 链接这条规则值得刻在墙上。LangSmith 的告警功能只是智能体可观测体系的一半另一半是你怎么面对这些告警做响应。把告警规则当成项目代码一样去 review 和维护生产环境的智能体才能跑得让人放心。