办公Agent的“询问-澄清”机制：如何处理模糊需求（如“整理上周客户邮件”）

先讲一个让所有办公Agent集体翻车的场景。

下午3点，产品经理老王在群里@办公Agent："帮我整理一下上周客户反馈的邮件。"

Agent秒回："好的，已为您整理上周所有客户邮件，共47封，汇总如下：[链接]"

老王点开一看：47封邮件，既有客户的吐槽，也有客户的感谢，还有客户的自动回复和退订通知。有的重要，有的完全没用。他想要的其实是：那些需要产品团队跟进的、客户提的具体功能建议 ，按优先级排个序。

他叹了口气："我说的'整理'不是这个意思啊。"

这不是Agent的错，是老王的指令太模糊。也不是老王的错------人在忙的时候，说话就是会省略上下文。

模糊需求是办公场景的常态："整理一下""帮我看看""催一下那件事"------人类之间靠默契和追问来消解模糊，但Agent没有这种默契。

于是，我们给Agent设计了一套 "询问-澄清"机制 。不是让Agent猜，而是让它主动问该问的问题，把模糊变成清晰。

这篇文章，我会用"整理上周客户邮件"这个典型模糊需求做引子，把整套机制掰开揉碎讲给你听。不搞花架子，只说落地时我们踩过的坑和填坑的方法。

一、为什么不能直接执行？拆解"模糊"的四个层次

先拆一下"整理上周客户邮件"这句话到底模糊在哪。

范围模糊："客户"------是所有客户，还是某几个重点客户？"上周"------自然周还是工作日周？含不含周末？
动作模糊："整理"------是简单罗列，还是分类汇总，还是提炼要点？
输出模糊：邮件原文放出来？还是只给摘要？要不要标注优先级？
隐含约束：有些邮件涉及保密信息，老王其实没有权限看所有客户的邮件，但他自己没意识到。

如果Agent直接执行，大概率会翻车。如果每个模糊点都反问用户一遍："你指的是哪些客户？哪些日期范围？整理成什么格式？"用户会被问烦。

所以一个好的"询问-澄清"机制，不是把模糊点全部抛回给用户，而是用最少的问题，把任务拉到可执行的确定状态。

二、三层漏斗：从模糊到清晰，只问三个关键问题

我们的机制设计成一个三层漏斗。每一层过滤一部分不确定性，只把真正需要用户确认的模糊点拿出来问。

第一层：默认值 + 智能假设

很多模糊点其实有"常识默认值"。Agent先尝试用默认值填充，不需要问用户。

"客户" → 默认指"最近3个月有主动发邮件往来的客户"（排除退订、自动回复、系统通知）
"上周" → 默认指"上一个自然周（周一至周日）"，如果是周四说"上周"，则指上一整周；如果是周二说"上周"，很多场景其实想表达"最近7天"，Agent根据说话日期自动调整
"整理" → 默认输出结构为：按主题分类（功能建议/投诉/咨询/其他），每条包含发件人、日期、一句话摘要

有了这些默认值，很多简单指令可以直接执行。比如"整理上周客户邮件"，Agent先用默认值跑一遍，然后反馈给老王：

"我将为你整理上周（4月5日-11日）发件人为客户、非系统自动回复的邮件，按功能建议、投诉、咨询分类输出摘要。是否确认？"

老王可以点"确认"，也可以纠正："不是所有客户，是华北区的客户。"Agent收到纠正后，只调整一个参数，继续执行。

第二层：关键不确定点追问（最多3个）

当默认值不够用时，Agent需要主动问。但问题不能超过3个，否则用户会放弃。

设计原则：优先问那些"一旦错了，后果严重"的点。

对于"整理客户邮件"，严重性排序：

访问权限：老王是否有权查看所有客户邮件？如果越权，后果严重。所以第一问："你需要查看所有客户的邮件，还是仅限你负责的客户？（我检测到你没有全员邮件权限）"
输出用途：如果是为了产品需求评审，需要按功能点归类并标记优先级；如果是为了客户满意度分析，需要统计情绪倾向。所以第二问："这份整理主要用于什么场景？（A.需求评审 / B.投诉跟进 / C.日常汇报）"
时间边界：上周是否包含周末？很多业务只关心工作日。可选第三问："是否只包含工作日（周一至周五）？"

三个问题问完，需求已经从不确定变成可执行了。用户只需要点选或填空，而不是重新说一段长篇大论。

第三层：边做边确认（流式澄清）

有些模糊点无法在开始前一次性澄清，因为用户自己也没想清楚。这时候采用"边做边确认"策略。

Agent先输出一个最小可行结果（比如前5封邮件的整理样例），附上一句话：

"以上是根据默认规则整理的样例。请确认格式和内容是否符合预期？如需要调整（例如增加优先级字段），请告诉我。"

用户看到样例，更容易说出自己想要什么："对，就这个格式，但把优先级从高到低排。"

Agent然后重新生成全量结果。这种方式比一开始问一堆抽象问题更自然。

三、真实代码逻辑：一个"询问-澄清"的有限状态机

下面是我在项目里实际使用的简化状态机逻辑（用伪代码表示）：

复制代码

