企业官网建设流程全解析

上周有个朋友跟我吐槽，他们公司费了不少力气做了一个Agent，演示的时候很惊艳，可一丢到真实业务里就露馅了：让它整理会议纪要，它给你一段漂亮的总结却漏掉了关键决策；让它查一下库存再回邮件，它查完了邮件倒是写出来，但把库存数量写错了。问题出在哪？不是模型不够聪明，而是这个Agent根本没有"干活用的技能"。后来我们把一套Agent Skills补进去，它才从"会聊天"变成了"能交付"。这篇文章就把我这几轮实操摸索出来的东西整理一遍：Agent Skills到底是什么、怎么设计、怎么写、怎么接真实业务，以及一路踩过的坑。不管你是正准备入门，还是已经做过几个Agent Demo，这篇应该都能帮你少走点弯路。

1. 先想明白：Agent会聊天，但为什么总是"干活"翻车

1.1 别把"智商高"当"能干活"——模型的上限和下限

大模型的推理能力很强，你问它问题，它往往能答得头头是道。但"干活"是另一回事。干活意味着要面对一个不规整的输入，按一套稳定的流程处理它，调用必要的外部工具，并且产出一个符合下游系统要求的输出。这个过程里，任何一个环节松了，结果就废了。我见过很多团队把大模型当成一个"万能实习生"，结果发现它今天给你干得像样，明天同样的输入就给你干走样了。

这里有个概念必须分开：模型能力决定的是"上限"，工程封装决定的是"下限"。模型再聪明，也有发挥不稳定的时候；而真正的线上应用，拼的是下限稳不稳。Agent Skills改的恰恰是下限——它把一次性的"聪明"变成可复制的"稳定"。这也是为什么很多Demo项目跑得通、一上生产就崩的核心原因：Demo拼的是模型上限，生产拼的是工程下限。

所以别再把"模型很强"等同于"Agent能干活"。模型强只是地基，Agent Skills是地基上面那套排水、电路、门窗——没有这些，房子没法住人。后面所有内容，都是围绕怎么把这件事补起来。

1.2 Skills到底是什么：给Agent装"职业技能"

我之前给朋友打过一个比方：一个应届生很聪明，但你要让他上手做客服，还是得先给他做岗位培训——告诉他公司的话术规范、工单系统怎么用、哪些问题该升级、哪些坑不能踩。Agent Skills就是大模型的"岗位培训材料"。

更具体地说，一个Agent Skill通常包含这样几块内容：

• 技能说明（description）：这个技能是干什么的、什么时候该触发、什么时候不该触发。
• 执行指令（instructions）：处理任务的具体步骤，越明确越好。
• 工具清单（tools）：处理过程中需要调用的API、脚本、数据库等外部能力。
• 输出规范（output schema）：结果必须长成什么样，哪些字段必须有。
• 校验规则（validation）：结果出来之后，怎么判断合不合格。

这几块合在一起，就等于把"做一件具体事情的方法论"封装成了一个可复用单元。Agent拿到任务时，会先看自己的技能清单，如果任务匹配某个Skill的description，它就把这个Skill的一整套流程跑起来。

注意这个思路和"在对话里塞一段Prompt"完全不同。Prompt是一次性的，换个场景就失效；而Skill是结构化的、可版本管理、可测试、可被多个Agent复用的。这也是为什么现在做Agent应用，大家越来越强调Skills而不是单纯堆Prompt。

1.3 Skills和插件、工作流、工具调用差在哪

这块我一开始也混淆过，经常听人把"插件""工具调用""工作流""Skills"混着说，实际上它们解决的是不同层面的问题。我做了个对比，方便理解：

工具调用解决的是"手够不够长"，RAG解决的是"知识够不够全"，工作流解决的是"流程是否可控"，而Skills解决的是"一件事能不能稳定做完做好"。它们之间有重叠：Skill执行过程当中一定会调用工具，也可以内置一个小工作流；但Skill的粒度比单次工具调用大得多，它描述的是"一个任务怎么做"，而不是"一个动作怎么执行"。

