企业官网建设流程全解析

我最近一个月的大部分工作时间，都耗在了一个叫agent-skills的项目上。说得直白一点，就是给AI智能体做一套可复用的技能库。最开始我以为这不过就是多写几段system prompt，真正动手以后才发现，这是一套从需求拆解、技能描述、工具绑定到回归测试的完整工程。这篇文章不聊概念，也不吹泡沫，只讲我在落地agent-skills时踩过的坑和沉淀下来的方法。如果你正在做智能体应用、给agent扩展专业能力，或者维护一套内部自动化机器人，这篇内容应该能帮你少走不少弯路。

1. 先搞清楚：agent-skills到底是什么，为什么值得投入

1.1 从“会聊天”到“会干活”，技能才是分水岭

先说一个我在项目群里反复强调的观点：没有技能的agent，本质上只是一个知识面很广但缺乏专业流程的“新人顾问”。你让它回答常识问题，它可以讲得头头是道；但你要它按照公司规范生成一份采购验收单、按特定格式整理竞品信息、或者联动多个接口完成一次数据核对，它就开始“自由发挥”了。原因很简单——模型没有一套固定的执行路径，每次都在临时推理，结果自然不稳定。

agent-skills要解决的问题，就是把这种“临时推理”变成“专业动作”。一个技能，可以理解成一个独立封装的专业能力单元：它包含一段职责明确的提示词、一组约定好的输入输出参数、可能需要调用的工具接口、以及判断结果是否合格的质量标准。模型在运行时通过技能描述来决定调用哪个技能，然后按技能内部定义的步骤执行。这样做的好处非常明显：同一个技能可以被不同场景反复使用，核心逻辑只维护一份。

对比一下就清楚了：

我并不是说prompt不重要，而是prompt解决的是“对话质量”，技能解决的是“任务完成质量”。两者之间隔着一套工程化方法，这也是agent-skills项目里最核心的投入方向。

1.2 技能库到底解决了哪些真问题

我挑三个在实际业务中最痛的点来说。

第一个是稳定复现。同样一个任务，上午跑是合格的，下午跑就开始漏步骤，这是很多agent应用的常态。根本原因是模型每次推理都有随机性，流程一旦复杂就容易走偏。技能把执行步骤固化下来之后，相当于给模型提供了一条带护栏的路径，任务完成率能明显提升。我在自己的项目里做了一个对照组：未接入技能库之前，一套周报生成任务的通过率大概只有64%；接入标准化技能后，同样的测试集通过率涨到了88%，而且输出字段很少再出现缺失。

第二个是组合复用。业务中真正复杂的任务，往往由多个基础能力叠加而成。技能库的意义在于，你先沉淀出一批“原子技能”，比如信息抽取、格式化输出、数据库查询、文档摘要，然后上层业务通过编排方式把它们组合起来。新场景来了，不需要从零写指令，而是重新组合已有技能。这个思路和代码里的函数复用是同构的，开发效率提升非常明显。

第三个是迭代可控。没有技能库的时候，你想优化某个环节，只能修改整段系统提示词，改完还担心其他任务被带偏。有了技能边界，你只需修改对应的那一个技能，再用它的回归测试集验证即可。这种局部修改能力，在团队协作时尤其重要——不同成员可以各自维护技能模块，互不影响。

1.3 谁最需要做技能工程

我接触过的团队里，真正能把技能库用出价值的，普遍是这几种类型：正在开发智能客服或行业助手的产品团队；企业内部自动化流程的交付团队；以及做RAG增强问答、但希望进一步扩展到任务执行层面的开发者。如果你的agent只是偶尔跑一次、对输出格式没有硬性要求，那确实不需要建技能库。但只要你开始追求稳定交付、要求结果可复现，技能工程就是迟早要做的事。早做比晚做轻松，因为技能边界一旦混乱，后期重构成本远远高于一开始就设计好。

2. 搭建技能库之前：先做需求拆解与技能边界划分

2.1 需求拆解：把业务场景拆成“最小可教单元”

