企业官网建设流程全解析

1. 项目概述：Agent-Skills 不是玩具，是工程化能力的分水岭

“agent-skills”这个名称乍看像一个技术标签，实则是一套正在快速收敛的工程实践范式——它不指代某个具体工具或框架，而是描述一类可复用、可测试、可编排、可交付的原子级智能体能力单元。我在过去三年里带过七支不同背景的团队（从金融风控系统到教育SaaS平台），凡是把“写个agent”当成“调个API”的项目，90%在第三周就陷入调试地狱；而把“agent-skills”当作接口契约来设计的团队，平均交付周期缩短42%，线上故障率下降67%。核心差异就在这里：前者在拼凑功能，后者在构建能力基建。

你能在热搜词里反复看到CLI、API、frontend-ui-engineering、test-driven-development这四个关键词并列出现，绝非偶然。它们共同指向一个事实：真正落地的 agent-skills 必须同时满足命令行可触发、服务端可暴露、前端可集成、测试用例可覆盖这四重约束。比如一个“自动归档会议纪要”的 skill，如果不能通过agent-skills archive --meeting-id=12345在终端跑通，就不能算完成；如果不能被前端按钮一键调用，就无法进入用户工作流；如果无法用 Jest 或 pytest 写出断言其输出结构、错误路径、超时行为的测试用例，那它就是一颗随时会爆的雷。

我见过太多团队踩的第一个坑，就是把 skill 当成“AI prompt 封装”。结果发现：prompt 改一行，所有调用方全崩；token 超限没兜底，整个流水线卡死；模型返回格式稍有波动，下游解析直接抛异常。而成熟的 agent-skills 设计，第一行代码不是写 prompt，而是定义Input Schema和Output Schema——就像当年 REST API 兴起时大家抢着写 OpenAPI Spec 一样。它强制你在动脑之前先动笔，画清楚这个能力的输入边界、处理契约、失败语义和输出契约。这不是增加负担，是把模糊的“AI 行为”翻译成确定的“软件接口”。

适合谁读？如果你是后端工程师，正被产品拉着“加个智能摘要功能”，但又怕接了 AI 就失去可控性；如果你是前端工程师，厌倦了每次改 UI 都要等后端发版，想直接对接能力单元；如果你是测试工程师，面对 LLM 输出的不确定性不知如何设计用例；甚至如果你是技术负责人，正在评估是否要把“智能能力”作为公司级基建来投入——这篇文章就是为你写的。它不讲大模型原理，不堆参数调优技巧，只聚焦一件事：如何把“让 AI 做件事”这件事，变成一门可重复、可验证、可维护的工程手艺。

2. 核心设计逻辑：为什么必须用 CLI 作为能力入口原点

2.1 CLI 是能力契约的“最小可信执行环境”

很多人疑惑：为什么 agent-skills 的起点不是 API，不是 SDK，甚至不是 Web UI？答案很朴素：CLI 是唯一能让你在 3 秒内验证一个 skill 是否真正“完成”的环境。打开终端，输入一行命令，看到 JSON 输出或明确错误，整个过程不依赖网络、不依赖浏览器、不依赖任何中间服务。这种“裸机级”验证，是工程可靠性的第一道门槛。

举个真实案例：我们曾为某银行客户开发“信贷材料合规性初筛”skill。初期版本在 Postman 里调 API 看起来完美，但上线后批量处理时频繁超时。直到我们把它封装成 CLI：agent-skills credit-check --file ./loan_app_20240512.pdf，才在本地复现问题——原来 PDF 解析模块在无 GUI 环境下默认启用了一个图形渲染子进程，导致内存泄漏。这个 bug 在纯 API 测试中完全不可见，因为测试容器里恰好装了 headless Chrome。CLI 强制你暴露所有隐式依赖，逼你做真正的环境隔离。

提示：一个合格的 agent-skills CLI 必须支持--dry-run模式。它不调用真实模型，只打印将要发送的请求体、预期响应结构、预估 token 消耗。这是防止“API 调用失控”的安全阀。我要求团队每个新 skill 上线前，必须用--dry-run跑满 100 个不同输入样本，确保 schema 无歧义。

2.2 CLI 到 API 的映射不是简单包装，而是契约升维

很多团队的错误做法是：先写好 CLI，再用 Flask/FastAPI 包一层，加个/v1/skill/credit-check路由完事。这看似省事，实则埋下三重隐患：

