提升智能体理解能力的10个上下文工程架构技巧——Agentic AI架构师必看的底层逻辑与实战指南

引言：为什么上下文工程是智能体理解能力的“骨架”？

你有没有遇到过这样的智能体？
用户说：“帮我订明天下午3点从北京到上海的高铁，要靠窗，并且提醒我带身份证”，它却回复：“上海明天的天气是多云转晴”——这不是AI“笨”，而是它没看懂上下文里的“需求链”：

• 主任务是“订高铁”（动作）；
• 附加条件是“靠窗”（偏好）；
• 关联任务是“提醒带身份证”（依赖）。

智能体的“理解能力”，本质是对上下文的“高效编码、精准检索、合理推理”能力。而“上下文工程”，就是为智能体搭建一套“能听懂、能记住、能联想”的信息处理骨架——它决定了智能体是“机械回应字面意思”，还是“理解深层意图”。

作为Agentic AI架构师，你可能已经试过加“聊天历史”“关键词提取”，但依然解决不了上下文过载、意图偏差、关联缺失等问题。这篇文章会拆解10个架构级的上下文工程技巧，从“底层逻辑”到“实战落地”，帮你彻底解决智能体“听不懂、记不住、想错了”的核心痛点。

读完这篇文章，你会掌握：

1. 如何用“分层总线”解决上下文过载；
2. 如何让智能体精准抓住用户的“核心意图”；
3. 如何让上下文“动态更新”而不过期；
4. 如何融合多模态信息（文本+图像+语音）；
5. 如何让智能体“主动关联”任务依赖（比如订高铁→提醒带身份证）；
   …

接下来，我们从“上下文工程的底层逻辑”讲起。

一、先搞懂：上下文工程的底层逻辑是什么？

在讲技巧之前，必须先明确两个关键问题——什么是智能体的“上下文”？“上下文工程”要解决什么问题？

1.1 智能体的“上下文”不是“聊天记录”——而是四维信息网络

很多人误以为“上下文=用户的历史输入”，这是对“上下文”的最大误解。智能体的上下文是一个四维信息网络：

维度	定义	示例
用户层	用户的长期意图、偏好、历史行为	“用户喜欢拿铁不加糖”“用户去年订过3次高铁”
任务层	当前任务的目标、子任务依赖、进度状态	“当前任务是订高铁，已选车次G101”
环境层	实时的环境状态（时间、地点、设备）	“当前时间是2024-05-20 14:00”“用户在手机端”
领域层	行业知识、规则、实时数据	“高铁靠窗座位是A/F座”“上海明天的天气”

比如用户说“帮我订明天去上海的高铁”，智能体需要整合：

• 用户层：“用户喜欢靠窗”；
• 任务层：“当前任务是订高铁”；
• 环境层：“明天是周五，高铁票可能紧张”；
• 领域层：“G101次高铁还有靠窗座位”。

只有整合这四个维度，智能体才能给出精准回复：“已帮您锁定明天G101次高铁的靠窗座位（A座），需要确认预订吗？”

1.2 上下文工程的四大目标：获取→编码→检索→推理

上下文工程的核心是解决四个问题：

1. 获取（不遗漏）：能否收集到所有相关的上下文信息？（比如用户发了一张高铁票截图，智能体能不能识别出票上的时间？）
2. 编码（不混淆）：能否把不同维度的信息转换成统一的、可处理的格式？（比如把“用户喜欢靠窗”和“G101有靠窗座”编码成向量，让智能体能关联起来？）
3. 检索（不延迟）：能否快速找到当前任务需要的上下文？（比如用户问“我的高铁票是几点”，智能体能不能100ms内从历史任务中检索到车次时间？）
4. 推理（不偏差）：能否根据上下文做出正确的逻辑推理？（比如用户订了高铁，智能体能不能推理出“需要提醒带身份证”？）

接下来的10个技巧，都是围绕这四个目标设计的。

二、提升智能体理解能力的10个上下文工程架构技巧

每个技巧都会包含：问题场景（你可能遇到的痛点）、底层原理（为什么有效）、架构设计（怎么落地）、实战案例（具体应用）。

技巧1：分层上下文总线——解决“上下文过载”的架构级方案

问题场景

你有没有遇到过：智能体处理长对话时，把一个月前的闲聊内容当作“上下文”，导致回复偏差？比如用户现在问“我的高铁票几点”，智能体却回复“上次你说喜欢吃火锅”——这是因为所有上下文混在一起，没有分层管理。

