AI Agent智能评估框架：从主观感知到数据驱动的14维度量

1. 项目概述：从“感觉”到“度量”的AI Agent智能评估革命

在AI Agent开发领域，我们常常陷入一种主观的困境：今天调整了提示词，明天优化了工作流，但Agent到底变“聪明”了多少？是“感觉上”更好了，还是真的在核心能力上有了可量化的提升？过去，我们依赖零星的用户反馈、模糊的定性判断，或者跑几个特定的测试用例来寻求安慰。这种评估方式不仅不可靠，更难以支撑持续、系统的能力迭代。smartness-eval项目的出现，正是为了解决这个痛点——它旨在将AI Agent的智能评估，从一种“玄学”转变为一门“科学”。

简单来说，smartness-eval是一个专为AI Agent设计的、多维度的智能评估框架。它不满足于单一维度的打分，而是构建了一个包含14个核心维度的评估体系，通过自动化测试、运行时遥测数据和反作弊探针三种信号的融合，最终输出一个结构化的、可重复的、带有置信区间的智能度评分报告。这个框架与CLEAR、T-Eval、Anthropic等行业领先的评估标准对齐，但其设计初衷更贴近开发者的日常：轻量、可集成、能真实反映Agent在复杂环境下的综合表现。

无论你是在打磨一个客服对话Agent，一个自动化工作流Agent，还是一个复杂的决策支持系统，smartness-eval都能为你提供一面清晰的镜子。它告诉你，你的Agent在“理解用户意图”、“逻辑推理”、“规划任务”、“控制幻觉”等关键能力上分别得了多少分，与上周相比是进步还是退步，以及下一步最应该优先优化哪个短板。这不再是猜测，而是基于数据和规则的度量。

1.1 核心设计理念：三位一体的评估信号

为什么传统的单点测试不够？因为Agent可能会“应试”——针对已知的测试集进行过拟合，但在真实、多变的环境中表现不佳。smartness-eval采用了三种互补的信号源，构建了一个更健壮、更抗干扰的评估体系：

1. 任务测试（Task Tests）：这是评估的“骨架”。框架内置了34项自动化测试命令，覆盖了14个评估维度。例如，测试“理解”维度时，会构造包含歧义、省略或隐含约束的用户指令；测试“规划”维度时，会给出一个多步骤的复杂任务，检查Agent是否能正确分解并排序。这些测试提供了标准化的能力基线。

2. 运行时遥测（Runtime Telemetry）：这是评估的“血肉”。框架会主动分析Agent在真实运行中产生的日志和数据，包括响应延迟（P50/P95）、错误自动修复率、推理知识库的条目增长、定时任务（Cron）的健康状态等。这部分数据反映了Agent在真实战场上的“实战表现”，避免了实验室环境下的性能失真。

3. 反作弊探针（Anti-gaming Probes）：这是评估的“免疫系统”。为了防止评估被“刷分”，框架会在评估时随机注入一些非常规的、未在测试集中出现过的输入或干扰项。如果Agent的得分在加入探针后显著下降，说明其能力可能过于依赖对已知测试模式的记忆，而非真正的泛化能力。这确保了评估结果的可靠性和泛化性。

将这三种信号按权重融合，最终计算出的总分和分维度得分，才是一个更接近Agent真实智能水平的指标。这种设计理念，使得smartness-eval不仅仅是一个测试工具，更是一个持续监控和引导Agent能力演进的“仪表盘”。

1.2 适用场景与目标用户

这个框架主要服务于以下几类人群：

• AI Agent开发者/研究者：需要客观、可重复的指标来对比不同模型、提示词工程（Prompt Engineering）或工作流架构的效果。
• 产品经理或项目负责人：希望用数据驱动的方式跟踪Agent能力的迭代进度，明确每个开发周期的重点改进方向。
• 质量保障（QA）工程师：为AI产品建立系统化的质量评估体系，实现自动化回归测试和能力基线守护。
• 开源AI项目维护者：为社区提供一个透明的、标准化的能力评估方案，方便用户了解和比较不同版本或分支的能力差异。

如果你正在使用或基于类似OpenClaw这样的AI Agent框架进行开发，并且厌倦了“拍脑袋”式的改进评估，那么smartness-eval将是你工具箱中一个强有力的补充。它让智能的增长，变得可见、可管、可优化。

