蚂蚁集团 AI Agent开发压力面：记忆管理、MCP 与多 Agent

《面试题目》

1. 自我介绍，简单介绍自己的技术背景和 AI Agent 相关经历。
2. 介绍一个最有代表性的项目或实习产出，重点讲业务背景、技术方案以及最终效果。
3. 除了这个项目之外，再介绍一下其他参与过的项目经历。
4. 在项目中为什么选择使用 Markdown 方案进行记忆管理？相比 RAG 方案有什么考虑？
5. Agent 记忆更新过程中，如何保证语义匹配的准确性？如果匹配错误会如何处理？
6. 项目中为什么采用 Agent Teams 架构？相比 Workflow 编排方式，它有什么优势？
7. 如果线上场景要求 Agent 全流程自动化，不依赖人工审核，如何设计机制保证系统稳定性和结果可靠？
8. 当一个 Agent 需要调用多个工具时，整体执行流程应该如何设计？如何管理工具调用顺序？
9. 大模型调用外部工具的底层机制是什么？模型如何决定调用哪个工具？
10. Agent 系统通常由哪些核心模块组成？各模块分别承担什么职责？
11. 如何理解 Agent 的短期记忆和长期记忆？两者通常有哪些实现方式？
12. MCP 是什么？它主要解决 Agent 开发中的什么问题？
13. 你用过 MCP 吗？MCP 工具使用的时候有什么注意事项？
14. 如果调用失败了怎么办？怎么保证工具调用的可靠性？
15. 用户数量是多少？每天的会话数是多少？
16. 意图识别树是什么？怎么做的意图识别？准确率指标怎么测？
17. 测评集是怎么做的？数量是多少？还是说不是你测的，是产品和测试测的？
18. 你在实验室做的是什么？做过模型训练相关的吗？做过图像分类吗？
19. 你怎么理解 Agent 中的长短期记忆？实际项目中分别如何实现？
20. 是否了解 KV Cache？它在大模型推理过程中起到什么作用？
21. Agent 中的 Skill 机制了解多少？Skill 渐进式加载是如何实现的？为什么需要这种设计？
22. MySQL 索引的数据结构是什么？B+ 树和 B 树的区别？
23. 什么情况下会加表锁，什么情况下会加行锁？
24. 你能举例平时用到的 MySQL 乐观锁、悲观锁的场景吗？
25. 你怎么看待现在开源的多智能体框架？有用过哪些？
26. 对最近的 DeepSeek Harness 有什么了解？使用过吗？有什么优势？
27. 使用过哪些 AI Coding 工具？Claude、Codex 怎么配合使用？
28. 在多 Agent 开发过程中，有没有遇到上下文传递丢失的问题？怎么解决的？
29. 两种多 Agent 范式的区别：流程编排型和自主规划型分别是什么？
30. 自主规划型的多 Agent 怎么传递消息？比如输入一个任务后，怎么传给 Agent，Agent 处理完后又怎么回来？
31. 你的 Agent 在实现文件解析方面做了哪些优化？图表解析有什么优化思路？
32. 中心调度 Agent 是怎么完成任务编排的？
33. Python GIL 是什么？多线程为什么无法利用多核？协程用过吗？原理是什么？
34. Transformer 结构简单介绍，文本生成大模型用哪一部分？Attention、FFN 的作用是什么？
35. 你求职意向的工作地点是哪里？
36. 手撕题：用数组实现栈。追问：如果要求支持泛型呢？如果要求线程安全呢？如果要求 O(1) 获取最小值呢？

《参考解析》

记忆管理：Markdown 与 RAG 的取舍，以及匹配错了怎么纠：Markdown 方案的本质是「结构化、可读、可直接进上下文」的记忆文件——每条记忆是一段带标题的短文本，更新靠模型改写文件、读取时整段注入或按标题检索；优点是透明可审计、人和模型都能直接改、没有向量库的运维成本，缺点是规模上去后检索精度和上下文占用会失控。RAG 方案的本质是向量化检索，优点是可扩展到海量记忆、按语义召回，缺点是切块与检索本身有误差、更新有延迟、可解释性差。合理的答法是分场景：记忆条目少、要求可读可改时用文件式；条目上万、需要模糊召回时用向量检索；实践中常见的是混合——用文件（或关系库）存权威记忆，向量索引只做召回入口，命中后取回原文。这样被追问「为什么不用另一种」时，你有清晰的边界条件可说。记忆更新的核心风险是「该覆盖的没覆盖、不该合并的被合并」。工程手段有四种：一是写入前先做候选召回再让模型判定（召回用语义相似度加关键字段过滤，判定输出结构化的「同一条/不同条/不确定」三态）；二是给记忆加元数据（类型、作用域、时间戳、来源），匹配时先按作用域收窄，避免把不同项目或不同用户的经验混在一起；三是置信度低或冲突时不自动合并，标记为待确认并保留双份，由后续使用效果或人工介入裁决；四是一切更新可回滚——保留版本历史，发现匹配错误可以回退到旧版本。评估上要有一组「该合并/不该合并」的标注样本，定期跑准确率，而不是只靠线上感觉。

