大模型Agent开发进阶：上下文引擎设计与实战

现在聊大模型应用开发，最不缺的可能是 Agent 框架。开源社区里有大量 Agent 项目，平台产品也把编排能力做得越来越完善，只要愿意折腾，一个能跑通的 Agent Demo 并不难搭建。但把 Agent 从玩具推向真实业务时，很多人会卡在同一个地方：上下文引擎。

Agent 的每一步推理、每一次工具调用、每一轮记忆回放，本质上都是在和上下文打交道。上下文怎么组织、怎么截断、怎么检索、怎么在多个子 Agent 之间传递，直接决定了智能体的稳定性、成本和安全边界。本文会先从“为什么 Agent 搭建已经不是难题”说起，再深入拆解上下文引擎的核心设计，最后用一个可运行的实战项目演示如何从零实现轻量上下文管理，并给出多 Agent 协作场景下的上下文传递方案和常见问题排查思路。

无论你是刚接触 Agent 智能体开发的新手，还是已经在业务里落地过 Agent 框架的工程师，这篇文章都值得收藏备用。

1. 背景：Agent 搭建为什么已经不是难题

1.1 Agent 开发经历的几个阶段

Agent 应用开发在过去一年多里经历了非常明显的变化。早期大家关注的是“怎么让大模型学会调用工具”，需要手工设计 ReAct 循环、解析模型输出、组装 Tool 调用逻辑，每一步都有不少坑。

现在再看 Agent 开发，生态已经成熟很多。

• Agent 框架层：LangGraph、LlamaIndex、各类国产 Agent 框架已经把 ReAct、Plan-and-Execute、多 Agent 编排等模式封装成了现成模块。
• 工具接入层：Function Calling 已成为大模型 API 的标准能力，MCP 协议也在快速统一工具接入方式。
• 平台产品化：很多云厂商和创业公司提供了可视化 Agent 搭建平台，业务人员也能在界面上拖拽出可用的 Agent。

换句话说，Agent 智能体入门教程里最常讲的那一套“搭建流程”，已经不是核心壁垒。照着文档写一个能聊天、能查天气、能算数的 Agent，对于有基础开发经验的工程师来说，通常一两天就能完成。

1.2 上下文引擎才是真正的分水岭

既然搭建不难，那为什么很多项目上线后效果却不理想？

答案往往出在上下文引擎上。

我们可以把 Agent 想象成一个员工。这个员工能力很强，但每个时刻能记住的信息有限，而且记性需要刻意维护。上下文引擎就是负责“喂信息、控记忆、管状态”的那套系统。

具体来说，上下文引擎面临的问题包括：

• 用户输入内容如何与系统提示词、历史对话、工具返回结果一起组织；
• 上下文窗口有限，超出后如何摘要、压缩或遗忘；
• 长期记忆如何存储和检索，哪些信息值得回放；
• 多 Agent 协作时，父子 Agent 之间的上下文如何隔离和传递；
• 上下文里的敏感信息如何被保护，防止越权访问。

这些问题不解决，Agent 就会表现出“记不住”、“答非所问”、“工具调用紊乱”、“一次对话成本暴涨”等症状。所以我说，Agent 搭建已非难题，上下文引擎才是破局关键。

2. 上下文引擎的核心概念

2.1 什么是上下文引擎

上下文引擎（Context Engine）是一套负责 Agent 上下文生命周期管理的系统，通常包含上下文构建、历史管理、记忆存储、检索增强、状态同步等能力。

在工程实现上，它不是一个单一的库，而是一组组件的组合。常见的组件包括：

• 上下文窗口管理器：控制哪些消息进入模型请求；
• 记忆存储：保存短期对话和长期事实；
• 检索器：从记忆或外部知识库中召回相关内容；
• 摘要器：在上下文过长时生成历史摘要；
• 状态机：记录 Agent 当前执行到哪一步，哪些子任务已完成。

2.2 上下文窗口与 Token 管理

上下文窗口是 Agent 最直接的成本和性能约束。

每个大模型都有一个最大上下文长度，比如有的模型支持 32K、128K 甚至更长。但这并不意味着可以把所有历史全部塞进窗口。原因有三点：

1. 成本：输入 Token 按量计费，上下文越长，每次请求成本越高。
2. 延迟：上下文越长，模型首字延迟通常会变高。
3. 效果：大量无关历史会稀释模型注意力，导致“迷失在中间”的现象，相关性反而下降。

