可观测性与事件响应

智能体系统可以返回格式完全正确的 HTTP 响应，却没有完成用户的任务。它也可能成功调用了每一个接口，却改错记录、泄露不该披露的数据、在没有进展的情况下反复循环，或者在确认外部影响之前就停止运行。传统服务遥测仍然不可或缺，但仅凭它无法说明系统是否使用了恰当的权限、是否采用了可信的上下文，以及是否真正产生了预期结果。

本章把生产环境中的证据与运维响应联系起来。它不会重新讲解其他章节已经负责的运行状态机、评估方法、重试语义、安全控制或发布流程，而是集中回答一个更具体的问题：

当生产系统出现异常行为时，负责团队能否确定用户实际经历了什么、还原关键执行路径和外部影响、阻止影响继续扩大，并获得足以避免问题再次发生或更早发现问题的认识？

核心观点

只有当遥测数据、状态记录和结果证据能够解释与任务有关的系统行为，并支持有边界的运维决策时，智能体系统才真正具备可观测性（observability）。事件响应必须与系统的权限和控制点一起设计，而不能等到造成影响后再临时拼凑。

收集更多数据并不等于系统更加可观测。有效的设计应先明确团队必须回答哪些问题、响应人员能够实际操作哪些控制手段，再在隐私、安全、成本和保留期限的约束下，记录能够回答这些问题的最小证据集合。

从遥测数据到证据模型

生产环境中的证据由几种相互补充的形式组成：

证据	最适合回答的问题	单独使用时无法证明什么
指标（Metrics）	某件事发生了多少次、规模多大，以及汇总趋势是否变化	某一次运行为什么如此，也不能证明某个具体外部影响是否发生
事件和日志	记录了哪个离散事实、决策、错误或状态转换	如果记录之间没有关联关系，就无法还原完整因果路径
追踪记录和 Span	哪些操作构成同一条执行路径、它们的父子关系、耗时和状态	流畅的输出或技术上成功的调用是否真正满足任务要求
权威状态与外部影响记录	事实来源系统当前接受什么为真，哪些外部变更已经提交	如果没有关联决策记录，就无法说明系统为什么选择这条路径
结果证据	指定的成功条件、策略要求和用户影响条件是否满足	故障的全部内部原因
抽样保存的材料	专家诊断所需的语义细节，例如选定的输入、输出或检索片段	整体发生频率；其中还可能包含敏感信息并受到抽样偏差影响

OpenTelemetry 为追踪记录、指标、日志和事件规定了通用名称与属性；W3C Trace Context 则定义了在服务间传递追踪标识的可互操作 HTTP Header（OpenTelemetry Semantic Conventions；W3C Trace Context）。这些标准解决了重要的传输与关联问题，却不会替应用定义产品是否成功、系统拥有什么权限，或智能体事件应达到怎样的严重程度。

每种证据都应各司其职。不要把追踪系统变成对话全文仓库，也不要把指标标签集合当作没有边界的数据库。用户、任务、运行等高基数标识通常更适合写入日志或追踪记录，而不是作为全局指标的维度；只有监控后端的能力和明确查询需求能够证明其成本合理时，才应例外处理。

建立贯穿全程的关联主线

响应人员应当能够从用户报告或告警出发，找到对应的运行、操作、外部影响、配置和结果，而不必在彼此无关的数据存储中按时间戳猜测。

系统至少应根据产品需要建立下列标识之间的关系：

用户可见的请求或任务
  -> 对话或业务事项
  -> 运行与追踪记录
  -> 步骤、Span、模型调用、接口操作、审批与子运行
  -> 外部影响或产物
  -> 验证器结果、用户纠正、事件与评估案例

并非每个系统都需要这里列出的全部标识，也不应强迫一个标识同时代表所有概念。一次对话可以包含多次运行，一次运行可以产生多个外部影响，异步外部影响还可能在发起它的追踪记录结束后继续存在。系统需要显式保留这些关系。

例如，OpenAI Agents SDK 把端到端工作流表示为包含模型、函数、防护栏和移交 Span 的 Trace，并提供 Group ID 来关联相关 Trace（OpenAI Agents SDK tracing）。Anthropic Claude Code 的遥测则使用 Prompt ID 关联由同一条用户提示触发的 API 和 Tool 事件，并用 Tool Use ID 连接决策、执行与结果（Anthropic Claude Code monitoring）。这些都是值得参考的实现示例，不是所有系统都必须采用的字段名称。