2. 深度解析14维评估体系：你的Agent到底在考什么？

smartness-eval的评估体系是其核心价值所在。它将一个模糊的“智能”概念，拆解为7个主维度和7个扩展维度，共计14个可观测、可量化的侧面。每个维度都有明确的定义、0-5分的详细量规（Rubric）以及对应的数据来源。理解这些维度，是正确解读评估报告、制定优化策略的关键。

2.1 七大主维度：衡量Agent的基础核心能力

这七个维度构成了Agent智能的基石，侧重于其在处理单次交互或任务时所展现的基础认知与执行能力。

1. 理解（Understanding，权重9%）：评估Agent能否准确捕捉用户的真实意图、识别指令中的所有显性和隐性约束、并在多轮对话中保持上下文的一致性。例如，用户说“把上个月销售数据里最高的三个找出来，做成图表，但不要包含测试部门的数据”，Agent需要同时理解时间范围（上个月）、操作（找最高、做图表）、过滤条件（排除测试部门）以及输出格式（图表）。

   • 数据来源：意图识别测试的准确率、从消息分析日志中抽样的上下文连贯性得分。

2. 分析（Analysis，权重9%）：评估Agent面对复杂问题时，能否进行有效的分解，识别出任务内部的依赖关系，并输出结构化的中间结果。这关乎Agent将混沌问题转化为可执行步骤的能力。例如，面对“优化网站加载速度”这个模糊需求，分析能力强的Agent会将其分解为“分析当前性能指标”、“识别资源加载瓶颈”、“评估CDN配置”、“提出具体优化建议（如图片压缩、代码拆分）”等子问题。

   • 数据来源：问题分解测试的结构化输出质量、依赖关系识别的准确率。

3. 思考（Thinking，权重9%）：这是一个更高阶的认知维度，评估Agent是否具备风险意识、能否进行自我检查（Self-Check）、以及是否能在决策前进行对抗性推演（思考“如果……会怎样”）。例如，在执行一个删除文件的操作前，思考能力强的Agent会主动确认文件路径、评估操作影响、甚至建议先进行备份。

   • 数据来源：风险检测测试的通过率、从反思报告（Reflection Reports）中分析出的自省频率和质量。

4. 推理（Reasoning，权重13%）：这是逻辑能力的核心体现。评估Agent构建逻辑链条的完整性、每一步是否有证据或数据支撑、以及其输出结果的置信度校准是否合理（即高置信度的回答是否真的更准确）。例如，回答“为什么销售额下降？”时，不应直接给出单一原因，而应展示从“数据下降趋势”到“可能因素（市场、产品、运营）”再到“相关性分析”的推理过程。

   • 数据来源：逻辑链完整性测试得分、推理知识库（Reasoning Store）中高置信度条目的比例和总量。

5. 自我迭代（Self-iteration，权重9%）：评估Agent从错误中学习和进化的能力。这包括识别并修复自身错误的效率、将成功经验总结为可复用模式（Pattern）的速度，以及这些模式知识的新鲜度（是否及时更新）。一个具有强自我迭代能力的Agent，其错误率应随时间下降，模式库应持续增长。

   • 数据来源：错误追踪器（Error Tracker）中的自动修复率、模式库（Pattern Library）的条目增长率和最近更新时间。

6. 对话沟通（Dialogue，权重9%）：评估Agent输出的“可读性”和“可用性”。包括回复是否清晰无歧义、是否完整回答了用户的所有子问题、给出的建议或步骤是否具备可操作性（Actionable），以及语气是否与对话场景和用户身份相匹配。

   • 数据来源：对话清晰度与完整性测试得分、LLM裁判（若启用）对回复可操作性的主观评分。

7. 响应时长（Responsiveness，权重5%）：衡量Agent的执行效率。虽然智能更重要，但过长的延迟会严重影响用户体验。该维度关注P50（中位数）和P95（高分位）延迟、超时请求的比例，以及整个API调用链路的健康度。

   • 数据来源：响应延迟指标（Response Latency Metrics）中的P50/P95值、超时率。

2.2 七大扩展维度：衡量Agent的进阶与稳健性

这七个维度在基础能力之上，进一步考察Agent在复杂、多变环境下的综合表现和可靠性。