class ClarifyAgent:
    def __init__(self):
        self.state = "need_clarify"  # 初始状态
        self.slots = {
            "customer_scope": None,
            "date_range": None,
            "output_format": None,
            "purpose": None
        }
        self.defaults = {
            "customer_scope": "all_active_customers",
            "date_range": "last_week_natural",
            "output_format": "category_summary"
        }

    def handle(self, user_input):
        if self.state == "need_clarify":
            # 先用LLM提取已有信息
            extracted = self.extract_slots(user_input)
            self.slots.update(extracted)
            
            # 找出缺失的关键槽位（最多3个）
            missing = self.get_missing_critical_slots()
            if missing:
                self.ask_questions(missing)
                self.state = "waiting_response"
            else:
                self.execute()
                
        elif self.state == "waiting_response":
            # 解析用户的回答，更新slots
            self.update_slots_from_answer(user_input)
            missing = self.get_missing_critical_slots()
            if missing:
                self.ask_questions(missing)
            else:
                self.execute()

实际运行时，对"整理客户邮件"，Agent会：

提取到customer_scope=None（没说明），date_range=上周（有），purpose=None。
调用权限检查：发现老王不是超级管理员，所以customer_scope是关键缺失槽位，问第一个问题。
老王回答"就我负责的客户"，更新slots。
发现purpose仍然缺失，且会影响输出格式，问第二个问题。
老王回答"需求评审"，Agent知道输出应该包含功能点归类和建议优先级。
所有槽位填满，执行。

四、避坑：澄清机制最易翻车的三个地方

坑1：问得太多，用户直接关闭对话框

早期版本我们设计了7个澄清问题：客户范围、日期精度、是否排除系统邮件、输出格式、是否包含附件、是否需要翻译、是否需要统计词频......测试用户反馈："我宁愿自己手动整理。"

教训：把问题分成"必须问"和"可以推后问"两类。必须问的不超过3个。其余用默认值，然后在输出里标注"默认值说明"，用户不满意可以再改。

比如Agent可以输出：

已按默认规则整理。默认说明：①客户排除系统邮箱；②输出为分类摘要。如需调整，请点击[修改参数]。

这样既没有打扰用户，又给了修改入口。

坑2：把模糊需求当成错误，非要用户"说清楚"

有的Agent设计成：遇到模糊就报错"请提供更详细的信息"。这是偷懒。

好的设计应该是分担澄清责任：Agent主动提出几个合理的候选解释，让用户选。例如：

你说的"整理客户邮件"，是指：

按时间顺序罗列所有邮件（简单版）

按主题分类并提炼待办（推荐）

只提取客户提到的问题，去重后汇总

请选择（1/2/3），或描述其他需求。

用户一键选择，比重新组织语言快得多。

坑3：忘记记录澄清结果，下次又问一遍

最让人恼火的是：同一个用户，同一种模糊需求，Agent每次都问一模一样的问题。

我们在每个用户的会话历史里，持久化存储偏好槽位。比如老王第一次选"客户范围=仅限我负责的客户"，这个偏好会保存下来。下次他再说"整理客户邮件"，Agent自动应用这个偏好，不再问，只在执行前提示：

"按你之前的偏好，仅整理你负责的客户的邮件。如需修改，请说'修改范围'。"

这样既保持了澄清能力，又避免了重复询问。

五、一个完整的好例子：从模糊到丝滑

让我们把上面的机制走一遍，看看一个理想的交互长什么样。

老王：帮我整理一下上周客户邮件。
Agent ：好的。我先按默认规则：客户为近3个月有往来的活跃客户，日期为上周一至周日，输出为按主题分类的摘要。

你有权限查看的客户包括：华北区（23家）、华东区（17家）。请问是针对所有客户，还是某一个区域？
老王：华北区。
Agent：收到。最后确认一下：这份整理主要用于什么场景？

A. 产品需求评审

B. 客户投诉跟进

C. 周报素材
老王：A。
Agent ：明白。正在整理华北区客户上周邮件（共47封），将按功能建议、投诉、咨询分类，并提取优先级。预计10秒。

（10秒后）
Agent ：整理完成。共提取有效客户反馈21条，其中高优先级建议5条（涉及批量导出、搜索优化等）。完整报告已发你飞书。是否需要我将高优先级建议单独推送到需求池？
老王：好，推过去吧。
Agent：已创建5个需求草稿，请到需求池确认并补充负责人。

整个过程，老王只做了4次轻量交互（确认默认值、选区域、选场景、最后确认推送），总耗时不到30秒。而他得到的结果，远比一开始那句模糊指令能给的要多。

六、写在最后：好的Agent，懂得"什么时候问、什么时候不问"

"询问-澄清"机制的本质不是对话技巧，而是不确定性管理。

太多Agent犯两种错误：要么不问，直接瞎猜（导致结果废了）；要么问太多，把用户当傻子（导致用户弃用）。

好的Agent应该像一个资深助理：你只说半句话，它就能补全剩下的，补不全的部分，用最少的问题确认。

下次你设计办公Agent时，不妨先问自己三个问题：

这个指令里，哪些模糊点是可以用默认值合理假设的？
如果必须问用户，最少问几个问题就能让任务跑起来？
用户回答后，我能记住他的偏好，下次不问同样的问题吗？

如果你能把这三个问题回答清楚，你的Agent就不会再闹出"整理47封邮件"的笑话了。它会成为团队里那个最懂分寸、最让人省心的电子同事。