
当前LLM应用的核心矛盾——强大的模型潜力需要依赖高质量、高密度的上下文信息才能被有效激活。

无状态服务配IMDB，无状态LLM良配是谁？答：上下文工程，给只有“金鱼记忆”的LLM插上记忆的翅膀。

我理解：AI系统 = 人 + 上下文信息 + LLM底座。
* 以前【Vibe Coding 和 Prompt工程】是匹配的一对儿，
* 现在【Spec驱动开发 和 Context工程】是匹配的一对儿。

<div align="center"><img src="https://developer.qcloudimg.com/http-save/yehe-11563618/a7c9a4c74e0cdf740b762649b276561b.jpg" width="70%"></div>


----------------------------------

## AI系统 = 人 + 上下文信息 + LLM 底座

**人**是需求的发起者和价值的验收者，**LLM 底座**是能力引擎，**上下文信息**是连接“人”和“LLM”的**价值桥梁**：
    - 脱离“上下文信息”，LLM 底座只是一个无差别的通用工具；
    - 脱离“人”的需求，上下文信息是无意义的数据流；
    - 三者的耦合度，直接决定 AI 系统的场景价值密度。

AI系统 = 人 + 记忆模块（上下文信息） + LLM底座

在LLM-based Agent体系中，记忆模块承担着四大关键职能:
1 状态持续化:RLP框架通过对话状态记忆，在长达数周的医疗咨询中保持患者病史的一致性
2 认知效率优化:AriGraph的事件图记忆将具身Agent的路径规划速度提升300%，通过情景记忆复用历史导航方案，
3 个性化建模:生成代理(Generative Aaent)的短期记忆能记录用户偏好，在电商推荐场景实现点击率17%的提升··
4 跨任务迁移:Agent S的语义记忆网络支持GU操作技能的跨平台迁移，使新任务学习成本降低60%


----------------------------------

## 上下文工程：医疗案例的实证

>多论文论及，通过对话状态记忆，在长达数周的医疗咨询中保持患者病史的一致性，AI医生做到了：
>* 问诊环节高效、
>* 诊断依据充分、
>* 治疗策略合理 + 有延续性

重要启发：LLM再强，也要有高密度信息的激活才行。

这恰恰点破了Agent记忆模块存在的根本理由：它是解决LLM“金鱼记忆”问题，将静态的模型能力转化为持续智能。




----------------------------------

## 上下文工程：正从“技巧”向“学科”进化

未来，上下文工程可能成为每一个 AI 应用开发者必须掌握的系统能力，就像今天的 API 架构、数据库设计一样基础而关键。

越来越多的公司在构建“上下文调度系统”；
* 统一的上下文协议（如 MCP）正在被提议；
* 上下文图谱、长时记忆引擎、KV 缓存管理等新技术逐渐标准化；
* 自动上下文调度器将成为 LLM 应用的核心模块；
* 研究者提出将上下文信息建模为“信息场”，以更细粒度感知任务状态和意图。

一个具备“上下文感知”的智能体，会先主动检索：
* 项目状态：按照项目规划，导入功能这周进入开发阶段。
* 需求文档：设计稿明确列出 V1 支持 CSV 和 JSON，但后者会延后一周上线。
* 团队氛围：研发那边人手吃紧，担心 scope 变化影响进度。
* 任务历史：曾有一次因需求细节未澄清导致返工，刚复盘过。
* 个性化语气设定：直接、细节清楚、减少异步往返。

<div align="center"><img src="https://developer.qcloudimg.com/http-save/yehe-11563618/47fe2a599b3242443b1a59d95a6d7975.jpg" width="70%"></div>


----------------------------------

## 回到研发场景：代码助手&长期研发

小场景（需求是“高效完成项目开发”）
  - 人：开发者
  - 上下文信息：项目的代码结构、API 文档、历史提交记录、bug 修复日志、团队编码规范
  - LLM 底座：代码生成模型（如 国内智谱GLM、国外Claude）
  - 价值：记忆模块持续存储项目上下文，让代码助手能理解 “项目全局逻辑”，而非仅生成孤立的代码片段。

大场景（需求是“产品演进支撑业务演进”）
  - 人：业务部门、研发部门多岗位
  - 上下文信息：业务目标、业务范围、系统需求、架构决策、代码结构、提交记录、测试记录
  - LLM 底座：代码生成模型（如 国内智谱GLM、国外Claude）
  - 长期价值：支撑起需求变更管理、架构基线评估、设计演进权衡、代码版本迭代等实践环节。让产品可长期演进。


----------------------------------

## SDD as 上下文工程一环​

