这两年如果只让我用一个词来概括AI应用开发的进展，我会选“Agent”。不管你是做RAG的、写代码的、做客服的还是干运维的，最后几乎都会绕回到同一个问题：怎么让大模型不只是“回答”，而是真正“把事办了”。围绕这个目标，业界走了一条从单次调用、到工具增强、再到多角色协作的演进路线——到了2024年之后，这条路上又冒出了Skills和Teams这两个词，很多人一开始是懵的，这跟之前的Plugin、Workflow到底有什么区别？团队真的需要多个Agent吗？这套东西到底该怎么选型？

这篇文章我想站在一个常年做AI应用落地的人的角度，把Agent、Skills、Teams这三层东西拆开来讲：它们各自解决什么问题、彼此之间怎么演进、选型时有哪些坑。我会尽量少聊玄学，多聊判断标准，因为我自己见过太多团队把这三个概念搅在一起，最后做出一个又贵又难调的系统。

1. 演进路线：从一问一答到“能自己规划干活的智能体”

1.1 第一阶段：链式调用，把流程写死

最早的大模型应用很好理解，就是“一问一答”：用户问一句，模型答一句。这种模式很快暴露出问题——它做不了稍微复杂的任务。比如用户说“帮我分析一下这个季度的销售数据，然后出一份报告”，你要是用一问一答的Bot来做，就需要先让用户提供数据，再让他告诉你怎么分析，然后再让他等着你生成报告，体验极其碎片化。

于是出现了第一代工程化的做法：链式调用。工程师预先写好一个固定pipeline，比如第一步调用摘要模型，第二步调用信息抽取模型，第三步调用报告生成模型。每一步做什么、输入从哪来、输出到哪去，全部由代码写死。

我把这个阶段称为“打螺丝阶段”。它的优点非常明显：稳定、可解释、成本可控，模型没有任何自由发挥的余地，每一步都知道自己要干什么。但缺点同样致命：凡是没被剧本覆盖的场景，系统就崩。用户稍微绕了半句话，或者换了一个步骤顺序，整条链就断掉了。所以这个阶段的系统，本质上还是一件“手工定制”的流程工具，而不是智能体。

有趣的是，直到今天，链式调用依然没有被淘汰。它在客服工单、数据清洗、固定报表生成这类场景里依然是首选方案。原因很简单：如果任务边界足够清晰，流程写死反而是一种优势，不会跑偏。问题在于，现实中的需求往往没有这么规整。

1.2 第二阶段：Function Call带来工具增强

真正让“智能体”这个词变得有意义的，是Function Calling机制的成熟。它的核心变化是：让模型判断该调用哪个工具，并且自己生成调用参数。

打个比方，链式调用像一台流水线上的机械臂，每一步都有人设定好；而Function Call模型则像是给操作员配了一工具箱，他看一眼工作内容，自己决定拿起哪把扳手。

这个阶段的系统已经具备了“工具增强”的外形：大模型负责理解意图和决策，外部工具负责执行具体动作。比如查天气、查库存、发消息、执行SQL，都可以做成一个个工具，模型在对话中动态选择。

这里有一个很多人容易忽略的关键点：工具的名字和描述写得越清楚，模型的选择就越准。我见过不少团队心急火燎接了一个工具，描述就草草写了一句“查询接口A”，结果模型在该用的时候不用，不该用的时候乱用。

为什么？因为大模型本质上是在做“语义匹配”，它靠的是工具函数名和描述来判断当前意图是否匹配。你给它一个“查询接口A”的描述，它根本不知道这个接口是查什么的。工具描述的好坏，几乎直接决定了这个阶段的体验上限。

1.3 第三阶段：Agent闭环，感知、决策、执行、反思

如果说Function Calling是“模型自己决定调哪个工具”，那么Agent就是在前面加上两条东西：目标拆解和自我纠错。

真正的Agent闭环通常包含四个环节：感知当前状态、决策下一步行动、执行动作工具、根据结果反思是否达成目标。如果没有达成，就调整策略继续执行。这是一个循环，而不是一次性调用。

