你有没有遇到过这种情况给一个大语言模型LLM一个复杂的、多步骤的任务比如“分析这份财报总结关键风险并生成一份给管理层的建议报告”。模型开始输出了前半部分分析得头头是道但写到后面突然开始重复前面的观点或者逻辑开始混乱甚至“忘记”了任务最开始的要求这不是模型“笨”也不是你的提示词写得不好。这背后是一个更深层、更根本的工程问题LLM 在处理长序列、复杂任务时其“工作记忆”是受限且易受干扰的。我们习惯于把 LLM 想象成一个拥有无限草稿纸的天才但实际上它更像是一个必须在固定大小的白板上演算的数学家。白板即上下文窗口就那么大写满了就得擦掉旧的才能写新的。而“Scratch Workspaces”草稿工作区这个概念正是为了解决这个核心矛盾。它不是一个具体的工具而是一种设计范式一种让 LLM 从“一次性答题者”进化为“有规划、可迭代的问题解决者”的关键思路。简单来说它主张不要让 LLM 在最终答案的“答题卡”上直接打草稿而是为它开辟一块独立的、结构化的“草稿纸”区域让它在那里思考、规划、试错和整理最后再誊写一份清晰的答案。这听起来像是一个简单的工程技巧但它的意义远不止于此。它触及了当前大模型应用从“玩具演示”走向“生产级系统”必须跨越的一道鸿沟如何将一次性的、黑箱的生成过程转变为可控、可解释、可复用的工作流。1. 从“即时生成”到“规划-执行”为什么 LLM 需要草稿纸要理解 Scratch Workspaces 的价值我们得先回到 LLM 工作的基本原理。当你输入一段提示词Prompt模型会基于其庞大的参数和你的输入逐词Token地预测下一个最可能的词。这个过程是“自回归”的意味着它没有真正的“内部循环”或“暂存区”。所有的中间思考都必须以文本的形式暴露在上下文中。这就导致了几个经典问题思维链污染当你使用“Chain-of-Thought”思维链技术让模型“一步一步思考”时这些中间步骤会占据宝贵的上下文窗口。如果任务非常复杂思维链本身就会变得很长挤占用于存储问题细节、参考材料或最终答案的空间。长程依赖丢失在生成长文本时模型对上下文开头的记忆会逐渐模糊。它可能会忘记最初设定的格式要求或者混淆在中间步骤中提到的关键实体。无法回溯与修正模型一旦写下某个结论就很难在后续生成中从根本上否定或大幅修改它。这就像在答题卡上写错了只能涂改无法优雅地重写。多任务协调困难对于需要调用工具如计算器、代码解释器、检索外部知识、或者进行多轮子任务的任务所有的 API 调用结果、检索片段、子任务结果都堆在主上下文中使得上下文变得杂乱无章模型容易“迷路”。Scratch Workspace 的核心思想就是进行“职责分离”。它将模型的“工作内存”划分为两个部分工作区Scratchpad一个专用的、结构化的空间用于存放非最终输出的一切内容。包括分解的子任务、临时假设、检索到的文档片段、工具调用计划和结果、中间代码、决策树、甚至是自我质疑和验证的笔记。输出区Final Answer一个干净的空间只存放最终要呈现给用户的、格式良好的答案。这种分离本质上是在教导或强制模型采用一种更接近人类解决问题的方法先打草稿再整理成文。2. 如何构建一个有效的 Scratch Workspace从模式到实践Scratch Workspace 不是一个标准化的 API而是一种你可以通过提示词工程、程序逻辑和新兴框架来实现的模式。其实施层次可以从简单到复杂。2.1 基础层通过提示词定义工作区最简单的实现就是在你的系统提示词System Prompt中明确划分区域。你是一个财务分析师。请遵循以下格式输出 ## 草稿工作区 在这里请你 1. 首先分解任务列出需要分析的几个关键部分。 2. 然后为每个部分进行初步计算和数据提取可以标记为[计算]。 3. 接着记录下任何不确定的地方或需要假设的点标记为[假设]。 4. 最后基于以上草稿梳理出核心论点和支撑证据。 ## 最终报告 请根据草稿工作区的内容撰写一份结构清晰、面向管理层的正式报告包含摘要、风险点、具体数据支撑和建议。这种方式依赖模型遵循指令的能力。优点是零成本、快速验证。缺点是模型可能会“偷懒”不认真使用草稿区或者格式混乱。它适合相对简单的任务作为思维链的增强版。2.2 进阶层通过程序逻辑管理工作区更可靠的方式是用程序Python 等主动管理两个独立的上下文。这通常需要利用 LLM 的 API 进行多轮对话。第一轮对话规划轮你给模型发送指令“请为‘分析财报并写报告’这个任务创建一个详细的工作计划。列出所有子步骤、所需数据、可能用到的工具如计算增长率和最终输出的结构。将计划输出到‘计划’字段。” 你只解析并存储模型的“计划”输出。第二轮及更多轮执行轮你新建一个对话或严格清空上下文只保留系统提示然后将原始任务和**第一轮产生的“计划”**一起作为输入。你可以指示模型“这是任务这是你之前制定的计划。请严格按照计划执行并在‘执行日志’区记录每个子步骤的结果、工具调用和中间发现。” 程序会收集这些“执行日志”。最终轮合成轮再新建一个对话将任务、计划、完整的执行日志一起输入并要求模型“基于以上所有材料生成最终报告。”在这个模式中程序是“导演”它负责维护“计划”和“日志”这两个核心的工作区内容并在适当的时机将它们喂给模型。LLM 则扮演“编剧”和“撰稿人”的角色。这种方法彻底解决了上下文污染问题因为每一轮的上下文都是干净的、目标明确的。2.3 框架层使用智能体Agent框架当前最自然实现 Scratch Workspace 范式的是AI Agent智能体框架比如 LangChain、LlamaIndex、AutoGen 以及热搜词中提到的Chimera等。这些框架内置了类似的工作流管理能力。以Chimera所代表的“面向延迟和性能感知的异构 LLM 多智能体服务”思路为例它揭示了工作区概念的工业化延伸多智能体不同的子任务如规划、检索、编码、分析、总结可以由不同的“专家”智能体负责每个智能体都有自己的“工作区”上下文或状态。异构 LLM规划任务可能用成本低、逻辑强的模型如 Claude Haiku代码生成用 Code LLM最终润色用 GPT-4。每个模型在其擅长的环节工作互不干扰。工作区即通信总线智能体之间通过一个共享的、结构化的“工作区”或称为黑板、共享内存来交换信息。规划智能体把计划写到工作区执行智能体从中读取任务并写入结果审核智能体再读取结果进行校验。这实现了彻底的解耦和专业化。延迟与性能感知框架会考虑不同模型的响应速度和成本动态分配任务确保整个工作流的效率和性价比。工作区在这里成为了任务调度和资源协调的核心数据结构。在这种框架下Scratch Workspace 从一个文本区域进化成了一个结构化的、支持并发访问的、用于协调多智能体的共享状态系统。3. Scratch Workspace 带来的范式转变与核心优势采用工作区模式不仅仅是技术实现的变化它从根本上改变了我们设计和评估 LLM 应用的方式。优势一可解释性与可调试性大幅提升当模型的所有中间步骤都被清晰地记录在“草稿区”或“执行日志”中时开发者就不再需要面对一个“输入-输出”的黑箱。如果最终答案有误你可以回溯到工作区检查是规划不合理、工具调用出错还是数据理解有偏差。这为复杂 AI 系统的调试和优化提供了可能。优势二处理复杂度与长度的能力突破上下文窗口的物理限制如 128K不再是处理超长任务的绝对瓶颈。你可以将一本电子书分块放入工作区让模型先做摘要和索引记录在工作区再基于这些摘要进行问答。工作区成为了模型的“外部记忆”通过精炼和索引有效扩展了其信息处理容量。优势三实现真正的迭代与优化人类写文章会反复修改草稿。在工作区模式下LLM 也可以做到。你可以让一个“批判者”智能体检查工作区中的中间结果提出修改意见并将意见写回工作区。然后“执行者”智能体根据意见进行修正。这种基于工作区的迭代循环是产生高质量、可靠输出的关键。优势四促进模块化与复用一个规划良好的工作区结构例如固定包含“任务分解”、“知识检索结果”、“工具调用记录”、“事实核查列表”、“最终大纲”等字段可以成为一个可复用的任务模板。对于同类任务如每周市场分析你只需要替换输入数据整个工作流就能自动运转。这极大地提升了开发效率。优势五降低成本与提升性能通过将任务分解你可以将不同的子任务分配给不同规模和成本的模型。简单的文本格式化用小型模型复杂的逻辑推理用大型模型。工作区确保了它们之间的信息无损传递。这优化了整体成本效益。同时清晰的规划可以避免模型在错误的方向上“空转”减少无效的 Token 消耗。4. 落地实践从概念到可运行系统的关键考量理解了“为什么”和“是什么”之后如何将它应用到你的项目中以下是一个从零开始构建带工作区的 LLM 应用的实践框架。4.1 第一步定义工作区的数据结构蓝图不要一上来就写代码。先像设计数据库 Schema 一样设计你的工作区。问自己我的任务类型是什么分析、创作、编码、决策解决这个任务理论上需要经历哪几个不可省略的阶段如理解需求 - 获取信息 - 分析信息 - 制定方案 - 输出成果每个阶段会产生什么中间产物如问题清单、搜索查询、数据表格、SWOT分析、报告大纲这些中间产物用什么结构化格式存放最好JSON、YAML、Markdown 表格、纯文本列表例如一个数据分析任务的工作区蓝图可能是{ task_understanding: {原始问题: , 澄清后的问题: , 成功标准: }, data_acquisition: {需查询的数据点: [], 查询语句: [], 获取的原始数据: {}}, analysis_phase: {计算步骤: [], 中间图表描述: , 关键发现: []}, synthesis: {报告核心论点: , 分论点与证据映射: {}, 最终报告草稿: } }4.2 第二步选择实现范式与工具链根据任务复杂度和团队能力做选择轻量级/快速验证从“进阶层”的程序逻辑管理开始。用 Python 脚本配合 OpenAI/Anthropic 等 API手动管理多轮对话和状态存储。使用json.dumps和json.loads来序列化工作区。中等复杂度/生产原型采用LangChain或LlamaIndex。它们提供了Agent、Tools、Memory等抽象其中Agent的scratchpad或intermediate_steps属性就是内置的工作区概念。你可以利用这些高阶抽象快速搭建可用的智能体。高复杂度/性能关键系统研究像Chimera这样的新一代框架。或者基于FastAPI、Celery等构建自定义的微服务架构将规划、执行、合成等环节服务化通过消息队列或 Redis 共享工作区状态。这时工作区就是一个真正的分布式状态存储。4.3 第三步设计并优化提示词Prompt工作区模式对提示词提出了更高要求。你需要为每个阶段规划、执行、合成设计专门的系统提示词。规划阶段提示词核心是让模型学会分解。要示例化Few-Shot给出优秀的工作区蓝图样例。指令要明确“请输出一个 JSON 结构包含…字段。”执行阶段提示词核心是让模型遵循计划并记录。指令如“请严格按‘计划’字段行动。每完成一个子步骤请在‘日志’字段追加一条记录格式为[步骤X] 输入… 操作… 输出… 状态成功/失败。”合成阶段提示词核心是让模型基于完整记录进行精炼。指令如“请忽略所有中间思考过程仅依据‘日志’中记录的事实性结果和‘计划’中的目标生成最终输出。”4.4 第四步实现、测试与迭代循环单任务跑通用一个典型但简单的任务实例走通整个“规划-执行-合成”流程。确保工作区能被正确创建、填充和读取。引入验证与回滚在工作区中增加“验证”字段。执行阶段后可以引入一个“验证者”模型或规则引擎检查执行日志的合理性和完整性。如果验证失败则触发回滚重新规划或重新执行某个子步骤。压力测试与边界处理用更复杂、模糊或存在矛盾信息的任务进行测试。观察工作区在哪些环节会崩溃如规划不合理、工具调用异常、日志格式混乱。针对这些点增加鲁棒性设计比如规划失败后的重试策略日志解析的容错处理。性能分析与优化分析整个流程的延迟和 Token 消耗。瓶颈是在规划、工具调用还是合成考虑缓存、并行化如果子任务独立或用更小/更快的模型处理非关键环节。5. 当前局限与未来展望工作区并非银弹尽管前景广阔但 Scratch Workspace 范式也面临挑战规划质量依赖上游模型如果规划阶段的模型无法做出合理的任务分解整个流程会在第一步就失败。这要求规划模型具备强大的元认知和领域知识。系统复杂性陡增从单次 API 调用到多轮、多智能体协调的系统架构复杂度和调试难度呈指数上升。它不再是“提示词工程”而是真正的“软件工程”。延迟与成本多轮调用意味着更多的 API 请求和更长的端到端延迟。虽然 Chimera 等框架在优化但相比零样本Zero-Shot提示开销依然显著。这要求应用场景本身对延迟不敏感或产出价值足以覆盖成本。工作区设计的艺术性如何设计一个通用、高效、可扩展的工作区数据结构本身就是一个开放的研究和工程问题。未来我们可以预见几个方向框架标准化会出现更成熟、开箱即用的工作区管理框架降低使用门槛。模型原生支持未来的 LLM 可能在架构层面就内置了对“暂存记忆”或“内部工作区”的支持使外部模拟的负担减小。可视化与调试工具会出现专门用于可视化工作区状态流转、跟踪智能体决策过程的调试工具成为 LLM 应用开发的“IDE”。与长期记忆结合工作区短期、任务特定记忆将与向量数据库长期、知识库记忆更深度地融合形成完整的 AI 记忆体系。回到最初的问题。当你下次看到 LLM 在复杂任务上表现不佳时不要只归咎于模型能力或提示词。想一想你是否给了它一张足够好的“草稿纸”并教会它如何使用Scratch Workspace 的本质是为人工智能注入一种可管理、可审查的“思考过程”。它不直接让模型变得更聪明而是让模型的智能以一种我们能够理解、控制和优化的方式流淌出来。从单次生成到规划执行从黑箱到白盒这或许是当前将 LLM 转化为可靠生产力量最值得投入精力的工程路径之一。