企业官网建设流程全解析

从瞎蒙乱猜到先问再分——Agent 决策层的两次进化

今天讲两件事：不懂就问，问了再分

一、一个让我很尴尬的瞬间

事情是这样的。

前几天我在 REPL 里跟 Agent 说：

“帮我弄一下。”

然后 Agent 沉默了 3 秒，说：

“好的，我帮你把工作区的文件都列出来。”

我：？？？

我还没说我要干嘛呢，你“弄”什么啊？

它直接理解为“列文件”了——我也不知道它为什么这么理解，可能因为“弄”在之前的对话里出现过一次，它就默认了同一个意图。

更尴尬的是，它直接开始执行了，然后列了一堆文件出来。我根本没想列文件。

它不问，它猜，它干了，然后错了。

这感觉就像你走进一家餐厅，服务员问都没问直接给你上了一盘菜，然后说“我猜你想吃这个”。

我说的是“随便来个菜”，那你可以帮我推荐。但我说的是“帮我弄一下”——信息远远不够，你应该先问我“弄什么”。

所以今天这个更新，核心解决两个问题：

1. 信息不够时，先问清楚，别瞎猜。（澄清门禁）
2. 信息够了之后，先分类任务类型，再决定怎么做。（任务拆解）

两条一起上，Agent 从“瞎蒙乱撞”变成了“先问清楚，再分类处理”。

二、先解释概念

2.1 什么是“澄清门禁”？

概念解释：澄清门禁就是一道“安检门”——Agent 在进入“执行阶段”之前，必须先检查信息够不够。不够的话，门不开，先追问。

就像你去医院看病，医生不会直接给你开药。他会先问：“哪里不舒服？多久了？有没有过敏史？”信息齐了才开药。

Agent 也一样：

用户话 → 安检门 → 信息够吗？ ↓ 不够 → 追问 ↓ 够了 → 放行 ↓ 进入任务拆解 → 执行

2.2 什么是“结构化任务拆解”？

概念解释：任务拆解就是把用户需求“分门别类”——它是闲聊？是数据预览？是数据导出？还是需要先出方案的复杂任务？

不同的类别，执行方式不一样：

先分好类，再选对方式。这是任务拆解的核心。

三、澄清门禁：不懂就问

3.1 四类场景

澄清门禁用一个简单的状态机，把用户话分成四类：

用户话 → 是闲聊吗？ → 是 → chat（轻路径） → 意图清楚吗？ → 不清楚 → unknown（强制追问） → 缺槽位（文件/条件/列名）吗？ → 缺 → clarify（追问） → 都齐了 → act（放行执行）

3.2 置信度机制

还有一个聪明的设计：置信度阈值。

当 Agent 对用户意图的理解不是 100% 确定时（比如置信度低于 0.55），它会先“复述”一遍自己的理解，然后等你确认，再执行。

用户：“帮我筛一下那个文件。” Agent 会这样回复： “我理解你想对某个文件做筛选操作。请确认： - 文件路径是 `examples/sample_data.xlsx` 吗？（我默认用了最近的） - 筛选条件是什么？ 确认后回复‘继续’，我会立刻执行。”

用户可以纠正：“不是这个文件，是另一个。”

Agent 收到纠正后，更新信息，再等确认。

确认是什么？就是用户说“继续 / 好的 / 可以”——这些词在澄清阶段时，会自动触发执行。

3.3 一个完整的澄清例子

用户：“帮我弄一下。” Agent：“您想让我做什么？比如：分析数据、导出文件、筛选表格、还是其他？” 用户：“筛选一下 POI 数据。” Agent：“好的，请告诉我要筛选哪个文件、筛选条件是什么。” 用户：“筛选 上海_poi.xlsx，地址不为空。” Agent：“收到。请确认：文件是 上海_poi.xlsx，条件是地址列不为空。确认请回复‘继续’。” 用户：“继续。” Agent：[开始执行]

三层确认，层层把关，绝不瞎猜。

四、任务拆解：分完类再动手

信息够了之后，任务拆解接棒。

它的工作是：把用户需求拆成结构化的任务，匹配内置模式，决定怎么执行。

4.1 内置模式有哪些？

4.2 什么是“执行档位”？

这是任务拆解里最重要的一组概念——执行档位：

区别在哪？

• silent：用户说“帮我看看这个文件有多少行”，直接出结果，不用等。
• soft：用户说“把这个文件按城市汇总”，先说一句“准备按城市汇总”，然后执行。
• hard：用户说“帮我全面分析这个数据”，先出方案，用户确认后再执行。