这个“循环”是最容易被忽视、又最关键的差异。普通Function Calling调用一次工具，拿到结果就还给用户了；Agent则会问自己“这个结果够了吗？离目标还差什么？要不要换个姿势再试一次？”

经典的做法是Plan-Execute-Reflect。模型先根据用户目标拆出几个子任务，然后一个接一个执行，每步执行完都做一次小结，检查方向有没有偏。如果某一步执行失败，模型会尝试修改参数或者换工具重试，而不会像传统程序那样直接抛异常退出。

这才是大家期待中的“智能体”：它不只回答问题，它能自己规划路径、处理中间意外，并且把一件多步骤的事从头到尾跑完。

1.4 辣评：很多团队用的其实是“伪Agent”

我必须实话实说：这两年我见过不少项目，把Function Call和一段漂亮的Prompt拼在一起，就对外宣称自己做了Agent。你仔细去看它的代码，发现根本没有循环，没有反思，没有自我纠错。模型只调用一次工具，拿到结果就输出，剩下的全靠提示词硬撑。

我把这种东西叫作“伪Agent”，它本质上还是增强版问答工具。

判断一个系统是不是真Agent，只看两条：

• 它能不能自己决定“下一步做什么”，而不是每一步都由代码安排；
• 它失败之后有没有“自我修正”的通道，而不是直接宣告失败。

如果没有这两条，哪怕你接再多的工具，它也就是个“工具人”。我并不反对用伪Agent应付简单场景，但你要清楚自己做到哪一步了，别自欺欺人。到这里Agent的形态算是完整了，那么围绕它的工程问题就开始出现：模型擅长做决策，但不擅长让一个“能力”被稳定复用，于是有了Skills。

2. Skills：从“能调用”到“会干活”的工程化封装

2.1 Skill的出发点：可复用的“能力单元”

早期大家管这些外挂能力叫Tool、Plugin或者Action，现在越来越多的人改口叫Skill。名字的变化背后，其实是一个重要的思路转变。Tool关心的是“接口能通”，这个函数能被模型调用就算成功；而Skill关心的是“任务能不能干成”，怎么在真实业务场景里把结果稳定地交付出来。

两者之间差了一步：一个Skill不仅包含“工具函数本身”，还包含什么时候该用、什么时候不该用、参数怎么校验、拿到结果之后怎么后处理，甚至包括出错了该怎么办。

举个例子，单纯的数据库查询可以是一个Tool，它接收SQL、返回表数据。但真正好用的Skill应该是“周报数据查询技能”：它接收“日期范围”和“粒度要求”，自己负责验证日期格式、拼出正确的查询条件、跑完SQL后把数字汇总成一张带百分比变化的统计表。用户（或者模型）不需要关心底层SQL长什么样。

这个封装过程，和写代码时做模块化是一个道理：不是把所有功能堆在一个函数里，而是把“能力”和“使用方式”解耦，让上层调用更简单、更稳定。

2.2 一个合格的Skill该由哪些部分组成

在我自己维护的项目里，一个能被系统稳定复用的Skill通常包含六个组成部分：

• 能力声明：一句话说清楚“这是一个干什么的技能”；
• 触发条件：什么场景下该用、什么场景下不该用；
• 执行逻辑：底层函数、模型调用，或者嵌套的另一个Agent；
• 输入输出契约：建议用JSON Schema定义参数和返回结构；
• 校验环节：输出检查、格式清洗、异常兜底；
• 版本标识：标注这个Skill的业务口径，方便回滚和对比。

前两项往往被忽略，但恰恰是它们决定了模型会不会“在合适的时机选择这个技能”。触发条件不是给程序看的，是给大模型判断用的。没有触发条件的Skill，在模型眼里就是一堆离散的按钮，它根本不知道每个按钮按下去会发生什么。

拿我们做的一个内部数据问答项目来举例。数据库里有一张订单表，最早我们只暴露了一个“SQL执行工具”，让模型自己写SQL查询。结果过了一个月，我们发现一个问题：模型生成的SQL经常不按业务口径走，比如“有效订单”的定义应该排除已取消和已退款的订单，但模型有时候不知道，会把退款订单也算进销售额里。

