企业官网建设流程全解析

1. 项目核心：先把“智能体技能”这件小事想清楚

如果你也把 Agent 当成一个“只会聊天的大模型”来调，那大概率会遇到一个非常经典的困境：模型回答什么都对，但让它干活的时候，总像一位纸上谈兵的实习生——理论满分，落地全废。它不会查数据库，不会调接口，不会把乱七八糟的 JSON 结构整理成表格，更不会在出错时换一种策略重试。这个问题的本质，不在于模型的推理能力不够，而在于根本没给它配“手脚”。所谓 agent-skills，就是给大模型装上可复用的“技能包”：它是一组经过设计的工具、指令与工作流的组合，让模型在对话之外真正能执行任务、调用系统、操作数据、完成闭环。

我最早接触这个方向时，还只是把一两个 API 封装成函数塞进 Prompt 里，结果 Prompt 越来越长，模型越来越懵，工具一多就互相打架。后来我花了大量时间把技能从 Prompt 里“拆”出来，做成一个独立的技能库模块，也就是这个 agent-skills 项目的雏形。它的核心思路其实不复杂：技能不是模型的提示词，而是模型可以按需调用、可组合、可编排的一组标准化操作单元。

这个项目适合谁来参考？如果你正在搭建个人助理、自动化工作流、垂直行业问答机器人，或者只是想在 LLM 应用里加入“工具调用”能力，agent-skills 的分层设计、协议约定和踩坑记录都能直接作为一套可复用的参考模板。它解决的不是“怎么让模型更聪明”，而是“怎么让模型更能干”这一更底层的问题。

很多人刚接触这个概念时会下意识地觉得：这不就是函数调用（Function Calling）吗？其实两者有重叠，但视角不同。Function Calling 是模型与外部函数之间的“一次性握手”；而 agent-skills 更接近一个“工具箱”，它包含了工具的元信息、前置条件、后置校验、执行策略，甚至包含多个工具如何编排成一条完整工作流。用生活里的话说，Function Calling 是打电话叫外卖，agent-skills 是“家里备了一套厨房，包括菜谱、食材管理、烹饪流程和备用方案”。

2. 设计思路：为什么技能必须“分层”，而不是堆一堆函数

2.1 技能分层的核心动机

我在项目早期犯过一个典型错误：把技能全部平铺在一个层里，查询数据库的函数、写文件的函数、发送邮件的函数、解析 PDF 的函数全部堆在一个目录里，让模型自主选择。结果自然是灾难性的。模型经常在“该调用哪个技能”这件事上选择困难，甚至会在一次任务里连续调用七八个无关函数，把上下文窗口塞满。

后来我把技能拆成了三层，这也是 agent-skills 项目目前最核心的设计骨架：原子技能层（Atomic Skills）、组合技能层（Composite Skills）与编排层（Orchestration Layer）。

原子技能是最小的、不可再分的操作单元，比如“读取一个文件”“执行一条 SQL”“调用某个内部 API”。每个原子技能只做一件事，输入输出都被严格定义。组合技能则是把多个原子技能按特定顺序拼接成一个有意义的动作，比如“读取用户上传的 Excel → 校验字段 → 清理空值 → 生成统计摘要”这是一个完整的组合技能，但其中每一步都是独立的原子技能。编排层则负责理解用户意图，决定“今天这个任务到底该跑哪个组合技能”，以及多个组合技能之间的切换逻辑。

这个分层所带来的直接收益是：可测试性大幅提升。原子技能可以单测，组合技能可以做集成测试，而编排层可以交给模型去动态决策。出了问题时，你可以精确地定位到“是某个原子技能的执行出错”，而不是在一团乱麻里猜模型到底干了什么。另一个好处是复用性，新项目要接入不同的业务场景时，不需要重写所有技能，只要在编排层加一些新的组合逻辑，或者新增少量原子技能，就能覆盖一个新场景。