这跟之前讲的 Plan 模式是什么关系？

• hard对应 Plan 模式的“先出方案再执行”（需要用户确认）
• soft对应“简短说一下就执行”（用户没机会纠正，但至少知道在干嘛）
• silent对应“全自动执行”（适合简单可逆的任务）

4.3 选模优先级（可解释）

选模不是黑盒，有明确的优先级：

闲聊 → 澄清 → 需要确认的计划 → 导出清单 → 预览表格 → 导出数据 → 数据变换 → 探索兜底 → 闲聊（回退）

为什么这个顺序？

• 闲聊和澄清最优先，因为它们根本不该进工具环
• 需要确认的计划次优先，因为它需要用户确认，不能轻易跳过
• 然后是各种数据任务，按“从简单到复杂”排列
• 探索兜底处理未命中的情况

这个优先级是可以解释的——每一层的选择都有理由。

4.4 输出什么？

任务拆解会输出一个结构化的结果：

{"mode":"transform","modeReason":"匹配数据配方: 筛选导出","planStyle":"soft","planStyleReason":"涉及导出，先简短告知","steps":[{"step":1,"action":"预览数据","toolHint":"profile_dataset","doneWhen":"获取列信息"},{"step":2,"action":"筛选行","toolHint":"filter_rows","doneWhen":"筛选完成"},{"step":3,"action":"导出 CSV","toolHint":"write_csv","doneWhen":"导出成功"}],"goalSummary":"按城市筛选 POI 数据并导出"}

这个结构会注入上下文构造层，模型看到了就知道：

• 你是transform模式（筛选/汇总）
• 用soft档位（简短告知再执行）
• 步骤有 3 步，每一步用什么工具、怎么算完成

模型不用自己猜了，系统已经告诉它了。

五、完整链路：从用户话到执行

两条合在一起，流程是这样的：

用户话 ↓ ① 澄清门禁 ├── 闲聊 → 不进工具环 ├── 意图不明 → 追问 ├── 缺信息 → 追问 ├── 确认（信息够了）→ 放行 └── 低置信度 → 复述 + 等确认 ↓ ② 任务拆解 ├── 匹配模式：闲聊/澄清/预览/导出/变换/... ├── 确定档位：静默/简短/确认 ├── 生成步骤：每步带工具提示 + 完成标准 └── 注入上下文构造层 ↓ ③ 执行（工具引擎） ├── 任务状态追踪器 跟踪完成度 ├── 观察事实收集器 收集事实 └── 最终回答

用户感知的变化：

• 以前：说了句话，Agent 直接开干，干了错事
• 现在：先问清楚 → 分好类 → 再干活

六、和之前功能的关系

澄清门禁和任务拆解是整个决策流程的“前两层”，之后的所有功能都在它们后面：

澄清门禁 → 任务拆解 → 上下文构造 → 工具引擎 → 任务状态追踪 → 回答

七、验证一下

> /forget > 帮我弄一下

预期：

• 澄清门禁检测到“意图不明” → 强制追问：“您想让我做什么？”
• 不会直接进工具环

> 分析 examples/sample_data.xlsx

预期：

• 澄清门禁：信息够了 → 放行
• 任务拆解：匹配“预览表格” → “静默执行” → 直接执行

> 帮我全面分析这个数据，按城市汇总并导出

预期：

• 澄清门禁：信息够了 → 放行
• 任务拆解：匹配“数据变换” → “简短告知”（或“需要确认”，取决于方案复杂度）
• 先简短告知，再执行

八、以前 vs 现在

以前：

用户：“帮我弄一下” Agent：“好的，列出工作区文件...” [直接执行错误]

现在：

用户：“帮我弄一下” Agent：“您想让我做什么？比如：分析数据、导出文件、筛选表格、还是其他？” [主动追问] 用户：“筛选 POI 数据” Agent：“请告诉我要筛选哪个文件、筛选条件是什么。” [追问细节] 用户：“上海_poi.xlsx，地址不为空” Agent：“收到。请确认：文件 上海_poi.xlsx，条件 地址不为空。回复‘继续’执行。” [复述+等确认] 用户：“继续” Agent：调用筛选工具 → 完成 → 输出结果

多花了三次交互，但做对了一件事。如果让 Agent 猜，它可能猜错，浪费时间更多。