后来我们做了一次改造，不再让模型写裸SQL，而是把它封装成一个“销售数据查询Skill”。这个Skill在内部校验逻辑里强制加上了“排除已取消和已退款订单”的规则，同时在触发条件里写明白：当用户询问销售额、订单量或者增长率时使用本技能，当用户询问单价明细时则不要使用。改造完之后，错误率明显下降，而且模型的决策负担也小了很多。这个例子想说明一件事：把一个脏逻辑收进内部流程、而不是指望模型每一次都推理正确，才是Skill存在的最根本价值。

2.3 烂Skill长什么样：命名和描述是门学问

我常跟人讲：写Skill描述，要像给实习生写SOP一样，把边界写透。

烂Skill的描述一般是这样的：“调用订单查询接口，传入用户ID，返回订单列表。”这种描述在技术上没错，但模型看完并不知道什么时候该调用它。用户问“我的账单一共多少钱”，它不一定想到要调这个接口，因为它只看到了“订单列表”，没看到“账单汇总”这个语义。

好一点的描述会写成：“当用户需要查询本人历史订单、账单金额或购买记录时使用；输入用户ID，输出订单明细列表；如果用户想退款或者投诉，请勿使用本技能，应转交给售后处理技能。”

你会发现，这部分描述本质上是在帮模型做“意图路由”。大模型是一个匹配器，它在沙里淘金，你得帮它把“什么时候做什么”这个指路牌立清楚。

2.4 Skill的实现不需要花架子

Skill不一定要用复杂框架来实现，它甚至可以只是一个JSON描述加上一个普通函数。我自己在实战中的习惯是：先用最轻量的方式做出来，让模型能调用到、能拿到正确结果，再考虑要不要上重型编排。

真正决定Skill上限的，永远是两件事：输入输出契约够不够严谨，触发条件的语义描述够不够清晰。前者决定了一次调用能不能稳定完成，后者决定了模型会不会在正确的场景里想起它。可惜大多数人把精力全部花在写执行函数上，恰恰把这两件事给忽略了。

到这里，单个Agent的“能力单元”问题解决了。但很快你会发现，只靠一个Agent，就算给它配上再多的Skill，它也会撞上天花板。这个天花板，就是Teams要回答的问题。

3. Teams：多智能体协作到底在解决什么问题

3.1 单Agent的瓶颈，逼着大家走向Teams

单Agent模式最大的问题是什么？并不是它“不够聪明”，而是它“什么都要管”。

我给你举一个典型的例子：如果你让一个Agent同时负责数据分析、代码生成、客户沟通、文件总结，那它的System Prompt很快就会膨胀到几千行。你要在提示词里描述所有业务规则、所有工具用法、所有输出偏好……结果就是模型在每个维度上的表现反而都会下降。

为什么？因为大模型的注意力是有限的，上下文窗口也不是无限的。塞的东西多了，它会忘了重点，推理准确率下降，单次调用的Token成本和延迟同时飙上去。它还容易产生工具冲突——一个Agent手里握了十几个工具，它经常分不清哪个工具才是当前场景的最优解。

更麻烦的是失败恢复。如果一个单体Agent在执行到第五步时挂了，它通常要回到第一步重新开始，因为它的状态是串在一起的。这就导致一个步骤出错，往往等于整轮重来，成本翻倍。在这个背景下，多Agent协作就成了一个自然的选择。

3.2 多智能体协作的三种主流拓扑

多Agent架构听起来高级，但实际落地的时候，绝大多数场景只需要三种拓扑。

星型拓扑：一个中心协调者接收任务，把任务拆解后分发给不同的专业Agent，收集结果后再汇总。这种模式的控制性最强，调试起来比较直观。代价是中心Agent容易成为瓶颈，一旦它决策错了，整个团队就跟着跑偏。但实际来看，这是很多团队起步做Teams的第一步，因为我们至少能搞清楚“谁在听谁的”。

