Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,562 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java
Domaine
backend-api-design, testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

🔴 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%)
Langage dominant
Java
Étoiles
1.7k
Forks
421
Merge moyen
3 j 14 h
PR mergées (30 j)
31

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de google/adk-java

Toutes les issues de google/adk-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.