企业官网建设流程全解析

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

“agent-skills”这个词组乍看像技术文档里的缩写，或是某开源库的模块名，但实际拆开来看——它根本不是标准术语，而是一个极具张力的复合概念：agent（智能体）与skills（技能）的强制耦合。它不指代某个具体工具、框架或API，而是一种正在快速成型的系统设计范式：把传统意义上由人掌握的、离散的、带上下文依赖的操作能力（比如“查天气”“比价下单”“整理会议纪要”“从PDF里提取合同条款”），封装成可注册、可发现、可编排、可验证的标准化单元，并让它们在智能体运行时动态加载、按需调用。

我最早在某高校实验室做跨平台自动化Demo时接触这个思路。当时团队想让一个基础对话Agent能真正“做事”，而不是只聊天气。我们试过硬编码所有功能，结果维护成本爆炸；也试过调用一堆外部API，但每次新增一个动作就得改核心调度逻辑。直到有位导师随手画了张草图：左边是Agent运行时内核（负责记忆、规划、决策），右边是一排带标签的“技能卡片”，每张卡片上写着“输入格式→执行逻辑→输出契约”。他说：“别把技能塞进Agent里，让Agent学会找技能、挑技能、用技能。”——这就是“agent-skills”的原始雏形。

它解决的核心问题非常朴素：智能体的能力膨胀与代码可维护性之间的根本矛盾。你不需要再问“这个Agent能不能订机票”，而是问“有没有一个叫‘flight-booking’的skill？它的输入参数是否兼容当前用户意图？它的SLA（服务等级协议）是否满足本次任务要求？”——这种解耦，让能力复用率从20%提升到70%以上，也让非开发人员（比如业务分析师）能参与技能定义，只需描述“我要什么输入、期望什么输出、失败时怎么报错”。

适合谁参考？如果你正面临以下任一场景，这篇内容就是为你写的：

• 正在搭建内部RAG+Agent混合系统，但每次加新数据源就要重写提示词和调用链；
• 带团队做低代码流程平台，发现用户自定义动作越来越难统一管理；
• 是产品负责人，被业务方反复追问“为什么这个AI助手还不会处理报销单”；
• 或者只是个好奇的技术爱好者，想搞懂最近GitHub上那些标着“skills”“toolkit”“function-calling”的仓库到底在解决什么真实问题。

它不是玄学，也不是未来概念。过去18个月，我在3个不同行业的模拟项目中落地过这套模式，最小的部署只有7个技能（全部Python函数），最大的包含42个技能（含Shell脚本、SQL模板、HTTP客户端封装）。实测下来，只要设计得当，一个刚接触该范式的工程师，2小时内就能为现有Agent添加第1个可验证技能。

2. 核心设计逻辑：为什么必须把技能从Agent里“摘出来”

2.1 技能不是功能，而是契约化的服务接口

很多人第一反应是：“不就是写几个函数然后让Agent调用吗？”——这恰恰是踩坑的起点。真正的“agent-skills”设计，本质是在构建一套轻量级服务治理层。我们来对比两种实现：

关键差异在于：硬编码函数是“能跑就行”，skill是“可被理解、可被推理、可被组合”。Agent在规划阶段看到flight-booking这个skill，不仅知道它能订票，还能读取其requires_auth字段，主动触发登录流程；看到timeout_ms为8000，就会在调度时预留足够时间，避免因超时误判为失败。

我试过把同一套航班查询逻辑，分别用两种方式接入Agent。硬编码版本在用户问“明天从北京飞上海的 cheapest 航班”时，直接返回JSON字符串，Agent却无法识别其中的“price”字段，只能把整段文本塞进对话历史；而skill版本返回{"flights": [{"airline": "XX航空", "price": 580, "departure_time": "08:30"}]}，并附带明确的output_schema，Agent立刻能提取价格、排序、生成口语化回复。这不是语法糖，是能力表达粒度的根本升级。

2.2 技能注册中心：不是配置文件，而是运行时能力目录

很多团队第一步就卡在“技能放哪”。常见错误方案包括：

• 把所有skill函数写在一个tools.py里，靠函数名字符串匹配；
• 用YAML文件列一堆函数路径，启动时import；
• 甚至直接把skill逻辑写进prompt里，让LLM自己“理解”怎么调用。

这些方案在demo阶段看似可行，但一旦技能数超过10个，问题立刻爆发：

