企业官网建设流程全解析

我最近接手了一个挺有意思的任务：让智能体自动处理一部分售后工单。刚开始的想法特别天真，以为把企业知识库丢给大模型，再写一段详细的提示词，它就能像老员工一样回复客户。结果一跑起来就发现完全不是那么回事——模型确实能说话，但不知道什么时候该查订单、什么时候该看物流、什么时候该升级人工，全凭“感觉”，输出质量忽上忽下。

后来我把这套能力彻底重构了一轮，核心就做了一件事：把智能体的能力拆成一个一个的“技能”，也就是 agent-skills。做完之后效果提升非常明显，工单处理准确率从之前的不到60%干到了85%以上，而且每个步骤都能回溯、能测试、能单独迭代。这篇文章我不打算讲什么高大上的理论框架，就老老实实分享我在实操中怎么设计、怎么落地、踩了哪些坑，希望能给正在折腾智能体的朋友一些参考。

1. agent-skills：先搞清楚它在解决什么问题

1.1 一个活儿，怎么拆给智能体干

我先用个大家都熟悉的例子说明一下。想象你去一家餐厅吃饭，你跟服务员说“给我来一桌生日宴”，服务员如果没有经过训练，他能做的只是把这句话原样传给后厨，后厨肯定懵。但如果服务员受过系统训练，听到“生日宴”之后，会自动拆成几个动作：确认人数和忌口、安排包间、通知后厨准备特定菜单、订蛋糕、布置现场。每个动作都有明确的流程和标准，串起来就是一整套服务能力。

智能体干活的逻辑也是一样的。你说“帮我处理一下这个退款工单”，它不能只用嘴回答“好的，我来处理”。它必须能自己判断：先查订单状态，再看退款原因，查一下是否超出售后时效，必要时调取聊天记录，最后生成处理意见。这一连串的“动作”，每一个都应该是一个明确、可执行、有输入有输出的技能。把这些技能拆得越清楚，智能体就越稳定，越好调。

我在最初的项目里犯的错，就是把所有能力全塞进一个大提示词里，让模型自己“悟”。结果就是：能用的场景看着很惊艳，不能用的场景莫名其妙。AI 的随机性在这个模式下被放到了最大，生产环境根本不敢用。把能力拆成 agent-skills 之后，至少每一条链路是我能控制的，模型只需要在技能之间做选择和填参，复杂度一下就降下来了。

1.2 技能、工具、工作流到底是什么关系

很多人第一次接触 agent-skills 的时候，会把“技能”和“工具”搞混。我先给个简单的区分：

• 工具（Tool）：是智能体可以调用的外部功能，比如“查订单API”“发邮件API”“数据库查询接口”。工具本身是无状态的，你给它什么参数，它返回什么结果，它不关心整体任务。
• 技能（Skill）：是把工具、提示词、判断逻辑、甚至多个工具调用，包装成一个完整的“完成某个任务的能力”。技能内部可以有自己的流程，比如先查订单再判断能不能退款，这中间有逻辑判断，不是简单一次API调用。
• 工作流（Workflow）：是更高层的编排，把多个技能串起来，完成一个端到端的业务目标。比如“处理整张退款工单”就是一个工作流，它内部会调用“核对订单”“查询售后政策”“生成处理意见”“回传工单系统”四个技能。

用开发的话说，工具是“函数”，技能是“服务”，工作流是“业务流程”。我之所以强调这个区别，是因为团队里沟通时如果概念不统一，设计出来的东西会非常混乱。有的人说“我们做了个工具”，其实他做的是一个复杂技能；有人说“做个工作流”，其实只是把两个API串在一起。概念统一之后，我们再聊架构就顺畅得多。

agent-skills 的价值就在这里：它给智能体提供了一个“能力封装层”。模型不需要关心技能的底层实现是调用API、读数据库还是跑一段Python，它只需要知道这个技能叫什么、什么时候该用、需要填什么参数。这样模型的选择负担小了，出错的概率自然也就低了。

2. 设计一套能用住的技能体系，关键在“边界”

2.1 技能描述：先让模型看得懂，再让模型用得好

技能体系的第一个关键设计决策，就是技能的“描述信息”怎么写。你可能觉得这不就是写一段说明文字吗？实际水很深。

