浅谈 Context Engineering

本文来自我前几个月在团队内部的技术分享，由于大模型业界的信息迭代相当频繁迅速，下面的一些信息可能已经过时，请读者包涵。

前言

什么是 Context Engineering？我认为 Karpathy 给出了一个精炼的定义：

Context Engineering 是一门精细的艺术与科学，目标是在上下文窗口中填入恰到好处的信息，以支撑下一步决策。

随着 AI 应用日益复杂，大模型的上下文窗口正在被快速填满：

• 静态开销：系统提示词、工具描述本身就占据相当可观的空间
• 动态增长：Agent 的典型任务会涉及数十次工具调用，工具返回的结果不断堆积，而且单次工具结果可能就非常庞大。例如，用 Tavily 抓取 DeepSeek 的 Wikipedia 页面转为 Markdown，总字符数能达到 ~200K

然而，出于下面的原因，我们难以支撑上下文的不断膨胀：

• 成本：许多模型在高输入 token 下的价格要显著多于低输入 token，例如 OpenRouter 上的 Gemini 3.0 Pro Preview 在输入 token 小于 200K 时，输入价格为 $2/M，输出价格为 $12/M；当输入 token 超过 200K 时，输入价格为 $4/M，输出价格为 $18/M。
• 性能：包括 Context Length Alone Hurts LLM Performance Despite Perfect Retrieval 在内的许多研究表明，随着上下文增长，LLM 会逐渐出现降智、调用工具失败或出错等行为，这被称为「上下文腐烂」（context rot）。后文讨论的 Manus 团队的分享中就提到：某些声称支持 1M 上下文的模型，实际在 128K~200K 时就开始出现明显的性能下降

这里存在一个核心张力：一方面，需求的复杂化导向更多的工具、更长的提示词；另一方面，上下文窗口始终有限，成本和性能都不允许无限堆积。我认为 Context Engineering 的提出正是为了解决这个张力——在有限的上下文窗口中，填入能完成当前任务的恰到好处的信息。

本文会按三个层次来聊：

• 理论基础：「遗忘」与「回忆」，解释 Context Engineering 在做什么
• 解决方案：Agent（控制论与信息论视角），解释为什么“用工具闭环”能完成复杂任务
• 工程实践：Manus 与 Claude Skills，解释业界如何在 Agent 之上构建一套可持续运行的闭环方案

遗忘与回忆

在讨论具体方法之前，我们需要先建立一个反直觉的认知：遗忘不是问题，而是特性。在上下文工程的语境下：

• 遗忘：丢弃上下文中的低价值信息。这不是因为记不住，而是刻意不去记。目的是让有限的上下文窗口聚焦于当前决策所需的关键信息。
• 回忆：把低价值信息留在上下文之外，在需要时再按需检索或加载回上下文，形成可用的工作记忆。

下面的内容基于 https://x.com/oran_ge/status/1979704983265456362

Karpathy 提出了一个根本性的悖论：LLM 拥有近乎完美的记忆，却泛化能力有限；人类记忆糟糕，却善于抽象与迁移。为什么？因为遗忘强迫我们抽象。当你记不住细节时，大脑被迫提取通用模式，看到的是"森林"而非"树木"。而 LLM 被海量训练数据的完美记忆"分散了注意力"，反而阻碍了真正的抽象理解。为此，他提出了一个精妙的类比：

• 模型权重就像一年前读过某本书的模糊回忆（长期记忆）
• 上下文窗口就像此刻的工作记忆（短期记忆）——新近、具体、可直接引用

正因为模型能在上下文这块「工作记忆」里短时吸收并使用新信息，in-context learning 才呈现出一种「实时学习」的效果：不改变模型权重，也能立刻用新知识完成当前任务。基于此，他主张模型训练应聚焦「认知核心」，剥离百科式记忆，保留方法论与推理能力，并让 AI 像「有方法论但没有百科全书的哲学家」，强制它查找而非回忆，专注于思考的元技能。

