企业官网建设流程全解析

从“会聊天”到“会办事”，Agent Skills 才是智能体的分水岭

做 Agent 开发这几年，我最大的感触是：模型本身的聪明程度确实重要，但真正让一个智能体从“什么都懂一点”变成“能把事办成”的，往往是它手里的那套技能——也就是标题里这个“agent-skills”。

你可能也遇到过这种情况：同一个大模型，有人用它搭出来的助手只会陪聊，有人却能做出一套能查库存、改订单、写周报的多面手。差别在哪？就在技能体系的设计和积累上。Agent Skills 不是某个工具的新名词，而是一套让智能体具备“可复用、可编排、可成长”能力的方法论。这篇文章不聊那些虚的概念，我直接用自己实操过的分层设计、技能注册、编排调度和评估迭代经验，把它拆开讲清楚。无论你是在做个人效率助手，还是企业级智能体平台，这套思路都能直接落地。

1. Agent Skills 的本质：先搞清楚技能在智能体里扮演什么角色

1.1 从一次对话说起：技能是怎么参与工作的

先看一个最简单的场景。用户对智能体说：“帮我把这周五的项目周报整理出来，顺便提醒团队三位同学。”

这个请求看起来不复杂，但背后至少涉及三类能力：一是理解文档内容、提炼要点的文本处理能力；二是根据人选查找通讯录、发送消息的对接能力；三是维护一个待办清单、在周五触发的调度能力。如果智能体只是把这段话丢给大模型去“自由发挥”，结果大概率是：周报格式漂移、提醒对象搞错、时间节点丢失。

有了技能体系之后就不一样了。智能体会先把用户请求拆解成“写周报”“查通讯录”“建提醒”三个子任务，然后分别匹配到对应的技能模块。每个技能模块像一个封装好的函数：输入“原始会议记录和本周数据”，输出“一份格式规范的周报”；输入“人名”，输出“通讯录中的联系方式和 IM 地址”。大模型在这里扮演的是“调度员+翻译官”，而不是“每一行代码都要自己写的苦力”。

换句话说，Agent Skills 的本质是把智能体需要具备的专业能力，从模型参数中剥离出来，放进一个可维护、可复用、可独立更新的能力层。这个能力层既可以承载确定性逻辑（查数据库、算金额），也可以承载模型自身的推理能力（总结、分类、生成），还可以关联外部工具链（发消息、调接口、跑脚本）。

1.2 技能、工具、提示词：三者的区别和关联

很多刚开始接触技能体系的同学，会把 Agent Skills 和“提示词”或者“工具调用”混为一谈。我自己的理解是这样的。

提示词是“怎么引导模型说话”的模板，它是静态的，每一次调用都需要重新组织上下文；工具是一段独立的 API 或脚本，它是确定性的，输入和输出都很严格；而技能介于两者之间，是一个“完整的工作单元”：它包含触发条件、输入参数、执行逻辑、输出格式、异常兜底，甚至还可以包含一小段专门针对这个任务的提示词。

你可以在一个工具上面套一层技能。比如“查询天气”是一个工具，但“为出行计划提供天气建议”是一个技能——它不仅要查天气，还要结合出行时间、目的地的场景做整合。你也可以在一个技能里面编排多个工具。比如“生成项目周报”这个技能，可能要调用“读取周会议记录”“读取代码提交统计”“调用大模型生成摘要”“格式化输出”四个工具。

所以我的经验是：提示词是技能的一部分，工具是技能的一种底层资源，而技能是对两者以及更多元素的有机组合。想明白了这一层，你设计技能体系时才不会跑偏。

1.3 技能类型全景：原子技能、组合技能、软技能

把技能按功能边界分个类，开发和维护的心态都会清楚很多。

原子技能是最小可执行单元，通常对应单个工具或单个逻辑块。比如“获取文件元数据”“发送钉钉消息”“计算两个日期之差”。这类技能的特点是职责单一、测试容易、几乎不需要大模型参与推理。