我一开始踩过一个坑：给技能写的描述又长又详细，把内部实现、注意事项、边界情况全部写进去了，结果模型反而变傻了。因为描述太长，模型在处理复杂任务时记不住关键触发条件，经常在错误的场景下调用错误的技能。后来我改成了“三层描述法”，效果好了很多：

第一层，一句话说明“这个技能是干什么的”，控制在50字以内。比如“查询订单当前状态及物流轨迹”。这一层是给模型做快速筛选用的，它看完就能决定要不要用。

第二层，写清楚“什么场景下该用这个技能”，包括典型的触发条件和不适用的情况。比如“客户咨询发货时间、物流位置时使用；如果客户要修改地址，请使用修改地址技能”。这一层是为了防止模型误用。

第三层，写清楚“有哪些关键参数、各自的格式要求和默认值”。比如订单号必须是字符串、时间范围要传Unix时间戳。这一层是为了让模型能正确填参。

另外我强烈建议在描述里加入“负面提示”，明确说明什么情况不要调用。比如一个“查询天气”的技能，你得写清楚“仅返回当天和未来三天天气，不负责穿衣建议，穿衣建议请调用其他技能”。别小看这几句话，它能拦掉大量AI幻觉导致的错误调用。

提示：技能描述不是给人类看的文档，是给模型看的“路由表”。每多写一句废话，都在增加模型选错技能的概率。写完描述之后，可以用“这个需求该调用哪个技能”的测试集跑一遍，看命中率。

2.2 输入输出约定：把“自由发挥”变成“格式约束”

技能设计的第二个重点，是输入输出的格式约定。如果这一步不做严格约束，后面所有的稳定性都是空谈。

输入方面，我的经验是：参数能少就少，能用基础类型就用基础类型，能不嵌套就不嵌套。模型填参的能力没有你想象的那么强，尤其是多层嵌套的JSON对象，它经常会漏字段、填错类型。如果业务确实需要复杂结构，我会在技能内部做一次“参数预处理”，允许模型传一个简化的输入，然后由代码补齐缺省字段。这只会在增加一层，但能把填参成功率从70%拉到95%以上。

输出方面，一定要定义好输出结构，而且要用代码来“接住”，不要让模型自由输出一段文本然后让下游解析。我在项目里的做法是：所有技能的输出统一为JSON结构，包含三个固定字段——success表示执行是否成功、data存业务数据、error存错误信息。执行失败时，error里还会带上“可读的错误原因”和“建议的替代方案”，这样智能体在调用失败之后才能自己决定下一步怎么办。

还有一点特别容易忽略：技能内部的“超时”和“重试”策略。模型调用工具API的时候，如果API响应慢，它会一直等着，表现就是整个工作流卡死。我给每个技能都设了硬超时时间，比如5秒；超时后返回一个预设的兜底结果，而不是空响应。这个设计在生产环境里救了我很多次。

2.3 技能编排：让简单技能组合出复杂工作流

单一技能能解决的问题始终有限，真正能打的是“技能编排”。我理解的技能编排，本质上是一种“路由决策”：

• 第一步，模型先理解用户的原始需求，拆解成子任务序列。
• 第二步，为每个子任务匹配合适的技能。
• 第三步，按顺序执行技能，并把上一个技能的输出作为下一个技能的输入上下文。

听起来简单，但这里有一个关键的技术细节：你在设计技能时，就要考虑好“输出能不能给下一个技能用”。我见过很多团队，每个技能单独都好用，但一连起来就废了——因为技能A输出的是自然语言段落，技能B却需要结构化的参数。解决办法就是上面说的，所有技能输出统一用JSON，而且为常用的“接力”组合做好字段映射。

另外一个实操经验：技能编排不要追求“一步到位”，要允许中间步骤存在“人工确认点”。尤其是涉及资金、承诺、对外发送消息等高风险动作时，我在编排里加了一个“前置审批技能”，由它把待执行的内容推送给人工审核，审核通过才继续执行。这个设计虽然不能算“全自动”，但它在稳定性和安全性上的收益远大于损失的那点效率。

3. 从零搭起 agent-skills 的实操记录

3.1 先给技能分层：底座技能、领域技能、流程技能

