AI Knowledge

外观

Agent 工程化与安全专项面试题 ​

目录 ​

1. 使用说明 ​

  • 对应知识主题：Agent 工程化与安全；
  • 角色：资深面试官从运行时信任边界追问到多租户生产系统，高级技术应聘者负责给出可靠性状态机、权限、对账和审计证据；
  • 回答顺序：先用 1～3 句专业短答，再用生活化解释；必须区分 Guardrail 与授权，以及重试、幂等、对账、补偿和检查点；

事实红线｜ 超时不等于外部未执行；没有外部协议与实测证据时不能宣称跨系统 exactly-once，所有项目事故与指标必须有证据；

  • 题目数量：7 题，严格覆盖 L1～L7。

阅读图例｜ L1～L2 概念与边界 · L3～L4 原理与实现 · L5 工程 · L6 架构 · L7 项目复盘

答案层级｜ 必答结论 · 小白解释 · 加分项 · 高频误区 · 下一问

2. 递进路线 ​

图：Agent 工程化与安全 L1～L7 递进路线

替代文本： L1 生产控制面 → L2 可靠性概念边界 → L3 不确定结果状态机 → L4 受控执行器实现 → L5 重复副作用故障闭环 → L6 多租户安全架构 → L7 示例面试教练工程化复盘。

图表加载中…

读图结论： 蓝色阶段建立概念与边界，紫色阶段进入原理与实现，橙色和青色阶段验证工程与架构能力，绿色阶段用项目证据完成复盘。

这条路线的关键节点不是七个孤立标签：L1～L2 先把模型提议、Guardrail、服务端授权、重试、幂等、对账、补偿和检查点分清；L3 把超时提升为独立的 SUBMISSION_UNKNOWN 状态；L4 再把可信身份、动作指纹、批准消费和持久幂等落进执行器。L5 用重复副作用演练检查证据与恢复闭环，L6 将单次工具边界扩展到多租户记忆和观测，L7 最后要求用示例项目说明验证方法与事实边界。后一层只有建立在前一层的状态语义和证据之上，才算真正递进。

图：高风险 Agent 动作从提议到对账收敛的安全门

替代文本： 模型提出的高风险动作依次经过 Schema 与工具白名单、服务端身份和资源鉴权、策略与预算检查；需要人工确认时进入未执行的等待态，确认必须绑定最终动作指纹。获准动作使用业务意图幂等键执行；明确结果被分为成功、永久失败、可重试失败和需要对账或补偿的部分成功，可重试失败只有在策略与预算允许时才沿同一幂等键回流。超时或响应丢失进入显式未知状态，先对账再决定完成、受控重试或人工处置。

图表加载中…

读图结论： 安全执行不仅要“验证身份与动作 → 必要时等待精确批准 → 幂等执行”，还要把永久失败、预算内可重试失败、需对账或补偿的部分成功以及结果未知分开收敛；任何受控重试都必须沿原业务意图的同一幂等键回流。

这张图把控制面和失败语义同时拆开：Schema、Guardrail 和策略筛选候选动作，真正的授权来自服务端身份与资源状态；人工确认只批准当时展示的规范化参数，参数变化必须重新确认。永久失败直接终止，可重试失败先检查错误类型、策略和预算，再携带原幂等键回到执行占位；部分成功或已产生副作用的失败必须先确定影响范围，补偿本身也使用独立幂等键。外部调用超时时，本地不知道结果并不等于失败，因此保存 SUBMISSION_UNKNOWN 并先查真实结果；只有确认未执行后，才进入同一重试预算门。

3. 一问一答 ​

第 1 题｜L1 概念｜Demo Agent 到生产 Agent，最关键的工程差距是什么？ ​

核心考察点｜概率决策、确定性执行、Guardrail 与授权边界

面试官提问

请从模型职责、运行时职责和信任边界回答，并解释 Guardrail 是否等于权限。

30 秒专业短答

生产 Agent 要把模型的不确定性限制在候选决策层，把身份、Schema、服务端授权、预算、状态、幂等、重试、审计和验收放进确定性运行时。Guardrail 可筛查输入、输出或参数，但不是 IAM 或资源授权；即使模型和 Guardrail 都说允许，工具服务端仍必须依据可信身份、资源范围和业务状态重新鉴权。

小白解释

模型像提出操作建议的实习生，Guardrail 像前台检查表，但真正开保险库要由门禁系统核验本人、钥匙和可访问柜子；一张“我已获授权”的纸条不能替代门禁。

  • 合格线｜ 模型只建议；身份、权限、副作用和验收由服务端控制；
  • 加分项｜ 输入/工具/输出 Guardrail 分层，认证上下文绝不来自模型或请求体自报字段；
  • 高频误区｜ 在 System Prompt 写“不要越权”就当安全完成，或让模型判断自身权限；
  • 下一问｜ 信任边界明确后，继续区分可靠执行中的五个不同机制。

第 2 题｜L2 边界｜重试、幂等、对账、补偿和检查点分别解决什么问题？ ​

核心考察点｜分布式副作用的错误语义和恢复职责

面试官提问

请用一个跨系统写操作说明它们为什么不能互相替代。

