导读

随着DeepSeek-R1、Claude等大语言模型（LLM）推理能力的持续突破，基于LLM的智能体系统，尤其是多智能体系统，已具备完成复杂任务和社会模拟的强大能力。相比传统的微服务架构，智能体系统在自动化、可解释性和灵活性方面展现出显著优势，因此在客户支持、推荐系统等在线服务中得到了越来越广泛的应用。然而，智能体系统并非完美无缺。它们因灵活性带来的异常问题远比传统系统复杂，例如任务执行常因幻觉而失败、角色扮演场景中单个智能体遭受攻击可能导致整个模拟崩溃。这些不稳定和不安全因素严重阻碍了智能体系统的进一步发展。 为了维护智能体系统的安全与稳定，迫切需要一套专门针对智能体系统的运维解决方案。然而，当前的运维技术——从早期的人工操作到基于规则的方法，再到AIOps（智能运维）——均主要针对行为确定性的传统系统设计。LLM驱动的智能体具有随机性、高可观测性需求、异常多样性以及修复复杂性等特点，使得传统运维技术难以直接适用。目前，尚缺乏针对智能体系统有效运维策略的全面研究，现有工作多聚焦于智能体系统的孤立方面，如代理范式分类、基础模型幻觉或多智能体系统安全问题，而非整体的运维挑战。 为填补这一空白，本文系统性提出了**智能体系统运维（Agent System Operations, AgentOps）**这一全新概念。论文首先对智能体系统中的异常进行了精确定义和系统分类，将其划分为智能体内异常和智能体间异常，并覆盖了执行前、执行中和执行后三个阶段。随后，论文借鉴传统运维实践，将智能体系统的运维过程划分为监控、异常检测、根因定位和异常解决四个关键阶段，并为每个阶段深入分析了智能体系统带来的新挑战，提出了详细的定义和潜在的解决方案。本文将现有的零散研究统一到AgentOps框架之下，为智能体系统的工程化部署提供了坚实的理论基础和清晰的技术路线图。

Abstract / 摘要

随着大语言模型推理能力的持续提升，基于LLM的智能体系统相较于传统系统在灵活性和可解释性方面展现出优势，获得了越来越多的关注。然而，尽管智能体系统在研究和工业应用中广受欢迎，它们与传统系统一样频繁遭遇异常。这些异常导致不稳定和不安全，阻碍了其进一步发展。因此，迫切需要一套全面且系统的方法来运维智能体系统。遗憾的是，目前关于智能体系统运维的研究尚显匮乏。为填补这一空白，我们针对智能体系统运维开展了一项调研，旨在为该领域建立清晰的框架、定义挑战并促进进一步发展。具体而言，本文首先系统性地定义了智能体系统中的异常，将其分为智能体内异常和智能体间异常。接着，我们引入了一个全新的、全面的智能体系统运维框架，称为AgentOps。我们对其四个关键阶段：监控、异常检测、根因定位和解决，提供了详细的定义和解释。

I. Introduction / 引言

随着DeepSeek-R1和Claude等技术的出现，当前大语言模型的推理能力持续增强。利用LLM作为强大的认知引擎，现有的基于LLM的智能体系统，特别是多智能体系统，已具备完成广泛复杂任务和社会模拟的能力，尤其是当配备了多样化工具时。与微服务架构等传统系统相比，智能体系统提供了更好的自动化、更强的可解释性和更大的灵活性。因此，智能体系统的研究和工业应用蓬勃发展，越来越多的在线服务，如客户支持和推荐系统，开始采用这些智能体系统。 然而，尽管智能体系统应用广泛，但并非没有缺陷。与传统的微服务系统相比，智能体系统提供的更大灵活性也引入了更多异常。如图4所示，任务执行常因幻觉等问题而失败。在角色扮演场景中，对单个智能体的攻击可能导致整个模拟崩溃。因此，为了维护智能体系统的安全与稳定，促进其进一步发展，高效的运维是必要的。 尽管运维技术一直在演进，从早期的人工操作到基于规则的方法，再到AIOps，但智能体系统在本质上与传统系统存在显著差异。LLM驱动的智能体的行为特征与硬编码的传统系统根本不同。主要区别包括：（1）在智能体系统中观察到广泛的异常，这显著降低了任务成功率。例如，SWE-Agent的成功率仍低于40%。（2）智能体系统对可观测性的要求高于传统系统，需要对LLM等模块给予额外关注。（3）异常的多样性使得无法使用统一的方法在智能体系统中进行异常检测和根因分析。（4）智能体系统中的异常解决相对复杂且具有挑战性，需要从多个角度考虑并进行迭代优化。因此，传统运维技术难以应用于智能体系统，迫切需要针对这些系统量身定制的新运维技术。 目前，缺乏针对智能体系统有效运维策略的全面研究。大多数研究仍然集中在智能体系统的孤立方面，而非解决其整体的运维挑战。例如，Durante等人阐述了智能体范式和分类；Chakraborty等人深入探讨了基础模型中的幻觉，涵盖了其定义和检测方法；Deng等人探索了多智能体系统中的安全问题，主要涵盖外部恶意攻击，并将威胁分为执行内安全和交互安全。Shi等人则详细介绍了GUI智能体的安全问题和评估方法。 为了进一步推动智能体系统的发展，本文引入了**智能体系统运维（AgentOps）**的概念，这是一个专门为智能体系统设计的新型运维框架。首先，我们提供了智能体系统内异常的精确界定和系统分类，主要将其划分为智能体内异常和智能体间异常。这两个类别涵盖了智能体系统生命周期中的执行前、执行中和执行后阶段。此外，借鉴传统运维实践，我们将智能体系统的运维过程分为四个阶段：监控、异常检测、根因定位和解决。针对每个阶段，我们识别了智能体系统中出现的新挑战，并提出了详细的定义和潜在的解决方案。 在第二节中，我们详细讨论了智能体系统中的异常分类。第三节介绍了AgentOps的概念。随后的四节分别聚焦于AgentOps的关键组成部分：监控、异常检测、根因定位（也称为故障归因）和解决。第八节介绍了数据集和基准。第九节总结全文。