所以上下文引擎的核心任务之一，就是做 Token 预算控制。实际项目中，通常会把上下文分成固定预算的多个区域，例如系统提示词占 20%，历史对话占 50%，工具结果占 20%，用户当前输入占 10%，并动态调整。

2.3 记忆分层：短期、长期、工作记忆

Agent 记忆是上下文引擎的重要组成部分。为了便于理解，可以把记忆分成三层：

在设计上下文引擎时，这三层记忆要分开管理。短期记忆决定模型当前看到什么，工作记忆决定 Agent 下一步做什么，长期记忆决定 Agent 如何个性化回应。

一个常见错误是把所有长期记忆都塞进上下文，导致每次请求都很昂贵且容易泄露无关隐私。正确的做法是：先检索出与当前问题相关的少量记忆，再注入上下文。

2.4 上下文引擎与 Agent 框架的关系

很多人会把 Agent 框架和上下文引擎混为一谈。实际上两者关注点不同：

• Agent 框架解决的是“Agent 怎么思考、怎么调用工具、怎么编排步骤”；
• 上下文引擎解决的是“Agent 在思考和调用过程中，信息如何被组织、保留、找回和传递”。

熟练的 Agent 开发工程师会同时关注这两层。框架负责流程，上下文引擎负责记忆和信息流。本文实战部分会带着大家从零实现一个极简上下文引擎，帮助理解底层机制。

3. 环境准备与前置条件

为了便于后续实战演示，我们先统一一下开发环境。这不是必须严格照搬的配置，按你自己的实际环境调整即可。

• 操作系统：Windows / macOS / Linux 均可；
• 编程语言：Python 3.10 或更高版本；
• 包管理工具：pip 或 poetry；
• LLM 客户端：可以准备一个支持 OpenAI 兼容接口的 SDK，例如openai库，或者使用国内大模型平台的 SDK；
• 额外存储：长期记忆示例会用到 SQLite，这是 Python 标准库，不需要额外安装。

本文的重点是上下文引擎的设计思路和数据结构，所以代码中会把 LLM 调用封装成一个llm_call函数。你在运行时需要将它替换为你自己的模型客户端代码。

建议先创建一个虚拟环境：

python -m venv context-engine-demo source context-engine-demo/bin/activate # Windows 下执行 context-engine-demo\Scripts\activate

后续代码都基于这个虚拟环境运行。

4. 从零实现一个轻量上下文引擎

这一节我们不看大型框架的源码，而是自己动手写一个简化版上下文引擎。通过这个小项目，你会发现上下文管理并不神秘，关键点在于数据结构设计和执行流程控制。

4.1 项目结构

我们先规划一个最小但完整的项目结构：

context_engine_demo/ ├── agent.py # Agent 主循环 ├── context.py # 上下文管理器 ├── memory.py # 记忆存储 ├── tools.py # 工具注册与调用 └── main.py # 演示入口

每个模块职责单一，方便阅读和扩展。

4.2 设计数据结构：上下文管理器

在context.py中，我们定义一个ContextEngine类。它的核心职责是：

• 保存系统提示词；
• 追加用户消息和助手消息；
• 维护一个最大 Token 预算；
• 当消息过多时，对早期历史做摘要压缩；
• 对外提供构建模型请求消息列表的方法。

代码如下：

# 文件路径：context_engine_demo/context.py from typing import List, Dict, Optional, Callable class ContextEngine: def __init__( self, system_prompt: str, max_messages: int = 20, summarize: Optional[Callable[[str], str]] = None ): self.system_prompt = system_prompt self.max_messages = max_messages self.messages: List[Dict[str, str]] = [] self.summarize = summarize def add_message(self, role: str, content: str) -> None: """向上下文中追加消息""" self.messages.append({"role": role, "content": content}) self._maybe_compress() def _maybe_compress(self) -> None: """当消息数量超过阈值时，把最早的非系统消息压缩成摘要""" if len(self.messages) <= self.max_messages: return # 保留最近的 max_messages / 2 条消息 keep_count = self.max_messages // 2 history = self.messages[:-keep_count] self.messages = self.messages[-keep_count:] if self.summarize is not None: history_text = "\n".join( f"{m['role']}: {m['content']}" for m in history ) summary = self.summarize(history_text) # 把摘要插入到消息列表最前面，但放在系统提示词之后 self.messages.insert( 0, {"role": "system", "content": f"历史对话摘要：{summary}"} ) def build_messages(self) -> List[Dict[str, str]]: """生成发送给模型的完整消息列表""" return [ {"role": "system", "content": self.system_prompt} ] + self.messages