关联标识应当是不透明的、足以避免碰撞的，并且用途范围明确。不要把电子邮箱、原始提示词、租户密钥或其他个人信息放进 Trace ID。还要把外部传入的 Trace Context 当作不可信元数据：它可能格式错误，也可能由攻击者刻意构造，绝不能因为它携带某个标识就允许访问另一租户的证据。

记录决策和实际影响，而不是模型的私有推理

运行记录应当能够解释发生了什么，但不应声称自己掌握模型私有的思维链。对于每一次重要转换，结构化记录至少应足以回答：

• 当时生效的目标、任务状态和配置是什么？
• 使用了哪个模型、提示词或指令版本、上下文清单、策略和路由决策？
• 系统提出了什么操作或生命周期转换？
• 执行了哪些结构、权限、审批、预算和策略检查，各自得出什么结论？
• 哪个身份针对哪个资源和状态版本发起了什么操作？
• 系统观察到怎样的结果、错误类别、延迟、Token 用量、成本、重试次数和供应商请求标识？
• 外部影响处于已确认、被拒绝、部分完成还是结果未知的状态？
• 哪个验证器接受或拒绝了进展与完成结论？
• 后续哪些用户纠正、申诉或下游信号改变了对这次运行的判断？

并非一定要记录完整模型提示词和接口参数。很多情况下，内容哈希、受保护材料的引用、脱敏字段集合或经过允许的摘录，既能提供足够的可复现性，又能减少暴露。模型生成的理由可以帮助用户或审阅者理解系统决定，但它不是隐藏计算过程的忠实日志，不能作为权威证据。

“架构”部分已经定义权威状态、执行边界、审批和运行转换分别意味着什么。本章负责把这些概念对应的标识与决策放在同一条证据链中，使团队能够还原生产行为。

观察完整系统，而不只是模型调用

模型延迟和 Token 数量有用，但视野太窄。生产观测应覆盖真正决定结果的整条路径：

1. 需求与任务：入口、受支持的任务类型、用户或租户分组、后果等级和预先声明的成功条件。
2. 配置：应用、模型、供应商、提示词、上下文策略、路由、接口、评估器、功能开关和部署版本。
3. 上下文组装：选用了哪些来源、来源与流转记录及信任标记、内容时效、排除项、压缩过程、规模和访问决策；默认不复制全部源内容。
4. 控制回路：状态转换、决策、校验、进展信号、预算、重复步骤、等待、取消和终止原因。
5. 能力与权限：请求的操作、执行身份、权限与审批决定、策略版本、执行边界结果和已经提交的外部影响。
6. 依赖项：模型与接口请求、队列、检索、存储、网络、限流、超时、重试和备用路径。
7. 结果：验证器证据、外部状态核对、用户可见结果、纠正、放弃、升级处理和后续下游影响。

由此可以得到一个重要区别：

协议成功只能证明某项操作的技术结果；任务成功需要证明预期结果已经实现。

HTTP 200、模型的 end_turn 或标记为成功的 Tool 返回值，可能是执行路径的必要条件，却都不能作为通用的任务成功标准。反过来，模型拒绝请求或策略阻止操作也不一定构成事件；它可能恰好说明系统按设计工作。告警应首先针对用户可见的异常和被违反的运行承诺，再用内部信号进行诊断。

从运行承诺中选择生产信号

信号设计应从系统对用户作出的承诺和可能造成的不可接受后果出发。值得关注的信号类型包括：

• 已验证的任务完成、不完整与无法确定的结果、用户纠正、任务放弃和升级处理；
• 已确认、被拒绝、部分完成、重复发生和结果未知的外部影响；
• 策略拒绝、审批请求、绕过审批的尝试，以及超出预期权限范围的操作；
• 没有进展的循环、重复操作、预算耗尽、递归深度和取消操作所需时间；
• 模型、检索、接口、队列和状态存储的错误、饱和、延迟与备用路径使用情况；
• 每个已完成或失败任务消耗的成本、Token、步骤、接口调用和总耗时；
• 按配置、模型、供应商、路由、上下文来源、用户、语言、地域、租户和后果等级划分的数据；
• 遥测系统自身的健康状态，包括导出失败、Span 丢失、抽样策略变化、时钟偏差、Schema 违规和关联关系缺失。

