什么是代理工作流？类型、模式和示例

如果您曾构建过人工智能代理，您可能会看到这样的情况：您的代理能够很好地处理简单的任务，但在处理复杂任务时却举步维艰。在应该并行运行任务时，它可能会尝试按顺序运行所有任务，或者它可能不知道应该使用哪种工具。有时，它就是无法跟踪多步骤任务中的所有内容。

问题通常不在于代理的智能或提示设计。而是工作流程。代理如何协调、委派和执行任务与代理本身同样重要。了解代理工作流和模式可将基本演示转化为可应对现实世界挑战的系统。

在本文中，我们将解释六种最常见的代理工作流，了解其背后的模式，并向您展示何时使用每一种工作流。

TLDR: Agentic 工作流快速参考

6 个核心工作流：

• 顺序：具有明确依赖关系的分步任务（文档管道、ETL）
• 并行：独立任务同时运行（多源数据聚合）
• 分层：父代理将任务委托给专门的子代理（旅游规划、软件开发）
• 自适应/路由：智能调度员将请求路由到适当的专家（客户支持）
• 协作：同行代理平等工作，结合不同的观点（代码审查、投资分析）
• 协调者-工人：中央协调者管理无状态的工人池（Web 搜索、分布式测试）

5 种基本模式：

• 工具使用：代理通过定义的接口与外部系统进行交互
• 规划：在复杂任务的行动之前制定明确的执行计划
• 路由：智能请求分配，以优化成本和质量
• 反思：针对高风险产出进行迭代批判和改进
• 人在环中：关键决策需要人工批准

关键决策因素：

• 任务依赖性 → 顺序
• 独立子任务 → 并行
• 复杂专业化 → 层次化
• 可变输入 → 自适应
• 多视角分析 → 协作
• 大规模协调 → Orchestrator-Worker

什么是代理工作流？

代理工作流是一种设计代理和工具如何协同完成任务的方法。它就像是人工智能系统的控制流程。它规定了谁做什么、按照什么顺序以及信息如何在各部分之间移动。

代理工作流不同于代理类型或个性设置。例如，"研究代理 "描述的是一种角色，而不是 工作流程。工作流程是研究代理用来分解问题、使用工具、与其他代理协作并产生最终答案的过程。

工作流程为何重要？现实世界中的任务很少只有一个步骤。例如，如果您要求代理 "分析我们第三季度的销售额，并将其与行业基准进行比较"，那么代理需要

• 将请求分解为多个子任务
• 获取内部销售数据
• 搜索行业基准数据
• 处理并比较两个数据集
• 将结果合成为一份连贯的报告

如果没有工作流，您的代理可能会试图同时完成所有任务，但却以失败告终，或者随意调用工具，以求最好的结果。一个好的工作流可为您的系统提供结构和可预测性，帮助其顺利处理故障。

6 个最常见的代理工作流

下面我们将介绍您在构建代理系统时将使用的 6 个最常见的代理工作流。对于每个工作流，我们都将解释其作用、何时使用、何时不使用，并提供实际示例。

Sequential / Prompt Chaining 工作流

Sequential 工作流也称为提示链，任务一个接一个地运行，每一步的输出都将成为下一步的输入。这是最简单、最可预测的工作流模式。它就像一条流水线，每个代理在完成自己的工作后，再移交给下一个代理。

主要优势在于可预测性：您总是知道什么时候会发生什么。如果出错，您可以轻松找到哪个步骤失败了。例如，在内容创建流水线中，一个代理研究一个主题，另一个代理起草一篇文章，第三个代理对其进行编辑，最后一个代理对其进行格式化以便出版。

// 研究代理
const researchAgent = new LlmAgent({
  name: "research_agent"、
  description："深入研究主题"、
  指令："查找并总结给定主题的关键信息"、
  工具[new GoogleSearch()]、
  模型"gemini-2.5-flash"、
});

// 编写代理
const writerAgent = new LlmAgent({
  name: "writer_agent"、
  description："根据研究撰写文章"、
  指令："使用所提供的研究成果撰写一篇结构合理的文章"、
  模式："gpt-4o"、
});

// 编辑器代理
const editorAgent = new LlmAgent({
  name: "editor_agent"、
  description："编辑和润色内容"、
  指令："提高清晰度、修正语法并确保语气一致"、
  model："claude-sonnet-4"、
});