这里有几个设计要点：

• summarize是一个可注入的摘要函数。理论上可以用任意 LLM 调用来实现，方便替换。
• 压缩时保留最近一半消息，把更早的历史变成摘要，而不是直接丢弃。这样既控制上下文长度，又不完全丢失信息。
• 摘要消息以system角色放在消息列表前面，让模型在生成回复时参考。

4.3 设计记忆存储：长期记忆的简化实现

接下来在memory.py中实现一个简单的长期记忆。为了不引入过多依赖，这里用 SQLite 作为存储，用关键词匹配代替向量检索。

# 文件路径：context_engine_demo/memory.py import sqlite3 from typing import List, Dict class MemoryStore: def __init__(self, db_path: str = "memory.db"): self.conn = sqlite3.connect(db_path) self.conn.execute( """ CREATE TABLE IF NOT EXISTS memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, created_at TEXT DEFAULT CURRENT_TIMESTAMP ) """ ) self.conn.commit() def save(self, content: str) -> None: """保存一条记忆""" self.conn.execute( "INSERT INTO memories (content) VALUES (?)", (content,) ) self.conn.commit() def search(self, keyword: str, limit: int = 3) -> List[Dict[str, str]]: """基于简单关键词匹配检索记忆""" cursor = self.conn.execute( """ SELECT content, created_at FROM memories WHERE content LIKE ? ORDER BY id DESC LIMIT ? """, (f"%{keyword}%", limit) ) rows = cursor.fetchall() return [ {"content": row[0], "created_at": row[1]} for row in rows ]

实际生产环境里，search应该替换成向量检索，例如把记忆内容做成 Embedding 存入向量数据库，再用语义相似度召回。这里用关键词匹配是为了让演示代码在任何环境都能直接运行。

4.4 实现工具注册与调用

Agent 能力的一个重要来源是工具调用。在tools.py中，我们实现一个极简工具注册表。

# 文件路径：context_engine_demo/tools.py from typing import Callable, Dict, Any class ToolRegistry: def __init__(self): self.tools: Dict[str, Dict[str, Any]] = {} def register( self, name: str, description: str, func: Callable, parameters: Dict[str, Any] ) -> None: self.tools[name] = { "description": description, "func": func, "parameters": parameters, } def run(self, name: str, args: Dict[str, Any]) -> str: if name not in self.tools: return f"错误：未找到工具 {name}" try: result = self.tools[name]["func"](**args) return str(result) except Exception as e: return f"工具执行失败：{e}" def get_schema(self) -> list: """生成给大模型看的工具描述""" schema = [] for name, info in self.tools.items(): schema.append({ "type": "function", "function": { "name": name, "description": info["description"], "parameters": info["parameters"], } }) return schema

get_schema返回的是符合 OpenAI Function Calling 风格的工具描述。不同模型 SDK 可能略有差异，但整体思路一致：把工具的名称、描述和参数结构告诉模型，模型决定何时调用。

4.5 实现 Agent 主循环

现在到最核心的部分：Agent 如何把上下文引擎、记忆存储和工具注册表串起来。

在agent.py中，我们定义一个Agent类：