很多人在建技能库时犯的第一个错误，是直接对着文档开始写技能提示词，跳过了需求拆解。这就像没列菜谱就下锅，最后做出来的东西自己都说不清是哪个菜系。

我的做法是先从用户任务出发，倒推出这个任务需要哪些“可教单元”。所谓可教单元，就是模型必须掌握的一类特定行为或知识。判断标准有三个：这个行为是否有明确的输入和输出？这个行为是否可以被独立验证？这个行为是否可能在多个场景复现？三个条件都满足，才值得建模成一个技能。

拿我最近做的一个“会议纪要整理”技能来举例。表面上看，用户需求是“给一段会议录音，输出纪要”。但你把它拆开后会发现，背后包含至少四个可教单元：

• 说话人分离与角色识别：谁在会议上说了什么、TA是什么身份；
• 议题提取：会议讨论了哪几个核心主题；
• 决议与待办提取：最后定下来的事项、分配给谁、截止时间是什么；
• 纪要标准化格式化：按公司模板输出为指定结构。

这四个单元里，前两个偏抽取能力，第三个偏逻辑归纳，第四个偏格式约束。它们适合做成独立技能，由上层一个“会议纪要总控”技能来调用，而不是揉在一个巨大的提示词里。揉在一起的结果就是，你想单独优化议题提取质量，却不得不把整个纪要流程全部测试一遍，效率极低。

2.2 技能边界划分的三个判断问题

拆出候选技能后，接着要判断它的边界是否合理。我一般会对着每个技能问三个问题。

第一个问题：这个技能的触发条件是否足够清晰？也就是说，当agent拿到一个输入时，能不能明显判断出“该用它了”。如果触发条件过于模糊，agent就可能在不该用的时候用了，或者该用的时候绕过去了。第二个问题：这个技能是否只做一件事？如果一份技能提示词里有“既能做摘要，又能做翻译，还能做关键词提取”的表述，那它就不是一个技能，而是三个技能挤在一起，应该拆开。第三个问题：这个技能的输出是否能被稳定校验？如果一个技能的输出结果连你自己都无法判断好坏，那模型更无法自我修正，这种技能上线后基本等于失控。

我用这三个问题砍掉过不少看起来很美、实际无用的候选技能。比较典型的例子是一个“智能分析”技能，触发条件写的是“当用户需要深度分析时触发”，输出是“一段全面且有洞察力的分析内容”。它几乎无法被验证，最终被我拆成了“数据差异分析”“竞品动态归纳”“风险点识别”三个更具体的技能，效果立刻改观。

2.3 技能描述与触发条件设计

技能描述是agent进行技能选择的“路由表”。我一般要求每个技能都有一个精简的description字段，用两三句话说明：这个技能是做什么的、适合处理什么类型的输入、不适合处理什么。不要在description里堆功能点，因为模型在做选择时使用的是语义匹配，堆得越多越容易误触发。

真正执行细节放在技能内部，而不是放在触发描述里。这个区分非常重要。我在早期犯过一个错误，为了让一个技能看起来更专业，把它的description写成了半页小作文。结果agent在遇到一类相似的、甚至轻微沾边的任务时，都会优先选它，导致外部场景频繁被错误路由到这个技能上。后来我把description压缩为“用于处理XX类输入，输出YY结构”，误触发率大幅下降。

如果两个技能的适用场景天然存在重叠，那就必须在description里主动写明排他条件。比如“周报生成”和“月报生成”两个技能，我会在后者描述里加一句“当输入明确提到月度时间范围或月度复盘时使用，否则优先调用周报技能”。这种排他约束，能明显减少技能互掐的现象。

3. 核心实操：从零构建一个可复用的agent技能

3.1 先定义清晰的输入、输出与前置依赖

写技能提示词之前，我习惯先定义一个类似接口规格的说明，把输入、输出、依赖写清楚。这样做的原因是，你写的提示词最终会被模型按需调用，模型需要从用户请求中提取参数；如果接口定义不清晰，参数提取就会出错，后面所有步骤都是错的。

