企业官网建设流程全解析

让 Agent 真正“会干活”，光有模型不够，还得有一套能管好技能、能调度技能、能避开坑的基础设施。这篇就是我从项目里沉淀下来的 agent-skills 实践经验，从技能设计到注册调度，再到排查实录，一次性讲透。

在 Agent 项目里泡久了，你会慢慢意识到一个事实：模型决定 Agent 的“智商”，技能体系决定 Agent 的“手脚”。把模型比作一个刚毕业的高材生，脑子再好，没有趁手的工具、不知道工具有什么用、不知道怎么按流程干活，一样做不了实事。做完 agent-skills 这套技能编排与调度方案后，我对这一点体会特别深。项目本身解决的核心问题，就是让 Agent 能够按需发现技能、准确调用技能、稳定执行技能，并且在技能数量膨胀之后还能保持可控、可观测、可排查。这套思路适合正在做 Agent 应用、搞 AI 工作流编排、或者即将面对技能管理难题的开发者参考。今天就把整个拆解思路、落地实现和踩坑记录整理出来，希望能帮到正在这条路上摸索的人。

1. 整体设计与思路拆解

1.1 为什么单独搞一套技能体系，而不是直接写一堆函数

先从一个最原始的场景说起。早期我写 Agent 的时候，处理任务的方式非常简单粗暴：把几个工具函数全部塞进系统提示词里，让模型自己读、自己选、自己调用。当时只有三五个函数，效果还不错，模型基本不会选错。但随着业务场景扩展，技能数量从五个涨到五十个，问题就来了：上下文窗口撑不住，工具描述互相干扰，模型开始频繁选错工具，甚至出现幻觉式的工具调用——它调了一个根本不存在的函数。

这个阶段给我的教训是：让模型直接面对零散工具，本质上是把“工具管理”的复杂度全部甩给了模型。模型既要理解每个工具的语义，又要做路由决策，还要处理工具之间的依赖关系，这对当前的大模型来说，负担还是太重了。于是我开始思考，能不能在模型和工具之间加一层“技能管理层”，把工具变成有名字、有描述、有入参规范、有返回值约定、有版本记录的技能，再让 Agent 通过一套机制去发现和调用它们。agent-skills 的雏形就这样出来了。

这套方案的核心价值可以归纳成三点：一是降低模型的决策负担，模型不需要理解所有技能的细节，只需要通过技能描述和指标找到合适的技能；二是让技能可以统一治理，比如版本更新、权限控制、运行隔离、调用审计，都能在技能管理层统一做掉；三是提升整个系统的可解释性和可排查性，每个技能调用都有规范化的记录，出了问题能快速定位是选型错了、参数错了、还是技能本身执行失败了。

1.2 方案选型背后的取舍：声明式优于命令式

在设计技能体系时，我碰到一个关键选择：技能定义应该用声明式（描述技能是什么、输入输出是什么、约束是什么）还是命令式（直接写调用逻辑）？两条路我都试过，最终选了声明式优先。

命令式的实现很快，写一个函数，注册一下就行，但问题在于函数签名本身承载的信息太少。比如一个函数叫search_products(keyword, page, page_size)，模型看到这个名字和参数名，其实很难准确理解这个技能到底适合什么场景、返回什么结构、有没有副作用。它需要从函数名和参数名去“猜”，猜错的概率在技能多了以后会急剧上升。

声明式则要求每条技能都附带一份结构化的描述信息，包括：技能名称、适用场景、依赖条件、入参说明、返回结构、错误码、权限要求、超时控制。模型拿到的是经过整理后的技能画像，而不是光秃秃的函数签名。从实测效果看，把工具描述从原来的“一句话函数名+参数列表”换成“场景化、结构化、带示例”的技能描述后，模型选错工具的比例明显下降。

另一个重要取舍是技能注册表要不要完全自研。我也认真考虑过要不要直接上 MCP（Model Context Protocol）这类现成协议。MCP 的好处是有标准、有生态、很多工具已经支持，但问题在于：现成协议偏“连接层”，只解决了工具暴露和传输格式的问题，对技能的编排、依赖、路由、权限处理、以及和 Agent 内部状态交互这部分，留白还是太多。所以我的做法是：底层借鉴 MCP 的标准化思路，上层自己做一套轻量级的技能管理服务，把技能注册、调度、观测这些都接进来。这样既有标准协议的灵活性，又不至于被协议边界限制住。

