导读：本文是“数据拾光者”专栏的第一百零五篇文章，这个系列将介绍在AI领域中的一些学习和思考，以及实战中的经验教训总结。本篇主要是分享大模型Agent上下文工程实战经验。

欢迎转载，转载请注明出处以及链接，更多关于自然语言处理、推荐系统优质内容请关注如下频道。
知乎专栏：数据拾光者
公众号：数据拾光者

继续上一篇《AI那些趣事系列104：大模型 Agent：从 “一问一答” 到 “自主办事”，上下文工程是关键》，本篇从实战的角度分享一些Agent上下文工程。在大模型 Agent 的体系里，上下文工程不是 “简单存对话”，而是一套 “让 Agent 能高效记忆、精准调用、动态更新信息” 的技术体系。它需要解决三个核心问题：该存什么信息、该怎么存、该怎么用。这篇文章会从技术逻辑出发，拆解上下文工程的实现步骤、核心组件和落地技巧，用通俗的语言和案例让你看懂 “智能记忆” 是如何炼成的。

一、先明确：上下文工程的实现目标

在动手实现前，要先清楚 “我们要达到什么效果”。上下文工程的核心目标，是让 Agent 具备三种能力：

• 短期关联能力：比如用户说 “帮我订明天去上海的票”，后续补充 “要靠窗的”，Agent 能关联 “上海” 和 “靠窗”，不用再问 “去哪个城市”；

• 长期复用能力：比如用户第一次用 Agent 时录入了身份证号，下次订车票时，Agent 能自动调取，不用重复输入；

• 动态调整能力：比如用户原本订 “明天 18 点的票”，后来改成 “19 点”，Agent 能实时更新上下文，不会按旧信息执行。

简单说，实现后的上下文工程，要像一个 “贴心的助理”—— 记得你说过的话、你的偏好，还能跟上你的需求变化。

二、上下文工程的实现框架：四大核心组件

无论是用 LangChain、LlamaIndex 这类开源框架，还是自研，上下文工程的实现都离不开四大核心组件。这四个组件就像 “仓库管理员”“整理员”“调取员”“质检员”，分工协作完成信息的全生命周期管理。

2.1 信息采集器 ——“该存什么，先搞清楚”

信息采集是上下文的 “源头”，核心是 “从多渠道收集有用的信息”，避免 “无目的存信息” 导致后续混乱。

2.1.1 采集的信息类型（必存 + 可选）

信息类别	具体内容示例	存不存？	作用
核心需求信息	用户的任务目标（订车票）、关键约束（明天、上海、二等座）	必存	决定 Agent 的行动方向，不能漏
环境反馈信息	工具返回结果（18 点的票已售罄）、实时数据（上海明天小雨）	必存	帮 Agent 判断 “下一步能不能做”
用户偏好信息	历史选择（每次都选靠窗）、习惯（不接受早于 8 点的车次）	必存（长期记忆）	提升体验，不用重复问
过程日志信息	Agent 的行动记录（已查询余票、已发送确认短信）	可选（按需存）	出问题时回溯原因（比如用户没收到票，查日志看是否发送成功）
无关闲聊信息	用户说 “今天天气真好”“中午吃了汉堡”	不存	占用空间，还会干扰 Agent 判断

2.1.2 采集的渠道

• 主动问询

  ：针对模糊需求，Agent 主动追问获取信息。比如用户说 “订车票”，采集器触发问询：“请问您要去哪个城市？出发时间是哪天？”

• 被动接收

  ：用户主动提供的信息，自动纳入采集范围。比如用户发 “明天 18 点，北京到上海，二等座”，采集器直接提取关键词。

• 工具拉取

  ：通过 API 调用外部工具，获取环境信息。比如采集器调用 12306 API 拉取余票数据，调用天气 API 拉取目的地天气。

• 历史调取

  ：从长期记忆库中调取用户过往信息。比如用户第一次订车票后，采集器把 “身份证号、偏好靠窗” 存到长期记忆，下次用的时候自动拉取。

案例：订车票的信息采集过程

1. 用户说 “帮我订明天去上海的票”→ 采集器识别 “核心需求：订车票；约束：明天、上海”，但缺少 “车次时间、座位类型”；

2. 采集器触发主动问询：“请问您偏好明天哪个时间段的车次？需要二等座还是一等座？”；

3. 用户回答 “18 点左右，二等座，要靠窗”→ 采集器补充 “时间段 18 点、座位类型二等座、偏好靠窗”；

