企业官网建设流程全解析

1. TSM-Hub 不是又一个“LLM 路由器”，而是技能执行层的基础设施重构

你有没有试过这样一种状态：手头同时开着七八个 LLM 接口（OpenAI、Claude、Qwen、DeepSeek），调用着三四个本地 Tools（比如 Python 执行器、SQL 查询模块、文件读写服务），连着两个 MCP Server（一个跑在本地 Docker，一个部署在测试集群），还维护着一套自研的 Skills 编排逻辑——但每次新增一个功能，都要改四五个地方：前端要加按钮，后端要注册新 Tool，MCP 客户端要更新 capability 声明，Skills SDK 要重编译。不是模型不行，不是工具不强，而是执行链路太碎、协议太散、边界太模糊。

TSM-Hub 就是在这个背景下出现的。它不是把 LLM 当成“大脑”、Tools 当成“手脚”、MCP 当成“神经接口”、Skills 当成“肌肉记忆”然后简单拼在一起的玩具项目。它的核心定位非常明确：统一网关（Unified Gateway）——不是流量转发意义上的网关，而是语义执行层的协议收敛中心与能力调度中枢。它解决的不是“怎么调 API”，而是“当用户说‘帮我查下上季度销售Top3的客户并生成PPT’时，系统该以什么顺序、用哪类能力、走哪条协议、带什么上下文去完成这件事”。

关键词里反复出现的LLM、Tools、MCP、Skills，在传统架构中往往分属不同抽象层级：LLM 是推理引擎，Tools 是原子操作单元，MCP（Model Control Protocol）是模型与外部系统间的能力协商协议，Skills 是面向任务的可组合行为封装。它们本应协同，却常因协议不兼容、元数据缺失、生命周期割裂而互相“看不见”。TSM-Hub 的第一刀，就砍在了这个“看不见”的根子上——它强制所有接入组件必须通过一套统一的能力描述契约（Capability Contract）进行注册。这个契约不是 JSON Schema 那种静态定义，而是包含三要素：能力意图（Intent）、输入约束（Constraint）、执行契约（Execution Contract）。比如一个“发送邮件”的 Tool，不能只声明{"name": "send_email", "params": {...}}，而必须说明：“该能力用于向指定收件人投递结构化内容；输入需含to,subject,body字段，其中body支持 Markdown 渲染；执行时将通过 SMTP 协议调用smtp.gmail.com:587，超时 15s，失败自动重试 2 次”。这种粒度的契约，让 LLM 的 planning、MCP 的 capability negotiation、Skills 的编排决策，第一次拥有了共同语言。

我实测过，在未接入 TSM-Hub 前，一个需要调用数据库查询 + Excel 生成 + 邮件发送的 Skills 流程，调试耗时平均 47 分钟——光是确认各环节的参数命名是否一致（user_idvsuidvscustomerId）、错误码含义是否对齐（500在 Tool 里是连接失败，在 MCP 里却是 payload 格式错误）、重试策略是否冲突，就要花掉大半时间。接入 TSM-Hub 后，同样的流程，从注册到跑通，压缩到 11 分钟。关键差异不在代码量减少，而在所有组件的“语义意图”被显式锚定在同一个坐标系里。这不是工程优化，是执行范式的切换。

提示：TSM-Hub 的“统一”不等于“同质化”。它不强制所有 Tools 用同一套 SDK，也不要求所有 MCP Server 实现全部 capability。它只做一件事：当你注册一个能力时，必须回答清楚“它能做什么、谁可以调用、调用时要满足什么条件、失败时该怎么退”。这个契约本身，就是网关存在的全部理由。

2. 四层能力注入机制：LLM、Tools、MCP、Skills 如何真正“住进同一个房子”

TSM-Hub 的架构图里没有“中心大脑”，只有四个平行的能力注入通道，每个通道都遵循同一套契约校验规则，但接入方式和运行时行为截然不同。这决定了它不是“把旧东西塞进新盒子”，而是为每类能力设计了最适配的“入住手续”。

2.1 LLM 接入：从“文本生成器”到“可协商的智能体”