组合技能则是在原子技能之上编排出来的、有明确流程的能力。比如“处理客户退款”，它可能要依次调用“核对订单状态”“计算可退金额”“执行退款接口”“发送通知”。组合技能可以有自己的状态机，也允许在中途根据结果分支跳转。

还有一类容易被忽视的是“软技能”。它不直接对接工具，而是承载一种思考方式或表达规范。比如“会议纪要写作风格”“代码风格审查”“安全合规检查”。这类技能的核心是一段高质量的提示词和一系列规则约束。看起来不硬核，但在实际产品中，软技能往往决定了用户体验的专业度。

我一般建议二八原则：体系里百分之八十是原子技能，百分之十五是组合技能，百分之五是软技能。比例失衡的时候，要么系统散成一地碎片，要么变成了一个大而笨重的“超级提示词”，这两种状态维护起来都痛苦。

2. 技能体系怎么设计：分层、粒度与注册机制

2.1 三层技能栈：通用层、业务层、专用层

设计技能体系的第一步，不是急着写技能，而是先把目录结构定下来。我习惯把技能仓库分成三个层级。

通用层放的是与具体业务无关的能力，比如“基地语言翻译”“长文本摘要”“表格转 Markdown”“意图识别”。这一层可以在不同项目里直接复用，相当于自己攒的基础工具库。

业务层服务于特定领域，但相对稳定。比如做客服智能体，业务层会有“订单查询”“物流轨迹解析”“售后工单创建”；做内容创作助手，业务层则有“选题推荐”“文章结构化”“多平台适配改写”。

专用层是面向具体场景和活动定制的，往往需要频繁调整。比如“某次营销活动的用户反馈分类”“某版本更新后的 Bug 报告摘要”。这些技能生命周期短、变化快，建议和长期技能做隔离，这样你在更新时不会影响主链路。

我踩过一个大坑：一开始图省事，把所有技能堆在一个命名空间里，后来技能数量超过一百个的时候，检索和更新都变得非常痛苦。强制分层之后，哪怕技能数量再多，定位一个技能只需要“层名+业务域+动作”三段式路径，效率提升非常明显。

2.2 技能颗粒度的取舍：太粗还是太细

技能设计中最难拿捏的往往是粒度问题。

技能太粗，比如把一个“全自动报告生成器”做成一个技能，输入几十个参数、输出几十种格式，表面上很省事，实际上一旦报错或者需要修改，整个人都会陷进去。而且这种粗粒度技能对模型来很难被准确触发，你根本说不清楚它到底能干什么，边际案例一多，模型选择技能的正确率会断崖式下降。

技能太细也有问题。比如把“计算两个日期之差”拆成“计算天数之差”“计算小时之差”“计算工作日之差”三个技能，看似职责清晰，实际上调用链变长、匹配次数变多，每次都要多做一遍技能选择的推理，既慢又容易错。

我常用的判断标准很简单：如果这个技能的描述可以在 20 个字以内说清楚它“什么时候被调用、输入是什么、输出是什么”，那它的粒度基本合适。另外还有一个经验：如果两个技能经常被同一个请求同时触发，那就考虑把它们合并成一个组合技能；如果某个技能内部的步骤经常被单独替换，那就考虑把它拆开。技能不是越多越好，而是“该拆的拆、该合的合”。

2.3 技能描述与注册：让智能体“看见”技能

这里必须单独提一下技能描述的重要性。很多技能没被正确触发，不是模型不行，而是描述写得太抽象了。

我之前接手过一个项目，里面有个技能描述写的是“处理数据问题”。结果这个技能要么被错误地用于一切与数据沾边的任务，要么被模型完全忽略。后来我改成“当用户提出 Excel 表格中存在重复行、空值、格式错误等问题，需要清洗和标准化数据集时，执行此技能”，命中率立刻上来了。