• 错误传播失真：CLI 报错Error: PDF parsing failed (code=PDF_INVALID)，API 却返回{"error": "Internal Server Error"}，前端无法区分是文件问题还是服务宕机；
• 参数校验脱节：CLI 用argparse做了严格类型检查（如--amount必须是正浮点数），API 层却用宽松的request.json.get()，导致非法输入穿透到模型层；
• 可观测性断裂：CLI 可以精确记录命令执行耗时、token 使用量、缓存命中率，API 层若不做透传，这些关键指标就丢失了。

正确做法是：CLI 和 API 共享同一套核心逻辑模块，且共用同一份 OpenAPI 3.0 Schema 定义。我们采用pydantic+fastapi的组合，定义如下：

# schemas.py from pydantic import BaseModel, Field from typing import Optional class CreditCheckInput(BaseModel): file_path: str = Field(..., description="本地文件路径，仅 CLI 使用") file_url: Optional[str] = Field(None, description="远程文件 URL，仅 API 使用") amount: float = Field(gt=0, le=10000000, description="贷款金额，单位元") applicant_age: int = Field(ge=18, le=70, description="申请人年龄") class CreditCheckOutput(BaseModel): is_compliant: bool risk_score: float = Field(ge=0, le=100) issues: list[str] = Field(default_factory=list) used_tokens: int

CLI 的argparse参数解析器和 FastAPI 的路由处理器，都基于这份 Schema 自动生成。这样，当产品说“要加个applicant_income字段”，你只需改 Schema，CLI 自动获得新参数提示，API 自动更新文档和校验逻辑，测试用例也只需扩展输入样本——变更成本被锁死在单一源点。

2.3 CLI 的“可测试性”是 TDD 实施的物理基础

Test-Driven Development（TDD）在 AI 工程中常被诟病“不适用”，因为 LLM 输出不可预测。但 agent-skills 的 TDD 完全可行，关键在于：测试对象不是“模型输出”，而是“skill 的输入-输出契约”。CLI 提供了完美的测试靶场。

我们团队的标准 TDD 流程是：

1. 先写测试用例，描述期望行为（如：“当输入含伪造签名的 PDF，应返回 is_compliant=False 且 issues 包含 'signature_invalid'”）；
2. 运行pytest test_credit_check.py，必然失败（因为 skill 还没实现）；
3. 编写最简 CLI 实现，只做输入校验和固定 mock 输出；
4. 再运行测试，通过；
5. 逐步替换 mock 为真实模型调用，每步都确保测试不破。

这个过程之所以成立，是因为 CLI 的输入输出是确定的字符串流。你可以用subprocess.run捕获 CLI 执行结果，用json.loads解析输出，用assert断言字段值。我们有个内部脚本cli-test-runner，能自动扫描tests/cli/下所有.yaml测试定义文件，生成标准 pytest 用例。一个典型测试文件长这样：

# tests/cli/credit_check_invalid_signature.yaml command: agent-skills credit-check --file ./test_data/fake_sig.pdf expected_exit_code: 0 output_schema: is_compliant: false issues: - contains: "signature_invalid" used_tokens: gt: 100

这套机制让我们在模型提供商切换（比如从 DeepSeek 切到 Qwen）时，只需更新底层模型适配器，所有 CLI 测试用例依然全绿——因为契约没变，只是实现换了。这才是 TDD 在 AI 时代的真正价值：用接口契约锚定业务逻辑，让模型成为可插拔的实现细节。

3. 核心技能栈拆解：从 CLI 到前端 UI 的全链路实现

3.1 CLI 工程骨架：用 Typer 构建可维护的命令行应用

我们放弃argparse，全面采用 Typer ，原因很实际：它把命令行参数、子命令、类型提示、自动帮助文档、Shell 自动补全全部打包进一个声明式 API。更重要的是，它和 FastAPI 同源（同作者），共享pydantic生态，CLI 和 API 的代码复用率可达 90%。

一个典型的 agent-skills CLI 主干长这样：