# 文件路径：context_engine_demo/agent.py import json from context_engine_demo.context import ContextEngine from context_engine_demo.memory import MemoryStore from context_engine_demo.tools import ToolRegistry def default_llm_call(messages, tools=None): """ 占位函数，需要替换为实际的模型调用代码。 参数： messages: 上下文消息列表 tools: 工具 schema 列表 返回： { "content": "模型生成的文本", "tool_calls": [ { "name": "工具名", "arguments": {"参数1": "值1"} } ] } """ raise NotImplementedError("请把这里的调用替换为实际的大模型 SDK") class Agent: def __init__( self, system_prompt: str, llm_call=default_llm_call, max_messages: int = 20, memory_store: MemoryStore | None = None, ): self.context = ContextEngine( system_prompt=system_prompt, max_messages=max_messages, summarize=llm_call_to_summary(llm_call), ) self.llm_call = llm_call self.tools = ToolRegistry() self.memory = memory_store or MemoryStore() def run(self, user_input: str) -> str: # 1. 检索长期记忆 memories = self.memory.search(user_input) memory_context = "" if memories: memory_context = "\n".join( f"- {m['content']}" for m in memories ) self.context.add_message( "system", f"以下是历史记忆中与当前问题相关的内容：\n{memory_context}" ) # 2. 加入用户消息 self.context.add_message("user", user_input) # 3. 进入 Agent 循环 max_iterations = 5 for _ in range(max_iterations): messages = self.context.build_messages() response = self.llm_call( messages, tools=self.tools.get_schema() ) tool_calls = response.get("tool_calls", []) if not tool_calls: # 不再调用工具，完成任务 answer = response.get("content", "") self.context.add_message("assistant", answer) self.memory.save(f"用户问题：{user_input}") self.memory.save(f"助手回答：{answer}") return answer # 4. 执行工具调用 for tool_call in tool_calls: name = tool_call["name"] args = tool_call.get("arguments", {}) result = self.tools.run(name, args) self.context.add_message( "tool", f"工具 {name} 返回：{result}" ) return "Agent 执行达到最大迭代次数，请检查工具逻辑。" def llm_call_to_summary(llm_call): """把 llm_call 包装成一个摘要函数""" def summarize(text: str) -> str: try: resp = llm_call( [ { "role": "system", "content": "请把下面的对话历史压缩成一段简洁摘要，保留关键事实：" }, {"role": "user", "content": text}, ], tools=[], ) return resp.get("content", "（摘要失败）") except Exception: return "（历史过长，已省略）" return summarize

整个run方法的流程就是典型的 ReAct 模式：

1. 先召回长期记忆；
2. 把用户问题加入上下文；
3. 调用大模型，判断是否需要调用工具；
4. 如果需要，执行工具并把结果写回上下文；
5. 再次调用大模型，直到不需要工具为止；
6. 保存对话到长期记忆。

这里的llm_call_to_summary复用了同一个调用函数来生成摘要，保证上下文超限时能自动压缩。

4.6 编写演示入口

最后我们写一个main.py，注册两个简单工具，并执行一段多轮对话。

# 文件路径：context_engine_demo/main.py from context_engine_demo.agent import Agent from context_engine_demo.tools import ToolRegistry def get_current_time() -> str: """获取当前时间""" from datetime import datetime return datetime.now().strftime("%Y-%m-%d %H:%M:%S") def calculator(expression: str) -> str: """计算数学表达式""" return str(eval(expression)) def create_agent() -> Agent: agent = Agent( system_prompt="你是一个乐于助人的助手。当需要查询信息时，请使用工具。", ) agent.tools.register( name="get_current_time", description="获取当前时间", func=get_current_time, parameters={ "type": "object", "properties": {}, }, ) agent.tools.register( name="calculator", description="计算数学表达式", func=calculator, parameters={ "type": "object", "properties": { "expression": { "type": "string", "description": "数学表达式，例如 12*8" } }, "required": ["expression"], }, ) return agent if __name__ == "__main__": agent = create_agent() print(agent.run("现在几点了？")) print(agent.run("帮我算一下 12 乘以 8 等于多少"))

这里要特别提醒：calculator中直接使用eval只是为了演示，生产环境绝对不能这样做，否则会有严重的代码注入风险。后面最佳实践部分会专门讨论安全边界。

4.7 运行与预期结果

按照实际环境接入大模型 SDK 后，运行main.py：

python main.py

预期效果大致如下：

• 第一轮，模型识别出需要调用get_current_time工具，工具返回时间后，模型生成带时间的文本回答。
• 第二轮，模型识别出需要调用calculator工具，传入12*8，拿到结果后回答“96”。

如果把default_llm_call换成真实 SDK，注意不同模型的工具调用返回格式可能略有不同，需要做一些字段适配。这个中间的适配层，本身也是上下文引擎的一部分。

5. 进阶实战：子 Agent 模式与上下文传递

5.1 为什么需要子 Agent

单个 Agent 处理简单任务足够，但现实业务往往需要多个步骤、多个领域的知识。比如一个“运维日志分析助手”，可能需要：

• 一个 Agent 负责查询 Elasticsearch 日志；
• 一个 Agent 负责分析错误模式；
• 一个 Agent 负责生成报告。

