为什么用 MCP 桥而不是直接集成
客户端只是对话壳，能力桥是独立的 MCP server——换客户端（LobeHub / Claude Desktop）不改桥，换能力不改客户端。两边解耦，各自演进。
上个月那通投诉电话里，客服承诺 48 小时退款，这符合制度吗？
⚙ 技能路由…voice_search()kb_ask()
找到 10-12 的质检报告（call-01）：客服原话「我们会在 48 小时内把退款打给您」。制度出处《售后退款政策》第 3 条：标准时效为 72 小时，48 小时属于超额承诺，记「政策口径偏差」一处，风险等级：中。
引用 · call-01 质检报告引用 · 《售后退款政策》第 3 条
对话流程示意，实际演示见本地工作台
11 个 MCP 工具
统一工具数
9 个项目 / 5 大能力族可对话调用
覆盖项目能力
62 个单测全绿
测试
能力演示
一句话，跨语音报告与制度库完成查证
首屏展示跨项目调用过程；当前以本地客户端演示为准，不把静态示意包装成在线成果。
输入
上个月那通投诉电话里，客服承诺 48 小时退款，这符合制度吗？
交付
路由到语音检索与知识库问答，返回通话原话、对应制度出处与政策口径判断。
如何实现
从输入到交付的完整链路
个人 AI 产品经理 / 面试官 · 能力散落在 8 个项目里（Dify、FastAPI、Fastify 各自为政），每次演示要开多个服务多个界面
- 01
能力桥统一封装
独立 MCP server（stdio）把 Dify 知识库、FastAPI 语音质检、Fastify 生图、看板 YAML 数据封装为 11 个标准工具，与客户端解耦
- 02
客户端接入
个人AI助手（开源 Cherry Studio）注册 MCP + 安装 ai-board-agent 技能 + 配置多模型（经本机 new-api 网关）+ 小程序窗格嵌入能力看板，零 UI 开发获得完整对话交互
- 03
技能路由与记忆
SKILL.md 教会 agent 何时调哪个工具、组合工作流；memory_* 工具提供文件式跨会话长期记忆
关键判断
不只是做出来，还要知道为什么这样做
为什么改造开源内核而不自研 UI
对话交互的完成度（多轮、工具调用可视化、模型切换）是客户端的核心资产，自研 UI 得不到任何新判断，只会把时间花在重造轮子上。
技能路由怎么教 agent 选工具
SKILL.md 写清楚「什么问题该调什么工具、哪些工具可以组合」——把路由规则写成文档喂给 agent，比写死 if-else 灵活，比裸靠模型猜稳定。
技术栈、技能原件与运行信息
技术与 AI 调用链
模型：MiMo-v2.6-flash、GLM、DeepSeek、Ollama 本地模型
框架：MCP (Model Context Protocol)、个人AI助手（测试版）、new-api 网关、TypeScript + esbuild、Vitest
链路：用户提问 → 客户端 agent 循环（Function Calling）→ MCP stdio 调 capability-bridge → 按技能路由分发到知识库/语音/生图/看板 → 结果带引用回填对话
技能原件
提供本地可运行版本，启动方式见项目文档；公开页面不展示本机目录。
可复用场景：任何 MCP 客户端（LobeHub / Claude Desktop / ZCode）零改动接入、二期部署 LobeHub Web 版复用同一能力桥
继续验证这个项目
看真实产出，或回到看板比较其他 AI 能力。