// 顺序工作流程
const contentPipeline = AgentBuilder.create("content_pipeline")
  .withDescription(
    "通过研究、写作和编辑代理按顺序处理内容的管道"
  )
  .withInstruction( `分阶段处理内容：
    1. 研究代理：研究主题并总结研究结果
    2. writer_agent：根据研究结果撰写文章
    3. editor_agent：编辑和润色文章以供发表`)
  .asSequential([researchAgent, writerAgent, editorAgent])
  .build();

顺序工作流最适用于具有明确依赖关系的任务，其中每个步骤都建立在前一个步骤的基础上。

当任务是独立的或速度至关重要时，您应该跳过这种方法，因为它的线性特性可能会造成瓶颈。

Parallel Execution 工作流

并行工作流同时运行多个独立任务，然后合并其结果。这种方法在任务互不依赖的情况下效果最佳。

关键是要知道任务何时真正独立。并行工作流最适合 I/O 绑定操作，例如 API 调用或数据库查询，在这些操作中，网络延迟是主要问题。

例如，一个市场调研系统同时查询新闻 API、金融数据库和社交媒体，然后将结果合并为一份报告，以最慢来源的时间完成，而不是所有来源的时间总和。

// 新闻分析代理
const newsAgent = new LlmAgent({
  name: "news_agent"、
  description："分析新闻文章以了解市场情绪"、
  工具：[new GoogleSearch()]、
  model："gemini-2.5-flash"、
});

// 金融数据代理
const financeAgent = new LlmAgent({
  name: "finance_agent"、
  description："Fetches and analyzes financial metrics"、
  工具[new HttpRequestTool()]、
  model："gpt-4o"、
});

// 社交情感代理
const socialAgent = new LlmAgent({
  name: "social_agent"、
  description："Analyzes social media sentiment"、
  工具：[new GoogleSearch()]、
  model："claude-sonnet-4"、
});

// 并行工作流程
const marketResearch = AgentBuilder.create("market_research")
    .withDescription("通过并行分析新闻、金融数据和社会情绪进行市场研究")
    .withInstruction(` 同时从多个来源收集和分析数据：
      - news_agent：分析最近的新闻文章，了解市场情绪
      - finance_agent：获取并分析关键财务指标
      - social_agent：分析社交媒体上的市场情绪`)
  .asParallel([newsAgent, financeAgent, socialAgent])
  .build();

并行执行在任务真正独立、速度胜过成本的情况下大放异彩。

当任务相互依赖或需要严格排序时，请避免使用这种模式，因为无法预测的完成时间将使调试成为一场噩梦。

Hierarchical 工作流

Hierarchical 工作流将复杂任务分解为更小的子任务，由父代理将工作分配给专门的子代理。这就形成了一个树状结构，类似于组织处理大型项目的方式。

当问题可以被划分为明确的领域，并且没有一个代理具备所有所需的知识或工具时，这种模式的效果最佳。这是一种 "分而治之 "的方法：协调者负责管理流程，而专家则负责各自的部分。层次结构可以有多个层次，从而使系统更易于理解、测试和扩展。

一个旅行计划系统展示了这种方法的实际应用。根代理委托给航班、酒店和活动专家，每个专家可进一步委托给特定于供应商的子代理，所有结果都将回流到创建综合行程的过程中。 const flightAgent = new LlmAgent({ name: "flight_agent"、 description："搜索和预订航班"、 工具：[new GoogleSearch(), new HttpRequestTool()]、 model："gpt-4o"、 }); // 酒店预订代理 const hotelAgent = new LlmAgent({ name: "hotel_agent"、 description："搜索和预订酒店"、 工具[new GoogleSearch(), new HttpRequestTool()]、 model："gpt-4o"、 }); // 活动代理 const activitiesAgent = new LlmAgent({ name: "activities_agent"、 description："推荐当地活动和景点"、 tools：[new GoogleSearch()]、 model："gemini-2.5-flash"、 }); // 根旅行规划器 const travelPlanner = AgentBuilder.create("travel_planner") .withDescription("Plans complete travel itineraries") .withInstruction(` 您是一名旅行协调员。分析用户请求并委派： - 航班搜索委托给 flight_agent - 酒店搜索交给 hotel_agent - 向活动代理推荐活动 协调所有次级代理并编制全面的旅行计划。） .withSubAgent([flightAgent, hotelAgent, activitiesAgent]) .withModel("claude-sonnet-4") .build();