底层原理

计算机的“总线架构”启发了这个技巧：把不同类型的上下文分到不同的“层”，用“总线”统一管理，按需调用。这样既能避免“无关信息干扰”，又能保证“关键信息不遗漏”。

架构设计

分层上下文总线的核心是**“四层三组件”**：

1. 四层（对应上文的四维信息网络）：

   • 用户层：存储用户的长期偏好（比如“喜欢靠窗”“咖啡不加糖”），用向量数据库（比如Pinecone）存储，因为向量能捕捉“偏好的相似度”（比如“喜欢靠窗”≈“喜欢安静”）。
   • 任务层：存储当前任务的动态信息（比如“已订G101次高铁”“子任务是提醒带身份证”），用临时缓存（比如Redis）存储，任务结束后自动清空。
   • 环境层：存储实时环境状态（比如“当前时间”“用户位置”），用事件驱动框架（比如Kafka）更新，比如用户位置变化时，自动触发环境层更新。
   • 领域层：存储行业知识和实时数据（比如“高铁座位规则”“天气”），用知识图谱（比如Neo4j）或**检索增强（RAG）**获取实时数据。

2. 三组件：

   • 编码器：每个层有独立的编码器（比如用户层用BERT编码偏好，任务层用GPT-3编码任务描述），把非结构化信息转换成向量。
   • 总线控制器：负责接收“当前任务请求”，从四层中“按需拉取”上下文（比如处理“订高铁”任务时，拉取用户层的“靠窗偏好”、任务层的“当前车次”、领域层的“座位规则”）。
   • 融合器：用注意力机制（Attention）把拉取的上下文融合成“任务相关的上下文向量”，比如“用户喜欢靠窗 + 当前车次G101 + G101有靠窗座”融合后，智能体就知道要推荐靠窗座。

实战案例：酒店预订智能体

用户说：“帮我订下周三上海外滩附近的酒店，要无烟房，高层。”

• 总线控制器收到任务后，拉取：
  • 用户层：“用户历史预订过3次无烟房”（向量数据库）；
  • 任务层：“当前任务是订酒店，目标是上海外滩”（Redis）；
  • 领域层：“上海外滩附近的酒店有5家，其中3家有高层无烟房”（知识图谱+RAG）；
• 融合器用注意力机制把这些信息融合，智能体回复：“已为您筛选出上海外滩附近的3家高层无烟房酒店，其中‘外滩华尔道夫’评分最高，需要帮您预订吗？”

技巧2：意图锚点式提取——让智能体精准抓住“用户到底要什么”

问题场景

用户说：“明天要去上海开会，帮我订高铁，要靠窗，顺便提醒我带笔记本电脑。” 智能体却回复：“上海的会议场地推荐……”——这是因为智能体没抓住“主意图”（订高铁）和“关联意图”（提醒带电脑）。

底层原理

“意图锚点”是用户输入中的关键元素：动词（订、提醒）、名词（高铁、笔记本电脑）、限定词（明天、靠窗）。这些锚点是“意图的骨架”，只要抓住它们，就能还原用户的真实需求。

架构设计

意图锚点式提取的核心是**“NER+意图树”**：

1. NER（命名实体识别）：用预训练模型（比如SpaCy、BERT-NER）提取输入中的实体（比如“明天”“上海”“高铁”“靠窗”“笔记本电脑”）。
2. 意图分类：用意图分类模型（比如TextCNN、GPT-3）识别用户的“主意图”（订高铁）和“关联意图”（提醒带电脑）。
3. 意图树构建：把“意图锚点”和“意图类型”关联成树结构，比如：
   • 主意图：订高铁 → 锚点：明天、上海、靠窗；
   • 关联意图：提醒带电脑 → 锚点：笔记本电脑。

实战案例：出行智能体

用户输入：“明天要去上海开会，帮我订高铁，要靠窗，顺便提醒我带笔记本电脑。”

• NER提取：“明天”（时间）、“上海”（地点）、“高铁”（交通工具）、“靠窗”（偏好）、“笔记本电脑”（物品）；
• 意图分类：主意图是“订高铁”，关联意图是“提醒带物品”；
• 意图树：订高铁（明天、上海、靠窗）→ 提醒带物品（笔记本电脑）；
• 智能体回复：“已帮您订明天G101次高铁的靠窗座位（A座），并添加‘提醒带笔记本电脑’的任务，需要确认吗？”