写技能描述的原则，我总结为一句话：写触发场景，不写能力概述。你要告诉模型“什么情况下用”，而不是“这个技能有多厉害”。另外，技能的输入参数说明也要具体，最好带上示例值。比如“format: 可选参数，支持 md、html、txt，默认 md”，这比“输出格式”四个字好用得多。

注册机制方面，凡是需要被模型动态选择的技能，都应该有一个统一的路由表。每次新增技能时先登记再上线，不要把技能散落在各种配置文件和代码库里。我已经养成习惯：技能仓库里维护一个索引文件，每个技能有自己的 ID、名称、描述、入参、出参、权限标记和版本号。这一步看起来繁琐，但它保证了后续的评估和排障有据可依。

3. 技能编排与调用链路的实操：从一个真实场景说起

3.1 技能调用格式与参数设计

确定了技能清单之后，下一步就是把技能的接口设计出来。我采用的是类似 JSON-RPC 的风格，每个技能一个skill_id，调用时传入一个参数对象，返回一个标准结构的结果。

{ "skill_id": "weekly_report.generate", "params": { "project": "某跨平台系统", "week_start": "2025-05-12", "week_end": "2025-05-16", "include": ["会议记录", "代码提交", "风险项"] }, "trace_id": "req_8f3a2b..." }

返回也好，统一包一层，业务逻辑层永远不去猜“这个技能到底返回了啥”：

{ "status": "success", "data": { "report": "......", "sections": ["summary", "progress", "risk"] }, "meta": { "duration_ms": 820, "model_calls": 3 } }

参数设计上我有一条铁律：能传结构化的就不要传自然语言。比如你要让技能“按日期过滤记录”，直接传{"start_date": "...", "end_date": "..."}，而不要传一句“把最近五天到昨天的数据弄出来”。结构化参数既方便缓存和校验，也便于将来做并行调度和重放测试。

技能的幂等性也值得提前考虑。凡是会改数据的技能，比如发消息、写文件、创建工单，我都在参数里加一个idempotency_key，避免重试的时候产生重复操作。这个设计可能在原型阶段看不出来，但一旦接入真实业务，几乎一定会用得上。

3.2 多技能协同：一个完整的编排样例

看一个具体的编排例子。假设我们正在做一个“客户周报自动生成”的智能体，收到的原始请求是这样的：

“本周华北区客户的活跃度有明显下降，帮我整理一份包含使用趋势、可能原因和建议动作的周报，发给项目经理。”

这个请求会被拆成这样的技能调用链：

第一步调用profile.customer_filters，技能把“华北区客户”解析成具体的客户列表；第二步调用metrics.usage_trend，查询这些客户近四周的登录次数、模块使用时长等指标；第三步调用analytics.change_detector，识别活跃度下降最明显的客户子集和时间拐点；第四步调用insight.reason_candidate，让大模型基于数据给出可能的下降原因；第五步调用report.finalize，把以上结果整合成符合内部模板的周报；最后一步调用message.im_notify，把报告发送给项目经理。

这个链路里，前三步偏确定性执行，第四步需要大模型推理，第五步又回到模板化输出。技能编排的核心就在这：把确定性和非确定性穿插组合，而不是让模型一步到位地“记起”所有数据。模型不擅长精确计算，但它很擅长在你准备好的分析材料上做归纳。

编排时的错误处理策略也要提前定好。我的经验是：组合技能里每一个子步骤都要有超时上限，并且在超时后走“降级路径”。比如analytics.change_detector失败了，可以降级为用metrics.usage_trend的原始数据加insight.reason_candidate的粗略分析顶上，保证最终的报告仍然能产出，只是精度可能低一些。

3.3 技能回调与结果校验

技能执行完之后，不要急着把它当成“不可质疑的真理”。尤其涉及真实业务数据的场景，校验是必须的。