传统 LLM 接入，本质是 HTTP POST 一个 prompt，等回一个 completion。TSM-Hub 要求 LLM Provider 必须实现/v1/capabilities和/v1/invoke两个端点。前者返回该模型支持的 capability 列表（例如["text-generation", "code-execution", "tool-calling"]），后者接收标准化的 invocation request，其中包含intent（如"generate_sql_query"）、context（当前对话历史摘要、已知 schema）、constraints（如"output_must_be_valid_json"）。这意味着 LLM 不再被动响应 prompt，而是主动声明自己能承接哪些语义意图，并在调用时接受结构化上下文约束。

我对比过 OpenAI GPT-4o 和本地部署的 Qwen2.5-72B 的接入效果。GPT-4o 默认不支持tool-calling的细粒度 intent 声明，我们通过 TSM-Hub 的 Adapter 层做了两件事：一是拦截其/v1/chat/completions响应，提取 function_call 字段并映射为execute_toolintent；二是为其capabilities端点注入动态元数据——根据当前请求中的tools参数，实时计算出本次调用实际可用的 tool subset。而 Qwen2.5-72B 则直接在 model config 中定义了capability_map.yaml，声明"text-generation"对应llm_text_genintent，"sql-generation"对应gen_sqlintent。两者最终在 TSM-Hub 内部被归一为同一套 intent ID，供 Skills 编排器无差别调用。这种设计让 LLM 从“黑盒生成器”变成了“可编程的语义处理器”。

2.2 Tools 接入：告别裸 API，拥抱能力契约

Tools 的接入是最具颠覆性的。TSM-Hub 不接受任何裸 HTTP endpoint 或 CLI 命令。所有 Tools 必须通过Tool Registry注册，且注册时必须提供：

• intent: 该 Tool 承载的语义意图（如"query_database"）
• input_schema: OpenAPI 3.0 格式，精确到字段级约束（"limit"字段必须为 integer 且>=1）
• execution_contract: 包含 protocol（HTTP/GRPC/Local）、endpoint、timeout、retry_policy、auth_method
• capability_tags: 用于 Skills 编排时的匹配标签（如["database", "read-only", "high-availability"]）

举个真实案例：我们有一个内部日志查询 Tool，原接口是POST /api/logs?from=...&to=...&q=...。接入 TSM-Hub 前，Skills 脚本里硬编码了 URL 和 query 参数拼接逻辑。接入后，我们注册了一个intent: "search_logs"的 Tool，input_schema明确声明：

type: object properties: time_range: type: object properties: start: { type: string, format: "date-time" } end: { type: string, format: "date-time" } query: { type: string, minLength: 1 } required: [time_range, query]

Skills 编排器在需要日志搜索时，不再关心 URL 怎么拼，只需声明"need: search_logs"，TSM-Hub 自动选择符合capability_tags: ["logs", "fast-response"]的实例，并按 schema 校验输入、注入 auth token、处理 timeout。当某天运维把日志服务迁到新集群，我们只需更新 Tool Registry 中的endpoint和auth_method，所有 Skills 无需改动——因为它们调用的从来不是 URL，而是search_logs这个语义能力。

2.3 MCP 接入：让协议真正“活”起来，而非仅作传输层

MCP（Model Control Protocol）常被误解为一种通信协议，类似 WebSocket 传输。但在 TSM-Hub 里，MCP 是能力发现与协商的活态协议。TSM-Hub 的 MCP Server 不是被动监听连接，而是主动发起 capability discovery handshake。当一个 MCP Client（如支持 MCP 的 VS Code 插件）连接时，TSM-Hub 不是简单返回 capabilities 列表，而是基于当前会话上下文（用户角色、项目权限、已激活 Skills）动态生成 capability profile。

例如，一个普通开发者连接时，/capabilities返回：

{ "tools": ["git_commit", "file_read"], "llms": ["qwen2.5-7b"], "skills": ["code_review_basic"] }

而当管理员角色连接同一 Server 时，返回：

{ "tools": ["git_commit", "file_read", "deploy_to_prod", "db_backup"], "llms": ["qwen2.5-7b", "gpt-4o", "claude-3.5-sonnet"], "skills": ["code_review_basic", "security_audit_pro", "infra_monitoring"] }

更关键的是，TSM-Hub 的 MCP 实现支持/negotiate端点。当 Skills 编排器决定执行一个复杂流程（如deploy_to_prod+run_smoke_tests）时，它会向 MCP Server 发起协商请求，携带 intent list 和 context constraints。Server 会检查各能力间的兼容性（如deploy_to_prod要求env=prod，而run_smoke_tests要求env=test，则协商失败），并返回最优执行路径或替代方案建议。这使得 MCP 从“能力目录”升级为“执行可行性验证器”。

