美团 AI Agent 开发二面

1. Agent 工具调用你知道怎么训练吗？训练集应该包含哪些？怎么得到训练数据集？

如果只是让模型“知道有工具”，那只需要在 SFT 里教会它工具名和参数格式；但如果想让它真的会用工具，训练集必须覆盖完整决策链路。至少要有三类样本：一类是该调用工具的，一类是不该调用工具的，还有一类是要调用多个工具且有依赖关系的。否则模型很容易学成“逢问题必调用”。

训练数据来源一般有几种。最理想的是业务日志里已有高质量人工操作轨迹，把用户问题、检索条件、调用参数、返回结果和最终回复串起来。没有现成轨迹时，就要靠规则模板、专家构造、模型自蒸馏和人工校验混合生成。真正难的地方不在造正样本，而在构造反例，比如参数缺失、工具返回为空、多个工具都能回答但代价不同，这些不补齐，模型上线后会非常脆。

2. 假如一个 query 有两个工具都可以调用，训练集应该怎么设计？

这个问题本质上在考“工具选择偏好是怎么学出来的”。如果两个工具都能答，训练集不能只保留其中一个，否则模型会误以为另一个永远不该用。更合理的做法是把样本拆成几种情况：一种是两个工具都可用但其中一个更便宜、更快、更稳定；一种是两个工具精度不同；还有一种是一个工具适合粗召回，另一个适合精查。

训练时最好显式标出为什么选这个工具。也就是说，不只是让模型输出 tool call，还要让它学到选择依据，比如“优先选结构化接口，因为结果更稳定”“优先选本地缓存接口，因为时延更低”。如果训练集没有把这些偏好编码进去，模型最后只会学会表面模式，而不是策略。

3. 你构造数据集时遇到过什么难点？怎么解决问题？

最大的难点通常不是数据量，而是分布不真实。很多人造数据写得太标准，用户输入特别工整，参数全都给齐，工具永远成功，这种数据拿去训模型，线上一遇到省略、歧义、错别字、跳步提问，马上就崩。

解决方法一般有三层。第一层是把真实线上 query 分桶，按意图、复杂度、是否多轮、是否缺参来采样；第二层是专门补边界样本，比如工具冲突、返回异常、部分字段为空；第三层是做反事实增强，也就是把同一个问题改写成几种表达，甚至故意删字段，看模型会不会澄清。高质量 Agent 数据集不是“整理干净”就行，而是要尽可能模拟线上脏场景。

4. 细问一下 Agent 是怎么设计的？

如果面试官这么追问，通常不是要你背一个 ReAct 或 Plan-and-Execute，而是看你有没有真正把系统拆开。我一般会从五层来说：意图理解、任务规划、工具决策、状态管理、结果校验。

真正决定上限的往往不是模型本体，而是状态管理。因为多轮 Agent 一旦没有明确状态，模型上一轮调用了什么工具、拿到了什么中间结果、哪些参数已经确认、哪些还不确定，很快就会乱。成熟一点的系统一般会把“自然语言对话状态”和“结构化执行状态”拆开，前者给模型理解上下文，后者给执行器判断下一步该做什么。

5. MCP 和普通 tool call 的区别是什么？

普通 tool call 更像是“模型输出一个函数调用”，重点在调用动作本身；MCP 更像是一套标准化的上下文和工具协作协议，它不只是让模型会调函数，而是让外部能力以统一方式暴露给模型，包括工具、资源、提示模板、上下文对象等。

说白了，tool 更像单个能力接口，MCP 更像能力接入规范。前者解决“怎么调”，后者解决“怎么让不同系统稳定接进来并被模型理解”。如果公司要做大量内部系统接入、跨团队共享能力、支持统一权限和上下文管理，那 MCP 的价值会更大。

6. 如何开发一个 MCP 服务？

核心不是写个 HTTP 接口，而是把能力抽象清楚。一个 MCP 服务至少要解决三件事：第一，暴露哪些 resource、tool、prompt；第二，输入输出 schema 怎么定义；第三，权限、鉴权、超时、错误码怎么做统一约束。

工程上通常会先把内部已有能力包装成标准 schema，再补 discoverability，也就是让模型或宿主知道这个服务里有什么能力。真正难的是稳定性和可观测性：你不能只关心“能不能调用成功”，还要知道调用失败时是 schema 不匹配、参数缺失、超时、下游异常还是权限问题。MCP 一旦做成，只是第一步，后面可观测、回放、审计才是长期成本。