Cloudflare 一周拆了 Agent 的两堵墙：Code Mode MCP 与 Agent Memory

如果你最近在做 agent，大概率撞过这两堵墙。

第一堵是工具太多。一个稍大点的 API 用 MCP 暴露出来，光工具描述就能塞掉几万 token。Cloudflare 自己的 API 有 2500+ 个端点，全部展开是 1.17M token - 光读完描述模型就懵了，更别提还要带着这堆描述完成实际任务。

第二堵是记忆太短。模型每开一个 session 是张白纸。前一天调好的口味、上周纠正过的代码风格、团队约定俗成的命名规范，统统不存在。你只能要么把所有事情往 system prompt 里塞（很快满），要么每次重新解释一遍（累），要么自己造一个外挂记忆系统（重）。

这周 Cloudflare 发了两个东西，正好一边拆一堵。Code Mode MCP 把 1.17M token 的工具描述压成 1K，Agent Memory 把对话历史压成可索引的结构化记忆。

分开看是两个产品发布。放在一起看，是 Cloudflare 在写一篇统一的论文 - context 不够用了，我们得重新设计 agent 的存储层。

Code Mode MCP

先说工具墙这边。

传统 MCP 服务器的做法是把每个 API 端点暴露成一个工具，每个工具都带 name、description、input schema。模型在选择工具时，需要把所有候选的描述都看一遍。当 API 很大（Cloudflare 2500+，AWS、Stripe、GitHub 这种规模都类似），这个清单就大到塞不进 context。

Cloudflare 的解法叫 Code Mode，思路是：不把每个端点当工具，把整个 API 当代码用。MCP 服务器只暴露两个工具：

search(query)   # 在 OpenAPI spec 里搜端点
execute(code)   # 在沙箱里跑一段 JavaScript，调那些端点

模型不再 “select tool then fill args”，而是 “write code that calls APIs”。比如要帮一个域名打开 DDoS 防护，agent 的执行流程大致是：

// 1. 先 search 找到 WAF 和 ruleset 相关端点
const waf = await search("WAF ruleset")

// 2. 看看 schema 里有什么 phase 可选
const phases = await search("ruleset phase")

// 3. 用 execute 把这几步串起来
await execute(`
  const ruleset = await api.createRuleset({ phase: "ddos_l7", ... })
  await api.attachRuleset({ zone_id, ruleset_id: ruleset.id })
`)

99.9% 的 token 节省（1.17M → ~1K）就是这么来的：模型不需要预先看到 2500 个端点描述，它需要的时候自己去 search。execute 那一步在 V8 isolate 里跑，没有文件系统访问、没有环境变量泄漏、外网请求默认禁、按需开放。

这里有几个值得停一下看的设计选择。

沙箱选 V8 isolate 不是容器。 Cloudflare 的 Workers 本来就跑在 V8 isolate 上，这个选型省了启动时间（容器冷启 100ms+，isolate <1ms），同时把每个 agent 调用隔离开。是 Cloudflare 把自家既有 serverless 基础设施直接拿来当 agent 基础设施 - 不是新搭一套。

OAuth 2.1 + downscoped token。 模型生成的代码能调的端点，是用户授权的子集。不是 “给模型一个全权 token 然后祈祷它别犯傻”，是协议层面把权限扎死。

方向指向 MCP Server Portals。 Cloudflare 计划把 Code Mode 这层扩展到其他 MCP 服务器 - Stripe、Twilio、GCP 都可能用同一种 search+execute 接口暴露。如果这件事跑通，“MCP 工具列表” 作为一种暴露 API 的形式可能会被取代，更像是 OpenAPI 加沙箱执行器的组合。

Agent Memory

再说记忆墙。

现在主流的记忆做法大致三种：

• 塞 system prompt - 简单粗暴，很快撞 context 上限
• 塞 vector store - RAG 风格，做 embedding 加相似度查 - 对结构化的事实和时间相关的查询都不准
• 造一个 memory framework - Mem0、Letta、自家造轮子 - 组件多、维护重、跟 agent 框架耦合死

Agent Memory 的设计是把记忆当一个托管服务调用，agent 框架不变。它有四个操作：

ingest(conversation)    # 上下文压缩时，把对话提取成结构化记忆
remember(fact)          # 模型直接记一个事
recall(query)           # 检索相关记忆
forget / list           # 管理

提取出来的记忆有四类：

• Facts - 稳定的原子知识（“用户偏好 TypeScript 不喜欢 JavaScript”）
• Events - 时间相关的事件（“2026-05 用户切换到 pnpm”）
• Instructions - 流程性知识（“提交前要跑 lint”）
• Tasks - 暂时的工作项（“修一下这个 bug”）

