企业官网建设流程全解析

1. 先搞清楚 Agent Skills 到底是什么

1.1 从一次失败的 Agent 开发说起

我至今记得第一次交付 Agent 项目翻车的样子。当时给一家客户做销售线索初筛智能体，需求很简单：读邮件、查企业信息、按条件打分、输出商机列表。我满脑子都是工具调用、上下文窗口、模型选型这些事，结果第一轮测试就露馅了——同一个邮件换个措辞，打分逻辑就漂了，有时候甚至把"竞品调研需求"识别成"采购意向"。问题出在哪？出在我把一个复杂的业务判断过程，直接压给了大模型的"临场发挥"，没有任何沉淀和约束。

后来我琢磨明白一件事：Agent 真正的核心竞争力，不是模型多聪明，而是你有没有把领域知识转化成"技能"沉淀下来。agent-skills 这个方向，讲的就是这套东西——把重复出现的判断逻辑、操作流程、甚至决策规则，从"每次都要模型重新想一遍"变成"固定的、可调用、可复用的技能模块"。

现在业界讨论 Agent 能力时，工具（Tools）、提示词（Prompt）、工作流（Workflow）讲得最多，但"技能"这个维度最容易被忽略。工具解决的是"能不能做某个动作"，提示词解决的是"用什么样的姿态做事"，而技能解决的是"在特定场景下，该怎么完整地做好一件事"。这三者的关系，你可以理解成：工具是手，提示词是说话方式，技能是肌肉记忆。

这也是为什么现在越来越多团队开始把 Agent 的构建重心从"堆工具"转向"磨技能"。我自己在几个落地项目里试过之后，最大的感受就是：把复杂任务技能化之后，Agent 的稳定性、可控性、可维护性都上了一个台阶。这篇文章我把整套思路和实操细节整理出来，希望能帮你少踩几个坑。

1.2 技能不是工具，是多层能力的组合

很多人一听"技能"就觉得是"给 Agent 加更多工具"，这是个很大的误解。

以我做的那个售后工单 Agent 为例。表面上看，技能化之后它多了一个"工单分类"的能力，好像就是一个分类工具？其实远不止。我拆开来看，背后至少叠了四层：

第一层是判断标准。什么算"退换货问题"、什么算"物流投诉"、边缘案例怎么归，这些不能交给模型自由发挥，需要固化成明确的分类规则和示例。

第二层是操作步骤。分类之后不是就结束了，后面还要跟着匹配优先级、查历史订单、生成初步回复、升级人工，每一步都有前因后果。

第三层是知识边界。哪些场景技能能处理，哪些必须转人工，要在指令里写死，防止 Agent 越界瞎答。

第四层是表达规范。最后输出的内容要什么格式、什么语气、要不要附上政策条款，也得由技能框架统一控制。

你看，一个看似简单的"技能"，其实是"规则 + 流程 + 边界 + 表达"的组合体。工具只是其中一块积木。所以我在实际设计技能时，从来不会问"这个 Agent 用了多少个工具"，而是问"这个 Agent 掌握了哪些技能，每个技能是不是足够完整"。

1.3 为什么现在才强调"技能化"

其实 Skill 这个概念不是今天才有的——早期搜索系统里的意图识别、电商系统里的促销策略引擎，某种意义上都是"技能"的雏形。只是到了大模型时代，"技能化"有了完全不同的意义。

以前我们把业务逻辑写死在代码里，判断条件一改就要走版本发布。现在用自然语言做 Agent，模型的灵活性让逻辑可以"软"着写，这既是好事也是麻烦——没有约束的灵活性就是不可控。技能化就是给灵活性装上一套稳定的骨架。它把"模型知道怎么说话"和"系统知道怎么执行"两层能力分开，各管各的。

另外还有一个很现实的原因：从商业视角看，技能是 Agent 产品里最值得复用的资产。我在一个团队的实践中见过，两三个项目做完后，沉淀下来的十几个技能模块能直接迁移到新场景，开发周期从一个月压缩到一周。技能库越厚，交付新 Agent 的速度越快，这种复利效应特别明显。

所以如果你正在做 Agent 产品，或者准备给现有系统接智能体能力，我建议你先把注意力从"模型选型"和"工具列表"上挪一挪，认真研究一下"技能体系怎么建"。后面我讲的内容，都是从真实项目里摸出来的方案，可能不花哨，但能用。

