企业官网建设流程全解析

这两年做智能体（Agent）应用的人越来越多，但很多人卡在同一个地方：模型能对话、能调用API，但一放到真实业务里就发飘，不知道怎么把“会聊天”变成“会干活”。我之前在好几个项目里反复折腾这个问题，最后发现核心解法就藏在agent-skills这个概念里——把模型会用的一整套能力显式地建模、注册、编排成可复用的技能单元。这篇东西就围绕 agent-skills 展开，聊聊它到底解决什么问题、怎么设计一套不翻车的技能体系、落地时有哪些坑，以及后续往哪个方向演进。适合正在做 Agent 应用、或者准备把大模型接进业务流程的开发者参考。

1. 先搞明白 agent-skills 到底在解决什么问题

1.1 大模型不是不够聪明，是缺少“手脚”和“章法”

很多人第一次接触 Agent 时会有一个误解：觉得只要把大模型接入 API，它就能自动完成任务。实际跑几个需求就会发现，模型确实能理解你的意图，但它“做不到”事情——不会查询内部的订单系统，不会读写数据库，不知道业务环节里有哪几步、每一步的输入输出长什么样。这就像雇了一个脑子很好使但四肢被绑住的新员工，你能和他对话，但他没法真正动手。

于是大家想到给模型加工具，也就是 Tool Calling。给它几个函数定义，让它自己决定调用哪个。这一步确实让 Agent 迈出了一大步，但接着问题又来了：工具一多，模型的选择就开始混乱。同一个业务场景里可能有几十个工具，描述稍微含糊一点，模型就挑错、传错参、甚至在一个环节里反复调用同一个工具。而且工具之间没有协作关系，模型每次都要从头推理“该做什么、用哪个工具、下一步去哪”。

这就是agent-skills要解决的核心矛盾：把“零散的工具”升级成“结构化的技能”。一个技能不是单个函数，而是一整套能力单元——它包含明确的触发条件、执行步骤、输入输出契约、依赖的资源和工具、以及完成后如何回传结果。模型看到的不是一个散装工具列表，而是一份“技能菜单”，上面写着“这个技能是用来干什么的、什么时候用它、它内部怎么跑”。模型只需要做选择题，而不需要每次从零规划执行细节。

1.2 从工具调用到技能编排，差的不只是概念

我在一个实际项目里对比过两种写法。第一种是传统方式：给模型塞了二十多个函数定义，每个函数就是一段 JSON Schema，让模型在对话里自己决定调用顺序。第二种是技能方式：把同样的二十多个函数按业务流程聚类成四五个技能，比如“订单查询”“物流跟踪”“退换货处理”“客服话术生成”，每个技能内部封装好步骤，模型只需选择技能入口。

实测下来的差距很明显。传统方式下，稍微复杂一点的多步任务（比如“查一下上周订单的物流状态并生成一条安抚话术发给客户”）模型经常出错：要么直接跳过物流查询，要么生成话术时没有引用真实物流信息，要么参数传错。换成技能方式后，模型的选择压力小了很多，它只需要识别“这是一个退换货场景”，命中对应技能，剩下的步骤全部由技能内部流程驱动，成功率明显提升。

这个对比说明了本质：工具调用解决的是“模型能不能调函数”的问题，技能体系解决的是“模型知不知道业务怎么跑”的问题。真实业务流程里，几乎没有单个函数就能完成的任务，都是多步协作。把这些协作逻辑沉淀成技能，模型才能把注意力放在决策上，而不是耗在执行细节里。

1.3 适合谁来用、在什么阶段用

如果你只是做一个简单的 demo，给模型挂三五个工具就够用了，搞技能体系反而显得笨重。但如果你在做这些东西，agent-skills就是一个绕不开的设计：

