企业官网建设流程全解析

1. 什么是 Harness？它不是另一个“AI Coding 工具”，而是企业级代码生成的工程底座

你可能已经看过太多标题：《用 Copilot 写完一个 CRUD》《Claude 自动生成测试用例》《Cursor 搞定前端组件》——这些确实有用，但它们解决的是“单点提效”，不是“系统性交付”。而今天要聊的Harness，不是插件、不是 IDE 扩展、更不是某个大模型的 API 封装。它是我在过去三年里，带团队落地 7 个中大型 AI Coding 项目后，唯一敢称之为“工程底座”的技术栈。

简单说：Harness 是一套可编排、可验证、可审计、可灰度的AI 编程行为执行框架。它不直接写代码，而是定义“谁在什么上下文、用什么能力、按什么规则、产出什么产物、经过什么校验”的完整契约。就像工厂里的自动化产线控制系统——机械臂（LLM）负责执行，Harness 负责调度、质检、防错、溯源、换模。

为什么必须强调“企业级”？因为真实业务场景里，你不会只面对一个 prompt 和一个 response。你会遇到：

• 同一个需求，在开发环境用 DeepSeek-Coder 生成，在测试环境必须用 CodeLlama-70B 校验逻辑一致性；
• 生成的 SQL 必须通过静态扫描（SQLFluff）、动态脱敏（MockDB）、权限白名单（RBAC Schema）三重拦截；
• 前端组件生成后，要自动注入 E2E 测试桩、埋点字段、无障碍语义标签，并触发 Storybook 快照比对；
• 当 LLM 输出异常时（比如循环生成 import、空函数体、硬编码密钥），系统不能报错退出，而要降级到规则引擎 fallback，或触发人工审核队列。

这些，都不是靠调一次 API 能解决的。它们需要状态管理、流程编排、能力注册、上下文隔离、结果契约化——而这正是 Harness 的核心价值。它把 AI 编程从“魔法黑盒”变成“可配置流水线”，把 Skill（技能）从“一段 prompt”升级为“带输入契约、输出 Schema、执行约束、失败策略的原子能力单元”。

我第一次在客户现场看到 Harness 生效，是在某银行核心账务系统重构项目。他们要求所有 AI 生成的 Java Service 层代码，必须满足：① 方法签名符合 OpenAPI v3 定义；② 所有 DAO 调用必须包裹在 @Transactional 注解内；③ 异常分支必须显式 throw BizException（而非 RuntimeException）；④ 日志必须包含 traceId 和 bizCode。传统做法是靠 Code Review 卡点，平均每个 PR 耗时 4.2 小时。接入 Harness 后，这四条规则被固化为 4 个 Skill 的 output validator，AI 生成即校验，92% 的代码一次通过 CI，Review 时间压缩到 23 分钟/PR。这不是“让 AI 更聪明”，而是“让工程约束更刚性”。

所以，请先放下“又一个 AI 编程工具”的预设。Harness 的本质，是把 AI 的不确定性，装进确定性的工程容器里。它不替代工程师，而是把工程师从“人肉守门员”解放为“规则设计师”和“Skill 架构师”。接下来，我会用真实项目中的 8 个 Skill，带你走完这条全链路——不是概念演示，而是每一步都踩过坑、配过参数、压过测、上过线的实战路径。

2. Skill 不是 Prompt，而是带契约的可执行单元：从定义、注册到上下文隔离的完整生命周期

很多团队一上来就问：“怎么写一个 Skill？” 然后掏出一个 JSON 文件，里面塞满 system prompt、few-shot examples、temperature=0.3……结果跑起来要么漏字段，要么格式错乱，要么在不同环境输出不一致。问题不在模型，而在对 Skill 的认知偏差——Skill 不是 prompt 的容器，而是带输入/输出契约、执行约束、生命周期管理的可部署单元。

我们以最典型的 “SQL Generator Skill” 为例，拆解它在 Harness 中的真实形态：

2.1 输入契约（Input Contract）：强制结构化，杜绝模糊指令

传统 prompt 可能这样写：