我在每个组合技能的末尾都会接一个validator子技能，它的工作分三层：一是检查完整性，确认返回结果中的关键字段是否存在；二是检查一致性，比如周报里的数据是否和源查询结果一致，有没有出现凭空多出来的指标；三是检查可读性，比如日期格式、数量单位、专有名词是否统一。

这个验证步骤看似多花一次模型调用，实际上能帮你省掉大量返工。我经历过一次线上事故：生成的周报里把“下降 12%”写成了“上升 12%”，底层数据是对的，但模型在生成叙述时把正负号给反转了。从那以后，涉及到关键指标的技能返回，我都会强制加一轮“数据+叙述对照”校验。宁可慢几百毫秒，也不能带错发布。

提示：校验技能不要用生产环境的真实数据跑随机测试，最好建立一个独立的“黄金数据集”，里面包含几十条典型历史场景以及正确的预期输出。每次技能版本更新，先在黄金数据集上跑回归，再放量。

4. 技能评估与持续迭代：怎么让技能越用越准

4.1 别偷懒，给每个技能建一个“及格线”

很多团队做完技能就上线，上线后全靠用户反馈来发现问题。这种做法太被动了。我自己会在技能上线之前，给每个技能定义三层评估指标。

第一层是触发准确率。针对一组真实历史请求，计算“该触发的时候触发了、不该触发的时候没触发”的占比。我一般要求不低于 85%。如果某个技能经常被误触发，我会优先调整它的描述和触发条件。

第二层是执行成功率。技能跑完且结果通过校验的比例。这里要注意：模型调用失败算失败，工具接口返回错误算失败，输出格式不对也算失败。最好把失败原因打点分类，否则很难定位问题在哪一层。

第三层是端到端体验分。这个偏主观，我会抽一批典型任务，让一个评估小助手按照固定的问答基准给结果打分。虽然每个团队的打分标准不一样，但分数本身能不能稳定复现才是重点——如果同一批任务两次评估的分数波动很大，说明你的评估流程还不够规范。

4.2 从失败日志反推技能缺口：快速定位与修复

技能上线后出现问题是必然的。关键是你从失败里能不能快速找到规律。我这里有一个常用的排查思路。

先把所有失败请求按“故障类型”分组：是技能没被触发、技能被触发后参数缺失、技能调用过程中依赖的工具报错、还是返回结果校验没通过？这四个方向定位路径完全不同。

• 技能没被触发：去看请求上下文与技能描述的相关性，多半是描述语义覆盖不够，或模型在多个相似技能之间产生了混淆。
• 参数缺失：回看请求原文，看模型抽取入参时是否缺少必要的实体信息，必要时在技能描述里补充抽取示例，或在调用达到一定条件时主动反问用户。
• 工具报错：检查依赖的接口是否变更、权限是否缺失、服务是否降级，这类问题往往是生产环境波动导致的。
• 校验不通过：看校验器列出的具体错误类型，是数据完整性还是可读性问题，这类问题往往需要调整技能内部的输出模板或后处理逻辑。

我还会定期做一次“未命中请求复盘”：从日志里找到所有没有匹配到任何技能的合法请求，把它们聚成主题。如果某个主题反复出现，那说明你缺一个新技能，或在某个现有技能的描述里漏掉了这个使用场景。技能体系不是一个静态仓库，它是在真实请求的“喂养”下慢慢长出来的。

4.3 技能的版本管理与灰度发布：从哪一步开始

技能改起来比普通代码容易，但也正因为容易，出问题的范围也容易被放大。我现在的习惯是对任何一个“组合技能”级别以上的技能都做版本管理，并且在发布流程上分三步走。

先在隔离环境跑黄金数据集回归，确保改动没有破坏历史场景。然后让新版本技能以一定比例在真实流量上生效，同时对比新旧版本的触发准确率和执行成功率。最后根据对比结果决定是全量切换还是回滚。