• 面向垂直行业的客服 Agent，涉及多轮查询、工单流转、话术生成
• 企业内部的流程自动化助手，需要对接 OA、ERP、数据库等多个内部系统
• 复杂研究类助手，比如资料搜集加分析报告生成，涉及多个阶段、多类数据源
• 任何“工具数量超过十五个”的 Agent 应用，这时候选择已经开始混乱

判断标准很简单：当你的模型频繁出现“工具选错”“步骤遗漏”“参数传错”这类问题，且加了提示词也没什么改善时，就该考虑把工具调用升级成技能体系了。

2. 技能体系的核心设计思路与架构选择

2.1 技能不是函数，是“函数 + 流程 + 边界”的封装体

在设计agent-skills时，我踩过第一个坑：把技能简单理解成“一个工具函数的增强版”，给函数描述写得详细一点就叫技能了。这是不对的。一个真正可用的技能，至少要包含四层内容：

第一层是技能元信息，也就是给模型看的“菜单”：技能名称、一句话说明、什么场景下触发、什么时候不该用。这一层决定了模型能不能在正确的时候选中它。很多技能失效，问题不在执行，而在“选错”或者说“该选的时候没选”。

第二层是执行流程，也就是技能内部怎么跑。它可以是代码写死的步骤序列，也可以是一张子任务清单，甚至可以是一个嵌套的“子技能调用链”。比如“生成物流安抚话术”这个技能，内部可能是：先调物流查询接口拿状态，再根据状态映射到话术模板，再调用大模型润色，最后做合规检查。这些步骤是技能内部封装好的，模型不需要操心。

第三层是输入输出契约，每个技能都定义严格的入参和出参。入参是模型从对话里抽取并通过自然语言转结构化得到的；出参是技能对外界产生的影响和返回结果。契约定义了模型和技能之间的接口，接口不稳定，整个系统就崩。

第四层是边界与兜底，包括技能适用的业务边界、需要哪些外部权限、执行失败时怎么办、有没有人工审批环节。这一层决定了技能能不能真正落在生产环境里，而不只是实验室里好玩。

2.2 技能、工具、插件、工作流到底是什么关系

很多人会把 agent-skills、tools、plugins、workflow 这几个词混在一起。做过完整项目后，我的理解是这样的：

工具（Tool）是最底层的能力原子，比如“调用订单查询 API”“发送一条企业微信消息”“执行一段 SQL”。一个工具只做一件事，没有流程逻辑。

插件（Plugin）是工具的打包分发单位，它解决的是“怎么把一批相关联的工具安全地交给模型”的问题。比如一个“文档处理插件”包含文档上传、格式转换、内容提取等多个工具。插件侧重的是打包和权限隔离，不强调执行流程。

技能（Skill）是面向业务目标的能力封装，它内部可以调用多个工具，也可以编排多个插件，还可以嵌套其他技能。技能的核心是“完成一个业务子目标”，比如“处理客户退款申请”“生成一份周报”。技能是模型决策的单元，也是开发者设计的单元。

工作流（Workflow）是跨技能的流程串联，它定义的是多个技能之间的先后顺序、分支条件和并行逻辑。技能解决“一个子任务怎么做”，工作流解决“整个业务怎么跑”。

这四层是递进关系。实际项目里没必要一上来就铺满四层，但至少要把工具和技能分清楚。我见过的最常见错误是：把所有工具平铺给模型，试图让模型自己编排步骤，这就跳过了“技能封装”这一层，模型容易失控。

2.3 为什么选择“显式技能注册 + 动态调度”而不是全自动生成

现在有些框架支持让模型自己写代码、自己定义工具，看起来更“智能化”。但我在生产项目里基本不依赖这种做法，原因很直接：自动生成的技能存在不可控性。让模型自行生成一段 Python 函数并动态执行，意味着你无法预判这段代码的行为边界——它可能访问网络、读写本地文件、执行系统命令。在内部业务系统里，这种不可控是无法规避的安全风险。

