夜雨聆风上周一位读者私信我：「面试 Agent 岗，技术题全答出来了，但最后还是挂了。面试官说我的回答『缺少系统性思考』。」我问他：「面试官追问你 Memory 系统的成本怎么控，你怎么答的？」他沉默了一会儿：「我说……用向量数据库存就行了？」
P6 和 P7 的差距，不在于知识量，在于有没有「生产思维」。
同一道题，P6 给你一个可以跑的方案，P7 给你方案 + 成本模型 + 降级策略 + 「为什么不是另一个方案」。面试官追问到第三层，P6 开始模糊，P7 还能撑到第五层。
这篇是《AI Agent 面试通关18问》的续集。上一篇给了你「怎么答」，这一篇给你「P6 怎么答 vs P7 怎么答，差距在哪里」——这是市面上几乎没有人做过的角度。
6 道题，每道题都有 P6 和 P7 的完整答案对比，以及面试官的 5 层追问链。读完你会知道自己现在在哪个层次，以及差距具体在哪里。
一、先搞清楚：P6 和 P7 的本质区别是什么？
很多人以为 P7 只是「知道更多」。错了。
P7 和 P6 的差距，是思维框架的差距，不是知识量的差距。
| 任务范围 | ||
| 问题定义 | ||
| 技术决策 | ||
| 不确定性 | ||
| 面试表现 |
在 AI Agent 面试里，这个差距体现得非常具体：
• P6 说「我们用 LangGraph，因为它支持状态管理」 • P7 说「LangGraph vs 自研，在 N 个 Agent、M 并发、K 成本约束下，LangGraph 的 overhead 是否值得——我的判断是……」
P6 在给定边界内设计，P7 主动质疑边界，重新定义问题。
下面 6 道题，你可以对照着测一下自己现在在哪个层次。
二、6 道区分题
💡 这部分建议收藏，面试前一天打开复习，30 分钟过完 6 道核心题的 P7 答案要点。
题目 1：Agent 的 Memory 系统怎么设计？
考察模块：Memory 系统P6 vs P7 核心差距：P6 给方案，P7 给方案 + 数字 + 成本模型 + 降级策略
P6 的典型答案
短期记忆用 ConversationBufferWindowMemory，保留最近 20 轮。长期记忆用向量数据库（Pinecone/Qdrant），存用户偏好和历史摘要。跨会话用 Redis 做持久化。
这个答案没有错，但面试官会继续追：
• 「为什么是 20 轮，不是 10 轮或 50 轮？」 • 「100 万用户，向量存储成本怎么控？」 • 「向量数据库挂了怎么办？」
P6 在第二层追问时开始模糊。
P7 的典型答案
P7 不会直接给方案，而是先问三个约束：
Memory 设计要先问三个问题：用户规模（影响存储选型和冷热分离策略）、记忆的时效性（偏好类记忆 vs 事实类记忆的 TTL 不同）、检索延迟要求（实时对话 vs 异步任务的容忍度不同）。
然后才给方案，而且每个决策都有数字支撑：
在 100 万用户、每人每天 10 轮的场景下：
短期记忆：滑动窗口 20 轮。为什么是 20 轮？经验值：超过 20 轮后 LLM 对早期内容的注意力衰减，但 20 轮 × 平均 200 token = 4000 token，在 128K 窗口里占比 3%，可接受。
长期记忆：向量存储 + 实体记忆双轨。向量存储用于用户偏好、历史摘要（语义检索）；实体记忆用于用户基本信息、明确偏好（精确查询，用 KV 存储，不走向量检索）。
检索策略：不是每轮都检索，而是「意图触发检索」——检测到用户在问个性化问题时才触发向量检索，节省 60-70% 的检索成本。
降级策略：向量数据库挂了，降级到只用短期记忆 + 实体记忆，不能因为长期记忆不可用就让整个 Agent 挂掉。
P7 答案的特征：先问约束，再给方案；每个决策都有数字（20 轮的理由、4000 token 的计算、60-70% 的成本节省）；有降级策略（生产思维）。
面试官的 5 层追问链
第 1 层：Memory 系统怎么设计？（P6/P7 都能答）第 2 层：为什么是 20 轮，不是 10 轮？（P6 开始模糊，P7 给出 token 计算）第 3 层：100 万用户，向量存储成本怎么控？（P6 卡壳，P7 给出冷热分离方案）第 4 层：向量数据库挂了怎么办？（P7 给出降级策略）第 5 层：用户 A 的记忆里有矛盾信息（上次说喜欢简洁，这次说要详细），怎么处理？ （P7 给出记忆冲突解决策略：时间戳优先 + 显式确认机制）题目 2：Function Calling 出错了怎么处理？
考察模块：工具调用可靠性P6 vs P7 核心差距：P6 处理单次错误，P7 设计错误处理体系
P6 的典型答案
try-except 捕获异常，重试 3 次，超时设 30 秒。如果工具返回错误，告诉 LLM 工具调用失败，让它换个方式。
P7 的典型答案
P7 的第一句话就不一样：
工具调用错误要分类处理，不是所有错误都该重试。
然后给出分类框架：
可重试错误（网络超时、限流）：指数退避重试，最多 3 次。
不可重试错误（参数错误、权限不足）：立即失败，告诉 LLM 原因，让它换策略，不要浪费重试次数。
部分成功（工具返回了结果但质量低）：让 LLM 评估是否够用，不够再换策略。
然后是 P6 完全没想到的部分：
更重要的是：工具调用失败的信息怎么传给 LLM？
错误信息要结构化：
{"error_type": "timeout", "tool": "search", "retry_count": 3}。不要把原始 stack trace 传给 LLM——token 浪费，而且可能泄露系统信息。生产中还要考虑幂等性：发邮件的工具重试 3 次，会发 3 封邮件。写数据库的工具重试，会写 3 条记录。所有有副作用的工具，必须在调用前检查幂等性。
面试官的 5 层追问链
第 1 层：工具调用出错怎么处理？（P6/P7 都能答）第 2 层：重试 3 次，如果是发邮件的工具，会发 3 封邮件吗？（P6 卡壳，P7 给出幂等性方案）第 3 层：错误信息怎么传给 LLM？（P7 给出结构化错误信息设计）第 4 层：某个工具的失败率突然从 2% 升到 20%，你怎么发现？（P7 给出监控告警方案）第 5 层：工具调用失败，但 LLM 还是生成了一个「看起来正确」的答案，怎么办？ （P7 给出幻觉工具调用检测方案：对比 LLM 声称调用的工具 vs 实际调用记录）题目 3：设计一个多 Agent 系统，任务分配怎么做？
考察模块：Multi-Agent 编排P6 vs P7 核心差距：P6 给分配方案，P7 给分配策略 + 失败处理 + 成本模型
P6 的典型答案
用 Supervisor + Workers 模式。Supervisor 接收任务，根据任务类型路由给对应的 Worker Agent。比如客服系统：订单查询 → 订单 Agent，退款 → 退款 Agent。
P7 的典型答案
P7 先问任务的结构：
任务分配要先问：任务是否可以并行？任务之间有没有依赖关系？
然后分情况讨论：
如果任务可以并行（比如同时查订单状态和物流信息）：用
asyncio.gather并行调用多个 Agent，延迟从 T1+T2 降到 max(T1,T2)。但要注意：并行调用的 Token 消耗是串行的 N 倍，要评估是否值得。如果任务有依赖（比如先查订单，再根据订单状态决定是否退款）：用 DAG（有向无环图）描述依赖关系，LangGraph 的 StateGraph 天然支持这种模式。
然后是 Supervisor 路由策略的 trade-off：
基于规则的路由（快，但维护成本高）vs 基于 LLM 的路由（灵活，但有额外 Token 消耗）。我的判断是：初期用规则路由，复杂度上来之后再引入 LLM 路由，不要一开始就过度设计。
最后是生产问题：
子 Agent 挂了，Supervisor 怎么知道？心跳检测 + 超时机制。两个 Agent 给出矛盾结论，怎么仲裁？置信度 + 人工审核阈值。整个 Multi-Agent 系统的 Token 消耗是单 Agent 的 N 倍，成本怎么控？不是所有任务都需要 Multi-Agent，先用单 Agent，复杂任务才升级。
面试官的 5 层追问链
第 1 层：多 Agent 任务分配怎么做？（P6/P7 都能答）第 2 层：两个 Agent 并行调用，Token 消耗是多少？（P6 模糊，P7 给出计算）第 3 层：子 Agent 挂了，Supervisor 怎么知道？（P7 给出心跳检测方案）第 4 层：两个 Agent 给出矛盾结论，怎么仲裁？（P7 给出置信度 + 人工审核方案）第 5 层：这个系统每天处理 10 万个任务，Token 成本是多少？怎么优化？ （P7 给出成本模型：任务数 × 平均 Token × 单价，然后给出多模型路由优化方案）题目 4：Agent 的 Prompt 怎么管理版本？
考察模块：工程实践P6 vs P7 核心差距：P6 用 Git 管理，P7 设计 Prompt 版本管理体系
P6 的典型答案
把 Prompt 存在代码仓库里，用 Git 做版本管理。改 Prompt 之前先测试，确认效果再合并。
P7 的典型答案
P7 先指出 P6 方案的本质问题：
Prompt 版本管理和代码版本管理有本质区别：代码改了，行为是确定性变化；Prompt 改了一个词，行为可能完全不同，而且这个变化是概率性的，不是确定性的。所以用 Git 管 Prompt 是不够的。
然后给出完整方案：
Prompt 注册中心（不是 Git）：每个 Prompt 有唯一 ID + 版本号，支持 A/B 测试（10% 流量用新 Prompt，90% 用旧 Prompt），支持快速回滚（不需要重新部署代码）。
Prompt 变更的评估流程：变更前跑回归测试集（100+ 黄金样本），变更后监控关键指标（成功率/幻觉率/用户满意度）至少 24 小时，回滚触发条件：成功率下降 > 5% 或幻觉率上升 > 2%。
Prompt 和代码的解耦：Prompt 变更不应该触发代码部署，运营人员可以在不改代码的情况下调整 Prompt。
然后是一个真实踩坑：
我们踩过一个坑：Prompt 里加了一句「请用中文回答」，导致工具调用的 JSON 输出也变成了中文，解析失败。教训：Prompt 变更要有专门的工具调用回归测试，不能只测对话质量。
面试官的 5 层追问链
第 1 层：Prompt 怎么做版本管理？（P6/P7 都能答）第 2 层：Prompt 改了一个词，怎么知道效果变好了还是变差了？（P6 模糊，P7 给出评估流程）第 3 层：线上 Prompt 出问题了，怎么快速回滚？（P7 给出注册中心 + 热更新方案）第 4 层：A/B 测试两个 Prompt，怎么判断哪个更好？（P7 给出统计显著性方案）第 5 层：运营人员想改 Prompt，但不会写代码，怎么办？（P7 给出 Prompt 管理平台方案）题目 5：Agent 上线后准确率从 85% 掉到 60%，怎么排查？
考察模块：可观测性与调试P6 vs P7 核心差距：P6 给排查步骤，P7 给排查框架 + 预防机制
P6 的典型答案
先看日志，找出失败的请求。看是 LLM 的问题还是工具调用的问题。如果是 LLM 的问题，检查 Prompt 有没有变化。如果是工具的问题，检查工具的返回值。
这个答案的问题是：靠直觉，没有系统性。
P7 的典型答案
P7 给出一个四步排查框架：
第一步：定位掉点的时间点
是突然掉（某个时间点之后全掉）还是渐进掉（慢慢变差）？
突然掉 → 找那个时间点发生了什么（代码部署/Prompt 变更/模型升级/数据变化）。
渐进掉 → 通常是数据分布漂移（用户行为变了，但 Prompt 没跟上）。
第二步：定位掉点的类型
按失败类型分桶：工具调用失败？LLM 幻觉？意图识别错误？找出占比最大的失败类型，优先处理。
第三步：定位根因
工具调用失败率升高 → 检查工具的 API 是否有变化。LLM 幻觉率升高 → 检查是否有新的 Query 类型（分布外样本）。意图识别错误 → 检查是否有新的用户表达方式。
第四步：修复 + 预防
修复当前问题。更重要的是：建立监控告警，下次掉点能在 5 分钟内发现，而不是用户投诉了才知道。
然后给出生产中的关键指标：
面试官的 5 层追问链
第 1 层：准确率掉了怎么排查？（P6/P7 都能答）第 2 层：怎么判断是突然掉还是渐进掉？（P7 给出时间序列分析方案）第 3 层：找到根因了，怎么确认修复有效？（P7 给出 A/B 测试 + 统计显著性方案）第 4 层：怎么做到「掉点 5 分钟内发现」？（P7 给出监控告警体系）第 5 层：用户投诉说 Agent 给了错误答案，但日志里显示成功，怎么解释？ （P7 给出「技术成功 vs 业务成功」的区分：工具调用成功 ≠ 用户问题被解决）题目 6：设计一个支持 100 万用户的 Agent 系统
考察模块：系统设计（Senior 重灾区）P6 vs P7 核心差距：P6 给架构，P7 给架构 + 成本模型 + 扩展路径
P6 的典型答案
用微服务架构，Agent 服务水平扩展。用 Redis 做会话状态存储。用向量数据库做知识库。用 Kubernetes 做容器编排，自动扩缩容。
这个答案没有错，但面试官会问：「这个系统每月 LLM 成本是多少？」P6 通常答不上来。
P7 的典型答案
P7 先澄清约束：
100 万用户不等于 100 万并发。DAU × 平均会话时长 / 86400 = 并发数。假设 DAU 10 万，平均会话 5 分钟，并发约 350 个会话。这是架构设计的起点。
然后给出五层架构：
接入层：API Gateway + 限流（每用户 10 QPS，防止滥用）会话管理层：Redis Cluster（会话状态 + 短期记忆）Agent 核心层：无状态服务，水平扩展（状态全在 Redis 里）工具层：工具调用服务化，独立部署，独立扩展存储层：向量数据库（长期记忆）+ 关系数据库（用户数据）然后是 P6 完全没有的部分——成本估算：
假设每次对话 2000 token（输入 1500 + 输出 500），用 GPT-4o，每次对话约 3000，每月约 $90,000。
成本优化路径：简单意图用小模型（成本降 10x）、语义缓存（节省 20-40%）、上下文压缩（减少输入 Token）。目标：把月成本从 20-30K。
最后是扩展路径：
100 万 DAU：在当前架构基础上水平扩展，不需要重新设计。1000 万 DAU：需要引入消息队列（异步处理）+ 多区域部署。
面试官的 5 层追问链
第 1 层：设计一个 100 万用户的 Agent 系统（P6/P7 都能答）第 2 层：这个系统每月 LLM 成本是多少？（P6 卡壳，P7 给出成本模型）第 3 层：怎么把成本降低 70%？（P7 给出多模型路由 + 缓存方案）第 4 层：用户量从 100 万增长到 1000 万，架构需要怎么改？（P7 给出扩展路径）第 5 层：某个工具调用的 API 提供商突然涨价 10 倍，你怎么应对？ （P7 给出供应商切换 + 抽象层设计：工具调用不直接依赖具体 SDK，通过抽象层隔离）三、P6 → P7 的跨越路径
看完 6 道题，你可能会想：「P7 的答案我也能想到，只是没有系统化。」
这正是关键所在。
P7 不是「知道更多」，而是把生产思维变成了本能。每次设计方案，自动问自己：成本是多少？挂了怎么办？怎么知道它出问题了？用户量 10 倍之后架构要怎么改？
3 个具体动作，帮你建立这个思维框架：
1. 每个技术决策，强制给出数字
不要说「用滑动窗口保留最近 N 轮」，要说「用滑动窗口保留最近 20 轮，因为 20 轮 × 200 token = 4000 token，在 128K 窗口里占比 3%，超过 20 轮后注意力衰减明显」。
数字不一定要精确，但要有数量级的感知。
2. 每个方案，强制设计降级路径
不要只设计「正常路径」，要问自己：「这个组件挂了，系统怎么降级？」向量数据库挂了，降级到 KV 存储；LLM 超时，降级到规则匹配；工具调用失败，降级到告知用户。
生产系统的稳定性，80% 来自降级设计，不是来自「让它不挂」。
3. 每个系统，强制设计可观测性
不要等用户投诉才知道出问题了。每个关键指标都要有告警阈值，每个工具调用都要有成功率监控，每次 Prompt 变更都要有回归测试。
「5 分钟内发现问题」是 P7 的基本要求，不是加分项。
总结
P6 和 P7 的差距，不是「P7 背了更多面试题」，而是：
• P6 给方案，P7 给方案 + 数字 + trade-off • P6 处理正常路径，P7 设计降级路径 • P6 等问题出现再排查，P7 在问题出现前建好监控 • P6 在给定约束内设计，P7 主动质疑约束
面试官追问到第三层，是在测你有没有真正在生产环境里踩过坑。背答案没用，建立生产思维才是根本。
📌 收藏速查
6 道题的 P7 答案核心要点：
1. Memory 设计：先问约束（规模/时效/延迟），再给方案；每个决策有数字；有降级策略 2. 工具调用错误：分类处理（可重试/不可重试/部分成功）；注意幂等性；错误信息结构化 3. 多 Agent 任务分配：先问并行/依赖关系；给出 Token 成本模型；设计子 Agent 失败处理 4. Prompt 版本管理：注册中心 + A/B 测试 + 热更新；Prompt 变更有回归测试集 5. 准确率掉点排查：四步框架（时间点→类型→根因→预防）；建监控告警 6. 百万用户系统设计：先算并发数；给出成本估算；有扩展路径
点击右上角「⭐收藏」，下次面试前打开复习。
💬 评论区选一个：你面试 Agent 岗时，最怕被追问到哪一层？
A. Memory 系统的成本模型B. 工具调用的幂等性设计C. 准确率掉点的排查框架D. 百万用户的架构扩展路径
📄 数据来源：本文内容综合自本号已发布的《AI Agent 面试通关18问》（2026-04-22）、《Agent Memory 面试通关18问》（2026-05-26）、《Function Calling 送命题》（2026-05-05），以及作者对大厂 P6/P7 晋升标准的行业观察（标注为作者判断）。成本数字基于 GPT-4o 截至 2026-05 的公开定价，模型定价频繁变化，仅供量级参考。