技巧3：动态上下文窗口——解决“上下文过期”的时间管理方案

问题场景

用户周一说：“项目deadline是下周五。” 周三说：“把需求文档改一下。” 周五问：“deadline能延期吗？” 智能体却回复：“周三的需求文档已经改好了”——这是因为智能体保留了“过期的上下文”（改需求文档），而忽略了“关键的长期上下文”（deadline）。

底层原理

上下文是“有生命周期的”：

• 短期上下文（比如“改需求文档”）：任务完成后就过期；
• 长期上下文（比如“项目deadline”）：整个任务周期内都有效。

动态上下文窗口的核心是**“时间衰减+任务相关性”**：给每个上下文打“ relevance score（相关性分数）”，分数低于阈值的自动移除。

架构设计

动态上下文窗口的核心是**“分数计算+窗口调整”**：

1. 分数计算：用两个维度计算上下文的相关性：

   • 时间衰减：用指数衰减函数计算，比如score = initial_score * e^(-λ*t)，其中λ是衰减系数（比如0.1），t是时间差（比如从周一到周五是4天）。
   • 任务相关性：用“意图相似度”计算，比如当前任务是“延期deadline”，则“项目deadline是下周五”的相关性是1.0，“改需求文档”的相关性是0.2。

2. 窗口调整：

   • 每个任务有一个“窗口大小”（比如长任务的窗口是10条，短任务的窗口是5条）；
   • 定期筛选“分数≥阈值”的上下文，保留在窗口中；
   • 新的上下文加入时，自动移除分数最低的旧上下文。

实战案例：项目管理智能体

用户对话历史：

• 周一：“项目deadline是下周五。”（initial_score=1.0，t=0）
• 周三：“把需求文档改一下。”（initial_score=0.8，t=2）
• 周五：“deadline能延期吗？”（当前任务）

分数计算：

• “项目deadline是下周五”：1.0 * e^(-0.1*4) ≈ 0.67，任务相关性=1.0 → 总分数=0.67；
• “把需求文档改一下”：0.8 * e^(-0.1*2) ≈ 0.66，任务相关性=0.2 → 总分数=0.13；

窗口调整：保留“项目deadline是下周五”，移除“改需求文档”；
智能体回复：“之前的deadline是下周五，需要延期到什么时候？”

技巧4：多模态上下文融合——解决“单一模态信息缺失”的跨模态方案

问题场景

用户发了一张“北京南站的照片”+ 文本“我现在在这里，要去上海，接下来怎么做？” 智能体却回复：“北京南站的地址是……”——这是因为智能体只处理了文本，没处理图像中的“位置信息”。

底层原理

人类的沟通是多模态的（比如说话+手势+表情），智能体要理解人类，必须能融合文本、图像、语音等多模态信息。多模态融合的核心是“把不同模态的信息映射到同一向量空间”，让智能体能“看懂”图像中的位置、语音中的情绪。

架构设计

多模态上下文融合的核心是**“多模态编码器+跨模态注意力”**：

1. 多模态编码器：用预训练模型把不同模态的信息编码成向量：

   • 文本：用BERT、GPT-3编码；
   • 图像：用CLIP、ResNet编码（CLIP能把图像和文本映射到同一空间）；
   • 语音：用Wav2Vec、Hubert编码（提取语音中的语义和情绪）。

2. 跨模态注意力：用注意力机制学习“不同模态信息的关联”，比如：

   • 图像中的“北京南站” → 文本中的“要去上海” → 关联“需要查北京南站到上海的高铁”；
   • 语音中的“着急”情绪 → 文本中的“接下来怎么做” → 关联“需要快速推荐路线”。

实战案例：出行引导智能体

用户输入：一张“北京南站的照片”+ 文本“我现在在这里，要去上海，接下来怎么做？”

• 图像编码：用CLIP编码图像，得到向量“北京南站”；
• 文本编码：用BERT编码文本，得到向量“要去上海，接下来怎么做”；
• 跨模态注意力：学习到“北京南站”→“要去上海”→“需要查高铁”的关联；
• 智能体回复：“您现在在北京南站，去上海的高铁在3号候车厅，最近一班是15:30的G101次，需要帮您导航到候车厅吗？”

