Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,562 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
backend-api-design, testing-qa

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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%)
Vorherrschende Sprache
Java
Sterne
1.7k
Forks
421
Ø Merge
3 T. 9 Std.
Gemergte PRs (30 T.)
29

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus google/adk-java

Alle Issues in google/adk-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.