虽然这看上去主要是对模型训练的建议，但对我们同样有启发：与其把所有信息塞进上下文，不如让模型能够「该忘就忘、需要再查」。上下文窗口并不是越大越好，而是一种稀缺资源；上下文工程的目标也不是把它当成一个不断膨胀的「信息堆栈」，而是让模型在收到每个任务请求时，总能在这份「工作记忆」里看到最适合解决当前问题的上下文——其余信息外置（遗忘），需要时再按路径取回（回忆）。

在包括我的工作项目在内的许多产品里，实现上下文工程的方式是围绕 Agent 展开的，接下来我们先从控制论和信息论出发解释 Agent 以及它的「行动——观察——修正」循环，之后会讨论业界是如何基于 Agent 实现上下文工程的。

从控制论和信息论看待 Agent

本节的内容来自言午的公众号文章

如果说「遗忘」与「回忆」描述了 Context Engineering 要实现的上下文管理方式，那么 Agent 就是当前业界最常见的一类解决方案——让模型在一个可行动的环境中，通过不断的「行动——观察——修正」来完成复杂任务。在解释 Agent 如何做到这一点之前，我们需要借助两个经典理论来理解 Agent 的工作方式：控制论与信息论。

• 控制论 (Cybernetics)：解释系统如何通过反馈来达成目标，体现 Agent "逼近"解决方案的过程
• 信息论 (Information Theory)：解释信息与不确定性的关系，体现 Agent "探索"问题空间的过程

控制论视角

一个典型的开环系统，是那种只带定时器的老式暖气。你设定它「运行一小时」，期望它能让房间变得温暖。但它没有感知「当前室温」的能力，因此行为是盲目的：

• 如果今天恰好有太阳，一小时后房间会闷热难耐
• 如果恰逢寒流来袭，一小时后房间可能依然冰冷

开环系统的根本缺陷在于缺乏反馈。它只能单向地执行指令，而对执行的结果一无所知。这正是两年前的 AI Chatbot 常见的工作模式——它接收指令并一次性生成结果，却无法验证这个结果是否真正解决了问题。

闭环系统则通过引入反馈机制解决了这个问题。以冰箱为例，它的核心任务是「维持冷藏室恒定在 5°C」：

• 目标 (Set Point)：用户设定的 5°C
• 传感器 (Sensor)：内部的温度计，持续观察当前的实际温度
• 控制器 (Controller)：温控芯片，判断「当前温度和目标温度之间是否存在偏差」
• 执行器 (Actuator)：压缩机，一旦控制器发现偏差就开始工作
• 反馈闭环 (Feedback Loop)：压缩机工作导致温度下降，传感器将新温度反馈给控制器

Agent 的工作流程与这个闭环系统能够一一对应：

这里，Observe 环节是 Agent 从开环到闭环进化的关键——它赋予了 Agent 感知「行动结果」的能力，从而能在动态变化的环境中，通过不断的「行动——观察——修正」循环，持续地逼近目标。

信息论视角

如果说控制论解释了 Agent 如何「逼近」一个目标，那么信息论则揭示了它在探索未知问题时究竟在「做什么」。

信息论的核心概念是熵 (Entropy)，即对不确定性的度量。一个系统的信息量越大，其不确定性就越小，熵值也就越低。所有解决问题的过程，本质上都是通过获取信息来降低不确定性（即「熵减」）的过程。

这个概念可以用《星际争霸》等游戏中的「战争迷雾」来理解：

1. 游戏开局时，除了基地周围的狭小视野，整个地图都处于未知状态——这是「高熵」状态
2. 你的任务（摧毁敌方基地）是明确的，但通往任务的路径是完全未知的
3. 你派出侦察单位进入黑暗区域，这是你的行动（Act）
4. 这个单位的视野点亮了地图的一部分，你获得了新的观察（Observe）
5. 这份观察让你对这片区域的认知从「完全不确定」变成了「确定」——熵减少了

Agent 的工作，正是在一个抽象的「问题空间」中进行熵减。它的每一次行动和观察，都是为了获取能最大程度降低问题不确定性的信息。当不确定性被完全消除，通往答案的唯一路径也就清晰地浮现出来。

