1. 项目概述当AI Agent需要“家”和“技能库”最近和几个做AI应用的朋友聊天大家不约而同地提到了同一个痛点Agent智能体的“生存环境”太脆弱了。你花大力气基于某个大模型LLM调教出一个能写周报、能查数据的Agent部署到云端跑得好好的。结果模型服务商那边一个接口升级或者你的云服务器资源波动一下这个Agent可能就“宕机”了或者表现变得不可预测。更麻烦的是你好不容易让这个Agent学会了处理Excel表格我们称之为一个“技能”当你想在另一个分析财报的Agent里复用这个技能时却发现要重新写一遍逻辑或者做复杂的集成效率极低。这就像你养了一群各有所长的“数字员工”但他们既没有稳定的办公场所运行环境说崩就崩也没有一个共享的技能培训中心能力无法沉淀和复用。整个开发过程陷入了“重复造轮子”和“运维救火”的循环。而Lighthouse与SkillHub这个组合瞄准的正是这两个核心问题。简单来说你可以把Lighthouse理解为AI Agent在云端的“灯塔”与“稳定器”它负责为Agent提供高可用、可观测、易扩展的运行底座而SkillHub则是Agent的“技能中枢”或“工具库”它致力于将各种AI能力无论是调用一个API、执行一段代码还是串联多个步骤标准化、模块化并实现跨Agent的安全流转与共享。这不是某个单一产品的名字而是一种架构理念和解决方案的指代。它的核心价值在于将AI Agent的开发从“手工作坊”式的一次性项目升级为“工业化”的可持续工程。开发者不再需要过分关心底层基础设施的稳定性也能像搭积木一样快速组合和复用已有的AI能力构建更复杂、更可靠的智能应用。2. 架构深潜Lighthouse如何照亮Agent的云端航路2.1 Lighthouse的核心职责超越简单的“服务器”很多人第一眼看到“运行底座”会下意识地想到虚拟机、容器Docker或者KubernetesK8s。没错这些是基石但Lighthouse的概念远不止于此。它是在这些基础设施之上为AI Agent量身定制的一整套“生存保障系统”。2.1.1 稳定性保障给Agent穿上“救生衣”AI Agent的核心是LLM的调用而当前LLM服务无论是OpenAI、Anthropic还是开源模型都存在不可控因素网络延迟、服务限流、令牌Token消耗、突发错误等。一个纯朴素的Agent直接调用API遇到429请求过多错误可能就直接失败了。 Lighthouse在这里扮演了“智能网关”和“韧性层”的角色。它会实现自动重试与回退当主用模型API调用失败时能按照预设策略如间隔递增重试自动重试或在某些可降级的场景下自动切换到备用模型如从GPT-4回退到GPT-3.5-Turbo。请求排队与限流针对有并发限制的APILighthouse可以管理请求队列平滑流量避免触发服务商的限制。上下文管理优化Agent的对话往往需要维护很长的上下文Context。Lighthouse可以智能地管理上下文窗口例如通过摘要Summarization或关键信息提取在Token数接近上限时压缩历史记录而非粗暴地截断从而在成本与效果间取得平衡。2.1.2 可观测性给Agent安装“黑匣子”与“仪表盘”Agent的运行过程是个黑盒在Lighthouse架构下这不应该发生。完备的可观测性是其关键特性。链路追踪Tracing记录一次用户查询从进入Agent到调用LLM、执行工具Skill、访问数据库的完整链路。每个步骤的耗时、输入输出、Token消耗都清晰可见。这对于调试复杂Agent的逻辑流至关重要。指标监控Metrics定义并收集关键指标如Agent每日调用次数、平均响应延迟、各技能Skill调用成功率、Token消耗成本趋势等。这些指标可以通过Grafana等工具可视化成为运维和成本核算的依据。日志聚合Logging将所有组件的结构化日志集中收集例如使用ELK栈或Loki方便问题排查。特别是LLM的提示词Prompt和补全Completion内容在脱敏后应被安全地记录用于后续的效果分析和优化。2.1.3 部署与扩展让Agent“弹性伸缩”基于容器化技术如DockerLighthouse可以提供一键部署、蓝绿发布、金丝雀发布等现代软件部署能力。当Agent流量激增时可以基于CPU、内存或自定义指标如请求队列长度自动水平扩展Auto-scaling实例数量流量低谷时自动缩容以节省成本。这确保了服务在面对不同负载时的可用性与经济性。实操心得在搭建Lighthouse层时不要试图从头造轮子。可以基于成熟的云原生技术栈组合。例如使用FastAPI或LangChain的Serve框架作为Agent服务框架用Prometheus收集指标Jaeger做分布式追踪Kubernetes做编排和弹性伸缩。关键是将针对LLM调用的特性如Token计数、提示词模板管理封装成中间件或Sidecar组件融入到这套体系中。2.2 SkillHub的核心设计技能即资产流通即价值如果说Lighthouse解决了Agent“活下来”和“被看清”的问题那么SkillHub解决的就是Agent“如何变得更强大”和“如何协作”的问题。其核心思想是“技能Skill”的抽象、封装、存储与调度。2.2.1 技能的标准化定义一个Skill本质上是一个可独立执行、具有明确输入输出规范的AI能力单元。它可以很简单比如“获取当前天气”也可以很复杂比如“分析一份财报PDF并提取关键财务指标”。SkillHub需要定义一套统一的描述标准类似OpenAPI Specification至少包括技能名称Name与唯一标识ID功能描述Description自然语言描述用于让LLM理解何时调用该技能。输入参数Input Schema定义参数名称、类型、是否必填、描述。例如天气查询技能需要city字符串和date可选日期参数。输出格式Output Schema定义返回数据的结构。执行端点Endpoint实现该技能的后端服务地址或函数调用入口。安全与权限Security Permissions调用该技能所需的认证方式如API Key以及数据访问权限。2.2.2 技能的动态发现与编排SkillHub作为一个中心化的注册表Registry存储所有注册的技能元数据。当一个Agent尤其是基于LLM的“大脑”需要完成复杂任务时它不必硬编码所有能力。流程可以是任务规划Agent的“大脑”LLM根据用户目标规划出需要执行的步骤序列。技能发现Agent向SkillHub查询根据当前步骤的描述匹配最相关的可用技能列表。SkillHub可以提供基于描述的语义搜索能力。技能调用Agent获得匹配的技能调用规范包括Endpoint和参数格式然后通过Lighthouse的稳定通道去执行调用。结果整合将技能执行结果返回给Agent的“大脑”用于后续决策或生成最终回答。这个过程实现了技能的“松耦合”。开发新Agent时开发者可以像在应用商店挑选App一样从SkillHub中选取所需技能进行组装极大提升开发效率。2.2.3 技能的安全流转与版本管理技能可能涉及敏感操作如发送邮件、操作数据库或私有数据。SkillHub必须提供细粒度的权限控制RBAC确保只有被授权的Agent或个人才能调用特定技能。同时技能本身也需要版本化管理当技能实现更新时可以平滑升级并允许Agent按需选择特定版本避免兼容性问题。3. 实战构建从零搭建一个微型Lighthouse SkillHub体系理论说得再多不如动手搭一个最小可行系统MVP来得实在。下面我将以一个“智能数据分析助手”Agent为例展示如何构建核心环节。3.1 环境准备与基础框架选择我们选择Python生态因为它拥有最丰富的AI和Web开发库。3.1.1 核心依赖# 基础框架与Agent开发 pip install fastapi uvicorn # 高性能Web框架用于构建API服务 pip install langchain langchain-community # Agent开发框架提供基础编排能力 pip install openai # 假设使用OpenAI LLM # 可观测性 pip install opentelemetry-api opentelemetry-sdk opentelemetry-instrumentation-fastapi opentelemetry-exporter-jaeger # 分布式追踪 pip install prometheus-client # 指标暴露 # 技能管理简易实现 pip install pydantic # 数据验证用于定义技能Schema3.1.2 项目结构ai-agent-platform/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI应用入口集成Lighthouse功能 │ ├── agents/ # 具体Agent实现 │ │ └── data_analyst_agent.py │ ├── skills/ # 技能实现与注册中心 │ │ ├── registry.py # 技能注册表 │ │ ├── weather.py # 示例技能天气查询 │ │ └── calculator.py # 示例技能计算器 │ └── lighthouse/ # Lighthouse核心模块 │ ├── middleware.py # 稳定性中间件重试、限流 │ ├── telemetry.py # 可观测性追踪、指标 │ └── llm_client.py # 封装的稳健LLM客户端 └── requirements.txt3.2 实现核心模块Lighthouse的稳定性与可观测层3.2.1 稳健的LLM客户端 (llm_client.py)这是Lighthouse理念最直接的体现。我们不直接使用openai.ChatCompletion.create而是将其包装起来。import logging import time from typing import Any, Dict, Optional import openai from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type logger logging.getLogger(__name__) class RobustLLMClient: def __init__(self, api_key: str, model: str gpt-3.5-turbo, max_retries: int 3): openai.api_key api_key self.model model self.max_retries max_retries # 使用tenacity库实现智能重试 retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10), retryretry_if_exception_type((openai.error.APIConnectionError, openai.error.RateLimitError)), before_sleeplambda retry_state: logger.warning(fLLM调用失败正在重试第{retry_state.attempt_number}次: {retry_state.outcome.exception()}) ) def chat_completion_with_retry(self, messages: list, **kwargs) - Dict[str, Any]: 带重试和降级机制的LLM调用 try: response openai.ChatCompletion.create( modelself.model, messagesmessages, **kwargs ) # 记录Token使用情况重要成本指标 usage response.get(usage, {}) logger.info(fLLM调用成功消耗Token: {usage}) # 这里可以将usage信息发送到Prometheus指标 return response except openai.error.InvalidRequestError as e: # 例如Token超限这是非重试错误需要特殊处理 logger.error(f无效请求错误如上下文超长: {e}) # 可以在这里触发上下文压缩逻辑然后重试或者直接向上抛出 raise except Exception as e: logger.error(fLLM调用发生未预期错误: {e}) raise # 可以扩展更多方法如切换模型、流式响应处理等3.2.2 可观测性集成 (telemetry.py)集成OpenTelemetry来实现追踪和指标。from opentelemetry import trace from opentelemetry.exporter.jaeger.thrift import JaegerExporter from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor from opentelemetry.sdk.resources import Resource, SERVICE_NAME from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor import prometheus_client as prom from prometheus_client import Counter, Histogram # 初始化追踪 def setup_tracing(service_name: str ai-agent-platform): resource Resource(attributes{SERVICE_NAME: service_name}) tracer_provider TracerProvider(resourceresource) # 配置Jaeger导出器假设Jaeger运行在localhost:6831 jaeger_exporter JaegerExporter( agent_host_namelocalhost, agent_port6831, ) tracer_provider.add_span_processor(BatchSpanProcessor(jaeger_exporter)) trace.set_tracer_provider(tracer_provider) return trace.get_tracer(__name__) # 定义Prometheus指标 LLM_CALL_COUNT Counter(llm_calls_total, Total number of LLM calls, [model, status]) LLM_CALL_DURATION Histogram(llm_call_duration_seconds, Duration of LLM calls, [model]) SKILL_CALL_COUNT Counter(skill_calls_total, Total number of skill calls, [skill_name, status]) # 在LLM客户端和技能调用处埋点 def record_llm_call(model: str, duration: float, success: bool): LLM_CALL_COUNT.labels(modelmodel, statussuccess if success else failure).inc() LLM_CALL_DURATION.labels(modelmodel).observe(duration)3.3 实现SkillHub技能注册与发现中心3.3.1 技能定义与注册表 (skills/registry.py)这是SkillHub的核心一个内存中的技能注册中心生产环境可用数据库。from typing import Dict, List, Any, Callable, Optional from pydantic import BaseModel, Field class SkillParameter(BaseModel): name: str type: str # string, number, boolean, object description: str required: bool True class Skill(BaseModel): id: str name: str description: str input_schema: List[SkillParameter] output_schema: Dict[str, Any] # 简化表示可以是JSON Schema endpoint: Optional[str] None # HTTP端点 handler: Optional[Callable] None # 本地函数处理器 auth_required: bool False class SkillRegistry: def __init__(self): self._skills: Dict[str, Skill] {} def register(self, skill: Skill): if skill.id in self._skills: raise ValueError(fSkill with ID {skill.id} already registered.) self._skills[skill.id] skill print(fSkill registered: {skill.name} ({skill.id})) def get_skill(self, skill_id: str) - Optional[Skill]: return self._skills.get(skill_id) def search_skills(self, query: str) - List[Skill]: 简单的基于描述的关键词搜索生产环境可接入向量数据库进行语义搜索 query_lower query.lower() results [] for skill in self._skills.values(): if query_lower in skill.description.lower() or query_lower in skill.name.lower(): results.append(skill) return results def list_all(self) - List[Skill]: return list(self._skills.values()) # 全局注册表实例 registry SkillRegistry()3.3.2 实现几个示例技能 (skills/weather.py,skills/calculator.py)# skills/weather.py import requests from .registry import Skill, SkillParameter, registry def get_weather_handler(city: str, date: str None) - dict: 模拟天气查询实际应调用真实API # 示例模拟API调用 return { city: city, date: date or today, condition: Sunny, temperature: 25, unit: Celsius } # 定义并注册天气技能 weather_skill Skill( idskill_weather_v1, nameget_weather, descriptionGet the current or future weather information for a given city., input_schema[ SkillParameter(namecity, typestring, descriptionThe name of the city, requiredTrue), SkillParameter(namedate, typestring, descriptionThe date for the forecast (e.g., 2023-10-27), requiredFalse) ], output_schema{type: object, properties: { city: {type: string}, condition: {type: string}, temperature: {type: number} }}, handlerget_weather_handler ) registry.register(weather_skill)# skills/calculator.py from .registry import Skill, SkillParameter, registry def calculate_handler(expression: str) - dict: 安全地计算数学表达式使用eval需极度谨慎此处仅为示例 try: # 警告生产环境必须使用更安全的表达式求值库如 ast.literal_eval, numexpr # 并严格限制可用的操作符和函数。 result eval(expression, {__builtins__: None}, {}) return {expression: expression, result: result, status: success} except Exception as e: return {expression: expression, error: str(e), status: failure} calculator_skill Skill( idskill_calculator_v1, namecalculator, descriptionEvaluate a mathematical expression., input_schema[ SkillParameter(nameexpression, typestring, descriptionA mathematical expression, e.g., (35)*2, requiredTrue) ], output_schema{type: object, properties: { result: {type: number}, status: {type: string} }}, handlercalculate_handler ) registry.register(calculator_skill)3.4 组装智能体让Agent学会使用技能现在我们创建一个数据分析助手Agent它可以根据用户需求自动规划并使用技能。3.4.1 构建Agent (agents/data_analyst_agent.py)我们使用LangChain来快速构建一个基于ReAct模式的Agent。from langchain.agents import Tool, AgentExecutor, create_react_agent from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI from app.skills.registry import registry from app.lighthouse.llm_client import RobustLLMClient # 使用我们封装的客户端 import json class DataAnalystAgent: def __init__(self, llm_client: RobustLLMClient): self.llm_client llm_client # 将SkillHub中的技能转换为LangChain可用的Tool self.tools self._load_tools_from_registry() self.agent self._create_agent() def _load_tools_from_registry(self): tools [] for skill in registry.list_all(): # 为每个技能创建一个LangChain Tool对象 def make_tool_func(skill_obj): # 闭包捕获具体的skill对象 def skill_tool_func(input_str: str) - str: 工具函数解析输入并调用技能处理器 try: # 简单解析输入实际中应由Agent的LLM来生成结构化参数 # 这里简化处理假设输入是JSON字符串或单个参数 if skill_obj.handler: # 对于示例我们假设输入直接就是参数值如城市名 # 复杂情况需要更完善的参数解析 if skill_obj.id skill_weather_v1: result skill_obj.handler(cityinput_str) elif skill_obj.id skill_calculator_v1: result skill_obj.handler(expressioninput_str) else: result {error: Handler not implemented for this skill.} return json.dumps(result, ensure_asciiFalse) except Exception as e: return json.dumps({error: fSkill execution failed: {str(e)}}) return skill_tool_func tool Tool( nameskill.name, funcmake_tool_func(skill), descriptionskill.description, ) tools.append(tool) return tools def _create_agent(self): # 使用封装的LLM客户端初始化LangChain LLM需适配此处为概念展示 # 实际中可能需要一个适配层将RobustLLMClient包装成LangChain LLM接口 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 简化直接使用原版 prompt PromptTemplate.from_template( 你是一个数据分析助手。你可以使用以下工具 {tools} 用户问题{input} 请逐步思考Thought如果需要使用工具就使用工具Action并观察工具返回结果Observation。最终给出答案Final Answer。 Thought: {agent_scratchpad} ) agent create_react_agent(llm, self.tools, prompt) agent_executor AgentExecutor(agentagent, toolsself.tools, verboseTrue, handle_parsing_errorsTrue) return agent_executor def run(self, query: str) - str: 执行Agent # 在这里可以集成Lighthouse的追踪记录整个Agent执行链路 # with tracer.start_as_current_span(data_analyst_agent_run) as span: # span.set_attribute(user.query, query) result self.agent.invoke({input: query}) return result[output]3.4.2 创建FastAPI主应用并集成 (app/main.py)将一切串联起来提供HTTP API。from fastapi import FastAPI, HTTPException from contextlib import asynccontextmanager from .lighthouse.telemetry import setup_tracing, LLM_CALL_COUNT, SKILL_CALL_COUNT from .agents.data_analyst_agent import DataAnalystAgent from .lighthouse.llm_client import RobustLLMClient import os import prometheus_client as prom from fastapi.responses import PlainTextResponse # 生命周期管理 asynccontextmanager async def lifespan(app: FastAPI): # 启动时初始化追踪、注册技能等 setup_tracing(ai-agent-platform) # 导入技能模块以触发注册 from .skills import weather, calculator print(Skills registered:, [s.name for s in registry.list_all()]) yield # 关闭时清理资源 print(Shutting down) app FastAPI(lifespanlifespan) # 集成OpenTelemetry中间件需在创建app后 # FastAPIInstrumentor.instrument_app(app) # 初始化全局Agent生产环境应考虑依赖注入和单例 llm_client RobustLLMClient(api_keyos.getenv(OPENAI_API_KEY)) agent DataAnalystAgent(llm_client) app.get(/) def read_root(): return {message: AI Agent Platform (Lighthouse SkillHub) is running} app.post(/agent/query) def query_agent(user_query: str): 主要端点用户向智能体提问 if not user_query: raise HTTPException(status_code400, detailQuery cannot be empty) try: answer agent.run(user_query) return {query: user_query, answer: answer} except Exception as e: # 记录错误指标 raise HTTPException(status_code500, detailfAgent execution failed: {str(e)}) app.get(/skills) def list_skills(): 查看所有注册的技能 skills registry.list_all() return [{id: s.id, name: s.name, description: s.description} for s in skills] app.get(/metrics) def get_metrics(): Prometheus指标端点 return PlainTextResponse(prom.generate_latest())3.5 运行与测试启动服务export OPENAI_API_KEYyour-api-key uvicorn app.main:app --reload --host 0.0.0.0 --port 8000测试Agent访问http://localhost:8000/skills查看已注册技能。向http://localhost:8000/agent/query发送POST请求Body为{user_query: 请计算一下(1527)*3等于多少}。观察控制台输出Agent会展示其思考过程Thought, Action, Observation最终调用计算器技能并返回结果。查看指标访问http://localhost:8000/metrics可以看到Prometheus格式的指标数据可以配置Grafana进行可视化。4. 进阶探讨与避坑指南构建一个生产可用的Lighthouse SkillHub体系远不止一个MVP这么简单。以下是几个关键的进阶方向和实践中必然遇到的“坑”。4.1 技能编排的复杂性从“能调用”到“会调用”我们的MVP中Agent通过简单的描述匹配来调用技能。但在真实场景中挑战巨大参数映射LLM如何将用户模糊的自然语言指令精确解析成技能所需的严格结构化参数例如用户说“看看北京明天天气怎么样”Agent需要解析出city北京datetomorrow并转换为日期格式。这需要精心设计的提示词Prompt Engineering和潜在的输出解析Output Parser。技能选择歧义当多个技能描述相似时如“获取数据”可能对应数据库查询、API拉取、文件读取如何选择最合适的一个可能需要结合技能的历史调用成功率、延迟、以及当前对话的上下文进行排序。多技能编排复杂任务需要按顺序或并行调用多个技能。例如“帮我分析上个月销售额最高的三个产品的天气影响因素”需要先调用“销售数据查询”技能再对结果中的产品产地依次调用“天气查询”技能。这需要更强大的任务规划Planning与工作流Workflow引擎支持。避坑指南不要指望一个通用的LLM能完美解决所有编排问题。可以采用分层策略1) 设计严谨的技能描述和参数规范2) 使用少量示例Few-shot在提示词中教导LLM3) 对于极其复杂或关键的流程可以退而使用硬编码的工作流引擎如Apache Airflow、Prefect来编排技能LLM只负责触发这个预定义的工作流。4.2 Lighthouse的性能与成本权衡延迟累积Lighthouse的每一层重试、排队、追踪都会增加延迟。特别是当重试发生时用户感知的延迟会显著增加。需要设置合理的超时Timeout和重试策略对于实时性要求高的场景如对话可能需要对某些非关键步骤采用更激进的超时或异步处理。Token成本控制记录完整的Prompt和Completion用于追踪和调试是宝贵的但这本身消耗存储且如果涉及敏感信息还有安全风险。必须制定日志保留策略并对敏感信息如个人身份信息PII进行脱敏处理。同时监控Token消耗并设置预算告警是必须的。扩展性瓶颈虽然Kubernetes提供了容器扩展能力但Agent应用本身可能是有状态的维护对话上下文。简单的水平扩展会导致状态丢失。需要将会话状态Session State外置到如Redis这样的共享存储中确保任何Pod都能访问到同一用户的上下文。4.3 SkillHub的治理与安全技能版本化与兼容性当技能接口变更时如何保证已有的Agent不受影响必须实行严格的语义化版本管理SemVer。SkillHub应支持同时托管同一技能的多个版本Agent在注册或调用时需声明依赖的技能版本。权限与审计技能可能对应着删除数据库、发送邮件等高危操作。必须实现基于角色的访问控制RBAC。每个技能调用都应有详细的审计日志记录“谁”哪个Agent/用户在“什么时间”调用了“什么技能”并提供了“什么参数”。这对于安全溯源和合规性至关重要。技能发现的质量简单的关键词匹配无法满足复杂需求。成熟的SkillHub应集成向量数据库如Weaviate, Qdrant将技能描述和用户查询都转换为向量Embedding通过语义相似度搜索来发现技能准确率会高得多。4.4 测试与监控的独特性AI Agent的测试不同于传统软件。非确定性测试由于LLM输出的非确定性传统的断言Assert经常失败。需要采用基于评分Score或评估Evaluation的测试方法例如使用另一个LLM或一套规则来判断输出是否“合理”或“符合要求”。端到端流程测试需要模拟真实用户对话测试整个Agent从理解、规划、调用技能到生成回答的完整流程。这通常需要构建复杂的测试数据集和自动化测试框架。监控业务指标除了技术指标延迟、错误率更需要监控业务指标例如“用户意图识别准确率”、“技能调用准确率”、“任务完成率”。这些指标往往需要通过采样、人工标注或利用LLM-as-a-Judge的方式来计算。5. 总结与展望通往AI原生应用的基础设施构建Lighthouse与SkillHub本质上是在为AI Agent的规模化应用铺设“铁轨”和“电网”。它让开发者从繁琐的基础设施运维和重复的能力建设中解放出来更专注于Agent本身的行为设计、领域知识注入和用户体验优化。这个架构是开放的。Lighthouse可以集成更强大的流量调度、A/B测试、混沌工程能力。SkillHub可以发展出技能市场允许团队间甚至组织间共享和交易AI能力。最终它可能演变为企业内部的“AI能力中台”成为所有智能应用的统一底座。我个人的体会是在AI应用爆发的初期投入资源构建这样一套基础设施短期内看似乎增加了复杂度但长期来看它是避免技术债堆积、实现敏捷创新和稳定运营的必然选择。就像微服务架构普及前大家也在争论是否值得引入API网关和注册中心一样当你的AI智能体超过三个并且开始处理真实业务时一个稳固的底座和一个共享的技能库价值就会立刻凸显出来。最后一个小技巧在项目启动初期不必追求大而全。可以从一个最核心的Agent和两个最常用的技能开始先实现一个最小闭环的SkillHub哪怕只是一个共享的Python模块和注册字典和一个具备基本重试和日志的Lighthouse客户端。在此基础上随着业务复杂度的提升逐步迭代、抽象和强化各个模块。这样既能快速验证价值又能让架构的演进始终贴合实际需求。