我更倾向于“显式注册、动态调度”的架构：所有技能都由开发者预先定义好，注册到技能仓库里，模型只能从注册表中选择技能，不能自行创建技能。模型的自由度体现在“选哪个技能、按什么顺序、传什么参数”，而不是“发明技能”。这个自由度边界划在哪里，决定了一个 Agent 应用是能用还是能出事。

这个思路类比一下就是：一个成熟的公司不会允许员工自己发明报销流程，而是提供一套已经审批过的报销模板，员工只需要按照模板填写并提交。效率确实多了一些约束，但可靠性和可控性完全不在一个级别。

2.4 架构选型时的两个关键取舍

技能体系落地的架构选择上，有两个点影响最大。

第一个是技能仓库与代码仓库的关系。我建议技能定义和实现代码放在同一个仓库里，用声明式配置（YAML 或 JSON）描述技能的元信息，用代码实现技能的执行逻辑，避免“技能文档”和“技能实现”分离。文档离代码越远，就越快过时，最后变成没人维护的黑洞。

第二个是技能与模型解耦的程度。技能定义不能绑定具体某个模型的能力。同一个技能可能在 GPT 系模型上运行，也可能在开源模型上运行。所以技能内部尽量标准化输入输出结构，避免依赖某个模型的特殊输出格式。比如入参统一用 JSON，出参也统一 JSON，执行步骤里不要包含“提示词”这种跟着模型变的东西。

我在真实项目里就吃过这个亏：技能内部写了一句针对某个闭源模型优化的提示词，换模型之后这句话完全失效，排查了一天才定位到问题。后来我把所有模型相关的提示词都抽离到技能外部，技能内部只保留确定性逻辑和数据流转。

3. 核心落地：从零构建一套 agent-skills 体系

3.1 技能描述怎么设计，模型才容易选对

技能描述是模型做选择时的唯一依据，写得好不好直接决定命中率。我总结了一个五段式模板，你可以直接抄：

• 技能名称：用动词开头的业务短语，比如“查询订单物流”，不要用“工具A”“func_123”这种没意义的命名。
• 适用场景：说明什么业务状态下该用这个技能，尽量写具体的触发信号，比如“用户询问包裹送到哪里了”“订单状态为已发货但用户说没收到”。
• 不适用的场景：明确写出什么时候不要选它，比如“用户还没下单时不要调用物流查询”。这个负面约束非常有用，能大量减少误调用。
• 输入要求：列出必填参数和可选参数，每个参数给出示例值。参数缺失时技能应该拒绝执行而不是瞎猜。
• 调用后的效果：说明技能执行后会返回什么，会给用户带来什么实际结果。这能帮助模型判断“这个技能能否满足当前需求”。

我在项目里实践下来，“不适用场景”这一项的信息增益最大。模型误调用的原因往往不是它不知道什么时候用，而是它不知道什么时候不该用。负面约束直接降低了候选范围。比如有一次，模型在一个用户“仅咨询退货政策”的对话里调用了“创建退货单”技能，差点真给用户生成一个退货单。后来我在技能描述里加了一句“用户未明确要求实际退货操作时禁止调用”，这类问题就再没出现过。

3.2 技能注册与参数契约：一份可落地的实现参考

假设我们要给客服 Agent 设计一个“查询物流并生成安抚话术”的技能。先看技能注册文件长什么样，我用 YAML 示例：

name: track_order_and_comfort description: 查询订单物流状态并生成安抚话术，适用于用户询问包裹位置或物流延迟的场景 applicable: - "用户询问包裹送到哪里" - "用户反馈物流进度与预期不符" not_applicable: - "用户只是随口抱怨物流慢，没有明确要求查询" - "订单尚未发货，需要引导用户耐心等待" inputs: order_id: type: string required: true description: 用户订单号，可从对话实体抽取 example: "SO202400618" user_channel: type: string required: false description: 用户所在的会话渠道，如 小程序/企微/APP example: "app" outputs: comfort_message: type: string description: 最终用于发送给用户的安抚话术 trace_status: type: string description: 供应链物流阶段状态 steps: - call_tool: query_logistics params: order_id: ${order_id} - call_tool: fetch_template params: status: ${trace_status} - call_tool: llm_polish params: template_text: ${template_text} user_channel: ${user_channel}