链式拓扑：任务按顺序在Agent之间传递，上一个Agent的输出是下一个Agent的输入。比如一个Agent负责拆需求，第二个Agent写代码，第三个Agent做代码审查。这种拓扑每一步的上下文都很清晰，容易调优；但如果后面的Agent发现前面的产出有问题，它没有反馈通道，整个链条就得推翻重来。

黑板拓扑：也叫共享内存模式，多个Agent通过一块共享记忆区协作，各自往里写信息、从里读信息。它最灵活，能应对高度动态的任务，但也是最难调试的。当一个结论出了问题，你很难追查是哪个Agent写入了错误信息。这种模式一般只适合研究型项目，不太建议生产环境首批尝试。

这里我想说一句大实话：绝大多数业务系统用不到复杂拓扑。先考虑星型，或者链式，已经能覆盖八成需求。不要为了炫技，把架构做得比业务还要复杂。

3.3 让Teams不崩的关键机制，其实是工程细节

在Teams里，真正决定成败的不是每个Agent的提示词写得多么华丽，而是几个工程机制有没有到位。我梳理了一下，至少这四个机制缺一不可。

统一的任务协议：团队里每个Agent之间传输的，不应该是一段“聊天记录”，而是一份结构化的“任务单”。任务单至少包含目标、上下文、约束条件、验收标准。否则两个Agent之间的交接，全靠模型猜，很容易互相误解。

共享记忆与隔离记忆：协作过程里需要一个大家都能读取的“公共工作区”，但每个Agent还需要自己独立的“私密草稿区”。共享记忆避免重复计算，隔离记忆避免私有信息互相干扰。如果你只有一个巨大的公共上下文，最后一定会变成信息污染。

失败语义：多Agent系统最难处理的事情是“任务被踢皮球”。用户的需求传到Agent A，A觉得自己做不了，传给B，B也拿不准，又传回给A。这种循环一旦出现，整个系统就卡死了。必须提前设定兜底机制：谁负责最终输出，谁负责判定任务超出边界，谁负责给用户一个响应而不是干等。

步数和预算控制：多Agent协作的Token消耗是惊人的，一个看起来不起眼的小任务，可能烧掉几百万Token。我见过不少团队在测试阶段还挺happy，一上生产，账单变成了天文数字。所以从一开始就得设计循环上限、Token预算和总成本熔断机制。

3.4 角色别贪多，三个角色是黄金起步

很多团队一上来就设计了八个Agent：产品经理Agent、架构师Agent、程序员Agent、测试Agent、运维Agent、客户Agent，恨不得把所有职场角色都建模一遍。

我的建议是，起步阶段最多三个角色就够：一个负责拆解任务和分配资源的Planner，一个负责执行具体操作的Worker，一个负责审查产出质量的Critic。三个Agent相互制衡，既不会太冗余，又不会太单调。

角色太多的时候，模型与模型之间会互相叠加错误——一个Agent推理失误，会污染下一个Agent的输入。你可以把多Agent团队想象成一条流水线，每增加一个节点，就多一道传播误差的概率。前期追求“分工明确”而不是“人多势众”，后面再按实际需求慢慢加角色。把Teams的关键机制聊清楚了，下一个更现实的问题就来了：我到底该不该上这些架构？这就是技术选型要回答的事。

4. 技术选型之道：什么时候该上Agent、该选Skill还是Teams

4.1 选型之前，先回答四个问题

技术选型，永远不是越先进越好，而是越匹配越好。在决定要不要上Agent、要不要上Teams之前，我建议先回答下面四个问题：

第一，任务边界清晰吗？如果任务边界非常清晰，比如“每天定时生成一份报表”，那老老实实用固定Workflow就好，没有必要上Agent。Agent的价值在于处理不确定性，不在于把确定的事情做得更花哨。

第二，失败成本高吗？如果失败一次会造成重大损失，比如财务对账、医疗建议、身份认证，那不管Agent听起来多酷，你都需要一个人工审核层或规则兜底层。不要指望纯Model输出完全可靠。