比率必须有含义明确的分母。40 次尝试中出现 30 个结果未知的外部影响，与 4,000 万次尝试中出现 30 个完全不是一回事。“每次请求的平均成本”也可能只是因为更多任务提前失败而下降；“每个已验证结果的成本”以及质量与成本的联合分布更能揭示真实变化。

不要把带有不确定性的语义信号标记成确定事实。如果使用模型分类器监控生产行为，就应记录它所用的模型、提示词、评分标准、阈值、校准证据和拒绝判断机制。只有在已经测量的误差范围内，才能用它排序或汇总问题；涉及重要后果时，还应使用更可靠的证据进行确认。

分层发现异常

面对可能变化且开放式的系统行为，单一检测器无法覆盖全部情况。应组合各有所长的几层机制：

1. 确定性约束检查：发现 Schema 违规、非法状态转换、缺少审批、外部影响标识重复、预算违规和已知危险模式。
2. 结果和服务等级信号：发现用户可见失败、过高延迟、任务放弃或可靠性目标被突破。
3. 基线与细分监控：按模型、路由、语言、租户、任务或版本发现显著变化，避免问题被全局平均值掩盖。
4. 由评估体系衍生的监控：在生产人群和隐私政策允许的条件下，把经过验证的评估标准用于生产样本。
5. 专家抽查：发现自动检查尚不能表达的语义问题。
6. 用户与合作方报告：发现运行时无法获知的延迟影响、上下文问题或下游结果。

Google SRE 的事件管理资料建议告警及时、可行动并围绕用户可见症状，同时也保留应对硬性配额即将耗尽等情况的预防性告警（Google SRE Incident Management Guide）。对智能体系统而言，“已验证完成率低于目标”通常比“模型使用了五次 Tool”更适合触发值班响应。后者仍可以作为诊断信息；如果它能够预测成本失控，也可以成为预防性信号。

每条需要立即响应的告警都应明确负责人、用户影响或风险条件、严重程度判断规则、初始证据和经过演练的响应步骤。没有决策和负责人的 Dashboard 只能提供态势信息，并不等同于事件响应。响应人员习惯性忽略的告警本身就是监控缺陷。

根据影响和协调需要定义事件

当异常已经造成影响，或有可信证据表明它可能造成影响，并且需要超出普通请求处理范围的协同行动时，就应将其视为事件（incident）。常见类别包括：

• 结果存在重大错误、危害、歧视或误导；
• 外部影响未经授权、并非预期、重复发生、不可逆转或结果未知；
• 违反隐私、保密、数据驻留或保留要求；
• 权威状态、记忆、上下文来源或评估记录受到破坏；
• 循环失控、支出异常、容量耗尽或依赖项连锁故障；
• 模型、供应商、策略、提示词、接口或数据变更后出现意外行为；
• 安全系统被攻破、提示词注入造成实际影响、凭据遭到滥用或遥测数据被篡改；
• 监控或评估器失效，导致团队无法继续确信系统能够安全运行。

严重程度应根据用户伤害、影响范围、是否仍在扩散、持续时间、可逆性、已经动用的权限、数据敏感程度、法律义务，以及外部影响存在多少不确定性来判断。不要根据模型置信度、日志异常条数或根因听起来是否“具有 AI 特点”来判断。一次已经确认的未授权转账，可能比数千次无害的拒绝严重得多。

安全事件还可能触发专门的法律、取证和通知义务。NIST SP 800-61 Rev. 3 把事件响应贯穿于准备、发现、响应、恢复和更广泛的网络安全风险管理之中（NIST, 2025）。本章把这一生命周期扩展用于更广泛的智能体生产故障，但它不能替代特定司法管辖区的安全、隐私、安全生产、劳动或行业规定。

在事件发生前准备控制手段

响应人员无法通过 Dashboard 遏制系统。以下控制手段需要提前设计、授权、记录并演练：