对于自然划分为专门领域的复杂问题，可选择分层工作流。

当任务不需要专业化或协调开销大于收益时，请坚持使用更简单的模式。

Adaptive / Dynamic Routing 工作流

Adaptive 工作流或动态路由工作流可根据输入特征在运行时决定由哪个代理处理每个请求。执行路径不是预先确定的，而是遵循 "智能调度器 "模式。

与委托给多个代理的分层工作流不同，自适应工作流将每个请求准确地路由到一个合适的处理程序。这就实现了高效的资源分配：简单的查询交给成本较低的模型，专业的任务交给领域专家。经过精心设计的路由可提高成本效率和质量。

考虑一个客户支持系统，该系统分析票单内容，并根据票单是否提及付款、错误或产品功能，将票单路由至计费、技术支持或销售。 const billingAgent = new LlmAgent({ name: "billing_agent"、 description："处理账单和付款查询"、 说明："协助用户处理发票、付款、退款和订阅问题"、 型号"gpt-4o"、 }); // 技术支持代理 const techAgent = new LlmAgent({ name: "tech_agent"、 description："提供技术支持"、 说明"帮助用户解决产品技术问题"、 工具[new GoogleSearch()]、 型号"claude-sonnet-4"、 }); // 销售代理 const salesAgent = new LlmAgent({ name: "sales_agent"、 description："Handles sales inquiries"、 说明："回答有关功能、定价和产品性能的问题"、 型号"gemini-2.5-flash"、 }); // 自适应路由器 const supportRouter = AgentBuilder.create("support_router") .withDescription("Routes support requests to specialized agents") .withInstruction(` 分析用户信息并将其路由到相应的代理： - 账单问题（付款、退款、发票） → 账单代理 - 技术问题（漏洞、错误、故障排除）→ 技术代理 - 产品问题（功能、定价、性能）→ sales_agent 根据请求内容选择最合适的代理。） .withSubAgent([billingAgent, techAgent, salesAgent]) .withModel("gpt-4o") .build();

当输入差异很大且成本优化很重要时，自适应路由就很有意义。

如果您需要可预测的行为，或者路由逻辑的成本高于其节省的成本，则不应使用自适应路由。

Collaborative / Multi-agent 工作流

顾名思义，Collaborative 工作流或多代理工作流涉及多个代理平等地共同处理一个共享问题。与分层工作流不同，这里没有上司和下属的关系。同级代理可以提供不同的观点，从而产生比任何单个代理更强大的解决方案。

强大之处在于将不同的观点结合在一起。安全专家代理会看到性能优化代理可能会忽略的漏洞。

代码审查系统完美地诠释了这一点。安全、性能和风格代理都会独立审查相同的代码，每个代理都会提供专门的审查结果，以创建全面的多角度审查。

// 安全审查员
const securityAgent = new LlmAgent({
  name: "security_agent"、
  description："审查代码是否存在安全漏洞"、
  指令："识别安全问题，如 SQL 注入、XSS、认证绕过和数据泄露、
  模型："claude-sonnet-4"："claude-sonnet-4"、
});

// 性能审查员
const performanceAgent = new LlmAgent({
  name: "performance_agent"、
  description："Review code for performance issues"、
  指令："识别性能瓶颈、低效算法和优化机会"、
  model："gpt-4o"、
});

// 样式审查员
const styleAgent = new LlmAgent({
  name: "style_agent"、
  description："审查代码的风格和最佳实践"、
  指令："检查是否违反代码风格、命名约定和 TypeScript 最佳实践"、
  model："gemini-2.5-flash"、
});

