Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

AgentTool runs the wrapped agent with the default RunConfig instead of the caller's

Abierto
  • ¿Algo no está bien?
#1,562 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend-api-design, testing-qa

Línea de trabajo

Start at AgentTool.runAsync and trace how the caller's RunConfig reaches the nested Runner. Use AgentToolTest, including call_propagatesCallerRunConfig, and the TestLlm utilities in core/src/test/java/com/google/adk/testing. Done means the wrapped agent receives the caller's limits, tool mode, and metadata, uses the expected streaming mode, and the tests stop the nested run at the configured limit.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

needs review

🔴 Required Information

Describe the Bug:

AgentTool.runAsync starts the wrapped agent with Runner.runAsync(userId, sessionId, content), the overload that uses RunConfig.builder().build(). So an agent used as a tool always runs with the RunConfig defaults (maxLlmCalls 500, ToolExecutionMode.NONE, empty customMetadata), whatever RunConfig the caller passed to Runner.runAsync. A maxLlmCalls limit set to bound one request does not bound the LLM calls of an agent behind an AgentTool, and toolExecutionMode(SEQUENTIAL) does not reach that agent's tool calls.

Steps to Reproduce:

  1. Check out main (4092a1f).
  2. Give a root LlmAgent an AgentTool that wraps a second LlmAgent whose model keeps calling one of its tools.
  3. Run the root agent with runner.runAsync(userId, sessionId, message, RunConfig.builder().maxLlmCalls(5).build()).

Expected Behavior:

The wrapped agent runs under the caller's RunConfig, so the run stops once the wrapped agent has made 5 LLM calls. adk-python does this since google/adk-python@983c280 ("fix(tools): run an agent tool under the caller's RunConfig"), and runs the wrapped agent in StreamingMode.NONE since google/adk-python@0d5752b, because only the last event of the nested run becomes the tool result.

Observed Behavior:

The wrapped agent gets the default RunConfig. With test doubles for both models (code below), the root agent made 1 LLM call and the wrapped agent 500 before the run failed with LlmCallsLimitExceededException: Max number of llm calls limit of 500 exceeded.

(When the wrapped agent's test model answers on the calling thread instead, main fails earlier with a StackOverflowError, after about 270–290 nested calls in my runs. With the fix, both variants stop after 5.)

Environment Details:

  • ADK Library Version (see maven dependency): main at 4092a1f; the v1.10.1 release has the same AgentTool code. AgentTool has called the three-argument runAsync since it was added in 0.1.0.
  • OS: Windows 11 (not OS-specific)
  • TS Version (tsc --version): N/A (Java: Microsoft OpenJDK 17.0.19; Maven 4.0.0-rc-3 via mvnw)

Model Information:

  • Which model is being used: N/A (reproduced with TestLlm; the call path does not depend on the model)

🟡 Optional Information

Regression:

No.

Logs:

What the wrapped agent receives, from the unit test in the fix (it wraps a test agent that records its InvocationContext; the caller's RunConfig has toolExecutionMode(SEQUENTIAL), maxLlmCalls(7) and customMetadata {tier=x}), run against main:

[ERROR]   AgentToolTest.call_propagatesCallerRunConfig:896 value of: runConfig()
expected: …, toolExecutionMode=SEQUENTIAL, outputAudioTranscription=null, inputAudioTranscription=null, maxLlmCalls=7, autoCreateSession=false, groupFunctionResponsesInHistoryOverride=Optional.empty, customMetadata={tier=x}}
but was : …, toolExecutionMode=NONE, outputAudioTranscription=null, inputAudioTranscription=null, maxLlmCalls=500, autoCreateSession=false, groupFunctionResponsesInHistoryOverride=Optional.empty, customMetadata={}}

Additional Context:

The nested Runner creates its own InvocationContext, so passing the caller's RunConfig bounds the wrapped agent's LLM calls separately from the caller's; that is also how adk-python counts them. I have a fix with unit tests ready and will link the PR here.

Minimal Reproduction Code:

// The wrapped agent's model always asks for echo_tool again. It answers on an RxJava IO thread
// so that the loop on main reaches the LLM-call limit instead of overflowing the stack first.
TestLlm workerLlm =
    createTestLlm(
        () ->
            Flowable.just(
                    createFunctionCallLlmResponse(
                        "worker-call", "echo_tool", ImmutableMap.of("arg", "x")))
                .subscribeOn(Schedulers.io()));
LlmAgent worker =
    LlmAgent.builder()
        .name("worker")
        .description("Keeps calling echo_tool.")
        .model(workerLlm)
        .tools(new EchoTool())
        .build();
TestLlm rootLlm =
    createTestLlm(
        createFunctionCallLlmResponse("root-call", "worker", ImmutableMap.of("request", "go")),
        createTextLlmResponse("done"));
LlmAgent root =
    LlmAgent.builder().name("root").model(rootLlm).tools(AgentTool.create(worker)).build();
InMemoryRunner runner = new InMemoryRunner(root);
Session session = runner.sessionService().createSession(runner.appName(), "user").blockingGet();

runner
    .runAsync(
        "user",
        session.id(),
        Content.fromParts(Part.fromText("hi")),
        RunConfig.builder().maxLlmCalls(5).build())
    .toList()
    .blockingGet();
// Fails with "Max number of llm calls limit of 500 exceeded";
// workerLlm.getRequests().size() is 500, not 5.

(createTestLlm, createFunctionCallLlmResponse, createTextLlmResponse and the nested EchoTool class are in TestUtils, next to TestLlm in core/src/test/java/com/google/adk/testing; Schedulers is io.reactivex.rxjava3.schedulers.Schedulers.)

How often has this issue occurred?:

  • Always (100%)
Lenguaje dominante
Java
Estrellas
1.7k
Forks
421
Merge medio
3 d 9 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/adk-java

Todos los issues de google/adk-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.