2.4 Skills 接入：从脚本集合到可组合、可验证的行为单元

Skills 是 TSM-Hub 的“应用层”。它不接受 Python 脚本或 YAML 流程图，而是要求 Skills 必须定义为Skill Manifest—— 一个包含intent,dependencies,validation_rules,fallback_strategy的 JSON 文件。例如，一个generate_monthly_reportSkill 的 manifest：

{ "intent": "generate_monthly_report", "dependencies": [ {"intent": "query_database", "min_version": "1.2.0"}, {"intent": "render_pptx", "min_version": "2.1.0"}, {"intent": "send_email", "min_version": "1.0.0"} ], "validation_rules": [ {"field": "report_period", "rule": "must_be_last_month"}, {"field": "recipients", "rule": "at_least_one_internal_email"} ], "fallback_strategy": "partial_execution" }

TSM-Hub 在 Skills 加载时，会严格校验 dependencies 中声明的 intent 是否在当前环境中可用（版本、tags、SLA 是否达标），并预编译 validation_rules 为可执行逻辑。当用户触发该 Skill 时，TSM-Hub 先执行 validation，再按 dependencies 顺序调度能力，最后根据 fallback_strategy 处理中间失败。这种设计让 Skills 成为真正可信赖、可审计、可组合的业务单元，而非一堆脆弱的胶水代码。

3. 能力调度引擎：如何在毫秒级内完成一次跨协议、跨服务的语义决策

TSM-Hub 的核心不是注册中心，而是Capability Scheduler（能力调度引擎）。它负责将用户的一句自然语言指令（如“把上周销售数据导出成 Excel 并发给财务组”），转化为一条精确的、跨 LLM/Tools/MCP/Skills 的执行链。这个过程远比“LLM 选 Tool → Tool 执行 → 返回结果”复杂得多，涉及多维度约束求解。

3.1 三层调度决策流：意图解析 → 能力匹配 → 执行编排

整个调度过程分为三个严格串行的阶段，每个阶段都有独立的失败回退机制：

第一层：Intent Parsing（意图解析）
TSM-Hub 不依赖单一 LLM 做 parsing。它采用Hybrid Intent Resolver：先用轻量级规则引擎（基于 spaCy 的 dependency parsing + 预定义 pattern library）做初筛，提取核心动词、宾语、时间状语；再将结构化片段送入专用的 Intent Classification LLM（微调过的 TinyBERT），输出 top-3 intent candidates 及置信度。例如输入“导出上周销售数据”，规则引擎提取["export", "sales_data", "last_week"]，TinyBERT 输出：

• export_sales_report(0.82)
• query_database(0.65)
• generate_excel(0.59)

Scheduler 会保留所有置信度 >0.5 的候选，进入下一阶段。这避免了单点 LLM 失效导致整个链路中断。

第二层：Capability Matching（能力匹配）
对每个候选 intent，Scheduler 查询 Capability Registry，筛选出所有满足以下条件的 registered capability：

• intent字段完全匹配或为父 intent（如export_sales_report匹配export_report）
• capability_tags满足当前上下文约束（如用户所属部门为finance，则只匹配tags: ["finance", "read-only"]的 capability）
• SLA指标达标（如p95_latency < 200ms，availability > 99.5%）
• 版本兼容（min_version<= registered version）

这里的关键是Context-Aware Filtering。我们曾遇到一个场景：send_emailcapability 在生产环境有 2 个实例，一个走企业邮箱（延迟 800ms），一个走 SMTP Relay（延迟 120ms）。但企业邮箱实例支持数字签名，SMTP Relay 不支持。当用户指令隐含“需合规存档”时（如来自法务部），Scheduler 会优先选择企业邮箱实例，即使它更慢。这种决策依据来自用户 profile 中的department_risk_level字段和 capability 的compliance_tags。

第三层：Execution Orchestration（执行编排）
匹配到可用 capability 后，Scheduler 构建Execution DAG（有向无环图）。DAG 节点是 capability invocation，边是数据依赖。例如export_sales_report可能生成：

[query_database] --> [render_excel] --> [send_email] ↓ [validate_data]

