DeepAgents : 上下文工程Context engineering一句话核心上下文工程就是用正确的信息、合适的格式、在恰当的时机喂给 Deep Agent从而让它稳定、可靠地完成任务。Deep Agent 运行时会接触到多种上下文。有些在启动时固定注入有些在运行中动态生成比如用户提问。更重要的是Deep Agent 内置了一整套机制能够在长时间、多轮对话中自动管理这些上下文避免“上下文爆炸”或“遗忘”问题。1. 五大上下文类别速览类别作用生命周期启动上下文系统提示词、记忆文件、技能描述等在 Agent 启动时一次性注入静态每轮运行都生效调用上下文每次调用时传入的固定配置如用户 ID、API 密钥、环境变量单次运行可自动传递给子 Agent压缩上下文内置的自动卸载和摘要机制当上下文接近窗口上限时触发动态按需自动执行隔离上下文通过子 Agent 隔离重负载任务主 Agent 只接收精简结果委托时生效各子 Agent 独立长期记忆基于虚拟文件系统的跨会话持久化存储如AGENTS.md持久跨对话保留2. 各类上下文的详细说明1. 启动上下文Input Context指 Agent 启动时加载到系统提示词中的信息。最终的系统提示词由三部分拼接而成用户自定义部分角色、行为规范、领域知识框架内置部分规划指南、文件操作、子 Agent 调用指令示例agentcreate_deep_agent(modelgoogle_genai:gemini-3.5-flash,system_prompt你是一名科研助理必须严格标注引用来源。当需要并行调研多个主题时请启用子 Agent。)2. 调用上下文Runtime Context这是每次请求时附带的“静态配置”比如用户身份、权限、数据库连接等。这些配置在整个会话中保持不变并会自动传递给所有子 Agent无需重复声明。3. 自动压缩Context CompressionDeep Agent 内部有“智能管家”当上下文长度快撑爆窗口时会自动执行卸载Offloading将不重要的历史对话转存为摘要摘要Summarization压缩冗长内容只保留关键信息这一切由模型自主决定开发者无需手动干预。4. 子 Agent 隔离Subagents这是最有效的上下文管理手段。当某个工具返回的结果巨大比如爬取整页网页、扫描整个代码库如果全塞进主 Agent 的上下文很快就会超限。正确的做法是将具体工作交给专门子 Agent带着自己的工具和指令子 Agent 完成后只把最终结论返回给主 Agent这样主 Agent 始终轻装上阵上下文干净清爽。5. 长期记忆Long-term Memory通过虚拟文件系统实现关键文件如下全局记忆~/.deepagents/agent_name/AGENTS.md—— 每次启动自动加载项目记忆.deepagents/AGENTS.md通常放在 Git 项目根目录—— 在此项目下运行时自动生效这些文件相当于 Agent 的“长期工作手册”能记住跨会话的项目约定、常用命令等信息。3. 上下文工程的核心心法为什么 Agent 经常翻车根本原因只有两个模型本身能力不够但现代 LLM 通常够用上下文没给对这是绝大多数问题的根源如何打造一个可靠的 Agent不要只盯着模型选型要牢牢控制住 Agent 循环中每一步以及步骤之间的上下文流动。具体来说需要把控三个层面层面控制要点持久性模型输入每次调用模型时送入的指令、历史消息、工具定义、响应格式瞬时仅本次调用工具交互工具可读取和写入的内容状态、存储、调用上下文持久影响后续状态生命周期两次调用之间发生的动作如自动摘要、合规检查、日志记录持久影响后续流程两点重要启示接口胜于示例把工具的参数描述写得清晰、规范比塞一堆 Few-shot 例子更能让模型准确调用。重复即浪费在系统提示词和工具描述中重复相同的话并不会提升效果只会白白消耗 Token。
DeepAgents : 上下文工程Context engineering一句话核心上下文工程就是用正确的信息、合适的格式、在恰当的时机喂给 Deep Agent从而让它稳定、可靠地完成任务。Deep Agent 运行时会接触到多种上下文。有些在启动时固定注入有些在运行中动态生成比如用户提问。更重要的是Deep Agent 内置了一整套机制能够在长时间、多轮对话中自动管理这些上下文避免“上下文爆炸”或“遗忘”问题。1. 五大上下文类别速览类别作用生命周期启动上下文系统提示词、记忆文件、技能描述等在 Agent 启动时一次性注入静态每轮运行都生效调用上下文每次调用时传入的固定配置如用户 ID、API 密钥、环境变量单次运行可自动传递给子 Agent压缩上下文内置的自动卸载和摘要机制当上下文接近窗口上限时触发动态按需自动执行隔离上下文通过子 Agent 隔离重负载任务主 Agent 只接收精简结果委托时生效各子 Agent 独立长期记忆基于虚拟文件系统的跨会话持久化存储如AGENTS.md持久跨对话保留2. 各类上下文的详细说明1. 启动上下文Input Context指 Agent 启动时加载到系统提示词中的信息。最终的系统提示词由三部分拼接而成用户自定义部分角色、行为规范、领域知识框架内置部分规划指南、文件操作、子 Agent 调用指令示例agentcreate_deep_agent(modelgoogle_genai:gemini-3.5-flash,system_prompt你是一名科研助理必须严格标注引用来源。当需要并行调研多个主题时请启用子 Agent。)2. 调用上下文Runtime Context这是每次请求时附带的“静态配置”比如用户身份、权限、数据库连接等。这些配置在整个会话中保持不变并会自动传递给所有子 Agent无需重复声明。3. 自动压缩Context CompressionDeep Agent 内部有“智能管家”当上下文长度快撑爆窗口时会自动执行卸载Offloading将不重要的历史对话转存为摘要摘要Summarization压缩冗长内容只保留关键信息这一切由模型自主决定开发者无需手动干预。4. 子 Agent 隔离Subagents这是最有效的上下文管理手段。当某个工具返回的结果巨大比如爬取整页网页、扫描整个代码库如果全塞进主 Agent 的上下文很快就会超限。正确的做法是将具体工作交给专门子 Agent带着自己的工具和指令子 Agent 完成后只把最终结论返回给主 Agent这样主 Agent 始终轻装上阵上下文干净清爽。5. 长期记忆Long-term Memory通过虚拟文件系统实现关键文件如下全局记忆~/.deepagents/agent_name/AGENTS.md—— 每次启动自动加载项目记忆.deepagents/AGENTS.md通常放在 Git 项目根目录—— 在此项目下运行时自动生效这些文件相当于 Agent 的“长期工作手册”能记住跨会话的项目约定、常用命令等信息。3. 上下文工程的核心心法为什么 Agent 经常翻车根本原因只有两个模型本身能力不够但现代 LLM 通常够用上下文没给对这是绝大多数问题的根源如何打造一个可靠的 Agent不要只盯着模型选型要牢牢控制住 Agent 循环中每一步以及步骤之间的上下文流动。具体来说需要把控三个层面层面控制要点持久性模型输入每次调用模型时送入的指令、历史消息、工具定义、响应格式瞬时仅本次调用工具交互工具可读取和写入的内容状态、存储、调用上下文持久影响后续状态生命周期两次调用之间发生的动作如自动摘要、合规检查、日志记录持久影响后续流程两点重要启示接口胜于示例把工具的参数描述写得清晰、规范比塞一堆 Few-shot 例子更能让模型准确调用。重复即浪费在系统提示词和工具描述中重复相同的话并不会提升效果只会白白消耗 Token。
)