“根据用户需求生成 MySQL 查询语句，注意安全。”

Harness 要求你明确定义输入 Schema：

{ "type": "object", "properties": { "business_context": { "type": "string", "description": "业务场景描述，如'查询近30天VIP用户订单量'" }, "data_source": { "type": "string", "enum": ["user_db", "order_db", "log_db"], "description": "目标数据库标识" }, "required_fields": { "type": "array", "items": { "type": "string" }, "minItems": 1, "description": "必须返回的字段列表，如 ['user_id', 'order_count']" }, "filters": { "type": "object", "properties": { "date_range": { "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}:\\d{4}-\\d{2}-\\d{2}$" }, "status": { "type": "string", "enum": ["active", "inactive", "all"] } } } }, "required": ["business_context", "data_source", "required_fields"] }

这个 Schema 不是摆设。Harness 在 Skill 执行前会做严格校验：如果传入{"business_context":"查VIP订单","data_source":"user_db"}（缺required_fields），直接拒绝执行，返回400 Bad Request并附带缺失字段提示。这避免了 LLM 因输入残缺而胡编乱造。

提示：我们曾在线上环境发现，前端传参时因 JavaScript 对象序列化丢失空数组，导致required_fields: []变成required_fields: undefined。Harness 的 Schema 校验第一时间捕获，而不是让 LLM 输出SELECT * FROM users这种高危语句。

2.2 执行约束（Execution Constraints）：控制风险边界的硬性护栏

一个 Skill 的执行，必须受控于明确的边界条件。Harness 支持以下关键约束：

特别强调output_format: "sql"：它不是简单检查字符串是否以SELECT开头。Harness 会调用sqlglot库对输出进行语法树解析，验证：① 是否存在未声明的表别名；② WHERE 子句是否包含OR且无括号包裹（易引发逻辑错误）；③ LIMIT 是否被设置（防全表扫描）。只有通过 AST 校验的 SQL 才视为有效输出。

2.3 上下文隔离（Context Isolation）：让 Skill 在沙箱中运行，互不污染

这是企业级落地最关键的细节。多个 Skill 可能同时运行，共享同一个 LLM 实例，但它们的上下文必须严格隔离。Harness 采用三层隔离机制：

1. Prompt Context Layer：每个 Skill 的 system prompt + few-shot examples 被封装为独立模板，执行时动态注入，不与全局 prompt 混合；
2. State Context Layer：Skill 可声明stateful: true，Harness 为其分配独立内存空间存储临时状态（如“当前已生成的 JOIN 表列表”），其他 Skill 无法访问；
3. Execution Context Layer：底层 LLM 调用时，Harness 自动注入context_idheader，后端服务据此路由到专属推理实例（如 Kubernetes 中的 dedicated pod），物理隔离资源。

我们曾在一个电商项目中，同时启用ProductRecommendationSkill（需实时用户画像）和InventoryCheckSkill（需强一致性库存快照）。若无上下文隔离，两个 Skill 共享的 LLM 可能将用户画像缓存误用于库存计算，导致推荐结果污染库存判断。启用隔离后，问题彻底消失。

2.4 注册与发现（Registration & Discovery）：让 Skill 成为可复用的“工程资产”

Skill 不是写完就扔的脚本。Harness 提供统一注册中心（基于 etcd），每个 Skill 注册时必须提供：

• skill_id: 全局唯一标识（如sql-gen-v2-strict）
• version: 语义化版本（1.2.0）
• tags: 业务标签（["finance", "read-only"]）
• health_check_url: 健康探针（Harness 定期调用，验证 Skill 是否就绪）

注册后，其他模块可通过GET /skills?tag=finance&version=^1.2.0发现并调用。这使得 Skill 可被：

• CI/CD 流水线自动部署（新版本注册即生效，旧版本自动下线）；
• 权限系统管控（RBAC 规则可精确到skill_id）；
• 监控平台追踪（每个 Skill 的 P95 延迟、错误率、token 消耗独立统计）。

