OpenOcta 同时挂 MCP 和 Agent Skills，模型调用走 TaoToken 统一接入

OpenOcta 的工作区里同时出现mcp.servers和SKILL.md时，Agent 的同一轮对话既要按 Skill 组织步骤，又要通过 MCP 拉真实数据。麻烦点不在写配置，而在模型侧：MCP 服务有 stdio 命令和 URL，Skill 有工作区、托管、内置三档优先级，模型调用却可能散在多个 Key 和 Base URL 上。TaoToken 把模型调用收成统一接入，先打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建 Key，再回 OpenOcta 的模型供应商里填自定义 API，这样同一会话里启停 Skill、增删 MCP 时，不用再动模型通道。下面按 OpenOcta 实际配置路径走一遍。

1. 先把 MCP 和 Agent Skills 的分工摆到 OpenOcta 桌面上

1.1 MCP 是连接层，负责把真实数据端上来

MCP 在 OpenOcta 里的角色像后厨采购员：它不决定今天做什么菜，只负责把食材从仓库、日志目录、只读接口拿到窗口。mcp.servers声明的是服务器怎么启动、用 stdio 还是 URL、带哪些环境变量。工具调用返回的是数据或只读结果，Agent 再解释。注意不要让 MCP 工具承担“执行生产变更”的角色；诊断类 SQL 由读者在本地或受控客户端执行，把报错贴回对话，MCP 只做只读取数。

1.2 Agent Skills 是方法论层，SKILL.md 决定步骤顺序

Skill 更像菜谱。SKILL.md里写清楚先查什么、后查什么、产物结构长什么样、失败时怎么收口。OpenOcta 按优先级加载 Skill：工作区.openocta/skills/最高，托管~/.openocta/skills/次之，内置安装目录最低。同会话里 Agent 先按 Skill 组织步骤，再通过 MCP 拉数据，两者不是二选一。MCP 管“数据从哪来”，Skill 管“拿到数据后按什么格式和顺序产出”，混在一起排查会非常费劲。

1.3 同会话同时挂 MCP 和 Skill 时，Key 为什么容易乱

当 MCP server 从一个变成三个，Skill 从内置切到工作区版本，模型供应商如果还留着多个 Base URL，排错会非常痛苦：你以为是 MCP 工具没返回，实际是模型请求打到了另一个 Key。把模型通道固定到 TaoToken，只保留一个 Base URL 和一个 Key，MCP 和 Skill 的变量就能分开看。先分清三层，再动配置文件，后面每一步都能独立验证。

2. 在 OpenOcta 里配 mcp.servers 之前，先固定模型通道

2.1 去官网创建 YOUR_API_KEY，别急着填 MCP 命令

先打开 TaoToken 注册并创建 API Key，复制出来的值在 OpenOcta 配置里统一写成占位符YOUR_API_KEY。模型 ID 不要猜，去模型广场看当时列表，把选中的 ID 填到YOUR_MODEL_ID。这一步先于mcp.servers，因为模型通道不通时，MCP 工具是否正常根本看不出来。很多同会话报错并不是 MCP 挂了，而是模型请求根本没拿到响应。

2.2 OpenOcta 自定义 API 配置：Base URL 只填 https://taotoken.net/api

在 OpenOcta 的模型供应商/自定义 API 里新增一条渠道，Base URL 填https://taotoken.net/api，末尾不要加/v1，也不要加任何查询参数。API Key 用刚才从官网创建的YOUR_API_KEY。如果界面分“OpenAI 兼容”“Anthropic 兼容”，按 OpenOcta 当前文档选对应兼容项；拿不准就先在模型对话里用同一把 Key 发消息确认。这个 Base URL 是给工具调用的接口地址，不要和官网注册页混用。

2.3 一个 OpenOcta 工作区配置示例

下面示例把模型通道和 MCP 声明放在.openocta/config.json，字段按你本地 OpenOcta 版本调整，重点是 Base URL 和 Key 的写法。

{ "model": { "provider": "custom", "baseUrl": "https://taotoken.net/api", "apiKey": "YOUR_API_KEY", "modelId": "YOUR_MODEL_ID" }, "mcp": { "servers": {} } }

保存后重启 OpenOcta 或重载工作区，先不挂 MCP，发一条“你好，请回复当前模型名”的消息，确认模型通道成功。成功后再继续加mcp.servers，这样出错时只需要看 MCP 这一层，不用同时怀疑 Key、Base URL、模型 ID 和 Skill 优先级。

3. mcp.servers 声明服务器：stdio 与 URL 两种写法

3.1 stdio MCP server 在 OpenOcta 里的配置