4. 采集器调用 12306 API→ 拉取 “明天 18 点左右北京到上海的余票数据”（环境反馈信息）；

5. 采集器从长期记忆库调取→ “用户身份证号：11010XXXXXXX”（用户偏好信息）；

6. 所有信息汇总，进入下一个组件。

2.2 信息处理器 ——“存之前，先整理好”

采集到的信息往往是 “杂乱的原始数据”（比如用户的语音转文字、工具返回的 JSON 串），如果直接存，Agent 后续调取时会 “找不到重点”。信息处理器的作用，就是 “把乱数据变成结构化、精简的有用信息”，核心做三件事：清洗、结构化、压缩。

第一步：信息清洗 ——“去掉没用的”

• 去冗余

  ：删除重复信息。比如用户重复说了两次 “要靠窗”，清洗后只保留一条；

• 去噪声

  ：删除无关信息。比如用户说 “帮我订明天 18 点去上海的票，对了今天吃了汉堡”，清洗后删除 “今天吃了汉堡”；

• 去错误

  ：修正明显错误。比如用户说 “订明天 18 点去上每的票”（“每” 是错别字），清洗后修正为 “上海”。

第二步：信息结构化 ——“把信息分类放好”

杂乱的文字很难快速调用，结构化就是 “给信息贴标签、分字段”，常用的结构化格式有两种：

格式 1：键值对（适合简单信息）

jason格式 ：{ "任务类型": "订高铁票", "出发地": "北京", "目的地": "上海", "出发时间": "2024-05-22 18:00左右", "座位类型": "二等座", "座位偏好": "靠窗", "用户身份证号": "11010XXXXXXX", "余票情况": "G101（18:05）余票3张，G103（18:15）余票充足" }

格式 2：表格（适合多维度信息）

信息维度	具体值	信息来源	更新时间
任务目标	北京→上海高铁票	用户输入	2024-05-21 10:00
时间约束	2024-05-22 18:00 左右	用户输入	2024-05-21 10:05
座位信息	二等座，靠窗	用户输入	2024-05-21 10:05
余票数据	G101（3 张）、G103（充足）	12306 API	2024-05-21 10:08
用户身份	身份证号：11010XXXXXXX	长期记忆库	2024-05-21 10:00

结构化后，Agent 要查 “出发地” 时，直接调取 “出发地” 字段即可，不用从大段文字里找。

第三步：信息压缩 ——“把长信息变短”

如果采集到的信息很长（比如用户发了 500 字的旅行需求），需要压缩成 “关键要点”，避免占用过多上下文窗口。

压缩案例：

• 原始信息（用户输入）：“我想周末去上海玩，大概周六早上出发，周日晚上回来，想去外滩看夜景，还想尝尝生煎包，住宿的话希望离地铁站近一点，预算每晚 500 元以内，对了，我不喜欢太吵的酒店，最好有窗户。”

• 压缩后信息：json
  { "任务类型": "上海周末旅行规划", "时间": "周六早出发，周日晚返回", "景点": "外滩（看夜景）", "餐饮": "生煎包", "住宿需求": "近地铁站、500元/晚以内、安静、带窗户" }

压缩的关键是 “保留核心约束（时间、预算）和明确需求（景点、住宿偏好）”，去掉描述性的冗余文字。

2.3 信息存储器 ——“存哪里，怎么取”

处理好的信息，需要 “分场景存”—— 短期用的信息和长期用的信息，存储方式完全不同。信息存储器就像 “两个仓库”：短期仓库（上下文窗口）存临时信息，长期仓库（外部数据库）存复用信息，两者协同工作。

2.3.1 短期仓库：上下文窗口（临时存放）

• 作用

  ：存放当前任务的 “临时信息”，任务结束后可删除或归档。比如订车票任务中的 “余票情况、用户本次的时间偏好”。

• 存储介质

  ：大模型自带的上下文窗口（比如 GPT-4 的 128k tokens 窗口）。

• 关键技术

  ：上下文截断与优先级排序。

• • 当信息快装满窗口时，自动删除 “优先级低” 的信息（比如任务早期的问询记录），保留 “优先级高” 的信息（比如用户最终需求、工具最新反馈）；

  • 示例：订车票任务快结束时，窗口里只保留 “最终订单信息（G103，18:15，靠窗）、用户身份证号、支付状态”，删除早期的 “余票查询记录、用户犹豫选 18 点还是 19 点的对话”。

