自定义连接器是面向开发者的服务端协同机制，需部署兼容MCP协议的Server并声明式注册：接收结构化请求、调用内部系统、按约定返回JSON结果、支持认证与熔断；在Muse平台配置触发路径、输入映射、模型绑定及结果回写地址。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
自定义连接器不是在 Muse App 里点几下就能完成的配置操作，而是面向开发者、SaaS 架构师或后端工程师的一套服务端协同机制。它不依赖 Muse 客户端 UI，也不靠写前端代码，核心是搭建一个符合协议的 MCP Server，并在 Muse 平台声明式注册 Connector。
你需要先搭一个兼容的 MCP Server
Muse 的 Connector 基于远程 MCP（Model Control Protocol）协议，不是 Webhook 或 SDK。你得自己部署一个能响应标准 HTTP 请求的服务，它要能：
- 接收 Muse 发来的结构化请求（含 context、input schema、callback URL）
- 调用你的内部系统（比如 CRM 接口、ERP 数据库、Python 分析脚本）
- 按约定格式返回结果（JSON），并支持错误码与重试语义
- 具备基础认证（如 API Key 或 OAuth2 验证）和熔断逻辑（例如超时 3s 自动放弃）
在 Muse 平台完成声明式配置
登录 Muse 开发者后台（muse.ai/developer），进入 Connectors 管理页，添加新 Connector 时需明确填写：
Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
-
触发路径：如
/api/v1/invoices/process，Muse 会向你 MCP Server 的该路径发起 POST -
输入映射规则：指定从 Muse 请求体中提取哪些字段（如
body.invoice_id→ 传给你的服务参数id） - 模型与动作绑定：选 deepseek-v4 还是 muse-spark，是否启用结构化输出（JSON mode）
-
结果回写地址：填你业务系统的更新接口，比如
PATCH /invoices/{id}，并声明把 Muse 返回的summary映射到字段processed_summary
关键细节必须注意
很多团队卡在测试阶段，问题往往出在协议理解偏差上：
- Connector 是双向契约，不是单向通知——你服务器必须主动返回 HTTP 200 + 正确 JSON，否则 Muse 会标记失败并停止后续调用
- 所有字段映射都支持 Jinja 模板语法，比如
{{ input.user_id | default('guest') }}，便于兜底处理 - 敏感字段（如 token、密钥）不能硬编码进配置，需通过 Muse 提供的 Secret Manager 注入环境变量
- 首次调试建议开启 Debug Mode，Muse 会把原始请求 payload 和你服务的响应完整记录在 Activity Log 中
典型场景参考：客服工单自动分析
某电商把 Muse 连接到自有客服系统，流程是：
- 客服系统在用户提交投诉录音后，向 Muse 的 Connector 路径
/complaints/analyze发起请求，附带 transcript 文本 - Muse 调用你部署的 MCP Server，Server 调用语音转文本 API + sentiment 模型，生成三项结构化结果
- Server 把结果 POST 回客服系统的
/tickets/{{ input.ticket_id }}，字段自动对齐 - 全程无数据库中转、无定时轮询、无 SDK 嵌入，端到端延迟控制在 800ms 内
这不是加个 Webhook 那么简单，但一旦跑通，你就拥有了一个可编排、可监控、可灰度发布的 AI 协同节点。
