为什么 100 万 token 窗口也救不了你的 Agent?

为什么 100 万 token 窗口也救不了你的 Agent? 为什么 100 万 token 窗口也救不了你的 Agent? Modified March 12 这就是渐进式披露的核心思想：不要一次性加载所有信息，而是按需展示。这是一个经典的交互设计原则，但在 Agent 设计中有了新的意义。 Cursor Agent 的动态上下文发现机制展示了这种思路的优雅实现：将 MCP 工具描述同步到文件夹，在 Agent 指令中只提供简短的工具列表，Agent 根据任务需要自行读取完整工具描述。这样，工具的详细定义不会占用初始上下文，只有在 Agent 确定需要使用某个工具时，才会“支付” token 成本。 Manus 的做法更简洁：在 Agent 指令中列出可用的 Shell 工具和 CLI, Agent 需要时自行调用“ help”查看详细用法。这利用了一个巧妙的事实：大多数命令行工具都有内置的帮助文档，为什么要在上下文中重复一遍？ Anthropic 的 Skills 标准把这个想法系统化了：采用 YAML 前置元数据 + Markdown 正文的结构。前置元数据（技能名称、简介）始终加载到上下文，完整的SKILL.md文件仅在需要时读取。这创造了一个三层信息架构：索引层（工具/技能列表，< 1K tokens）、摘要层（简短描述，帮助 Agent 判断是否需要深入）、详情层（完整文档，按需加载）。 这种设计的美妙之处在于，它把“决定需要什么信息”的责任交给了 Agent 本身。Agent 不再是被动接受预先准备好的上下文，而是主动探索和获取所需信息。 模式四：上下文卸载 人类在处理复杂任务时，会把中间结果写在纸上，而不是全部记在脑子里。Agent 也应该如此。 上下文卸载的核心思想是：将上下文从 Agent 的工作记忆转移到文件系统的长期存储。Manus 的策略很务实：将旧的工具执行结果写入文件，只有当卸载收益递减时才启用摘要压缩。这避免了过早压缩导致的信息丢失——这是很多 Agent 系统的通病。 Cursor Agent 同样将工具结果和 Agent 轨迹卸载到文件系统，Agent 可以在需要时重新读取。这创造了一种“外部记忆”机制：上下文窗口是工作记忆，文件系统是长期记忆。 对于长期运行的 Agent，上下文卸载还有更深层的用途。一些 Agent 会将任务规划写入文件，定期读回以强化目标——这解决了长会话中 Agent “忘记”初始目标的问题。还有些会记录已完成的子任务，避免重复工作。甚至可以保存关键决策的理由，供后续验证。 这里有一个微妙的设计选择：何时卸载，何时压缩？如果信息可能再次需要，且完整性重要（如代码片段、API 响应），应该卸载到文件。如果信息仅需概要，且不会再次详细访问（如长篇文档的摘要），可以压缩。卸载保留了完整信息，代价是需要额外的读取操作；压缩节省了空间，代价是信息损失。 模式五：上下文缓存 如果你的 Agent 每次启动都要重新加载系统提示、工具定义、项目规范，成本会高到无法商业化。 Manus 团队有一个明确的结论：缓存命中率是生产环境 Agent 最重要的指标。他们发现，一个高容量模型（如 Claude Opus）配合缓存，实际成本可能低于低价模型（如 GPT 3.5）不使用缓存的情况。Claude Code 的用户反馈也证实：没有缓存，编码 Agent 的成本将高到无法商业化。 提示缓存的原理很简单：如果上下文的前缀部分没有变化，模型可以复用之前的计算结果，只处理新增的部分。但要充分利用缓存，需要精心设计上下文结构。理想的结构是：系统提示、项目规范、工具定义、历史对话都可以缓存，只有当前用户输入不缓存。 这带来了一个重要的设计约束：前缀稳定性。你应该尽量保持上下文前缀不变，新信息追加到末尾。不要在历史消息中间插入新内容——这会破坏缓存。也不要频繁修改系统提示或工具定义。 这里有一个有趣的权衡：更长的缓存前缀意味着更高的缓存命中率，但也意味着更多的“固定成本”。对于短会话，缓存可能不划算；对于长会话，缓存是必需的。产品设计需要在缓存失效和上下文膨胀之间找到平衡点。 模式六：上下文隔离 当单个 Agent 的上下文窗口不够用时，一个自然的想法是：能不能用多个 Agent 分工合作？ Cursor 2.0 的多代理架构给出了一个答案：支持最多 8 个并行 Agent，每个 Agent 在独立工作空间中运行。复杂任务被分解为并行子任务，显著降低端到端延迟。Claude Code 使用子 Agent 进行代码审查：每个子 Agent 独立检查不同类型的问题（安全漏洞、性能问题、代码风格），最后汇总结果。这是典型的 Map Reduce 模式。 🖥️ Map Reduce 是一个经典的分布式计算模式,最初由 Google 提出。在 Agent 设计的语境下,它指的是: • Map(映射阶段):将一个大任务分解成多个独立的子任务,分配给不同的 Agent 并行处理。 • Reduce(归约阶段):收集所有 Agent 的结果,汇总整合成最终答案。 这种模式在 Agent 设计中特别有价值，因为它同时解决了两个问题——通过并行执行缩短延迟，通过任务分解让每个 Agent 的上下文保持聚焦。代码审查就是一个理想场景：安全检查、性能分析、风格检验彼此独立，可以完全并行，最后只需要简单拼接结果。但要注意，这种模式只适用于子任务之间没有强依赖关系的场景。如果子任务需要频繁交互或共享中间状态，Map Reduce 反而会增加协调成本。 但多 Agent 不是万能的。Google Cloud 的指南明确指出：多 Agent 系统虽能提升任务完成质量，但带来显著的延迟与费用增加。每个额外的 Agent 调用都意味着额外的模型推理开销。所以什么时候应该使用多 Agent？当任务可以并行分解，或者单 Agent 上下文窗口不足以容纳完整任务，或者需要专业化分工时。对于简单任务，多 Agent 只会带来额外的延迟和成本。 对于长期运行的任务，多 Agent 有了新的意义。“Ralph Wiggum” 循环是一个经典模式：初始化 Agent 创建计划文件和任务追踪文件，执行 Agent 从计划中领取任务并完成，验证 Agent 通过 Stop Hook 检查工作质量，然后循环迭代直到所有任务完成。上下文通过文件系统和 Git 历史在 Agent 间传递，每个 Agent 只需关注当前子任务。 这种设计的关键在于：上下文隔离不是为了隔离，而是为了聚焦。每个子 Agent 只看到完成自己任务所需的信息，避免了无关信息的干扰。这类似于人类团队的分工：每个人专注于自己的部分，通过文档和会议同步进度。 多 Agent 的协调机制也值得关注。Manus 的 Planner/Execution/Verification 架构通过结构化事件流通信，这比简单的文件共享更加结构化。长期运行任务则通过 Git 提交记录追踪进度，这利用了版本控制系统的天然优势。 模式七：上下文演化 前面六个模式都在解决“如何管理当前任务的上下文”，但还有一个更深层的问题：Agent 能否从经验中学习，让未来的任务变得更容易？ 这就是上下文演化的核心思想。Claude Code 有一个有趣的实践：将每次会话提炼为“日记条目”，定期反思多个日记条目，提取可复用的经验，然后更新 CLAUDE.md 文件，将学到的规则持久化。这创造了一个学习循环：执行任务 → 提炼经验 → 更新规则 → 下次任务更高效。 Anthropic 的 Skills 标准把这个想法系统化了：Agent 反思历史任务轨迹，将可复用的流程提炼为新的 Skill，保存到文件系统供未来任务调用。这不是简单的记忆，而是抽象和泛化——从具体的执行轨迹中提取通用的流程模式。 GEPA（任务特定提示优化）展示了另一种学习方式：收集 Agent 执行轨迹，对结果进行评分，反思失败案例，生成改进的提示变体，然后测试并迭代。这是一个更加结构化的优化过程，类似于机器学习中的超参数调优。 这里有一个有趣的设计空间：学习应该在什么层次发生？任务级学习针对特定任务优化提示（GEPA 方法）；技能级学习提炼可复用流程为 Skills；记忆级学习积累开放式知识和偏好。不同层次的学习有不同的泛化能力和适用范围。 上下文演化还带来了一个新的挑战：如何确保学到的内容是正确的？如果 Agent 从失败的经验中学到了错误的规则，可能会让未来的任务变得更糟。一些系统采用人工审核：关键记忆和技能需要用户确认后才生效。另一些采用增量更新：每次学习只修改部分上下文，避免大幅变动。 还有一个更深层的可能性：离线反思。想象一下，Agent 在用户不活跃时，自动回顾历史会话，反思自己的决策，更新记忆和技能。这类似于人类的睡眠——我们在睡眠中巩固记忆，整理经验。这种“睡眠时计算”可能是 Agent 持续学习的关键。 三、写在最后 现在有很大一部分人都把 Agent 神话了，以为 Agent 天生就应该具备极好的记忆和规划能力，但事实是，这些能力的背后，都藏着极其复杂和精密的工程设计。 上面聊的这些设计理念其实都不是孤立的技巧，抽象来看其实都是把 Agent 当作一个有限理性的智能体来设计，它不是全知全能的神，而是一个需要精心管理自己注意力和记忆的系统。 这也解释了为什么简单地扩大上下文窗口不是解决方案。即使我们有了 100 万 token 的窗口，Agent 仍然需要知道在什么时候关注什么信息。这不是一个容量问题，而是一个管理问题。 这就是渐进式披露的核心思想：不要一次性加载所有信息，而是按需展示。这是一个经典的交互设计原则，但在 Agent 设计中有了新的意义。 Cursor Agent 的动态上下文发现机制展示了这种思路的优雅实现：将 MCP 工具描述同步到文件夹，在 Agent 指令中只提供简短的工具列表，Agent 根据任务需要自行读取完整工具描述。这样，工具的详细定义不会占用初始上下文，只有在 Agent 确定需要使用某个工具时，才会“支付” token 成本。 Manus 的做法更简洁：在 Agent 指令中列出可用的 Shell 工具和 CLI, Agent 需要时自行调用“ help”查看详细用法。这利用了一个巧妙的事实：大多数命令行工具都有内置的帮助文档，为什么要在上下文中重复一遍？ Anthropic 的 Skills 标准把这个想法系统化了：采用 YAML 前置元数据 + Markdown 正文的结构。前置元数据（技能名称、简介）始终加载到上下文，完整的SKILL.md文件仅在需要时读取。这创造了一个三层信息架构：索引层（工具/技能列表，< 1K tokens）、摘要层（简短描述，帮助 Agent 判断是否需要深入）、详情层（完整文档，按需加载）。 这种设计的美妙之处在于，它把“决定需要什么信息”的责任交给了 Agent 本身。Agent 不再是被动接受预先准备好的上下文，而是主动探索和获取所需信息。 模式四：上下文卸载 人类在处理复杂任务时，会把中间结果写在纸上，而不是全部记在脑子里。Agent 也应该如此。 上下文卸载的核心思想是：将上下文从 Agent 的工作记忆转移到文件系统的长期存储。Manus 的策略很务实：将旧的工具执行结果写入文件，只有当卸载收益递减时才启用摘要压缩。这避免了过早压缩导致的信息丢失——这是很多 Agent 系统的通病。 Cursor Agent 同样将工具结果和 Agent 轨迹卸载到文件系统，Agent 可以在需要时重新读取。这创造了一种“外部记忆”机制：上下文窗口是工作记忆，文件系统是长期记忆。 对于长期运行的 Agent，上下文卸载还有更深层的用途。一些 Agent 会将任务规划写入文件，定期读回以强化目标——这解决了长会话中 Agent “忘记”初始目标的问题。还有些会记录已完成的子任务，避免重复工作。甚至可以保存关键决策的理由，供后续验证。 这里有一个微妙的设计选择：何时卸载，何时压缩？如果信息可能再次需要，且完整性重要（如代码片段、API 响应），应该卸载到文件。如果信息仅需概要，且不会再次详细访问（如长篇文档的摘要），可以压缩。卸载保留了完整信息，代价是需要额外的读取操作；压缩节省了空间，代价是信息损失。 模式五：上下文缓存 如果你的 Agent 每次启动都要重新加载系统提示、工具定义、项目规范，成本会高到无法商业化。 Manus 团队有一个明确的结论：缓存命中率是生产环境 Agent 最重要的指标。他们发现，一个高容量模型（如 Claude Opus）配合缓存，实际成本可能低于低价模型（如 GPT 3.5）不使用缓存的情况。Claude Code 的用户反馈也证实：没有缓存，编码 Agent 的成本将高到无法商业化。 提示缓存的原理很简单：如果上下文的前缀部分没有变化，模型可以复用之前的计算结果，只处理新增的部分。但要充分利用缓存，需要精心设计上下文结构。理想的结构是：系统提示、项目规范、工具定义、历史对话都可以缓存，只有当前用户输入不缓存。 这带来了一个重要的设计约束：前缀稳定性。你应该尽量保持上下文前缀不变，新信息追加到末尾。不要在历史消息中间插入新内容——这会破坏缓存。也不要频繁修改系统提示或工具定义。 这里有一个有趣的权衡：更长的缓存前缀意味着更高的缓存命中率，但也意味着更多的“固定成本”。对于短会话，缓存可能不划算；对于长会话，缓存是必需的。产品设计需要在缓存失效和上下文膨胀之间找到平衡点。 模式六：上下文隔离 当单个 Agent 的上下文窗口不够用时，一个自然的想法是：能不能用多个 Agent 分工合作？ Cursor 2.0 的多代理架构给出了一个答案：支持最多 8 个并行 Agent，每个 Agent 在独立工作空间中运行。复杂任务被分解为并行子任务，显著降低端到端延迟。Claude Code 使用子 Agent 进行代码审查：每个子 Agent 独立检查不同类型的问题（安全漏洞、性能问题、代码风格），最后汇总结果。这是典型的 Map Reduce 模式。 🖥️ Map Reduce 是一个经典的分布式计算模式,最初由 Google 提出。在 Agent 设计的语境下,它指的是: • Map(映射阶段):将一个大任务分解成多个独立的子任务,分配给不同的 Agent 并行处理。 • Reduce(归约阶段):收集所有 Agent 的结果,汇总整合成最终答案。 这种模式在 Agent 设计中特别有价值，因为它同时解决了两个问题——通过并行执行缩短延迟，通过任务分解让每个 Agent 的上下文保持聚焦。代码审查就是一个理想场景：安全检查、性能分析、风格检验彼此独立，可以完全并行，最后只需要简单拼接结果。但要注意，这种模式只适用于子任务之间没有强依赖关系的场景。如果子任务需要频繁交互或共享中间状态，Map Reduce 反而会增加协调成本。 Map Reduce 是一个经典的分布式计算模式,最初由 Google 提出。在 Agent 设计的语境下,它指的是: • Map(映射阶段):将一个大任务分解成多个独立的子任务,分配给不同的 Agent 并行处理。 • Reduce(归约阶段):收集所有 Agent 的结果,汇总整合成最终答案。 这种模式在 Agent 设计中特别有价值，因为它同时解决了两个问题——通过并行执行缩短延迟，通过任务分解让每个 Agent 的上下文保持聚焦。代码审查就是一个理想场景：安全检查、性能分析、风格检验彼此独立，可以完全并行，最后只需要简单拼接结果。但要注意，这种模式只适用于子任务之间没有强依赖关系的场景。如果子任务需要频繁交互或共享中间状态，Map Reduce 反而会增加协调成本。 但多 Agent 不是万能的。Google Cloud 的指南明确指出：多 Agent 系统虽能提升任务完成质量，但带来显著的延迟与费用增加。每个额外的 Agent 调用都意味着额外的模型推理开销。所以什么时候应该使用多 Agent？当任务可以并行分解，或者单 Agent 上下文窗口不足以容纳完整任务，或者需要专业化分工时。对于简单任务，多 Agent 只会带来额外的延迟和成本。 对于长期运行的任务，多 Agent 有了新的意义。“Ralph Wiggum” 循环是一个经典模式：初始化 Agent 创建计划文件和任务追踪文件，执行 Agent 从计划中领取任务并完成，验证 Agent 通过 Stop Hook 检查工作质量，然后循环迭代直到所有任务完成。上下文通过文件系统和 Git 历史在 Agent 间传递，每个 Agent 只需关注当前子任务。 这种设计的关键在于：上下文隔离不是为了隔离，而是为了聚焦。每个子 Agent 只看到完成自己任务所需的信息，避免了无关信息的干扰。这类似于人类团队的分工：每个人专注于自己的部分，通过文档和会议同步进度。 多 Agent 的协调机制也值得关注。Manus 的 Planner/Execution/Verification 架构通过结构化事件流通信，这比简单的文件共享更加结构化。长期运行任务则通过 Git 提交记录追踪进度，这利用了版本控制系统的天然优势。 模式七：上下文演化 前面六个模式都在解决“如何管理当前任务的上下文”，但还有一个更深层的问题：Agent 能否从经验中学习，让未来的任务变得更容易？ 这就是上下文演化的核心思想。Claude Code 有一个有趣的实践：将每次会话提炼为“日记条目”，定期反思多个日记条目，提取可复用的经验，然后更新 CLAUDE.md 文件，将学到的规则持久化。这创造了一个学习循环：执行任务 → 提炼经验 → 更新规则 → 下次任务更高效。 Anthropic 的 Skills 标准把这个想法系统化了：Agent 反思历史任务轨迹，将可复用的流程提炼为新的 Skill，保存到文件系统供未来任务调用。这不是简单的记忆，而是抽象和泛化——从具体的执行轨迹中提取通用的流程模式。 GEPA（任务特定提示优化）展示了另一种学习方式：收集 Agent 执行轨迹，对结果进行评分，反思失败案例，生成改进的提示变体，然后测试并迭代。这是一个更加结构化的优化过程，类似于机器学习中的超参数调优。 这里有一个有趣的设计空间：学习应该在什么层次发生？任务级学习针对特定任务优化提示（GEPA 方法）；技能级学习提炼可复用流程为 Skills；记忆级学习积累开放式知识和偏好。不同层次的学习有不同的泛化能力和适用范围。 上下文演化还带来了一个新的挑战：如何确保学到的内容是正确的？如果 Agent 从失败的经验中学到了错误的规则，可能会让未来的任务变得更糟。一些系统采用人工审核：关键记忆和技能需要用户确认后才生效。另一些采用增量更新：每次学习只修改部分上下文，避免大幅变动。 还有一个更深层的可能性：离线反思。想象一下，Agent 在用户不活跃时，自动回顾历史会话，反思自己的决策，更新记忆和技能。这类似于人类的睡眠——我们在睡眠中巩固记忆，整理经验。这种“睡眠时计算”可能是 Agent 持续学习的关键。 三、写在最后 现在有很大一部分人都把 Agent 神话了，以为 Agent 天生就应该具备极好的记忆和规划能力，但事实是，这些能力的背后，都藏着极其复杂和精密的工程设计。 上面聊的这些设计理念其实都不是孤立的技巧，抽象来看其实都是把 Agent 当作一个有限理性的智能体来设计，它不是全知全能的神，而是一个需要精心管理自己注意力和记忆的系统。 这也解释了为什么简单地扩大上下文窗口不是解决方案。即使我们有了 100 万 token 的窗口，Agent 仍然需要知道在什么时候关注什么信息。这不是一个容量问题，而是一个管理问题。 如果你最近在关注 AI Agent 领域，应该注意到了两个大新闻：Meta 花 20 亿美元收购了 Manus，Claude Code 的年收入破了 10 亿美元。这些数字背后藏着一个关键问题——什么样的 Agent 产品才能真正落地？ 如果你最近在关注 AI Agent 领域，应该注意到了两个大新闻：Meta 花 20 亿美元收购了 Manus，Claude Code 的年收入破了 10 亿美元。这些数字背后藏着一个关键问题——什么样的 Agent 产品才能真正落地？ 答案可能会让你意外：不是模型有多强，而是你怎么把 AI 能力变成用户真正能用、敢用、愿意用的产品。 AI Agent Design 的核心目标就是在聊 AI 如何从被动响应的工具，进化成能主动推进任务的智能体。 一、上下文管理：Agent 设计的核心命题 在深入具体模式之前，我们需要先理解 Agent 设计面临的根本挑战。METR 的研究显示了一个有趣的悖论：Agent 任务长度每 7 个月翻一番，但模型性能却随着上下文增长而下降。Anthropic 将这一现象称为“上下文腐化”——就像人类的工作记忆有限一样，LLM 也存在“注意力预算”，每个新 token 都会消耗这部分预算。 Andrej Karpathy 对此有一个精准的描述：上下文工程是一门精妙的艺术和科学，它能将下一步所需的正确信息填充到上下文窗口中。 这不是一个可以用暴力扩展上下文窗口解决的问题。即使我们有了 100 万 token 的窗口，如何让模型在海量信息中找到关键内容，仍然是一个设计挑战。接下来聊的几个模式本质上都是在回答同一个问题：如何让 Agent 在有限的注意力预算下，完成越来越复杂的任务？ 二、七大设计模式 模式一：给 Agent 一台计算机 传统的 Agent 设计把工具调用看作核心能力——模型选择一个工具，传入参数，获得结果。但这种设计有个根本性的局限：你必须预先定义所有可能的工具。当任务复杂度上升，工具数量会爆炸式增长，最终让模型无所适从。 Claude Code 和 Manus 选择了一个更激进的方向：与其给 Agent 一堆工具，不如给它一台计算机。 Claude Code 的设计哲学是“驻留在你电脑上的 AI”。它不是一个 IDE 插件，而是一个能够访问文件系统和 Shell 的智能体。文件系统给了 Agent 持久化记忆的能力——它可以把项目规范、历史决策、中间结果存成文件，随时读取。Shell 则赋予了它几乎无限的扩展性——它可以调用系统工具、安装依赖、执行自己写的脚本。 Manus 把这个想法推向了极致。它为每个用户提供云端虚拟计算机（基于 E2B 沙箱），配备完整的 Ubuntu 系统、浏览器、Python/Node 解释器。这意味着 Agent 不再受限于预设的工具集，而是可以像人类开发者一样，使用任何命令行工具、编写任何代码来完成任务。 这种设计带来了一个有趣的权衡：本地执行（Claude Code）响应更快、隐私更好，但可能破坏用户系统；云端沙箱（Manus）更安全、环境更可控，但增加了延迟和成本。没有绝对的优劣，只有不同场景下的选择。 模式二：分层的行动空间 当你给 Agent 一台计算机后，一个新问题出现了：Agent 应该在哪一层执行动作？ Google Cloud 的研究揭示了一个反直觉的发现：单 Agent 系统的性能随工具数量增加而下降。GitHub MCP 服务器有 35 个工具，光是工具定义就消耗了 2.6 万个 token——这还没开始执行任何任务。更糟糕的是，工具越多，模型越容易混淆，选择错误的工具。 主流产品的解决方案出奇一致：极简工具集 + 代码执行能力。Claude Code 只有约 12 个核心工具，Manus 少于 20 个。但它们都能完成远超这个数字的任务类型。秘密在于分层设计： 第一层是工具调用层，只有少量原子工具（bash、文件读写、搜索）。 第二层是代码执行层，Agent 编写代码来组合工具、调用 API、实现复杂逻辑。 第三层是系统层，Shell 工具、CLI、系统服务。 Manus 的 CodeAct 方案是这种思路的极致体现：用 Python 代码作为统一的动作格式。Agent 不是调用预设的“发送邮件”工具，而是写一段代码来调用邮件 API。这样做的好处是：减少工具定义的 token 消耗，避免中间工具结果占用上下文（代码内部处理），最重要的是，赋予 Agent 组合创新的能力。 但这也带来了新的风险：Agent 可能写出有问题的代码，或者陷入无限循环。Manus 的工程决策是严格限制每轮一个动作，执行后必须观察结果再决定下一步。这是一个安全阀，防止 Agent “失控”。 模式三：渐进式披露 如果你有 100 个工具，但只在需要时才告诉 Agent 具体怎么用，会怎样？