我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于
Tiptap的富文本编辑器、NestJs后端服务、AI集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了Tiptap的深度定制、性能优化和协作功能的实现等核心难点。
如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。
如果你对 OpenClaw 也感兴趣，也欢迎添加我微信，我拉你进交流群
不少朋友从传统前后端或数据岗往 AI 全栈、Agent 方向转，简历上会写"做过智能客服""搞过 LLM 应用"，真到面试时，面试官往深了一问，多轮对话怎么设计、幻觉怎么控、工具调用怎么落地，很容易卡壳。下面是一份美团 AI Agent 开发一面（智能客服方向，2026 年 2 月）的真实题目和参考答案思路，你可以先在心里答一遍，再对照看看自己差在哪一块。
第一题 智能客服的多轮对话怎么设计
面试官问：假设你需要开发美团智能客服 Agent，如何设计多轮对话流程？
多轮对话要解决的是"用户说了上句，系统还能接住下句"。用户说"那改成明天""再帮我加一份"时，如果系统不知道当前在哪个环节、已经有哪些信息，就会答非所问。设计时可以抓住几条线。
- 对话状态：当前处在哪个业务环节、已经填了哪些槽位（时间、门店、商品等），用结构化状态或状态机维护。
- 每轮解析：对用户输入做意图识别和实体抽取，和当前状态拼在一起。
- 决策与动作：根据"状态 + 本轮意图"决定是继续追问、调用接口、还是转人工，再生成回复。
把"状态 → 解析 → 决策 → 回复"这条链路想清楚，再考虑超时、用户打断、多轮澄清等边界，就能讲出一套完整方案。
追问一：你会使用哪些对话状态跟踪方法？
常见有三种思路。一是基于槽位的状态机，每个意图对应一组必填槽，槽填满再执行动作，适合流程固定的场景。二是基于 DST（Dialogue State Tracking）的更新，用规则或小模型根据上一轮状态和本轮用户话术做状态更新。三是把多轮当成序列交给 LLM，不显式维护槽位，靠上下文做"隐式"状态跟踪。实际项目里可以混用，例如关键槽用显式状态机保证可控，其余交给模型。
追问二：如何处理用户意图模糊的情况？
先对意图做置信度判断，置信度低时不要强行选一个意图执行，而是主动澄清。澄清方式可以是：给出几个最可能的意图让用户选、针对缺的关键信息单独追问、或用一句带选项的确认（例如"您是想查询订单，还是想申请退款？"）。可以单独做一个"澄清"子流程，在意图不清时一律走澄清，避免误触发下单、退款等敏感操作。
第二题 用 LLM 做智能助手时遇到过哪些幻觉
面试官问：描述一次使用 LLM 开发智能助手的经历，遇到过哪些幻觉问题？
幻觉是面试高频题，最好提前准备一两个具体例子，按类型说清楚。
- 无中生有：用户问"上周订单有没有优惠"，模型编造了一个不存在的活动或规则。
- 张冠李戴：把 A 产品的价格、规则套到 B 产品上，或者把别的业务线的政策当成当前业务的。
- 过度肯定：对不确定的问题也给出非常肯定的结论，用户信以为真后才发现是错的。
应对思路可以分几层说：从数据源上限制模型只能基于检索到的文档或调用 API 的结果来答；对关键结论做二次校验或要求引用来源；在系统提示里明确写"不确定就说不知道，不要猜测"。有真实项目经历的话，可以顺带说一句你们当时是怎么发现、怎么修的就更有说服力。
第三题 Agent 的规划能力与多任务协同
面试官问：解释 AI Agent 的规划能力，如何实现多任务协同（如点餐、支付、售后）？
规划能力指的是 Agent 能把一个复杂目标拆成多个子目标、排好顺序或依赖关系，再一步步执行。点餐、支付、售后就是一条链路上的多步，有先后和依赖：先点餐再支付，售后又依赖已有订单。
实现上可以有两种说法。一是显式规划：用单独的规划模块（Planner）根据用户目标生成步骤列表，执行模块按步骤依次调工具。二是把规划交给主控 LLM，每轮由模型决定"当前该做哪一步、调用哪个工具"，用 ReAct、LangGraph 等范式都能实现。多任务协同时要讲清楚三件事：步骤之间的数据怎么传（例如订单号从点餐传到支付再传到售后）、某一步失败时是重试还是降级、用户中途改主意时如何重新规划，这样才显得你真正做过或认真想过。
第四题 Agent 工具调用的技术方案
面试官问：在设计 Agent 的工具调用能力时，你的技术方案是什么？
工具调用可以拆成三块来讲，逻辑清晰又不容易漏。
- 工具描述：把每个工具的名称、参数、用途用
JSON Schema或OpenAPI描述出来，和LLM的function calling格式对齐，让模型知道有哪些工具、该怎么选。 - 解析与校验：用模型自带的
function calling输出拿到"想调哪个工具、参数是什么"，再自己做一层校验（必填、类型、范围），避免脏参数直接打到业务接口。 - 执行与治理：真实调用下游
API，把结果塞回上下文。执行层要做超时、重试、熔断，对下单、支付等敏感工具可以做权限控制或二次确认。
追问一：如何选择合适的工具 API？
从"和当前意图是否匹配、参数能否从对话里补齐、当前是否有权限调用"几个维度筛。工具很多时，可以先做意图或语义检索，只把 Top-K 个相关工具暴露给当轮，减少干扰和 token 消耗。业务上要区分核心流程工具（下单、支付）和辅助工具（查门店、查天气），优先保证核心工具的稳定和可控。
追问二：会使用哪些函数调用框架？
可以分几类说：云厂商的 Agent 平台（如阿里百炼、腾讯混元助手）、开源编排如 LangChain、LangGraph 的 tool 能力、以及直接用 OpenAI 或国内大模型的 function calling API 自建。选型时看团队技术栈、要不要多模型切换、以及对编排和可观测性的要求。如果已有统一网关或 BFF，可以在这一层做 tool 的注册与路由，再对接不同 LLM 的 function calling 格式，这样答会显得你有架构视角。
第五题 通过用户反馈优化 Agent 的经历
面试官问：分享一次通过用户反馈优化 Agent 能力的经历，关键改进是什么？
这道题考的是你有没有闭环思维，最好用真实项目来答。可以按"现象 → 归因 → 动作 → 效果"来讲。
例如：上线后发现某类问题用户常问但回答不准，通过收集 badcase 发现是意图被误判或检索不到对应文档。改进动作包括：补充、改写该意图下的 FAQ，调整检索策略（关键词、向量、混合）或文档切分方式，在 prompt 里加该场景的 few-shot，对高频问题单独做规则兜底。关键是要强调反馈闭环：从工单、日志、标注里筛出问题样本，归因到"意图、检索、生成、工具"中的某一环，再针对性迭代，用 A/B 或离线评估验证，而不是凭感觉改。
小结
五道题分别扣住多轮对话、幻觉控制、规划与多任务、工具调用、反馈优化，都是 Agent 和智能客服场景里实实在在会碰到的问题。想转 AI 全栈的朋友，可以拿这份题当自测：先不看答案在心里答一遍，再看自己哪一块说不清，针对性补一补理论和项目经历。祝大家面试顺利，早日拿到心仪 offer。