// 协作审查工作流程
const codeReviewTeam = AgentBuilder.create("code_review_team")
  .withDescription("Collaborative code review system")
  .withInstruction(` 您是代码审查团队的一员。
    每个代理都会独立审查相同的代码：
    - security_agent 专注于安全漏洞
    - performance_agent 专注于性能问题
    - style_agent 专注于代码风格和最佳实践
    将所有发现合并为一份综合审查报告。）
  .asParallel([securityAgent, performanceAgent, styleAgent])
  .build()；
`;

当不同的视角能带来真正的价值时，协作方法就能很好地发挥作用--想想投资分析、内容管理和招聘决策。

如果您可以使用单个专家代理，或者协调开销大于收益，或者多种意见造成的问题多于解决的问题，则请勿使用此工作流。

Orchestrator-Worker 工作流

Orchestrator-Worker 工作流使用中央协调器来管理 Worker 代理池。

这种分离带来了强大的优势：协调器负责协调（任务分配、负载平衡、重试逻辑），而工作者则专注于执行。您可以水平扩展 Worker，而无需触及协调逻辑。

想象一下文档处理系统：协调器接收混合文件类型，分析每种类型，动态地将 PDF 分配给 PDF Worker，将图像分配给 OCR Worker，将电子表格分配给数据 Worker，然后将结果编译成统一格式。

// PDF 处理器 Worker
const pdfWorker = new LlmAgent({
  name: "pdf_worker"、
  description："从 PDF 文件中提取文本和元数据"、
  工具[new HttpRequestTool()]、
  model："gpt-4o"、
});

// 图像处理器工作者
const imageWorker = new LlmAgent({
  name: "image_worker"、
  description："使用 OCR 从图像中提取文本"、
  工具[new HttpRequestTool()]、
  model："claude-sonnet-4"、
});

// 电子表格处理器工作者
const spreadsheetWorker = new LlmAgent({
  name: "spreadsheet_worker"、
  description："从 Excel 和 CSV 文件中提取数据"、
  工具[new HttpRequestTool()]、
  model："gemini-2.5-flash"、
});

// 协调器
const documentOrchestrator = AgentBuilder.create("document_orchestrator")
  .withDescription("Coordinates document processing across specialized workers")
  .withInstruction(` 您是文档处理协调者。
    分析每种文档类型并将其委托给相应的 Worker：
    - PDF 文件 → pdf_worker
    - 图像文件（JPG、PNG）→image_worker
    - 电子表格（XLS、XLSX、CSV）→电子表格工作员
    跟踪进度并将所有提取的数据编译成统一格式。）
  .withSubAgents([pdfWorker, imageWorker, spreadsheetWorker])
  .withModel("gpt-4o")
  .build();

协调器-工作者工作流擅长管理大规模并行工作，例如网络刮削、批量数据处理和分布式测试执行。

但是，如果您运行的是一个仅有几个代理的简单系统，那么这种工作流程就会显得过于繁琐，而当协调器成为一个关键故障点时，这种工作流程就会变得非常危险。

Agentic 工作流程比较表

最适合优点缺点何时不使用实际示例

顺序/提示连锁分步任务简单，确定性慢，线性瓶颈任务独立时文档流水线、ETL 流程 并行独立任务快速、可扩展难以协调当顺序很重要时多源聚合、批处理 分层复杂分解自然任务分解管理费用当任务简单时旅行计划、软件开发 自适应/动态可变输入灵活路由不可预测的执行需要严格控制时客户支持路由、电子邮件分流 协作/多代理多角度问题多样化的专业知识协调复杂性当代理发生冲突时代码审查、投资分析 协调者-工作者分布式处理明确协调单点故障当系统很小时网络搜刮、测试执行

Agentic Workflows 内部的常见模式

既然我们已经了解了工作流（架构），那么让我们来看看模式（行为）。模式是可在任何工作流中使用的可重用技术。工作流定义了结构，而模式定义了行为。以下是代理工作流程中最常用的一些模式：

工具使用模式

工具使用模式使代理能够通过定义的接口与外部系统交互。工具将代理从仅限于训练数据的聊天机器人转变为可查询数据库、调用 API 和搜索网络的行动系统。

这是最基本的模式。没有工具，代理就无法访问实时数据或特定业务数据。智能在于座席人员确定何时使用工具、使用哪种工具以及如何从自然语言中提取正确的参数。

示例：客户服务代理分析了 "订单 #12345 的状态如何？"，认识到它需要数据库访问，选择 query_database_tool工具，提取订单 ID，获取订单详细信息，并将实时数据纳入其答案；
import * as z from "zod"；

// 模拟数据库连接
const database = {
query: async (sql: string, params: any[]) => {
// 模拟响应
return { id: params[0], email："user@example.com"};
},
};

// 自定义数据库查询工具
const databaseTool = createTool({
name: "query_database_tool"、
description："查询客户数据库中的用户信息"、
schema: z.object({
userId：z.string().describe("The user ID to query")、
fields: z.array(z.string()).describe("Fields to retrieve")、
}),
fn: async ({ userId, fields }) => {
// 在生产过程中，这将影响实际数据库
const user = await database.query(
SELECT ${fields.join(",")}FROM users WHERE id = ?`、
[用户 ID］
);
返回 JSON.stringify(user)；
},
});

