最近总有朋友问我同一个问题Agent这个词现在被叫得满天飞到底什么样子的东西才配叫智能体什么样子的只能算一个脚本或者一个聊天机器人恰好在整理功能型AI Agent的分类体系干脆把这一块单独拿出来讲透。这一篇不聊学术定义也不堆名词就讲讲我在实际项目里是怎么给Agent归类的以及每一类在落地时真正要注意什么。先说一个判断功能型分类的价值不在于给你一个标准答案而在于让你在设计阶段就清楚知道——你的Agent主要靠什么能力立足应该在哪个环节投入最多的工程成本。想清楚这个问题后面选模型、定框架、设评测指标都会有方向得多。1. 功能型Agent的分类坐标别按行业分按决策—执行—交付分1.1 为什么按行业分类会误导产品设计很多团队在做Agent规划时习惯性按行业去切金融Agent、医疗Agent、教育Agent、法律Agent。这种分法在商务汇报时听上去很顺但落到产品设计层面几乎没有指导意义。原因很简单——同一行业里的Agent可能干着完全不同的活。拿金融行业举例一个负责给客户做资产配置建议的Agent和一个负责自动整理每日报表的Agent虽然都在金融场景但前者依赖大模型的推理与对话能力后者依赖结构化数据提取和流程调度能力。两者在模型选型、上下文管理、评测方式上几乎没有共同点硬按行业归在一起反而啥都学不到。我自己的习惯是换一套坐标体系按决策复杂度、执行闭环度、交付形态三个维度来对Agent做功能分类。1.2 三个坐标的具体含义决策复杂度指Agent在完成目标时需要在多大程度上进行推理、规划、判断。低复杂度的Agent只要命中规则就行高复杂度的Agent要拆解子任务、评估多种方案、根据中间结果动态调整。执行闭环度指Agent的决策是否能直接触达外部系统并产生实际动作。只输出建议文字、没有落地的Agent闭环度低能直接调API、操作数据库、驱动硬件设备的Agent闭环度高。交付形态指Agent最终产出的是什么——是一段对话、一份报告、一段代码、一组数据可视化还是一个已经执行完毕的业务动作。这三个坐标交叉基本可以把目前能见到的AI Agent归入几大功能类型。接下来我按这几类逐一拆解每一类都会给到特征、核心技术点和落地时的坑。2. 决策规划型Agent多工具协作下的行动指挥官2.1 这类Agent的核心特征决策规划型Agent的目标不是生成内容而是**想清楚接下来该做什么然后驱动工具去做**。它们的典型工作方式是接收一个模糊目标自主拆解成执行计划调用一个或多个外部工具根据执行结果判断是否继续或调整策略。比如我做过一个供应链异常处理Agent它的输入是库存系统的实时告警输出不是解释告警原因的文章而是自动拉起采购申请流程、发送供应商通知、并同步更新ERP里的预计到货时间。整条链路里Agent要做的事不是写文案而是做决策先查库存和再订货点再决定补货量再决定走哪条审批路径。2.2 决定成败的关键技术点这类Agent要跑得稳关键在三个环节。第一是任务分解。目标模糊时Agent要把大目标拆成可执行的子步骤。实操上我常用两步走先让模型产出候选子任务列表再用规则或轻量校验去重、排序而不是让模型直接在一个大Prompt里边想边做。这样每一步都在可控范围内出了问题定位也快。第二是工具选择与参数生成。Agent需要把自然语言意图映射到特定工具并为该工具正确生成参数。这块最容易出问题的不是选错工具而是参数生成时的上下文缺失。比如查订单状态需要订单号模型如果没在历史对话里抓住用户提到的订单号就会瞎填。我的补救办法是在工具调用的Prompt里显式加入对话关键信息抽取环节先把实体和参数抽出来再交给工具层。第三是自我校验。执行完一个工具之后Agent得判断结果是否合理。一个很实用的校验方法是让结果反哺下一步计划比如判断采购建议数量是否超过安全库存上限、判断API返回状态码是否正常。这里不要依赖于模型我觉得没问题要有硬校验兜底。2.3 落地时容易翻车的地方决策规划型Agent最大的坑是把它当作万能胶水。产品经理看到它能调工具就恨不得把搜索、生成、审批、推荐全都塞进去。结果就是调用链过长、延迟爆炸、失败概率指数级上升。我的经验是单次任务的完整决策链条最好控制在四次工具调用以内。超过四步优先考虑拆成多个小Agent或者用工作流引擎硬编码中间态。另外这类Agent对底层模型的要求不低尤其对长期指令跟随能力要求很高。便宜的小模型在单轮工具调用上还行一旦要承担基于多轮中间结果调整策略这种复杂推理几乎必翻车。如果预算有限更聪明的做法是让强模型做规划让弱模型在特定子任务上做执行两者配合。3. 对话交互型Agent把聊得来变成可量化指标3.1 它和决策规划型的本质区别对话交互型Agent的核心能力是维持一个自然、连贯、有目标感的多轮对话。它也可能调工具、查数据但最终交付物通常是一段让人满意的对话过程而不是某个外部系统里的真实动作。换句话说这类Agent的服务结果体现在对话本身。很多人在搭客服Agent的时候期望它既聊得好又能把事办完这就是两种功能类型的混合要求。我的建议是哪怕最后要做混合形态设计阶段也先把它拆成两部分分开做——对话质量归对话模块任务执行归决策模块。混在一起两边指标都会被对方拖累。3.2 状态管理才是这是灵魂第一代对话Agent基本靠识别意图→回复模板撑场面放到今天就明显不够用了。现在的对话交互型Agent至少要管理三类状态用户目标状态用户这轮对话到底想解决什么问题有没有中途换过目标信息完备度状态当前对话收集到的关键槽位时间、地点、订单号、诉求描述是否够用缺哪个就要主动反问哪项情绪与风格状态用户语气是否急躁是否需要切换回复风格有没有出现明显的红线内容需要转人工。这块我最深的体会是别指望模型凭记忆记住这些状态。上下文窗口再大也扛不住几十轮对话的信息衰减。工程上要做到每一轮对话结束后把抽取到的结构化状态写进一个独立的State对象下一轮开始时先读State再让模型生成回复。状态外置才能保证对话再长也不乱。3.3 评测指标别只盯着意图识别准确率对话交互型Agent的评测是我见过最容易被一支指标带偏的领域。团队上车先冲意图识别准确率结果模型在测试集上跑到了97%上了真实环境用户照样骂。原因很简单真实对话里用户表达通常是模糊的、省略的、口语化的测试集里的权衡样本根本覆盖不全。我的建议是至少同时看三组指标任务完成率用户的目标是否闭环达成、对话轮效达成目标用了多少轮越少越好、用户主动中断率用户是不是聊到一半忍不了了直接关窗口。这三件事比单看意图准不准确要靠谱得多。另外提醒一句对话交互型Agent不要过度追求像人。像人不等于好用。在售后、助理这类场景用户要的是快、准、不用重复偶尔来一句像人的俏皮话是加分项但为了像人故意把回复拖慢就是负分项。给Agent设定话术公约时把简洁可靠放在幽默亲切之前会省掉后面很多麻烦。4. 内容生成型Agent从吐出文字到产出作品4.1 与单次生成的本质差异内容生成型Agent是应用最广的一类也是最容易被误判的一类。很多人觉得只要接入大模型能写文案就算内容Agent了但严格说只做输入Prompt→输出完整内容的流程那只是一个应用了大模型的生成工具真正意义上的内容生成型Agent应该表现出多阶段协作、主动修订、质量可控的工作方式。举个例子。之前一个项目要做一个营销活动落地页自动生成Agent它的流程是这样先根据给定的活动目标和受众画像生成页面大纲和文案骨架再调用图片模型生成主视觉素材接着拉取商品库数据填充活动利益点最后对整页内容做一致性检查发现某个优惠信息与商品库不一致就自动回退修改。这整条链路里Agent不是一个写手更像一个内容项目经理。它会调度子模块、检查中间产物、在发现问题时主动返回修改。4.2 落地实操的三个关键细节内容生成型Agent要在工程上落地有几个细节值得重点关注。一是角色拆分。不要用一个Agent包揽创作者、审核者、修改者三个角色。我更习惯把角色放进不同的子Agent里至少要做生成和审核分离。生成Agent的天职是产出审核Agent的职责是挑刺两者标准不同混在一起很容易出现自己写自己觉得挺好的盲区。二是质量守门人。内容型Agent需要预设一套质量检查规则。这套规则不能光靠模型自由发挥要把硬性条件写死比如关键词覆盖、字数范围、违禁词检测、数据一致性比对。在规则判定不通过时要么自动重写要么打回给人类确认。三是输出结构标准化。内容类模块的中间产物尽量用JSON等结构化格式传递不要用大段Markdown文本传来传去。结构化带来的好处是后续流程能精确定位字段比如单独拿出标题做A/B测试、单独拿出卖点词做合规检查而不用让模型反复全文解析。4.3 典型场景与边界提醒内容生成型Agent现在在文案创作、短视频脚本、社媒批量发布、营销海报设计、教学材料生成这些场景里落地很多。它产出的直接价值是效率间接价值是让团队把人力集中到策略和最终审美把关。但有个边界我得说清楚内容型Agent不擅长处理后果严重的对外输出。涉及法务条款、医疗建议、投资观点内容型Agent只能做初稿最终一定要有资质的人签字确认。这不是保守是责任归属问题。Agent生成的文本在法律上找不到主体来担责出事必然回落到运营团队。所以凡是看到全自动对外发布、零人工审核这种需求我一般都会劝一句把自动生成的管线做好但把发布开关留给人。5. 数据分析与流程执行型离业务结果最近的Agent5.1 数据分析型Agent的本质把业务问题翻译成分析管线数据分析型Agent接收的是业务人员一句模糊提问比如这个季度哪个渠道的获客效率在下降产出不是一段描述文字而是一整套可复现的分析过程——生成SQL去查数、执行统计或机器学习模型、输出可视化图表、归纳结论。这类Agent的设计要点有三个。第一NL2SQL要加审计约束。很多团队倒在这一步模型生成的SQL语法没错但查出来的数是错的。常见问题包括表连接条件漏了、时间范围没用参数化、同名字段选错表。我的做法是让Agent查询前先输出查询意图陈述我要查哪个指标、按什么维度切、用什么过滤条件、来自哪张表。有了这个前置声明再让SQL生成模块去写代码错误率会明显下降。第二分析结果要可解释。不少数据分析Agent一上来就丢一堆图表和结论用户根本不知道这个数字怎么算出来的、样本量够不够、有没有做显著性检验。我的建议是强制Agent按固定结构输出分析报告数据来源、口径说明、分析过程、结论建议、局限性声明。哪怕用户急着要看结论也要保留前两者否则出了错没法追溯。第三容忍中度偏差。Agent分析的结论不能说百分百对但业务上能用。比如毛利下降分析Agent能快速定位到华东区某SKU的成本异常上涨这就帮团队节省了一天手动分析的时间。不要追求Agent做因果推断那是统计学家的事Agent做到相关性的业务提示就足够有价值了。5.2 流程执行型Agent把决策翻译成系统内的真实动作流程执行型Agent是所有类别里最强调动作落定的一类。它不负责思考太深层的策略它的核心使命是把已经明确的决策稳健地转化为系统操作。典型场景包括工单自动分派、审批流转、数据回填、跨系统信息同步、定时任务调度。设计这类Agent时我会把重心放在接口的确定性上。大模型的输出天生有概率性而流程执行需要确定性——同一份参数不能这次传这格式、下次传那格式。解决的思路是在模型和外部系统之间加一个中间适配层模型只输出规范化的动作指令适配层负责把指令解析成具体API调用并做好幂等处理。这样就算模型偶尔抽风适配层也能拦截非法操作。幂等这一点特别提醒一下凡是Agent要写入或触发外部系统的动作都要带幂等键。Agent如果调一次采购接口超时了重试一次结果是不是下了两单这是很现实的灾难场景。在动作指令里加一个requestId让下游系统按这个ID去重成本很低但能避免大事故。5.3 混合形态AIRPA怎么搭数据分析型和流程执行型经常结伴出现。比如一个合同审核Agent先做内容分析是不是数据型能力再走OA审批流流程执行能力中间还要翻译不同系统的数据格式。我搭这种混合形态的经验是AI负责判断什么该做RPA或脚本负责把动作做掉。不要指望大模型去逐像素控制界面那是RPA的活儿也不要指望RPA脚本去理解语义那是AI的活儿。两个系统各干各擅长的接口处用消息队列解耦这样的架构既灵活又不脆弱。6. 边界的灰色地带混合型Agent与功能漂移6.1 混合形态的典型组合前面几类看上去界限清晰真到项目里大量Agent是混合形态。常见的组合有这么几组对话决策客服Agent既要把人聊明白又要判断退换货规则内容分析报告生成Agent既要写结论文案又要跑数出图决策执行调度Agent既要判断优先级又要触发真实业务流程内容交互虚拟人物Agent既要在对话里自然说话又要按人设生成有吸引力的表达。组合本身没有问题问题在于很多团队没有意识到自己做的Agent是组合型把两个功能模块塞进同一个Prompt里让大模型全权处理。最后效果就是对话还挺自然但一执行正经任务就歇菜内容写得不错但一涉及状态管理就混乱。正确做法是前面反复强调的按功能域拆分模块模型之间通过结构化数据衔接而不是靠一段Prompt包打天下。6.2 功能漂移Agent会慢慢变形较少有人提但真实存在的现象Agent上线几个月后它的行为会在功能类型上发生漂移。原因有三个。一是底层模型更新。同一个Prompt换了新版本模型输出行为可能从稳妥型变成激进型原本偏向决策规划的表现就会向内容生成偏移。二是调优偏斜。团队收到用户反馈后不断修补Prompt今天加一句解释得更详细明天加一句语气更友好几个月后Agent的文本表现越来越强但原本的决策准确率可能悄悄掉了。三是数据分布变化。用户提问模式变化Agent为了满足新问题逐渐演化出原本不属于它的行为——客服Agent开始承担分析师角色内容Agent开始尝试写代码。应对功能漂移我的做法是给Agent做能力指纹。上线前把核心能力做成固定的回归测试集比如决策准不准、流程执行成功率、生成内容的合规命中率。每半个月跑一次回归哪个维度掉分了就知道漂移发生在哪里及时纠正Prompt或冻结模型版本。6.3 面对模糊边界的务实做法如果你发现自己的Agent卡在两类之间分不清别焦虑这是常态。这时候最重要的不是纠结这到底属于哪一类而是回退到三个最基础的问题这个Agent为用户创造的核心价值是想清楚做啥、说清楚反馈还是直接办成事如果只能优化一个指标优先保哪个出问题时最容易出在决策质量、对话体验、内容质量还是执行稳定性回答完这三个问题功能定位自然就清楚了。7. 功能分类如何落到工程实践选型、评测与迭代7.1 先定功能类型再做架构选型很多团队上来就选框架LangChain、Semantic Kernel、自研编排引擎……选完才发现框架的侧重点和自己的Agent并不匹配。我的建议是先从功能类型推导出刚需能力再倒推选型。比如你的Agent偏向内容生成型那么核心要考虑的是生成质量、多轮修订、人机协同编辑那就应该多花精力在Prompt调优和审核流程上框架只挑轻量的即可如果你的Agent偏流程执行型那框架的编排能力、重试机制、可观测性就比一切都重要如果你的Agent偏对话交互型那对状态管理和多轮跟踪的要求就会卡死一批框架。7.2 各功能类型的评测指标参考我按自己的项目经验整理了一张评测指标速查表供参考功能类型首要指标配套指标最容易忽视的指标决策规划型任务完成率工具调用成功率、平均决策耗时、失败恢复率错误决策的危害等级对话交互型任务完成率对话轮效、用户中断率、意图识别准确率敏感内容转人工率内容生成型交付可用率一次性通过率、返工轮数、风格一致性事实与数据错误率数据分析型分析结论命中率SQL正确率、报告产出时长、局限声明完整度误导性结论率流程执行型动作执行成功率接口调用失败率、重试成功率、幂等命中率静默失败次数这套表不是一个月的死规矩但它能帮你在写评测方案时对齐思路。实际的每个项目还会有专属指标但把上面这些底账打牢不至于方向跑偏。7.3 我在过程中踩过的三个坑第一坑是把评测做成了模型考试——脱离了Agent所在的任务链路单测模型输出。Agent系统里更多错误发生在工具衔接、状态传递、异常分支上这些光测模型根本暴露不出来。要搭评测环境就要把Agent放进完整的工具Mock环境里跑端到端流程。第二坑是过度设计——一上来就做一个包罗万象的大Agent什么都想覆盖。这种项目后期几乎都会卡在改一个模块带崩一片功能的泥潭里。更保险的路线是先做单功能Agent跑通核心场景再逐步扩展边界通过注册机制挂载新能力。第三坑是忽视Agent的退出机制。很多Agent设计时只想着疯狂干活没想清楚什么时候该停、该认怂、该转人工。其实一个Agent能明确判断我搞不定了求助人类比硬扛着做完一个错误结果要靠谱得多。我在方案里通常会给Agent设置置信度阈值和人工接管接口这招在客服和流程场景里非常管用。最后再给一个落地建议分类这件事适合在每个项目启动时做一次15分钟的自我确认——写下我的Agent主要靠什么能力立足、最应该死磕哪个指标、需要哪些支撑模块三句话。等后面遇到方案摇摆的时候翻回来看看这三句话能帮你少走不少弯路。