先讲一个让所有办公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封邮件”的笑话了。它会成为团队里那个最懂分寸、最让人省心的电子同事。