以做菜类比：工具调用是"我有锅和刀"，Workflow是"必须先洗菜、再切菜、再下锅"，Skills则是"我会做一道麻婆豆腐"——它背后绑定了食材清单、处理手法、火候顺序和出锅标准。做Agent的时候，如果你只有工具和工作流，模型就像手上全是零件但不会组装；你把Skills补上之后，它才真正"会做菜"。

2. 设计Skills之前，先把任务拆对了

2.1 什么样的任务才配做成Skill

不是所有任务都值得做成Skill。我在早期犯过一个典型错误：什么功能都想封装成Skill，结果维护成本暴涨，而且很多Skill几乎没被触发过。做了几轮之后，我总结出了更适合做成Skill的任务特征。

高频。如果这个任务一个月才出现两三次，你把它写成Skill太大材小用。

标准化。任务的输入和输出相对固定，有清晰的成功标准。比如"整理会议纪要"、"生成周报"、"解析发票信息"这类就很标准；但"帮我写一封让客户满意的道歉信"这种极度依赖语境和创意的任务，就不适合封装死流程。

有明确的产出物。Skill应该产出可以被下游消费的东西，比如一段结构化JSON、一份Markdown文件、一条数据库记录。

当前模型裸做容易翻车。这是很多人忽略的一个点——如果模型直接两句Prompt就能干得又快又好，你也不需要封装了。Skill的价值恰恰在于"裸做不稳定，加一层流程之后就稳定"。

反过来说，那些探索型、发散型、高度依赖情感判断的任务，最好不要硬塞进Skill里。硬封装的后果就是输出千篇一律、模态僵化，用户反而觉得这个Agent变蠢了。

2.2 一个动作拆成"输入→处理→输出"

确定要做一个Skill之后，第一步不是写代码，而是把任务拆开。我习惯用"输入→处理→输出"三段式去拆。拿会议纪要Skill举例子：

输入侧：可能是会议录音转写文本、参会人名单、会议主题。这些输入来源不同，有的是用户自己粘贴的，有的是系统拉取的，你要先想清楚到底接受哪一种。

处理侧：这个环节会拆成若干动作序列。比如：

• 清洗文本：删掉语气词、重复片段、无意义停顿标记。
• 分段：按讨论主题把整篇内容切成若干块。
• 提炼：每个主题块里找出结论、分歧、未决问题。
• 汇总：整理出决策清单和行动项清单。

输出侧：最终呈现为结构化的会议纪要，包含摘要、决策列表、行动项列表（每项带负责人和截止时间）。

拆到这种粒度之后，你再去看每一步是模型直接做，还是需要调工具，还是需要加一段确定性逻辑。比如"清洗文本"这种活，其实用正则或简单的字符串处理更快更稳，就不必让模型做；而"提炼结论"这种语义活，才需要模型上场。

我做过的另一个"自动生成日报"Skill也是这么拆的。输入是当天的工作日志和代码提交记录；处理侧把日志按项目归类、按时间排序、再按产出度打分；输出是一份按项目分组的日报文本。拆完之后，每一步都知道该用什么手段去实现，后面写的时候就不会纠结。

2.3 写清"何时用、怎么用、别乱用"

Skill里的description字段，很多人不当回事，随手写一句"整理会议纪要"就完事。但实际运行中，Agent是拿着任务去匹配Skill清单的，它判断"该不该用这个Skill"完全依赖description。写得太短，模型就会误触发。

我给你看一个真实场景。之前有个团队做了一个"周报助手"Skill，description写的是"生成周报"。结果用户问"上周我们组做了什么"，模型就把这个Skill拉出来跑了一遍，输出了一份格式化的周报——但这个用户其实只是想知道一件事的进展，根本不需要一份周报。这就是典型的误触发。

后来我们把description改成："当用户需要根据本周工作记录、代码提交或任务系统数据生成一份结构化周报时使用。适用于用户明确要求'生成周报''写周报'或'汇总本周工作'的场景。如果用户只是询问具体任务进展，不应使用本技能。"改完之后，误触发率明显下降。

