Agent 面试题

用“能够查订单、生成处理方案并提交工单的助手”贯穿回答。面试的重点是模型如何参与决策，以及系统如何约束、记录和恢复这些决策。

核心问题

1. Agent 和固定工作流怎么区分？

固定工作流由代码确定主要步骤；Agent 允许模型根据观察结果选择后续行动。二者可以组合：代码负责鉴权、预算和状态提交，模型负责在限定工具中选择下一步。任务步骤稳定、规则能覆盖时，先考虑普通程序或固定工作流，减少不必要的模型调用。

追问：只调用一次工具算不算 Agent？先约定定义，随后讨论实际控制权和失败模式，标签本身不能证明系统可靠。参见 Agent 全景。

2. Tool calling、planning、reflection、memory 分别负责什么？

能力	输入与输出	工程边界
工具调用	任务状态 → 工具名称和参数	模型提出调用，执行器验证并执行
规划	目标与约束 → 步骤与依赖	计划不是事实，执行后要更新状态
反思	产物与反馈 → 修正建议	缺少外部证据时可能重复原错误
记忆	已发生事件 → 可检索的状态或摘要	需要来源、时效、权限和删除机制

不要把对话摘要当作外部动作的最终执行记录。是否成功创建工单，应以业务系统返回与查询结果为准。继续阅读 记忆管理 与 规划。

3. 工具超时后可以直接重试吗？

先区分结果：请求未发送、明确失败、结果未知。读取通常可在预算内重试；创建工单等写入可能已经生效，只是响应丢失。应使用稳定的幂等键或查询业务状态，确认后再决定是否重试。

失败案例：客户端超时后重新生成一个幂等键，仍可能重复创建工单。幂等键应绑定同一业务动作，重试时复用；真正的新动作才使用新键。更多见 异常处理与恢复。

4. 什么时候使用多 Agent？

当子任务能独立执行、输入边界清楚、结果可合并时，考虑并行分工，例如分别核对多个独立文档。若所有子任务都争用同一可写状态或需要频繁交换上下文，协调开销可能超过收益。

实验设计：让单 Agent 与多 Agent 在相同工具权限、任务集和成本预算下比较成功率、总 token、完成延迟和冲突次数。增加角色数量本身不算改进。参见 多智能体协作。

5. 如何防止提示注入导致越权执行？

网页、检索结果和工具输出都作为外部数据处理，不能升级为系统授权。执行器在每次工具调用时检查真实身份、资源权限、参数范围及业务条件；涉及重要外部变更时，根据产品规则展示具体动作并取得确认。

关键词过滤和第二个模型可以辅助检测，但不能替代服务端权限校验。测试应包含正常任务夹带恶意指令、工具描述污染，以及合法参数指向无权限资源等情况。详见 安全。

追问角度

• 如何停止：明确完成条件、最大步骤、时间/token 预算、取消信号和无法继续时的交接状态。
• 如何恢复：保存任务 ID、已确认的动作、待确认结果、检查点和下一步，避免恢复时重复执行写入。
• 如何评估：验证最终业务状态、参数正确性、越权次数、人工接管原因，以及每个成功任务的成本。

示例回答骨架

“我会把订单查询做成只读工具，把工单创建拆成草稿和提交。运行时负责 schema 校验、权限、预算与幂等，模型只在这些边界内决定下一步。每次调用保存请求 ID 和结果状态；超时先查结果，不立即重复写入。评估同时看最终任务是否完成、是否越权，以及失败后能否恢复。”

自测

画出“工单已创建但响应丢失”的恢复路径；说明哪些信息可以重新生成，哪些状态必须从业务系统确认。用 评估与监控 设计一个能够发现重复写入的指标。