在大型语言模型（LLM）快速迭代的今天，“无状态”这一原本属于网络协议领域的概念，正悄然重塑AI应用的底层逻辑。当开发者们习惯性地将对话历史、用户偏好一股脑塞进模型窗口时，一种更轻量、更可控的架构思想正在兴起——无状态 LLM 架构。它并非简单模仿 HTTP 的无状态特性，而是通过“上下文工程”的精妙设计，在抛弃状态包袱的同时，保留了对话的连贯性与智能性。这一转变，或许将深刻影响未来AI产品的开发范式。
无状态：从 HTTP 协议汲取的灵感
HTTP 协议之所以被设计为无状态，核心目的是简化服务器设计、提升可扩展性——每个请求都是独立的，服务器无需保留客户端之前的状态信息。这一特性让 Web 能够支撑数十亿并发用户。如今，LLM 开发者正在复制这一思路：不让模型记忆对话历史，而是将每次交互所需的“上下文”显式打包在请求中。
传统有状态架构下，开发者需要维护一个庞大的状态数据库，记录用户的每一次提问、模型每一次回答，甚至用户的情绪变化。这带来了高昂的存储成本、复杂的同步问题，以及难以调试的状态混乱。无状态 LLM 架构则选择“遗忘”：每次调用都是一次全新的推理，模型不会自主回忆之前的对话。这种设计大幅降低了系统复杂性，也让开发者能够更灵活地控制模型的行为边界。
上下文工程：无状态背后的“隐形记忆”
然而，完全无状态将导致对话断裂——用户说“刚才提到的那个方案”，模型却一无所知。这正是“上下文工程”登场的时刻。它并非让模型拥有记忆，而是人类开发者通过外部工具，主动构建每次请求所携带的“上下文包”。
上下文工程的核心包括三个环节：检索、压缩与注入。检索阶段，系统从外部知识库、对话日志或向量数据库中，精准找到与当前用户输入相关的历史信息；压缩阶段，将冗余信息剔除，用精炼的自然语言或结构化数据表达核心事实；注入阶段，将压缩后的上下文嵌入到用户提示词中，连同当前问题一起送入模型。例如，当用户问“请延续我刚才的方案”，系统会回溯对话记录，提取关键决策点，将其转化为一段类似“此前我们已确定使用A技术，目标是提升响应速度，目前卡点在数据清洗”的文本，再输入模型。
这一过程与 HTTP 协议中 cookie 或 session token 的设计异曲同工——客户端（外部工程）负责携带状态信息，服务器（模型）只处理当前请求。区别在于，HTTP 的“状态”是用户身份和会话标识，而 LLM 的“状态”是知识脉络和推理上下文。
从实践看：为何主流平台纷纷拥抱无状态架构？
观察当前主流 LLM 平台，OpenAI 的 Assistants API、Anthropic 的 Messages API 都已经采用类似设计。它们不要求模型记住用户，而是鼓励开发者主动管理上下文。这种转变并非偶然。一方面，无状态架构天然适配微服务与云原生环境，模型实例可以无缝扩展，不存在状态迁移的痛点；另一方面，它让开发者对模型输出的控制力大大增强——你可以精确决定哪些信息进入模型，从而规避隐私泄露、幻觉传播等风险。
更重要的是，上下文工程催生了“外挂大脑”模式。模型不再需要将所有知识压缩在参数量中，而是可以实时检索最新的网页、数据库甚至用户本地文件。这种“检索增强生成”（RAG）技术正是无状态架构的直接产物。未来，随着上下文窗口不断增长（如 128K、1M token），开发者甚至可以将整本书、整段对话日志直接注入，但核心思想依然不变：状态由工程管理，模型只管推理。
结语：无状态，更智能
无状态 LLM 架构并非技术的退步，而是对复杂性的敬畏。它提醒我们，在追求“模型越来越聪明”的同时，也要思考如何让系统更健壮、更可控。当 HTTP 协议的无状态智慧与 LLM 的生成能力相遇，我们看到了一种新的平衡：模型专注于理解与生成，而上下文工程负责记忆与调度。这或许才是大规模部署 AI 的务实路径——不让模型背负沉重的记忆包袱，而是让人类用工程智慧为它铺设一条清醒、可靠的推理之路。