蚂蚁集团智能体一面：从 MCP Client 问到知识图谱，60 个问题一路追到设计动机

《面试题目》

1. 请简单介绍一下自己。
2. 你硕士期间是不需要发表小论文的吗？
3. 你现在是回学校准备秋招吗？
4. 能不能具体讲一下 Agent 是怎么实现的？
5. 你的实现主要是一个 Skill 吗？
6. 为什么要把 MCP 的目录传给 Agent？
7. MCP 需要提前安装并连接 Server；如果只传一个 MCP 列表、Agent 又没有主动连接 Server，它是怎么调通工具的？
8. 具体什么叫 MCP Client？能不能讲讲它是怎么实现、怎么工作的？
9. MCP 是在运行期间主动连接 Server 的吗？
10. MCP Client 是什么，是你们做的工具吗？它之前已经安装好并在「双态」那边连上了吗？
11. 所以它可以理解为一个通用的 MCP 功能吗？
12. 如果大模型通过统一的 Center 看不到 MCP 工具名称和入参，怎么保证它能正确组装参数？
13. MCP Client 会把所有工具都取回来吗？大模型又是怎么拿到这些工具信息的？
14. 如果 query 里才给 MCP name，怎么确保大模型会调用 MCP Client 并拿到对应的 tools？它的上下文里是不是没有 MCP 工具信息？
15. 大模型怎么知道要调用本地 Client？是否需要先通过 MCP Client 请求对应的 tools，再组装参数？
16. 你在 Skill 里给它设定了一些上下文信息吗？
17. 为什么要通过 MCP 获取信息？MCP Center 这个设计是怎么考虑的？
18. 为什么不把 MCP 获取回来的信息写在 SQL 里，而要经过 MCP 层？
19. 为什么不把远程信息直接写在 Skill 里，还要通过 MCP 绕一圈？这个设计的考虑是什么？
20. 二次请求应该不会再经过 MCP Server 吧？所以走一次 MCP Center 是为了这个考虑吗？是出于上下文长度的考虑吗？
21. 大模型是在什么时候调用你们的 API？
22. 是在 query 里主动指定要用这个 Skill，或者指定用 SQL 排查问题吗？
23. 大模型 request 里的 Skill、MCP、System Prompt 和 User Prompt 是怎么组装的？
24. 撇开 Agent 项目不谈，Anthropic 或 OpenAI 的 API request 具体怎么组装、怎么调用？请求内容只有这些吗？
25. 大模型返回时，在哪个字段说明要调用什么 tool、传什么参数？response 通常有哪些结构？
26. 你这边没有特别关心过 response 结构吗？
27. 你在 2025 年 6 月和 10 月做过基于 LangGraph 的事情吗？
28. Graph 的正常开发流程是什么样的？
29. LangGraph 的各个节点怎么拼装、怎么调用？具体怎么拼成一个 LangGraph？
30. 你们编排了几个 Agent、几个 LangGraph 节点？2025 年 6 月到 11 月的 LangGraph 里有多少个节点？
31. 向量检索的目的是什么？召回方式有很多，为什么用向量检索？
32. 向量检索库承载什么功能？
33. 你们的库里存放多少信息，大概多少条数据？放的是 20 条数据吗？
34. 这是必做的设计吗？如果只有 6 条或 20 条数据，还需要用向量检索吗？
35. 考虑未来使用增长，增长情况大概有哪些？用户平常每天会存多少数据，或者每隔多久存多少？
36. 「商家库版本」是什么概念？
37. 工作流编排、工作流名称和描述是放在向量库里吗？
38. 正常使用时不就一个版本吗？会同时有三四个版本吗？
39. 为什么要用向量数据库？
40. 后面的人会不断叠加工作流，运行时再把工作流召回吗？
41. 你们是预设模板吗？用户怎么新增节点、动态编排？如果没有匹配的模板怎么办？
42. 如果现有流程不满足需求，用户能做什么？
43. 用户拖拽并校验完新的工作流后，点击保存会存到向量库还是新的数据库里？
44. 什么情况下会用知识图谱？当时为什么选择它？
45. 为什么目前（比如到 2026 年的 Agent）知识图谱用得比较少？
46. 百度实习时好像也没有用知识图谱；诊断场景没有用吗？
47. 2026 年的知识构建和图谱抽取中，什么样的知识需要用知识图谱构建？
48. 大模型的请求怎么样在知识图谱里变成确定性的搜索？
49. 为什么不把所有信息直接放在向量库里？
50. 知识一般用 RAG、从向量数据库召回就可以了吧？那为什么你说的这些知识不能通过 RAG 召回？
51. 大模型读了 SOP 不就已经构建联系了吗？为什么还需要通过知识库构建联系？
52. 知识图谱相比大模型自己去找，优势在哪里？
53. 你们的知识图谱大概几跳？也就两跳吧？那大模型自己也能跳两跳吗？
54. 你们当时主要是考虑大模型的耗时和 token 吗？
55. 知识图谱检索准确率有多少？80% 多是怎么算出来的，你们怎么看这个数据？
56. 如果要提升准确率，除了刚才提到的办法和知识清洗，还有什么方法？
57. 你们组目前对知识图谱的改进主要就这两种吗？数据准备怎么清洗？
58. 你们的数据不是还挺大的吗？从数据清洗到训练模型的决策是怎么得出来的？主要考虑的是训练成本，而不是清洗过程中遇到了什么问题吧？
59. 你那边有没有什么需要问的？
60. 这一块应该不用我介绍吧？你在百度这样的公司实习过，应该有不少经验吧？

