mirror of
https://github.com/google/adk-docs.git
synced 2026-09-14 16:16:59 +08:00
Amaad Martin
c75e61f5f3
The site rendered one language under two names. Tab labels were split 137 `TypeScript` / 53 `Typescript`, with three pages carrying both spellings at once (custom-agents.md 7/7, patterns.md 1/7, function-tools.md 4/1), and the language-support badges were split 67/18 the same way. Because pymdownx.tabbed slugifies tab labels to lowercase, both variants rendered and linked fine, so no link check or build warning ever flagged it -- it was visible only to readers, as two names for one SDK. Every user-visible occurrence is normalized to `TypeScript`, plus the two inconsistencies that turned up while doing it. 80 changed lines, accounted for exactly: 53 tab label === "Typescript" -> === "TypeScript" 18 badge span lst-typescript">Typescript -> TypeScript 3 prose mention cloud-run.md, mcp-tools.md, workflows/patterns.md 2 api-reference/index.md card heading and link text 1 badge div attr title="...Python and Typescript." 1 mkdocs.yml nav Typescript ADK -> TypeScript ADK 1 code fence ```javascript -> ```typescript on a .ts include 1 artifacts/index.md closing summary sentence --- 80 The first six rows are pure casing: 78 lines that differ from their originals by nothing but `Typescript` -> `TypeScript`. The last two are not, and are the reason this is not a `sed`: llm-agents.md:872 fenced `--8<-- ".../capital_agent.ts"` as ```javascript. It was the only javascript-fenced `.ts` include in docs/ (the other 189 TypeScript fences are correct), and it cost that one snippet its TypeScript highlighting. artifacts/index.md:1084 closed the page by naming languages and got the list wrong. It described reaching the artifact methods "using Python's context objects or directly interacting with the `BaseArtifactService` in Java" -- a two-language enumeration at the end of a page that carries Python, TypeScript, Go, Java and Kotlin tabs (11/10/10/10/11), and one that contradicts :556, which correctly names four of them. The enumeration is dropped rather than extended: the sentence now describes the two ways to reach these methods -- through the context object, or through `BaseArtifactService` -- which is what the page actually teaches and does not rot when a sixth language is added. docs/api-reference/index.md is included even though the rest of docs/api-reference/ is generated output that must not be touched. That tree holds 3,140 generated HTML files and exactly one hand-authored page: this one. It is Markdown, it is the only api-reference entry mkdocs.yml lists as `.md` rather than `index.html` (:272, :441), it uses Material `grid cards` and `:fontawesome-*:` shortcodes, and it carries a `CONTRIBUTORS:` note citing issues #1716 and #1717. Its TypeScript card already said "TypeScript" twice in its body text while its heading and link text said "Typescript"; those two are now consistent with the body. No generated file is modified. Not in this change: the broken `SseConnectionParams` sample in mcp-tools.md (docs-ts/p6c-mcp-ts-sample) and the `@google/adk` example version bumps (docs-ts/p6b-example-versions). Only the casing of the prose line above that sample is touched here. Verified: `mkdocs build` exits 0 with an empty warning set on both main and this branch, and the two warning sets are identical. A rendered before/after diff of the whole site shows every `__tabbed_*` id, every tab radio id and every heading anchor unchanged. Zero `=== "Typescript"` and zero `lst-typescript">Typescript` remain anywhere in the repo. Co-authored-by: Amaad Martin <amaadmartin@google.com>
85 lines
3.7 KiB
Markdown
85 lines
3.7 KiB
Markdown
# Sequential template workflow agent
|
|
|
|
<div class="language-support-tag">
|
|
<span class="lst-supported">Supported in ADK</span><span class="lst-python">Python v0.1.0</span><span class="lst-typescript">TypeScript v0.2.0</span><span class="lst-go">Go v0.1.0</span><span class="lst-java">Java v0.2.0</span>
|
|
</div>
|
|
|
|
The ***SequentialAgent*** class is a [template workflow](/agents/workflow-agents/)
|
|
agent that executes its sub-agents in the order they are specified in a list.
|
|
Use ***SequentialAgent*** when you want execution to occur in a fixed, strict
|
|
order. As with other templated workflows, the execution of a
|
|
***SequentialAgent*** object is not controlled by an AI model, and is
|
|
deterministic in how it executes its sub-agents. The sub-agents specified in the
|
|
sequential execution set may or may not utilize AI models, but the overall
|
|
execution of those sub-agents is ultimately managed by the ***SequentialAgent***
|
|
object you define.
|
|
|
|
!!! note "Alternative: graph-based workflows"
|
|
|
|
Starting in ADK 2.0 for Python and Go, templated workflows have been superseded
|
|
|
|
by more flexible workflow structures, including
|
|
[graph-based workflows](/graphs/) and
|
|
[dynamic workflows](/graphs/dynamic/).
|
|
|
|
### Example scenario
|
|
|
|
You want to build an agent that can summarize any webpage, using two tools:
|
|
**Get Page Contents** and **Summarize Page**. Since the agent must always call
|
|
**Get Page Contents** before calling **Summarize Page**, you can build your
|
|
agent using the ***SequentialAgent*** class.
|
|
|
|
### How it works
|
|
|
|
When the `SequentialAgent`'s `Run Async` method is called, it performs the following actions:
|
|
|
|
1. **Iteration:** It iterates through the sub agents list in the order they were provided.
|
|
2. **Sub-Agent Execution:** For each sub-agent in the list, it calls the sub-agent's `Run Async` method.
|
|
|
|
{: width="600"}
|
|
|
|
!!! note "Shared Invocation Context"
|
|
The `SequentialAgent` passes the same `InvocationContext` to each of its
|
|
sub-agents. This means they all share the same session state, including the
|
|
temporary (`temp:`) namespace, making it easy to pass data between steps within
|
|
a single turn.
|
|
|
|
### Full Example: Code Development Pipeline
|
|
|
|
Consider a simplified code development pipeline:
|
|
|
|
* **Code Writer Agent:** An LLM Agent that generates initial code based on a specification.
|
|
* **Code Reviewer Agent:** An LLM Agent that reviews the generated code for errors, style issues, and adherence to best practices. It receives the output of the Code Writer Agent.
|
|
* **Code Refactorer Agent:** An LLM Agent that takes the reviewed code, and the reviewer's comments, and refactors it to improve quality and address issues.
|
|
|
|
Using a `SequentialAgent` makes it simple to define this exection flow, as shown
|
|
in the following code snippet:
|
|
|
|
```py
|
|
SequentialAgent(sub_agents=[CodeWriterAgent, CodeReviewerAgent, CodeRefactorerAgent])
|
|
```
|
|
|
|
This ensures the code is written, *then* reviewed, and *finally* refactored, in a strict, dependable order. **The output from each sub-agent is passed to the next by storing them in state via [Output Key](/agents/llm-agents/##data-handling)**.
|
|
|
|
???+ "Code"
|
|
|
|
=== "Python"
|
|
```py
|
|
--8<-- "examples/python/snippets/agents/workflow-agents/sequential_agent_code_development_agent.py:init"
|
|
```
|
|
|
|
=== "TypeScript"
|
|
```typescript
|
|
--8<-- "examples/typescript/snippets/agents/workflow-agents/sequential_agent_code_development_agent.ts:init"
|
|
```
|
|
|
|
=== "Go"
|
|
```go
|
|
--8<-- "examples/go/snippets/agents/workflow-agents/sequential/main.go:init"
|
|
```
|
|
|
|
=== "Java"
|
|
```java
|
|
--8<-- "examples/java/snippets/src/main/java/agents/workflow/SequentialAgentExample.java:init"
|
|
```
|