大模型面试题：办公 Agent 的意图识别模块核心痛点是什么？怎么解决？

在办公 Agent 里意图识别不是简单地判断用户“想干什么”而是要判断用户现在想做什么、缺什么信息、能不能直接调用工具、是否存在风险、要不要追问、当前任务和历史上下文是什么关系。很多候选人回答这类问题时只会说“用 LLM 做意图分类”这个回答太浅。真正落地过办公 Agent 的人会知道意图识别模块的难点不在分类本身而在上下文、状态、槽位、工具和风险控制。一、面试官考察点面试官问“办公 Agent 的意图识别模块核心痛点是什么怎么解决”通常不是想听一个 NLP 分类模型的答案而是想考察你有没有真实做过 Agent 系统。主要考察这几个点是否理解办公场景的复杂性办公场景不是单轮问答用户经常边想边补充表达不完整还会临时改需求。是否理解意图识别和工具调用的关系意图不是直接等于工具。比如“帮我通知王经理”可能对应邮件、企业微信、日历邀请、待办创建不能简单一一映射。是否知道槽位和状态管理的重要性办公任务通常需要收件人、时间、正文、附件、权限、发送方式等信息缺了就不能安全执行。是否有风险控制意识像“发送邮件”“删除文件”“修改日程”“提交审批”这类操作不能识别到意图就直接执行。是否能提出工程化方案比如分层意图体系、Session 状态、任务状态机、规则 小模型 LLM 混合识别而不是只说“Prompt 写好一点”。二、1 分钟标准回答可以这样回答办公 Agent 的意图识别核心痛点不是单纯的意图分类而是用户表达往往是模糊、分多轮、带省略和指代的同时一个任务可能包含多个子任务意图和工具也不是一一对应的。比如用户说“帮我发给王经理”系统要知道“发什么、通过什么工具发、王经理是谁、是否需要确认”。我的解决思路一般是做一套上下文感知的意图识别框架。先建立分层意图体系比如一级是邮件、日程、文档、审批二级是创建、修改、发送、查询然后做槽位抽取抽出时间、对象、内容、动作、工具等信息再用 Session 状态和任务状态机维护多轮上下文支持用户补充、修改、切换任务。对于工具选择不是直接用意图映射工具而是结合槽位、上下文和工具能力做路由。最后根据风险等级决定是否直接执行、主动澄清或二次确认。工程上我会采用规则 小模型 LLM 的混合方案。高频明确意图用规则和小模型保证稳定性复杂表达、企业内部术语、多轮推理交给 LLM同时在执行前加入风险校验和确认机制。三、核心痛点1. 用户表达模糊办公场景里用户很少说完整指令。比如帮我处理一下这个会议发给王经理明天下午安排一下把这个改正式一点这些话单独看都不完整。“处理会议”可能是改时间、取消会议、发纪要、创建日程、通知参会人。“发给王经理”可能是发邮件也可能是发企业微信还可能是共享文档权限。所以意图识别不能只看当前一句话必须结合当前页面、历史对话、用户正在处理的对象和可用工具。2. 多轮省略和指代用户在办公 Agent 里经常连续说帮我写一封请假邮件下周三下午发给王经理语气正式一点顺便抄送 HR现在发出去这里后面几句话都不是完整意图而是对前一个任务的补充或修改。系统必须知道“下周三下午”是在补充请假时间“发给王经理”是在补充收件人“语气正式一点”是在修改邮件风格“顺便抄送 HR”是在补充抄送人“现在发出去”是高风险执行动作需要最终确认。如果没有 Session 状态系统很容易把每句话都当成一个新任务导致上下文断裂。3. 复合任务办公任务经常不是单动作。比如帮我总结这份会议纪要生成待办并发给项目组成员。这句话至少包含三个子任务总结会议纪要抽取待办事项发送给项目组成员。如果系统只识别一个意图很可能漏掉后面的任务。因此需要把复杂指令拆成多个子意图并建立执行顺序和依赖关系。4. 意图和工具不是一一对应这是很多候选人容易忽略的点。用户说“通知王经理”这只是业务意图不是工具意图。它可能对应邮件发送工具IM 消息工具日程邀请工具待办提醒工具审批流通知工具。所以办公 Agent 不能简单写成意图 发邮件 → 调用邮件工具 意图 查日程 → 调用日历工具更合理的做法是业务意图 → 任务类型 → 所需槽位 → 可选工具 → 工具选择策略 → 风险校验 → 执行也就是说意图识别模块只负责判断用户目标工具选择模块再结合上下文和工具能力做决策。5. 槽位缺失办公任务往往依赖关键参数。比如发邮件至少需要收件人主题正文是否有附件是否立即发送是否需要抄送语气风格。用户只说“帮我写封请假邮件”系统不能直接发送因为收件人、请假时间、正文细节都不完整。所以意图识别不能只输出{ intent: send_email }更应该输出{ intent: email.create_or_send, slots: { recipient: null, leave_time: null, tone: formal, cc: null, send_now: false }, missing_slots: [recipient, leave_time], next_action: ask_clarification }6. 高风险操作需要确认办公 Agent 不是聊天机器人很多动作会产生真实后果。比如发邮件删除文件修改日程取消会议提交审批对外发送附件修改客户资料。这类操作不能因为模型判断“用户想发出去”就直接执行。一般要做风险等级划分风险等级示例处理方式低风险查询日程、草拟邮件、总结文档可直接执行中风险创建日程、生成待办、保存草稿可执行但要展示结果高风险发送邮件、删除文件、取消会议、提交审批必须二次确认比如用户说“现在发出去”系统应该回复我将把这封请假邮件发送给王经理并抄送 HR请假时间是下周三下午语气正式。是否确认发送确认后才调用邮件发送工具。7. 任务中途切换用户经常在一个任务还没完成时突然切换话题。比如帮我写一封请假邮件。等一下先帮我看看明天下午有没有会。好继续刚才那封邮件。这里系统要能识别“查日程”是一个新任务但原来的邮件任务不能丢。这就需要任务栈或 Session 状态管理。可以维护类似结构{ active_task: calendar.query, paused_tasks: [ { task_id: email_leave_request, status: drafting, slots: { recipient: 王经理, leave_time: 下周三下午 } } ] }当用户说“继续刚才那封邮件”系统可以恢复之前的邮件任务。8. 企业内部术语歧义办公场景里有大量企业内部术语。比如发给 PM同步给中台走一下合同流程拉一下 Alpha 项目的人给风控那边看一下这些词在不同公司含义不一样。“PM”可能是产品经理也可能是项目经理。“中台”可能是组织、系统、部门也可能是某个群组。“Alpha 项目”可能对应多个文档、群聊、项目空间。所以意图识别要结合企业知识库、组织架构、通讯录、权限系统、历史项目上下文不能只靠通用大模型的常识。四、解决方案1. 上下文感知识别意图识别不能只看当前 query而要把这些信息都纳入上下文当前用户输入历史对话当前页面或文档用户选中的内容当前任务状态可用工具列表用户角色和权限企业内部知识库。例如用户在一封邮件草稿页面说改得正式一点系统应该识别为修改当前邮件草稿的语气而不是泛泛地回答“可以正式语气应该如何写”。2. 分层意图体系不要把所有意图平铺成几十个分类。办公 Agent 更适合做分层意图。例如一级意图 - 邮件 - 日程 - 文档 - 审批 - 通讯录 - 待办 - 知识库 二级意图 - 创建 - 查询 - 修改 - 删除 - 发送 - 总结 - 分享 三级意图 - email.create_draft - email.send - email.modify_tone - calendar.query_availability - calendar.create_event - document.summarize - approval.submit这样做的好处是第一扩展性更好。第二可以按模块维护。第三便于和工具能力对齐。第四模型识别失败时也可以先落到较粗粒度意图再通过追问补齐。3. 槽位抽取和缺失检测识别意图之后还要抽取槽位。以发邮件为例常见槽位包括{ recipient: 王经理, cc: [HR], subject: 请假申请, body: 邮件正文, tone: 正式, leave_time: 下周三下午, send_time: now, attachments: [] }如果关键槽位缺失不要硬执行而是进入澄清流程。比如请问请假时间是哪一天请问王经理是王磊还是王明这封邮件需要现在发送还是先保存为草稿槽位抽取不是一次性完成的而是在多轮对话中逐步补齐。4. Session 状态管理Session 状态是办公 Agent 的核心。它要记录当前任务是什么已经收集了哪些槽位还缺哪些槽位用户刚刚修改了什么当前任务是否可以执行是否已经过确认是否存在暂停任务。一个简化的 Session 可以长这样{ task_id: email_leave_request_001, intent: email.send_leave_request, status: collecting_slots, slots: { recipient: 王经理, cc: [HR], leave_time: 下周三下午, tone: 正式, body: null }, missing_slots: [body], risk_level: high, confirmed: false }这比单轮意图分类可靠得多。5. 任务状态机办公任务最好不要只用一个状态字段而是设计任务状态机。例如邮件任务可以分为初始化 ↓ 识别意图 ↓ 收集槽位 ↓ 生成草稿 ↓ 用户修改 ↓ 待确认 ↓ 执行发送 ↓ 完成其中任何一步都可能被用户打断、修改或取消。比如用户在“待确认”阶段说先别发把语气再委婉一点状态就应该从“待确认”回到“用户修改”重新生成草稿而不是继续发送。6. 工具选择策略工具选择不能只靠意图标签。更好的方式是综合判断用户目标 槽位 上下文 工具能力 权限 风险等级比如“通知王经理”如果上下文是邮件草稿优先邮件如果上下文是会议安排可能创建日程邀请如果用户说“马上告诉他”可能走 IM如果涉及正式审批可能走审批系统或邮件如果对方不在通讯录需要澄清身份。工具选择应该是一个独立模块输入标准化任务表示输出候选工具和调用参数。7. 风险等级和二次确认每个意图或工具都应该有风险等级。例如{ tool: email.send, risk_level: high, need_confirm: true }二次确认要包含关键信息而不是简单问“是否确认”。不好的确认方式是否执行好的确认方式我将向王经理发送一封正式语气的请假邮件内容是申请下周三下午请假并抄送 HR。是否确认发送这样用户才能真正判断有没有问题。8. 主动澄清当信息缺失或存在歧义时系统要主动澄清。澄清问题要具体不要泛泛地问“请补充信息”。比如用户说发给王经理如果通讯录里有多个王经理应该问你指的是王磊经理还是王明经理用户说下周三下午如果任务需要明确请假时间可以问请问是下周三整个下午请假还是从某个具体时间开始主动澄清的目标是减少用户输入成本而不是把问题丢回给用户。9. 规则 小模型 LLM 混合方案工程上不建议所有意图都交给大模型。比较稳的架构是规则层 处理高频、明确、强约束场景 例如“发送”“取消”“删除”“确认”等高风险关键词 小模型层 处理常见意图分类和槽位抽取 优点是速度快、成本低、稳定性好 LLM 层 处理复杂语义、多轮上下文、复合任务拆解、企业术语歧义一个典型流程是用户输入 ↓ 规则预处理 ↓ 上下文拼装 ↓ 小模型做初步意图识别和槽位抽取 ↓ LLM 处理复杂推理和歧义消解 ↓ 任务状态机更新 ↓ 工具选择和风险判断 ↓ 澄清 / 确认 / 执行这样既能保证效果也能控制成本和延迟。五、办公场景案例解析用户连续输入帮我写一封请假邮件下周三下午发给王经理语气正式一点顺便抄送 HR现在发出去系统应该如何处理第一步识别初始意图用户说帮我写一封请假邮件系统识别为{ intent: email.create_draft, task_type: leave_request_email, slots: { recipient: null, leave_time: null, tone: default, cc: [], send_now: false }, status: collecting_slots }此时不能发送只能进入草稿创建或信息收集状态。第二步补全时间槽位用户说下周三下午系统不能把它当成新意图而要结合 Session 判断这是在补充请假时间。更新状态{ leave_time: 下周三下午 }第三步补全收件人用户说发给王经理系统识别为补充 recipient 槽位。如果通讯录中只有一个王经理可以直接填充。如果有多个则需要澄清你指的是产品部王经理还是行政部王经理假设识别到唯一对象状态更新为{ recipient: 王经理 }第四步修改语气用户说语气正式一点系统识别为对当前邮件草稿的修改而不是新任务。更新{ tone: formal }并重新生成或调整邮件正文。第五步补充抄送人用户说顺便抄送 HR系统识别为增加 cc 槽位。{ cc: [HR] }这里也可能需要结合组织架构解析 HR 是个人、部门邮箱还是 HR 群组。第六步识别高风险执行动作用户说现在发出去系统识别为{ intent: email.send, risk_level: high, need_confirm: true }虽然用户已经说“发出去”但发送邮件是高风险操作仍然建议二次确认。系统可以回复我将向王经理发送一封正式语气的请假邮件申请下周三下午请假并抄送 HR。是否确认发送用户确认后再调用邮件发送工具。六、常见追问追问 1为什么不能只用 LLM 做意图识别因为办公 Agent 要稳定、可控、可审计。LLM 擅长理解复杂语义但它也可能出现输出不稳定、槽位遗漏、风险判断不一致的问题。尤其是发送邮件、删除文件、提交审批这类操作不能完全依赖模型自由生成。更合理的是让 LLM 负责理解和推理让规则、状态机、权限系统和风险控制负责约束执行。追问 2意图识别和工具调用有什么区别意图识别回答的是用户想完成什么目标工具调用回答的是用哪个系统、哪个 API、带哪些参数去完成两者不能混在一起。比如用户说“通知王经理”意图是通知工具可能是邮件、IM、日程、审批系统。具体用哪个工具要结合上下文、用户习惯、任务类型和风险等级判断。追问 3如何处理槽位缺失核心原则是低风险可先生成草稿高风险必须补齐关键槽位。比如“写一封请假邮件”可以先生成草稿。但“发一封请假邮件”必须补齐收件人、请假时间、正文内容并经过确认。常见策略是关键槽位缺失 → 主动澄清 非关键槽位缺失 → 使用默认值或生成草稿 高风险操作缺槽 → 禁止执行追问 4如何处理用户中途改需求靠 Session 状态和任务状态机。用户说“语气正式一点”系统要知道这是修改当前邮件草稿。用户说“先别发”状态要从待确认回退到草稿。用户说“继续刚才那个”系统要能恢复被暂停的任务。这类能力不是靠单次 Prompt 解决的而是 Agent 框架层要维护状态。追问 5企业内部术语怎么解决需要接入企业知识库、通讯录、组织架构、项目空间和权限系统。比如“王经理”“HR”“中台”“Alpha 项目”这些词通用模型只能猜企业 Agent 必须查内部数据。如果匹配结果不唯一就主动澄清如果用户没有权限就不能展示或执行相关操作。七、可背诵模板面试时可以这样背办公 Agent 的意图识别核心痛点不在于做一个简单分类器而在于办公任务天然是多轮、模糊、省略、带上下文的。用户经常只说半句话比如“发给王经理”“语气正式一点”“现在发出去”系统要能判断这是新任务、补槽、修改当前任务还是高风险执行动作。我的方案是做上下文感知的分层意图识别。先把意图体系分成邮件、日程、文档、审批等一级意图再细分创建、查询、修改、发送等二级意图。同时做槽位抽取维护 Session 状态和任务状态机把用户多轮补充的信息持续写入当前任务。对于缺失槽位要主动澄清对于发送、删除、提交审批这类高风险操作必须做二次确认。工具调用上我不会把意图和工具做简单一一映射而是根据用户目标、上下文、槽位、权限和风险等级选择工具。工程实现上可以采用规则 小模型 LLM 的混合方案规则处理高风险和强约束场景小模型处理高频意图和槽位LLM 处理复杂语义、多轮上下文和企业内部术语歧义。这样整体会比单纯 Prompt 调大模型更稳定也更适合真实办公场景落地。