测试框架

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

引言 LLM应用的测试与传统软件测试截然不同：输入空间无限大、输出不确定、质量主观。2026年，LLM自动化测试已经形成了一套完整的方法论和工具链。本文将系统介绍如何构建LLM自动化测试体系。 LLM测试的挑战 挑战一：输入空间无限 传统软件的输入是结构化的（如表单字段），而LLM的输入是自由文本，可能的组合无限多。 挑战二：输出不确定 同一个输入，LLM可能给出不同的输出（即使temperature=0，不同版本也可能不同）。 挑战三：质量主观 “好的回答"的定义因任务、用户、上下文而异。 挑战四：成本高 每次测试都需要调用LLM API，大规模测试成本可观。 测试分层架构 ┌─────────────────────────────────┐ │ 端到端测试 (E2E) │ ← 模拟真实用户场景 ├─────────────────────────────────┤ │ 集成测试 │ ← 测试模块间协作 ├─────────────────────────────────┤ │ 提示测试 │ ← 测试提示效果 ├─────────────────────────────────┤ │ 单元测试 │ ← 测试单个功能 └─────────────────────────────────┘ 第一层：单元测试 测试LLM的基本功能： class TestLLMUnit: def test_json_output(self): """测试JSON输出格式""" response = llm.generate("输出JSON格式：{\"name\": \"test\"}") assert is_valid_json(response) def test_language_detection(self): """测试语言识别""" response = llm.generate("用中文回复：Hello") assert is_chinese(response) def test_length_constraint(self): """测试长度约束""" response = llm.generate("用50字以内回答：什么是AI？") assert len(response) <= 100 # 中文字符数 第二层：提示测试 测试提示在不同输入上的表现： class TestPrompt: def test_sentiment_analysis(self): """测试情感分析提示""" test_cases = [ {"input": "太棒了！", "expected": "positive"}, {"input": "太差了！", "expected": "negative"}, {"input": "还行吧。", "expected": "neutral"}, ] for case in test_cases: response = llm.generate(prompt.format(input=case["input"])) assert case["expected"] in response.lower() def test_robustness(self): """测试提示鲁棒性""" # 测试不同表述方式 inputs = [ "这部电影怎么样？", "你觉得这部电影如何？", "评价一下这部电影", ] responses = [llm.generate(prompt.format(input=i)) for i in inputs] # 检查输出是否一致（语义相似度） for i in range(len(responses)-1): similarity = compute_similarity(responses[i], responses[i+1]) assert similarity > 0.7 第三层：集成测试 测试多个模块协作： ...