美团 AI-Agent 开发秋招一面：每讲一个方案，都被追问“那怎么保证？”

面经时间：2026年10月15日

这场是美团 AI-Agent 开发秋招一面。

面经的原作者的体感是范围广，但不刁，面试官像验收方：你说一个方案，他就接一句“那怎么保证”。

面经原作者反馈是第七题答得最久，也最虚，因为项目一直有人在后面检查结果，只是简历里没写。

以下为补充的参考回答，第一人称为口述示例。

全文用一个学习验证阶段的“团队资料整理助手”串联：读取指定项目资料，结合用户确认的偏好生成带来源的周报草稿，结果由人检查；Markdown 保存少量长期偏好，多 Agent 协作作为对照方案。

自动发布、无人审核和生产级恢复机制，都属于后续设计，不写成已经落地的成绩。

本次面经问题：

• 一、自我介绍，讲技术背景和 Agent 相关经历
• 二、挑一个最有代表性的项目，讲业务背景、技术方案、最终效果
• 三、除了这个，还参与过什么项目？
• 四、为什么用 Markdown 做记忆管理？相比 RAG 有什么考虑？
• 五、记忆更新时怎么保证语义匹配的准确性？匹配错了怎么处理？
• 六、为什么用 Agent Teams 架构？相比 Workflow 编排有什么优势？
• 七、线上要求全流程自动化、不依赖人工审核，怎么保证稳定和可靠？
• 八、一个 Agent 要调多个工具时，执行流程怎么设计？调用顺序怎么管？
• 九、模型调用外部工具的底层机制是什么？模型怎么决定调哪个？
• 十、一个 Agent 系统通常包含哪些核心模块，各承担什么职责？
• 十一、短期记忆和长期记忆怎么理解？各自有哪些实现方式？
• 十二、MCP 是什么？它解决 Agent 开发里的什么问题？
• 十三、工具描述写得不好，模型选错工具，从哪几层改？
• 十四、你的方案里，哪一部分真正影响了指标？

四、为什么用 Markdown 做记忆管理？相比 RAG 有什么考虑？

Markdown 是存储和组织格式，RAG 是检索增强生成的流程，不能直接当成二选一。 Markdown 文件也能被切块、建索引，再通过 RAG 按需读取。

在这个示例里，需要跨会话保留的是少量稳定偏好，比如“周报先写风险，再写进展”。用 Markdown 按用户、项目和主题组织，便于查看、修改和比较版本。文件里仍要有记忆 ID、作用范围、来源和更新时间，不能只有一段没有出处的自然语言。

读取时先按用户和项目定位，再取相关主题；规模很小时可以直接读取受控的小文件，不一定需要向量库。资料库里的业务事实则按任务检索，不会因为“以后可能有用”就全部写进用户记忆。

当文件数量增加、同义表达多、精确定位困难时，我会考虑关键词与向量混合检索。但索引只是找候选，命中后仍需校验当前原文、权限和版本。文件方式也有并发覆盖、重复和过期问题，不能把“方便人工编辑”说成“天然准确”。

关于存储、检索和记忆职责的区别，可以结合Agent 的记忆：短期、长期、RAG 的关系看。

五、记忆更新时怎么保证语义匹配的准确性？匹配错了怎么处理？

我不会让模型凭相似度直接覆盖旧记忆。流程是：提取候选信息，按用户、项目和记忆类型过滤，找到可能相关的旧条目，再判断它属于重复、补充、纠正、冲突，还是一条新信息。

比如旧记忆是“项目甲周报先写风险”，新输入是“项目乙这次先写进展”。两句话都在说周报，但项目不同，而且“这次”是临时要求，应该进入本次任务状态，不能覆盖项目甲的长期偏好。语义相似，不代表事实相同，更不代表有权替换。

对于确实要更新的条目，我会保存原文证据、变更原因、旧版本和新版本，通过版本校验防止并发覆盖。证据不足就暂存候选或不更新；有人参与的阶段可以请求确认，无人审核的方案则应保守保留旧值，并把冲突返回任务状态。

匹配错了，先停用错误版本，恢复有效旧值，再查哪些草稿引用过它，必要时重新生成。只改回记忆文件，已经产生的错误结果不会自动消失。

评测会专门收集容易混淆的配对样本：不同用户、同名项目、否定句、临时偏好和相互矛盾的更新。分别统计应更新条目的命中情况、错误覆盖比例，以及暂缓更新的比例；阈值在开发集上调，不能拿向量相似度当“正确概率”。

这张图强调的是写入之前先判断信息是否稳定、有用、得到确认。语义匹配只是其中一环，临时要求即使匹配得很准，也未必应该写入长期记忆。