动手搭建技能体系的时候，我先做的一件事是给技能分层。不是我上来就规划得那么清楚，是被现实教育过之后才总结出来的。一开始我把所有技能全塞平级，结果技能一多，模型选错的概率直线上升。后来我按“能力层级”重新分了层，整个体系清晰了很多。

第一层叫“底座技能”，这是跟业务无关的通用能力。比如“调用HTTP接口”“读写文件”“执行一段Python代码”“做时间计算”“编解码JSON”。这一层更像“工具”，但是我把它们也封装成了技能，好处是模型可以通过自然语言描述直接调用，而不需要知道具体API细节。

第二层叫“领域技能”，这是跟具体业务相关的技能，比如“查询订单”“计算退款金额”“生成工单回复”。这一层是核心资产，每个技能都对应一个明确的业务动作，且输入输出完全标准化，独立可测。

第三层叫“流程技能”，这是面向完整任务的高级技能，内部会编排多个领域技能。比如“处理退款工单”这个流程技能，内部可能涉及查询订单、核对政策、计算金额、生成回复四个子技能。流程技能对模型来说是一个“黑盒”，它只需要触发一次，内部逻辑由代码或工作流引擎来控制。

分层设计的好处是：新增一个业务需求时，如果底座技能、领域技能都有现成的，只需要调整流程技能的编排，改动面最小。如果只有底座技能，那需要新增领域技能，但不用动流程层。分层之后，技能库的可维护性提升了一个数量级。

3.2 注册和测试技能：我用的一套管法

技能设计完之后，就要考虑怎么注册和测试。这块我整理了一个自己的“技能上架流程”，基本每加一个新技能都走这个流程：

第一步，写“技能描述”草稿。按我说的三层描述法来写，先不管措辞，把内容列全。

第二步，建测试集。我会整理10到20条典型的用户请求，这些请求覆盖正常场景、边界场景、易混淆场景。比如测试“查订单”技能时，我会有“刚刚下单了怎么还没发货”（正常场景）、“我改了地址为什么还送到老地址去”（边界场景）、“我想看昨天的聊天记录”（易混淆场景）。测试集是技能质量最核心的保障。

第三步，跑描述效果测试。把用户请求发给模型，看它能不能准确选中这个技能。如果选不中，就去调描述措辞，而不是调模型。这个环节我会反复过好几轮，直到命中率100%为止。别嫌麻烦，这一步省下的全是后面调试的时间。

第四步，跑参数提取测试。让模型从一个完整请求里提取技能需要的参数。我会特意构造一些“绕弯子”的请求，比如“帮我看看那个XX牌的粉色杯子发货了没”——里面既有商品名又有颜色，还有用户意图，模型要能提取出正确参数。提取准确率低于90%的技能，我不允许上生产。

第五步，跑端到端测试。把技能放进一个完整的业务场景里，从用户请求到最后输出结果走一遍，记录耗时、成功率、兜底触发次数。这个环节往往会暴露一些“单测过了但联调挂了”的问题，比如上游传参格式不一致、下游返回结构变化等。

3.3 组合技能时最容易翻车的三个地方

技能组合是效率提升最快的阶段，也是最容易出“玄学问题”的阶段。我翻车翻得比较多的地方有三个：

第一个是“上下文污染”。多个技能串行执行时，每个技能的返回结果都会堆进对话上下文里。如果前面的技能返回了一段特别冗长的原始数据，后面模型做决策时就会被无关信息干扰，导致误判。解决办法是引入“上下文压缩节点”，每次技能返回后，只保留“结构化摘要”，把原始数据存到外部存储，不进对话上下文。

第二个是“错误传播”。技能A执行失败了，返回一段错误信息，然后技能B在不知情的情况下继续执行，基于错误的数据往下推理，结果越算越离谱。这类问题的根因是没有做“执行状态检查”。后来我在工作流引擎里强制加了状态门控：只要前一个技能返回的success=false，流程就必须进入“异常处理分支”，跟后端开发里“error early”的思想一模一样。

第三个是“循环调用”。有一次我在测试一个复杂流程时，发现智能体在一个由两个技能构成的小环路上反复调用，既不退出也不报错，白烧了大量token。排查下来发现是技能描述里“不适用场景”写得太弱，模型判断“这个技能好像能用、那个也能用”，就来回试探。后来我把循环检测做进了工作流引擎，同一技能连续调用超过3次就强制中断，让模型重新规划路径。