SDD通过"**规格优先**"的工作流（Spec-first → Plan → Tasks → Implement），将模糊的自然语言需求转化为结构化的上下文信息，这正是AI系统公式中"上下文信息"的核心价值——为LLM提供精确、可执行的指令。

人类专注于定义"做什么"（意图），AI负责生成"怎么做"（实现）。这恰好映射了AI系统公式的构成要素：

- **人**：对应SDD中的规格编写者，负责定义业务意图和约束
- **上下文信息**：对应SDD的规格文档（spec.md、plan.md、tasks.md），是结构化的、可执行的上下文
- **LLM底座**：对应AI编码代理，根据规格生成代码实现


----------------------------------

## SDD = 人机协同定义意图 + AI生成实现 + Tools完成测试

**LLM本质上是无状态的**，SDD通过规格文档作为"**外部记忆系统**"：

- **规格锚定（Spec-anchored）**：规格文档长期保留，成为功能的"数字档案"，确保跨会话、跨迭代的一致性
- **规格即源码（Spec-as-source）**：规格成为唯一需要人类维护的源文件，代码由AI自动生成，实现了"意图与实现的彻底分离"

SDD作为"上下文信息"的一部分，为无状态的LLM提供持续、结构化的记忆，使其能够处理复杂、长期的任务。

通过这套框架，SDD实现了"**人机协同定义意图，AI生成实现**"的协作模式。实现了从"代码为王"到"规格驱动"的范式转变。

| SDD组件 | 对应AI系统要素 | 作用 |
|---------|---------------|------|
| **Spec.md** | 上下文信息（业务意图） | 定义"做什么"，是LLM的输入上下文 |
| **Plan.md** | 上下文信息（技术约束） | 定义"怎么做"，为AI提供技术上下文 |
| **Tasks.md** | 上下文信息（执行计划） | 拆解任务，为AI提供可执行的指令 |
| **AI Agent** | LLM底座 | 根据规格生成代码 |


----------------------------------

## SDD can 支撑系统的可维护性与可演进性

SDD 是实现“有序演进”的核心保障。
1. **维护阶段：规格文档是故障定位的依据**
    当 AI 系统出现“病史一致性丢失”“LLM 输出幻觉”等问题时，规格文档中定义的 **要素交互流程、信息流转规则** 可作为故障定位的基准：比如排查是“上下文信息未正确存储”，还是“LLM 未正确调用历史信息”，避免维护过程中的盲目性。
2. **演进阶段：规格文档是功能扩展的蓝图**
    当 AI 系统需要扩展场景（如从医疗咨询延伸到慢病管理）时，规格文档会明确 **新增要素的接入规则**：比如新增“慢病随访记录”上下文字段的存储格式、与原有病史信息的关联方式、LLM 针对慢病场景的输出规范，确保新功能与原有系统无缝衔接。


----------------------------------

## 【附录】技术：LangGraph的记忆管理机制

以主流的LangGraph框架为例，它通过一套精巧的机制实现了上述流程。
- **`Checkpointer`（检查点）**：这是实现**状态持续化**的核心。它负责在Agent执行的每个步骤（step）自动保存整个图的状态（包括对话消息、中间结果等）。通过指定一个唯一的 `thread_id`，可以在多次调用甚至应用重启后，精确恢复到某一状态继续执行。
- **`Store`（存储）**：用于实现**长期记忆**。与`Checkpointer`自动保存状态不同，`Store`需要开发者显式地进行读写操作，通常用于保存需要跨线程共享的结构化知识（如用户档案、产品信息等）。
- **集成向量检索**：在实际生产中，LangGraph可以轻松集成PgVector、Chroma等向量数据库。当需要回忆长期记忆时，就通过语义相似度进行检索，并将结果动态加入当前对话上下文。



----------------------------------

## 【附录】无状态 + 有状态的架构组合是分布式系统的通用范式

无状态服务优点是：可伸缩性强。

同时，大型无状态技术架构 无一例外 需要有状态服务 伴航：
- 例如：白盒交换机 SONiC = 一堆云原生的无状态容器 + Redis作状态管理中心
- 例如：微信 = 无状态IM服务 + 分布式存储

所以，你看到设计原则总是这样写：
1. 服务无状态化：业务逻辑服务不保存状态，状态统一由外部存储管理
2. 状态外部化：使用Redis、MySQL、Elasticsearch等组件集中管理状态

**无状态 + 有状态的架构组合是分布式系统的通用范式**，两者分工明确：无状态层负责高效计算与请求处理，有状态层负责数据持久化、状态一致性保障，缺一不可

