Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,562 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend-api-design, testing-qa

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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%)
Ngôn ngữ chính
Java
Star
1.7k
Fork
421
Merge trung bình
3 ngày 9 giờ
Pull request đã merge (30 ngày)
29

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của google/adk-java

Tất cả issue của google/adk-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.