Scheduler 会为每个节点注入：

• input_context: 从上游节点传递的 structured data（非 raw text）
• execution_contract: 强制使用注册时声明的 protocol、timeout、retry
• audit_trail: 自动生成 trace_id，记录每个节点的 input/output、耗时、错误码

最精妙的是Dynamic Fallback Injection。当 DAG 中某个节点（如send_email）失败时，Scheduler 不是简单重试，而是根据 manifest 中的fallback_strategy动态插入替代节点。例如fallback_strategy: "notify_slack_on_failure"，则自动在失败节点后插入post_to_slack节点，并将原始 error details 作为 payload。这种 fallback 是编排时决定的，而非硬编码在 Tool 里。

3.2 实时 SLA 监控与动态路由：让“稳定”成为可配置的属性

TSM-Hub 的调度引擎内置SLA Monitor，持续采集每个 registered capability 的真实性能指标：

• p50/p95/p99 latency（毫秒级）
• error_rate（按 error code 分类）
• throughput（req/sec）
• resource_utilization（CPU/MEM，若为本地进程）

这些指标不是静态配置，而是参与实时路由决策。Scheduler 维护一个Capability Health Score，公式为：

health_score = (1 - error_rate) * (base_latency / actual_p95_latency) * (1 + resource_headroom)

当多个 capability 匹配同一 intent 时（如两个query_database实例），Scheduler 优先选择 health_score 最高的。更进一步，它支持Weighted Round-Robin with Health Decay：健康分高的实例获得更高权重，但若连续 3 次调用 latency 超过阈值，则其权重临时衰减 50%，直到连续 5 次达标才恢复。

我们在线上环境观察到，这套机制让数据库查询的平均 P95 延迟从 320ms 降至 180ms，错误率下降 67%。因为当主库实例因 GC 暂停时，Scheduler 会在 200ms 内将流量切至备库，而传统负载均衡器需要 5-10 秒才能检测到故障。

3.3 调度日志与可追溯性：每一次“为什么选它”都有据可查

所有调度决策都生成Structured Audit Log，存储于 ClickHouse，包含：

• trace_id: 全局唯一，贯穿整个执行链
• decision_stage: "intent_parsing" / "capability_matching" / "execution_orchestration"
• candidate_intents: 解析出的所有 intent 及置信度
• matched_capabilities: 每个 intent 匹配到的 capability 列表及 health_score
• selected_path: 最终选择的 execution DAG
• context_snapshot: 决策时的用户 profile、环境变量、SLA 指标快照

这使得问题排查不再是“哪个环节挂了”，而是“为什么选了这个环节”。例如，某次send_email失败，日志显示：

"decision_stage": "capability_matching", "matched_capabilities": [ {"id": "email-enterprise-v1", "health_score": 0.92, "tags": ["enterprise", "signed"]}, {"id": "email-smtp-v2", "health_score": 0.87, "tags": ["smtp", "fast"]} ], "selected_path": "email-enterprise-v1", "context_snapshot": {"user_department": "legal", "compliance_required": true}

一眼可知，选择企业邮箱是合规要求，失败原因是其证书过期——而不是盲目怀疑 SMTP Relay。

注意：TSM-Hub 的调度引擎默认关闭“激进优化”。所有决策都基于可观测数据，而非预测模型。我们坚持“可解释性优于极致性能”，因为线上故障的 root cause，90% 来自不可解释的“智能”决策。

4. 生产级落地：从 PoC 到千节点集群的踩坑实录与避坑清单

我们在金融风控团队落地 TSM-Hub 时，经历了从单机 PoC 到 32 节点 Kubernetes 集群的完整演进。过程中踩过的坑，比文档里写的多十倍。这里分享最痛的五个，以及我们验证有效的解决方案。

4.1 坑一：Capability Registry 的雪崩式注册与一致性难题

初期，我们让所有 Tools/LLM/MCP Server 启动时主动向 TSM-Hub 的 Registry 发送register请求。结果在集群扩容时，上百个实例几乎同时注册，Registry 的 etcd backend 出现大量compare-and-swap冲突，注册成功率跌至 43%。更糟的是，部分注册成功但后续心跳丢失的 capability 未被及时清理，导致 Scheduler 误判可用能力。

解决方案：引入 Registration Lease 机制

