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

m0_65481401

267人浏览 · 2026-05-08 22:16:40

m0_65481401 · 2026-05-08 22:16:40 发布

在办公 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 调大模型更稳定，也更适合真实办公场景落地。