// 带有工具的代理
const customerAgent = new LlmAgent({
name: "customer_agent"、
description："提供客户信息"、
工具[databaseTool]、
model："gpt-4o"、
});

export const getRootAgent = async () => {
const { runner } = await AgentBuilder.create("root_agent")
.withSubAgent([customerAgent])
.build()；

const result = await runner.ask(
"用户 ID 12345 的电子邮件地址是什么？
);
console.log(result)；
};

当代理需要实时数据或必须执行文本生成以外的操作时，工具就变得必不可少。

Planning Pattern

规划模式让代理在采取行动前创建明确的执行计划--即 "先看后跳 "方法。复杂的任务可从前期分解中获益，就像人类在编码前绘制架构草图一样。

规划可产生可见的、可检查的策略，您可在产生执行成本前对其进行验证。这种透明度有助于尽早发现逻辑错误，并使调试变得更加容易。代价是延迟--您将在实际工作发生之前增加一个规划阶段。

示例：一个研究代理创建了一个计划（搜索文档 → 查找对比分析 → 找出差异 → 查找示例 → 综合），然后执行每个步骤，并在初始结果表明查询需要改进时进行调整。

import { LlmAgent, AgentBuilder, GoogleSearch } from "@iqai/adk"；

const plannerAgent = new LlmAgent({
  name: "planner_agent"、
  description："创建并执行研究计划"、
  instruction: `给定一个研究问题时：
    1.首先，创建包含具体步骤的详细研究计划
    2.为每个步骤确定需要查找的信息
    3.使用现有工具逐步执行计划
    4.将结果综合成一个全面的答案
    在执行计划之前，一定要先展示你的计划、
  工具：[new GoogleSearch()]、
  model："claude-sonnet-4"、
});

export const getRootAgent = async () => {
  const { runner } = await AgentBuilder.create("root_agent")
    .withSubAgents([plannerAgent])
    .build()；

  const result = await runner.ask(
    "React 服务器组件与传统 React 组件的主要区别是什么？
  );
  console.log(result)；
};

规划模式在复杂的多步骤任务中真正发挥了作用，在这些任务中，提前思考可提高结果。

路由模式

路由模式可智能地将请求引导至最合适的处理程序--即代理系统的流量控制器。

智能路由通过分析请求特征（意图、复杂性、领域）并将其引导至最合适的处理程序，从而优化了这种异质性。

例如，您可将 "什么是 TypeScript？"路由至快速、廉价的模型，但将 "比较 TypeScript 与 Flow 类型推理 "路由至功能更强的模型，从而优化质量和成本。

import { LlmAgent, AgentBuilder } from "@iqai/adk"；

// 简单查询代理
const quickAgent = new LlmAgent({
  name: "quick_agent"、
  description："处理简单明了的查询
  model："gemini-2.5-flash", // 更快、更便宜的模型
});

// 复杂查询代理
const deepAgent = new LlmAgent({
  name: "deep_agent"、
  description："处理复杂的多步骤查询"、
  model："claude-sonnet-4", // 能力更强的模型
});

export const getRootAgent = async () => {
  // 具有复杂性检测功能的路由器
  const routerAgent = AgentBuilder.create("router_agent")
    .withDescription("Routes queries based on complexity")
    .withInstruction(
      分析每个查询并适当路由：
    - 简单的事实性问题、定义、基本信息 → quick_agent
    - 复杂分析、多步骤推理、研究 → 深度代理
    考虑一下：是否需要深入思考？多步骤？细致入微的分析？
    )
    .withSubAgent([quickAgent, deepAgent])
    .withModel("gpt-4o")
    .build()；

  const { runner } = await routerAgent；

  // 这将路由到 quick_agent
  const simple = await runner.ask("What is TypeScript?")；

  // 这将路由到 deep_agent
  const complex = await runner.ask(
    "比较 TypeScript 和 Flow 中的类型推理，考虑边缘情况和性能
  );
};

当工作负载在复杂性上存在显著差异时，使用智能路由将为您节省大量资金，但如果您的所有查询都需要类似的工作流，或者如果错误造成的损失大于节省的资金，则不应使用路由模式。

Reflection Loop / Evaluator-Optimizer 模式

反射模式要求代理评估其输出并反复改进，强调自我修正和 "测量两次，削减一次 "的原则。

通过添加明确的批评和修订，您可以在提高质量的同时增加延迟和 API 调用。批评者根据既定的标准（如正确性、效率和安全性）进行评估，并提供可行的反馈。然后，生成器进行相应的修改，从而建立一个改进循环。

示例：

从"@iqai/adk "导入 { LlmAgent, AgentBuilder }；

// 生成器代理
const generatorAgent = new LlmAgent({
  name: "generator_agent"、
  description："从自然语言生成 SQL 查询"、
  指令："将用户请求转换为 SQL 查询"、
  model："gpt-4o"、
});

// 评论员代理
const criticAgent = new LlmAgent({
  name: "critic_agent"、
  description："评估 SQL 查询质量"、
  instruction: `Evaluate SQL queries for：
      - 正确性（是否符合请求？）
      - 效率（是否有更好的方法？）
      - 安全性（SQL 注入风险？）
      - 最佳实践（适当的 JOIN、索引考虑？）
      如果发现问题，提供具体的改进反馈、
  模型："claude-sonnet-4"、
});