注意：我们踩过的最大坑是版本兼容性。某次升级sql-gen到1.3.0，新增了explain_plan字段。但下游的QueryOptimizerSkill仍按1.2.0Schema 解析，导致 JSON 解析失败。解决方案是 Harness 强制要求：所有 Skill 必须提供 backward-compatible schema migration script，并在注册时执行验证。现在，任何不兼容变更都会被注册中心拒绝。

3. 全链路八 Skill 实战：从需求解析到生产发布，每个环节如何用 Skill 构建确定性

标题里说的“8 个 Skill”，不是凑数，而是我们为某保险科技客户构建 AI Coding 全链路时，真正上线并稳定运行的八个原子能力。它们覆盖了从原始需求输入到最终代码部署的完整闭环，每个 Skill 都经过至少 3 轮压力测试和 2 次线上灰度。下面按实际执行顺序展开，重点讲清每个 Skill 的设计动机、技术选型依据、以及那些文档里绝不会写的实操细节。

3.1 RequirementParserSkill：把自然语言需求，变成可编程的结构化任务

为什么需要它？
直接让 LLM 处理“帮我写个保单查询接口”这种模糊需求，错误率高达 67%（我们内部统计）。原因在于：LLM 会自行脑补业务规则（如默认返回所有字段）、忽略非功能需求（如性能 SLA）、混淆领域术语（“保单”在核保和理赔中含义不同）。

核心设计：

• 输入：原始需求文本 + 业务知识图谱 ID（如insurance-domain-v3.1）
• 输出：JSON Schema 严格定义的TaskDefinition对象，包含：

  { "api_endpoint": "/v1/policies/{policy_id}", "http_method": "GET", "response_schema": { "$ref": "#/components/schemas/PolicyDetail" }, "performance_sla": { "p95_ms": 200, "max_concurrent": 1000 }, "security_requirements": ["oauth2", "field_level_encryption"] }

技术实现细节：

• 不用通用大模型，而是微调一个7B 参数的 Domain-Specific LLM（基于 Qwen2），仅训练保险领域 2000+ 条标注样本。理由：通用模型在“核保规则”“理赔时效”等术语上准确率不足 40%，微调后达 92%；
• 使用RAG 增强：实时检索内部 Confluence 的《核保业务手册 V4.2》，将相关条款作为 context 注入 prompt，避免 LLM 虚构规则；
• 双校验机制：LLM 输出后，启动一个轻量级规则引擎（Drools），校验response_schema是否符合公司 OpenAPI 规范（如禁止anyOf，强制required字段存在）。只有两者都通过才返回。

实操心得：最初我们尝试用 GPT-4 做 parsing，成本高且不稳定。切换到自研微调模型后，单次解析成本下降 83%，P99 延迟从 3.2s 降至 0.8s。关键是——在确定性要求高的环节，永远优先选择可控的小模型，而非不可控的大模型。

3.2 ApiContractGeneratorSkill：自动生成 OpenAPI 3.0 规范，驱动前后端并行开发

为什么需要它？
传统方式由架构师手写 Swagger YAML，平均耗时 4.5 小时/接口，且常出现前后端理解偏差（如date字段是 ISO8601 还是 timestamp）。AI 生成后，Harness 强制校验其合规性。

核心设计：

• 输入：TaskDefinition（来自上一 Skill）
• 输出：标准 OpenAPI 3.0 YAML，且必须通过swagger-cli validate

技术实现细节：

• 模型选型：DeepSeek-Coder-33B-Instruct。原因：它在代码生成类任务上对 YAML 结构的保持能力最强（对比测试中，CodeLlama-70B 有 12% 概率漏掉components/schemas下的$ref）；
• 关键约束：output_format: "openapi-yaml"，Harness 内置校验器会：
  1. 解析 YAML 为 JSON；
  2. 检查所有$ref是否指向存在的 components；
  3. 验证securitySchemes是否与公司 SSO 配置匹配（调用内部 Auth API）；
  4. 确保x-codegen扩展属性存在（标记此 spec 由 AI 生成，触发后续代码生成流程）。

