AI Agent 的评测正在变成比模型推理更让人头疼的问题。你辛苦搭了一个 Multi-Agent 系统功能演示很顺畅但一放到真实环境就暴露各种问题工具调用时灵时不灵、多轮对话绕圈子、任务稍微变个说法就失败。更麻烦的是你很难说清楚它到底哪里不行是模型能力不够还是 Prompt 设计有问题还是评测标准本身就不合理。过去两年围绕大模型的评测基准层出不穷从 MMLU、HumanEval 到 SWE-bench、GAIA每个都有明确的定位。但到了 AI Agent 阶段问题变得复杂得多Agent 面对的不是一道静态题目而是一个随时会变化的动态环境。它需要规划、调用工具、读取反馈、修正错误再继续执行。用一套固定题库去测这种能力本质上就像用“驾照笔试”去衡量一个人的真实驾驶水平——有关系但远远不够。Computer Anthology 这个名字恰好指向了一个关键思路AI Agent 的 benchmark 不应该是一个孤立的静态数据集而应该是一个持续演进的 benchmark 家族。它不是一本书而是一套不断更新的丛书。这篇文章会拆解这个思路背后的核心问题也会给出一套可以落地的最小评测框架帮你理解为什么 Agent 评测需要“家族化 持续演进”以及你自己怎么搭一个简单的评测体系。1. 这篇文章真正要解决的问题先说明白这篇文章不是给你介绍一个可以直接拿去刷分的榜单而是解决一个更实际的问题如何持续、可信地评估一个 AI Agent 的能力。如果你正在做下面这些事情这篇文章值得读完你在开发 Agent 应用比如客服机器人、代码助手、数据分析助手需要知道每次 Prompt 或模型更新后能力有没有下降。你在做 RAG 或工具调用相关的项目想评估“调用工具是否准确”“回答是否基于检索内容”。你负责团队的基础设施需要建立一套 Agent 回归测试机制避免上线后才发现问题。你关注 benchmark 趋势想理解 SWE-bench、GAIA 这些评测之外为什么会出现“持续演进”的新方向。传统 benchmark 有三个典型的局限第一静态性。题目集固定答案固定一旦模型刷过一遍分数的信息量就急剧下降。第二单一性。一个 benchmark 只测一个维度代码能力、数学能力、工具调用能力各自独立。但真实 Agent 任务是复合型的比如“帮我在这个数据库里找到异常订单并生成报告”它同时涉及 SQL、推理、文本生成和理解用户意图。第三易过拟合。公开 benchmark 的测试集一旦被模型训练数据覆盖评测就失去了意义。这在 Agent 领域更严重因为 Agent 不只依赖模型本身还依赖 Prompt、工具描述、任务模板任何一个环节都可能被“针对性优化”而不是“真正变强”。Computer Anthology 的命名传递了一个明确信号把 benchmark 当作一个持续维护的工程制品而不是一次性发布的数据集。这个思路解决的不是“测得更准”这一个点而是把评测从“考试”变成“持续校准工具”。2. 为什么 AI Agent 的评测比大模型评测更难在深入 Computer Anthology 之前得先把一个问题聊透Agent 评测到底难在哪。只有理解了难点你才能理解为什么传统的 benchmark 设计思路不够用。2.1 LLM 评测和 Agent 评测的本质区别大模型评测比如 MMLU、GSM8K本质是“单轮问答”给一个问题模型给出一个答案对照标准答案打分。流程是线性、确定的。Agent 评测则完全不同任务是一个目标没有固定路径。比如“帮我订一张明天从北京到上海的机票”Agent 可能需要理解用户意图调用航班查询工具解析返回结果询问用户偏好调用预订工具处理可能的失败重试。每一步都可能出错而且前一步的错误会传导到后面。最终结果可能正确但过程绕了很多弯路也可能最终任务失败但中间某几步执行得很出色。这种“轨迹式”的执行过程很难用“对/错”二元评价。2.2 四个核心难点难点一任务空间无限。真实世界的任务组合几乎是无穷的没法像选择题那样穷举出一个完整题库。你只能用“抽样”的方式逼近真实场景但如何保证抽样覆盖了关键能力维度难点二环境状态可变。同样是“查询订单状态”如果 Agent 第一次执行时环境里没有订单第二次执行时订单存在了结果就完全不同。评测环境必须能重置、隔离否则不同 Agent 之间的比较就是不公平的。难点三评分标准模糊。一个 Agent 调了 10 次工具终于完成任务另一个 Agent 只调了 2 次。两者都算“成功”但显然效率不同。只看最终结果无法区分“能力强”和“运气好 蛮力试错”。难点四数据泄漏。Agent 依赖的工具描述、示例任务、提示模板都是文本很容易被模型训练数据吸进去。一旦模型“见过”这道题评测就失真了。一个合适的类比是传统 benchmark 像驾校科目一考试题库固定刷题就能过Agent 评测像路考路线可以设计但路况会变你还要考察驾驶员对突发情况的反应。Computer Anthology 强调“持续演进”本质就是在承认Agent 的能力评测不能靠一次路考定终身必须持续加入新路线、新路况。3. Computer Anthology 的核心概念与定位“Anthology” 一词的本意是“选集、文集”通常指一系列有主题关联的作品集。Computer Anthology 这个名字实际上是在定义一个关于 AI Agent benchmark 的设计哲学。3.1 从“单点基准”到“基准家族”传统 benchmark 是“单点”的一个数据集、一个任务类型、一个分数。Computer Anthology 代表的思路是一套基准应该由多个相关任务族构成并且随能力发展而持续演进。这里有几个关键点第一系列化。不是一个数据集而是一组数据集彼此之间有关联、有层级。比如可以从“工具调用能力”“多步规划能力”“错误恢复能力”这些维度分别构建任务族再汇总成一个综合评估体系。第二版本化。基准有一个生命周期设计 → 内测 → 发布 → 收集反馈 → 更新。就像软件版本一样v1.0、v1.1、v2.0每次更新都有 changelog。第三持续性。只要 Agent 能力还在发展基准就要演进。新能力出现就要有新任务去测旧任务被模型训练数据覆盖价值下降就该退役或调整。3.2 演进式 benchmark 解决什么问题抵御数据泄漏持续新增私有任务让模型无法通过“记住”来刷分。对抗过拟合单一静态 benchmark 刷分没有意义了因为新任务不断加进来。追踪能力变化可以看到 Agent 在连续版本上的能力曲线而不仅仅是一个孤立快照。区分“记忆”和“能力”如果任务在持续变化高分才更可能代表真正的泛化能力。你可能会问这和“不断换新题”有什么区别区别在于演进不是随意换题而是有方向地扩展新任务必须由旧任务无法覆盖的能力缺口驱动。这就像一个团队在持续维护测试用例库用户反馈什么场景容易出错就把什么场景变成回归测试。3.3 在 benchmark 生态中的位置目前主流的 Agent benchmark 各有侧重SWE-bench聚焦真实 GitHub issue 的代码修复任务来自真实仓库比较接近工程实践。GAIA设计更偏向通用助手任务强调需要多步推理和工具使用问题由人类设计以避免模型记忆。AgentBench覆盖操作系统、数据库、知识图谱、卡牌游戏等 8 个环境试图评价跨域泛化。tau-bench专注于工具调用场景模拟用户与 Agent 的对话。这些基准的共性问题是发布之后基本固定只能在有限程度上持续更新。Computer Anthology 的定位不是“又一个 benchmark”而是“benchmark 的孵化和管理机制”。它把“评估 AI Agent”本身当作一个需要持续投入的工程问题而非一次性的研究产出。这种定位背后有一个很实际的判断AI Agent 的评测不是一次发布就结束的而是要像 CI/CD 一样长在开发流程里。4. 单一 benchmark 会产生哪些误导为什么需要“家族”而不是“一个超大 benchmark”原因是单一 benchmark 在实践中会产生几个很具体的问题。4.1 Leaderboard 过拟合公开 Benchmark 天然会变成军备竞赛。团队为了在排行榜上拿名次会针对任务特征做各种 trick——比如针对 SWE-bench 优化对 issue 的文本处理或针对 GAIA 构造特定工具的调用策略。这些优化让分数上去了但真实场景的泛化能力并没有同步提升。这就是经典的“古德哈特定律”当一个指标变成目标它就不再是一个好的指标。4.2 单任务类型无法覆盖复合能力真实 Agent 任务几乎都是复合的。“整理本月销售数据并生成周报”至少涉及数据查询、数值计算、文本组织、格式输出。单一 benchmark 测的是单项能力无法告诉你 Agent 面对复合任务时的表现。Computer Anthology 把多个任务族组合起来评估就是为了逼近真实任务的复杂度。4.3 静态数据的半衰期越来越短模型训练数据会不断吸收公开的 benchmark 任务。一个静态 benchmark 发布三个月后它的区分度就可能明显下降。它不是“坏了”而是“被污染了”——测试的已经不是 Agent 的即兴推理能力而是它对训练数据的记忆能力。4.4 轨迹质量被忽略许多 benchmark 只按最终结果打分忽略了 Agent 的轨迹质量。连续追问 10 次才成功和一次调用就成功分数可能完全相同。这对真实产品是致命的用户不会容忍一个绕圈子的 Agent。演进式 benchmark 家族会在评分维度上加入“过程质量”指标比如工具调用次数、是否需要人工介入、单步成功率等。理解这些误导你就能理解为什么要坚持“持续演进 多任务族”的评测哲学。这不是学术洁癖而是工程上对评测可信度的基本要求。5. 如何落地一个演进式 Agent 评测系统概念讲完了接下来是落地。很多人会觉得“持续演进的 benchmark”是研究团队的事但实际上任何正式一点的 Agent 项目都应该建立自己的评测系统否则你根本没法回答“这次改动到底是变好了还是变坏了”。一个可运行的评测系统核心由六个部分组成组件作用典型实现任务定义描述任务的输入、目标、约束JSON/YAML 配置文件测试环境提供给 Agent 的工具、状态、初始条件沙箱、Mock 服务、数据库Runner调度 Agent 执行任务记录轨迹Python 异步脚本评分器根据结果和轨迹计算分数规则 模型双通道报告模块生成可读的评估报告JSON、Markdown 报告任务管理新增、更新、退役任务的流程Git 版本管理下面重点拆解两步任务定义和 Runner 实现。这是搭系统时最容易出问题的地方。5.1 任务定义最值得花时间的一步很多评测系统做不好第一个坑就在任务定义。任务定义不是写一句“让 Agent 查天气”就完了它必须包含任务描述给 Agent 的目标指令要足够自然避免直接暴露评测意图。可用工具Agent 在这个任务里可以调用哪些工具每个工具的参数 schema 是什么。初始状态环境里预置了什么数据。成功标准什么算完成任务是精确匹配、包含关键信息还是需要通过模型判断。禁止行为哪些路径不算数比如直接访问评测答案。下面是一个任务定义的简化示例使用 JSON 文件描述{ task_id: order_status_001, version: 1.0.0, title: 查询订单状态并回复用户, description: 用户想知道订单 #1024 的当前状态以及预计送达时间。请使用提供的工具查询并给出简洁回复。, tools: [query_order_status, query_order_detail], initial_state: { order_id: 1024, status: shipped, eta_days: 3 }, success_criteria: { type: llm_judge, must_mention: [已发货, 预计3天内送达], forbidden: [直接猜测] }, max_steps: 5, timeout_seconds: 60 }这个文件定义了任务的基本信息。注意version字段这是演进式 benchmark 的关键——任务也像代码一样需要版本管理。5.2 Runner如何驱动的 Agent 执行任务Runner 是整个评测系统的发动机。它的职责是读取任务定义准备测试环境启动 Agent 实例并传入任务描述在 Agent 执行过程中记录每一步动作判断是否达到终止条件把轨迹交给评分器。下面是一个简化版的 Python Runner 示例。它使用一个假设的AgentSession接口你可以把它替换成自己的 Agent 框架# file: runner.py import json import time import traceback from dataclasses import dataclass, field from typing import Any dataclass class StepRecord: 记录 Agent 执行的单步动作 step_index: int action: str tool_name: str | None tool_input: dict | None observation: Any timestamp: float dataclass class EvalResult: 一次评测任务的完整结果 task_id: str success: bool score: float detail: str steps: list[StepRecord] field(default_factorylist) error: str | None None class AgentRunner: 评测 Runner。 agent_factory 是一个返回 Agent 实例的工厂函数。 task_loader 是加载任务定义的函数。 def __init__(self, agent_factory, task_loader): self.agent_factory agent_factory self.task_loader task_loader def run_single(self, task_id: str) - EvalResult: task self.task_loader(task_id) agent self.agent_factory(task) records: list[StepRecord] [] start_time time.time() for step in range(task[max_steps]): # 超时保护避免单任务卡死整个评测 if time.time() - start_time task[timeout_seconds]: return EvalResult( task_idtask_id, successFalse, score0.0, detailtimeout, stepsrecords, errorTask timeout, ) try: action agent.next_action() if action is None: break observation self.execute_tool(action) records.append( StepRecord( step_indexstep, actionaction[type], tool_nameaction.get(tool_name), tool_inputaction.get(tool_input), observationobservation, timestamptime.time(), ) ) if action[type] final_answer: return self.score_task(task, records, action[answer]) except Exception as exc: # 捕获异常避免单任务中断评测 records.append( StepRecord( step_indexstep, actionexception, tool_nameNone, tool_inputNone, observationstr(exc), timestamptime.time(), ) ) return EvalResult( task_idtask_id, successFalse, score0.0, detailexception, stepsrecords, errortraceback.format_exc(), ) # 达到最大步数仍未结束 return EvalResult( task_idtask_id, successFalse, score0.0, detailmax_steps_reached, stepsrecords, ) def execute_tool(self, action: dict) - Any: 根据 Agent 返回的动作执行工具返回观测结果。 实际项目中要在这里拦截危险操作并保证环境隔离。 tool_name action.get(tool_name) if tool_name query_order_status: return {status: shipped, eta_days: 3} elif tool_name query_order_detail: return {order_id: 1024, item: wireless keyboard} else: raise ValueError(funknown tool: {tool_name}) def score_task(self, task, records, answer): 简单评分先按规则判断再记录轨迹。 完整的评分器请参考 evaluator.py criteria task[success_criteria] must_mention criteria.get(must_mention, []) ok all(m in answer for m in must_mention) score 1.0 if ok else 0.0 return EvalResult( task_idtask[task_id], successok, scorescore, detailsuccess if ok else missing_key_info, stepsrecords, ) # ---- 使用示例 ---- if __name__ __main__: def load_task(task_id): with open(ftasks/{task_id}.json, r, encodingutf-8) as f: return json.load(f) class DemoAgent: 一个固定策略的 Demo Agent仅用于验证 Runner 逻辑 def __init__(self, task): self.task task def next_action(self): if not hasattr(self, _called): self._called True return { type: tool_call, tool_name: query_order_status, tool_input: {order_id: 1024}, } return { type: final_answer, answer: 订单已发货预计3天内送达。, } runner AgentRunner(agent_factorylambda task: DemoAgent(task), task_loaderload_task) result runner.run_single(order_status_001) print(ftask_id{result.task_id}) print(fsuccess{result.success}) print(fscore{result.score}) print(fsteps{len(result.steps)})这个 Runner 的核心是循环Agent 每发出一个动作Runner 执行它把观测结果返回给 Agent同时记录轨迹。这里有三个设计值得注意第一超时保护。生产环境的 Agent 可能卡在死循环里没有超时保护一次评测可能跑几个小时。第二异常隔离。单个任务出错不应该中断整个评测要把异常记录进轨迹方便后续分析。第三逐步记录。每一步动作和观测都被记录这是后续分析 Agent 行为的基础也是最终结果之外最有价值的产物。5.3 评分器规则和模型双通道单纯用规则评分会太死板单纯用模型评分会不稳定。实践中更推荐“规则 模型”双通道规则通道处理可量化的指标比如工具调用次数、是否超时、关键字段是否出现。模型通道处理需要语义理解的部分比如“回答是否自然”“是否理解了用户隐含意图”。# file: evaluator.py import json class Evaluator: 规则 模型双通道评分器 def __init__(self, llm_judgeNone): self.llm_judge llm_judge # 可选的模型评分函数 def evaluate(self, task: dict, result) - dict: rule_score self._rule_based_score(task, result) llm_score self._llm_based_score(task, result, rule_score) final_score 0.7 * rule_score 0.3 * llm_score return { task_id: task[task_id], rule_score: rule_score, llm_score: llm_score, final_score: round(final_score, 4), trajectory_len: len(result.steps), detail: result.detail, } def _rule_based_score(self, task, result): criteria task[success_criteria] must_mention criteria.get(must_mention, []) answer getattr(result, answer, ) or if all(m in answer for m in must_mention): return 1.0 return 0.0 def _llm_based_score(self, task, result, rule_score): 模型评分对规则无法覆盖的语义质量做主观打分。 如果未配置 llm_judge则退化为规则分数。 if self.llm_judge is None: return rule_score return self.llm_judge(task, result) # 将评估结果汇总为 JSON 报告 def build_report(results: list[dict]) - str: total len(results) avg_score sum(r[final_score] for r in results) / total report { total_tasks: total, avg_score: avg_score, pass_rate: sum(1 for r in results if r[final_score] 0.8) / total, results: results, } return json.dumps(report, ensure_asciiFalse, indent2)评分器设计的核心原则是可解释性。如果 Agent 得了 0.7 分你必须能拆出这 0.7 分是怎么来的规则分多少、模型分多少、哪些任务拉了后腿。不能给一个黑盒分数。5.4 任务管理用 Git 思路管理 Tasks演进式 benchmark 最关键的是任务管理。任务文件应该像代码一样放在 Git 里每个任务都有版本号。当任务因为过拟合需要调整时不是直接改任务内容而是新建一个版本。tasks/ order_status_001.json # v1.0.0 order_status_001.v2.json # v1.1.0 data_analysis_002.json # v1.0.0每次 Agent 版本发布前跑全部任务把得分变化和任务版本一起提交。这样你能定位到“从哪个 Agent 版本开始哪个任务族的能力出现了回退”。6. 运行与验证如何判断评测系统可用写完 Runner 和评分器先不要急着接入真实 Agent。先用一个固定策略的 Demo Agent 验证评测系统本身是否正确。运行示例python runner.py预期输出示例task_idorder_status_001 successTrue score1.0 steps2这里的steps2表示 Agent 用两步完成了任务一步调用工具一步给出最终回答。验证评测系统是否可用的四个关键点第一任务能被正确加载。检查 JSON 配置文件是否被正确解析task_id是否匹配。第二工具调用能被正确分派。Demo Agent 调用query_order_statusRunner 能返回对应的模拟结果。第三轨迹能完整记录。打印result.steps确认每一步的动作和观测都在。第四评分结果符合预期。Demo Agent 的回答包含“已发货”和“预计3天内送达”所以得分是 1.0。如果把回答改成“订单正在处理中”得分应该变成 0.0。如果这四点都通过说明评测系统的骨架是通的。接下来再逐步接入真实 Agent 框架替换agent_factory的实现。如果运行失败按下面的顺序排查文件路径是否正确tasks/order_status_001.json是否存在。JSON 格式是否合法肉眼检查逗号、引号、括号是否闭合。Python 版本是否支持str | None这类类型语法需要 Python 3.10 及以上低版本可以改成Optional[str]。7. 常见问题与排查思路从实际搭建经验看Agent 评测系统最容易踩的坑集中在下面这些场景问题现象可能原因排查方式解决方案Agent 不调用工具直接编答案工具描述不清晰或任务描述没说明必须用工具查看轨迹中是否出现tool_call类型动作在任务描述中明确“请使用指定工具查询后再回答”评测结果不稳定同一版本分数波动评分规则对语义判断过于严格模型评分随机性高对比多次运行轨迹检查 LLM Judge 的温度参数规则评分优先模型评分作为辅助固定温度或多次采样取均值任务被 Agent “记住”分数虚高公开任务被模型训练数据吸收检查任务发布时间与模型训练数据截止时间使用私有评测集或持续更新任务版本单任务卡死整个评测被阻塞缺少超时控制检查 Runner 是否设置timeout_seconds为每个任务设置最大步数和超时时间异常任务单独记录工具调用污染了评测环境多个 Agent 共用了同一个外部服务状态检查是否有状态隔离每个任务使用独立沙箱数据库用事务回滚或重建成功标准主观评分争议大任务定义里成功标准过于模糊邀请第二人对结果独立打分对比一致性将成功标准细化为可验证的检查点新任务加入后历史分数不可比任务集合不稳定版本混乱检查任务文件里是否有version字段每次变更任务的version报告和代码一起提交最终结果正确但轨迹垃圾只看最终正确率没看过程和步骤数增加轨迹质量指标记录工具调用次数、单步成功率、重试次数这里特别强调一下“评测环境隔离”。Agent 评测和普通单元测试不一样Agent 会真实调用外部工具可能修改数据库、发送请求、创建文件。如果评测环境没有隔离一次评测可能污染下一次评测甚至影响线上真实数据。安全边界是最低要求Agent 只能用评测专用的 Mock 服务和沙箱环境数据库使用独立实例每次评测前重建禁止 Agent 访问评测评分器和任务定义的内部文件生产环境变更前先在隔离评测环境完整跑一遍。8. 演进式评测的最佳实践与工程建议把评测系统从“能跑”提升到“可信、可持续维护”有几个工程建议值得参考。8.1 把评测做成回归门禁最有效的用法是把评测嵌入 CI/CD每次 Agent 的 Prompt、模型或工具代码变更时自动跑一个精选的评测集把分数变化作为合并请求的门禁条件。分数下降超过阈值就阻止合并。这样能避免“模型升级后客服 Agent 解决问题的能力悄悄变差”这种隐蔽回归。实际操作上不需要每次全量跑所有任务。可以把任务分成两个层级冒烟集5 到 20 个代表性任务每次变更都跑控制在几分钟内。全量集几百到几千个任务定期跑比如每晚定时评测生成完整报告。8.2 区分“能力评测”和“需求评测”注意一个常见误区评测集到底在测 Agent 的能力还是在测特定业务需求能力评测关注通用能力比如工具调用准确率、多步规划成功率。需求评测关注特定业务场景比如你的客服 Agent 能否正确处理退款流程。两者都需要但任务设计逻辑完全不同。能力评测任务要抽象、去业务化需求评测任务要贴近真实用户输入。Computer Anthology 的“家族”思路在这里很有用把两类任务分开维护分别跑分别出报告不要混在一个分数里。8.3 轨迹回放比分数更重要评分只能告诉你“好不好”轨迹能告诉你“为什么不好”。评测系统应该支持轨迹回放查看每个动作、每个观测、每轮模型输出。没有轨迹回放遇到一个失败任务你只能猜。建议在评测结果里记录这些字段Agent 每一步的完整输入和输出工具调用的请求和响应包括状态码每一轮的延迟模型版本号、Prompt 版本号环境标识。8.4 防御过拟合的正确姿势完全避免过拟合不太现实但可以降低风险保留 20% 到 30% 的私有评测任务不对外公开定期新增任务替换被“刷高”的旧任务公布评测结果时附带任务版本而不是只给分数关注分数变化趋势而不是单次绝对分数。8.5 成本控制Agent 评测是花钱的。每个任务都要调用模型多步任务调用次数更多。如果全量集有 1000 个任务平均每个任务 5 步那就是 5000 次模型调用成本压力不小。可以这样控制先用规则过滤明确失败的任务再对边界任务用模型评分冒烟集用性能较好的模型全量集用成本较低的模型失败任务立即停止不继续执行后续步骤缓存工具调用结果相似任务复用。9. 总结与后续学习方向回到开头的问题AI Agent 已经进入工程化阶段“能不能跑通”已经不是核心矛盾“能不能持续可靠地评估”才是。Computer Anthology 代表的思路值得每个 Agent 开发者借鉴不要把 benchmark 当成一次性的数据集而是当成一个持续演进的工程体系。传统 benchmark 测的是“存量能力”演进式 benchmark 家族测的是“增量能力”和“泛化能力”这在 Agent 快速迭代的当下尤为重要。如果你正准备给自己的 Agent 项目搭评测体系我的建议是先小规模跑通不要一上来就追求大规模任务集。先用 10 个任务验证 Runner、评分器和报告流程确认系统可靠之后再扩展到上百个任务并逐步加入“任务版本管理”和“回归门禁”。后续值得深入的方向有三个LLM-as-a-Judge 的可靠性模型打分本身会偏如何校准、如何对齐人工评分。多 Agent 系统的评测多个 Agent 协作时的责任归属和端到端效果评估比单 Agent 更复杂。评估任务的自动生成用模型自动生成新的评测任务再由人工筛选审核这是降低“持续演进”成本的重要路径。这篇文章讲的评测框架是按通用思路实现的没有绑定特定框架代码可以在你自己的项目中直接用。建议收藏备用等真正开始搭评测系统时按章节 5 到 8 的操作路径逐步落地即可。