Agent Teams 与 Workflow：自主性和可控性的取舍：Workflow 编排是开发者预先定好节点和边，模型只在节点内做局部决策，优点是路径确定、可测试、成本可控、失败可重放；缺点是遇到没预设的路径就走不通。Agent Teams（多个 Agent 自主规划、互相委派）把路径决策交给模型，优点是灵活、能处理开放任务、可并行；缺点是不可预测、容易绕圈、成本与延迟不可控、评测和复现困难。合理的选型是分层：主干流程（有明确业务步骤的）用 Workflow 固定，局部开放问题（信息不全、需要探索的）放开自主规划，并且给自主部分加护栏——步数与预算上限、允许的工具白名单、每步的状态与产物落库、关键动作（对外写操作）强制人工确认或二次校验。被问到「全流程无人审核怎么保证可靠」时，答案就是这些护栏加可观测性加回滚，而不是承诺模型不会出错。

工具调用：机制、顺序与可靠性：模型决定调哪个工具的机制，是把工具的名字、描述和参数 schema 作为上下文交给模型，模型输出结构化的调用（function calling 或 tool_use），宿主解析后执行再把结果回灌。因此工具描述的质量直接决定调用准确率——描述要写清用途、边界、参数含义和反例。多工具的执行流程设计要点：先做参数校验再执行；有依赖关系的工具按 DAG 串行或并行（无依赖的并行调用能显著降延迟）；工具返回统一成「成功数据或结构化错误」两种形态，错误要带可读原因和是否可重试的标记；每个工具有超时、重试上限与熔断；写操作带幂等键。MCP 解决的是工具接口标准化的问题——把工具、资源和提示词按统一协议暴露，客户端无需为每个服务写适配器，也便于权限与审计统一管理；使用时的注意事项主要是权限最小化、把外部工具当作不可信输入（返回值要校验）、以及连接生命周期与错误处理。

意图识别、评测集与效果量化：意图识别的常见做法是先分类再路由（规则加模型的两级判定），把用户输入映射到有限意图集合并交给对应流程；「意图识别树」可以理解成按业务层级组织的意图体系，每个节点有自己的触发特征与兜底策略。准确率要用标注集测，指标至少包含意图级别的精确率、召回率和混淆矩阵，重点看高风险意图（转人工、退款、投诉）的漏判率。评测集的构建方法是从真实会话里采样并标注，覆盖正常路径、边界与对抗样本，规模上先做到几十到几百条核心用例（要能每次改动都跑），再按业务域扩展；跑评测必须固定环境与模型版本，报告要能对比基线。被追问「谁测的」时如实回答分工——这题考的是你有没有真正掌握评估链路，不知道的数据就说不知道，别编数字。

多 Agent 的消息传递与上下文丢失：流程编排型是「中心调度按图驱动」，每个节点看成一次函数调用，数据沿图的边显式传递；自主规划型是「Agent 之间自由对话」，消息通过共享的消息总线或点对点传递，中心调度 Agent 负责把任务拆分、分派、汇总。上下文丢失是自主模式最常见的故障，解决思路有三层：一是显式契约——给 Agent 之间定义结构化消息（任务、输入产物引用、约束、期望输出格式、截止条件），不要靠自然语言转述；二是产物外置——大块内容（代码、文件、检索结果）写进共享存储，消息里只传引用 ID，避免被摘要和截断吃掉；三是恢复与校验——每个子任务结束后把结论与关键字段写回中心状态，中心在汇总前校验必填字段是否齐全，缺了就回问而不是猜。这也正是「中心调度 Agent 如何完成编排」的标准答案：拆解、分派、状态机跟踪、汇总校验，加上预算与超时控制。

八股与手撕：把追问链条接完整：MySQL 索引用 B+ 树，非叶节点只存键、扇出大、树高低，叶子节点用链表相连支持范围扫描，所以比 B 树更适合磁盘；InnoDB 的行锁加在索引上，走了索引才是行锁，没走索引或范围过大就退化成表锁（间隙锁出现在可重复读隔离级别下的范围查询）；乐观锁用版本号或条件更新判断影响行数，适合冲突少的场景，悲观锁用 select ... for update，适合必须串行化的场景。Python 的 GIL 是解释器级锁，多线程无法并行执行字节码，CPU 密集要靠多进程，协程解决的是 IO 等待时的高并发切换。KV Cache 缓存历史 token 的 Key 与 Value，避免自回归生成时重复计算，代价是显存随上下文线性增长；Transformer 里文本生成主要用解码器部分，Attention 负责 token 间的信息交互，FFN 做逐位置的非线性变换。手撕「数组实现栈」的追问要一次答全：泛型用泛型参数加运行时转换；线程安全最省事是直接建议用 ArrayDeque；O(1) 取最小值用一个同步维护的辅助栈（入栈时把当前最小值一起压入、出栈一起弹出），不用额外空间的做法是存「与插入时最小值的差值」并额外保存当前最小值。