避坑经验：
我们曾发现，当TaskDefinition中performance_sla.max_concurrent> 5000 时，模型会错误地在x-rate-limit中写入10000（超出网关配置上限）。解决方案是：在 Skill 执行前，Harness 自动注入一个Pre-Execution Hook，对输入做业务规则校验（max_concurrent <= 5000），超限则拒绝并返回建议值。

3.3 BackendCodeGeneratorSkill：生成 Spring Boot Controller + Service + DTO，带完整注释和单元测试骨架

为什么需要它？
不是生成“能跑就行”的代码，而是生成“符合公司 Java 编码规范、可直接进入 CR 流程”的代码。重点在于：注释质量、异常处理模式、日志规范、测试覆盖率要求。

核心设计：

• 输入：OpenAPI YAML + 公司 Java 规范 ID（java-standards-v2.4）
• 输出：ZIP 包含：
  • Controller.java（带@Valid、@RequestHeader("X-Trace-ID")）
  • Service.java（事务边界、BizException 抛出）
  • DTO.java（Lombok +@Schema注解）
  • ControllerTest.java（MockMvc + 断言响应结构）

技术实现细节：

• 模板引擎：Jinja2 + 自定义 Filter。例如{{ field.type | to_java_type }}将string转为String，integer转为Long；
• 注释生成：使用CodeT5+ 微调模型（专训 JavaDoc 生成），而非通用 LLM。实测 JavaDoc 准确率从 58% 提升至 89%；
• 单元测试骨架：固定模板 + LLM 填充业务断言。例如：

  // LLM 生成的断言部分 assertThat(response.getBody()).extracting("policyNumber", "status") .containsExactly("POL-2024-001", "ACTIVE");

关键技巧：我们给每个 DTO 字段添加了@ApiModelProperty(required = true)，但 LLM 常漏掉required = true。解决方案是 Harness 在生成后启动Post-Processing Script，用 AST 解析器（JavaParser）扫描所有@ApiModelProperty，自动补全缺失的required属性。这比让 LLM 学习更可靠。

3.4 FrontendComponentGeneratorSkill：生成 React 组件，强制包含 Storybook、TypeScript 类型、无障碍标签

为什么需要它？
前端同学最反感“AI 生成的组件没类型、没测试、没可访问性”。此 Skill 的目标是：生成即可用，无需人工补漏。

核心设计：

• 输入：OpenAPI/components/schemas/PolicyDetail定义
• 输出：React 组件目录，含：
  • PolicyDetailCard.tsx（TSX + PropTypes + JSDoc）
  • PolicyDetailCard.stories.tsx（Storybook，含argTypes控制 props）
  • PolicyDetailCard.test.tsx（RTL 测试，断言aria-label存在）

技术实现细节：

• 模型：StarCoder2-15B。它在前端生态（尤其是 TypeScript JSX）的 token 预测准确率最高；
• 强制注入：所有组件开头必须有// @generated-by-harness注释，CI 流水线据此识别 AI 生成代码，跳过人工 CR，直入自动化测试；
• 无障碍保障：Harness 内置规则库，校验生成代码是否包含：
  • <button>必有aria-label或children；
  • <input>必有aria-labelledby；
  • 所有颜色对比度 ≥ 4.5:1（调用axe-coreCLI 扫描）。

血泪教训：
初期生成的组件，<div className="card">没有语义化标签，屏幕阅读器无法识别。我们不是去改 prompt，而是让 Harness 在生成后自动运行a11y-fix script：用 Cheerio 解析 HTML，为无语义的div添加role="region"和aria-labelledby。现在，100% 的 AI 生成组件通过 axe 扫描。

3.5 SqlMigrationGeneratorSkill：生成 Flyway 兼容的 SQL 迁移脚本，带数据校验逻辑

为什么需要它？
AI 生成 DDL 很容易，但生成安全、可回滚、带数据校验的迁移脚本极难。此 Skill 的核心是：把数据库变更当作“有状态操作”来管理。

核心设计：