30 秒专业短答

重试再次尝试可恢复失败；幂等让同一业务意图重复到达时结果等同一次；对账在结果不确定时查询外部真实状态；补偿为无法原子回滚的已完成步骤执行反向业务动作；检查点保存恢复位置和必要状态。重试不能替代幂等，幂等也不自动提供跨系统事务或 exactly-once。

小白解释

转账按钮卡住时，重试是再按一次，幂等是同一转账单不会重复扣款，对账是去银行流水查到底成功没，补偿是错转后发起退款，检查点是记住流程走到哪一步；这五件事解决不同问题。

  • 合格线｜ 五个概念定义准确，明确重试≠幂等、幂等≠跨系统事务；
  • 加分项｜ 幂等键代表业务意图，状态用唯一约束/条件更新持久化；
  • 高频误区｜ 认为 HTTP 重试库自动保证幂等，或说有幂等键就实现外部 exactly-once；
  • 下一问｜ 概念区分后，继续解释超时为何产生“不知道是否已执行”的第三种状态。

第 3 题｜L3 原理｜工具超时后为什么不能直接判失败并重试？ ​

核心考察点｜网络不确定性、显式状态、对账优先和重提条件

面试官提问

请设计 SUBMISSION_UNKNOWN 的状态迁移，并说明何时才能再次提交。

30 秒专业短答

超时只表示本地未收到确定响应，外部动作可能未执行、执行中或已成功；对副作用调用盲目重试可能重复扣费、发消息或修改资源。运行时应保存业务意图幂等键与外部任务标识，将状态置为 SUBMISSION_UNKNOWN，先对账；确认已成功则收敛为成功，确认未执行且仍满足策略时才允许受控重试，无法对账的不可逆动作应转人工。

小白解释

自动售货机扣款后没掉饮料，你不能马上连续刷卡；先查扣款和出货记录，确认没扣钱才重试，已经扣款则走补货或退款，查不清就找工作人员。

  • 合格线｜ 超时≠未执行，结果未知先冻结重提并对账；
  • 加分项｜ 使用供应商原生幂等 Token、业务键查询、状态告警和同资源写隔离；
  • 高频误区｜ 所有超时指数退避重试，或把本地异常直接标记外部失败；
  • 下一问｜ 状态语义明确后，把可信身份、动作指纹、人工批准和原子占位落到执行器。

第 4 题｜L4 实现｜如何实现一个受控的高风险工具执行器？ ​

核心考察点｜可信身份、最小权限、动作指纹、批准与持久幂等

面试官提问

请从认证上下文、策略、人工批准、幂等记录和并发控制说明。

30 秒专业短答

认证中间件构造不可由模型修改的 AuthContext，执行器先做工具允许列表、Schema、角色与资源级授权，再用服务端签发的 intent_id、规范化参数和资源版本生成动作指纹。高风险批准绑定身份、动作指纹、策略/资源版本与有效期，并在数据库唯一约束创建执行占位时原子消费；重复意图只返回已有结果或进入对账，不跨慢外部调用持有锁。

小白解释

开保险柜前要核验证件、可开的柜号和操作清单；用户批准的是“这个人今天取这个柜中的这件物品”，任何对象或数量改变都要重新确认。系统先登记唯一业务单，再执行，重复送来的同一单不能再做一次。

  • 合格线｜ 服务端身份/授权、精确批准、唯一意图、重复结果处理；
  • 加分项｜ 乐观锁/条件更新、批准原子消费、规范化参数、外部对账与审计日志分离；
  • 高频误区｜ 模型自报 user_id/role，批准后可改参数，或用进程内字典冒充生产幂等；
  • 下一问｜ 执行器设计完成后，继续用重复副作用事故演练验证恢复与证据链。

第 5 题｜L5 工程｜Agent 因超时重试造成疑似重复副作用，如何闭环处理？ ​

核心考察点｜生产副作用事故的证据、止损、恢复和防复发

面试官提问

请按现象、证据、止损、根因、修复、验证和防复发回答。

30 秒专业短答

先暂停同资源自动写入和相关重试，固定 run_id、intent_id/call_id、动作指纹、外部任务 ID、状态历史、网络错误与业务结果；向外部系统对账确认每个意图的真实状态和影响范围。根因可能是响应丢失后被当失败、缺业务幂等键或本地落库非原子；修复为唯一意图占位、SUBMISSION_UNKNOWN、对账恢复和受控补偿，再注入“外部成功、响应丢失、进程崩溃、重复回调”验证业务结果收敛，并建立告警、Runbook 和回归。没有外部系统协议与验证，不能宣称 exactly-once。

小白解释

发现可能重复扣款时先停掉自动扣款，逐笔查银行流水和订单号，再退款或补记；之后模拟“银行扣了但收银机没收到回执”，确认系统先查账而不是再扣一次。

  • 合格线｜ 停止重提、按业务意图对账、显式未知状态、故障注入验证；
  • 加分项｜ 重复/乱序 Webhook 唯一约束、状态机合法迁移、死信队列和补偿幂等；
  • 高频误区｜ 清空本地记录重新执行，或无证据宣称“保证只执行一次”；
  • 下一问｜ 单工具副作用能控制后，继续设计多租户、长期记忆、外部内容与观测的整体安全架构。