所以写description要回答三个问题：什么时候该用、输入是什么样、什么时候不该用。别嫌啰嗦，模型的工具匹配能力还远没到"你写个标题它就懂上下文"的程度。

3. 从零实现一个"会议纪要"Skill，跑通最小闭环

3.1 第一步：写出一份合格的Skill清单

我建议你维护一份Skill清单文件，用一个结构化的YAML格式来声明每个Skill的元数据。这是我在实际项目里用惯的写法，你可以直接抄：

name: meeting_minutes_v1 description: 将会议转写文本整理成结构化会议纪要，包括摘要、决策和行动项。 适用于用户提供会议录音转写文本并明确要求整理会议纪要的场景。 如果用户只是询问某次会议内容，不应使用此技能。 inputs: transcript: type: string required: true description: 会议转写文本，可以是录音识别结果或人工记录 attendees: type: array required: false description: 参会人员名单，可选 instructions: - 清洗转写文本，删除语气词、重复片段和无意义内容 - 按讨论主题对内容进行分段 - 从每段中提炼结论、分歧和未决问题 - 汇总所有决策并生成决策列表 - 整理行动项，每项包含任务描述、负责人和截止时间 tools: [] output_schema: summary: string decisions: type: list items: string action_items: type: list items: task: string owner: string due_date: string validation: required_fields: [summary, decisions, action_items]

这个清单有几个好处：它是纯文本的，可以放进Git仓库做版本管理；它可以被一个调度模块读取，自动挂载到Agent的技能列表里；它让模型在每次执行前都能看到"这个Skill到底怎么干"。

有一点要注意：instructions里的步骤不要写"好好总结""确保准确"这种废话，要写具体动作。我给的这个清单里，每一步都是一个明确的操作指令。你写得越具体，模型的执行就越稳定。

3.2 第二步：把处理流程翻译成执行指令

Skill清单里有了步骤之后，还要把这套步骤翻译成模型真正会去执行的那段指令。这一步把你的抽象流程"讲"给模型听，大部分时候其实就是一段结构清晰的系统指令。

我常用的做法是把每一段指令写得像SOP一样，甚至带上编号和强调词：

你是会议纪要整理助手。严格按以下步骤处理用户提供的会议转写文本，不要跳过任何步骤，不要添加原文中不存在的信息： 步骤1：清洗文本。删除口头禅、语气词、重复片段，保留完整语义。 步骤2：分段。按讨论主题将内容分为多个段落，每段起一个主题名。 步骤3：提炼。对每个主题段落，提取结论、关键分歧、未决问题。 步骤4：汇总决策。把全文所有已经达成的决策写入decisions数组。 步骤5：整理行动项。从原文中找出所有待办任务，写入action_items数组。 每项必须包含task、owner、due_date。 如果原文没有提供负责人或时间，在对应字段填"待确认"，不要编造。

这段指令看起来简单，但它踩住了两个关键点：步骤编号防止模型跳步骤；"不要添加原文中不存在的信息"和"不要编造"这两句，是在压制模型最常见的幻觉。根据自己的经验，加了这两句话之后，输出里凭空出现的待办事项数量能下降一半以上。

还有一个实用技巧：把指令和Skill清单分开存。清单是给人看和做索引的，指令是给模型执行用的。你不能把一堆YAML直接扔给模型让它照着来，模型读YAML的效率和读自然语言指令的效率完全不一样。

3.3 第三步：用结构化输出卡住结果质量

Skill做完之后还差最后一件事：规定输出长什么样，并且按标准验收。很多Agent翻车不是模型不会干活，而是输出格式飘忽不定，下游程序一接就崩。

我在会议纪要Skill里是这样定的输出格式：

{ "summary": "本次会议讨论了Q3营销方案，确定了两项核心决策...", "decisions": [ "Q3预算按600万执行", "重点投放方向从搜索转向视频" ], "action_items": [ {"task": "完成视频素材需求整理", "owner": "某同学", "due_date": "2025-07-10"}, {"task": "更新排期表", "owner": "待确认", "due_date": "待确认"} ] }

并且加了一条校验规则：如果summary为空，或者decisions和action_items为空数组，这个输出就算不合格，需要让模型重新生成。这一步本质上是在给模型加一道"质检关卡"。

