分发 Agents：一个插件、Skills，以及 UnifAPI MCP 服务器
UnifAPI 如何打包 Agents 与 Skills，让操作者无需自建应用就能加载工作流，并连接只读的公开数据 MCP 服务器。
一句话概括：UnifAPI 的分发模型把工作流和数据连接一并打包。操作者把 Agent/Skill 内容加载进自己的助手，再连接一个只读的公开数据 MCP 服务器即可。
Agent 类产品最难的部分往往是分发。你能构建一个工作流，但操作者仍然得知道在哪里运行它、如何连接数据、如何鉴权，以及该相信什么样的输出。
UnifAPI 的模型刻意做得很简单：
- 把 Agents 和 Skills 作为可加载的工作流构件发布。
- 连接一次
https://mcp.unifapi.com。 - 用 OAuth 鉴权。
- 让助手通过 MCP 调用公开数据操作。
- 为开发者保留直连 HTTP API。
操作者无需为了跑一个调研工作流就再添一个新仪表盘。
为什么一个插件很重要
一个 Agent 不应要求十个互相独立的配置步骤。理想的打包方式，是把运行手册和数据连接路径一并交给助手。
| 没有打包时 | 用 Agent/Skill 打包后 |
|---|---|
| 从零散的文档里复制提示词 | 加载这个 Agent 及其 Skills |
| 添加好几个 API 密钥 | 连接一个 UnifAPI MCP 服务器 |
| 猜该调用哪个端点 | 使用 Skill 说明和 MCP 操作 schema |
| 为了试这个工作流自建一个应用 | 在 Claude、Codex 或别的助手里直接运行 |
这对非开发者的操作者尤其重要。这款产品应该让人感觉像在加载一项能力，而不是在集成一个后端。
MCP 是连接路径
UnifAPI MCP 服务器对外提供一个紧凑的目录接口：
| 工具 | 用途 |
|---|---|
list_operations | 发现可用的公开数据操作 |
get_operation | 查看 schema、示例和计费元数据 |
call_api | 调用一个具体操作并返回记录 |
这避免了每个端点配一个 MCP 工具。目录可以不断扩张，而 MCP 接口始终保持可理解。
Skills 是工作流路径
MCP 告诉助手如何调用 UnifAPI。Skills 告诉它该做什么工作。
例如：
| Skill | 它在 MCP 之上加了什么 |
|---|---|
seo-audit | 查询框定、页面检查、输出模板、置信度规则 |
llm-mention-tracking | 品牌/域名匹配和 AI 可见性报告的形态 |
creator-shortlist | 候选人评分和跨平台证据规则 |
linkedin-account-research | 公司、职位、人员和新闻的调研顺序 |
没有 Skills，助手能调用数据，但可能产不出一份一致的构件。没有 MCP，Skill 能描述工作，却无法获取实时证据。两者合在一起才是产品。
对待开源的协作姿态
有些 Skills 可以改编开源工作流。正确的姿态是协作式的：致谢原项目、保留许可证背景、说明为 Agent 操作者改了什么，并仅在实时公开数据能增强工作流之处使用 UnifAPI MCP。
这避免了假装每一个好工作流都是 UnifAPI 内部发明的。它也给了维护者一条走向合作、而非被取代的路径。
操作者应该看到什么
一个好的配置页面应当回答：
- 哪个助手能运行这个？
- 我要添加哪个服务器 URL？
- 我怎么登录？
- 这个 Agent 能读取哪些公开数据？
- 它绝不会做什么？
- 我先运行哪段提示词？
答案应当使用客户的语言。"连接 MCP"是一个配置动作。"创建 API 密钥"是面向开发者的备选。"推荐 OAuth"可以出现在技术文档里，但操作者主要需要知道的是：浏览器登录授权的是 UnifAPI 积分。
接下来可以读什么
将 UnifAPI MCP 连接到通用 Agent 与编程 Agent —— 配置教程。
为什么 SKILL.md 运行手册能让营销 Agents 可复现 —— 工作流这一层。
Agent First 架构 —— 完整的产品模型。