蚂蚁智能体一面：从 MCP 工具发现一路追到知识图谱为什么两跳就够

《面试题目》

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、几个节点？2025 年 6 月到 11 月的图里有多少个节点？
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. 你那边有没有什么需要问的？

《参考解析》

MCP 的工具是怎么进上下文的：这是整场追问的主线。MCP 是「模型 ↔ 工具/资源」的协议，Server 通过 tools/list 暴露工具名、描述、JSON Schema 形式的入参；Client（可以是宿主应用内的一个组件，也可以是独立进程）负责连接 Server、取回清单、把「模型返回的工具调用意图」翻译成对 Server 的实际调用（tools/call），再把结果回灌给模型。所以「只传一个 MCP 列表、Agent 没主动连接 Server 怎么调通」的正确答案是：调不通——上下文里没有 schema 就没有可组装的参数，只能先让 Client 去拿 tools 再进第二轮请求。这就是所谓「两段式」：第一轮拿清单（或按 name 精确请求某一个 Server 的 tools），第二轮才带 schema 生成调用。追问「为什么不让模型自己猜参数」时要点明：参数正确性靠 schema 约束，不靠模型记忆；把工具清单塞进上下文是「有成本的正确性」，工具多时要按需检索而不是全量注入。

为什么要 MCP 而不是写进 Skill 或 SQL：三类东西的分工要能一句话说清——Skill 放程序性知识（这类任务按什么步骤做、踩过什么坑），MCP 放能力与数据的边界（有哪些工具、参数是什么、权限归谁），SQL 是某一次具体查询的实现。把远程信息硬写进 Skill 的问题是：数据变了要改提示词、没有权限校验、无法审计、也无法复用给别的 Agent；把 MCP 拉回来的数据再塞进 SQL 是绕路——SQL 只能查你已有的库，外部系统的实时状态本来就该由工具去取。MCP 这层的价值是标准化（换模型/换客户端不用重写集成）、权限与审计（工具级授权、每次调用可留痕）、以及按需加载（工具清单不进常驻上下文）。

request 与 response 的组装：一次请求本体是 model + messages + tools + 参数（temperature、max_tokens、thinking 等）。messages 按角色分 system / user / assistant / tool（OpenAI 叫 tool，Anthropic 叫 tool_result），system prompt 放身份与规则，Skill 的操作规范通常也拼进 system 或作为前缀消息，MCP 的工具清单放在顶层 tools 字段而不是消息里。响应里模型要调工具时给出的是结构化的 tool_calls（OpenAI：choices[0].message.tool_calls[]，每项含 id、function.name、function.arguments 的 JSON 字符串；Anthropic：content 数组里的 tool_use block，含 id/name/input），纯文本回答则在 content/message.content。拿到调用后由宿主执行，把结果作为一条新消息（带对应的 tool_call_id）追加进 messages 再请求一次。流式下这些都是增量的 delta，要按 index 拼装。

LangGraph：把 Agent 建模成状态图——定义全局 State（字段可带 reducer 决定如何合并），节点是函数（读 State、返回局部更新），边是流转（普通边、条件边按 State 决定下一跳），编译成可执行图后按「节点 → 更新状态 → 下一节点」循环，直到到达 END。相比自己写 while 循环，它的价值是显式的状态与分支（可读、可测）、检查点（每步可持久化，支持断点续跑与人机协同）、以及可观测的轨迹。节点怎么拼要能说清：一个节点只做一件事（调模型、调工具、做校验），条件边里做路由判断，循环靠「回到某个节点」表达，并要设最大步数防死循环。

什么时候该用向量检索：向量检索解决的是「语义相近但字面不同」的召回，比如用户说「退不了款」要命中「退款流程与时限」。它不适合：数据量极小（二十条数据全塞进上下文更准也更省事）、需要精确匹配或聚合的查询（订单号、金额区间、计数）、强结构化约束（权限、时间范围）——这些用 SQL 或倒排索引更可靠。工程上常见的是混合召回：向量管语义、BM25 管关键词，两路融合再重排；过滤条件（权限、版本、时间）在检索前应用，不能指望模型自己筛。被问「二十条数据也要向量库吗」，正确回答是不要——这是过度设计，直接全量放进提示词或者用关键词匹配即可，向量库的成本在运维与一致性上。

知识图谱与 RAG 的边界：RAG 给的是「相关文本片段」，模型自己从片段里拼关系；知识图谱给的是「已经确定下来的实体与关系」，多跳查询是显式的图遍历。什么时候必须上图：关系本身就是答案（A 的供应商的控股股东是谁）、需要多跳且每跳都要精确（医疗诊断的症状→疾病→用药禁忌）、需要一致性与可解释（同一实体在不同文档里有不同叫法，必须先归一）、以及需要做约束推理（哪些组合不允许）。什么时候不必上图：知识以长文本描述为主、问题基本是「找到那段话」、或者图规模太小（两跳、几十个节点）——这时模型自己在几段文本里跳两跳就够了，上图只是多一层维护成本。被追问「准确率 80% 怎么算的」，要能说清评测集怎么构造（问句从真实日志采样还是人工写）、标注口径（多跳是否算对、部分正确怎么计）、以及分母是什么；说不清口径的准确率等于没有。

面试里的自保：这场面试的特点是「连续追问到你答不出」，遇到确实没深入过的点（比如某个 response 字段），直接说「这块我没有特别关注，我的理解是……回去我会去确认」，比硬编一个细节安全——面试官明显在验证边界，瞎编会被立刻抓住。