企业官网建设流程全解析

1. 项目概述：一个被严重低估的“技能容器”概念

“agent-skills”这个词组最近在技术社区和开发者讨论中频繁闪现，但它既不是某个新发布的开源库名，也不是某家大厂刚推出的API服务，而是一个正在悄然成型的设计范式共识。我第一次在某次跨团队架构评审会上听到它，当时一位后端负责人指着白板上画的三层调用链说：“我们得把‘agent-skills’单独拎出来建模，否则每次加个新能力都要动核心调度器。”——那一刻我就意识到，这不是一个功能点，而是一套关于“能力如何被组织、发现、组合与复用”的底层思维框架。

简单说，“agent-skills”指的是赋予智能体（Agent）可插拔、可声明、可验证的具体能力单元。它不等于“函数”，因为函数没有上下文感知；也不等于“微服务”，因为微服务太重、启动太慢；更不等于“Prompt模板”，因为模板缺乏结构化输入输出契约。它介于三者之间：像函数一样轻量可调用，像微服务一样有明确接口定义，又像Prompt模板一样天然适配语言模型的语义理解边界。我在过去两年里参与过5个不同规模的Agent系统落地项目，从客服对话路由到自动化研发生态编排，凡是没提前设计好“skills”抽象层的，后期都卡在能力膨胀后的维护泥潭里——新增一个查天气的功能，结果要改调度逻辑、补日志埋点、加权限校验、更新文档，最后发现连测试用例都得重写。

这个概念之所以突然升温，根本原因在于LLM应用开发正从“单体Prompt工程”迈入“模块化能力组装”阶段。就像90年代Web刚兴起时，大家还在手写HTML页面，突然有人提出“组件化UI”概念，React还没诞生，但思想已经跑在了工具前面。“agent-skills”就是当前这个阶段最务实的破局点：它让非AI专家也能安全地贡献能力（比如前端同学写个调用地图API的skill），让AI工程师专注优化调度策略而非重复造轮子，也让产品同学能用自然语言描述“我希望Agent会做X、Y、Z三件事”，而不是盯着JSON Schema发呆。如果你正在设计一个需要持续迭代能力的Agent系统，或者正被“每次加功能都要重构核心”的问题困扰，那么“agent-skills”不是可选项，而是你技术选型的第一道分水岭。

2. 核心设计思路：为什么必须放弃“大一统函数库”？

2.1 传统方案的三大死结

在我经手的第一个Agent项目里，团队最初采用的是“中央函数库”模式：所有能力都塞进一个tools.py文件，用装饰器标记哪些函数可被Agent调用。初期确实快，三天就上线了查订单、改地址、查物流三个功能。但第四周开始，问题像多米诺骨牌一样倒下：

• 耦合爆炸：当产品经理提出“查订单时自动高亮超时订单”时，我们不得不修改get_order_status函数内部逻辑。而这个函数又被客服Agent和售后Agent同时依赖，一次修改引发两个线上流程异常；
• 测试失焦：单元测试覆盖率从85%掉到42%，因为每个函数都开始依赖数据库连接、外部API密钥、甚至临时文件路径，mock成本越来越高；
• 权限失控：财务部门要求“仅特定角色可调用退款接口”，但我们发现权限校验逻辑散落在7个函数里，且每个函数的参数结构都不一致，根本没法统一拦截。

后来我们做了根因分析，发现症结不在代码质量，而在抽象层级错位——把“能力”当成“工具函数”来管理，本质上是用过程式编程思维解决声明式问题。就像试图用Excel宏来管理企业ERP权限体系，再怎么封装也绕不开底层模型缺陷。

2.2 “agent-skills”范式的四层解耦逻辑

真正有效的“skills”设计，必须实现四个维度的硬性隔离。我在第三个落地项目中强制推行这套规范，后续新增32个能力模块，核心调度器代码零修改。其核心不是写更多代码，而是用更少的约束换更大的自由度：

1. 契约层（Contract Layer）
   每个skill必须提供机器可读的接口定义，格式为严格校验的JSON Schema。例如天气查询skill的输入schema长这样：

   { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，支持中文或拼音"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius"} }, "required": ["city"] }

   提示：这里不用OpenAPI是因为OpenAPI对LLM调用场景过于冗余；也不用Protobuf是因为需要人类可读性。JSON Schema是当前平衡机器解析与人工维护的最佳选择。

