1. 先搞清楚agent-skills 到底解决什么问题最近和几个做 AI 应用落地的朋友聊起同一个痛点模型本身的聪明程度已经不是瓶颈真正卡住项目进度的是“怎么让智能体稳定地做完一件完整的事”。比如让它去批量整理文件、自动巡查监控指标、按照固定流程生成周报单看每一步模型都会可是连起来跑就经常掉链子——要么漏参数要么格式换了个花样要么中途直接放弃。这种时候光靠调 prompt 已经救不回来了真正好用的做法是给智能体搭建一套可以复用的 agent-skills也就是技能库。这阵子我围绕 agent-skills 做了一轮比较完整的整理和实践。先说结论这套思路把“告诉模型怎么做”升级成了“让模型调用一个定义好的能力”简单说就是从写 prompt 变成写技能再从写技能变成管理技能库。它适合所有正在做智能体应用的人不管是基于 LangChain、开源模型微调还是直接用 API 做编排这套方法论都能接进去。我接下来把这些设计思路、实操流程和踩过的坑逐条展开尽量把能直接照抄的东西都写出来。2. 为什么技能化比 prompt 工程更稳定2.1 prompt 是“口头交代”技能是“标准化接口”先打个比方。你让一个新来的实习生去发快递口头交代“帮我把这个寄了”大概率出问题——寄到哪用哪家快递要不要保价他得反复问你。但你给他一张写明收件人、地址、快递公司、运费上限的工单他照着执行就不会错。老员工习惯把这类重复性的流程沉淀成“标准操作单”AI 智能体这边对应的就是 agent-skills。直接堆 prompt 的问题在于模型对自然语言的理解是有灵活性的这既是优点也是灾难。同一个请求换个说法模型对任务边界、输出格式的理解就会漂移。把技能做成结构化定义之后模型的行为被约束在一个明确的接口里——输入是什么、输出是什么、调用什么工具、失败怎么处理全部写清楚。这样模型不再“自由发挥”而是在技能框架内做执行。2.2 技能库让能力沉淀、复用、审计我见过不少团队项目做大了之后 prompt 散落在各个文件里改一个业务规则要在十几个 prompt 里同步修改漏一个就出现“两个模块行为不一致”的诡异问题。技能化的思路是把能力沉淀为独立、可版本管理的模块——每个技能有自己独立的输入输出定义、测试用例和版本记录。改技能时只动一个模块所有引用方自动生效还能做回归测试。这就像把代码里重复的逻辑抽成公共函数调用方不用关心内部实现只用关心输入输出契约。agent-skills 本质上是给智能体写“函数库”好处不只是稳定还有可维护、可测试、可复用。2.3 技能化之后模型和业务逻辑的边界更清晰另一个实际操作中体会到的好处是拆分技能之后模型主要负责“理解用户意图 选择技能 填好参数”具体的执行逻辑由技能本身保证。业务规则不需要靠模型去“悟”而是直接固化在技能代码里。权限控制也好做——不同角色挂载不同的技能白名单用户能调用什么不能调用什么在技能层就能挡住而不是靠模型自觉。所以我的判断是现阶段做智能体的核心工作量已经从“写提示词”慢慢转为“设计技能体系”。谁把技能定义得清晰、拆分得合理谁的系统就更可控。3. 设计一套 agent-skills 的核心思路3.1 先搭技能地图从业务场景倒推技能清单我在动手写技能之前会先做一件事把业务场景完整地列出来然后逐项倒推“这个场景需要什么能力”。比如做一个内部运营助手可能的场景有周报生成、数据查询、文件归档、任务提醒。每个场景对应一到多个技能把这张表画出来技能的边界就清晰了。这一步最容易犯的错是“一把梭”——把多个能力塞进一个技能里表面看是为了省事实际上后面维护时特别难受。一个技能只做一件事这句话怎么强调都不过分。举个例子“生成周报”应该拆成“汇总本周提交记录”“抓取指标数据”“按模板生成文档”三个技能前两个是数据准备第三个是生成动作。拆细了之后每个技能都能单独测试、替换和复用。3.2 技能描述是灵魂写得越具体选得越准技能描述决定了模型能不能在正确的时候把技能调出来。我见过太多人在这上面偷懒写一句“用于生成周报”就完事了结果模型在用户根本没有要求周报的时候也去调用——因为描述太宽泛模型判断不准触发条件。好的技能描述应该包含三个要素做什么、在什么情况下用、输出是什么。比如“当用户要求汇总本周工作内容、需要生成周期性工作报告时将本周数据填充到周报模板并导出为 Markdown 文件”。这样模型选择技能时就有了明确的语义锚点误调用的概率会大幅下降。这里面的经验是技能描述宁可啰嗦也不要含糊。3.3 结构化输出是刚需别让模型自由发挥技能执行完返回什么格式必须在定义阶段就定死。常规做法是给每个技能定义一个 JSON 输出契约不仅规定字段还规定字段类型和可选值。比如文件整理技能的输出就是[{“source”: “...”, “target”: “...”, “status”: “moved|failed”, “error”: “...”}]模型或者上层系统读取这个结构就能继续走流程不用再解析一遍自然语言。这里有个小教训如果输出的字段类型不约束模型偶尔会返回数字当字符串、日期写成年月日中文格式这些细节在单次调用时看着没事一旦下游要做自动校验、入库、统计就会变成麻烦需要写一堆兼容逻辑。技能化的意义之一就是消灭这种不确定性。3.4 技能的分层原子技能和组合技能把技能分成两层的经验对我帮助很大。底层是原子技能类似函数库里的基础方法比如“读取文件”“发送HTTP请求”“执行SQL查询”体积小、逻辑单一上层是组合技能负责编排多个原子技能完成业务任务比如“生成周报”会依次调用“查询数据库”“读取本周提交记录”“生成 Markdown 文档”。分层的意义在于原子技能足够稳定可以放心复用组合技能可以快速调整业务逻辑而不动底层。好比我做了一个“项目周报”技能等另一个团队说也要日报我只需要改组合技能里的模板和查询参数底层技能不动就接上了。分层设计是 agent-skills 这种方案最值得投入的部分一次设计长期受益。4. 从零搭建 agent-skills 的实操记录4.1 技能定义的载体选择技能定义用什么格式取决于你的智能体框架。如果项目是围绕一个开源框架做的通常框架本身定义了技能或插件、工具的字段格式按它的规范写就行。没有框架约束的推荐用 JSON 定义技能元数据结构清晰也方便外部系统解析。下面是一个技能定义的参考结构字段可以按需扩展{ “name”: “weekly_report_generator”, “description”: “当用户要求汇总本周工作、生成周报或周期性工作报告时使用。将已收集的工作记录填充到标准模板中输出 Markdown 文件。”, “input_schema”: { “type”: “object”, “properties”: { “date_range_start”: {“type”: “string”, “format”: “date”}, “date_range_end”: {“type”: “string”, “format”: “date”}, “project”: {“type”: “string”, “description”: “项目名称可为空”} }, “required”: [“date_range_start”, “date_range_end”] }, “output_schema”: { “type”: “object”, “properties”: { “file_path”: {“type”: “string”}, “report_title”: {“type”: “string”}, “sections”: {“type”: “array”, “items”: {“type”: “object”}} } }, “steps”: [ “collect_recent_work_records”, “fetch_project_metrics”, “render_markdown_template”, “save_to_output_dir” ] }这套结构基本覆盖了描述、输入、输出、执行步骤几个核心部分后端代码只要按这个契约来路由就能工作。字段命名建议统一用蛇形方便跨语言处理。4.2 模型能力接入把技能绑定到模型上定义好技能之后下一步是把它暴露给模型。这个过程根据技术栈不同分两种做法用 API 的场景下把技能的 name、description、parameters 传到工具列表模型会在需要时发起调用用开源模型本地部署的场景下需要把技能描述拼进 system prompt同时靠函数调用的能力来触发。实操中我倾向于把技能注册表做成独立的配置文件系统启动时自动加载再传给模型运行时。这样新增技能不用改主程序代码只增加一个配置文件就能生效。整个流程走下来技能接入的边际成本很低新增一个技能几乎不需要动业务代码团队迭代的效率提升非常明显。4.3 一个完成度高的示例文件批量归档技能我拿一个真实使用过的技能来完整演示一遍。“按日期归档文件”这个技能解决的问题是用户指定一个目录系统对目录内所有文件按修改日期自动分类归档到年/月子目录避免手动整理大量文件。import os import shutil from datetime import datetime def archive_files_by_date(source_dir, dry_runTrue): errors [] moved [] for filename in os.listdir(source_dir): full_path os.path.join(source_dir, filename) if not os.path.isfile(full_path): continue try: mtime datetime.fromtimestamp(os.path.getmtime(full_path)) target_dir os.path.join(source_dir, str(mtime.year), f“{mtime.month:02d}”) os.makedirs(target_dir, exist_okTrue) target_path os.path.join(target_dir, filename) if os.path.exists(target_path): target_path os.path.join(target_dir, f“{datetime.now().strftime(‘%H%M%S’)}_{filename}”) if dry_run: moved.append({“source”: full_path, “target”: target_path, “status”: “preview”}) else: shutil.move(full_path, target_path) moved.append({“source”: full_path, “target”: target_path, “status”: “moved”}) except Exception as exc: errors.append({“source”: full_path, “error”: str(exc)}) return {“moved”: moved, “errors”: errors} if __name__ “__main__”: result archive_files_by_date(“./test_files”, dry_runTrue) print(result)这段代码的思路特别适合作为技能的示例先加一个dry_run参数来预览结果而不真正动文件这个开关帮我避了不少坑确认无误后再开实际执行。跑完后返回结构化的 moved / errors 列表上层系统可以直接读取结果做后续展示或日志审计。4.4 技能执行中的状态管理需要特别注意的是技能执行不是每次都一次成功的尤其涉及外部依赖时。我在每个技能里都加了两样东西执行状态标记pending / running / success / failed和错误上下文哪一步、什么错误、原参数是什么。这样出问题后无论是模型重试还是人工介入都能快速定位不用从日志里翻半天。执行状态对应到每个调用实例模块级记录。一套核心的技能执行流程跑下来如果状态设计和错误上下文做得充分整个系统的可观测性会提升一大截后续排查问题的效率完全不同。5. 几个容易踩的坑和排查心得5.1 技能描述太长或太短都会导致模型误选技能描述这个事不是越短越好也不是越长越好。我踩过的坑是短了模型根本不知道这个技能什么时候该用长了一大段之后模型反而被里面的细节带偏在明明不该触发的时候触发了。比较好的状态是描述维持在两三句话把“触发场景”和“具体产出”讲清楚不带多余的信息。模型选择技能的本质是语义匹配描述里跟场景相关的关键词越多、越聚焦匹配越准。5.2 技能内部不要依赖模型的理解这个坑是我做了很久之后才彻底想明白的技能是实现层不是提示词层。技能代码里的所有分支逻辑都应该是正规代码写死的判断不能指望模型“理解之后灵活处理”。技能的函数里不要留太多“模糊地带”所有逻辑都得写到明处。一个技能如果到了要靠模型现场发挥才能完成的程度说明拆得不彻底应该继续往原子化拆。5.3 上下文窗口是硬约束技能描述不能无限膨胀技能库超过几十个之后所有技能描述拼在一起会占用大量上下文空间直接影响模型对主任务的注意力。解决办法是给技能做分组挂载而不是一次性全部塞给模型——比如管理类技能只在用户进入管理后台时加载。这一步上线后调用准确率的提升肉眼可见上下文窗口也宽裕了一大截。5.4 技能返回结果的校验不可省收到技能返回后系统需要做一层格式校验别默认模型或代码永远产出合法结果。我写过一段很小的校验函数检查返回的 JSON 是否符合 output_schema不符合就自动触发一次带错误信息的重试。实际用下来这层防护能把很多偶发问题拦截在进入业务逻辑之前系统的稳定性因此提高了不少强烈建议保留。6. 没有说透的细节和我的体会可能你会问技能和工具、插件、函数调用这些概念到底什么关系我的理解是技能偏重“能力封装 可复用”的抽象层级工具更偏重单一动作的落地实现插件则通常是技能的集合体。实际落地时不必纠结术语重点是搞清楚自己在哪一层做设计。另一个还没展开说的是技能测试。技能本质上是一段可运行的代码或配置这意味着它能像软件一样做回归测试。我自己会把每个技能配两个用例一个正常路径、一个边界情况每次改动技能定义之后自动跑一遍。这个习惯帮我省掉了大量联调时间。以后有时间我会单独写一篇技能测试的详细做法。agent-skills 这套思路真正让我感觉值得投入的地方是把“模型的能力边界”和“业务的可控性”这两个问题分开了。模型负责理解、决策、表达技能负责稳定地完成任务各司其职。现在再看手头这些智能体项目最让我踏实的已经不是模型的聪明程度而是底层的技能库稳如老狗。如果你也在做智能体相关的东西不妨从最小的一个技能开始试验把你每天重复让模型做的某件事定义成一个带输入输出契约的技能跑两周看看稳定性变化。我猜你也会和我一样把越来越多的能力迁到技能体系里来。 
长河君 · 2026/9/26 0:09:16 · 阅读 1.2k Agent-Skills技能库设计：从Prompt工程到稳定智能体实战
1. 先搞清楚agent-skills 到底解决什么问题最近和几个做 AI 应用落地的朋友聊起同一个痛点模型本身的聪明程度已经不是瓶颈真正卡住项目进度的是“怎么让智能体稳定地做完一件完整的事”。比如让它去批量整理文件、自动巡查监控指标、按照固定流程生成周报单看每一步模型都会可是连起来跑就经常掉链子——要么漏参数要么格式换了个花样要么中途直接放弃。这种时候光靠调 prompt 已经救不回来了真正好用的做法是给智能体搭建一套可以复用的 agent-skills也就是技能库。这阵子我围绕 agent-skills 做了一轮比较完整的整理和实践。先说结论这套思路把“告诉模型怎么做”升级成了“让模型调用一个定义好的能力”简单说就是从写 prompt 变成写技能再从写技能变成管理技能库。它适合所有正在做智能体应用的人不管是基于 LangChain、开源模型微调还是直接用 API 做编排这套方法论都能接进去。我接下来把这些设计思路、实操流程和踩过的坑逐条展开尽量把能直接照抄的东西都写出来。2. 为什么技能化比 prompt 工程更稳定2.1 prompt 是“口头交代”技能是“标准化接口”先打个比方。你让一个新来的实习生去发快递口头交代“帮我把这个寄了”大概率出问题——寄到哪用哪家快递要不要保价他得反复问你。但你给他一张写明收件人、地址、快递公司、运费上限的工单他照着执行就不会错。老员工习惯把这类重复性的流程沉淀成“标准操作单”AI 智能体这边对应的就是 agent-skills。直接堆 prompt 的问题在于模型对自然语言的理解是有灵活性的这既是优点也是灾难。同一个请求换个说法模型对任务边界、输出格式的理解就会漂移。把技能做成结构化定义之后模型的行为被约束在一个明确的接口里——输入是什么、输出是什么、调用什么工具、失败怎么处理全部写清楚。这样模型不再“自由发挥”而是在技能框架内做执行。2.2 技能库让能力沉淀、复用、审计我见过不少团队项目做大了之后 prompt 散落在各个文件里改一个业务规则要在十几个 prompt 里同步修改漏一个就出现“两个模块行为不一致”的诡异问题。技能化的思路是把能力沉淀为独立、可版本管理的模块——每个技能有自己独立的输入输出定义、测试用例和版本记录。改技能时只动一个模块所有引用方自动生效还能做回归测试。这就像把代码里重复的逻辑抽成公共函数调用方不用关心内部实现只用关心输入输出契约。agent-skills 本质上是给智能体写“函数库”好处不只是稳定还有可维护、可测试、可复用。2.3 技能化之后模型和业务逻辑的边界更清晰另一个实际操作中体会到的好处是拆分技能之后模型主要负责“理解用户意图 选择技能 填好参数”具体的执行逻辑由技能本身保证。业务规则不需要靠模型去“悟”而是直接固化在技能代码里。权限控制也好做——不同角色挂载不同的技能白名单用户能调用什么不能调用什么在技能层就能挡住而不是靠模型自觉。所以我的判断是现阶段做智能体的核心工作量已经从“写提示词”慢慢转为“设计技能体系”。谁把技能定义得清晰、拆分得合理谁的系统就更可控。3. 设计一套 agent-skills 的核心思路3.1 先搭技能地图从业务场景倒推技能清单我在动手写技能之前会先做一件事把业务场景完整地列出来然后逐项倒推“这个场景需要什么能力”。比如做一个内部运营助手可能的场景有周报生成、数据查询、文件归档、任务提醒。每个场景对应一到多个技能把这张表画出来技能的边界就清晰了。这一步最容易犯的错是“一把梭”——把多个能力塞进一个技能里表面看是为了省事实际上后面维护时特别难受。一个技能只做一件事这句话怎么强调都不过分。举个例子“生成周报”应该拆成“汇总本周提交记录”“抓取指标数据”“按模板生成文档”三个技能前两个是数据准备第三个是生成动作。拆细了之后每个技能都能单独测试、替换和复用。3.2 技能描述是灵魂写得越具体选得越准技能描述决定了模型能不能在正确的时候把技能调出来。我见过太多人在这上面偷懒写一句“用于生成周报”就完事了结果模型在用户根本没有要求周报的时候也去调用——因为描述太宽泛模型判断不准触发条件。好的技能描述应该包含三个要素做什么、在什么情况下用、输出是什么。比如“当用户要求汇总本周工作内容、需要生成周期性工作报告时将本周数据填充到周报模板并导出为 Markdown 文件”。这样模型选择技能时就有了明确的语义锚点误调用的概率会大幅下降。这里面的经验是技能描述宁可啰嗦也不要含糊。3.3 结构化输出是刚需别让模型自由发挥技能执行完返回什么格式必须在定义阶段就定死。常规做法是给每个技能定义一个 JSON 输出契约不仅规定字段还规定字段类型和可选值。比如文件整理技能的输出就是[{“source”: “...”, “target”: “...”, “status”: “moved|failed”, “error”: “...”}]模型或者上层系统读取这个结构就能继续走流程不用再解析一遍自然语言。这里有个小教训如果输出的字段类型不约束模型偶尔会返回数字当字符串、日期写成年月日中文格式这些细节在单次调用时看着没事一旦下游要做自动校验、入库、统计就会变成麻烦需要写一堆兼容逻辑。技能化的意义之一就是消灭这种不确定性。3.4 技能的分层原子技能和组合技能把技能分成两层的经验对我帮助很大。底层是原子技能类似函数库里的基础方法比如“读取文件”“发送HTTP请求”“执行SQL查询”体积小、逻辑单一上层是组合技能负责编排多个原子技能完成业务任务比如“生成周报”会依次调用“查询数据库”“读取本周提交记录”“生成 Markdown 文档”。分层的意义在于原子技能足够稳定可以放心复用组合技能可以快速调整业务逻辑而不动底层。好比我做了一个“项目周报”技能等另一个团队说也要日报我只需要改组合技能里的模板和查询参数底层技能不动就接上了。分层设计是 agent-skills 这种方案最值得投入的部分一次设计长期受益。4. 从零搭建 agent-skills 的实操记录4.1 技能定义的载体选择技能定义用什么格式取决于你的智能体框架。如果项目是围绕一个开源框架做的通常框架本身定义了技能或插件、工具的字段格式按它的规范写就行。没有框架约束的推荐用 JSON 定义技能元数据结构清晰也方便外部系统解析。下面是一个技能定义的参考结构字段可以按需扩展{ “name”: “weekly_report_generator”, “description”: “当用户要求汇总本周工作、生成周报或周期性工作报告时使用。将已收集的工作记录填充到标准模板中输出 Markdown 文件。”, “input_schema”: { “type”: “object”, “properties”: { “date_range_start”: {“type”: “string”, “format”: “date”}, “date_range_end”: {“type”: “string”, “format”: “date”}, “project”: {“type”: “string”, “description”: “项目名称可为空”} }, “required”: [“date_range_start”, “date_range_end”] }, “output_schema”: { “type”: “object”, “properties”: { “file_path”: {“type”: “string”}, “report_title”: {“type”: “string”}, “sections”: {“type”: “array”, “items”: {“type”: “object”}} } }, “steps”: [ “collect_recent_work_records”, “fetch_project_metrics”, “render_markdown_template”, “save_to_output_dir” ] }这套结构基本覆盖了描述、输入、输出、执行步骤几个核心部分后端代码只要按这个契约来路由就能工作。字段命名建议统一用蛇形方便跨语言处理。4.2 模型能力接入把技能绑定到模型上定义好技能之后下一步是把它暴露给模型。这个过程根据技术栈不同分两种做法用 API 的场景下把技能的 name、description、parameters 传到工具列表模型会在需要时发起调用用开源模型本地部署的场景下需要把技能描述拼进 system prompt同时靠函数调用的能力来触发。实操中我倾向于把技能注册表做成独立的配置文件系统启动时自动加载再传给模型运行时。这样新增技能不用改主程序代码只增加一个配置文件就能生效。整个流程走下来技能接入的边际成本很低新增一个技能几乎不需要动业务代码团队迭代的效率提升非常明显。4.3 一个完成度高的示例文件批量归档技能我拿一个真实使用过的技能来完整演示一遍。“按日期归档文件”这个技能解决的问题是用户指定一个目录系统对目录内所有文件按修改日期自动分类归档到年/月子目录避免手动整理大量文件。import os import shutil from datetime import datetime def archive_files_by_date(source_dir, dry_runTrue): errors [] moved [] for filename in os.listdir(source_dir): full_path os.path.join(source_dir, filename) if not os.path.isfile(full_path): continue try: mtime datetime.fromtimestamp(os.path.getmtime(full_path)) target_dir os.path.join(source_dir, str(mtime.year), f“{mtime.month:02d}”) os.makedirs(target_dir, exist_okTrue) target_path os.path.join(target_dir, filename) if os.path.exists(target_path): target_path os.path.join(target_dir, f“{datetime.now().strftime(‘%H%M%S’)}_{filename}”) if dry_run: moved.append({“source”: full_path, “target”: target_path, “status”: “preview”}) else: shutil.move(full_path, target_path) moved.append({“source”: full_path, “target”: target_path, “status”: “moved”}) except Exception as exc: errors.append({“source”: full_path, “error”: str(exc)}) return {“moved”: moved, “errors”: errors} if __name__ “__main__”: result archive_files_by_date(“./test_files”, dry_runTrue) print(result)这段代码的思路特别适合作为技能的示例先加一个dry_run参数来预览结果而不真正动文件这个开关帮我避了不少坑确认无误后再开实际执行。跑完后返回结构化的 moved / errors 列表上层系统可以直接读取结果做后续展示或日志审计。4.4 技能执行中的状态管理需要特别注意的是技能执行不是每次都一次成功的尤其涉及外部依赖时。我在每个技能里都加了两样东西执行状态标记pending / running / success / failed和错误上下文哪一步、什么错误、原参数是什么。这样出问题后无论是模型重试还是人工介入都能快速定位不用从日志里翻半天。执行状态对应到每个调用实例模块级记录。一套核心的技能执行流程跑下来如果状态设计和错误上下文做得充分整个系统的可观测性会提升一大截后续排查问题的效率完全不同。5. 几个容易踩的坑和排查心得5.1 技能描述太长或太短都会导致模型误选技能描述这个事不是越短越好也不是越长越好。我踩过的坑是短了模型根本不知道这个技能什么时候该用长了一大段之后模型反而被里面的细节带偏在明明不该触发的时候触发了。比较好的状态是描述维持在两三句话把“触发场景”和“具体产出”讲清楚不带多余的信息。模型选择技能的本质是语义匹配描述里跟场景相关的关键词越多、越聚焦匹配越准。5.2 技能内部不要依赖模型的理解这个坑是我做了很久之后才彻底想明白的技能是实现层不是提示词层。技能代码里的所有分支逻辑都应该是正规代码写死的判断不能指望模型“理解之后灵活处理”。技能的函数里不要留太多“模糊地带”所有逻辑都得写到明处。一个技能如果到了要靠模型现场发挥才能完成的程度说明拆得不彻底应该继续往原子化拆。5.3 上下文窗口是硬约束技能描述不能无限膨胀技能库超过几十个之后所有技能描述拼在一起会占用大量上下文空间直接影响模型对主任务的注意力。解决办法是给技能做分组挂载而不是一次性全部塞给模型——比如管理类技能只在用户进入管理后台时加载。这一步上线后调用准确率的提升肉眼可见上下文窗口也宽裕了一大截。5.4 技能返回结果的校验不可省收到技能返回后系统需要做一层格式校验别默认模型或代码永远产出合法结果。我写过一段很小的校验函数检查返回的 JSON 是否符合 output_schema不符合就自动触发一次带错误信息的重试。实际用下来这层防护能把很多偶发问题拦截在进入业务逻辑之前系统的稳定性因此提高了不少强烈建议保留。6. 没有说透的细节和我的体会可能你会问技能和工具、插件、函数调用这些概念到底什么关系我的理解是技能偏重“能力封装 可复用”的抽象层级工具更偏重单一动作的落地实现插件则通常是技能的集合体。实际落地时不必纠结术语重点是搞清楚自己在哪一层做设计。另一个还没展开说的是技能测试。技能本质上是一段可运行的代码或配置这意味着它能像软件一样做回归测试。我自己会把每个技能配两个用例一个正常路径、一个边界情况每次改动技能定义之后自动跑一遍。这个习惯帮我省掉了大量联调时间。以后有时间我会单独写一篇技能测试的详细做法。agent-skills 这套思路真正让我感觉值得投入的地方是把“模型的能力边界”和“业务的可控性”这两个问题分开了。模型负责理解、决策、表达技能负责稳定地完成任务各司其职。现在再看手头这些智能体项目最让我踏实的已经不是模型的聪明程度而是底层的技能库稳如老狗。如果你也在做智能体相关的东西不妨从最小的一个技能开始试验把你每天重复让模型做的某件事定义成一个带输入输出契约的技能跑两周看看稳定性变化。我猜你也会和我一样把越来越多的能力迁到技能体系里来。