1. 项目概述：从"会聊天"到"会干活"，Agent技能体系的关键一跳
这两年做大模型应用，最明显的一个感受是：模型本身的能力已经足够强了，真正拉开差距的是你怎么让它去干活。单纯靠提示词把大模型包装成一个对话机器人，已经很难解决真实业务里的复杂问题。于是大家都在往同一个方向走——给Agent配上"技能"（Skills），让它能调用工具、查数据库、操作软件、执行多步流程。这个"agent-skills"项目，本质上就是一套教Agent高效掌握和运用技能的解决方案。
我最早产生做这个项目的念头，是因为手头好几个AI应用都卡在了同一个地方：模型回答得挺好，但让它去做事就抓瞎。比如让它去整理一个报表，它知道要整理成什么样子，但不知道去哪里拿数据、怎么处理异常值、怎么把结果写回系统。这就像一个人脑子里有百科全书，但手脚不听使唤，根本干不了活。我们需要的不是另一个聊天机器人，而是一个真正长了手和脚的AI助手，技能体系就是这些手和脚。
这篇内容适合两类人：一类是正在做AI应用开发、想提升Agent实际执行力的开发者，另一类是刚接触大模型应用、想搞明白"Agent到底怎么落地"的技术爱好者。我会带着你把技能体系的设计思路、实现方式、调试方法和踩坑经验完整过一遍，保证你读完能直接上手搭自己的技能库。
说白了，这个项目解决的就是一个问题：让AI从"知道什么"进化为"会做什么"。而技能，就是架在这两者之间那座桥。
2. 技能体系的设计思路：为什么不能把所有逻辑都塞进提示词里
2.1 提示词的天花板：你无法靠"说"让AI学会操作复杂系统
在正式拆解技能体系之前，我想先聊一个很多人都踩过的坑：试图用提示词包打天下。刚开始做Agent的时候，我的想法很简单——把需求描述得足够详细，模型不就能照着做吗？比如告诉它"你去查一下销售数据，如果低于目标值就发告警邮件"。听起来没问题，但实际跑起来全是问题。
- 提示词越长，模型的注意力越容易被分散，关键指令反而被淹没
- 每次对话都要把操作说明重复一遍，既浪费token又容易出错
- 如果某个操作流程需要调整，你得去改提示词，而提示词的改动往往牵一发而动全身
- 更严重的是，复杂操作根本无法用自然语言精确描述，比如"打开软件、点这个按钮、等它加载完、再填那个表单"——这种流程性强的活，文字描述既不精确也不稳定
举个实际例子。我让Agent去一个内部系统导数据，提示词里写了"登录系统、进入报表页面、选择时间范围、点击导出"。结果它每次都卡在不同的地方：一会儿找不到登录按钮，一会儿选错时间范围，一会儿导出格式不对。后来我把这事想明白了——操作技能和语言能力是两码事。你让一个刚学会说话的小孩去帮你做饭，他能复述步骤，但手完全不听使唤。大模型也一样，它的语言能力再强，也替代不了对具体操作流程的掌握。
这就是技能体系存在的根本原因：把那些高频、复杂、需要精确执行的操作，封装成独立的"技能模块"，让Agent在需要的时候直接调用，而不是每次都在脑子里临时想。
2.2 技能与工具的本质区别：技能是"会做"，工具只是"能做"
在做agent-skills项目时，我遇到一个很常见的认知误区：把技能和工具混为一谈。很多人觉得，给Agent接个API就是给它技能了，比如接了天气API，Agent就会查天气了。但实际用下来你会发现，有了工具离会用工具还差着十万八千里。
工具的本质是一个能力接口，它告诉你"我能做什么"，但不会告诉你"什么时候该用我、用我的时候要注意什么"。技能则是把这个接口放到具体的业务场景里，包装上完整的使用方法、边界条件和处理逻辑。说白了，技能是"会做"，工具只是"能做"。
举个最直观的例子。给Agent接一个发送邮件的API，这算有个工具。但真正的技能应该是：知道什么时候该发邮件（比如用户明确要求、某个流程需要通知）、知道邮件怎么写（不同对象、不同场景有不同的措辞规范）、知道怎么处理发送失败（重试、转人工、记录日志）、知道邮件发出去之后要干什么（通知用户、更新任务状态）。这些逻辑如果全靠提示词在现场拼凑，效果就是时好时坏，而封装成技能之后，Agent每次执行都能保持一致的水准。
所以我在设计agent-skills项目时，定了一条基本原则：工具是原子能力，技能是完整的"会做事"的能力单元。每个技能必须包含三样东西：触发条件（什么时候用）、执行逻辑（怎么用）、兜底方案（用不了怎么办）。后面我会详细讲这三样东西怎么设计。
2.3 技能分层：把技能库变成一套可插拔的架构
技能体系设计还有一个关键决策——到底怎么组织这些技能。一开始我犯了一个错误，把所有技能平铺在同一个列表里，结果Agent每次选择技能的时候都很纠结，不知道该用哪个。后来参考了一些框架的设计思路，我把技能做成了分层结构，效果立刻不一样了。
我的分层方案是这样的：
基础技能层：就是那些通用的、跨场景的能力，比如文本处理、格式转换、数据计算、HTTP请求。这些技能在任何Agent里都能用，相当于工具箱里的螺丝刀和扳手。
业务技能层：针对特定业务场景设计的技能，比如"销售周报生成"、"异常告警处理"、"客户信息更新"。这一层是真正产生业务价值的地方，也是最需要花心思设计的。
复合技能层：把多个基础技能和业务技能按固定流程组合起来，比如"月度经营分析"可能就是"拉数据→清洗→计算→生成报告→发送邮件"这一串动作的集合。复合技能是让Agent完成复杂任务的终极形态。
这套分层的价值在于，每层技能可以独立迭代。基础技能出了问题，只影响依赖它的少数场景；业务技能要调整时，也不至于把底层逻辑全推翻。而且分层之后，Agent在做技能选择时会更清晰——先在高层级判断要做的事属于哪一类，再去对应的技能集合里选具体的执行方案，选择效率高了一截。
在agent-skills项目里，我一直强调一个理念：技能库不是功能的堆积，而是一套有结构的能力系统。没有结构，技能越多越混乱；有了结构，每一个新增技能都能找到自己的位置，整体能力才会越来越强。
3. 技能的定义与封装：让Agent真正"学会"一项技能的三个核心要素
3.1 触发条件设计：别人用技能的时候，靠什么知道该用哪个
先来解决一个看起来简单、实际最难的问题：Agent怎么知道当前任务该调用哪个技能？如果你做的Agent只会执行预设好的固定流程，这个问题还不明显；但只要任务稍微灵活一点，技能选择就变成了决定成败的关键。
我在agent-skills项目里采用的方案是给每个技能加上一份结构化的"触发条件清单"。这份清单不是简单的几个关键词，而是包含以下几个维度的描述：
- 适用场景：这个技能解决什么问题，什么类型的任务应该调用它
- 输入条件：调用这个技能需要提供哪些信息，比如"需要客户ID和查询时间段"
- 前置状态：调用之前必须满足什么条件，比如"用户已登录"、"数据源已连接"
- 不适用情况：什么时候千万不要用这个技能，比如"当数据量超过某个阈值时应该走批量流程而非这个接口"
这个设计的思路是：与其让Agent在几十个技能之间大海捞针，不如主动告诉它每个技能的"使用说明书"。实践中效果最好的方式是给Agent一个筛选器，先把任务要求和技能清单做一次结构化匹配，筛掉明显不适合的技能，再把候选的几个给Agent做精细判断。这样既减少了token消耗，也大幅降低了选错技能的概率。
有个教训我必须提。最初我尝试过完全靠模型的语义理解来做技能选择，结果发现一个很有意思的现象：如果两个技能在功能上只有细微差别，模型经常选错。比如"生成日报"和"生成周报"，听起来是两个技能，但模型有时候会用日报技能生成周报，里面缺了周环比数据。后来我把这两个技能合并成一个"周期性报表生成"技能，用参数控制周期，问题立刻消失了。这个经验很实用——技能边界要清晰，重叠度高的技能尽量合并，或者用参数而不是用不同技能来区分。
3.2 执行逻辑封装：把每一步操作拆到"机器能稳定执行"的粒度
技能封装的核心工作是把执行逻辑写清楚。这一步的难度在于，人类觉得理所当然的操作，机器根本不知道怎么做。比如"查一下这个客户的消费记录"，对人来说一句话就够了，但对Agent来说，你得告诉它：用什么接口查、参数怎么传、返回数据怎么解析、查不到的时候怎么办、查到之后怎么把结果整理成需要的格式。
我在封装执行逻辑的时候，会坚持一个拆解原则：每一步都要拆到原子操作级别。所谓原子操作，就是不需要再进一步拆解的动作，比如"调用接口xxx"、"把字段A重命名为B"、"对结果按时间倒序排列"。这样拆的好处有两个：一是Agent执行的时候不需要临时思考"这一步具体怎么操作"，照着步骤走就行；二是每一步都容易验证和调试，出了问题能精确定位到是哪一步坏了。
下面是一个我在项目里实际用过的技能封装伪代码，简化之后给大家做个参考，名字用的是"客户消费情况查询"：
技能名称: 客户消费查询与分析 触发条件: 适用场景: 用户询问"某个客户的消费情况""这个客户花了多少钱" 输入条件: 客户ID、查询时间段 前置状态: 已连接客户数据库，客户ID有效 不适用情况: 查询全量客户消费汇总（应使用报表技能） 执行步骤: 1. 调用客户数据库接口，传入客户ID和时间段 2. 校验接口返回状态，若失败则重试一次，间隔3秒；仍失败则报错转人工 3. 对返回数据做清洗：剔除金额为负的异常记录，标记缺失字段 4. 计算总消费金额、订单数、平均客单价 5. 与上月同期数据做对比，生成环比变化率 6. 将结果格式化为自然语言摘要，包含核心指标和变化趋势 兜底方案: - 数据源连接失败时，返回缓存中的最近一次查询结果并标注时间 - 客户无消费记录时，返回"该客户暂无消费记录"并建议检查客户ID你可能注意到了，这个技能里每一步都有明确的输入、操作和判断逻辑。我在设计的时候时刻提醒自己：让机器做它擅长的事——精确执行；不要让机器临时做判断的事——那是提示词的活。所以技能封装完之后，Agent的执行路径是非常确定的，稳定性自然就上来了。
3.3 兜底方案设计：没有Plan B的技能不是一个合格的技能
这个章节我特别想展开讲，因为兜底方案是很多Agent项目里最容易被忽略、但恰恰是最要命的部分。我见过太多Agent在正常运行的时候表现惊艳，一旦遇到异常情况就彻底摆烂。原因很简单：技能只设计了happy path，没有考虑失败的时候怎么办。
我的经验是，每个技能都必须显式设计至少一层兜底方案。所谓兜底方案，就是当主流程走不通的时候，Agent应该怎么做。我总结了常见的三类异常和对应的兜底策略：
外部依赖异常：数据库连不上、API超时、第三方服务报错。策略是有限次重试、切换到备用数据源、使用缓存数据、降级到简化流程。比如查天气的服务挂了，退回用另一个数据源；另一个也挂了，告诉用户"暂时无法获取实时天气"而不是瞎编一个气温。
数据异常：返回的数据格式不对、字段缺失、数值明显不合理。策略是解析前先校验数据完整性，不符合预期的数据一律不进入下一步，宁可中止流程也不能将错就错。
操作状态异常：前置条件不满足、用户取消操作、权限不够。策略是明确返回失败原因，告诉用户"因为什么原因没做成"以及"怎么调整之后才能做成"，而不是含糊地说一句"出错了"。
这一步做得好不好，直接决定了Agent是"看起来聪明"还是"真正好用"。我测过很多Agent，正常路径上两者差别不大，一到异常场景就高下立判。有兜底方案的Agent，会主动告诉你发生了什么、它做了什么尝试、接下来建议怎么做——这不就是我们期待一个靠谱助理该有的表现吗？
4. 实操拆解：从零构建一套技能库的完整流程
4.1 明确业务边界和Agent能力范围
动手之前，先别急着写代码或者定义技能格式，第一件要做的事是想清楚：你这个Agent到底服务什么场景、覆盖哪些业务边界。这一步是最容易糊弄过去的，但也是最重要的全局规划。
我在agent-skills项目里的做法是，先用一张表格把Agent的核心任务和边界梳理清楚。举个例子，假如你要做一个客服Agent，那至少得先厘清这些问题：
| 任务范围 | 是否覆盖 | 备注 |
|---|---|---|
| 查询订单状态 | 是 | 核心场景，必须做技能 |
| 用户信息修改 | 是 | 需要权限校验流程 |
| 财务对账 | 否 | 涉及敏感操作，MVP阶段不做 |
| 产品推荐 | 是 | 需要对接商品库 |
| 投诉升级 | 待定 | 先做基本版，后续迭代 |
这张表格看起来简单，但实际操作中能帮你砍掉一大堆不必要的工作。很多人在做Agent的时候喜欢"把能力做全"，结果就是每个技能都做得浅尝辄止，反而没有一个真正好用的。边界清晰远比能力大全重要，先做透核心场景，再做扩展。
另外还要明确一个容易忽略的问题：Agent的能力上限在哪里。说白了就是你打算让这个Agent能做什么、不能做什么。这个"不能做什么"和边界表里的"否"还不太一样，能力上限更多是指技术层面的约束。比如你接入了客户数据库，但你对数据库只有只读权限，那Agent就不能做任何写操作，技能设计时要主动避开这一块。
4.2 梳理高频操作清单，给技能分优先级
边界确定之后，下一步是从真实业务场景中提取高频操作，给它们排优先级。这一步的核心目标是找出那些"非做不可"和"做了立刻见效"的技能。
我的方法是翻历史记录。如果是一个已经跑了一段时间的业务系统，人工客服的历史对话、用户提问记录、操作日志都是金矿。把高频用户问题列出来，再分析每个问题对应的操作路径，你会发现80%的问题都集中在少数几个操作上。这些操作就是要优先封装成技能的候选。
我整理一个技能的优先级评估维度供参考：
- 出现频率：每周被触发的次数，频率越高越值得先做
- 操作复杂度：步骤越多越值得封装成技能，因为能省掉现场编排的成本
- 错误代价：做错了造成的影响大不大，影响越大越需要封装好做严谨
- 人工参与度：当前流程里有多少步骤需要人工处理，需要越少越适合Agent来做
把这些维度打分排序之后，MVP阶段的技能清单就出来了。我当时做某一个内部运营Agent的时候，列出的候选技能有二十多个，按优先级排序之后，第一批只做了六个技能。事实证明这个取舍非常正确——六个技能做好，已经能覆盖日常70%以上的需求，而且每个技能的稳定性和体验都不错。后面再逐步加新技能，整个体系是稳步成长的。
4.3 制定统一技能格式，让技能可以被Agent"阅读"
接下来是技术实现里最关键的一步：定义一套统一的技能描述格式。这一步跟写代码的关系不大，但它决定了Agent能不能在运行时正确地理解和调用技能。
在agent-skills项目里，我最终采用的格式在三要素的基础上进行了细化，变成五个部分：
技能名: 简短、明确、一看就知道干什么 描述: 2-3句话说明功能、适用场景、典型用法 参数: 输入参数的名称、类型、必填项、取值说明 执行流程: 步骤列表，每一步是清晰的原子操作 错误处理: 异常情况识别方法和兜底策略这套格式的设计初衷，是让技能描述具备两个特性：结构一致性和语义无歧义。结构一致性是指所有技能都用同一种模板来描述，这样Agent在解析技能库的时候有规律可寻，不需要每次重新理解新的结构。语义无歧义是指描述里不出现模棱两可的表达，比如"稍微等一下"、"数据不太对"这种话绝对不行，要精确到"等待5秒"、"状态码非200则视为失败"。
我举个实际例子，帮忙理解这个格式的颗粒度：
技能名: 发送邮件通知 描述: 用于向指定收件人发送邮件通知。适用于任务完成提醒、异常告警、每日摘要。默认使用模板A，支持自定义内容。 参数: - 收件人地址: string, 必填 - 邮件主题: string, 必填, 长度不超过100个字符 - 邮件正文: string, 必填 - 优先级: string, 可选, 可选值[low, normal, high], 默认normal 执行流程: 1. 校验参数合法性，收件人地址必须符合邮箱格式 2. 检查邮件模板配置，如果存在自定义内容则使用自定义内容，否则使用模板A 3. 调用邮件发送接口，设置超时10秒 4. 发送成功后记录日志并返回发送成功标记 5. 发送失败则进入错误处理流程 错误处理: - 参数校验不通过: 返回具体报错字段列表 - 发送接口超时: 重试一次，等待3秒；仍失败则返回失败结果 - 收件人地址无效: 返回"该邮箱格式不正确"，终止流程注意看这个格式里的几个细节：每个参数都标了类型和必填性，执行流程的顺序是明确的，错误处理覆盖了主流程里能预见的几类异常。这些细节加起来，就是一个合格的、能被Agent稳定调用的技能。
4.4 打开技能开关：Agent在什么节点调用哪个技能
技能封装好只是一半，剩下的一半是解决"什么时候调用哪个技能"的问题。我把它称为"技能开关设计"，这是Agent能不能自主行为的关键。
我的做法分两步走。第一步，给Agent一个全量技能清单，让它知道有哪些技能可用，通过技能名和描述做初筛。第二步，在具体的任务流程里，用规则约束调用顺序——什么情况下先调技能A、什么情况下跳过技能B。我把后一步叫做"流程编排层"，它比纯靠Agent自由发挥稳定得多。
举个例子，假设你要做一个项目进度汇报的Agent。流程可能是这样的：
收到汇报指令 → 调用"项目进度查询"技能获取最新数据 → 判断是否有延期任务，如果有，调用"延期原因分析"技能 → 调用"汇报模板生成"技能生成文档 → 调用"邮件发送"技能发给指定接收人每一步都对应一个技能，每一步的判断条件都是明确的规则。这不是死板，而是在Agent还不足以处理完全开放的复杂流程时，用半约束的方式保证执行质量。随着Agent能力增强，可以逐步放宽流程编排层的控制，让它有更多自由选择技能的空间。
这里有个分寸要拿捏：完全自由发挥，Agent容易天马行空乱调用工具；完全固定流程，又失去了Agent的自主性。我个人的建议是，核心流程用编排控制，非核心环节给Agent一定的自由度。比如上面的例子，数据怎么查、邮件怎么写模板，这些都可以让Agent自由发挥，但"查完数据必须做延期判断"这个逻辑点必须锁死。锁住关键逻辑，放开不关键的自由度，这是编排层设计的核心哲学。
5. 技能调参与评测：如何让技能越用越"顺手"
5.1 技能执行日志：每一个决策都要能回溯
技能体系上线之后，很多人会觉得"能跑就行了"，然后就把精力投到新功能上。这是一个非常致命的错误。技能体系的迭代优化，靠的是数据而不是感觉。你要想清楚：技能执行成功了没有？Agent用了哪个技能？有没有选错？每一步花了多少时间？
我的做法是在技能执行链路上加完整的日志记录，每一个关键节点都打一条log：
任务ID: 384902 技能调用顺序: 项目进度查询 → 延期原因分析 → 汇报模板生成 每个技能的耗时: 1.2s / 0.8s / 2.1s 每个技能的调用结果: 成功 / 成功 / 成功 整体任务是否完成: 是 是否有用户干预: 否这些日志积累一周之后，就是一份非常有价值的评测数据。你可以清楚地看到：哪个技能被调用的频率最高、哪个技能经常执行失败、哪一类任务经常出现"没有匹配到合适技能"的情况。这些数据决定了下一步要优化哪个技能、补充哪个新技能。
我在做agent-skills项目时，有一次靠日志发现一个奇怪的现象：某个技能整体的调用量很低，但每次调用成功率高达100%。看日志才发现，是因为它的触发条件写得太严格，Agent几乎不会选择它。后来调整了触发条件描述，调用量立刻上来了。这种问题，不靠日志根本发现不了。
5.2 评测集与判定标准：所有优化必须拿数据说话
有了日志，还需要一套评测集来衡量技能效果。评测集就是一组标准的测试任务合集，每个任务附带了期望结果和判定标准。技能每次改动之后，都用这套评测集回归一遍，确保修了一个bug没有引入新的问题。
评测集的设计有讲究，不能只测正常路径，更要多测异常场景。我一般会给每个技能准备四类用例：
- 标准用例：正常输入，期望一步到位成功
- 边界用例：输入参数在临界值的情况，比如空值、极大值、极小值、超长文本
- 异常用例：模拟数据源故障、非法输入、操作被拒绝的情况
- 干扰用例：用户表达不清晰、包含多余信息、涉及多个技能的场景
评测时除了看最终结果对不对，还要看执行过程中的几个指标：技能选择是否准确、错误处理是否生效、有没有浪费不必要的步骤、生成的内容是否在预期格式内。所有这些维度合在一起，才算一次完整的技能质量评估。
有一次我改了一个数据类的技能，把数据清洗逻辑优化了一版。标准用例和边界用例全过了，我对改动很有信心。结果一跑异常用例发现，当数据里出现负数时，新逻辑会直接把它当成异常值剔除，但实际上负数在计费场景里是合法数据。这个bug幸亏靠评测集逮住了，否则一上线就会让一批用户在月底对账时看到错误结果。评测集不是评测工具，是保护Agent质量的防弹衣。
5.3 技能进化：建立一套持续迭代的循环机制
最后聊一聊技能体系怎么保持生命力。我见过很多Agent项目起步得很漂亮，技能库从5个涨到50个，然后就开始失控——技能重复、逻辑冲突、执行方式混乱，最后变成一个没法维护的巨无霸。
为了避免这种情况，我给自己定了一条规矩：每新增一个新的技能，必须先回答三个问题：
- 这个技能是否和已有的技能重复？如果重复，能不能复用已有技能加参数来实现？
- 这个技能解决的是高频问题还是低频问题？如果是低频问题，值不值得为它增加一个技能？
- 这个技能和其他技能有没有冲突？比如两个技能都涉及"发送消息"，哪个优先级更高？
这套问题的价值在于，它能帮你保持技能库的简洁。技能库不是越大越好，而是越精准越好。一个由三十个高质量技能组成的系统，效率远好于一个由三百个低质量技能组成的系统。
除此之外，我还建议每月做一次技能使用情况复盘：把调用频次最低的十个技能拎出来，逐个分析是触发条件不够清晰，还是这个技能本身确实没有存在价值。如果连续一个月都没有被触发，果断把它下线或者合并到其他技能里。这种定期"瘦身"能让技能库始终保持在健康状态，不会随着时间推移逐渐腐坏。
6. 避坑指南与个人实践感悟
6.1 我踩过的几个最有价值的坑
做这个项目的过程中，我遇到过很多问题，挑几个最有价值的分享给大家。
第一个坑：把技能调用做成纯自由形式。一开始我完全依赖Agent自主选择技能，结果发现模型在复杂任务中经常会"跑偏"。比如明明有专门的"数据汇总"技能，它却先调了个"数据查询"技能，然后自己对着结果硬算。解决方法是加上一层流程编排约束，把关键节点的技能调用顺序固定下来。这让"Agent自主调度"和"固定流程"之间找到了一个平衡点。
第二个坑：技能描述写得不够精确。我一开始觉得技能描述写得模糊一点没关系，大模型能理解。结果大模型"理解"出的含义和我预期差了十万八千里。比如我写"如果有必要，调用数据刷新技能"，这个"有必要"到底怎么界定？后来我把描述改成"当数据更新时间超过30分钟时，调用数据刷新技能"，一切就正常了。所有模糊表达都是隐患，精确到数据和条件才可靠。
第三个坑：忽略了技能间的依赖关系。有些技能会依赖另一些技能的输出，比如"生成月度报表"要先调用"拉取销售数据"。最初我把它们当作平级技能，Agent在生成报表时经常拿不到数据。后来我把依赖关系显式地写进了技能描述里，在"执行流程"中注明"前置步骤：调用销售数据拉取技能并确保成功后再执行本技能"，问题迎刃而解。
第四个坑：测试用例太少且太理想化。早期做技能测试时我只准备了几条标准用例，没做异常和边界测试。结果每次上线都觉得稳了，实际跑起来总出幺蛾子。后来我把评测集扩充到包含异常场景和边界场景，并在每次变更后完整回归，上线事故率直接降了一个台阶。
6.2 从"能用"到"好用"，技能体系后续还能怎么扩展
最后，我聊聊这个技能体系的扩展方向，给想要深入的朋友一些参考。
第一个方向是跨Agent技能共享。目前技能库是跟单个Agent绑定的，但很多技能其实是通用的，比如"发送邮件"、"数据格式转换"、"权限校验"。如果能做成一个共享的技能市场，让不同Agent共用一套经过验证的技能库，整体效率会高很多。这类似把工具从"私有后院"搬到"公共广场"的感觉。
第二个方向是技能学习进化。现在的技能还都是人工设计好给Agent用的，后续可以让Agent在执行任务的过程中自己去发现"这个操作太复杂了，应该拆成一个技能"，甚至半自动地生成新技能的草案。这可能是技能体系最激动人心的发展方向，也是这个项目未来最大的想象空间。
第三个方向是技能质量量化。除了基本的成功率、耗时这些指标，能不能给每个技能做一个质量评分体系，让Agent在调度时能综合评估"哪个技能在当前场景下效果最好"？这需要积累大量真实的执行反馈数据，但一旦做出来，Agent的技能调用就不再是"凭感觉匹配"，而是"按数据择优"。
这个项目磕磕绊绊做到现在，我最大的体会是：做Agent技能体系，其实是在驯化不确定性。大模型天生有随机性，同一个问题每次回答可能不一样；但业务执行需要确定性，该查的数据必须查到，该做的操作必须做完。技能体系存在的全部价值，就是在这两者之间铺一条尽可能稳定的路。希望这篇内容能帮你少踩一些我踩过的坑，做出一套真正好用、能落地的Agent技能系统。