第三，是否跨多个知识域？如果任务只依赖一个领域的知识，一套Prompt加几个工具就够了；如果任务要同时处理数据、法律条款、文案、代码，那么要么做超长Prompt，要么用多Agent分工。后者通常更可持续。

第四，是否需要过程可见性？有些应用场景要求系统解释“为什么得出这个结论”，这时候多Agent反而更容易做分步记录，因为每个Agent负责的步骤是清晰的。

你把这四个问题写在纸上，选型方向基本就清晰了一半。

4.2 框架选型：自研编排还是直接用现成方案

聊到技术选型，一个绕不开的话题是：用现成框架，还是自己写编排？

现成编排框架的好处是快速验证、生态成熟。但如果团队只是套了一层壳，而不理解底层机制，一旦遇到问题，你会发现自己面对的是一个黑盒，根本不知道链路的哪一环出了岔子。这类框架的学习曲线也是成本，而且版本升级带来的适配工作量经常被低估。

自研编排的好处是可控性极强，日志、重试、错误边界都能完全捏在自己手里。代价是工程量大，你必须自己处理状态管理、Agent之间的通信协议、任务队列、并发控制等等问题。

我个人的建议是分两步走：第一步，用现成框架做快速原型验证，重点看模型决策的准确性，而不是架构的华丽程度；第二步，在核心业务路径上，逐步把编排逻辑沉淀成自己的服务。用别人的框架探路，用自研的模型管住生产，这个组合在大多数团队里是性价比最高的。

关于框架的选型，不要纠结于“最强”，而要关注四个维度：可控性（出现问题时能不能定位）、可观测性（每一步有没有日志和Trace）、成本（Token和延迟的预期）、生态（遇到问题找不找得到参考案例）。这四个维度的优先级，按你项目的阶段去排。

4.3 演进路线上的“够用就好”原则

我经常打一个比方：Agent架构的选择，有点像个段位晋级。你不能一开始就想拿最高的段位，必须一步一步打上去。

给团队做体检验证的时候，我会把系统分成四个等级：

• L0：固定链式调用，适合流程完全固定的场景；
• L1：增加Function Call，模型动态选择工具；
• L2：有闭环的Agent，模型自主规划并反思；
• L3：多Agent协作，也就是Teams。

每上升一级，系统的灵活性会增加，但排查问题的难度、Token成本、调试成本也会同步上升。所以我的原则是：能用L1解决，就不要上L2；能用L2解决，就不要硬凑L3。

但话又说回来，这并不代表所有人都应该停在低级别。如果业务场景的任务复杂度已经明显超过当前等级的处理能力——比如一个Agent的上下文快被撑爆了，或者单Agent失败率一直在10%以上——那么往上走一级就是顺势而为，不是赶时髦。

4.4 几句不留情面的辣评

说起技术选型，我发现有个特别普遍的现象：很多团队拿着Teams当项目亮点，为了在汇报里多一个“多Agent协作”的title，强行把一个单Agent能解决的任务拆成七个人干。

结果是怎样？效果没有变好，反而变差了。原本一个Agent一次到位的任务，非要让“规划Agent”先拆一遍，再让“执行Agent”做一遍，最后让“审查Agent”审一遍，中间来回通信烧掉大量Token，最终效果却不如一个写得很好的单Agent配上几个扎实的Skill。

多Agent的价值，从来不在“人多热闹”，而在于“分工之后更稳定”。如果分工没有带来稳定性的提升，那这个多Agent架构就是纯负资产。我一直觉得，负责任的技术负责人应该敢于说一句话：“这个场景不需要Teams，单Agent就够了。”敢于说这句话的人，才真正理解Teams。

5. 实战避坑清单：这些雷区我替你趟过了

5.1 Agent最常见的五类翻车现场

到了这一章，我想把实战中看到过的高频翻车现场整理出来，每一个都对应一开始就该埋下的防御设计。