2. 执行层（Execution Layer）
   实际执行代码必须与契约完全解耦。我们规定所有skill执行函数签名统一为def execute(input_dict: dict) -> dict，输入输出都是纯字典，禁止任何全局变量、类实例或闭包状态。这样做的好处是：同一个skill可以无缝切换执行引擎——本地Python函数、HTTP微服务、甚至未来接入WASM沙箱，只要输入输出符合契约即可。

3. 元数据层（Metadata Layer）
   每个skill附带结构化元数据，包含name（机器标识）、display_name（用户可见名）、description（一句话功能说明）、tags（如["public", "finance", "high_risk"]）、cost_estimate（预估token消耗）。这些字段直接驱动Agent的决策逻辑，比如调度器看到"high_risk"标签就会自动触发二次确认流程。

4. 生命周期层（Lifecycle Layer）
   技能不是静态文件，而是有完整生命周期的对象。我们内置了register()、deactivate()、rollback_to_version()等方法。最实用的是dry_run()——在真实执行前先模拟调用，返回预期输出结构和潜在风险提示（如“将访问用户隐私数据，需获得显式授权”）。这解决了LLM应用最大的信任难题：让用户知道Agent准备做什么，而不是盲目等待结果。

2.3 为什么拒绝“AI原生函数即服务”（AI-FaaS）？

当前有些团队尝试用Serverless函数直接暴露skill，看似先进实则埋雷。我实测过AWS Lambda+Bedrock的组合，在QPS>50时出现三类不可控问题：

• 冷启动延迟突变：平均响应200ms，但10%请求飙升至2.3秒，导致Agent对话流卡顿，用户感知极差；
• 错误传播失真：Lambda抛出ConnectionTimeout异常，但LLM接收到的却是“我无法完成该请求”，丢失关键调试信息；
• 版本漂移：函数更新后，旧skill实例仍在内存中缓存，新老版本混用导致数据不一致。

“agent-skills”范式刻意保持执行层的“非云原生”特性——优先选择进程内执行（in-process execution），通过轻量级沙箱（如Pyodide for Python, QuickJS for JS）隔离风险。只有当某个skill明确需要GPU加速或超长运行时，才降级为独立服务。这种“默认轻量、按需升格”的策略，比强行统一部署模型更贴合实际业务节奏。

3. 核心细节解析：从定义到注册的七步实操法

3.1 Step1：用DSL定义Skill契约（比写代码还重要）

很多团队栽在第一步：直接开写Python函数，等联调才发现参数命名混乱、必填项缺失、错误码不统一。正确的起点永远是契约定义。我们自研了一套极简DSL（Domain Specific Language），语法比JSON Schema更贴近自然语言，且自带校验：

skill weather_forecast: description = "获取指定城市的实时天气与未来24小时预报" input: city: string | required | example "北京" unit: enum["celsius", "fahrenheit"] | default "celsius" output: current_temp: number | unit "°C" condition: string | enum["sunny", "rainy", "cloudy"] hourly_forecast: list[{ time: string | format "HH:mm" temp: number precipitation_chance: number | range [0, 100] }] tags = ["public", "low_cost"]

这个DSL文件（.skill后缀）会被编译成标准JSON Schema和Python dataclass。关键优势在于：

• 产品经理能看懂并参与评审（我们曾让非技术人员用此DSL写了8个基础skill）；
• 编译器自动注入required字段校验、类型转换、范围检查等样板代码；
• 修改DSL后一键生成TypeScript客户端、Postman测试集合、Swagger文档。

注意：不要试图用YAML替代。YAML的缩进敏感性和隐式类型转换（如yes自动转布尔值）在多人协作中已导致我们3次线上事故。DSL虽需学习，但换来的是确定性。

3.2 Step2：编写执行函数——遵循“三不原则”

执行函数是唯一允许写业务逻辑的地方，但必须遵守铁律：

• 不操作全局状态：禁止读写模块级变量、类属性、环境变量（除预设的SKILL_CONFIG字典外）。所有配置必须通过input参数传入或从SKILL_CONFIG中提取。
• 不处理异常：函数内不写try/except，所有异常原样抛出。由统一的skill运行时（runtime）捕获并标准化为SkillExecutionError对象，包含error_code（如NETWORK_TIMEOUT）、retryable（是否可重试）、user_message（给终端用户的友好提示）。
• 不决定输出格式：函数返回纯Python字典，格式必须100%匹配DSL定义的output结构。格式化（如温度加单位符号、时间转本地时区）由上层展示层处理。

我们用装饰器强制约束：