这个 YAML 文件描述的是技能对外暴露的“契约”，模型看到的就是这些字段。真正执行时，调度器会把inputs里的值填充进steps，然后逐步调用底层工具。注意steps里的变量引用用了${}占位符，表示这里的值来自输入参数或前一步的输出——这是一种简单的数据流绑定方式，不需要写复杂代码。

3.3 调度器怎么工作：一次技能执行的完整链路

技能注册之后，需要一个调度器来跑“从模型决策到技能执行”的完整过程。我用伪代码描述一下调度器核心逻辑，这套逻辑我跑了很多轮，结构比较稳：

def dispatch(skill_registry, user_intent, context): candidates = skill_registry.match(user_intent) if len(candidates) == 0: return default_fallback() selected = model.select(candidates, context) if selected is None: return clarify_to_user() params = extract_params(selected.schema, context) if not validate_required(selected.schema, params): return ask_missing_info() skill_result = execute_skill(selected, params) return skill_result

调度流程的核心原则是：能不给模型做选择题就不给模型做选择题。第一步先用规则缩小候选集（match），这一步把几百个技能过滤到三五个，模型只需要在三五个里选。很多框架直接把全部技能抛给模型做判断，技能一多模型就开始头晕，这是没必要的。规则匹配可以用关键词、意图分类、甚至一句简单的模型分类判断，宗旨都是先瘦身再选择。

参数抽取是另一个关键节点。模型从用户对话里抽参数，经常抽不准，比如把“上周的订单”理解成具体订单号失败。我的做法是分层抽取：先尝试基于 Schema 让模型抽取，抽不全时回退到基于规则的实体识别，再不行就主动反问用户补齐缺失参数。宁可多问用户一句，也不要拿残缺参数去执行技能。

3.4 技能执行时的数据传递与安全边界

技能执行时有一个环节特别容易被忽视——中间步骤的数据传递。很多技能内部要连续调两三个工具，每个工具的输出格式不一致，你需要在技能内部做好适配层。我见过一个项目，第一个工具返回的是 JSON，第二个工具要求 XML，第三个工具又要 markdown，技能内部没有做转换，结果模型生成的中间数据在传递时全乱了。后来我要求所有内部工具统一采用 JSON 输入输出，个别老系统不方便改的，就在技能层包一层适配函数，问题彻底解决。

安全边界方面，我的经验是两个前置设计一定要有：

第一，技能执行的分级审批。如果技能会对真实业务产生写操作（创建工单、退款、发消息），执行前必须在技能定义里声明requires_approval: true，调度器发现这个标记后暂停执行，等人工确认。千万不要想着让模型自己判断“要不要审批”，模型做不到，必须靠注册表里的事前声明来约束。

第二，技能的权限隔离。每个技能对应一套最小化权限，执行时只挂载需要的权限空间。比如说，一个读取物流状态的技能，就不该具备发送企业微信消息的权限。我的项目里踩过一次坑：技能 A 误调用了一段通用工具代码，那段代码恰好有管理员权限，结果因为引入依赖的问题执行了不该执行的写操作，还好是在测试环境。后来我把权限声明也写进技能 YAML，调度器执行前统一校验，从源头掐断这类风险。

3.5 技能的观测日志：别等出问题才抓瞎

技能体系跑起来之后，观测成了最大的隐性工程。模型调用技能是一个黑盒过程，如果不加日志，技能报错或者选择错误时，你连从哪查起都不知道。我给每个技能调用都加了结构化日志，至少记录五个字段：