2.2 技能的协议设计：让模型“看得懂、调得对”

技能设计里最容易被忽略的，是“模型视角”。我们写代码时习惯用驼峰命名、缩写变量，但模型对名称的语义理解完全依赖自然语言。技能命名和描述写得不够清晰，模型就不知道该在什么时候调它。

我给每个原子技能定义了一套统一的元信息结构，包括技能名称、简要描述、输入参数结构（JSON Schema）、输出结构、错误类型与常见异常提示。这里有一个非常关键的细节：技能描述必须写“什么时候用”，而不是只写“这个技能是什么”。比如“read_file”这个技能，描述不应该只写“读取文件”，而应该写成“当用户需要查看、分析或引用某个本地文件内容时使用；输入为文件绝对路径；若文件不存在则返回明确错误”。模型在调用技能时，本质上是在做文本匹配，描述越接近用户意图的表达方式，召回的准确率越高。

我还给技能加了“前置条件”与“后置条件”的声明。比如“发送邮件”这个技能的前置条件是“发件人邮箱已经过授权认证”，后置条件是“邮件进入已发送队列”。模型在编排任务时，会先检查前置条件是否满足，如果未满足，它会自动触发“初始化邮件服务”这个前置技能。这套机制把隐式的依赖关系变成了显式的执行流，减少了很多因为环境没准备好而导致的隐性失败。

以下是某个原子技能的元信息示例，你可以看出协议的整体结构：

{ "skill_name": "read_file", "description": "当用户需要查看、分析或引用某个本地文件内容时使用。", "input_schema": { "type": "object", "properties": { "file_path": { "type": "string", "description": "文件的绝对路径" }, "encoding": { "type": "string", "default": "utf-8" } }, "required": ["file_path"] }, "output_schema": { "type": "object", "properties": { "content": { "type": "string" }, "file_size": { "type": "integer" } } }, "preconditions": ["文件存在", "应用具备读取权限"], "postconditions": ["文件内容已完整载入上下文"] }

这套结构看起来有点重量级，但在后续的调试和演进中帮了大忙。因为每一个技能都自带可校验的契约，你可以写自动化测试去验证“输入 schema 描述与真实函数签名是否一致”，防止模型调用时参数错位。这类问题在 Function Calling 场景里非常常见：模型的参数推断对了，但真实函数的参数名对不上，返回一个晦涩的 TypeError，模型又读不懂，最终只能给用户一句“系统错误”。

2.3 上下文预算是技能库设计的隐形天花板

另一个在设计阶段就必须考虑的问题是上下文预算。每个技能调用都会产生输入输出 token，而大模型的上下文窗口是有限的。技能库再强大，也不能把所有技能的结果一次性全部塞进上下文。agent-skills 采用的方式是“按需注入”：模型先看到的是技能清单（只有名称和简述），当它决定调用某个技能时，系统才把该技能的详细描述和参数 schema 注入当前上下文。

这个设计有个很直观的类比：餐厅菜单不会把每道菜的全部做法都写出来，而是先给你一页菜名和价格，等你点菜后再由后厨去执行。如果一开始就给你一本三千道菜的详细菜谱，你会连菜单都翻不完。很多 Agent 框架跑得慢、乱调用工具，往往不是模型能力的问题，而是设计者把整个“菜谱”都放进了“菜单”里。

我在这部分做过一次非常直观的对比实验：在同一份任务集上，平铺式技能清单的模型工具命中率只有不到 60%，平均单次任务消耗 token 超过 6000；采用按需注入后，命中率提升到接近 90%，token 消耗降到了 2000 以内。这个数字不严谨，但足以说明问题。技能库的“可发现性”与“轻量性”必须同时满足，否则模型就被工程结构压垮了。

3. 实操细节：搭建一个属于自己的技能库

3.1 从零开始的三步搭建法