• 输入：TaskDefinition中的data_source+ 新增字段定义
• 输出：FlywayV1_2_0__add_policy_status.sql，含：

  -- !Ups ALTER TABLE policies ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'DRAFT'; UPDATE policies SET status = 'ACTIVE' WHERE created_at > '2024-01-01'; -- !Downs ALTER TABLE policies DROP COLUMN status;

技术实现细节：

• 模型：SQLCoder-7B（专为 SQL 优化的模型），在 DDL 生成任务上 F1-score 达 94%；
• 关键创新：生成后自动注入数据校验 SQL。Harness 解析!Ups部分，识别出ADD COLUMN，则自动追加：

  -- !Verify SELECT COUNT(*) FROM policies WHERE status IS NULL; -- Expected: 0

  Flyway 执行时，会先运行!Verify，失败则中断迁移；
• 版本控制：每个 Skill 生成的 SQL 脚本，Harness 自动注入-- Generated by Skill: sql-migration-v1.1和时间戳，便于审计。

实操提醒：MySQL 和 PostgreSQL 的ALTER TABLE语法差异巨大。我们为每个data_source配置了专属的Database Adapter，Skill 执行时自动加载对应方言模板，避免生成ADD COLUMN ... FIRST（MySQL）被 PostgreSQL 拒绝。

3.6 SecurityScannerSkill：对生成代码做静态扫描，拦截硬编码密钥、SQL 注入、XSS 漏洞

为什么需要它？
AI 生成的代码，漏洞密度是人工代码的 3.2 倍（SonarQube 数据）。此 Skill 不是“锦上添花”，而是生产发布的强制闸门。

核心设计：

• 输入：Backend/Frontend 生成的代码 ZIP
• 输出：ScanReport.json，含：
  • critical_issues: 硬编码密钥、反序列化漏洞
  • high_issues: SQL 拼接、dangerouslySetInnerHTML
  • medium_issues: 密码明文传输、CORS 配置宽松

技术实现细节：

• 工具链：组合扫描，非单一工具：
  • gitleaks：检测密钥（自定义规则：匹配AKIA[0-9A-Z]{16}）；
  • semgrep：检测 Java 中的Statement.executeQuery("SELECT * FROM " + input)；
  • eslint-plugin-react：检测 React 中的 XSS 风险；
• Harness 的增强：扫描结果自动映射到原始 Skill 输入。例如，若BackendCodeGeneratorSkill生成的Service.java有 SQL 拼接，报告会标注：

  "origin_skill": "backend-code-gen-v3.2", "input_task_id": "TASK-2024-08765"

  便于追溯是哪个 Skill 的 prompt 或模板出了问题。

关键配置：
我们禁用了所有low级别告警（如未使用的 import），只保留critical/high。理由：AI 生成代码的medium问题太多，会淹没真正风险。宁可放过 10 个 medium，不错放 1 个 critical。

3.7 IntegrationTestGeneratorSkill：生成 Pact 合约测试，保障微服务间接口契约

为什么需要它？
微服务架构下，AI 生成的 Provider（服务端）代码，必须与 Consumer（调用方）的期望严格一致。此 Skill 生成Consumer-Driven Contracts，而非传统单元测试。

核心设计：

• 输入：OpenAPI YAML + Consumer 服务名（如policy-frontend）
• 输出：Pact 文件policy-service-pact.json，定义：

  { "consumer": {"name": "policy-frontend"}, "provider": {"name": "policy-service"}, "interactions": [{ "description": "get policy detail", "request": {"method": "GET", "path": "/v1/policies/123"}, "response": {"status": 200, "body": {"policyNumber": "POL-2024-001"}} }] }

技术实现细节：

• 模型：微调的 CodeLlama-13B，专训 Pact DSL 生成；
• Harness 的深度集成：生成 Pact 后，自动触发pact-broker发布，并运行pact-provider-verifier验证 Provider 是否满足契约；
• 失败即阻断：若验证失败，Harness 返回422 Unprocessable Entity，CI 流水线立即停止，不进入部署阶段。