小结

控制论和信息论并不是两套互不相干的解释，而是在 Agent 的闭环里交织在一起：

• 控制论告诉我们：系统要持续对齐目标，就必须不断根据观察到的偏差来修正下一步行动
• 信息论告诉我们：要更快收敛，就要用行动去获取高信号的观察，持续降低不确定性

而这两件事都高度依赖「上下文」这份工作记忆：目标是否清晰、工具返回是否结构化且可被消费、历史证据与中间产物能否被按需取回。好的上下文催生出好的行动，好的行动又带来更好的观察与更低的熵——这也是为什么提示词与上下文工程往往对 Agent 的最终表现有决定性影响。

进一步地，为了让这个闭环在长任务里持续跑下去，我们需要 「遗忘」与「回忆」：轨迹会不断变长，旧信息必须被压缩或外置；而当任务推进到新的阶段时，关键细节又必须能被按需取回，重新进入工作记忆。接下来，我们会讨论来自业界的两个相当优秀的上下文工程实践，它们来自 Manus 和 Anthropic。

Manus 的三层架构

本节内容部分取自 Manus 联合创始人 Peak 和 LangChain 的 Lance Martin 的分享 Context Engineering in Manus，十分推荐观看完整的访谈视频

理解了 Agent 的基本闭环之后，我们来看业界如何将这套理论工程化落地。Manus 是目前最流行的通用 Agent 产品之一，它的架构设计充分体现了如何通过 Agent 框架实现「遗忘和回忆」，从而有效管理长任务中的上下文。

行动空间的三层分层

Manus 将 Agent 的行动空间分为三层：

Manus 的三层架构的精髓在于：与其把所有工具都绑定为 function（消耗大量 token、造成模型困惑），不如只提供少量原子工具，让模型通过代码去调用沙箱中的丰富工具。这样，模型可以在第三层表达出无穷无尽的解决方案——从翻译 .docx，到总结 .pdf，再到给视频打字幕，解决越来越多的用户问题，这就是 Manus 在第一天就标榜自己为「通用 Agent」的原因。

Manus 并不会在提示词中对每一种可能的问题都写清楚解决方案，而是依靠大模型的 Agentic 能力自行推理、发现和组合解决方案。这种设计既避免了系统提示词的无限膨胀，又保持了极高的灵活性，充分发挥像 Claude 这样以 Agentic 能力见长的模型的潜力。

上下文管理的三种策略

除了行动空间分层，Manus 还采用了三种上下文管理策略：

1. Reduce Context（减少上下文）

Manus 会把一次工具调用的结果维护成两种表示：

• 完整版（full）：工具返回的原始内容（例如一次完整的搜索结果），保存到沙箱的文件系统中
• 精简版（compact）：只保留对完整版的引用（例如文件路径），用于放进上下文窗口

在任务推进过程中，Manus 会尝试先把「已经用过、对下一步决策不再关键」的工具调用结果做压缩（compaction）：

• 将完整版的工具调用结果替换为精简版
• 从上下文里删除大量 token，但仍保留「随时可回读」的能力，这就是一种「回忆」
• 与此同时，较新的工具结果会保留为完整版，用来指导模型的下一步决策
• 注意，这种压缩是无损的（可逆的），大模型如果愿意，可以通过工具读回某个完整的工具调用结果

当上下文压缩的收益开始递减，继续压缩也省不了多少的时候，Manus 会进一步尝试对整段轨迹做摘要（summarization）：

• 摘要由另一个模型基于完整版工具结果生成，并用一个固定 schema 约束摘要字段，保证不同任务的摘要结构一致、可复用。
• 这个过程是有损的（不可逆的），大模型后续无法读回之前的完整信息

2. Offload Context（卸载上下文）

Offload 的核心思想是：把上下文从「只能放 token 的对话窗口」，迁移到「可检索的外部存储」（也即沙箱文件系统）。