技巧5：上下文依赖图谱——解决“任务关联缺失”的知识推理方案

问题场景

用户说：“帮我订明天去上海的高铁。” 智能体回复：“已订G101次高铁。” 但没提醒“带身份证”“查天气”——这是因为智能体没“联想”到订高铁的“依赖任务”。

底层原理

人类做决策时，会“自动联想”相关的事情（比如订高铁→带身份证→查天气→叫车去车站）。智能体要做到这一点，需要用知识图谱存储“任务依赖关系”，然后用图神经网络（GNN）推理关联任务。

架构设计

上下文依赖图谱的核心是**“知识图谱+GNN推理”**：

1. 知识图谱构建：

   • 实体：任务（订高铁）、物品（身份证）、服务（查天气）、地点（车站）；
   • 关系：“订高铁需要带身份证”“订高铁后需要查天气”“订高铁需要叫车去车站”。

2. GNN推理：

   • 当智能体接收到“订高铁”任务时，用GNN遍历知识图谱，找到所有关联的实体（身份证、天气、叫车）；
   • 把这些关联实体作为“上下文”加入任务处理流程。

实战案例：出行助手智能体

用户说：“帮我订明天去上海的高铁。”

• 知识图谱：“订高铁”→“需要带身份证”→“需要查天气”→“需要叫车去车站”；
• GNN推理：找到这三个关联任务；
• 智能体回复：“已帮您订明天G101次高铁，提醒您带身份证，上海明天多云，需要帮您叫车去车站吗？”

技巧6：用户画像驱动的上下文个性化——解决“千人一面”的精准理解方案

问题场景

白领用户说：“帮我订下午的咖啡。” 智能体回复：“请问您要什么口味？” 但其实白领用户“喜欢拿铁不加糖”——这是因为智能体没“记住”用户的长期偏好。

底层原理

每个人的需求都是“个性化”的，智能体要“懂”用户，必须用用户画像驱动上下文理解。用户画像包括“长期特征”（年龄、职业、偏好）和“短期特征”（最近的行为，比如“最近一周订了3次拿铁”）。

架构设计

用户画像驱动的上下文个性化的核心是**“画像数据库+个性化编码器”**：

1. 用户画像数据库：

   • 长期特征：存储在关系型数据库（比如MySQL），比如“用户年龄30，职业白领，喜欢拿铁不加糖”；
   • 短期特征：存储在缓存（比如Redis），比如“最近一周订了3次拿铁”。

2. 个性化编码器：

   • 把用户画像（长期+短期）编码成“用户向量”；
   • 把用户向量和当前上下文向量（比如“订下午的咖啡”）融合，得到“个性化上下文向量”。

实战案例：咖啡预订智能体

• 白领用户说：“帮我订下午的咖啡。”

  • 用户画像：长期特征“喜欢拿铁不加糖”，短期特征“最近一周订了3次拿铁”；
  • 个性化编码器融合：“订下午的咖啡”+“喜欢拿铁不加糖”→ 个性化上下文；
  • 智能体回复：“已帮您订下午2点的拿铁不加糖，送到您的办公室。”

• 学生用户说：“帮我订下午的咖啡。”

  • 用户画像：长期特征“喜欢美式加冰”，短期特征“最近一周订了2次美式”；
  • 智能体回复：“已帮您订下午3点的美式加冰，送到图书馆。”

技巧7：上下文纠错机制——解决“理解偏差”的容错方案

问题场景

用户打错字：“帮我订明天的高贴。” 智能体回复：“请问您要订什么高贴？”——这是因为智能体没“纠正”输入中的错误。

底层原理

人类沟通中会有“口误”“笔误”，智能体要“容错”，必须在上下文处理的各个环节加入纠错：输入纠错、意图纠错、推理纠错。

架构设计

上下文纠错机制的核心是**“三级纠错模块”**：

1. 输入纠错：用预训练的纠错模型（比如BERT-based纠错、ERNIE-CSC）纠正输入中的错别字、语法错误，比如“高贴”→“高铁”。
2. 意图纠错：用“多轮确认”纠正意图误解，比如用户说“我想取消订单”，智能体反问：“是取消明天去上海的高铁订单吗？”
3. 推理纠错：用“规则引擎+大模型推理”纠正逻辑错误，比如“订高铁需要带身份证”→ 智能体不会推荐“不带身份证的方法”。

