“agent skills”这组合我在今年2025下半年看到频率越来越高。很多朋友会问这不就是把提示词整理一下吗或者干脆说这不就是给 Claude Code / Codex 加一套自定义指令吗一开始我也这么想但真正把 agent-skills 这套东西折腾进日常开发流程之后我发现它远不是“prompt 模板集合”那么简单。这更像是在给 AI 编程助手装上一套“外接专家大脑”让它能从零开始学会做一件具体的事而不是每次都得从头读文档、猜上下文。我自己用 agent-skills 做 LATEX 排版、前端重构、结构图画图、甚至是给老项目做 legacy 代码扫描踩了不少坑也沉淀出一套完整的工作流。这篇就从一个“天天跟 agent 打交道的人”角度把 skills 的设计思路、开发方法、常见坑一次性讲透。1. 项目概述agent-skills 到底在解决什么问题1.1 从“对话式助手”到“带技能的工程师”先聊一个很直观的场景。你现在让 Claude Code 或者 OpenAI Codex 去改一个前端项目传统做法是把项目里相关代码路径、框架说明、设计规范全塞进 prompt再仔细叮嘱“不要动其他文件、样式请参考现有组件、记得跑测试”。效果嘛看运气有时候模型理解得挺准有时候它会很礼貌地给你改出一个乱七八糟的版本。原因在于默认的 AI 编程助手本质上是“通用问答模型”它知道很多但对“你的项目”一无所知。agent-skills 的思路是把某类特定问题的高效解法做成一套可复用、可插拔的“技能包”当 agent 遇到匹配任务时自动加载这个技能包按里面的流程、规则和脚本来执行。这就像是给一个全科医生配了专科手术包——你医术再高专不专科器械和流程还是不一样的。技能包不再是一大段 prompt 文本而是一个包含指令、资源、脚本、校验逻辑的文件夹。agent 会在任务开始时“看到”这个文件夹并按其中的 SKILL.md 文件作为主入口来组织执行真正做到“按图索骥”而非“自由发挥”。这也是 agent-skills 项目最核心的设计哲学把离散经验固化为结构化能力而不是把经验写在对话里。1.2 为什么 2025 年 skills 会集中爆发翻了一下最近的开发社区动态agent 相关关键词里“skills”“agent framework”“agent evals”甚至超过了模型本身的讨论。背后有几个原因值得说。第一基础模型的能力已经“够用”了瓶颈转移到了任务编排和经验复用。大模型跟你对话没问题但要让它稳定地执行多步骤工作流比如“分析项目→生成报告→执行重构→跑测试→修正回归”每一步都可能偏离轨道。skills 把这种行为路径固化成半结构化的执行脚本降低了任务编排的随机性。第二prompt 工程的“天花板”已经出现。GPT-6 Astra 之类的新模型虽然推理更聪明但靠临时写提示词很难把“特定领域资深专家的隐性知识”塞进去——隐性知识没法用一段话描述它更像“遇到 A 情况优先用方案 B超过 N 秒没跑完就检查 C”这种分支逻辑。skills 用文档、脚本和资源文件把这层逻辑表达出来正好补齐了模型的短板。第三工具链生态的成熟。Claude Code、Codex CLI、OpenCode、Cursor 的 Agent 模式以及 Pi Agent、Hermes Agent 等桌面端/框架层产品都开始支持自定义 skills 或类似的 harness 机制。这意味着你不用自己发明轮子只要定义好 SKILL.md 和配套文件多个 agent 工具都能按统一约定加载。换句话说agent-skills 不是一个“未来概念”它就是当前 agent 开发走向工程化的中间产物。你把它装好、调通、塞进日常工作流后面出活的稳定性和质量完全不是一个层级。2. 核心概念拆解skill、prompt、agent 和 harness 到底有啥区别2.1 skill 不是 prompt也不是 plugin很多人会把 skill 和 prompt 混为一谈。从表现上看skill 确实包含一段类似 prompt 的说明文本但它的结构比 prompt 复杂得多且是“面向 agent 执行”设计的不是“面向模型对话”设计的。一个标准 skill 包通常包含SKILL.md技能的主说明文件包含技能名称、适用场景、执行步骤、注意事项。这是 agent 在决定调用 skill 时会重点扫描的内容。scripts/配套脚本目录可能是 Python、TypeScript、Shell用来执行实际的操作比如代码检查、截图、文件生成。assets/模板、样例、参考图片、结构图模板等静态资源。tests/技能自身的测试用例用来验证 skill 在各种输入下是否按预期工作。prompt 是“一次性”的每次对话都要重新把上下文讲一遍。skill 则是“持久化”的通过文件名、路径和自动匹配机制让 agent 在恰当的时候自动加载。我打个比方prompt 是口述菜谱skill 是厨房里准备好的“半成品净菜包”加“操作手册”——同样能做菜但后者稳定、可复制、不会漏步骤。2.2 skill 与 agent 的分工边界agent 是承载智能决策和执行循环的框架它负责感知环境读取文件、看命令输出、规划决策选择下一步动作、调用工具执行命令、调用 API。skill 则是 agent 身上的“专业模块”让 agent 在特定领域表现得像一个行家。你可以把 agent 理解成一个“万能操作员”它什么都能碰但缺少领域知识skill 就是给这个操作员配置的“领域操作卡”。操作员不需要理解所有行业细节只要调用对应操作卡按卡上的步骤走结果就不会太差。这个边界在代码层面也很清楚。agent 层处理“怎么调工具、怎么迭代、怎么终止”skill 层处理“针对这个任务应该做什么、按什么顺序做、需要避免什么”。所以同一条 skill 可以被不同的 agent 框架Claude Code、Codex、OpenCode加载而 agent 本身不应该强绑定某一个 skill 的实现细节——这个思路和 harness 的出现密切相关。2.3 harness 和 agent-cli 工具的关系热搜词里有人搜“harness和agent区别”这是个好问题。按我的理解harness 是 agent 运行时的“外壳”负责给 agent 提供命令执行、文件读写、网络请求、技能加载等底层能力。可以理解成给模型套上的一副“手脚”让它可以真正操作外部环境。Claude Code 本身就是一个带有 harness 的 agent 产品Codex、Cursor Agent 同理。而 skill 是运行在 harness 之上的“知识包”依赖 harness 提供的能力去执行脚本、读取文件。Hmm那 agent-skills 项目在中间扮演什么角色它更像一个“预制技能仓库 开发规范”一方面汇集了大量配置好的技能包方便直接安装使用另一方面定义了一套编写技能的标准流程让大家可以自己定制和分发技能。它不替代 harness也不替代 agent而是把“agent 能执行什么”这件事模板化、标准化。下面用一个表格区分几个概念概念定位示例是否依赖模型prompt一次性上下文指令“请用简洁风格重构这段代码”是skill可复用的结构化技能包打包好的“latex 排版技能”部分agent智能决策与执行主体Claude Code、Codex 中的执行循环是harnessagent 的运行底座Node/Python 运行时 CLI 工具否framework开发 agent 的框架AgentScope、OpenAI Agents SDK否这个表格特别适合还没入门的读者。先搞清楚这几层后面设计自己的 skill 时就不会“一锅炖”把提示词、脚本和 agent 配置全部塞在一起。3. 实操准备skill 开发环境与工具链选型3.1 哪些 agent 客户端已经支持 skills现在支持 skill 机制的客户端和框架越来越多实测下来最稳定的几条路线如下Claude Code通过.claude/skills目录或插件机制加载技能支持 SKILL.md 解析。它的 skill 触发准确率不错尤其对代码诊断和重构类任务效果好。Codex CLIOpenAI加载~/.codex/skills或项目级技能目录。Codex 对 skill 中的结构化描述很敏感skill 的 description 写得越明确触发越准。Cursor Agent 模式配合.cursor/skills使用适合在前端项目里做 UI 生成、结构图绘制。OpenCode开源 CLI支持自定义 skills配合 TypeScript 脚本很香。Pi Agent桌面端对多模态技能如截图分析、图像步骤识别支持不错适合做偏视觉流的技能。Hermes Agent偏研究向的 agent 框架对 skill 的上下文优先级处理有自己的实现。如果只是入门我建议先装 Claude Code 或 Codex CLI因为它们的 skills 生态最成熟、文档最清晰踩坑也最少。3.2 安装一个现成 skill 的两种路径技能安装通常分两种方式因为不同工具的加载路径不一样。一种是通过命令行工具直接安装。比如 Codex CLI 可以用类似下面的命令从仓库拉取并注册技能codex skills install agent-skills/latex-typesetting如果工具没有内置的安装命令就手动把技能目录复制到对应位置mkdir -p ~/.claude/skills cp -r ~/Downloads/latex-typesetting ~/.claude/skills/安装后可以用codex skills list或直接查看目录内容确认加载情况。注意每个工具扫描 skill 的路径不同多参考对应工具的官方说明不要照抄我的路径。3.3 目录规范一份能跑的 SKILL.md 长什么样拿一个真实可用的技能来拆解。假设要写一个“latex 排版”技能目录结构如下latex-typesetting/ ├── SKILL.md ├── assets/ │ ├── paper-template.tex │ └── proofread-checklist.md ├── scripts/ │ ├── compile_and_check.py │ └── validate_latex.sh └── tests/ ├── sample.tex └── expected-report.jsonSKILL.md 是门面也是 agent 最先读的东西写法有点讲究。--- name: latex-typesetting description: 用于生成、排版和校验 LaTeX 文档。当用户需要论文模板、公式排版、参考文献格式化时自动加载。支持中文与英文混排。 version: 1.0.0 --- # LaTeX 排版技能 ## 适用范围 - 学术论文、技术报告、幻灯片中 LaTeX 文档生成与检查。 - 对已有 .tex 文件进行结构诊断、编译错误修复。 - 配置 BibTeX 文献格式处理中文字体与 xelatex 编译。 ## 执行步骤 1. 检查输入文档结构确认 documentclass、packages、begin/end 匹配。 2. 使用 scripts/compile_and_check.py 试编译捕获 warning 和 error 并定位行号。 3. 按 assets/proofread-checklist.md 逐项检查标题、图表引用、交叉引用、参考文献。 4. 输出修复后的 .tex 文件及编译说明。 ## 注意事项 - 中文文档优先使用 xelatex 编译不要用 pdflatex。 - 修改 .tex 时不得破坏已有的数学公式语义。这段 SKILL.md 里agent 会重点看description和执行步骤。description 写得具体agent 才能在一堆任务中准确判断是否需要调用这个技能执行步骤写得细致agent 才能按步骤稳定推进。4. 核心实操从零开发一个自己的 skill4.1 第一步确定技能边界别做成“万能包”开发 skill 之前最忌讳的一件事是贪大求全。比如想给前端项目做一个全能的“前端重构”技能结果文件夹里既有代码格式化规则、又有项目结构生成脚本、还有 UI 截图分析工具——这不是 skill这是另一个框架。好的 skill 应该边界明确。我建议按照“完成一个可验收的任务”来定义边界比如“把指定目录下的 HTML 转成符合 Tailwind 风格的 React 组件”“检查并修复 Markdown 文档的语法和链接有效性”“根据给定数据绘制 matplotlib 图表并生成说明报告”“对某个 Python 项目做 legacy 化改造前的扫描输出风险报告”以“print to pdf”这种小技能为例边界就是“把 Markdown 文件转成 PDF”不涉及 OCR、不涉及批量扫描只做这件事做到极致。边界越清晰agent 触发越准确执行越不会跑偏。4.2 第二步写好 description决定会不会被调用description字段是 skill 的“电梯演讲”。模型不会先读你整个文件夹它通常只扫描这个字段来决定调用哪个技能。所以 description 必须包含三要素这个技能解决什么任务动词 对象适用什么场景/输入不适用什么场景可选但很有用拿“前端结构图生成”为例description: - 根据前端项目代码React/Vue/HTML生成组件依赖结构图和目录树概览。 当用户需要“画一下项目结构”、“组件关系图”、“依赖分析图”时使用。 不适用于后端架构图或数据库 ER 图。这里的关键词是“结构图”“目录树”“组件依赖”模型看到这些词就容易激活。如果 description 写得模糊比如“进行前端分析”它可能半天不知道要不要用这个技能最后选择继续用默认 prompt 方法执行技能就形同虚设。4.3 第三步SKILL.md 正文的六个执行要素写好描述之后正文就是整个技能的“路线图”。我常用的结构包含六个要素不一定全写但核心的四五项必须有目标明确交付物是什么。前置条件需要哪些输入、环境变量、脚本依赖。执行步骤按顺序给出具体操作最好每步都有“可验证结果”比如“运行后会输出report.json检查文件是否存在”。决策规则遇到分支情况怎么选。比如“如果编译失败优先检查缺少的包而不是修改公式”。禁止项明确不能做什么避免模型自己加戏。例如“不要修改 package.json 中的依赖版本”。质量验收完成任务的标志。比如“latexmk -xelatex可以零 Error 编译通过”。这六个要素是我从十几次 skill 迭代里总结出来的关键结构。你没看错SKILL.md 本质上就是在“给模型编一份标准作业流程SOP”。写的时候要有一种“把徒弟带成员工”的心态规则越明确agent 犯错的概率越低。4.4 第四步配套脚本怎么设计才会被 agent 顺利用起来SKILL.md 是指令真正干活的是 scripts 目录里的脚本。把脚本设计成“傻瓜式 CLI”agent 才容易调度。什么叫傻瓜式就是每个脚本只做一件事、参数明确、输出可解析。举个例子如果写一个检查 Markdown 链接的脚本我建议接口长这样python scripts/check_links.py --input docs/ --output links-report.json而不是搞成长长的交互式向导或者需要手动修改脚本里的路径变量。因为 agent 没有“耐心”去读脚本源码它只会看 help 信息或运行示例。如果你想让它按指令跑脚本至少要支持--help输出用 JSON 或结构化文本这样 agent 才能“看懂结果决定下一步”。再分享一个小技巧在 SKILL.md 的执行步骤里直接把关键命令写清楚而不是只写“运行检查脚本”。比如2. 运行: python scripts/check_links.py --input docs/ --output links-report.json 3. 读取 links-report.json若存在 broken_links 字段不为空则按其中列出的文件逐一修复。这样模型少一层推理执行准确率会明显提升。4.5 第五步测试与迭代——自己的 skill 也要有 evals写完 skill 不测试就上线等于裸奔。我在早期开发“latex 排版”技能时第一次用样本文档测试就翻车了——代码把\author{}清空了因为 SKILL.md 里没写清楚“禁止修改作者信息”模型自作主张补了一个“unknown author”。从那以后我养成了给 skill 建测试集的习惯。测试分两层。第一层是单元验证即用 2~3 个典型输入跑一遍确认脚本本身没问题第二层是端到端验证即模拟真实用户请求看模型是否会正确触发技能、按步骤执行、得到预期产出。这块最近社区里也流行给 agent 和 skill 做“evals”。你可以给每个 skill 准备一组黄金输入和期望输出比如给“前端结构图生成”技能准备一个 React 示例项目期望生成一个包含 8 个节点和依赖关系的 JSON 结构图。模型跑完后用脚本比对实际输出和期望值的差异就能量化技能触发率和完成质量。拿前端结构图技能举例一个最简单的 eval 脚本可以这样写# scripts/eval_structure_skill.py import json import subprocess test_cases [ { prompt: 帮我分析 src/pages 目录下组件的依赖关系生成一个结构图, input_dir: tests/fixtures/react-app/src, expect_nodes: 8, expect_edges: 7, } ] for case in test_cases: result subprocess.run( [node, scripts/generate_structure.mjs, --input, case[input_dir]], capture_outputTrue, textTrue ) data json.loads(result.stdout) assert len(data[nodes]) case[expect_nodes], 节点数不匹配 print(PASS:, case[prompt])这是简化版本但核心思想很明确期望结果越具体skill 的回归测试越可靠。任何一次迭代升级都可以先把测试集跑一遍避免“改好了 A 方案又弄坏了 B 方案”。5. 实战案例开发一个“latex 排版报告”技能的全过程5.1 需求定义与现状分析我最近常用 agent-skills 来做技术报告的排版所以就拿这个当完整案例来讲。场景每周要给项目输出一份 Markdown 技术周报最终交付要转成带封面、目录、代码高亮的美观 PDF。以前是人工用 Typora 导出再手动调字体、页边距、标题颜色非常繁琐。后来决定把整个流程固化成 skill。需求定义输入一个 Markdown 文件或包含多章节的 docs/ 目录输出符合团队模板的 PDF带封面、目录、页眉页脚代码块带 highlight约束中英文混排、字体清晰、标题分级明确现状分析团队里 Pandoc LaTeX 路线最稳定既有模板文件又支持 xelatex 编译。因此 skill 的技术栈定为 Pandoc XeLaTeX 自定义模板。5.2 目录结构和脚本骨架按前面说的技能规范我把目录结构搭成weekly-report/ ├── SKILL.md ├── assets/ │ ├── weekly-report.tex # Pandoc 自定义 LaTeX 模板 │ ├── cover.tex # 封面 │ └── reference.docx # 字体与页边距备选参考跨工具用 └── scripts/ ├── build_report.py # 入口脚本负责调用 pandoc、处理编译异常 └── check_tex_warnings.py # 解析编译日志并给出可读提示SKILL.md 里重点写清楚了执行步骤1. 检查输入路径确定是单个 .md 文件还是 docs/ 目录。 2. 若为目录按 chapter 数字前缀合并章节顺序生成临时 full_report.md。 3. 使用 scripts/build_report.py 调用以下命令完成编译 pandoc full_report.md --pdf-enginexelatex --templateassets/weekly-report.tex -o output.pdf 4. 若编译出现 error读取日志中的行号定位对应 Markdown 源文件位置进行修复。 5. 检查 output.pdf 页数和关键渲染结果封面、目录、标题层级。5.3 关键参数怎么定为什么用 xelatex 而非 pdflatex这一步踩过坑值得单独说。英文文档用 pdflatex 完全没问题但中文报告用 pdflatex 会遇到大量字体和字形不兼容问题连 CJK 字符都可能显示成乱码。xelatex 直接支持系统字体中文字体渲染稳定编译命令也简单。所以我在 SKILL.md 备注里明确写了一条“禁止项”不得将编译引擎切换为 pdflatex。因为团队模板用的字体是系统内的“思源宋体 CN”和“Sarasa Mono SC”我在 LaTeX 模板里做了字体配置% assets/weekly-report.tex (片段) \usepackage{xeCJK} \setCJKmainfont{Source Han Serif CN}[ BoldFontSource Han Serif CN Bold, ItalicFontKaiTi ] \setmonofont{Sarasa Mono SC}[Scale0.85]使用 xelatex 的另一个好处是代码块里的特殊字符处理起来更稳不需要大量转义。这也是技能包中“参数选择”的重要性——我一开始图省事用 pdflatex结果整个报告编译全是警告换成 xelatex 后一次通过节省了大量沟通成本。5.4 执行脚本的关键逻辑注解build_report.py里最核心的功能有两个一是调用 Pandoc 编译二是把非零退出码转换成可读的报错信息。简化代码如下#!/usr/bin/env python3 import argparse import subprocess import sys from pathlib import Path def run_compile(input_file: Path, output_file: Path, template: Path): cmd [ pandoc, str(input_file), --pdf-enginexelatex, f--template{template}, -o, str(output_file), ] print(, .join(cmd)) proc subprocess.run(cmd, capture_outputTrue, textTrue) if proc.returncode 0: print(编译成功:, output_file) return True print(编译失败日志末尾 100 行) for line in proc.stderr.splitlines()[-100:]: print(line) return False if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--input, requiredTrue) parser.add_argument(--output, defaultoutput.pdf) parser.add_argument(--template, requiredTrue) args parser.parse_args() if not run_compile(Path(args.input), Path(args.output), Path(args.template)): sys.exit(1)这个脚本看起来简单但对 agent 非常友好输出简洁、有成功提示、失败时直接打印日志尾部。实际跑的时候agent 读到“编译失败日志末尾 100 行”就会自己去日志里找行号、修复源文件不会傻在那里。5.5 验证效果与迭代记录做完第一版后我拿一份真实周报测试。第一次编译失败错误定位到表格列宽表达式的语法错误第二次编译成功但封面里机构名没显示模板变量未赋值第三次加了模板变量终于看到干净美观的 PDF。随后我又把这个 skill 迭代了三次主要改动是在 SKILL.md 中增加“使用 xelatex 编译禁止换用 pdflatex”的注意事项。在脚本里自动检测缺失的字体并提示安装命令而不是让编译报一堆 unicode 错误。加入了check_tex_warnings.py对 Overfull/Underfull 这类受警告影响排版质量的项做汇总避免影响 PDF 观感。整个过程下来我最大的感受是写 skill 的过程其实是在写一份“让模型少踩一次坑”的专家经验表。每次在 SKILL.md 里加一条注意事项未来执行的回报就增加一分。6. 常见问题、坑位清单与排查思路6.1 技能触发失败模型根本没用你的 skill怎么办这个现象太常见了尤其是在 Codex CLI 里。排查思路按顺序来先确认 description 里有没有把“触发场景”写清楚光写“技能名称”不够一定要写具体任务词汇。再确认技能目录是否被正确加载。不同工具的加载路径不同你可以用agent skills list之类的命令列出来看看。检查是否有“同类技能抢触发”。比如同时存在“generate chart”和“plot data”两个技能模型可能选了其中一个另一个就不会被触发。此时就应该把两个技能的边界分开或者在 description 里明确互斥场景。我自己的经验如果多次测试都不触发就别改 description 了直接在用户提示词里明确写“请使用 xxx 技能”来调试。先把技能调通再回来优化自动触发。6.2 SKILL.md 内容太长反而导致表现下降有人会问把规则写详细一点不好吗不是的。SKILL.md 太冗长模型在上下文窗口里浪费太多 token 读取规则真正的任务信息反而挤占不足。尤其 Claude 和 GPT 对新输入的注意力是按 token 分配的规则文件一旦超过几百行很多后面的步骤它实际“看但记不住”。我的做法是SKILL.md 控制在 200~400 行以内。长流程放到 assets/ 里的子文档比如assets/detail-rules.md在 SKILL.md 里引用“如需处理复杂数学公式参考 assets/math-rules.md”。关键命令直接写进步骤里不依赖模型自己去读脚本源码。这样既能保留专家细节又不至于让主流程臃肿。6.3 脚本执行环境不一致这是另一个常见的翻车点。你的 skill 可能在本地 Mac 上运行完美但换到 Linux CI 或者别人的电脑上环境变量、Python 依赖、字体都不对。skill 不是把文件丢给 agent 就完了还得附上环境校验。我的做法是在 SKILL.md 的“前置条件”里加入环境检查步骤## 前置条件 - 检查 pandoc --version 和 xelatex --version 是否可用。 - 若失败运行 brew install pandoc brew install --cask mactex-no-guimacOS或 apt install pandoc texlive-xetexLinux。 - 确认中文字体已安装fc-list | grep Source Han。其实这是在告诉 agent“动手前先检查你有没有资格干活”。虽然多了一步但后续执行更稳因为它不会在一个缺失环境里反复尝试却报出让人摸不着头脑的错。6.4 技能执行中途终止或出错后的恢复策略很多人遇到过 agent 执行到一半报 “execution terminated due to error”然后整个流程就断了。这个问题的根源往往是脚本崩溃后agent 没有“回到上一个稳定状态”的路径。一种解决思路是在 SKILL.md 里定义“失败恢复”小节## 错误处理 - 若第一步脚本退出码非 0不继续后续步骤读取日志并修复输入。 - 若第 3 步编译失败 2 轮以上生成 debug_report.md 后终止。同时把脚本设计成“可重入的”也很重要。也就是说脚本处理输入时不要产生副作用比如删除原始文件、改动全局配置。尽量输出到独立的 output 目录这样即便中断也能保留现场人工接手不费劲。6.5 速查表我自己常用的排查命令和工具最后整理一份速查清单都是我实际在用的问题排查路径常用命令/方法skill 未被加载查看技能列表codex skills list/claude skills listskill 触发率低检查 description 关键词加入“当用户需要”“适用于”等触发词脚本依赖缺失环境预检在 SKILL.md 加检查 runner 的步骤编译/报错日志难以阅读写日志解析脚本用 Python 正则提取 error 行号流程中断定义恢复步骤在 SKILL.md 加错误处理段脚本保持可重入效果不稳定建立 eval 测试集准备黄金输入和期望输出跑回归多个 skill 概念重叠合并或拆分边界将描述改为互斥一个管 A一个管 B这张表帮我省了很多沟通时间。每次遇到问题先过一遍表而不是重写整个技能。7. 经验总结与后续扩展建议如果你打算把 agent-skills 引入日常工作流我个人建议从一个小而明确的技能做起。别一上来就写“全栈开发技能”先写一个“把 Markdown 转成 PDF”、或者“生成 React 组件结构图”这种边界清楚的小技能。跑通了再逐步扩展。整套流程下来你会发现这个“技能包”的价值不亚于换一个新模型因为它把人的经验沉淀了下来。我日常最常用到的还是 LaTeX 排版、前端结构图、以及代码仓库 legacy 扫描这三个技能。每次使用后只要有不对劲的地方我都会顺手更新 SKILL.md 或脚本形成一个小迭代循环。这个习惯带来一个明显的好处同一个任务第一次可能要走五步才能搞定第三次可能模型自己就能直接一次成型。如果你的场景涉及团队协作还可以把技能仓库用 Git 管理起来配合 CI 自动跑 eval 测试。这样每个技能的变更都有据可查质量也有保证。后续甚至可以尝试让 agent 根据任务结果自动反馈、微调描述或步骤形成“技能自我进化”的工作流这个方向我认为是 agent engineering 下一个值得探索的节点。