真实体验：某次 AI 生成的 Controller 返回了{"policy_number": "POL-2024-001"}（snake_case），但前端契约要求policyNumber（camelCase）。Pact 验证失败，Harness 拦截。我们没去改代码，而是调整了BackendCodeGeneratorSkill的模板，强制使用 Jackson@JsonProperty注解。这就是 Harness 的价值——用契约倒逼 Skill 质量提升。

3.8 DeploymentPlanGeneratorSkill：生成 Argo CD Application YAML，含金丝雀发布策略和回滚预案

为什么需要它？
AI 生成的代码，最终要安全地上线。此 Skill 不是生成kubectl apply，而是生成声明式的、可审计的、带熔断机制的发布计划。

核心设计：

• 输入：TaskDefinition+ 环境标识（prod-canary）
• 输出：Argo CDApplication.yaml，含：
  • spec.source.path: 指向 Harness 生成的 Helm Chart 目录；
  • spec.syncPolicy.automated.prune:true（自动清理旧资源）；
  • spec.syncPolicy.automated.selfHeal:true（自动修复 drift）；
  • spec.healthCheck: 自定义健康检查脚本（调用/actuator/health）；

技术实现细节：

• 关键创新：动态生成金丝雀策略。根据TaskDefinition.performance_sla.p95_ms，自动设置：
  • 若< 100ms：金丝雀流量 5% → 20% → 100%，每步等待 2 分钟；
  • 若100-500ms：金丝雀流量 1% → 5% → 20% → 100%，每步等待 5 分钟；
• 回滚预案：Harness 自动生成rollback-manifest.yaml，包含上一版本的全部 Helm values，并注入preSynchook：

  hooks: - name: pre-sync-check command: [sh, -c] args: ["curl -sf http://policy-service:8080/actuator/health | grep -q 'UP' || exit 1"]

终极保障：
所有 Deployment Plan 必须通过argo cd app diff预检，Harness 会模拟应用 diff，若发现replicas: 3→replicas: 10这类突变，自动拒绝并告警。这避免了 AI 因理解偏差导致的爆炸性扩缩容。

4. 工程实战的硬核细节：Windows 网关、RabbitMQ 路由、Linux 部署、MySQL 主从同步的全链路配置

标题里提到的“Windows 网关 + RabbitMQ + Linux + MySQL 全链路”，不是噱头，而是我们为某制造业客户落地时的真实拓扑。它解决了企业最痛的三个问题：① 内网开发机（Windows）无法直连生产 LLM 服务；② 高并发请求需削峰填谷；③ 生产环境必须满足等保三级对数据库主从分离的要求。下面拆解每个环节的配置要点和避坑指南。

4.1 Windows 网关层：用 Nginx 做协议转换与认证代理，而非直接暴露 Harness API

为什么不用直接调用？
客户开发机全是 Windows，且禁止安装 Docker。Harness 服务部署在 Linux 集群，直接调用需处理：

• Windows TLS 1.2 兼容性问题（老版 .NET Framework）；
• 企业 AD 域账号认证（非 JWT）；
• 请求体大小限制（上传 OpenAPI YAML 可能 > 10MB）。

解决方案：Nginx 作为反向代理网关

# nginx.conf upstream harness_backend { server 10.20.30.40:8080; # Harness API Server } server { listen 8081 ssl; server_name harness-gateway.internal; # SSL 配置（使用企业 CA 签发的证书） ssl_certificate /etc/nginx/certs/gateway.crt; ssl_certificate_key /etc/nginx/certs/gateway.key; # AD 集成认证（通过 Kerberos） auth_gss on; auth_gss_realm INTERNAL.CORP; auth_gss_keytab /etc/nginx/krb5.keytab; # 协议转换：将 Windows 认证头转为 Harness 接受的 Bearer Token location /api/ { proxy_pass https://harness_backend/; proxy_set_header Authorization "Bearer $remote_user"; proxy_set_header X-Forwarded-For $remote_addr; client_max_body_size 50M; # 支持大文件上传 } }

关键配置说明：