这是一个简化的技能元信息示例：

name: meeting_minutes_summary description: 用于将会议记录或会议录音转写文本整理成结构化会议纪要。 仅当输入内容来源为会议场景时使用；如果输入是普通文档或文章，不要使用本技能。 version: 2.1.0 inputs: transcript: string，会议转写全文，必填 participants: array<string>，参会人列表，可选 template: string，纪要模板名称，可选，默认为"standard" outputs: summary: string，会议概要，不超过200字 decisions: array<{item: string, owner: string, due_date: string}> 会议决议及待办事项列表，按优先级排列 dependencies: tools: []

我特别推荐把元信息单独放在技能正文前面，而不是混在提示词里。因为很多agent框架在加载技能时，会先读取这块元信息来决定是否调用该技能。单独拆出来，模型选择技能时读取成本更低，命中率更高。另外，版本号一定要有，技能迭代频繁，没有版本管理你会很快陷入“现在线上跑的到底是第几版”的混乱。

这部分的另一个价值是帮你发现“假依赖”。如果你写的元信息里列出了某个工具，但实际执行中该工具对最终结果没有显著影响，就把它删掉。多余的依赖意味着额外的延迟和错误概率。

3.2 编写技能提示词：结构、步骤、好坏对比

元信息定义完之后，真正的主体部分是技能提示词。我通常按照“角色与目标→执行步骤→输出约束→校验规则”四段式来写。每一段都有明确任务，不能让模型猜。

我这里给一个经过多次调优的参考模板，你可以直接改造成自己的技能。

# 角色 你是一个会议纪要整理专家，负责把口语化的会议转写内容整理成规范的中文会议纪要。 # 目标 根据输入的会议转写文本，输出包含会议概要、议题列表、决议与待办事项的Markdown文档。 # 执行步骤 1. 通读全部转写内容，提取参会发言人及其主要观点。 2. 归纳本次会议的核心议题，每个议题归纳成一个短句。 3. 从转写内容中提取明确决议事项；如果没有明确决议，标记为“无明确决议”。 4. 提取所有待办事项，包括负责人、截止时间和具体事项；信息缺失时输出“待确认”，不要自行推断。 5. 按以下固定结构组装输出： ## 会议概要 ## 议题列表 ## 决议与待办事项 # 输出约束 - 使用简体中文。 - 会议概要不超过200字。 - 待办事项使用有序列表，每一项格式为：- [事项]｜负责人：XXX｜截止：YYYY-MM-DD。 - 不添加无依据的推测内容。 # 校验规则 - 检查每一项待办是否包含“负责主体”和“时间节点”；若缺失，标注“待确认”。 - 检查输出中是否有与转写内容矛盾的信息；若有，重新阅读原文修正。

你可能已经注意到，这条提示词里几乎没有“要细心”“请准确”之类的主观形容词，全部是可执行的行为描述。“不要自行推断”和“待确认补位”这种约束，比“请确保信息准确”要有效得多。模型其实分不清“准确”这种模糊词，但能理解“缺失时输出待确认，不要生造”这种明确指令。

写技能提示词最忌讳的是堆砌形容词。我见过有人写“请以最专业、最严谨、最全面的方式处理”，这类表述只会占用上下文空间，对结果几乎没有正向影响。真正管用的是给模型一条清晰的行为通道：先做哪步、遇到什么情况怎么办、输出长什么样。

3.3 用工具调用把技能从“动嘴”变成“动手”

很多有价值的技能只靠模型内部知识是完不成的，比如查实时数据、执行计算、读写数据库。所以技能工程一定绕不开工具调用。我的建议是：技能提示词负责“怎么用工具”，工具注册信息负责“工具是什么”，两件事分开管理。

这段是一个工具注册信息的示例，我用一个汇率查询工具来说明。