2. 核心细节解析与实操要点

2.1 技能 Schema 设计：每个字段都不是摆设

技能定义是整个体系的基石，Schema 设计得不好，后面所有环节都会出问题。我在实践里反复调整过的技能 Schema 字段如下，每条都踩过真实的坑。

技能名称（name）：看起来最简单，其实最容易出问题。一定要用“动词+名词”的清晰结构，比如send_email_to_user而不是email_sender。因为模型在选择技能时，名称权重很高，动词开头的名称比名词开头更容易被模型理解。另外要确保全系统唯一，同类技能不要出现多个语义重叠的名字。

技能描述（description）：这是最重要的一个字段。模型决定调不调这个技能，主要就看描述。描述不能只写“这个技能做什么”，还要写“这个技能适合什么场景”“什么情况下不应该用”。我在最早的版本里吃过亏，有个get_weather技能，描述只写了“获取天气信息”，结果模型在需要“根据天气建议穿搭”时，也会去调这个技能，因为它不知道这个技能只返回天气数据，不负责建议。给描述加上场景和边界后，这种误用少了很多。

入参定义（parameters）：建议用 JSON Schema 风格定义，尽量细化参数的类型、格式、默认值、是否必填、取值范围。有一点要特别提醒：不要信任模型传入的参数。模型生成参数时很可能漏字段、填错格式，所以技能执行前的参数校验和兜底赋值非常重要。我在代码里会给每个参数设置容错处理，比如某个参数允许None值时就按业务默认值走。

返回结构（returns）：明确返回体的格式，最好是统一包装一层，比如{"status": "success", "data": ...}或{"status": "error", "code": "...", "message": "..."}。统一结构的好处是，Agent 主流程处理返回结果时可以写一套通用逻辑，而不需要针对每个技能单独适配。另外，返回值建议尽量精简，只返回模型判断下一步所需要的必要信息，不要返回来龙去脉的完整大对象，否则上下文很快就会被撑爆。

权限要求（permissions）与超时控制（timeout）：这两个字段是后来补上去的。技能不是都能被任意调用的，有些技能涉及数据修改、发送消息这类敏感操作，需要设置权限标记，Agent 侧路由时对应做拦截或二次确认。超时控制则是为了防止技能卡死拖垮整个流程，比如某个外部 API 调用没有限制时间，一旦挂了，整个 Agent 任务都会卡住。给每条技能配一个合理的默认超时值，并在执行层强制拦截，是必须做的事。

2.2 技能描述写作的实操方法论

技能描述写得好不好，直接决定了模型能不能正确选路。写过几十条技能描述之后，我总结出一个三段式结构，非常管用：一句话功能定义、适用及不适用场景、典型使用示例。

一句话功能定义要让模型在 0.5 秒内看懂，比如“根据用户查询关键词搜索商品并返回分页列表”。适用及不适用场景要写清楚边界，比如“适用于按关键词找商品的场景，不适用于传入商品 ID 查询详情，这种情况请使用 get_product_detail”。典型使用示例可以放一个极简的入参样例和返回样例，模型在看到示例后，对怎么调用这个技能会更有把握。

一个反面教材是我早期写的某条技能：描述只有“查询订单”，没有任何场景说明和边界提示。结果模型拿到一个“我要催发货”的任务时，调了这个“查询订单”技能，其实当时的技能只支持按订单号查状态，根本支撑不了“催发货”背后的完整链路。后来我把描述改成了“根据订单号查询订单当前状态、物流进度等基础信息，适用于查询类场景；如果用户要求催发货或发起投诉，请使用 after_sales_service 技能”。这样改完后，模型的选型准确率确实上了一个台阶。

2.3 技能注册表：版本、归属与灰度

技能管理不能让技能处于“散装”状态，需要有统一的注册中心。我在项目里维护了一张技能注册表，核心字段包括：技能ID、名称、版本号、所属模块、状态、标签、负责人、更新时间。为什么单独强调版本号？因为技能逻辑不是总不变的，你今天写的技能，过两周可能就要改参数、调整返回结构。如果没有版本管理，技能一更新就全量生效，线上的 Agent 可能瞬间开始用新逻辑，出了问题只能回滚（如果还来得及的话）。给技能加上版本号，并且支持按版本灰度发布，能非常有效地控制变更风险。