2.3.2 长期仓库：外部数据库（永久 / 长期存放）

• 作用

  ：存放 “长期复用的信息”，比如用户的身份证号、偏好（每次都选靠窗）、常用地址（家、公司）。

• 常用存储介质

  ：

• • 关系型数据库（MySQL、PostgreSQL）：适合存结构化的用户信息（比如身份证号、手机号）；

  • 向量数据库（Pinecone、Milvus）：适合存 “非结构化但需要语义检索的信息”（比如用户过往的旅行偏好描述、历史对话总结）；

  • 文档数据库（MongoDB）：适合存半结构化信息（比如用户的多轮对话记录）。

2.3.3 两仓库协同逻辑：“需要时，自动调”

• 当 Agent 处理新任务时，先从 “长期仓库” 调取用户的长期信息（比如身份证号、偏好），加入 “短期仓库”；

• 任务过程中，新产生的临时信息（比如本次的余票数据）只存在 “短期仓库”；

• 任务结束后，判断是否有 “新的长期信息”（比如用户这次新增了 “不接受早于 8 点的车次” 的偏好），如果有，同步到 “长期仓库”；

• 示例：用户第一次订车票时，长期仓库没有信息，短期仓库存 “本次需求 + 余票数据”；任务结束后，把 “身份证号、偏好靠窗” 同步到长期仓库；下次订车票时，Agent 先从长期仓库调取 “身份证号、偏好靠窗”，再结合本次的 “时间、目的地”，组成新的短期上下文。

2.4 信息调用器 ——“用的时候，精准拿”

存好的信息，最终要 “在需要的时候精准调用”—— 比如 Agent 要生成订单时，需要调用 “用户身份证号、车次信息”；要推荐酒店时，需要调用 “用户住宿预算、偏好（安静、近地铁）”。信息调用器的核心是 “按需调取”，关键技术是检索与关联。

1. 两种核心检索方式

方式 1：关键词检索（适合结构化信息）

• 原理：根据 “关键词” 从仓库里找对应的字段。比如 Agent 要生成订单，需要 “身份证号”，调用器直接从长期仓库的 “用户信息表” 中，按 “用户 ID” 检索出 “身份证号” 字段。

• 场景：调取明确的结构化信息（身份证号、手机号、座位类型）。

方式 2：语义检索（适合非结构化信息）

• 原理：不依赖精确关键词，而是根据 “语义相似性” 找信息。比如用户说 “帮我订和上次一样的票”，调用器通过向量数据库检索 “上次订票的语义描述（北京→上海，18 点左右，二等座靠窗）”，自动提取关键信息。

• 关键技术：向量嵌入（Embedding）。把文字信息转换成 “向量”（一串数字），通过计算向量相似度，找到最匹配的信息。比如 “上次订的晚上去上海的二等座” 和 “帮我订和上次一样的票” 的向量相似度很高，调用器就能关联到上次的信息。

2. 调用触发逻辑：“什么时候，自动调”

• 任务启动时触发

  ：调用长期仓库的用户基础信息（身份证号、偏好）；

• 执行步骤时触发

  ：比如执行 “生成订单” 步骤时，触发调用 “用户身份证号、车次信息、座位偏好”；

• 需求变化时触发

  ：比如用户说 “改成 19 点的票”，触发调用 “19 点左右的余票数据”（从工具拉取，存入短期仓库后调用）；

• 出现疑问时触发

  ：比如 Agent 不确定用户偏好，触发调用 “长期仓库的历史偏好记录”（比如 “根据你之前的选择，你通常选靠窗座位，这次是否继续？”）。

案例：信息调用的完整流程

用户说 “帮我订明天去上海的票”→ Agent 启动任务：

1. 调用器触发 “长期仓库检索”→ 调取 “用户身份证号：11010XXXXXXX，偏好：靠窗”；

2. 调用器把这些信息加入 “短期仓库”，结合用户本次的 “目的地上海、时间明天”，组成初始上下文；

3. Agent 发现缺少 “具体时间”，主动问询 “请问偏好明天哪个时间段？”→ 用户回答 “19 点左右”；

4. 调用器触发 “工具调用”→ 拉取 “明天 19 点左右北京→上海的余票数据”（G105，19:05，余票 5 张），存入短期仓库；

5. Agent 执行 “生成订单” 步骤→ 调用器从短期仓库调取 “用户身份证号、车次 G105、时间 19:05、偏好靠窗”，生成订单；

