Agent 的 think-execute 循环如何控制规划路径，避免偏离业务预期或无限循环？｜高频面试题解析

60 秒回答模板

think-execute 的价值在于把复杂任务拆成多轮计划和多步执行：think 阶段根据目标、上下文和当前状态决定下一步，execute 阶段调用工具、查询数据或生成结果，再把执行反馈喂回下一轮。它比一次性生成答案更适合需要检索、调用工具、处理异常和逐步收敛的任务。但循环机制天然有风险，模型可能扩展无关目标、重复尝试、选择错误工具或无限规划。要保证路径符合项目预期，我会先把业务目标和边界写成显式约束，包括任务成功条件、禁止动作、可用工具、参数范围、优先级和最大影响面；再把流程抽象成状态机或工作流图，让每一步只能从合法状态转移到合法状态；每轮 think 输出结构化计划，经过 schema、权限、业务规则、前置条件和预算校验后才能 execute；执行结果进入评估器，判断是否达成目标、是否需要重试、是否需要澄清、是否应终止或人工接管。最后用测试开发视角做验证：准备 golden path、异常依赖、边界输入、对抗提示、循环诱导和历史 badcase 回放，观察路径覆盖率、越界率、循环率、工具误调用率、任务成功率和 p95 步数。这样路径控制不是靠相信模型，而是靠约束、状态、评估和测试闭环。

考点 循环的适用性

难度 真实面经题

回答目标 让候选人能把 think-execute 讲成可约束、可执行、可测试的 Agent 工作流控制问题，而不是泛泛描述链式思考。

深入解析

先说明为什么需要循环

很多 Agent 任务不是一次回答能完成的，例如需要先理解意图、再检索资料、调用工具、校验结果、补充上下文和处理失败。think-execute 把推理和动作拆开，使系统能根据执行反馈调整下一步。但它的代价是路径变长、状态更多，也更容易出现偏航和死循环。

项目预期要变成显式约束

不能只在 prompt 里写一句按照项目预期执行。项目预期应拆成任务目标、成功判定、禁止行为、可用工具、输入输出格式、权限范围、数据边界、成本预算和最大步数。模型每一轮规划都要在这些约束内选择动作，超出约束就不能执行。

用状态机限制合法路径

如果业务流程有明确阶段，可以把 Agent 运行过程建模为状态机或 DAG，例如意图识别、信息收集、工具调用、结果校验、交付和结束。每个状态只允许有限动作和有限下一状态，避免模型从任意节点跳到任意工具。对于测试开发场景，这种状态定义也方便写覆盖用例和路径断言。

结构化计划必须先校验再执行

每轮 think 不应直接输出自然语言动作，而应输出 next_action、reason、tool、arguments、expected_observation、risk_level 和 stop_condition 等结构化字段。执行前由系统做 schema 校验、参数校验、权限校验、前置条件校验和预算校验。校验失败时走澄清、重规划或终止，而不是让模型自己解释一下继续执行。

评估器决定继续、重试还是停止

execute 后需要一个独立评估环节判断结果是否推进了任务。评估器可以是规则、断言、业务校验、检索证据一致性检查、单元测试或轻量模型 judge。它要回答四个问题：目标是否完成，当前动作是否有效，是否偏离约束，是否达到停止条件。没有评估器的循环只是反复让模型自由发挥。

测试回放要覆盖偏航和循环

验证 think-execute 机制时不能只跑正常样例。要构造工具超时、空结果、错误结果、权限不足、用户需求含糊、对抗提示、重复失败、上下文冲突和高成本任务。关键指标包括任务成功率、非法路径率、平均步数、最大步数命中率、循环拦截率、工具误调用率、人工接管率和可复现 badcase 修复率。

易错点

只解释 think-execute 是先思考再执行，没有说明为什么循环会带来路径偏离和无限循环风险。
把项目预期只写在 prompt 里，没有转成状态机、工具白名单、参数边界和可执行校验。
让模型自然语言计划直接触发工具调用，缺少结构化 action、schema 校验和权限校验。
只看最终答案是否对，不记录中间路径、工具调用、状态转移和失败重试过程。
停止条件只设置最大轮数，忽略连续无进展、重复错误、预算耗尽和风险升级等信号。
测试只覆盖正常路径，没有覆盖异常依赖、越权请求、对抗提示和历史 badcase 回放。

面试官追问

think 阶段和 execute 阶段为什么要分开？

分开后规划可以被检查，执行可以被隔离和审计。否则模型把推理、工具选择和动作执行混在一起，系统很难在危险动作发生前拦截。

如何设置循环的停止条件？

常见停止条件包括目标达成、最大步数、最大耗时、连续无进展、连续同类错误、预算耗尽、风险升高、用户需要澄清或命中人工接管规则。停止后要返回可解释状态，而不是静默失败。

如果模型规划的路径看起来合理但结果不符合业务怎么办？

要把不符合业务的原因沉淀成规则或评估用例，例如缺少前置条件、工具选择错误、参数范围错误或结果校验不足，然后在计划校验器、状态机或评估器里补约束。

测试开发如何验证 Agent 没有被提示词带偏？

可以构造 prompt injection、越权请求、无关目标扩展、要求跳过校验、诱导重复调用等用例，并断言系统拒绝、澄清、停机或进入人工处理，而不是只检查最终回答文本。

路径控制会不会让 Agent 变得不够智能？

会牺牲一部分自由探索，但换来可预测、可测试和可上线。可以通过状态内候选动作、可配置策略和低风险探索区保留灵活性，高风险路径必须优先可控。