DEVELOPER EXTENSIONS · 客服平台的扩展体系

客服平台的开发者扩展体系

开发者在这个平台上能扩展什么、扩展如何过质量门、上线后如何闭环、贡献如何变现

扩展底座：这个客服平台的分层防御架构（L1 意图 / B2 Flow+RAG / Agent）+ 质量基础设施（L1 六维 / L2 八维）+ BadCase 质量闭环，构成开发者扩展的底座。三层扩展点对外暴露统一协议接口，内部实现互不影响--加新能力不改编排器、不重新发布平台、不需理解内部实现。

协议选型：Tool 层采用 MCP 作为对外协议--语言无关、一次开发全客户端复用、Agent 按需发现而非人逛商店。扩展基础设施的竞争不在"插件市场多大"，在"接入多薄"。越薄，开发者写的胶水代码越少。

扩展点：原子扩展（Tool/Flow/Guardrail）+ 能力包（Skill）

原子扩展（Tool / Flow / Guardrail）走统一接口 handle(ctx) -> bool，任一层短路即停止；能力包（Skill）是声明式组合，SKILL.md 定义，不走 handle 接口。协议优于 SDK--平台无关，换平台不用重写

Tool 层 · 接外部系统

定义 Schema + Handler + 注册，Tool Registry 自动发现，暴露给 Agent 按需调用（当前 8 Tools：产品搜索/支付记录/价保/转人工/知识搜索等）。

Tool 可封装为 MCP Server，被所有兼容客户端调用--一次开发，全生态复用。

ProtocolAuto-DiscoverMCP

Flow 层 · 确定性业务流程

钱 / 法 / 合规场景走这层（退款、价保、重复扣款）。step 函数确定性执行，零 LLM、零幻觉。错误成本不可承受的，不交给概率。

Flow 失败自动 escalate 到 Agent 承接，不阻断。

零 LLM确定性钱法合规

Guardrail 层 · 安全与规则

Input 13 规则（指令注入 / 角色劫持 / 数据泄露）+ Output 4 门（幻觉 / 敏感词 / 长度 / 格式）。返回 True 即短路。

可自由组合、可独立回滚。行业合规规则在这里长。

可组合合规短路

能力包 · 声明式扩展：Skill

Skill 是不同维度的扩展：不实现 handle 接口，是声明式能力包。SKILL.md 定义"遇到什么场景、用什么工具、走什么流程、输出什么结果"，组合调用 Tool / Flow / KB。前三类是原子扩展点，Skill 是它们的声明式组合与复用单元。2026 年中已生态化：SKILL.md 成开放标准、SkillHub 上 Skill 超 5 万个。对应 partner 方案包层。

为什么协议比 SDK 重要

SDK 是平台绑定的--换平台要重写。协议（MCP / OpenAPI / handle(ctx)->bool）是平台无关的--一个 MCP Server 能被所有兼容客户端调用。平台的价值不在"SDK 多好用"，在"扩展基础设施多薄"。越薄，胶水代码越少，生态粘性越大。

扩展的质量门控

质量基础设施是平台的默认能力：L1 规则全覆盖 + L2 按需抽样 + Golden 回归基准。系统级变更需过回归门才放行

三层质量基础设施

L1 · 规则全覆盖 - 零成本，100% 覆盖。六维：相关性 / 依据性 / 完整性 / 流畅度 / 有用性 / 安全性。不需 LLM。
L2 · 按需抽样 - LLM-Judge 八维（6 核心 + context_recall / precision）。只在 L1 过不去时触发，不浪费 token。
Golden Set 回归 - 系统级变更（retriever / prompt / KB 配置）提交前跑全量基准，RegressionGate A/B 要求 hit_rate 提升 ≥5% 才放行，防采样噪声误判。扩展代码变更由开发者跑 L1/L2 自测。

质量基础设施提供的能力

全量回归测试（不通过不合并）
多维评分面板（打单时有数据）
安全门控（幻觉 / 敏感词 / 格式 / 长度）
效果可观测（不需自己埋点）

贡献不是"交出去就失控了"--质量继承是平台的承诺。

¥0

L1 六维 100% 覆盖

10%

L2 LLM 抽样

≥5%

回归放行阈值

100%

Golden 回归全覆盖

质量闭环：检测 · 门禁 · 回滚 · 回流