8. 鲁棒性（Robustness，权重7%）：评估Agent在面对噪声输入、超长上下文、边缘案例（Edge Cases）时的稳定性。例如，用户输入包含错别字、无关信息或极其冗长的背景描述时，Agent的核心功能是否依然能正常工作。

   • 数据来源：噪声注入测试的通过率、长上下文处理测试的表现。

9. 泛化能力（Generalization，权重5%）：评估Agent将在一个领域学到的能力，迁移到相似但不同的新领域或新意图上的准确性。这反映了其内部表示和策略的通用性，而非机械记忆。

   • 数据来源：跨领域任务路由（Routing）的准确率、对未见过的意图变体的处理能力。

10. 规划能力（Planning，权重5%）：这是v0.3.0新增的核心维度。评估Agent对于需要多步骤、有前后依赖关系的复杂任务的规划与执行能力。包括：能否正确将宏观任务分解为原子步骤、步骤间的顺序是否合理、能否管理步骤间的依赖（如步骤B需要步骤A的输出）、以及整个工作流的执行连贯性。

    • 数据来源：专门的任务规划测试套件，评估分解的合理性、步骤排序和依赖管理的正确性。

11. 幻觉控制（Hallucination Control，权重6%）：同样是v0.3.0新增的关键维度。评估Agent生成内容的真实性、是否基于已知事实或提供的信息（Grounded），以及在不确定时能否坦然承认而非胡编乱造。这是大模型应用落地中最受关注的挑战之一。

    • 数据来源：事实准确性测试、对无法回答问题的“拒答”率测试。

12. 策略遵循（Policy adherence，权重5%）：评估Agent在行动时，是否严格遵守预设的安全策略、操作约束和伦理指南（通常定义在如AGENTS.md这样的策略文件中）。例如，是否在执行高风险操作前进行了二次确认，是否避免了访问未经授权的资源。

    • 数据来源：安全策略符合性测试、操作约束检查。

13. 工具可靠性（Tool reliability，权重4%）：评估Agent所依赖的外部工具、脚本或服务的健康状态。一个再聪明的Agent，如果它调用的工具总是失败，其整体效用也会大打折扣。这包括脚本的可用性、定时任务（Cron）的成功率、状态文件的完整性等。

    • 数据来源：Cron健康报告（Cron Governor Report）中的错误任务比例、关键工具/脚本的可用性检查。

14. 校准能力（Calibration，权重5%）：评估Agent对其自身答案的“自信程度”是否有清醒的认识。理想情况下，当Agent对其答案非常有信心时（高置信度），这个答案的正确率也应该很高；当它不确定时（低置信度），其错误率可以被容忍。校准能力差表现为“盲目自信”或“过度谦虚”。

    • 数据来源：高置信度答案的实际错误率、Agent表达不确定性（如“可能”、“据我所知”）的恰当性。

实操心得：权重配置的学问框架默认的权重配置（如推理13%，响应时长5%）反映了一种通用的价值取向：认知能力重于执行速度。但在实际使用中，你可以根据自己Agent的定位调整config/config.json中的权重。例如，对于一个实时对话客服Agent，你可能需要适当提高“响应时长”和“对话沟通”的权重；对于一个后台数据分析Agent，则可以更侧重“推理”和“分析”。权重的调整会直接引导优化资源的投向。

3. 实战指南：从安装到生成第一份评估报告

了解了评估体系后，我们进入实战环节。smartness-eval的设计追求开箱即用，但为了获得准确、有意义的评估结果，一些准备工作至关重要。以下步骤将引导你完成从环境准备到生成并解读第一份深度评估报告的全过程。

3.1 环境准备与前置检查

假设你的工作目录是基于OpenClaw V5.1+的AI Agent项目。smartness-eval被设计为一个“技能”（Skill），可以无缝集成到你的项目中。

# 1. 克隆评估框架到你的项目技能目录中 # 通常，OpenClaw项目的技能位于 `skills/` 目录下 cd /path/to/your-openclaw-project git clone https://github.com/xyva-yuangui/smartness-eval.git skills/smartness-eval # 2. 进入评估框架目录 cd skills/smartness-eval # 3. 运行健康检查脚本，确保框架结构完整且与你的项目兼容 python3 scripts/check.py

运行check.py脚本是强烈推荐的第一步。它会检查：