II. Anomalies in Agent Systems / 智能体系统异常

Fig. 1 and Fig. 2: Workflow of agent systems and definition/taxonomy of anomalies in agent systems. Source: original paper PDF, page 2.

异常的定义

排行榜显示，不同类型智能体系统的成功率仍然相对较低，这表明存在大量阻碍任务成功完成的异常情况。先前的工作，如Who&When，假设智能体系统中的异常主要出现在任务执行的特定步骤中。这里，执行指的是智能体系统在收到用户指令后，开始推理并调用工具来执行任务的阶段。 然而，现代智能体系统的定义远远超出了执行阶段。执行前和执行后阶段对任务成功同样至关重要。首先，在执行前阶段，如Claude Code、Hermes Agent、OpenClaw和Deep Agent等智能体框架通常会根据用户输入进行意图识别，随后配置或构建一个智能体工作流。这些工作流并非静态的，而是根据任务的演进动态实例化并持续更新。其次，在执行后阶段，任务完成并不一定意味着任务成功。例如，当Claude Code构建一个软件项目时，不能仅仅因为构建过程终止就认为成功；生成的项目可能仍然包含错误或未能满足功能需求。同样，在运维领域，一个根因分析任务可能没有出现任何明显的执行时异常，但仍可能因过早终止或粒度不足的分析而失败。这些案例表明，执行后因素也可能严重影响任务结果。因此，我们将智能体系统中的异常定义为在执行前、执行中或执行后阶段发生的、扰乱任务进程或妨碍任务有效完成的任何事件。 在上述基于阶段的定义基础上，我们从一个正交的结构化视角进一步分析异常。执行前、执行中和执行后阶段阐明了异常可能发生的时间，但并未说明异常在智能体系统内的来源。由于智能体系统大致可分为单智能体和多智能体系统，异常可能源自单个智能体的内部工作流，也可能源自多个智能体之间的交互。这与传统服务架构类似，故障可能发生在单个服务内部或服务间通信过程中。因此，如图2所示，我们将异常分为两大类型：智能体内异常和智能体间异常。智能体内异常指根植于单个智能体推理或工具使用中的中断，而智能体间异常指由智能体间的协调、通信或依赖问题引起的故障。

智能体内异常

如图3所示，智能体内异常指在任务执行过程中，发生在单个智能体或子智能体内部的故障。由于大多数现有智能体实现遵循ReAct范式，这类异常通常表现为推理和动作失败。此外，当智能体部署在复杂的垂直领域时，朴素的设计常常因长上下文处理、不可靠的检索以及工具权限约束不足而遭受内存退化和安全风险。这些观察强调了**装备工程（Harness Engineering）**对于提升智能体系统鲁棒性、可控性和安全性的重要性。

# 推理异常

推理是指导智能体后续行动并使其能够完成复杂任务的认知基础。近期研究提出了多种增强推理的技术，包括SFT、RLHF、Search-R1和DeepSeek-R1等微调方法，以及CoT、Reflexion、Self-Consistency、CoK和StepBack等提示策略。尽管取得了这些进展，推理异常仍然普遍存在，其中最具代表性的是幻觉。 文献中对幻觉的定义不断被完善。Rawte等人将幻觉定义为与已知事实相矛盾的不可靠生成；Gallifant等人则将其视为与原始提示无关的响应。Chakraborty等人通过四个特征总结了幻觉：合规性、期望性、相关性和合理性。Yang等人进一步将幻觉解释为一种不诚实的形式，即不确定的答案被以过度的自信表达出来。总的来说，幻觉可以看作是偏离事实、逻辑或任务要求的异常生成。它们难以消除，因为LLM对训练数据敏感，容易发生知识遗忘，并且无法同步吸收训练后出现的新知识。

# 动作异常

动作异常发生在智能体通过工具调用或函数调用未能正确执行预期操作时。在实践中，此类故障可能源于接口不一致、API选择错误、执行延迟、参数格式错误或系统级故障。此外，工具的使用带来了额外的安全风险。Wu等人表明，攻击者可以通过越狱提示利用函数调用机制，诱导LLM调用敏感函数或绕过限制。尽管模型上下文协议（MCP）标准化了LLM与外部工具之间的交互，但它并未完全消除动作异常。在实际部署中，配置更改和配置错误的MCP服务器仍可能导致失败、非预期或不安全的操作。

# 内存异常

