企业官网建设流程全解析

这次的直播主题很有实操性：现场 vibe coding，从 0 打造一个智能体的技能集市。不是讲概念，而是直接敲代码、跑功能、看效果。如果你正在用 AI 搭建自己的智能体应用，或者想给智能体加一套可扩展的“技能插件体系”，这篇内容值得看完。

先拆解一下关键词：vibe coding 是指用自然语言驱动 AI 编译器逐步生成代码，人在循环里做架构决策和验收；技能集市则是一套让智能体能力可注册、可检索、可调用、可管理的基础设施。两者结合，直播会演示如何在几个小时内完成一个最小可运行的技能集市，并把它接入智能体。

这篇文章会围绕“直播会讲什么”展开，整理成一套可以直接照着做的技术路线：整体架构、环境准备、核心模块代码、API 调用与批量测试、性能观察、常见问题排查和工程化建议。即使不看直播，按这套路线也能搭出原型。

1. 核心能力速览

核心思路是：不要把智能体能力写死在代码里，而是抽象成“技能包”。每个技能包含元信息、输入输出定义和执行函数。智能体收到用户指令后，先做意图识别，再去技能集市里找到合适技能，最后调用执行。这套模式的好处是扩展性强，新增能力不需要改主流程，只需要注册新技能。

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 通用开发环境清单

在直播开始前，先准备好以下环境，可以减少现场排错时间。

现场代码会尽量少依赖额外服务，优先使用内存数据结构和 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_factory=dict, description="参数 Schema" ) version: str = Field(default="0.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(f"skill {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(f"skill {skill_id} not found") return skill def get_executor(self, skill_id: str) -> callable: if skill_id not in self._executors: raise KeyError(f"executor 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(title="Skill Market") registry = SkillRegistry() executor = Executor(registry) registry.register( Skill( skill_id="order_report", name="生成订单汇总", description="订单 汇总 报表", ), executor=generate_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 设计要遵循统一规范。

统一使用 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, json=payload, timeout=30) 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", json=item, timeout=30, ) 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", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

批量执行时需要注意几个点：

• 控制并发数，避免瞬间打爆本地服务。
• 记录每个任务的入参和状态，失败时能够重放。
• 调用间隔不要太短，尤其涉及第三方 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 技能冷启动与并发

如果技能执行函数内部需要加载模型或初始化连接池，第一次调用的耗时通常会明显高于后续调用。生产环境要做好初始化预热。并发方面，本地简单实现可以跑小规模测试，但如果要支撑多智能体并发调用，需要在执行器外层加并发控制，避免资源竞争。

8. 常见问题与排查方法

现场 coding 过程中，最容易出现的问题集中在依赖、接口、路由和并发这几类。提前熟悉排查思路，可以少走弯路。

排查时要遵循“先看日志，再改代码”的原则。技能集市这类系统的问题大多能通过调用日志快速定位，没必要直接翻源码。

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 打造的结构，适合做内部工具，也适合作为进一步商业化能力分发平台的基础。建议收藏备用，直播开始前把环境准备好，到时可以直接跟着动手跑代码。