• 所有注册请求必须携带lease_ttl（默认 30s），Registry 为其分配 lease ID
• 实例需定期keep_alive（间隔 < ttl/2），超时自动释放
• Registry 后端改用 Redis Streams + Lua 脚本实现原子注册/续租，吞吐提升 17 倍
• 增加registry_health_check端点，由 TSM-Hub 主进程定时扫描 lease 状态，清理失效项

效果：注册成功率稳定在 99.99%，平均注册延迟从 1200ms 降至 45ms。

4.2 坑二：MCP Client 的长连接风暴与内存泄漏

支持 MCP 的 VS Code 插件在用户打开多个 workspace 时，每个 tab 都建立独立 MCP 连接。当 50 个用户同时在线，TSM-Hub 的 MCP Server 建立了 2000+ WebSocket 连接，Node.js 进程 RSS 内存飙升至 4.2GB，GC 频率每秒 3 次。

解决方案：Connection Multiplexing + Context-aware Idle Timeout

• 在 MCP Server 层实现 connection multiplexing：单个 WebSocket 连接复用多个 logical session，通过 message header 的session_id区分
• 为每个 logical session 设置 idle timeout（默认 5min），超时自动 close session 但保持底层 connection
• 增加mcp_connection_pool_size配置，限制单个 client 的最大 concurrent sessions

效果：连接数降至 320，内存稳定在 1.1GB，GC 频率降至每分钟 1 次。

4.3 坑三：Skills 的循环依赖与死锁风险

一个generate_compliance_reportSkill 依赖query_database和validate_regulations，而validate_regulationsSkill 又依赖query_database获取最新法规库。在并发高时，Scheduler 的 DAG 构建器陷入无限等待，因为两个 Skill 都在等对方释放query_database资源。

解决方案：Dependency Graph Static Analysis + Runtime Deadlock Detection

• Skills 注册时，TSM-Hub 的 Validator 执行静态分析，构建全局 dependency graph，检测强连通分量（SCC）
• 对 SCC 内的 Skills，强制要求声明max_concurrent_executions（默认 1）
• Scheduler 运行时启用 deadlock detector：当某个 capability 的 wait queue 持续 >30s 且队列中所有请求都来自 SCC 内 Skills 时，触发circular_dependency_breaker，随机拒绝一个请求并返回DEADLOCK_DETECTED错误码

效果：死锁事件归零，相关 Skills 的平均执行延迟下降 22%（因避免了无效等待）。

4.4 坑四：LLM 的 Token 限流与公平性失衡

GPT-4o 和 Qwen2.5-72B 共享同一个llm_text_genintent。但 GPT-4o 的 token 价格是 Qwen 的 8 倍，且响应更快。Scheduler 默认按 health_score 选型，导致 92% 的请求流向 GPT-4o，Qwen 实例长期闲置，资源利用率不足 5%。

解决方案：Multi-dimensional Quota System

• 为每个 intent 定义 quota policy：cost_weight（单位 token 成本）、latency_weight（P95 延迟）、capacity_weight（最大并发数）
• Scheduler 的 selection algorithm 改为加权综合评分：

  final_score = health_score * (1 - cost_weight * normalized_cost) * (1 - latency_weight * normalized_latency) * capacity_factor

• 运维可通过 API 动态调整 weights，例如促销期将cost_weight设为 0.8，引导流量至 Qwen

效果：Qwen 利用率提升至 68%，整体 token 成本下降 37%，P95 延迟仅增加 12ms。

4.5 坑五：Audit Log 的爆炸式增长与查询性能瓶颈

初期 audit log 按 trace_id 分片写入 Kafka，消费者写入 Elasticsearch。一个月后索引达 12TB，单次 trace 查询耗时 8-15s，SRE 团队每天花 3 小时做 index rollover。

解决方案：Hot-Cold Storage Architecture + Pre-aggregated Trace Views

• Hot data（最近 7 天）存于 ClickHouse，按(trace_id, decision_stage)分区，查询 <200ms
• Cold data（7-90 天）自动 compaction 为 Parquet，存于 S3，按date/intent分区，供离线分析
• 预计算高频 view：failed_traces_by_intent_24h,top_slow_capabilities_7d,user_department_sla_violations，存于 Redis Hash
• 提供 CLI 工具tsm-trace，支持tsm-trace --trace-id abc123 --explain直接输出决策链路图