六、为什么用 Agent Teams 架构？相比 Workflow 编排有什么优势？

这里我先明确，Agent Teams 指多个角色 Agent 的协作，不默认绑定某个框架。它和 Workflow 也不是同一维度：前者描述由哪些角色协作，后者描述流程由谁、按什么规则控制，多 Agent 完全可以放在 Workflow 里运行。

我尝试的分工是资料收集、草稿生成和证据核对。资料较多、不同子任务可以独立推进时，拆角色能隔离上下文，也方便按来源并行收集；核对角色则从事实与引用的角度检查草稿。交接产物要包含事实条目、来源、未解决冲突，不能只传一段概括。

代价是多次模型调用、角色间信息损失，以及共享状态冲突。核对 Agent 也可能和生成 Agent 犯同一种错，所以“有一个审核角色”不能作为正确性的证明。

如果流程只是“读资料、生成、检查”，固定 Workflow 很可能已经够用。我会让确定性流程管权限、阶段和提交，开放的信息查找再交给 Agent；只有在同样预算下的对照结果证明多角色有收益，才保留 Teams。

图里主流程与开放节点分开控制。放到本题，资料收集可以动态探索，是否允许进入发布阶段则由明确条件决定。选型细节可以看Agent 与 Workflow 怎么取舍。

七、线上要求全流程自动化、不依赖人工审核，怎么保证稳定和可靠？

我会先承认现状：目前有人看结果，所以我还没有证据证明它能无人值守。要去掉人工审核，得先定义自动处理的范围、成功标准和失败出口。全流程自动化应包括自动判断无法完成，并安全结束，不能要求任意输入都强行产出一个成功结果。

以周报为例，我会先限定为授权项目、固定时间范围和指定模板，只允许发布到配置好的目标位置。缺关键资料、来源互相冲突或目标位置不合法，就返回明确失败状态，不让模型自行扩大查询范围、猜事实或换发布位置。

执行过程用状态机控制：收集资料、生成草稿、验证、提交、完成。模型可以提出下一步动作，但执行器检查权限、参数和当前阶段；同时限制总时间、模型轮数、工具次数和费用。工具返回的文档属于数据，其中夹带的指令不能改变系统权限。

验收时把能确定检查的部分交给程序：必填章节、引用是否存在、来源是否属于当前项目、时间和数值是否对应原文。模型评审可以辅助判断是否遗漏重点、是否曲解语义，但它本身也有误判，需要用已标注样本校准。引用存在不等于结论被引用支持，这两项要分开测。

如果要自动发布，写工具还需要业务幂等键、草稿版本和提交前条件校验。遇到“请求超时但可能已经发布”，先按幂等键查询结果，再决定是否重试，不能直接再次发布。可撤回的内容保留旧版本；不可逆动作要限定得更严，无法建立验收和恢复条件的任务就不进入自动处理范围。

上线前我会建包含正常、缺资料、冲突、越权、超时和重复请求的评测集，并注入工具失败、进程中断等情况，验证重试、恢复和停止是否符合预期。固定外部资料快照，对同一任务多次运行，观察稳定性；发布前做回归，先影子运行，再对满足条件的流量逐步放开。

这里不能只看成功率。我会同时统计合格完成率、错误放行率、自动处理覆盖率、耗时和成本。错误放行率可以定义为“被系统判为通过并交付、但独立验收不合格的任务数／系统判为通过并交付的任务数”。全部拒绝可能让这个指标看起来很好，因此覆盖率必须一起看。

没有人工逐单审核，不代表开发和运营阶段也不再做样本标注、抽检与故障复盘。真正移除的是每次执行都要等人点确认，质量标准和改进过程仍需要人负责。

这张图对应失败后的处理：从轨迹中定位原因，把样本变成回归用例，把可强制执行的约束放进运行系统。更完整的定位方法，可以看Agent Harness 可观测性面试详解。

八、一个 Agent 要调多个工具时，执行流程怎么设计？调用顺序怎么管？

我会根据数据依赖、任务阶段和副作用决定顺序，不能按模型返回的工具数组直接并行执行。

比如用户给出项目名，我要先解析成唯一项目 ID，再读取该项目的资料。项目已明确后，不同资料源的只读查询可以并行；生成草稿依赖收集结果，证据检查依赖草稿，发布又依赖检查通过。这些必要前置条件由执行器约束，不只写在 Prompt 里。

每个工具调用保存调用 ID、输入、结果、错误和状态。并行查询部分失败时，明确哪些结果完整、哪些缺失，再判断是否允许继续。执行恢复时从已确认的状态继续，写操作先查提交结果，避免重复产生副作用。

