如果说 2025 年我们还在讨论“AI Agent 能不能用”那么到 2026 年讨论重点已经变成了“AI Agent 能不能稳定地规模化地用”。换个更直白的说法你在本地写一个 Agent Demo 很容易让它调用一个天气接口也不难但当你把日历、邮件、数据库、审批流、知识库、低代码平台这些技能全部塞给 Agent 时你会发现真正让系统崩溃的从来不是模型本身而是——技能多了之后Agent 根本不知道怎么找到对的技能、怎么把多个技能串起来、怎么在一个技能报错之后优雅降级。这个问题的答案正在从“工具调用 Tool Calling”演进到“技能网络 Skill Network”。本文要讲的 SkillNet本质上是把 Agent 的每一项能力当作一个可以被注册、检索、组合和调用的“技能节点”然后通过统一编排层让 Agent 像调用平台 API 一样调用技能。文章会分成三个部分先讲清楚为什么需要技能网络再看它的检索、组合、调用机制到底是怎么回事最后用一个最小可运行的实现把流程完整跑通。读完你会得到一个判断Agent 未来拼的不是单点模型能力而是技能网络的工程化水平。1. 这篇文章真正要解决的问题如果你正在做 AI Agent 开发大概率会遇到下面三类问题之一。第一类技能越多Agent 越笨。把一个 Agent 接上十个工具之后它的指令遵循能力会明显下降。模型需要在十多个工具描述中挑出符合当前任务的工具描述越长、数量越多误差就越大。很多时候不是模型不行而是我们没有给模型一个更好的检索机制。第二类技能调用是“写死”的不是“编排”的。大多数人实现 Agent 技能的方式是在 System Prompt 里写“如果你需要查天气调用 weather_api”然后靠模型自己去翻 Prompt。这种方式在技能数量少的时候能用但技能之间一旦存在依赖关系——比如“先查库存再算报价再生成审批单”——靠 Prompt 硬编码就完全失控了。第三类技能与技能之间是孤岛没有组合能力。真实业务从来不是一个技能包打天下。你需要让 Agent 同时处理“查资料→总结→写邮件→发起审批”这样一条链路。如果没有一套标准的技能描述、路由规则和组合方式每接一个技能就要改一遍代码项目越大越痛苦。SkillNet 要解决的就是这三个问题的交集技能的标准化描述、按需检索、顺序编排和可靠调用。它不是什么神秘框架也不是替代 LangChain 或 Spring AI 的东西而是一种设计思路。你可以把它理解成 Agent 世界的“微服务网关”每个技能是一个独立服务注册中心知道所有技能的路由信息编排引擎负责把用户请求翻译成技能调用链最后统一执行并聚合结果。从 EvoAgentX Talk 的讨论语境来看这个方向更像是在强调多智能体也好单体 Agent 也好真正制约能力上限的是技能层是否具备“网络化”的治理能力。技能不是堆得越多越好而是要能被有效管理。2. 基础概念与核心原理2.1 什么是 Agent 技能在传统软件开发里一个功能模块有明确的接口定义、参数校验和返回值协议。AI Agent 里的“技能”虽然形式不一样但本质也是一样它是 Agent 可以主动调用的一组能力封装。技能可以是一个 API 调用比如查天气、发邮件、下单。一个代码函数比如计算运费、生成本地缓存。一个更复杂的子 Agent比如“先搜索再总结”的专用助手。一个提示模板比如把用户问题格式化为结构化查询。在代码层面一个技能至少包含两部分模型用来决策的“技能描述”程序用来执行的“技能实现”。前者要足够清楚让模型知道什么时候该用后者要足够健壮让程序在参数异常时不至于崩溃。2.2 从 Tool Calling 到 Skill Network你可能会问LangChain 的 Tool Calling 已经能做工具调用了为什么还要提技能网络这里要区分两个层次。Tool Calling 解决的是“模型能不能正确输出调用某个工具的 JSON”。它更关心模型侧的行为。Skill Network 解决的是“一个 Agent 系统如何管理大量技能”。它更关心系统侧的组织方式。举个现实例子。你用 Tool Calling 可以让模型调用send_email这个工具但你不会在 Tool Calling 层解决这些问题技能描述按什么格式维护100 个技能如何快速筛选出最相关的 3 个技能 A 的输出怎么变成技能 B 的输入技能调用失败后是否要重试还是换路这些都是技能网络层的问题。2.3 技能的四种关键能力SkillNet 讨论的“技能网络”通常围绕四个核心机制展开机制解决什么问题类比技能注册技能怎么声明自己的功能、入参、出参微服务的服务注册技能检索Agent 如何从 N 个技能中选中最相关的 M 个服务发现与路由技能组合多个技能如何按照业务语义串联工作流编排技能调用技能执行时参数如何校验、结果如何返回RPC 调用与异常处理从材料来看SkillNet 强调的“可编排”关键就在于把技能当成网络节点而不是孤立函数。节点与节点之间通过统一的输入输出协议连接业务方只需要关心链路的编排方式不需要关心每个技能内部怎么实现。2.4 一个通俗类比你可以把 SkillNet 想成一个大型公司的内部服务台。过去每个部门都有自己的办事流程客户要办事必须知道该去哪个部门、找谁、带什么材料。这就是没有技能网络的状态用户Agent必须自己搞清楚所有细节。有了服务台之后你只需要说“我要报销一笔差旅费”服务台会判断这件事涉及财务技能。需要先调用差旅记录技能。再调用报销单生成技能。最后推送审批技能。Agent 就是那个“服务台”SkillNet 就是服务台背后的流程管理系统技能就是各部门提供的服务。3. SkillNet 的核心机制拆解这一节我们把四个机制逐个讲透讲到能指导写代码的程度。3.1 技能注册先定义一套技能元数据技能要能被检索和编排第一步是标准化。每个技能都应该有一套元数据name技能唯一标识。description技能能力描述给模型看的要写清楚“什么时候用、能做什么、不能做什么”。parameters入参 JSON Schema。output_schema出参格式。routing_tags路由标签用于快速过滤。例如[查询, 只读]。timeout调用超时时间。retry失败重试策略。有人会觉得这些字段太多了其实不然。在一个几十个技能的系统里没有标准元数据检索和编排根本无从谈起。3.2 技能检索先缩小候选集再交给模型决策这是 SkillNet 与普通 Tool Calling 最大的区别。普通 Tool Calling 会把所有技能描述一股脑丢给模型SkillNet 则会先做一个“预检索”把技能候选集从 100 个缩小到 5 个再把 5 个技能描述交给模型做最终决策。检索方式可以选择关键词/标签匹配根据用户问题的词频匹配routing_tags。向量相似度检索把用户问题和技能描述都转成向量然后 top-K。规则路由根据用户类型、租户、业务线直接指定技能范围。这个设计的价值很明显模型每次做选择时面对的选项变少了选择准确率自然更高同时技能描述越长、数量越多 token 成本也越高预检索能有效降低成本。3.3 技能组合由执行计划驱动链路技能组合不等于简单地把几个函数写在 if/else 里。“可编排”的意思是组合逻辑由一份可解释、可配置的执行计划决定。比如用户请求“帮我查一下上海明天适合跑步吗”技能网络的执行计划可能是调用geocoding技能把“上海”转成经纬度。调用weather技能查询明日天气和空气质量。调用running_advice技能根据天气数据生成跑步建议。三个技能之间的依赖关系、参数传递、结果合并规则都应该在这份计划里描述清楚。如果计划是模型生成的我们称之为“动态编排”如果计划是开发者写死的就是“静态编排”。生产系统里通常两者结合。3.4 技能调用协议统一了才能万物互联组合的前提是协议统一。不管底层技能是 Python 函数、HTTP 接口还是另一个 Agent对外暴露的都应该是统一的invoke(context)接口输入一个上下文对象输出一个标准结果结构。标准结果结构至少包含status成功、失败、部分成功。data技能返回的数据。error错误码和错误信息。metadata耗时、使用技能版本号、调用链 ID。没有统一协议技能组合就是空谈。A 技能返回的字段和 B 技能需要的字段对不上模型再强也补不了格式差异。4. 轻量技能网络实现思路前面讲了概念接下来我们用代码把这个架构跑通。这里选择 Python 做演示因为 Python 在 AI Agent 生态里表达能力最直接。生产环境你可以用 Java、Go甚至用 n8n 这类流程引擎但核心设计都是一样的。4.1 工程目录skill-net-demo/ ├── agent.py # Agent 主程序意图识别 技能路由 ├── registry.py # 技能注册与检索 ├── orchestrator.py # 技能编排与执行 ├── skills/ │ ├── __init__.py │ ├── weather.py # 天气技能 │ ├── calc.py # 计算器技能 │ └── travel.py # 差旅建议技能 └── skills.json # 技能元数据配置这个目录不是必须照抄但建议保持类似分层技能定义、注册检索、编排执行、入口四个模块分开。4.2 定义技能元数据我们先用一个 dataclass 定义技能元数据。# registry.py from dataclasses import dataclass, field from typing import Callable, Any dataclass class SkillMeta: name: str description: str tags: list[str] parameters: dict[str, Any] field(default_factorydict) output_schema: dict[str, Any] field(default_factorydict) timeout: int 5 retry: int 1 class SkillRegistry: 技能注册中心负责登记、检索和管理技能。 def __init__(self): self._skills: dict[str, SkillMeta] {} # name - callable 的映射存放技能实现函数 self._handlers: dict[str, Callable] {} def register(self, meta: SkillMeta, handler: Callable): self._skills[meta.name] meta self._handlers[meta.name] handler def get(self, name: str) - SkillMeta: return self._skills.get(name) def retrieve(self, query: str, top_k: int 3) - list[SkillMeta]: 简单的关键词检索按标签和描述的相关性返回候选技能。 query_tags set(query.lower().split()) scored [] for meta in self._skills.values(): score 0 for tag in meta.tags: if tag in query_tags: score 2 # description 里的关键词也有加分 for word in query_tags: if word in meta.description.lower(): score 1 if score 0: scored.append((score, meta)) scored.sort(keylambda x: x[0], reverseTrue) return [meta for _, meta in scored[:top_k]] def invoke(self, name: str, params: dict) - Any: meta self._skills.get(name) if not meta: raise KeyError(fSkill {name} not found) handler self._handlers[name] return handler(params)这版代码牺牲了一点语言优雅度换来了“每一步都能看懂”。实际生产环境中retrieve的query_tags用向量检索替代效果会好很多。这里演示的是思路先缩小候选集再调用。4.3 编写两个技能我们编写两个有实际业务感的技能天气查询和差旅建议。# skills/weather.py def get_weather(params): 模拟查询天气的接口。 city params.get(city) date params.get(date, 今天) # 生产环境这里应该是 requests.get(weather_api, ...) # 演示环境我们写死返回结构化数据 return { city: city, date: date, temperature: 25, condition: 晴天, humidity: 0.4, wind_level: 3, }# skills/travel.py def recommend_travel(params): 根据天气数据给出出行建议。 temperature params.get(temperature) condition params.get(condition) city params.get(city) if temperature 30: advice 天气炎热建议做好防晒并及时补水。 elif condition 雨: advice 有降雨建议携带雨具并减少室外活动。 else: advice 天气适宜适合安排户外活动。 return { city: city, advice: advice, suitable: 户外散步 if temperature 30 else 室内活动, }注意这两个技能都不是“真实接口”演示重点是技能接口的输入输出设计。生产环境中get_weather内部接入真实天气服务商或者通过宿主机上的 Agent 网关调用内部服务但外层协议保持不变。这个设计带来的直接好处是技能改内部实现不影响技能网络的编排层技能对外协议一旦稳定可以像插件一样被任意更换。4.4 注册中心里登记技能# main.py from registry import SkillRegistry, SkillMeta from skills.weather import get_weather from skills.travel import recommend_travel def setup_registry() - SkillRegistry: registry SkillRegistry() registry.register( SkillMeta( nameweather, description查询指定城市和日期的天气情况适合在用户询问天气、出门建议时使用, tags[weather, 天气, 查询], parameters{city: string, date: string}, output_schema{temperature: number, condition: string}, timeout3, ), get_weather, ) registry.register( SkillMeta( nametravel_advice, description根据天气数据生成出行建议适合在天气查询完成后进行联动编排, tags[travel, advice, 出行, 建议], parameters{city: string, temperature: number, condition: string}, output_schema{advice: string, suitable: string}, timeout3, ), recommend_travel, ) return registry到这里我们已经完成了“技能注册”和“技能检索”的第一版。运行main.py打印技能候选列表你就能看到一个最小技能网络的核心概念已经闭合。4.5 编排器把多个技能串起来下面是最核心的部分编排器。# orchestrator.py from registry import SkillRegistry class SkillOrchestrator: 技能编排器根据执行计划依次调用技能并传递参数。 def __init__(self, registry: SkillRegistry): self.registry registry def execute_plan(self, plan: list[dict]) - dict: plan 示例 [ {skill: weather, params: {city: 上海, date: 明天}, output_key: wx}, {skill: travel_advice, params: { city: 上海, temperature: ${wx.temperature}, condition: ${wx.condition} }, output_key: advice} ] context {} for step in plan: skill_name step[skill] raw_params step.get(params, {}) # 支持从上下文引用前序技能的返回值 resolved_params self._resolve_params(raw_params, context) result self.registry.invoke(skill_name, resolved_params) context[step[output_key]] result return context def _resolve_params(self, raw: dict, context: dict) - dict: resolved {} for key, value in raw.items(): if isinstance(value, str) and value.startswith(${) and value.endswith(}): ref value[2:-1] parts ref.split(.) source context.get(parts[0], {}) resolved[key] source.get(parts[1]) if isinstance(source, dict) else None else: resolved[key] value return resolved这里的_resolve_params很关键。它允许执行计划里写${wx.temperature}这样的表达式表示“取上一个技能输出中的 temperature 字段”。这个做法的好处是执行计划变成了一份可读的 JSON 配置而不是写死在代码里的 if/else。真正生产环境里你可以用jsonpath或者JMESPath做更复杂的参数抽取但核心思想一样技能之间的数据流转要用显式表达式不要靠函数内部偷偷改外部全局变量。4.6 Agent 入口把用户意图映射为技能链最后写一个简化版 Agent 入口。真正的模型调用部分涉及 LLM 推理这里我们用规则演示流程避免引入过重的依赖。# agent.py from registry import SkillRegistry from orchestrator import SkillOrchestrator from main import setup_registry def parse_user_intent(user_input: str) - list[dict]: 将用户输入映射为技能执行计划。 生产环境这里通常是 LLM 做意图识别和计划生成。 这里用规则模拟 - 包含“天气”且包含“建议” - 先天气后出行建议 - 只包含“天气” - 只查天气 if 天气 in user_input and (建议 in user_input or 适合 in user_input): return [ { skill: weather, params: {city: 上海, date: 明天}, output_key: wx, }, { skill: travel_advice, params: { city: 上海, temperature: ${wx.temperature}, condition: ${wx.condition}, }, output_key: advice, }, ] if 天气 in user_input: return [ { skill: weather, params: {city: 上海, date: 明天}, output_key: wx, } ] return [] def main(): registry setup_registry() orchestrator SkillOrchestrator(registry) user_input 上海明天天气怎么样适合出去散步吗 plan parse_user_intent(user_input) if not plan: print(没有匹配到任何技能计划。) return result orchestrator.execute_plan(plan) for key, value in result.items(): print(f{key} - {value}) if __name__ __main__: main()运行这段代码输出如下wx - {city: 上海, date: 明天, temperature: 25, condition: 晴天, humidity: 0.4, wind_level: 3} advice - {city: 上海, advice: 天气适宜适合安排户外活动。, suitable: 户外散步}你在这里能清楚地看出“技能组合”的效果Agent 先调天气技能再把天气输出作为出行建议技能的输入最后得到一个跨技能组合后的结论。整个过程没有写死“城市上海”的业务逻辑技能之间完全通过上下文传递数据。这个例子虽然简单但已经包含技能网络的四个核心机制注册、检索、组合、调用。你完全可以沿着这个基底继续加技能。5. 用配置驱动技能网络在真实项目里我们不希望每增加一个技能就改一次 Java 或 Python 代码。更好的做法是让技能元数据外置用配置文件管理。下面的skills.json展示了一个纯配置驱动的技能描述方案[ { name: send_email, description: 发送邮件给指定用户适合在需要通知、审批、报告场景使用, tags: [email, 邮件, 通知], parameters: { type: object, properties: { to: {type: string, description: 收件人}, subject: {type: string, description: 邮件主题}, body: {type: string, description: 邮件正文} }, required: [to, subject, body] }, timeout: 10, retry: 2 }, { name: create_todo, description: 创建待办事项并添加到指定项目列表适合任务管理场景, tags: [todo, task, 待办], parameters: { type: object, properties: { title: {type: string}, due_date: {type: string} }, required: [title] }, timeout: 5, retry: 1 } ]这段 JSON 可以在启动时加载提前构建技能注册中心。与在代码里硬编码SkillMeta相比配置化的优势很明显新技能上线只需要加一段配置 一个 handler。非开发人员可以审核技能描述确保 LLM 看到的描述清晰无歧义。不同租户可以加载不同技能集实现按租户隔离。如果你用的是 Spring AI完全可以把这个 JSON 映射成Tool的注解参数或者转成自定义的ToolCallback。思路完全一致。6. 完整示例从注册到编排到调用为了让演示更加完整下面补充一个完整可运行的 Python 脚本。它不依赖任何第三方库只要本机有 Python 3.10 或以上版本就能跑。# skill_net_demo.py from dataclasses import dataclass, field from typing import Callable, Any dataclass class SkillMeta: name: str description: str tags: list[str] field(default_factorylist) params: dict field(default_factorydict) class Registry: def __init__(self): self.metas {} self.handlers {} def register(self, meta: SkillMeta, handler: Callable): self.metas[meta.name] meta self.handlers[meta.name] handler def retrieve(self, query: str): q set(query.lower().split()) scored [] for meta in self.metas.values(): score sum(1 for tag in meta.tags if tag in q) scored.append((score, meta)) scored.sort(keylambda x: x[0], reverseTrue) return [m for s, m in scored if s 0] def invoke(self, name: str, **kwargs): if name not in self.handlers: raise ValueError(funknown skill: {name}) return self.handlers[name](**kwargs) def weather(**kwargs): return {condition: sunny, temperature: 26} def suggest(**kwargs): temp kwargs.get(temperature) if temp and temp 30: return {advice: 太热室内活动} return {advice: 适合户外} registry Registry() registry.register( SkillMeta(weather, 查询天气, [weather, 天气, 查询]), weather, ) registry.register( SkillMeta(suggest, 出行建议, [suggest, 建议, 出行]), suggest, ) candidates registry.retrieve(天气 建议) print(候选技能:, [m.name for m in candidates]) # 执行组合 w registry.invoke(weather, city上海) advice registry.invoke(suggest, temperaturew[temperature], conditionw[condition]) print(结果:, w, advice)运行命令python skill_net_demo.py预期输出候选技能: [weather, suggest] 结果: {condition: sunny, temperature: 26} {advice: 适合户外}这个脚本展示的检索方式虽然简单但“候选技能先缩小、再组合调用”的流程已经完整。下一步建议把weather技能内部改成真实 HTTP 请求把retrieve改成向量检索整个就接近生产雏形了。7. 常见问题与排查思路在技能网络接入真实项目后问题往往会出现在几个固定位置。这里整理一份高频问题清单。问题现象可能原因排查方式解决方案Agent 在技能多时不调用正确技能技能描述不准确或存在歧义打印候选技能列表检查检索排序重写技能描述增加 use_case 字段技能调用报参数缺少前序技能输出和后序技能参数对不上查看编排上下文对比输出 schema 和参数预期使用${wx.temperature}显式映射某个技能调用超时导致整条链路失败未设置单技能超时或重试检查timeout和retry配置对只读查询类技能设置短超时并重试一次同一个技能在多个场景返回格式不一致技能实现内部直接返回裸数据检查技能返回值是否经过统一协议包装统一返回{status, data, error, metadata}Agent 把 A 技能理解为 B 技能技能描述里出现了过多重复关键词逐个打印技能描述让评测集跑一轮分类准确率精简 tags降低描述重叠度技能组合顺序总是错执行计划完全靠模型生成且不稳定对关键链路改用静态编排模板高确定性链路用代码模板低确定性链路才动态编排生产环境技能变更后线上行为异常技能元数据更新未做灰度检查版本号和发布流程技能描述先在小流量 Agent 验证再全量排查的重要手段是可观测性。技能网络上线第一件事不是优化效果而是给每个技能调用加上call_id、耗时、输入输出摘要日志。否则一旦技能链路有二十个节点出问题根本定位不了。8. 最佳实践与工程建议8.1 技能描述要“面向检索”而非“面向人”很多开发者写技能描述时习惯像写代码注释一样只写“查询天气”。但技能描述是给 LLM 和检索系统看的信息密度要高。反例description: 查天气正例description: 查询指定城市和日期的天气情况包含温度、湿度、风力、天气现象适合用户询问天气、穿衣建议、出行准备时调用。真实项目里技能描述的质量直接决定检索准确率。我见过一个项目只优化了技能描述没有换模型工具选择准确率从 78% 提到了 91%。这个杠杆幅度比调模型参数大得多。8.2 优先做静态编排模板再叠加动态编排不要太相信让 Agent 自己规划二十步链路的能力。在实际业务里链路越关键越应该走静态编排。例如“查库存→算报价→生成订单→发起审批”这种确定性流程应该由开发者定义模板Agent 只负责填充参数。动态编排用在真正需要发散思维的场景。比如“根据用户聊天记录生成周报并发给直属上级”技能的选择和顺序具有不确定性这时候交给模型规划更合适。8.3 技能注册中心必须有版本管理和灰度你可能会问技能实现是代码代码本来就在 CI/CD 里管理为什么还强调版本关键在于 LLM 看到的技能描述也是技能的一部分描述文本的变更和代码变更都需要独立版本。上线流程建议技能代码合并到主干。技能描述同步更新。在测试环境跑评测集记录工具选择准确率。灰度发布到生产 Agent监控工具选择失败率。确认无误后再全量。8.4 技能调用务必设置超时和降级技能背后如果是真实 API一定会出现网络抖动、上游超时。因此每个技能调用都要有超时控制。更重要的是定义“技能不可用时 Agent 怎么回答”。推荐模式技能超时后重试一次。重试仍失败记录错误返回给 Agent 一个明确的“该技能暂不可用”信号。Agent 收到信号后可以尝试替代技能或者直接告知用户。要做到这一点编排器必须能够根据错误结果动态调整后续步骤。一个最简单的做法是在execute_plan里捕获invoke异常把错误信息写进 context由 Agent 决定是否继续。try: result self.registry.invoke(skill_name, resolved_params) except Exception as exc: context[step[output_key]] { status: error, error: str(exc), skill: skill_name, } continue注意这里要谨慎处理“部分成功”的场景。如果链路前两步成功、第三步失败是把已经成功的结果返回给用户还是直接整链路失败这取决于业务语义。比如“查询天气后生成报告”天气查询成功但报告生成失败应该把天气结果和错误信息同时给 Agent让 Agent 决定如何给用户一个最低可用度的回答。8.5 评测集是技能网络的护城河没有评测集技能网络优化就是瞎调。建议为每个技能至少准备三类测试样本必须调用该技能的显式语句。可以不调用该技能的相似干扰语句。该技能与另一个技能同时被需要时的组合语句。每次修改技能描述后跑一遍评测集比较工具选择准确率和编排成功率。这一步听起来繁琐但它是维持技能网络长期稳定最值得投入的工作。8.6 从单 Agent 到多 Agent技能网络是协作基础在多智能体架构里技能网络还能进一步延伸。一个 Agent 可以把另一个 Agent 当作技能来调用。这在 EvoAgentX 这类多智能体讨论中是一个很常见的思路Agent 的技能网络不仅包含工具技能还包含协作技能。当一个 Agent 发现自己的技能不足以完成用户请求时它可以检索到另一个 Agent 的元数据并把任务派发过去。这会要求技能注册中心额外支持“人群路由”——按 Agent 分类、按租户隔离、按权限过滤。但底层的注册、检索、调用机制并没有改变。如果你计划做多 Agent 系统建议先在单体 Agent 上把技能网络这四个机制做扎实再谈 Agent 间的技能互调。9. 总结与后续学习方向SkillNet 这个话题放到今天看已经不只是架构师应该关心的东西而是每个做 AI Agent 的开发者迟早要面对的工程问题。把技能当成网络节点来治理用标准元数据注册、用检索缩小决策空间、用编排计划组织调用链这套方法可以让 Agent 的技能规模从“十几个”提升到“上百个甚至更多”同时保持可控的调用准确率。从 EvoAgentX Talk 的视角来看“技能网络”更像是一种务实的工程共识不追求模型在开放式规划上一口气处理几十个工具而是用工程手段把技能的复杂度降下来让模型每次只面对一个小而准确的决策。如果你想接着深入建议按这个顺序学习把本文的最小示例跑通搞清楚注册、检索、调用三个环节。把检索从关键词换成 Embedding 向量检索做一个带本地知识库的技能候选召回。给编排器增加一个可视化执行计划查看器观察技能链路的每一步输入输出。用 pytest 为每个技能和编排器建立回归测试把评测集和 CI 接起来。调研 Spring AI 或 LangChain 里的 Tool 机制看它和你自己实现的技能网络在设计上的异同。AI Agent 的发展方向大概率不会是“一个模型统治一切”而是“模型负责判断技能网络负责规模化”。对开发者来说现在开始积累技能注册、检索、编排、调用的工程经验正是投入产出比很高的时间点。建议收藏这篇文章下一步就是找一个你业务里最常被 Agent 调用的工具按第 5 节的 JSON 配置模板登记成第一个技能然后跑通一条包含两个技能的编排链路。先把最小闭环做出来后面的一切都好说。 
长河君 · 2026/9/8 4:29:21 · 阅读 1.2k AI Agent技能网络SkillNet：从工具调用到规模化编排
如果说 2025 年我们还在讨论“AI Agent 能不能用”那么到 2026 年讨论重点已经变成了“AI Agent 能不能稳定地规模化地用”。换个更直白的说法你在本地写一个 Agent Demo 很容易让它调用一个天气接口也不难但当你把日历、邮件、数据库、审批流、知识库、低代码平台这些技能全部塞给 Agent 时你会发现真正让系统崩溃的从来不是模型本身而是——技能多了之后Agent 根本不知道怎么找到对的技能、怎么把多个技能串起来、怎么在一个技能报错之后优雅降级。这个问题的答案正在从“工具调用 Tool Calling”演进到“技能网络 Skill Network”。本文要讲的 SkillNet本质上是把 Agent 的每一项能力当作一个可以被注册、检索、组合和调用的“技能节点”然后通过统一编排层让 Agent 像调用平台 API 一样调用技能。文章会分成三个部分先讲清楚为什么需要技能网络再看它的检索、组合、调用机制到底是怎么回事最后用一个最小可运行的实现把流程完整跑通。读完你会得到一个判断Agent 未来拼的不是单点模型能力而是技能网络的工程化水平。1. 这篇文章真正要解决的问题如果你正在做 AI Agent 开发大概率会遇到下面三类问题之一。第一类技能越多Agent 越笨。把一个 Agent 接上十个工具之后它的指令遵循能力会明显下降。模型需要在十多个工具描述中挑出符合当前任务的工具描述越长、数量越多误差就越大。很多时候不是模型不行而是我们没有给模型一个更好的检索机制。第二类技能调用是“写死”的不是“编排”的。大多数人实现 Agent 技能的方式是在 System Prompt 里写“如果你需要查天气调用 weather_api”然后靠模型自己去翻 Prompt。这种方式在技能数量少的时候能用但技能之间一旦存在依赖关系——比如“先查库存再算报价再生成审批单”——靠 Prompt 硬编码就完全失控了。第三类技能与技能之间是孤岛没有组合能力。真实业务从来不是一个技能包打天下。你需要让 Agent 同时处理“查资料→总结→写邮件→发起审批”这样一条链路。如果没有一套标准的技能描述、路由规则和组合方式每接一个技能就要改一遍代码项目越大越痛苦。SkillNet 要解决的就是这三个问题的交集技能的标准化描述、按需检索、顺序编排和可靠调用。它不是什么神秘框架也不是替代 LangChain 或 Spring AI 的东西而是一种设计思路。你可以把它理解成 Agent 世界的“微服务网关”每个技能是一个独立服务注册中心知道所有技能的路由信息编排引擎负责把用户请求翻译成技能调用链最后统一执行并聚合结果。从 EvoAgentX Talk 的讨论语境来看这个方向更像是在强调多智能体也好单体 Agent 也好真正制约能力上限的是技能层是否具备“网络化”的治理能力。技能不是堆得越多越好而是要能被有效管理。2. 基础概念与核心原理2.1 什么是 Agent 技能在传统软件开发里一个功能模块有明确的接口定义、参数校验和返回值协议。AI Agent 里的“技能”虽然形式不一样但本质也是一样它是 Agent 可以主动调用的一组能力封装。技能可以是一个 API 调用比如查天气、发邮件、下单。一个代码函数比如计算运费、生成本地缓存。一个更复杂的子 Agent比如“先搜索再总结”的专用助手。一个提示模板比如把用户问题格式化为结构化查询。在代码层面一个技能至少包含两部分模型用来决策的“技能描述”程序用来执行的“技能实现”。前者要足够清楚让模型知道什么时候该用后者要足够健壮让程序在参数异常时不至于崩溃。2.2 从 Tool Calling 到 Skill Network你可能会问LangChain 的 Tool Calling 已经能做工具调用了为什么还要提技能网络这里要区分两个层次。Tool Calling 解决的是“模型能不能正确输出调用某个工具的 JSON”。它更关心模型侧的行为。Skill Network 解决的是“一个 Agent 系统如何管理大量技能”。它更关心系统侧的组织方式。举个现实例子。你用 Tool Calling 可以让模型调用send_email这个工具但你不会在 Tool Calling 层解决这些问题技能描述按什么格式维护100 个技能如何快速筛选出最相关的 3 个技能 A 的输出怎么变成技能 B 的输入技能调用失败后是否要重试还是换路这些都是技能网络层的问题。2.3 技能的四种关键能力SkillNet 讨论的“技能网络”通常围绕四个核心机制展开机制解决什么问题类比技能注册技能怎么声明自己的功能、入参、出参微服务的服务注册技能检索Agent 如何从 N 个技能中选中最相关的 M 个服务发现与路由技能组合多个技能如何按照业务语义串联工作流编排技能调用技能执行时参数如何校验、结果如何返回RPC 调用与异常处理从材料来看SkillNet 强调的“可编排”关键就在于把技能当成网络节点而不是孤立函数。节点与节点之间通过统一的输入输出协议连接业务方只需要关心链路的编排方式不需要关心每个技能内部怎么实现。2.4 一个通俗类比你可以把 SkillNet 想成一个大型公司的内部服务台。过去每个部门都有自己的办事流程客户要办事必须知道该去哪个部门、找谁、带什么材料。这就是没有技能网络的状态用户Agent必须自己搞清楚所有细节。有了服务台之后你只需要说“我要报销一笔差旅费”服务台会判断这件事涉及财务技能。需要先调用差旅记录技能。再调用报销单生成技能。最后推送审批技能。Agent 就是那个“服务台”SkillNet 就是服务台背后的流程管理系统技能就是各部门提供的服务。3. SkillNet 的核心机制拆解这一节我们把四个机制逐个讲透讲到能指导写代码的程度。3.1 技能注册先定义一套技能元数据技能要能被检索和编排第一步是标准化。每个技能都应该有一套元数据name技能唯一标识。description技能能力描述给模型看的要写清楚“什么时候用、能做什么、不能做什么”。parameters入参 JSON Schema。output_schema出参格式。routing_tags路由标签用于快速过滤。例如[查询, 只读]。timeout调用超时时间。retry失败重试策略。有人会觉得这些字段太多了其实不然。在一个几十个技能的系统里没有标准元数据检索和编排根本无从谈起。3.2 技能检索先缩小候选集再交给模型决策这是 SkillNet 与普通 Tool Calling 最大的区别。普通 Tool Calling 会把所有技能描述一股脑丢给模型SkillNet 则会先做一个“预检索”把技能候选集从 100 个缩小到 5 个再把 5 个技能描述交给模型做最终决策。检索方式可以选择关键词/标签匹配根据用户问题的词频匹配routing_tags。向量相似度检索把用户问题和技能描述都转成向量然后 top-K。规则路由根据用户类型、租户、业务线直接指定技能范围。这个设计的价值很明显模型每次做选择时面对的选项变少了选择准确率自然更高同时技能描述越长、数量越多 token 成本也越高预检索能有效降低成本。3.3 技能组合由执行计划驱动链路技能组合不等于简单地把几个函数写在 if/else 里。“可编排”的意思是组合逻辑由一份可解释、可配置的执行计划决定。比如用户请求“帮我查一下上海明天适合跑步吗”技能网络的执行计划可能是调用geocoding技能把“上海”转成经纬度。调用weather技能查询明日天气和空气质量。调用running_advice技能根据天气数据生成跑步建议。三个技能之间的依赖关系、参数传递、结果合并规则都应该在这份计划里描述清楚。如果计划是模型生成的我们称之为“动态编排”如果计划是开发者写死的就是“静态编排”。生产系统里通常两者结合。3.4 技能调用协议统一了才能万物互联组合的前提是协议统一。不管底层技能是 Python 函数、HTTP 接口还是另一个 Agent对外暴露的都应该是统一的invoke(context)接口输入一个上下文对象输出一个标准结果结构。标准结果结构至少包含status成功、失败、部分成功。data技能返回的数据。error错误码和错误信息。metadata耗时、使用技能版本号、调用链 ID。没有统一协议技能组合就是空谈。A 技能返回的字段和 B 技能需要的字段对不上模型再强也补不了格式差异。4. 轻量技能网络实现思路前面讲了概念接下来我们用代码把这个架构跑通。这里选择 Python 做演示因为 Python 在 AI Agent 生态里表达能力最直接。生产环境你可以用 Java、Go甚至用 n8n 这类流程引擎但核心设计都是一样的。4.1 工程目录skill-net-demo/ ├── agent.py # Agent 主程序意图识别 技能路由 ├── registry.py # 技能注册与检索 ├── orchestrator.py # 技能编排与执行 ├── skills/ │ ├── __init__.py │ ├── weather.py # 天气技能 │ ├── calc.py # 计算器技能 │ └── travel.py # 差旅建议技能 └── skills.json # 技能元数据配置这个目录不是必须照抄但建议保持类似分层技能定义、注册检索、编排执行、入口四个模块分开。4.2 定义技能元数据我们先用一个 dataclass 定义技能元数据。# registry.py from dataclasses import dataclass, field from typing import Callable, Any dataclass class SkillMeta: name: str description: str tags: list[str] parameters: dict[str, Any] field(default_factorydict) output_schema: dict[str, Any] field(default_factorydict) timeout: int 5 retry: int 1 class SkillRegistry: 技能注册中心负责登记、检索和管理技能。 def __init__(self): self._skills: dict[str, SkillMeta] {} # name - callable 的映射存放技能实现函数 self._handlers: dict[str, Callable] {} def register(self, meta: SkillMeta, handler: Callable): self._skills[meta.name] meta self._handlers[meta.name] handler def get(self, name: str) - SkillMeta: return self._skills.get(name) def retrieve(self, query: str, top_k: int 3) - list[SkillMeta]: 简单的关键词检索按标签和描述的相关性返回候选技能。 query_tags set(query.lower().split()) scored [] for meta in self._skills.values(): score 0 for tag in meta.tags: if tag in query_tags: score 2 # description 里的关键词也有加分 for word in query_tags: if word in meta.description.lower(): score 1 if score 0: scored.append((score, meta)) scored.sort(keylambda x: x[0], reverseTrue) return [meta for _, meta in scored[:top_k]] def invoke(self, name: str, params: dict) - Any: meta self._skills.get(name) if not meta: raise KeyError(fSkill {name} not found) handler self._handlers[name] return handler(params)这版代码牺牲了一点语言优雅度换来了“每一步都能看懂”。实际生产环境中retrieve的query_tags用向量检索替代效果会好很多。这里演示的是思路先缩小候选集再调用。4.3 编写两个技能我们编写两个有实际业务感的技能天气查询和差旅建议。# skills/weather.py def get_weather(params): 模拟查询天气的接口。 city params.get(city) date params.get(date, 今天) # 生产环境这里应该是 requests.get(weather_api, ...) # 演示环境我们写死返回结构化数据 return { city: city, date: date, temperature: 25, condition: 晴天, humidity: 0.4, wind_level: 3, }# skills/travel.py def recommend_travel(params): 根据天气数据给出出行建议。 temperature params.get(temperature) condition params.get(condition) city params.get(city) if temperature 30: advice 天气炎热建议做好防晒并及时补水。 elif condition 雨: advice 有降雨建议携带雨具并减少室外活动。 else: advice 天气适宜适合安排户外活动。 return { city: city, advice: advice, suitable: 户外散步 if temperature 30 else 室内活动, }注意这两个技能都不是“真实接口”演示重点是技能接口的输入输出设计。生产环境中get_weather内部接入真实天气服务商或者通过宿主机上的 Agent 网关调用内部服务但外层协议保持不变。这个设计带来的直接好处是技能改内部实现不影响技能网络的编排层技能对外协议一旦稳定可以像插件一样被任意更换。4.4 注册中心里登记技能# main.py from registry import SkillRegistry, SkillMeta from skills.weather import get_weather from skills.travel import recommend_travel def setup_registry() - SkillRegistry: registry SkillRegistry() registry.register( SkillMeta( nameweather, description查询指定城市和日期的天气情况适合在用户询问天气、出门建议时使用, tags[weather, 天气, 查询], parameters{city: string, date: string}, output_schema{temperature: number, condition: string}, timeout3, ), get_weather, ) registry.register( SkillMeta( nametravel_advice, description根据天气数据生成出行建议适合在天气查询完成后进行联动编排, tags[travel, advice, 出行, 建议], parameters{city: string, temperature: number, condition: string}, output_schema{advice: string, suitable: string}, timeout3, ), recommend_travel, ) return registry到这里我们已经完成了“技能注册”和“技能检索”的第一版。运行main.py打印技能候选列表你就能看到一个最小技能网络的核心概念已经闭合。4.5 编排器把多个技能串起来下面是最核心的部分编排器。# orchestrator.py from registry import SkillRegistry class SkillOrchestrator: 技能编排器根据执行计划依次调用技能并传递参数。 def __init__(self, registry: SkillRegistry): self.registry registry def execute_plan(self, plan: list[dict]) - dict: plan 示例 [ {skill: weather, params: {city: 上海, date: 明天}, output_key: wx}, {skill: travel_advice, params: { city: 上海, temperature: ${wx.temperature}, condition: ${wx.condition} }, output_key: advice} ] context {} for step in plan: skill_name step[skill] raw_params step.get(params, {}) # 支持从上下文引用前序技能的返回值 resolved_params self._resolve_params(raw_params, context) result self.registry.invoke(skill_name, resolved_params) context[step[output_key]] result return context def _resolve_params(self, raw: dict, context: dict) - dict: resolved {} for key, value in raw.items(): if isinstance(value, str) and value.startswith(${) and value.endswith(}): ref value[2:-1] parts ref.split(.) source context.get(parts[0], {}) resolved[key] source.get(parts[1]) if isinstance(source, dict) else None else: resolved[key] value return resolved这里的_resolve_params很关键。它允许执行计划里写${wx.temperature}这样的表达式表示“取上一个技能输出中的 temperature 字段”。这个做法的好处是执行计划变成了一份可读的 JSON 配置而不是写死在代码里的 if/else。真正生产环境里你可以用jsonpath或者JMESPath做更复杂的参数抽取但核心思想一样技能之间的数据流转要用显式表达式不要靠函数内部偷偷改外部全局变量。4.6 Agent 入口把用户意图映射为技能链最后写一个简化版 Agent 入口。真正的模型调用部分涉及 LLM 推理这里我们用规则演示流程避免引入过重的依赖。# agent.py from registry import SkillRegistry from orchestrator import SkillOrchestrator from main import setup_registry def parse_user_intent(user_input: str) - list[dict]: 将用户输入映射为技能执行计划。 生产环境这里通常是 LLM 做意图识别和计划生成。 这里用规则模拟 - 包含“天气”且包含“建议” - 先天气后出行建议 - 只包含“天气” - 只查天气 if 天气 in user_input and (建议 in user_input or 适合 in user_input): return [ { skill: weather, params: {city: 上海, date: 明天}, output_key: wx, }, { skill: travel_advice, params: { city: 上海, temperature: ${wx.temperature}, condition: ${wx.condition}, }, output_key: advice, }, ] if 天气 in user_input: return [ { skill: weather, params: {city: 上海, date: 明天}, output_key: wx, } ] return [] def main(): registry setup_registry() orchestrator SkillOrchestrator(registry) user_input 上海明天天气怎么样适合出去散步吗 plan parse_user_intent(user_input) if not plan: print(没有匹配到任何技能计划。) return result orchestrator.execute_plan(plan) for key, value in result.items(): print(f{key} - {value}) if __name__ __main__: main()运行这段代码输出如下wx - {city: 上海, date: 明天, temperature: 25, condition: 晴天, humidity: 0.4, wind_level: 3} advice - {city: 上海, advice: 天气适宜适合安排户外活动。, suitable: 户外散步}你在这里能清楚地看出“技能组合”的效果Agent 先调天气技能再把天气输出作为出行建议技能的输入最后得到一个跨技能组合后的结论。整个过程没有写死“城市上海”的业务逻辑技能之间完全通过上下文传递数据。这个例子虽然简单但已经包含技能网络的四个核心机制注册、检索、组合、调用。你完全可以沿着这个基底继续加技能。5. 用配置驱动技能网络在真实项目里我们不希望每增加一个技能就改一次 Java 或 Python 代码。更好的做法是让技能元数据外置用配置文件管理。下面的skills.json展示了一个纯配置驱动的技能描述方案[ { name: send_email, description: 发送邮件给指定用户适合在需要通知、审批、报告场景使用, tags: [email, 邮件, 通知], parameters: { type: object, properties: { to: {type: string, description: 收件人}, subject: {type: string, description: 邮件主题}, body: {type: string, description: 邮件正文} }, required: [to, subject, body] }, timeout: 10, retry: 2 }, { name: create_todo, description: 创建待办事项并添加到指定项目列表适合任务管理场景, tags: [todo, task, 待办], parameters: { type: object, properties: { title: {type: string}, due_date: {type: string} }, required: [title] }, timeout: 5, retry: 1 } ]这段 JSON 可以在启动时加载提前构建技能注册中心。与在代码里硬编码SkillMeta相比配置化的优势很明显新技能上线只需要加一段配置 一个 handler。非开发人员可以审核技能描述确保 LLM 看到的描述清晰无歧义。不同租户可以加载不同技能集实现按租户隔离。如果你用的是 Spring AI完全可以把这个 JSON 映射成Tool的注解参数或者转成自定义的ToolCallback。思路完全一致。6. 完整示例从注册到编排到调用为了让演示更加完整下面补充一个完整可运行的 Python 脚本。它不依赖任何第三方库只要本机有 Python 3.10 或以上版本就能跑。# skill_net_demo.py from dataclasses import dataclass, field from typing import Callable, Any dataclass class SkillMeta: name: str description: str tags: list[str] field(default_factorylist) params: dict field(default_factorydict) class Registry: def __init__(self): self.metas {} self.handlers {} def register(self, meta: SkillMeta, handler: Callable): self.metas[meta.name] meta self.handlers[meta.name] handler def retrieve(self, query: str): q set(query.lower().split()) scored [] for meta in self.metas.values(): score sum(1 for tag in meta.tags if tag in q) scored.append((score, meta)) scored.sort(keylambda x: x[0], reverseTrue) return [m for s, m in scored if s 0] def invoke(self, name: str, **kwargs): if name not in self.handlers: raise ValueError(funknown skill: {name}) return self.handlers[name](**kwargs) def weather(**kwargs): return {condition: sunny, temperature: 26} def suggest(**kwargs): temp kwargs.get(temperature) if temp and temp 30: return {advice: 太热室内活动} return {advice: 适合户外} registry Registry() registry.register( SkillMeta(weather, 查询天气, [weather, 天气, 查询]), weather, ) registry.register( SkillMeta(suggest, 出行建议, [suggest, 建议, 出行]), suggest, ) candidates registry.retrieve(天气 建议) print(候选技能:, [m.name for m in candidates]) # 执行组合 w registry.invoke(weather, city上海) advice registry.invoke(suggest, temperaturew[temperature], conditionw[condition]) print(结果:, w, advice)运行命令python skill_net_demo.py预期输出候选技能: [weather, suggest] 结果: {condition: sunny, temperature: 26} {advice: 适合户外}这个脚本展示的检索方式虽然简单但“候选技能先缩小、再组合调用”的流程已经完整。下一步建议把weather技能内部改成真实 HTTP 请求把retrieve改成向量检索整个就接近生产雏形了。7. 常见问题与排查思路在技能网络接入真实项目后问题往往会出现在几个固定位置。这里整理一份高频问题清单。问题现象可能原因排查方式解决方案Agent 在技能多时不调用正确技能技能描述不准确或存在歧义打印候选技能列表检查检索排序重写技能描述增加 use_case 字段技能调用报参数缺少前序技能输出和后序技能参数对不上查看编排上下文对比输出 schema 和参数预期使用${wx.temperature}显式映射某个技能调用超时导致整条链路失败未设置单技能超时或重试检查timeout和retry配置对只读查询类技能设置短超时并重试一次同一个技能在多个场景返回格式不一致技能实现内部直接返回裸数据检查技能返回值是否经过统一协议包装统一返回{status, data, error, metadata}Agent 把 A 技能理解为 B 技能技能描述里出现了过多重复关键词逐个打印技能描述让评测集跑一轮分类准确率精简 tags降低描述重叠度技能组合顺序总是错执行计划完全靠模型生成且不稳定对关键链路改用静态编排模板高确定性链路用代码模板低确定性链路才动态编排生产环境技能变更后线上行为异常技能元数据更新未做灰度检查版本号和发布流程技能描述先在小流量 Agent 验证再全量排查的重要手段是可观测性。技能网络上线第一件事不是优化效果而是给每个技能调用加上call_id、耗时、输入输出摘要日志。否则一旦技能链路有二十个节点出问题根本定位不了。8. 最佳实践与工程建议8.1 技能描述要“面向检索”而非“面向人”很多开发者写技能描述时习惯像写代码注释一样只写“查询天气”。但技能描述是给 LLM 和检索系统看的信息密度要高。反例description: 查天气正例description: 查询指定城市和日期的天气情况包含温度、湿度、风力、天气现象适合用户询问天气、穿衣建议、出行准备时调用。真实项目里技能描述的质量直接决定检索准确率。我见过一个项目只优化了技能描述没有换模型工具选择准确率从 78% 提到了 91%。这个杠杆幅度比调模型参数大得多。8.2 优先做静态编排模板再叠加动态编排不要太相信让 Agent 自己规划二十步链路的能力。在实际业务里链路越关键越应该走静态编排。例如“查库存→算报价→生成订单→发起审批”这种确定性流程应该由开发者定义模板Agent 只负责填充参数。动态编排用在真正需要发散思维的场景。比如“根据用户聊天记录生成周报并发给直属上级”技能的选择和顺序具有不确定性这时候交给模型规划更合适。8.3 技能注册中心必须有版本管理和灰度你可能会问技能实现是代码代码本来就在 CI/CD 里管理为什么还强调版本关键在于 LLM 看到的技能描述也是技能的一部分描述文本的变更和代码变更都需要独立版本。上线流程建议技能代码合并到主干。技能描述同步更新。在测试环境跑评测集记录工具选择准确率。灰度发布到生产 Agent监控工具选择失败率。确认无误后再全量。8.4 技能调用务必设置超时和降级技能背后如果是真实 API一定会出现网络抖动、上游超时。因此每个技能调用都要有超时控制。更重要的是定义“技能不可用时 Agent 怎么回答”。推荐模式技能超时后重试一次。重试仍失败记录错误返回给 Agent 一个明确的“该技能暂不可用”信号。Agent 收到信号后可以尝试替代技能或者直接告知用户。要做到这一点编排器必须能够根据错误结果动态调整后续步骤。一个最简单的做法是在execute_plan里捕获invoke异常把错误信息写进 context由 Agent 决定是否继续。try: result self.registry.invoke(skill_name, resolved_params) except Exception as exc: context[step[output_key]] { status: error, error: str(exc), skill: skill_name, } continue注意这里要谨慎处理“部分成功”的场景。如果链路前两步成功、第三步失败是把已经成功的结果返回给用户还是直接整链路失败这取决于业务语义。比如“查询天气后生成报告”天气查询成功但报告生成失败应该把天气结果和错误信息同时给 Agent让 Agent 决定如何给用户一个最低可用度的回答。8.5 评测集是技能网络的护城河没有评测集技能网络优化就是瞎调。建议为每个技能至少准备三类测试样本必须调用该技能的显式语句。可以不调用该技能的相似干扰语句。该技能与另一个技能同时被需要时的组合语句。每次修改技能描述后跑一遍评测集比较工具选择准确率和编排成功率。这一步听起来繁琐但它是维持技能网络长期稳定最值得投入的工作。8.6 从单 Agent 到多 Agent技能网络是协作基础在多智能体架构里技能网络还能进一步延伸。一个 Agent 可以把另一个 Agent 当作技能来调用。这在 EvoAgentX 这类多智能体讨论中是一个很常见的思路Agent 的技能网络不仅包含工具技能还包含协作技能。当一个 Agent 发现自己的技能不足以完成用户请求时它可以检索到另一个 Agent 的元数据并把任务派发过去。这会要求技能注册中心额外支持“人群路由”——按 Agent 分类、按租户隔离、按权限过滤。但底层的注册、检索、调用机制并没有改变。如果你计划做多 Agent 系统建议先在单体 Agent 上把技能网络这四个机制做扎实再谈 Agent 间的技能互调。9. 总结与后续学习方向SkillNet 这个话题放到今天看已经不只是架构师应该关心的东西而是每个做 AI Agent 的开发者迟早要面对的工程问题。把技能当成网络节点来治理用标准元数据注册、用检索缩小决策空间、用编排计划组织调用链这套方法可以让 Agent 的技能规模从“十几个”提升到“上百个甚至更多”同时保持可控的调用准确率。从 EvoAgentX Talk 的视角来看“技能网络”更像是一种务实的工程共识不追求模型在开放式规划上一口气处理几十个工具而是用工程手段把技能的复杂度降下来让模型每次只面对一个小而准确的决策。如果你想接着深入建议按这个顺序学习把本文的最小示例跑通搞清楚注册、检索、调用三个环节。把检索从关键词换成 Embedding 向量检索做一个带本地知识库的技能候选召回。给编排器增加一个可视化执行计划查看器观察技能链路的每一步输入输出。用 pytest 为每个技能和编排器建立回归测试把评测集和 CI 接起来。调研 Spring AI 或 LangChain 里的 Tool 机制看它和你自己实现的技能网络在设计上的异同。AI Agent 的发展方向大概率不会是“一个模型统治一切”而是“模型负责判断技能网络负责规模化”。对开发者来说现在开始积累技能注册、检索、编排、调用的工程经验正是投入产出比很高的时间点。建议收藏这篇文章下一步就是找一个你业务里最常被 Agent 调用的工具按第 5 节的 JSON 配置模板登记成第一个技能然后跑通一条包含两个技能的编排链路。先把最小闭环做出来后面的一切都好说。