1. 这篇文章真正要解决的问题如果你正在尝试将大语言模型LLM集成到你的应用或服务中无论是构建一个智能客服、一个代码助手还是一个复杂的多智能体系统你很可能已经遇到了一个核心的工程难题如何高效、稳定且低成本地管理模型推理的“上下文”。传统的做法是什么我们往往将用户与模型的每一次对话都塞进一个连续的、不断增长的上下文窗口里。这带来了几个显而易见的痛点成本飙升随着对话轮次增加输入的Token数量线性增长而像GPT-4这类按Token计费的模型推理成本会急剧上升。性能下降模型处理超长上下文时推理速度会变慢响应延迟Latency增加用户体验变差。信息污染早期无关的对话历史会持续占用宝贵的上下文空间可能干扰模型对当前问题的专注度导致回答质量下降。状态管理复杂在多轮对话中维护用户状态、工具调用历史等代码会变得臃肿且难以调试。那么有没有一种方法能让我们像管理服务器或容器一样为每一次独立的“思考任务”分配一个干净、隔离、可随时销毁的临时环境这正是“Scratch Workspaces”暂存工作区概念试图为LLMs带来的范式转变。它不是一个具体的开源工具而是一种设计思想和架构模式。本文将深入探讨“Scratch Workspaces”为何是下一代LLM应用架构的关键。我们不会停留在概念空谈而是会结合最新的行业实践如网络热词中提到的chimera一种面向异构LLM的、延迟和性能感知的多智能体服务框架为你拆解其核心原理、实现思路并通过一个具体的Python示例展示如何为你的LLM智能体构建一个简易但功能完整的“暂存工作区”。读完本文你将能清晰地判断这种模式是否适合你的项目并掌握将其落地的初步方法。2. 基础概念与核心原理在深入之前我们需要厘清几个关键概念并理解“Scratch Workspaces”要解决的核心矛盾。2.1 什么是 LLM 的“上下文”Context对于LLM而言上下文就是模型在进行推理生成下一个Token时所能“看到”的全部文本信息。它通常包括系统提示词System Prompt定义AI的角色、能力和行为边界。对话历史Chat History用户与AI之间已发生的多轮问答。当前查询Current Query用户本次提出的问题。检索到的知识Retrieved Knowledge从向量数据库等外部系统获取的相关信息。模型的能力尤其是遵循指令、保持对话一致性和利用外部信息的能力严重依赖于上下文的构建质量。2.2 传统连续上下文的局限性当前绝大多数LLM应用采用“连续上下文”模式。想象一个不断延长的卷轴所有对话都记录在上面。这种模式的问题在于无差别的记忆模型无法区分哪些历史信息是当前任务的关键哪些是冗余噪音。资源浪费为保存可能不再需要的早期对话持续支付计算和金钱成本。“失焦”风险在超长上下文中模型可能无法有效关注到最相关的指令或信息。2.3 Scratch Workspaces一种隔离的、任务导向的上下文管理范式“Scratch Workspaces”的核心思想是为每一个独立的、有明确边界的目标任务动态创建并管理一个专有的、临时的上下文环境。这个工作区是隔离的、状态独立的任务完成后即可销毁。类比理解这就像软件开发中的“函数调用”或“微服务”。传统模式如同一个全局变量不断增长的巨型单体函数逻辑纠缠难以维护。Scratch Workspaces模式如同一个纯净的函数。每次调用时传入明确的参数任务描述、必要背景函数内部使用局部变量工作区内的临时上下文进行计算返回结果后局部变量被回收。下次调用互不干扰。这种模式带来的核心转变从“记忆一切”到“按需记忆”工作区只加载与当前任务强相关的历史和信息。从“成本不可控”到“成本可预估”每个工作区的上下文长度是有限且可知的便于进行预算和优化。从“性能随对话衰减”到“性能稳定”每次推理都在一个长度可控的上下文内进行延迟更可预测。更适合复杂工作流在多智能体Multi-Agent系统中每个智能体可以拥有自己的工作区通过明确定义的接口消息进行协作架构更清晰。2.4 与相关热词chimera的联系网络热词chimera描述了一个“延迟和性能感知的、服务于异构LLM的多智能体系统”。这恰恰是“Scratch Workspaces”理念的绝佳应用场景。异构LLM不同任务可能由不同规模、不同能力的模型处理例如简单分类用小型模型复杂创作用大型模型。每个模型实例都可以关联独立的工作区。多智能体服务每个智能体Agent负责特定的子任务如规划、执行、验证。为每个智能体的每次任务执行创建独立工作区能实现更好的隔离、容错和资源管理。延迟与性能感知系统可以监控每个工作区的上下文长度和模型推理耗时动态调度或优化例如将过载的工作区任务迁移到其他节点或提示用户简化问题。3. 环境准备与前置条件为了演示如何实现一个简易的Scratch Workspace我们需要搭建一个基础的Python开发环境。本例将使用LangChain和OpenAI API作为核心工具链因为它们生态成熟能清晰展示概念。基础环境要求操作系统Windows 10/11, macOS, 或 Linux (Ubuntu 20.04)Python版本3.8 或更高版本 (推荐 3.9)包管理工具pip核心Python库我们将创建一个新的虚拟环境来管理依赖这是Python项目的最佳实践。# 1. 创建并进入项目目录 mkdir llm-scratch-workspace-demo cd llm-scratch-workspace-demo # 2. 创建Python虚拟环境 (以venv为例) python -m venv venv # 3. 激活虚拟环境 # Windows (PowerShell) .\venv\Scripts\Activate.ps1 # macOS/Linux source venv/bin/activate # 4. 安装核心依赖 pip install langchain langchain-openai python-dotenv关键依赖说明langchain: 提供了构建LLM应用的高级框架包括链Chains、智能体Agents等抽象非常适合实现工作区模式。langchain-openai: LangChain的OpenAI集成包用于调用GPT系列模型。python-dotenv: 用于从.env文件安全加载环境变量如API密钥。获取OpenAI API密钥访问 OpenAI平台 并登录。点击右上角个人头像选择 “View API keys”。点击 “Create new secret key”复制生成的密钥。项目结构初始化在项目根目录创建以下文件和文件夹llm-scratch-workspace-demo/ ├── .env # 存储敏感配置如API密钥 ├── .gitignore # Git忽略文件 ├── requirements.txt # 项目依赖声明 ├── src/ │ ├── __init__.py │ ├── workspace.py # Scratch Workspace 核心类 │ └── main.py # 主程序入口 └── tests/ # 测试目录可选创建.env文件并填入你的API密钥# .env OPENAI_API_KEYsk-your-actual-api-key-here重要安全提醒务必在.gitignore文件中添加.env切勿将API密钥提交到版本控制系统。4. 核心流程拆解构建一个简易Scratch Workspace实现一个Scratch Workspace本质上是设计一个管理“任务生命周期”和“上下文状态”的类。我们将遵循以下核心流程来构建4.1 定义工作区类Workspace Class这个类将封装一次独立任务执行所需的所有资源模型实例、记忆系统、工具集以及任务本身的描述。4.2 初始化与资源加载在工作区创建时__init__根据任务描述动态加载必要的上下文“素材”。这可能包括从数据库或文件系统中读取相关的知识片段。初始化一个只包含本次任务相关历史的“短期记忆”。绑定该任务专用的工具例如计算器、搜索引擎API。4.3 任务执行与上下文构建这是核心步骤。当调用工作区的run(task_input)方法时构建本次推理的精准上下文结合系统指令、工作区初始知识、短期记忆和当前输入组装成一个长度优化的Prompt。调用LLM将构建好的上下文发送给模型。解析与执行如果模型返回的是工具调用指令则在工作区隔离的环境中执行对应工具并将结果作为新的上下文追加再次调用模型形成链式思考。更新短期记忆将本次交互中有价值的信息非全部原始对话提炼后存入工作区记忆。4.4 结果返回与资源清理任务完成后返回最终结果。工作区对象可以被保留以供后续关联任务使用也可以被显式销毁destroy()释放其占用的资源如模型连接、内存中的知识库。4.5 与外部系统的协作在复杂场景下工作区可能需要与其他工作区或中心化的“长期记忆”服务通信。这通过定义清晰的消息传递接口来实现。5. 完整示例与代码实现下面我们实现一个具体的ScratchWorkspace类。这个示例模拟一个“技术文档问答助手”每个工作区针对一个特定的技术产品例如“Redis”、“Docker”并加载该产品的专属知识库。5.1 实现 ScratchWorkspace 核心类# src/workspace.py import os from typing import Dict, List, Any, Optional from langchain_openai import ChatOpenAI from langchain.schema import HumanMessage, SystemMessage, AIMessage from langchain.memory import ConversationBufferWindowMemory from dotenv import load_dotenv # 加载环境变量 load_dotenv() class ScratchWorkspace: 一个简易的 Scratch Workspace 实现。 每个工作区针对一个特定主题拥有独立的记忆和上下文。 def __init__(self, workspace_id: str, topic: str, knowledge_base: Optional[str] None): 初始化一个暂存工作区。 Args: workspace_id: 工作区唯一标识符 topic: 工作区专注的主题如 Redis knowledge_base: 与该主题相关的初始知识文本 self.workspace_id workspace_id self.topic topic # 1. 初始化专属的LLM实例可配置不同模型 # 使用 gpt-3.5-turbo 以控制成本实际可根据任务复杂度选择 self.llm ChatOpenAI( modelgpt-3.5-turbo, temperature0.1, # 低温度保证回答更专注、确定 openai_api_keyos.getenv(OPENAI_API_KEY) ) # 2. 初始化工作区独立的短期记忆 # 只保留最近3轮对话防止上下文无限膨胀 self.memory ConversationBufferWindowMemory( k3, return_messagesTrue, memory_keychat_history ) # 3. 加载主题相关初始知识到工作区 self.base_knowledge knowledge_base or self._load_default_knowledge(topic) # 4. 定义工作区的系统指令将其角色与主题绑定 self.system_prompt f你是一个专注于 {self.topic} 的技术专家助手。 你的知识背景如下 {self.base_knowledge} 请基于以上知识专业、准确地回答用户关于 {self.topic} 的问题。 如果问题超出你的知识范围请如实告知不要编造信息。 你的回答应简洁明了重点突出。 print(f[Workspace {self.workspace_id}] 已初始化主题: {self.topic}) def _load_default_knowledge(self, topic: str) - str: 模拟从数据库或文件加载知识。此处返回模拟数据。 # 在实际应用中这里可能是从向量数据库检索的相关文档 knowledge_map { Redis: Redis是一个开源的内存数据结构存储用作数据库、缓存和消息代理。它支持字符串、哈希、列表、集合等多种数据结构。, Docker: Docker是一个用于开发、发布和运行应用程序的开放平台。它允许你将应用程序与依赖项打包到一个容器中从而实现环境一致性。, Kubernetes: Kubernetes是一个开源的容器编排平台用于自动化部署、扩展和管理容器化应用程序。 } return knowledge_map.get(topic, f这里是关于{topic}的一般性知识。) def run(self, user_input: str) - str: 在工作区内执行一次任务处理用户输入。 Args: user_input: 用户的查询 Returns: LLM生成的回答 # 1. 从记忆加载历史对话 history self.memory.load_memory_variables({})[chat_history] # 2. 构建本次调用的完整消息列表 messages [SystemMessage(contentself.system_prompt)] messages.extend(history) # 添加上下文记忆 messages.append(HumanMessage(contentuser_input)) # 添加当前问题 # 3. 调用LLM print(f[Workspace {self.workspace_id}] 调用LLM上下文长度: {len(str(messages))} 字符) try: response self.llm.invoke(messages) ai_message response.content except Exception as e: ai_message f请求模型时发生错误: {e} # 4. 将本次交互保存到工作区记忆 self.memory.save_context( {input: user_input}, {output: ai_message} ) # 5. 返回结果 return ai_message def get_context_info(self) - Dict[str, Any]: 获取工作区当前上下文信息用于监控和调试。 history self.memory.load_memory_variables({})[chat_history] return { workspace_id: self.workspace_id, topic: self.topic, memory_messages_count: len(history), approx_context_length: len(str(history)) len(self.system_prompt) } def destroy(self): 清理工作区资源。在实际应用中可能关闭连接、清理缓存等。 print(f[Workspace {self.workspace_id}] 正在销毁...) # 清空内存 self.memory.clear() # 这里LLM客户端通常无需特殊关闭但如有其他资源如数据库连接应在此释放 self.llm None print(f[Workspace {self.workspace_id}] 已销毁。)5.2 编写主程序进行演示# src/main.py import time from src.workspace import ScratchWorkspace def main(): 演示 Scratch Workspaces 的创建、使用和隔离性。 print( * 50) print(演示1: 创建两个不同主题的工作区) print( * 50) # 创建专注于 Redis 的工作区 redis_workspace ScratchWorkspace( workspace_idws_redis_001, topicRedis, knowledge_baseRedis 持久化有两种方式RDB快照和 AOF追加日志。主从复制可以提高可用性。 ) # 创建专注于 Docker 的工作区 docker_workspace ScratchWorkspace( workspace_idws_docker_001, topicDocker, knowledge_baseDockerfile 用于定义镜像构建步骤。docker-compose 用于编排多容器应用。 ) print(\n * 50) print(演示2: 在工作区内执行独立任务) print( * 50) # 向 Redis 工作区提问 question1 Redis 的 RDB 和 AOF 有什么区别 print(f\n[用户] 向 Redis工作区 提问: {question1}) answer1 redis_workspace.run(question1) print(f[Redis助手] {answer1}) # 向 Docker 工作区提问 question2 Dockerfile 里的 COPY 和 ADD 指令有什么不同 print(f\n[用户] 向 Docker工作区 提问: {question2}) answer2 docker_workspace.run(question2) print(f[Docker助手] {answer2}) print(\n * 50) print(演示3: 展示工作区的隔离性记忆不互通) print( * 50) # 再次向 Redis 工作区提问一个 Docker 相关问题它不应利用到 Docker 工作区的历史 question3 那我刚才问的 Dockerfile 指令问题在 Redis 里有什么类似概念吗 print(f\n[用户] 再次向 Redis工作区 提问: {question3}) answer3 redis_workspace.run(question3) print(f[Redis助手] {answer3}) # 预期答案应围绕 Redis 配置或命令而不会提及 Docker证明记忆隔离。 print(\n * 50) print(演示4: 查看工作区上下文状态) print( * 50) print(\nRedis 工作区状态:) print(redis_workspace.get_context_info()) print(\nDocker 工作区状态:) print(docker_workspace.get_context_info()) print(\n * 50) print(演示5: 清理销毁工作区) print( * 50) redis_workspace.destroy() docker_workspace.destroy() print(\n演示结束。) if __name__ __main__: main()5.3 模拟知识库检索的增强版工作区在实际场景中初始知识库knowledge_base很可能来自一个向量数据库的检索结果。下面我们扩展ScratchWorkspace模拟这一过程使其更贴近真实应用。# src/workspace_enhanced.py import os from typing import List from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 示例使用Chroma需安装 chromadb from langchain.schema import Document from langchain.memory import ConversationBufferWindowMemory from dotenv import load_dotenv load_dotenv() class ScratchWorkspaceWithRetrieval: 一个集成了向量检索的增强版 Scratch Workspace。 def __init__(self, workspace_id: str, topic: str): self.workspace_id workspace_id self.topic topic # 初始化LLM和Embeddings self.llm ChatOpenAI(modelgpt-3.5-turbo, temperature0.1) self.embeddings OpenAIEmbeddings() # 初始化记忆 self.memory ConversationBufferWindowMemory(k3, return_messagesTrue, memory_keychat_history) # 模拟一个“知识库”。实际中这里应连接你的向量数据库。 self._init_simulated_vector_store() # 系统指令动态部分由检索到的知识填充 self.base_system_prompt f你是一个专注于 {self.topic} 的技术专家助手。 你将获得一些关于 {self.topic} 的参考知识。请严格依据这些知识来回答问题。 如果问题无法从提供的知识中找到答案请说“根据现有资料我无法回答这个问题。” 回答应简洁专业。 参考知识 {{context}} def _init_simulated_vector_store(self): 初始化一个模拟的向量存储用于演示检索增强生成RAG。 # 模拟一些文档 simulated_docs [ Document(page_contentRedis持久化方式RDB是定时内存快照恢复快但可能丢失最后一次快照后的数据。, metadata{source: redis_guide}), Document(page_contentRedis持久化方式AOF记录每个写操作命令数据安全性高但文件体积大。, metadata{source: redis_guide}), Document(page_contentDocker镜像由只读层构成容器在镜像层之上添加一个可写层。, metadata{source: docker_basics}), Document(page_contentKubernetes Pod是最小的部署单元可以包含一个或多个容器。, metadata{source: k8s_concepts}), ] # 过滤出与当前主题相关的文档模拟按主题分区检索 self.relevant_docs [doc for doc in simulated_docs if self.topic.lower() in doc.page_content.lower()] # 在实际RAG中这里应该是self.vectorstore Chroma.from_documents(docs, self.embeddings) def _retrieve_knowledge(self, query: str, k: int 2) - str: 根据查询从知识库中检索最相关的文档。 # 模拟检索过程在实际中这里调用 vectorstore.similarity_search(query, k) # 本例中我们简单返回与主题相关的模拟文档内容 retrieved_texts [doc.page_content for doc in self.relevant_docs[:k]] return \n---\n.join(retrieved_texts) if retrieved_texts else 暂无相关参考知识。 def run(self, user_input: str) - str: 运行工作区检索 - 构建上下文 - 调用LLM。 # 1. 检索与当前查询相关的知识 context self._retrieve_knowledge(user_input) system_message_content self.base_system_prompt.format(contextcontext) # 2. 构建消息 history self.memory.load_memory_variables({})[chat_history] messages [{role: system, content: system_message_content}] # 转换历史消息格式简化示例 for msg in history: if msg.type human: messages.append({role: user, content: msg.content}) elif msg.type ai: messages.append({role: assistant, content: msg.content}) messages.append({role: user, content: user_input}) # 3. 调用LLM (使用新的 invoke 接口格式) try: response self.llm.invoke(messages) ai_message response.content except Exception as e: ai_message f请求模型时发生错误: {e} # 4. 保存记忆 self.memory.save_context({input: user_input}, {output: ai_message}) print(f[Workspace {self.workspace_id}] 检索到 {len(context.split(---))} 条知识片段。) return ai_message # 使用示例 if __name__ __main__: ws ScratchWorkspaceWithRetrieval(enhanced_01, Redis) answer ws.run(AOF 持久化的优点是什么) print(answer)6. 运行结果与效果验证现在让我们运行主程序来验证Scratch Workspace的效果。6.1 运行命令与预期输出在项目根目录下执行python -m src.main你应该能看到类似以下的输出具体回答内容因模型随机性略有不同 演示1: 创建两个不同主题的工作区 [Workspace ws_redis_001] 已初始化主题: Redis [Workspace ws_docker_001] 已初始化主题: Docker 演示2: 在工作区内执行独立任务 [用户] 向 Redis工作区 提问: Redis 的 RDB 和 AOF 有什么区别 [Workspace ws_redis_001] 调用LLM上下文长度: 约XXX 字符 [Redis助手] RDBRedis Database是Redis的持久化方式之一它通过创建数据集的快照来保存数据。...详细对比RDB和AOF [用户] 向 Docker工作区 提问: Dockerfile 里的 COPY 和 ADD 指令有什么不同 [Workspace ws_docker_001] 调用LLM上下文长度: 约XXX 字符 [Docker助手] COPY 和 ADD 指令都用于将文件从构建上下文复制到镜像中。主要区别在于ADD 指令功能更多...详细解释区别 演示3: 展示工作区的隔离性记忆不互通 [用户] 再次向 Redis工作区 提问: 那我刚才问的 Dockerfile 指令问题在 Redis 里有什么类似概念吗 [Workspace ws_redis_001] 调用LLM上下文长度: 约XXX 字符 [Redis助手] 在 Redis 中没有直接与 Dockerfile 指令完全对应的概念。不过从配置和持久化的角度来看...回答聚焦于Redis自身的配置命令如 CONFIG SET不会提及Docker 演示4: 查看工作区上下文状态 Redis 工作区状态: {workspace_id: ws_redis_001, topic: Redis, memory_messages_count: 4, approx_context_length: 约XXX} Docker 工作区状态: {workspace_id: ws_docker_001, topic: Docker, memory_messages_count: 2, approx_context_length: 约XXX} 演示5: 清理销毁工作区 [Workspace ws_redis_001] 正在销毁... [Workspace ws_redis_001] 已销毁。 [Workspace ws_docker_001] 正在销毁... [Workspace ws_docker_001] 已销毁。 演示结束。6.2 效果验证要点隔离性验证成功在演示3中向Redis工作区询问Docker相关问题时它的回答完全基于Redis自身的知识体系和它自己独立的对话历史没有“记住”或“穿越”到另一个工作区的对话。这证明了工作区在记忆和上下文层面的有效隔离。上下文长度可控通过get_context_info()可以监控每个工作区的近似上下文长度。由于使用了ConversationBufferWindowMemory(k3)无论对话进行多少轮工作区记忆的对话轮次始终不超过3轮有效控制了上下文膨胀。成本与性能可预估每个工作区的每次run调用其上下文主要由“系统指令 知识库 最近3轮历史 当前问题”构成长度是稳定且相对较短的。这使得单次API调用的Token消耗和延迟变得可预测便于进行性能分析和成本核算。任务导向明确每个工作区在创建时就被赋予了一个明确的topic和相关的knowledge_base这使得它的行为高度专业化避免了通用聊天机器人可能出现的上下文干扰。7. 常见问题与排查思路在实际应用Scratch Workspaces模式时你可能会遇到以下问题问题现象可能原因排查方式解决方案工作区响应变慢或成本异常高1. 工作区记忆 (k) 设置过大。2. 初始知识库 (knowledge_base) 文本过长。3. 系统提示词过于冗长。1. 打印或记录每次run前的上下文长度。2. 检查get_context_info()返回的approx_context_length。1. 减小ConversationBufferWindowMemory的k值。2. 对知识库进行摘要或分块按需检索。3. 精简系统提示词移除不必要的指令。工作区“遗忘”了重要早期信息k值设置过小导致超出窗口的历史对话被丢弃。回顾业务需求确定必须长期记忆的关键信息类型如用户姓名、核心偏好。1. 对于必须记忆的状态信息不要放在对话历史中应作为工作区的属性变量存储。2. 或实现一个“摘要记忆”模式定期将长历史总结成一段文本存入系统提示词。多个工作区之间需要共享信息业务逻辑要求工作区协作如Agent A的结果需传递给Agent B。分析信息流明确哪些信息需要共享哪些必须隔离。设计一个工作区管理器Workspace Manager或消息总线。工作区不直接通信而是通过管理器传递结构化的消息对象。工作区初始化加载知识耗时过长从向量数据库检索大量文档或知识库文件过大。分析初始化阶段的性能瓶颈。1. 实现懒加载在第一次run时再根据查询去检索知识而非初始化时全量加载。2. 对知识进行预索引和缓存。LLM回答偏离工作区主题1. 系统提示词约束力不够。2. 检索到的知识相关性不强干扰了模型。1. 检查系统提示词是否清晰强调了“仅基于给定知识回答”。2. 检查检索环节的相似度阈值和返回数量 (k)。1. 强化系统提示词使用更严格的指令例如“你必须且只能参考以下信息”。2. 调整检索策略提高相似度阈值或使用重排序Re-ranking技术。内存泄漏长时间运行后内存增长工作区对象未被正确销毁或内部缓存如向量存储客户端未释放。使用内存 profiling 工具监控。1. 确保在任务完成后调用工作区的destroy()方法。2. 对于长期运行的服务实现工作区的生命周期管理和自动回收如LRU缓存。8. 最佳实践与工程建议将Scratch Workspaces模式投入生产环境需要考虑更多工程细节。8.1 工作区生命周期管理创建策略根据会话ID、用户ID或任务类型创建。避免为每个请求都创建新工作区带来不必要的开销。复用与池化对于常见任务类型可以维护一个工作区对象池避免频繁的初始化和销毁。超时销毁为工作区设置一个空闲超时时间。如果一段时间内没有活动则自动调用destroy()释放资源。8.2 上下文构建优化动态上下文组装不要总是将全部知识库塞进上下文。采用RAG检索增强生成模式根据当前查询动态检索最相关的片段。记忆摘要对于长对话定期让LLM对之前的对话历史进行总结将摘要而非原始历史存入系统提示词可以大幅节省Token。分层记忆系统结合短期记忆ConversationBufferWindowMemory和长期记忆如向量存储用户历史偏好。工作区主要管理短期记忆和任务上下文长期记忆由独立服务提供。8.3 与多智能体Multi-Agent架构集成这正是chimera等框架关注的核心。你可以将每个智能体Agent实例化在一个独立的工作区中。编排器Orchestrator负责接收用户请求分析任务将其分配给最合适的智能体工作区。通信协议定义智能体间通信的消息格式如AgentMessage包含发送者、接收者、任务ID、内容等。共享黑板Blackboard提供一个共享存储空间供智能体工作区读写中间结果避免通过冗长的自然语言在对话历史中传递复杂数据。8.4 监控与可观测性关键指标监控每个工作区的上下文长度、LLM调用延迟、Token消耗、错误率。链路追踪为每个工作区执行的任务分配唯一的trace_id便于在分布式系统中追踪整个请求链路。日志记录详细记录工作区的创建、运行、销毁日志以及重要的中间决策如检索到的文档、工具调用参数。8.5 安全与权限数据隔离确保不同用户或租户的工作区在数据层面完全隔离防止信息泄露。工具沙箱如果工作区可以执行代码或调用外部API必须在一个安全的沙箱环境中进行严格限制其权限。输入输出过滤对传入工作区的用户输入和LLM的生成结果进行内容安全过滤防止注入攻击或生成有害内容。9. 总结与后续学习方向Scratch Workspaces 不仅仅是一个编程技巧它代表了一种更符合LLM本质的、面向任务和资源隔离的应用架构思想。通过将庞大的、连续的对话上下文拆分为一个个轻量的、专注的、可管理的临时工作区我们能够更精细地控制成本、提升性能、保证回答质量并构建出更清晰、更健壮的多智能体系统。本文带你从概念理解走到了一个可运行的Python原型。要将其应用于真实项目下一步你可以探索成熟的框架深入研究像LangGraph、AutoGen、CrewAI等多智能体框架看它们是如何实现类似“工作区”或“状态管理”概念的。集成向量数据库将示例中的模拟检索替换为真实的Chroma、Pinecone或Weaviate连接实现真正的RAG工作流。设计工作区管理器实现一个管理多个工作区生命周期的服务包括创建、查找、调度和销毁。性能压测与调优对你的工作区实现进行压力测试找到上下文构建、模型调用、记忆存储等环节的瓶颈并针对性优化。关注前沿动态持续关注如chimera这类专注于异构LLM、低延迟、性能感知的多智能体服务框架理解工业界是如何解决大规模部署时的复杂问题的。技术的价值在于解决真实问题。当你下次被LLM应用的上下文管理、高昂成本或复杂状态所困扰时不妨回想一下“Scratch Workspaces”这个思路为每次思考创造一个干净的房间。这或许就是你架构演进的下一个关键节点。 LLM应用架构革新：Scratch Workspaces实现高效上下文管理
1. 这篇文章真正要解决的问题如果你正在尝试将大语言模型LLM集成到你的应用或服务中无论是构建一个智能客服、一个代码助手还是一个复杂的多智能体系统你很可能已经遇到了一个核心的工程难题如何高效、稳定且低成本地管理模型推理的“上下文”。传统的做法是什么我们往往将用户与模型的每一次对话都塞进一个连续的、不断增长的上下文窗口里。这带来了几个显而易见的痛点成本飙升随着对话轮次增加输入的Token数量线性增长而像GPT-4这类按Token计费的模型推理成本会急剧上升。性能下降模型处理超长上下文时推理速度会变慢响应延迟Latency增加用户体验变差。信息污染早期无关的对话历史会持续占用宝贵的上下文空间可能干扰模型对当前问题的专注度导致回答质量下降。状态管理复杂在多轮对话中维护用户状态、工具调用历史等代码会变得臃肿且难以调试。那么有没有一种方法能让我们像管理服务器或容器一样为每一次独立的“思考任务”分配一个干净、隔离、可随时销毁的临时环境这正是“Scratch Workspaces”暂存工作区概念试图为LLMs带来的范式转变。它不是一个具体的开源工具而是一种设计思想和架构模式。本文将深入探讨“Scratch Workspaces”为何是下一代LLM应用架构的关键。我们不会停留在概念空谈而是会结合最新的行业实践如网络热词中提到的chimera一种面向异构LLM的、延迟和性能感知的多智能体服务框架为你拆解其核心原理、实现思路并通过一个具体的Python示例展示如何为你的LLM智能体构建一个简易但功能完整的“暂存工作区”。读完本文你将能清晰地判断这种模式是否适合你的项目并掌握将其落地的初步方法。2. 基础概念与核心原理在深入之前我们需要厘清几个关键概念并理解“Scratch Workspaces”要解决的核心矛盾。2.1 什么是 LLM 的“上下文”Context对于LLM而言上下文就是模型在进行推理生成下一个Token时所能“看到”的全部文本信息。它通常包括系统提示词System Prompt定义AI的角色、能力和行为边界。对话历史Chat History用户与AI之间已发生的多轮问答。当前查询Current Query用户本次提出的问题。检索到的知识Retrieved Knowledge从向量数据库等外部系统获取的相关信息。模型的能力尤其是遵循指令、保持对话一致性和利用外部信息的能力严重依赖于上下文的构建质量。2.2 传统连续上下文的局限性当前绝大多数LLM应用采用“连续上下文”模式。想象一个不断延长的卷轴所有对话都记录在上面。这种模式的问题在于无差别的记忆模型无法区分哪些历史信息是当前任务的关键哪些是冗余噪音。资源浪费为保存可能不再需要的早期对话持续支付计算和金钱成本。“失焦”风险在超长上下文中模型可能无法有效关注到最相关的指令或信息。2.3 Scratch Workspaces一种隔离的、任务导向的上下文管理范式“Scratch Workspaces”的核心思想是为每一个独立的、有明确边界的目标任务动态创建并管理一个专有的、临时的上下文环境。这个工作区是隔离的、状态独立的任务完成后即可销毁。类比理解这就像软件开发中的“函数调用”或“微服务”。传统模式如同一个全局变量不断增长的巨型单体函数逻辑纠缠难以维护。Scratch Workspaces模式如同一个纯净的函数。每次调用时传入明确的参数任务描述、必要背景函数内部使用局部变量工作区内的临时上下文进行计算返回结果后局部变量被回收。下次调用互不干扰。这种模式带来的核心转变从“记忆一切”到“按需记忆”工作区只加载与当前任务强相关的历史和信息。从“成本不可控”到“成本可预估”每个工作区的上下文长度是有限且可知的便于进行预算和优化。从“性能随对话衰减”到“性能稳定”每次推理都在一个长度可控的上下文内进行延迟更可预测。更适合复杂工作流在多智能体Multi-Agent系统中每个智能体可以拥有自己的工作区通过明确定义的接口消息进行协作架构更清晰。2.4 与相关热词chimera的联系网络热词chimera描述了一个“延迟和性能感知的、服务于异构LLM的多智能体系统”。这恰恰是“Scratch Workspaces”理念的绝佳应用场景。异构LLM不同任务可能由不同规模、不同能力的模型处理例如简单分类用小型模型复杂创作用大型模型。每个模型实例都可以关联独立的工作区。多智能体服务每个智能体Agent负责特定的子任务如规划、执行、验证。为每个智能体的每次任务执行创建独立工作区能实现更好的隔离、容错和资源管理。延迟与性能感知系统可以监控每个工作区的上下文长度和模型推理耗时动态调度或优化例如将过载的工作区任务迁移到其他节点或提示用户简化问题。3. 环境准备与前置条件为了演示如何实现一个简易的Scratch Workspace我们需要搭建一个基础的Python开发环境。本例将使用LangChain和OpenAI API作为核心工具链因为它们生态成熟能清晰展示概念。基础环境要求操作系统Windows 10/11, macOS, 或 Linux (Ubuntu 20.04)Python版本3.8 或更高版本 (推荐 3.9)包管理工具pip核心Python库我们将创建一个新的虚拟环境来管理依赖这是Python项目的最佳实践。# 1. 创建并进入项目目录 mkdir llm-scratch-workspace-demo cd llm-scratch-workspace-demo # 2. 创建Python虚拟环境 (以venv为例) python -m venv venv # 3. 激活虚拟环境 # Windows (PowerShell) .\venv\Scripts\Activate.ps1 # macOS/Linux source venv/bin/activate # 4. 安装核心依赖 pip install langchain langchain-openai python-dotenv关键依赖说明langchain: 提供了构建LLM应用的高级框架包括链Chains、智能体Agents等抽象非常适合实现工作区模式。langchain-openai: LangChain的OpenAI集成包用于调用GPT系列模型。python-dotenv: 用于从.env文件安全加载环境变量如API密钥。获取OpenAI API密钥访问 OpenAI平台 并登录。点击右上角个人头像选择 “View API keys”。点击 “Create new secret key”复制生成的密钥。项目结构初始化在项目根目录创建以下文件和文件夹llm-scratch-workspace-demo/ ├── .env # 存储敏感配置如API密钥 ├── .gitignore # Git忽略文件 ├── requirements.txt # 项目依赖声明 ├── src/ │ ├── __init__.py │ ├── workspace.py # Scratch Workspace 核心类 │ └── main.py # 主程序入口 └── tests/ # 测试目录可选创建.env文件并填入你的API密钥# .env OPENAI_API_KEYsk-your-actual-api-key-here重要安全提醒务必在.gitignore文件中添加.env切勿将API密钥提交到版本控制系统。4. 核心流程拆解构建一个简易Scratch Workspace实现一个Scratch Workspace本质上是设计一个管理“任务生命周期”和“上下文状态”的类。我们将遵循以下核心流程来构建4.1 定义工作区类Workspace Class这个类将封装一次独立任务执行所需的所有资源模型实例、记忆系统、工具集以及任务本身的描述。4.2 初始化与资源加载在工作区创建时__init__根据任务描述动态加载必要的上下文“素材”。这可能包括从数据库或文件系统中读取相关的知识片段。初始化一个只包含本次任务相关历史的“短期记忆”。绑定该任务专用的工具例如计算器、搜索引擎API。4.3 任务执行与上下文构建这是核心步骤。当调用工作区的run(task_input)方法时构建本次推理的精准上下文结合系统指令、工作区初始知识、短期记忆和当前输入组装成一个长度优化的Prompt。调用LLM将构建好的上下文发送给模型。解析与执行如果模型返回的是工具调用指令则在工作区隔离的环境中执行对应工具并将结果作为新的上下文追加再次调用模型形成链式思考。更新短期记忆将本次交互中有价值的信息非全部原始对话提炼后存入工作区记忆。4.4 结果返回与资源清理任务完成后返回最终结果。工作区对象可以被保留以供后续关联任务使用也可以被显式销毁destroy()释放其占用的资源如模型连接、内存中的知识库。4.5 与外部系统的协作在复杂场景下工作区可能需要与其他工作区或中心化的“长期记忆”服务通信。这通过定义清晰的消息传递接口来实现。5. 完整示例与代码实现下面我们实现一个具体的ScratchWorkspace类。这个示例模拟一个“技术文档问答助手”每个工作区针对一个特定的技术产品例如“Redis”、“Docker”并加载该产品的专属知识库。5.1 实现 ScratchWorkspace 核心类# src/workspace.py import os from typing import Dict, List, Any, Optional from langchain_openai import ChatOpenAI from langchain.schema import HumanMessage, SystemMessage, AIMessage from langchain.memory import ConversationBufferWindowMemory from dotenv import load_dotenv # 加载环境变量 load_dotenv() class ScratchWorkspace: 一个简易的 Scratch Workspace 实现。 每个工作区针对一个特定主题拥有独立的记忆和上下文。 def __init__(self, workspace_id: str, topic: str, knowledge_base: Optional[str] None): 初始化一个暂存工作区。 Args: workspace_id: 工作区唯一标识符 topic: 工作区专注的主题如 Redis knowledge_base: 与该主题相关的初始知识文本 self.workspace_id workspace_id self.topic topic # 1. 初始化专属的LLM实例可配置不同模型 # 使用 gpt-3.5-turbo 以控制成本实际可根据任务复杂度选择 self.llm ChatOpenAI( modelgpt-3.5-turbo, temperature0.1, # 低温度保证回答更专注、确定 openai_api_keyos.getenv(OPENAI_API_KEY) ) # 2. 初始化工作区独立的短期记忆 # 只保留最近3轮对话防止上下文无限膨胀 self.memory ConversationBufferWindowMemory( k3, return_messagesTrue, memory_keychat_history ) # 3. 加载主题相关初始知识到工作区 self.base_knowledge knowledge_base or self._load_default_knowledge(topic) # 4. 定义工作区的系统指令将其角色与主题绑定 self.system_prompt f你是一个专注于 {self.topic} 的技术专家助手。 你的知识背景如下 {self.base_knowledge} 请基于以上知识专业、准确地回答用户关于 {self.topic} 的问题。 如果问题超出你的知识范围请如实告知不要编造信息。 你的回答应简洁明了重点突出。 print(f[Workspace {self.workspace_id}] 已初始化主题: {self.topic}) def _load_default_knowledge(self, topic: str) - str: 模拟从数据库或文件加载知识。此处返回模拟数据。 # 在实际应用中这里可能是从向量数据库检索的相关文档 knowledge_map { Redis: Redis是一个开源的内存数据结构存储用作数据库、缓存和消息代理。它支持字符串、哈希、列表、集合等多种数据结构。, Docker: Docker是一个用于开发、发布和运行应用程序的开放平台。它允许你将应用程序与依赖项打包到一个容器中从而实现环境一致性。, Kubernetes: Kubernetes是一个开源的容器编排平台用于自动化部署、扩展和管理容器化应用程序。 } return knowledge_map.get(topic, f这里是关于{topic}的一般性知识。) def run(self, user_input: str) - str: 在工作区内执行一次任务处理用户输入。 Args: user_input: 用户的查询 Returns: LLM生成的回答 # 1. 从记忆加载历史对话 history self.memory.load_memory_variables({})[chat_history] # 2. 构建本次调用的完整消息列表 messages [SystemMessage(contentself.system_prompt)] messages.extend(history) # 添加上下文记忆 messages.append(HumanMessage(contentuser_input)) # 添加当前问题 # 3. 调用LLM print(f[Workspace {self.workspace_id}] 调用LLM上下文长度: {len(str(messages))} 字符) try: response self.llm.invoke(messages) ai_message response.content except Exception as e: ai_message f请求模型时发生错误: {e} # 4. 将本次交互保存到工作区记忆 self.memory.save_context( {input: user_input}, {output: ai_message} ) # 5. 返回结果 return ai_message def get_context_info(self) - Dict[str, Any]: 获取工作区当前上下文信息用于监控和调试。 history self.memory.load_memory_variables({})[chat_history] return { workspace_id: self.workspace_id, topic: self.topic, memory_messages_count: len(history), approx_context_length: len(str(history)) len(self.system_prompt) } def destroy(self): 清理工作区资源。在实际应用中可能关闭连接、清理缓存等。 print(f[Workspace {self.workspace_id}] 正在销毁...) # 清空内存 self.memory.clear() # 这里LLM客户端通常无需特殊关闭但如有其他资源如数据库连接应在此释放 self.llm None print(f[Workspace {self.workspace_id}] 已销毁。)5.2 编写主程序进行演示# src/main.py import time from src.workspace import ScratchWorkspace def main(): 演示 Scratch Workspaces 的创建、使用和隔离性。 print( * 50) print(演示1: 创建两个不同主题的工作区) print( * 50) # 创建专注于 Redis 的工作区 redis_workspace ScratchWorkspace( workspace_idws_redis_001, topicRedis, knowledge_baseRedis 持久化有两种方式RDB快照和 AOF追加日志。主从复制可以提高可用性。 ) # 创建专注于 Docker 的工作区 docker_workspace ScratchWorkspace( workspace_idws_docker_001, topicDocker, knowledge_baseDockerfile 用于定义镜像构建步骤。docker-compose 用于编排多容器应用。 ) print(\n * 50) print(演示2: 在工作区内执行独立任务) print( * 50) # 向 Redis 工作区提问 question1 Redis 的 RDB 和 AOF 有什么区别 print(f\n[用户] 向 Redis工作区 提问: {question1}) answer1 redis_workspace.run(question1) print(f[Redis助手] {answer1}) # 向 Docker 工作区提问 question2 Dockerfile 里的 COPY 和 ADD 指令有什么不同 print(f\n[用户] 向 Docker工作区 提问: {question2}) answer2 docker_workspace.run(question2) print(f[Docker助手] {answer2}) print(\n * 50) print(演示3: 展示工作区的隔离性记忆不互通) print( * 50) # 再次向 Redis 工作区提问一个 Docker 相关问题它不应利用到 Docker 工作区的历史 question3 那我刚才问的 Dockerfile 指令问题在 Redis 里有什么类似概念吗 print(f\n[用户] 再次向 Redis工作区 提问: {question3}) answer3 redis_workspace.run(question3) print(f[Redis助手] {answer3}) # 预期答案应围绕 Redis 配置或命令而不会提及 Docker证明记忆隔离。 print(\n * 50) print(演示4: 查看工作区上下文状态) print( * 50) print(\nRedis 工作区状态:) print(redis_workspace.get_context_info()) print(\nDocker 工作区状态:) print(docker_workspace.get_context_info()) print(\n * 50) print(演示5: 清理销毁工作区) print( * 50) redis_workspace.destroy() docker_workspace.destroy() print(\n演示结束。) if __name__ __main__: main()5.3 模拟知识库检索的增强版工作区在实际场景中初始知识库knowledge_base很可能来自一个向量数据库的检索结果。下面我们扩展ScratchWorkspace模拟这一过程使其更贴近真实应用。# src/workspace_enhanced.py import os from typing import List from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 示例使用Chroma需安装 chromadb from langchain.schema import Document from langchain.memory import ConversationBufferWindowMemory from dotenv import load_dotenv load_dotenv() class ScratchWorkspaceWithRetrieval: 一个集成了向量检索的增强版 Scratch Workspace。 def __init__(self, workspace_id: str, topic: str): self.workspace_id workspace_id self.topic topic # 初始化LLM和Embeddings self.llm ChatOpenAI(modelgpt-3.5-turbo, temperature0.1) self.embeddings OpenAIEmbeddings() # 初始化记忆 self.memory ConversationBufferWindowMemory(k3, return_messagesTrue, memory_keychat_history) # 模拟一个“知识库”。实际中这里应连接你的向量数据库。 self._init_simulated_vector_store() # 系统指令动态部分由检索到的知识填充 self.base_system_prompt f你是一个专注于 {self.topic} 的技术专家助手。 你将获得一些关于 {self.topic} 的参考知识。请严格依据这些知识来回答问题。 如果问题无法从提供的知识中找到答案请说“根据现有资料我无法回答这个问题。” 回答应简洁专业。 参考知识 {{context}} def _init_simulated_vector_store(self): 初始化一个模拟的向量存储用于演示检索增强生成RAG。 # 模拟一些文档 simulated_docs [ Document(page_contentRedis持久化方式RDB是定时内存快照恢复快但可能丢失最后一次快照后的数据。, metadata{source: redis_guide}), Document(page_contentRedis持久化方式AOF记录每个写操作命令数据安全性高但文件体积大。, metadata{source: redis_guide}), Document(page_contentDocker镜像由只读层构成容器在镜像层之上添加一个可写层。, metadata{source: docker_basics}), Document(page_contentKubernetes Pod是最小的部署单元可以包含一个或多个容器。, metadata{source: k8s_concepts}), ] # 过滤出与当前主题相关的文档模拟按主题分区检索 self.relevant_docs [doc for doc in simulated_docs if self.topic.lower() in doc.page_content.lower()] # 在实际RAG中这里应该是self.vectorstore Chroma.from_documents(docs, self.embeddings) def _retrieve_knowledge(self, query: str, k: int 2) - str: 根据查询从知识库中检索最相关的文档。 # 模拟检索过程在实际中这里调用 vectorstore.similarity_search(query, k) # 本例中我们简单返回与主题相关的模拟文档内容 retrieved_texts [doc.page_content for doc in self.relevant_docs[:k]] return \n---\n.join(retrieved_texts) if retrieved_texts else 暂无相关参考知识。 def run(self, user_input: str) - str: 运行工作区检索 - 构建上下文 - 调用LLM。 # 1. 检索与当前查询相关的知识 context self._retrieve_knowledge(user_input) system_message_content self.base_system_prompt.format(contextcontext) # 2. 构建消息 history self.memory.load_memory_variables({})[chat_history] messages [{role: system, content: system_message_content}] # 转换历史消息格式简化示例 for msg in history: if msg.type human: messages.append({role: user, content: msg.content}) elif msg.type ai: messages.append({role: assistant, content: msg.content}) messages.append({role: user, content: user_input}) # 3. 调用LLM (使用新的 invoke 接口格式) try: response self.llm.invoke(messages) ai_message response.content except Exception as e: ai_message f请求模型时发生错误: {e} # 4. 保存记忆 self.memory.save_context({input: user_input}, {output: ai_message}) print(f[Workspace {self.workspace_id}] 检索到 {len(context.split(---))} 条知识片段。) return ai_message # 使用示例 if __name__ __main__: ws ScratchWorkspaceWithRetrieval(enhanced_01, Redis) answer ws.run(AOF 持久化的优点是什么) print(answer)6. 运行结果与效果验证现在让我们运行主程序来验证Scratch Workspace的效果。6.1 运行命令与预期输出在项目根目录下执行python -m src.main你应该能看到类似以下的输出具体回答内容因模型随机性略有不同 演示1: 创建两个不同主题的工作区 [Workspace ws_redis_001] 已初始化主题: Redis [Workspace ws_docker_001] 已初始化主题: Docker 演示2: 在工作区内执行独立任务 [用户] 向 Redis工作区 提问: Redis 的 RDB 和 AOF 有什么区别 [Workspace ws_redis_001] 调用LLM上下文长度: 约XXX 字符 [Redis助手] RDBRedis Database是Redis的持久化方式之一它通过创建数据集的快照来保存数据。...详细对比RDB和AOF [用户] 向 Docker工作区 提问: Dockerfile 里的 COPY 和 ADD 指令有什么不同 [Workspace ws_docker_001] 调用LLM上下文长度: 约XXX 字符 [Docker助手] COPY 和 ADD 指令都用于将文件从构建上下文复制到镜像中。主要区别在于ADD 指令功能更多...详细解释区别 演示3: 展示工作区的隔离性记忆不互通 [用户] 再次向 Redis工作区 提问: 那我刚才问的 Dockerfile 指令问题在 Redis 里有什么类似概念吗 [Workspace ws_redis_001] 调用LLM上下文长度: 约XXX 字符 [Redis助手] 在 Redis 中没有直接与 Dockerfile 指令完全对应的概念。不过从配置和持久化的角度来看...回答聚焦于Redis自身的配置命令如 CONFIG SET不会提及Docker 演示4: 查看工作区上下文状态 Redis 工作区状态: {workspace_id: ws_redis_001, topic: Redis, memory_messages_count: 4, approx_context_length: 约XXX} Docker 工作区状态: {workspace_id: ws_docker_001, topic: Docker, memory_messages_count: 2, approx_context_length: 约XXX} 演示5: 清理销毁工作区 [Workspace ws_redis_001] 正在销毁... [Workspace ws_redis_001] 已销毁。 [Workspace ws_docker_001] 正在销毁... [Workspace ws_docker_001] 已销毁。 演示结束。6.2 效果验证要点隔离性验证成功在演示3中向Redis工作区询问Docker相关问题时它的回答完全基于Redis自身的知识体系和它自己独立的对话历史没有“记住”或“穿越”到另一个工作区的对话。这证明了工作区在记忆和上下文层面的有效隔离。上下文长度可控通过get_context_info()可以监控每个工作区的近似上下文长度。由于使用了ConversationBufferWindowMemory(k3)无论对话进行多少轮工作区记忆的对话轮次始终不超过3轮有效控制了上下文膨胀。成本与性能可预估每个工作区的每次run调用其上下文主要由“系统指令 知识库 最近3轮历史 当前问题”构成长度是稳定且相对较短的。这使得单次API调用的Token消耗和延迟变得可预测便于进行性能分析和成本核算。任务导向明确每个工作区在创建时就被赋予了一个明确的topic和相关的knowledge_base这使得它的行为高度专业化避免了通用聊天机器人可能出现的上下文干扰。7. 常见问题与排查思路在实际应用Scratch Workspaces模式时你可能会遇到以下问题问题现象可能原因排查方式解决方案工作区响应变慢或成本异常高1. 工作区记忆 (k) 设置过大。2. 初始知识库 (knowledge_base) 文本过长。3. 系统提示词过于冗长。1. 打印或记录每次run前的上下文长度。2. 检查get_context_info()返回的approx_context_length。1. 减小ConversationBufferWindowMemory的k值。2. 对知识库进行摘要或分块按需检索。3. 精简系统提示词移除不必要的指令。工作区“遗忘”了重要早期信息k值设置过小导致超出窗口的历史对话被丢弃。回顾业务需求确定必须长期记忆的关键信息类型如用户姓名、核心偏好。1. 对于必须记忆的状态信息不要放在对话历史中应作为工作区的属性变量存储。2. 或实现一个“摘要记忆”模式定期将长历史总结成一段文本存入系统提示词。多个工作区之间需要共享信息业务逻辑要求工作区协作如Agent A的结果需传递给Agent B。分析信息流明确哪些信息需要共享哪些必须隔离。设计一个工作区管理器Workspace Manager或消息总线。工作区不直接通信而是通过管理器传递结构化的消息对象。工作区初始化加载知识耗时过长从向量数据库检索大量文档或知识库文件过大。分析初始化阶段的性能瓶颈。1. 实现懒加载在第一次run时再根据查询去检索知识而非初始化时全量加载。2. 对知识进行预索引和缓存。LLM回答偏离工作区主题1. 系统提示词约束力不够。2. 检索到的知识相关性不强干扰了模型。1. 检查系统提示词是否清晰强调了“仅基于给定知识回答”。2. 检查检索环节的相似度阈值和返回数量 (k)。1. 强化系统提示词使用更严格的指令例如“你必须且只能参考以下信息”。2. 调整检索策略提高相似度阈值或使用重排序Re-ranking技术。内存泄漏长时间运行后内存增长工作区对象未被正确销毁或内部缓存如向量存储客户端未释放。使用内存 profiling 工具监控。1. 确保在任务完成后调用工作区的destroy()方法。2. 对于长期运行的服务实现工作区的生命周期管理和自动回收如LRU缓存。8. 最佳实践与工程建议将Scratch Workspaces模式投入生产环境需要考虑更多工程细节。8.1 工作区生命周期管理创建策略根据会话ID、用户ID或任务类型创建。避免为每个请求都创建新工作区带来不必要的开销。复用与池化对于常见任务类型可以维护一个工作区对象池避免频繁的初始化和销毁。超时销毁为工作区设置一个空闲超时时间。如果一段时间内没有活动则自动调用destroy()释放资源。8.2 上下文构建优化动态上下文组装不要总是将全部知识库塞进上下文。采用RAG检索增强生成模式根据当前查询动态检索最相关的片段。记忆摘要对于长对话定期让LLM对之前的对话历史进行总结将摘要而非原始历史存入系统提示词可以大幅节省Token。分层记忆系统结合短期记忆ConversationBufferWindowMemory和长期记忆如向量存储用户历史偏好。工作区主要管理短期记忆和任务上下文长期记忆由独立服务提供。8.3 与多智能体Multi-Agent架构集成这正是chimera等框架关注的核心。你可以将每个智能体Agent实例化在一个独立的工作区中。编排器Orchestrator负责接收用户请求分析任务将其分配给最合适的智能体工作区。通信协议定义智能体间通信的消息格式如AgentMessage包含发送者、接收者、任务ID、内容等。共享黑板Blackboard提供一个共享存储空间供智能体工作区读写中间结果避免通过冗长的自然语言在对话历史中传递复杂数据。8.4 监控与可观测性关键指标监控每个工作区的上下文长度、LLM调用延迟、Token消耗、错误率。链路追踪为每个工作区执行的任务分配唯一的trace_id便于在分布式系统中追踪整个请求链路。日志记录详细记录工作区的创建、运行、销毁日志以及重要的中间决策如检索到的文档、工具调用参数。8.5 安全与权限数据隔离确保不同用户或租户的工作区在数据层面完全隔离防止信息泄露。工具沙箱如果工作区可以执行代码或调用外部API必须在一个安全的沙箱环境中进行严格限制其权限。输入输出过滤对传入工作区的用户输入和LLM的生成结果进行内容安全过滤防止注入攻击或生成有害内容。9. 总结与后续学习方向Scratch Workspaces 不仅仅是一个编程技巧它代表了一种更符合LLM本质的、面向任务和资源隔离的应用架构思想。通过将庞大的、连续的对话上下文拆分为一个个轻量的、专注的、可管理的临时工作区我们能够更精细地控制成本、提升性能、保证回答质量并构建出更清晰、更健壮的多智能体系统。本文带你从概念理解走到了一个可运行的Python原型。要将其应用于真实项目下一步你可以探索成熟的框架深入研究像LangGraph、AutoGen、CrewAI等多智能体框架看它们是如何实现类似“工作区”或“状态管理”概念的。集成向量数据库将示例中的模拟检索替换为真实的Chroma、Pinecone或Weaviate连接实现真正的RAG工作流。设计工作区管理器实现一个管理多个工作区生命周期的服务包括创建、查找、调度和销毁。性能压测与调优对你的工作区实现进行压力测试找到上下文构建、模型调用、记忆存储等环节的瓶颈并针对性优化。关注前沿动态持续关注如chimera这类专注于异构LLM、低延迟、性能感知的多智能体服务框架理解工业界是如何解决大规模部署时的复杂问题的。技术的价值在于解决真实问题。当你下次被LLM应用的上下文管理、高昂成本或复杂状态所困扰时不妨回想一下“Scratch Workspaces”这个思路为每次思考创造一个干净的房间。这或许就是你架构演进的下一个关键节点。