• Python版本（需>=3.9）。
• 必要的目录结构（config/,scripts/,state/等）是否存在。
• 你的OpenClaw工作空间版本是否兼容（需>=V5.1）。
• 评估所需的数据源路径（如state/error-tracker.json）是否可访问。如果某些文件不存在，检查脚本会给出警告，这有助于你提前准备数据或理解后续评估某些维度得分偏低的原因。

3.2 评估模式选择与首次运行

框架提供了三种评估模式，对应不同的评估强度和耗时。对于首次使用，建议从standard模式开始。

# 4. 执行一次标准评估（耗时中等，约运行30项测试，分析7天窗口期的数据） python3 scripts/eval.py --mode standard --format markdown

• --mode standard: 选择标准模式。它会执行大部分测试用例，并分析过去7天的运行时数据，在全面性和耗时之间取得平衡，适合生成每周能力报告。
• --format markdown: 指定输出格式为Markdown。除了默认的JSON格式结果（用于程序化处理），Markdown报告更便于人类阅读和分享。报告将保存在state/smartness-eval/reports/目录下，以日期命名。

首次运行可能会花费几分钟时间，因为它需要执行测试套件、收集并分析你项目中的历史运行时数据。请耐心等待。

注意事项：关于数据源的准备评估的准确性严重依赖于运行时遥测数据。如果你的Agent项目是全新的，或者没有启用相关的日志和状态记录功能（如错误追踪、推理知识库、Cron报告等），那么“自我迭代”、“工具可靠性”等维度的得分可能会是0或很低。这并非框架问题，而是真实反映了当前Agent缺乏这些维度的可观测数据。在优化Agent之前，你可能需要先完善其可观测性（Instrumentation）建设，确保关键行为都被记录。check.py的警告信息是很好的指引。

3.3 解读你的第一份评估报告

运行完成后，你会在终端看到概要输出，同时一份详细的Markdown报告已经生成。我们以一个虚构的示例报告片段为例，讲解如何解读：

# Smartness Eval Report - 2023-10-27 **总体评分: 71.36 (B-)** **置信区间: [71.36, 71.36]** | **模式: standard** | **样本数: 15** ## 主维度得分 | 维度 | 得分 | 评级 | |------|------|------| | 理解 | 85.00 | A | | 分析 | 76.31 | B | | 思考 | 73.50 | B | | 推理 | 74.79 | B | | 自我迭代 | 55.56 | C | | 对话沟通 | 82.50 | A- | | 响应时长 | 63.05 | C | ## 扩展维度得分 | 维度 | 得分 | 评级 | |------|------|------| | 鲁棒性 | 62.14 | C | | 泛化能力 | 70.00 | B- | | 规划能力 | 65.00 | C+ | | 幻觉控制 | 58.33 | C | | 策略遵循 | 77.14 | B+ | | 工具可靠性 | 72.43 | B- | | 校准能力 | 60.69 | C | ## 风险提示 - **高优先级**: 推理知识库中高置信度条目占比低于阈值（<60%），影响推理维度得分可靠性。 - **中优先级**: 有3个Cron任务处于持续失败状态，影响工具可靠性。 - **低优先级**: 过去7天“反思报告”生成数量不足，限制了思考维度的数据来源。 ## 关键证据指标 - **基准测试通过率**: 100.0% - **P50延迟**: 5246 毫秒 - **推理知识库总条目**: 116 - **错误自动修复率**: 0.0% - **Cron任务错误率**: 35.71% ## 优化建议 1. **立即行动**: 检查并修复那3个失败的Cron任务，或考虑将其重构为更可靠的脚本（Thin-script）。 2. **重点提升**: 针对“幻觉控制”（58.33分）和“自我迭代”（55.56分）两个短板维度进行优化。对于幻觉，可以引入更多事实核查步骤和拒答机制；对于自我迭代，请确保错误追踪器已启用并正常工作。 3. **长期建设**: 鼓励Agent更多地使用“最终确定”（finalize）路径来闭环任务，并生成反思报告，这将为“思考”和“校准”维度提供更丰富的数据。

解读要点：

