核心内容摘要
window系统telnet 最佳方案
文章介绍了面向大语言模型智能体系统的运维框架AgentOps系统定义了智能体内部异常与智能体间异常两大类别构建了监控、异常检测、根因分析、修复验证四大阶段闭环框架。
相比传统AIOpsAgentOps首次将模型参数、注意力图谱等语义级数据纳入监控有效解决智能体系统黑箱难题提升不确定性环境下的自愈能力与运行可靠性。
随着大模型智能体与AI技术的迅猛发展智能体正逐步渗透至各行各业成为人机交互、任务自动化与系统智能化的核心载体。
然而智能体在日益复杂的环境与场景中持续运行其行为可控性、系统稳定性与长期可靠性也面临全新挑战——智能体的运维及异常检测逐渐从幕后走向关键地位成为保障其安全、高效、可持续运行的重要基石。
本期给大家推荐一篇关于大语言模型智能体运维的前沿综述论文《AgentOps面向LLM智能体系统的运维框架综述》开创性地提出了针对智能体系统的全生命周期运维新范式。
该研究系统定义了智能体系统的异常体系将其划分为智能体内部异常与智能体间异常两大核心类别。
论文构建了包含监控、异常检测、根因分析、修复验证四大关键阶段的AgentOpsAgent System Operations智能体系统运维闭环框架显著提升了智能体系统在不确定性环境下的自愈能力与运行可靠性。
相比传统AIOps方法AgentOps首次将模型参数、注意力图谱、思维链快照等语义级数据纳入监控范畴有力解决了智能体系统黑箱难题。
由于文章篇幅过长小编将分两次为大家翻译介绍这篇论文。
论文链接通过点击本文左下角的阅读原文进行在线阅读及下载。
论文基本信息**论文题目:**A Survey on AgentOps: Categorization, Challenges, and Future Directions**论文来源**arXivDoihttps://doi.org/
1
48550/arXiv.
2
02121github地址https://github.com/linafaik08/agentic-investor-brief**作者:**Zexin Wang1,*, Jingjing Li1, Quan Zhou1, Haotian Si1, Yuanhao Liu2, Jianhui Li1, Gaogang Xie1, Fei Sun3, Dan Pei4, Changhua Pei1**论文时间:**2025年8月机构:1Computer Network Information Center, Chinese Academy of Sciences, China2Hangzhou Institute for Advanced Study, University of Chinese Academy of Sciences., China3Institute of Computing Technology, Chinese Academy of Sciences, China4Tsinghua University, China摘要随着大语言模型LLMs推理能力的持续提升基于LLM的智能体系统在灵活性和可解释性方面较传统系统更具优势因而备受关注。
然而尽管智能体系统在学术界和工业界广受研究关注并得到广泛应用但这类系统与传统系统一样常会遭遇异常现象。
这些异常导致系统不稳定且存在安全隐患阻碍了其进一步发展。
因此亟需建立一套全面系统的智能体系统运维方法论。
遗憾的是当前关于智能体系统运维的研究尚显匮乏。
为填补这一空白本文开展了智能体系统运维的系统性调研旨在构建清晰的领域框架、界定核心挑战并推动后续发展。
本文首先系统定义智能体系统中的异常现象将其划分为智能体内部异常与智能体之间异常两大类。
随后提出名为智能体系统运维AgentOps的创新性综合运维框架。
本文详细阐释了该框架的四个关键阶段监控、异常检测、根本原因分析及问题解决并给出了具体定义。
关键词人工智能软件与应用安全智能体系统运营目录1****引言2****智能体系统的分类
1 智能体系统的定义
2 智能体分类3****智能体系统中的异常现象
1 智能体系统中异常的定义
2 智能体内部异常
3 智能体间异常4****智能体系统运维
1 运维演变
2 传统系统运维与智能体系统运维的区别
3 结论5****监控智能体系统
1 监测数据示意图
2 当前监测方法
3 挑战6****异常检测
1 推理异常
2 规划异常
3 动作异常
4 内存异常
5 环境异常
6 任务规范异常
7 安全异常
8 通信异常
9 信任异常
10 涌现行为异常
11 终止异常7****根本原因分析
1 代理失败根本原因分类体系
2 从异常检测到根本原因分析的映射8****解决方案
1 解决方案验证
2 解析模式迭代修复与多轮验证
3 代理系统的异常解决9 AgentOps****的挑战与未来方向
1 监测
2 异常检测
3 根本原因分析
4 解决方案10****结论注小编能力有限如有翻译不恰之处请多多指正~若想进一步拜读完整版请下载原论文进行细读。
1 引言随着DeepSeek-R1[35]和Claude[4]等技术的出现当前大型语言模型LLMs的推理能力正持续增强。
基于LLMs构建的智能体系统–尤其是多智能体系统–凭借其强大的认知引擎特性已具备完成各类复杂任务与社会模拟[60]的能力当配备多样化工具时[78]表现尤为突出。
相较于微服务架构[75]等传统系统智能体系统能提供更优的自动化水平、增强的可解释性及更强的灵活性。
因此代理系统的研究与工业应用蓬勃发展越来越多的在线服务[50]例如客户支持和推荐系统开始采用这些代理系统。
图1 智能体系统的异常现象。
左侧展示任务执行过程中的异常情况智能体在整合网络搜索结果时出现幻觉导致生成错误答案。
右侧呈现拍卖角色扮演模拟中的异常现象对买家1的攻击引发异常高价竞标最终导致拍卖崩盘。
然而尽管智能体系统应用广泛其缺陷依然存在。
相较于传统微服务系统智能体系统提供的更高灵活性也带来了更多异常现象。
如图1所示任务执行常因幻觉等问题而失败。
在角色扮演场景中对单个智能体的攻击可能导致整个模拟系统的崩溃。
因此为保障智能体系统的安全稳定并推动其持续发展高效的运维机制至关重要。
尽管运维技术历经演变–从早期的手动操作到基于规则的方法再到后来的IT运维人工智能AIOps但代理系统与传统系统在根本上存在显著差异。
基于大型语言模型LLM的智能体行为特征与硬编码传统系统存在根本差异主要区别包括(
智能体系统中出现的异常类型更为多样(
智能体系统对可观测性要求远高于传统系统需重点关注LLM等模块(
异常的多样性使得统一方法无法在智能体系统中实现异常检测与根本原因分析。
(
代理系统的故障处置相对复杂且具有挑战性需要多维度考量与迭代优化。
因此传统运维技术难以适用于代理系统亟需针对该类系统开发定制化的新型运维技术。
目前针对智能体系统有效运行维护策略的综合性研究尚显不足。
多数研究仍聚焦于智能体系统的孤立方面而非解决其整体运行挑战。
例如Durante等[27]阐述了智能体范式与分类体系Chakraborty等人[12]深入探讨基础模型中的幻觉现象涵盖其定义与检测方法Deng等人[24]研究多智能体系统安全问题主要涉及外部恶意攻击并将威胁划分为执行内安全与交互安全两类Shi等人[85]则详细剖析了图形用户界面智能体的安全问题及评估方法。
为进一步推动智能体系统的发展本文提出智能体系统运维AgentOps的概念–这是专为智能体系统设计的新型运维框架。
首先本文对智能体系统中的异常现象给出了精确定义并提出系统性分类框架主要将异常分为代理内部异常与代理间异常两类。
这两大类涵盖了代理系统生命周期中的执行前、执行中及执行后阶段。
此外借鉴传统运维实践本文将代理系统的运维流程划分为四个阶段监控、异常检测、根本原因分析及问题解决。
针对每个阶段本文识别出代理系统中出现的新挑战并提出详细定义与潜在解决方案。
据本文所知这是首次系统性提出AgentOps概念并规范其各项流程定义的研究。
2 智能体系统的分类
1智能体系统的定义智能体系统指能够感知环境、自主决策、执行行动并最终完成任务的智能系统。
这类系统通常由多个智能体构成并具备四项核心能力[69]。
随着大型语言模型的兴起与发展当代智能体系统常基于这些模型构建因其在多模态数据理解与推理方面具备卓越能力且擅长工具运用。
因此本文主要聚焦于基于大型语言模型的智能体系统运作机制。
l 、**工具调用**基于大型语言模型的智能体系统通过工具调用与环境交互持续获取观测数据作为反馈。
该反馈为自动化推理与决策过程提供参考依据。
早期实现中工具调用通过函数调用完成–针对特定任务编写专用函数并将函数描述格式化后输入至大型语言模型。
然而不同语言模型间的差异导致格式及其他信息需频繁调整。
模型上下文协议MCP[3]通过标准化大型语言模型、外部数据源与工具之间的通信协议从根本上解决了这一问题。
MCP的引入既促进了服务提供商开发对应服务API同时避免了资源浪费。
**
推理与行动**随着DeepSeek-R1[35]等具备推理能力的LLM出现大型语言模型的推理能力日益强大足以支撑基于LLM的智能体系统实现自动化决策并执行各类复杂任务。
众多方法通过提示工程有效调用LLM的推理能力来增强智能体系统。
例如Chain-of-Thought[105]采用少样本方法引导LLM逐步推理ReAct[109]提出思考先行于行动的策略Reflexion[88]则建议在特定周期后对完整推理路径进行反思。
**
短期与长期记忆**与人类相似基于大型语言模型的智能体系统因令牌长度限制而具有有限的知识存储能力因此需要有效的知识管理机制。
常见的知识管理范式是将信息划分为短期记忆与长期记忆。
短期记忆包含与当前任务密切相关的少量知识和观察结果通常通过提示工程提供给大型语言模型。
长期记忆则包含大量虽与当前任务关联性不强但可在任务执行特定步骤时调用的知识库。
长期记忆通常通过检索增强生成RAG和向量数据库进行管理。
当需要调用知识时系统会基于查询向量与知识向量间的相似度进行检索。
诸如GraphRAG[28]等RAG与向量数据库的创新技术正持续推动该领域的发展。
**
智能体通信**尽管多智能体系统日益受到关注但大量研究表明在许多场景中其性能有时并不优于单一智能体。
这凸显了智能体通信的关键作用。
有效的分工与协作理应带来更优结果。
因此针对大型语言模型LLM代理的通信标准与协议已陆续提出其中包括广为人知的代理间通信A2A[18]协议。
A2A协议引入了代理卡片的概念用于系统化定义每个代理的能力同时使客户端代理能够高效管理任务及所有参与代理。
2智能体分类在基于大型语言模型LLMs的智能体系统研究中可根据参与智能体的数量进行基础分类。
如图2所示智能体系统可分为单智能体系统SAS与多智能体系统MAS。
SAS系统以单个大型语言模型驱动的智能体为核⼼处理单元。
图2 智能体系统的分类体系这类系统通常应用于以下类型任务**推理**该智能体通过调用内置知识或上下文线索执行逻辑或数学推理以及因果推理。
例如AI科学家[67]通过开放式推理过程探索自动化科学发现。
**对话**智能体维持对话状态解析用户意图并生成语义连贯的回应。
对话任务已超越文本交互范畴延伸至包含图像、音频和视频的多模态沟通例如GPT-4o[52]等系统所展示的应用。
**交互**智能体通过信息交换或执行操作直接与相对简单且可预测的外部环境进行交互。
典型代表是WebArena[122]其中智能体与结构化网页界面进行交互。
相比之下多智能体系统MAS由多个基于大型语言模型LLM的智能体在共享环境中协同运作。
这些智能体既可相互协作亦可相互竞争使得MAS特别适用于处理单智能体系统难以应对的分布式、并发性或战略复杂性问题。
典型的MAS应用包括**角色扮演与仿真**智能体被赋予特定身份、背景及行为规则并在预定义框架内以符合角色特性的方式互动。
此类仿真可研究由微观层面的交互所引发的宏观层面的涌现现象例如社会动态、经济系统及疫情传播。
典型案例包括模拟地缘政治冲突的WarAgent[48]以及建模宏观经济活动的EconAgent[60]。
**合作与协作**多个智能体共享共同或部分一致的目标并通过任务分解、协商和信息交换来实现这些目标。
例如在ChatDev[77]中智能体协同参与代码生成和调试工作。
**博弈论互动**在目标可能冲突的情境中行为主体必须在决策过程中考虑他人的策略。
这涉及以下要素竞争、谈判与激励机制设计例如拍卖、多方博弈和零和博弈[45]。
值得注意的是多智能体系统MAS能够完成传统智能体系统SAS的任务且通常能提升性能。
然而这需要付出系统复杂性增加、潜在突发故障风险及更高维护成本的代价。
因此在SAS与MAS之间进行选择时应基于目标应用领域的具体需求与约束条件[33]。
3 智能体系统中的异常现象
1智能体系统中异常的定义前文指出各类智能体系统的成功率并不高表明存在大量阻碍任务任务成功完成的异常情况。
根据WhoWhen[116]的研究他们认为这些系统中的异常主要发生在任务执行的特定步骤。
具体而言若在某个异常步骤进行干预使其转化为常规步骤从而确保任务成功完成则该步骤即可被识别为异常步骤。
然而这一定义相当有限。
传统微服务系统通常能长期稳定运行无需考虑执行前与执行后阶段。
相比之下智能体系统的任务执行与其执行前提示密切相关而执行后成功完成并不必然意味着未发生异常例如推理幻觉等仍可能导致错误结果。
因此如图3所示本文将智能体系统中的异常定义为在执行前、执行中或执行后阶段出现的任何导致任务中断或无法有效完成的情况。
图3 智能体系统中异常的定义基于上述定义本文提出了一种针对智能体系统异常的新分类方法。
如前所述智能体系统可分为单智能体系统和多智能体系统。
因此异常既可能发生在单个智能体内部也可能出现在多智能体交互过程中。
这类似于传统服务架构中异常既可能出现在单个服务的内部流程中也可能发生在服务间通信过程中。
因此如图4所示本文将所有异常归类为两类智能体内部异常与智能体间异常。
图4 智能体系统中的异常分类体系
2智能体内部异常要完成复杂任务智能体系统需要多个智能体协同完成不同子任务。
智能体执行这些子任务的过程占据了任务执行时间的大部分。
在执行子任务期间智能体必须进行推理与规划同时通过多种方式与环境交互这极易导致异常现象的发生。
代理系统中最常见的是代理内部异常。
**
****推理异常。
**智能体利用认知系统进行推理进而指导后续行动并为完成复杂任务奠定基础。
近年来众多方法被提出以增强推理能力包括精细调整方法如 SFT[104]、RLHF[73]、Search-R1[53]和 DeepSeek-R1[35]以及如CoT[105]、Reflexion[88]、Self-Consistency[102]、CoK[61]和StepBack[119]等提示工程技术。
尽管这些技术提供了支持推理过程中仍频繁现异常现象。
**
规划异常。
**自主规划与工具调用是智能体系统完成任务的核心功能。
然而受限于当前大型语言模型的概率特性规划异常不可避免。
此类异常通常源于规划阶段出现的幻觉现象。
Park等[74]指出幻觉表现为系统在解释待执行操作的不确定性时错误预测自主系统的可行性。
Kwon等人[55]观察到LLM常产生与前期推理相悖的行动方案。
Wang等人[97]与Ren等人[82]指出LLM这类生成式模型极易产出不合逻辑且错误的规划方案。
Hu等人[46]将幻觉定义为与不存在实体如错误工具或参数的交互行为。
综上所述规划异常显著影响任务规划阶段常导致任务失败因此亟需重点关注。
**
****操作异常。
**在智能体系统中初始操作通过函数调用实现。
然而由于接口非标准化和不一致等问题操作异常容易发生。
WANG 等[98]指出函数调用实践中的挑战如延迟、API选择错误和系统故障。
Wu等人[106]指出函数调用存在越狱风险攻击者可构造特殊请求诱使LLM调用敏感函数或绕过限制。
MCP的出现已实现LLM与工具交互的标准化。
然而MCP并非万能良方在实际应用中MCP服务器的配置变更常导致操作异常[91]。
**
****记忆异常。
**如前所述智能体系统的记忆分为短期记忆与长期记忆。
短期记忆指大型语言模型的上下文范围。
即便当前大型语言模型的上下文范围不断扩展仍常无法满足任务需求。
因此许多智能体框架采用滑动窗口管理上下文这可能导致重要初始信息如任务完成指令的丢失。
即使LLM上下文容量满足任务需求刘等[65]的研究表明LLM常会忽略长上下文中段的信息。
PI-LLM[95]也证实了LLM在工作记忆方面存在瓶颈。
**环境异常。
**随着智能体系统的规模持续扩大它们消耗了大量资源尤其当智能体在本地执行资源密集型操作时。
这可能导致环境相关的异常例如资源不足或CPU使用率过高。
2智能间异常**
任务规范异常。
**Cemri等人[11]指出许多任务层面的失败源于任务定义不清例如提示语不够明确。
Altmann等人[2]强调当任务定义不完善时即使每个智能体的个体行为相对合理也容易导致追逐和阻塞等情况。
SentinelAgent[41]指出当任务描述或提示未能充分涵盖潜在协作模式时智能体可能偏离目标、形成串通或出现提示注入等不可预见行为。
因此在执行前阶段评估任务描述的完整性并在执行阶段进行反馈调整是至关重要的操作步骤。
**
安全异常。
**尽管已开发出A2A[34]和ACP[51]等协议来标准化代理之间的通信但它们仅确保不同代理能使用相同协议进行通信并未解决协议整体的安全性问题。
Frost等人[31]指出在现实中的智能体系统中某些智能体可能遭受恶意攻击导致其频繁发送请求或消息类似于分布式拒绝服务DDoS攻击。
He 等[39]提出针对智能体系统的特定攻击方法如图5所示这些攻击既可针对智能体本身也可针对智能体间的通信。
图5 不同类型的攻击**
通信异常。
**正如Bronsdon[10]所强调的在代理间消息交换过程中常会出现通信异常。
这些异常具体表现为消息风暴–由过量消息传递引发可能导致资源耗尽和延迟增加最终造成任务失败。
AgentPrune[112]同时指出消息冗余问题强调过量消息并不能提升智能体系统的效率反而会因冗余导致智能体迷失方向。
**
信任异常。
**ATrust[38]指出大型语言模型LLM代理对所有接收到的消息一视同仁。
He等[40]强调LLM代理在接受其他代理的消息并将其纳入自身上下文时既不进行一致性验证也不考虑这些消息是否可信。
然而不同代理的基础模型可能存在差异加之记忆能力等因素的差别它们在特定领域的处理能力也可能存在显著差异。
例如代码代理的编程能力明显强于通用型代理。
因此不应统一对待不同代理的消息。
盲目信任所有代理消息可能导致信息冲突或错误反之若完全不信任任何代理系统又将丧失协作能力。
代理间的信任问题作为影响协作效率的关键因素亟待解决。
**
涌现行为异常。
**Sanjeev[83]指出当多个智能体相互作用时会产生宏观模式或行为这些模式或行为在单独分析智能体时难以预测或解释即为涌现行为。
布朗斯顿[10]认为涌现行为异常源于多实体间的复杂交互由此产生的系统级行为无法归因于任何单一实体。
因此涌现行为异常虽属于相对较少被理解的异常类别却可能引发严重后果。
**
终止异常。
**Cemri等[11]与微软[70]均将过早终止异常视为智能体系统中的重要异常类别。
Smurfs[14]指出在单智能体模式下深度优先搜索决策树DFSDT常面临过早终止问题–系统在未完成多步推理时便过快调用终止工具。
该问题会严重影响复杂任务的完整性与逻辑一致性。
Zhang等[116]将过早终止识别为多智能体系统中常见且可精确定位的故障根源。
4 智能体系统运维本节将深入探讨AgentOps的起源、定义及具体范畴。
本文将首先追溯运维的演变历程该历程自然引出了AgentOps概念。
随后本文将概述AgentOps与传统运维在不同阶段的主要差异阐明传统运维为何无法应对智能体系统的挑战。
最后将给出AgentOps的精确定义。
1 运维演变如图6所示运维技术历经时代演进持续进步。
从早期的手动运维到后期的基于规则的自动化运维每个阶段都标志着重大飞跃。
机器学习的迅猛发展尤其是深度学习的突破进一步推动了运维技术的革新。
近年来大型语言模型LLM强大的推理与分析能力催生了越来越多采用LLM智能体实现自动化运维的方法。
图6 操作演进历程除了运维技术的演进运维对象也发生了转变。
最初运维工作仅聚焦于传统软硬件系统如微服务系统。
随着机器学习的快速发展模型规模日益庞大训练与推理等过程中故障频发。
这催生了管理机器学习模型的各类运维技术–即MLOps。
近年来大型语言模型LLM代理已能自主完成任务促使众多服务采用智能体替代传统模式。
由此智能体系统已成为当今行业服务构建的主流方式。
然而智能体系统与传统系统存在本质差异传统系统行为由底层代码决定具有确定性而智能体系统基于概率模型构建其推理与行动具有随机性。
因此智能体系统的运维方式与传统系统截然不同直接套用传统技术并不可行。
为此本文提出AgentOps智能体运维概念下文将详细阐述传统系统运维与 AgentOps的区别。
2传统系统运维与智能体系统运维的区别
4.
1****操作时间线如图7所示该行业通常将操作划分为四个阶段监控、异常检测、根本原因分析和解决。
l**监控**在监控阶段可观测性工具被部署以尽可能全面地从多维度收集系统运行时数据。
这包括指标、日志、追踪等内容为后续异常检测等流程提供关键支持。
**异常检测**当系统故障发生时必须利用监控数据及时发现异常。
这有助于在短时间内阻止故障进一步蔓延从而最大限度地降低潜在影响。
**根本原因分析**当系统发生故障时问题可能通过不同组件的调用而蔓延导致多个组件触发警报。
唯有通过根本原因分析才能找出问题根源从而实现快速解决。
**解决方案**通过上述流程确定根本原因后可通过通知站点可靠性工程师SRE或采用自动化修复方法解决问题。
图7 传统系统操作与智能体系统操作的比较
4.
2****传统系统运维与智能体系统运维的差异如图7所示尽管传统系统运维与代理系统运维的时间线相似但两者在每个阶段都存在显著差异。
这正是需要建立全新运维框架–AgentOps的原因。
下文将详细阐述这些差异。
**监控**主要差异在于监控数据的类型。
基于OpenTelemetry[8]的传统系统运行监控侧重于指标、日志和追踪数据这些数据反映系统的实际运行状态可用于系统状态的逆向工程。
然而对于代理系统而言根本区别在于服务由大型语言模型LLM代理提供其本质具有随机性。
这要求对LLM代理的相关模块进行额外监控。
LLM代理主要由语言模型和代理组件构成。
针对语言模型部分监控需涵盖模型参数、注意力图、令牌对数等相关状态而代理组件则必须在每个步骤监控检查点如内存和环境状态。
监控这些代理层级的检查点不仅能更清晰地把握代理系统状态还便于执行回滚操作–这正是代理系统相较传统系统在可操作性方面的重要优势。
**异常检测**差异主要体现在异常检测的应用时机上。
传统系统运维应用于确定性系统时依赖的数据通常被认为准确可靠可直接作为异常检测的输入。
而智能体系统通过 LLM 智能体生成数据其正确性无法保证。
因此异常检测不仅需验证数据生成的合理性还需利用这些数据进一步评估系统状态。
**根本原因分析**差异主要体现在定位的对象和粒度层面。
传统根本原因分析侧重于识别服务、Pod或环境层面的问题甚至深入代码层面。
而对于代理系统由于涉及LLM代理定位可能需要识别代理的具体行为或在 LLM 处理流程的特定步骤中识别幻觉现象。
**决议**主要差异在于决议过程。
在传统系统运行中一旦明确故障的精确位置和原因即可通过基于相关领域知识的确定性程序迅速解决问题。
而在智能体系统中由于内在随机性解决过程具有长期性和复杂性需要持续测试并可能回滚利用监测阶段的相关数据最终才能达到最优状态。
例如若智能体系统异常的根本原因是提示词不合理则可能需要持续进行提示词优化测试。
3****结论基于上述差异本文将代理化系统运维AgentOps定义为涵盖执行前、执行中及执行后阶段的综合运维框架。
与传统系统运维类似AgentOps同样包含四个阶段监控、异常检测、根本原因分析及问题解决。
AgentOps与传统系统运维如AIOps的根本差异在于运维主体的本质。
这种主体性质的区别导致各阶段呈现显著差异每个阶段都需要全新的技术解决方案。
5 监控智能体系统
1****监测数据示意图
5.
1****传统数据在传统监控数据中使用OpenTelemetry[8]收集的指标、日志和追踪数据同时存在于微服务系统和代理系统中。
然而如前所述代理系统中的数据与微服务系统中的数据存在显著差异。
传统微服务系统通常侧重于监控系统指标和应用性能监控APM指标。
然而在融合了LLM智能体的智能体系统中则引入了与LLM及智能体相关的额外指标例如LLM延迟和工具调用延迟。
此外由于成本是智能体系统的重要考量因素还包含了各类成本相关指标如消耗的令牌数量。
在当前垂直行业的智能体系统应用中RAG技术不可或缺因此也需要相关的RAG指标。
关于追踪如图8所示微服务追踪通常指通过API 调用实现的服务间交互。
这些API调用的参数由用户操作或预定义系统规则决定因此相对稳定且直观。
但在智能体系统中每个智能体的输入输出及其与工具的交互包括智能体间调用往往由大型语言模型生成引入了高度不确定性。
这些不确定性正是追踪数据的核心要素——因此在智能体系统中追踪不仅涵盖智能体与工具间的关联关系更包含每个步骤的输入输出。
由此可见追踪数据是智能体系统的关键要素。
在日志方面如图9所示微服务系统与代理系统具有相当的相似性。
微服务系统的日志记录服务整体的行为而代理系统的日志则捕捉代理的行为。
图8 微服务系统与智能体系统的追踪数据对比图9 日志数据示例
5.
2****模型数据随着数据安全问题的日益凸显越来越多的在线代理系统选择采用本地部署的开源大型语言模型作为推理引擎[36]。
若将LLM纯粹视为黑盒模型而忽略其内部状态本文仅能观察其输入与输出。
此类信息极为有限不足以检测LLM内部发生的异常。
因此越来越多的方法开始将LLM视为白盒模型旨在从其隐藏层和令牌对数值中收集内部参数[9, 49]。
5.
3****检查点数据相较于微服务系统智能体系统具备更强的控制力能够通过数据复现任意时刻的系统状态。
这为代理系统内的运维工作提供了显著优势。
如图10所示本文可以记录智能体系统在不同时间点会记录包括内存环境等检查点信息。
当发生故障时这些检查点数据使本文能够回滚至先前状态解决问题并最终获得正确结果。
图10 检查点数据的收集及其在回滚过程中的应用
2 当前****监测方法基于大型语言模型的智能体系统的可观测性工具也在快速发展。
这些工具主要遵循前述收集指标、日志和追踪数据的原则。
大多数代理系统可观测性工具集成了追踪、指标、数据集、实验、评估、提示优化及管理等功能。
LangDB[56]作为首个完全用Rust开发的可观测性工具通过路由器优化实现成本控制具备更高效率和内部集成性。
Langfuse[57]支持OpenTelemetry集成是开源社区中最活跃的可观测性工具。
Helicone[42]除观测工具外还整合缓存管理以降低延迟并节约资源通过网关回退等机制保障代理系统的安全性和可扩展性。
HoneyHive[43]采用分布式追踪技术能有效处理多模态系统支持自定义追踪范围以聚焦特定系统维度。
PromptLayer[68]最初为提示优化而设计现将可观测性作为任务完成的必要组件涵盖提示排序与评分等功能。
TruLens[94]作为 Python 包可无缝对接LLamaIndex等多种框架并通过人类反馈高效迭代优化智能体系统。
OpenLLMetry[93]遵循OpenTelemetry 标准兼容各类框架但缺乏提示优化与评估测试等功能。
LangWatch[58]与 Literal AI[64]作为标准可观测性工具具备可观测性评估与开发功能其中LangWatch已集成 MCP 服务器。
源自传统深度学习的MLFlow[21]支持在智能体系统中使用自定义指标。
DeepEval[20]主要侧重于评估缺乏可观测性功能而AgentOps[1]则强调对整个系统的运行监督同时具备可观测性功能。
3****挑战尽管存在众多适用于代理系统的可观测性工具挑战依然存在。
**海量数据**随着代理系统持续扩展代理数量不断增加每个代理都会产生大量数据。
当加入模型数据和检查点数据时这一挑战尤为突出。
如此庞大的数据集在采集、存储和分析方面都面临着重大挑战。
**缺乏多样化的监控数据**如前所述与传统微服务系统相比智能体系统存在日志、追踪和指标数据不足的问题。
**安全漏洞**智能体程序能够自主调用可能修改内存的工具。
若缺乏适当的监控与警报机制极易导致数据泄露及其他损失。
因此在完善代理程序监控方面仍有很长的路要走。
如何学习AI大模型如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】这是一份大模型从零基础到进阶的学习路线大纲全览小伙伴们记得点个收藏第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。
100套AI大模型商业化落地方案大模型全套视频教程200本大模型PDF书籍学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。
因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。
LLM面试题合集大模型产品经理资源合集大模型项目实战合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】