经 NexusDock 接入 ChatGPT：workspace_context 已出现在节点能力中，但当前会话无调用入口，影响 AGENTS.md 加载

[JTropy]

想确认的问题

通过 NexusDock 在 ChatGPT 中使用 AgentDock 时，观察到：节点声明支持 workspace_context，操作规则也要求在进入项目时先调用它，但当前 ChatGPT 会话的可调用工具定义中找不到这个入口。

想请作者确认这是否是已知的连接器 Schema 缓存、版本兼容或 NexusDock 工具透传问题，以及这种情况下项目 AGENTS.md 的加载有没有明确提示或兜底。

环境与实际观察

• 连接方式：ChatGPT → NexusDock → AgentDock 节点。
• 三个在线节点分别为 macOS/arm64、Windows/amd64、Linux/amd64，agentdock_context 均报告版本 0.9.0。
• 三个节点返回的 capabilities 均包含 workspace_context。
• 返回的操作规则明确要求：操作具体项目、切换工作区或规则可能变化时，先调用 workspace_context。
• 但当前会话按 workspace_context 重新发现 AgentDock 工具时，仅找到名称或描述匹配的 agentdock_context、mcp_tool_search，没有名为 workspace_context 的可调用工具及其输入 Schema。这一现象已在同一会话中再次核对。

节点返回摘要（删去设备标识、个人路径及无关字段）：

{
  "nodes": [
    {"os": "darwin", "arch": "arm64", "version": "0.9.0", "online": true, "capabilities": ["workspace_context", "..."]},
    {"os": "windows", "arch": "amd64", "version": "0.9.0", "online": true, "capabilities": ["workspace_context", "..."]},
    {"os": "linux", "arch": "amd64", "version": "0.9.0", "online": true, "capabilities": ["workspace_context", "..."]}
  ]
}

对架构的理解，请作者确认

阅读以下源码快照后，我的理解是：

1. agentdock_context 不返回全局或项目 AGENTS.md 的正文。
2. MCP 初始化只提示模型主动调用 workspace_context，不直接注入规则正文。
3. workspace_context(workdir) 才会读取全局规则和项目目录继承链；仅执行 cd 或给命令传入 workdir，不等于已经调用规则加载器。
4. NexusDock 应把 workspace_context 作为节点级工具转发，而不是作为中心自有工具过滤。

参考：

• AgentDock 工作区上下文文档，快照 c5f1dae
• AgentDock workspace_context 实现
• AgentDock MCP 初始化说明
• NexusDock canonical tool 的节点归属处理，快照 1313218

这里不是把“按需加载而非强制自动读取”的设计本身认定为 bug，而是担心标准入口缺失时，客户端仍可以执行命令、读写项目，但项目规则可能被跳过。

希望确认

1. 作者是否已知这种“capabilities 声明存在，但客户端可调用工具缺失”的情况？推荐从哪一层排查？
2. 是否有明确的 AgentDock/NexusDock 版本组合要求，或需要刷新连接器并新建会话的条件？
3. 当 workspace_context 不可用时，是否已有规则未加载的提示或回退方式？是否考虑对这类能力声明与工具暴露不一致增加诊断？
4. 如果工具正常暴露，但模型没有主动调用它，目前是否完全依赖模型遵循提示，而没有项目操作前的强制检查？

证据边界

• 当前确认的是 ChatGPT 本次会话的工具发现层 缺少入口，不能据此断言 AgentDock Core 或 NexusDock 的服务端原始 tools/list 也缺少它。
• 尚未取得已鉴权的服务端原始 tools/list，也未完成“刷新连接器 + 新建会话”后的对照验证，因此缓存、部署版本和网关透传都只是待排查方向。
• 节点只报告 0.9.0；上述源码链接是审阅快照，尚未核对部署二进制的具体 commit，也未确认当前 NexusDock 部署 commit。
• 没有修改配置或关闭认证。个人路径、节点 ID、域名及凭据均未附上。

已用 workspace_context 和 AGENTS.md 检索 AgentDock、NexusDock 的现有 issue，未找到匹配项。若更适合在 NexusDock 仓库跟踪，烦请告知或转移，谢谢。

[uvwt]

理解基本正确。

1. 这种情况从目前现象看更像是 ChatGPT 侧仍在使用旧的工具 Schema。可以先在 GPT 的 Nexus 插件页面刷新工具或重新连接，然后新建会话再确认 workspace_context 是否已经出现。

2. 现在 NexusDock 和 AgentDock 的版本已经做了对应，大版本建议保持一致，避免工具契约或能力存在版本差异。

3. 如果确认 Nexus 服务端已经正确暴露 workspace_context，但 ChatGPT 当前会话里仍然没有，那么属于GPT平台侧旧 Schema / 缓存问题，AgentDock 本身无法直接干预。

4. MCP 初始化 instructions 和 agentdock_context 中都有提示模型在操作具体项目、切换工作区或规则可能变化时先调用 workspace_context。正常情况下模型会遵循这个提示，但目前不是 Core 层强制拦截，也不会因为执行了 cd 或传入 workdir 就自动触发。

[JTropy]

感谢说明，两个问题的边界清楚了。

工具入口缺失：刚在同一个 ChatGPT 会话里重新发现了一次工具，仍未取得 workspace_context 的调用 Schema。不过这不属于“刷新插件／重新连接 + 新建会话”的对照验证，也还没有已鉴权的 Nexus 服务端原始 tools/list，所以目前不能确认缓存就是根因，更不能据此认定 Core 或 NexusDock 有 bug。排查顺序理解为：先核对 NexusDock 与 AgentDock 大版本，再确认 Nexus 服务端是否暴露该工具，最后刷新连接器并在新会话检查。原报告中这部分仍是待验证现象。

AGENTS.md 加载：明白了，即使工具入口正常，也仍依赖模型主动调用 workspace_context；cd／传入 workdir 本身不触发读取，Core 也不强制拦截。原先“进入项目是否自动读取”的疑问已经得到明确答复。

还有一个使用体验上的建议，供参考：在面向用户的文档或排障说明中突出区分“节点支持规则加载”“本次已返回规则正文”“模型是否遵循规则”这几件事，并说明工具不可用或模型漏调时如何发现、如何处理。若后续考虑可选的加载诊断提示，也能减少用户误以为项目规则已生效的情况；不一定需要强制拦截所有操作，也不需要把规则全文塞进初始化上下文。

谢谢解答！