企业官网建设流程全解析

1. 为什么我们需要一套“Agent Skills”体系

1.1 一个让我重新审视Agent开发的场景

先聊聊我自己的一段经历。年初某团队在做一个人力资源领域的智能助手，需求不算复杂：候选人投递简历后，Agent需要自动解析简历、评估匹配度、生成面试邀约邮件，并在HR确认后更新招聘系统的状态。

刚开始，我们把所有逻辑都塞进了System Prompt。效果呢？简历解析还好，但一旦涉及多轮任务——比如候选人回复邮件询问改期，Agent就很容易混乱：分不清当前是“重新邀约”还是“新流程”，偶尔还会调用错误的工具参数。

后来我们做了一次重构，把能力拆成一个个独立的“技能”模块，每个技能负责一件事，比如parse_resume、score_match、generate_email、update_ats。再配一个简单的调度层，让Agent根据用户意图选择技能、编排顺序。效果立刻上来了：任务成功率从68%提升到91%，关键是在后续迭代中，每次新增功能都不需要动Prompt骨架，只需要往技能库里塞一个模块。

这个项目的存储库名就叫agent-skills。这篇文章，就是把那次重构和之后几个项目里沉淀下来的思路做个完整复盘，希望能帮你少走一些弯路。

1.2 从“函数调用”到“技能编排”的思维转变

很多接触过大模型开发的人都知道Function Calling，但“Agent Skills”和它不是一个维度的东西。

函数调用解决的是“模型如何调用工具”的问题，核心是参数填得准不准；Agent Skills解决的则是“模型如何把多个动作组合成一套解决方案”的问题，核心是流程组织得好不好、边界是否清晰。

用一个生活类比来说：函数调用是你会使用“锅碗瓢盆”，技能体系则是你懂得按顺序“先烧水、再下面、最后调味”做出一碗面条。

所以，谈到Agent Skills，我眼中的定义更接近“面向目标的、可复用的、带元信息的能力单元组合”。它不是单函数，而是函数、提示词片段、规则和前置条件的集合，随时可以被Agent检索、编排、回退。

这套体系的价值体现在几个场景里：

• 多步业务场景：简历解析完接着评估再发邮件，是天然技能链
• 工具众多时避免选择困难：技能分域管理，模型不用全量检索
• 长尾能力沉淀：某个小技巧、某个特定领域流程，可以固化成技能，反复复用
• 人机协作维护：非开发者也能通过“录制一段操作”的方式生成技能

一句话，Agent Skills是让Agent从“能调用工具”进化到“会做事情”的那层黏合剂。

2. 技能的分层模型：基础技能、复合技能与元技能

2.1 技能的本质：把不确定性变成确定性

我们在项目中最常犯的错误，是把“技能”当成“代码片段”或“几个函数的集合”。但真正有用的技能，应该包含四个要素：

• 触发条件：什么时候这个技能可以被选中
• 输入输出约束：技能接收什么结构的数据，输出什么结构的数据
• 执行逻辑：具体怎么做，可能是函数代码，也可能只是Prompt
• 评估与回退：怎么判断成功，失败了怎么处理

基础技能是最小的原子操作。比如send_email、query_database、parse_pdf。它们的特点是职责单一、输入输出明确、没有复杂的内部状态。这类技能通常直接映射为一个工具函数。

复合技能则是编排层。它把一个业务流程固化成模板，比如“候选人改期邀约”可以拆解为：读取原档期→查询面试官新空档→生成新邀约邮件→发邮件→更新日历。复合技能的价值是让Agent面对常见场景时，不必从零推理步骤，直接“照方抓药”。

元技能管的是“如何学习新技能”和“如何评估技能效果”。比如，系统可以设定一个“新技能试运行”流程：新技能先在low-traffic模式下跑一段时间，收集成功率数据后再转正。这套机制本身也是一种技能。

2.2 三层技能模型的实际分工

我在自己项目里习惯用一套简化的三层模型。这里用一个表格说明它们的协作边界：

分层模型最直接的收益，是让开发和调试都变得可聚焦。基础技能出了问题，单独测函数即可；复合技能出问题，重点查编排顺序和条件分支；元技能出问题，才需要动整体调度逻辑。

我踩过的坑是：一开始把所有技能都揉在一起，Agent运行时频繁出现“记忆混乱”。后来强制按层管理之后，问题大幅减少。每一层技能在模型上下文里的描述格式都要统一，这样调度器才能稳定地做选择。

3. 实战构建：“技能注册、发现与编排”的完整链路

3.1 技能接口规范：让所有技能长得一样

构建技能库的第一步，不是兴奋地写各种能力模块，而是先定义一套统一的“技能描述语言”。否则技能之间差异过大，调度模型几乎没法学会正确选择。

我在项目中采用过一个很简单的接口规范，效果不错。每个技能包含下面这些字段：