第 6 题｜L6 架构｜如何设计多租户 Agent 的权限、记忆、观测和恢复架构？ ​

核心考察点｜身份与数据隔离、间接注入、耐久状态、可观测与隐私

面试官提问

请覆盖提示注入、跨用户记忆、工具预算、长任务和隐私。

30 秒专业短答

网关认证后由服务端注入主体与 entitlement，工具层执行最小权限和资源级授权；外部网页、检索文本与工具结果标记为不可信数据，不能覆盖系统策略。长期记忆按 tenant/user/用途隔离并具备来源、TTL、撤权和删除，缓存绑定权限范围；长任务用持久状态机、事件历史、检查点、幂等记录与合法迁移恢复。Trace 记录模型/Prompt/工具/Guardrail/状态/成本，但内容按分级脱敏、受控 Artifact 和保留期治理，高基数 ID 不作无界 Metric 标签。

小白解释

商场里每位顾客有自己的钥匙和储物柜，广告传单不能命令保安开门；断电后系统根据登记簿恢复到安全步骤，监控能查责任但不能把顾客隐私公开贴在大厅屏幕上。

  • 合格线｜ 服务端授权、外部内容不可信、记忆/缓存隔离、状态持久化与脱敏 Trace；
  • 加分项｜ 策略版本、撤权事件、恢复演练、工具风险分级、预算配额和敏感 Artifact 审计；
  • 高频误区｜ 从 Prompt 读取 tenant，完整记录秘密，或只靠关键词过滤注入；
  • 下一问｜ 最后用受控面试教练说明工程难点、亮点、风险和真实证据边界。

第 7 题｜L7 项目复盘｜如何把 AI 面试教练 Agent 工程化并安全上线？ ​

核心考察点｜生产 Agent 的边界划分、验证证据、故障风险和诚实表达

面试官提问

请说明技术难点、可验证亮点、代表性风险和验收；当前能否讲成真实上线项目？

30 秒专业短答

这是源文档中的示例设计：题库与知识检索使用只读工具，用户回答和检索内容按来源隔离；评分采用版本化结构化 rubric，最大轮次、问题去重、预算和终止由运行时控制，长期弱点记忆按用户作用域、TTL 和删除治理。难点是概率评分、上下文恢复与隐私观测，亮点要通过非法动作/注入拒绝、固定答案重复评测、长会话、跨用户记忆、崩溃恢复和预算终止测试证明。代表性风险是评分漂移、重复追问、记忆污染和提示注入；仓库没有真实系统与事故数据，不能声称线上指标、用户规模或收益。

小白解释

这是一个有考场纪律的智能面试官设计：它能灵活追问，但题库只读、评分表固定、考试时间受控、每位考生的错题本隔离；还要演练恶意答案、断电恢复和无限追问。没有真实运营证据，就只能说设计与测试方法。

  • 合格线｜ 只读工具、结构化评分、运行时终止、记忆隔离、注入与恢复测试；
  • 加分项｜ 将每类故障转化为状态不变量、回归样本、告警和 Runbook；
  • 高频误区｜ 把设计说成上线经历，或用模型自评代替验收证据；
  • 下一问｜ 本组题结束；后续可进入 AI 系统设计中的容量、降级、数据和发布治理。

4. 自测与评分 ​

  • [ ] 为只读、可逆写入和不可逆写入设计三级工具策略；
  • [ ] 画出 PENDING/RUNNING/SUBMISSION_UNKNOWN/SUCCEEDED/FAILED 的合法迁移；
  • [ ] 注入外部成功但响应丢失、重复/乱序 Webhook 和批准后参数替换；
  • [ ] 设计跨用户记忆、撤权、提示注入和敏感 Trace 回归；
  • [ ] 按准确性、原理深度、工程意识、项目表达、沟通结构各 0～5 分评分；
  • [ ] 第 7 题不得虚构真实事故、exactly-once、SLO 或业务收益。

5. 事实边界与参考资料 ​

  • 单一事实源：Agent 工程化与安全；
  • 源文档依据包括 OpenAI Agents SDK Guardrails/Tracing/Running Agents、OWASP LLM Top 10、OpenTelemetry 与 Temporal 官方资料；
  • 认证、授权、幂等协议、补偿策略、SLO、重试预算和数据保留必须根据目标系统及外部服务能力验证；

当前无法确认｜ 示例面试教练的实现、第三方幂等保证、真实事故、质量、延迟、成本、用户规模和业务效果。

6. 总结 ​

一句话记忆： 生产 Agent 要默认模型、网络和外部系统都会犯错，再由服务端权限、显式状态、对账和审计限制损失。

  • Guardrail 是辅助检查，可信服务端授权才是最终安全边界；
  • 重试、幂等、对账、补偿和检查点解决不同问题；
  • 超时不代表未执行，副作用结果未知时应先冻结重提并对账；
  • 没有外部协议与故障验证，不能宣称跨系统 exactly-once；
  • 所有项目亮点和生产事故都要由 Trace、测试与运行证据支持。