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


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

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

<!-- more -->

## 为什么需要多个 Agent

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

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

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

**好的回答会提到：**

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

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

## Agent 之间怎么通信

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

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

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

**好的回答会提到：**

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

可以参考我们之前讲多 Agent 协作时聊到的消息设计思路 {{< ref "2026-05-19-multi-agent-collaboration-engineering.md" >}}，里面提到了几个实际踩过的坑。

## 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 定义工具调用的预算限制，详见 {{< ref "2025-11-05-prompt-engineering-context-management-complete-guide.md" >}} 里关于预算管理的讨论。

## 状态和记忆怎么管

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

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

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

**好的回答会提到：**

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

{{< image src="/pictures/posts/agent-interview-assessment.svg" alt="Agent 面试评估矩阵" caption="五个核心面试维度，好的回答和背概念的回答对比" width="800px" >}}

## 怎么判断回答质量

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

**真干过的人会说的话：**
- "当时我们的场景是…"
- "一开始没考虑这个，出了一个问题之后才加的"
- 能说出版本号、具体的配置值、踩过的具体 bug

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

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

---

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