如果所有能力都塞进同一个 Agent，工具列表会非常长，上下文也会混乱。这时候更合理的方案是使用多 Agent 协作，最常见的是主从模式：一个主 Agent 负责任务拆解，多个子 Agent（SubAgent）分别执行子任务。

5.2 把子 Agent 当作 Tool 调用

在多 Agent 设计中有一个非常实用的观点：子 Agent 本质上可以看作一种特殊的 Tool。

父 Agent 不关子 Agent 的内部上下文，它只需要知道“这个子 Agent 能完成什么任务、输入是什么、输出是什么”。这种设计带来几个好处：

• 上下文隔离：子 Agent 的中间过程不会污染父 Agent 的上下文。
• 可复用性：同一个子 Agent 可以被不同的父 Agent 调用。
• 可观测性：每个 Agent 的调用关系清晰，方便追踪。

实现上，我们可以在 ToolRegistry 中注册一个“子 Agent 工具”，它的执行函数内部直接调用另一个 Agent 的run方法。

# 核心思路示例 def make_agent_tool(sub_agent: Agent): def run_sub_agent(task_description: str) -> str: return sub_agent.run(task_description) return run_sub_agent

父 Agent 只需要维护任务描述和最终结果，子 Agent 的内部思考过程、工具调用历史都被封装在子 Agent 内，这是多 Agent 协作中控制上下文膨胀的核心手段。

5.3 上下文传递的三种方式

多 Agent 协作中，上下文传递方式直接影响效果和成本。常见的三种方式：

实际项目中，推荐默认使用“结果回传”。父 Agent 每次调用子 Agent 前，先把任务描述写得足够清晰；子 Agent 完成后，把结构化结果返回给父 Agent，父 Agent 再决定下一步动作。

这里还需要注意一个细节：如果子 Agent 依赖用户身份、业务规则等公共信息，可以把这些信息固化到子 Agent 的系统提示词中，而不要每次从父 Agent 那里重复传递。这样可以减少 Token 消耗，也更容易统一管理权限边界。

6. 常见问题与排查思路

6.1 Agent 执行超时

很多开发者反馈过这样一类报错：

The agent execution provider did not respond in time. This may indicate the...

这句话的意思是 Agent 的执行提供方没有在预期时间内响应。常见原因包括：

• 网络延迟或模型服务端负载过高；
• 上下文过长导致模型推理时间增加；
• 工具调用链路过长，循环次数过多；
• 某个外部 API 没有设置超时，一直阻塞等待；
• 模型鉴权失效导致请求被拒绝。

排查顺序建议如下：

1. 检查模型服务是否正常，做一个最简单的文本生成请求测试；
2. 查看当前上下文长度和估算 Token 数；
3. 检查工具调用是否出现了死循环；
4. 为所有外部 HTTP 调用设置连接超时和读取超时；
5. 在 Agent 循环里增加最大迭代次数和单步超时。

6.2 上下文丢失，Agent 记不住之前的话

如果 Agent 在多轮对话后“失忆”，通常是因为上下文被截断或摘要丢失了关键信息。

排查时先看上下文压缩策略：

• 压缩时保留了哪些消息；
• 摘要函数是否完整保留了用户偏好和任务状态；
• 长期记忆是否成功写入和检索。

解决方案是在压缩时优先保留“事实型”内容，比如用户明确给出的约束、任务目标、已完成步骤，这类内容比寒暄更重要。更稳妥的做法是把关键状态单独维护到结构化变量中，而不是完全依赖自然语言摘要。

6.3 上下文过大，成本飙升

上下文过大通常由两个原因导致：一是历史消息无限增长；二是工具返回结果太大，比如一次查询返回上万行日志。

建议做法：

• 限制工具返回的最大长度，超长内容先做本地聚合或摘要；
• 对历史消息设置滑动窗口；
• 把大文档放入检索库，只在需要时按片段注入；
• 设置单轮 Token 预算告警，超过阈值主动提示用户。

6.4 历史记忆污染或隐私泄露

长期记忆是双刃剑。如果检索逻辑不精准，可能把不相关的历史记忆注入当前上下文，甚至泄露其他用户的信息。

要避免这个问题，需要做到：

• 长期记忆按用户或租户做数据隔离；
• 检索结果增加相关性阈值，低于阈值不注入；
• 敏感信息默认不写入长期记忆；
• 对记忆内容提供人工删除和审计入口。

