最近这波大模型应用的热度几乎都绕不开一个词Agent。但说实话我在实际项目里看到不少团队做 Agent本质上只是把大模型包了一层壳让它“看起来”能调用工具、能对话但一旦扔进真实业务场景就露馅了——要么遇到没见过的操作就卡死要么把工具参数传得乱七八糟要么一个多步骤任务跑到一半就彻底迷路。问题出在哪我觉得很大程度是“技能”这个层面没做好。这次想聊聊我在 agent-skills 项目上的一些实践和思考关于怎么把 Agent 从“能聊天”打磨成“能干活的”重点围绕技能的分类、拆解、编排和沉淀。1. 为什么 Agent 需要独立的“技能层”而不是一堆 Prompt先说一个我在很多项目里反复踩过的坑一开始为了省事把所有的工具说明、调用逻辑、边界条件全部写进 System Prompt。结果就是 Prompt 变得越来越长Token 消耗越来越大而且模型的表现越来越不稳定。今天能正确调 A 工具明天同一个问题它可能就去调 B 工具了完全不可控。后来我意识到Prompt 只是“说明书”而 Agent 真正需要的是一套可以反复执行、独立维护、可测试的“肌肉记忆体系”这个体系就是技能层。它就是介于大模型和真实工具之间的一层封装把工具调用的参数、上下文、异常处理、前置条件这些细节全部包在里面让模型只需要知道“什么时候用哪个技能”而不需要关心“这个技能内部是怎么实现的”。我一直觉得一个好的 Agent 技能层应该做到三件事把大模型的输出稳定地约束成可执行的指令不要让模型去“自由发挥”工具参数。让技能的复用变成常态同一个技能在不同 Agent 或不同任务之间能即插即用。让技能的调试和迭代不依赖整个系统的重构改一个技能就像换一个插头。而且从实际体验来看技能层做扎实之后Prompt 反而可以做得非常简短。模型只需要做高层的决策选哪个技能、什么顺序执行、结果要不要继续处理。至于“怎么调接口、传什么参数、出错怎么办”全部由技能层去解决。这就像你请了一个助理你只需要告诉他“去把合同打印了”而不需要告诉他“打开 Word、找到文件、点击打印、选择打印机、确认纸张大小”这些步骤。这里也顺带分享一个判断标准如果你的 Agent 的 Prompt 里开始出现大量“如果调用工具失败请重试并检查参数”之类的描述那说明技能层没建好你在让模型替你处理本应由代码解决的问题。2. 从“能对话”到“能干活”技能层要解决的三类核心问题把 Agent 真正推到生产环境后我总结了一下技能层如果不做最常见的无非就是三类问题。第一类是“工具不会用”。模型对工具的理解只停留在 Prompt 描述层面一旦遇到边界情况就不会处理了。比如一个发送邮件的工具模型知道要传收件人、主题、正文但遇到附件大小超限、收件人格式不对、网络超时这种问题就完全不知所措了。这种情况下模型往往会编造一个不存在的成功结果或者反复用同样的错误参数重试体验非常糟糕。第二类是“拆解不动”。复杂任务需要把目标拆成多个子任务然后编排执行顺序。但纯粹靠 Prompt 让模型做拆解经常拆得乱七八糟要么漏掉关键步骤要么把步骤顺序搞反。我见过一个项目让 Agent 帮忙做“市场调研竞品分析报告”它直接先去写报告再去找数据最后发现报告里全是空话因为关键的数据还没查。第三类是“经验留不住”。今天你花了一整天时间调试好某个工具的调用逻辑明天换一个场景、换一个 Agent又要重新调试一遍。项目做得越多这种重复劳动就越让人崩溃而且每个人的处理方式还不一样有人遇到超时习惯重试三次有人习惯直接放弃团队协作的时候很难统一。技能层本质上就是把这三类问题全部收口把工具怎么用封装进技能把复杂任务的拆解和编排交给技能组合把经验沉淀成可复用的技能库。这样一来模型的能力边界反而更清晰了——它只负责决策不负责猜工具怎么用。3. 技能设计的核心粒度原子技能与组合技能在做 agent-skills 项目的时候我首先遇到的问题就是技能的粒度到底怎么定拆得太大技能太笨重复用性差拆得太细组合的时候又麻烦光调度就累死人。我当时把技能分成了两层。第一层叫原子技能也就是最小可执行单元。比如“发邮件”“查天气”“创建日历事件”“调用某个 API 获取数据”“计算两个日期之间的天数”。这类技能的特点是输入输出都非常明确内部逻辑单一不依赖其他技能。原子技能的核心价值就是复用所以设计的时候要尽量保持单一职责。第二层叫组合技能。组合技能就是由多个原子技能按照特定顺序编排出来的流程。比如“每周五下午给团队发周报”这个技能内部其实涉及“查询本周代码提交记录”“读取上周周报模板”“生成周报内容”“发送邮件”四个原子技能。组合技能的核心价值是沉淀经验把常用流程固化下来避免每次都要重新编排。关于粒度我个人的经验是如果你发现一个技能的描述里出现“然后……接着……最后……”这种词那它大概率不是原子技能而是一个组合技能。另外还有一个判断标准就是看这个技能能不能被其他场景复用。如果只能在一个场景里用一次那它就称不上原子技能。举个我实际做过的例子。当时我们做一个客服助手 Agent底层接了订单查询、物流查询、退款处理、商品推荐四个系统。如果按传统做法可能会设计一个巨大的“处理客户问题”技能然后里面全是 if-else。但按照原子技能的思路我们拆成了十多个原子技能比如“查订单状态”“查物流轨迹”“获取退款规则”“创建退款单”“根据关键词荐品”等等。然后针对不同的客服场景组合出“处理退货请求”“催物流”“推荐替代商品”这些组合技能。这样每个原子技能都可以单独测试哪个出问题就修哪个组合技能的调整也完全不用动底层代码。4. 技能注册、上下文传递与工具协议落地实操的关键设计技能分层只是第一步真正落到代码层面有几件细节必须处理好否则技能层会非常难用。技能注册和发现机制。每个技能都需要有元信息包括技能名称、描述、输入参数、输出结构、适用场景、失败处理策略。这个元信息的作用是让大模型能够“看懂”这个技能是干嘛的。我建议技能描述一定要写清楚“什么时候用、什么时候不用”这对模型选择技能的准确率影响非常大。比如“查询物流”这个技能描述里应该写“当用户询问包裹位置、配送进度、预计送达时间时使用”而不是只写“查询物流”。上下文传递机制。Agent 执行多步任务时前一个技能的输出往往是后一个技能的输入。这个传递如果处理不好很容易出现信息丢失。我在项目里是给每个技能加了一个标准化的输出结构无论内部逻辑多复杂输出的一定是一个 JSON 结构包含执行状态、关键数据和自然语言摘要三个字段。这样后面不管是大模型还是代码逻辑都只用解析这个统一结构不需要关心具体技能的内部细节。工具调用协议。技能内部调用外部工具的时候最好统一走一层协议不要直接散落地在技能代码里写 HTTP 请求。我统一封装了一个工具调用器支持 GET、POST、超时设置、重试策略、鉴权方式等把那些重复的逻辑收敛到一起。后面换接口、换服务商只需要改这一层就行技能本身完全不用动。这些细节看起来不起眼但确实是决定技能层好不好用的关键。我见过不少项目技能层设计文档写得漂漂亮亮一落地就崩就是栽在这些细节上。5. 模型在该层如何做决策让 LLM 学会选择和编排技能技能层封装好之后剩下的核心问题就是大模型怎么知道该调用哪个技能、按什么顺序调用这块我测试过几种方案简单分享一下效果和感受。最基础的是单一 Function Calling。也就是把每个原子技能的 JSON Schema 暴露给模型让模型根据用户输入去选择调用哪个函数。这种方案最简单适合任务流程固定、顺序明确的场景。比如“天气查询机器人”用户问天气模型调用天气查询函数拿到结果返回这就够了。但这个方案的问题很明显任务一旦复杂模型会频繁选错函数或者选对了函数但是传参乱七八糟缺乏全局规划能力。进阶一些的是 ReAct 模式的循环推理。模型先思考当前需要什么信息然后调用技能获取再观察结果、继续推理直到完成整个任务。这个方案的优势是灵活能够应对很多意外情况模型可以在执行过程中根据实际结果调整下一步计划。但代价是 Token 开销大、执行时间长而且对模型的推理能力要求比较高小参数模型跑 ReAct 模式会比较吃力。再说一下我目前比较推荐的做法就是“组合技能偏好 局部动态决策”。在技能库里把高频业务场景提前编排成组合技能模型在执行组合技能时不需要逐层规划只需要按既定流程走中间如果遇到分支情况再根据当时的具体输入做局部决策。这种方案相当于把“战略层”和“战术层”分开组合技能负责战略路径模型在战术节点上做判断。用下来稳定性大幅提升Token 消耗也比纯 ReAct 少很多。对于模型决策这一层我的观点很明确能不做的决策就不要让模型做。技能库里已经有的流程直接走流程流程覆盖不到的情况才考虑让模型自由调度原子技能。这样既保留了灵活性又保证了核心任务的成功率。6. 技能的容错、回退与多轮纠错机制真实场景和 Demo 最大的区别就在于真实场景里什么都会出错而且很多错是你根本想不到的。我在做 agent-skills 的过程中感触最深的就是容错机制这件事。技能执行失败之后怎么处理是衡量一个 Agent 是否“能干活”的重要标准。我一般把技能的错误分成两类。一类是确定性错误比如参数缺失、鉴权失败、接口返回 500。这类错误完全可以在技能代码里直接处理比如参数缺失就补默认值鉴权失败就重新拉取令牌重试一次接口 500 就退避重试。另一类是非确定性错误比如用户给了一个非常模糊的指令导致技能选错或者对外部接口返回的数据结构跟预期不一致。这类错误不太好预先写死逻辑需要引入多轮纠错机制。我现在的做法是给每个组合技能内置一个“执行监控器”。每执行一个步骤都会记录当前的状态和结果摘要。如果某一步失败了监控器会先判断错误类型确定性错误直接按预设策略处理非确定性错误再把错误信息反馈给模型让模型重新决策是换一个技能还是换一种参数组合。我做过统计加入这个机制之后多轮任务的整体成功率提升了大概三到四成效果非常明显。还有一个容易忽略的点成功路径也要记录。Agent 执行完一个组合技能后把每一步的执行摘要和关键参数保存下来对后面排查问题、优化 Prompt 非常有帮助。什么叫“有据可查”这就是。没有日志的 Agent 就像没有黑匣子的飞机出事之后全靠猜。7. 从单技能到技能库如何做经验的复用与迭代前面说了那么多样化和编排其实最后拼的是积累。项目做得越久我就越觉得做 Agent 的工作重心会从“写代码”慢慢转变成“维护技能库”。我的技能库目前是这样一个结构基础技能层通用性最高比如 HTTP 请求、时间计算、数据格式化几乎任何 Agent 都能用到。领域技能层针对特定业务场景封装比如电商的订单处理、内容社区的定时发文。场景组合层面向具体任务的组合技能比如“双十一大促客服开场白”“社群每日早报推送”。这三层对应的是不同粒度、不同复用频率的技能沉淀。关于技能的迭代我的经验是一定要以“失败案例”为驱动。每当 Agent 在线上出了一个问题第一件事不是改 Prompt而是复现这个问题分析到底是模型选错了技能、技能内部逻辑有 bug还是上下文传递丢信息了。定位到原因后再决定是优化技能描述、调整技能内逻辑还是新增一个技能把这条路固下来。这种以问题为导向的迭代方式比纯粹靠感觉优化要高效得多。还有一点建议每一个技能都尽量配备一两个典型的测试用例。技能库大了之后改动一个底层技能可能影响几十个组合技能没有测试用例兜底改出问题都不知道是哪儿出的。8. 关于“技能意识”Agent 训练与技能沉淀的未来方向聊到最后说一个我个人的观点。做 agent-skills 做到后面我发现最难的其实不是技术而是“技能意识”——怎么让系统里的人、流程、工具沉淀成可持续进化的资产。目前业内大部分工作还是在把大模型的能力往外延伸让它会调用更多工具、处理更多格式、适应更多场景。但我更关心的恰恰是反方向的问题一次成功的执行过程能不能反向沉淀成一个新技能比如用户在客服 Agent 里问了一个非常冷门的问题Agent 靠拆解多个原子技能成功解决了。这个解决路径其实很有价值完全可以固化成一个新的组合技能以后再遇到类似问题就不用重新推理一遍了。我现在已经在尝试在系统里加入“技能沉淀开关”。每次 Agent 成功执行完一个非标准路径的任务系统会把执行轨迹记录下来经过人工确认后转化成新的技能模板入库存。虽然目前还需要人工把关但我觉得这个方向是对的。未来的 Agent 开发很可能不再是一个人写代码的过程而是一个“使用得越多技能库越强大”的自进化过程。这也是我会继续在 agent-skills 这个方向深挖的原因。技能层把大模型从“聪明但不可靠”推向“可靠且可复制”而技能库则让这种可靠变成一种可以累积、可以传承的组织能力。这个价值不局限于某一家公司或者某一个场景它对所有想把 Agent 真正落地的人都有意义。