我之前在这个环节踩过一个坑：把输出schema卡得太死，要求模型必须从十个预设分类里选一个，结果模型为了满足格式要求而编造分类。后来我把预设项都改成"允许填写其他"，并且加了"如果内容不属于任何分类，请填写其他并在备注中说明"这一条，幻觉才明显缓解。所以结构化输出的原则是：框架可以严格，内容不要逼迫模型撒谎。格式上严厉一点，内容上宽容一点——这两者要平衡好。

4. 进阶：让Skill真正接入业务

4.1 让Skill能调API：把外部能力变成"一步动作"

会议纪要Skill可以靠模型本身完成，但绝大多数真实业务Skill必须接外部系统。比如你做一个"订单查询"Skill，模型本身不知道订单状态，它得去调后台API。这时候你就要用到函数调用（Function Calling）机制，把API封装成可供模型选择的一个"动作"。

实操层面我通常这样封装：

def query_order_status(order_id: str) -> dict: """查询订单当前状态。 Args: order_id: 订单编号，字符串类型 Returns: dict，包含订单状态、物流节点、预计送达时间 """ # 这里调用真实的订单查询接口 resp = order_service_api.get(order_id=order_id) return { "status": resp["status"], "tracking": resp["tracking_log"], "eta": resp["estimated_arrival"] }

把这个函数挂到函数调用列表里之后，模型在回答用户关于订单状态的问题时，就能自己判断"需要调用query_order_status"，并解析返回结果再组织成用户能看懂的话。

但这里有一个容易翻车的点：外部API不是永远可靠。我自己的经验是，每一个被Skill调用的外部动作都要单独配一个兜底分支。比如上面这个函数，如果API连着超时三次，就应该返回一个固定文案"订单系统暂时繁忙，请稍后再试"，而不是让模型瞎编一个物流状态。你要记住：模型在拿不到真实数据的时候，第一反应就是编，所以兜底逻辑必须由工程侧写死。

4.2 组合多个Skill：从单技能到组合拳

单个Skill能解决单个任务，但真实业务很少只有一个任务。比如"处理一条客户投诉"这件事，至少涉及三个动作：先判断客户情绪，再对问题做分类，最后生成回复方案。你可以把这三个动作分别封装成三个独立Skill，然后让一个主Agent统一调度。

这个过程其实非常像团队协作。我见过一个比较成熟的做法是这样的：

• 设置一个"调度Agent"，它的工作是根据用户任务，从技能库里选合适的Skill组合。
• 调度Agent先调用"情感分析Skill"，输出客户情绪等级。
• 再调用"问题分类Skill"，把投诉归到某个问题类型。
• 最后调用"回复生成Skill"，结合情绪等级和问题类型，生成一段回复。

这里有两个设计要点。第一个要点是Skill之间的传参要标准化。情感分析Skill的输出必须是一个包含level字段的JSON，问题分类Skill才能直接读那个字段，否则两个Skill之间就会出现"数据对不上"的断点。第二个要点是调度Agent的决策逻辑要足够清晰，它自己也要有明确的指令，告诉它什么情况下应该串行调用、什么情况下可以并行调用。

我不建议一上来就做大量Skill的复杂编排。先做两个Skill的串联，跑通数据衔接，再逐步增量，这是最稳妥的路子。我见过有团队第一版就想做八个Skill的自动编排，结果调了一周，最后发现大部分问题都出在Skill之间的数据契约上。

4.3 怎么管理Skill版本：给团队复用做准备

Skill一旦多了，管理就成了新问题。我见过最混乱的状态是：一个团队代码库里散落着二十几个Skill文件，每个人都按自己的习惯改，改完也不更新说明，最后谁都不敢动，一动就坏。

我自己的经验是，Skill要像代码一样管起来。具体做四件事：