简单任务用状态机和依赖检查即可，不必硬上复杂 DAG。开放步骤里，模型根据工具反馈选择继续搜索、读取原文或结束；执行层负责并发上限、超时、重试和终止。

图里展示的是逐轮根据结果推进的循环。多工具调度要在这个循环外补依赖与状态约束，并不是模型一次列好工具就全部执行。

九、模型调用外部工具的底层机制是什么？模型怎么决定调哪个？

通常使用 Function Calling 或 Tool Use。应用把可用工具的名称、描述、参数 Schema 和当前上下文提供给模型，模型生成工具调用请求；执行器解析和校验后调用真实函数，把结果关联到调用 ID，再放回下一轮上下文。

比如下面是示意格式，不绑定具体厂商接口：

{
  "tool_calls": [
    {
      "id": "call_01",
      "name": "read_project_document",
      "arguments": {
        "project_id": "project_alpha",
        "document_id": "weekly_source_01"
      }
    }
  ]
}

模型不是在内部直接执行这段函数。它依据任务、工具说明、已有结果和训练中学到的调用模式，生成工具名与参数；实际选择还会受应用提供的工具子集、强制调用设置等条件影响。描述相似或上下文缺失时，它可能选错。

结构合法只说明请求能被解析，不说明调用符合业务。 执行器仍需检查项目访问权限、文档是否存在、参数组合是否有效，以及当前步骤是否允许调用。工具执行成功后，也还要检查返回结果是否足以完成任务。

十、一个 Agent 系统通常包含哪些核心模块，各承担什么职责？

我会沿着实际执行链路讲，不把“感知、规划、行动、记忆”四个词背完就结束。

模块	在资料整理助手里负责什么
任务入口与约束	接收目标，确认用户身份、项目、时间范围和输出要求
模型决策与规划	根据上下文提出工具调用、生成草稿或选择结束
编排与任务状态	管阶段、依赖、并发、检查点、预算和终止条件
工具注册与执行	提供工具契约，校验参数和权限，执行并返回结果
上下文、记忆与检索	组装当前证据，读取适用偏好，管理历史与版本
验收与交付	检查产物，决定通过、失败或安全停止，控制提交
可观测与评测	记录轨迹、耗时和成本，定位问题并支持回归比较

边界是：模型提出“我想读这个文档”，执行层决定能不能读；模型说“草稿完成”，验收层决定是否满足条件。运行状态要能持久化，不能只存在模型的一段聊天记录里。

这些是职责划分，不代表每一项都要拆成独立服务。原型可以在一个应用里实现，但接口和状态边界要清楚，之后才能定位“到底是没查到、用错了，还是检查没拦住”。

十一、短期记忆和长期记忆怎么理解？各自有哪些实现方式？

短期记忆服务当前会话或任务，比如近期消息、刚拿到的工具结果、当前草稿和待验证假设。常见实现是消息窗口、摘要和结构化任务状态，超出上下文预算的原文放在外部，通过引用按需读取。

当前阶段、已执行动作、发布是否成功这类状态，我会放进任务存储，便于恢复；它不应该只靠对话摘要记住。摘要可能丢否定词和适用范围，关键 ID、版本和工具结果要保留精确字段。

长期记忆跨任务保留稳定且值得复用的信息，比如用户确认的输出偏好。可以用 Markdown、关系表或文档存储保存；需要语义检索时再加向量索引，并保留来源、适用范围、有效期、更新和删除机制。向量库是一种检索实现，不是长期记忆的定义。

例如“这次不要写人员名单”先作为本次约束；“今后的周报都不要列人员名单”才是长期偏好候选。项目资料库则保存外部业务知识，两者可以共用检索设施，但写入权限和生命周期不同。

这张图把近期对话、任务状态、长期偏好与外部知识分开。系统重启后恢复任务状态，并不意味着所有历史聊天都该进入长期记忆。

十二、MCP 是什么？它解决 Agent 开发里的什么问题？

MCP 是 Model Context Protocol，用于标准化 AI 应用与外部能力之间的交互。它解决的是不同应用反复为资料库、文件系统等工具写专用适配的问题，让能力可以通过统一协议暴露、发现和调用。

典型角色包括 Host、Client 和 Server。Host 是承载 Agent 的应用，Client 负责与相应 Server 通信，Server 暴露工具、资源或提示模板。就工具而言，应用发现可用工具后，可以整理成模型使用的工具定义；模型提出调用，再由应用校验并通过客户端调用服务端。

