《Agentic Design Patterns》第 19 章导读评估与监控本文是对开源书籍《Agentic Design Patterns》第 19 章的解读与导读内容忠实呈现原文并附个人思考。原书在线阅读https://adp.xindoo.xyz/ 翻译项目代码仓库https://github.com/xindoo/agentic-design-patterns前面我们聊了怎么让智能体更聪明——规划、推理、协作、工具使用……但有一个灵魂拷问你怎么知道你的智能体表现好不好传统软件有单元测试、集成测试、性能测试——输入什么、输出什么清清楚楚。但 AI 智能体不一样它是概率性的、非确定性的同一个问题每次回答可能都不一样。它还会调用工具、跟环境交互行为轨迹千变万化。第 19 章讲的就是评估和监控——怎么系统地衡量智能体的性能、监控目标进展、检测操作异常。一、为什么评估和监控这么难先想一下你怎么评估一个客服聊天机器人的好坏传统思路写一堆测试用例输入问题检查输出——但输出是自然语言啊请问怎么退款和我要退货退款表达的是同一个意思但字符串完全不一样。精确匹配根本行不通。而且智能体不只是回答问题它还会调用工具查订单、改地址、退款项多轮对话用户说不清智能体得追问处理异常订单不存在怎么办跟其他系统交互这就导致传统的软件测试方法完全不够用。我们需要全新的评估体系。书中列举了 7 个典型应用场景场景说明实时性能跟踪持续监控生产环境中智能体的准确性、延迟、资源消耗A/B 测试并行比较不同版本/策略的性能找出最优方案合规与安全审计自动生成审计报告跟踪道德准则、监管要求的遵守情况企业系统治理AI合约——为 AI 委派的任务编纂目标、规则和控制机制漂移检测监控输出质量是否随时间退化数据分布变化、环境变化异常检测识别异常或意外操作可能表明错误、攻击或涌现的不良行为学习进度评估跟踪学习型智能体的学习曲线、技能改进、泛化能力二、基础评估指标1. 响应准确性评估最基础的评估是检查智能体输出的正确性。但正确性怎么衡量一个最简单的版本是精确匹配defevaluate_response_accuracy(agent_output:str,expected_output:str)-float:计算智能体响应的简单准确度分数。return1.0ifagent_output.strip().lower()expected_output.strip().lower()else0.0但这个方法问题很大——法国首都是巴黎和巴黎是法国的首都意思完全一样但字符串不匹配就会被判 0 分。真实场景中需要更高级的指标字符串相似度Levenshtein 距离、Jaccard 相似度关键词分析检查关键词的存在/缺失语义相似度用嵌入模型计算余弦相似度LLM-as-a-Judge让另一个 LLM 来评估细微的正确性和有用性RAG 特定指标忠实性答案是否基于检索到的上下文、相关性2. 延迟监控响应速度直接影响用户体验。特别是在实时或交互式环境中延迟过高会严重损害用户体验。实际应用中延迟数据不能只打印到控制台需要记录到持久存储结构化日志文件JSON 格式时间序列数据库InfluxDB、Prometheus数据仓库Snowflake、BigQuery、PostgreSQL可观测性平台Datadog、Splunk、Grafana Cloud3. Token 使用量跟踪LLM 驱动的智能体成本主要来自 token 消耗。输入输出 token 越多账单越贵。classLLMInteractionMonitor:def__init__(self):self.total_input_tokens0self.total_output_tokens0defrecord_interaction(self,prompt:str,response:str):# 实际场景用 LLM API 的 token 计数器或 tokenizerinput_tokenslen(prompt.split())output_tokenslen(response.split())self.total_input_tokensinput_tokens self.total_output_tokensoutput_tokens跟踪 token 使用量有两个好处成本管理知道钱花在哪了优化资源分配改进提示词识别提示词工程或响应生成中的优化空间三、LLM-as-a-Judge用 AI 评估 AI“有用性”、质量这些主观品质用客观指标很难衡量。这时候就有了一个巧妙的思路让一个 LLM 来评估另一个 LLM 的输出。这就是LLM-as-a-Judge方法。它的优势是一致同样的标准不会今天松明天紧高效可以大规模并行评估可扩展想加多少评估维度就加多少书中给了一个法律调查问题质量评估的完整示例用 Gemini 模型当法官从五个维度打分评估维度说明清晰性和精确性问题是否模糊、歧义、令人困惑中立性和偏见是否有引导性或有偏见的语言相关性和焦点是否与调查目标直接相关完整性是否提供了回答所需的足够上下文受众适当性术语难度是否适合目标受众每个维度 1-5 分最后输出 JSON 格式的结构化结果整体分数、理由、详细反馈、关注点、建议行动。classLLMJudgeForLegalSurvey:使用生成式 AI 模型评估法律调查问题的类。def__init__(self,model_namegemini-1.5-flash-latest,temperature0.2):self.modelgenai.GenerativeModel(model_name)self.temperaturetemperaturedefjudge_survey_question(self,survey_question:str)-Optional[dict]:full_promptself._generate_prompt(survey_question)responseself.model.generate_content(full_prompt,generation_configgenai.types.GenerationConfig(temperatureself.temperature,response_mime_typeapplication/json))returnjson.loads(response.text)当然LLM-as-a-Judge 也不是完美的——它受限于法官LLM 自身的能力可能忽略中间步骤也可能有自己的偏见。三种评估方法对比评估方法优势劣势人工评估能捕捉细微行为、考虑主观因素难以扩展、昂贵、耗时LLM-as-a-Judge一致、高效、可扩展可能忽略中间步骤、受 LLM 能力限制自动化指标可扩展、高效、客观在捕获完整能力方面可能有局限四、智能体轨迹评估评估智能体不能只看最终输出还要看它是怎么走到那里的——也就是它的轨迹trajectory。轨迹就是智能体达到目标所采取的步骤序列。评估轨迹可以检查决策质量好不好推理过程对不对工具有没有用对效率高不高比如一个处理客户产品查询的智能体理想轨迹应该是确定用户意图使用数据库搜索工具审查结果生成报告把智能体的实际操作和理想轨迹对比就能发现错误和低效率。对比方法有很多种方法说明严格程度精确匹配要求与理想序列完全一致最高按序匹配正确操作按顺序允许有额外步骤中等任意顺序匹配正确操作以任何顺序允许额外步骤较低精确度测量预测操作的相关性灵活召回率测量捕获了多少基本操作灵活单工具使用检查特定操作是否发生最低选哪种方法取决于场景——高风险场景可能要求精确匹配灵活场景用按序或任意顺序就行。测试文件 vs 评估集文件ADKGoogle 的 Agent Development Kit提供了两种评估文件格式测试文件单个简单的智能体交互JSON 格式适合单元测试快速执行评估集文件多个可能很长的会话适合模拟复杂多轮对话和集成测试每个测试/评估包含多个回合每个回合包括用户查询、预期的工具使用、中间智能体响应、最终响应。五、多智能体评估评估团队表现评估多智能体系统就像评估团队项目——不只要看每个人干得怎么样还要看整个团队配合得好不好。四个关键问题智能体是否有效合作比如航班预订智能体成功订完票后有没有正确把日期和目的地传给酒店预订智能体传错了酒店就订错了时间。它们是否制定了好计划并坚持执行计划是先订航班再订酒店如果酒店智能体在航班确认前就尝试订房那就是偏离计划了。还要检查智能体会不会卡住——比如无休止地搜完美的租车永远不进入下一步。是否为正确的任务选择了正确的智能体用户问天气系统应该用专门的天气智能体提供实时数据而不是通用知识智能体只给夏天通常很温暖这种废话。添加更多智能体是否真的提高了性能加了个餐厅预订智能体是让整体旅行规划更好更高效了还是造成冲突、拖慢系统如果是后者说明可扩展性有问题。六、从智能体到高级承包商书中提出了一个很有意思的演进方向从简单的 AI 智能体演进为高级承包商Contractor。当今的 AI 智能体靠简短模糊的指令运行——做 demo 还行放到生产环境就很脆弱因为歧义会导致失败。承包商模型通过建立用户和 AI 之间严格的正式化关系来解决这个问题——就像人类世界的法律服务协议一样明确定义、双方同意。四个关键支柱1. 正式化合约不是简单的提示词而是详细的规范作为任务的唯一真实来源。比如财务分析任务的合约不会只说分析上个季度的销售而是会要求一份 20 页的 PDF 报告分析 2025 年第一季度欧洲市场销售包含五个特定的数据可视化与 2024 年第一季度的比较分析基于提供的供应链中断数据集的风险评估明确到可交付成果、精确规格、可接受的数据源、工作范围、预期成本和完成时间——结果客观可验证。2. 动态协商和反馈生命周期合约不是静态命令而是对话的开始。承包商智能体可以分析初始条款并进行协商。比如合约要求使用智能体无法访问的专有数据库它可以返回反馈“指定的 XYZ 数据库不可访问。请提供凭据或批准使用替代公共数据库这可能会略微改变数据的粒度。”协商阶段还允许智能体标记歧义或潜在风险——在执行开始之前解决误解防止代价高昂的失败。3. 以质量为中心的迭代执行承包商优先考虑正确性和质量而不是低延迟。它基于自我验证和纠正的原则运作。比如代码生成合约智能体不会只是写代码它会生成多个算法方法根据合约定义的单元测试编译和运行它们对性能、安全性、可读性等指标评分只提交通过所有验证标准的版本4. 通过子合约的层次化分解复杂度很高的任务主承包商智能体充当项目经理把大目标分解成更小的子任务——通过生成新的正式子合约。比如构建电商移动应用的主合约可以分解为设计 UI/UX开发用户身份验证模块创建产品数据库架构集成支付网关每个子合约都是完整独立的有自己的可交付成果和规格可以分配给其他专门的智能体。这个承包商模型的思路非常值得深思。它本质上是把软件工程中的需求规格说明书、“合同管理”、项目分解等成熟实践引入到 AI 智能体的交互中。对于高风险、高价值的任务这可能是未来的方向。七、Google ADK 的评估支持Google 的 ADKAgent Development Kit提供了三种评估方式基于 Web 的 UIadk web交互式评估和数据集生成可视化地创建会话并保存到评估集pytest 编程集成通过AgentEvaluator.evaluate调用整合到测试管道中适合 CI/CD命令行界面adk eval自动化评估适合定期构建和验证流程八、速览评估和监控设计模式维度说明问题背景Agentic 系统在复杂动态环境中运行性能可能随时间退化。概率性和非确定性意味着传统软件测试不足以确保可靠性解决方案标准化评估和监控框架——定义明确指标准确性、延迟、token 使用、分析智能体轨迹、采用 LLM-as-a-Judge、建立反馈循环实践建议生产环境部署、A/B 测试比较、合规审计、漂移检测、评估复杂行为轨迹 主观质量时使用九、关键要点总结超越传统测试评估智能体需要在真实环境中持续测量其有效性、效率和合规性基础指标三件套响应准确性、延迟监控、token 使用跟踪——每个智能体系统都得有轨迹评估很重要不只要看结果还要看过程——把实际操作和理想路径对比发现错误和低效率LLM-as-a-Judge 是利器主观品质有用性、质量的评估让 AI 来评 AI一致且可扩展多智能体要看协作团队表现不等于个体表现之和要检查合作质量、计划执行、角色匹配、可扩展性承包商模型是未来方向从简单提示词到正式合约协商、分解、自我验证——让 AI 从不可预测的工具变成可问责的系统我的思考这一章让我感触最深的是**“从智能体到承包商”**这个概念。现在很多人做 AI 应用思路还是写个好提示词就行。但真要上生产你会发现歧义、边界情况、可靠性、可审计性……全是问题。承包商模型提出的四个支柱——正式合约、协商反馈、迭代执行、层次分解——其实就是把人类社会中已经验证过的工程项目管理方法论移植到 AI 系统中来。另外LLM-as-a-Judge 也是一个非常实用的技术。以前评估 AI 输出质量只能靠人贵且慢。现在用 AI 评 AI虽然不是 100% 准确但胜在快、便宜、一致可以作为第一道筛选关卡。当然评估和监控是个大学问——数据漂移怎么检测异常行为怎么发现多智能体的协作效率怎么量化这些问题都还在探索中。但至少我们已经有了一个框架和起点。下一章我们聊第 20 章——优先级排序。当智能体面临一堆任务、目标冲突、资源有限时该先做什么后做什么敬请关注