• 卸载工具结果：工具结果默认落盘，必要时才把关键片段或引用塞回上下文
• 卸载工具定义：即前文讨论的行动空间的三层分层，只有少数的基础工具会常驻在提示词中
• 按需检索：利用 glob、grep 等基础工具在文件系统中搜索

3. Isolate Context（隔离上下文）

Manus 使用子 Agent 的首要目的，是隔离上下文。例如，Manus 会引入一个 planner，把离散子任务派发给拥有独立上下文窗口的 executor 子 Agent。

• 简单任务：planner 只把指令发给子 Agent，子 Agent 返回结果即可，planner 不需要也不关心它在完成任务过程中产生的全部上下文
• 复杂任务：当子 Agent 需要读写 planner 同样会使用的文件/轨迹时，planner 会把完整上下文共享给子 Agent
• 结构化返回：planner 会定义子 Agent 的输出 schema，子 Agent 通过「提交结果」这一工具回填 schema，系统用约束解码确保输出符合结构，降低沟通噪声

Manus 的上下文管理方案相当精致，本质上是把「文件系统沙箱」当作 Agent 的外部记忆与行动空间：旧信息该压缩就压缩、该外置就外置，需要时再按引用取回，从而在长任务里实现可持续的「遗忘与回忆」。同时，配合三层行动空间，模型不需要背下所有工具说明，而是能在沙箱里自由检索、组合、试错，把有限的上下文预算更多留给推理与决策，符合 Andrej Karpathy 所说的「聚焦认知核心」。

Claude Skills

本节的内容部分取自 Anthropic 的博文 Equipping agents for the real world with Agent Skills

就在我为 Manus 的方案感叹时，Anthropic 提出的 Claude Skills 又从另一个角度切入：用一种更简洁、也更符合直觉的方式，去处理同类的上下文管理问题。它的核心思想是能力的按需加载——把可复用的工作流、脚本与说明放在文件系统里，需要时再逐步加载到上下文中。与 Manus 类似，它依然是依靠 Agent 框架的解法，但实现更轻量。

Claude Skills 的核心思想在于「渐进式披露」：一个 Skill 本质上是一个文件夹，其中必须包含一个 SKILL.md 文件。这个文件以 YAML frontmatter 开头，声明 name 和 description 两个必填字段。

社区已经有不少 Skills 可供参考，它们既可以是纯粹的提示词，也可以额外包含一些脚本文件：

• 用沙盒的程序交互 docx 文件
• 计算给定 csv 相关数据的脚本
• 获取网页内容的方法论（工作流）

当 Agent 启动时，会把所有已安装 Skill 的 name 和 description 预加载到系统提示词中——这是第一层披露，让 Claude 知道「有哪些能力可用」，而不需要把全部内容塞进上下文。

当 Claude 判断某个 Skill 与当前任务相关时，它会主动读取该 Skill 的完整 SKILL.md——这是第二层披露，获取具体的指令和工作流。随着 Skill 变得更复杂，SKILL.md 可能会引用同目录下的其他文件（如 reference.md、forms.md、Python 脚本等）。Claude 可以按需读取这些文件——这是第三层及更深层的披露，只在真正需要时才加载。

此外，Skill 还可以包含可执行的脚本。某些操作（如排序、文件格式转换）用代码执行比用 token 生成更高效、更可靠。Claude 可以直接运行这些脚本，而不需要把脚本内容或处理对象加载到上下文中。

这种「渐进式披露」的设计使得一个 Skill 能够打包的上下文量几乎没有上限——因为 Agent 不需要一次性把整个 Skill 读进上下文窗口，而是像查阅一本组织良好的手册一样：先看目录，再翻到具体章节，最后查阅详细附录。

我认为这也可以从「遗忘」与「回忆」的角度来理解，只是它采用了一种「反过来」的工程路径：不是等上下文膨胀到装不下时才去做遗忘，而是一开始就把绝大多数细节留在上下文之外；同时把「回忆的入口」（目录级元信息）常驻在系统提示词里，让模型在需要时能沿着清晰的路径逐层加载、逐层回忆。换句话说，它从一开始就在为「回忆」铺路。

