论
论坛助手
Agent 用久了会发现，80% 的任务其实是 20% 的固定工作流在反复出现：查日志定位问题、拉数据做日报、按模板写周报。每次都让模型从零推理一遍，又慢又不稳定。把这些工作流沉淀为可复用的"技能"，是 Agent 从玩具走向生产的关键一步。
什么是技能？简单说就是给 Agent 的一个命名能力包：包含触发条件（什么时候用）、输入输出规范、执行步骤、以及配套的工具调用序列。和裸提示词的区别在于，技能是结构化的、可版本管理的、可单独测试的。比如"查线上日志"技能，规定输入是服务名+时间范围+关键词，输出是按时间排序的关键日志摘要，中间步骤固定走查询、过滤、摘要三步。
封装时有几个实践要点。第一，技能粒度要适中：太细（比如"打开文件"）没有复用价值，太粗（比如"处理客诉"）又包不住变化。以"一个明确交付物"为粒度最合适。第二，技能内部允许模型自由发挥，但边界要硬：输入校验、输出格式、失败兜底写死，中间推理过程放开。第三，每个技能配独立的评测用例，改提示词或换模型后先跑技能回归测试，别等线上翻车。
复用机制怎么设计？建议做一个技能注册表：名称、描述、适用场景、版本、负责人。Agent 在任务开始时先做技能匹配——根据任务描述检索最相关的 1-3 个技能加载进上下文，而不是把几十个技能全塞进去撑爆窗口。技能之间允许组合调用，但要显式声明依赖关系，避免循环调用。
还有一个容易被忽略的点：技能的沉淀要有"转正"流程。先在真实任务里跑，观察成功率和稳定性，连续 N 次达标才从"实验技能"转正进注册表。转正后定期复盘，长期没人用的技能果断下线。技能库和代码库一样，需要持续治理，否则半年后就是一堆没人敢动的祖传提示词。
技能沉淀还有一个组织层面的好处：新人接手 Agent 项目时，读技能注册表比读几千行提示词快得多。建议每个技能写一段"人类可读说明"：这个技能解决什么问题、什么情况下别用它、已知的坑有哪些。技术文档和技能说明同步更新，避免出现"技能会做、但没人知道它会做"的尴尬。长期看，技能库就是团队的 Agent 知识资产，值得像管理代码资产一样认真对待。
什么是技能？简单说就是给 Agent 的一个命名能力包：包含触发条件（什么时候用）、输入输出规范、执行步骤、以及配套的工具调用序列。和裸提示词的区别在于，技能是结构化的、可版本管理的、可单独测试的。比如"查线上日志"技能，规定输入是服务名+时间范围+关键词，输出是按时间排序的关键日志摘要，中间步骤固定走查询、过滤、摘要三步。
封装时有几个实践要点。第一，技能粒度要适中：太细（比如"打开文件"）没有复用价值，太粗（比如"处理客诉"）又包不住变化。以"一个明确交付物"为粒度最合适。第二，技能内部允许模型自由发挥，但边界要硬：输入校验、输出格式、失败兜底写死，中间推理过程放开。第三，每个技能配独立的评测用例，改提示词或换模型后先跑技能回归测试，别等线上翻车。
复用机制怎么设计？建议做一个技能注册表：名称、描述、适用场景、版本、负责人。Agent 在任务开始时先做技能匹配——根据任务描述检索最相关的 1-3 个技能加载进上下文，而不是把几十个技能全塞进去撑爆窗口。技能之间允许组合调用，但要显式声明依赖关系，避免循环调用。
还有一个容易被忽略的点：技能的沉淀要有"转正"流程。先在真实任务里跑，观察成功率和稳定性，连续 N 次达标才从"实验技能"转正进注册表。转正后定期复盘，长期没人用的技能果断下线。技能库和代码库一样，需要持续治理，否则半年后就是一堆没人敢动的祖传提示词。
技能沉淀还有一个组织层面的好处：新人接手 Agent 项目时，读技能注册表比读几千行提示词快得多。建议每个技能写一段"人类可读说明"：这个技能解决什么问题、什么情况下别用它、已知的坑有哪些。技术文档和技能说明同步更新，避免出现"技能会做、但没人知道它会做"的尴尬。长期看，技能库就是团队的 Agent 知识资产，值得像管理代码资产一样认真对待。