这次的直播主题很有实操性现场 vibe coding从 0 打造一个智能体的技能集市。不是讲概念而是直接敲代码、跑功能、看效果。如果你正在用 AI 搭建自己的智能体应用或者想给智能体加一套可扩展的“技能插件体系”这篇内容值得看完。先拆解一下关键词vibe coding 是指用自然语言驱动 AI 编译器逐步生成代码人在循环里做架构决策和验收技能集市则是一套让智能体能力可注册、可检索、可调用、可管理的基础设施。两者结合直播会演示如何在几个小时内完成一个最小可运行的技能集市并把它接入智能体。这篇文章会围绕“直播会讲什么”展开整理成一套可以直接照着做的技术路线整体架构、环境准备、核心模块代码、API 调用与批量测试、性能观察、常见问题排查和工程化建议。即使不看直播按这套路线也能搭出原型。1. 核心能力速览能力项说明活动主题现场 vibe coding从 0 打造一个智能体的技能集市核心技术方向AI 辅助编码、智能体技能编排、技能注册与调用、API 服务设计现场产出一套最小可行的智能体技能集市原型适用人群想学习 AI Agent 落地、技能插件化、vibe coding 实战的开发者形态建议先跑通单机版再做 API 化与批量任务环境依赖Python 环境、LLM API 配置、FastAPI 等 Web 框架、Git直播信息以官方预告为准建议提前注册并准备本地开发环境核心思路是不要把智能体能力写死在代码里而是抽象成“技能包”。每个技能包含元信息、输入输出定义和执行函数。智能体收到用户指令后先做意图识别再去技能集市里找到合适技能最后调用执行。这套模式的好处是扩展性强新增能力不需要改主流程只需要注册新技能。2. vibe coding 与智能体技能集市的概念拆解2.1 vibe coding 到底是什么vibe coding 的核心不是“不写代码”而是用自然语言描述需求把重复性编码工作交给 AI 补全。开发者的角色从“逐行写实现”变成“定义目标和验收标准”。在直播场景里这种方式非常高效一段文字描述AI 可以生成接口定义、服务骨架、测试用例然后开发者在关键节点上检查、修改、继续推进。用 vibe coding 搭建技能集市比较适合的原因是需求边界足够清晰。技能集市本质是一套 CRUD 加路由系统注册技能、列出技能、调用技能、记录调用日志。这些结构清晰、重复度高、样板代码多的模块正好是 AI 生成代码最擅长的部分。开发者可以把精力放在架构决策和业务边界上。2.2 什么是智能体的技能集市技能集市不是“很多个 Agent 的集合”而是“Agent 所有可执行能力的统一管理市场”。每个技能都是可复用的功能单元。比如一个智能体需要查天气、画图、读文档、调数据库就可以把查天气、画图、读文档、调数据库分别封装成技能。技能集市负责这些能力的注册、发现、调用和治理。这与直接写 if-else 分支的主要区别在于技能是数据化的可以动态注册不重新发版。技能有统一接口接入第三方能力时更规范。技能之间可以组合形成复杂工作流。技能集市天然适合多人协作和生态共享。直播现场会演示一个典型的场景智能体收到“帮我把订单数据生成一张汇总表”这样的指令先识别出“生成汇总表”是一个技能然后从技能集市中找到对应实现带参数调用最后把结果返回给用户。2.3 技能集市的价值边界不是所有场景都需要技能集市。如果智能体只有两三个固定能力直接写函数调用更省事。一旦能力数量超过一定程度或者需要外部团队贡献技能或者需要做权限控制和调用计费这时候技能集市的优势才能体现。直播中强调“从 0 打造”关键是让观众看到最小实现。不需要引入复杂的微服务框架一个 Web 服务加一个注册表就能起步。理解最小闭环再决定如何扩展。3. 从 0 搭建技能集市的整体架构完整技能集市可以拆成五个核心部分。3.1 技能定义层这是所有技能的统一契约。一个技能由以下信息描述技能 ID唯一标识。技能名称与描述帮助 AI 做意图匹配。输入参数 Schema调用时的参数约束。执行函数实际业务逻辑。权限要求是否需要特定角色或额外授权。版本号便于更新和回滚。从工程上看技能定义就是“元信息 可调用对象”的组合。定义格式越规范后续的意图识别和参数校验就越简单。3.2 技能注册中心注册中心负责管理技能列表提供注册、查询、更新、下架能力。现场会用内存存储启动简化构建过程。生产环境可以替换为数据库或 Redis核心接口不用变。注册时要做的基础校验包括ID 是否重复、必填字段是否完整、执行函数是否存在、参数 Schema 是否合法。这些校验逻辑简单但能让整个系统稳定很多。3.3 技能执行器执行器是技能集市的中枢。它接收调用请求找到技能校验参数执行函数统一返回结果。执行器要做好异常捕获避免一个技能报错导致整个服务崩溃。执行器还应该记录调用日志包括调用方、技能 ID、入参、出参、耗时、状态码。这些日志是后续排查问题、统计使用量、做计费的基础。3.4 智能体编排层编排层是智能体与技能集市的桥梁。智能体拿到用户指令后把指令传给 LLM让 LLM 返回“应该调用哪个技能、参数是什么”再请求技能执行器完成实际调用。这里有两种路由方式纯函数式路由用关键词匹配技能名称和描述适合技能少、意图明确的场景。LLM 路由依赖大模型理解用户意图适合技能多、表达灵活的复杂场景。直播现场更推荐先做纯函数式路由再切换成 LLM 路由对比效果。这样既能展示原理又能说明如何在真实系统中演进。3.5 Web UI 与 API 网关最后需要一层对外入口。Web UI 用来直观展示技能列表、技能详情和调用记录。API 网关则负责统一接收外部请求做身份校验和限流。现场为节省时间可以把这两部分合并到一个 FastAPI 项目里同时提供 HTML 页面和 JSON 接口。整体调用链路可以用一段伪代码描述# 技能集市调用链路的伪代码 user_input 帮我把订单数据生成一张汇总表 intent route_intent(user_input) # 意图识别返回技能ID skill registry.get(intent[skill_id]) # 从注册中心获取技能 result executor.invoke(skill, intent[params]) # 执行技能 return format_response(result) # 统一返回格式不要把这套架构想得太重。从代码量来看核心模块在数百行到一千行左右就能完成适合现场演示也适合作为内部工具继续演化。4. 环境准备与前置条件4.1 通用开发环境清单在直播开始前先准备好以下环境可以减少现场排错时间。检查项建议要求说明操作系统Windows / macOS / Linux均支持推荐 macOS 或 LinuxPython需要支持 FastAPI 的版本建议使用当前稳定版本包管理pip / uv / poetry任选一个即可Web 框架FastAPI轻量、自带 API 文档、适合 AI 项目LLM API按实际项目配置需要准备好 API Key并注意密钥保管代码仓库Git方便保存和回放实现过程辅助工具Postman 或 curl用于接口调用测试现场代码会尽量少依赖额外服务优先使用内存数据结构和 SQLite保证任何人都能快速运行。4.2 初始化项目结构建议项目目录按模块拆分skill-market/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── registry.py # 技能注册中心 │ ├── executor.py # 技能执行器 │ ├── router.py # 意图路由 │ ├── skills/ │ │ ├── order_report.py # 示例技能 │ │ └── ... │ └── models.py # 数据模型 ├── tests/ │ └── test_market.py # 基础测试 ├── requirements.txt └── README.md把不同模块拆开即使后面扩展成真实项目也不需要推翻重写。4.3 注意事项不要在生产环境使用硬编码的 API Key。LLM API 调用需要设置超时时间和重试策略。第一次跑通时先不要接太多技能两个示例技能足够验证链路。端口建议选择一个不常用的避免和本地其他服务冲突。5. 现场实战路线与代码实现直播的节奏会按照“最小系统推进”的顺序走每个阶段都有可运行结果。5.1 第一步定义技能 Schema统一技能定义是整套系统的基础。用 Pydantic 模型管理数据校验比较方便也可以直接用 dataclass。# app/models.py from enum import Enum from typing import Any, Callable, Dict, Optional from pydantic import BaseModel, Field class SkillStatus(str, Enum): ACTIVE active DISABLED disabled class Skill(BaseModel): skill_id: str Field(..., description技能唯一标识) name: str Field(..., description技能名称) description: str Field(..., description技能描述用于意图匹配) parameters: Dict[str, Any] Field( default_factorydict, description参数 Schema ) version: str Field(default0.1.0, description技能版本号) status: SkillStatus SkillStatus.ACTIVE这样定义后每次注册技能都需要提供结构化信息后续交互和校验都有据可依。这里刻意保持简单方便现场演示时让观众快速理解。5.2 第二步实现技能注册中心注册中心主要维护两个数据结构技能列表和技能索引。索引可以用技能名称和描述分词建关键词表用来做基础意图匹配。# app/registry.py from typing import Dict, List, Optional from app.models import Skill, SkillStatus class SkillRegistry: def __init__(self) - None: self._skills: Dict[str, Skill] {} self._executors: Dict[str, callable] {} def register( self, skill: Skill, executor: callable, ) - Skill: if skill.skill_id in self._skills: raise ValueError(fskill {skill.skill_id} already exists) self._skills[skill.skill_id] skill self._executors[skill.skill_id] executor return skill def get(self, skill_id: str) - Skill: skill self._skills.get(skill_id) if skill is None: raise KeyError(fskill {skill_id} not found) return skill def get_executor(self, skill_id: str) - callable: if skill_id not in self._executors: raise KeyError(fexecutor for {skill_id} not found) return self._executors[skill_id] def list_skills(self) - List[Skill]: return [s for s in self._skills.values() if s.status SkillStatus.ACTIVE] def disable(self, skill_id: str) - None: self._skills[skill_id].status SkillStatus.DISABLED注册中心保证了技能的动态性。新增技能时只需要调用 register 方法不需要改动主程序逻辑。这是技能集市最核心的使用体验。5.3 第三步编写技能执行器执行器负责技能调用前的参数校验和执行。# app/executor.py import time import traceback from typing import Any, Dict from app.models import Skill from app.registry import SkillRegistry class Executor: def __init__(self, registry: SkillRegistry) - None: self._registry registry self._logs [] def invoke( self, skill_id: str, params: Dict[str, Any], caller: str unknown, ) - Dict[str, Any]: start time.time() skill self._registry.get(skill_id) executor self._registry.get_executor(skill_id) try: result executor(params) status success except Exception as exc: result { error: str(exc), traceback: traceback.format_exc(), } status failed finally: cost time.time() - start log_item { skill_id: skill_id, caller: caller, params: params, status: status, cost_ms: round(cost * 1000, 2), } self._logs.append(log_item) return { skill_id: skill_id, status: status, result: result, cost_ms: round((time.time() - start) * 1000, 2), log_id: len(self._logs) - 1, }执行器必须做到“技能隔离”一个技能报错不能影响其他技能。把异常转换成结构化结果是非常实用的工程习惯现场也会重点强调这一点。5.4 第四步用 LLM 做意图路由在跳过节的前提下先提供两种路由实现。第一种是关键词和规则路由适合技能少、调用模板固定的场景。# app/router.py from typing import Dict, Any from app.registry import SkillRegistry class RuleRouter: def __init__(self, registry: SkillRegistry) - None: self._registry registry def route(self, user_input: str) - Dict[str, Any]: for skill in self._registry.list_skills(): keywords skill.description.split() if any(kw in user_input for kw in keywords): return { skill_id: skill.skill_id, params: self._extract_params(user_input), } raise ValueError(no skill matched)第二种是 LLM 路由。把技能列表发送给 LLM要求它输出技能 ID 和参数 JSON。这样可以处理更自然更复杂的表达但会增加一次模型调用延迟和 token 开销。在实际项目中建议优先使用规则路由做兜底LLM 路由作为增强入口。直播现场会演示“同一条指令在两种路由下的表现差异”帮助理解两者适用条件。5.5 第五步注册示例技能为了验证完整链路现场会写两个示例技能。比如“生成订单汇总”和“生成问候语”。# app/skills/order_report.py import random from typing import Any, Dict def generate_order_report(params: Dict[str, Any]) - Dict[str, Any]: date params.get(date, 2025-01-01) orders [ {id: 1001, amount: 100.0}, {id: 1002, amount: 200.0}, ] total_amount sum(item[amount] for item in orders) return { date: date, order_count: len(orders), total_amount: total_amount, orders: orders, }在 main.py 中把这些技能注册进去。现场建议“先注册到内存再通过 API 查看列表”。# app/main.py from fastapi import FastAPI from app.registry import SkillRegistry from app.executor import Executor from app.models import Skill from app.skills.order_report import generate_order_report app FastAPI(titleSkill Market) registry SkillRegistry() executor Executor(registry) registry.register( Skill( skill_idorder_report, name生成订单汇总, description订单 汇总 报表, ), executorgenerate_order_report, ) app.get(/api/skills) def list_skills(): skills registry.list_skills() return {items: [s.dict() for s in skills]} app.post(/api/skills/invoke) def invoke_skill(payload: dict): skill_id payload[skill_id] params payload.get(params, {}) caller payload.get(caller, anonymous) return executor.invoke(skill_id, params, caller)到这里一个最小可用的技能集市已经跑通有注册中心、有执行器、有 API 入口。后续可以继续加 Web UI、数据库和更复杂的路由逻辑。5.6 第六步用 WebUI 展示技能集市现场会用一个简单 HTML 页面展示技能列表和调用状态。主要页面包含三个部分技能列表展示所有已注册技能的名称、描述和状态。技能调用表单选择技能并输入参数。调用日志列出最近调用记录和耗时。这一步的目的是把 API 能力可视化方便演示也方便在直播中让观众直观看到技能集市的效果。6. 接口 API 与批量任务6.1 接口能力说明标题中的“智能体技能集市”意味着外部智能体需要以接口方式调用技能。因此 API 设计要遵循统一规范。接口方法用途/api/skillsGET获取技能列表/api/skills/registerPOST注册新技能/api/skills/{skill_id}GET获取技能详情/api/skills/{skill_id}/disablePOST下架技能/api/skills/invokePOST执行技能/api/logsGET查看调用日志统一使用 JSON 请求和响应便于不同语言接入。6.2 API 调用示例以调用“生成订单汇总”技能为例import requests url http://127.0.0.1:8000/api/skills/invoke payload { skill_id: order_report, params: {date: 2025-06-01}, caller: test-agent, } response requests.post(url, jsonpayload, timeout30) print(response.status_code) print(response.json())预期返回结果是一个包含 skill_id、status、result 和 cost_ms 的 JSON。把接口跑通以后就可以把这个技能集市接进任何支持 HTTP 调用的智能体或自动化流程中。6.3 批量任务设计技能集市的价值在批量场景更能体现。批量任务可以简化成“循环调用接口 收集结果 写入文件”三步。# 批量调用示例 import json import time import requests results [] payloads [ {skill_id: order_report, params: {date: 2025-06-01}}, {skill_id: order_report, params: {date: 2025-06-02}}, {skill_id: order_report, params: {date: 2025-06-03}}, ] for item in payloads: try: resp requests.post( http://127.0.0.1:8000/api/skills/invoke, jsonitem, timeout30, ) resp.raise_for_status() results.append(resp.json()) except requests.RequestException as exc: results.append({payload: item, error: str(exc)}) time.sleep(0.2) with open(batch_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)批量执行时需要注意几个点控制并发数避免瞬间打爆本地服务。记录每个任务的入参和状态失败时能够重放。调用间隔不要太短尤其涉及第三方 API 时要注意限流要求。建议在本地工程里增加“失败重试不超过 3 次退避间隔 1 秒”的策略。实际生产环境可以用任务队列替代简单循环但核心思路一致任务可追踪、可重试、可统计。7. 资源占用与性能观察技能集市是一个轻量服务在没有额外 GPU 依赖的情况下资源占用主要来自 Web 服务和 LLM API 调用。不需要像大模型本地推理那样关注显存重点观察四个方面。7.1 API 响应耗时调用单个技能时耗时主要来自Web 框架处理请求的时间。技能执行逻辑本身。LLM 路由时的模型推理时间。网络 IO 和第三方服务调用。生产环境建议给所有技能接口加上耗时统计并输出到日志。现场会直接用 cProfile 或简单 time 模块演示如何定位耗时热点。7.2 LLM token 消耗如果采用了 LLM 路由每一条用户指令都会转换成一到两次大模型调用。这会带来 token 费用和延迟。优化的思路有几种只发送必要技能元信息不发送完整执行代码。按技能名称和描述做一次本地预筛减少送入 LLM 的技能数量。对常见指令做缓存直接映射到固定技能。对低风险请求使用更小的模型。从成本出发规则路由永远是第一道关卡。现场会用同一个指令对比“规则路由”和“LLM 路由”的耗时和消耗。7.3 技能冷启动与并发如果技能执行函数内部需要加载模型或初始化连接池第一次调用的耗时通常会明显高于后续调用。生产环境要做好初始化预热。并发方面本地简单实现可以跑小规模测试但如果要支撑多智能体并发调用需要在执行器外层加并发控制避免资源竞争。观察项观察方式判断标准单技能调用耗时看日志中 cost_ms稳定且符合业务预期批量任务成功率统计调用日志失败重试后可恢复LLM 路由额外延迟对比规则路由根据业务可接受范围判断并发冲突同时发起多个调用无参数串号和执行报错8. 常见问题与排查方法现场 coding 过程中最容易出现的问题集中在依赖、接口、路由和并发这几类。提前熟悉排查思路可以少走弯路。问题现象可能原因排查方式解决方案FastAPI 服务无法启动端口被占用检查端口监听情况更换端口或释放占用进程技能注册时报 ID 重复注册中心已有同 ID 技能查看技能列表修改 ID 或先更新旧技能技能调用返回 KeyError技能 ID 不存在或已下架检查调用参数和注册列表确认 skill_id 后重试LLM 路由超时网络延迟或模型响应慢看调用超时配置增加超时时间、使用规则路由兜底批量任务部分失败第三方 API 限流或本地超时查看返回状态和错误信息增加退避重试控制并发参数校验失败请求参数不符合技能 Schema查看报错字段按 Schema 调整参数类型技能执行抛异常内部逻辑错误或依赖缺失查看 traceback修复技能实现或安装依赖日志数据量增长过快无保留策略查看日志表或内存占用增加清理策略或保存到数据库排查时要遵循“先看日志再改代码”的原则。技能集市这类系统的问题大多能通过调用日志快速定位没必要直接翻源码。9. 最佳实践与使用建议9.1 工程化建议真实使用技能集市不能只停留在“能跑”的程度。建议从以下角度持续优化技能定义要有版本管理升级技能时保留旧版本可回滚。注册中心必须加权限校验不是任何人都能注册技能。执行器要支持超时控制防止技能长时间挂起耗尽资源。调用日志要保存足够长时间便于审计和排错。使用数据库或 Redis 替代内存注册中心支持服务重启后技能不丢失。增加健康检查和启动预热让服务状态可观测。9.2 合规与安全边界技能集市涉及智能体能力开放必须注意以下边界技能市场中的技能来源需要审核不运行来源不明或恶意代码。涉及用户数据、图片、声音、人脸等敏感信息时必须先获得合法授权。不要在技能配置中硬编码 API Key、数据库密码等敏感凭据。如果技能集市对外提供服务要限制访问范围并做好身份认证。批量任务处理个人数据时严格遵循最小必要原则。基于 LLM 生成的内容发布前应该增加人工复核机制。技能集市本质上是一个“能力分发平台”一旦开放注册它就和所有开放平台一样需要治理能力。技术演示可以简单生产化则必须补上权限、审计和合规机制。9.3 直播观看建议建议在直播开始前先完成本地 Python 和 Git 环境准备并准备好 LLM API Key。直播中跟随实现时不要追求代码一模一样而是重点理解每一步在解决什么问题。如果卡在环境安装上可以先把代码结构看懂后面再补跑。直播过程中最好准备一个笔记本记录架构图把“注册中心、执行器、路由、API 网关”四个模块之间的关系画清楚。这套架构思路比具体代码更值得沉淀。10. 总结与下一步这次直播的核心看点是用 vibe coding 的方式把一个技能集市的最小系统完整跑通。从技能 Schema 定义到注册中心从执行器到意图路由从 API 到批量任务完整链路足够覆盖日常开发中的大部分智能体能力管理需求。建议先重点验证三个点第一技能注册后能否通过接口动态发现第二执行器能否隔离单技能异常第三批量任务是否可重放、可追踪。这三个点跑通技能集市的底座就稳了。最容易踩的坑是路由设计。如果一开始就让 LLM 直接处理所有意图会遇到额外的 token 开销和响应延迟结合规则路由做预筛会更稳。另外技能执行时的参数校验不要跳过否则大量问题会在调用层逐步累积。下一步可以按自己的业务扩展开来给技能集市加上数据库持久化补充技能分组和权限模型把调用日志接进监控系统再逐步开放给更多智能体或团队使用。这套从 0 打造的结构适合做内部工具也适合作为进一步商业化能力分发平台的基础。建议收藏备用直播开始前把环境准备好到时可以直接跟着动手跑代码。