最近这波大模型应用的热度，几乎都绕不开一个词：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 真正落地的人都有意义。