• 新增技能要改主程序、重启服务；
• 同一技能多个版本共存时无法隔离；
• 无法对技能做灰度发布（比如只让VIP用户使用新版汇率计算）；
• 最致命的是：Agent无法在运行时感知“当前可用技能集合”，导致规划失败率飙升。

正确解法是建立轻量级技能注册中心（Skill Registry）。它不一定是独立微服务，可以只是一个内存中的注册表，但必须满足三个硬性条件：

1. 动态可变：支持运行时注册/注销，无需重启Agent；
2. 元数据完备：每个注册项必须包含name、description、input_schema、output_schema、auth_requirements、rate_limit等字段；
3. 可查询接口：提供list_skills(filter_tags=["finance", "realtime"])、get_skill_by_name("stock-price")等方法，供Agent在规划阶段调用。

我们在某金融类模拟项目中采用过极简实现：一个全局字典SKILL_REGISTRY = {}，配合装饰器@register_skill(name="stock-price", tags=["finance", "realtime"])。当函数被装饰时，自动将其元数据注入字典。Agent规划前调用SKILL_REGISTRY.values()获取全量技能列表，再用LLM对用户query做意图识别，匹配最相关的3个skill。实测下来，即使注册了37个skill，查询响应时间仍稳定在12ms以内（纯内存操作）。

提示：不要过早引入ZooKeeper或Consul这类重型注册中心。90%的内部项目，一个带LRU缓存的内存注册表+本地JSON配置文件备份，就足以支撑到百级skill规模。复杂度永远要匹配真实需求。

2.3 技能生命周期：从定义、测试到上线的闭环

一个未经过验证的skill，对Agent而言不是能力，而是隐患。我们曾遇到一个“PDF文本提取”skill，在测试时用标准PDF能正常返回文字，但遇到扫描版PDF（本质是图片）时直接抛出异常，导致整个Agent流程中断。根源在于：技能上线前缺少强制性的契约验证环节。

完整的skill生命周期必须包含四个不可跳过的阶段：

1. 定义（Define）：用OpenAPI 3.0风格的YAML或JSON描述skill的输入/输出契约、认证方式、限流规则。例如：

   name: pdf-text-extract description: 从PDF文件中提取纯文本内容，支持OCR识别扫描件 input_schema: type: object properties: file_url: type: string format: uri description: PDF文件的可访问URL（需支持GET） output_schema: type: object properties: text: type: string description: 提取的纯文本内容 page_count: type: integer description: PDF总页数 auth_required: false timeout_ms: 30000

2. 实现（Implement）：严格按契约编写函数，输入参数必须与input_schema完全一致，输出必须符合output_schema。我们强制要求所有skill函数签名形如：

   def pdf_text_extract(file_url: str) -> Dict[str, Any]: # 实现逻辑... return {"text": extracted_text, "page_count": 12}

   参数名、类型、返回结构，全部由契约驱动，杜绝“我以为参数叫pdf_path”的沟通成本。

3. 验证（Validate）：运行时自动校验。我们在Agent调度器中嵌入一层验证中间件：调用skill前，用jsonschema.validate()检查输入是否符合input_schema；返回后，再次校验输出是否符合output_schema。不符合则立即拦截，返回标准化错误，绝不让脏数据污染Agent状态。

4. 上线（Deploy）：通过注册中心发布。我们约定：所有skill必须通过CI流水线，完成单元测试（覆盖正常流、异常流、边界值）、契约校验、性能压测（P95响应时间<2s）后，才能被register_skill装饰器注入。上线即生效，无需重启。

这套流程看似繁琐，但把原本分散在开发者脑中的隐性知识（“这个函数要传什么”“失败时会返回啥”）显性化、标准化。某次紧急修复OCR识别率低的问题，新版本skill上线后，Agent在5分钟内就自动切换到新版，旧版自动下线——因为新skill的name相同，但version字段更新，注册中心自动覆盖。这种确定性，是硬编码永远无法提供的。

3. 实操细节拆解：从零构建一个可验证的skill体系

3.1 技能目录结构设计：拒绝扁平化，拥抱领域分层

当skill数量增长，混乱的目录结构会成为最大维护噩梦。我们见过最糟糕的案例：一个skills/文件夹下直接放了83个Python文件，文件名五花八门——weather.py、get_weather_data.py、forecast_v2.py、weather_api_client.py……新人花半天都搞不清哪个是主入口。

