Gemini Deep Search- 编排智能体
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链接。
这里Google是直接推理API中集成了类似能力,哈哈我也没用过Gemini的API,不过看代码,应该是类似以下的结构, 会通过结构化推理(哈哈Google很爱用结构化推理,其实个人也觉得不论是工具还是Function Calling或者是Thinking,最底层的对接方案还是结构化推理),返回引用序号列表对应的文字段落的起止位置。
# Gemini API响应结构
response.candidates[0].grounding_metadata = {
"grounding_supports": [
{
"segment": {"start_index": 0, "end_index": 50},
"grounding_chunk_indices": [0, 1, 2]
}
],
"grounding_chunks": [
{
"web": {
"uri": "https://example.com/page1",
"title": "Example Page 1"
}
}
]
}
考虑到这里涉及两次模型推理,第一次就是每个query的搜索总结,第二次是最终基于所有总结段落的二次汇总推理。因此这里项目在本次推理(第一次)中把citation以markdown超链接的格式插回到了原文中,这样二次推理可以直接生成引用链接。(URL进行了缩写,降低推理token和copy出错的可能性)
3. 反思评估(Reflection)
- 评估当前收集的摘要信息是否足以回答用户问题。
- 同样采用结构化输出,个人实践的优化点: 可扩展Reflection模型,加入reasoning字段,让模型先分析“回答用户需要什么信息?”、“当前已有哪些信息?”,再做出判断和提出补充查询,使决策更透明、依据更充分。
class Reflection(BaseModel):
is_sufficient: bool = Field(
description="Whether the provided summaries are sufficient to answer the user's question."
)
knowledge_gap: str = Field(
description="A description of what information is missing or needs clarification."
)
follow_up_queries: List[str] = Field(
description="A list of follow-up queries to address the knowledge gap."
)
4. 决策路由(Router)
- 根据Reflection节点的输出 (is_sufficient) 和预设的最大循环次数,决定流程走向(继续搜索Generate Query或进入Finalize Answer)。
- Context管理:此节点本身不修改Context,仅基于Reflection的Context进行流程控制。
5. 生成最终答案(Finalize Answer)
- 汇总所有步骤收集到的摘要信息(已包含Markdown引用链接)
- 进行最终推理,生成回答,并保留摘要中已嵌入的引用信息。
Context管理
Gemini的Context管理
- 模块化隔离: 每个节点聚焦特定任务,使用特定的Context输入(如Generate Query只用原始Query,Web Research用特定Query列表,Reflection用所有摘要)。
- 无状态传递: 节点间不共享“推理状态”上下文(如之前的思考过程),主要传递任务结果(Query列表、摘要文本)。
OpenManus - 自主智能体
OpenManus 提供了两种模式:Manus Mode(基础ReAct)和Flow Mode(规划驱动)。虽然项目将Flow称为“多智能体”,但从Context管理角度看,更像是单智能体的两种任务分解策略:Manus是局部规划+即时执行,Flow是全局规划(Plan)+分步执行(Manus)。
Manus 模式:经典ReAct循环
Manus模式本质是ReAct循环:思考(Think)->行动(Act)->观察(Observe),循环执行直至任务完成。核心流程:
- Think: 基于当前Context(用户问题+历史消息+可用工具描述),模型决定下一步动作(调用哪个工具及其参数)。
- Act: 执行所选工具(如browser-use进行复杂网页交互操作、文本编辑器)。
- Observe: 将工具执行结果作为ToolMessage加入Context。
- 循环上述步骤,直到Think选择终止工具。
Manus的Context管理
线性增长: 整个任务由一个智能体完成,Context随执行步骤线性增长,每一步都使用前置的所有message信息。
Flow 模式
Flow的核心思想是引入全局Plan规划器。在当前模型能力下,先规划再执行有助于:
- 简化步骤Context: 每个Manus步骤只需关注当前Step和Plan状态,上下文更轻量。
- 减少迭代次数: 全局视野可能降低智能体陷入局部循环的概率。
- 潜在挑战: 步骤间Context隔离可能导致信息重复/冲突;全局规划器传递任务时可能丢失细节(Context Gap)。
Plan工具设计 (核心): Plan本身通过结构化工具实现管理:
- 两层结构: Plan -> Steps。
- 操作完备: 创建(Create)、更新(Update)、列表(List)、获取(Get)、激活(Set Active)、标记步骤状态(Mark Step)、删除(Delete)
- 状态跟踪: Step状态包括未开始(not_started)、进行中(in_progress)、完成(completed)、阻塞(blocked)。
- 核心参数示例如下
class PlanningTool(BaseTool):
"""
A planning tool that allows the agent to create and manage plans for solving complex tasks.
The tool provides functionality for creating plans, updating plan steps, and tracking progress.
"""
name: str = "planning"
description: str = _PLANNING_TOOL_DESCRIPTION
parameters: dict = {
"type": "object",
"properties": {
"command": {
"description": "The command to execute. Available commands: create, update, list, get, set_active, mark_step, delete.",
"enum": [
"create",
"update",
"list",
"get",
"set_active",
"mark_step",
"delete",
],
"type": "string",
},
"plan_id": {
"description": "Unique identifier for the plan. Required for create, update, set_active, and delete commands. Optional for get and mark_step (uses active plan if not specified).",
"type": "string",
},
"title": {
"description": "Title for the plan. Required for create command, optional for update command.",
"type": "string",
},
"steps": {
"description": "List of plan steps. Required for create command, optional for update command.",
"type": "array",
"items": {"type": "string"},
},
"step_index": {
"description": "Index of the step to update (0-based). Required for mark_step command.",
"type": "integer",
},
"step_status": {
"description": "Status to set for a step. Used with mark_step command.",
"enum": ["not_started", "in_progress", "completed", "blocked"],
"type": "string",
},
"step_notes": {
"description": "Additional notes for a step. Optional for mark_step command.",
"type": "string",
},
},
"required": ["command"],
"additionalProperties": False,
}
下面我们来看下Plan创建、遍历、更新的整个流程
- 创建初始Plan (create_initial_plan):
- 基于用户Query生成Plan (Steps)。
- Prompt设计的几个亮点关键词: 简洁有力,强调关键里程碑(Key Milestones)、可行动性(Actionable)、清晰度(Clarity)、效率(Efficiency)。
system_message = Message.system_message(
"You are a planning assistant. Create a concise, actionable plan with clear steps. "
"Focus on key milestones rather than detailed sub-steps. "
"Optimize for clarity and efficiency."
)
# Create a user message with the request
user_message = Message.user_message(
f"Create a reasonable plan with clear steps to accomplish the task: {request}"
)
- 效果评估: 生成的Plan结构(Plan-Step两层)清晰,但内容质量(步骤逻辑、并行性)较基础,有优化空间。
- 执行Plan (execute):
- 按顺序遍历Plan中的每个Step。
- 将当前Step标记为in_progress。
- 调用execute_step执行当前Step。
- 执行单个Step (execute_step):
- 为当前Step实例化一个Manus智能体。
- 关键Context注入:这里同时提供全部plan status能解决(一部分)有些步骤模型会发散把多个步骤一起做了导致重复或者冲突的问题。
- 当前任务: "You are now working on step {index}: '{step_text}'"
- 全局状态: "CURRENT PLAN STATUS: {plan_status}" (包含所有Steps的状态)
step_prompt = f"""
CURRENT PLAN STATUS:
{plan_status}
YOUR CURRENT TASK:
You are now working on step {self.current_step_index}: "{step_text}"
Please execute this step using the appropriate tools. When you're done, provide a summary of what you accomplished.
"""
- 所有Plan执行完成进入汇总阶段:会基于原始生成的所有Plan的执行状态,让模型给出一份汇总
Flow的Context管理
- 分层Context: 全局Plan状态 vs. 单个Step执行Context。
- 智能体隔离: 每个Step由独立的Manus智能体执行,其Context主要包含:Plan全局状态 + 当前Step描述 + 当前Step执行历史 (ReAct循环)。
- 状态共享: Plan Status(所有Step状态)作为只读Context传递给每个执行Step的Manus智能体,有助于缓解步骤间冲突。
- 信息传递: Step间不直接共享详细推理/操作Context,仅通过Plan Status的宏观状态(完成/阻塞)和最终结果字符串进行间接传递。
Reference
- how we build our multi-agent system: Claude给出的多智能体构建智能
- Don't build multi-agents:Devin创始人指出的多智能构建中的一些坑
想看更全的大模型论文·微调预训练数据·开源框架·AIGC应用 >> DecryPrompt
AI大模型学习福利
作为一名热心肠的互联网老兵,我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。我已将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
一、全套AGI大模型学习路线
AI大模型时代的学习之旅:从基础到前沿,掌握人工智能的核心技能!
因篇幅有限,仅展示部分资料,需要点击文章最下方名片即可前往获取
二、640套AI大模型报告合集
这套包含640份报告的合集,涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师,还是对AI大模型感兴趣的爱好者,这套报告合集都将为您提供宝贵的信息和启示。
因篇幅有限,仅展示部分资料,需要点击文章最下方名片即可前往获
三、AI大模型经典PDF籍
随着人工智能技术的飞速发展,AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型,如GPT-3、BERT、XLNet等,以其强大的语言理解和生成能力,正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。
因篇幅有限,仅展示部分资料,需要点击文章最下方名片即可前往获
四、AI大模型商业化落地方案
因篇幅有限,仅展示部分资料,需要点击文章最下方名片即可前往获
作为普通人,入局大模型时代需要持续学习和实践,不断提高自己的技能和认知水平,同时也需要有责任感和伦理意识,为人工智能的健康发展贡献力量。