智能体内存大致可分为短期记忆和长期记忆。短期记忆对应于LLM的上下文窗口。尽管现代LLM的上下文窗口不断扩大，但对于复杂任务而言常常仍然不足。许多智能体框架因此采用滑动窗口策略，这可能会丢弃早期但重要的指令。即使上下文长度在技术上足够，LLM仍可能无法充分利用位于长上下文中间的信息，这种现象被称为“丢失在中间”问题。PI-LLM也表明LLM在工作记忆方面存在内在瓶颈。 长期记忆通常通过向量数据库实现，并利用RAG进行回忆。然而，基于检索的记忆容易受到不准确召回、噪声证据和不可靠生成的影响。QE-RAG表明现有RAG系统对噪声高度敏感，而Astute RAG则强调了内部参数知识与检索到的外部知识之间的冲突。这种冲突可能进一步诱发RAG幻觉。Chen等人也观察到，尽管技术改进广泛，当前RAG系统的准确性仍然有限。

# 安全异常

安全异常指智能体或子智能体执行违反预定义安全策略、访问控制规则或身份约束的操作的情况。典型的例子包括未经授权的工具调用、超出分配权限的操作、滥用委托凭证以及在不正确或未经验证的身份下执行的操作。由于基于LLM的智能体通过自然语言推理与工具和API交互，其安全边界通常是隐式的，难以强制执行。 值得注意的是，安全异常不一定源于智能体的自主意图或内部故障。它们可能由对抗性输入、提示注入、恶意工具输出或受损的外部环境诱导，从而操纵智能体执行超出其预期授权范围的操作。这些风险与过度代理（Excessive Agency）密切相关，即智能体被授予了超出必要的自主权或权限，使得错误或被操纵的输出能够触发不安全的操作。在多智能体系统中，安全异常还可能源于委托或智能体间通信期间不正确的授权传播，其中受损的智能体间接导致其他智能体执行未授权操作。因此，健壮的智能体系统需要明确的身份管理、最小权限工具访问、对抗性鲁棒的输入和工具输出处理以及策略感知的执行机制。

智能体间异常

如图3所示，智能体间异常指源于多个智能体之间交互、协调和集体行为的故障。与固定工作流不同，许多新近的框架（如Hermes）会根据用户输入从可用技能和工具中动态构建子智能体，然后执行规划、执行和结果验证。因此，智能体间异常可能发生在整个生命周期。在执行前阶段，它们主要涉及由模糊、不完整或恶意的输入以及不适当的子智能体构建导致的任务规范和编排故障。在执行阶段，当智能体交换信息、调用工具或依赖不可靠的中间输出时，可能会出现通信和信任异常。在执行后阶段，当系统错误地判断任务完成或结果有效性时，会发生终止异常。此外，由于多智能体交互的不确定性，即使单个智能体行为正常，系统层面也可能出现突现行为异常。

# 任务规范异常

任务规范异常发生在用户目标、任务约束、智能体角色或配置模糊、不完整或不一致时。Pan等人表明，许多任务级别的故障源于不明确的任务定义，例如提示词指定不充分。Altmann等人进一步观察到，定义不当的任务可能导致追逐和阻塞，即使每个智能体的局部行为看起来是合理的。SentinelAgent报告称，不充分的协作模式规范可能导致智能体偏离预期行为、串通或易受提示注入攻击。因此，在执行前评估任务完整性并在执行中启用反思，对于稳健的多智能体运行至关重要。 智能体配置也是任务规范的重要组成部分，包括提示、角色、技能和工具。Pan等人将角色配置错误确定为异常的常见来源。Platon等人表明，不清晰的配置和角色混淆经常导致协调失败和对抗性对齐错误。同样，OG认为超出指定职责范围的操作会直接导致冲突、不一致和低效，而AgentFM则将模糊的角色配置确定为数据库智能体的常见故障源。

# 编排异常

编排异常指智能体系统全局规划过程中的故障。现代基于LLM的多智能体系统通常涉及任务分解、角色分配、工具和技能选择、智能体间协调以及工作流控制。此阶段的错误可能在单个子智能体采取行动之前就已传播到后续执行。典型的编排异常包括缺失或冗余的子任务、不匹配的智能体-工具分配、循环或冲突的依赖关系、低效的工作流以及违反任务约束或安全策略的计划。这些异常之所以具有挑战性，是因为它们通常不能归咎于某个单一的故障智能体，而是源于不恰当的全局协调、不完整的任务理解或不稳定的规划决策。

# 通信异常

通信异常发生在智能体之间进行消息交换时。Bronsdon强调了消息风暴是一种典型的故障模式，其中过多的智能体间通信导致资源耗尽、延迟增加和最终任务失败。AgentPrune同样观察到，冗余消息不一定能提升系统性能；相反，过度通信可能会分散智能体的注意力并降低协调效率。因此，有效的通信控制对于可扩展且可靠的多智能体系统至关重要。

# 终止异常

终止异常发生在智能体系统错误地判断任务是否应该停止或继续时。过早终止是一个代表性案例，即系统在完成所需的推理或执行步骤之前就停止了。Pan等人和Microsoft都将过早停止视为智能体系统故障的一个重要类别。Smurfs表明，在单智能体环境中，DFSDT可能会过早调用终止工具，从而损害复杂任务的完整性和逻辑连贯性。Zhang等人进一步将过早终止确定为多智能体系统中常见且可定位的故障源。 相反，智能体也可能无法终止。Zhu等人识别了低承诺异常，其中智能体反复将任务委派给子智能体，形成无限递归链，最终达到递归深度限制或超时。Drake描述了一个相关现象，称为“神经啸叫”，即智能体陷入没有明确终点的递归自我优化或推理循环中。这种非终止异常可能导致系统停滞，并导致严重的低效或认知停滞。

III. What is AgentOps? / 什么是AgentOps