name: book_interview_slot description: 预订一场面试，需要候选人ID、面试官ID、起始时间 domain: interview input_schema: candidate_id: string interviewer_id: string start_time: string duration_minutes: integer output_schema: booking_id: string status: string success_criteria: - booking_id exists fallback_strategy: notify_hr_for_manual_schedule priority: high

这里有一个关键点：description必须写清楚“什么情况下调用”，而不是只写“这个技能能做什么”。模型是靠语义匹配来选技能的，如果你的描述是“预订面试”，而用户的表达是“帮我把下周二上午跟张面试官约个时间段”，匹配度不一定够。但如果你写的是“当用户在面试流程中需要为候选人安排或修改面试时间、且已提供或可推断出候选人、面试官、期望时间时可调用”，匹配成功率会高很多。

fallback_strategy也很重要。技能一定会失败，关键在于失败后模型知道还有什么招数。没有fallback设计，技能一旦报错，Agent就会陷入“卡住”状态。

3.2 技能注册与检索：从全量背下来到按需找

技能库一旦变大，把所有技能描述都塞进Prompt是不现实的。尤其是基础技能超过20个之后，按OpenAI或Claude的上下文限制来看，光技能描述就可能占据三四千token，这会挤占业务上下文的空间。

我采用的做法是“分层检索”：

• 常驻技能（不超过10个）：每个Agent的base prompt里都会列出最常用的核心技能，这些技能覆盖这个Agent岗位的主业务
• 候选技能池：剩余技能按照域名分组（HR场景、技术场景、财务场景），由调度模型动态检索
• 检索方式：可以用向量相似度，也可以在调度时让模型先“生成意图标签”（如intent=interview_reschedule），再用标签精确匹配技能池

我实测下来，第二种“意图标签+规则匹配”的方式准确率更高，尤其是在中文场景下，向量检索容易受同义词干扰。比如“改约”和“重新安排一下面试时间”，向量上相似但可能偏差不小。用意图标签收敛后再匹配，稳定性强很多。

注册机制上，可以做一个简单的“技能注册中心”：新增技能时提交YAML描述，注册中心校验字段完整性、检测同域名下是否有重复技能、跑一遍最小烟雾测试（比如给一个构造示例输入看输出格式），通过后自动加入候选池。

3.3 编排引擎：让它自己会“串流程”

编排是技能体系里最有意思的部分。核心思路是：不要用Workflow硬编码每个业务场景的走向，而要让模型基于“技能依赖关系”自行串联。

你可以在技能元信息里增加can_trigger字段，声明这个技能执行后可能连带需要执行的下一批技能。例如：

name: generate_interview_invitation can_trigger: - send_email - add_calendar_event

调度模型读到底层的输出后，根据can_trigger来决定是否继续调用后续技能。本质上是一种“基于程序预设依赖的自主决策”。

这里要提醒一点：编排时一定要注意“过程可见性”。每个技能的输入输出都加入一个trace_id，在UI界面上展示为一条时间线。调试时候你会发现，有了trace，10分钟就能定位到“是哪一步传参传错了”，没有trace，找bug可能得一下午。

4. 技能调度中的三个硬骨头：上下文、回退与多技能冲突

4.1 上下文简报机制：让小模型也能处理大任务

技能越多，中间产生的状态和中间结果就越多。如果你把简历解析长文本、数据库查询返回结果全部原样堆积到上下文里，很快就爆掉了。

我用过一个很有效的方式：每个技能执行完毕后，不一定把完整结果交给模型，而应该由技能自身生成一份“简报”。比如解析了一份60页的候选人简历PDF，模型不知道细节也没关系，关键是提取出结构化摘要：姓名、工作年限、关键项目经历、教育背景。简报控制在300字以内，不仅省token，而且降低了模型对无关细节的注意力分散。

生成简报的方式可以是规则提取，也可以让模型对技能输出做一次 summarization。我的建议是第一版用规则提取，因为稳定可控。

4.2 技能回退：接受失败是常态

在一个自动化系统里，技能失败不是可不可能的问题，而是什么时候发生的问题。没有设计回退机制，Agent就会出现类似“死循环”的状态：同一个技能失败十次还在重试。

我在项目中定义了四级回退策略：

回退逻辑的开关尽量放在技能YAML里，不要硬编码在代码里。因为不同的业务场景，对成功率的诉求不一样：简历解析失败可以悄悄地重试，但发邮件失败了必须立刻通知人。

4.3 多技能冲突时的仲裁策略

当模型有权自行编排技能时，冲突几乎必然出现。最典型的例子是：用户说“把下周一所有会议都取消，但保留和导师的一对一”。系统同时检索到cancel_meetings和find_mentor_meeting两个技能，如果Agent机械地全量调用，就会误删。

我总结了一条简单的仲裁原则：写入类操作（增删改、发消息）必须经过“意图确认+前置条件校验”，读取类操作可以自动执行。