如果你也想照猫画虎，我把项目从立项到跑通第一版技能库的过程拆成三个步骤，每一步都有明确的产出物与检查标准。这个流程适合大多数从零开始的场景，不管是个人项目还是团队协作。

第一步，盘点真实任务清单。不要从“我想让 Agent 能干什么”出发，而要从“用户到底会给 Agent 提什么问题”出发。把你预期中的高频任务全部列出来，比如“查本周销售数据”“生成每日库存报告”“发送项目周报邮件”等等。这个清单是技能库的需求文档，决定了你后续要造哪些工具。

第二步，从任务反推原子技能。每个任务拆成 3 至 5 个不可再分的操作步骤，每个步骤对应一个原子技能。比如“生成每日库存报告”这个任务，拆出来可能是“连接数据库 → 查询出入库记录 → 计算当前库存 → 生成 Markdown 表格 → 渲染为报告文件”，这五个动作，前四个都是高复用原子技能，只有最后一个可能是特定场景的专用技能。任务拆解完成后，你会发现自己真正要写的核心技能并不多，大概 20 个原子技能就能覆盖 70% 的日常任务。

第三步，编写技能注册表并做好索引。每个技能写清楚元信息，并按功能域分组（如“数据访问”“文件操作”“消息通知”“计算分析”），然后在注册表里登记一个全局唯一的技能名。这一步不要偷懒，后续模型调用的准确率和这个注册表的质量强相关。我甚至在注册表里给每个技能加了一行“典型调用短语”，比如“当用户提到'查一下库存'时调用 get_current_inventory”，实测下来这对小模型的工具选择正确率有显著提升。

3.2 关键项目的实现细节：用 Python 搭建技能注册表与执行器

项目里最核心的运行时模块是技能注册表（Skill Registry）和技能执行器（Skill Executor）。注册表负责管理技能元信息，执行器负责在收到模型调用请求时找到对应函数、校验参数、执行并返回结构化结果。下面是我的一个简化实现版本，只保留了最核心的骨架逻辑，你可以直接参考这个思路去扩展。

from typing import Any, Callable, Dict, List, Optional import json class Skill: """技能单元：描述元信息 + 对应执行函数""" def __init__(self, name: str, description: str, input_schema: Dict, output_schema: Dict, handler: Callable[..., Any], preconditions: Optional[List[str]] = None): self.name = name self.description = description self.input_schema = input_schema self.output_schema = output_schema self.handler = handler self.preconditions = preconditions or [] def execute(self, arguments: Dict) -> Dict: # 执行前的参数校验 missing = [f for f in self.input_schema.get("required", []) if f not in arguments] if missing: return { "success": False, "error": f"缺少必要参数: {', '.join(missing)}", "suggest": "请补充完整参数后重试" } try: result = self.handler(**arguments) # 统一包装为结构化输出 return {"success": True, "result": result} except Exception as exc: return { "success": False, "error": f"{type(exc).__name__}: {str(exc)}", "suggest": "请检查相关依赖服务是否可用，或确认输入数据格式" } class SkillRegistry: """技能注册表：登记所有技能，并提供按名称检索能力""" def __init__(self): self._skills: Dict[str, Skill] = {} def register(self, skill: Skill) -> None: if skill.name in self._skills: raise ValueError(f"技能名 {skill.name} 已被注册") self._skills[skill.name] = skill def get(self, name: str) -> Optional[Skill]: return self._skills.get(name) def list_skills_tooltips(self) -> List[Dict]: """生成给模型看的技能清单摘要""" tips = [] for skill in self._skills.values(): tips.append({ "name": skill.name, "description": skill.description, "input_schema": skill.input_schema }) return tips # 示例：注册一个读取文件技能 def read_file_handler(file_path: str, encoding: str = "utf-8") -> Dict: with open(file_path, "r", encoding=encoding) as fh: content = fh.read() return {"content": content, "file_size": len(content.encode(encoding))} registry = SkillRegistry() registry.register(Skill( name="read_file", description="当用户需要查看、分析或引用某个本地文件内容时使用。", input_schema={ "type": "object", "properties": { "file_path": {"type": "string", "description": "文件的绝对路径"}, "encoding": {"type": "string", "default": "utf-8"} }, "required": ["file_path"] }, output_schema={ "type": "object", "properties": { "content": {"type": "string"}, "file_size": {"type": "integer"} } }, handler=read_file_handler ))