• skill_name：哪个技能被执行了
• trigger_context：触发时的用户意图摘要
• params_received：实际接收到的入参
• steps_trace：技能内部每一步的耗时和状态
• result_summary：执行结果是否成功、返回了什么

这套日志上线后的价值远超预期。有一次模型频繁选错技能，就是靠对比日志里用户意图和技能选择结果，发现模型总是把“催发货”和“查物流”搞混——两个技能的描述在“适用场景”里高度重叠。后来我调整了一个技能的负面约束描述，准确率立刻上来了。没有日志，这种问题基本只能靠猜。

4. 真实项目中的高频问题与排查方法

4.1 模型总是不选技能，或者选错技能怎么办

这是我在项目里遇到最多的问题。模型对技能存在视而不见，或者明明该用技能 A 却选了技能 B。排查路径我建议按顺序走：

先看技能的“适用场景”写得够不够具体。很多开发者在写技能描述时偷懒，就写一句话“这个技能用来查询订单”，完全没写触发信号。模型就像一个新人员工，你说“这个表格用来记录订单信息”，它不知道该在什么情况下翻出表格。把描述改成“当用户询问包裹当前位置、物流更新进度、预计送达时间时，使用该技能查询真实物流数据”，命中率会明显改善。

再看候选集是不是太大了。如果一次匹配给模型留了十几个候选，模型的选择准确率会直线下降。用规则预筛，把候选压缩到 4 个以内，效果立竿见影。我自己的经验是：3 选 1 的准确率远高于 15 选 1，这一点没有例外。

最后看是不是存在“描述重叠”的技能。两个技能的场景描述太像，模型就会随机选。这时需要主动在描述里写入互斥条件——在技能 A 里写明“用户未确认退款时不要使用本技能”，在技能 B 里写明“用户仅咨询退货政策时使用本技能，不发起实际退款”。把选择边界写清楚，比寄希望于模型自己判断可靠得多。

4.2 参数抽取不准，技能拿到一堆残缺输入

参数抽取是另一个高频问题。模型从用户的话里抽参数，经常抽错或者漏抽。比如用户说“帮我看看上个月最后一个订单到哪了”，模型需要自己推理“上个月最后一个订单”对应哪个订单号。这种推理对很多模型来说都不容易，尤其是在多轮对话里上下文又长。

我的做法是分三层兜底：第一层由模型直接从最近对话抽取；抽不到时进入第二层，调用一个规则化的实体识别模块，从用户原话里提取订单号、日期、商品名等关键实体；第二层还不行，就进入第三层——主动反问用户：“方便提供一下订单号吗？我可以帮您查询具体物流信息”。

很多人觉得反问用户会降低体验，但实际数据表明，让用户多提供一个订单号，比模型拿错误参数硬执行产生误导结果要好太多。宁可多一次交互，也不要给用户一个错误的物流状态。

4.3 技能执行出错，但错误信息是黑盒

技能内部往往要调外部接口，外部接口不稳定是常态。偶尔接口超时、返回异常结构，技能就报错了。这时最怕的是报错信息直接回给用户，用户看不懂，体验极差，排查时也搞不清楚是哪个环节出了问题。

我给所有技能加了“错误转译层”：内部工具抛出的异常，统一捕获后转译为人类可读的业务错误码。比如“物流接口超时”转译为“物流信息暂时更新较慢，请稍后再试”，“订单号不存在”转译为“没有查询到该订单，请核对订单号”。转译规则写在技能代码里，和技能一起维护，避免大段 try-catch 散落在各处。

4.4 多技能协作时流程失控

单个技能跑得挺好，但多个技能组合在一起时，模型容易犯“乱序执行”或者“跳过步骤”的毛病。比如“退换货处理”场景需要先验证订单、再审核条件、再生成退换货单、最后通知仓库。模型可能跳过条件审核直接生成退货单。

