技术简报 · 第 2026-08-17 号
技术简报 - 2026-08-17
本页目录6 节
本期概览
#今天两条，问的是同一件事：智能体的流量该由哪一层承载，谁来治理它。
MCP 无状态化之后，被少报的是另一半。 本站 08-01 发过那次规范改动，写的是废除会话之后任何请求都能落到任意实例。同一版还新增了两个必需的 HTTP 标头——Mcp-Method 与 Mcp-Name——于是网关、限流器或 WAF 不用打开请求正文就能按方法或按工具做路由、限流和计量。方向的变化才是重点：智能体治理此前一直是坐在协议之上的独立控制层，现在元数据进了传输层，基础设施团队已经在跑的系统读得懂它。代价同样具体：人工审批从一条保持的连接变成两个请求，等待人类不再位于单次调用内部。
Cloudflare Computer 从另一头回答同一题。 它认为容器根本不该是运行智能体的单位：框架跑在 isolate 里，容器按需连上来当一次工具调用，两边共享一套基于 SQLite 的文件系统。一个把治理放进协议，一个把执行换掉单位。
还有一组方向相反的数字，值得单独记。 Anthropic 报告 MCP SDK 月下载超过 4 亿次、今年增长三倍；而一次咨询审计发现某客户的服务器三个月只记录了 61 次工具调用，其中 58 次来自客户自己的工程师。下载量衡量可得性，调用量衡量使用——这是本站这一周里第二次踩到同一个区分，上一次是昨天那份开放模型生态报告。那篇咨询帖自己的收尾也指向同一处：钱正在流向网关、注册中心和鉴权层，而不是服务器本身。
本期立即关注
#精选评级最高的已发布技术信号，编辑置顶的条目优先展示。
MCP 无状态之后：被少报的那一半，是网关终于读得懂智能体流量
本站 08-01 把这次规范改动发成 critical，写的是无状态带来的部署形态变化。这条补上被少报的另一半：两个新的必需标头让网关不打开请求正文就能路由、限流和计量智能体流量——智能体治理此前一直是协议之上的独立控制层，现在元数据进了传输层。附带一组方向相反的数字：SDK 月下载 4 亿次，而一次审计里某台服务器三个月只有 61 次工具调用。
适合 已经在生产环境跑 MCP、需要规划无状态迁移与弃用窗口的平台团队、负责智能体流量限流、计量与鉴权的基础设施与网关团队、把人工审批做进工具调用链路、需要重新安排超时与状态归属的安全角色
值得跟踪
#值得跟进的信号，但在成为立即优先项之前仍需更多背景或验证。
Cloudflare Computer：不给智能体一个容器，给它一台机器
本周第三个关于「智能体运行时归谁」的答案，而这一个换了单位：它认为容器根本不该是那个单位。框架跑在 isolate 里，容器按需连上来当作一次工具调用，两边共享同一套基于 SQLite 的文件系统。目标写得很直白——让不到一成的工作才需要容器。仍是早期预览版。
适合 在为大量并发智能体做成本模型、被容器冷启动与常驻开销卡住的平台团队、需要让智能体在多次运行之间保留真实文件而不是靠提示词摘要接力的工程团队、在评估厂商托管运行时的锁定程度、需要把可迁移性写进决策记录的架构负责人
来源参考
#本期简报中已发布技术信号所代表的公开来源。
订阅简报
稳定的公开订阅源仅包含已发布的技术简报，草稿和已归档简报不在其中。