经验总结：技能组合的核心不是“把多个API串起来”，而是“让每一步都有明确的状态、明确的出口、明确的异常处理”。做不到这三点，技能越多，系统越不稳定，而不是越强大。

4. 真实场景复盘：售后工单技能是怎么长出来的

4.1 需求拆解：从“让AI回复客户”到“五段式处理”

回到我开头说的售后工单项目。最开始的需求描述是“让AI能自动回复客户的售后问题”，这种需求表述非常模糊，直接开做必死。我先做的第一件事是把需求拆成具体的处理流程。

我把一张售后工单从进来到关闭，拆成了五个阶段：工单归类、信息核验、方案匹配、回复生成、结果回填。每个阶段对应一个或多个技能：

• 工单归类阶段，需要“工单意图识别”技能，判断客户是退换货、退款、物流咨询还是投诉。
• 信息核验阶段，需要“查订单状态”和“查售后政策”两个技能，并且要做一个交叉比对，判断这个工单是否符合售后条件。
• 方案匹配阶段，需要“退款试算”技能，根据订单金额、商品状态、超出时限等条件计算退款金额。
• 回复生成阶段，需要“话术组装”技能，把方案转成自然语言的回复文案，同时控制在预设的几种语气风格之内。
• 结果回填阶段，需要“工单回写”技能，把处理结果写回工单系统，并记录处理日志。

这五段式拆解看起来不复杂，但它是整个项目最关键的决策。因为拆完之后，每个环节都能独立开发、独立测试、独立优化。哪一段准确率低就单独调哪一段，而不是整个系统推倒重来。从那以后我形成了一个习惯：凡是做 agent 项目，第一步永远是拆流程，而不是先选模型、写提示词。

4.2 技能落地的具体参数与中间结果

拆解确认以后，落地阶段有几个参数和中间结果是值得参考的。以“退款试算”技能为例：

输入参数只有三个：订单号（字符串）、售后类型（枚举：仅退款/退货退款/换货）、申请原因描述（字符串）。内部逻辑是：先查订单金额，再判断商品状态是否影响二次销售，再对照退款政策表，最后输出一个结构化的退款信息。

输出参数包括：应退金额（数值）、运费承担方（枚举：商家/平台/客户）、退款时限（字符串）、备注（字符串）。这里有个细节：应退金额的计算结果我会保留到两位小数，而且会在技能内部做一次“金额合理性校验”——如果算出来的金额大于订单实付金额，直接判为计算异常，返回错误，而不是硬着头皮往下走。

另一个值得说的是“工单意图识别”技能的冷启动。我们一开始没有足够的标注数据来训练一个专用分类模型，所以我先用了一种极端务实的方法：让大模型加规则做“双重判断”。先用关键词规则快速筛分化石级场景（比如包含“退款”两字优先归属退款类），再用大模型处理规则覆盖不了的模糊请求。两路结果一致直接走；如果不一致，以规则判断为准，并记录一条待人工复核的日志。

跑了一段时间后，我把积累下来的高质量标注样本整理出来，才去微调了一个轻量级的分类模型，把规则引擎给替换掉。整个过程很朴素，但特别稳。我一直觉得，做 agent 不是每一步都要上最先进的方案，能用规则解决的先用规则，能让代码控制的就少让模型发挥，模型只处理真正需要理解力的部分。

4.3 效果数据与局限性反思

上线跑了一个多月之后，我整理了一下这版本的数据。最核心的指标是“无需人工介入自动完结率”，从最初版本的不到20%，涨到了接近65%。也就是说，大概有三分之二的售后工单，整套技能流程可以在没有任何人工参与的情况下处理完并回填系统。作为对比，人工客服处理一张工单的平均耗时是7分钟，而技能流程的平均耗时是40秒，效率提升大约10倍。

但我也必须说清楚局限性。65%的自动完结率背后，有将近20%的工单走了“异常处理分支”，不是处理失败，而是被设计逻辑主动转给了人工。比如涉及高金额退款、用户情绪激烈的投诉、或者首次出现的新问题，这些场景我宁可转人工，也不敢让AI直接处理。这个取舍很重要：agent 追求的不是100%自动化，而是“在安全边界内的最大化自动化”。