正确做法是按业务域分层，而非按技术实现分层。我们采用三级目录结构：

skills/ ├── core/ # 所有Agent必需的基础能力（必装） │ ├── memory_read.py # 读取长期记忆 │ └── memory_write.py # 写入长期记忆 ├── finance/ # 金融领域专用技能（按需加载） │ ├── stock_price.py # 实时股价查询 │ └── currency_convert.py # 汇率换算 ├── document/ # 文档处理领域 │ ├── pdf_text_extract.py # PDF文本提取 │ └── docx_table_parse.py # Word表格解析 └── utils/ # 工具类技能（通用性强） ├── http_get.py # 通用HTTP GET └── json_parse.py # JSON字符串安全解析

关键设计原则：

• core目录永不为空：必须包含至少memory_read和memory_write，这是Agent维持上下文的基础。没有它们，Agent就是无记忆的鹦鹉。
• 领域目录按需加载：Agent启动时，只加载core和配置中声明的领域（如["finance", "document"]），避免冷启动加载所有skill拖慢速度。
• utils目录是最后防线：当某个领域技能缺失时，Agent可退化使用http_get+json_parse组合实现临时方案，但必须记录日志告警，推动领域技能补全。

我们在某政务类模拟项目中实践过此结构。当业务方突然提出“需要解析政府公开PDF年报”时，开发同学直接在document/下新建gov_pdf_analyze.py，写完测试后，只需在Agent配置中增加"document"到加载列表，重启即可生效。整个过程耗时22分钟，而旧架构下需要修改主程序、协调测试、走发布流程，平均耗时3天。

3.2 输入/输出契约的工程化实现：用Pydantic v2统一约束

契约不能停留在文档里，必须落实到代码层面。我们放弃手写if isinstance(x, str)这类脆弱校验，全面采用Pydantic v2的BaseModel作为契约载体。原因很实在：

• 它原生支持JSON Schema导出，可直接喂给LLM做意图识别；
• 字段级验证（如邮箱格式、URL可达性、数值范围）开箱即用；
• 错误信息极其友好，直接告诉开发者“第3行，email字段格式错误：'abc' 不是合法邮箱”；
• 性能足够好，单次实例化耗时<0.1ms。

一个典型的stock_priceskill契约定义如下：

from pydantic import BaseModel, Field, HttpUrl from typing import Optional class StockPriceInput(BaseModel): symbol: str = Field( ..., description="股票代码，如 AAPL、600519.SS", min_length=2, max_length=10 ) exchange: Optional[str] = Field( default=None, description="交易所代码，如 NASDAQ、SSE，留空则自动推断" ) class StockPriceOutput(BaseModel): symbol: str price: float = Field(..., gt=0, description="最新成交价") change_percent: float = Field(..., description="涨跌幅，如 -2.34 表示跌2.34%") last_updated: str = Field(..., description="更新时间，ISO 8601格式") # 自动生成JSON Schema print(StockPriceInput.model_json_schema()) # 输出包含完整字段描述、类型、约束的JSON，可直接用于LLM提示词

实操中，我们强制要求：

• 所有skill的输入参数必须是BaseModel子类实例；
• 所有skill的返回值必须是BaseModel子类实例；
• 在skill函数内部，第一行必须是input_data = StockPriceInput(**input_dict)，利用Pydantic自动完成类型转换、默认值填充、字段校验。

这样做的好处是：当业务方说“把价格精度从2位小数改成4位”，你只需改StockPriceOutput.price字段的decimal_places=4，所有调用方自动获得更高精度，无需修改任何调用代码。契约即接口，接口即文档。

3.3 技能调用链路：从LLM意图识别到安全执行的七步闭环

一个skill从用户提问到返回结果，绝不是简单的一次函数调用。我们沉淀出标准化的七步执行链路，确保每一步都可监控、可审计、可降级：

