Agent 面试题：哪些问题能筛出真干活的人

面了十几个 Agent 方向的候选人之后，一个感觉越来越强烈：能聊架构的很多，能说清楚"挂了怎么办"的很少。

下面几个是实际用过的面试问题，以及什么样的回答说明对方真干过。

为什么需要多个 Agent

开场问题，用来区分"看过文章"和"动手搭过"。

不好的回答： “Multi-Agent 能并行处理，提升系统吞吐和鲁棒性。”

这句话每个字都对，但你追问"拆成两个 Agent 之后吞吐真的翻倍了吗"就卡住了。实际情况是：Agent 之间通信有开销，协调有复杂度，拆了之后总吞吐可能反而下降。加 Agent 不是加 CPU 核。

好的回答会提到：

• 拆的依据是领域边界，不是性能。支付 Agent、库存 Agent、用户行为 Agent — 各自有自己的数据源和失败边界
• 单个 Agent 能解决的问题，不要用两个。拆了之后一致性成本可能大于收益
• 会主动说"我们这个场景用一个 Agent 就够了"的，比上来就画三五 Agent 架构图的靠谱

这个问题能看出对方有没有拆和不拆的判断力。

Agent 之间怎么通信

第二个问题，看对方做过实际集成。

不好的回答： “Agent 通过 API 互相调用，用 gRPC 或者 REST。”

听起来挺技术，但 Agent 通信的关键在消息设计。

好的回答会提到：

• 异步消息队列是默认选择。每个 Agent 有自己的输入管道，消息带超时和重试。gRPC 直连在 Agent 通信里很少见
• 消息结构怎么设计比用什么传输重要得多：消息里带什么字段、失败时消息怎么处理、时序怎么保证
• “某个 Agent 收到了一条跟自己无关的消息” 的处理逻辑比"怎么发消息"更说明问题

可以参考我们之前讲多 Agent 协作时聊到的消息设计思路 https://byronfinn.github.io/2026-05-19-multi-agent-collaboration-engineering/，里面提到了几个实际踩过的坑。

Agent 挂了怎么办

这个问题最有区分度。因为只有真上过生产的人才会认真想这个。

不好的回答： “加 try-catch 和 fallback。”

然后追问 fallback 是什么，就说不清楚了。

好的回答会主动区分两种故障：

1. 预期故障：API 超时、模型返回格式不对、工具调用失败。这些可以重试（但有次数限制），或者走预设的降级路径
2. 系统性故障：Agent 内部状态损坏、消息丢失、死锁。这些不能简单重试，需要整个链路回滚或人工介入

好的回答还会有几个具体的数字：

• “API 超时重试 3 次，间隔指数退避”
• “连续失败 5 次以上的消息进死信队列，人工处理”
• “每次状态变更都写日志，出问题能回溯”

还会提到一个关键点：Agent 不能无限重试。没有约束边界的 Agent 容易在错误路径上跑很远都没人察觉。

Tool Calling 怎么设计

Function calling 是模型自带能力，但生产环境里用的不是模型返回的那层。

不好的回答： “定义好 tools 的 JSON schema 就行，模型自己会选。”

模型确实会选，但生产环境需要的远不止这个。

好的回答会提到：

• 每个工具需要有完整的 schema 描述——参数名、类型、枚举值、必填/可选，模型才能准确理解
• 参数校验必须在工具侧再做一次，不能信模型的输出。模型经常幻觉出不在 schema 里的参数值
• 超时控制：模型选了工具不代表工具能跑完。每个工具调用必须有超时
• 结果过滤：工具返回的结果不能直接喂给模型。需要过一层 sanitization，去掉敏感信息、截断过长内容
• 工具选择的限制：不是所有工具对所有 Agent 可用。要基于角色或上下文限制可调用的工具集合

Agent 进行 tool calling 时，上下文窗口的管理是一个经常被低估的问题。每个工具调用的输入和输出都占用 token，不加控制的话几个工具调用就能把上下文撑满。我们的实践是给每个 Agent 定义工具调用的预算限制，详见 https://byronfinn.github.io/2025-11-05-prompt-engineering-context-management-complete-guide/ 里关于预算管理的讨论。

状态和记忆怎么管

最后一个问题，也是最容易被低估的。

不好的回答： “把 context 传给 Agent 就行，模型会自己记住上下文。”

模型确实会"记住"，但这个"记住"和实际工程里需要的状态管理不是一回事。

好的回答会提到：

• 状态外部化：Agent 的状态不能只存在模型的上下文里。每次关键操作后都应该持久化到 Redis 或数据库
• 每个 Agent 处理完就持久化一步，全部跑完再存可能在中间失败时丢进度
• 状态的颗粒度：存什么不存什么，需要设计。全量存浪费空间，只存对话记录损失信息
• 上下文窗口的预算管理：给定模型的上下文是有限的，状态多了要压缩、总结、或者分页

怎么判断回答质量

上面五个问题，每个都能看出候选人的实际经验深度。几个综合判断信号：

真干过的人会说的话：

• “当时我们的场景是…”
• “一开始没考虑这个，出了一个问题之后才加的”
• 能说出版本号、具体的配置值、踩过的具体 bug

背概念的人会说的话：

• 全是用"能/会/可以"开头的能力描述
• 追问细节就说"这个要看具体实现"
• 所有问题都能答个大概，但没有一个能深入 3 层追问

最后一个信号可能最有价值：候选人会不会主动说"这个我没想到过"或者"这个我们当时没处理好"。 真干过的人知道自己系统的边界在哪里，不会假装什么问题都解决了。

说到底，Agent 就是带有工具使用能力和自主决策逻辑的程序。面试考的是对方有没有把一个复杂系统跑稳的经验。能说出错误边界的人，比能画出完美架构图的人有用得多。