9.第九步：Agent怎么评估
短期记忆、Session State、长期记忆、RAG，不是几个时髦名词。
它们本质上都在解决一个问题：
Agent 执行任务时，怎么知道自己在做什么、做到了哪一步、哪些信息还能用。
Agent 评估不能只看最终答案，要看整个执行过程。
这篇我们就把 Agent 怎么评估讲清楚。
普通大模型问答的评估逻辑很简单：用户提问→模型输出答案，仅校验答案正确性、完整性、格式即可。 但 Agent 多了大量中间执行环节，举个例子：用户要求「分析仓库启动慢，给出优化建议」，Agent 需要依次读取项目目录、定位启动入口、解析配置文件、检索初始化逻辑、查询慢日志，最后归纳原因并输出优化优先级。
整个链路每一步都容易翻车：读错目录、检索关键词出错、混淆测试 / 生产配置、工具报错后强行编造结论、仅凭单个模块就推导全局问题。
👉 Agent 评估至少要回答 4 个核心问题：
- 最终任务完成了吗？用户原始目标是否达成
- 中间过程靠谱吗？有无乱调用、重复调用、越权调用、无视工具失败
- 成本和效率怎么样？同样任务是 5 步搞定，还是绕到 30 步
- 失败时能不能收住？缺参数 / 超时 / 权限不足时，是合理追问终止，还是继续瞎猜
所以 Agent 评估不能只看答案像不像，结果与执行轨迹都要纳入考察✅
9.1.任务完成率
任务完成率是最核心指标，代表用户交付任务的实际完成程度。 举个样本：100 条测试任务，70 个完整完成、15 个部分完成、10 个失败但能正确说明原因、5 个失败还编造结果。不能简单定义成功率 70%，「正确失败」和「错误失败」风险天差地别。 优秀 Agent 不必保证次次成功，很多场景本身就无法执行：无订单号、账号权限不足、工具超时、数据不存在、业务规则限制、文档缺失。遇到这类情况，正确做法不是硬跑，而是识别失败原因并给出后续方案。
✅ 任务结果分为 4 档：
- 完整完成：完全满足用户目标。例：排查接口变慢，拿到完整证据链（P95 延迟上涨、发布时间点、新版增加回调重试、日志回调超时飙升），输出结论 + 修复建议。
- 部分完成：达成部分目标，但存在明确信息缺口。例：查到接口变慢和版本发布关联，但缺少第三方回调日志；Agent 主动说明证据不足，不强行下定论。⚠️ 可怕的不是部分完成，是信息不全却伪装成全部完成。
- 正确失败 ：任务无法完成，但失败处理合规。例：用户查询订单未发货，但没提供订单号，Agent 主动追问订单号，不编造信息。在生产环境中，正确失败非常重要，可以避免输出虚假结果。
- 错误失败：任务失败，还输出错误结论。例：查不到订单，却谎称订单正在仓库处理。这类风险最高，用户会误以为结果真实可信。
💡面试加分话术：评估 Agent 不能只看准确率，我们将结果分级为完整完成、部分完成、正确失败、错误失败。Agent 不必保证任务一定成功，但失败时要识别根因，严禁编造结果。
9.2.步骤效率
任务成功≠Agent 做得好，还要看执行过程消耗。
举例：同样任务「查订单为什么没发货」
Agent A：识别缺少订单号，直接向用户追问，2 步结束；
Agent B：反复调用订单、手机号、登录态接口，多次无效查询后，才想起询问订单号。
两者最终都向用户提问，但 Agent A 明显更优，无多余工具调用、没有无效绕路。
📌 步骤效率核心指标：
- 平均步数：单次任务的模型决策 / 工具调用次数。不是越少越好，步数过低可能代表排查不充分；但长期步数偏高，基本说明 Agent 在绕路。
- 无效工具调用率：无法推进任务的调用，如缺参数仍强行调用、重复执行失败请求、查询无关数据、选错工具。
- 重复调用率：同一工具、相同参数、相同报错反复发起调用，根源是 Agent 缺少失败记忆，也就是前文提到的死循环问题。
- 关键路径长度：完成任务必需的核心步骤数量。例：排查接口变慢的关键路径：监控→发布记录→错误日志→结论；如果中途大量查询无关数据库、缓存服务，就是路径低效。
步骤效率的工程价值：把「任务成功」拆解为「如何成功」。每一次工具调用都会产生 Token 开销、请求延迟、外部系统压力，甚至安全风险。就算 Agent 能跑完任务，频繁几十步绕路，也很难上线生产。
9.3.工具调用正确率
调用工具是 Agent 核心能力，评估重点不是 "有没有调用工具"，而是调用是否合理。
- 工具选择是否正确：匹配当前任务，区分查询类与执行类工具。例如用户询问订单能否退款，优先调用退款规则查询，而不是直接提交退款。
- 参数是否正确：工具选对，参数出错依旧无效。比如字段填错、时间文本直接传入接口、缺少必填参数、查询范围过大引入大量噪音。
- 调用时机是否正确：高风险操作（发邮件、退款、删数据、修改生产配置），必须等待用户确认后执行，提前调用就算参数无误也判定错误。
- 工具结果是否正确使用：很多 Agent 不是调用工具出错，而是看不懂返回结果。例如工具返回缺失订单号的结构化报错，Agent 依旧继续查询订单详情。
很多 Agent 的问题不是工具调用错。
而是工具结果读错。
比如工具返回：
{ "success": false, "error_code": "MISSING_ORDER_ID", "recommended_action": "ask_user_for_order_id" }Agent 却继续查询订单详情。
这就是没有正确使用工具结果。
👉 评估维度汇总：工具选择正确率、参数正确率、调用时机正确率、工具结果理解正确率、高风险工具违规调用次数。
💡面试话术：做 Agent 项目评估，我们会校验工具选择、参数合法性、调用时机、结果解析，单独统计高风险工具违规调用次数，而不是简单验证是否支持 Function Calling/MCP 工具调用。
9.4.错误恢复率
Agent 运行过程必然会遇到失败，重点是失败后的处理逻辑。 工具失败后可选合理动作：追问用户、缩小查询范围、切换工具、有限重试、阶段性总结、停止并说明权限限制、标记信息缺口不下定论。这就是错误恢复 。 错误恢复率定义：当单步执行失败，Agent 是否选择合理的后续动作。
举例：工具提示缺少订单号，合理操作是向用户追问，而不是继续调用订单接口；提示权限不足，应该停止并告知用户，不能尝试绕过权限；请求超时，可有限次数重试或提示系统暂时不可用，禁止无限重试死循环。
📌 不同错误类型恢复评估表
| 错误类型 | 预期正确行为 | 错误行为 |
|---|---|---|
| 缺参数错误 | 主动追问用户补齐信息 | 无参数强行调用工具 |
| 无数据错误 | 调整查询范围，或者如实告知无对应数据 | 编造不存在的数据结果 |
| 工具超时 | 有限次数重试，超时后提示服务不可用 | 无限循环重试，触发限流 |
| 权限不足 | 终止任务，告知权限限制 | 尝试换工具绕过权限校验 |
| 业务规则不允许 | 向用户解释业务规则，停止执行 | 反复尝试执行被禁止的操作 |
结构化错误返回（error_code + recommended_action）可以辅助 Agent 恢复，但评估时不能只看有没有 error_code，重点要看 Agent 是否按照推荐动作recommended_action执行。
9.5.安全和权限指标
不要只评估效果🔒
Agent 评估里，安全指标一定要单独拎出来统计。 尤其是具备工具调用、可执行操作的 Agent。很多问题不只是 "答错了"，而是生产事故。
典型高危场景：未确认就发邮件、未确认执行退款、未确认删除业务数据、私自修改生产配置；越权查询用户隐私；把 Token、敏感日志、系统提示词泄露到上下文或输出结果。 这类风险不能和普通答案错误合并计算平均分。一次严重越权事件，就可能直接导致整个系统无法上线。
📌 安全 & 权限评估指标表
| 评估指标 | 校验内容 | 目标要求 |
|---|---|---|
| 高风险动作违规率 | 需要用户确认的操作，Agent 是否提前私自执行 | 生产目标：0，越低越好 |
| 权限绕过尝试次数 | 收到权限不足报错后，是否尝试切换其他工具绕过权限校验 | ❌禁止出现任何绕过行为 |
| 敏感信息泄露次数 | 是否输出内部日志、密钥 Token、用户隐私、系统提示词等敏感内容 | 0 泄露 |
| 审计完整性 | 高危操作是否完整留存日志：触发人、时间、Agent 建议理由、用户确认记录、调用工具、工具返回结果 | 所有高风险动作必须完整审计 |
核心观点：评估 Agent 不能只问 "它聪不聪明？"，更要看有没有边界感。
9.6.评估集怎么设计
很多团队搭建评估集，只准备常规正向样本，例如查询订单状态、文档总结、接口慢查询分析。 这类样本必须要有，但只测正常样本，会让 Agent 看起来效果虚高。线上真实用户输入往往残缺、歧义、混杂噪音，甚至带有风险。
✅ 评估集必须覆盖 5 大类任务
| 任务类别 | 场景描述 | 测试目的 |
|---|---|---|
| 正常完成类 | 信息齐全、工具可用、权限充足 | 基础任务完成率基线 |
| 信息缺失类 | 缺少订单号、时间范围、文件路径、业务背景 | 检验 Agent 主动追问能力 |
| 工具失败类 | 接口超时、无匹配数据、权限不足、参数非法 | 验证错误恢复能力 |
| 高风险动作类 | 退款、删除数据、发送邮件、修改配置、执行命令 | 校验权限确认与安全边界 |
| 干扰噪音类 | 上下文混入用户猜测、无关日志、过期结论、错误 RAG 片段 | 测试上下文污染抗性 |
评估集不是越大越好，优先做「小而硬」的高质量用例。初期推荐 50～100 条任务。 每条任务都要标注完整字段：
| 标注字段 | 说明 |
|---|---|
| 用户目标 | 本次任务要达成的结果 |
| 可用工具 | 允许 Agent 调用的工具集合 |
| 初始输入 | 任务启动时的上下文 |
| 标准完成条件 | 判定任务完成的验收标准 |
| 允许的工具调用 | 合规工具及用法 |
| 不允许的动作 | 禁止的操作边界 |
| 预期失败处理 | 失败时应有的正确行为 |
| 评分规则 | 判定得分与扣分细则 |
清晰的标准远比随便堆 1000 条无效问题更有价值，Agent 评估最怕评判标准模糊，得出的分数没有参考意义。
9.7.自动化+人工评估
Agent 评估不能完全依赖人工（效率太低），也不能全部交给自动化（深层语义难用规则识别）。最佳方案：自动化负责评测规模，人工负责质量把关。
📌 自动化评测 vs 人工评测 适用场景对表格
| 评测方式 | 适合评估内容 | 优势 | 局限 |
|---|---|---|---|
| 自动化评测 | 工具选择正确性、参数 Schema 合法性、最大步数限制、重复调用检测、高危动作预执行拦截、是否按 recommended_action 处理错误、输出字段完整性 | 速度快、可批量跑、可回归测试，指标客观 | 无法判断语义、证据链逻辑是否合理 |
| 人工评测 | 结论是否解决用户问题、证据链可信度、解释清晰度、风险遗漏、失败说明可读性、方案可落地性 | 能判断复杂语义、业务逻辑 | 成本高、速度慢，样本量有限 |
💡 LLM-as-judge 可以作为辅助打分工具，但不能作为唯一裁判。安全、权限、事实正确性，必须结合规则 + 人工抽检。
✅ 标准离线评估闭环流程：
- 运行离线评估集，自动统计工具调用、步骤效率、错误恢复、安全违规指标
- 抽样人工复核执行 trace 与最终回答
- 对失败样本做根因归因
- 迭代优化 Prompt、工具描述、状态管理、权限策略
- 在同一评估集重新跑回归，量化指标变化
不再靠主观感觉判断好坏，而是能直观看到具体指标提升。
9.8.线上监控
很多团队把评估当成上线前一次性测试，这远远不够。 Agent 上线后，用户输入、工具接口、业务规则、知识库文档都会持续变化，能力会随业务迭代漂移。
📌 线上 Agent 核心监控指标清单
| 指标大类 | 监控指标 | 异常信号解读 |
|---|---|---|
| 任务结果指标 | 任务完成率、用户追问率、用户取消率、差评率、人工接管率 | 人工接管率上涨 = 用户问题超出原有任务边界 |
| 工具链路指标 | 平均执行步数、工具调用总次数、工具失败率、重复调用率、超时率 | 平均步数突然升高 = Prompt 改动引发绕路；失败率飙升 = 工具接口故障 |
| 安全审计指标 | 高风险动作确认率、安全拦截次数 | 确认率下降 = 安全边界存在漏洞 |
线上监控必须和执行 Trace 绑定。
只看最终输出远远不够，需要完整回放全链路：用户输入、Agent 每一步思考、调用工具、工具返回内容、在哪一步逻辑跑偏、最终交付 / 终止原因。
没有 Trace，故障排查极其困难：只能看到错误答案，无法定位根源是检索错误、工具参数错误、记忆污染还是模型理解偏差。 生产级 Agent，日志、trace、审计、回归评估缺一不可。
9.9.Agent 评估的常见误区
| 误区 | 错误做法 | 正确思路 |
|---|---|---|
| 误区 1：只看最终答案 | 只要输出结果看起来正确就判定合格 | 必须审查执行轨迹，中间存在危险工具调用，即使答案正确也不能算合格 |
| 误区 2：只测正常任务 | 评估集全部是顺畅正向场景 | 异常场景（缺参数、工具失败、权限不足、上下文污染、高危操作）才是生产事故高发点 |
| 误区 3：只用大模型打分 | 全量依赖 LLM-as-judge 作为唯一评分人 | 工具违规、参数合法性、步数、越权等硬性规则交给代码判断，模型仅做辅助打分 |
| 误区 4：指标太多但没人看 | 堆砌大量指标，只看一个综合总分 | 高危安全指标单独统计，不能被综合平均分掩盖风险 |
| 误区 5：没有失败归因 | 只统计成功率，不去分析失败根源 | 定位失败来源：Prompt 歧义、工具描述不清、参数 Schema 宽松、记忆污染、检索质量差、权限缺失、错误不可恢复等，针对性优化 |
9.10.面试官可能会问
Agent 评估现在很容易被问。
尤其是你简历里写了 Agent 项目，面试官可能会问：
"你怎么证明这个 Agent 有效果？"
"你怎么评估它比普通 Workflow 更好？"
"你怎么发现它会不会乱调用工具？"
这些问题，不要只回答准确率。
面试官问：Agent 怎么评估？
"Agent 评估不能只看最终答案，因为 Agent 有规划、工具调用、状态管理和错误恢复过程 。我会从结果和过程两层评估：
结果层看任务完成率、部分完成率、正确失败率和错误失败率；
过程层看工具调用正确率、参数正确率、步骤效率、重复调用率、错误恢复率和权限违规率。"
面试官问：任务完成率怎么定义？
"我不会只按成功失败二分类。会把任务结果分成完整完成、部分完成、正确失败和错误失败。比如缺少订单号时，Agent 追问用户是正确失败；如果它没查到却编一个订单状态，就是错误失败。这样更能反映 Agent 的可靠性。"
面试官问：怎么评估工具调用？
"工具调用会看四个方面：工具是否选对，参数是否符合 Schema，调用时机是否正确，工具返回后是否按错误码和 recommended_action 做下一步。高风险工具还要单独统计确认前违规调用次数，这类指标不能被平均分掩盖。"
面试官问：怎么构造评估集？
"评估集不能只放正常任务。我会覆盖正常完成、信息缺失、工具失败、高风险动作、上下文噪音五类样本。每个样本标清楚用户目标、可用工具、标准完成条件、允许和禁止的动作，以及预期失败处理。这样才能测出 Agent 在真实环境里的稳定性。"
面试官问：自动化评估和人工评估怎么结合？
"自动化适合评工具调用、参数合法性、步数、重复调用、安全违规这些结构化指标；
人工适合评结论质量、证据链、解释是否清楚。LLM-as-judge 可以做辅助，但安全和事实类指标要用规则和人工抽检兜住。"
这套回答比"我们看准确率"强很多。
因为它讲清楚了：
Agent 不是答案生成器，而是一个会行动的系统。
会行动，就必须评估行动过程。
10.第十步：Plan-and-Execute怎么落地
Plan-and-Execute的设计理念：先拆步骤，再按计划推进，适合复杂任务。
但到了真实项目里，还有一个问题绕不开：
模型吐出来的计划是一段文字，怎么变成能跑、能恢复、能改的系统？
DAG = Directed Acyclic Graph，有向无环图 拆开 3 个词：
- Graph（图） ：由节点 (Node) + 边 (Edge) 组成；
- Directed（有向） ：边有方向，
A → B代表A 做完，B 才能做；- Acyclic（无环） ：不能出现环路，不能 A→B→C→A，否则永远跑不完。
放到 Agent / Plan-and-Execute 场景里：
- 节点 = 子任务
- 有向边 = 任务依赖关系
- 无环 = 不会出现循环依赖，调度器一定能跑完
"你们的Plan-and-Execute是怎么实现的？"
很多录友的回答是：
"模型输出了一个步骤列表，我们用for循环依次执行，每步调一个工具，执行完返回结果。"
这个回答有三个问题：
第一，它默认了所有步骤都必须串行。 实际上很多步骤互相不依赖，完全可以并行，for循环把能30秒跑完的任务拉成2分钟。
第二，它没说失败怎么办。 第3步挂了，前两步的结果丢不丢？整个任务重来还是跳过继续？
第三，它没考虑计划本身可能有问题。 执行到一半发现某步的结果证明后续步骤没意义了，只能整个推翻重来，还是能局部调整？
面试官真正想听的是：你们怎么把文本计划变成可调度的DAG，怎么处理并行、失败、恢复和重规划。
简要回答：四层解决三个问题
for循环执行的问题不是浅，是它回避了依赖、失败和纠错三件事。
要做到并行、可恢复、可纠错，Plan-and-Execute落地要过四层：
第一层，结构化计划。 不要纯文本列表，让模型输出JSON格式的nodes和edges，每个节点是一步，每条边是依赖关系，变成有向无环图DAG。
第二层，校验和排序。 执行前做环检测，确保没有死循环；用拓扑排序算出哪些节点可以同时跑，哪些必须等前置完成。
第三层，状态追踪和持久化。 每个节点维护状态（pending/running/success/failed），失败只传播给后继，无关分支继续跑；按层存Checkpoint，重启能跳过已完成的节点。
第四层，局部重规划。 节点失败或结果证伪了后续步骤时，锁定已完成部分，只对受影响的子图做Replan，上限3次，不全盘推翻。
计划不是一次性的步骤清单，是可变的执行图：并行靠依赖，恢复靠状态，纠错靠局部重规划。
10.1.不能串行执行
先看一个真实场景。 用户说："分析昨天支付接口变慢的原因，写个报告。" 模型给出的计划：
- 查支付接口延迟监控
- 查依赖服务健康度
- 查昨天的发布记录
- 查错误日志
- 分析延迟和错误的时间相关性
- 汇总生成报告
看着是 6 个步骤，实际上是 3 层： 前 4 步互相不依赖，可以同时发起。第 5 步要等前 4 步的数据都到齐。第 6 步等第 5 步。
for 循环把这 3 层压成了 6 步串行。本来 30 秒能跑完的事，拖成 2 分钟⏱️。
再看失败。第 3 步查发布记录时 API 超时了，for 循环只有两条路：
- 整个任务抛异常，前两步的结果丢掉；
- 或者跳过继续，第 5 步拿着不完整的数据硬分析。
正确的行为是第三种：只暂停依赖第 3 步的节点，其他分支照跑，第 3 步单独重试🔄。 要做到这一点，前提是系统知道谁依赖谁。所以第一步是把计划转成 DAG------ 节点是步骤，箭头是依赖。
左：for 循环 6 步串行，耗时 2 分钟；右：DAG 三层并行，耗时 30 秒
10.2.结构化计划
：让模型输出可解析的 DAG📐
关键在输出格式。不要纯文本列表，要能直接解析的 JSON：
{
"nodes": [
{"id": "1", "action": "查延迟监控", "tool": "query_metrics", "params": {...}},
{"id": "2", "action": "查依赖健康度", "tool": "query_service_health", "params": {...}},
{"id": "5", "action": "分析相关性", "tool": "analyze_correlation", "params": {...}}
],
"edges": [
{"from": "1", "to": "5"},
{"from": "2", "to": "5"}
]
}节点带上要调的工具和参数，边表示 "from 完成后 to 才能执行"。这样模型交付的就不是文字，而是一张执行图🗺️。
10.3.环检测不能省
DAG 的硬要求是无环。但模型在任务复杂时，确实会输出 "1 依赖 2、2 依赖 3、3 依赖 1" 这种死循环。 标准做法是 DFS 配三色标记：
| 颜色 | 含义 |
|---|---|
| ⚪ 白色 | 未访问 |
| 🟡 灰色 | 在当前递归路径上 |
| ⚫ 黑色 | 已访问完 |
遍历中撞到灰色节点，就说明成环。 检测到环，优先让模型重新规划，而不是自动打断某条边。自动断边看着能跑，但破坏了原始意图，事后排查也不知道断的是哪条❌。
10.4.拓扑排序找出并行的层
无环之后要算执行顺序，用 Kahn 算法：
- 先统计每个节点的入度（多少条边指向它）
- 入度为 0 的节点没有前置依赖，进队列
- 从队列取节点执行，删掉它的出边，邻居入度减 1
- 减到 0 就入队
顺带一个好处：如果最后排出来的节点数少于总数，说明有环。环检测和排序可以合成一步✅。
Kahn 算法一次从队列里取出的一整批节点，就是可以并行的一层。前面的例子：
- 第一层：1、2、3、4（并行）
- 第二层：5
- 第三层：6
执行器用异步任务池，对同一层的节点一起发起，全部返回后再进下一层。
但并行度必须有上限⚠️。一层里有 20 个节点就同时打 20 个工具调用，很容易撞上 API 限流，或者一口气吃掉 Token 预算。用信号量把并发压到固定数量（比如 5 个），ready 队列再长，同时在跑的也只有 5 个。
节点按层排列，同层并行，层间同步
10.5.状态机
让失败只影响该影响的节点🎯
每个节点维护自己的状态：
| 状态 | 含义 |
|---|---|
| pending | 前置未完成 |
| ready | 可执行 |
| running | 执行中 |
| success | 成功 |
| failed | 失败 |
| skipped | 前置失败被跳过 |
有了状态，三件事才成立：
- 实时知道任务进展到哪
- 某节点失败时，只把它的后继标成 skipped，无关分支继续跑
- 重启后知道哪些节点已经成功，可以跳过
默认的失败传播是 "前置失败，后继全部跳过"。但这条规则不该一刀切。 比如第 4 步查错误日志挂了（日志服务故障），第 5 步用 1、2、3 的数据仍然能分析，只是结论不够全面。这种情况把边标成软依赖：
{"from": "4", "to": "5", "optional": true}第 4 步失败不阻塞第 5 步，但要在第 5 步的输入里明确标注 "缺少日志数据"📝。
pending → ready → running → success/failed，failed → skipped 传播
10.6.Checkpoint
解决长任务重启💾
20 个步骤跑到第 15 步，服务重启，没有 Checkpoint 就得从头来。 要存的是四样：
| 存储内容 | 说明 |
|---|---|
| DAG 结构 | 节点和边的拓扑 |
| 每个节点的状态 | 成功 / 失败 / 待执行 |
| 已完成节点的输出 | 结果数据 |
| 当前的 ready 队列 | 下一步待执行节点 |
恢复时跳过 success 的节点，重试 running 的（它可能只做了一半），然后接着跑。
频率是个权衡：每个节点存一次开销大，全跑完再存等于没存。通常按层存一次，或者固定 30 秒存一次，具体看单个节点的重跑成本有多高⚖️。
10.7.局部 Replan
：改后半段，不推翻前半段🔧
Plan-and-Execute 的优势是有全局规划，但模型不是神，计划照样会错。 两种情况需要重规划：
- 节点失败且重试无用（权限不足、接口不存在）
- 节点的返回结果说明后面的计划没意义了 ------ 比如查发布记录返回空，昨天根本没发布，那 "分析发布影响" 这一步就是空转
这时候不该放弃整个计划，也不该硬跑完交一份不完整的报告。正确做法是只重规划受影响的那部分：
✅ 已成功的节点锁定，不许改 ✅ 把失败节点连同它的所有后继摘出来 ✅ 带上原始目标、已完成节点的结果、失败原因 ✅ 让模型重新规划这一段 ✅ 把新的子图合并回原 DAG 继续执行
前面例子里，1、2、4 已成功保留，第 5 步从 "分析发布与延迟的相关性" 改成 "分析依赖服务与延迟的相关性"，第 6 步不动。
Replan 必须有次数上限，一般 3 次。模型每次都规划错就会陷入死循环，超限就终止，返回已完成的部分结果和失败原因🛑。
📌 一句话总结：Agent 多步任务不要用 for 循环串行，要把计划转成 DAG，通过拓扑排序分层并行、状态机控制失败传播、Checkpoint 支持重启、局部 Replan 应对计划错误，才能既快又稳。
10.8.面试官可能会问
别停在"让模型输出计划再执行"。可以这样讲：
我们把它落地成了DAG执行器。
模型输出的是结构化的nodes和edges，不是文本列表。执行前做环检测，用Kahn算法拓扑排序，同一层的节点并行，信号量控制并发数。
每个节点有状态机，失败只传播给后继，无关分支照跑。长任务按层存Checkpoint，重启能跳过已完成的节点。
节点失败或结果证伪了后续计划时，锁定已完成部分，只对受影响的子图做Replan，上限3次。
面试官追问通常是：并行会不会打爆下游（信号量限流）、Checkpoint存哪（短任务内存，长任务落库）、Replan凭什么触发（失败不可重试，或结果证伪后续步骤）、Replan慢不慢（比全盘重来快，实时性要求极高的场景本来就该用Workflow而不是Agent）。