@skill_executor( contract_file="weather.skill", timeout=8.0, # 超时强制中断，避免阻塞Agent max_retries=2 # 运行时自动重试，无需函数内实现 ) def execute(input_dict): # 这里只做核心逻辑：调用天气API、解析JSON api_response = requests.get( f"https://api.weather.com/v3/wx/forecast/daily/1day?city={input_dict['city']}", timeout=5.0 ) return parse_weather_response(api_response.json())

3.3 Step3：注册到技能中心——不只是“加载模块”

注册不是简单的import，而是向中央技能中心（Skill Registry）提交可验证的凭证。我们采用双证书机制：

1. 契约证书（Contract Certificate）：由DSL编译器生成，包含SHA256哈希值、编译时间、作者签名（Git commit hash）；
2. 执行证书（Execution Certificate）：运行时对执行函数二进制码（或源码）计算哈希，并绑定Python版本、依赖库版本锁（pip freeze --all > requirements.lock）。

注册流程如下：

# 1. 编译DSL生成契约证书 skillc compile weather.skill # 2. 打包执行代码（自动检测依赖） skillc package weather.py --include-requirements # 3. 提交到技能中心（自动校验双证书一致性） skillc register --contract weather.cert --package weather.pkg

实操心得：曾有个团队跳过package步骤，直接注册源码。结果生产环境Python版本升级后，某个正则表达式行为变更，导致天气解析失败。双证书机制让我们在灰度发布时就能发现版本不兼容，避免故障扩散。

3.4 Step4：为Agent配置技能可见性——权限不是事后补丁

技能注册后默认不可见。必须通过RBAC（基于角色的访问控制）策略显式授权。我们的策略文件长这样：

# policy/weather-access.yaml version: "1.0" rules: - role: "customer_service_agent" skills: - name: "weather_forecast" allow: true conditions: - "input.city in ['北京', '上海', '广州', '深圳']" # 白名单城市 - role: "admin_agent" skills: - name: "weather_forecast" allow: true conditions: [] # 无限制

关键创新在于conditions字段：它不是简单的布尔开关，而是支持JMESPath语法的动态表达式。Agent在调用前，运行时会实时计算条件表达式——比如检查用户当前所在城市是否在白名单，或判断当前时间是否在工作时段。这使得权限控制从静态配置升级为上下文感知的动态决策。

3.5 Step5：技能发现与编排——让Agent自己学会“找工具”

Agent不能靠硬编码调用skill，必须具备自主发现能力。我们实现了一个轻量级技能发现引擎，核心是三元组索引：

当Agent收到用户请求“北京明天热不热？”，引擎执行：

1. 对请求文本做向量嵌入（使用小型蒸馏版sentence-transformers）；
2. 计算与所有已注册skill关键词向量的余弦相似度；
3. 筛选出相似度>0.65的候选skill（此处为weather_forecast）；
4. 用语义指纹做二次过滤，排除“heat_pump_control”等误匹配项；
5. 返回skill元数据，供LLM生成调用参数。

整个过程耗时<15ms，比调用一次外部API还快。更重要的是，它让Agent具备了“举一反三”能力——用户问“上海后天会不会下雨”，即使训练数据里没出现过“上海”，引擎也能基于地理语义关联匹配到天气skill。

3.6 Step6：执行监控与熔断——看不见的守护者

每个skill调用都会产生结构化日志，包含：

• skill_id: 唯一标识符（如weather_forecast@v1.2.0）
• input_hash: 输入参数SHA256（用于去重和回放）
• execution_time_ms: 真实执行耗时
• llm_decision_score: Agent选择该skill的置信度（0~1）
• error_code: 标准化错误码（空表示成功）

基于这些日志，我们构建了两级熔断机制：

• 单技能熔断：连续5次调用超时（>8s）或错误率>30%，自动将该skill降级为“只读模式”（返回缓存结果或固定提示）；
• 领域熔断：当weather_*前缀的所有skill错误率超过15%，触发气象API整体降级，所有相关请求转向备用数据源（如本地缓存+用户历史偏好推测）。

注意：熔断阈值不是拍脑袋定的。我们用混沌工程工具定期注入故障（随机延迟、网络丢包），观察Agent在不同阈值下的恢复能力，最终选定的5次/30%是业务可用性与故障响应速度的最优平衡点。

3.7 Step7：版本回滚与灰度发布——把发布变成常规操作

技能更新必须支持原子化回滚。我们采用“影子注册”机制：

• 新版本skill注册时，先以weather_forecast@v1.3.0-shadow形式进入灰度池；
• 10%流量路由到新版本，其余走旧版v1.2.0；
• 监控对比指标：成功率、耗时P95、LLM置信度下降幅度；
• 若新版本llm_decision_score均值比旧版低0.15以上，自动终止灰度，全量回滚。

最惊艳的是“语义回滚”：当发现新版本skill返回的condition字段值从"rainy"变成了"light_rain"（旧版未定义的新枚举值），运行时会自动映射为"rainy"，保证下游逻辑不受影响。这解决了API演进中最头疼的“向前兼容”问题。

4. 实操过程详解：从零搭建一个可运行的Skills系统

4.1 环境准备：最小可行依赖栈

我们坚持“够用就好”原则，整个运行时核心依赖仅4个包：

• pydantic>=2.0：用于契约校验和数据解析（比dataclasses更强大）；
• jmespath：动态条件表达式求值（比eval安全百倍）；
• redis>=7.0：作为技能元数据和执行状态的高速缓存（可选，文件系统亦可）；
• numpy：向量相似度计算（若不用技能发现可移除）。

安装命令：

pip install "pydantic>=2.0" jmespath redis numpy

提示：坚决不用FastAPI/Flask等Web框架。Skills系统本质是库（library），不是服务（service）。把它嵌入现有Agent框架比独立部署更稳定、更易调试。

4.2 创建第一个Skill：天气查询（完整代码）

文件结构：

my_agent/ ├── skills/ │ ├── weather/ │ │ ├── weather.skill # DSL契约定义 │ │ └── weather.py # 执行函数 ├── registry.py # 技能中心主模块 └── agent.py # 示例Agent调用入口

Step1：编写weather.skill

skill weather_forecast: description = "获取指定城市的实时天气与未来24小时预报" input: city: string | required | example "北京" unit: enum["celsius", "fahrenheit"] | default "celsius" output: current_temp: number | unit "°C" condition: string | enum["sunny", "rainy", "cloudy", "snowy", "foggy"] humidity_percent: integer | range [0, 100] tags = ["public", "low_cost"]

Step2：编写weather.py

import json import requests from typing import Dict, Any from pydantic import BaseModel # 自动生成的输入输出模型（由DSL编译器生成，此处手动简化示意） class WeatherInput(BaseModel): city: str unit: str = "celsius" class WeatherOutput(BaseModel): current_temp: float condition: str humidity_percent: int def execute(input_dict: Dict[str, Any]) -> Dict[str, Any]: """ 天气查询执行函数 注意：此处仅演示逻辑，生产环境需添加重试、超时、错误分类 """ try: # 模拟API调用（实际替换为真实天气服务） # 为演示稳定性，我们用固定响应 mock_data = { "Beijing": {"temp": 22.5, "cond": "sunny", "humid": 45}, "Shanghai": {"temp": 28.1, "cond": "cloudy", "humid": 72}, "Guangzhou": {"temp": 31.7, "cond": "rainy", "humid": 88} } city_key = input_dict["city"].replace("市", "").strip() if city_key not in mock_data: raise ValueError(f"不支持的城市: {input_dict['city']}") data = mock_data[city_key] # 单位转换（仅演示） if input_dict.get("unit") == "fahrenheit": data["temp"] = data["temp"] * 9/5 + 32 return { "current_temp": round(data["temp"], 1), "condition": data["cond"], "humidity_percent": data["humid"] } except requests.Timeout: raise TimeoutError("天气API请求超时") except Exception as e: raise RuntimeError(f"天气查询失败: {str(e)}")

Step3：创建registry.py（核心技能中心）

import json import hashlib from pathlib import Path from typing import Dict, Any, Optional, List from pydantic import BaseModel class SkillMeta(BaseModel): name: str version: str description: str input_schema: Dict[str, Any] output_schema: Dict[str, Any] tags: List[str] # 其他元数据... class SkillRegistry: def __init__(self, storage_path: str = "./skills_registry.json"): self.storage_path = Path(storage_path) self.skills: Dict[str, SkillMeta] = {} self._load_from_disk() def register(self, skill_name: str, meta: SkillMeta) -> bool: """注册技能元数据""" full_name = f"{skill_name}@{meta.version}" self.skills[full_name] = meta self._save_to_disk() return True def get_skill(self, full_name: str) -> Optional[SkillMeta]: """根据全名获取技能元数据""" return self.skills.get(full_name) def list_skills(self, tags: List[str] = None) -> List[str]: """按标签筛选技能列表""" if not tags: return list(self.skills.keys()) return [ name for name, meta in self.skills.items() if all(tag in meta.tags for tag in tags) ] def _load_from_disk(self): if self.storage_path.exists(): with open(self.storage_path) as f: data = json.load(f) # 这里应做反序列化，简化起见略过 self.skills = data def _save_to_disk(self): with open(self.storage_path, "w") as f: json.dump(self.skills, f, indent=2, ensure_ascii=False) # 全局技能中心实例 registry = SkillRegistry()

Step4：创建agent.py（演示Agent调用）

from skills.weather.weather import execute from registry import registry from skills.weather.weather import WeatherInput, WeatherOutput def call_weather_skill(city: str, unit: str = "celsius") -> dict: """Agent调用天气技能的封装函数""" # 1. 构建输入 input_data = {"city": city, "unit": unit} # 2. 参数校验（使用Pydantic） try: validated_input = WeatherInput(**input_data) except Exception as e: raise ValueError(f"输入参数校验失败: {e}") # 3. 执行技能 try: result = execute(validated_input.dict()) # 4. 输出校验 WeatherOutput(**result) # 自动校验结构 return { "status": "success", "data": result, "skill_used": "weather_forecast@1.0.0" } except Exception as e: return { "status": "error", "message": str(e), "skill_used": "weather_forecast@1.0.0" } # 测试调用 if __name__ == "__main__": print("=== 天气技能测试 ===") print(call_weather_skill("北京")) print(call_weather_skill("上海", "fahrenheit")) print(call_weather_skill("不存在的城市"))

运行效果：

$ python agent.py === 天气技能测试 === {'status': 'success', 'data': {'current_temp': 22.5, 'condition': 'sunny', 'humidity_percent': 45}, 'skill_used': 'weather_forecast@1.0.0'} {'status': 'success', 'data': {'current_temp': 82.6, 'condition': 'cloudy', 'humidity_percent': 72}, 'skill_used': 'weather_forecast@1.0.0'} {'status': 'error', 'message': '不支持的城市: 不存在的城市', 'skill_used': 'weather_forecast@1.0.0'}

4.3 集成到主流Agent框架：LangChain与LlamaIndex适配

虽然我们强调“skills是库而非服务”，但必须无缝对接主流生态。以下是两个最常用框架的适配方案：

LangChain适配：

from langchain.tools import BaseTool from pydantic import BaseModel, Field class WeatherToolInput(BaseModel): city: str = Field(..., description="城市名称") unit: str = Field("celsius", description="温度单位") class WeatherTool(BaseTool): name = "weather_forecast" description = "获取指定城市的实时天气与未来24小时预报" args_schema: Type[BaseModel] = WeatherToolInput def _run(self, city: str, unit: str = "celsius") -> str: # 调用我们定义的execute函数 result = execute({"city": city, "unit": unit}) return json.dumps(result, ensure_ascii=False, indent=2) def _arun(self, city: str, unit: str = "celsius") -> str: raise NotImplementedError("同步调用已足够") # 在Agent中使用 from langchain.agents import initialize_agent, AgentType tools = [WeatherTool()] agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)

LlamaIndex适配：

from llama_index.tools import FunctionTool def weather_tool(city: str, unit: str = "celsius") -> str: result = execute({"city": city, "unit": unit}) return json.dumps(result, ensure_ascii=False, indent=2) # 注册为FunctionTool weather_function_tool = FunctionTool.from_defaults( fn=weather_tool, name="weather_forecast", description="获取指定城市的实时天气与未来24小时预报", )

关键洞察：适配层代码不超过20行，证明“agent-skills”范式与框架无关。真正的价值在契约定义和执行隔离，而非对接代码。

4.4 生产环境加固：Docker化与可观测性

Dockerfile（精简版）：

FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 技能文件单独挂载，便于热更新 VOLUME ["/app/skills"] EXPOSE 8000 CMD ["python", "server.py"] # server.py启动技能中心HTTP API

可观测性集成：

• Metrics：用Prometheus Client暴露skill_execution_total{skill="weather_forecast",status="success"}等指标；
• Tracing：OpenTelemetry自动注入span，追踪从LLM决策→技能发现→执行→返回的完整链路；
• Logging：结构化日志输出到stdout，字段包含skill_id,input_hash,duration_ms,llm_confidence。

我们发现一个反直觉事实：增加可观测性后，技能平均修复时间（MTTR）下降67%，但新增代码量仅占总代码库的3.2%。因为90%的故障定位时间花在“到底调用了哪个skill版本”上，而结构化日志让这个问题瞬间消失。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：高频故障与根因定位

5.2 那些只有踩过才懂的实操心得

心得1：技能粒度宁小勿大
曾有个团队把“用户旅程分析”做成一个skill，包含数据拉取、清洗、建模、可视化全流程。结果每次模型算法更新都要全量回归测试。后来拆成fetch_user_events、clean_session_data、train_ltv_model、generate_report四个skill，现在算法团队可独立更新train_ltv_model，其他环节完全不受影响。经验法则：一个skill只做一件事，且这件事能在10秒内完成。

心得2：错误码设计比功能本身更重要
早期我们用通用SkillError，结果监控告警全是“skill failed”，根本分不清是网络问题、数据问题还是逻辑问题。后来定义了12类标准错误码：

• NETWORK_TIMEOUT（可重试）
• DATA_NOT_FOUND（不可重试，需引导用户换查询条件）
• PERMISSION_DENIED（需触发权限申请流程）
• INPUT_VALIDATION_FAILED（LLM参数生成错误，需优化prompt）

现在告警能直接定位到根因，MTTD（平均诊断时间）从47分钟降到6分钟。

心得3：永远为“降级”而设计
天气skill上线首周，第三方API宕机37分钟。我们本可返回“服务暂时不可用”，但选择了更优雅的方案：当检测到API不可用时，自动切换到“基于历史数据的预测模式”——用过去7天同城市、同时间段的平均温度作为fallback。用户无感知，体验反而更稳定。最好的容错不是报错，而是用更低精度的答案维持服务连续性。

心得4：技能文档要写给三类人看

• 给LLM看：DSL中的description和example字段，直接影响调用准确率；
• 给开发者看：input_schema的详细注释，特别是边界条件（如“城市名最长15字符”）；
• 给运维看：cost_estimate字段（预估token数）和timeout设置，用于容量规划。

我们强制要求每个skill提交PR时，必须包含这三类文档的更新，否则CI拒绝合并。

5.3 性能压测实录：千万级调用量下的表现

我们在某金融客户环境做了72小时压力测试，模拟10万日活用户，峰值QPS 1200：

关键发现：技能中心自身的性能瓶颈不在代码，而在序列化/反序列化开销。当input/output结构复杂时（如含嵌套list），JSON序列化耗时占比达63%。解决方案是引入orjson替代标准json库，性能提升2.8倍，且自动处理datetime、bytes等类型。

5.4 安全审计重点：五个必须检查的红线

在金融、医疗等强监管行业，skills系统需通过专项安全审计。以下是我们的检查清单：

1. 输入净化：所有字符串输入必须经过XSS过滤（如html.escape()）和SQL注入检测（正则匹配SELECT.*FROM等模式）；
2. 输出脱敏：技能返回的user_data字段自动触发PII（个人身份信息）扫描，发现手机号、身份证号立即掩码；
3. 依赖锁定：requirements.lock文件必须提交到Git，且CI流水线强制校验pip install -r requirements.lock结果与锁文件一致；
4. 执行沙箱：高危skill（如文件操作、系统命令）必须运行在Pyodide沙箱中，禁用os.system、subprocess等危险API；
5. 审计日志：所有skill调用必须记录user_id、session_id、input_hash、timestamp，保留至少180天。

注意：曾有个团队为提升性能关闭了输入净化，结果一个恶意构造的city参数（<script>alert(1)</script>）导致前端XSS漏洞。安全不是性能的敌人，而是必须前置的设计约束。

6. 后续演进方向：从Skills到Skill Ecosystem

6.1 技能市场（Skill Marketplace）：让能力流动起来

我们正在内测的技能市场，不是App Store式的下载平台，而是基于Git的分布式能力交换网络。每个团队维护自己的skills-org/repo，通过skillc publish命令将技能推送到公共索引。关键特性：

• 智能依赖解析：当A团队引用B团队的payment_processskill时，系统自动检测B团队的requirements.lock，确保依赖版本兼容；
• 可信签名：所有发布技能必须用团队私钥签名，消费者可验证来源真实性；
• 使用计量：自动统计各skill被调用次数、成功率，形成“能力健康度排行榜”。

目前已有17个业务线接入，最热门的skill是extract_invoice_info（发票信息抽取），