死循环是最常见的。模型调用了一个工具，拿到结果后发现和预期不符，于是它决定再调一次，结果还是不对，再调一次……这种循环如果不加步数上限，就会一直烧Token到崩溃。我见过最夸张的一次，一个Agent在无人值守环境里跑了三千多次调用，账单让人心疼到说不出话。解决办法很简单：核心循环里必须写死最大迭代次数，同时记录每轮调用返回的结果摘要。

上下文爆炸也很典型。很多Agent会把工具的完整输出一股脑塞进上下文，结果几轮循环下来，上下文越来越长，模型越来越“恍神”，处理速度和效果同步下降。应对方案是：对工具输出做摘要压缩，只保留关键字段进入下一轮。

第三个是Skill误调用。没事的时候一切正常，一旦用户发来一句“帮我删掉这个文件夹”，模型如果接到权限过大的操作Skill，可能直接把不可删的东西给删了。治理方法就是我在前面强调过的：写清触发条件，并且对高风险Skill强制加确认闸门。

第四个问题出现在多Agent场景——互相甩锅。用户要一份分析报告，规划Agent拆完任务，执行Agent说“数据不全”，审查Agent说“质量不合格”，结果谁都不负责给用户最终答复。这个问题靠提示词很难根治，必须在任务单里明确“最后一棒是谁”。

第五个是输出不稳定。同一段输入，这次输出的格式和上次完全不一样，业务方拿到手一脸茫然。这种随机性是模型自带属性，你要实在忍不了，就上规则校验和格式化后处理，对模型输出做强制约束。

5.2 排查三板斧：日志回放、回归集、沙箱演练

Agent系统出了问题，靠肉眼盯着屏幕是没有用的，你得有系统性的排查工具。我的日常是三板斧组合：

第一板斧是日志回放。每个Agent的关键决策动作（选了哪个Skill、传了什么参数、拿到什么结果、下一步计划是什么）必须全量记录。出了问题时，你要能像看录像一样，把一次任务从头到尾复现出来。没有这一步，你就永远在盲人摸象。

第二板斧是回归测试集。准备二三十条覆盖典型场景的测试用例，每次改动Prompt、Skill或者Agent角色，都跑一遍回归集，对比前后输出质量。这就像给Agent系统做单元测试，没有它，你根本不知道一次改动到底是变好了还是变坏了。

第三板斧是沙箱演练。对于涉及真实数据操作或者高成本调用的Agent，务必先在隔离环境模拟一次，确认所有外部调用都在安全边界内。管道一旦连到生产库，谨慎点儿永远不吃亏。

5.3 我自己的三条实操心得

最后再分享三条我个人的实操心得。

第一条：写Skill描述，要按“给实习生写SOP”的标准来写。别嫌啰嗦，描述越具体，模型选对工具的概率越高，你要花在调Prompt上的时间就越少。

第二条：让模型先做规划，再执行动作，但一定要给人留干预的手。不要让Agent一次性把一串动作全部自动跑完，中间至少留一个“人审节点”。真正上生产的Agent系统，多多少少都带一点人机混合的味道，纯无人值守在复杂场景里很容易失控。

第三条：无论你用的是哪个框架，都要给自己的系统加“保险丝”：循环次数上限、单次任务Token预算、外部API调用总次数上限、异常兜底回复。这些保险丝看起来很简单，但它们能在最关键的时候拉住系统的缰绳。

Agent、Skills、Teams这三个东西，本质上是一条演进道路上的三段路。Skills解决的是单Agent的“能力稳定复用”，Teams解决的是多Agent的“分工协作”。选型没有标准答案，只有阶段匹配的问题。

我在做了几个项目之后才真正意识到，最大的坑不是选错框架，而是没有判断清楚一个系统现在处于哪个阶段。把L1的任务硬套L3的架构，只会增加排查难度和账单；反过来，该上Agent的时候还在写死流程，又会白白丢掉自动化的空间。不妨拿出当前最难的那个业务场景，对照我上面的等级表做一个“阶段体检”，先判断自己实际处在L几，再决定下一步少踩哪些坑。