# cli/main.py import typer from agent_skills.core import credit_check, summarize_meeting from agent_skills.schemas import CreditCheckInput, MeetingSummarizeInput app = typer.Typer( name="agent-skills", help="Enterprise-grade agent skills toolkit", no_args_is_help=True, ) @app.command() def credit_check( file: str = typer.Option(..., "--file", "-f", help="Path to loan application PDF"), amount: float = typer.Option(..., "--amount", help="Loan amount in CNY"), applicant_age: int = typer.Option(..., "--age", help="Applicant age"), dry_run: bool = typer.Option(False, "--dry-run", help="Show what would be sent, no API call"), ): """Perform initial compliance check on loan application.""" input_data = CreditCheckInput( file_path=file, amount=amount, applicant_age=applicant_age, ) result = credit_check.execute(input_data, dry_run=dry_run) typer.echo(result.model_dump_json(indent=2)) @app.command() def summarize_meeting( transcript: str = typer.Option(..., "--transcript", help="Meeting transcript text"), max_length: int = typer.Option(300, "--max-length", help="Max summary length in chars"), ): """Generate concise meeting summary.""" input_data = MeetingSummarizeInput(transcript=transcript, max_length=max_length) result = summarize_meeting.execute(input_data) typer.echo(result.model_dump_json(indent=2)) if __name__ == "__main__": app()

这段代码的价值远超表面：

• CreditCheckInput类型提示让 IDE 能自动补全参数名和类型；
• typer.Option(..., "--file", "-f")自动生成-h帮助文本，且--file和-f两种写法都支持；
• result.model_dump_json(indent=2)确保输出是标准 JSON，前端或脚本可直接jq解析；
• dry_run参数统一注入到所有 skill 执行逻辑中，无需每个函数单独处理。

注意：我们禁用 Typer 的callback机制，坚持每个@app.command()函数只做三件事：参数解析、调用核心逻辑、格式化输出。所有业务逻辑必须下沉到agent_skills.core模块。这是为了保证 CLI 只是“薄胶水层”，便于未来替换成其他 CLI 框架（如 Click）或彻底移除。

3.2 API 服务层：FastAPI + Redis 缓存的生产级实践

CLI 解决了本地验证，API 解决了多端集成。我们的 API 服务不是简单包装 CLI，而是构建一个具备企业级特性的能力网关。核心组件包括：

• 统一认证与配额：使用 JWT Bearer Token，每个 API Key 绑定用户 ID 和配额策略（如 “credit-check: 100 calls/day”）；
• 智能缓存：对幂等性 skill（如摘要、翻译），用 Redis 缓存input_hash -> output，缓存键包含模型版本号，避免模型升级导致缓存污染；
• 熔断降级：当 DeepSeek API 连续 5 次超时，自动切换到备用模型（如 Qwen），并记录告警；
• 审计日志：每条请求记录user_id,skill_name,input_hash,used_tokens,response_time_ms,is_cached。

关键代码片段（api/main.py）：

from fastapi import FastAPI, Depends, HTTPException, status from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials from redis import Redis import hashlib import json app = FastAPI(title="Agent Skills API Gateway") security = HTTPBearer() redis_client = Redis(host="redis", port=6379, db=0) @app.post("/v1/skill/credit-check") async def api_credit_check( input_data: CreditCheckInput, credentials: HTTPAuthorizationCredentials = Depends(security), ): # 1. 认证 user_id = verify_jwt(credentials.credentials) # 2. 配额检查（伪代码，实际调用配额服务） if not quota_service.check(user_id, "credit-check", 1): raise HTTPException(status_code=429, detail="Rate limit exceeded") # 3. 缓存键：包含输入内容、模型版本、技能版本 cache_key = hashlib.md5( json.dumps({ "input": input_data.model_dump(), "model": "deepseek-v4-pro", "skill_version": "1.2.0" }, sort_keys=True).encode() ).hexdigest() # 4. 尝试缓存读取 cached = redis_client.get(cache_key) if cached: return json.loads(cached) # 5. 执行核心逻辑（复用 CLI 的 same function） result = credit_check.execute(input_data, model="deepseek-v4-pro") # 6. 写入缓存（TTL 1小时，因信贷政策可能每日更新） redis_client.setex(cache_key, 3600, result.model_dump_json()) return result

这里的关键洞察是：缓存策略必须和业务语义对齐。信贷审核结果缓存 1 小时合理，因为政策不会每分钟变；但会议摘要缓存 5 分钟就够了，因为参会人可能马上发新消息。我们用skill_name作为配置项，在config.yaml中定义每个 skill 的默认 TTL，运维可热更新。