实战案例：订高铁智能体

用户输入：“帮我订明天的高贴。”

• 输入纠错：“高贴”→“高铁”；
• 意图确认：“您是想订明天的高铁吗？”；
• 用户确认后，智能体继续处理：“请问您要订从哪里到哪里的高铁？”

技巧8：长上下文压缩与摘要——解决“长上下文处理慢”的效率方案

问题场景

用户和智能体聊了20轮关于“项目规划”的内容，最后问：“项目进度怎么样了？” 智能体却回复：“你之前说项目要做电商APP……”——这是因为智能体处理长上下文时，计算量太大，无法快速提取关键信息。

底层原理

长上下文（比如100轮对话、长文档）的处理难点是“信息冗余”，解决方法是**“压缩+摘要”**：提取关键信息，减少计算量。

架构设计

长上下文压缩与摘要的核心是**“摘要模型+关键句提取”**：

1. 文本摘要：用预训练的摘要模型（比如PEGASUS、BART）生成长上下文的“浓缩版”，比如把20轮对话摘要成“项目是开发电商APP，deadline是下周五，需求包括用户登录、商品展示、支付功能”。
2. 关键句提取：用TextRank、BM25等算法提取长上下文的“关键句”，比如“项目deadline是下周五”“需求包括支付功能”。

实战案例：项目管理智能体

用户20轮对话内容：

• 周一：“项目是开发电商APP，deadline是下周五。”
• 周三：“需求包括用户登录、商品展示。”
• 周五：“再加一个支付功能。”
• 周日：“项目进度怎么样了？”

处理流程：

• 摘要模型生成：“项目是开发电商APP，deadline是下周五，需求包括用户登录、商品展示、支付功能。”
• 关键句提取：“deadline是下周五”“需求包括支付功能”；
• 智能体回复：“项目进度：用户登录模块已完成，商品展示模块完成80%，支付功能正在开发中，预计下周四完成，能赶上deadline。”

技巧9：上下文推理增强——解决“推理能力弱”的逻辑强化方案

问题场景

用户问：“帮我算一下从北京到上海的高铁票（二等座）加上上海外滩附近的三星级酒店（一晚）的总费用。” 智能体回复：“高铁票是309元，酒店是400元。” 但没计算总和——这是因为智能体没“推理”出“需要计算总和”。

底层原理

智能体的推理能力，本质是“根据上下文进行逻辑运算”。增强推理的核心是**“思维链（CoT）+ 检索增强生成（RAG）”**：

• CoT：引导智能体“分步思考”（比如先查高铁票价格→再查酒店价格→最后计算总和）；
• RAG：检索实时数据（比如高铁票价格、酒店价格），避免“ hallucination（幻觉）”。

架构设计

上下文推理增强的核心是**“CoT提示+RAG检索+推理引擎”**：

1. CoT提示：在智能体的prompt中加入“分步思考”的引导，比如：“请分步解决用户的问题：1. 查北京到上海的高铁二等座价格；2. 查上海外滩附近的三星级酒店一晚的价格；3. 计算总费用。”
2. RAG检索：用搜索引擎（比如SerpApi）或知识库检索实时数据，比如“高铁二等座价格309元”“酒店价格400元”。
3. 推理引擎：用大模型（比如GPT-4）或规则引擎计算总和（309+400=709元）。

实战案例：费用计算智能体

用户问：“帮我算一下从北京到上海的高铁票（二等座）加上上海外滩附近的三星级酒店（一晚）的总费用。”

• CoT提示：引导智能体分步思考；
• RAG检索：获取高铁票309元，酒店400元；
• 推理引擎：计算总和709元；
• 智能体回复：“从北京到上海的高铁二等座价格是309元，上海外滩附近的三星级酒店一晚是400元，总费用是709元。”

技巧10：上下文反馈闭环——解决“持续优化”的迭代方案

问题场景

你花了一个月优化智能体的上下文系统，但运行一个月后，智能体的理解能力反而下降了——这是因为没有收集用户反馈，无法持续优化。

底层原理

上下文系统不是“一成不变”的，需要根据用户反馈持续迭代。比如用户反馈“你理解错了我的意思”，智能体需要“学习”这个错误，下次避免。

架构设计

上下文反馈闭环的核心是**“反馈收集+离线训练+在线更新”**：