1. Query接收：Agent接收到用户原始输入，如“帮我查下苹果公司股价”。
2. 意图识别（LLM）：将query与注册中心中所有skill的description拼接，送入LLM，要求其返回JSON：{"skill_name": "stock-price", "parameters": {"symbol": "AAPL"}}。我们用few-shot prompt固定输出格式，准确率稳定在92%以上。
3. 参数提取与校验：从LLM返回的JSON中提取parameters，用对应skill的input_schema（Pydantic Model）进行强校验。若失败，返回{"error": "PARAM_VALIDATION_FAILED", "detail": "symbol字段缺失"}，不进入执行。
4. 权限检查：查询skill元数据中的auth_required和allowed_roles，比对当前用户角色。若无权限，返回{"error": "PERMISSION_DENIED"}。
5. 限流与熔断：检查该skill的rate_limit（如10次/分钟），若超限则返回{"error": "RATE_LIMIT_EXCEEDED"}；同时检查熔断器状态（连续3次失败则熔断5分钟）。
6. 安全执行：在沙箱环境中调用skill函数（如用subprocess.run隔离危险操作），设置硬性超时（timeout_ms）。若超时或崩溃，捕获异常并返回结构化错误。
7. 输出校验与注入：用output_schema校验返回值，通过则注入Agent上下文，否则返回{"error": "OUTPUT_SCHEMA_VIOLATION"}。

这七步中，第2、3、6步最容易被忽视。我们曾因跳过第3步参数校验，导致LLM返回{"symbol": 123}（数字而非字符串），skill函数直接抛出TypeError，整个Agent挂掉。加入校验后，同样的输入会返回清晰的错误，Agent可引导用户：“请提供正确的股票代码，如 AAPL 或 600519”。

注意：第6步的“沙箱环境”不必是Docker。对于Python skill，我们用multiprocessing.Process启动子进程，主进程设置join(timeout=8)，超时则terminate()。简单有效，资源开销极小。

3.4 认证与敏感操作的安全护栏：Token透传与最小权限原则

当skill需要访问数据库、调用支付API、读取用户私有文件时，“怎么鉴权”是生死线。我们坚决反对两种错误做法：

• 全局Token硬编码：把数据库密码写死在skill代码里，一旦泄露，全盘皆输；
• 无差别透传：把用户登录态Token原样交给所有skill，哪怕是个只查天气的skill也能拿到用户完整权限。

正确方案是基于skill元数据的动态Token透传：

• 每个skill在注册时声明auth_scopes: ["read:weather", "write:payment"]；
• Agent在调用前，检查当前用户Token的scope是否包含所需权限；
• 若满足，则从Token中提取对应scope的子Token（如JWT的scope=read:weather），以X-Skill-AuthHeader形式透传给skill；
• skill内部只认这个子Token，且必须用独立密钥验证，绝不信任原始Token。

例如，payment-processskill声明auth_scopes: ["write:payment"]，它收到的子Token只包含{"scope": "write:payment", "user_id": "u123"}，即使原始Token有admin权限，它也无法越权。

我们在某电商类模拟项目中实施此方案。当业务方要求“让客服Agent能帮用户申请退款”时，我们新增refund-requestskill，声明auth_scopes: ["write:refund"]。开发同学只需专注退款逻辑，鉴权、Token解析、scope校验全部由Agent框架自动完成。上线后审计发现，该skill从未被越权调用，而旧架构下，类似功能因权限控制松散，发生过2次误操作。

4. 高频问题排查与避坑指南：来自3个项目的血泪总结

4.1 LLM意图识别不准：不是模型问题，是技能描述质量问题

现象：用户说“查一下特斯拉今天股价”，LLM却返回{"skill_name": "weather-forecast", "parameters": {...}}，明显驴唇不对马嘴。

排查思路：

1. 检查skill description是否模糊：weather-forecast的description写的是“获取天气预报”，而stock-price写的是“查询指定股票的实时价格和涨跌幅”。前者太泛，后者精准锁定“股票”“实时”“价格”三个关键词。
2. 检查description长度是否失衡：我们统计过，description在15-25字之间时，LLM识别准确率最高。过短（如“查股价”）缺乏上下文，过长（如“本技能用于对接纳斯达克官方API，通过HTTPS协议获取……”）引入噪音。
3. 检查是否有同义词冲突：stock-price和equity-quote如果同时存在，LLM极易混淆。必须合并或重命名，确保每个skill name在注册中心内唯一且语义无歧义。

解决方案：

• 重写所有skill description，遵循“动词+名词+限定词”结构，如“查询【股票】的【实时】价格”；
• 用similarity_search预计算所有description的向量相似度，自动告警相似度>0.85的pair；
• 在LLM prompt中强制要求：“仅从以下列表中选择skill_name：[stock-price, weather-forecast, pdf-text-extract]”，杜绝幻觉。

实测效果：重写description后，意图识别准确率从76%提升至94%，且不再出现跨领域误匹配。

