Agent 系统设计面试题：如何讲清楚一个生产级 Agent
这篇文章解决什么问题
面试中经常会被问：
- 你怎么设计一个 AI Agent 系统？
- Agent 和普通 LLM 应用有什么区别？
- Agent 怎么调用工具？
- Agent 怎么保证执行过程可追踪？
- Agent 效果怎么评估？
- Agent 出错怎么恢复？
- Agent 怎么做权限控制和安全审计？
如果你只回答"用 LangChain / LangGraph"或者"写好 Prompt 就行"，面试官会觉得你没有工程落地经验。
核心观点：回答 Agent 系统设计时，不能只说框架名，而要讲清楚系统分层、执行链路、状态管理、工具权限、可观测性和评测闭环。
这篇文章基于 HFL AI Agent Lab 站点建设中积累的 Agent 工程理解，整理面试中如何讲清楚一个生产级 Agent 系统。
面试官真正想考什么
| 考察点 | 面试官想确认什么 |
|---|---|
| 是否理解 Agent 和普通 LLM 应用的区别 | 你知不知道 Agent 不只是调 API 返回文本 |
| 是否理解 Runtime | 你知不知道 Agent 需要一个执行引擎来组织模型、工具和状态 |
| 是否理解工具调用工程化 | 你知不知道 Tool Calling 不是简单函数调用 |
| 是否理解状态管理 | 你知不知道多步骤任务需要 State 推进 |
| 是否理解 Trace | 你知不知道生产级 Agent 需要可追踪的执行轨迹 |
| 是否理解 Evaluation | 你知不知道 Agent 需要评测闭环 |
| 是否理解安全边界 | 你知不知道 Agent 调用工具会带来安全风险 |
| 是否有工程落地意识 | 你能不能把概念落地成可执行的系统设计 |
面试官不是想听你背概念，而是想确认你有没有想过"如果真要做一个 Agent 系统，应该怎么设计"。
回答 Agent 系统设计时，要展示你考虑到了工程落地的各个方面：不只是模型能做什么，还有系统怎么保证可控、可追踪、可评估、可恢复。
一句话回答框架
如果让我设计一个生产级 Agent 系统，我会把它拆成请求入口、Agent Runtime、工具系统、Memory / State、Trace、Evaluation、安全控制和部署监控几个模块。Runtime 负责接管任务、组织模型调用、选择工具、推进状态和生成结果；工具系统负责 Schema、参数校验、权限和执行；Trace 记录每一次模型调用、工具调用和状态变化；Evaluation 负责评估任务完成率、工具调用准确率、成本和安全风险。这样系统不是只会生成文本，而是可以执行、可追踪、可评估、可恢复。
这个回答框架的核心是：不讲框架名，讲系统模块；不讲 Prompt，讲执行链路；不讲"能做什么"，讲"怎么保证可控"。
Agent 系统分层
| 层级 | 作用 | 面试表达 |
|---|---|---|
| API 层 | 接收用户请求，返回结果 | 负责请求接入、鉴权、限流和结果格式化 |
| Runtime 层 | 任务执行引擎，组织模型、工具、状态和 Trace | 负责创建 run_id、推进 step、调用模型、选择工具、生成结果 |
| Tool 层 | 工具注册、Schema、参数校验、权限和执行 | 负责工具调用的安全、规范和可追踪 |
| Memory / State 层 | 管理会话上下文、长期记忆和任务状态 | 负责 Context 构建、State 推进和 Memory 复用 |
| Trace 层 | 记录每次模型调用、工具调用和状态变化 | 负责执行轨迹的完整记录和问题定位 |
| Evaluation 层 | 评估任务完成率、工具准确率、成本和安全 | 负责质量闭环和持续优化 |
| Security 层 | 权限控制、审计日志、敏感信息脱敏 | 负责工具调用的安全边界和合规 |
| Storage 层 | 持久化任务数据、Trace、Memory 和评测结果 | 负责数据的可靠存储和查询 |
| Deployment 层 | 部署、监控、告警和扩缩容 | 负责系统上线后的稳定运行 |
面试时不需要每一层都展开，但要让面试官知道你考虑到了这些层面。
Agent 执行链路怎么讲
一条完整的 Agent 执行链路：
用户请求 → API 接入 → Runtime 创建 run_id → 读取 Session / Memory / State → 调用模型 → 解析 Action → 校验工具参数 → 权限检查 → 执行工具 → 更新状态 → 记录 Trace → 判断是否继续 → 生成最终结果 → 进入 Evaluation
每一步的作用：
- 用户请求：用户通过 API 发起任务。
- API 接入：鉴权、限流、格式化请求。
- Runtime 创建 run_id：为这次任务创建唯一标识。
- 读取 Session / Memory / State：构建当前上下文。
- 调用模型：传入上下文，获取下一步行动。
- 解析 Action：把模型输出解析成结构化行动。
- 校验工具参数：检查参数是否符合 Schema。
- 权限检查：检查用户是否有权限调用该工具。
- 执行工具：调用工具系统执行操作。
- 更新状态：根据工具结果更新任务状态。
- 记录 Trace：记录这次调用的完整信息。
- 判断是否继续：检查停止条件，决定继续还是结束。
- 生成最终结果：整理所有信息，生成用户可读结果。
- 进入 Evaluation：对结果进行质量评估。
Runtime 怎么讲
面试中要强调：
- Runtime 不是模型。模型负责推理，Runtime 负责执行。
- Runtime 是任务执行引擎。它组织模型调用、工具调用、状态推进和结果生成。
- Runtime 要有停止条件。最大 step 数、最大耗时、成本上限。
- Runtime 要有错误处理。工具失败、模型输出异常、超时。
- Runtime 要有成本统计。记录每次模型调用的 token 消耗。
- Runtime 要有状态恢复。任务中断后能从断点继续。
面试表达：
我会把 Runtime 设计成任务执行中心，每次任务生成 run_id，每个阶段生成 step_id，模型调用、工具调用和状态变化都挂在同一个执行轨迹下。Runtime 不只是 while loop，还要处理权限控制、Trace 记录、错误恢复、成本统计和人工审批。
Runtime 的核心设计原则是：每次任务执行都有唯一标识，每个步骤都有状态记录，每个工具调用都有权限检查，每个错误都有处理策略，每次执行都有成本统计。这样系统才是可控的、可追踪的、可优化的。
Tool Calling 怎么讲
工具调用不是普通函数调用，而是一套完整的工程机制。工具 Schema 至少要定义：
tool_name：工具唯一标识。description：功能描述，帮助模型判断什么时候用。input_schema：输入参数的 JSON Schema。output_schema：输出结果的结构定义。permission_level：权限等级。risk_level：风险等级。timeout：超时时间。retry_policy：重试策略。audit_log：审计日志。
必须讲的工程点：
- 参数校验：模型生成的参数不能直接执行，需要校验类型、必填字段、值域和安全风险。
- 权限控制：检查当前用户是否有权限调用该工具。
- 高风险审批：删除数据、发送消息、执行代码等操作需要审批。
- 错误处理：根据错误类型决定重试、降级还是终止。
- 结果结构化：返回 status、data、error_code、latency_ms。
- Trace 记录：每次工具调用都记录到 Trace。
面试表达：
我不会把 Tool Calling 当成普通函数调用。模型生成的参数可能有格式错误、类型不匹配甚至安全风险，必须经过参数校验和权限检查才能执行。高风险工具还需要审批机制，不能只靠 Prompt 约束。
Memory / State 怎么讲
面试中不要把 Memory 简化成聊天记录。要区分五个概念：
- Session：当前会话容器。
- Context：当前模型调用看到的信息。
- Memory：长期可复用信息，跨会话持久化。
- State：任务执行状态，记录当前步骤和进度。
- Trace：执行过程记录。
面试表达：
State 用于任务推进——记录当前步骤、已完成步骤、待处理操作和关键状态摘要。Memory 用于长期复用——保存用户偏好、项目背景和历史经验。Trace 用于复盘和审计——记录每次模型调用、工具调用和状态变化。这三者有不同的生命周期和管理策略。
面试中还要提到上下文压缩：长任务会导致上下文膨胀，需要压缩策略——保留关键状态摘要和工具调用结果，丢弃低价值的历史内容。这样既保证模型有足够的信息，又不会超出 token 限制。
Trace 怎么讲
生产级 Agent 必须记录完整执行轨迹：
run_id：任务执行唯一标识。step_id：当前步骤标识。model_call：模型调用的输入、输出和耗时。tool_call：工具调用的名称、参数、结果和状态。state_change：任务状态的变化。error_event：错误信息和处理方式。latency：执行耗时。token_usage：token 消耗。cost：成本。final_result：最终结果。
面试表达：
我不会只保存最终答案，而会保存完整执行轨迹。这样当 Agent 出错时，可以定位是模型输出问题、工具参数问题、权限问题、外部服务问题还是状态推进问题。Trace 也是 Evaluation 的数据来源——通过分析 Trace 可以发现哪些步骤容易失败、哪些工具调用不准确。
Trace 的设计原则是：只记录推进任务所需的信息，不记录无关细节。敏感信息（如 API Key、Token）需要脱敏后记录。
Evaluation 怎么讲
Agent 评测不能只看最终文本。至少要看这些指标：
- Task Success Rate：任务完成率。
- Tool Call Accuracy：工具调用准确率。
- Step Completion：步骤完成率。
- Error Recovery：错误恢复率。
- Latency：执行延迟。
- Cost：token 消耗和工具调用成本。
- Human Intervention Rate：人工干预率。
- Safety Violation Rate：安全违规率。
面试表达：
Evaluation 要和 Trace 关联，通过 run_id 定位失败原因。比如某个任务失败了，通过 Trace 可以看到是第几步出了问题、工具调用参数是否正确、模型输出是否异常。这样评测不是黑盒打分，而是有据可查的改进依据。
Evaluation 还要区分离线评测和在线评测。离线评测用评测集跑指标，适合版本对比和回归测试；在线评测收集真实用户反馈，适合发现实际使用中的问题。两者结合才能建立完整的质量闭环。
Security 怎么讲
Agent 能调用工具后，安全风险上升。必须考虑：
- 权限上下文：当前用户是谁、有什么权限。
- 工具白名单：只允许调用已注册的工具。
- 高风险工具审批：删除、发送、执行等操作需要审批。
- 敏感信息脱敏：Trace 中不保存 API Key、Token、密码。
- 审计日志：记录所有工具调用和状态变化。
- 沙箱执行：高风险操作在隔离环境中执行。
- 人工确认：关键操作需要人工确认。
- 失败回滚：操作失败后能回滚到安全状态。
面试表达：
Agent 的安全风险比普通 LLM 应用高，因为它能执行操作。我会在 Runtime 层面实现强制的权限检查和审批机制，而不是只靠 Prompt 约束。Prompt 可能被绕过或产生幻觉，但工程层面的权限检查是确定性的。
安全控制要贯穿整个 Agent 执行链路：请求接入时鉴权，工具调用前检查权限，执行过程中记录审计日志，敏感信息在 Trace 中脱敏，高风险操作需要人工审批。这样即使模型输出异常，也不会导致安全事故。
常见追问
追问 1：Agent 和 Workflow 有什么区别？
回答要点：
- Workflow 更偏预定义流程，按固定节点顺序执行。
- Agent Runtime 更偏动态决策，根据模型输出和状态决定下一步。
- 确定性任务适合 Workflow，开放性任务适合 Agent。
- 二者可以结合——用 Workflow 定义大框架，用 Runtime 处理动态逻辑。
追问 2：Agent 怎么避免无限循环？
回答要点：
- 最大 step 数限制：比如最多 20 步。
- 最大耗时限制：比如最多 5 分钟。
- 成本上限：比如最多消耗 10000 token。
- 状态变化检测：如果连续多步状态没有变化，说明 Agent 可能陷入了循环，强制停止。
- 人工接管机制：超时或超限后通知人工介入。
追问 3：Agent 工具调用失败怎么办？
回答要点：
- 根据错误类型决定处理策略。
- 临时性错误（超时、服务不可用）可以重试，设置最大重试次数。
- 参数错误需要让模型重新生成参数，可能需要补充错误信息到上下文。
- 权限不足需要提示用户，不能自动重试。
- 外部服务不可用可以降级或换工具。
- 记录错误到 Trace，用于后续分析和优化。
追问 4：多工具冲突怎么办？
回答要点：
- 定义工具优先级。
- 引入 Reviewer 检查冲突。
- 记录冲突原因到 Trace。
- 需要时引入人工确认。
追问 5：如何判断 Agent 是否完成任务？
回答要点：
- 模型输出 final_answer 类型的 Action：这是最直接的完成信号。
- 达到最大 step 数：防止无限循环。
- 达到最大耗时：防止任务卡住。
- 达到成本上限：控制 token 消耗。
- 用户主动终止：用户可以随时取消任务。
追问 6：如何记录执行过程？
回答要点：
- 每次模型调用记录到 Trace。
- 每次工具调用记录到 Trace。
- 每次状态变化记录到 Trace。
- 通过 run_id 和 step_id 关联所有记录。
追问 7：如何做安全控制？
回答要点：
- 工具权限分级：不同角色有不同的工具访问权限。
- 高风险工具审批：删除、发送、执行等操作需要人工确认。
- 敏感信息脱敏：Trace 中不保存 API Key、Token、密码。
- 审计日志：记录所有工具调用和状态变化。
- 沙箱执行：高风险操作在隔离环境中执行。
追问 8：如何做线上评测？
回答要点：
- 通过 Trace 收集执行数据。
- 定义评测指标（Task Success、Tool Accuracy、Cost）。
- 定期跑评测集。
- 对比版本间的效果变化。
- 失败样本进入迭代优化。
线上评测和离线评测结合，才能建立完整的质量闭环。
容易踩坑的回答
- 只说"我会用 LangChain / LangGraph"——面试官会觉得你只会用框架，不理解原理。
- 只讲 Prompt——面试官会觉得你没有工程概念。
- 把 Tool Calling 当普通函数调用——面试官会觉得你没考虑安全和规范。
- 不提权限和审计——面试官会觉得你没有安全意识。
- 不提 Trace——面试官会觉得你不知道怎么调试 Agent。
- 不提 Evaluation——面试官会觉得你不知道怎么评估效果。
- 不提错误恢复——面试官会觉得你只考虑了正常流程。
- 不提成本和延迟——面试官会觉得你没有生产意识。
- 把 Agent 说成万能自动化系统——面试官会觉得你对 Agent 能力边界没有认知。
更好的表达方式
| 不推荐表达 | 更好的表达 |
|---|---|
| 我会用 LangChain 来做 Agent | 我会把 Agent 系统拆成 Runtime、Tool、Memory、Trace、Eval 等模块，框架只是实现方式之一 |
| Agent 就是 LLM + Tool Calling | Agent 是一个任务执行系统，Runtime 负责组织模型调用、工具调用、状态推进和结果生成 |
| 工具调用就是一个函数 | 工具调用需要 Schema 定义、参数校验、权限控制、错误处理和 Trace 记录 |
| 保存聊天记录就是 Memory | 要区分 Session、Context、Memory、State 和 Trace，它们有不同的生命周期 |
| Prompt 写好就行 | Prompt 只是输入，还需要 Runtime 来组织执行、Trace 来记录过程、Evaluation 来评估效果 |
| Agent 能自动完成所有任务 | Agent 有明确的能力边界，高风险操作需要人工审批，复杂任务需要人机协作 |
| 测试一下就知道效果 | 需要建立评测指标体系，通过 Trace 定位失败原因，用失败样本驱动迭代 |
| 直接部署就行了 | 需要考虑监控、告警、成本控制、权限管理和审计日志 |
| Agent 出错就让模型重新回答 | 需要根据错误类型决定重试、换工具、降级或人工接管，不能只靠模型 |
| 多 Agent 就是多个角色协作 | 需要讲清楚调度机制、状态共享、工具权限、冲突处理和结果聚合 |
对个人项目的启发
项目 A（RAG 工单系统）：
RAG 查询可以设计成可追踪的 run。从用户提问到返回答案，整个过程可以用 Runtime 的思路来管理。文档检索、Rerank、答案生成、引用返回都可以记录为 step。后续可以加入 Evaluation Pipeline，通过 Trace 分析每次查询的效果。这样项目 A 不仅是一个 RAG 应用，更是一个可追踪、可评估的 Agent 系统。
面试时可以这样表达：我把 RAG 查询设计成一个完整的 Agent 执行链路，每次查询有 run_id，每个阶段有 step_id，检索结果、排序分数、引用来源都记录到 Trace。这样当答案质量不好时，可以精确定位是哪个环节出了问题。
项目 B（多 Agent 运营中台 Copilot）：
后续可以围绕 Runtime、Tool、State、Trace、Evaluation 设计多 Agent 协作。不能只讲多角色协作，要讲任务分派、工具权限、状态共享和结果聚合。Project B 已整理为作品集入口，面试表达时可以结合该项目讲清楚规划思路。
面试时可以这样表达：我的多 Agent 设计思路是围绕 Runtime 展开的——Planner 负责任务拆解，Executor 负责执行操作，Reviewer 负责审查结果，Aggregator 负责汇总输出。每个 Agent 有独立的工具权限，通过 Shared State 共享必要信息，通过 Trace 记录完整执行过程。
后续 TODO
- 补充 Agent 系统设计图，展示各模块的关系和数据流。
- 补充 Agent 系统设计 3 分钟口述稿，用于面试快速表达。
- 补充 Runtime / Tool / Trace / Eval 的项目表达模板，可直接迁移到项目 A 和项目 B。
- 补充 Agent 系统设计模拟面试问答，覆盖常见追问和进阶问题。