我采用的技能注册表本质上是一个技能元信息库，它不存技能实现代码，只存技能的定义、来源、依赖、权限等描述信息。当 Agent 启动时，注册表会把当前环境可用的技能列表加载到内存中，Agent 每次做技能选择前，都会在内存中检索技能元数据，而不是直接扫描一堆散落的函数。这样可以做到技能的新增、下线、变更都走注册流程，避免“烂代码”悄悄进入生产环境。

3. 技能调度与执行：Agent 怎么选路、怎么落地

3.1 技能路由策略：纯模型选路并不够

技能体系建好之后，真正核心的问题来了：Agent 面对一堆技能，怎么决定调哪个？最常见的做法是让模型自己选，把技能列表丢给模型，让模型输出技能调用意图。这种“LLM 自主选路”在技能数量少、语义边界清晰时表现非常好。但技能数量超过一定阈值，或者技能之间的语义相似度比较高时，纯模型选路会出现犹疑、误选、跳变的问题。

我在实践中的方案是混合路由：先做规则预筛，再做模型排序。规则预筛的核心思路是：利用标签系统和关键词系统，先把候选技能集从几十个缩小到三五个。比如说用户的任务含有“天气”，那就把带有“天气”标签的技能挑出来，然后通过语义相似度算一下，把不太可能被用到的技能过滤掉。预筛完成后，把缩小后的候选技能列表丢给模型做决策，这样模型面临的选择范围大幅缩小，决策稳定性明显提高。

还有一种情况需要特别注意：多个技能都能完成类似的活儿。比如“发送短信”和“发送站内信”，语义都是发消息。这时候光靠模型看描述选，很容易选错。我采用的方法是在技能标签里增加“渠道偏好”维度，让预筛选阶段就根据上下文推断出用户意图更偏哪个渠道，比如用户提到“手机收不到”，那大概率是短信；没有上下文时，默认走站内信。模型的决策压力会小很多。

3.2 技能执行的生命周期管理

一条技能被选中之后，执行过程我做了六个环节的管理：参数校验、鉴权、执行、结果校验、返回归一化、观测记录。每一步都有明确的处理逻辑。

参数校验这一步，前面已经说过，绝对不能省。除了格式校验，我还会做“必填参数补齐”，某些参数缺失时，能从会话上下文里提取的就自动补上，比如用户 ID、当前时间这种常见上下文。鉴权环节则是检查这条技能是否允许当前会话使用，比如涉及扣款、涉及敏感数据读取的技能，必须有权限标记才能放行。

执行环节要注意的地方是：技能内部不能假设自己独占资源。我在执行层统一做了超时控制和并发限制，任何技能都不能无限跑，也不能同时开启太多实例。结果校验是检查技能返回的数据是否符合预期格式，防止脏数据直接回流到模型上下文。返回归一化就是把各种技能的不同返回风格，统一转成上一步约定的标准结构。观测记录则是把每次技能调用的输入、输出、耗时、错误码、调用链 route 全部记录下来，方便后面的问题排查和性能优化。

3.3 技能太多塞不进上下文怎么办

技能数量一旦过百，直接把全部技能描述塞给模型是不现实的，即使塞得下，模型的注意力也可能被无关噪声干扰。我的解决思路是两级技能目录。

第一级是总目录，只放每个技能的名称、一句话简介、标签。总目录的目的是让模型知道系统里“有哪些能力”，但不用理解细节。第二级是技能详情，只有当模型决定某个技能可能被调用时，系统才把对应技能的完整描述、入参定义、使用示例注入到对话上下文里。这个机制类似我们查字典：先看目录找到页码，再翻到那一页查细节，而不是把整本字典背下来。

实测下来，这种做法的收益非常明显。技能总数从六十涨到一百五十，上下文中的技能相关 token 占用不升反降，模型的选择准确率也稳定住了。实现这个机制的背后，需要一套技能检索服务，能根据用户当前意图快速召回候选技能，并把候选技能的详情动态拼装到提示词里。这也是我后续认为 agent-skills 最值得继续深挖的方向之一。

4. 实操过程与核心环节实现

4.1 技能注册与加载的最小实现

先分享一段技能注册的核心代码，这是我项目里的一个简化版本，但逻辑完整可跑。我用的语言是 Python，主要通过装饰器来完成技能注册。