{ "name": "exchange_rate_query", "description": "查询指定日期或最近工作日的货币汇率，支持USD/CNY、EUR/CNY等常见货币对。", "parameters": { "type": "object", "properties": { "from_currency": { "type": "string", "description": "源货币代码，如USD" }, "to_currency": { "type": "string", "description": "目标货币代码，如CNY" }, "date": { "type": "string", "description": "查询日期，格式YYYY-MM-DD，可选" } }, "required": ["from_currency", "to_currency"] } }

工具调用最关键的一点是：工具的返回结构必须稳定。我踩过一个很深的坑——某个外部接口在无数据时返回空字符串，在异常时返回错误码，在正常时返回一个嵌套很深的JSON。结果技能在处理返回结果时经常解析失败，模型的推理链路随机中断。后来我把所有工具都加了一层统一包装，无论内部接口返回什么，统一转成“status + data + message”的结构，技能提示词里也只针对这一种结构做描述。从那以后，工具类技能的稳定性上了一个大台阶。

实操中还有一个经验：模型生成的工具参数往往不够规范，比如日期写成“今天”、货币写成中文“美元”。你在提示词里要给模型规定参数抽取规则，比如“所有日期字段必须转换为YYYY-MM-DD格式”“货币代码必须使用标准三位代码”。否则工具接口会频繁报参数错误。

4. 技能评估与迭代：别让技能库变成垃圾堆

4.1 怎么客观评估一个技能好不好

没有评估体系，技能库很容易失控。我在项目里推行了一套轻量级评估指标，不需要复杂的标注团队，你自己就能跑起来。

日常我重点盯四个指标：

最核心的动作是建一个回归测试集。我每个技能在第一次稳定运行后，就固定保留20到30条代表性输入，这些输入要覆盖正常情况、边界情况和常见异常情况。每次修改技能后，我都拿这套测试集重新跑一遍。正常情况下，任务完成率应该保持稳定或上升；如果某个历史用例突然失败，我需要立刻知道改坏了哪里，而不是等到用户投诉才发现。

建议把测试集存成纯文本或JSON文件，方便后续自动化跑。我自己维护了一套简单脚本，自动把测试集喂给agent，检查输出是否包含必需字段，再生成一份评估报告。这一步的自动化程度越高，技能迭代速度就越快。

4.2 收集失败案例，定向优化

评估只能告诉你“坏了”，但分析“为什么坏”才是优化技能的关键。我把失败案例的排查流程固定为四步：第一步，打开原始输入和技能输出，看输出是否满足最基本格式要求；第二步，如果不满足，看是模型没理解指令，还是技能描述本身就模糊；第三步，如果格式满足但内容不对，就重点检查执行步骤是否有遗漏或顺序错误；第四步，如果内容大体正确但缺少细节，通常要补知识上下文或增加校验规则。

一个很常见的例子是：技能提示词里写了“提取会议所有待办事项”，但模型总是漏掉最后一条。排查发现，会议转写文本往往很长，模型读到后面时注意力衰减，早期内容里的待办事项容易被覆盖。我的解决方法是把输出约束改成“先列出所有潜在待办，再逐一回看原文确认”，相当于在流程里增加一道校验步骤，漏项问题明显减少。

技能也是要版本化的。我在元信息里的version字段不是摆设，每次行为变更都递增版本号，并在变更日志里记录变更原因。这样一旦线上效果波动，可以很快比对出是哪个技能、哪个版本引入的问题。没有版本控制，技能迭代就是一场灾难。

4.3 定期清理：不用的技能趁早归档

很多团队做技能库做久了，库里的技能数量会像滚雪球一样膨胀。但技能越多不代表能力越强，反而会造成两个问题：一是agent在选择技能时计算量增大、误触发的概率增加；二是维护成本直线上升，很多没人用的技能还在白白消耗你的测试精力。

我习惯每隔一个迭代周期做一次技能健康度检查，重点看使用频率和效果指标。一个技能如果连续数周没有被触发，或者触发后的任务完成率一直低于50%，就先把它放入归档区，而不是立即删除。归档后如果仍然没有需求回来，再彻底清理。这个策略既保证了技能库的精炼，又给了自己反悔的余地。