设计目标：检测 -> 诊断 -> 修复 -> 验证 -> 门禁 -> 自动应用的全闭环。当前实现到门禁为止、auto_apply 休眠、全转人工审批--稳基线阶段先验证修复建议准不准，客服场景错改直接误导客户

检测

->

诊断

->

修复建议

->

验证

->

门禁

->

human_review

6 道门控 · 全部通过才放行 · 第①道是硬前提 · auto_apply 当前休眠，案例停在 verified 等人工 resolve

① 信号强度

需 rule
（LLM 信号不可信 ρ≈0）

② 诊断置信度

≥ 0.80

③ 验证通过

Golden: coverage ≥ 0.6
Fallback: 覆盖率不退化

④ 金标回归

不退化

⑤ 断路器

回归率 ≤ 5%

⑥ 一致性

不自矛盾

第①道为什么是硬前提：LLM 输出非确定性，用 LLM 信号判定"修没修好"统计上无意义（设计依据，ρ≈0）。诊断可用 LLM 找问题，但 放行只能由 rule 信号触发。这是闭环安全的地基。

🔍

① 诊断 · 开放根因

预置 11 根因（幻觉 / 检索缺失 / KB 空白 / 工具误用等）。根因当前硬编码，修复策略可注册

🔧

② 修复 · 开放策略

8 修复策略（Tier1 直接 5 / Tier2 系统级 3）。修平台资产（KB/guardrail/retriever），不修扩展代码；策略经 STRATEGY_REGISTRY 注册

✅

③ 验证 · 开放基准

Golden 模式 coverage ≥ 0.6 + self-comparison 兜底。Golden 集可贡献（JSON）

FeedbackSignal · bad case 回流为回归用例： 20 样本滑动窗口聚合诊断结果 -> 自动 emit 4 类信号（retriever_tune ≥30% / kb_expand ≥20% / prompt_revise ≥15% / guardrail ≥25%）-> 去重避免重复触发。

扩展生命周期：从提交到调用

从写一个扩展到产生调用量、获得分成的完整链路。每一步的摩擦都被平台基础设施吸收

Step 1

开发

定义 Schema + Handler
实现 handle(ctx)->bool

->

Step 2

注册

Tool Registry 自动发现
无需手动配置

->

Step 3

门控

Golden Set 回归 + 安全审查
不通过不合并

->

Step 4

上架

MCP Server 过安全审计
公开可调用

->

Step 5

调用

Agent 按需发现并调用
非人搜商店

->

Step 6

变现

方案包 / 连接器被调用
产生持续分成

接入成本决定生态增长

开发者的首次成功调用时间（从注册到第一次业务有效的 API 返回）和生产部署转化率（demo 上了多少生产），比注册数更能反映生态健康。注册不产生价值，调用才产生。

零侵入的含义

加新扩展不改编排器、不重新发布平台、不需理解内部实现。Tool Registry 动态发现，扩展注册即生效。Agent 通过协议按需查找工具，不存在"安装"这个概念。

扩展飞轮与回报

成熟的开发者生态是开发者反哺平台资产库，形成正反馈。飞轮与治理的理论框架见 eco-ops.html 三环，合作伙伴侧见 partner.html，本文聚焦开发者侧回报

开发者为什么愿意贡献

分发杠杆 - 自己用只能服务自己的客户；上架后平台所有客户可见（含 Agent 搜索找方案）。一次开发，全生态复用。
质量继承 - 贡献的扩展自动继承平台的回归测试、门控、可观测性。不是"交出去就失控了"。
收入分成 - 方案包 / 连接器被其他客户调用时产生持续分成。

平台门控 = 护城河

质量门控 - Golden Set 不通过的不合并
安全审查 - MCP Server 过安全审计才可公开调用
定价 + 分成规则 - 平台定义商业模型，开发者在其上建业务

开放做大、控制做厚。治理框架与合作伙伴侧一致，见 partner.html。

本文范围：开发者扩展体系--能扩展什么（扩展点）、怎么过门（质量门控）、怎么闭环（检测·门禁·回滚·回流）、怎么变现（生命周期）。
生态飞轮与治理的完整理论（三条铁律 / 自进化三环 / 三阶段节奏）见 eco-ops.html；合作伙伴 / ISV 侧落地见 partner.html。本文不复述。