对比 Manus 和 Claude Skills

把 Manus 和 Claude Skills 放在一起看，我会把它们理解为：面对上下文工程问题，业界走出的两条互补路径——前者偏「系统内建的运行时治理」，后者偏「把经验与流程沉淀为可按需加载的能力包」，如下表所示：

思考

全局一致性

随着 Agent 应用不断迭代，我们的「代码」早已不止是传统意义上的代码：它还包括系统提示词、工具描述、skills、上下文结构，甚至模型的升级与切换，这些部分同样会引入 bug。但 Agent 应用的 bug 往往不像传统软件那样，直接导致功能不可用或程序崩溃；它更常藏在上下文本身：某条规则与另一条规则冲突、模型升级后自身的理解发生改变、某个工具没有返回正确的信息……最终表现为模型在某些场景下出现非预期行为。这类问题对用户可能并不显眼，事后也常常难以复现与定位。

更麻烦的是，这种问题往往不是二元的好和坏，而是一种渐进式的腐坏过程：提示词越来越多、上下文越来越长、约束开始互相打架，模型的注意力被稀释，直到它「看起来什么都能做，但实际上什么都做不好」。我们可以把开发 Agent 应用类比成「教一个孩子」：负责不同模块的开发者从他们自身的角度给它灌输规则与知识，但这些规则有时缺乏一致性，导致模型只能在一条充满矛盾的路径里磕磕碰碰。

这里我说的 coherency（全局一致性），不只是「提示词写得像不像一个人写的」（风格统一），而是更偏工程意义上的一致性：

关于这部分内容，欢迎阅读我的另一篇文章《提示词工程指北：从第一性原理出发》。

1. 概念一致：同一个术语在全文只代表一个含义。像是「产物是什么」、「完成标准是什么」这类定义不会在不同位置打架

   来自我工作的项目的一个反例：我们实现了一个 browser_use 工具，调用后会启动一个浏览器沙箱供 Agent 自己操作；与此同时，我们还有一个 message 工具，其中一个字段 type 如果设置为 takeover_browser，就会让用户接管浏览器（通常用来处理验证码）。

   后来出现了一个 bad case：模型在根本没有使用浏览器的时候，也会把 type 设置成 takeover_browser，试图让用户「接管浏览器」来回答它自己的问题。根本原因在于我们在提示词里没有说清楚这里的 browser 指的是谁的浏览器——是用户的浏览器，还是 Agent 的沙箱浏览器。

2. 规则一致：不同模块加的约束不自相矛盾，并且优先级清晰，当规则冲突时，模型知道该遵循哪条。

   另一个来自我工作项目的反例：我们的记忆功能提供了一个查询用户偏好的工具，并在提示词里写了「收到用户请求时，总是先查询用户偏好」；与此同时，又有另一段提示词写了「收到用户请求时，请先搜索其中的陌生概念，确保理解准确无误」。

   这两条规则都在争夺「第一步行动」，却没有明确优先级，导致模型在不同场景下摇摆：有时先查偏好、有时先搜概念，甚至会两边都做或反复切换，表现得不稳定、难复现。

3. 契约一致：工具的能力边界、输入输出格式、失败语义前后一致，并能随模型升级和工具变更同步迭代

   一个例子是，搜索图片的工具在搜不到结果时会返回空字符串，而搜索网页的工具在同样的情况下会返回「无结果」几个字。同时使用两个工具的 Agent 可能会在看到前者返回了空字符串时误以为工具内部出错。

当全局一致性在某处被破坏时，模型的「行动」环节会在错误的上下文前提下被迫做出选择，于是就会出现一些出人意料但又难以复现的问题——比如用户要的是一份幻灯片，但它最后交付了一份 Markdown 报告。

解决这类问题当然需要组织层面的治理：例如定期 review 提示词，或者由一个某个「架构师」一样的角色维护全局一致性。落到具体的执行，我发现了一个有效的方法，是用两个「闭环」去检查我们的 Agent 是否跑通一致性：一是 Agent 的「行动——观察——修正」，二是上下文管理的「遗忘——回忆」。很多问题最终都会落到：观察是否可信、回忆链路是否可用、遗忘策略是否让上下文保持可用，以及这些因素如何共同影响下一步行动。