在实现上，我们把技能的side_effect字段设为destructive或readonly。destructive类技能在执行前，调度器强制要求先调用一次confirm_intent技能，向用户展示影响范围并等待确认。这招极大降低了不可逆操作的出错率，尤其是邮件外发和数据库删除之类的动作。

5. 让技能体系可持续生长：评估、版本与权限治理

5.1 每次执行都是一次标注：成功率追踪的落地方法

我遇到的一个实际问题是：一个技能上线时效果很好，但三个月后业务调整，它的调用成功率直线下降，却没有任何人察觉。

所以我后来给技能库加了一个“健康度面板”。每次技能调用结束，后台都会自动标记三件事：

• 是否到达成功标准
• 是一次性成功，还是重试1次、2次后才成功
• 失败时触发了哪一级回退

每周汇总一次，就能得到每类技能的周成功率曲线。对于准确率下降超过5个百分点的技能，自动将它标记为“待观察”，超过10个百分点则移出候选池，转人工审查。

5.2 版本管理：改技能不等于改代码

技能库本质上是一个逐渐演进的系统。复合技能经常要调流程、改字段。如果不做版本管理，很容易出现“模型描述和实际逻辑不一致”的问题。

我在项目里给每个技能套一个version标识，升级不是替换，而是“影子模式”——新版本与旧版本同时在线，按一定比例分流流量，对比两者的调用成功率和用户满意度。达到指标后新版本转正，旧版本归档，保留3个历史版本以便回滚。

5.3 权限治理：技能越多，越要小心越权

当你把多个技能组合起来时，组合后的能力可能会超过单个技能的权限边界，形成越权路径。

有一种串谋：query_employee_salary和send_email_to_employee都是正常技能，但组合起来就可以把工资信息发给无关人员。

因此我们的技能注册中心里专门有一层permission_policy，标注每个技能的数据敏感等级。调度器在做串联之前，会先做一次“组合权限校验”：如果输出方等级为p3，输入方等级为p2，则禁止直连。需要将这个场景上报管理员，人工确认后才能新建跨级组合。

这一层一开始看起来“多此一举”，直到真的拦截了一次潜在的数据外泄，我才意识到它在技能体系里有多么关键。

6. 踩坑实录：我从Agent Skills项目里学到的教训

讲几个非常具体的坑，都是实际写代码时才体会得到的。

第一个坑：技能描述写了“太长太多”。一开始我们为了让模型选得更准，给每个技能写了两三百字的description，结果可读性反而下降，模型被不重要的细节干扰。后来强迫自己用三句话以内完成描述：这个技能什么时候用、输入是什么、输出是什么。准确率反而上升了。

第二个坑：技能编排时不保留中间产物。有些复合技能有多个分支，我们早期让底层函数返回什么就直接丢给下一个技能，结果一旦流程变化需要回溯——比如第三个技能发现第二步的结果没算对——就会因为缺少中间产物而整个重来。改成保留每个技能输出快照之后，回退定位的代价降了一个数量级。

第三个坑：没有考虑“模型偏好”。同一个场景如果同时存在两个技能都能解决问题，模型通常会倾向于选先出现的那个或名字看起来更匹配的那个，而不是真正更优的那个。所以技能库的排序不是固定的，我们会定期根据成功率把更优的技能往前排，甚至给技能增加一个bias_weight字段调节命中率。

第四个坑：离线评测不够真实。技能库刚搭好时我们用模拟数据做验证，一切顺利。但到了线上，输入数据格式五花八门，比如候选人生日字段是中文“一九九三年五月”，而不是标准ISO格式，直接导致解析技能报废。后来我把“脏数据样例”也加入了技能烟雾测试集里，上线前的置信度才算真正可靠。

7. 写在最后的一个扩展思路

如果这套体系你已经跑通了，还有一个高收益的方向：把技能库本身变成可共享的“内部市场”。

比如某团队沉淀了一套“专业面试提问生成”技能，另一团队在做选拔评估Agent时，直接订阅这个技能，无需重新开发。做一次技能封装，多个Agent受益。这就是技能体系从“工程手段”变成“组织能力基础设施”的转折点。

更远的想象是技能的“复合再生长”。当技能数量达到一定规模，系统可以自动检测频繁同时出现的技能对，提示用户“这两个技能经常串联，是否合并为一个新技能”。这次运营就完成了从人工设计到自动进化的切换。

所以，如果你正准备构建自己的Agent项目，我建议不要只是纠结“这个任务用什么函数”，而是从第一天就把功能抽象成“技能”、把业务流程抽象成“技能编排”。你的Agent才不会只是一个“会调工具的玩具”，而是一个“真正会做事的产品”。

最后再分享一个小技巧：技能库的每个技能记得都加一个human_fallback_prompt字段，一旦无法自动处理，就把这段说明拼到提示里转给人工处理人。你会发现这个字段的存在，能让你的自动化系统在全链路执行的可靠性和安全感上提升一个极大的台阶。