这里有一个容易忽略的细节：版本管理不要只记录技能代码，要连技能的描述文本、依赖的工具版本甚至模型版本一起记录。因为技能的行为是“代码+提示词+模型”共同决定的，某天模型厂商升级了底层能力，同一个技能的表现可能会明显变化，没有配套版本记录，你根本没法解释为什么突然变好了或者变差了。

注意：灰度期间要确保同一个会话或同一个用户始终使用固定版本的技能，避免用户前后两次操作得到不一致的结果。我一般会按trace_id后缀或user_id哈希来路由，而不是简单按请求量百分比。

5. 常见问题与排查技巧实录：那些年我踩过的坑

5.1 技能没有被正确触发怎么办

这是使用频率最高、也最让人抓狂的问题。排查方向我总结成三步。

第一步，检查技能描述。把技能描述拿出来和真实请求逐字对照，很多时候是描述里用了太多抽象词汇，比如“处理”“分析”，而用户通常说的是具体场景，比如“把这堆聊天记录里客户抱怨最多的功能点挑出来”。把抽象词改成场景化的触发词，效果立竿见影。

第二步，检查是不是存在相似技能。当两个技能描述在语义上重叠达到一定程度时，模型就会开始随机选择。解决办法是明确区分边界，在描述里主动写明“本技能不负责……场景”。没错，负向描述同样重要。

第三步，检查路由策略。如果你在代码里对某些技能加了显式优先级或者黑名单，先确认是不是因为路由规则把正确技能拦掉了。这类问题从日志里很好定位，别一开始就怀疑模型能力。

5.2 技能返回格式不稳定怎么兜底

模型生成的结果天生就带有不确定性，即便你把输出模板写得再细，也挡不住它在边界场景里“自由发挥”。我的兜底策略是两条腿走路。

一方面加强强约束生成。能通过 JSON Schema 约束的内容就尽量约束，必要时会对模型输出做一次结构化校验自动重试，超过两次重试再走兜底分支。这样可以显著降低格式异常的概率。

另一方面做后处理清洗。无论模型的输出是什么形态，先统一转成文本，再用轻量的脚本做规则修补。比如把“百分之十二”替换成“12%”，把日期中的“2025/5/16”统一为“2025-05-16”。这套清洗逻辑独立于技能内部逻辑，可以复用到所有技能上。

5.3 多技能同时匹配上了，冲突怎么解决

请求“帮我把这个文档翻译成英语并整理摘要”很容易让“翻译技能”和“摘要技能”同时被触发。真正的问题不在于两者都触发了，而在于它们的执行顺序。

我在技能路由表里加了一个priority字段，同时对有依赖关系的技能在描述里显式声明前置条件。比如摘要技能的描述里写明“如果用户同时要求翻译，请先翻译后摘要”。此外，还有一种更稳妥的做法：不让模型一次决定多个技能的执行顺序，而是让它先选主技能，主技能内部再串起其他子技能。

5.4 独家避坑清单：五条我用真金白银换来的教训

• 技能描述千万别写成“能力介绍”，要写成“触发场景说明”。
• 组合技能的中间结果一定要落盘或打点，否则出问题的时候根本没有依据排查。
• 新增技能之前先搜索一下现有技能，很多时候你不需要新建，只需要扩展现有的描述。
• 不要在一个技能里塞超过五个工具调用，链路越长越容易断，尽量用组合子技能代替串行硬编码。
• 定期清理长期未触发访问的技能，它们要么是废技能，要么是描述已经失效了。

在我实际接触的大量智能体项目里，真正拉开体验差距的从来不是某一个模型有多强，而是背后那套技能体系是否足够清晰、可扩展、能排错。把 Agent Skills 当作一个需要长期耕耘的产品来经营，你会看到智能体的能力天花板被一次次抬高。希望这篇基于实操经验的拆解，能帮你少走一些弯路。