Fig. 4, Fig. 5 and Fig. 6: Examples of traditional operations in agent systems, evolution of operations, and comparison of traditional system operations and agent system operations. Source: original paper PDF, page 5. 第二节识别了智能体系统中的多种异常，突显了对其运维的需求。在本节中，我们将深入探讨AgentOps的起源、定义和具体范围。首先，表I列出了将在讨论中引用的关键概念。

运维的演进

如图5所示，运维的演进可以从两个维度来理解：运维技术的演进和运维对象的演进。在技术维度上，运维已经从人工干预和基于规则的自动化发展到基于平台的可观测性、智能分析，以及最近由LLM智能体实现的自主运维。在对象维度上，运维的目标已从传统的IT基础设施和云原生应用扩展到AI/ML系统和新兴的智能体系统。 不同的运维范式对应于这个二维演进中的不同阶段。SRE通过SLO管理、监控、告警和变更控制等工程实践，专注于确保应用和基础设施的可靠性。AIOps进一步引入了智能技术来维护各类系统的稳定性，包括异常检测、根因分析、告警降噪和预测性优化。随着AI/ML系统变得越来越复杂，MLOps应运而生，用于管理数据管道、模型训练、部署、推理和漂移监控的全生命周期和可靠性。 最近，基于LLM的智能体成为了一类新的运维对象。与传统系统不同，传统系统的行为在很大程度上由程序逻辑确定，而智能体系统依赖于概率性的基础模型、动态工具调用、记忆和多步推理。它们的故障不仅可能源于基础设施故障或模型退化，还可能源于推理错误、不安全操作、工具误用以及与用户或系统目标的对齐失败。这些特性使得直接应用现有运维技术到智能体系统变得不够充分。 这种不足可以通过两个代表性的故障来说明。如图4所示，在一个医疗调度智能体中，用户要求重新预约，但在新时段确认之前保留原有预约。尽管正确的轨迹应该只在confirm_reschedule之后调用cancel_appointment，但智能体可能会过早地取消现有预约，随后无法找到新时段。传统的日志异常检测可能不会标记此行为，因为所有工具调用都返回了成功状态码和标准日志模板。故障反而是一种语义性的工具使用策略违规：智能体违反了所需的排序约束。同样，在一个企业报销智能体中，传统的追踪可能显示一条从收据解析到费用分类、策略检查和报销提交的正常路径，所有跨度都成功完成。然而，智能体可能将“观光旅游”分类为“会议活动”并予以报销。追踪捕获了结构化的服务调用路径，但未能捕获错误分类背后的语义决策路径。这些例子表明，智能体故障可能是轨迹层面和语义层面的，涉及意图、约束、工具使用顺序和决策 rationale，而非传统日志、状态码、延迟或追踪中的异常。 因此，我们提出AgentOps，指的是用于维护智能体系统可靠性、安全性和可控性的运维技术。AgentOps有别于AgenticOps：前者是在智能体系统上进行运维，而后者是使用智能体系统作为运维主体来维护其他系统。这种区别激发了为智能体系统设计专用运维框架的必要性。 Fig. 7: Illustration of AgentOps. Source: original paper PDF, page 7.

传统运维与智能体运维的差异

如图6所示，尽管传统系统运维和智能体系统运维共享相似的时间线，但它们在每个阶段都存在显著差异。表II给出了DevOps和AgentOps中可靠性实践的任务级映射。这就是为什么需要一个新的运维框架，即AgentOps的原因。下面，我们将详述这些差异。

• 监控：主要区别在于监控数据的类型。基于OpenTelemetry的传统系统运维侧重于监控指标、日志和追踪，这些数据能够反映系统实际运行状态，并允许对系统状态进行逆向工程。然而，对于智能体系统而言，根本区别在于服务是由LLM智能体提供的，这本质上是随机的。
• 异常检测：传统异常检测依赖于对结构化日志、指标阈值和拓扑依赖的分析。在AgentOps中，异常检测需要分析语义层面、轨迹层面和行为层面的偏差。例如，需要检测推理步骤中的幻觉、工具调用序列中的策略违规，以及多智能体交互中的意外突现行为。
• 根因定位：传统根因定位方法利用预先构建的静态依赖图或调用链进行故障定位。在AgentOps中，由于智能体之间的动态交互和LLM行为的随机性，需要定位到具体的推理步骤、错误动作或通信消息。这需要更细粒度的轨迹分析和因果推断。
• 异常解决：传统解决通常依赖于预设的运维手册（Runbook）执行固定操作，如重启服务或回滚版本。AgentOps中的解决更具挑战性，可能需要自纠正循环、提示优化、状态回滚或动态调整智能体配置。这是一个迭代的、需要评估的过程。

与既有智能体运维工作的区别

原文特别区分了本文的 AgentOps 与既有 AgentOps 工作的侧重点。已有文献通常从三类视角进入这个领域：一类强调可观测性，例如为智能体产物建立 tracking 与 tracing 管道；一类强调智能体架构的动态适配，例如围绕持续学习、多智能体共识和角色优化管理系统演进；还有一类强调基于角色的自动化流程，把智能体作为执行运维任务的自动化主体。 本文的不同之处在于，它把 AgentOps 明确定义为面向故障诊断与恢复的结构化生命周期，而不是单一的追踪工具或自动化流水线。第一，论文将分析中心从传统 metric-based tracing 转向由智能体结构边界驱动的异常分类，既覆盖单个智能体内部的推理、动作、记忆和安全异常，也覆盖多智能体之间的任务规范、编排、通信和终止异常。第二，论文试图连接高层原则与低层控制手段，把 checkpoint、state rollback、execution-level intervention 等机制放进运维闭环中，用来处理智能体执行路径的随机性和错误传播。