《参考解析》

60 个问题不是 60 个知识点，是一条追问链

三块内容看着跨度很大——MCP 与 Skill、LangGraph 与向量检索、知识图谱与训练成本——其实是同一种问法：先让你讲实现，再一层层问「为什么这么设计、换个做法行不行、在你这点数据量上还成立吗」。大量「对吧？」不是让你点头，是给你一个台阶，你确认了他就往下挖一层。应对这种面，把每个设计说成「取舍 + 边界条件」，比背架构图有用得多。

MCP Client 与工具上下文：谁在什么时候把 tools 放进请求

这块要讲清三个动作。第一是发现：Client 连上 Server 后取工具清单，拿到工具名、描述和参数的 JSON Schema。第二是注入：工具定义是随 request 一起发过去的（放在请求的 tools 字段里），不是写在用户 prompt 里，模型看到的是结构化的能力列表而不是一段散文。第三是调用与回灌：模型返回一个 tool call，里面是工具名和参数 JSON，由 Client 真正执行，结果作为工具结果消息追加进对话，再发起下一轮。

面试官连追的正是这条链最含糊的接缝：只在 query 里给了一个 MCP name，模型上下文里既没有工具名也没有入参 schema，它凭什么正确组装参数？唯一站得住的答案是「必须有一刻把 schema 取回来放进 tools」，否则就是让模型猜参数名，不可靠也没法校验。他接着问「为什么不把取回来的信息写进 SQL、不直接写进 Skill」，考的是单一来源：写死之后工具一升级，提示词里的描述就静默过期，而且没有任何地方会报错；经过 MCP 层是为了让能力描述跟着 Server 走，我们能改的只有调度策略，不是把远端契约抄一份到本地。二次请求不再经过 Server 那问要答得干净：会话内可以缓存工具清单，但要能说出缓存有效期与失效条件，而不是「应该不会吧」。

为什么用向量库，而不是直接塞进 prompt

这一串问了七八遍：多少条数据、20 条也要用向量检索吗、未来增长多少、为什么不放 SQL、为什么要用向量数据库。诚实的顺序是先承认边界：如果现在只有 6 到 20 条、结构固定、更新不频繁，塞进 prompt 或者查 SQL 都更简单、更准、更便宜。再讲为什么还是引入：条目会随用户叠加工作流线性增长，条目本身是自然语言描述而不是严格字段，召回要按语义相近而不是字面相等，而且上下文预算有限不可能全塞。

更关键的是把「向量库承载什么」说清楚：它承载候选筛选，不承载事实来源。流程是先召回 top-k，再用结构化字段（版本、状态、权限）过滤，最后取正文。被问「商家库版本」「会不会同时有三四个版本」时，要说明版本是元数据、参与过滤，不是靠相似度区分——这一句能挡掉后面一半的追问。最后给量化边界：涨到多少条、查询延迟要求多少、召回率掉多少就必须上，把「为了将来」这种空话换成一个可验证的阈值。

知识图谱相对 RAG 的边界

追问路径很典型：什么情况下用图谱、为什么现在 Agent 里用得少、两跳而已大模型自己也能跳、那是不是只省了 token 和耗时。别吹图谱，讲边界：RAG 擅长找到相关的一段文字，不擅长表达多实体之间的确定关系与约束；图谱擅长的是关系显式、可枚举、可校验，以及跳数可控（两三跳）且要求结果确定、可解释、可审计的场景，比如设备与部件的从属、故障码到处置步骤的映射。

「大模型自己也能跳两跳」的代价是不稳定：同样输入两次结果可能不同，跳错一步无法定位，每次还得把候选文本整段读进上下文。图谱的收益是把这一步变成一次确定性的图查询，省 token 和耗时只是副产品，真正的价值是可复现、可追责。同时主动交代成本：图谱要建、要清洗、要维护 schema，抽取错了会一路传下去，所以只在「关系稳定 + 查询高频 + 错了代价大」时才划算。准确率那题要能说清口径：多少条标注样本、命中判定标准是什么、无法判定的 case 有没有排除——说不清定义的数字等于没有数字。

被一层层追问设计动机时怎么应对

三个动作。一是把「当时的选择」和「现在的最优解」分开：「当时只有 20 条，先上向量库是给增长留余量；如果重做，我会先用 SQL 加规则，到几百条再切。」这比硬撑体面，也比顺着面试官改口可信。二是不确定就说不确定，但给验证方式：「这个我没测过，要验证我会做 A/B，看召回率和端到端成功率」，把「不知道」变成「知道怎么知道」。三是被指出问题时先接住再补证据，不辩解：「你说得对，这里确实没考虑并发写入，当时写入是单线程批处理，所以没暴露。」整场里那些「对吧」的引导，该确认的确认，该补充的补充——他要看的是你有没有自己的判断，而不是能不能一路点头到底。