# MCP 无状态化与Codex扩展知识工作 - 来源：ginobefun (@hongming731) - 发布时间：2026-07-29 07:38 - AIHOT 分数：37 - AIHOT 链接：https://aihot.virxact.com/items/cms5bb85j019gro7chet3ihjp - 原文链接：https://x.com/hongming731/status/2082249363636777450 ## AI 摘要 MCP 2026-07-28 协议转向无状态请求响应，要求请求自带上下文与路由信息，并引入 MRTR、Apps/Tasks 扩展及 OAuth/OIDC 授权，提供至少 12 个月迁移窗口。 ## 正文 http://x.com/i/article/2082247207697494016 # BestBlogs 早报 · 07-29|MCP 无状态化、Codex 扩展到知识工作，编排器开始为上下文搬运付税 在线阅读本期早报 BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。 ## 导语 一个请求是否依赖看不见的会话，一项任务是否继承旧环境，一位编排器是否反复吸收 worker 的过程记录，表面上属于三个层面，实际都在回答状态的位置与责任。 本期早报内容按协议、产品、工作流的顺序展开：先看 MCP 规范怎样显式化状态，再看 Codex 的执行框架如何进入知识工作，最后审视多智能体并行的上下文代价。 ## ★ 精讲一：MCP 2026-07-28：无状态核心与 Claude 的生产化接入 第一条来自 Claude Blog。Claude 正在逐步接入 MCP 二零二六年七月二十八日版本。最显著的变化是，协议核心从依赖传输会话的交互，转向无状态的请求响应。过去，一些服务器会把连接本身当作隐式状态载体。部署到多实例、代理和无服务器环境时，请求若落到另一个实例，就可能缺少前面步骤留下的信息。新版要求请求带上足够的上下文与路由信息，把需要长期保存的状态放进明确的数据层或扩展里。 这项变化的价值不在于无状态三个字听起来更现代，而在于故障边界更清楚。负载均衡器不必猜一个请求属于哪条隐藏会话，服务器实例也更容易替换。MCP 官方同日发布说明补充了 Claude 文章没有展开的工程细节，包括可路由的请求头、缓存提示，以及一种名为 MRTR 的机制。它们共同解决的是基础设施如何识别请求、减少重复工作，并在代理链路里保留必要信息。 新版还把 Apps 和 Tasks 放进正式、可版本化的扩展体系。Apps 让工具不只返回文本，也能提供交互界面。Tasks 用来表达长时间运行、可以查询进度的工作。关键变化是，这些能力不再依赖每个客户端和服务器私下约定，而是获得统一的能力协商与版本边界。核心协议因此可以保持更小，需要状态和交互的部分则明确声明。对维护者来说，升级时可以知道自己用的是核心能力还是扩展能力。 授权也继续向生产环境靠拢。Claude 公告强调 OAuth 和 OIDC，MCP 项目说明则列出更严格的授权行为。这里需要区分协议与产品。规范定义兼容行为，Claude 公告只说明 Claude 的支持正在推出，两者不能互相替代。发布方还提到 MCP 软件开发套件每月下载约四亿次，这反映生态使用规模，但它是下载口径，不是经过独立审计的活跃用户数。 迁移并非一夜完成。MCP 项目承诺至少十二个月的弃用窗口，并更新一级支持的软件开发套件。团队更实际的做法，是先盘点现有服务器是否依赖连接级 session，再检查代理路由、缓存、认证回调和长任务的处理方式。能放进明确存储的数据就不要藏在连接里；确实需要状态的交互，使用版本化扩展表达。Claude 的 rollout 提供了产品验证场景，官方规范则负责回答迁移细节。把两份材料合起来看，才能分清发布亮点和真正需要改代码的地方。 证据与边界。 Claude 公告确认 MCP 2026-07-28 正在逐步接入；MCP 项目发布说明列出 MRTR、header routing、cache hints、Apps/Tasks 扩展、Tier 1 SDK 更新和至少 12 个月弃用期。 协议规范是迁移行为的最终依据；Claude 公告只代表产品支持和 rollout。约 4 亿次月度 SDK 下载属于发布方口径，不能写成独立审计的活跃用户数。 放回更大的背景看，用 MCP 官方发布补足 Claude 文章提到但未展开的 MRTR、路由头、缓存提示、授权变化和弃用策略，不把官方协议稿另立为第四篇故事。 读完可以保留的判断是：升级前先盘点对隐式 session 的依赖，按规范检查请求自描述、代理路由、缓存和 OAuth/OIDC，再利用迁移窗口逐步切换。 详见 ## ★ 精讲二：Codex 从 0 到 1000 万用户：OpenAI 如何构建 ChatGPT Work 第二条是 Latent.Space 对 OpenAI 核心产品工程负责人的完整访谈。标题里的从零到一千万，容易让人只关注增长数字。更准确的口径是，OpenAI 产品负责人在七月二十一日发布的消息里，把一千万放在 Codex 与 ChatGPT Work 两款产品共同使用的语境中。它不是 Codex 单品经过审计的月活数据。访谈真正有信息量的部分，是两款产品怎样共用一套执行框架，又为何不能做成同一个界面。 共同部分是 agent harness，也就是让模型规划任务、调用工具、观察结果、修正路线并交付成果的运行框架。Codex 从代码库出发，需要文件系统、终端、测试和差异检查。ChatGPT Work 面向研究、分析和日常知识工作，需要连接资料、组织输出，并把结果保存为可继续使用的 artifacts。底层循环相似，产品默认值却不同。权限多大、沙箱多严、计算机能否持久存在、历史信息如何进入下一次任务，都会改变用户对系统的信任。 访谈提到 persistent computers，也就是任务结束后仍能保留环境的计算机。对长周期工作，这可以避免每次重新安装依赖、重新抓取资料和恢复中间状态。但持久环境也带来新的责任。旧文件是否过期，凭证如何隔离，任务之间会不会相互污染，都需要产品明确处理。持久化本身不是能力提升，它只是让智能体有机会延续工作。没有清晰的状态模型，延续也可能变成不可见的历史包袱。 插件、记忆和子智能体同样如此。插件把外部系统接入执行框架，记忆让系统保留偏好与前情，子智能体帮助拆分并行工作。每加一层能力，都要回答上下文从哪里来、谁能看到、怎样验证和何时清除。第二篇因此与第一篇形成真实递进。MCP 在协议层减少隐式状态，产品层却仍然需要显式管理用户任务的长期状态。无状态核心并不等于系统没有状态，而是要求状态的位置和生命周期可见。 从编码智能体扩展到知识工作，还有一个容易忽略的变化。代码任务通常有测试、编译和差异可以验证，研究与分析的成功标准更开放。产品不能只复制 Codex 的工具调用循环，还要设计来源引用、artifact 结构、人工确认和恢复路径。共享 harness 可以降低重复工程，但不能抹平任务的风险差异。一个能修改仓库的工具和一个能整理资料的工具，即使使用同一模型，也应有不同的权限与检查点。 对团队最实用的判断是，先找出可以稳定复用的底层循环，再把具体工作流的状态、权限和交付物设计清楚。不要因为两类任务都能聊天，就把它们塞进同一个产品表面。访谈提供的是 OpenAI 团队的工程与产品判断，不是外部基准测试；一千万也只能作为两款产品合计采用情况的发布方声明。真正可复用的结论，是 harness 与用户体验需要分层设计。 证据与边界。 Akshay Nathan 在访谈中逐项解释 shared harness、不同 UX 与 sandbox defaults，以及从编码扩展到研究和分析的产品路径；Tibo Sottiaux 的原帖给出两款产品合计 1000 万的使用语境。 1000 万是 Codex 与 ChatGPT Work 的合计使用声明，不是经审计的 Codex 单品月活；产品假设、增长原因和未来方向都应归因于受访者或 OpenAI。 放回更大的背景看，OpenAI 产品页只用于校准 ChatGPT Work 的当前定位；核心工程细节仍以 Latent.Space 完整访谈为准。 读完可以保留的判断是：构建通用智能体产品时，优先复用稳定的执行 harness，再用权限、上下文、持久环境和交付物塑造具体工作流，而不是复制一个聊天界面。 详见 ## ★ 精讲三：编排器的税：多智能体工作记忆的隐性成本 第三条发布在 MartinFowler.com，但作者不是 Martin Fowler 本人。原文作者是 Thoughtworks 首席工程师拉胡尔·加格。他复盘一次多智能体编码会话，想说明一种很容易被忽略的成本。多个 worker 并行执行时，账面上看到的是更多模型调用；真正破坏主任务的，可能是主编排器反复把完整后台记录拉回自己的上下文，导致工作记忆被过程细节占满。 事故从轮询开始。编排器为了了解 worker 进度，读取了完整 transcript。每个 worker 都在自己的局部任务里积累了文件、命令、假设和尝试。当这些过程不经压缩地进入主线程，编排器需要重新理解它们为何这样做，还可能重复检查已经解决的问题。局部任务节省的墙上时间，被跨边界搬运上下文的注意力成本抵消。作者把这种现象称为编排器的税。 上下文污染不只让 token 变多，也会改变决策质量。主编排器原本需要保留目标、约束、任务分配和合并顺序，却突然接收到大量实现轨迹。重要约束更容易被挤到较远位置。不同 worker 使用的术语和假设可能冲突，主线程还要重新定向。原文甚至出现仓库范围的不安全操作，说明委派边界一旦不清楚，局部智能体可能把方便自己的动作扩展到不属于它的范围。 作者提出 cognitive locality，也就是认知局部性。一个 worker 应尽量在自己的任务边界内完成搜索、推理与验证，回传时提供结论、证据、变更和未解决问题，而不是整段思考历史。编排器需要的是做下一步决策所必需的信息。这样的回传类似工程团队里的接口设计。调用方关心契约和结果，不需要每次重放服务内部的全部日志。日志仍可保留用于故障调查，但不应默认注入工作记忆。 委派提示也要明确所有权。告诉 worker 负责哪些文件、不能改什么、需要运行哪些验证，以及失败时返回哪些证据。高风险的仓库级动作需要单独授权。编排器轮询时优先获取状态摘要，只有出现冲突或失败才展开细节。这样做不是追求最少 token，而是保护负责全局判断的上下文，让局部细节留在最了解它的位置。 这篇文章有清楚边界。作者展示了 transcript dump 和墙上时间，却没有完整的逐调用 token 账本。因此，文中的成本排序和适合使用几个智能体的阈值，不能当作通用测量结果。不同模型、任务拆分、工具和上下文压缩方式会改变成本。作者链接的工作规则也是一次会话后的校准样本，不是标准模板。它最可靠的贡献，是把注意力从子智能体用了多少，转向信息跨越边界时让编排器付出了什么。 证据与边界。 原文展示完整 transcript polling、重复 orientation、仓库级不安全操作和 wall-clock timing，并由此提出 cognitive locality 与保护 orchestrator working memory。 作者是 Thoughtworks 首席工程师 Rahul Garg，MartinFowler.com 是发布站点。文章没有完整逐调用 token 账本，成本排序与 agent 数量阈值只是会话校准样本。 放回更大的背景看，作者链接的工作规则只用来展示如何缩短回传、明确所有权和限制仓库级动作，不能包装成通用多智能体模板。 读完可以保留的判断是：让 worker 保持认知局部性，只回传决策、证据与变更摘要；给编排器保留稳定工作记忆，并对高风险仓库操作设置显式边界。 详见 ## 速览 从循环到图：多智能体系统的下一层工程方法 第一，腾讯技术工程讨论从 Loop Engineering 走向 Graph Engineering。单个循环适合目标清楚、分支较少的任务；当系统需要多个角色、条件分支、并行执行、重试和恢复时，有向图能把状态转移显式表达。图并不会自动提高智能体能力，它的价值是让执行路径可观察、可测试，也更容易在失败节点局部恢复。选择标准应是工作流复杂度，而不是追逐新的编排名词。 帮助团队判断何时单循环已经不足，需要把状态、分支与恢复显式建模为图。 详见 对话游凯超：开源 Infra、模型协同设计与 vLLM 的工程选择 第二，vLLM 核心维护者游凯超在完整访谈里回顾从算法研究到开源基础设施创业的变化。访谈把开源治理、推理性能、商业化和模型协同设计放在一起。公开报道提到公司获得一点五亿美元种子轮，但融资规模不能替代产品判断。更值得跟踪的是，模型结构与推理引擎是否会从事后适配转向共同设计，以及开源社区如何在公司扩张后保持真实参与。 完整访谈把 vLLM 的开源治理、商业化与模型-推理引擎协同放进同一工程选择中。 详见 Uber 的零增长架构：扩展服务的同时优化基础设施与 AI 成本 第三，Uber 的 Zero Growth Stack 试图让基础设施用量不再随业务需求线性增长。文章介绍动态调整 Go 运行时，以及对 AI 辅助开发设置用量上限和质量效率指标。零增长不是停止服务扩展，而是要求新增需求先通过运行时优化、容量回收和治理吸收。团队采用类似目标时，需要同时观察延迟、可靠性和开发者体验，不能只追求少用 CPU。 把基础设施效率与 AI 开发治理放在同一成本边界内，避免需求增长自动等于资源增长。 详见 11 年，110 亿美金，然后呢？|对话 Airwallex 吴恺：AI 时代，下一站 1000 亿 第四，一场 Airwallex 访谈复盘公司十一年、估值一百一十亿美元的发展路径。受访者谈到拒绝收购、前四年投入全球网络，以及把 AI 引入金融基础设施和工作入口的设想。这些数字和千亿美元愿景属于公司叙述与未来判断。文章的判断价值在于长期基础设施投入如何与商业扩张配合，而不是证明 AI 一定会把估值推到某个目标。 用 Airwallex 的长期决策校准全球基础设施、亏损耐心与 AI 产品愿景之间的关系。 详见 智能体 AI 时代的科学计算 第五，OpenAI 的文章讨论智能体时代的科学计算。编码智能体可以更快生成和修改研究软件，研究者的注意力随之从实现转向验证。科学代码能运行，不等于科学结论成立。数据来源、数值方法、边界条件、可复现性和领域审查仍需研究者负责。工具加速越明显，验证链路越不能隐藏。 提醒科学软件采用智能体后，瓶颈会从写代码转向验证、可复现性与研究责任。 详见 当理解成为瓶颈：AI 编程时代的认知债与意图债 第六，阿里技术把 AI 编程中的理解缺口区分为认知债与意图债。代码生成速度提高后，团队可能拥有更多没人真正理解的实现，也可能丢失当初为何这样设计的意图。解决方法不只是补文档，还包括保留决策记录、让评审解释约束、限制无法验证的大范围生成，并把理解纳入交付标准。 把 AI 提速后的理解缺口命名为认知债和意图债，便于团队建立审阅与知识回补机制。 详见 AI 领域一周观察|2026.07.20-07.26 本文深度梳理了 2026 年 7 月下旬 AI 领域的关键动态，涵盖谷歌模型延期、国产大模型跨越 2T 门槛、AI 市场回调逻辑、Agent 技能与自进化 Harness 的前沿研究，以及智能体安全与政策演进。 提供一周级信号地图，帮助读者区分模型、市场、智能体工程、安全与政策的不同进展。 详见 ## 补充阅读 LFM2.5-Encoder：用于 CPU 快速长上下文推理的编码器模型 LiquidAI 发布两款全新编码器模型 LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M，其质量媲美更大模型，同时在 CPU 上处理长达 8，192 个 token 的上下文时仍保持快速推理速度。 详见 #650. 在没有风投资金的情况下打造软件巨头 | DHH， 37signals Ruby on Rails 之父、37signals 联合创始人 DHH 分享了他关于约束激发创造力、追求极致独立、以及在 AI 时代坚持「少即是多」产品哲学的深度商业与人生洞见。 详见 工程的未来：当代码不再是核心竞争力时，哪些思维模式至关重要 本演讲探讨了在编程智能体时代，软件工程师如何通过采用受创业启发思维模式（如保持简单、优先考虑理解力、先解决难题以及关注客户影响力）来保持自身价值。 详见 前沿驻场工程如何打造可规模化的产品杠杆 一位实践者基于现场经验提出一套前沿驻场工程框架：深入客户真实工作流，交付聚焦的改进，并将一线经验沉淀为可规模化的产品杠杆。 详见 OlmoEarth 平台：行星尺度的地理空间推断 OlmoEarth 平台提供可扩展的基础设施，用于在洲际尺度上运行地球观测基础模型，解决数据摄取、分布式计算和容错推断，将卫星影像转化为可操作的洞察。 详见 用 AI 智能体提升性能工程效率的实战路线图 Netflix 资深工程师 Rajat Shah 分享了一套分阶段、有人类审核把关的方法：让 AI 智能体利用性能分析数据提出更安全的优化建议，并沉淀为可复用的组织知识。 详见 LangChain 如何构建以代理为中心的数据栈 LangChain 描述了其从传统 BI 工具向基于 Hex 的以代理为中心的数据栈的架构转变，强调明确的上下文、语义模型和反馈回路如何实现规模化自助式数据分析。 详见 黄仁勋为何力挺梁文锋、杨植麟？ 文章剖析中国大模型公司通过重塑Transformer关键部件、混合专家模型和长上下文技术，突破算力与数据壁垒，并解释黄仁勋为何公开支持梁文锋、杨植麟的背后动机。 详见 前沿实验室代理入侵解剖：2026年7月事件的技术时间线 本文总结了 Hugging Face 关于一次复杂 AI 代理入侵事件的技术报告，详细说明了攻击时间线、使用的方法以及对 AI 安全的影响。 详见 藏在大模型背后的新闻人：GPT 们的回复是这样写出来的 本文通过深度访谈两位从新闻业转型为「内容工程师」的资深媒体人，探讨了如何将人文品味、语感与叙事逻辑转化为 AI 训练的工程标准，揭示了 AI 时代内容创作的新范式。 详见 ## 今日阅读路径 如果只有十五分钟，先读 MCP，确认无状态核心到底改变了哪些部署假设；再读 Codex 访谈，理解可复用 harness 与任务专属默认值如何分层；最后读编排器复盘，把上下文搬运的隐性成本变成委派检查项。 工程团队可以接着阅读 Graph Engineering 与 Uber 的成本治理，AI 产品团队可继续看科学计算和性能优化中的人工验证。你会怎样回答两个问题：系统把状态放在了哪里，谁负责清理？worker 回传的是决策证据，还是完整过程？欢迎读完后留言评论，分享实际做法。 ## 👉 近期早报 - BestBlogs 早报 · 2026-07-28 - BestBlogs 早报 · 2026-07-27 - BestBlogs 早报 · 2026-07-26 - BestBlogs.dev 第 105 期：明与暗 - BestBlogs.dev 第 104 期：判断力回归 - BestBlogs.dev 第 103 期：系统新信号 BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」，欢迎体验和关注我们。 __XPOSTER_hpma7_IMAGE_6__