6. 订单完成后，调用器判断是否有新长期信息→ 本次没有新增偏好，不更新长期仓库。

三、落地实战：用 LangChain 实现一个简单的上下文工程

前面讲了理论框架，现在用最流行的开源框架 LangChain，手把手教你实现一个 “订车票 Agent 的上下文工程”（基于 Python），让你直观感受四大组件的工作过程。

前置准备

1. 1. 安装依赖：

pip install langchain openai python-dotenv（用 OpenAI 的 GPT-3.5/4 作为大模型，也可以替换成国产模型如文心一言）；

2. 准备 OpenAI API 密钥（或其他模型密钥）。

步骤 1：实现 “信息采集器”—— 主动问询 + 工具拉取

from langchain.chat_models import ChatOpenAIfrom langchain.prompts import ChatPromptTemplatefrom langchain.chains import LLMChainfrom dotenv import load_dotenvimport os# 加载API密钥load_dotenv()openai_api_key = os.getenv("OPENAI_API_KEY")# 初始化大模型llm = ChatOpenAI(model_name="gpt-3.5-turbo", api_key=openai_api_key)# 1. 主动问询：获取用户核心需求prompt_ask = ChatPromptTemplate.from_messages([    ("system", "你是一个订车票的助手，需要获取用户的出发地、目的地、出发时间、座位类型（二等座/一等座）、座位偏好（靠窗/过道）。如果用户没说全，只问缺失的信息，不要多问。"),    ("human", "{user_input}")])ask_chain = LLMChain(llm=llm, prompt=prompt_ask)# 模拟用户输入（第一次输入不完整）user_input1 = "帮我订明天去上海的票"ask_result1 = ask_chain.run(user_input=user_input1)print("Agent问询：", ask_result1)  # 输出：请问你的出发地是哪里？需要二等座还是一等座？座位偏好靠窗还是过道？# 模拟用户补充输入user_input2 = "出发地是北京，二等座，靠窗"ask_result2 = ask_chain.run(user_input=user_input2)print("Agent确认需求：", ask_result2)  # 输出：已确认你的需求：出发地北京，目的地上海，出发时间明天，座位类型二等座，座位偏好靠窗。# 2. 工具拉取（模拟调用12306 API获取余票）def mock_12306_api(departure, destination, date):    # 模拟返回余票数据    return {        "departure": departure,        "destination": destination,        "date": date,        "trains": [            {"train_no": "G101", "time": "18:05", "seats": "3张", "seat_type": "二等座"},            {"train_no": "G103", "time": "18:15", "seats": "充足", "seat_type": "二等座"}        ]    }ticket_data = mock_12306_api(departure="北京", destination="上海", date="2024-05-22")print("工具拉取的余票数据：", ticket_data)

步骤 2：实现 “信息处理器”—— 清洗、结构化、压缩

# 1. 信息清洗：这里用户输入没有冗余和错误，主要是提取关键信息def clean_information(user_input_series, ticket_data):    # 从两次用户输入中提取关键信息    user_info = {        "departure": "北京",        "destination": "上海",        "date": "2024-05-22",        "seat_type": "二等座",        "seat_preference": "靠窗"    }    # 合并余票数据，去除无用字段（比如seat_type重复，已在user_info里）    ticket_info = {        "trains": [            {"train_no": train["train_no"], "time": train["time"], "seats": train["seats"]}            for train in ticket_data["trains"]        ]    }    return user_info, ticket_info# 2. 信息结构化：组合成键值对格式user_info, ticket_info = clean_information([user_input1, user_input2], ticket_data)structured_context = {    "task_type": "订高铁票",    "user_info": user_info,    "ticket_info": ticket_info,    "status": "待确认车次"}print("结构化后的上下文：", structured_context)# 3. 信息压缩：如果有长文本，这里模拟压缩（比如用户输入很长时）def compress_context(context):    # 把结构化上下文压缩成简洁描述    user_desc = f"{context['user_info']['departure']}→{context['user_info']['destination']}，{context['user_info']['date']}，{context['user_info']['seat_type']}（{context['user_info']['seat_preference']}）"    ticket_desc = "；".join([f"{t['train_no']}（{t['time']}，余票{t['seats']}）" for t in context['ticket_info']['trains']])    return f"任务：{context['task_type']}；用户需求：{user_desc}；余票：{ticket_desc}；状态：{context['status']}"compressed_context = compress_context(structured_context)print("压缩后的上下文：", compressed_context)# 输出：任务：订高铁票；用户需求：北京→上海，2024-05-22，二等座（靠窗）；余票：G101（18:05，余票3张）；G103（18:15，余票充足）；状态：待确认车次

