如何剖析单智能体代码中的Agent context Engineering？

近期关于智能体设计有诸多观点，一个关键点让我豁然开朗——无论智能体是1个还是多个，是编排驱动还是自主决策，是静态预定义还是动态生成，Context上下文的管理机制始终是设计的核心命脉。它决定了：每个节点使用哪些信息？分别更新或修改哪些信息？多步骤间如何传递？智能体间是否共享、如何共享？后续篇章我们将剖析多个热门开源项目，一探它们如何驾驭Context。本章聚焦单智能体设计，选取两个代表性框架：模仿OpenAI深度研究范式的Gemini-fullstack（编排式）与模仿Manus的OpenManus（自主式）。 框架对比 先来整体对比下两个框架，这样懒得看细节的盆友们就可以只看下表了~ 特性 Gemini Deep Search (编排式) OpenManus Flow Mode (规划式自主) OpenManus Manus Mode (纯自主) 智能体类型 单智能体，编排驱动 单智能体，全局规划 + 分步ReAct循环 单智能体，ReAct循环 任务分解 固定流程节点 全局Plan 动态思考下一步(Think) Context 范围 节点级隔离 (每节点用特定输入) Step级隔离 (每Step用Plan状态+当前任务) 线性增长+窗口截断 (全历史) Context 传递 传递任务结果 (Query列表, 摘要文本) 外层：传递Plan状态 + Step结果字符串；内层全部历史 传递完整ReAct历史 (截断后) 状态管理 无显式状态，依赖数据流 显式Plan & Step状态管理 隐含在消息历史中 优势 流程清晰可控，模块化，引用处理优雅 步骤Context轻量，潜在减少迭代次数 灵活性高 挑战 灵活性较低，节点间“思考”不共享 Plan质量依赖（或需要动态调整），Step间Context隔离可能导致信息断层/冲突 Context膨胀，长程依赖易丢失，多轮消息会引入噪音 Gemini Deep Search- 编排智能体 gemini-fullstack-langgraph-quickstart Gemini Deep Search 是一个典型的编排式智能体。其执行流程预先定义，核心在于引入了反思节点，用于动态判断信息收集是否充分。流程清晰简洁： 图释：Gemini Deep Search的核心编排流程，包含查询生成、并行搜索、反思评估、路由决策和最终答案生成五个关键节点，通过反思节点实现循环控制。 1. 查询生成（Generate Query） 核心亮点：将“思考过程”工具化/结构化输出。 使用Pydantic模型强制输出包含查询列表(query)和推理依据(rationale) class SearchQueryList(BaseModel): query: List[str] = Field( description="A list of search queries to be used for web research." ) rationale: str = Field( description="A brief explanation of why these queries are relevant to the research topic." ) 实际应用中会发现把 思考工具化（结构化） 有很多优点: 模型无关性： 不依赖模型的“思考”原生能力，任何支持结构化输出的模型皆可。 简洁可控： 结构化输出比模型自由生成的思考通常更简短、更聚焦，避免冗余和发散。。 2. 并行搜索+摘要（Web_research) 然后就是基于多个query的并行搜索模块这里直接使用了Langgraph自带的Send多线程并发模式，然后直接让大模型基于检索上文进行总结。这里可参考不多，因为引用生成等逻辑在Gemini的API中，用开源模型的盆友需要重新适配。 不过有意思的是现在如何给模型推理插入引用，原来多数都是在指令中加入要求，让模型一边推理一边生成引用序号[i]([citation:i])，不过在新的模型能力下有了很多天马星空的方案。像Claude给出过先直接进行无引用推理，然后再让模型重新基于推理结果，在不修改原文的基础上，插入引用的markdown链接。