stdio 型 MCP server 由 OpenOcta 启动子进程，配置里要写command、args和必要的env。路径建议用绝对路径或工作区相对路径，不要依赖终端当前目录。下面这个ops-log只读本地导出的巡检日志，返回时间戳、来源和摘要。

{ "mcp": { "servers": { "ops-log": { "command": "node", "args": ["./.openocta/mcp-servers/ops-log/index.js"], "env": { "LOG_DIR": "./fixtures/logs", "READ_ONLY": "1" } } } } }

这里的ops-log只读本地导出的巡检日志，返回时间戳、来源和摘要。变更动作、修复命令、数据库写入都不放在 MCP server 里；需要诊断 SQL 时，让 Agent 生成 SQL 或解释思路，读者在本地执行，再把结果贴回。OpenOcta 的 MCP 面板里应该能看到ops-log下的工具列表，看不到就先查 server 启动日志。

3.2 URL 型 MCP server 在 OpenOcta 里的配置

如果 MCP server 已经以 HTTP 服务方式跑在本地，可以用 URL 声明。注意这个 URL 是 MCP 服务自己的地址，和模型 Base URL 是两回事，不要混。

{ "mcp": { "servers": { "asset-api": { "url": "http://127.0.0.1:8787/mcp", "transport": "http" } } } }

配置后看 OpenOcta 的 MCP 面板是否出现工具列表。工具名通常带 server 前缀，例如ops-log.query、asset-api.list。如果列表为空，先看 server 进程有没有起来，再看mcp.servers的键名和 transport 是否对。URL 型服务最容易踩的坑是端口写错，或者把模型接口地址误填到这里。

3.3 装完先单独测 MCP 工具，不要和 Skill 一起排错

点开单个 MCP 工具，用一条只读请求试跑，比如“列出最近 10 条日志摘要”。确认返回里有真实数据、时间戳和来源，再继续写SKILL.md。MCP 和 Skill 同时报错时，排查成本会翻倍；先把连接层跑通，再把方法论层叠上去。这样同会话里 Agent 调用工具时，你能确认拿到的是 MCP 返回，而不是模型自己编出来的内容。

4. SKILL.md 按优先级加载：工作区、托管、内置谁先谁后

4.1 工作区 Skill 的 SKILL.md 示例

在 OpenOcta 工作区建.openocta/skills/inspection-report/SKILL.md，用 frontmatter 写名称、描述、优先级和允许调用的 MCP 工具。下面是一份可复制的巡检报告 Skill。

--- name: inspection-report description: 按固定结构生成巡检报告，数据必须来自 MCP 工具返回 priority: 100 allowed-tools: - mcp.ops-log.query - mcp.asset-api.list --- # 巡检报告 Skill ## 工作流 1. 调用 MCP 工具 `ops-log.query` 拉取最近 30 分钟日志摘要。 2. 调用 MCP 工具 `asset-api.list` 拉取目标资产列表。 3. 按“范围、异常、证据、建议”四段输出。 4. 每个异常必须带 MCP 返回的时间戳和来源，缺失就标注“数据缺失”。 5. MCP 工具失败时停止推断，只输出失败原因和已取到的字段。

priority越高越先被选中。工作区 Skill 适合放当前项目特有的巡检格式，不要把所有临时提示词都塞进来。allowed-tools写得越窄，Agent 在同会话里越不容易把无关工具拉进来。

4.2 托管 Skill 和内置 Skill 的覆盖关系

托管 Skill 放在~/.openocta/skills/，跨项目可用，优先级低于工作区。内置 Skill 随 OpenOcta 发行，优先级最低。同一名称的 Skill 出现时，工作区版本覆盖托管版本，托管版本覆盖内置版本。调试时可以在 OpenOcta 面板看实际加载路径，不要只看文件名。工作区里改了SKILL.md但没生效，先检查有没有同名的托管版本在旁边抢优先级。

4.3 同会话里 Agent 如何按 Skill 组织步骤再调 MCP

当用户提问“按 inspection-report 输出报告”，Agent 先命中工作区 Skill，读取工作流；然后按allowed-tools调用 MCP 工具；最后按 Skill 规定的四段结构生成产物。此时模型调用的仍是固定渠道，Base URL没有被 MCP 或 Skill 改写。把这三层分开看，排错路径就清晰：模型不通查 Key，工具不返回查 MCP server，产物结构不对查 SKILL.md。同会话里既挂 MCP 又启 Skill，最怕的就是把这三个问题混成一个“AI 又抽风了”。

5. 用“巡检报告”跑一次同会话验证

5.1 提问模板要同时点名 Skill 和 MCP