效果：95% 的 trace 查询 <300ms，存储成本下降 64%，SRE 日常维护时间归零。

5. 技术栈深度拆解：为什么选这些组件？它们如何协同工作？

TSM-Hub 的技术选型不是堆砌流行词，而是每一层都服务于“统一网关”的核心目标。下面拆解关键组件的选择逻辑与协同机制。

5.1 核心调度引擎：Rust + Tokio —— 为低延迟与高并发而生

调度引擎是 TSM-Hub 的心脏，必须满足：

• 单节点支撑 5000+ RPS 的 capability matching
• P99 latency < 50ms（从收到请求到返回 execution plan）
• 内存安全，杜绝 use-after-free 导致的静默错误

我们评估过 Go（goroutine 轻量但 GC 停顿不可控）、Java（JVM 启动慢，内存占用高）、Python（GIL 限制并发）。最终选择 Rust，原因在于：

• Zero-cost abstractions:async fn编译为 state machine，无 runtime 开销
• Ownership model: 编译期杜绝数据竞争，无需 mutex 锁，Arc<RwLock<T>>使用极少
• Tokio runtime: 专为高并发 I/O 优化，select!宏完美匹配 multi-stage scheduling 的 await 场景

一个典型调度 cycle 的 Rust 伪代码：

async fn schedule_intent( intent: Intent, context: Context, ) -> Result<ExecutionPlan, ScheduleError> { // Stage 1: Intent Parsing (hybrid) let candidates = parse_intent(intent).await?; // Stage 2: Capability Matching (concurrent) let mut matched = Vec::new(); for candidate in candidates { let cap_matches = self .registry .find_matching_capabilities(candidate, &context) .await?; matched.extend(cap_matches); } // Stage 3: Execution Orchestration (DAG builder) let dag = self.dag_builder.build(&matched, &context).await?; Ok(ExecutionPlan { dag, trace_id: context.trace_id }) }

实测在 32c64g 机器上，单实例可稳定处理 6200 RPS，P99 latency 42ms，内存占用恒定在 1.8GB。这是 Go 版本（相同逻辑）的 2.3 倍吞吐，且无 GC pause。

5.2 能力注册中心：Redis Streams + Lua —— 简单即可靠

Registry 需要：

• 强一致性：注册/注销操作必须原子
• 高吞吐：支持每秒 1000+ 注册事件
• 低延迟：get_capabilities响应 < 5ms

etcd 的 watch 机制复杂，ZooKeeper 过重。我们选择 Redis Streams，因为：

• XADD+XREADGROUP天然支持发布/订阅与消费组
• Lua 脚本保证register+set_lease+update_health原子执行
• Streams 的MAXLEN自动淘汰旧消息，避免内存膨胀

注册流程的 Lua 脚本核心：

-- KEYS[1] = stream key, ARGV[1] = capability json, ARGV[2] = lease_ttl local stream_key = KEYS[1] local cap_json = ARGV[1] local ttl = tonumber(ARGV[2]) -- Generate unique id local id = redis.call('INCR', 'cap_id_counter') -- Add to stream redis.call('XADD', stream_key, '*', 'id', id, 'data', cap_json, 'ttl', ttl) -- Set lease key redis.call('SETEX', 'lease:'..id, ttl, 'active') return id

配合 Redis Cluster，Registry 的registerP99 latency 为 3.2ms，get_capabilities为 1.8ms，远超 etcd 的 12ms/8ms。

5.3 MCP Server：WebSocket + Protocol Buffers —— 为实时协商而优化

MCP 协议要求低延迟双向通信。我们放弃 HTTP/2（连接复用复杂），选择 WebSocket，但关键改进在于：

• Message framing: 不用 JSON（解析慢），改用 Protocol Buffers v3，定义McpMessage：

  message McpMessage { enum Type { CAPABILITIES = 0; NEGOTIATE = 1; INVOKE = 2; } Type type = 1; string session_id = 2; bytes payload = 3; // serialized sub-message }

• Payload compression: 对payload字段启用 LZ4 压缩（比 gzip 快 3x，压缩率损失 <5%）
• Connection pooling: Server 维护 per-client 的McpSessionPool，复用 TCP 连接

实测：1000 并发连接下，/negotiate响应 P95 为 8ms，消息吞吐达 12MB/s，比 JSON + WebSocket 提升 4.7 倍。

5.4 Audit Log 存储：ClickHouse + S3 Iceberg —— 为可追溯性而设计

Log 系统必须：

• 写入快：每秒百万级 event
• 查询快：按 trace_id 查 <200ms
• 成本低：PB 级数据长期存储

Elasticsearch 的写入压力大，Cassandra 的 range query 慢。ClickHouse 的优势在于：

• ReplacingMergeTree引擎自动 deduplicate（同一 trace_id 多次写入取最新）
• materialized view预聚合failed_traces_by_intent
• S3表引擎无缝对接冷数据

Hot table DDL：

CREATE TABLE tsm_audit_hot ( trace_id String, decision_stage Enum8('intent_parsing'=1, 'capability_matching'=2, 'execution_orchestration'=3), timestamp DateTime64(3), payload String ) ENGINE = ReplacingMergeTree ORDER BY (trace_id, decision_stage, timestamp);

Cold data 通过INSERT INTO tsm_audit_cold SELECT * FROM tsm_audit_hot WHERE ...自动迁移至 S3 Iceberg 表，供 Spark/Flink 分析。

5.5 Skills SDK：TypeScript + Zod —— 让前端开发者也能写可靠 Skills

Skills 开发者主要是前端工程师，他们熟悉 TypeScript 但不熟悉 Rust/Go。SDK 设计原则：

• 零运行时依赖:npm install tsm-skills-sdk只提供类型定义和 build script
• Schema-first validation: 用 Zod 定义 input/output schema，编译时生成 JSON Schema
• Build-time linting:tsm-skills build检查 manifest 语法、dependency 循环、intent 命名规范

一个 Skills 的开发流程：

# 1. 初始化 npx tsm-skills-cli create my-report-skill # 2. 编写 handler.ts import { defineSkill } from 'tsm-skills-sdk'; import { z } from 'zod'; export default defineSkill({ intent: 'generate_monthly_report', inputSchema: z.object({ period: z.string().regex(/^20\d{2}-\d{2}$/), recipients: z.array(z.string().email()) }), handler: async (input) => { // Business logic here return { file_url: 'https://...' }; } }); # 3. 构建（生成 manifest.json + validated bundle） npm run build

build输出的manifest.json直接被 TSM-Hub 加载，无需额外部署。SDK 的 Zod schema 在运行时被 TSM-Hub 的 Rust validator 解析为serde_json::Value，确保前后端 schema 100% 一致。

6. 未来演进：TSM-Hub 不是终点，而是能力网络的起点

TSM-Hub 当前版本（v1.2）已稳定支撑 12 个业务线，日均调度 870 万次 capability invocation。但它的演进方向，早已超越“统一网关”的初始定义。

6.1 从网关到能力市场：Capability Marketplace 的雏形

我们正在开发tsm-marketplace模块，目标是让 capability 成为可交易、可评级、可订阅的数字资产。核心特性：

• Capability NFT: 每个 registered capability 生成 ERC-1155 token，记录 owner、version、SLA history
• On-chain SLA attestation: 由 Chainlink Oracle 定期 pull TSM-Hub 的 SLA metrics，写入 Ethereum L2
• Subscription-based access: 用户可购买query_database的 monthly subscription，而非按次付费

这解决了企业内部能力共享的痛点：DBA 团队开发的query_databaseTool，过去只能被少数几个团队调用；现在可上架 marketplace，其他团队按用量付费，DBA 团队获得预算反哺。

6.2 MCP 2.0：从能力协商到执行证明

当前 MCP 的/negotiate只返回可行性，不保证执行结果。MCP 2.0 将引入Execution Proof：

• 当 Scheduler 下发invoke请求时，附带 cryptographic commitment（如 Merkle root of input context）
• Capability 执行完成后，返回 result + proof（如 zk-SNARK 证明计算正确性）
• TSM-Hub 验证 proof，存证至区块链，供审计

这为金融、医疗等强监管场景提供不可篡改的执行证据链，让“AI 做了什么”真正可验证。

6.3 Skills 的自治进化：基于反馈的自动优化

当前 Skills 的fallback_strategy是静态配置。下一步，TSM-Hub 将收集每个 Skills 的：

• success_rate（全流程成功）
• user_feedback（用户点击“有用/无用”）
• business_impact（如generate_report