这个骨架里有几个细节值得放大说明。

第一，执行器的返回格式必须是统一的结构体。无论底层函数返回什么，都要包一层{success, result/error, suggest}结构。suggest字段是我特意加的，它可以让模型在技能执行失败时直接拿到一个补救建议，而不是面对一个冷冰冰的异常堆栈。比如“文件不存在”的错误，suggest 可以写成“请确认文件路径是否正确，或尝试先使用 list_files 技能查看可用文件”。这比让模型自己猜怎么处理要高效得多。第二，参数校验必须在执行前做。模型推断出的参数经常有多余字段，或者必填字段缺失。提前校验并且返回缺失字段清单，可以避免很多因为参数不匹配而导致的异常中断。

第三，技能执行器与主流程的耦合要松。在实际项目中，技能执行器只是一个纯函数模块，不持有任何对话状态。对话状态由编排层管理，执行器只负责“被调用并返回结果”。这样设计的好处是，技能可以被单测、被其他流程复用、甚至被别的项目直接 import 过去用。我在做某个跨平台系统时，把同一个技能注册表同时用在了命令行工具和 Web 服务上，两者共享同一套技能定义，完全没有重复代码。

3.3 参数计算的取舍：如何设计技能的输入输出 schema

设计技能输入输出 schema 时，最常犯的错误是把 schema 设计得过于严格。模型不是严谨的工程师，它给的参数就是会偶尔缺少、偶尔多出、偶尔类型不匹配。如果 schema 卡得太死，比如要求file_path必须是.txt结尾的字符串，模型传一个.md路径就会被拒掉；但用户的真实意图可能只是“读一下这个文档”，并不关心扩展名。我的经验是：schema 的约束只用来防止真正的错误，不用来约束表达方式的差异。

具体来说，输入参数中尽量少用 strict 枚举类型，多用描述性注解。比如对于“日期范围”这个参数，不要只定义成{"type": "string"}，写明“格式可以是 2024-01-01 或 2024/01/01，支持自然语言如'上周'”，模型反而能更准确地把用户的话转换成参数。输出方面，尽量让每个技能返回一个结构化的 JSON，而不是自由文本，这样多个技能的结果才能被后续技能继续消费。

如果涉及数值计算或数据统计，还需要在技能内部把单位、精度、四舍五入规则写清楚。比如“计算库存周转率”这个技能，分子分母分别是什么、保留几位小数、负库存怎么处理，这些都需要在函数内部做好防御。这类细节不会直接体现为炫酷的功能，但它们决定了你的技能库在真实业务中能不能用。

3.4 组合技能：把原子操作编排成真正的任务能力

原子技能只是一个动作，不是一个“能力”。真正让 Agent 显得能干的是组合技能。我举一个非常典型的例子：从邮件附件中提取数据并更新数据库。这个任务在用户视角里“只是一件事”，但如果拆解成原子技能，至少需要“读取邮件列表 → 下载附件 → 解析 Excel → 字段映射校验 → 执行 SQL 更新 → 生成执行报告”这六个步骤。如果你让模型每次都在运行时临时规划这六步，它大概率会漏掉某一步，或者在一次执行中反复尝试不同的顺序，浪费大量 token。

