两个 AI 助手的故事
2025 年 4 月,一位产品经理同时测试了两个 AI 写作助手。
助手 A:
产品经理:“帮我写一封邮件,告诉客户项目会延期。”
助手 A:“好的,这是一封专业的延期通知邮件…"(生成了一封通用的、礼貌的邮件)
助手 B:
产品经理:“帮我写一封邮件,告诉客户项目会延期。”
助手 B:“我注意到您正在与 Acme Corp 合作他们的新网站项目。根据项目日志,原定 4 月 30 日上线,但现在需要延期到 5 月 15 日。延期原因是等待他们的品牌指南最终确认。我建议这样写:‘Hi Sarah,关于我们新网站的上线时间,我需要跟您更新一下…’”
助手 B 不仅知道项目背景,还知道:
- 客户联系人是 Sarah
- 项目的具体内容和时间线
- 延期的真实原因
- Sarah 的沟通风格(直接、喜欢简洁)
- 之前的沟通历史
结果:产品经理选择了助手 B,并愿意支付 3 倍的价格。
这就是上下文工程的力量。
什么是上下文工程?
上下文工程是设计、管理和优化 AI 系统可用信息的过程,使 AI 能够在正确的时间、以正确的方式、使用正确的信息来服务用户。
上下文的维度
1. 用户上下文
- 用户是谁(角色、职位、公司)
- 用户的历史行为(过去做了什么)
- 用户的偏好(喜欢什么样的输出)
- 用户的目标(想要达成什么)
2. 任务上下文
- 当前任务是什么
- 任务的前置条件
- 任务的预期结果
- 任务的优先级和紧急程度
3. 环境上下文
- 时间(什么时候)
- 地点(在哪里)
- 设备(使用什么设备)
- 网络状态(带宽、延迟)
4. 业务上下文
- 公司信息和结构
- 项目状态和历史
- 团队协作模式
- 业务流程和规则
5. 知识上下文
- 领域知识(行业术语、最佳实践)
- 实时信息(新闻、市场数据)
- 专有数据(公司内部文档、数据库)
- 外部知识(公开信息、第三方数据)
上下文工程的核心技术
1. 检索增强生成(RAG)
RAG 是上下文工程的基础技术,通过检索相关信息来增强 AI 的生成能力。
基本架构:
class RAGSystem:
def __init__(self):
self.document_store = VectorDatabase()
self.retriever = SemanticRetriever()
self.llm = LargeLanguageModel()
def generate_with_context(self, query):
# 1. 检索相关文档
relevant_docs = self.retriever.retrieve(query, top_k=5)
# 2. 构建上下文
context = self.build_context(relevant_docs, query)
# 3. 生成回答
response = self.llm.generate(context + query)
return response
高级 RAG 技术:
混合检索(Hybrid Retrieval)
结合语义检索和关键词检索:
def hybrid_retrieve(self, query):
# 语义检索
semantic_results = self.semantic_retriever.retrieve(query)
# 关键词检索
keyword_results = self.keyword_retriever.retrieve(query)
# 融合结果
combined = self.reciprocal_rank_fusion(semantic_results, keyword_results)
return combined
查询重写(Query Rewriting)
优化用户的查询以提高检索质量:
def rewrite_query(self, query, context):
# 使用 LLM 重写查询
rewritten = self.llm.generate(f"""
原始查询:{query}
上下文:{context}
请重写查询以提高检索效果:
""")
return rewritten
多跳检索(Multi-Hop Retrieval)
对于复杂问题,进行多轮检索:
def multi_hop_retrieve(self, query):
# 第一轮检索
first_hop = self.retrieve(query)
# 分析第一轮结果,生成第二轮查询
second_query = self.generate_follow_up_query(query, first_hop)
# 第二轮检索
second_hop = self.retrieve(second_query)
# 合并结果
return first_hop + second_hop
2. 记忆系统
记忆系统让 AI 能够记住过去的交互和学习。
短期记忆(Working Memory)
当前会话的上下文:
class WorkingMemory:
def __init__(self, max_tokens=4000):
self.messages = []
self.max_tokens = max_tokens
def add_message(self, role, content):
self.messages.append({"role": role, "content": content})
self.trim_if_needed()
def trim_if_needed(self):
while self.count_tokens() > self.max_tokens:
# 保留系统消息和最近的消息
self.messages = self.messages[:1] + self.messages[-10:]
长期记忆(Long-term Memory)
跨会话的持久化记忆:
class LongTermMemory:
def __init__(self):
self.vector_db = VectorDatabase()
self.graph_db = GraphDatabase()
def store_interaction(self, interaction):
# 提取关键信息
entities = self.extract_entities(interaction)
facts = self.extract_facts(interaction)
preferences = self.extract_preferences(interaction)
# 存储到向量数据库(用于语义检索)
self.vector_db.insert(interaction)
# 存储到图数据库(用于关系推理)
for entity in entities:
self.graph_db.add_node(entity)
for fact in facts:
self.graph_db.add_edge(fact.subject, fact.predicate, fact.object)
def recall(self, query, context):
# 从向量数据库检索相关记忆
relevant_memories = self.vector_db.search(query)
# 从图数据库查询相关关系
related_entities = self.graph_db.query(context.entities)
return relevant_memories + related_entities
情景记忆(Episodic Memory)
记住具体的事件和经历:
class EpisodicMemory:
def store_episode(self, episode):
episode_data = {
"timestamp": datetime.now(),
"participants": episode.participants,
"location": episode.location,
"events": episode.events,
"emotions": episode.emotions,
"outcome": episode.outcome
}
self.episodes.append(episode_data)
def recall_similar_episodes(self, current_situation):
# 找到类似的历史情况
similar = []
for episode in self.episodes:
similarity = self.calculate_similarity(current_situation, episode)
if similarity > 0.7:
similar.append(episode)
return sorted(similar, key=lambda x: x.similarity, reverse=True)
3. 上下文压缩
当上下文太长时,需要压缩以适合模型的上下文窗口。
摘要压缩:
def summarize_context(self, context, max_length):
if len(context) <= max_length:
return context
# 使用 LLM 生成摘要
summary = self.llm.generate(f"""
请将以下内容压缩到 {max_length} 字符以内,保留关键信息:
{context}
""")
return summary
分层压缩:
def hierarchical_compression(self, context, max_length):
# 将上下文分为多个部分
sections = self.split_into_sections(context)
# 对每个部分生成摘要
section_summaries = [self.summarize(section) for section in sections]
# 如果还是太长,递归压缩
combined = "\n".join(section_summaries)
if len(combined) > max_length:
return self.hierarchical_compression(combined, max_length)
return combined
选择性保留:
def selective_retention(self, context, query):
# 评估每个部分与查询的相关性
relevance_scores = []
for section in context.sections:
score = self.calculate_relevance(section, query)
relevance_scores.append((section, score))
# 按相关性排序,保留最相关的部分
sorted_sections = sorted(relevance_scores, key=lambda x: x[1], reverse=True)
# 在长度限制内选择最相关的部分
selected = []
total_length = 0
for section, score in sorted_sections:
if total_length + len(section) <= self.max_length:
selected.append(section)
total_length += len(section)
return "\n".join(selected)
4. 上下文注入
在正确的时间注入正确的上下文。
动态上下文注入:
def inject_context(self, query, user):
context_parts = []
# 用户档案
context_parts.append(f"用户信息:{user.profile}")
# 当前项目
if user.current_project:
context_parts.append(f"当前项目:{user.current_project.summary}")
# 最近的活动
recent_activities = self.get_recent_activities(user)
context_parts.append(f"最近活动:{recent_activities}")
# 相关的知识库内容
relevant_knowledge = self.retrieve_knowledge(query)
context_parts.append(f"相关知识:{relevant_knowledge}")
# 组合上下文
full_context = "\n\n".join(context_parts)
return full_context + "\n\n用户查询:" + query
条件上下文注入:
def conditional_injection(self, query, user):
context = []
# 分析查询类型
query_type = self.classify_query(query)
if query_type == "technical":
# 注入技术文档
context.append(self.retrieve_technical_docs(query))
elif query_type == "business":
# 注入业务数据
context.append(self.retrieve_business_data(query))
elif query_type == "creative":
# 注入创意灵感
context.append(self.retrieve_creative_examples(query))
return context
实际应用案例
案例一:Notion AI 的上下文工程
Notion AI 在 2025 年实现了深度上下文感知:
工作空间上下文:
- 理解整个工作空间的结构
- 知道页面之间的关系
- 了解团队的工作流程
用户上下文:
- 记住用户的写作风格
- 了解用户的角色和职责
- 追踪用户的工作模式
任务上下文:
- 理解当前编辑的文档的目的
- 知道文档的受众
- 了解文档的历史版本
实际场景:
用户在写产品需求文档(PRD):
Notion AI 自动注入:
- 公司其他 PRD 的模板和格式
- 相关的产品文档和技术文档
- 用户过去写的 PRD 的风格
- 当前项目的背景信息
- 团队成员的反馈和讨论
结果:Notion AI 生成的 PRD 草稿不仅格式正确,还包含了相关的技术细节、用户故事和风险评估,节省了 80% 的写作时间。
案例二:Linear 的智能项目管理
Linear 在 2025 年推出了上下文感知的项目管理:
项目上下文:
- 项目的目标和里程碑
- 团队成员的技能和负载
- 历史项目的经验教训
任务上下文:
- 任务的依赖关系
- 相关的代码提交和 PR
- 客户反馈和支持票据
人员上下文:
- 每个人的专长和偏好
- 当前的工作负载
- 历史表现和效率
实际场景:
当创建新任务"实现用户认证功能"时:
Linear AI 自动:
- 识别这是一个后端任务,建议分配给后端专家 Alice
- 检查 Alice 的当前负载,发现她下周有空
- 找到类似的历史任务,估计需要 3 天
- 识别依赖关系:需要先完成数据库设计
- 关联相关的技术文档和 API 规范
- 建议检查清单:安全性、性能、可访问性
结果:任务分配更合理,时间估计更准确,遗漏更少。
案例三:Intercom 的个性化客服
Intercom 在 2025 年实现了超个性化的客户服务:
客户上下文:
- 客户的完整历史记录
- 产品使用情况
- 过去的支持票据
- 客户的沟通偏好
问题上下文:
- 问题的类型和严重程度
- 相关的知识库文章
- 类似问题的解决方案
- 当前的系统状态
代理上下文:
- 代理的专业领域
- 代理的当前负载
- 代理的历史表现
- 代理的沟通风格
实际场景:
客户报告"无法登录”:
Intercom AI 自动:
- 识别这是 VIP 客户,过去 6 个月有 3 次类似问题
- 检查系统状态,发现没有全局问题
- 查看客户的登录日志,发现是从新设备登录
- 检索知识库,找到新设备登录的解决方案
- 分配给专门处理 VIP 客户的代理 Bob
- 为 Bob 准备完整的客户档案和建议的解决方案
Bob 收到的不是"客户无法登录",而是:
“VIP 客户 John Smith 从新设备(iPhone 15)登录失败。他的账户正常,系统正常。这可能是新设备的 2FA 问题。建议:引导他重置 2FA,并提供备用登录方式。他过去对技术问题很耐心,喜欢详细的解释。”
结果:问题解决时间从平均 15 分钟缩短到 3 分钟,客户满意度 5/5。
上下文工程的最佳实践
1. 分层上下文管理
不要把所有上下文都塞进一个地方。分层管理:
- 系统级上下文(全局信息)
- 用户级上下文(个人信息)
- 会话级上下文(当前对话)
- 任务级上下文(具体任务)
2. 上下文新鲜度
确保上下文是最新的:
- 定期更新用户档案
- 实时同步业务数据
- 及时清理过时的信息
- 标记信息的时效性
3. 上下文相关性
不是所有上下文都有用。评估相关性:
- 使用相关性评分过滤
- 优先使用最近的上下文
- 考虑用户的当前目标
- 避免信息过载
4. 上下文隐私
保护敏感的上下文信息:
- 实施访问控制
- 加密敏感数据
- 遵守隐私法规
- 提供透明度
5. 上下文可解释性
让用户理解 AI 为什么使用某些上下文:
- 显示使用的上下文来源
- 解释上下文如何影响输出
- 允许用户编辑上下文
- 提供反馈机制
上下文工程的技术挑战
挑战一:上下文窗口限制
即使是最先进的 LLM,上下文窗口也是有限的(通常是 128K-1M tokens)。
解决方案:
- 智能压缩和摘要
- 分层上下文管理
- 动态上下文加载
- 上下文优先级排序
挑战二:上下文质量
不是所有上下文都是高质量的。可能包含:
- 过时的信息
- 矛盾的信息
- 不相关的信息
- 错误的信息
解决方案:
- 上下文验证和清理
- 冲突检测和解决
- 来源追踪和可信度评分
- 定期审计和更新
挑战三:上下文延迟
检索和注入上下文需要时间,可能影响响应速度。
解决方案:
- 预加载常用上下文
- 异步上下文检索
- 缓存频繁使用的上下文
- 渐进式上下文加载
挑战四:上下文隐私
上下文可能包含敏感信息,需要保护。
解决方案:
- 数据脱敏和匿名化
- 访问控制和权限管理
- 加密存储和传输
- 合规性审计
上下文工程的商业价值
1. 差异化竞争优势
在 AI 模型能力趋同的 2025 年,上下文工程成为关键的差异化因素:
- 同样的模型,不同的上下文 = 不同的体验
- 上下文是难以复制的竞争壁垒
- 用户愿意为更好的上下文付费
2. 用户粘性和留存
好的上下文工程创造强大的网络效应:
- 用户用得越多,上下文越丰富
- 上下文越丰富,体验越好
- 体验越好,用户越不愿意离开
3. 定价权
上下文丰富的产品可以收取更高的价格:
- 用户清楚地看到价值
- 转换成本高(需要重新积累上下文)
- ROI 更容易证明
4. 数据飞轮
上下文工程创造正向循环:
- 更多用户 → 更多上下文数据
- 更多上下文数据 → 更好的体验
- 更好的体验 → 更多用户
未来展望
趋势一:跨产品上下文
未来的 AI 将能够跨多个 SaaS 产品共享上下文:
- 你的 CRM 知道你的邮件历史
- 你的项目管理工具知道你的会议记录
- 你的文档工具知道你的代码提交
趋势二:预测性上下文
AI 将预测用户需要什么上下文:
- 在用户提问之前准备好相关信息
- 根据用户的行为模式预测需求
- 主动推送可能有用的上下文
趋势三:协作上下文
多个用户的上下文将被智能地组合和协调:
- 团队成员的上下文被整合
- 冲突的上下文被识别和解决
- 集体知识被有效利用
趋势四:上下文市场
将出现上下文的交易市场:
- 公司可以购买行业特定的上下文
- 用户可以出售自己的上下文(在保护隐私的前提下)
- 上下文成为新的资产类别
给 SaaS 公司的建议
1. 投资于上下文基础设施
上下文工程需要强大的技术基础:
- 向量数据库
- 图数据库
- 检索系统
- 记忆系统
2. 从用户旅程开始
理解用户在不同阶段需要什么上下文:
- 新手阶段:教育性上下文
- 成长阶段:效率性上下文
- 专家阶段:战略性上下文
3. 持续优化
上下文工程是一个持续优化的过程:
- 收集用户反馈
- A/B 测试不同的上下文策略
- 分析上下文使用模式
- 不断改进检索和注入算法
4. 保护用户隐私
上下文工程必须在保护隐私的前提下进行:
- 透明的数据使用政策
- 用户控制和选择权
- 严格的安全措施
- 合规性优先
结论
2025 年,上下文工程已经从"锦上添花"变成"核心竞争力"。在 AI 模型能力趋同的时代,上下文是创造差异化体验的关键。
成功的 SaaS 公司将是那些能够:
- 收集和管理高质量上下文的公司
- 在正确的时间注入正确上下文的公司
- 在保护隐私的前提下利用上下文的公司
- 持续优化上下文工程的公司
上下文不仅让 AI 更智能,还让 AI 更个性化、更有用、更有价值。这就是上下文工程的力量,也是 2025 年 SaaS 行业最重要的趋势之一。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。