Agent 项目很容易展示得很漂亮：用户给一个目标，模型拆步骤，调用工具，最后生成结果。但面试官如果继续问“它做错了怎么办”“会不会一直循环”“工具执行谁负责确认”，就进入了真正的工程问题。
Agent 会规划只是第一步。可上线的 Agent 必须把计划、执行和反思分开约束，否则模型看起来更自主，系统反而更不可控。
计划不是承诺，只是草案
模型生成的计划，本质上是对任务的理解和分解，不应该直接等同于系统承诺。计划里可能漏步骤、顺序错、把不可执行的动作写进去，也可能把用户没有授权的操作放进流程。
更稳的做法是让计划进入校验层。系统检查任务是否完整、工具是否存在、参数是否足够、权限是否允许、高风险动作是否需要确认。低风险任务可以自动执行，高风险任务必须让用户确认或转人工。
工具执行要由后端接管
Agent 调用工具时，模型只提供意图和参数，真正执行必须由后端负责。后端要校验参数、检查权限、设置超时、记录审计日志，并根据错误类型返回结构化结果。不能让模型绕过业务系统直接决定执行。
比如模型想“取消订单”，后端要判断订单是否属于当前用户，是否还允许取消，是否需要二次确认，取消失败是否会产生补偿任务。模型理解了用户意图，不代表它有权执行动作。
反思不能变成无限循环
很多 Agent 框架会加入反思或自我修正：执行失败后，让模型分析原因并重新规划。这在演示里很有用，但上线后必须限制次数和范围。否则一个工具持续失败，模型可能不断重试，既浪费成本，也可能放大外部系统压力。
反思应该有明确边界：最多重试几次，哪些错误可以让模型修正，哪些错误必须停止。参数格式错误可以让模型修正一次；权限不足不能让模型想办法绕过；外部系统超时应该退避或降级，而不是立即连续重试。
中间状态要能恢复
多步骤 Agent 最怕执行到一半失败。前两步已经创建了资源，第三步失败，系统要知道当前到了哪里，是否可以继续，是否需要回滚，用户能看到什么状态。
这意味着 Agent 任务最好有任务记录和步骤状态，而不是只靠一次对话上下文。每一步的输入、输出、工具结果、错误码和耗时都应该可追踪。这样失败后才能从某一步恢复，或者给用户一个可信的失败解释。
面试里可以这样讲
我会把 Agent 分成计划层、校验层、执行层和审计层。模型负责提出计划和参数，后端负责权限、参数、风险和执行；反思只处理可修正错误，且有次数和成本上限；多步骤任务要保存中间状态，支持恢复或补偿。这样 Agent 才不是“模型想做什么就做什么”，而是一个受控的自动化系统。
还要给 Agent 设置预算。预算不只是钱，也包括最大步骤数、最大工具调用次数、最长执行时间和最大上下文长度。没有预算的 Agent 很容易在复杂任务里反复尝试，看起来很努力，实际是在消耗资源。
面试里可以补一句：我会把预算展示给任务执行器，而不是只写在提示词里。执行器到达上限就停止，并把已完成步骤、失败原因和下一步建议返回给用户。这样系统即使没完成任务，也不会失控。