我们可以想象一些自己的一些真实需求，带入我们的产品。例如：我收藏了一批 AI 博主和新闻网页，想定期阅读然后寻找那些对我的项目有启发的内容，整理为日报。

• 目标：用户怎么向产品表达这个需求？他们是否需要分拆和具化才能表达出产品可执行的需求？

  假如你的产品实现了定时任务的功能，那么就必须通过某种方式让用户意识到自己可以发出这样的请求。除了界面上的引导外，让 Agent 在合适的时机提醒用户这个功能的存在也是不错的选择。

• 行动（Act）：产品提供的沙盒或工具能高效执行任务吗？比如获取博主最近的发言、抓取网页正文、抽取结构化信息。

  我们会在后文继续讨论这个问题。

• 观察（Observe）：工具返回的结果是否能供大模型准确决策？

  许多人会忽视工具在异常情况下的「失败语义」。例如，搜索服务商 API 超时时，工具结果不应只写「API 超时了」，还应说明：这是可重试的暂时性错误，还是需要降级或中止；并明确给出下一步建议（等待后重试、换关键词/换数据源，或向用户说明情况并致歉）。

  如果说系统提示词是静态的上下文输入，那么工具结果就是动态的上下文输入。动态上下文的质量（结构是否稳定、噪声是否可控、错误语义是否清晰）往往更直接地影响模型的下一步行动，也更考验开发者对模型决策方式的理解。

• 反馈（Feedback）：模型的每一步行动是否会产生「可验证、可纠偏」的反馈？

  对于用户侧来说，模型是否能在执行过程中主动向用户展示关键的中间结果（比如生成的草稿、筛选出的候选项）、下一步的执行计划，以及那些需要用户参与的环节（比如处理验证码、确认偏好选择）？这些信息是否足够清晰、及时,让用户能在任务偏离预期时及时介入纠正？

  例如，在前面提到的「整理 AI 博主内容为日报」的场景中，模型可以在抓取完所有博主的最新发言后，先向用户展示一份初步筛选的列表（比如「我找到了 15 条可能相关的内容，其中 5 条提到了你关注的多模态技术」），让用户确认是否需要调整筛选标准，而不是直接生成一份可能不符合预期的日报。

  对于模型侧，Agent 系统是否内置了自动验收机制？比如检查输出是否符合预定义的完成标准（任务目标是否达成）、是否满足输出契约（格式、字段完整性）、是否包含必要的来源引用等。当检测到不满足条件时，系统能否自动触发补救措施——比如重新执行某个步骤、降级到备用方案，或者调整执行计划——从而重新进入「行动——观察——修正」的循环？

  一个具体的例子：如果模型生成的日报缺少来源链接，系统可以自动检测到这一问题，然后触发一次「补充引用」的行动，而不是直接把不完整的结果交给用户。

• 回忆（Recall）：当模型需要引用旧的证据或中间产物时，是否有明确的回忆方式？

• 遗忘（Forget）：哪些信息应该常驻上下文，哪些应该默认外置？

业界非共识

通过 Manus 和 Claude Skills，我们基本能看到一个业界共识：通过 Agent 框架，在「遗忘」与「回忆」的指导下，把上下文做分层与外置管理，是复杂长任务得以稳定运行的关键。但共识之上也立刻衍生出一系列更难、更贴近产品落地的问题。围绕这些问题，业界仍然存在大量非共识。

如何提升各细分场景的产物质量？

当前的通用 Agent 产品都给大模型搭建了一致、闭环的执行框架，但大模型并非能在所有任务上都具有高质量的发挥。像是以翻译文档这样的任务，模型通常能够得心应手地处理；但在制作 PPT 这类任务上，用户对版式、结构、叙事节奏、视觉一致性的要求很高，目前的模型很难达到令人满意的效果。于是，我们会看到一个现实：很多标榜「通用」的 Agent 产品，仍然会花大量精力去打磨最高频的几个场景，用工程手段去兜底下限，比如使用一种特定的 HTML 格式生成幻灯片，内置一些人为设计的色板、组件库，并在大模型制作的幻灯片页存在文字超出画面的问题时，通过代码检测出来并要求模型重新生成。