2. 设计技能体系时，我是怎么拆解任务的

2.1 第一步：先给 Agent 做一次"岗位分析"

我每次启动一个新 Agent 项目，做的第一件事不是写代码，也不是想提示词，而是像给员工写岗位说明书一样，先做一遍任务盘点。这个习惯是从一次翻车里学来的：当时我直接照着一个通用客服 Agent 的模板改，结果业务场景换了，整个体系都要重做。

做岗位分析的方法很简单，我一般会拿一张大表，分成三列：场景、目标、动作。场景是"用户说了什么话/遇到了什么情况"，目标是"Agent 需要达成的结果"，动作是"为了达成结果要做哪些事"。把业务方给的案例、历史工单、用户反馈全部往这三列里填。

填完你会发现一件有意思的事：很多看似不同的场景，背后的动作高度重叠。比如"查订单状态"和"查物流信息"，其实都要先做"用户身份验证"，再查"交易数据"，最后做"信息汇总输出"。这时候我就知道，这些重复出现的动作就是"技能候选"。

我有一个经验值供你参考：一个 Agent 的技能数量最好控制在 5~12 个之间。太多了维护不过来，而且技能边界容易冲突；太少了说明拆得不够细，Agent 又回到了"临场发挥"的模式。前面提到的销售线索 Agent，我最后沉淀下来 7 个技能，工单 Agent 是 8 个，跑起来都比较稳。

2.2 把技能拆成"显式技能"和"隐式技能"

在岗位分析的基础上，我第二步会做一件很多人没做的事：把所有候选技能再分成两类。

一类叫显式技能，就是用户一句话就能触发的、有明确操作流程的能力。比如"查询订单"、"生成报表"、"发起退款"。这类技能适合做成独立模块，动作清晰，边界好定义，测试也容易。

另一类叫隐式技能，是藏在所有对话底下的通用能力。比如"识别用户情绪并决定是否转人工"、"在多轮对话里维护用户画像"、"判断当前场景是否需要追问"、"在拿不准时选择保守表达而不是瞎猜"。隐式技能不绑定任何具体流程，但它们决定了 Agent 在复杂对话里会不会"崩"。

两类技能分开管理非常重要。我在项目里是把隐式技能抽成一个独立的"行为基线"文件，相当于给 Agent 设定了一套默认品格和工作习惯。显式技能则每个单独成一个模块，独立开发、独立测试。这样做的好处是什么？显式技能可以频繁迭代、替换、新增，但隐式技能作为基线要保持稳定。相当于公司里岗位可以调整，但核心价值观和文化不能天天改。

2.3 技能之间的调用关系要先画清楚

第三步，也是最容易忽略的一步：技能不是孤立的，它们之间是有调用链的。我在早期设计里吃过亏——技能模块之间完全平铺，没有优先级和触发条件，结果一个请求同时触发三个技能，Agent 自己都懵了。

后来我学到一个方法，就是画一张技能触发表，列清楚每个技能的触发条件、生效优先级、打断规则和结果处理方式。比如我的工单 Agent 里面，"风险识别"技能的触发条件就是"用户对话中出现金额、投诉、维权等敏感词的上下文"，而且优先级高于"常规分类"，一旦命中就直接升级人工，后面的流程就不用走了。

这张表特别有用，因为它等于把所有"如果...那么..."的分支逻辑都显式化了。模型天生不擅长处理大量隐式分支，你把分支规则写清楚，Agent 的执行才会稳定。我建议不管项目多小，都要留出半天时间专门做这张表，后期调试能省很多事。

3. 一个完整的技能构建实录

3.1 我选的场景：售后工单分类（含严重度判断）

理论讲太多容易飘，我拿一个完整的实盘案例来演示——售后工单分类 Agent 的技能构建过程。这个场景非常典型：用户发一段售后描述，Agent 要完成两个核心动作：判断这是什么类型的问题（类别标签）、判断这个问题的严重程度（决定要不要立刻升级）。

这个场景好在哪里？第一，它足够简单，核心逻辑不超过三步；第二，它足够常见，几乎所有做客服系统的团队都能套用；第三，它同时包含显式技能（分类）和隐式技能（严重度判断），有完整代表性。

