智能体怎么做意图识别与任务拆解
· 上海临境绘谷信息科技有限公司
上个月，一家做快消的客户给我们看了一段会话记录。
他们在内网智能体里打了这么一句话：帮我对比一下华东和华南上个季度的销量，出一份汇报材料。
六分钟后，智能体交了一份 PPT。三页，图表齐全，排版像模像样。客户把内容打开一看，两个问题：对比的是销售额，不是销量；时间取的是上个月，不是上个季度。
那句话里有四个要素，它弄错一个，自己改窄一个。而整个六分钟里，它一次都没有回头问一句。
客户问我：它是没听懂吗？
我把它的执行过程完整看了一遍，回答是：它听懂了。它的问题是在信息不全的时候，选择了自己补齐，而不是停下来问一句。 这是智能体最典型、也最贵的一种失败。它不报错，它交活。
前面几篇讲过的东西这一篇直接当结论用：模型没有手，它只会一段一段往外吐字；一个能干活儿的智能体得看得见现场、能一轮一轮推、能真的动手、知道什么时候停、知道自己的边界在哪；智能体和模型之间靠的是三条消息的往返，每一轮都要把前面的内容重发一遍。这些都不重复。
这一篇只讲一件事：从用户说的那句话，到一份能执行的工序单，中间发生了什么。
一分钟速览
- 没有哪个组件叫“意图识别”。 现代智能体里没有意图分类器，这件事被拆散在三处：这句话该谁接、这句话里哪些信息是必须的、缺的那部分是猜还是问。
- 让模型听得准的办法不是让它理解得更好，是让它没得选。 把意图写成封闭清单，把要素写成固定字段，它只能在这张小表里挑。
- 能画出来的步骤，别交给模型现想。 有明确规则和固定顺序的部分画在流程画布上，模型只出现在真正需要它判断的节点里。
- 拆解的粒度标准只有一条：这一步的产出能不能被单独检查。 产出只能描述成“它想了一下”的步骤，迟早出问题。
- 上下文是用来想的，制品是用来传的。 长任务跑不动，多数是因为把该落成文件的东西一直抱在上下文里。
- 模釜（AgentSteamer） 是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，支持完整私有化部署，且不绑定特定大模型。
一、先破一个误会：没有一个叫“意图识别”的模块
上一代对话系统里，意图识别是一个实实在在的零件。先训一个分类器，把用户这句话分到“查库存”“开单”“投诉”其中一类，再走那一类对应的流程。这套做法能跑通，因为它简单、可控、便宜。
它的代价也很明白：判定边界是人写死的。用户换一种说法、少说一个字、把两件事揉在一句话里说，它就掉出去了。
大模型这一代，很多项目把那个分类器整个拿掉了。原因不复杂：模型本来就在做理解这件事，你在它前面再挂分类器，等于先把一句人话压成一个标签，再让模型照着标签干活，信息在这一步就丢了。
所以真实的智能体里没有“意图识别”这个模块。它被拆散在三件事里：
- 路由：这句话该由谁来接。
- 抽要素：干这件事，哪些信息是必需的。
- 决定要不要问：缺的那部分，是猜一个、问一句，还是干脆停。
前两件听着像“识别”，第三件才是真正拉开差距的地方。我见过的智能体出问题，绝大多数不是出在听不懂上，是出在第三件上。
那个快消客户的例子里，模型其实抽对了要素。它知道要做对比、知道比什么、知道比哪段时间、知道比哪几个区域。它只是发现“销量”这个词有点含糊，然后自己做了个决定：理解成销售额，顺手把“上个季度”缩成“上个月”。这两个决定它都没有告诉用户。
它的问题不是理解力，是它没把“我不确定”这件事说出来。
> 判断方法：找一次智能体给出结果的会话，把用户原话和它实际做的事对齐看一遍。数一数，用户那句话里有几个信息是必需的，有几个在它执行的过程中从来没被确认过。凡是它没确认又直接用了的，都是它在替你做主。
二、让它听得准的办法，是让它没得选
那怎么让模型“听”得准？我的经验跟直觉是反的：不要指望它理解得更准，要让它没有别的选择。
具体是两个动作。
把意图列成一张封闭的清单
不要写“你是一个专业的业务助手”，要写：你能处理的请求只有下面五类，第一类是查库存，第二类是对比分析，第三类是……五类之外的一律回“这个我处理不了，请找某某”。
为什么这样有效？前面讲过一件事：模型写“看起来合理的回答”的能力，和它做判断的能力是同一套。你给它一个开放问题，它给你一个开放答案；你给它一张多选题的答题卡，它才会在一个小范围里挑。
平台侧的第一刀是在创建应用时切的：应用类型从问答、文档、流程、取数、客服、销售、审核、运维、研究、自定义里选一个。这个选择决定了这个应用接哪一类活，也决定了它该配哪些工具和知识库。把意图的边界定在创建应用的时候，比定在每一轮的提示词里可靠。
把要素写成字段，逼它填
模型的输出格式里有一个选项，可以让这一轮的返回必须是一段结构化内容，字段名是你定好的。上面那个例子里，我一般会把它定成五个字段：
- intent：要做的动作。取值只能是清单里的那几类。
- objects：操作的对象，这里是销量。
- period：时间范围。取值只能是本日、本周、本月、本季度、上季度、自定义。
- scope：范围，这里是华东、华南。
- missing：上面几项里，哪些它没有把握。
最后那个字段是整张表里最值钱的。它逼模型把“我缺什么”说出来，而不是自己补上。
有了这个字段，后面的路由就变得很简单：missing 是空的，继续往下走；missing 里有东西，走条件分支到一个专门问话的节点，把缺的那项问回来再说。
这里有个细节值得单独提：字段的取值范围要写成它猜不动的样子。 period 如果是自由文本，它能给你“上季度”“上一个季度”“Q3”“最近三个月”四种写法，下游的每个判断都得防四种；把可选值列死，它就只有一种。约束写在结构里，比写在提示词的措辞里可靠得多。措辞是软的，结构是硬的。
> 判断方法：把你们智能体上一次的输出调出来，看它的结构化结果里有没有一个专门装“缺失项”的字段。如果没有，说明它是在拿信息不全的输入直接开干，中间没有一道闸。
三、拆解的第一层：能画出来的，别让它现想
意图弄清楚了，接下来才是拆解。
我先把立场摆出来：任务拆解的第一步不是让模型拆，是问你自己，这里面的步骤哪些是确定的。
规则明确、顺序固定的步骤，画在流程图上就行，别让模型每一轮现场想一遍。原因不是它想不好，是它想得“不固定”：同样一句话，今天走三步，明天可能走四步。你没法测它，也没法保证它每次都走对，出了偏差连从哪一步开始错的都说不清。
流程画布能表达的东西比大多数人想的要少，但已经够用：一个起点，按某个值走不同分支，把结果存进变量，调用大模型，检索知识库，把几路结果聚成一份。就这几样。
这样能搭出什么？举一个真实的结构：收到单据，判断单据类型，按类型走各自的规则，把结论汇总，生成回复。整条链路里，只有“判断单据类型”和“生成回复”这两处需要模型，其余都是确定的。确定的步骤不消耗 token，不用等模型吐字，改流程改的是连线，不是提示词。
一句话概括这一层：模型负责它擅长的部分，从一段人话里读出要素、写一段人话回去；确定性的事交给画布。
> 判断方法：把你们现在的流程图打开，数一数有几个节点的判定条件是能写成一条明确规则的。如果超过一半的节点都是“让大模型自由发挥”，那这个流程每次跑出来的结果都不一样，而且没人能解释它为什么不一样。
四、拆解的第二层：画不出来的，拆到哪一步为止
画布画不到的地方还有很多。“帮我看看这几个型号为什么卖得差”这句话，要查几个维度、查哪几张表、要不要看竞品，事先说不清。这部分只能交给模型在运行时自己决定，也就是动态拆解。
动态拆解最容易翻车的地方是粒度，两个方向都会出问题。
拆得太粗：一步做完三件事。出错的时候没法定位是哪一件错的，中间也没地方插人工确认。这类任务最典型的表现是跑很久，最后交回来的东西有一处不对，你只能整段重来。
拆得太细：一步只干一件小事。这时候轮数会爆炸，而轮数就是账单。前面算过那笔账：每一轮都要把前面的全部内容重新递一遍，token 消耗大致按轮数平方往上走。一件本该三轮做完的活拆成十二轮，花费和耗时会差好几倍，出错的机会也跟着涨。
那粒度怎么定？我给客户的标准只有一条：看这一步的产出能不能被单独检查。
- 如果这一步做完，你能拿到一个可以单独看一眼的东西，比如一段结构化结果、一张表、一段结论，这一步就是实的。
- 如果它的产出只能描述成“它想了一些东西”，这一步就是虚的，迟早出状况。
按这条标准拆出来的步骤，通常长这样：查 A 类数据，得到一份固定字段的表；查 B 类数据，字段一样；把两份合起来排序；写结论。每一步都有名字，有明确的输入，有固定的输出形状。
到这个程度，动态拆解才从“它自己看着办”变成一件可控的事。你可能也看出来了，这条标准其实是在把动态拆解一点点推回静态那一层：凡是能被检查的中间产物，都可以固化成一个节点。
> 判断方法：把模型自己拆出来的步骤逐条读一遍，每条问一句，这一步做完我能看到什么。如果答案是“它内部想了一下”，这一步就得重拆。
五、拆完之后，步骤之间传什么
这一节最容易被跳过，但它决定了拆解到底能不能用。
步骤拆开了，上一步的产物怎么交给下一步？很多项目的默认做法是留在上下文里，也就是接上一句。小任务上这没问题，步骤一多就会出三个后果：越往后越贵，因为每一轮都要重发一遍；会被挤掉，上下文满了要丢东西，丢掉的可能正是关键那份；不可检查，你只能看到模型说它拿到了什么。
能用的传递方式其实有三种，按可靠程度排：
1. 存进变量。 上一步输出的结构化结果落到一个变量里，下一步直接引用。它是确定的，可以被检查，也不占上下文。
2. 落成文件。 需要反复读写的内容写进工作目录，哪一步要用哪一步去读。这个目录在一次会话的多个轮次之间是保留的，前一步写进去的文件，后一步打开就能看到。
3. 留在上下文里。 只适合“下一步看一眼就完事”的短内容，比如一句判断结论。
这三者的分工可以概括成一句：上下文是用来想的，制品是用来传的。
很多长任务跑不动，不是模型不够强，是它把该落成文件的东西一直抱在上下文里，抱着抱着就抱不动了。反过来，一个任务如果每一步的中间产物都落了地，它就能跑得很长，中途停下来换个人接手也接得住。
> 判断方法：找一个需要五步以上才能完成的任务，看它的中间产物有没有落成文件。如果从第一步到最后一步所有东西都堆在对话历史里滚，那这个任务能稳定跑通的步骤数是有天花板的，而且这个天花板比你以为的低。
六、活多到一个智能体装不下的时候
前面几节讲的都是“一个智能体”的事。现实里还会撞上另一件事：一个应用要处理的意图越来越多，从五种涨到三十种。
这时候有两个后果会同时出现。系统提示词越写越长，而它每一轮都要被带上，成本和对模型的干扰一起涨；意图清单越长，模型挑错的概率越高。讲工具清单那篇里提过一句，一次递五十个工具让它挑，错选几乎是必然的。
处理办法是按角色分流：把活拆给几个专门的智能体，每个只管一小摊，前面再放一个负责分发的。用户那句话先由分发的那一层判断该给谁，然后交给对应的人去做。
这里的关键是分发那一层要做薄。它只判断该谁接，不判断该怎么干。一旦让分发层也开始理解业务细节，它自己就长成了一个巨大的智能体，前面那些问题原样回来。
分流之后还有一个附带的好处：每个子智能体有自己的提示词、自己的工具、自己的知识库，改其中一个不会牵动另外几个。这在一个人维护十几个场景的时候非常要紧。
> 判断方法：把你们那个智能体负责的事情列出来，如果超过十五到二十项，而且其中明显能按部门或者按业务线分组，就该分了。分组这件事你心里其实已经有答案，只是还没动手。
七、这些事在模釜里落在哪些地方
上面六节讲的是要管住什么。这一段说在模釜（AgentSteamer）里，它们分别对应哪些已经做出来的能力。
关于意图清单和要素抽取。 应用创建时先选类型，问答、文档、流程、取数、客服、销售、审核、运维、研究、自定义里选一个，这是意图分层的第一刀。应用内部的判定逻辑落在工作流上，条件判断节点支持多分支，按上一轮抽出来的字段走不同路径。大模型节点的输出格式可以设成纯文本、json_object 或 json_array 三种，需要它吐字段的时候就选后两种。
关于反问。 反问的话术和兜底话术都放在提示词模板里。模板带变量、可一键试跑、版本自动递增，改的时候不用去翻工作流。系统提示词和用户提示词都在大模型节点上配置。
关于拆解。 编排画布基于拖拽，节点包括开始、结束、条件判断、变量赋值、大模型调用、知识检索、数据聚合。工作流可以导出成 JSON，也可以从 JSON 导入。保存和执行之前有结构校验，会检查开始与结束节点是否齐全、有没有环、有没有孤立节点，一共九条规则。大模型节点在非流式场景下走 deepagents 模式，可以挂技能包和 MCP 工具，在沙箱里执行命令和文件操作。
关于步骤之间传什么。 变量赋值节点负责把上一步的结果落成变量，后面的节点通过模板变量引用它。所有真实动作都在隔离沙箱里完成，每个会话有独立目录，多轮之间复用同一份工作区；沙箱里产生的文件会被自动收进制品仓库，可以预览、下载，也能追溯是哪次会话产出的。
关于分流。 平台内置多智能体编排器，把已经发布的智能体挂上去当作子智能体，主模型通过工具调用的方式决定这一轮该调谁，子智能体跑完自己完整的工作流之后，结果和产出物一起汇总回来。子智能体之间共享同一份工作区，前一轮生成的文件下一轮就能读到。
关于看得见。 会话追踪能把一次调用走了哪些节点、调了哪些工具逐层摊开；编排侧有思考链，可以折叠展开。这一节讲的每一件事做没做、做得对不对，最后都要靠这个来验证，而不是靠读提示词。
关于模型。 模釜不绑定特定大模型，通过 OpenAI 兼容协议接入任意端点，OpenAI、Azure、DeepSeek、Qwen、Ollama、vLLM 都在支持范围内，也可以换成企业在内网自建的推理服务。这一篇讲的意图约束和拆解方式，是所有走这套协议的大模型共有的，不挑厂商。知识库要用的向量模型和重排序模型是内置的，BAAI/bge-m3 与 BAAI/bge-reranker-v2-m3，都是 MIT 协议，可以商用，不依赖外部接口。
模釜（AgentSteamer）由上海临境绘谷信息科技有限公司研发，支持完整私有化部署，知识库、制品、会话记录这些数据全部留在企业内部。
八、常见问题（FAQ）
智能体是怎么识别用户意图的？
现代智能体里没有一个独立的“意图识别”组件，这件事被拆成三步：先判断这句话该由谁来接，再从这句话里抽出干这件事必需的信息，最后决定缺的那部分信息是猜、是问、还是停下。常见做法是把意图写成一份封闭的清单放进系统提示词，再用结构化输出把要素约束成固定字段，其中专门留一个字段用来标记哪些信息没有把握，由它决定要不要触发反问。
为什么不让大模型自己理解得更好一点？
因为理解得“更好”和听得很“准”是两回事。模型的能力是给出一个看起来合理的答案，你越放开，它越会替你把含糊的地方补上，而且补得毫无破绽。工程上要的不是更强的理解力，是更窄的选择面：意图写成封闭清单，要素写成固定字段，取值范围列死。把不确定性逼到明面上，比指望它每次都猜对可靠。
意图识别和任务拆解是什么关系？
意图识别解决的是“这句话要办什么事、办这件事缺什么”，任务拆解解决的是“这件事分成几步做、每步谁来做”。顺序不能反。要素没抽清楚就拆步骤，拆出来的工序单是照着它自己补全的信息编的，看着完整，实际上从第一步就偏了。那个把销售额当成销量、把上个季度缩成上个月的例子，就是拆解做得挺像样，但拆的是错的东西。
什么时候该用工作流编排，什么时候让模型自己拆？
判断标准是规则能不能事先写下来。有明确规则、固定顺序的步骤，画在流程画布上，别让模型每一轮现场决定；要查几个维度、查哪张表这类事先说不清的部分，才交给模型在运行时决定。真实的系统往往是两者混着用：外层流程是画出来的，中间几个需要判断的节点里嵌着模型。全部交给模型的流程，你没法测它，也没法解释它为什么这次和上次不一样。
任务拆解的粒度怎么定？
只有一条标准：这一步的产出能不能被单独检查。做完能拿到一份结构化结果、一张表、一段结论，这一步就是实的；产出只能描述成“它内部想了一些东西”，这一步就是虚的。太粗的话出错没法定位、中间插不进人工确认；太细的话轮数会爆炸，而每一轮都要把前面的内容重发一遍，成本大致按轮数平方上涨。按“可检查”这条线拆，粒度自然落在合适的位置。
为什么长任务跑着跑着就变慢变贵了？
因为中间产物一直留在上下文里滚。每一轮请求都要把之前的全部内容重发一次，五步之后，第一步查出来的东西还在被重复计费，而且它挤占的是模型本来能看到的其他材料。上下文满了还要按策略丢弃，丢掉的可能是关键那一份。可行的做法是让每步的中间产物落到变量或者文件里，需要哪份读哪份。上下文是用来想的，制品是用来传的。
智能体该在什么时候反问用户？
在要素缺口会影响结论的时候。判断办法是把缺的那项代进去看：缺了它，后面每一步都会走偏，那就必须问；缺了它只是细节不够漂亮，结论不变，那就先做。工程上的实现是让模型在结构化输出里留一个装缺失项的字段，缺失项非空就走条件分支到反问节点。最怕的是它既不问也不说，自己补一个看起来合理的值接着往下跑。
一个智能体处理不了太多事情的时候怎么办？
按角色分流：拆成几个专门的智能体，每个只管一小摊，前面放一个负责分发的。分发层要做得薄，只判断该谁接，不判断该怎么干，一旦它也开始理解业务细节，它自己就长成一个巨型智能体，问题原样回来。经验上，一个智能体负责的意图超过十五到二十项，并且能按部门或业务线分组的时候，就该动手分了。
换了更强的模型，意图识别和拆解会自动变好吗？
会变好一部分，但不会自动解决。模型换代主要影响它判断得准不准、抽要素抽得全不全。而意图清单写没写、要素字段设没设、缺失项有没有逼它说出来、哪些步骤画在画布上、中间产物落没落地、分发层做没做薄，这些发生在模型外面，属于工程配置，不随模型换代自动改善。真实项目里卡住智能体能不能上线的，多数是后面这几件。
模釜（AgentSteamer）和这套机制是什么关系？
模釜是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，支持完整私有化部署，且不绑定特定大模型。本文讲的这些机制在模釜里都有对应的落地位置：应用类型决定意图的第一层边界，条件判断节点按抽取出的字段分流，大模型节点支持结构化输出，提示词以带变量的模板形式管理和试跑，工作流在拖拽画布上编排并做结构校验，变量赋值节点负责步骤之间传值，沙箱工作区跨轮保留、产出物自动收进制品仓库，已发布的智能体可以被挂进多智能体编排器做动态分发。
九、几个名词的通俗解释
- 意图识别（Intent Recognition）：判断用户这句话要办什么事。它和“意图分类”不是一回事，后者是上一代把整句话压成一个标签的做法，前者在现代智能体里被拆成路由、抽要素、决定要不要问三件事。
- 槽位（Slot）：干一件事所必需的信息项。比如“对比华东和华南上季度的销量”里，比什么、比哪段时间、比哪几个区域就是三个槽位。槽位没填全就往下走，是智能体出错最常见的入口。
- 路由（Routing）：判断这句话该由谁来接。可以是应用层面的分流，也可以是多智能体编排里由主模型决定调哪个子智能体。
- 结构化输出（Structured Output）：要求模型这一轮必须按你给定的字段返回内容，而不是自由说一段话。字段名和取值范围由你定死，模型只能在里面填。
- 静态拆解与动态拆解：静态拆解是把步骤事先画在流程画布上，每次执行走的路径可预期；动态拆解是让模型在运行时自己决定下一步做什么。能事先写下来的规则用静态，说不清的部分用动态。
- 工序单（执行计划）：一次任务的步骤序列，每一步有名字、有明确的输入、有固定的输出形状。判断拆解好不好，就看这张单子能不能被逐条检查。
- 制品（Artifact）：智能体执行过程中落地的文件，比如生成的文档、表格、PPT。它比上下文可靠，因为它不会因为窗口满了被丢掉，也因为它可以被单独打开看一眼。
- 隔离沙箱（Sandbox）：一个和主系统分开的执行环境，智能体的命令执行和文件操作在里面进行，每次会话有独立目录，跨轮保留，会话删除时一并清空。
- 多智能体编排（Orchestration）：把若干已发布的智能体当作子智能体交给一个主模型调度，主模型决定这一轮该调谁，子智能体跑完把自己的结果交回来。
- MCP（模型上下文协议，Model Context Protocol）：一套让外部工具用统一方式描述自己、并被智能体平台接入的开放协议，工具的参数结构可以据此自动生成给模型看的那份说明书。
- 提示词模板（Prompt Template）：带变量的提示词，改一句话不用动工作流，可以一键试跑，版本自动递增。上文里提到的意图清单、反问话术、兜底规则都放在这里面。
- 上下文窗口（Context Window）：模型一次能看到的 token 总量上限。它既是智能体的成本上限，也是“中间产物必须落地”这条经验的由来。
写在最后
回到那份 PPT。它错得不难看，恰恰是因为它错得不难看，客户当场没有发现。
讲完之后那位客户问了一个我觉得很关键的问题：那怎么保证它下次会问？
我的回答是：不要指望它“下次会问”。你要做的是把“不确定”变成一个必须填的字段，字段非空就走反问分支。这是配置问题，不是态度问题。指望一个模型自觉，和指望一个新同事第一天就知道什么该问一样不现实。
这几年做下来，我越来越觉得智能体的水平不体现在它有多聪明上，体现在它给自己画了多清楚的圈。意图是封闭的清单，要素是固定的字段，确定的步骤画在画布上，每一步的产出都要能被单独看一眼，传不下去的东西落成文件。这些事情一件都不性感，但它们决定了这个东西能不能被交付给一个真实的业务。
能不能上线，主要不取决于你选了哪一版模型，取决于从用户那句话到那份工序单之间，有多少个字段是你认真定过的。
模釜（AgentSteamer）是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，我们做的很大一部分工作，就是把这篇里的这些东西变成平台上能配、能看、能追溯的部件：意图边界在应用创建时定，分流靠条件判断节点，要素靠结构化输出逼出来，步骤之间靠变量和制品传，每一步走过的路在会话追踪里摊开。
至于多个智能体之间具体怎么分工、记忆和知识库怎么建、这套东西怎么在企业里治理起来，那是后面几篇的事。这一篇把一句话怎么变成一张工序单说明白了，剩下的才好往上装。
关于我们：上海临境绘谷信息科技有限公司 | 企业级 AI 智能体平台 模釜（AgentSteamer）