• 停止接受新的运行，同时保留证据导出和安全清理能力；
• 禁用某项具有重要后果的能力，或把它切换为只给建议、不执行，或者只读模式；
• 隔离某个租户、用户群、任务类型、地域、模型、供应商、路由或配置；
• 撤销或收窄凭据与审批授权；
• 降低步骤、Token、成本、并发和外部影响预算；
• 固定或恢复到已知配置，并切换到能力边界明确的备用方案；
• 暂停、取消或隔离运行，同时保留能够继续执行的状态；
• 隔离可疑的上下文来源、记忆记录、输出和评估案例；
• 通过外部事实来源系统核对并补偿已经提交的外部影响。

全局停止开关可以减少即时伤害，却也可能中断关键工作、破坏运行中证据或造成状态不一致。因此应优先提供作用范围明确、状态转换语义清晰的控制手段，并在演练和分阶段环境中验证它们。第一次在真实事件中尝试的应急控制只是一项未经证明的假设。

“可靠性、恢复与持久执行”一章将负责幂等、检查点、补偿和持久恢复机制；“测试、变更与发布”一章将负责上线与回滚的具体做法。本章负责判断应调用哪个控制手段、在执行控制时保留证据，并确认遏制操作确实改变了真实影响。

按纪律执行事件响应

一套实用的响应过程包括：

1. 初步判断并宣布事件

核实信号，但不必等到所有事实都确定才行动。创建事件记录，指定严重程度，明确事件负责人或承担同等协调职责的人，并指定技术处置与沟通负责人。分别记录当前已知、未知、假设和仍在变化的内容。

2. 保护用户并阻止影响扩大

先限制进一步影响，再证明根因。停止或收窄高风险操作，保护凭据和数据，隔离受影响的配置或人群，并建立安全的备用路径。应通过结果与状态证据确认遏制是否生效，而不是只看配置命令是否执行成功。

3. 保存证据

保护时间线、已关联的 Trace 与事件引用、配置版本、策略与审批决定、模型与供应商标识、状态快照、外部影响记录、用户报告和响应人员操作。涉及法律或取证用途时，应限制访问并保留证据流转记录。不要在保存之前用“清理”操作毁掉唯一证据。

4. 确定范围并诊断

确定受影响的用户、任务、租户、数据、外部影响、版本、时间范围和剩余风险。比较配置变更与正常运行的数据分组，检查状态转换与依赖项行为，只在安全环境中复现问题。区分触发因素、促成条件、失效的控制措施和根本原因。

5. 恢复并核对结果

在加强监控的条件下逐步恢复服务。确认权威状态，修复或补偿外部影响，重新处理可以安全重做的工作，向相关方说明仍存在的不确定性，并验证用户最终得到的结果。如果错误记录或尚未履行的义务仍然存在，“智能体已经重新响应”就不算恢复完成。

6. 沟通

以适合不同受众的方式，定期更新影响、范围、缓解措施、可用替代方案和不确定性。由获得授权的负责人协调内部、客户、合作方、供应商、监管机构和公共沟通。保存时间与决策记录，在事件仍在处理中时避免把未经证实的根因写成事实。

7. 学习并闭合改进回路

完成基于事实、避免归罪个人的事后审查，说明影响、发现方式、时间线、响应过程、原因、促成条件、哪些控制有效或失效，以及团队在哪些地方只是幸运。把预防、检测、缓解和流程改进转化为具体行动，明确负责人、优先级、期限和验收方法。把有代表性的故障加入评估套件和生产监控，但不要不加选择地复制敏感事件数据。

Google SRE 的资料把响应中的协调、沟通和控制分开，并强调只有后续改进行动得到跟踪，事后复盘才会产生价值（Incident Management Guide；Postmortem Culture）。避免归罪个人的目的，是让事实更充分暴露并推动系统改进；它并不取消决策责任、专业义务，也不为明知故犯的策略违规开脱。

保护可观测性系统本身

遥测数据可能是产品中最敏感的数据集合之一。模型输入、检索文档、接口参数、输出、文件路径、标识和错误信息，都可能包含个人数据、密钥、专有内容或攻击载荷。

应落实：

• 明确收集目的并遵循数据最小化原则；
• 在导出前执行字段白名单、脱敏、标记化，或只保留受保护材料的引用；
• 单独控制内容采集，不能假定用户同意采集元数据就等于同意采集完整内容；
• 租户隔离、最小权限访问、加密、访问审计和导出限制；
• 根据诊断、合同与法律需要制定保留和删除规则；
• 既能保留少见但后果严重的故障，又不会收集每次普通交互的抽样策略；
• 监控采集器、管道、Schema、时间戳、抽样决定和存储的完整性。