1. 反馈收集：用三种方式收集用户反馈：

   • 显式反馈：用户点击“有用”“没用”，或文本反馈（比如“你理解错了”）；
   • 隐式反馈：用户的行为（比如用户修改了智能体的回复，说明智能体理解错了）；
   • 人工标注：运营人员标注错误的理解案例。

2. 离线训练：用反馈数据fine-tune上下文处理模型（比如意图分类模型、NER模型），比如用户反馈“我喜欢拿铁不加糖，你却订了加奶的”，就用这个案例fine-tune用户画像编码器。

3. 在线更新：把离线训练后的模型部署到线上，实时更新上下文系统（比如更新用户画像中的“咖啡偏好”）。

实战案例：咖啡预订智能体

• 用户反馈：“我之前说喜欢拿铁不加糖，这次你给我订了加奶的。”
• 反馈收集：记录这个显式反馈；
• 离线训练：用这个案例fine-tune用户画像编码器，让编码器更准确地识别“拿铁不加糖”的偏好；
• 在线更新：实时更新用户画像中的“咖啡偏好”为“拿铁不加糖”；
• 下次用户订咖啡时，智能体就会正确推荐“拿铁不加糖”。

三、落地注意事项：避免踩坑的3个关键

3.1 不要为了“全面”而冗余——上下文要“按需供给”

很多架构师误以为“上下文越多越好”，但其实冗余的上下文会干扰智能体的理解。比如处理“订高铁”任务时，不需要把用户一年前的闲聊内容加入上下文。正确的做法是：根据任务类型，只拉取“相关的上下文”（比如用户层的“靠窗偏好”、任务层的“当前车次”）。

3.2 不要忽略“动态性”——上下文是“活的”，不是“死的”

上下文不是“静态存储”的，而是“动态更新”的。比如用户的位置变化时，环境层的上下文要自动更新；用户的偏好变化时（比如以前喜欢拿铁，现在喜欢美式），用户层的上下文要实时更新。

3.3 不要跳过“反馈闭环”——没有持续优化的上下文系统会“退化”

上下文系统的效果会随着时间推移而“退化”（比如用户的偏好变化、行业规则更新），必须用反馈闭环持续优化。比如每两周用用户反馈fine-tune一次模型，每月更新一次知识图谱。

四、结论：从“听懂”到“理解”，上下文工程是必经之路

智能体的理解能力，从来不是“靠大模型的参数堆出来的”，而是“靠上下文工程的架构设计出来的”。本文的10个技巧，本质是帮你搭建一套“能获取、能编码、能检索、能推理”的上下文系统：

• 用“分层总线”解决过载；
• 用“意图锚点”抓住核心；
• 用“动态窗口”管理时间；
• 用“多模态融合”处理跨模态信息；
• 用“依赖图谱”关联任务；
• 用“用户画像”实现个性化；
• 用“纠错机制”容错；
• 用“压缩摘要”提升效率；
• 用“推理增强”强化逻辑；
• 用“反馈闭环”持续优化。

这些技巧不是孤立的，而是构成一个完整的上下文工程体系。作为Agentic AI架构师，你不需要一开始就落地所有技巧——可以先选1-2个痛点最明显的技巧（比如“分层上下文总线”解决过载，“反馈闭环”持续优化），然后逐步迭代。

最后，我想对你说：智能体的“理解能力”，本质是“对用户的同理心”——而上下文工程，就是把这种“同理心”变成可落地的架构。希望这篇文章能帮你搭建出“懂用户”的智能体。

五、参考文献

1. 《Contextualized Word Representations: A Contextual Introduction》——EMNLP 2020；
2. 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》——NeurIPS 2020；
3. 《CLIP: Connecting Text and Images》——OpenAI 2021；
4. 《思维链提示：让大模型学会推理》——Google Research 2022；
5. 《用户画像驱动的个性化推荐系统》——ACM SIGIR 2023。

六、作者简介

我是林深，从事AI架构设计5年，主导过3款智能体产品的上下文系统设计（出行助手、项目管理、咖啡预订），擅长用工程化方法解决智能体的“理解问题”。我的博客专注于Agentic AI的架构设计与实战，如果你有任何问题，欢迎在评论区留言讨论。

最后，送你一句话：“好的上下文系统，不是让智能体‘记住更多’，而是让智能体‘记住对的’。” 祝你能搭建出“懂用户”的智能体！