放到这个示例里，资料系统可以通过 MCP 暴露查询与读取工具，Agent 应用接入后复用这些能力。但也可以直接封装普通函数，工具少、只有一个应用时，不必为了名字好看再多加一层。

MCP 管接入和交互，Function Calling 管模型侧的调用表达。 接上 MCP 不会自动带来合理的调用顺序、正确的业务参数或可靠的结果，权限校验、超时和验收仍要落实到应用及服务端。

图中两层可以一起使用：模型选择工具，应用通过标准接口执行。协议本身的展开可以看MCP 协议与工具接入。

十三、工具描述写得不好，模型选错工具，从哪几层改？

我先看调用轨迹：正确工具有没有出现在候选里？模型是选错名字，还是参数填错？工具有没有返回错误，但被当成成功？没有分清原因，光改描述可能改不到问题上。

如果是工具含义重叠，我会改名称和职责边界。比如 search_documents 返回候选文档 ID 和摘要，read_project_document 读取指定文档原文；描述里说明适用条件、前置输入、返回内容和不负责的事情，并补容易混淆的正反例。

参数层把项目 ID、文档 ID、日期格式和取值范围写清，必要参数缺失就显式报错。返回层区分“查询成功但无结果”“权限不足”“资料不完整”和“工具超时”，否则模型可能拿空结果继续生成，或者反复用相同参数重试。

工具多时，再按任务和权限缩小候选集合，检查路由是否漏掉正确工具。关键前置条件由执行层强制校验；描述清楚也不能省掉检查。仍然选错，再评估提示样例、上下文组织或模型能力，而不是先认定换更强模型就行。

修改后我会跑工具混淆样本集，分别测选择、参数、调用时机和结果使用是否正确，并回归相邻工具，防止修好一个入口却挤掉另一个。契约写法可以看Agent 工具设计。

十四、你的方案里，哪一部分真正影响了指标？

我不能把“加了 Teams”“接了 MCP”直接说成贡献。要先回答：改动作用在哪个环节，减少了什么错误，是否在其他条件相同时改善了最终任务。

如果我想证明记忆更新校验有用，就固定模型、工具、任务输入、资料快照和运行预算，比较开关校验时的结果。先看错误覆盖是否减少，再看跨任务生成的草稿是否更少采用错误偏好；同时记录因为暂缓更新造成的偏好遗漏，不能只展示收益。

Teams 也是一样，要和单 Agent、固定 Workflow 做同预算对照。若额外核对角色只是增加调用次数，却没有减少事实错误或人工修改，就没有证据保留这层复杂度。改变多个组件后一起变好，也不能把提升全部归给其中一个。

我会把评测工作讲成三件具体的事：

• 怎么建集：从真实任务或明确标注的模拟任务采样，包含普通任务、缺资料、跨项目同名、临时偏好、冲突更新和工具故障；写明可接受结果与必须停止的条件。按项目或时间划分开发集和留出测试集，避免同一模板的近似样本两边都有。
• 怎么归因：保留输入、模型与提示版本、记忆版本、资料快照和工具轨迹，区分检索漏证据、记忆误更新、工具选错、生成误读和验收漏检。找到最早偏离的位置，也检查后续为什么没有拦住。
• 回归怎么卡：每次改模型、Prompt、工具或记忆规则都跑关键用例与完整回归。对越权、错误发布等关键用例设阻断条件，对完成率、覆盖率、成本和时延设事先约定的比较口径；小样本中的“零错误”不能解释成未来没有风险。

对同一个样本多次运行，比较结果波动；报告样本数、成功次数和不确定性，不能只挑成功的那次。自动验收器也要单独测试错误接受与错误拒绝，必要时用独立人工标注校准，避免生成器和评分器一起看漏同一个问题。

离线改善后，还要在允许的线上范围验证人工返工和处理时间。没有对照数据，就把它称为设计判断；有证据后，再说它影响了指标。 评测口径可以继续看Agent 怎么评估。

这场面试真正考什么？

原作者复盘时把重点落在评测上，这个提醒很实在。不过，评测发现问题之后，还得有人把错误更新修掉、把执行边界卡住、把恢复流程做出来。它和架构、工具工程连在一起，才能回答那句“怎么保证”。

录友可以拿自己的项目做一次练习：选一条曾经依赖人工发现的错误，写清输入、错误结果、发现方法和拦截位置，再做成一个能重复运行的回归用例。如果想继续练检索与证据问题，可以接着看美团 Agent 开发日常实习面经。

把“有人看着所以没出事”，改成“拿掉这一步后，哪些错误能被系统发现，哪些还发现不了”。这句话讲清楚，项目才经得起追问。