Google ADK-Python项目中Gemini模型工具调用的限制与解决方案

背景与问题现象

在Google Agent Development Kit (ADK) Python项目中，开发者在使用Gemini模型构建多智能体系统时遇到一个关键限制：当主智能体通过sub_agents机制调用子智能体时，如果子智能体配置了内置功能（如google_search），系统会抛出400 INVALID_ARGUMENT错误，提示"Tool use with function calling is unsupported"。

这个问题的本质在于Gemini模型当前版本的功能调用机制限制。当主智能体通过内部函数调用机制激活子智能体后，子智能体在同一交互轮次中尝试使用内置功能时，系统无法处理这种状态转换。

技术原理分析

ADK框架中智能体协作的核心机制是：

1. 主智能体（Orchestrator）通过sub_agents参数配置子智能体列表
2. 框架将这些子智能体作为可调用函数暴露给主智能体的LLM
3. 主智能体通过内部函数调用机制委托任务给子智能体

问题出现在第三步之后：当被调用的子智能体尝试使用内置功能时，Gemini API会拒绝这种嵌套的功能调用模式。这是因为当前Gemini实现中：

• 函数调用和功能调用属于互斥的操作模式
• 不支持从函数调用上下文直接切换到功能调用上下文
• 每个交互轮次只允许单一类型的扩展操作（函数或功能）

解决方案与实践

社区成员KVNAditya提出的有效解决方案是使用AgentTool包装器替代直接的sub_agents配置：

from google.adk import agent_tool

class AgentSearch(LlmAgent):
    def __init__(self):
        super().__init__(
            tools=[google_search],
            # 其他参数...
        )

class AgentOrchestrator(LlmAgent):
    def __init__(self):
        super().__init__(
            tools=[
                agent_tool.AgentTool(agent=AgentSearch()),
                agent_tool.AgentTool(agent=OtherAgent())
            ],
            # 其他参数...
        )

这种方案之所以有效，是因为：

1. AgentTool将子智能体作为独立功能注册
2. 每个功能调用都是独立的交互轮次
3. 避免了函数调用和功能调用的嵌套冲突

深入探讨与最佳实践

对于更复杂的场景，建议采用以下架构模式：

1. 功能隔离原则：为每个独立功能创建专用智能体

   • 搜索专用智能体（仅配置google_search）
   • 代码执行专用智能体（仅配置code_execution）
   • 数据处理专用智能体等

2. 分层调用架构：

   主智能体
   ├─ 搜索代理（功能调用）
   ├─ 代码代理（功能调用）
   └─ 存储代理（函数调用）
   

3. 结果传递机制：

   • 通过智能体间的消息传递处理中间结果
   • 在主智能体层实现结果聚合
   • 使用临时存储解决跨智能体数据共享

未来展望

虽然当前版本存在限制，但这种设计可能源于Gemini模型的安全和性能考量。开发者可以期待未来版本可能带来的改进：

1. 嵌套功能/函数调用支持
2. 更灵活的组合模式
3. 增强的上下文保持能力