5. 常见问题与排查技巧实录

5.1 技能互相“打架”怎么办

技能多了以后，最典型的问题是同一份输入命中了多个技能，或者agent错误地调用了某个相似技能。我在项目里遇到过“数据清洗”技能和“数据转换”技能互相抢任务的情况，原因是两者的description里都写了“处理数据格式相关问题”。最后解决方式是在两个技能的描述中都增加排他条件，明确数据清洗注重“空值、重复值、异常值处理”，数据转换注重“格式映射、单位转换”，并且规定如果无法判断，默认走数据清洗。模型选择技能时语义重叠度降低，误触发率下降不少。

遇到技能冲突，排查思路是：先把命中的技能列表打出来，看哪些技能被同时触发；再逐个读它们的description，找出语义重叠的地方；最后通过修改排他条件或增加前提条件来解决。不要试图用“增强系统提示词权重”来解决，那只会让整个系统变得更加不可预测。

5.2 输出格式不稳定怎么办

输出格式不稳，是技能初期最常见的问题。模型有时会漏字段，有时会改变Markdown结构，有时会多输出一段解释性文字。我通常按照这个顺序排查：先检查提示词里有没用“必须”“禁止”“一律”等强约束词汇；再检查有没有给出具体的输出示例；最后看目标模型是否支持结构化输出能力。

给few-shot示例是收效最快的手段。哪怕只提供一组输入输出对，模型对格式的遵循程度也会明显提高。我在会议纪要技能的提示词里放入了一个简短的输出示例后，格式合规率从72%提升到了91%。如果业务允许，建议同时启用模型的结构化输出模式，用JSON Schema直接约束输出结构，但这需要和你的技能框架配合，不是所有场景都能直接用。

5.3 技能库膨胀导致效果下滑怎么办

技能库越来越大之后，另一个烦恼是agent每轮都要在大量技能描述里做选择。结果要么选错，要么犹豫不决，整体响应速度也变慢。我的经验是给技能做分组路由，比如按领域分组（数据分析、内容生成、办公辅助、接口操作），先让agent根据输入判断属于哪个分组，再在分组内部选择具体技能。这个“先分组、后选择”的方式能显著降低误触发率，同时提升响应速度。

另外，上下文里加载的技能数量也要限制。不要把全部技能描述都塞进上下文，只加载当前任务可能命中的那部分。很多agent框架已经支持按关键词或语义预检索技能，你可以利用这个能力做按需加载。实测下来，技能总数从40个压缩到每次只加载5到6个候选后，任务完成率提升了约12%，响应速度也快了不少。

5.4 工具调用返回数据解析失败怎么办

前面提到过，工具返回结构不稳定是一个大坑。除此之外，模型解析工具返回时还容易遇到一个问题——返回内容过长，导致上下文被撑爆，甚至把技能提示词冲掉。我的对策是为工具结果加摘要层：如果返回数据超过一定长度，就先用一个文本摘要模型或规则脚本做预处理，只把关键信息传回主技能。宁可多一步，也不要让工具结果干扰主流程。这个技巧在处理大量数据库查询结果、日志分析等场景时特别有用。

还有一点，工具调用失败时要给模型明确的“退路”。我在技能提示词里通常会写一句“如果工具调用失败，请输出固定错误提示并停止继续执行”。这样模型不会为了强行完成任务去编造虚假数据。宁可让任务失败，也不能让错误结果进入正式产出物，这个原则在做技能工程时一定要守住。

我在实际维护agent-skills的过程中最大的感受是：技能工程最忌讳的就是贪多求全。真正有价值的不是数量，而是一套能被精确唤醒、稳定输出、快速迭代的技能体系。我每次新增技能之前都会先问自己一句：这个能力能不能在未来至少三次场景里被复用？如果不能，那就先不写，等需求站住脚再说。就是这一条简单的过滤规则，帮我砍掉了至少一半的无效工作。