不会的 Agent 面试题怎么答：先拆问题，再声明假设

面试官问：“如果让你设计一个能自动处理退款的 Agent，你会怎么做？”

如果没做过退款系统，最危险的反应不是说“我没做过”，而是马上开始背框架：先接一个大模型，再加 RAG，再注册几个工具。这样说得很快，却没有回答业务目标、权限边界和失败后怎么办。

先给一个能复述的答案

不会的 Agent 题，先用四步把未知变成可讨论的范围：确认目标和成功口径，声明关键假设，拆出数据、工具、状态和安全边界，最后给出验证方案和取舍。回答不要求猜中面试官心里的唯一架构，而要让对方看到你如何在信息不全时做出可回滚的工程决策。

第一步：先确认“要解决什么”

同一个“退款 Agent”，可能是客服问答、退款资格判断、执行退款，或者只负责生成工单。先问三个问题：

1. 目标是谁的目标？ 是降低客服处理时长，还是提高自动退款率？
2. 什么叫成功？ 答案被采纳、工单创建成功，还是资金真的退回？
3. 哪些动作不能自动做？ 读订单、改状态和打款的风险完全不同。

如果面试时间不允许反问，就直接把假设说出来：

假设：系统面向已登录用户，只处理已支付订单；
目标：减少客服查订单和解释规则的时间；
成功：只读咨询要有依据，写操作必须经过资格校验和审批；
约束：不跨租户、不重复退款、失败结果必须可对账。

声明假设不是示弱，而是给后面的方案画边界。假设一旦改变，方案哪里要改也能说清楚。

第二步：把问题拆成四类对象

不要直接画“用户—Agent—数据库”三框图。至少把对象拆成：

模型只负责提出下一步意图，不能替系统拥有这些对象。比如“退款”不能只是模型输出一个 refund=true，而应该经过工具契约、权限检查和状态机。

第三步：选择最小可行架构

陌生题最容易答成“大而全”。我会先给一个只读版本，再沿风险逐步增加能力：

用户问题
  -> 意图分类：咨询 / 资格判断 / 执行请求
  -> 读取订单与规则（带租户、版本过滤）
  -> 生成带引用的解释
  -> 若涉及写操作：审批 -> 幂等执行 -> 对账回执

只有当题目明确需要复杂规划、多工具协作或长任务恢复，才加 planner、队列和多 Agent。先把最小闭环讲清楚，比一次画十几个组件更有说服力。

第四步：把“我会验证”说具体

“上线后观察效果”太空。可以给出一张最小验证表：

功能：退款资格判断在固定订单集上的准确率、拒答率
安全：越权订单、重复 refund_id、审批绕过
可靠：工具超时、未知结果、worker 重启后的恢复
体验：P95 响应、解释是否带规则版本
成本：每个成功处理任务的模型与工具成本

遇到追问，沿着证据而不是名词走

面试官说“那你为什么不用多 Agent”，可以回答：

目前目标是单一退款流程，单 Agent + 明确工具契约足够；
如果客服解释和财务执行需要不同权限，再拆成两个角色，
并用消息协议和交接状态隔离副作用。是否拆分由冲突率、延迟和审计成本验证。

这比说“多 Agent 更先进”更稳，也给出了何时改变方案的条件。

用“假设—边界—验证”三列保持回答稳定

题目条件变化时，不必把整套架构推倒。把回答写成三列：

面试官把“已支付订单”改成“跨境订单”时，只需要更新假设对应的资格校验、汇率和人工边界，其余状态、审计和验证框架仍然保留。能局部重算，说明你是在做工程推理，不是在背一张架构图。

安全边界要主动说出来

陌生题不确定业务细节时，安全边界反而是可以先固定的：不跨租户读取、不让模型直接写数据库、不在未知工具结果下重复副作用、不把未经验证的回答伪装成确定事实。先说这些不变量，再讨论模型和框架，回答会更稳。

如果题目要求“全自动”，也可以提出分级自动化：低风险只读自动，高风险动作先给建议和证据，审批通过后由幂等工具执行。自动化比例是实验结果，不是开场就应该承诺的数字。

答不出来时怎样诚实又不失分

可以用三句话：