这里也要强调安全边界：任何工具调用都必须遵循最小权限原则。比如日志分析 Agent，应该只授予它读取指定索引的权限，不要给它整个集群的管理员凭证。

6.5 多 Agent 上下文混乱

多 Agent 协作中最常见的问题是子 Agent 的上下文过多，导致父 Agent 无法判断该相信谁、该忽略什么。

此时需要统一结构化的返回格式。建议给子 Agent 定义明确的输出 Schema，例如：

{ "summary": "任务执行摘要", "result": "结构化结果", "confidence": "置信度 0-1", "error": "错误信息，没有则为空" }

父 Agent 只需要解析这个 Schema，不必阅读子 Agent 的完整思考过程。如果子 Agent 结果异常，父 Agent 可以直接根据error字段决定重试或切换方案。

7. 最佳实践与工程建议

7.1 上下文治理与成本控制

在真实项目中，上下文引擎不能只实现“能跑”，还要考虑成本治理。

建议为每次 Agent 运行维护一份上下文明细，包括系统提示词 Token 数、历史 Token 数、工具返回 Token 数、生成 Token 数。把这份数据作为日志输出，配合监控面板观察平均单次调用成本。

当上下文成本异常升高时，优先检查是不是工具返回结果过大。处理手段包括：限制返回行数、返回前先聚合、使用更紧凑的序列化格式。

7.2 安全边界与权限最小化

Agent 的权限越大，安全事故的风险越高。在接入真实业务时，需要遵守以下底线：

• 所有数据库操作必须经过白名单校验，禁止直接拼接 SQL；
• 文件读写限制在指定目录，禁止访问系统敏感路径；
• 生产环境的变更类工具必须增加人工审批节点；
• 外部 API 调用使用独立的只读凭证；
• 涉及用户隐私的数据，默认不进入长期记忆；
• 工具函数的执行应做超时和并发限制。

代码层面的示例是：不要像本文演示中的calculator那样直接eval用户输入，应该使用安全表达式解析库，或者把计算能力限定为四则运算。

7.3 可观测性：日志、追踪、评测

Agent 应用上线只是开始，长期维护需要依赖可观测性。

• 关键日志：记录每次 LLM 请求的消息数、工具调用序列、耗时和 Token 用量；
• 链路追踪：每个 Agent 实例分配一个 trace_id，父 Agent 和子 Agent 共享这个 ID；
• 评测集：准备一批典型业务问题，定期回归测试上下文引擎的召回和摘要效果；
• 用户反馈：对 Agent 回答提供“有帮助/无帮助”反馈入口，形成闭环。

我自己在项目里最重视的是 trace_id。没有链路追踪的时候，多 Agent 调用一旦出错，只能靠猜；加上 trace_id 之后，排查效率提升非常明显。

7.4 给 AI Engineer 的学习路径

如果你打算深入 Agent 开发，可以参考下面的学习路径。

第一阶段是掌握 Agent 基础，了解 ReAct 循环、Function Calling、工具调用原理，能把一个简单 Agent 跑通。

第二阶段是学习上下文管理，重点理解 Token 计算、滑动窗口、摘要策略、消息结构设计，这一阶段对应本文的实战内容。

第三阶段是学习记忆系统，包括向量库、Embedding、混合检索、记忆写入策略。这里可以关注“skill 和 MCP 有什么区别”这类话题，它们分别解决能力封装和工具协议问题。

第四阶段是学习多 Agent 协作，掌握主从模式、路由模式、黑板模式等常见架构，重点关注上下文如何在 Agent 之间安全传递。

第五阶段是工程化与评测，包括成本监控、安全审计、评测集构建、生产环境灰度发布。

8. 结尾

Agent 开发的确已经不是难题，框架和平台提供了大量现成能力。但要真正做出稳定、可控、低成本的 Agent 应用，上下文引擎是绕不开的核心工程点。希望本文从概念到实战的拆解，能帮你建立起自己的上下文管理思路。

你在实际项目里遇到过哪些上下文相关的坑？你用的是自研上下文引擎还是框架内置方案？欢迎在评论区聊聊。如果觉得这篇文章对你有帮助，可以收藏备用，后续我会继续更新 Agent 记忆系统和多 Agent 协作的深入实战。