1. 看整体，定等级：总体71.36分（B-）给出了一个宏观定位。置信区间窄（[71.36, 71.36]）说明本次评估结果稳定。
2. 拆维度，找短板：雷达图或表格清晰地展示了强弱项。本例中，“自我迭代”、“幻觉控制”、“响应时长”和“校准能力”是明显的短板（C级）。
3. 读风险，明隐患：“风险提示”部分直接指出了当前系统存在的具体问题，如Cron任务失败、数据不足等，这些都是需要优先解决的工程问题。
4. 查证据，究细节：“关键证据指标”提供了得分的具体依据。例如，P50延迟5246毫秒（约5.2秒）直接导致了“响应时长”得分偏低。
5. 跟建议，定计划：“优化建议”部分给出了从紧急修复到长期建设的 actionable 项目。你可以直接将其转化为近期的开发任务。

3.4 进行深度评估与趋势对比

当你按照建议进行了一轮优化后，如何量化改进效果？这时就需要用到深度评估和趋势对比功能。

# 5. 执行一次深度评估，并与上一次评估结果进行对比 python3 scripts/eval.py --mode deep --compare-last --format markdown

• --mode deep: 深度模式会运行所有测试用例（可能重复多次），并分析长达30天的历史数据，给出最全面、最稳定的评估。耗时最长，适合月度复盘或重大版本发布后的评估。
• --compare-last: 这是核心功能。框架会自动加载上一次评估的结果（存储在state/smartness-eval/history.jsonl中），并在报告中生成一个“趋势对比”章节，用绿色（↑）和红色（↓）箭头直观展示每个维度得分的变化，以及总体分数的升降。

一份典型的趋势对比输出如下：

## 趋势对比 (vs. 2023-10-20) - **总体评分**: 71.36 → **73.15** (+1.79 ↑) - **理解**: 85.00 → 85.00 (→) - **分析**: 76.31 → **78.50** (+2.19 ↑) - **幻觉控制**: 58.33 → **65.00** (+6.67 ↑) *显著提升* - **工具可靠性**: 72.43 → **80.00** (+7.57 ↑) *Cron任务已修复* - **响应时长**: 63.05 → 63.05 (→) *仍需优化*

这个对比能让你清晰地看到，修复Cron任务直接提升了“工具可靠性”近8分，针对幻觉的优化也带来了近7分的增长，而“响应时长”由于未做针对性优化，分数保持不变。这种数据驱动的反馈，是持续迭代的黄金指南。

4. 高级配置与定制化评估

smartness-eval提供了灵活的配置选项，允许你根据自身需求进行定制。核心配置文件位于config/config.json。

4.1 调整维度权重

如前所述，你可以修改权重以适配你的Agent类型。打开config/config.json，找到dimension_weights部分：

{ "dimension_weights": { "understanding": 0.09, "analysis": 0.09, "thinking": 0.09, "reasoning": 0.13, "self_iteration": 0.09, "dialogue_comm": 0.09, "responsiveness": 0.05, "robustness": 0.07, "generalization": 0.05, "planning": 0.05, "hallucination_control": 0.06, "policy_adherence": 0.05, "tool_reliability": 0.04, "calibration": 0.05 } }

修改原则：所有权重之和必须为1.0。提高某个维度的权重，意味着它在最终总分中的影响力变大。建议每次只微调1-2个维度，并观察对总体排名和优化方向的影响。

4.2 自定义测试套件

框架的测试定义在config/task-suite.json中。每个测试都关联到一个具体的维度。如果你有特定的业务场景需要测试，可以在这里添加自定义测试。

{ "tasks": [ { "id": "custom_business_flow", "dimension": "planning", "description": "测试处理我司特有的订单审核流程", "command": ["python3", "scripts/custom_tests/order_audit_test.py"], "weight": 1.0 } ] }

你需要编写对应的测试脚本（如order_audit_test.py），该脚本应能调用你的Agent并验证其行为，最后返回一个0-1之间的分数。将自定义测试加入套件后，它就会在相应的评估模式中被执行。

4.3 启用LLM裁判进行主观评分

框架支持调用大语言模型（如GPT-4、Claude等）作为“裁判”，对Agent的回复进行更细腻的主观评分（例如，对话的友好度、创意的丰富性等）。这是一个可选功能，需要额外的API配置。

# 首先，需要设置你的LLM API密钥（例如OpenAI） export OPENAI_API_KEY='your-api-key-here' # 运行评估时，添加 --llm-judge 参数 python3 scripts/eval.py --mode standard --llm-judge