这类问题出现时，我不会把希望寄托在提示词上，而是建议把多技能协作上升为工作流：在注册表里增加一个编排层，用显式的流程定义把技能的调用顺序固定下来，模型只负责输入必要参数，不再负责顺序决策。这相当于把“让模型靠自觉做流程”改成“流程替你管住模型”。代价是灵活性降低，但换来的是稳定性和合规性。

4.5 技能数量膨胀后如何维护

项目跑起来之后，技能数从五个涨到二十个、三十个是常事。技能一多，维护成本开始显现：描述没人更新、参数契约和实际代码脱节、废弃技能没人清理。

我的经验是建立“技能清单”的评审机制。每月固定过一次技能清单，按使用频次排序，清理掉三个月以上无人调用的技能；每次技能描述或参数变更时，强制同步更新注册文件，让“技能注册文件”跟着代码评审走。这套机制看起来是流程管理，但实际保住了系统整体的可靠性——一个满是僵尸技能的注册表，模型选错的概率会指数级上升。

5. agent-skills 的下一步：从技能到自组织

5.1 技能与记忆系统的结合

现在我的项目里，技能是“无状态”的——每次执行都是全新开始。但在真实的业务场景中，很多需求是连续性的：用户上一次问过订单问题，这一次又来问售后，Agent 如果能记住用户之前的状态，技能调用的参数抽取会更准确。

下一步我的方向是将技能与记忆系统打通：技能执行前自动读取与该用户相关的历史上下文，例如订单偏好、历史诉求、未完结的流程等；执行后再把结果同步回记忆库。这样技能就不再是一次性的孤立调用，而是有记忆支撑的连续服务。经验判断，这一步能显著提升复杂多轮场景的效果。

5.2 技能质量评测与回归验证

技能体系最容易被忽视的是评测。模型更新版本、提示词重写、底层 API 变化，都可能影响技能命中率。没有评测机制，你根本不知道一次改动是变好了还是变坏了。

我计划在项目里沉淀一个技能评测集：准备一批典型用户话语，标注好期望命中的技能和期望抽取的参数，每次改动后跑一遍评测集，看命中率和参数抽取准确率的变化。这比靠几个手工用例试一下就上线要稳得多。技能多了以后，这种事情不做不行。

5.3 半自动化的技能沉淀机制

最后聊一个更有意思的方向。现在所有技能都是开发者手工定义的，但实际运行中，模型有时会在技能找不到的情况下自己做出一个“近似正确”的行为。把这些成功案例沉淀成新技能候选，是 agent-skills 体系进阶的核心路径。

我设想的是一个半自动流程：配置层开启“疑似新技能”检测，当模型在候选技能集中找不到合适技能却通过自身推理完成了任务时，系统记录这段完整的决策与执行链路，生成技能候选，推送给开发者审核。开发者确认后，把候选转成正式技能注册进技能库。这样，技能体系就能随着真实业务需求持续生长，而不再完全依赖开发者的提前预判。这个方向还在验证阶段，但我认为它是摆脱“手工堆技能”的唯一路径。

写在最后

我自己做完一个完整的 agent-skills 项目后，最大的体会是：用模型做业务落地，难点从来不是模型本身，而是你如何把业务结构变成一个模型能理解、能选择、能稳定执行的东西。技能体系就是一层“业务结构化”的中间表示，它让模型从“自由发挥”变成了“规范操作”，虽然看起来多一些约束，但换来的可靠性和可维护性完全值得。

如果你正准备做 Agent 应用，或者现有系统已经出现工具选择混乱的问题，我的建议是从一个高频业务场景入手，把三五个工具封装成两三个技能，跑通“注册、选择、执行、观测”这条最小链路，再逐步扩展。别一上来就追求几百个技能的宏大体系，那是给自己挖坑。技能不在于多，而在于每一层描述都足够清晰，每一步流程都足够可靠。这条路走稳了，Agent 才能真正从“能聊”变成“能干”。