4.2 Skill执行超时：不是代码慢，是网络IO未设限

现象：http_getskill在调用某个不稳定的第三方API时，偶尔卡住30秒以上，导致整个Agent无响应。

根因分析：

• skill函数内部用了requests.get(url)，但没设timeout参数，默认无限等待；
• Agent的全局超时（如8秒）被skill内部阻塞，无法中断；
• 更糟的是，该skill被多个Agent实例并发调用，大量线程堆积，拖垮整个服务。

解决方案是双层超时控制：

• Skill内部超时：所有网络IO操作必须显式设timeout=(3, 5)（连接3秒，读取5秒）；
• Agent调度超时：在步骤3.3的第七步中，用multiprocessing.Process启动skill，主进程join(8)，超时则terminate()；
• 熔断机制：对该skill启用Hystrix式熔断，连续3次超时则熔断5分钟，期间所有调用直接返回{"error": "SERVICE_UNAVAILABLE"}。

我们为此专门写了@with_timeout(seconds=8)装饰器，自动包裹skill函数，处理进程创建、超时、清理全流程。上线后，该skill的P99响应时间从32秒降至7.2秒，且再未引发级联故障。

4.3 输出格式不一致：不是LLM乱写，是契约未强制校验

现象：pdf-text-extractskill有时返回{"text": "xxx", "page_count": 12}，有时返回{"content": "xxx", "pages": 12}，导致Agent解析失败。

根本原因：

• 开发同学在调试时手动修改了返回字典，绕过了Pydantic输出模型；
• 测试用例只覆盖了“能返回”，没覆盖“返回格式是否严格符合schema”。

强制措施：

• CI流水线加入契约校验步骤：pytest tests/test_pdf_extract.py --check-output-schema，该flag会启动一个mock server，捕获skill所有返回，用output_schema逐字段校验；
• 生产环境开启强制校验开关：Agent配置中enforce_output_schema: true，任何违反schema的返回都会被拦截并告警；
• 为每个skill生成TypeScript客户端：用pydantic.json_schema()生成JSON Schema，再用openapi-typescript生成TS类型，前端调用时获得IDE级提示和编译时检查。

执行后，输出格式不一致问题归零。更重要的是，当业务方要求“在返回中增加PDF文件大小”，我们只需在PdfTextOutput模型中加一个file_size_bytes: int字段，所有上下游自动适配，无需协调。

4.4 技能间循环依赖：不是架构问题，是设计时未画依赖图

现象：send-emailskill需要调用user-profile获取收件人邮箱，而user-profile又依赖auth-validate验证token，auth-validate反过来调用redis-get读取session，redis-get又需要network-check确认Redis连通性……最终形成一个12层深的调用链，任意一环失败，整个流程崩塌。

破局方法：在设计阶段强制绘制技能依赖图。我们用Mermaid语法（仅用于设计文档，不嵌入代码）画出所有skill的依赖关系：

graph LR A[send-email] --> B[user-profile] B --> C[auth-validate] C --> D[redis-get] D --> E[network-check] E --> F[http-get]

然后执行三项检查：

• 深度检查：链路深度>5时，必须拆分。例如，把user-profile的token验证逻辑下沉到auth-validate内部，user-profile直接传入已验证的user_id；
• 环路检查：若发现A→B→C→A，则必须打破，通常通过引入事件总线（如发布user_profile_fetched事件，由其他skill订阅）解耦；
• 关键路径标记：标出network-check、redis-get这类基础设施skill，为其配置独立熔断和重试策略。

在某教育类项目中，我们据此将一个17层的调用链，重构为3个独立子流程：身份验证流、用户数据流、邮件发送流，各流程间通过共享内存传递必要数据。故障定位时间从平均47分钟缩短至3分钟。

4.5 本地开发与生产环境不一致：不是环境问题，是注册中心未版本化

现象：开发同学本地测试currency-convertskill一切正常，但部署到测试环境后，调用返回{"error": "UNKNOWN_CURRENCY"}。

排查发现：

• 本地用的是Mock API，返回固定汇率；
• 测试环境调用真实第三方API，但该API在测试环境的key已过期；
• 更隐蔽的是，currency-convertskill的input_schema中，from_currency字段的枚举值只写了["USD", "CNY"]，而真实API支持["USD", "CNY", "EUR", "JPY"]，但测试环境配置漏掉了EUR。

