Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,562 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend-api-design, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🔴 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%)
Lingua principale
Java
Stelle
1.7k
Fork
421
Merge medio
3g 14h
PR unite (30g)
31

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di google/adk-java

Tutte le issue di google/adk-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.