小结

因此，本文中的 AgentOps 是一个跨越预执行、执行和后执行阶段的综合运维框架。它继承传统运维中“监控、异常检测、根因定位、解决”的四阶段结构，但把每一阶段都重新映射到智能体系统的特性上：监控不仅看延迟和错误率，还要看 prompt、tool call、trace、memory、retrieval 与模型内部信号；检测不仅发现数值异常，还要识别语义偏差和行为违规；根因定位不仅定位服务节点，还要定位智能体、步骤、消息和动作；解决也不只是重启或扩容，而可能涉及任务重写、计划验证、动作限制、自纠正、回滚重放、记忆更新与策略修订。

IV. How to Monitor Agent Systems? / 如何监控智能体系统

监控数据说明

在传统监控数据中，使用OpenTelemetry收集的指标、日志和追踪同时存在于微服务系统和智能体系统中。 首先，关于指标，传统微服务系统通常关注系统级指标和应用性能监控（APM）指标。相比之下，包含基于LLM的智能体的智能体系统引入了额外的可观测性需求，特别是由于LLM、外部工具和检索组件的使用。基于当前智能体系统的应用，我们总结了四个常用的指标类别：系统指标、APM指标、成本相关指标和RAG相关指标。需要指出的是，这些类别并非详尽无遗，而是旨在涵盖实际智能体系统部署中具有代表性且常被采用的指标类型。 关于追踪，微服务追踪通常指的是服务之间通过API调用的交互。这些API调用的参数由用户操作或预定义系统规则决定，因此相对稳定和直接。然而，在智能体系统中，每个智能体的输入和输出以及智能体之间的交互（包括智能体到工具的调用）通常由LLM生成，引入了高度不确定性。这些不确定性是追踪数据的关键要素；因此，在智能体系统中，追踪不仅包括智能体和工具之间的关系，还包括每个步骤的输入和输出。因此，追踪数据是智能体系统的一个重要方面。 至于日志，微服务系统和智能体系统相似。微服务系统中的日志记录服务的整体行为，而在智能体系统中，它们捕获智能体的行为。

监控方法

用于基于LLM的智能体系统的可观测性工具正在快速发展。大多数这些工具遵循收集指标、日志和追踪的通用可观测性范式，同时进一步扩展了特定于智能体的功能，如数据集管理、实验追踪、评估、提示优化和部署管理。表III比较了代表性工具的功能。

• LangDB：首个完全用Rust实现的可观测性工具，强调运行时效率，并集成了路由器优化以进行成本控制。
• Langfuse：支持OpenTelemetry集成，是该领域最活跃的开源工具之一。
• Helicone：将可观测性与缓存管理相结合，以减少延迟和资源消耗，并通过网关回退等机制提高可靠性。
• HoneyHive：支持分布式追踪和多模态系统，允许用户定义自定义跨度以进行细粒度分析。
• PromptLayer：最初设计用于提示优化，现已集成可观测性功能，如提示排名。
• TruLens：作为Python包提供，可与LlamaIndex等框架集成，并支持基于人类反馈的迭代优化。
• OpenLLMetry：遵循OpenTelemetry标准，兼容多种框架，但对提示优化和评估的支持有限。
• LangWatch和Literal AI：提供标准的可观测性、评估和开发功能，其中LangWatch还可作为MCP服务器使用。
• MLflow：源自传统机器学习工作流，支持智能体系统的自定义指标。
• DeepEval：主要侧重于评估而非可观测性。
• AgentOps：除了可观测性外，还强调运维管理。

未来方向

当前智能体系统的可观测性在很大程度上仍是为监控而设计的。然而，有效的可观测性应服务于更广泛的目标：它应该支持异常检测、根因定位和故障解决，贯穿智能体执行的整个生命周期。如第三节B部分所述，智能体系统中现有的可观测数据（如指标、日志和追踪）通常不可靠、不完整或语义不足。因此，这些信号甚至可能无法为全面的异常检测提供足够的支持，更不用说精确定位和自动恢复。 因此，一个有前景的方向是丰富智能体系统可用的可观测数据类型。特别是，模型数据和检查点数据可以作为现有可观测性信号的两个重要扩展。随着数据安全问题的日益突出，越来越多的在线智能体系统采用本地部署的开源LLM作为推理引擎。这种部署范式使智能体系统能够超越仅能获得输入和输出的黑盒观测，转而从内部状态（如隐藏层表示和token logits）收集白盒模型数据。与仅有的输入输出记录相比，这种模型级数据可以提供更细粒度的证据，用于检测源于LLM本身的异常行为，从而提高智能体推理和生成过程的可观测性。 检查点数据提供了另一种互补的可观测数据类型。与传统的微服务系统相比，智能体系统通常提供更强的可控性，因为某个时刻的执行状态可以从记录的数据中重现。因此，可以引入检查点来定期捕获智能体系统的执行状态，包括内存、环境、中间结果和其他运行时信息。如图10所示，一旦检测到异常，系统可以回滚到之前安全的检查点，结合反馈，并从纠正后的状态继续执行。这种机制有助于防止错误中间状态的累积，从而避免最终导致任务失败。类似的思路已在编码智能体中显示出有效性，其中版本控制可以防止错误的代码修改传播并导致级联故障。 除了扩展可观测数据的类别外，未来的可观测性还应提高此类数据的质量。与其仅依赖原始的指标、日志、追踪、模型数据或检查点记录，智能体系统需要经过处理的、风险感知的信号，这些信号能更直接地反映潜在故障。例如，从执行轨迹推断出的幻觉概率或从logits估计出的token级不确定性，可以提供比原始记录更具可操作性的证据。这种高质量的可观测性信号可以帮助智能体框架更高效地检测、定位和恢复故障，从而使智能体系统保持稳定、可靠且可持续改进。