1. “这个业务细节我没有做过，我先声明一个可讨论的假设。”
2. “在这个假设下，最小闭环是……，风险边界是……”
3. “我会用这组数据和故障演练验证；如果条件改成……，我会调整……。”

这比硬猜一个框架 API 更有价值，因为它把未知、推理和验证分开了。

架构图里一定要画失败出口

陌生题的正常路径通常很容易说，区分度在失败出口：

权限不通过 -> 拒绝并记录原因
规则版本冲突 -> 请求补充信息或转人工
工具超时 -> 只读查询可重试，写操作进入未知状态对账
模型无法给证据 -> 明确拒答，不编造结论

每个出口都要有用户看到的结果、系统留下的事件和下一步 owner。只画“用户—模型—数据库”三框图，会让面试官无法判断你是否考虑过真实运行。

给陌生题做一个最小证据包

回答陌生题时，可以把脑中的推理压缩成一页“证据包”，让面试官看到你不是凭感觉堆组件：

assumption: "知识库每天更新，工具可能超时"
decision: "artifact 引用 + 状态机 + 幂等写接口"
evidence: ["离线回放", "超时演练", "权限拒绝集"]
stop_if: "重复副作用 > 0 或高风险拒答率下降"

这份证据包的好处是条件一变只改一行：如果题目改成“允许写入”，先修改权限假设，再重新检查审批、幂等和对账，不需要把整张架构图推倒重来。

一页证据包让面试官能沿着“为什么这样做、怎么证明、失败怎么办”继续追问。

面试现场的反事实练习

真正有区分度的回答，不是第一次把方案讲完整，而是能在约束变化时快速重算。可以主动给自己三个反事实：请求量提高十倍，哪些预算和缓存要改；工具从读变成写，哪些审批和补偿要加；知识库存在互相冲突的版本，答案何时澄清或拒答。

每次只改一个条件，并明确受影响的组件、指标和验证集。这样回答会从“我知道很多名词”变成“我知道系统的杠杆在哪里”。

把自动化拆成风险等级

可以用三级方式回答“能不能全自动”：

这样既没有简单拒绝需求，也没有承诺模型可以直接控制资金。自动化等级可以通过误判率、人工节省、重复执行和安全事件逐步调整。

用一张回答账本记录现场假设

陌生题最容易出现“说着说着把假设当成事实”。可以在草稿或脑中维护一张回答账本，把每个判断绑定到假设、证据和下一步验证：

回答时先说“基于这个假设，我会……”，再说验证动作。若面试官改变条件，只重算受影响的行，不必推倒整套架构。账本也能防止为了显得自信而编造不存在的指标。

四个常见坑

一上来就报框架名

框架不能替你回答租户、权限和失败恢复。先说问题和边界，最后再说框架如何承载。

假设藏在语气里

没有声明假设，面试官一改条件，你的整套方案就像被推倒。把假设写出来，才能局部调整。

只讲正常路径

Agent 题的区分度往往在超时、重复执行、数据过期和人工接管。至少说一个失败路径和恢复动作。

把“可以验证”当成结论

验证必须有数据集、指标、基线和停止条件。否则只是把未知推迟到上线。

L1 / L2 / L3 分层追问

L1： 遇到没做过的 Agent 题怎么办？

先确认目标和成功口径，再声明假设，拆数据、工具、状态和风险，给最小架构与验证方案。

L2： 面试官不同意你的假设怎么办？

先承认假设变化，再指出受影响的模块、接口和指标，保留不变的边界，重新给出最小调整方案。

L3： 怎样证明你不是在背模板？

把每个组件绑定到具体约束和证据：为什么需要它、不用会怎样、用什么实验判断有效、失败后如何回滚。

L1： 面试题信息很少时先说什么？

先说目标、用户、成功口径和关键假设，再给最小闭环；不要用组件名填补信息缺口。

L1： 为什么要把假设写出来？

假设决定数据、权限和自动化边界；条件变化时可以局部重算，不会让整套方案失去依据。

L2： 题目要求全自动，你会拒绝吗？

不会直接拒绝，但会按风险分级自动化：低风险只读自动，高风险经过审批、幂等执行和对账，并用指标验证自动化比例是否可接受。

L2： 设计题里模型应该负责什么？

模型负责理解、规划和提出工具意图；权限、状态、写操作、版本和审计交给确定性服务，不让自然语言直接成为副作用。