| 大型架构 | 无状态核心组件 | 有状态伴航服务 | 核心状态管理逻辑 | 典型场景价值 |
|----------|----------------|----------------|------------------|--------------|
| **大型电商 淘宝** | 无状态应用集群（商品/订单/用户API容器化部署）、Nginx/LVS负载均衡、CDN静态资源节点 | 1. Redis集群：会话状态（登录态、购物车）、库存缓存<br>2. MySQL主从集群：用户数据、订单记录、交易流水<br>3. RocketMQ消息队列：订单创建、支付回调的状态流转<br>4. Tair/Redis分布式缓存：商品详情、价格等高频数据 | 会话状态通过客户端Cookie+Redis集中存储，交易状态通过消息队列异步同步，核心数据落地数据库，避免服务实例存储状态 | 支撑双11亿级并发，订单峰值10万TPS，商品详情页95%请求在缓存层拦截 |
| **云原生容器编排 Kubernetes（K8s）** | 无状态Deployment/Pod（如微服务API、Web应用）、Service网格（Istio） | 1. Etcd集群：存储集群配置、Pod状态、服务端点<br>2. PV/PVC：持久化容器数据（如日志、业务文件）<br>3. 分布式存储（如Ceph）：容器数据持久化 | Etcd作为“集群大脑”记录全局状态，Pod故障重启时从Etcd恢复配置，持久化存储保证数据不丢失 | 支持Pod弹性扩缩容，故障自动迁移，实现集群高可用 |
| **AI大模型服务（如GPT-4 API）** | 无状态LLM推理容器（按请求动态扩缩）、API网关 | 1. Redis/向量数据库：会话上下文、用户历史对话<br>2. PostgreSQL：用户权限、调用日志、计费记录<br>3. 分布式缓存：模型参数分片缓存（加速推理） | 会话状态外置，每次请求携带会话ID，LLM推理不存储状态，通过检索获取历史上下文 | 突破LLM上下文窗口限制，支持长期对话一致性，降低推理成本 |
| **分布式数据库（如TiDB）** | 无状态SQL层（TiDB Server节点，负责SQL解析、执行） | 1. 有状态存储层（TiKV集群，分布式事务KV存储）<br>2. PD集群：记录TiKV节点拓扑、数据分片位置 | TiDB Server无状态可水平扩展，TiKV存储数据并保证一致性，PD负责集群调度 | 支持PB级数据存储，百万级QPS，适合电商、金融等大规模数据场景 |
| **视频直播平台（如抖音直播）** | 无状态直播推流/拉流节点、弹幕分发服务 | 1. Redis：直播间在线人数、用户互动状态<br>2. Kafka：弹幕消息、直播数据日志<br>3. HBase：用户直播历史、观看记录 | 实时状态存Redis，消息流通过Kafka异步处理，历史数据落地HBase | 支撑百万级直播间并发，弹幕实时分发，观看体验无卡顿 |
| **Serverless函数计算（如AWS Lambda）** | 无状态函数实例（按需启动，执行后销毁） | 1. DynamoDB：函数执行结果、用户状态<br>2. S3：函数依赖资源、输出文件<br>3. API Gateway：请求路由、认证状态 | 函数不存储状态，执行所需数据从外部存储获取，执行结果持久化到数据库/对象存储 | 按请求计费，弹性扩缩至零，降低运维成本 |

---

当前LLM应用的核心矛盾——强大的模型潜力需要依赖高质量、高密度的上下文信息才能被有效激活。

CodeGen生态05 | 方法层：SDD as 上下文工程一环

上下文工程，给只有“金鱼记忆”的LLM插上记忆的翅膀。

人工智能

架构设计

开发工具

LLM应用的核心在于上下文工程，通过记忆模块解决"金鱼记忆"问题，将静态模型转化为持续智能。AI系统=人+上下文信息+LLM底座，其中上下文工程是关键桥梁。医疗案例证明记忆模块能保持长期一致性，提升诊断效率。SDD通过规格文档作为外部记忆系统，实现人机协同开发。LangGraph等框架通过检查点和存储机制实现状态管理，突破LLM无状态限制。

腾讯云数据库特惠，新用户首单0.5折起


2026新春采购季

tencentdb-catalog

message-queue-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

LLM应用的核心在于上下文工程，通过记忆模块解决"金鱼记忆"问题，将静态模型转化为持续智能。AI系统=人+上下文信息+LLM底座，其中上下文工程是关键桥梁。医疗案例证明记忆模块能保持长期一致性，提升诊断效率。SDD通过规格文档作为外部记忆系统，实现人机协同开发。LangGraph等框架通过检查点和存储机制实现状态管理，...

CodeGen生态05 | 方法层：SDD as 上下文工程一环-腾讯云开发者社区-腾讯云

CodeGen生态05 | 方法层：SDD as 上下文工程一环

CodeGen生态05 | 方法层：SDD as 上下文工程一环

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