V. How to Detect Anomalies in Agent Systems? / 如何检测智能体系统异常

在通过多维观测获得足够多样和全面的监控数据后，可以利用这些高质量数据对智能体系统执行运维操作。在这些操作中，异常检测扮演着至关重要的角色，因为及时发现系统中的异常对于有效指导后续的根因分析和解决至关重要。本节主要关注异常检测的方法。表IV总结了智能体系统中异常检测和缓解的方法概况。下面，我们主要介绍一些常见异常的检测方法。

检测方法

# 检测推理异常

根据使用的输入信息类型，检测和缓解推理异常的方法可以分为白盒、灰盒和黑盒三类。白盒方法利用token序列、每个token的相关概率以及模型参数。相比之下，灰盒方法不使用模型参数。最后，黑盒技术仅依赖token序列。

• 白盒方法：SPALMA认为LLM参数包含幻觉的隐式线索，并提出了一个基于参数的分类器，在大型多样数据集上训练，以零样本方式检测幻觉。相比之下，OPERA在推理阶段解决幻觉问题，通过识别自注意力图中的“部分过度信任”现象，使用列式度量、概率惩罚和回滚策略来缓解。同时，Honesty将幻觉归因于超出模型知识边界的查询，倡导模型对其局限性保持诚实，通过引入进化度量和IDK（“我不知道”）响应，以及提示工程和微调等技术来解决此类异常。
• 灰盒方法：LURE分析了幻觉的三个主要原因——共现、不确定性和对象位置，并使用LLM生成样本来训练一个轻量级的修正器，该修正器可以在推理阶段直接检测和修正响应。Conformal受共形预测启发，基于token序列logits计算采样响应的质量，并根据停止规则将其丢弃。
• 黑盒方法：Debate通过让多个模型实例对同一问题迭代评估和更新答案来减少幻觉，借鉴了“思维社会”的观点。CoK通过使LLM在推理过程中主动查询和整合来自多个外部知识源的信息，迭代地审查和纠正推理链，从而增强事实准确性。

# 检测内存异常

由于智能体的内存分为短期记忆和长期记忆，因此内存异常可分为短期记忆异常和长期记忆异常。

• 短期记忆异常：为了解决扩展上下文窗口长度的挑战，PI提出了位置插值，通过位置编码缩放整个窗口。相比之下，CoA采用多智能体协作框架，不同的智能体处理不同的数据块，并由一个管理智能体整合结果，从而缓解了传统微调方法中常见的“丢失在中间”问题。
• 长期记忆异常：ReDeep通过计算两个分数——外部上下文分数和参数知识分数——来调节残差流中Knowledge FFN和Copying Heads的贡献，从而缓解RAG幻觉。另一方面，LRP4RAG采用逐层相关性传播（LRP）算法，在生成器输出logits后执行反向LRP以获得相关性矩阵，然后将该矩阵输入预训练分类器以确定是否存在幻觉。

# 检测安全异常

安全异常对系统安全构成重大威胁，检测方法通常依赖于图方法。GUARDIAN强调传统的多智能体投票方法忽略了智能体之间的依赖关系。为了解决这个问题，它将智能体系统建模为图，使用编码器-解码器架构来压缩和重建整个图，并根据重建分数检测异常。SentinelAgent则处理多智能体协调风险，提出了一种从全局到细节的三层层次化检测方法。

# 检测编排异常

编排异常可以根据其发生位置分为单步异常和多步异常。

• 单步异常：Introspective结合RAG召回和基于人类反馈的共形预测来解决LLM中的常识推理问题。API-bank通过使用从API调用收集的对话数据微调模型来改进LLM规划能力，采用数据驱动方法。ReAct则引入了一个推理和行动框架，将规划分为推理和行动两个阶段，并通过提示工程实现，为模型提供了反思性纠错的机会。
• 多步异常：ToolLLM基于API生成单工具和多工具指令，并进一步提出了一种基于深度优先搜索的决策树来构建连贯的规划路径。Reflexion利用外部反馈——如简单的二元环境反馈、针对常见失败情况的预定义启发式规则，以及自评估机制（如使用LLM进行二元分类或编写单元测试）——使智能体能够反思过去的执行步骤并优化后续轨迹。CodeAct则将整个规划过程表述为可执行的Python代码，通过确保精确的参数传递从根本上减少了工具使用中的幻觉。

未来方向

尽管现有研究针对推理、动作、内存、编排和通信异常提出了各种检测方法，但大多数方法仍局限于特定异常类型，依赖于不同的输入信号、检测粒度，并且缺乏一个统一的框架来应对智能体系统中多样且动态的异常模式。未来需要开发更通用、更全面的异常检测系统，该系统能够整合多种数据源（如日志、追踪、模型内部状态和交互行为），并能够适应智能体行为的随机性和动态性。此外，对于多智能体系统中突现行为的检测是一个尚未充分探索但极具潜力的方向。

