Qoder Cloud Agents 已支持 MCP 2026-07-28 核心协议
为 Agent 接入一个外部系统，通常不难。接入对象多起来以后，重复工作才会出现：能力描述、参数格式、授权流程和错误返回各不相同，每个系统都需要单独适配。单条链路很快可以跑通，跨系统复用却没有统一做法。这是我们在 Qoder Cloud Agents 接入外部工具时反复碰到的问题，我们更加倾向于选择 MCP 方式。
MCP 2026-07-28 做了重大的更新，它不是继续往核心里塞能力，而是删除握手和协议 Session、重写依赖长连接的交互方式，把 Tasks 移出核心，Roots、Sampling、Logging 等能力也开始进入弃用周期。在我们看来，核心管得更少，请求、路由、缓存和授权的规则反而更明确了。
先让每次请求独立成立
旧版 MCP 中，客户端首次连接要先完成 initialize/initialized。如果服务端创建了协议 Session，后续请求还要携带 Mcp-Session-Id。本地运行时，这套流程没有多少负担；Server 部署到多个实例后，同一 Session 要么持续回到原实例，要么依赖共享存储，普通 HTTP 服务就多出了一层会话管理。
新版移除了握手和协议 Session。协议版本与客户端能力随请求发送，客户端信息也可以一并携带；服务端必须实现 server/discover，客户端按需调用。服务端拿到一条请求，就能知道该按哪个版本和能力集处理，不必先找回此前的连接状态。
业务状态仍然存在。购物车可以返回 basket_id，故障处置可以传递 incident_id；需要跨请求保存的数据继续由应用持久化，只是不再藏在传输层 Session 中。模型也能看到这些 Handle，并在后续调用中明确传回。
多轮交互改用 Multi Round-Trip Requests，也就是 MRTR。工具需要补充参数或征求确认时，返回 input_required、inputRequests 和可选的 requestState；客户端收集答案后，带着 inputResponses 重新发起原调用。
Supabase 在官方发布中举过一个例子：创建项目之前确认费用，执行可能删除数据的查询前再次确认。交互能力还在，但暂停、回答和重试都变成了显式协议字段。SSE 仍可用于单次请求和 subscriptions/listen；退出的是独立 GET Stream、SSE 恢复，以及 Server 通过 SSE 发送独立 JSON-RPC 请求的方式。
左侧为依赖 Session 的请求路径，右侧为独立请求经普通负载均衡分发，并通过 MRTR 完成补充输入与重试。
核心做窄以后，协议反而更好落地
无状态只是其中一部分，新版 MCP 还补了几块过去落地时经常要业务自己处理的内容，同时把并非所有实现都需要的能力移到扩展层。
Streamable HTTP 请求现在携带 Mcp-Method，工具调用、资源读取等具名方法还会携带 Mcp-Name。
网关和限流器可以直接看到调用类型与目标；当识别到 Header 和 Body 对不上，服务端必须拒绝请求。这些 Header 不是身份证明，但可以直接用于路由、计量和策略判断。同时对于目录和资源结果增加了 ttlMs、cacheScope 等缓存提示，可以少拉几次相同内容；规范还建议 tools/list 使用确定性排序，有助于保持 Prompt Cache 稳定。
在采用 HTTP OAuth 的部署中，新规范加强了 Issuer 校验和凭据与签发方的绑定，Dynamic Client Registration 也被标记为弃用，后续推荐使用 Client ID Metadata Documents。
Tasks 从实验性核心能力迁移为扩展，MCP Apps、Enterprise-Managed Authorization 也各自协商。Roots、Sampling、Logging 和旧 HTTP+SSE 进入至少 12 个月的弃用窗口。以后增加高阶能力，不必再牵动整个核心协议。
Agent API 需要一套标准化协议
外部系统接入 Agent API 时，最先暴露的问题就是授权问题。不同系统可能使用 OAuth、PAT、AK/SK 或自定义 Token，凭据的获取、刷新、撤销和 Scope 表达也不一样。对单个应用来说，这些方式都可以正常工作；但是 Qoder Cloud Agent 需要同时连接多个系统时，平台就要反复处理相似但不兼容的接入逻辑。在这个过程中 MCP 并没有要求上游系统放弃原有 API 和账号体系，MCP Server 本身负责适配这些差异，再通过 Tools、Resources 和 Prompts 向 Agent 提供一致的能力描述、参数 Schema 与返回结果。
在采用 HTTP OAuth 的场景中，MCP 还约定了 Agent 到 Server 之间的授权流程。它没有统一所有系统的账号与权限模型，而是固定了 Agent 侧需要面对的接口，让同一套调用逻辑能够连接不同服务。
我们的判断很直接：面向长期运行的 Cloud Agent，MCP 很适合承担标准 API 这一层。它统一外部能力怎么被发现和调用，完整任务如何运行则由 Cloud Agent 平台负责。
连接由 MCP 统一，任务由 Qoder Cloud Agent 平台负责
一次工具调用能够发出去，只解决了连接问题。Cloud Agent 平台还要处理 Token 从哪里来、这项操作能否自动执行、什么时候必须等人确认，以及失败或暂停后从哪里继续。这些不属于 MCP Core，而是 Agent 平台需要承担的工作。
Qoder Cloud Agents 已支持 MCP 2026-07-28 核心协议。远程 MCP Server 通过 Streamable HTTP 接入，Vault 提供调用所需的凭据。工具权限为 allow 时直接执行，ask 会暂停任务并等待确认，deny 则拒绝调用；任务状态和事件记录始终保留在平台内。
在兼容性上，Qoder Cloud Agents 同时支持早期的 HTTP+SSE、带 Session 的 Streamable HTTP，以及 2026-07-28 引入的无状态 Streamable HTTP。存量 MCP Server 可以继续使用原有接入方式，新 Server 也能采用最新协议，不需要为了平台升级一次性完成迁移。对 Agent 平台来说，及时跟进新规范和保持存量兼容同样重要。
Cloud Agents 处理云监控告警
以云监控告警为例，告警触发任务后，Agent 可以通过 MCP 查询日志、监控和资源状态。只读工具可以设为 allow，重启、扩容等操作可以设为 ask，不允许 Agent 执行的动作则设为 deny。遇到 ask 时，平台保存当前任务进度，收到确认后继续执行，而不是重新开始整项排查。MCP Apps、Tasks、Enterprise-Managed Authorization 都是独立扩展。支持新版核心协议，不代表这些扩展已经全部开放。这样的分层也更符合我们的实践：接入方式可以统一，任务运行仍由平台负责。
回头看这次升级，MCP 的成熟并不体现在新增了多少能力，而在于开始明确哪些问题应该由协议解决。它移除协议 Session，让状态显式传递，将 Tasks 等高阶能力放入扩展，把凭据管理、权限判断和任务运行明确留给平台。核心看似变轻，职责却更加清晰，也更容易被不同产品稳定实现。所谓做少，不是少做，而是把必须统一的部分做扎实，把不该由协议承担的复杂度留在正确的位置。