# skill_registry.py import inspect import json from typing import Callable, Dict, Any, List class SkillRegistry: def __init__(self): self._skills: Dict[str, Dict[str, Any]] = {} def register(self, name: str, description: str, parameters: dict, version: str = "1.0.0", tags: List[str] = None, timeout: float = 10.0): def decorator(func: Callable): self._skills[name] = { "name": name, "description": description, "parameters": parameters, "version": version, "tags": tags or [], "timeout": timeout, "func": func, "enabled": True, } return func return decorator def get_skill(self, name: str) -> Dict[str, Any]: return self._skills.get(name) def list_skills(self) -> List[Dict[str, Any]]: """返回技能元信息列表，供 Agent 检索""" return [{ "name": s["name"], "description": s["description"], "parameters": s["parameters"], "version": s["version"], "tags": s["tags"], "enabled": s["enabled"], } for s in self._skills.values()] def call(self, name: str, **kwargs): skill = self.get_skill(name) if not skill: return {"status": "error", "code": "SKILL_NOT_FOUND", "message": f"技能 {name} 不存在"} if not skill["enabled"]: return {"status": "error", "code": "SKILL_DISABLED", "message": f"技能 {name} 已禁用"} # 参数校验与兜底 validated_kwargs = self._validate_params(skill["parameters"], kwargs) # 执行（简化版，未加超时线程） try: result = skill["func"](**validated_kwargs) return {"status": "success", "data": result} except Exception as e: return {"status": "error", "code": "SKILL_EXEC_ERROR", "message": str(e)}

这里我特别想说的是list_skills方法的设计。它只返回元信息，不返回函数对象本身。这个细节决定了 Agent 侧永远不需要接触真实执行函数，只需要通过技能名字符串去调用，这样既方便做权限拦截，也为后续把技能执行迁到独立进程或远程服务预留了空间。

4.2 技能描述与注册示例

现在假设我们要注册一个查询订单状态的技能，实际代码如下：

registry = SkillRegistry() @registry.register( name="query_order_status", description="根据订单号查询订单当前状态、物流进度、预计送达时间等基础信息。" "适用于用户查询订单进度、物流位置的场景。" "不适用于催发货、退换货、投诉等售后处理场景，这些场景请使用 after_sales_service。", parameters={ "order_id": {"type": "string", "description": "订单号，必填", "required": True}, "user_id": {"type": "string", "description": "用户ID，从上下文补充", "required": False}, }, version="1.2.0", tags=["order", "query", "logistics"], timeout=5.0, ) def query_order_status(order_id: str, user_id: str = None): # 实际业务逻辑（伪代码） # 1. 根据 order_id 查订单库 # 2. 获取订单状态、物流信息 return { "order_id": order_id, "status": "shipped", "logistics": "包裹已到达上海分拨中心，预计明天送达", }

这段代码里你可能会注意到，我把user_id设成了非必填，但真实业务里查询订单往往需要校验用户权限。这里我故意留了一个口子：如果参数校验发现 user_id 缺失，但在外部上下文中能拿到会话的用户 ID，就会自动补齐。如果补不上，则返回权限错误。这种“上下文补充参数”的模式在 Agent 场景里特别实用，因为模型通常不会主动把所有隐式参数都传全，需要系统在调用链路上做价值补全。

4.3 技能的上下文注入与路由执行

技能不能光注册完就不管了，还要打通 Agent 主流程。下面这段代码展示的是：如何从注册表中获取技能元信息、按标签和描述进行候选过滤，并按两级目录方式注入上下文。

# agent_skill_router.py class SkillRouter: def __init__(self, registry: SkillRegistry): self.registry = registry def propose_candidates(self, user_intent: str, top_k: int = 5) -> List[Dict[str, Any]]: """规则预筛：基于关键词与标签粗召回候选技能""" all_skills = self.registry.list_skills() # 简单打分：标签命中 +1，描述关键词命中 +1 scored = [] for skill in all_skills: score = 0 if any(tag in user_intent for tag in skill["tags"]): score += 1 desc = skill["description"].lower() # 提取用户意图关键词（简化写法） for kw in user_intent.lower().split(): if kw in desc: score += 1 if score > 0: scored.append((score, skill)) scored.sort(key=lambda x: x[0], reverse=True) return [s for _, s in scored[:top_k]] def build_prompt_blocks(self, candidates: List[Dict[str, Any]]) -> str: """把候选技能拼装成两级目录提示块""" # 第一级：目录 catalog_lines = ["可用技能目录："] for skill in candidates: catalog_lines.append(f"- {skill['name']}: {skill['description'][:30]}") # 第二级：完整描述（只注入候选技能） detail_lines = ["技能详情："] for skill in candidates: detail_lines.append(json.dumps({ "name": skill["name"], "parameters": skill["parameters"], "description": skill["description"], }, ensure_ascii=False)) return "\n".join(catalog_lines + detail_lines)