还有一类局限性是长尾问题。哪怕技能划分得很细，也一定会碰到“这个工单看不出属于哪个已知类型”的情况。最初我把这类全部转人工，后来我多加了一个“处理建议”选项——让技能先给出一个基于经验的建议方案，人工只需确认就能快速处理掉。这个改动又把处理时长压缩了不少。

5. 几个压箱底的调试技巧和避坑心得

5.1 日志与追踪：技能出问题时先看什么

agent 项目调试起来比传统后端难很多，因为中间隔着大模型这层“不确定性黑盒”。我的经验是：必须从第一天就做好全链路日志，否则出问题的时候你连从哪查起都不知道。

我在每个技能执行的时候都会记录三类信息：入参（模型传了什么进来）、出参（技能返回了什么）、决策上下文（模型为什么选了这个技能，也就是让它看过的描述摘要）。这三类信息拼在一起，才能还原一个完整的执行过程。遇到问题时，第一件事永远是查日志，看是“选错了技能”“填错了参数”还是“技能内部报错”，三个方向的处理方法完全不同。

可视化追踪我也试过，用开源的链路追踪工具把技能调用关系画成时序图。有一定帮助，但不要指望它直接告诉你错误原因。真正有用的还是日志里的入参出参对比。我后来还养成了一个习惯：每周抽几个失败案例，把模型当时的决策上下文拉出来，手动复盘它到底是被哪句话误导的。这类复盘比任何调试工具都有效。

5.2 描述“过拟合”和“欠拟合”问题

技能描述写多了以后，我发现一个特别有意思的现象：描述也会“过拟合”。有一段时间，我在一个技能描述里把某个边界情况写得特别详细，结果模型对那个边界情况的触发极其敏感，稍微沾点边就调用这个技能，反而把正常意图给忽略了。这就是典型的描述过拟合——你把某类场景写得越细，模型就越倾向于在有歧义的时候选择它。

反过来，描述写得太简单，又会欠拟合。比如有个技能描述只写了“查询用户信息”，结果模型在用户问“我上次的收货地址是什么”时没想到调用它，跑去别的技能里找答案。后来我把描述改成了“查询用户的基础信息，包括姓名、电话、收货地址、会员等级”，命中率一下就上来了。

调整技能描述本质上是在做“路由边界校准”。我给自己的流程是：每次调整完描述，把测试集完整跑一遍，对比调整前后的命中率变化。而且要警惕“按了葫芦起了瓢”——解决了一个误用问题，可能引发另一个场景的误用。这个测试集必须长期维护，积累得越多，调整起来越安心。

5.3 版本管理与复用：技能库不是一次性工程

随着技能数量增多，我越来越意识到一个好的技能库是慢慢“长”出来的，不是一开始规划出来的。所以版本管理非常重要。我推荐用代码仓库管理技能定义，每个技能的描述、参数Schema、测试集、版本号都作为代码的一部分。改技能描述要走“修改-测试-提交”的流程，别在线上环境直接改，否则哪天改崩了你都不知道是哪次改动导致的。

复用方面，我见过两种极端团队：一种是每个项目都从零开始写技能，完全不看以前的积累；另一种是什么都想做成通用技能，结果技能之间耦合严重，改一个全崩。我的建议是：先按项目需求做出“能用”的技能，等发现多个项目都在用同一套逻辑的时候，再把它抽象成底座技能或领域技能。复用是抽象的结果，不是规划的目标。

最后再分享一个习惯：技能库每过一段时间要做一次“技能瘦身”。那些长期没被调用的技能，要么是没价值，要么是描述写得太隐蔽导致模型找不到。前者直接删掉，后者要重写描述。我的观察是，技能库的规模不是越大越好，模型在成千上万个技能里做选择，本身就是一件高难度动作。精简、高可用、边界清晰的技能库，比大而全的摆设要强得多。

我个人的经验是：agent-skills 这套思路，真正考验人的不是技术，而是“拆解”的功力。能把一个复杂的业务场景拆成边界清楚、描述准确、可独立测试的技能，比会写多少行提示词重要得多。这需要你对业务有足够的理解，对模型的行事偏好有足够的体感，再配合上面这些工程方法，大概率能做出生产可用的智能体。