这个分类比简单的 fact 列表细致，因为四类的检索语义不一样。Facts 适合 key-lookup，Events 适合时间范围查，Instructions 适合根据当前任务模糊匹配，Tasks 适合按 active 状态过滤。

最有意思的是检索那一边。Recall 不是单一通道的 vector search，是五路并行：

1. 全文搜索
2. Fact-key 精确查找
3. 原始消息搜索
4. 向量检索
5. HyDE (Hypothetical Document Embeddings) - 让模型先生成一个 “如果有相关文档应该长什么样” 的假设文档，再用这个假设文档做向量查

五路并行查，结果用 RRF (Reciprocal Rank Fusion) 合并。RRF 是个老 IR 算法，对每个候选按它在每路结果里的排名做 reciprocal 加权求和 - 简单但是稳。Cloudflare 把它和 HyDE、四类 memory 合到一起，等于把信息检索领域过去十年的经验完整搬到 agent memory 上。

底下的存储栈是熟人：

Durable Objects   ← 单 agent / 单租户的隔离 + 一致性
Vectorize         ← 向量索引
Workers AI        ← 提取、verify、classify 的模型推理
SQLite            ← 持久化结构化数据

每一层都不是新东西。新的是把这堆原本服务通用工作负载的 serverless primitive 对准 agent memory 这个用例。和 Code Mode 选 V8 isolate 一样，是把现有积木搭新房子，不是再造一个全栈。

还有一个被低估的设计点：memory profile 可以共享。一个工程团队的所有人可以挂同一个 memory profile - 一个人的 coding agent 学到的 “我们这边 import 顺序怎么排”，后面其他人的 agent 直接能用。这把 agent memory 从 “个人助手记忆” 升到 “团队知识资产”。是不是一定真有人这么用还要看，但至少这是 Cloudflare 给的一个升级路径。

一个共同的判断

把 Code Mode 和 Agent Memory 摆在一起，能看出 Cloudflare 在写一份统一的备忘录：

Agent 不是 chatbot，是分布式系统。

chatbot 的世界里，所有上下文塞 prompt，response 出来就忘。这个心智模型支撑了过去三年的工具开发 - prompt engineering、RAG、function calling 都是在这个框架下打补丁。

agent 的世界里，状态是分布式的。工具描述不在上下文，在另一个 service (Code Mode 的 search)。记忆不在上下文，在另一个 service (Agent Memory 的 recall)。模型本身只负责判断 “我现在需要什么” 加 “拿到之后怎么用”。

这个心智模型上了，许多设计选择就自然了：

• 沙箱选 isolate 不选容器，因为 agent 调用频率高、隔离要轻
• 检索做多通道并行，因为单一相似度查在结构化加时间相关 memory 上 fail mode 太多
• 权限走 OAuth 加 downscoped，因为 agent 写的代码不可信
• memory 当托管服务，因为每家自己造一遍意味着每家都做不好

是不是只有 Cloudflare 能做这件事？不是。Anthropic、OpenAI、Letta、Mem0 都在做记忆侧；Anthropic、Vercel、Replit 都在做沙箱侧。但 Cloudflare 的优势很具体 - 它本来就在卖 serverless primitive，Agent Memory 和 Code Mode 是把同一组积木换个组合方式继续卖。这种 “复用既有基础设施做新形态” 比从零搭一套的胜率高。

给 builder 的几个提醒

如果你正在做 agent，从这两个公告能拿走的不只是 “等一下试试 Cloudflare 这两个产品”。下面这几条更通用。

不要指望 200K context 窗口拯救你。 即便窗口翻倍翻三倍，工具描述加历史消息加文档片段照样能塞满。把 token economy 当作一个独立的优化维度去设计 - 工具列表能不能压缩、记忆能不能外存、文档能不能按需检索 - 比假设上下文够用要稳。

Tool 设计开始考虑 token 经济学。 你设计的每个 MCP 工具，都在抢模型的 context budget。一个 description 超过 200 token 的工具，要问自己：“这个工具是不是可以拆成 search + execute？” “是不是可以让模型按需访问 schema 而不是预先全展开？” 这是工具设计的新约束。

Memory 不该和 agent 框架强耦合。 如果你现在的 agent 把记忆逻辑写在框架内部，用框架自己的 vector store - 换框架的代价会很大。Memory 当作一个独立服务（Cloudflare 这个、Mem0、Letta、自己用 Pinecone 加一层结构化）能让你在 agent 框架变化时少痛。

多路检索很有必要。 如果你之前的 RAG 只是 “embedding + cosine similarity”，看看 Cloudflare 这五通道。多通道并行加 RRF 合并的工程量不大，但 recall 上限高很多 - 尤其是 fact-style queries 和时间敏感 queries 那一类。