Scratch Workspaces：解决LLM复杂任务处理难题的工程范式

你有没有遇到过这种情况：给一个大语言模型（LLM）一个复杂的、多步骤的任务，比如“分析这份财报，总结关键风险，并生成一份给管理层的建议报告”。模型开始输出了，前半部分分析得头头是道，但写到后面，突然开始重复前面的观点，或者逻辑开始混乱，甚至“忘记”了任务最开始的要求？

这不是模型“笨”，也不是你的提示词写得不好。这背后是一个更深层、更根本的工程问题：LLM 在处理长序列、复杂任务时，其“工作记忆”是受限且易受干扰的。我们习惯于把 LLM 想象成一个拥有无限草稿纸的天才，但实际上，它更像是一个必须在固定大小的白板上演算的数学家。白板（即上下文窗口）就那么大，写满了就得擦掉旧的才能写新的。

而“Scratch Workspaces”（草稿工作区）这个概念，正是为了解决这个核心矛盾。它不是一个具体的工具，而是一种设计范式，一种让 LLM 从“一次性答题者”进化为“有规划、可迭代的问题解决者”的关键思路。简单来说，它主张：不要让 LLM 在最终答案的“答题卡”上直接打草稿，而是为它开辟一块独立的、结构化的“草稿纸”区域，让它在那里思考、规划、试错和整理，最后再誊写一份清晰的答案。

这听起来像是一个简单的工程技巧，但它的意义远不止于此。它触及了当前大模型应用从“玩具演示”走向“生产级系统”必须跨越的一道鸿沟：如何将一次性的、黑箱的生成过程，转变为可控、可解释、可复用的工作流。

1. 从“即时生成”到“规划-执行”：为什么 LLM 需要草稿纸？

要理解 Scratch Workspaces 的价值，我们得先回到 LLM 工作的基本原理。当你输入一段提示词（Prompt），模型会基于其庞大的参数和你的输入，逐词（Token）地预测下一个最可能的词。这个过程是“自回归”的，意味着它没有真正的“内部循环”或“暂存区”。所有的中间思考，都必须以文本的形式暴露在上下文中。

这就导致了几个经典问题：

1. 思维链污染：当你使用“Chain-of-Thought”（思维链）技术，让模型“一步一步思考”时，这些中间步骤会占据宝贵的上下文窗口。如果任务非常复杂，思维链本身就会变得很长，挤占用于存储问题细节、参考材料或最终答案的空间。
2. 长程依赖丢失：在生成长文本时，模型对上下文开头的记忆会逐渐模糊。它可能会忘记最初设定的格式要求，或者混淆在中间步骤中提到的关键实体。
3. 无法回溯与修正：模型一旦写下某个结论，就很难在后续生成中从根本上否定或大幅修改它。这就像在答题卡上写错了，只能涂改，无法优雅地重写。
4. 多任务协调困难：对于需要调用工具（如计算器、代码解释器）、检索外部知识、或者进行多轮子任务的任务，所有的 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 进行多轮对话。

1. 第一轮对话（规划轮）：你给模型发送指令：“请为‘分析财报并写报告’这个任务，创建一个详细的工作计划。列出所有子步骤、所需数据、可能用到的工具（如计算增长率）和最终输出的结构。将计划输出到‘计划’字段。” 你只解析并存储模型的“计划”输出。
2. 第二轮及更多轮（执行轮）：你新建一个对话（或严格清空上下文，只保留系统提示），然后将原始任务和**第一轮产生的“计划”**一起作为输入。你可以指示模型：“这是任务，这是你之前制定的计划。请严格按照计划执行，并在‘执行日志’区记录每个子步骤的结果、工具调用和中间发现。” 程序会收集这些“执行日志”。
3. 最终轮（合成轮）：再新建一个对话，将任务、计划、完整的执行日志一起输入，并要求模型：“基于以上所有材料，生成最终报告。”

在这个模式中，程序是“导演”，它负责维护“计划”和“日志”这两个核心的工作区内容，并在适当的时机将它们喂给模型。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 第四步：实现、测试与迭代循环

1. 单任务跑通：用一个典型但简单的任务实例，走通整个“规划->执行->合成”流程。确保工作区能被正确创建、填充和读取。
2. 引入验证与回滚：在工作区中增加“验证”字段。执行阶段后，可以引入一个“验证者”模型或规则引擎，检查执行日志的合理性和完整性。如果验证失败，则触发回滚，重新规划或重新执行某个子步骤。
3. 压力测试与边界处理：用更复杂、模糊或存在矛盾信息的任务进行测试。观察工作区在哪些环节会崩溃（如规划不合理、工具调用异常、日志格式混乱）。针对这些点增加鲁棒性设计，比如规划失败后的重试策略，日志解析的容错处理。
4. 性能分析与优化：分析整个流程的延迟和 Token 消耗。瓶颈是在规划、工具调用还是合成？考虑缓存、并行化（如果子任务独立）或用更小/更快的模型处理非关键环节。

5. 当前局限与未来展望：工作区并非银弹

尽管前景广阔，但 Scratch Workspace 范式也面临挑战：

• 规划质量依赖上游模型：如果规划阶段的模型无法做出合理的任务分解，整个流程会在第一步就失败。这要求规划模型具备强大的元认知和领域知识。
• 系统复杂性陡增：从单次 API 调用到多轮、多智能体协调的系统，架构复杂度和调试难度呈指数上升。它不再是“提示词工程”，而是真正的“软件工程”。
• 延迟与成本：多轮调用意味着更多的 API 请求和更长的端到端延迟。虽然 Chimera 等框架在优化，但相比零样本（Zero-Shot）提示，开销依然显著。这要求应用场景本身对延迟不敏感，或产出价值足以覆盖成本。
• 工作区设计的艺术性：如何设计一个通用、高效、可扩展的工作区数据结构，本身就是一个开放的研究和工程问题。

未来，我们可以预见几个方向：

1. 框架标准化：会出现更成熟、开箱即用的工作区管理框架，降低使用门槛。
2. 模型原生支持：未来的 LLM 可能在架构层面就内置了对“暂存记忆”或“内部工作区”的支持，使外部模拟的负担减小。
3. 可视化与调试工具：会出现专门用于可视化工作区状态流转、跟踪智能体决策过程的调试工具，成为 LLM 应用开发的“IDE”。
4. 与长期记忆结合：工作区（短期、任务特定记忆）将与向量数据库（长期、知识库记忆）更深度地融合，形成完整的 AI 记忆体系。

回到最初的问题。当你下次看到 LLM 在复杂任务上表现不佳时，不要只归咎于模型能力或提示词。想一想，你是否给了它一张足够好的“草稿纸”，并教会它如何使用？Scratch Workspace 的本质，是为人工智能注入一种可管理、可审查的“思考过程”。它不直接让模型变得更聪明，而是让模型的智能以一种我们能够理解、控制和优化的方式流淌出来。从单次生成到规划执行，从黑箱到白盒，这或许是当前将 LLM 转化为可靠生产力量，最值得投入精力的工程路径之一。