L2： 面试官突然改变约束怎么办？

先指出受影响的假设和模块，再保留不变的安全与状态边界，给出最小调整和新增验证，不要从头背另一套架构。

L3： 如何处理自己完全不了解的行业？

明确未知业务规则，先抽象出身份、数据、工具、状态、证据和风险，再把行业差异放进可替换的策略接口，避免假装知道具体政策。

L3： 什么时候应该主动提出不确定性？

当数据、权限、规则版本或工具副作用会改变方案时就要主动说明，并给出获取信息或验证假设的路径；不确定性本身不是失分点，隐藏它才是。

L5： 面试官临时把“只读查询”改成“会扣款的写操作”，你会怎么改答案？

保留需求、数据和观察层，把执行层切成审批、幂等、状态查询和补偿；先用 dry-run 验证参数与权限，未知结果不重试写入，无法证明安全时明确转人工。变化的是风险边界，不是把整个回答换成另一个框架。

L1： 为什么设计题一定要讲失败出口？

正常路径无法说明系统如何面对权限拒绝、版本冲突、超时和未知结果；失败出口才体现边界和可恢复性。

L2： 读操作和写操作的重试有何不同？

读操作通常可以在幂等和权限不变时重试；写操作遇到未知结果不能盲目重试，要先查状态、对账或转人工。

L2： 题目没有给指标，你会怎么补？

先提出与目标对应的最小指标：任务成功、拒答安全、P95、成本、人工接管和重复副作用，再说明需要哪些样本与基线。

L3： 面试官要求你立刻选某个框架怎么办？

先说明框架只承载编排和适配，关键契约、权限、状态和评测不依赖它；在约束明确后再选择能满足版本、观测和迁移要求的实现。

L3： 如何判断该拆成多 Agent？

先看权限、责任边界、交接状态和并行收益是否真实存在；若单 Agent 加清晰工具契约已能满足目标，就不为概念增加通信和仲裁成本。

陌生题先发一张假设清单，再开始画架构

题目越模糊，越不能用熟悉的组件名填空。先把未知条件列成可验证的假设，并给每条假设标风险、证据来源和改变方案的触发器：

question: "为企业设计一个能处理合同的 Agent"
assumptions:
  - id: A1
    statement: "合同内容按租户隔离，允许引用页码"
    risk: high
    evidence_needed: [tenant_policy, sample_contract]
    if_false: "切换到人工审批和脱敏检索"
  - id: A2
    statement: "写回只生成草稿，不直接签署"
    risk: critical
    evidence_needed: [approval_flow, audit_policy]
    if_false: "禁用自动写入，保留 dry-run"
minimum_loop: "解析 → 检索 → 引用 → 审批 → 草稿"

面试中可以先说“以下是我的假设”，再给最小闭环；当面试官改一条约束时，只重算受影响的节点。这个动作比背一张通用架构图更能证明你理解了数据、权限、状态和证据之间的关系。

把面试现场写成一张可追问的决策记录

陌生题的回答不应该只留下“我会选某某架构”。更有用的是记录面试官改了哪条约束、哪条假设受到影响、你增加了什么验证。这样复盘时能分辨是知识缺口，还是现场没有把边界说清：

decision_record: dr_20260820_11
question: "企业合同 Agent 是否允许自动写回？"
initial_assumptions: [tenant_isolation, draft_only]
interviewer_change: "要求自动更新合同状态"
affected:
  - "write_path"
  - "approval_boundary"
kept:
  - "retrieval_citation"
  - "audit_event"
adjustment: "增加幂等键、审批节点和状态对账，先 dry-run"
validation:
  dataset: "contract-fixtures-v2"
  stop_when: "unknown_write_result > 0"
follow_up: "补偿策略与人工接管 SLA"

面试后只复盘三件事：哪条假设没有及时说出、哪条边界被追问打穿、哪个验证可以在项目里补出来。记录越具体，下次越不需要依赖模板记忆。

假设写完还要做一次“最小反例测试”

假设不是免责声明，而是可以被拿来压测设计的变量。写完方案后，我会主动改动一个最关键的条件，做一次最小反例测试：例如把单租户换成多租户、把同步工具换成 30 秒延迟，或把“可读”权限改成“可读但不可导出”。如果系统没有局部调整路径，就说明原方案的边界还没有说清楚。

