Agent 项目的面试很少停留在概念层，几乎都是顺着你的项目往下挖：为什么这么设计、线上出过什么问题、怎么定位和修复。这篇指南拆解面试官的三类考察点，给出把项目讲出深度的三个抓手，并预演「为什么用 Agent 不用 Workflow」「效果如何评估」「成本怎么控」等高频追问。

面试官到底在考察什么

Agent 项目没有 CRUD 那样成熟的评价标准，面试官只能靠追问核实三件事：

  1. 工程落地能力。项目是不是真的做过、能不能上生产。真做过的人讲得出约束、数据规模和踩过的坑；只跑过 Demo 的人只能复述架构图，追问到第三层（统计口径、基线版本、上线后的维护方式）立刻露馅。
  2. 问题排查能力。模型输出不可靠、工具会失败、状态会不一致——面试官想知道你面对一个「看起来答错了」的现象，能不能按数据、检索、上下文、模型、工具、编排逐层定位，而不是一句「优化了 Prompt」。
  3. 评估意识。效果好不好，凭什么？「准确率提升 30%」如果没有评测集、样本量和基线，信息量为零。

「项目效果很好」「架构可扩展」这类回答为什么无效？因为它们是结论而非论证。有区分度的回答只有一种结构：什么约束下做了什么选择，解决了什么、引入了什么代价，用什么证据确认它有效。

把项目讲出深度的三个抓手

场景选择：证明非 Agent 不可

面试官的第一个质疑往往是：「这个需求用普通接口或固定工作流解决不了吗？」你需要讲清任务中哪一段路径无法被有限规则穷举——用户输入开放、下一步动作依赖中间状态、候选工具组合随上下文变化——这才是 Agent 的立足点。反过来，鉴权、确认、写入、审计这些可以提前确定的环节，本来就应该留在确定性 Workflow 里。一个成熟的回答是：用 Workflow 固定安全边界，只在路径不确定的局部嵌入 Agent Loop。自然语言入口本身不构成必须用 Agent 的理由。

架构权衡：交代约束与代价

讲架构不要按「Spring AI、Redis、Milvus……」报技术栈，而是带面试官走一次完整请求：接入层（鉴权、租户、限流）、编排层（任务状态与停止条件）、模型层（路由与结构化输出）、上下文层（RAG 证据、会话历史、Memory）、工具层（参数校验、授权、幂等）、状态层（任务进度与业务产物）、治理层（Trace、评测、审计）。每层都要说清「什么不能交给模型做」——权限、事务、幂等、预算必须由代码兜底。

每个关键选型都要能回答：当时的约束、比较过的候选方案、为什么当前方案更合适、牺牲了什么、用什么数据验证、约束变化到什么程度会换。比如单 Agent 拆成 Multi-Agent，要交代触发条件（工具误选率、上下文隔离、团队维护边界）与代价（路由延迟、调试与上下文传递成本）。

失败与迭代：Badcase 复盘

Badcase 是最能区分真假经历的部分。一个合格的复盘是：保存现场（输入、模型与 Prompt 版本、检索结果、工具请求响应）→ 描述现象与影响面 → 分层假设 → 控制变量逐项排除 → 确认可稳定复现的根因 → 说明修复放在哪一层 → 把原始 Case 和相邻边界 Case 加入回归集。

准备两个不同根因的 Badcase 效果最好：一个效果问题（如相似工具误选，根因在工具描述与前置条件不清，修复是重写契约并缩小暴露的工具集），一个工程问题（如写操作超时后盲重试产生重复工单，根因是把超时误判为失败且缺幂等约束，修复是稳定 actionId + 状态查询 + 对账）。每个 Badcase 都要落到「指标怎么变」：误选率从多少降到多少，重复副作用是否归零。

讲述框架：30 秒与 3 分钟

30 秒版本只回答四件事：项目是什么、为什么需要 Agent、你负责哪块、最难的问题是什么。不要讲细节，而是留好钩子——为什么混合架构、写操作为什么不能盲目重试、评测怎么做——让深挖发生在你的主场。

3 分钟版本按五步走：业务问题与成功标准 → 一次请求的完整链路 → 两个关键技术选择 → 一个最有代表性的 Badcase → 结果与职责边界。职责边界一句话拆开：团队完成了什么、你负责哪段、哪些决策是你做的，这比「我负责整个项目」可信得多。

高频追问预演

为什么用 Agent，而不是 Workflow？

先承认 Workflow 能读中间状态、走条件分支，甚至可以把 Agent 嵌进某个节点。划界标准是：下一步由预定义代码控制，还是由模型在运行时选择动作与路径。候选路径有限且规则稳定，「意图分类 + 表单补齐 + 固定规则」就够用；路径难以穷举且评测证明模型决策有收益，才交给 Agent。回答时最好给出自己项目里两者的具体分工。

效果如何评估？

分四层答：任务结果（完成率、最终业务状态正确率）、执行过程（工具选择与参数正确率、多余调用率）、成本（端到端 P50/P95、Token、单任务成本）、失控兜底（转人工率、重复副作用数）。然后交代评测集来源、判定方式（代码规则 / LLM-as-Judge / 人工）、运行次数与基线版本。开放任务有多条正确路径，评测应校验最终业务状态和安全红线，而非要求执行顺序与标准路径完全一致。未上线项目就展示离线评测集与错误分布，别包装成生产数据。

成本怎么控制？

从三个层面回答：模型侧——按节点难度分级用模型（分类、抽取用小模型，规划、综合用强模型），替换时跑同一套评测集；链路侧——限制最大步数、总截止时间与 Token 预算，检测「连续相同动作」按无进展终止，缓存命中高的结果；架构侧——网关做配额、路由与成本归因，慢工具放独立并发舱壁。给出优化前后的单任务成本对比最有说服力。

其他必备追问

  • 超时怎么处理：超时不等于失败，写操作盲重试会产生重复副作用；幂等键 + 状态查询 + 对账是正解，各层重试共享总 Deadline 与重试预算。
  • 死循环怎么防：最大步数、总预算、无进展检测由执行器强制，Prompt 里写「最多调用十次」只是行为提示。
  • 安全怎么兜：工具按风险分级（只读 / 可逆写 / 高危写 / 禁止自动执行），高危动作人工确认；检索结果与 MCP Server 返回内容都是不可信输入，不能改变服务端权限判断。

面试前清单

  • 一页能讲完的架构图，覆盖入口到最终产物；
  • 30 秒、3 分钟、10 分钟三个版本的项目介绍；
  • 两个有备选方案的选型决策，两个不同根因的 Badcase；
  • 评测集构成、指标定义与统计口径；
  • 当前模型、框架版本，以及「框架提供了什么、我自己补了什么」的边界；
  • 项目当前明确的局限与下一步计划。

小结

  1. 面试官考察的是工程落地、问题排查与评估意识，回答要落「约束—选择—代价—证据」四要素。
  2. 深度来自三处：证明场景非 Agent 不可、讲清每层架构的边界与权衡、Badcase 有可复现的根因与指标变化。
  3. 高频追问（Agent vs Workflow、评估、成本、超时、死循环、安全）提前写成逐字稿，并在介绍里主动留钩子。
  4. 数字必须真实可查，离线实验就说是离线实验，编造口径最容易穿帮。