步骤 3：实现 “信息存储器”—— 短期窗口 + 长期数据库（用 MongoDB 示例）

# 1. 短期存储：模拟上下文窗口（用列表模拟，限制最大长度）class ShortTermMemory:    def __init__(self, max_length=5):        self.memory = []        self.max_length = max_length    def add(self, info):        # 加入新信息        self.memory.append(info)        # 如果超过最大长度，删除最早的信息        if len(self.memory) > self.max_length:            self.memory.pop(0)    def get(self):        return self.memory# 初始化短期记忆，加入结构化上下文short_term_memory = ShortTermMemory()short_term_memory.add(structured_context)print("短期记忆内容：", short_term_memory.get())# 2. 长期存储：用MongoDB存储用户长期信息（需要先安装pymongo：pip install pymongo）from pymongo import MongoClientclass LongTermMemory:    def __init__(self, db_name="agent_memory", collection_name="user_preferences"):        self.client = MongoClient("mongodb://localhost:27017/")  # 本地MongoDB        self.db = self.client[db_name]        self.collection = self.db[collection_name]    def save_user_preference(self, user_id, preference):        # 保存或更新用户偏好（user_id是用户唯一标识，比如手机号）        self.collection.update_one(            {"user_id": user_id},            {"$set": preference},            upsert=True  # 不存在则插入，存在则更新        )    def get_user_preference(self, user_id):        # 获取用户偏好        return self.collection.find_one({"user_id": user_id}, {"_id": 0})  # 不返回MongoDB的默认ID# 初始化长期记忆，保存用户偏好long_term_memory = LongTermMemory()user_id = "13800138000"  # 模拟用户手机号（唯一标识）user_preference = {    "user_id": user_id,    "id_card": "11010XXXXXXX",  # 模拟身份证号    "seat_preference": "靠窗",    "usual_departure": "北京"  # 常用出发地}long_term_memory.save_user_preference(user_id, user_preference)# 调取用户长期偏好，加入短期记忆retrieved_preference = long_term_memory.get_user_preference(user_id)structured_context["user_long_term_info"] = retrieved_preferenceshort_term_memory.add(structured_context)  # 更新短期记忆print("加入长期信息后的短期记忆：", short_term_memory.get())

步骤 4：实现 “信息调用器”—— 关键词检索 + 语义检索

# 1. 关键词检索：从短期记忆中按关键词找信息def keyword_retrieval(short_memory, keyword):    # 遍历短期记忆中的所有上下文，找包含关键词的信息    results = []    for context in short_memory.get():        # 递归遍历字典，找包含关键词的字段        def search_dict(d, k):            for key, value in d.items():                if k in str(key) or k in str(value):                    results.append({key: value})                if isinstance(value, dict):                    search_dict(value, k)                elif isinstance(value, list):                    for item in value:                        if isinstance(item, dict):                            search_dict(item, k)        search_dict(context, keyword)    return results# 调用关键词检索：找“车次信息”train_info = keyword_retrieval(short_term_memory, "train_no")print("关键词检索（车次信息）：", train_info)# 输出：[{"train_no": "G101"}, {"train_no": "G103"}]# 2. 语义检索：用LangChain的向量检索实现（模拟用户说“帮我订和上次一样的”）from langchain.embeddings.openai import OpenAIEmbeddingsfrom langchain.vectorstores import FAISSfrom langchain.text_splitter import CharacterTextSplitter# 初始化向量存储（模拟长期记忆中的用户历史偏好文本）user_history_texts = [    "用户上次订的是北京到上海的高铁票，18点左右的车次，二等座靠窗，身份证号11010XXXXXXX",    "用户常用出发地是北京，不喜欢早于8点的车次"]# 生成文本嵌入，存入FAISS向量库embeddings = OpenAIEmbeddings(openai_api_key=openai_api_key)text_splitter = CharacterTextSplitter(chunk_size=100, chunk_overlap=0)docs = text_splitter.create_documents(user_history_texts)db = FAISS.from_documents(docs, embeddings)# 语义检索：用户查询“帮我订和上次一样的票”query = "帮我订和上次一样的票"docs = db.similarity_search(query)print("语义检索结果（用户历史偏好）：", docs[0].page_content)# 输出：用户上次订的是北京到上海的高铁票，18点左右的车次，二等座靠窗，身份证号11010XXXXXXX# 基于检索结果，生成本次的上下文retrieved_history = docs[0].page_content# 提取历史信息中的关键内容，加入本次上下文structured_context["retrieved_history"] = retrieved_historyshort_term_memory.add(structured_context)print("加入语义检索结果后的短期记忆：", short_term_memory.get())