• 进Git仓库：每个Skill目录下放一个skill.yaml，和它的关联脚本、测试用例放在一起。
• 命名带版本：meeting_minutes_v1、meeting_minutes_v2，不要只叫meeting_minutes。这样你随时可以回滚。
• 每个Skill配一个测试集：准备5到10个典型输入样本，每次改动都跑一遍，看输出有没有回归。
• 写变更记录：改了什么、为什么改、效果怎么样，几句话就够。别小看这个，没有它，一周之后你自己都不知道当初为什么这么改。

我还建议建一个"Skill卡片"文档，一张卡片对应一个Skill，写上它的用途、输入输出、负责人、最近变更。这样不管团队规模多大，新同学来了一眼就能看懂这个Skill是干什么的，而不是靠翻几万行代码去猜。当时我们把这一套落地之后，Skill的复用率一下子高了——因为大家终于知道仓库里已经有哪些Skill了，不用再重复造轮子。

5. 实战里的坑与排查技巧

5.1 我先列几个真实踩过的坑

第一个坑：description写得像白开水。前文提过，description太短会导致Skill被误触发。这个坑的隐蔽之处在于，它在Demo阶段几乎不显现，因为Demo的数据量小、任务单一，一旦上真实业务，用户问题五花八门，误触发就像雨后春笋一样冒出来。

第二个坑：输出schema设置过严。总想让模型输出一个完美的JSON，每个字段非空、枚举值必选，结果逼着模型编数据。我到现在还记得一个案例：一个"竞品分析"Skill要求必须填五条竞品信息，某次只找到三家，模型硬编了两家出来，差点误了决策。设置schema的时候一定要考虑"数据不足时怎么办"，给它一个"允许留空"的口子。

第三个坑：指令里塞了太多工具。有个团队做一个"智能客服"Skill，一口气挂了二十个工具，结果模型经常选错工具。后来精简到四个，准确率立刻上来了。模型做工具选择时，选项越少越准，这是很朴素但经常被忽略的道理。

第四个坑：忽略输入清洗。会议转写文本里经常带着"嗯""然后然后"这类噪声，直接丢给模型去做总结，输出质量就会很飘。你如果先在工程侧把文本清洗干净，模型的表现会稳定很多。这个坑说明了一个指导思想：能确定性处理的东西，就不要丢给模型。

5.2 出问题时，按这个顺序排查

Skill出了质量问题，我建议按下面这个顺序排查，不要在乱猜上浪费时间。

第一看触发：日志里模型到底有没有调用这个Skill？很多时候你以为它调了，其实它压根没调，自己裸答了。先确认Skill有没有被触发。

第二看输入：传给Skill的输入是不是符合预期？我遇到过很多次，问题不在Skill本身，而是上游传进来的文本是乱码、格式错位、或者字段都没取对。

第三看指令：输入没问题，再看指令。指令里的步骤是否符合这个输入类型？有没有可能某一步要求的信息在输入里根本不存在？这类冲突要尽早发现。

第四看输出：如果指令没问题，就看输出校验。比如输出的JSON经常解析失败，那大概率是schema定义有问题，或者模型被迫编了内容。

第五看外部依赖：最后才查外部API、数据库这些依赖。这个顺序很像医生问诊，按可能性和影响面排序，快速定位病灶。

5.3 三条标准判断Skill好不好用

Skill做出来之后，怎么判断它是好是坏？我习惯用三个指标来评估。

可执行率：模型在应该触发这个Skill的任务上，到底触发了几次？低于80%说明description写得不对，或者匹配逻辑有问题。

成功率：触发之后，产出的结果是否通过了输出校验和人工抽检？这一步直接反映指令写得好不好。

回归稳定性：同一组测试输入，反复跑几轮，结果波动大不大？如果一个Skill这次输出优秀下次输出稀烂，那说明它的执行流程里还有未被约束的环节，要补指令或补校验。

我自己的评测方法很朴素：每个Skill准备10个典型输入样本，建一个评估集，每周跑一轮，人工给输出打通过/不通过，把通过率记下来。不需要什么复杂平台，一个表格就够了。通过率稳定在90%以上，我才敢把它放进正式流程；低于这条线，就继续回去调description和指令。久而久之，你手头就会有一批真正经得起折腾的Skill。毕竟，让人省心的Agent，背后终究是让人省心的Skill工程。