我先展示最初版的技能定义文件结构。用 YAML 组织，分为meta、triggers、steps、rules、output_format五个区块：

skill_name: after_sales_ticket_classifier version: 2.4 description: 处理用户提交的售后描述，识别问题类别并判断严重程度 triggers: - 用户描述了与购买商品相关的问题 - 用户表达了对订单、物流、退换货的不满 - 用户提交了售后表单或发起了售后会话 steps: - name: 信息抽取 desc: 从用户描述中提取关键实体，包括订单号、商品名、问题现象、用户诉求 method: 基于正则 + 模型命名实体识别，实体字段全部限定在预设schema内 - name: 类别判定 desc: 基于抽取特征和用户原文，判断问题属于哪一类别 options: - 质量问题 - 物流问题 - 退换货问题 - 价格争议 - 其他 - name: 严重度评估 desc: 判断问题严重程度，决定后续流程 levels: 低: 仅涉及信息咨询，无用户损失 中: 涉及操作失误或时间延迟，但可补救 高: 涉及用户资金损失、安全风险或强烈情绪投诉 rules: - 如果无法判断类别，默认走人工复核，不要猜测 - 如果严重度为高，立即转接人工客服，禁止继续追问 - 如果用户描述包含攻击性词汇，跳过分类流程，直接升级至质检部门 - 不允许编造订单信息，所有订单数据必须来自真实查询结果 output_format: 结构化的 JSON，包含用户意图、类别、严重度、建议动作

看到这里你应该能明白，所谓技能，本质上就是"把做这件事的所有决策规则都显式化"。我在这版定义里特别注意了几点，都是过去踩坑换来的教训：

第一，触发条件不要写得太死。比如"用户表达了不满"这种话，模型理解起来反而更容易，因为它是语义层面的；你要是写成"包含差评关键词"，碰到"这个商品还行但发货太慢了"这种隐匿抱怨就识别不出来了。触发条件宁可松一点，靠后续分类来兜底。

第二，规则里一定要有"默认动作"。很多 Agent 在遇到边界情况时选择沉默或者瞎猜，原因就是你没给它们写好"拿不准就干什么"。我的经验是：凡是涉及资金、安全、情绪的边界情况，默认动作都是"升级人工"而不是"模型继续处理"。这看起来保守，但正是因为保守，这个 Agent 的交付才敢给客户签 SLA。

第三，steps 层要控制数量。我见过有人把一个技能写成 20 多个步骤，结果整个流程又长又脆弱。我的习惯是：显式技能的主流程步骤控制在 3~7 个，分支逻辑全部下沉到 rules 里，让模型在关键节点做"判断"而不是在每一步都做"决策"。

3.2 技能开发中的三个关键设计细节

上面是静态的技能定义，但实际开发中，真正影响成败的往往是一些细节设计。我挑三个最关键的说。

第一个细节是实体抽取的 schema 设计。我前面提到"实体字段全部限定在预设 schema 内"，这句话背后是有血泪的。最初版本我让模型自由抽取实体，结果它抽出来一堆模棱两可的值，比如"订单号"抽成了"用户提到的订单"，后续做数据库查询根本没法对齐。

后来我改成了强 schema 约束，预先定义好每个实体的类型、枚举值、取值范围和抽取逻辑。比如"问题现象"这一项，我给了固定的候选集，包括破损、错发、漏发、延迟、描述不符等，模型只能从候选集里选，不能自由发挥。这样做的好处是：下游的判断逻辑不需要处理各种"野生"表达，分类和严重度判断的准确率一下子就上来了。

第二个细节是类别判定和严重度评估的顺序。我的第一版流程是先做严重度评估再做分类，但测下来效果很差。因为严重度评估本身是一个需要上下文的判断，没有类别信息的时候，模型对"严重"的理解会比较飘。调换顺序之后，先分类再评估，模型在"已有类别前提"下做严重度判断，准确率高了很多。这种细节只有实测才能发现，文档里永远不会写。

第三个细节是少样本示例的选择。每个技能定义里，都应该带上 3~5 个少样本示例，但很多人对示例的选择很随意。我的经验是：示例要覆盖边缘情况，而不是覆盖常规情况。分类器的边界模糊点通常在那些"看起来像 A 又像 B"的案例上。我特意在示例里放了两条"容易混淆"的样本——一条是"商品有点小瑕疵但能用"（质量问题还是价格争议？），一条是"客服已经承诺补偿但用户还是投诉"（分类是什么？严重度如何？）。让模型在这些边缘例子上有了参考，实际跑起来明显更稳。