组合技能的本质，就是把“这件事的成功路径”预先固化下来。它不需要模型去临时发挥，而是像一张流程图一样把步骤串联好，模型只需要为每一步补充必要的参数。对于组合技能，我还会额外定义一个“回滚策略”。比如“执行 SQL 更新”这一步失败了，到底是直接终止整个组合技能，还是尝试跳过并记录异常，这需要根据业务场景在组合技能定义时写清楚。把这类决策提前固化在代码里，比让模型在执行时临场判断要稳定得多。

组合技能的定义同样是一份 JSON 元数据，示例：

{ "composite_skill_name": "import_mail_attachment_to_db", "description": "从指定邮箱下载最新附件的 Excel 表格，解析后更新到业务数据库。", "steps": [ {"skill": "list_recent_emails", "arguments": {"folder": "INBOX", "limit": 5}}, {"skill": "download_attachment", "arguments": {"email_id": "{{outputs.step1.selected_id}}", "suffix": ".xlsx"}}, {"skill": "parse_excel", "arguments": {"file_path": "{{outputs.step2.file_path}}", "sheet_name": 0}}, {"skill": "map_and_validate_fields", "arguments": {"rows": "{{outputs.step3.rows}}", "mapping": "default_mapping"}}, {"skill": "execute_sql_update", "arguments": {"records": "{{outputs.step4.validated_records}}", "table": "inventory"}}, {"skill": "generate_execution_report", "arguments": {"result": "{{outputs.step5.result}}"} ], "rollback_strategy": "如果第 5 步失败，回滚本次更新并终止任务" }

每一层步骤的参数都可以引用前一步的输出，用{{outputs.stepN.field}}这种模板语法完成数据流传递。这种设计可能没有完全自动化的 Agent 那么“智能”，但它的稳定性要高出好几个量级。对于真实业务场景，稳定压倒一切，用户宁可选一个每次结果一致但不够惊艳的方案，也不愿意接受一个时而超神时而翻车的 Agent。实际项目中大约 70% 的高频任务都应该做成组合技能，留给模型自由发挥的只有那 30% 的开放式探索场景。

4. 避坑笔记：我在 agent-skills 开发与使用中踩过的典型问题

4.1 技能调用“假成功”：模型以为调用了，实际上没执行

早期联调时经常遇到这样一个现象：模型回答说“已为您查询最新数据”，但技能日志里根本没有对应的调用记录。模型在编造执行结果。这类“幻觉型成功”极难排查，因为用户端看到的是一个正常的回答，只有当追问数据来源时才发现异常。

这个问题有几种解法，我最推荐的是“结果溯源”。即每一步技能执行后，在返回给模型的结果中强制带上一个可追溯字段，比如source: "skill:read_file:20240101120000:result.md"。如果模型没有执行技能却声称已完成，后续校验逻辑会直接判负。同时，限定模型必须引用技能返回的原始数据来回答，不能凭印象总结。把“是否真的执行了技能”变成一个可验证的事实，幻觉问题能减少一大半。

4.2 参数自动推断带来的“脏数据”

模型在调用技能时，喜欢自作主张地“脑补”参数值。比如查数据库时，用户说“查一下这个季度的销量”，模型把“这个季度”推断成了上季度，因为对话中的时间参照容易混乱。这类问题在 Agent 类项目里非常常见，我称之为“参数推断的歧义陷阱”。

要缓解这个问题，一是尽量在技能输入 schema 中给时间类参数加“缺省策略”，比如注明“若不指定，默认使用当前自然季度”。二是建立“关键参数确认机制”，对于涉及时间、金额、范围这类高敏感参数，在技能执行前先在流程中触发一次确认。当然，这会增加一次模型的往返，但比起执行了错误操作再回滚，成本反而是低的。

4.3 上下文污染：上一个任务的残留数据干扰了下一次调用

这是技能库长期运行后最让人头疼的问题。每次技能的执行结果都会写入对话上下文，如果上一次任务在上下文中留下了大量 table 数据或文件路径，下一次任务开始时，模型很可能会被这些残留信息带偏。比如前一次任务是分析一个两千行的销售数据表，表内容全部留在上下文中，后一次用户问“帮我写一封邮件”，模型居然用销售报告里的数字作为邮件正文的数据来源。

应对这个问题，我在执行器中加了一步“数据分区隔离”：敏感数据和长表格结果不直接进入对话上下文，而是先写入一个临时存储区，模型只能拿到一个引用 ID。只有模型明确请求查看数据内容时，才把部分数据注入上下文。在技能库项目里，这个机制带来的收益非常明显，上下文里不再混杂大段原始数据，模型也显得更“聪明”了，因为它看到的始终是精简过的摘要，而不是未加工的噪声。

4.4 技能数量的增长陷阱：从 20 个变成 200 个之后怎么办

技能库一定会越来越大，这是不可避免的趋势。20 个技能时模型选得很准，100 个技能时模型已经开始出现选择困难，200 个技能时技能清单本身可能就超过了上下文窗口。我处理这个问题有两个方向。

一是“技能分组 + 子调度器”。把技能按功能域拆分成多个子库，每个子库有一个专门的调度 Agent，先由主 Agent 判断“当前任务属于哪个域”，再交给对应域的子调度器去选具体技能。这就像医院先分科，再找专科医生，而不是让一个全科医生记住所有病症的疗法。

二是“技能精简 + 淘汰机制”。定期检查技能调用日志，对低调用频率的技能做降级处理，移出主清单，只在特定意图命中时才动态加载。技能库的管理是一个持续过程，不能只写不删。

4.5 常见问题速查表

• 模型总是调用错误技能：检查技能描述中是否包含“什么时候用”的语义，而非仅功能说明
• 技能执行结果返回格式不统一：确保所有 handler 的返回值被统一包装为{success, result/error, suggest}结构
• 参数总是缺字段：在输入 schema 中尽量减少必填项，缺省值逻辑宁可写在函数内部
• 组合技能跑到一半失败：为每个步骤配置独立的错误捕获，并明确“终止、重试、跳过”三种策略
• 模型调用技能后仍输出编造结果：启用结果溯源校验，要求模型引用技能原始返回值作答
• 调试时无法区分是哪一步出错：为每个技能执行生成全局唯一的 trace_id，贯穿整条调用链

5. 性能与体验优化：让技能库跑得更快、用起来更顺手

5.1 高频技能的缓存与预加载

技能库里总有那么几个“明星技能”被反复调用，比如“查用户信息”“读今日报表”。对于这类只读型且结果变化不频繁的技能，可以加一层缓存。缓存的粒度不是技能级别，而是“参数级别的结果缓存”。比如查“用户 123 的信息”，第一次执行后把结果缓存 5 分钟，五分钟内再次调用直接返回缓存结果，不再触发底层 SQL 查询。这个优化在数据查询类 Agent 中效果极好，平均响应时间能缩短一半以上。

不过缓存要格外注意数据一致性。涉及写操作、状态变更的技能绝不能缓存结果，否则模型拿到的一定是过期信息。我会为每个技能定义cacheable字段，在执行器中统一判断，避免在 handler 里各自为政。不写“缓存策略”这个字段的话，后续接手的开发者很容易误判某个技能是否可缓存，埋下数据不一致的隐患。

5.2 并发控制与超时管理

技能一旦变多，就可能出现并发调用。模型在某些任务里会“并行”发起多个技能请求，比如既想查文件，又想读数据库。如果你的技能执行器是同步串行执行的，那这些请求会排队，用户体验大打折扣。我在项目里把执行器改成支持并发调用的模式：每个技能请求一个线程/异步任务，统一等待结果返回。但并发也带来了一个风险，就是多个技能同时操作同一个共享资源（比如同时写同一个文件），所以还需要在每个技能上标注“并发安全”属性。对于非并发安全的技能，强制串行，其他技能则不受影响。

超时管理也是必不可少的环节。任何外部依赖（数据库、API、远程服务）都可能挂起。每个技能都应该配置执行超时时间，超时之后立即返回失败，并附上 suggest 提示“相关服务无响应，请稍后重试或检查服务状态”。如果不设置超时，一次外部服务故障可能让整个 Agent 卡住好几分钟，用户早就流失了。

5.3 技能的可观测性：日志、指标与轨迹回放

技能库做得越大，维护成本越高。如果没有一套好的可观测体系，出问题时你会像盲人摸象。我项目里为每个技能执行生成了结构化的执行日志，包含技能名、入参摘要、出参摘要、耗时、错误信息、trace_id。再把所有日志汇聚到一个可视化的看板上，实时能看到技能的调用量、成功率、平均耗时。

看板的价值体现在两个场景：一是新版本发布后快速观察是否有异常波动；二是做技能淘汰决策时，直接看调用量和成功率来筛选。如果没有这些数据，优化全凭感觉，很容易把高频技能改坏，同时留下无人问津的僵尸技能浪费上下文位置。

5.4 给模型侧做减法：Prompt 精简与技能描述压缩

技能库和 Prompt 之间是此消彼长的关系。技能库越庞大，注入给模型的技能清单就越长，留给实际任务处理的上下文就越少。所以我在实际项目中不断做“技能描述压缩”：把冗长的自然语言描述精简成“意图触发词 + 功能一句话 + 限制条件”三段式，把参数 schema 里不必要的字段说明删掉。实测下来，精简后的清单放在同等上下文窗口里，模型的工具选择准确率和任务完成质量均有所提升，因为注意力更集中了。

如果上下文窗口仍然紧张，可以考虑一个进阶技巧：给每个技能额外生成一个“语义指纹”，由触发词列表、典型问题模板、相关技能链接组成，然后用嵌入模型对用户问题做意图检索，只把命中的前 5 个技能注入上下文。这种做法在技能数量突破 50 个之后几乎是必须的，否则清单长度本身就会耗尽模型的注意力资源。

6. 技能库的演进思路：从“能用”到“好用”

做到这一步，agent-skills 已经不是一套静态的工具集，而是一个可以不断生长与自我进化的系统。我认为它的下一步演进方向有三个。

一是“技能质量自评机制”。每次技能执行后，让模型根据返回结果的完整性和用户的下一次反馈来给技能评价，并把评价结果写回技能注册表。长期下来，低分技能会被自动降权，高分技能会被优先推荐。

二是“组合技能的自动生成”。当用户多次以相同方式调用一组原子技能时，系统自动记录调用序列，并尝试将它固化为一个新的组合技能。这其实就是“从用户行为中学习工作流”。这个方向需要非常谨慎，自动生成的流程必须经过评估和人工确认后才能启用，否则会固化一些有缺陷的操作路径。

三是“跨 Agent 的技能共享”。同一个技能库可以被多个不同的 Agent 复用，比如一个面向客服的 Agent 和一个面向数据分析的 Agent，可以共享“读取 Excel”这个原子技能，但各自的组合技能完全不同。把技能库从单体应用里解放出来，变成一个独立的基础服务，适配任何场景和团队，这是 agent-skills 演进的终局形态。

我个人在实际操作中的体会是，技能库这个方向最难的不是写代码，而是“克制”。你总会想给 Agent 加更多技能，让它显得更强大，但每多一个技能，模型的选择成本和维护成本都会增加，上下文也在被悄悄占用。真正好用的技能库一定是精简、明确、边界清晰、可替换的，就像一套好工具，不在于数量多，而在于每把都趁手。这个项目做到后面，最有价值的反而不再是某个具体技能的实现，而是那一套关于“什么是好技能”的判断标准。它让我在搭任何 Agent 应用时，都能有一个清晰的尺度来判断：这一步是让模型去发挥，还是预先做成技能。有了这个尺度，Agent 才会真正从“会聊天”进化为“会干活”。