• auth_gss启用 Kerberos 认证，开发人员用域账号登录 Windows 后，浏览器自动携带 SPNEGO token，Nginx 解析后提取用户名；
• proxy_set_header Authorization "Bearer $remote_user"将域用户名转为 Harness 的简易 Token（Harness 后端有对应校验逻辑）；
• client_max_body_size 50M解决上传大型 OpenAPI 文件的限制，默认 1M 会失败。

踩坑实录：初期我们用auth_basic，但客户要求 AD 集成。折腾一周后发现，Windows 10 的 IE/Edge 对 Kerberos 支持不一致。最终方案是：强制开发人员使用 Chrome，并在 Chrome 启动参数中添加--auth-server-whitelist=".internal"，确保 SPNEGO 正常工作。

4.2 RabbitMQ 消息总线：用死信队列（DLX）实现 Skill 执行的异步化与失败重试

为什么需要消息队列？
Harness 的 Skill 执行是 CPU 密集型（LLM 推理），同步调用会导致：

• 前端请求超时（尤其复杂 SQL 生成）；
• 单点故障影响整个链路（如 RabbitMQ 挂了，所有 Skill 都卡住）；
• 无法实现优雅降级（如 LLM 不可用时，自动切到规则引擎）。

RabbitMQ 拓扑设计：

[Harness API] ↓ (publish to 'skill.request') [Exchange: skill.direct] ↓ (route by routing_key: 'sql-gen') [Queue: skill.sql-gen] → [Consumer: SqlGenWorker] ↓ (on success: publish to 'skill.result') ↓ (on failure: publish to 'dlx.skill.sql-gen' with x-retry-count=3)

关键配置：

• 死信交换机（DLX）重试：

  # 创建队列时绑定 DLX rabbitmqctl set_policy DLX "skill.*" \ '{"dead-letter-exchange":"dlx","dead-letter-routing-key":"retry"}' \ --apply-to queues

  每次失败，消息进入 DLX，x-retry-count自增。当x-retry-count >= 3，消息进入skill.failed队列，触发人工干预流程；
• 消费者确认（Ack）：SqlGenWorker 处理完 Skill 后，才发送basic.ack。若 Worker 崩溃，消息自动重回队列；
• 消息持久化：所有队列、交换机、消息均设durable=true，防止 RabbitMQ 重启丢消息。

实测数据：
在 200 QPS 压力下，RabbitMQ 集群（3 节点）CPU 稳定在 45%，消息堆积 < 100 条。对比直接 HTTP 调用，API 平均延迟从 2.1s 降至 0.3s（纯网关开销）。

4.3 Linux 部署层：Kubernetes StatefulSet 部署 LLM，用 local-path-provisioner 管理模型权重

为什么不用云厂商托管 LLM？
客户要求：① 模型权重不出内网；② GPU 资源独占（避免多租户干扰）；③ 模型热更新（不重启 Pod）。

K8s 部署方案：

# llm-deployment.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: deepseek-coder-v2 spec: serviceName: "llm-headless" replicas: 1 template: spec: containers: - name: llm-server image: deepseek-coder:v2.1 ports: - containerPort: 8000 volumeMounts: - name: model-storage mountPath: /models/deepseek-coder-v2 volumes: - name: model-storage persistentVolumeClaim: claimName: llm-model-pvc --- # PVC 使用 local-path-provisioner apiVersion: v1 kind: PersistentVolumeClaim metadata: name: llm-model-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 120Gi storageClassName: local-path

关键实践：

• StatefulSet保证 Pod 有稳定网络标识（deepseek-coder-v2-0.llm-headless），Harness 可直接 DNS 解析；
• local-path-provisioner将模型权重存于 GPU 服务器本地 SSD（非 NFS），IO 吞吐达 2.1GB/s，加载 33B 模型仅需 48 秒；
• 热更新机制：当新模型权重写入/models/deepseek-coder-v2-new/，Harness 发送POST /model/reload请求，LLM Server 动态卸载旧模型、加载新模型，业务无感。

注意事项：我们为每个 LLM Pod 设置resources.limits.nvidia.com/gpu: 1，并