再给你看一个我踩过的具体的坑。第一次上线时，"规则"部分我没写清楚"用户诉求与当前类别不一致"的处理方式。结果有个用户说"我想投诉快递态度差"，但订单分类跑到"退换货咨询"去了。后来我加了一条规则：收到用户描述时先做一次"诉求匹配"检查，如果用户表达的诉求是投诉类，不管描述里有没有其他信息，优先按投诉流程处理。这种规则栈加多了以后，Agent 的"人情味"也出来了，用户觉得系统"听懂了自己"，实际上只是规则设计到位。

3.3 一场典型的技能测试与调优过程

技能写完了，不等于能上线。我的流程是：先做离线回归测试，再放量灰度，最后再全量。离线回归测试这块，我有一套自己的做法。

我会准备两个测试集。一个叫"常规集"，大概 80 条，覆盖日常高频场景；另一个叫"刁钻集"，大概 30 条，专门挑那些容易让 Agent 出丑的边界案例。每次迭代技能定义后，两个集都要跑一遍，用同一套打分脚本输出准确率和错误类型分布。

我分享一次典型的调优过程，非常有意思。第一版技能定义跑完常规集，准确率 91%，看着不错。结果刁钻集一跑，掉到 74%。我逐个看了错误样本，发现三大类问题：一是把"退款金额争议"归类成"价格争议"而不是"退换货问题"；二是把"用户抱怨物流慢但没要求赔偿"判成了"高严重度"，实际上用户只是想要个解释；三是实体抽取时漏掉了"订单号"这类关键信息，导致后续查询失败。

针对第一类问题，我在类别判定的示例里补充了这两条边界案例，规则里加了一条：凡是涉及已购买商品的金钱往来，优先归入退换货类，除非用户明确表达的是对定价本身的质疑。针对第二类问题，我调整了严重度评估的判定引导，明确"严重度高"必须包含"有明确损失诉求"这一条。针对第三类问题，我把 schema 里"订单号"的抽取逻辑改成了"优先用正则匹配，失败了用模型兜底，再失败就转人工追问"。

改完后第二次跑，常规集 93%，刁钻集 86%。又迭代了两轮，最终常规集 95%，刁钻集 91%，才敢拿给客户试运行。这个调优过程本身就说明问题了：技能一次性写完美是不可能的，但要有一个有效的迭代闭环，让问题能被结构化地发现、归类和解决。我建议每个技能至少预留两轮打磨时间，别指望一发命中。

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

4.1 提示词越长，技能越脆弱

很多人刚接触 agent-skills 的时候，第一反应是把所有东西都塞进提示词里，写得又长又全。我一开始也这样干过。一个工单分类技能，提示词写了近两千字，把各种规则、背景、示例全堆进去。结果实测下来效果非常差——给一个简单案例，它反而犹豫不决，甚至开始编规则里没有的东西。

后来我才反应过来，提示词越长，模型注意力越分散。它就像一个人拿到一本两百页的说明书，反而不知道哪条是当前场景的关键。解决思路是分层承载，把不同类型的知识放在不同位置：触发条件和默认动作放前面，少样本示例放中间，边界规则放后面。而且每个模块之间的逻辑要独立，别交叉引用太多。

我在项目里甚至把技能定义和系统提示词分开了。技能模块是一个独立文件，只在需要时才被加载进上下文。这样系统提示词保持精简，技能文件可以写得很细，但两者互不干扰。实测下来，这种做法对复杂任务的稳定性提升非常明显。把该写的写进技能文件而不是提示词里，是我做 agent-skills 之后最重要的一个转变。

4.2 技能能复用，但复用不等于照抄

我前前后后做过十来个技能模块，其中一个容易让人掉以轻心的点就是——以为技能定义可以跨场景直接套用。比如我在销售线索 Agent 里写了一个"行为基线"，同样的文本稍微改改就塞到工单 Agent 里了，结果运营一阵子后发现，它处理售后问题时显得过于"冷冰冰"，用户反馈变差了。