OpenAI 的文档明确指出，模型生成和函数调用 Span 可能包含敏感输入输出，并提供关闭此类内容采集的控制。Anthropic 的 OpenTelemetry 导出需要主动启用，对更详细的 Tool 属性与内容也分别设置开关。这些机制证明了风险确实存在，但应用负责人仍然需要根据用户、所在司法管辖区和数据类别，决定是否允许采集与导出。

遥测数据本身也可能出错。缺少 Span 不能证明操作没有发生；抽样 Trace 不能代表全部流量；时钟偏差可能扭曲时间线；被攻破的服务还可能上报虚假的成功结果。重要外部影响必须向权威系统核实，同时还应监控遥测链路自身的健康状态。

权衡

选择	收益	代价或风险
采集全部内容	更快诊断语义问题	带来隐私、安全、保留、访问和提示词注入风险
只保留元数据与受保护引用	遥测数据更少、更安全	诊断时可能需要从另一数据存储受控提取材料
在 Trace 开始时决定是否抽样	收集成本可预测	可能遗漏开始时还无法识别的少见故障
根据最终结果决定抽样	能保留缓慢、失败或后果严重的 Trace	需要更多缓冲、基础设施和策略复杂度，决定也会延迟
使用统一 Schema	便于跨团队查询和复用工具	语义可能退化为最小公分母，并增加中央协调成本
使用特定业务事件	能准确表达任务和外部影响	更难做全局比较和迁移
自动遏制	响应更快	误报可能中断工作或引发新的状态转换
人工宣布事件	能结合具体背景判断	负责人或信号不明确时会延误响应
长期保留	有助于发现延迟问题和分析趋势	扩大泄露影响、合规负担和存储成本

目标不是完美回放每一个内部 Token，而是为系统可能造成的后果保留足够可信的证据，并准备好相应的控制能力。

失效模式

把 Trace 当作对话全文仓库

系统无限期保存所有提示词、文档和接口 Payload，却没有明确的诊断需要、访问边界或删除路径，最终形成极具价值的敏感数据集合。

请求成功，任务失败

Dashboard 上的 HTTP 错误率很低，但已验证完成率持续下降，或者外部影响一直无法确认。运维系统测量了基础设施路径，却没有测量产品承诺。

证据彼此失联

模型调用、接口操作、审批、外部影响和用户报告各用一套无关标识。响应人员只能依靠时间戳和经验拼接事件，既浪费时间，也无法确信结论完整。

全局平均值掩盖受影响分组

总体质量看似稳定，但某种语言、模型路由、租户、任务类型或后果严重的能力已经显著退化。

让模型评估器充当唯一警报

未经校准的分类器把含糊输出变成确定的事件信号，而它自身的漂移、提示词敏感性、漏报和受操纵风险却无人监控。

只有 Dashboard，没有响应负责人

异常已经可见，却没有人负责宣布事件、操作遏制控制或对外沟通影响。

停止开关没有状态语义

应急停止直接终止工作进程，恰逢写入正在进行，导致检查点丢失，或让排队操作在之后悄悄恢复。

缓解过程中毁掉证据

响应人员在保存时间线和关键版本之前就重新部署、删除会话或覆盖配置，最终无法确定真实影响范围。

服务恢复了，外部影响仍未核对

流量已经恢复，但重复付款、错误权限、受损记忆或尚未履行的用户义务仍然存在。团队围绕正常运行时间关闭了事件，而不是围绕真实结果。

事后复盘没有可落实的行动

复盘形成了一篇精美叙述，却没有推动控制手段、监控、评估、操作手册或责任分工发生任何具体变化。

手册建议

应维护两份相互关联的运维约定。

遥测约定应说明：

运行承诺和用户影响信号：
关联标识及其传递规则：
必须记录的事件和 Span 类型：
配置与策略版本：
结果与外部影响证据：
指标定义、单位、分母和细分维度：
内容采集、脱敏、访问、抽样和保留策略：
遥测系统健康指标：
告警负责人、严重程度规则和响应步骤：
已知盲区以及供应商无法提供的细节：

事件记录应说明：