export const getRootAgent = async () => {
  // 根代理（协调器）
  const rootAgent = AgentBuilder.create("reflection_workflow")
    .withDescription("SQL 查询生成与迭代改进")
    .withInstruction(
      "您负责管理 SQL 生成过程。将生成委托给生成器代理，将评估委托给批判者代理"。
    )
    .withSubAgents([generatorAgent, criticAgent])
    .withModel("gpt-4o")
    .build()；

  const { runner } = await rootAgent；

  // 反射工作流逻辑
  const request =
    "获取上个月购物金额超过 1000 美元的所有用户"；
  const maxIterations = 3；

  // 第 1 步：生成初始查询
  let currentQuery = await runner.ask(`Generate SQL query for: ${request}`)；
  let iteration = 0；

  while (iteration < maxIterations) {
    // 第 2 步：批判
    const critique = await runner.ask(
      Evaluate this SQL query:/n${currentQuery}\n\nOriginal request: ${request}`
    );

    if (critique.includes("APPROVED") || critique.includes("looks good")) {
      console.log("Query approved!")；
      返回 currentQuery；
    }

    // 第 3 步：改进
    currentQuery = await runner.ask(
      `Improve this query based on feedback:\n${currentQuery}\n\nFeedback: ${critique}`).
    );
    iteration++；
  }

  return currentQuery；
};

反射循环适用于具有明确质量标准的高风险输出。

Human-in-the-Loop 模式

human-in-the-loop模式会在关键点暂停代理执行，以请求人工输入或批准。它将人工智能自动化与人工判断相结合，以处理对自主代理而言过于重要的决策，例如金融交易、内容发布和数据删除。

人工智能处理繁琐的工作，而人工则对重大决策做出最终决定。

一个例子是，内容代理负责研究、起草和格式化一篇文章，然后暂停，将草稿提交给人类编辑，由人类编辑审查其准确性和语气，批准或要求修改，而代理则根据该决定行事。

import * as z from "zod"；
import * as readline from "readline"；
import { createTool, AgentBuilder } from "@iqai/adk"；

// 人工审批工具
const requestApprovalTool = createTool({
  name: "request_approval_tool"、
  description："在执行操作前请求人工批准"、
  schema: z.object({
    action: z.string().describe("The action requiring approval")、
    context: z.string().describe("Context and reasoning for the action")、
    risk_level: z
      .枚举（["低"、"中"、"高"])
      .describe（"行动的风险等级"）、
  }),
  fn: async ({ action, context, risk_level }) => {
    console.log("\n🚨 HUMAN APPROVAL REQUIRED 🚨")；
    console.log(`Action: ${action}`)；
    console.log(`Context: ${context}`)；
    console.log(`Risk Level: ${risk_level}`)；

    const rl = readline.createInterface({
      输入：process.stdin、
      输出：process.stdout、
    });

    const response = await new Promise<string>(resolve => {
      rl.question("/nApprove this action?(是/否/修改）："，答案 => {
        rl.close()；
        resolve(answer.toLowerCase())；
      });
    });

    if (response === "yes") {
      返回 "已批准：继续执行操作"；
    } else if (response === "no") {
      返回 "拒绝：不继续执行操作"；
    } else {
      返回 "修改：根据人工反馈提供替代方法"；
    }
  },
});

// 有人类参与的内容发布代理
export const getRootAgent = async () => {
  const contentPublisherAgent = AgentBuilder.create("content_publisher_agent")
    .withDescription("Publishs content with human approval")
    .withInstruction(
      您可以帮助将内容发布到产品中。
      在发布之前，请务必使用 request_approval_tool 获得人工审核。
      请提供清晰的上下文，说明您要发布的内容和原因。
      只有在收到 APPROVED 状态后才能继续。
    )
    .withTools(requestApprovalTool)
    .withModel("gpt-4o")
    .build()；

  const { runner } = await contentPublisherAgent；

  // 示例用法：经人工批准后起草和发布内容
  const result = await runner.ask(
    "起草并发布一篇关于我们新功能的博文"
  );

  console.log("Final result:", result)；
  返回结果；
选择正确的代理工作流选择正确的工作流至关重要。错误的选择会导致不必要的复杂性和较差的性能。以下是一个实用框架：从任务结构入手。在考虑技术之前先分析问题。它有明确的顺序吗？独立的子任务？专业领域？选择适合的工作流程。避免过度工程化。如果顺序链就足够了，就不要跳到分级授权。 在适当的时候合并工作流。真实系统通常使用多个工作流，不要将所有事情都强加到一种模式中。从简单开始。如果有疑问，请从顺序或并行工作流开始。考虑操作限制。考虑可调试性、延迟预算、成本敏感性和监督需求。Building Blocks of Agentic WorkflowsEvery agentic workflow combines five fundamental components:图 9：代理工作流的五大构件：代理、工具、上下文、状态和控制流代理是您的推理引擎--配置了特定指令和功能的 LLM。 工具将代理的功能扩展到文本生成之外。工具可让代理查询数据库、调用 API、搜索网络并与外部系统交互。上下文是代理工作时使用的信息--对话历史、以前的输出和相关文档。有效的工作流可以控制代理之间的上下文流。状态跟踪您在工作流中所处的位置--哪些代理已经运行、他们产生了什么结果以及接下来会发生什么。这对于错误处理和恢复至关重要。控制流决定执行顺序--哪些代理在何时、何种条件下运行。ADK-TS等现代框架可处理复杂的协调工作，从而让您专注于设计工作流逻辑，而不是从头开始构建基础架构。Conclusion代理工作流是决定您的代理系统能否处理现实世界复杂性或在压力下崩溃的支柱。通过熟悉六种主要工作流和五种基本模式，您将掌握创建智能、可管理的系统的知识和诀窍。现实世界中的系统通常将多种工作流和模式融合在一起。使用分级授权来利用专业知识，并行运行任务来提高速度，添加反射循环来提高质量，并在涉及安全问题时在循环中加入人工。这些构建模块旨在相互配合，因此您可以根据需要将它们混合在一起。想要应用您刚刚学到的知识吗？ADK-TS 框架包含这些工作流和模式的现成版本。您可以浏览示例目录，从模板开始，或者深入研究文档。 真正有效的代理系统并不是拥有最华丽或最复杂的工作流的系统，而是工作流真正与任务相匹配、模式能够解决实际问题、开发人员知道何时以及为何使用每种方法的系统。Further Reading & Useful Resources 如果您想进一步了解代理系统、工作流和人工智能工具，以下是一些有用的资源：使用 ADK-TS 在 TypeScript 中构建您的第一个人工智能代理 https://blog.iqai.com/build-ai-agent-in-typescript-with-adk-ts/ 学习提示工程基础https://cloud.google.com/discover/what-is-prompt-engineering 理解现代人工智能系统中的工作流https://www.ibm.com/think/topics/workflow 为人工智能代理设计有效的编写工具 https://www.anthropic.com/engineering/writing-tools-for-agents 如何设计多代理智能系统 https://developer.microsoft.com/blog/designing-multi-agent-intelligence Anthropic 如何构建其多代理研究系统 https://www.anthropic.com/engineering/multi-agent-research-system