后面细看，问题出在"价值观"上——销售场景需要高效、直接、快速筛选，但售后场景需要共情、耐心、逐步安抚。同一个基线的底层表达逻辑不同，用户体验就完全不同。复用技能时，复用的应该是经验和结构，不是字符本身。我现在每次复用都强迫自己重读一遍，逐条校准用词"温度"和优先级权重。这份重复劳动是有价值的，花不了太多时间，但能避免上线后返工。

还有一个容易踩的坑是框架版本不一致。A 项目里技能模块用的是"读取 Json 配置"的格式，B 项目里换成了"读取 YAML"的格式，如果把定义文件直接搬过去，轻则解析失败，重则逻辑错乱。我自己的规范是：技能文件必须包含一个 meta 字段，声明自身的适用版本和依赖项。跨项目迁移时先检查 meta，再做字段映射，最后回归测试。

4.3 技能之外的"隐性上下文"有多重要

另一个特别容易被忽略的坑：技能定义本身写得很完善了，但 Agent 在执行时还是会出现莫名其妙的错误。追查后发现，问题竟然出在上下文窗口里的历史信息污染。比如工单 Agent 在某个会话里，前两轮用户还在聊退换货，第三轮突然切到了物流投诉。如果技能模块只基于"当前这一轮"做分类，往往会把上一轮的语义残留带进判断。

解决方法是给技能定义一个"输入上下文"的接口规范，明确指定应该抽取哪些信息：当前用户消息、最近的系统动作、必要的用户画像字段，其余历史信息一律过滤掉。这个接口规范的受益比你想象的大得多。技术上做起来也不难，就是在组装 prompt 时显式声明哪些内容进入技能处理范围，哪些内容只作为背景。

5. 从"技能"走向"技能库"，我的一些心得

5.1 用"单一技能质量"和"整体配合度"双重指标评估

单看一个技能模块的准确率，其实不够。我后来在项目里用上了双维度评估体系。

第一个维度是"单一技能质量"：每个技能模块独立跑测试集，看准确率、召回率、边界案例的处理效果。这个维度保证单个技能"可用"。

第二个维度是"整体配合度"：把多个技能放进同一个 Agent 里，跑完整的使用流程，看技能之间切换是否顺畅、会不会出现互相打架、信息在技能之间流转是否丢失。这个维度保证技能体系"可用"。

具体怎么测整体配合度？我会设计一批"多跳任务"。比如："用户先问订单状态，然后投诉物流慢，接着问退款什么时候到账"——这个任务要依次触发订单查询技能、投诉升级技能、退款查询技能，任何一环卡住都会暴露问题。这种测试用纯单技能的准确率是发现不了的，非跑整体流程不可。

5.2 技能也要做版本管理

技能不是写完就一劳永逸了，它是要不断进化的。我自己是拿 Git 管技能文件的，每次改动一个版本，备注写清楚"改了哪条规则、为什么改、影响哪个场景"。同一技能的不同版本会在不同渠道里灰度，比如线上渠道用 2.3 版，灰度渠道用 2.4 版，两边跑数据对比，稳定之后才全量切换。

这里有个细节：改技能定义的时候，一定要同步更新测试集。很多团队改完技能忘改测试集，跑了几天发现指标跌了，一查是测试集里的案例已经不符合新逻辑了，是自己把自己评估崩了。

5.3 技能库是团队资产，不是个人备忘录

做到最后我想说一个观点：技能沉淀不是某一个人的任务，而是整个团队的资产流动。我给团队搭了个简单但有效的共享技能库，每个模块都有明确的负责人、适用场景和已知限制。新手接手时先翻技能库，再上手新任务，路径非常清晰。

这种做法的核心价值是降低重复劳动。同一个判断逻辑，A 在这里写过一次，就不需要 B 在那边重新踩一遍坑。技能库越厚，团队的交付速度就越快，这是我从一开始完全没预料到的收益——本来只是为了解决问题，结果顺带把团队产能也拉上去了。

我平时看到很多 Agent 项目，技术选型很新、工具链很全，但流于"每做一个新需求就从头搭一个 Agent"，既不稳定也不高效。把心思多花在技能体系上，效果会好很多——这基本是我最近做 agent-skills 最大的一个心得，跟各位同行分享一下。