启用后，框架会在执行部分测试（尤其是对话、创意类测试）时，将Agent的回复和标准答案（或评分标准）一起发送给LLM，要求其给出0-5分的评分。这能引入“人类偏好”的视角，但也会增加评估耗时和成本。注意：网络调用默认是关闭的，--llm-judge是显式开启开关，符合安全模型。

安全模型深度解析smartness-eval在设计上极度重视安全性，因为评估过程需要执行测试命令。其安全模型是多层次的：

1. 解释器白名单：只允许调用python3，防止执行任意shell。
2. 禁止内联代码：完全禁止-c或exec()这类动态代码执行，所有逻辑必须封装在脚本文件中。
3. 路径限制：所有命令路径必须是相对路径，且必须以白名单前缀（scripts/，skills/，state/，benchmarks/）开头，防止访问系统敏感区域。
4. 网络隔离：默认评估过程无任何网络出口。只有显式使用--llm-judge时，才会通过受控的HTTP客户端进行网络调用。 这意味着，只要你的测试脚本本身是安全的，评估框架就不会引入额外的安全风险。在编写自定义测试时，也应遵循这些原则。

5. 集成到CI/CD与常见问题排查

要将智能评估真正融入开发流程，自动化是关键。你可以将smartness-eval集成到你的持续集成（CI）流水线中，例如在每次合并请求（Pull Request）时自动运行快速评估，确保新代码不会导致Agent能力回退。

5.1 在GitHub Actions中集成示例

在你的项目.github/workflows目录下创建一个新的工作流文件，例如smartness-eval.yml：

name: Smartness Eval on PR on: pull_request: branches: [ main ] jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.9' - name: Run Quick Smartness Eval run: | cd skills/smartness-eval python3 scripts/check.py # 运行快速评估，只检查核心能力是否达标 python3 scripts/eval.py --mode quick --format json > eval_result.json # 你可以在这里添加一个检查：如果总分低于某个阈值（如60），则使构建失败 SCORE=$(python3 -c "import json; data=json.load(open('eval_result.json')); print(data['overall']['score'])") if (( $(echo "$SCORE < 60" | bc -l) )); then echo "❌ Smartness score ($SCORE) below required threshold (60)." exit 1 else echo "✅ Smartness score ($SCORE) passed." fi

这个工作流会在每次PR时运行快速评估，并将总体分数与预设阈值比较，实现能力基线的门禁（Gating）。

5.2 常见问题与排查技巧

在实际使用中，你可能会遇到一些典型问题。以下是一个速查表：

5.3 从评估到优化：一个闭环实践案例

假设你的Agent在“幻觉控制”维度得分持续偏低（55分左右）。根据框架的建议和维度定义，你可以制定一个具体的优化冲刺：

1. 根因分析：查看“幻觉控制”相关的测试用例（在config/task-suite.json中过滤hallucination_control）和失败详情。发现Agent在回答关于特定领域知识（如公司内部政策）时，容易编造细节。
2. 策略制定：
   • 增强检索：优化Agent的检索工具，确保在回答前优先从可信知识库（如公司Wiki、产品文档）中查找信息。
   • 引入拒答机制：当检索结果置信度低或为空时，强制Agent回复“根据现有信息，我无法确定答案，建议您查阅XX文档或联系XX部门”。
   • 提示词工程：在系统提示词（System Prompt）中强化“基于事实”、“引用来源”、“不确定则明确说明”等指令。
3. 实施与验证：
   • 实施上述改动。
   • 运行一次针对性的快速评估：python3 scripts/eval.py --mode quick，重点关注“幻觉控制”维度的分数变化。
   • 观察关键证据指标，如“高置信度错误率”是否下降。
4. 固化与监控：
   • 如果分数提升显著（例如从55分升至70分），将优化策略固化到Agent的默认配置中。
   • 在后续的每周标准评估中，持续监控该维度分数，确保不出现回退。

通过这样“评估 -> 分析 -> 优化 -> 再评估”的闭环，你可以系统化地、数据驱动地提升AI Agent的智能水平。smartness-eval提供的正是这个闭环中不可或缺的“度量”环节，它让每一次改进的效果都变得清晰可见。