四、落地中的关键问题与解决方案

在实际实现上下文工程时，很容易遇到 “窗口不够用”“检索不准”“信息同步延迟” 等问题，这里给出最常见问题的解决方案：

问题 1：上下文窗口容量不足（信息装不下）

• 解决方案：

优先级截断：按 “信息重要性” 排序，删除低优先级信息（比如早期问询记录、过时的工具反馈）；

1. 上下文总结：定期对短期上下文做 “总结”，用总结文本代替原始多轮对话（比如把 10 轮对话总结成 1 段核心需求）；

2. 外部挂载：把不常用的临时信息（比如历史余票查询记录）存到外部缓存（Redis），需要时再调取，不占用窗口空间。

问题 2：语义检索不准确（找不到想要的信息）

• 解决方案：

1. 优化嵌入模型：选择更适合中文的嵌入模型（比如百度文心一言的嵌入模型、阿里通义千问的嵌入模型），比 OpenAI 的嵌入模型在中文语义理解上更准；

2. 文本预处理：对要嵌入的文本做 “关键词强化”（比如在用户偏好文本里加入 “偏好：”“常用：” 等标签），提升检索时的匹配度；

3. 多轮检索：第一次检索结果不准时，基于第一次结果调整查询词（比如用户说 “订晚上的票”，第一次没找到，调整为 “订 18 点以后的票” 再检索）。

问题 3：长期与短期仓库信息不同步（比如用户改了偏好，长期仓库没更新）

• 解决方案：

1. 任务结束时强制同步：每次任务完成后，自动检查 “本次是否有新的长期信息”（比如用户新增了 “不接受靠窗” 的偏好），如果有，立即同步到长期仓库；

2. 定期校验：每隔一段时间（比如每周），Agent 主动问询用户 “你的偏好（如座位、常用地址）是否有变化？”，更新长期仓库；

3. 版本控制：给长期仓库的信息加 “版本号和更新时间”，调用时优先用 “最新版本” 的信息，避免用旧信息。

问题 4：用户隐私信息泄露（比如身份证号被恶意调取）

• 解决方案：

1. 数据加密：长期仓库中存储的敏感信息（身份证号、手机号）必须加密（比如用 AES 加密算法），调取时再解密；

2. 权限控制：给信息调用设置 “权限门槛”，比如只有 “生成订单” 步骤能调用身份证号，其他步骤（如余票查询）不能调用；

3. 日志审计：记录所有 “敏感信息的调用记录”（谁调用、什么时候调用、用在什么地方），方便后续追溯。

五、总结：上下文工程的实现本质

从技术拆解来看，上下文工程的实现本质是 “信息的全生命周期管理”—— 从 “采集（源头）” 到 “处理（整理）”，再到 “存储（仓库）”，最后到 “调用（使用）”，每个环节都围绕 “让 Agent 更高效、更精准地利用信息” 展开。

对于开发者来说，落地上下文工程不需要 “从零造轮子”：

• 用 LangChain、LlamaIndex 等框架的现成组件（如 LangChain 的 Memory 模块、LlamaIndex 的检索模块），可以快速搭建基础框架；

• 重点关注 “业务场景适配”—— 比如订车票场景要优先保证 “用户身份信息、车次信息” 的准确存储与调用，而旅行规划场景要优先保证 “用户偏好、景点信息” 的语义检索准确性。

未来，随着大模型上下文窗口的扩大（比如 GPT-5 可能支持更大的窗口）和向量数据库技术的发展，上下文工程会变得更 “智能”—— 比如 Agent 能自动理解 “用户没说出口的隐含需求”（比如用户订去上海的票，自动联想到 “上海最近有展会，是否需要推荐附近酒店”），但核心逻辑依然是 “采集→处理→存储→调用” 的闭环。

掌握这个闭环，你就能搭建出 “真正懂用户” 的 Agent 上下文系统。

最新最全的文章请关注我的微信公众号或者知乎专栏：数据拾光者。

码字不易，欢迎小伙伴们关注和分享。