你可以看到，我把候选召回的逻辑做得很简单，就是标签加关键词的轻量匹配。真实项目里这一步可以换成向量检索或更复杂的排序模型，但思想一样：先粗筛，再精排，最后用 LLM 决策。粗到细再到模型的链路，可以在保证效果的同时大幅降低模型需要处理的 token 数和决策噪声。

4.4 接入 LLM 后的实测表现与参数选择

技能调度链路搭好后，我需要验证效果，所以做了一组对比测试。测试集里有一百条用户需求，覆盖查询、售后、推荐、退款等八个业务场景，目标是把每个需求路由到正确的技能。对比组分别是：纯 LLM 直接从全量技能列表选路；规则预筛+候选注入+LLM 选路。实测结果如下：

这个数据更能说明问题，规则预筛不只是为了省 token，更重要的是把模型的注意力聚焦到最有可能的几个技能上，准确率直接从 78% 拉到 91%。上下文相关的 token 消耗也降了 70% 左右，对于高并发、高频调用的线上场景来说，这既能省钱，又能降低响应延迟。

另一个更微妙的参数是温度（temperature）。在做技能选路时，我把模型的温度调到了 0.1，几乎是最高确定性模式。因为技能选路本质上是一项“判断题”，不是“创作题”，温度太高会导致模型发挥不稳定，同一个问题隔几次调用选不同的技能，这在线上的体验是非常致命的。技能执行参数生成（比如生成 JSON 参数）时也建议用低温度，但如果你让模型基于结果做下一步规划的开放式回答，不同温度的选择就另说了。

5. 常见问题与排查技巧实录

5.1 技能完全没被调用

这个问题是最常见的，也是最折磨人的。模型明明看到了技能描述，但就是不用，宁愿自己瞎编答案。排查路径我按优先级整理如下：

第一，检查技能的 description 是否有明确的“适用场景”引导，如果描述太泛（比如只有一句话“提供订单信息”），模型很难把它和当前问题关联起来。第二，检查技能是否被注册表正确加载，有没有被 enabled 标记禁用。真实项目中我踩过这种坑：技能逻辑在本地调得好好的，上了测试环境才发现注册表没更新，技能根本没出现在列表里。第三，检查候选预筛逻辑是否误杀，有些技能本身没问题，但预筛阶段的关键词匹配没命中，导致它压根没进候选列表，模型当然看不到它。

排查时最好在观测日志里加上“候选技能列表”这一环，这样能区分到底是预筛阶段漏掉了，还是模型在候选里看到了却没用。这条数据对定位问题非常关键。

5.2 模型生成了乱参数

模型选对了技能，但传的参数完全不按 Schema 要求来，比如把order_id传成了空字符串，或者把数字字段传成了字符串。这个问题在高版本模型上有所缓解，但要彻底控制，必须靠执行前的参数校验加兜底修正。

我的处理方法分三步：第一，在技能 Schema 中把参数约束写得更严格，比如format: "string", minLength: 4，让模型有更明确的生成依据。第二，在参数校验环节做强制类型转换和默认值填充，比如接收order_id时，如果是None或空字符串，尝试从最近对话上下文中提取一个合法的订单号，提取不到就直接返回参数错误。第三，如果技能反复出现参数错误，那么我会在技能描述里加一个“参数示例”，用具体的 JSON 示例引导模型输出规范参数。这一步的收益往往比修改 Schema 本身还大，因为模型是示例驱动型选手。

5.3 技能返回数据太长，撑爆上下文

有些技能天然会返回大量数据，比如搜索接口返回几十条结果，每条的字段还老长。如果不做裁剪，技能调用两次，对话上下文就废了。这个问题在“搜索类”“列表类”技能中尤其突出。

解决方案我在实践里把它分为两层：一层是技能侧裁剪，限制返回条数和字段数，比如搜索接口默认只返回 top 10 条，每条只保留核心字段（标题、价格、缩略图），其他全部丢弃；另一层是 Agent 主流程侧兜底，加一个“返回体大小检查器”，一旦发现某次技能返回超过预定的 token 预算，就自动做截断或摘要。这种兜底机制能让整个系统在极端数据情况下不至于崩溃，大概属于 Agent 开发里“护城河”级别的保护手段。