assumption_counterexample: act_20260820_35
question: enterprise-knowledge-agent
baseline_assumptions:
  tenants: 1
  tool_latency_ms: 800
  export_permission: false
counterexample:
  tenants: 20
  tool_latency_ms: 30000
  export_permission: false
affected_modules: [router, cache_scope, deadline_policy, audit_log]
adjusted_answer: tenant_scoped_cache_and_async_resume
confidence: medium

回答时我会先说清“改变了什么”，再指出受影响模块和保持不变的安全边界。反例只需要覆盖一条关键假设，不必把整张架构图推倒重画；重点是证明路由、状态、权限和证据链可以局部演进，并且有数据集或演练能验证调整后的结论。

L5：为什么假设必须配一个反例，而不只是写在开头？

没有反例的假设只是背景描述，无法说明设计对条件变化的敏感点。用一个最小变化去跑模块影响和验证路径，才能把“我这样假设”变成“我知道改动会影响哪里”。

L5：为什么要记录“保留不变的边界”？

因为优秀的调整不是推倒重来。面试官改一个约束时，如果你能说清哪些模块要变、哪些安全和证据边界仍然成立，就能证明方案是可演进的，而不是背了一张静态架构图。

L5：为什么先讲假设，反而显得更专业？

因为设计题的关键不是猜中面试官心里的唯一答案，而是让方案在条件变化时仍可局部修正。把假设、边界和验证方法说出来，才能区分“我暂时不知道”和“系统没有安全出口”；隐藏不确定性，才会让整套方案显得脆弱。

时间不够时，先锁住不可逆的假设

陌生题的现场时间通常不够把所有组件都讲完。可以先把假设按风险排序：会造成数据丢失、越权或成本失控的假设优先验证；只影响吞吐或体验的假设可以暂时采用保守默认值。回答结构因此不是“想到什么说什么”，而是先给最小方案，再说明哪一个实验最能改变结论。

time_box:
  remaining_minutes: 8
  assumptions:
    - {name: payment_is_idempotent, risk: irreversible, verify_first: true}
    - {name: traffic_has_daily_peak, risk: capacity, verify_first: true}
    - {name: dashboard_can_be_eventual, risk: ux, verify_first: false}
  smallest_design: "queue + idempotency store + worker + audit log"
  next_experiment: "duplicate request under worker timeout"
  stop_rule: "若幂等不成立，先不扩展多活架构"

这套方法能把“我不确定”说得很专业：不是逃避细节，而是说明在当前时间预算下哪些细节值得先验证、哪些可以延后。面试官继续追问时，沿着假设账本逐条打开即可，回答不会因为临时换了一个名词而失去主线。

L5：如果面试官要求立刻给出具体数字呢？

先给量级和来源，不要假装精确。可以说“我会先按峰值 QPS、单请求 token 和尾延迟预算估算，具体数值需要压测确认”，然后把估算公式写出来。诚实的边界和可执行的验证计划，通常比一个没有依据的数字更有说服力。

60 秒面试回答

遇到没做过的 Agent 题，我不会先报框架，而是先确认目标和成功口径，再声明关键假设。接着把系统拆成数据、工具、状态和证据四类对象，先给一个最小可行闭环：模型提出意图，工具做校验和执行，状态机负责恢复，写操作经过权限和审批。最后用功能、安全、可靠性、体验和成本五类指标验证。这样即使题目条件变化，也能说明哪条假设变了、哪些边界仍然不变。

交付前检查清单

• 说清目标、用户和成功口径
• 把关键假设显式写出来
• 区分数据、工具、状态和证据
• 先讲最小可行架构，再按风险扩展
• 至少覆盖一个失败与恢复路径
• 验证方案包含数据集、指标和停止条件

相关阅读

• 从零设计企业知识库 Agent，第一张图该画什么？
• Code Agent 怎样把一句需求稳稳做成补丁？
• 项目被追问‘你做的和框架有什么区别’，怎样讲出自己的贡献
• 技术方案有争议怎么办？从不同意见到可验证实验

资料来源

• AgentAlpha《Agent 岗面试宝典 v3》：系统设计题章节
• ARIS in AI Offer：系统设计题的假设、分层与验证结构