Agent 开发先做意图解析——为什么如此关键？

痛点聚焦：

• 你是否曾因为程序误解了一句话而导致后续操作完全偏离预期？
• 你是否在尝试让 Agent 做“检索+写作”时发现它直接跳到执行而忽略关键上下文？话说回来，
• 你是否担心一次错误就会让整个执行链走错方向？
• 你是否想让 Agent 在高风险动作前自动弹出确认窗口，却发现它总是直接执行？话说回来，

以上四点正是大多数产品经理和开发者在建立复杂 Agent 时最常遇到的痛点。

Agent 接管的是执行链，不是单轮回答

聊天模型面对的是一轮输出。使用者问得不清楚，模型可以回答得保守一点，或者让使用者补充信息。Agent 不一样，它接管的是一条执行链。

使用者输入之后后面可能接着一串运行时角色：

• Router 负责选择任务方法
• Planner 负责拆解执行步骤
• Retriever 负责检索资料或上下文
• Tool Selector 负责选择工具
• Risk Gate 负责判断风险等级
• Confirmation Gate 负责判断是否需要人工确认
• Executor  负责执行动作
• Evaluator

如果入口处把任务读错，这些节点会在错误前提上继续工作——从而导致资源浪费甚至业务中断。其实，

使用者输入通常是一份被压缩过的任务包

大多数人以为一句话足够清晰。但往往包含多个子目标和约束。

• 帮我看下这个线上报错，先别动生产。能复现的话给我修复建议 ⚠️ “先别动生产” 是安全约束，需要被捕捉！⚠️ “能复现” 是检索条件！ ⚠️ “修复建议” 是输出形式！
• 帮我查一下这个客户最近情况，再判断要不要继续推进 ⚠️ “查信息” → 检索 ⚠️ “判断推进” → 商业决策
• 帮我整理这份材料，必要的话生成一版发给领导的摘要 ⚠️ “整理材料” → 写作 ⚠️ “摘要发领导” → 输出格式
• 帮我把这个功能做出来但不要影响现在的登录流程 ⚠️ “实现功能” → 编码 ⚠️ “不影响登录流程” → 风险约束
• 按我们之前那个架构继续写。输出一版可以给同事看的方案 ⚠️ “按之前架构写” → 继续改进模板 ⚠️ “输出给同事” → 文档格式

单标签分类无法捕捉这些细节，会导致程序误判后期全部失效。

意图识别本质上是在选择运行模式

同一句话后面可能出现多种不同的执行方式：

direct answer retrieval-enhanced answer single tool call multi-tool serial parallel multi-source retrieval multi-Agent division of labor clarify first n continue confirm before execute direct reject

每一种模式都对应不同成本与风险。老实说，例如发送邮件需要人工确认，但简单检索答案则不需要。所以，“意图识别 = 模式选择”，不是仅仅“命名”。

常见问题：

• 帮我查这家公司最近融资。再判断适不适合合作，再给一版会议提纲。-> 如果只打 research 或 business_analysis，将漏掉分析与写作；只打 writing 则可能直接生成无事实依据的提纲。

• 一个多维度需求，例如检查代码质量并同时生成报告。-> 单标签难以表达两步联合需求。

• 当 top‑intent 与 second‑intent 区别很小且置信度相近时只保留 top‑intent 会导致误路。

 ⛔ **高风险**：若误判为发送邮件而未确认，将造成外部副作用。⛔ **低风险**：若误判为查询答案而未实际检索，则返回空白/错误答案。⛔ **资源浪费**：错误方法往往耗费计算与调用成本。❗ **痛点提醒**：请勿盲目将所有输入归纳为单个标签，否则您将失去对流程细粒度控制。