5.4 技能并发与超时问题

Agent 在同一轮对话里可能并行调用多个技能，比如用户问“比较一下这两个商品的物流速度”，Agent 可能同时调用商品查询和物流查询。技能执行时需要做并发控制，否则几十个技能同时运行，数据库连接池先被压死。

我的做法是给技能执行层加一个全局并发限制器，使用信号量控制同时执行的技能数量，默认设为 8。同时每个技能单独设置超时时间，超时直接中断执行，并在返回体里带上超时错误码。这样即使某一个技能挂了，整个 Agent 流程还能继续运转，而不是卡死在那个技能上。这个设计在 Agent 生产化时几乎是刚需，你在 demo 阶段感受不到，一上真实业务流量就明白它的价值了。

5.5 问题速查表

6. 技能体系的运维与安全加固

6.1 技能权限边界：最小授权原则

技能一旦被 Agent 用起来，就不能再像 demo 那样随意。我在技能注册表里增加了权限标记，类似"permission": "read_only"或"permission": "write"，然后在路由层做拦截。对于只读技能，任何会话都可以调用；对于涉及修改数据的技能，必须要求会话具备特定角色，或者在调用前向用户确认。

有个真实的教训：某次我放开了一个“批量修改订单备注”的技能给测试 Agent 使用，没有做权限校验，结果 Agent 基于一个语义模糊的需求，把一批订单的备注全部改成了同一个模板文本。数据恢复花了两天。从那以后，所有写操作技能一律默认关闭，接到明确指令并且通过用户授权后才开放。

6.2 技能灰度发布与监控

技能更新不能拍脑袋直接全量上线。我在注册表里引入了“状态机”的概念，技能状态分为：开发中、测试中、灰度中、全量、已下线。新技能或大版本更新的技能，先在测试环境跑一轮，然后灰度到 10% 的线上流量观察一段时间，稳定了再全量放开。灰度期间重点监控的指标包括：调用成功率、平均耗时、参数非法率、以及模型选路是否出现偏移。

这里特别要盯的是“模型选路偏移”。技能灰度更新后，描述变了、参数变了、返回结构变了，模型的选路行为可能跟着变。比如之前 A 技能能接住的请求，更新后模型更倾向于选 B 技能。这种偏移有时候是预期的，因为更新就是为了把语义边界划得更清楚；但有时候是非预期的，可能只是描述里某个词变了，导致召回逻辑全变了。所以每次技能变更，我都会跑一遍回流测试集，用固定的测试需求对比更新前后的选路结果分布，变化过大就要审视更新是否合理。

6.3 技能健康度评分

这是后期加上去的一个运维手段。我针对每条技能，周期性统计四个指标：调用频次、成功率、平均耗时的波动、参数校验通过率。然后把这些指标综合成技能健康度评分，低于阈值的技能自动进入“观察名单”。这个机制帮助我在没有专职运维的情况下，仍然能第一时间发现技能质量下降的问题。印象最深的一次，某个第三方物流查询接口被服务商悄悄升级，返回字段名变了，导致我的技能解析逻辑拿到一堆空值，成功率从 95% 跌到 55%。如果没有健康度评分，这个 bug 可能要在线上跑很久才会被发现。

Agent 技能的稳定程度直接决定上层应用的口碑，把技能当成有生命周期的服务来运维，而不是写完就一劳永逸的脚本，是这条路走到后面必然会遇到的问题。

7. 一点实战收尾的话

坦白说，agent-skills 这个方向没有“银弹”，不同的业务场景、不同的模型底座、不同的技能数量，适合的方案都会有差异。但有一点是通用的：技能体系的核心理念是把“能力”变成“可管理、可描述、可调度、可观测”的标准化资产。我最早的做法只是给模型一堆函数签名，后来慢慢演进成完整的技能注册、路由、执行、运维体系，每一次改进的动机都是被线上真实问题逼出来的。

最后分享一个小技巧：在你开始为 Agent 注册第 21 条技能的时候，强制自己回答三个问题——这条技能和已有技能的功能边界在哪里？什么场景下模型不应该选它？它失败时的兜底方案是什么？回答完这三个问题再注册，你会发现技能质量肉眼可见地提升。如果你也正在做 Agent 技能编排，在工具选型、调度策略或者排查流程上有新的想法，随时值得动手试一试，这条路还远没到定型的时候。