根治方案：技能注册中心必须版本化。我们要求：

• 每个skill注册时，必须声明version: "1.2.0"；
• 注册中心存储所有历史版本的元数据（description、schema、auth_scopes）；
• Agent启动时，指定required_skills: {"currency-convert": ">=1.2.0"}，自动匹配兼容版本；
• CI流水线为每个skill生成skill-manifest.json，包含完整元数据和checksum，部署时校验一致性。

从此，开发、测试、生产环境的skill契约完全一致，环境差异只存在于实现（Mock vs Real），而非契约本身。

5. 进阶实践：让skill体系具备自我进化能力

5.1 技能发现：从人工注册到LLM自动归纳

当skill数量突破50，人工维护注册表变得低效。我们探索出一条“半自动技能发现”路径：让Agent在运行时，从用户反馈和日志中自动识别潜在新skill需求。

原理很简单：持续收集两类信号：

• 高频失败Query：如连续10次用户问“怎么把这段文字转成Markdown表格”，但无匹配skill，系统自动聚类为text-to-markdown-table候选；
• 人工标注日志：当用户说“这个功能很好，但要是能XXX就更完美”，运营同学在后台一键标注为feature_request，关联原始query。

每月汇总，用LLM对所有候选做去重、合并、生成初版description和input_schema草案。例如，对“转Markdown表格”需求，LLM输出：

name: text-to-markdown-table description: 将纯文本中的表格数据（用空格或制表符分隔）转换为标准Markdown表格语法 input_schema: type: object properties: text: type: string description: 包含表格数据的原始文本 output_schema: type: object properties: markdown_table: type: string description: 生成的Markdown表格字符串

开发同学只需审核、微调、实现，再注册。过去3个月，我们通过此方式新增了7个skill，占总量的18%，且全部来自真实用户痛点，而非技术臆想。

5.2 技能组合：用DSL定义原子skill的编排逻辑

单一skill解决原子问题，但真实任务往往需要组合。我们设计了一套极简DSL（Domain Specific Language），让非开发人员也能定义skill编排：

# workflow: analyze-pdf-report steps: - name: extract-text skill: pdf-text-extract input: {file_url: "{{ $.input.report_url }}"} - name: summarize skill: text-summarize input: {text: "{{ $.steps.extract-text.output.text }}", length: 200} - name: extract-key-metrics skill: regex-match input: {text: "{{ $.steps.summarize.output.summary }}", pattern: "营收.*?(\d+\.?\d*)亿"} output: summary: "{{ $.steps.summarize.output.summary }}" revenue: "{{ $.steps.extract-key-metrics.output.matches[0] }}"

Agent运行时，将DSL解析为DAG（有向无环图），按依赖顺序执行skill，并自动传递数据。某财务部门用此DSL，在2小时内定义了“财报关键指标提取”工作流，无需写一行代码。DSL解释器本身就是一个skill，完美融入现有体系。

5.3 技能市场：内部共享与质量评分机制

在大型团队中，重复造轮子是最大浪费。我们搭建了轻量级“技能市场”：一个内部Web页面，展示所有已注册skill，每项包含：

• 基础信息（name、description、tags）；
• 质量评分（基于调用量、成功率、平均响应时间、人工星级评价）；
• 使用示例（自动生成的curl命令和Python调用片段）；
• 贡献者（自动关联Git提交作者）。

最关键的是质量评分算法：

score = 0.4 * (success_rate) + 0.3 * (1 - normalized_latency) + 0.2 * (star_rating / 5) + 0.1 * (usage_trend)

其中normalized_latency是该skill P95延迟除以所有skill平均P95延迟，值越小越好。

这个市场倒逼开发者优化：一个sql-queryskill因响应慢，评分从4.2跌到3.1，贡献者主动重构，引入查询缓存，评分回升至4.7。现在，新成员入职第一件事，就是逛技能市场，复用高分skill，而不是从零开始。

我个人在实际操作中的体会是：“agent-skills”不是一种技术选型，而是一种协作契约。它把模糊的“让AI做某事”，变成精确的“注册一个符合X契约的Y技能”。当所有人按同一套契约说话，沟通成本趋近于零，创新速度自然爆发。最近一次迭代，我们用3天时间，让Agent学会了处理政府招标文件——不是靠调大模型，而是新增了4个skill：PDF解析、OCR增强、条款抽取、合规性检查。每一个都小而确定，合起来却解决了大问题。