VI. How to Locate the Root Cause of Agent System Anomalies? / 如何定位智能体系统异常根因

Fig. 11: Localization accuracy under different context lengths. Source: original paper PDF, page 11. 在检测到异常后，快速定位根因是恢复系统正常运行的关键。智能体系统中异常的复杂性和多样性使得根因定位远比传统系统更具挑战性。传统方法（如基于日志的故障定位、基于指标的根因分析）在智能体系统中往往失效，因为故障原因通常隐藏在语义层面、推理步骤或智能体交互中。

根因定位的挑战

• 原因-症状的强耦合：在传统系统中，异常（如高延迟）与根因（如CPU过载）之间通常有直接的关联。但在智能体系统中，一个错误推理步骤（根因）可能不会立即引发可观测的异常（症状），而是经过多步累积后导致任务失败。这使得关联变得非常困难。
• 大规模搜索空间：智能体系统，特别是多智能体系统，其执行轨迹可能包含大量的推理、动作和交互步骤。在大规模搜索空间中定位导致最终失败的少数关键步骤类似于大海捞针。
• 非确定性行为：LLM的随机性意味着即使输入相同，系统也可能产生不同的执行轨迹。这使得基于历史数据的模式匹配和定位方法效果不佳。
• 因果链的复杂性：故障可能源于一个智能体的错误推理，通过通信传递给另一个智能体，最终导致复杂的级联故障。在这样的因果链中定位初始触发点非常困难。

现有的方法

目前，针对智能体系统的根因定位研究还处于起步阶段，主要分为以下几类：

• 基于轨迹分析的方法：许多方法通过分析智能体的执行轨迹来定位故障。例如，Who&When通过分析多智能体系统执行步骤的因果依赖关系，来定位是哪个智能体、在哪一步导致了任务失败。这种方法通常将轨迹建模为图结构，并利用图遍历或因果推断算法来识别关键节点。
• 基于LLM推理的方法：利用LLM自身的推理能力来辅助根因分析是另一个新兴方向。例如，可以将整个智能体的执行过程（包括观察、思考、行动、反馈）作为上下文提供给一个分析型LLM，并请它分析可能的原因。Flow-of-Action方法利用标准操作程序（SOP）增强的LLM多智能体系统，特别用于根因分析任务。
• 基于统计或启发式的方法：某些方法通过统计异常步骤的出现频率或预定义一些启发式规则（例如，如果某工具调用失败率突然升高，则可能是该工具出现问题）来定位根因。这些方法在特定场景下有效，但泛化能力有限。

未来方向

未来的研究方向应包括：

• 开发更结构化的因果模型：建模智能体系统内部复杂的因果依赖关系，例如使用因果图或概率图模型。
• 融合多模态数据：不仅仅依赖执行轨迹，还要整合日志、指标、模型内部状态（如注意力权重、token logits）、系统事件等多种数据源，提供更全面的定位依据。
• 实现自动化且可解释的定位：根因定位算法不仅要指出故障点，还应该能够提供可解释的推理路径，说明为什么该点被认为是根因，帮助运维人员快速验证和理解。

VII. How to Resolve the Anomalies? / 如何解决异常

一旦定位到根因，下一步就是采取行动解决异常，使系统恢复正常。智能体系统中异常的解决同样面临独特挑战，因为解决方案不仅仅是重启服务或回滚配置，而可能需要对智能体的行为、推理或环境进行精细调整。

异常解决的挑战

• 需要语义理解：许多异常（如违反策略的工具使用顺序）需要对任务意图和业务规则有深入理解，才能制定正确的解决方案。简单的“重试”操作可能无效。
• 迭代性和评估性：解决过程往往不是一次性的。采取一个纠正措施后，需要重新评估系统状态，确认问题是否真正解决，以及是否有新的问题产生。这形成了一个“检测-定位-解决-评估”的闭环。
• 风险性：不当的干预可能使情况更糟。例如，错误地回滚到一个较旧的状态可能会丢失有效的工作。
• 多视角权衡：解决方案可能需要从多个角度考虑，包括修改提示词、调整智能体配置、切换模型版本、引入新的验证机制或改变多智能体的协作策略。

现有解决方法

根据解决的复杂性和干预深度，可以将方法分为：

• 基于反馈的自我纠正：这是目前最常用的方法。智能体在执行过程中通过反思（如Reflexion）、自我验证或外部反馈（如编译器错误、环境奖励）来修正自己的行为。这通常涉及到在轨迹中的某个点（如工具调用失败后）重新思考和规划。
• 基于状态回滚：利用在监控阶段收集的检查点数据，当检测到异常后，将系统状态回滚到之前一个已知的安全和正确的状态点，然后重新执行。这在编码智能体中通过版本控制实现，在通用场景中通过保存中间状态实现。
• 配置调优与提示工程：对智能体的根因（如推理错误、工具误用）进行定向修复，例如修改系统提示词以强化约束、调整模型的温度参数、或为智能体增加新的工具使用范例。
• 基于外部工具的干预：引入防御性机制。例如，MCP Guardian这样的模型上下文协议（MCP）守护进程，可以监控智能体与工具的交互，在发现潜在不安全或异常的操作时进行拦截、告警或强制修正。这提供了一种策略层面的解决能力。
• 基于学习的优化：更高级的解决框架，如Agent-Pro，能够从过往的成功和失败经验中进行学习，通过策略级别的反思和优化来进化自身的技能集和决策模式。Trial and Error方法也通过探索大量轨迹来找到最优的解决路径。

