最近一个朋友跟我聊到一个很实际的困惑他已经把一个LLM应用做得很顺了问答、摘要、文案生成都没问题但老板下一步要求“让它自己把事干了”比如自动查订单、改物流地址、给客户回邮件。他问我从“会聊天”的LLM到“会干活”的Agent到底差在哪一步这个问题正好对应我今天想整理的这份笔记从LLM到Agent Skill的学习路线与落地经验。这篇笔记不是泛泛的概念介绍而是我带着团队从纯LLM对话走向Agent化改造的完整复盘。里面包括LLM与Agent的本质差异、Agent的三大核心技能、一个可落地的Skill技能包定义流程以及大量真实环境里的踩坑和排查记录。不管你是在做客服机器人、内部效率工具还是想把现有业务接口封装成Agent能力这篇笔记应该都能给你一条相对清晰的路径。1. LLM与Agent Skill的本质差异先搞清楚你在切换什么1.1 LLM的能力边界动嘴很强动手为零我们先用一个最朴素的视角看LLM。它本质上是一个“基于上下文生成下一个Token”的模型训练目标决定了它最擅长的是语言理解和文本生成。你说一段话它给你接一段合情合理的下文。这个东西放到业务里就变成问答、摘要、翻译、情感分析、内容生成都属于“认知型任务”输入输出都是文本。但一旦涉及“动手”LLM立刻露怯。比如让它查一下某个订单号现在走到哪一步了模型不知道订单数据存在哪个数据库里也没有权限去调订单接口。它只能根据训练语料“猜”一个答案而且猜得越流畅风险越大。再比如让它连续操作三步先查库存、再锁库存、最后生成发货单每一步都依赖上一步的真实结果LLM单独在一个对话窗口里完全做不了因为每一步的数据都是外部系统给的不是模型脑子里生成的。这就像一个知识渊博的顾问你问他行业问题他能滔滔不绝但你让他亲自去仓库把货搬出来他连仓库门朝哪开都不知道。LLM的边界就在这里它拥有“知道什么”的能力但不拥有“做什么”的通道也没有“做完之后拿到结果继续判断”的闭环。1.2 Agent Skill到底是什么把模型装进一个可执行的工作流那Agent又是什么一个Agent并不只是“升级版的LLM”而是把LLM作为大脑外面接上工具、记忆、状态管理、决策循环让它能感知环境、做出动作、观察结果、再决定下一步。用大白话说就是给那个“知识渊博的顾问”配上助理、电话、电脑和操作手册让他不光能说还能真去办事。而Agent Skill我倾向于把它理解成“Agent的一项可复用专项能力”。它不是一个抽象概念而是一套具体可执行的东西触发条件、工具清单、状态流转、退出条件、异常处理全部被定义清楚。比如“订单查询技能”“退货处理技能”“日程安排技能”每一个Skill都对应一条独立的任务链路Agent在对话中识别出意图后就把控制权交给对应的Skill去执行。换句话说从LLM到Agent Skill表面上是从一个模型变成一个系统本质上是从“生成文本”迁移到“完成任务”。你关注的焦点也会从Prompt怎么写变成工具怎么定、状态怎么管、错误怎么恢复。这个迁移才是大多数人从LLM走向Agent时最不适应的坎。1.3 技术栈迁移Prompt之外还需要掌握什么我见过不少团队LLM应用做得不错但一上Agent就卡住。原因其实很一致他们还在用“写Prompt的思维”去写Agent。比如把工具说明全塞进System Prompt里指望模型自己按说明去调工具。这种做法在实验环境能跑通一到真实业务就崩因为真实业务有并发、有鉴权、有超时、有数据格式不一致这些都不是靠Prompt能解决的。顺利走向Agent Skill至少需要补上几块新知识。第一块是工具契约设计也就是Function Calling的Schema怎么写参数类型怎么界定描述怎么让模型一次命中。第二块是状态管理一个多步任务进行到一半当前状态存在哪、中间结果怎么存、步骤怎么推进。第三块是控制流逻辑什么时候该循环、什么时候该终止、遇到工具报错要不要重试。第四块是记忆策略短期上下文怎么裁剪长期知识怎么存取哪些历史记录该丢。这几块内容单独拎出来每一项其实都不难但它们组合在一起才构成你从“能用LLM”到“能做Agent Skill”的核心技术栈。后面几节我会把每一项的具体做法和踩坑经验拆开讲。2. Agent三大核心技能拆解工具、记忆、规划2.1 工具调用让模型“动手”的那条通道工具调用是Agent最基础的技能。现在主流做法是Function Calling也叫Tool Use流程非常简单你在请求里带上工具定义列表模型在需要调用工具时不是输出自然语言而是输出一个结构化调用请求包含工具名和参数JSON你的代码收到这个请求后去执行真实函数再把执行结果以一条新的消息塞回给模型模型基于真实结果继续推理。我见过有人图省事让模型直接输出JSON然后自己解析执行。这种方案在工具数量少、参数固定的Demo里能跑但一旦工具多了模型会自己发明参数格式时不时多一个字段少一个字段解析逻辑会越写越恶心。用Function Calling机制参数结构由你在Schema里严格定义模型只需要“选”而不是“造”命中率和稳定性会好很多。工具定义有几个关键点值得记一下。Schema里有几个核心字段name工具名全局唯一、description这个工具是干什么的什么场景下用、parameters参数结构用JSON Schema描述。我刚开始写工具描述时非常随意后来踩坑发现description写得好不好直接决定模型调不调得对。比如订单查询工具如果只写“查询订单”模型在用户问“我的快递到哪了”时不一定能联想到这个工具但你写成“根据订单号查询订单当前状态、物流轨迹、预计送达时间适用于用户询问包裹位置、物流进度、送达时间等场景”命中率立刻上来了。还有一个容易忽略的点参数类型越严格越好。能用字符串枚举就別用开放文本能用数字就别用字符串required字段只把真正必须的放进去否则模型在参数缺失时容易纠结。工具数量也要控制我个人的经验是单次请求里最好不超过十个超过之后模型的选工具准确率会明显下降。2.2 记忆机制短期上下文与长期存储分工Agent的记忆问题是所有实操里最绕不开的。先分清两类记忆短期记忆是当前任务上下文就是当前这轮对话里模型能看到的消息列表长期记忆是跨越会话存下来的知识比如用户偏好、历史订单、之前任务的结果。短期记忆的痛点是上下文窗口有上限一旦多轮对话加上工具调用历史很容易爆窗。长期记忆的痛点则是存什么、怎么存、什么时候该读出来。我团队现在的短期记忆方案是三段式固定System指令 最近N轮对话原文 一轮历史摘要。中间工具调用产生的中间结果不完整保留而是把它“清洗”成摘要再放回上下文。举个例子工具返回了一个几千字的订单详情我不会把原文塞给模型而是先用一个小模型做抽取提取“订单状态、金额、物流节点、预计时间”只把这几个字段拼成摘要放回去。这样既保留关键事实又大幅度省Token模型也不会被无关信息干扰。长期记忆我们用的是“按任务存”的策略不是一股脑把对话全存向量库。每个任务完成后只把结构性结论写进存储系统比如“用户偏好电子发票”“这个订单已安排退款”。每次新会话启动时按用户身份和当前意图做一次检索把命中的历史结论拼进上下文。要注意的是中间过程的错误结果千万别写进长期记忆我见过Agent把一次查询失败误记成“订单不存在”导致后续所有对话都在错误前提上推理非常难排查。2.3 规划能力把任务拆成可执行的步骤第三项核心技能是规划。现在主流范式还是ReAct推理Reason→ 行动Act→ 观察Observe→ 再推理。模型先思考当前情况需要做什么调用一个工具拿到结果再基于结果判断下一步。但落到真实业务里我强烈不建议把整条流程全部交给模型自由发挥而是应该“关键路径用代码锁定小步决策交给模型”。什么叫关键路径用代码锁定举个实际例子退款流程里有明确的步骤顺序先校验订单状态再计算退款金额再发起退款最后记录结果。这些步骤之间的顺序、依赖关系、哪些状态能走退款是业务规则应该用状态机在代码里写死而不是靠模型理解。模型在其中负责的是“判定用户意图”和“从工具返回中提取关键信息”比如用户说“我不想要了”模型判定为退款意图然后把订单号提取出来接下来每一步走什么由状态机控制。没有这个约束模型在自由规划时会出现很多让人哭笑不得的情况明明上一步说订单已关闭它还会继续调用退款接口用户只是问退款规则它直接把退款申请发出去任务做到一半突然开始长篇大论解释流程就是不执行下一步。用状态机把路径固定下来之后这些问题的出现频率会直线下降。所以我的结论是Agent的规划能力不应该是“让模型想干嘛就干嘛”而是“在系统搭建好的轨道上让模型做他最擅长的判断”。3. Agent Skill的落地实操从设计到上线全流程3.1 先别急着上框架从最小循环开始我见过不少初学者上来就直接选一套重量级Agent编排框架又是知识库又是多Agent协调结果写了两周连一个完整任务都跑不通。我的建议是第一版用最朴素的方式手写一个最小循环代码量不超过一百行把链路跑通再说。最小循环的核心逻辑其实就三步。第一步把用户输入和工具定义发给模型看看模型返回的是普通文本还是函数调用。第二步如果是函数调用你的代码负责执行对应工具把结果转成一条新的消息拼回消息列表。第三步再发给模型循环直到模型不再触发工具调用或达到步骤上限。这个循环写清楚之后你已经拥有了一个可以执行多步任务的Agent雏形。我在团队里把这个最小循环写在了一个只有几十行的脚本里里面包含了一个“查询订单”演示技能。跑通之后再逐渐叠加上下文压缩、异常重试、任务状态管理。这个顺序很重要先能干活再谈干得漂亮。3.2 技能包的标准结构一份可直接抄的配置清单当你要把一个Skill正式化、产品化的时候就不再是几行脚本了而是需要一个结构清晰的技能包。我常用的Skill定义包含五个部分技能元信息技能名称、版本号、负责人、适用范围触发条件与拒绝条件什么样的话术应该触发本技能什么情况下必须转人工或拒绝执行工具清单本技能依赖哪些工具每个工具有什么权限状态流转图这个技能执行过程中有哪些状态状态之间怎么流转哪些操作被禁止退出条件正常完成、用户取消、超时、异常时的收尾策略我拿一个“订单售后助手”示例出来这份配置可以直接作为参考模板。触发条件是用户表达出“我要退款/换货/催发货/改地址”这四类售后需求拒绝条件是用户问的是售前问题或敏感操作比如修改已签收订单的价格这种情况明确回复不处理并引导到人工。工具清单里包括查询订单、提交售后申请、修改物流地址、查询退款进度四个工具每个工具都限定在只读或可写的一种权限内。状态流转上从“初始化”到“查询订单”查到订单后根据状态分支可售后则进入“发起售后”不可售后则进入“解释原因”。每条分支都有明确的下一步不允许模型任意跳转。这份配置它不是文档后面是要落到代码里的。我建议用结构化形式存储比如YAML或JSON代码直接读取这份配置来初始化状态机和工具列表这样改一个业务流程只需要改配置不用动主逻辑。3.3 关键实现细节状态管理、工具契约与反馈回路配置落到代码后有几个实现细节值得单独讲讲。先说状态管理我用的是最简单直接的方式枚举当前状态加上一张“状态转移表”表里定义了每个状态下允许触发哪些动作以及动作完成后转移到哪个状态。比如“查询订单”状态下只允许调用订单查询工具不允许调用提交售后工具查完订单进入“售后判断”状态这时候模型可以根据订单状态选择下一步。这套约束把模型的自由度收敛在业务允许的范围内。再说工具契约我建议每个工具尽量做成“幂等”的同样的参数执行两次结果一致不会产生重复副作用。尤其是提交申请、发消息这类操作必须带上请求ID做去重否则模型在重试时可能重复提交。我们在实际测试里遇到过模型因为网络超时误判失败自动重发了一次结果用户收到两条一模一样的短信。处理后端幂等性是Agent工程里最容易被忽视但最重要的功课。最后是反馈回路的设计。工具执行不一定每次都成功失败信息返回给模型时不能只写“调用失败”而是要给出尽量多的结构化信息失败原因、是否可重试、建议下一步怎么做。比如订单查询工具返回“订单不存在”模型收到后应该直接告诉用户“查不到这个订单”而不是继续尝试查询多次如果返回“接口超时可重试”模型可以自动重试一次。把这些规则预置在工具返回里比在Prompt里写一堆“如果遇到失败请如何处理”有效得多因为模型是基于当前的真实反馈做判断而不是基于你的泛泛指示。4. 实测问题排查与调优经验4.1 模型不调用工具或调错工具这是我们在测试里遇到最多的问题而且原因多种多样。最常见的是工具描述太笼统模型压根不知道这个工具能解决当前问题。我排查第一步永远是重新读工具描述把描述念给自己听看“当用户说了什么话时应该用这个工具”讲清楚了没有。第二个常见原因是System Prompt里的引导压过了工具调用意图。比如你在System里反复强调“你是一个友善的客服要耐心解答”模型就会倾向于直接回答而不是调用工具因为它觉得“回答”才是它的主要职责。解决办法是把“优先调用工具确认事实再基于工具结果回答”写进System的第一条并且把工具优先级提上来。调错工具的情况多半是工具之间的边界不清晰。比如有“查询订单”和“查询退款记录”两个工具如果描述里都带有“查询订单”字眼模型很容易搞混。这时需要把每个工具适用的用户问法写得更具象并且在工具名上就区分开比如改成query_sales_order和query_refund_record尽量不要用太泛的词。4.2 上下文爆炸与记忆污染Agent跑起来之后最让人头疼的就是上下文爆炸。一次多步任务每调一次工具工具返回加上模型的思考过程都要塞回上下文几轮下来就几千Token了。而这其中真正对最终结果有用的往往只有一小部分。我们的处理方案是给工具返回做一层“提炼层”不让原始返回直接进入模型上下文。工具执行完先经过一个精简函数把原始返回结构切成几个关键字段太长的字段做截断或摘要。比如物流详情有几十条轨迹就只保留最近三条加一个“已签收/运输中”的状态字段。这么做之后同样流程的Token消耗能降到原来的三分之一。记忆污染则是另外一个坑。有一次Agent在处理一个订单时连续查询了三次第二次查询因为临时网络问题返回了一个空结果模型把“空结果”记成了“订单不存在”后续所有回复都基于这个错误前提。排查了很久才发现问题根源是中间结果被写进了长期记忆。从那以后我们定了一条死规矩只有任务最终结论可以写长期记忆中间步骤的任何观察结果只存在于当前上下文任务结束即清空。4.3 循环震荡、任务戛然而止循环震荡指的是模型反复调用同一个工具或者几个工具之间来回切换永远不输出最终结果。我们跟踪过一例用户问“为什么我的退款还没到账”模型第一次查了退款状态显示“处理中”它不太放心又查了一次订单状态然后回到退款状态又查了一遍订单来回折腾了六轮就是不给用户一个明确答复。这个问题的根源在于缺少退出条件。模型不知道“什么时候算任务完成”就会觉得信息不够一直查下去。给每个Skill设置步骤上限是最简单有效的办法比如最多执行八步必须给出结论。更精细一点的做法是设置“状态机终止态”只要进入了“已答复用户”这个状态无论模型后续还想干什么系统都强制结束循环把控制权交还给用户。反过来的问题是任务戛然而止模型查到一半突然开始输出总结好像任务已经完成了但实际工具还有一步没做完。这个通常是因为模型发现当前上下文里的信息已经够回应用户了就不会再继续往下执行。解决办法是让工具返回里带上“后续可操作项”的提示逼着模型走完整个流程。比如退款提交工具返回时带上“退款成功后需要向用户发送通知”模型看到这个提示就会继续执行发送通知那一步。4.4 延迟和成本一次任务烧掉多少次模型调用Agent的延迟和成本比纯LLM问答高一个量级。一个简单的单步查询一次模型调用就能完成但一个完整的多步任务比如处理一个售后请求我们统计过平均要调用8到12次模型接口中间还有大量Token用于传工具结果和思考过程。如果在上面再叠加重试和循环震荡成本会进一步失控。控制成本我们用了两招。第一招是“模型分级”大部分单步工具调用用响应更快、成本更低的轻量模型就够只有涉及复杂规划和多步推理时才切到能力更强的大模型。第二招是“缓存层”对于用户经常查询的订单状态、物流信息这类数据做短时间缓存同一个用户短时间内重复查询直接复用缓存结果不再调用模型和业务接口。这两招叠加之后整体成本大概降了一半响应时间也从原来的几秒降到一秒左右。延迟高的另一个原因是串行调用太多每一步都要等上一步模型返回。如果某些工具之间没有依赖关系可以改成并行调用。比如用户同时问订单状态和账户余额这两个查询互不影响就可以在一次循环里让模型同时触发两个工具再把两个结果一起返回给模型。多数Agent框架已经支持这种并行工具调用实测下来对整体响应提速很明显。我在实际项目里还有一个感受Agent Skill的调试难度比普通接口要高一个维度因为同样的用户输入不同时间跑可能得到不同结果模型的输出天然有随机性。为了让自己能稳定复现问题我在调试时会把模型温度调到最低甚至关闭采样确保同样的输入得到同样的输出。定位到问题之后再调回正常参数。这样虽然不能杜绝随机性但至少能让排查过程不那么“看运气”。最后再分享一个我最近形成的工作习惯每做一个Agent Skill我都会单独建一个测试用例集每条用例包含用户原话、预期工具调用序列、预期最终答复。这个测试集的价值不只是回归验证更是在做模型升级或者Prompt调整时能快速告诉我哪些能力退化、哪些行为被破坏。LLM和Agent Skill这条路上没有一劳永逸的方案保持对细节的掌控才是长期稳定运行的基础。