在 OpenOcta 同会话里发一条明确点名两者的提问：“按 inspection-report Skill 输出一份巡检报告，数据来自 MCP 工具 ops-log 和 asset-api，不要编造，缺失字段直接标注。” 这条提问同时触发 Skill 加载、MCP 工具调用和模型推理，适合做端到端检查。提问里写清楚工具名和 Skill 名，能避免 Agent 自己猜加载了哪个版本。

5.2 检查三类成功信号：MCP 取数、Skill 结构、模型调用

第一，看 OpenOcta 的工具调用记录里是否有ops-log.query和asset-api.list的真实返回；第二，看最终产物是否按“范围、异常、证据、建议”四段输出；第三，去 TaoToken 控制台看这次调用有没有记上账、用的模型 ID 是否一致，入口还是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 。三个信号都对，说明同会话挂 MCP 和 Agent Skills 已经跑通。只要有一个信号不对，就按层排查，不要先改提示词。

5.3 同会话里换 Skill 时不要动模型通道

启停工作区 Skill、切到托管 Skill，或者在mcp.servers里临时加一个只读工具，都不需要改Base URL和 Key。模型通道保持https://taotoken.net/api，Key 保持YOUR_API_KEY对应的那一把。这样 Skill 和 MCP 的变更不会把模型调用一起带乱。验证通过后，再把临时加的 MCP 工具固化到工作区配置里，方便团队复用。

6. OpenOcta 挂 MCP + Skills 常见报错与排查

6.1 MCP server 启动失败或工具列表为空

stdio 型先看command是否在 PATH 里、args路径是否相对工作区、env是否漏了 Node 或 Python 运行时。URL 型先看端口是否被占用、transport是否写对、服务是否真的返回 MCP 协议。工具列表为空时，把 OpenOcta 的 MCP 日志级别调高，看它有没有连上 server。工具名带没带前缀，也决定 Agent 在 Skill 里能不能按allowed-tools找到它。

6.2 Skill 没被加载：优先级和 frontmatter 踩空

SKILL.md路径大小写、目录层级、frontmatter 的name与调用名不一致，都会导致 Skill 不命中。工作区、托管、内置三档优先级不要凭感觉猜，直接在 OpenOcta 面板看加载来源。如果工作区 Skill 没生效，检查它是否被同名的托管或内置版本覆盖。priority写错成字符串、allowed-tools缩进错误，也会让 Skill 半加载。

6.3 模型侧 Key 或 Base URL 填错时的表现

Key 没替换成YOUR_API_KEY对应值，通常直接 401；Base URL 写成https://taotoken.net/api/v1，可能 404 或提示路径不存在。正确写法只有https://taotoken.net/api，末尾不要加/v1，也不要把官网注册链接填进baseUrl。模型 ID 不要猜，以模型广场当时列表为准。OpenOcta 里如果同时存在多个自定义供应商，确认当前工作区到底选了哪一条。

6.4 同会话 Context 太乱：把只读数据和执行动作分开

巡检报告里混入变更命令、生产连接串或完整大日志，会让模型注意力分散。MCP 只返回摘要和证据字段，执行动作交给读者本地完成；需要 SQL 时，让 Agent 生成 SQL 或解释 SQL，读者在本地或受控客户端执行，再把结果贴回对话。这样同会话既保留 Skill 的结构，又不会把 MCP 变成“什么都干”的黑盒。Skill 负责收口，MCP 负责取数，模型只负责推理和整理。

7. 配通之后，Key、套餐和文档各自去哪里

7.1 模型对话先验同一把 Key

配完 OpenOcta 的巡检报告后，先去 TaoToken 模型对话 用同一把 Key 发一条测试消息，确认模型 ID 和 Base URL 没填错。对话里能出结果，OpenOcta 里再报模型错误，就优先查 OpenOcta 工作区配置是否覆盖了渠道。模型对话能快速排除 Key 和模型 ID 的问题。

7.2 长期跑巡检再看 Coding Plan 和 API Keys

如果每天都要让 Agent 按 Skill 出巡检报告，可以打开 Coding Plan 看套餐是否够用；Key 的统一入口在 控制台 API Keys。模型广场的列表会变动，模型 ID 以当时页面为准，不要拿旧截图里的 ID 硬填。需要多把 Key 时，建议按项目或环境拆，不要混进同一个 OpenOcta 工作区。

7.3 需要命令行执行时再对照 Claude Code 文档

OpenOcta 主要负责把 MCP 和 Skill 挂进同一会话。若你还要用 Claude Code 跑命令行任务，环境变量对照见 Claude Code 接入文档，Base URL 同样填https://taotoken.net/api，Key 仍从官网创建。把模型通道收成一处之后，MCP 管连接、Skill 管步骤、OpenOcta 管会话，三者各司其职，后面加工具或换 Skill 都只是局部调整。