未来方向

• 自动化运维编排：开发能够根据异常类型和根因自动选择和编排解决步骤的AgentOps系统。这类似于AIOps中的自动化运维，但需要处理更复杂的语义和不确定性。
• 安全且可逆的干预：设计安全的干预机制，确保每次干预都是可逆的，并且可以进行原子化操作，以降低风险。
• 持续学习与进化：AgentOps系统自身应该具备学习能力，能够从解决历史异常的经验中不断优化其检测、定位和解决策略，实现系统的自我进化。

VIII. Datasets and Benchmark for AgentOps / AgentOps数据集与基准

为了推动 AgentOps 的发展，论文最后梳理了已有数据集与基准。这里需要注意，AgentOps 包含监控、异常检测、根因定位和异常解决四个阶段，但并不是每个阶段都容易构造统一基准。监控强依赖实际部署环境、插桩方式和业务系统结构；异常解决则受下游约束、恢复成本和安全边界影响，很难用一个静态数据集完全覆盖。相比之下，根因定位，也就是 failure attribution，已经成为当前最成熟、最容易标准化的数据集和基准方向。

现有数据集与基准

论文表 VII 比较了若干代表性数据集和基准，包括 Who&When、MASFT、TRAIL、AgentFail、Aegis 和 AgentDebug。它们大多通过社区常用智能体系统模拟执行轨迹，再配合人工或自动标注构造失败样本。例如，Who&When 覆盖 184 个失败实例，面向 127 个多智能体 LLM 系统；MASFT 覆盖 1642 个失败实例、14 类失败类型，涉及 ChatDev、MetaGPT、HyperAgent、AppWorld、AG2、Magentic-One 和 OpenManus 等系统；TRAIL 覆盖 841 个失败实例和 21 类失败类型；AgentFail 覆盖 Dify、Coze 等平台场景；Aegis 的规模最大，包含 24843 个失败实例，涉及 LLM Debate、MacNet、AgentVerse、Dylan、SmolAgents 和 Magentic-One；AgentDebug 则覆盖 ALFWorld、WebShop、GAIA 等环境。 从表 VIII 的覆盖分析看，现有研究已经开始覆盖推理异常、动作异常、记忆异常、安全异常、任务规范异常、通信异常、终止异常和编排异常等不同类别，但覆盖仍不均衡。多数基准更关注智能体内部异常，尤其是推理、动作和记忆问题；对智能体间异常，特别是通信异常、编排异常和终止异常的覆盖仍然不足。随着 Hermes Agent 等自动化多智能体构建框架出现，高效协同正在变得越来越重要，这意味着未来基准不能只评估单个智能体是否出错，还要评估多个智能体之间的协作链条如何断裂。

主要趋势

论文总结出三个趋势。第一，失败实例数量持续增长。更多失败样本能够覆盖更丰富的错误组合，也能支持更细粒度的方法评估。第二，失败类型越来越多样化。不同工作都提出了自己的智能体失败 taxonomy，但这些 taxonomy 的交集和覆盖范围仍有限，尤其难以统一描述跨智能体传播的异常。第三，数据生成和标注正在走向自动化。人工标注成本高、扩展性差，因此越来越多工作使用模拟轨迹、故障注入、自动标注或 LLM 辅助评估来构造数据。

评估局限与未来方向

从评估角度看，许多现有方法仍依赖 LLM 作为 evaluator。替代方法要么效果较弱，要么设计复杂，因此当前不少基准实际上仍在评估模型本身的判断能力，而不是完整 AgentOps 系统的工程可靠性。此外，多数基准继续使用 agent-level accuracy 和 step-level accuracy 作为主要指标。这对于根因定位很有用，但还不足以衡量真实运维所关心的恢复能力。 论文认为，未来需要更细粒度的评估协议。除了判断系统能否识别失败，还应评估智能体在错误轨迹之后能否高效恢复，例如能否回滚到正确检查点、能否避免错误继续传播、能否在较少迭代中完成修复、以及修复是否引入新的副作用。对于真实部署的 AgentOps 来说，发现错误只是第一步，能否以可控成本把系统带回可靠状态，才是更接近工程价值的评价目标。

IX. Conclusion / 结论

LLM推理能力的不断提升极大地加速了智能体系统的发展。然而，智能体系统经常遇到异常，并且目前缺乏有效的运维解决方案。本文对智能体系统异常进行了新颖的定义和全面的分类，将其划分为智能体内异常和智能体间异常。此外，我们提出了一个新的运维框架——AgentOps，专门为智能体系统设计。该框架涵盖四个关键组成部分：监控、异常检测、根因定位和解决。我们对每个组成部分都进行了深入的分析和分类。总体而言，这项工作推动了智能体系统的运维，为其更稳健和可靠的部署奠定了基础。

原文信息

英文题目 Agent System Operations: Categorization, Challenges, and Future Directions 作者 Zexin Wang, Changhua Pei, Yuanhao Liu, Jingjing Li, Yintong Huo, Quan Zhou, Haotian Si, Hang Cui, Zihan Liu, Jianhui Li, Gaogang Xie, Fei Sun, Dan Pei, David Lo arXiv ID 2606.01581 类别 cs.MA Comments/项目信息 原文未明确说明 原文链接 https://arxiv.org/abs/2606.01581