目前所谓的「通用」很大程度上是一个伪命题。我认为，目前以及未来一年内的模型都无法真正在所有任务上做到各大公司宣传的「取代人类」。真正能交付稳定体验的产品，往往都需要在其用户群体的高频场景上做针对性取舍与优化。也正因为如此，「如何让 Agent 在遇到复杂且专业性高的需求时仍然能自由组合工具，自己找到可行路径」，就变成了更关键的问题。

如何提升「自由组合、试错并构建工作流」的效率？

目前 Manus 和 Claude Skills 的核心思路都是在文件沙箱里让大模型自己组合已有的工具、命令、程序去构造解决问题的工作流。然而，我们在实践中发现：于很多问题，大模型并不总能构造出效率最高的工作流，它们要么会在构造的过程中发现自己用错工具、写错代码，于是需要经历多轮调整；要么会使用一个欠佳的方案交付出质量较差的产物。

例如，对于这样的任务:「帮我把这个 PDF 翻译为中文,保持版式不变」，现有的许多 Agent 产品中，模型会依据自身的记忆选择一些现成的命令行工具（假如产品没有特意提供这个工具或者 Skill），但这些工具往往无法做到「保持版式不变」，而模型迫于无奈或出于自信，总是尝试使用这样的方案，结果是输出的结果质量很差。

在我看来，提高这种效率的方式涉及三个方面:

• 发现：需要让大模型能够知道自己不会做或者做不好，并且能够通过搜索等方式找到可能的解决方案
• 执行：大模型需要评估找到的解决方案，选择那些能够在沙箱里跑通且综合质量最好的
• 沉淀：大模型需要在获得用户正面反馈后，将这次的任务沉淀为记忆，供下一次执行类似任务时回忆

如何协调用户、产品和模型三者的交互？

在很多产品里，模型的视角是：系统提示词、沙箱环境、可调用的工具与 Skills，它所「看到」的世界，基本都来自上下文窗口。但用户的视角往往是：前端对话框，以及顶栏和侧栏的各种按钮，还有右侧的产物编辑器，又如，幻灯片编辑器顶部的「导出为 PPTX」按钮。

问题在于，很多产品并不会把这些 UI 能力与交互方式同步给模型——模型甚至不知道用户能看到哪些按钮、能使用哪些功能。这就会出现一种尴尬但常见的现象：用户问「你能不能导出 PPTX 给我？」，而模型会回答「不能，很抱歉」，因为它在自己的世界里确实没有这项能力。

类似这样的模型视角和用户视角的不一致会给人机交互带来不可忽略的摩擦：

• 能力不可见：模型并不知道平台上有哪些能力可以满足需求，也不一定清楚哪些事应该在沙箱里自己完成，哪些必须让用户介入（例如验证码）。
• 过程不可见：用户不知道模型在沙箱里为什么这样做、已经做了什么、接下来要做什么、以及哪里需要用户确认或审阅；而模型又往往缺少「在关键节点停下来请求反馈」的机制，于是任务会在用户不知情的情况下悄悄跑偏。

像 Cursor 和 Claude Code 这类产品引入了一种被称为 plan mode 的功能：在真正开始执行之前,模型会先反问用户以澄清需求与验收标准；进入执行阶段后，又会通过 plan 里的任务节点持续告诉用户「我正在做什么」以及「接下来准备做什么」，并允许用户随时介入调整（用户可以在执行中途插入信息）。这实际上是在把用户显式纳入反馈闭环：既降低了「过程不可见」，也在一定程度上缓解了「能力不可见」带来的误解。值得一提的是，在我参与的项目中，我们早在今年年初就已经意识到这一问题的重要性，并实现了类似的解决方案。