事件标识、事件负责人、技术处置负责人和沟通负责人：
开始、发现、宣布、遏制、恢复和关闭时间：
已经观察到以及潜在的用户影响：
受影响的任务、用户、租户、数据、外部影响和配置：
已知事实、假设、未知内容和证据链接：
严重程度和通知义务：
遏制操作及其验证结果：
外部影响核对和剩余风险：
时间线与响应人员的决定：
触发因素、促成条件、根本原因和失效控制：
哪些环节有效，哪些地方只是幸运：
纠正行动、负责人、优先级、期限和验收方式：
新增评估案例、监控、操作手册变更和后续审查：

如果团队无法从告警连接到这些证据，也无法操作有边界的控制手段，那么它虽然有监控，却还没有可靠的事件响应能力。

检查清单

• 生产信号是否来自运行承诺、用户结果、权限和不可接受的后果？
• 能否从用户报告关联到对应的运行、模型与接口操作、审批、状态变化、外部影响、配置和验证器证据？
• 是否分别规定了指标、事件、追踪记录、状态记录、结果证据和抽样材料的用途？
• 事件记录能否区分外部影响处于已提出、已授权、已尝试、已确认、部分完成、被拒绝或结果未知？
• 是否分别测量协议成功和任务成功？
• 能否查看重要的模型、路由、任务、语言、租户、后果等级和配置分组？
• 基于模型的监控是否经过校准、纳入版本管理、允许拒绝判断，并在重要后果下使用更强证据确认？
• 每条需要立即响应的告警是否有用户影响或风险条件、负责人、严重程度规则、证据链接和经过演练的响应步骤？
• 响应人员能否在不丢失证据或破坏状态的情况下，停止或收窄能力、人群、凭据、配置和预算？
• 遏制控制是否经过演练，并且能够验证它产生的实际效果？
• 事件流程是否明确协调、技术处置和沟通职责？
• 关闭事件前是否完成证据保存、外部影响核对、分阶段恢复和剩余不确定性说明？
• 事后改进行动是否有负责人、优先级、期限和验收标准？
• 从事件产生的评估案例和监控是否遵守隐私及来源与流转记录要求？
• 是否明确治理敏感内容、标识、访问、保留、删除、抽样和租户隔离？
• 是否监控遥测导出失败、Span 丢失或失联、Schema 漂移、时钟偏差和抽样偏差？

参考资料及其用途

• OpenAI Agents SDK, “Tracing” — OpenAI 维护的 Agents SDK 文档，用于说明如何把工作流、模型生成、函数调用、防护栏和移交组织成相互关联的 Trace 与 Span。其敏感数据默认设置和 SDK 特定 Schema 是实现示例，并非通用可观测性设计。
• Anthropic Claude Code, “Monitoring” — Anthropic 维护的 Claude Code 文档，用于说明如何通过 OpenTelemetry 导出指标、事件和可选 Trace，如何关联 Prompt、API 请求与 Tool 活动，以及如何单独控制详细内容。它描述的是 Claude Code，而不是所有基于 Anthropic API 的应用。
• OpenTelemetry Semantic Conventions — 用于统一 Trace、指标、日志和事件词汇的社区规范。生成式 AI 与智能体相关约定仍在变化，因此本章没有把业务领域模型固定在当前草案字段上。
• W3C Trace Context — W3C 正式推荐标准，用于在 HTTP 服务间以可互操作方式传递 Trace 标识。它能关联分布式请求，却不定义任务、租户、审批或持久外部影响的标识。
• Google SRE, “Incident Management Guide” — Google SRE 事件管理资料，支持以用户症状为中心的可行动告警、响应准备、明确职责、沟通、控制与学习。它来自 Google 的实践经验，需要根据本地组织规模调整。
• Google SRE Workbook, “Postmortem Culture: Learning from Failure” — Google SRE Workbook 章节，支持事实时间线、影响测量、避免归罪个人的学习方式、明确负责人和跟踪改进行动。其组织实践是参考案例，不是正式标准。
• NIST SP 800-61 Rev. 3, “Incident Response Recommendations and Considerations for Cybersecurity Risk Management” — 2025 年发布的美国公共机构事件响应出版物，用于把准备、发现、响应、恢复和持续改进与风险管理相连接。其正式适用对象是网络安全事件；本章借鉴其生命周期处理更广泛的智能体系统故障，但不声称二者具有相同法律范围。