3.3 前端集成：React Hook 封装与 UI 工程化实践

前端工程师常抱怨：“后端给的 API 文档太抽象，不知道怎么用”。我们的解法是：为每个 skill 提供开箱即用的 React Hook，把 API 调用、错误处理、加载状态、缓存管理全部封装好，业务组件只需关注 UI 渲染。

以useCreditCheckHook 为例（src/hooks/useCreditCheck.ts）：

import { useState, useCallback } from 'react'; import { CreditCheckInput, CreditCheckOutput } from '../types'; import { apiClient } from '../lib/apiClient'; export const useCreditCheck = () => { const [data, setData] = useState<CreditCheckOutput | null>(null); const [loading, setLoading] = useState(false); const [error, setError] = useState<string | null>(null); const execute = useCallback(async (input: CreditCheckInput) => { setLoading(true); setError(null); try { // 1. 文件转 base64（前端处理，避免后端解析压力） const fileContent = await readFileAsBase64(input.file); // 2. 调用 API（自动携带 auth token） const response = await apiClient.post<CreditCheckOutput>( '/v1/skill/credit-check', { ...input, file_content: fileContent } ); setData(response.data); return response.data; } catch (err) { const msg = err instanceof Error ? err.message : 'Unknown error'; setError(msg); throw err; } finally { setLoading(false); } }, []); return { data, loading, error, execute }; }; // 业务组件中使用 function LoanApplicationForm() { const { data, loading, error, execute } = useCreditCheck(); const handleSubmit = async (e: React.FormEvent) => { e.preventDefault(); await execute({ file: (e.target as any).file_input.files[0], amount: parseFloat((e.target as any).amount.value), applicant_age: parseInt((e.target as any).age.value), }); }; return ( <div> <form onSubmit={handleSubmit}> <input type="file" name="file_input" /> <input name="amount" placeholder="Amount" /> <input name="age" placeholder="Age" /> <button type="submit">Check Compliance</button> </form> {loading && <p>Checking...</p>} {error && <p className="error">Error: {error}</p>} {data && ( <div className="result"> <h3>Compliance Result</h3> <p>Status: {data.is_compliant ? '✅ Approved' : '❌ Rejected'}</p> <p>Risk Score: {data.risk_score}/100</p> {data.issues.length > 0 && ( <ul> {data.issues.map((issue, i) => <li key={i}>{issue}</li>)} </ul> )} </div> )} </div> ); }

这个 Hook 的价值在于：

• 错误分类明确：网络错误、401 认证失败、429 配额超限、400 输入错误，每种都有不同 UI 反馈策略；
• 加载状态粒度细：loading只在 API 请求中为 true，文件读取阶段不干扰；
• 缓存透明：如果 API 返回X-Cache: HIT，Hook 自动设置data并跳过 loading；
• TypeScript 驱动：CreditCheckInput和CreditCheckOutput类型来自后端pydanticSchema 的自动生成（用datamodel-codegen工具），前后端类型 100% 一致。

实操心得：我们禁止业务组件直接调用fetch。所有 API 调用必须经过统一apiClient，它内置了：自动 token 注入、401 重定向登录、429 指数退避重试、请求/响应日志（仅 dev 环境）。一个团队从接入第一个 skill 到全量迁移，只花了 2 天培训，因为 Hook API 极其简单。

3.4 测试驱动开发：用 Pytest 构建不可绕过的质量门禁

TDD 在 agent-skills 中不是理想主义，而是生存必需。我们要求：每个新 skill 合并前，必须通过三类测试：

一个典型的集成测试（tests/integration/test_credit_check_api.py）：

import pytest import httpx from agent_skills.schemas import CreditCheckInput @pytest.mark.integration def test_credit_check_api_success(): # 使用沙箱模型 endpoint（返回预设响应） client = httpx.Client(base_url="http://localhost:8000") # 构造合法输入 input_data = CreditCheckInput( file_url="https://example.com/test_valid.pdf", amount=50000.0, applicant_age=35, ) response = client.post( "/v1/skill/credit-check", json=input_data.model_dump(), headers={"Authorization": "Bearer test-token"} ) assert response.status_code == 200 data = response.json() # 断言输出结构（非内容，是契约！） assert "is_compliant" in data assert isinstance(data["is_compliant"], bool) assert "risk_score" in data assert 0 <= data["risk_score"] <= 100 assert "used_tokens" in data assert isinstance(data["used_tokens"], int) @pytest.mark.integration def test_credit_check_api_validation_error(): client = httpx.Client(base_url="http://localhost:8000") # 构造非法输入：amount 为负数 invalid_input = {"amount": -1000, "applicant_age": 35, "file_url": "x"} response = client.post( "/v1/skill/credit-check", json=invalid_input, headers={"Authorization": "Bearer test-token"} ) assert response.status_code == 422 # FastAPI 自动返回 422 assert "amount" in response.text.lower() # 错误信息包含字段名

关键点在于：测试不关心模型是否“聪明”，只关心它是否“守规矩”。即使今天用 DeepSeek，明天换 Claude，只要输出 JSON 符合CreditCheckOutputSchema，所有测试就全绿。这让我们敢于在模型提供商之间做 A/B 测试，而不必重写测试用例。

4. 实战部署与运维：Docker、K8s 与可观测性体系

4.1 Docker 镜像分层：构建可复现、可审计的生产环境

我们拒绝“一个 Dockerfile 打天下”。agent-skills 服务采用三层镜像架构：

Dockerfile.skill.credit-check示例：

# syntax=docker/dockerfile:1 FROM our-registry/runtime:2.4.1 # 复制 skill 代码（只复制必要文件，避免 .git 泄露） COPY pyproject.toml poetry.lock ./ COPY agent_skills/core/credit_check.py /app/agent_skills/core/ COPY agent_skills/schemas.py /app/agent_skills/ # 安装 skill 特定依赖（如 pdfminer） RUN poetry install --no-dev # 设置启动命令（CLI 和 API 共用入口） CMD ["uvicorn", "api.main:app", "--host", "0.0.0.0:8000", "--port", "8000"]

这种分层带来三大好处：

• 构建速度快：base 和 runtime 层在 CI 中缓存，每次 PR 只需构建 skill 层，平均 23 秒；
• 漏洞扫描准：Trivy 扫描 base 镜像即可覆盖所有 skill，不用每个镜像单独扫；
• 回滚可靠：runtime 层升级出问题，只需将所有 skill 镜像 tag 回退到上一版 runtime，无需修改业务代码。

注意：我们禁用pip install -r requirements.txt，坚持用poetry管理依赖。因为poetry.lock锁定了每个包的 exact version 和 hash，确保pip install在任何机器上产生的依赖树 100% 一致。这是避免“在我机器上能跑”陷阱的基石。

4.2 Kubernetes 部署：按 skill 优先级调度资源

在 K8s 中，我们不把所有 skill 部署在一个 Deployment 里。每个 skill 独立 Deployment，并配置差异化资源策略：

关键配置（k8s/credit-check-deployment.yaml）：

apiVersion: apps/v1 kind: Deployment metadata: name: agent-skills-credit-check spec: replicas: 2 selector: matchLabels: app: agent-skills-credit-check template: metadata: labels: app: agent-skills-credit-check spec: priorityClassName: high-priority containers: - name: api image: our-registry/agent-skills-credit-check:v1.2.0 resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 1Gi env: - name: MODEL_PROVIDER value: "deepseek-official" - name: DEEPSEEK_API_KEY valueFrom: secretKeyRef: name: deepseek-api-keys key: prod-key ports: - containerPort: 8000 # 关键：健康检查必须反映 skill 真实状态 livenessProbe: httpGet: path: /healthz?skill=credit-check port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz?skill=credit-check port: 8000 initialDelaySeconds: 5 periodSeconds: 5

/healthz?skill=credit-check端点会执行一个轻量级检查：尝试用deepseek-flash模型处理一个 10 字符的 dummy 输入，验证 API 连通性和密钥有效性。这比单纯检查进程存活更有意义——它确保 skill 在当前配置下确实可用。

4.3 可观测性体系：用 Prometheus + Grafana 看清每个 skill 的脉搏

我们不监控“服务是否在线”，而是监控“每个 skill 的契约履约率”。核心指标全部打上skill_name、model_provider、http_status标签：

Grafana 看板必备面板：

• 契约健康度仪表盘：显示每个 skill 的output_schema_violation_total24h 趋势，绿色表示 0，红色表示有违约；
• 模型成本分析图：按model_provider和skill_name分组的token_usage_total，帮产品决策哪个 skill 该优化 prompt；
• 错误根因透视表：点击http_status="400"，下钻查看具体是哪个字段校验失败（如amount_invalid占比 80%），直接定位前端表单缺陷。

一次真实故障复盘：某天credit-check的output_schema_violation_total突然飙升。下钻发现全是risk_score字段超出0-100范围。排查发现是 DeepSeek 新版模型在极端 case 下返回100.5。我们立刻在CreditCheckOutputSchema 中将risk_score的约束从le=100放宽到le=100.5，并发布 hotfix。整个过程从告警到修复不到 12 分钟，因为指标精准定位到了问题字段。

5. 常见问题与实战排障指南

5.1 “API Error: 400 The supported API model names are deepseek-flash, deepseek-v4” —— 模型名硬编码陷阱

现象：CLI 或 API 调用返回 400，错误信息明确列出支持的模型名，但你的代码里写的是deepseek-v4-pro。

根因：DeepSeek 官方 API 的模型名是动态演进的。deepseek-v4-pro是某个灰度环境的内部名，生产环境只认deepseek-v4。更糟的是，你的代码里把模型名写死在字符串里，而不是从配置中心读取。

解决方案：

1. 立即行动：在config.yaml中定义模型别名映射：

   model_providers: deepseek-official: aliases: v4-pro: "deepseek-v4" # 生产环境映射 flash: "deepseek-flash"

2. 代码改造：所有模型名引用改为config.get_model_name("deepseek-official", "v4-pro")；
3. 防御性编程：在模型调用前，添加预检：

   def validate_model_name(provider: str, alias: str): real_name = config.get_model_name(provider, alias) if real_name not in config.SUPPORTED_MODELS[provider]: logger.warning(f"Model alias '{alias}' resolved to '{real_name}', but it's not in supported list. Falling back to 'flash'.") return config.get_model_name(provider, "flash") return real_name

实操心得：我们要求所有新 skill 的 PR 必须附带一份model-compatibility-matrix.csv，列出已测试的模型名、版本、token 限制、响应速度。这张表由 CI 自动更新，避免人工记忆错误。

5.2 “Failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen” —— Windows Docker Desktop 权限问题

现象：在 Windows 上运行docker build时，报错连接不到 Docker daemon，路径看起来像 Linux 的命名管道。

根因：Docker Desktop for Windows 默认使用 WSL2 后端，但某些旧版安装或权限设置会导致命名管道路径错乱。错误信息里的npipe:////./pipe/dockerdesktoplinuxen是一个已知的路径拼接 bug。

解决方案：

1. 重启 Docker Desktop：右键任务栏图标 → “Restart Docker Desktop”；
2. 检查 WSL2 状态：在 PowerShell 中运行wsl -l -v，确认docker-desktop-data和docker-desktop两个发行版状态为Running；
3. 重置 Docker Engine：Docker Desktop 设置 → Resources → WSL Integration → 取消勾选所有发行版，Apply & Restart，再重新勾选；
4. 终极方案：如果仍失败，在项目根目录创建.dockerignore，内容为：

   node_modules __pycache__ .git

   然后用docker build --platform linux/amd64 -t my-skill .显式指定平台，绕过 WSL2 问题。

注意：这个错误 99% 发生在开发者本地，不影响 CI/CD。我们的 CI 使用 Ubuntu runner，完全规避此问题。

5.3 “Login failed. Check API token or GitLab version.” —— 多身份认证冲突

现象：在 CI 环境中，agent-skills 调用需要 GitLab API 的 skill（如自动创建 MR）时，报登录失败，但 token 明明正确。

根因：你的 CLI 同时集成了多个服务商（GitLab、DeepSeek、飞书），它们都试图读取环境变量GITLAB_TOKEN、DEEPSEEK_API_KEY、FEISHU_APP_ID。当 CI 系统（如 GitLab CI）注入GITLAB_TOKEN时，它可能是一个短期 token，而 skill 代码错误地用它去调 DeepSeek API，导致 401。

解决方案：

1. 环境变量命名规范化：强制所有 token 环境变量以AGENT_SKILLS_开头：
   • AGENT_SKILLS_GITLAB_TOKEN
   • AGENT_SKILLS_DEEPSEEK_API_KEY
   • AGENT_SKILLS_FEISHU_APP_ID
2. Token 加载器隔离：创建auth/token_loader.py，按 provider