做AI Agent开发这几年我越来越觉得“分类”这个词被严重低估了。很多人一看“功能型AI Agent分类”以为是教科书式的概念梳理实际工作中根本用不上。但我的真实体验恰恰相反如果你在动手写第一行Agent代码之前没有先想清楚这个Agent到底属于什么功能类型、应该按什么模式工作后期返工的概率几乎百分之百。这篇是系列第18篇专门把功能型AI Agent的分类这件事掰开揉碎讲清楚包括我踩过的坑、验证过的选型方法以及每种分类背后的技术实现差异。1. 为什么必须先谈“分类”再谈“开发”先讲一个我自己的教训。早先做一个内部工单处理系统我一上来就套用了当时很流行的ReAct模式让大模型自由调用工具处理每一个工单。demo阶段看着很惊艳大模型能自己查知识库、写回复、开工单。但一上真实业务就崩了工单处理流程有明确的合规分支大模型每跑一次走的路径都不一样有的工单直接被模型跳过审核就提交了。最后不得不推翻重做。问题就出在没有提前分类。工单处理本质上是“规则驱动流程型”它需要的是流程引擎加有限分支决策而不是完全开放式的模型自由发挥。如果当时先进行分类判断我根本不会选ReAct方案。功能型AI Agent的分类本质上不是学术研究而是开发前的设计方案选择。分类的核心价值有三个第一选型不同功能类型的Agent对应不同的提示词结构、记忆策略和工具调用方式第二评估你只有知道Agent属于哪个类型才知道该用什么样的指标去衡量它好不好用第三排查系统出问题的时候分类能帮你快速锁定问题层是规划层、工具层还是决策层。需要说明的是我这里说的“功能型Agent”是指那些要解决具体业务任务、跑在生产环境里的Agent不是实验室里研究通用智能的那种。所以分类的维度也完全是实用导向。我常用的分类维度有四个任务粒度、决策机制、交互方式、功能定位。任何一个真实的Agent都可以用这四个维度去刻画而且大概率会同时属于多个类别。这正是分类真正有用的地方——它不是一个标签而是一组设计约束。2. 按任务粒度单体执行型与复合规划型2.1 单任务执行型Agent单任务执行型Agent是指一次只完成一件明确事情的Agent。典型的例子包括文本摘要Agent、敏感词审核Agent、格式转换Agent、翻译Agent。这类Agent的实现通常非常直接一个模型调用加上输入输出校验和失败重试逻辑。很多人觉得这种“一个小功能”不算Agent因为它太简单了。但我恰恰认为单任务执行型是功能型Agent里数量最多、也最容易被做砸的一类。做过生产环境的都知道一个翻译Agent跑在内部系统里用户传上来一个几百MB的文档你怎么切分、怎么保持上下文、怎么处理模型超时这里面坑多得很。虽然任务单步但工程复杂度一点不少。实现这类Agent的关键不在模型而在工程兜底。输入检查要前置格式不对直接拒绝别让模型处理脏数据输出要做结构化校验让模型输出JSON就严格校验字段缺了就重试还要预留降级方案模型服务不可用的时候至少要返回一个明确错误而不是让用户干等。我见过太多团队把精力放在调prompt上结果真正救命的却是这些看起来不性感的工程逻辑。2.2 复合规划型Agent复合规划型Agent面对的是一个大目标需要自己拆解成多个子任务再依次执行。典型场景包括自动生成调研报告、智能排期、故障根因分析。这类Agent才算真正用上了“规划”能力也是目前最容易翻车的类型。实现路线主要有两条。一条是ReAct风格的循环让模型在“思考-行动-观察”之间反复迭代另一条是Plan-and-Execute先让模型生成一份任务清单然后逐个执行。我的使用感受是ReAct灵活但不可控每一步都依赖模型判断token消耗大且容易跑偏Plan-and-Execute前期可控但一旦计划第一条就错了后面全跟着错而且缺乏动态修正能力。所以实际项目里我更倾向两种结合先生成计划把计划交给一个执行器执行过程中如果遇到计划外的情况再回到规划器做局部重置。复合规划型Agent的难点有三个任务拆分粒度、子任务依赖关系、部分失败回滚。任务拆分太粗子任务本身还是一个大问题拆分太细规划开销又过大。子任务之间如果有依赖执行顺序错了整个流程就废了。部分失败回滚更是硬骨头头几个子任务成功了、后面失败了怎么处理中间状态这需要非常严谨的状态设计。注意在任务粒度上我的经验是“能单步不复合”。如果一个任务不需要动态规划就能完成就老老实实用单任务Agent。很多人为了技术炫技硬把简单任务搞成多步规划结果成本和风险都翻倍。对比项单任务执行型复合规划型任务特征目标单一、边界清晰目标开放、需要拆解实现复杂度低工程兜底为主高需要规划与状态管理稳定性高容易测试低路径不确定性大适用场景翻译、审核、格式转换调研、排期、诊断典型成本一次模型调用多次模型调用工具调用3. 按决策机制规则驱动、模型驱动与混合决策3.1 规则驱动型Agent规则驱动型Agent的决策不是模型做的而是由预定义的规则、状态机或工作流引擎控制。它的特点是稳定、可解释、成本低。模型在里面的角色往往是执行某个节点上的具体任务而不是决定下一步做什么。典型场景包括流程审批Agent、定时任务Agent、有明确分支导向的自动化流程。打个比方一个合同归档Agent它的流程可能是“收到合同→检查是否带签章→带签章走归档→不带签章通知补充”这个流程里的分支判断完全可以由规则完成模型只需要在“识别签章位置”这一步出力。这种Agent的优点是出问题好排查每一步都有日志、有明确状态缺点是僵化流程一变就得改代码。如果你发现业务流程三个月一小改、半年一大改那纯规则驱动会让维护者想骂人。合理的做法是把规则做成可配置的甚至用可视化的工作流编辑器去管理。3.2 模型驱动型Agent模型驱动型Agent的决策核心是大模型系统只提供工具集和约束条件具体走哪条路径完全由模型根据上下文判断。这种类型适合任务开放、没有固定流程的场景比如开放域问答、创意生成、复杂问题探索。技术实现上常见的模式有三种。第一种是ReAct模型循环推理决策第二种是反思机制让模型先做一次再自己对输出做批评修正第三种是树状搜索让模型展开多条路径再评估取舍。听起来很像是AI Agent的标准玩法实际落地时要意识到模型驱动的代价是极高的不确定性同一输入两次运行可能走完全不同的路径这对生产系统是很头痛的。线上环境用模型驱动型Agent必须有预算控制、步骤上限和时间限制否则一个失控循环可能让账户余额归零。3.3 混合决策型Agent第三种类型是我个人最推荐在真实业务里用的混合决策型。它的核心思想非常简单——能用规则判定的就不让模型决定规则覆盖不了的场景再让模型兜底。这样做的好处非常明显。第一成本低大部分简单流量走规则只有少数复杂情况才调用模型第二稳定规则分支的行为是可以预先测试的第三可控模型出错时规则层可以作为安全网拦截。举一个我做过的问题分类Agent实例。用户提交一个技术工单系统先做关键词和正则匹配能命中已知问题类型就直接打标签命中不了再交给大模型做语义理解。实测下来这个Agent的准确率比纯模型高因为它天然减少了模型幻觉的机会同时成本降了60%因为大多数工单根本不需要进模型。混合决策的关键在于设计好“交给模型”的触发条件。我的建议是如果规则判定置信度很低或者规则覆盖范围外才调用模型。这个置信度阈值需要在真实数据上反复校准太严格会把本该规则处理的拉去模型成本降不下来太宽松又会让很多模型能处理的简单任务进规则层准确率受影响。一般我会习惯设两个阈值高阈值直接采用规则结果低阈值直接给人工兜底中间地带留给模型。决策机制优点缺点适合场景规则驱动稳定、便宜、可解释僵化、维护成本高流程固定的业务模型驱动灵活、适应开放任务不可控、成本高探索型、开放型任务混合决策平衡成本与灵活需要设计触发逻辑大部分生产环境4. 按交互方式工具调用、知识检索与系统操作4.1 工具调用型Agent工具调用型Agent的核心特征是它能通过函数调用机制去使用外部工具。你给模型一个工具清单每个工具都有名称、描述、参数结构模型在需要时自主选择调用哪个工具、传什么参数。这就是目前大模型平台普遍支持的函数调用机制。这类Agent最常见的应用场景是信息聚合和操作执行。比如一个出行助手Agent它需要同时查天气、查车票、查酒店就可以分别封装成三个工具模型根据用户需求决定调用顺序。实现工具调用型Agent的时候最容易出问题的其实是参数校验。模型给出的参数经常“像模像样但细节错误”前端一个时间参数可能差一天文件名可能多了个空格。所以工具调用层必须做参数强校验不能直接把模型返回的参数透传给外部系统。另外工具的描述要写清楚。很多开发者随便写一句描述模型就无法准确理解工具能力和边界。我的习惯是每个工具描述里说明它能做什么、不能做什么、有哪些限制条件甚至给一两个使用范例。描述写得好工具调用的准确率能明显提升。4.2 知识检索型Agent知识检索型Agent致力于解决一个核心问题让模型回答基于特定知识库而不是凭空编造。实现上就是完整的RAG管线包括文档解析、文本切分、向量化、召回、重排、生成。这类Agent在企业内部特别常见比如制度问答Agent、产品手册客服Agent、技术文档助手。RAG管线的坑集中在中间环节。文档切分粒度不对语义就被切断向量化模型选得不对召回质量直接崩召回条数设得太少上下文不足设得太多又可能把噪声引入生成。我个人的经验是重排这个环节别省。第一轮向量召回可以宽一点召回二三十条然后用重排模型精排取前三到五条效果比单纯提高向量模型分数来得实在。知识检索型Agent还有一个容易忽略的评估维度答对是及格线答不出来才是加分项。很多Agent为了不冷场强行从知识库里拽一堆弱相关内容来编答案。这比直接说“不知道”还要糟糕。所以生产环境的检索Agent我强烈建议加一个“相关性阈值”召回内容得分过低就直接输出“当前知识库中暂无对应内容”同时把这个查询记录下来供人工补充知识。4.3 系统操作型Agent系统操作型Agent不只是调用几个API它实际上是在操作一个业务系统往往带有状态变更。典型场景包括自动化测试Agent、数据迁移Agent、批量状态更新Agent。这类Agent执行的动作是不可逆的所以安全设计是它的第一优先级。我对系统操作型Agent的最低要求是所有操作必须有审计日志所有变更类操作必须有确认步骤所有工具必须有权限边界。也就是说一个Agent可以查询订单不代表它可以修改订单它在测试环境可以删除数据但生产环境的删除工具压根不暴露给模型。操作型Agent还特别依赖“幂等性”设计。因为模型可能因为超时重复调用同一个工具如果这个工具不是幂等的就可能产生重复订单、重复扣费。做这类Agent时最好给关键工具增加幂等键机制同一任务的操作只允许执行一次。这不是锦上添花而是保命用的。4.4 三种交互方式的组合实际产品里三种交互方式往往同时存在。一个成熟的AI助手很可能同时具备工具调用能力查天气、建日程、知识检索能力翻文档找答案、系统操作能力帮你改配置。分类的意义在于搞清楚主从关系。我的建议是确定一个主导交互方式其他作为辅助。主导方式决定了核心架构。如果主导是知识检索那重心就在知识管线的质量如果主导是工具调用那重心就在工具体系的稳定和权限。把主导方式定下来团队的开发重心、测试用例设计、监控指标就都清晰了。5. 按功能定位内容生产、数据分析、流程协同与对话服务5.1 内容生产型Agent内容生产型Agent的输入和输出都是内容。这类Agent不负责决策业务逻辑不操作业务系统它的产物就是文字、代码、图片、音视频。典型应用包括文案生成Agent、代码生成Agent、报告撰写Agent。这类Agent的核心矛盾是“速度与质量”。用大模型直接生成的内容速度快但容易模板化要让内容真正可用必须加入大量后处理。以营销文案为例我的做法是先生成多个候选版本再用一个评审Agent做质量打分最后按分数筛出最佳同时还要加敏感词、品牌词合规校验。内容型Agent的评估方式也很直接主要看生成内容的可用率而不是好不好看。如果10篇里能直接用的只有2篇那这个Agent在业务上没有价值。5.2 数据分析型Agent数据分析型Agent的定位是帮助用户从数据里拿到结论。它的工作模式一般是理解用户的问题、生成查询比如SQL、执行查询、解读结果、输出结论。典型应用场景包括经营日报Agent、数据问答Agent、异常指标归因Agent。这里要区分两种形态。一种是只做“查询生成”模型负责写SQL交给查询引擎执行结果直接给用户另一种是“全链路解读”模型不仅要查询还要结合上下文业务知识做归因分析比如“为什么昨日转化率下降”。后者的技术难度高很多需要融合业务元数据、历史基线数据和知识库。实现数据分析型Agent时我最看重的是查询准确性。这里的一个现实问题是模型生成的SQL经常跑不通或者跑通了但结果偏离问题本意。建议先在测试库上做SQL正确性验证通过后再在生产库执行同时对用户的模糊问题要做澄清比如“这个季度的销售额”到底指的是订单金额还是实收金额不澄清就瞎猜的结果一定不准。5.3 流程协同型Agent流程协同型Agent更像是一个“编排者”它不直接完成所有工作而是把不同的人和系统拉到一个流程里推动事情往前走。典型场景包括项目管理Agent、工单流转Agent、跨部门协作Agent。这类Agent的设计核心是“状态机”。一个流程的每个节点有明确的状态待处理、处理中、已完成、已驳回。Agent的职责是根据当前状态决定下一步动作可能调用模型可能在系统间同步数据可能通知对应负责人。我之前踩过一个大坑就是没有把状态机设计清楚导致一个订单卡在“已支付”和“待审核”两个状态里用户支付了但系统迟迟不推进。后来每次做流程协同型Agent第一件事就是画出状态流转图用代码严格约束每个状态能发生什么动作。流程协同型Agent的评估指标也很特殊主要看“流转有效率”也就是工单在Agent介入后平均处理时长下降了没卡单率降低了没。这类Agent根本不在于聪明不聪明而在于流程治理是否严密。5.4 对话服务型Agent对话服务型Agent是用户感知最强的一类大家平时聊的客服Agent、销售助手、闲聊伴侣都是这一类。它的核心特征是多轮对话、上下文管理、用户意图识别和情感识别。对话服务型Agent的技术重点和前几类不一样。第一多轮状态管理用户可能在第四轮才说出真实需求Agent要能结合前三轮的上下文理解不能每轮都当新对话处理第二上下文长度管理多轮对话累计的token增长很快需要做滑窗式摘要压缩第三兜底策略用户问了一个Agent无法回答的问题时怎么自然过渡而不让对话死掉。我做过一个客服类型的Agent印象最深的教训是“过度承诺”。模型在对话里容易输出“好的我已为您退费”这种话但实际上系统根本没有执行退费。这类问题的解决方案是对话服务型Agent的每一条承诺都必须绑定到具体的工具执行结果上工具没成功对话里就不能主动宣告成功。模型生成回复前要把“是否已执行成功”作为关键信息注入提示词。功能定位输入输出特征核心技术点主要评估指标内容生产型内容到内容多版本生成、评审过滤内容可用率数据分析型问题到结论查询生成、归因分析查询准确率、结论正确率流程协同型状态到动作状态机、流程治理流转有效率、卡单率对话服务型对话到对话多轮记忆、承诺控制任务完成率、用户满意度6. 实操选型一套可落地的分类决策方法前面讲的都是分类维度现在说怎么落地。我把自己的选型过程整理成一套方法每次做新Agent都按这个顺序走一遍。第一步明确任务目标。用一句话说清楚这个Agent要完成什么业务目标写不出来就说明需求本身不清晰。第二步判断任务粒度。这个任务能否在一个步骤内完成如果可以直接走单任务执行型如果不能画一下子任务清单准备做复合规划型。第三步分析决策确定性。问自己任务的每一步是否都有明确规定如果有走规则驱动如果完全没有走模型驱动如果部分明确、部分开放走混合决策。大多数业务场景都落在混合决策上。第四步确定主导交互方式。任务是否需要调用外部工具是否需要访问知识库是否需要修改系统状态按优先级排一排序哪个是核心能力哪个就是主导交互方式。第五步归类功能定位。任务的核心产物是内容、结论、流程推进还是对话体验功能定位决定了你的评估指标和验收标准。第六步评估资源约束。算一下模型调用预算、响应时间要求、权限边界这些制约因素会反过来调整前面的分类决策。我拿一个“合同审查Agent”举例。它的目标一句话是“自动检查合同文本的风险点并输出审查意见”。任务粒度上它需要读合同、抽条款、比对规则库、输出报告是复合任务决策机制上条款识别用模型风险判定有明确的合规规则是混合决策交互方式上它需要检索合同模板库和法规库主导是知识检索加内容生成功能定位上它产出的是审查报告属于内容生产型。经过这一套分类架构就非常清楚了一个单入口接收合同先做文本解析关键条款走检索增强生成从规则库召回匹配规则风险判定部分走规则引擎过滤确定性条款最后模型输出审查意见整个流程有节点回滚机制。这个Agent我实际搭过运行稳定性和可维护性都比直接让模型自由审查好太多。在做这套分类决策的时候要特别注意一点分类不是终点而是沟通工具。架构师、开发者、业务方对齐需求时只要把分类维度和结论摆出来很多潜在的误解在早期就能暴露。比如业务方说要“智能客服”技术方上来就设计了一堆花哨的对话策略但按分类方法一聊才发现业务方真正需要的是工单自动分类加知识库应答压根不需要闲聊能力。这一下就省了三分之一的开发量。7. 常见误区与排查技巧实录做Agent项目久了遇到的典型问题其实高度重复。我整理几个出现频率最高的连同排查思路一起分享。7.1 所有Agent都做成大模型自由发挥这几乎是新手团队的通病。一提到AI Agent就认为必须让大模型主导决策否则就不是Agent。真上了生产成本高、不稳定、难排查然后回过头来骂模型不行。排查思路很简单如果某个环节有固定规则就把它从模型手里拿出来放进规则层。模型只负责那些规则覆盖不到的部分。7.2 忽视工具接口稳定性工具调用型Agent跑得好不好和模型的聪明程度关系没有想象中那么大大部分时间取决于工具本身稳不稳。工具超时、参数格式没对齐、接口返回结构变化任何一个问题都会直接把Agent打挂。排查时要分清楚到底是模型选错了工具还是工具本身出错了。建议给每个工具加独立的日志埋点记录调用时间、入参、出参、错误码这样Agent出错时能快速定位到是哪个环节。7.3 知识库Agent不做效果评估很多人上RAG只顾着把文档灌进去就完事完全不建评测集。等上线了用户反馈答得差又开始逐条调整提示词这属于瞎猫碰死耗子。我的建议是知识库Agent上线前至少准备50到100条真实用户问题作为评测集每条标注参考答案和期望的回答来源。所有对管线或提示词的改动都先跑一遍评测集拿指标说话再上线。7.4 没有超时、重试和熔断机制Agent是有外部依赖的复杂分布式系统模型的响应时间本身就不稳定。现实环境里模型服务可能晚了几秒用户的请求就被前端断开了又或者工具服务临时故障Agent没有重试就直接放弃。排查这类问题一是所有外部调用都要设超时和重试二是关键下游连续失败时要有熔断路子别让故障连续打爆整个流程三是所有Agent入口最好加一层服务质量检测任何一个节点长时间高错误率都要能自动触发降级方案。7.5 权限与安全边界收紧不够系统操作型Agent的权限如果设计不好后果要比普通程序严重得多。因为模型可能被用户的提示词诱导去调用不该调用的工具。这里的原则是用“最小权限”约束Agent模型能看到和调用的工具集在全流程中动态收窄。比如用户问“帮我查一下订单”Agent只需要查询权限那写操作类工具在这个上下文里就不应该出现在工具清单里。动态工具过滤是成本最低、效果最好的安全策略。另外补一个排查技巧Agent类系统的日志记录要比普通系统更详细。因为模型决策的中间过程不可复现所以必须把每一轮的模型输入、输出、工具调用结果、token消耗全部记录在案。出了问题回放日志就能看到模型当时的决策路径快速定位是提示词问题还是状态传递问题。这个习惯在排查复合规划型Agent时尤其重要否则模型跑偏了你连怎么偏的都看不到。8. 实操总结与个人体会我自己做功能型Agent的感受一句话总结就是好的分类胜过好的框架。很多人关心选哪个框架、用哪个模型但真正决定项目成败的是你有没有在动手前想清楚这六个维度——任务粒度、决策机制、交互方式、功能定位、资源约束和评估指标。框架只是工具分类才是方向。另一个体会是分类不是一成不变的。同一个Agent随着业务演化会从单任务变成复合任务从规则驱动变成混合决策。比如最初我只做了一个简单的合同条款识别单步Agent后来业务方要求加上风险归因分析这个Agent就自然演变成了复合规划型。所以分类决策不是一次性的每阶段迭代都要重新过一遍这套分类方法。最后一句话给新入门的朋友别急着写代码先拿一张纸把分类表的四个维度填一遍。填完你就知道该用什么架构、该买什么服务、该找什么资源了。分类这件事花半小时做可能给你省下后面一个月的重构时间。