AI-Agent 白皮书 1 - Introduction to Agents whitepaper

Introduction to Agents

Agents are the natural evolution of Language Models, made useful in software.

代理是语言模型的自然演进，在软件中变得有用。

From Predictive AI to Autonomous Agents

从预测性 AI 到自主代理

Artificial intelligence is changing. For years, the focus has been on models that excel at passive, discrete tasks: answering a question, translating text, or generating an image from a prompt. This paradigm, while powerful, requires constant human direction for every step. We’re now seeing a paradigm shift, moving from AI that just predicts or creates content to a new class of software capable of autonomous problem-solving and task execution.

人工智能正在发生变化。多年来，重点一直放在擅长被动、离散任务的模型上：回答问题、翻译文本或根据提示生成图像。这种范式虽然强大，但每一步都需要持续的人工指导。我们现在正在看到范式转变，从仅仅预测或创建内容的 AI 转向一类能够自主解决问题和执行任务的新软件。

This new frontier is built around AI agents. An agent is not simply an AI model in a static workflow; it’s a complete application, making plans and taking actions to achieve goals. It combines a Language Model’s (LM) ability to reason with the practical ability to act, allowing it to handle complex, multi-step tasks that a model alone cannot. The critical capability is that agents can work on their own, figuring out the next steps needed to reach a goal without a person guiding them at every turn.

这个新前沿是围绕 AI 代理构建的。代理不仅仅是静态工作流中的 AI 模型；它是一个完整的应用程序，制定计划并采取行动以实现目标。它结合了语言模型 (LM) 的推理能力和行动的实际能力，使其能够处理模型本身无法处理的复杂、多步骤任务。关键能力是代理可以独立工作，无需人工在每一步进行指导，就能找出实现目标所需的下一步。

This document is the first in a five-part series, acting as a formal guide for the developers, architects, and product leaders transitioning from proofs-of-concept to robust, production-grade agentic systems. While building a simple prototype is straightforward, ensuring security, quality and reliability is a significant challenge. This paper provides a comprehensive foundation:

• Core Anatomy: Deconstructing an agent into its three essential components: the reasoning Model, actionable Tools, and the governing Orchestration Layer.

• A Taxonomy of Capabilities: Classifying agents from simple, connected problem-solvers to complex, collaborative multi-agent systems.

• Architectural Design: Diving into the practical design considerations for each component, from model selection to tool implementation.

• Building for Production: Establishing the Agent Ops discipline needed to evaluate, debug, secure, and scale agentic systems from a single instance to a fleet with enterprise governance.

Building on the previous Agents whitepaper1 and Agent Companion2; this guide provides the foundational concepts and strategic frameworks you will need to successfully build, deploy, and manage this new generation of intelligent applications which can reason, act and observe to accomplish goals3.

本文档是五部分系列中的第一部分，作为开发人员、架构师和产品负责人从概念验证过渡到健壮、生产级代理式系统的正式指南。虽然构建一个简单的原型很简单，但确保安全性、质量和可靠性是一项重大挑战。本文提供了全面的基础：

• 核心解剖： 将代理分解为三个基本组件：推理模型、可操作工具和管理编排层。

• 能力分类： 将代理从简单的互联问题解决器分类到复杂的协作式多代理系统。

• 架构设计： 深入探讨每个组件的实际设计注意事项，从模型选择到工具实现。

• 面向生产的构建： 建立评估、调试、保护和扩展代理式系统（从单个实例到具有企业治理的代理群）所需的代理运维规范。
  本文档以之前的代理白皮书1和代理伴侣2为基础；本指南提供了成功构建、部署和管理新一代智能应用程序所需的基本概念和战略框架，这些应用程序可以推理、行动和观察以实现目标。
  Words are insufficient to describe how humans interact with AI. We tend to anthropomorphize and use human terms like “think” and “reason” and “know.” We don’t yet have words for “know with semantic meaning” vs “know with high probability of maximizing a reward function.” Those are two different types of knowing, but the results are the same 99.X% of the time.
  言语不足以描述人类如何与 AI 互动。我们倾向于拟人化并使用“思考”、“推理”和“知道”等人类术语。我们还没有“具有语义意义的知道”与“具有最大化奖励函数高概率的知道”的词语。这是两种不同类型的知道，但结果 99.X% 的时间是相同的。

  Introduction to AI Agents AI 代理简介

  In the simplest terms, an AI Agent can be defined as the combination of models, tools, an orchestration layer, and runtime services which uses the LM in a loop to accomplish a goal. These four elements form the essential architecture of any autonomous system.
  • The Model (The “Brain”): The core language model (LM) or foundation model that serves as the agent’s central reasoning engine to process information, evaluate options, and make decisions. The type of model (general-purpose, fine-tuned, or multimodal) dictates the agent’s cognitive capabilities. An agentic system is the ultimate curator of the input context window the LM.
  • Tools (The “Hands”): These mechanisms connect the agent’s reasoning to the outside world, enabling actions beyond text generation. They include API extensions, code functions, and data stores (like databases or vector stores) for accessing real-time, factual information. An agentic system allows a LM to plan which tools to use, executes the tool, and puts the tool results into the input context window of the next LM call.
  • The Orchestration Layer (The “Nervous System”): The governing process that manages the agent’s operational loop. It handles planning, memory (state), and reasoning strategy execution. This layer uses prompting frameworks and reasoning techniques (like Chain-of-Thought4 or ReAct5) to break down complex goals into steps and decide when to think versus use a tool. This layer is also responsible for giving agents the memory to “remember.”
  • Deployment (The “Body and Legs”): While building an agent on a laptop is effective for prototyping, production deployment is what makes it a reliable and accessible service. This involves hosting the agent on a secure, scalable server and integrating it with essential production services for monitoring, logging, and management. Once deployed, the agent can be accessed by users through a graphical interface or programmatically by other agents via an Agent-to-Agent (A2A) API.

At the end of the day, building a generative AI agent is a new way to develop solutions to solve tasks. The traditional developer acts as a “bricklayer,” precisely defining every logical step. The agent developer, in contrast, is more like a director. Instead of writing explicit code for every action, you set the scene (the guiding instructions and prompts), select the cast (the tools and APIs), and provide the necessary context (the data). The primary task becomes guiding this autonomous “actor” to deliver the intended performance.

最简单地说，AI 代理可以定义为模型、工具、编排层和运行时服务的组合，它使用 LM 在循环中实现目标。这四个元素构成了任何自主系统的基本架构。

• 模型（“大脑”）： 核心语言模型 (LM) 或基础模型，作为代理的中央推理引擎，用于处理信息、评估选项和做出决策。模型的类型（通用、微调或多模态）决定了代理的认知能力。代理式系统是 LM 输入上下文窗口的最终策展人。
• 工具（“双手”）： 这些机制将代理的推理与外部世界连接起来，实现文本生成之外的操作。它们包括 API 扩展、代码函数和数据存储（如数据库或向量存储），用于访问实时、事实信息。代理式系统允许 LM 规划要使用的工具，执行工具，并将工具结果放入下一个 LM 调用的输入上下文窗口中。
• 编排层（“神经系统”）： 管理代理操作循环的治理过程。它处理规划、内存（状态）和推理策略执行。此层使用提示框架和推理技术（如 Chain-of-Thought4 或 ReAct5）将复杂目标分解为步骤，并决定何时思考以及何时使用工具。此层还负责赋予代理“记忆”能力。
• 部署（“身体和腿”）： 虽然在笔记本电脑上构建代理对于原型设计很有效，但生产部署使其成为可靠且可访问的服务。这涉及将代理托管在安全、可扩展的服务器上，并将其与用于监控、日志记录和管理的基本生产服务集成。部署后，用户可以通过图形界面或通过代理到代理 (A2A) API 以编程方式访问代理。

归根结底，构建生成式 AI 代理是一种开发解决方案以解决任务的新方式。传统开发人员充当“砖瓦匠”，精确定义每个逻辑步骤。相比之下，代理开发人员更像一名导演。您不是为每个操作编写显式代码，而是设置场景（指导说明和提示）、选择演员（工具和 API）并提供必要的上下文（数据）。主要任务变为指导这个自主“演员”提供预期的表现。

You’ll quickly find that an LM’s greatest strength—its incredible flexibility—is also your biggest headache. A large language model’s capacity to do anything makes it difficult to compel it to do one specific thing reliably and perfectly. What we used to call “prompt engineering” and now call “context engineering” guides LMs to generate the desired output. For any single call to a LM, we input our instructions, facts, available tools to call, examples, session history, user profile, etc – filling the context window with just the right information to get the outputs we need. Agents are software which manage the inputs of LMs to get work done.

您会很快发现 LM 最大的优势——其令人难以置信的灵活性——也是您最大的麻烦。大型语言模型能够做任何事情的能力使其难以强制它可靠且完美地做一件特定的事情。我们过去称之为“提示工程”，现在称之为“上下文工程”，它指导 LM 生成所需的输出。对于 LM 的任何单个调用，我们输入我们的指令、事实、可调用的工具、示例、会话历史记录、用户配置文件等——用恰到好处的信息填充上下文窗口以获得我们需要的输出。代理是管理 LM 输入以完成工作的软件。

Debugging becomes essential when issues arise. “Agent Ops” essentially redefines the familiar cycle of measurement, analysis, and system optimization. Through traces and logs, you can monitor the agent’s “thought process” to identify deviations from the intended execution path. As models evolve and frameworks improve, the developer’s role is to furnish critical components: domain expertise, a defined personality, and seamless integration with the tools necessary for practical task completion. It’s crucial to remember that comprehensive evaluations and assessments often outweigh the initial prompt’s influence.

当出现问题时，调试变得至关重要。“代理运维”本质上重新定义了熟悉的测量、分析和系统优化循环。通过跟踪和日志，您可以监控代理的“思维过程”，以识别与预期执行路径的偏差。随着模型的发展和框架的改进，开发人员的角色是提供关键组件：领域专业知识、定义的个性以及与完成实际任务所需的工具的无缝集成。重要的是要记住，全面的评估和评估往往比初始提示的影响更重要。

When an agent is precisely configured with clear instructions, reliable tools, and an integrated context serving as memory, a great user interface, the ability to plan and problem solve, and general world knowledge, it transcends the notion of mere “workflow automation.” It begins to function as a collaborative entity: a highly efficient, uniquely adaptable, and remarkably capable new member of your team.

In essence, an agent is a system dedicated to the art of context window curation. It is a relentless loop of assembling context, prompting the model, observing the result, and then re-assembling a context for the next step. The context may include system instructions, user input, session history, long term memories, grounding knowledge from authoritative sources, what tools could be used, and the results of tools already invoked. This sophisticated management of the model’s attention allows its reasoning capabilities to problem solve for novel circumstances and accomplish objectives.

当代理通过清晰的指令、可靠的工具和集成的上下文（作为内存）、出色的用户界面、规划和解决问题的能力以及通用世界知识进行精确配置时，它超越了单纯的“工作流自动化”概念。它开始作为一个协作实体发挥作用：一个高效、独特适应且能力非凡的新团队成员。

本质上，代理是一个致力于上下文窗口管理艺术的系统。它是一个组装上下文、提示模型、观察结果，然后重新组装上下文以进行下一步的无情循环。上下文可能包括系统指令、用户输入、会话历史记录、长期记忆、来自权威来源的基础知识、可以使用哪些工具以及已调用的工具的结果。这种对模型注意力的复杂管理使其推理能力能够解决新情况并实现目标。

The Agentic Problem-Solving Process

代理式问题解决过程

We have defined an AI agent as a complete, goal-oriented application that integrates a reasoning model, actionable tools, and a governing orchestration layer. A short version is “LMs in a loop with tools to accomplish an objective.”

我们将 AI 代理定义为一个完整的、面向目标的应用程序，它集成了推理模型、可操作工具和治理编排层。简而言之，就是“LM 在循环中与工具一起实现目标”。

But how does this system actually work? What does an agent do from the moment it receives a request to the moment it delivers a result?

但是这个系统实际上是如何工作的呢？从接收请求到交付结果的那一刻，代理会做什么？

At its core, an agent operates on a continuous, cyclical process to achieve its objectives. While this loop can become highly complex, it can be broken down into five fundamental steps as discussed in detail in the book Agentic System Design:6

1. Get the Mission: The process is initiated by a specific, high-level goal. This mission is provided by a user (e.g., “Organize my team’s travel for the upcoming conference”) or an automated trigger (e.g., “A new high-priority customer ticket has arrived”).

2. Scan the Scene: The agent perceives its environment to gather context. This involves the orchestration layer accessing its available resources: “What does the user’s request say?”, “What information is in my term memory? Did I already try to do this task? Did the user give me guidance last week?”, “What can I access from my tools, like calendars, databases, or APIs?”

3. Think It Through: This is the agent’s core “think” loop, driven by the reasoning model. The agent analyzes the Mission (Step 1) against the Scene (Step 2) and devises a plan. This isn’t a single thought, but often a chain of reasoning: “To book travel, I first need to know who is on the team. I will use the get_team_roster tool. Then I will need to check their availability via the calendar_api.”

4. Take Action: The orchestration layer executes the first concrete step of the plan. It selects and invokes the appropriate tool—calling an API, running a code function, or querying a database. This is the agent acting on the world beyond its own internal reasoning.

5. Observe and Iterate: The agent observes the outcome of its action. The get_ team_roster tool returns a list of five names. This new information is added to the agent’s context or “memory.” The loop then repeats, returning to Step 3: “Now that I have the roster, my next step is to check the calendar for these five people. I will use the calendar_api.”

代理的核心是持续、循环地操作以实现其目标。虽然这个循环可能变得高度复杂，但它可以分解为五个基本步骤，如《代理系统设计》一书中所述：

1. 获取任务： 过程由一个特定的、高级别的目标启动。此任务由用户提供（例如，“为即将召开的会议组织团队差旅”）或由自动化触发器提供（例如，“收到新的高优先级客户工单”）。

2. 扫描场景： 代理感知其环境以收集上下文。这涉及编排层访问其可用资源：“用户的请求说了什么？”、“我的长期记忆中有哪些信息？我是否已经尝试过执行此任务？用户上周是否给了我指导？”、“我可以从我的工具（如日历、数据库或 API）访问什么？”

3. 思考： 这是代理的核心“思考”循环，由推理模型驱动。代理根据任务（步骤 1）分析场景（步骤 2）并制定计划。这并非单一的思考，而通常是推理链：“要预订差旅，我首先需要知道团队中有谁。我将使用 get_team_roster 工具。然后我需要通过 calendar_api 检查他们的可用性。”

4. 采取行动： 编排层执行计划的第一个具体步骤。它选择并调用适当的工具——调用 API、运行代码函数或查询数据库。这是代理在其自身内部推理之外的世界中行动。

5. 观察和迭代： 代理观察其行动的结果。get_team_roster 工具返回一个包含五个名称的列表。此新信息被添加到代理的上下文或“记忆”中。然后循环重复，返回到步骤 3：“现在我有了花名册，我的下一步是检查这五个人的日历。我将使用 calendar_api。”

This “Think, Act, Observe” cycle continues - managed by the Orchestration Layer, reasoned by the Model, and executed by the Tools until the agent’s internal plan is complete and the initial Mission is achieved.

![][image1]Figure 1: Agentic AI problem-solving process

这个“思考、行动、观察”循环持续进行——由编排层管理，由模型推理，由工具执行——直到代理的内部计划完成并实现初始任务。

Let’s take a real-world example of how a Customer Support Agent would operate in this 5-step cycle:

让我们以一个客户支持代理如何在此 5 步循环中操作的真实示例：

Imagine a user asks, “Where is my order #12345?”

想象一个用户问道：“我的订单 #12345 在哪里？”

Instead of immediately acting, the agent first enters its “Think It Through” phase to devise a complete strategy. It reasons:

“The user wants a delivery status. To provide a complete answer, I need a multi-step plan:

1. Identify: I must first find the order in our internal database to confirm it exists and get its details.

2. Track: From those details, I’ll need to extract the shipping carrier’s tracking number. Then, I’ll query the external carrier’s API for the live status.

3. Report: Finally, I must synthesize the information I’ve gathered into a clear, helpful response for the user.”

With this multi-step plan in mind, the agent begins execution.

In its first “Act” phase, it executes step one of its plan, calling the find_order("12345") tool. It observes the result—a full order record, including the tracking number “ZYX987.”

The agent’s orchestration layer recognizes that the first part of its plan is complete and immediately proceeds to the second. It acts by calling the get_shipping_ status("ZYX987") tool. It observes the new result: “Out for Delivery.”

Finally, having successfully executed the data-gathering stages of its plan, the agent moves to the “Report” step. It perceives it has all the necessary components, plans the final message, and acts by generating the response: “Your order #12345 is ‘Out for Delivery’!

代理不会立即行动，而是首先进入其**“思考”**阶段，以制定完整的策略。它推理：

“用户想要配送状态。为了提供完整的答案，我需要一个多步骤计划：

1. 识别： 我必须首先在我们的内部数据库中找到订单，以确认其存在并获取其详细信息。

2. 跟踪： 根据这些详细信息，我需要提取货运承运人的跟踪号。然后，我将查询外部承运人的 API 以获取实时状态。

3. 报告： 最后，我必须将收集到的信息综合成清晰、有用的回复给用户。”

考虑到这个多步骤计划，代理开始执行。

在其第一个“行动”阶段，它执行其计划的第一步，调用 find_order(“12345”) 工具。它观察结果——一个完整的订单记录，包括跟踪号“ZYX987”。

代理的编排层识别出其计划的第一部分已完成，并立即进行第二部分。它通过调用 get_shipping_status(“ZYX987”) 工具进行操作。它观察到新结果：“正在配送”。

最后，在成功执行了数据收集阶段的计划后，代理进入“报告”步骤。它感知到它拥有所有必要的组件，规划最终消息，并通过生成回复进行操作：“您的订单 #12345 正在配送中！”

A Taxonomy of Agentic Systems

代理式系统分类

Understanding the 5-step operational loop is the first part of the puzzle. The second is recognizing that this loop can be scaled in complexity to create different classes of agents. For an architect or product leader, a key initial decision is scoping what kind of agent to build.

We can classify agentic systems into a few broad levels, each building on the capabilities of the last.

![][image2]Figure 2: Agentic system in 5 steps

理解 5 步操作循环是解决难题的第一步。第二步是认识到这个循环可以在复杂性上进行扩展，以创建不同类别的代理。对于架构师或产品负责人来说，一个关键的初始决策是确定要构建哪种代理。

我们可以将代理式系统分为几个广泛的级别，每个级别都建立在前一个级别的能力之上。

Level 0: The Core Reasoning System 核心推理系统

Before we can have an agent, we must start with the “Brain” in its most basic form: the reasoning engine itself. In this configuration, a Language Model (LM) operates in isolation, responding solely based on its vast pre-trained knowledge without any tools, memory, or interaction with the live environment.

Its strength lies in this extensive training, allowing it to explain established concepts and plan how to approach solving a problem with great depth. The trade-off is a complete lack of real time awareness; it is functionally “blind” to any event or fact outside its training data.

For instance, it can explain the rules of professional baseball and the complete history of the New York Yankees. But if you ask, “What was the final score of the Yankees game last night?”, it would be unable to answer. That game is a specific, real-world event that happened after its training data was collected, so the information simply doesn’t exist in its knowledge.

在拥有代理之前，我们必须从“大脑”最基本的形式开始：推理引擎本身。在此配置中，语言模型 (LM) 独立运行，仅根据其庞大的预训练知识进行响应，没有任何工具、内存或与实时环境的交互。

它的优势在于其广泛的训练，使其能够深入解释既定概念并规划如何解决问题。缺点是完全缺乏实时意识；它在功能上“盲目”于其训练数据之外的任何事件或事实。

例如，它可以解释职业棒球规则和纽约洋基队的完整历史。但是，如果您问“昨晚洋基队比赛的最终比分是多少？”，它将无法回答。那场比赛是发生在其训练数据收集之后的特定真实世界事件，因此信息根本不存在于其知识中。

Level 1: The Connected Problem-Solver 互联问题解决器

At this level, the reasoning engine becomes a functional agent by connecting to and utilizing external tools - the “Hands” component of our architecture. Its problem-solving is no longer confined to its static, pre-trained knowledge.

Using the 5-step loop, the agent can now answer our previous question. Given the “Mission”: “What was the final score of the Yankees game last night?”, its “Think” step recognizes this as a real-time data need. Its “Act” step then invokes a tool, like a Google Search API with the proper date and search terms. It “Observes” the search result (e.g., “Yankees won 5-3”), and synthesizes that fact into a final answer.

This fundamental ability to interact with the world - whether using a search tool for a score , a financial API for a live stock price, or a database via Retrieval-Augmented Generation (RAG) is the core capability of a Level 1 agent.

在此级别，推理引擎通过连接和利用外部工具（我们架构的“双手”组件）成为功能性代理。其问题解决不再局限于其静态的预训练知识。

使用 5 步循环，代理现在可以回答我们之前的问题。给定“任务”：“昨晚洋基队比赛的最终比分是多少？”，其“思考”步骤将此识别为实时数据需求。其“行动”步骤然后调用一个工具，例如带有适当日期和搜索词的 Google 搜索 API。它“观察”搜索结果（例如，“洋基队以 5-3 获胜”），并将该事实综合为最终答案。

这种与世界互动的基本能力——无论是使用搜索工具获取比分、使用金融 API 获取实时股价，还是通过检索增强生成 (RAG) 访问数据库——都是 1 级代理的核心能力。

Level 2: The Strategic Problem-Solver 战略问题解决器

Level 2 marks a significant expansion in capability, moving from executing simple tasks to strategically planning complex, multi-part goals. The key skill that emerges here is context engineering: the agent’s ability to actively select, package, and manage the most relevant information for each step of its plan.

An agent’s accuracy depends on a focused, high-quality context. Context engineering curates the model’s limited attention to prevent overload and ensure efficient performance.

For instance, consider the “Mission”: “Find a good coffee shop halfway between my office at 1600 Amphitheatre Parkway, Mountain View, and my client’s office at 1 Market St, San Francisco.”

A Level 2 agent will start creating a plan:

1. Think: “I must first find the halfway point.”

• Act: Call the Maps tool with both addresses.

• Observe: “The halfway point is Millbrae, CA.”

2. Think: “Now I must find coffee shops in Millbrae. The user asked for ‘good’ ones, so I will search for places with a 4-star rating or higher.”

• Act: Call the google_places tool with query="coffee shop in Millbrae, CA", min_rating=4.0. (This is context engineering - it automatically created a new, focused search query from the previous step’s output ).

• Observe: “The search returns ‘Millbrae Coffee’ and ‘The Daily Grind’.” 3. Think: “I will synthesize these results and present them to the user.”

This strategic planning also enables proactive assistance, like an agent that reads a long flight confirmation email, engineers the key context (flight number, date), and acts by adding it to your calendar.

2 级标志着能力的显著扩展，从执行简单任务转向战略性规划复杂的、多部分的目标。这里出现的关键技能是上下文工程：代理主动选择、打包和管理与其计划的每个步骤最相关的信息的能力。

代理的准确性取决于专注、高质量的上下文。上下文工程管理模型有限的注意力，以防止过载并确保高效性能。

例如，考虑“任务”：“在我的办公室（山景城圆形剧场大道 1600 号）和客户办公室（旧金山市场街 1 号）之间找到一家好的咖啡店。”

2 级代理将开始制定计划：

1. 思考： “我必须首先找到中点。”

• 行动： 使用两个地址调用地图工具。
• 观察： “中点是加利福尼亚州米尔布雷。”2. 思考： “现在我必须在米尔布雷找到咖啡店。用户要求‘好的’咖啡店，所以我将搜索评分 4 星或更高的地点。”
• 行动： 调用 google_places 工具，查询为“Millbrae, CA 的咖啡店”，min_rating=4.0。（这是上下文工程——它自动从上一步的输出创建了一个新的、重点突出的搜索查询）。
• 观察： “搜索结果返回‘Millbrae Coffee’和‘The Daily Grind’。”

3. 思考： “我将综合这些结果并呈现给用户。”

这种战略规划还支持主动协助，例如一个代理读取一封冗长的航班确认电子邮件，提取关键上下文（航班号、日期），并通过将其添加到您的日历中来采取行动。

Level 3: The Collaborative Multi-Agent System 协作式多代理系统

At the highest level, the paradigm shifts entirely. We move away from building a single, all powerful “super-agent” and toward a “team of specialists” working in concert, a model that directly mirrors a human organization. The system’s collective strength lies in this division of labor.

Here, agents treat other agents as tools. Imagine a “Project Manager” agent receiving a “Mission”: “Launch our new ‘Solaris’ headphones.”

The Project Manager agent doesn’t do the entire work itself. It Acts by creating new Missions for its team of specialized agents much like how it works in the real life:

1. Delegates to MarketResearchAgent: “Analyze competitor pricing for noise-canceling headphones. Return a summary document by tomorrow.”

2. Delegates to MarketingAgent: “Draft three versions of a press release using the ‘Solaris’ product spec sheet as context.”

3. Delegates to WebDevAgent: “Generate the new product page HTML based on the attached design mockups.”

This collaborative model, while currently constrained by the reasoning limitations of today’s LMs, represents the frontier of automating entire, complex business workflows from start to finish.

在最高级别，范式完全转变。我们不再构建单一的、无所不能的“超级代理”，而是转向一个“专家团队”协同工作，这种模式直接反映了人类组织。系统的集体力量在于这种分工。

在这里，代理将其他代理视为工具。想象一个“项目经理”代理接收到“任务”：“推出我们的新‘Solaris’耳机。”

项目经理代理不会自己完成所有工作。它通过为自己的专业代理团队创建新任务来行动，就像现实生活中一样：

1. 委托给市场研究代理： “分析降噪耳机的竞争对手定价。明天提交一份总结文档。”

2. 委托给营销代理： “使用‘Solaris’产品规格表作为上下文，起草三个版本的媒体新闻稿。”

3. 委托给 Web 开发代理： “根据随附的设计模型生成新产品页面 HTML。”

这种协作模型，虽然目前受到当今 LM 推理能力的限制，但代表着自动化整个复杂业务工作流程（从开始到结束）的前沿。

Level 4: The Self-Evolving System 自我演进系统

Level 4 represents a profound leap from delegation to autonomous creation and adaptation. At this level, an agentic system can identify gaps in its own capabilities and dynamically create new tools or even new agents to fill them. It moves from using a fixed set of resources to actively expanding them.

Following our example, the “Project Manager” agent, tasked with the ‘Solaris’ launch, might realize it needs to monitor social media sentiment, but no such tool or agent exists on its team.

1. Think (Meta-Reasoning): “I must track social media buzz for ‘Solaris,’ but I lack the capability.”

2. Act (Autonomous Creation): Instead of failing, it invokes a high-level AgentCreator tool with a new mission: “Build a new agent that monitors social media for keywords ‘Solaris headphones’, performs sentiment analysis, and reports a daily summary.”

3. Observe: A new, specialized SentimentAnalysisAgent is created, tested, and added to the team on the fly, ready to contribute to the original mission.

This level of autonomy, where a system can dynamically expand its own capabilities, turns a team of agents into a truly learning and evolving organization.

4 级代表着从委托到自主创建和适应的深刻飞跃。在此级别，代理系统可以识别自身能力中的差距，并动态创建新工具甚至新代理来填补这些空白。它从使用固定资源集转向积极扩展资源。

根据我们的示例，“项目经理”代理负责“Solaris”发布，可能会意识到它需要监控社交媒体情绪，但其团队中没有此类工具或代理。

1. 思考（元推理）： “我必须跟踪‘Solaris’的社交媒体热度，但我缺乏这种能力。”

2. 行动（自主创建）： 它没有失败，而是调用了一个高级代理创建工具，并带有一个新任务：“构建一个新代理，监控关键词‘Solaris 耳机’的社交媒体，执行情感分析，并报告每日摘要。”

3. 观察： 一个新的、专业的 SentimentAnalysisAgent 被创建、测试并即时添加到团队中，随时准备为原始任务做出贡献。

这种自主性级别，即系统可以动态扩展自身能力，将代理团队转变为一个真正学习和演进的组织。

Core Agent Architecture: Model, Tools, and Orchestration 核心代理架构：模型、工具和编排

We know what an agent does and how it can scale. But how do we actually build it? The transition from concept to code lies in the specific architectural design of its three core components.

我们知道代理做什么以及它如何扩展。但我们究竟如何构建它呢？从概念到代码的转变在于其三个核心组件的特定架构设计。

Model: The “Brain” of your AI Agent 模型：AI 代理的“大脑”

The LM is the reasoning core of your agent, and its selection is a critical architectural decision that dictates your agent’s cognitive capabilities, operational cost, and speed. However, treating this choice as a simple matter of picking the model with the highest

benchmark score is a common path to failure. An agent’s success in a production environment is rarely determined by generic academic benchmarks.

Real-world success demands a model that excels at agentic fundamentals: superior reasoning to navigate complex, multi-step problems and reliable tool use to interact with the world7.

To do this well, start by defining the business problem, then test models against metrics that directly map to that outcome. If your agent needs to write code, test it on your private codebase. If it processes insurance claims, evaluate its ability to extract information from your specific document formats. This analysis must then be cross-referenced with the practicalities of cost and latency. The “best” model is the one that sits at the optimal intersection of quality, speed, and price for your specific task8.

You may choose more than one model, a “team of specialists.” You don’t use a sledgehammer to crack a nut. A robust agent architecture might use a frontier model like Gemini 2.5 Pro for the heavy lifting of initial planning and complex reasoning, but then intelligently route simpler, high-volume tasks—like classifying user intent or summarizing text—to a much faster and

more cost-effective model like Gemini 2.5 Flash. Model routing might be automatic or hard coded but is a key strategy for optimizing both performance and cost9.

The same principle applies to handling diverse data types. While a natively multimodal model like Gemini live mode10 offers a streamlined path to processing images and audio, an alternative is to use specialized tools like the Cloud Vision API11 or Speech-to-Text API12. In this pattern, the world is first converted to text, which is then passed to a language-only model for reasoning. This adds flexibility and allows for best-of-breed components, but also introduces significant complexity.

Finally, the AI landscape is in a state of constant, rapid evolution. The model you choose today will be superseded in six months. A “set it and forget it” mindset is unsustainable. Building for this reality means investing in a nimble operational framework—an “Agent Ops” practice13. With a robust CI/CD pipeline that continuously evaluates new models against your key business metrics, you can de-risk and accelerate upgrades, ensuring your agent is always powered by the best brain available without requiring a complete architectural overhaul.

LM 是代理的推理核心，其选择是一个关键的架构决策，它决定了代理的认知能力、运营成本和速度。然而，将此选择视为简单地选择基准分数最高的模型是常见的失败之路。代理在生产环境中的成功很少由通用学术基准决定。

现实世界的成功需要一个擅长代理式基本原理的模型：卓越的推理能力来应对复杂的、多步骤的问题，以及可靠的工具使用能力来与世界互动。

要做好这一点，首先要定义业务问题，然后根据直接映射到该结果的指标测试模型。如果您的代理需要编写代码，请在您的私有代码库上进行测试。如果它处理保险索赔，请评估其从您的特定文档格式中提取信息的能力。然后必须将此分析与成本和延迟的实际情况进行交叉引用。“最佳”模型是质量、速度和价格最适合您特定任务的最佳交集。

您可以选择多个模型，一个“专家团队”。您不会用大锤砸核桃。一个健壮的代理架构可能会使用像 Gemini 2.5 Pro 这样的前沿模型来处理初始规划和复杂推理的繁重工作，然后智能地将更简单、大批量的任务（如用户意图分类或文本摘要）路由到速度更快、成本效益更高的模型，如 Gemini 2.5 Flash。模型路由可以是自动的或硬编码的，但它是优化性能和成本的关键策略。

同样的原则也适用于处理不同的数据类型。虽然像 Gemini 实时模式10 这样的原生多模态模型提供了处理图像和音频的简化路径，但另一种选择是使用像 Cloud Vision API11 或 Speech-to-Text API 这样的专用工具。在这种模式中，世界首先被转换为文本，然后传递给仅限语言的模型进行推理。这增加了灵活性并允许最佳组件，但也引入了显著的复杂性。

最后，AI 格局处于持续、快速演变的状态。您今天选择的模型将在六个月内被取代。“一劳永逸”的心态是不可持续的。为应对这一现实而构建意味着投资于灵活的操作框架——“代理运维”实践。通过一个健壮的 CI/CD 管道，该管道持续根据您的关键业务指标评估新模型，您可以降低风险并加速升级，确保您的代理始终由可用的最佳大脑提供支持，而无需进行完整的架构大修。

Tools: The “Hands” of your AI Agent

If the model is the agent’s brain, tools are the hands that connect its reasoning to reality. They allow the agent to move beyond its static training data to retrieve real-time information and take action in the world. A robust tool interface is a three-part loop: defining what a tool can do, invoking it, and observing the result.

如果模型是代理的大脑，那么工具就是连接其推理与现实的双手。它们允许代理超越其静态训练数据，检索实时信息并在世界中采取行动。一个健壮的工具接口是一个三部分循环：定义工具可以做什么，调用它，并观察结果。

Here are a few of the main types of tools agent builders will put into the “hands” of their agents. For a more complete deep dive see the agent tools focused whitepaper in this series.

以下是代理构建者将放入其代理“手中”的几种主要工具类型。有关更完整的深入探讨，请参阅本系列中以代理工具为重点的白皮书。

Retrieving Information: Grounding in Reality 检索信息：立足现实

The most foundational tool is the ability to access up-to-date information. Retrieval Augmented Generation (RAG) gives the agent a “library card” to query external knowledge, often stored in Vector Databases or Knowledge Graphs, ranging from internal company documents to web knowledge via Google Search. For structured data, Natural Language to SQL (NL2SQL) tools allow the agent to query databases to answer analytic questions like, “What were our top-selling products last quarter?” By looking things up before speaking— whether in a document or a database—the agent grounds itself in fact, dramatically reducing hallucinations.

最基础的工具是访问最新信息的能力。检索增强生成 (RAG) 赋予代理一张“图书馆卡”，可以查询外部知识，这些知识通常存储在向量数据库或知识图谱中，范围从内部公司文档到通过 Google 搜索获取的网络知识。对于结构化数据，自然语言到 SQL (NL2SQL) 工具允许代理查询数据库以回答分析问题，例如“上个季度我们最畅销的产品是什么？”通过在说话前查找信息（无论是在文档中还是在数据库中），代理将自己立足于事实，从而大大减少幻觉。

Executing Actions: Changing the World 执行操作：改变世界

The true power of agents is unleashed when they move from reading information to actively doing things. By wrapping existing APIs and code functions as tools, an agent can send an email, schedule a meeting, or update a customer record in ServiceNow. For more dynamic tasks, an agent can write and execute code on the fly. In a secure sandbox, it can generate a SQL query or a Python script to solve a complex problem or perform a calculation, transforming it from a knowledgeable assistant into an autonomous actor14. This also includes tools for human interaction. An agent can use a Human in the Loop (HITL) tool to pause its workflow and ask for confirmation (e.g., ask_for_confirmation()) or request specific information from a user interface (e.g., ask_for_date_input()), ensuring a person is involved in critical decisions. HITL could be implemented via SMS text messaging and a task in a database.

当代理从读取信息转向积极做事时，其真正的力量就得以释放。通过将现有 API 和代码函数封装为工具，代理可以发送电子邮件、安排会议或更新 ServiceNow 中的客户记录。对于更动态的任务，代理可以即时编写和执行代码。在安全的沙盒中，它可以生成 SQL 查询或 Python 脚本来解决复杂问题或执行计算，从而将其从一个知识渊博的助手转变为一个自主的行动者14。

Function Calling: Connecting Tools to your Agent 函数调用：将工具连接到您的代理

For an agent to reliably do “function calling” and use tools, it needs clear instructions, secure connections, and orchestration15. Longstanding standards like the OpenAPI specification provide this, giving the agent a structured contract that describes a tool’s purpose, its required parameters, and its expected response. This schema lets the model generate the correct function call every time and interpret the API response. For simpler discovery and connection to tools, open standards like the Model Context Protocol (MCP) have become popular because they are more convenient16. Additionally, a few models have native tools, like Gemini with native Google Search, where the function invocation happens as part of the LM call itself17.

为了让代理可靠地执行“函数调用”并使用工具，它需要清晰的指令、安全的连接和编排15。像 OpenAPI 规范这样的长期标准提供了这一点，为代理提供了一个结构化的契约，描述了工具的用途、其所需的参数及其预期的响应。此模式允许模型每次生成正确的函数调用并解释 API 响应。为了更简单的工具发现和连接，像 模型上下文协议 (MCP) 这样的开放标准已经流行起来，因为它们更方便16。此外，一些模型具有原生工具，例如带有原生 Google 搜索的 Gemini，其中函数调用作为 LM 调用本身的一部分发生。

The Orchestration Layer 编排层

If the model is the agent’s brain and the tools are its hands, the orchestration layer is the central nervous system that connects them. It is the engine that runs the “Think, Act, Observe” loop, the state machine that governs the agent’s behavior, and the place where a developer’s carefully crafted logic comes to life. This layer is not just plumbing; it is the conductor of the entire agentic symphony, deciding when the model should reason, which tool should act, and how the results of that action should inform the next movement.

如果模型是代理的大脑，工具是它的双手，那么编排层就是连接它们的中央神经系统。它是运行“思考、行动、观察”循环的引擎，是管理代理行为的状态机，也是开发人员精心设计的逻辑变为现实的地方。这一层不仅仅是管道；它是整个代理式交响乐的指挥，决定模型何时推理，哪个工具应该行动，以及该行动的结果应该如何影响下一个动作。

Core Design Choices 核心设计选择

The first architectural decision is determining the agent’s degree of autonomy. The choice exists on a spectrum. At one end, you have deterministic, predictable workflows that call an LM as a tool for a specific task—a sprinkle of AI to augment an existing process. At the other end, you have the LM in the driver’s seat, dynamically adapting, planning and executing tasks to achieve a goal.

第一个架构决策是确定代理的自主程度。选择存在于一个连续统一体上。一端是确定性的、可预测的工作流，它将 LM 作为特定任务的工具进行调用——少量 AI 来增强现有流程。另一端是 LM 处于主导地位，动态适应、规划和执行任务以实现目标。

A parallel choice is the implementation method. No-code builders offer speed and accessibility, empowering business users to automate structured tasks and build simple agents rapidly. For more complex, mission-critical systems, code-first frameworks, such as Google’s Agent Development Kit (ADK)18, provide the deep control, customizability, and integration capabilities that engineers require.

一个并行的选择是实现方法。无代码构建器提供速度和可访问性，使业务用户能够快速自动化结构化任务并构建简单代理。对于更复杂的、任务关键型系统，像 Google 的 代理开发工具包 (ADK)18 这样的代码优先框架提供了工程师所需的深度控制、可定制性和集成能力。

Regardless of the approach, a production-grade framework is essential. It must be open, allowing you to plug in any model or tool to prevent vendor lock-in. It must provide precise control, enabling a hybrid approach where the non-deterministic reasoning of an LM is governed by hard-coded business rules. Most importantly, the framework must be built for observability. When an agent behaves unexpectedly, you cannot simply put a breakpoint in the model’s “thought.” A robust framework generates detailed traces and logs, exposing the entire reasoning trajectory: the model’s internal monologue, the tool it chose, the parameters it generated, and the result it observed.

无论采用何种方法，生产级框架都是必不可少的。它必须是开放的，允许您插入任何模型或工具以防止供应商锁定。它必须提供精确控制，允许混合方法，其中 LM 的非确定性推理由硬编码的业务规则管理。最重要的是，该框架必须为可观察性而构建。当代理行为异常时，您不能简单地在模型的“思维”中设置断点。一个健壮的框架会生成详细的跟踪和日志，暴露整个推理轨迹：模型的内部独白、它选择的工具、它生成的参数以及它观察到的结果。

Instruct with Domain Knowledge and Persona 领域知识和角色指导

Within this framework, the developer’s most powerful lever is to instruct the agent with domain knowledge and a distinct persona. This is accomplished through a system prompt or a set of core instructions. This isn’t just a simple command; it is the agent’s constitution.

在此框架内，开发人员最强大的杠杆是使用领域知识和独特的角色来指导代理。这是通过系统提示或一组核心指令来实现的。这不仅仅是一个简单的命令；它是代理的章程。

Here, you tell it, You are a helpful customer support agent for Acme Corp, ... and provide constraints, desired output schema, rules of engagement, a specific tone of voice, and explicit guidance on when and why it should use its tools. A few example scenarios in the instructions are usually very effective.

在这里，您告诉它，“您是 Acme Corp 的一名乐于助人的客户支持代理，……”，并提供约束、所需的输出模式、参与规则、特定的语气，以及何时以及为何使用其工具的明确指导。指令中的几个示例场景通常非常有效。

Augment with Context 上下文增强

The agent’s “memory” is orchestrated into the LM context window at runtime. For a more complete deep dive see the agent memory focused whitepaper in this series.

Short-term memory is the agent’s active “scratchpad,” maintaining the running history of the current conversation. It tracks the sequence of (Action, Observation) pairs from the ongoing loop, providing the immediate context the model needs to decide what to do next. This may be implemented as abstractions like state, artifacts, sessions or threads.

Long-term memory provides persistence across sessions. Architecturally, this is almost always implemented as another specialized tool—a RAG system connected to a vector database or search engine. The orchestrator gives the agent the ability to pre-fetch and to actively query its own history, allowing it to “remember” a user’s preferences or the outcome of a similar task from weeks ago for a truly personalized and continuous experience.19

代理的“记忆”在运行时被编排到 LM 上下文窗口中。有关更完整的深入探讨，请参阅本系列中以代理记忆为重点的白皮书。

短期记忆是代理的活跃“草稿本”，维护当前对话的运行历史记录。它跟踪正在进行的循环中的（行动，观察）对序列，提供模型决定下一步需要做什么的即时上下文。这可以通过状态、工件、会话或线程等抽象来实现。

长期记忆提供跨会话的持久性。从架构上讲，这几乎总是作为另一个专用工具实现——一个连接到向量数据库或搜索引擎的 RAG 系统。编排器赋予代理预取和主动查询其自身历史记录的能力，使其能够“记住”用户的偏好或几周前类似任务的结果，从而实现真正个性化和持续的体验。

Multi-Agent Systems and Design Patterns 多代理系统和设计模式

As tasks grow in complexity, building a single, all-powerful “super-agent” becomes inefficient. The more effective solution is to adopt a “team of specialists” approach, which mirrors a human organization. This is the core of a multi-agent system: a complex process is segmented into discrete sub-tasks, and each is assigned to a dedicated, specialized AI agent. This division of labor allows each agent to be simpler, more focused, and easier to build, test, and maintain, which is ideal for dynamic or long-running business processes.

随着任务复杂性的增加，构建一个单一的、无所不能的“超级代理”变得效率低下。更有效的解决方案是采用“专家团队”方法，这反映了人类组织。这是多代理系统的核心：一个复杂的流程被分割成离散的子任务，每个子任务都分配给一个专用的、专业的 AI 代理。这种分工使得每个代理更简单、更专注，更容易构建、测试和维护，这对于动态或长期运行的业务流程来说是理想的。

Architects may rely on proven agentic design patterns, though agent capabilities and thus patterns are evolving rapidly.20 For dynamic or non-linear tasks, the Coordinator pattern is essential. It introduces a “manager” agent that analyzes a complex request, segments the primary task, and intelligently routes each sub-task to the appropriate specialist agent (like a researcher, a writer, or a coder). The coordinator then aggregates the responses from each specialist to formulate a final, comprehensive answer.

![][image3]Figure 3: The “iterative refinement” pattern from
https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system

For more linear workflows, the Sequential pattern is a better fit, acting like a digital assembly line where the output from one agent becomes the direct input for the next. Other key patterns focus on quality and safety. The Iterative Refinement pattern creates a feedback loop, using a “generator” agent to create content and a “critic” agent to evaluate it against quality standards. For high-stakes tasks, the Human-in-the-Loop (HITL) pattern is critical, creating a deliberate pause in the workflow to get approval from a person before an agent takes a significant action.

架构师可以依赖经过验证的代理式设计模式，尽管代理能力和模式正在迅速演变。对于动态或非线性任务，协调器模式至关重要。它引入了一个“管理器”代理，该代理分析复杂请求，分割主要任务，并智能地将每个子任务路由到适当的专家代理（如研究员、作家或编码员）。然后，协调器聚合每个专家的响应以形成最终的、全面的答案。

对于更线性的工作流，顺序模式更适合，它像数字装配线一样，一个代理的输出成为下一个代理的直接输入。其他关键模式侧重于质量和安全。迭代细化模式创建了一个反馈循环，使用“生成器”代理创建内容，并使用“评论者”代理根据质量标准对其进行评估。对于高风险任务，人工介入 (HITL) 模式至关重要，它在工作流中创建一个刻意的暂停，以在代理采取重大行动之前获得人员的批准。

Agent Deployment and Services 代理部署和服务

After you have built a local agent, you will want to deploy it to a server where it runs all the time and where other people and agents can use it. Continuing our analogy, deployment and services would be the body and legs for our agent. An agent requires several services to be effective, session history and memory persistence, and more. As an agent builder, you will also be responsible for deciding what you log, and what security measures you take for data privacy and data residency and regulation compliance. All of these services are in scope, when deploying agents to production.

Luckily, agent builders can rely on decades of application hosting infrastructure. Agents are a new form of software after all and many of the same principles apply. Builders can rely on purpose-built, agent specific, deployment options like Vertex AI Agent Engine which support runtime and everything else in one platform21. For software developers who want to control their application stacks more directly, or deploy agents within their existing DevOps infrastructure, any agent and most agent services can be added to a docker container and deployed onto industry standard runtimes like Cloud Run or GKE22.

![][image4]
Figure 4: Vertex AI Agent builder from

https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview

If you are not a software developer and a DevOps expert, the process of deploying your first agent might be daunting. Many agent frameworks make this easy with a deploy command or a dedicated platform to deploy the agent, and these should be used for early exploration and onboarding. Ramping up to a secure and production ready environment will usually require a bigger investment of time and application of best practices, including CI/CD and automated testing for your agents23.

构建本地代理后，您会希望将其部署到服务器上，使其始终运行，并供其他人和其他代理使用。继续我们的类比，部署和服务将是代理的身体和腿。代理需要多种服务才能有效运行，包括会话历史记录和内存持久性等。作为代理构建者，您还将负责决定要记录什么，以及为数据隐私、数据驻留和法规遵从性采取哪些安全措施。所有这些服务都在部署代理到生产环境的范围内。

幸运的是，代理构建者可以依赖数十年的应用程序托管基础设施。代理毕竟是一种新形式的软件，许多相同的原则也适用。构建者可以依赖专门构建的、针对代理的部署选项，例如 Vertex AI Agent Engine，它在一个平台上支持运行时和所有其他功能21。对于希望更直接地控制其应用程序堆栈或在其现有 DevOps 基础设施中部署代理的软件开发人员，任何代理和大多数代理服务都可以添加到 Docker 容器中，并部署到 Cloud Run 或 GKE22 等行业标准运行时上。

如果您不是软件开发人员和 DevOps 专家，部署您的第一个代理的过程可能会令人生畏。许多代理框架通过部署命令或专用平台使代理部署变得容易，这些应该用于早期探索和入门。要达到安全且生产就绪的环境通常需要更大的时间投入和最佳实践的应用，包括代理的 CI/CD 和自动化测试23。

Agent Ops: A Structured Approach to the Unpredictable

代理运维：应对不可预测性的结构化方法

As you build your first agents, you will be manually testing the behavior, over and over again. When you add a feature, does it work? When you fix a bug, did you cause a different problem? Testing is normal for software development but it works differently with generative AI.

The transition from traditional, deterministic software to stochastic, agentic systems requires a new operational philosophy. Traditional software unit tests could simply assert output == expected; but that doesn’t work when an agent’s response is probabilistic by design. Also, because language is complicated, it usually requires a LM to evaluate “quality” – that the agent’s response does all of what it should, nothing it shouldn’t, and with proper tone.

![][image5]
Figure 5: Relationships between the operational domains of DevOps, MLOps, and GenAIOps from https://medium.com/@sokratis.kartakis/genai-in-production-mlops-or-genaiops-25691c9becd0

Agent Ops is the disciplined, structured approach to managing this new reality. It is a natural evolution of DevOps and MLOps, tailored for the unique challenges of building, deploying, and governing AI agents, turning unpredictability from a liability into a managed, measurable, and reliable feature.24 For a more complete deep dive see the agent quality focused whitepaper in this series.

在构建您的第一个代理时，您将一遍又一遍地手动测试其行为。当您添加功能时，它是否有效？当您修复错误时，您是否导致了不同的问题？测试对于软件开发来说是正常的，但它与生成式 AI 的工作方式不同。

从传统的、确定性软件到随机的、代理式系统的转变需要一种新的操作理念。传统软件单元测试可以简单地断言输出 == 预期；但这在代理的响应本质上是概率性的情况下不起作用。此外，由于语言的复杂性，通常需要一个 LM 来评估“质量”——即代理的响应是否完成了它应该做的一切，没有做它不应该做的事情，并且语气恰当。

代理运维是管理这种新现实的规范化、结构化方法。它是 DevOps 和 MLOps 的自然演进，专为构建、部署和治理 AI 代理的独特挑战而定制，将不可预测性从负债转变为可管理、可衡量和可靠的功能24。有关更完整的深入探讨，请参阅本系列中以代理质量为重点的白皮书。

Measure What Matters: Instrumenting Success Like an A/B Experiment 衡量重要指标：像 A/B 实验一样衡量成功

Before you can improve your agent, you must define what “better” means in the context of your business. Frame your observability strategy like an A/B test and ask yourself: what are the Key Performance Indicators (KPIs) that prove the agent is delivering value? These metrics should go beyond technical correctness and measure real-world impact: goal completion rates, user satisfaction scores, task latency, operational cost per interaction, and—most importantly—the impact on business goals like revenue, conversion or customer retention. This top-down view will guide the rest of your testing, puts you on the path to metrics driven development, and will let you calculate a return on investment.

在改进代理之前，您必须在业务环境中定义“更好”的含义。像 A/B 测试一样构建您的可观察性策略，并问自己：哪些关键绩效指标 (KPI) 可以证明代理正在创造价值？这些指标应该超越技术正确性，衡量现实世界的影响：目标完成率、用户满意度评分、任务延迟、每次交互的运营成本，以及——最重要的是——对收入、转化率或客户保留等业务目标的影响。这种自上而下的视图将指导您的其余测试，使您走上指标驱动开发之路，并让您计算投资回报。

Quality Instead of Pass/Fail: Using a LM Judge 质量而非通过/失败：使用 LM 评判

Business metrics don’t tell you if the agent is behaving correctly. Since a simple pass/fail is impossible, we shift to evaluating for quality using an “LM as Judge.” This involves using a powerful model to assess the agent’s output against a predefined rubric: Did it give the right answer? Was the response factually grounded? Did it follow instructions? This automated evaluation, run against a golden dataset of prompts, provides a consistent measure of quality.

Creating the evaluation datasets—which include the ideal (or “golden”) questions and correct responses—can be a tedious process. To build these, you should sample scenarios from existing production or development interactions with the agent. The dataset must cover the full breadth of use cases that you expect your users to engage with, plus a few unexpected ones. While investment in evaluation pays off quickly, evaluation results should always be reviewed by a domain expert before being accepted as valid. Increasingly, the curation and maintenance of these evaluations is becoming a key responsibility for Product Managers with the support from Domain experts.

业务指标无法告诉您代理是否行为正确。由于简单的通过/失败是不可能的，我们转向使用“LM 作为评判”来评估质量。这涉及使用强大的模型根据预定义的标准评估代理的输出：它是否给出了正确的答案？响应是否基于事实？它是否遵循了指令？这种针对黄金提示数据集运行的自动化评估提供了衡量质量的一致方法。

创建评估数据集——包括理想的（或“黄金”）问题和正确响应——可能是一个繁琐的过程。为了构建这些数据集，您应该从与代理的现有生产或开发交互中抽取场景。数据集必须涵盖您期望用户参与的所有用例，以及一些意外用例。虽然对评估的投资会很快得到回报，但评估结果在被接受为有效之前应始终由领域专家进行审查。产品经理在领域专家的支持下，对这些评估的策划和维护正日益成为一项关键职责。

Metrics-Driven Development: Your Go/No-Go for Deployment

指标驱动开发：部署的 Go/No-Go

Once you have automated dozens of evaluation scenarios and established trusted quality scores, you can confidently test changes to your development agent. The process is simple: run the new version against the entire evaluation dataset, and directly compare its scores to the existing production version. This robust system eliminates guesswork, ensuring you are confident in every deployment. While automated evaluations are critical, don’t forget other important factors like latency, cost, and task success rates. For maximum safety, use A/B deployments to slowly roll out new versions and compare these real-world production metrics alongside your simulation scores.

一旦您自动化了数十个评估场景并建立了受信任的质量分数，您就可以自信地测试开发代理的更改。过程很简单：针对整个评估数据集运行新版本，并将其分数与现有生产版本直接进行比较。这个健壮的系统消除了猜测，确保您对每次部署都充满信心。虽然自动化评估至关重要，但不要忘记其他重要因素，如延迟、成本和任务成功率。为了最大限度地提高安全性，请使用 A/B 部署来缓慢推出新版本，并同时比较这些真实世界的生产指标和您的模拟分数。

Debug with OpenTelemetry Traces: Answering “Why?”

使用 OpenTelemetry 跟踪进行调试：回答“为什么？”

When your metrics dip or a user reports a bug, you need to understand “why.” An OpenTelemetry trace is a high-fidelity, step-by-step recording of the agent’s entire execution path (trajectory), allowing you to debug the agent’s steps.25 With traces, you can see the exact prompt sent to the model, the model’s internal reasoning (if available), the specific tool it chose to call, the precise parameters it generated for that tool, and the raw data that came back as an observation. Traces can be complicated the first time you look at them but they provide the details needed to diagnose and fix the root cause of any issue. Important trace details may be turned into metrics, but reviewing traces is primarily for debugging, not overviews of performance. Trace data can be seamlessly collected in platforms like Google Cloud Trace, which visualize and search across vast quantities of traces, streamlining root cause analysis.

当您的指标下降或用户报告错误时，您需要了解“为什么”。OpenTelemetry 跟踪是代理整个执行路径（轨迹）的高保真、分步记录，允许您调试代理的步骤25。通过跟踪，您可以看到发送给模型的精确提示、模型的内部推理（如果可用）、它选择调用的特定工具、它为该工具生成的精确参数以及作为观察返回的原始数据。跟踪在您第一次查看时可能很复杂，但它们提供了诊断和修复任何问题的根本原因所需的详细信息。重要的跟踪详细信息可能会转换为指标，但审查跟踪主要用于调试，而不是性能概述。跟踪数据可以无缝收集在 Google Cloud Trace 等平台中，这些平台可视化和搜索大量跟踪，从而简化根本原因分析。

Cherish Human Feedback: Guiding Your Automation 珍视人工反馈：指导自动化

Human feedback is not an annoyance to be dealt with; it is the most valuable and data rich resource you have for improving your agent. When a user files a bug report or clicks the “thumbs down” button, they are giving you a gift: a new, real-world edge case that your automated eval scenarios missed. Collecting and aggregating this data is critical; when you see a statistically significant number of similar reports or metric dips, you must tie the occurrences back to your analytics platform to generate insights and trigger alerts for operational issues. An effective Agent Ops process “closes the loop” by capturing this feedback, replicating the issue, and converting that specific scenario into a new, permanent test case in your evaluation dataset. This ensures you not only fix the bug but also vaccinate the system against that entire class of error ever happening again.

人工反馈不是一个令人烦恼的问题；它是您改进代理最有价值和数据最丰富的资源。当用户提交错误报告或点击“不喜欢”按钮时，他们正在给您一份礼物：一个新的、真实的边缘案例，您的自动化评估场景遗漏了。收集和聚合这些数据至关重要；当您看到大量类似的报告或指标下降时，您必须

Agent Interoperability 代理互操作性

Once you build your high quality agents, you want to be able to interconnect them with users and other agents. In our body parts analogy, this would be the face of the Agent. There is a difference between connecting to agents versus connecting agents with data and APIs; Agents are not tools26. Let’s assume you already have tools wired into your agents, now let’s consider how you bring your agents into a wider ecosystem.

一旦您构建了高质量的代理，您会希望能够将它们与用户和其他代理互连。在我们的身体部位类比中，这将是代理的“面部”。连接代理与连接代理与数据和 API 之间存在差异；代理不是工具。让我们假设您已经将工具连接到您的代理，现在让我们考虑如何将您的代理带入更广泛的生态系统。

Agents and Humans

The most common form of agent-human interaction is through a user interface. In its simplest form, this is a chatbot, where a user types a request and the agent, acting as a backend service, processes it and returns a block of text. More advanced agents can provide structured data, like JSON, to power rich, dynamic front-end experiences. Human in the loop (HITL) interaction patterns include intent refinement, goal expansion, confirmation, and clarification requests.

Computer use is a category of tool where the LM takes control of a user interface, often with human interaction and oversight. A computer use enabled agent can decide that the next best action is to navigate to a new page, highlight a specific button, or pre-fill a form with relevant information27.

Instead of an agent using an interface on behalf of the user, the LM can change the UI to meet the needs of the moment. This can be done with Tools which control UI (MCP UI)28, or specialized UI messaging systems which can sync client state with an agent (AG UI)29, and even generation of bespoke interfaces (A2UI)30.

Of course, human interaction is not limited to screens and keyboards. Advanced agents are breaking the text barrier and moving into real-time, multimodal communication with “live mode” creating a more natural, human-like connection. Technologies like the Gemini Live API31 enable bidirectional streaming, allowing a user to speak to an agent and interrupt it, just as they would in a natural conversation.

This capability fundamentally changes the nature of agent-human collaboration. With access to a device’s camera and microphone, the agent can see what the user sees and hear what they say, responding with generated speech at a latency that mimics human conversation. This opens up a vast array of use cases that are simply impossible with text, from a technician receiving hands-free guidance while repairing a piece of equipment to a shopper getting real-time style advice. It makes the agent a more intuitive and accessible partner.

代理与人类最常见的互动形式是通过用户界面。最简单的形式是聊天机器人，用户输入请求，代理作为后端服务处理并返回一段文本。更高级的代理可以提供结构化数据（如 JSON），以支持丰富、动态的前端体验。人工介入 (HITL) 互动模式包括意图细化、目标扩展、确认和澄清请求。

计算机使用是一种工具类别，其中 LM 控制用户界面，通常伴随着人工互动和监督。一个启用计算机使用的代理可以决定下一步的最佳行动是导航到新页面、突出显示特定按钮或用相关信息预填充表单。

代理不仅可以代表用户使用界面，LM 还可以更改 UI 以满足当前需求。这可以通过控制 UI 的工具 (MCP UI) 或可以与代理同步客户端状态的专用 UI 消息系统 (AG UI)，甚至生成定制界面 (A2UI) 来完成。

当然，人机交互不仅限于屏幕和键盘。高级代理正在打破文本障碍，进入实时、多模态通信，通过“实时模式”创建更自然、更像人类的连接。像 Gemini Live API 这样的技术支持双向流媒体，允许用户与代理对话并打断它，就像在自然对话中一样。

这种能力从根本上改变了代理与人类协作的性质。通过访问设备的摄像头和麦克风，代理可以看到用户所见，听到用户所说，并以模仿人类对话的延迟生成语音进行响应。

Agents and Agents

Just as agents must connect with humans, they must also connect with each other. As an enterprise scales its use of AI, different teams will build different specialized agents. Without a common standard, connecting them would require building a tangled web of brittle, custom API integrations that are impossible to maintain. The core challenge is twofold: discovery (how does my agent find other agents and know what they can do?) and communication (how do we ensure they speak the same language?).

代理不仅与人类互动，还与其他代理互动。在多代理系统中，不同的代理可以协同工作以完成更复杂的任务。一个代理可以将任务委托给另一个专门的代理，或者将自己的输出作为另一个代理的输入。这种协作使得代理系统能够处理更大规模和更复杂的问题。

The Agent2Agent (A2A) protocol is the open standard designed to solve this problem. It acts as a universal handshake for the agentic economy. A2A allows any agent to publish a digital “business card,” known as an Agent Card. This simple JSON file advertises the agent’s capabilities, its network endpoint, and the security credentials required to interact with it. This makes discovery simple and standardized. As opposed to MCP which focuses on solving transactional requests, Agent 2 Agent communication is typically for additional problem solving.

Agent2Agent (A2A) 协议是旨在解决此问题的开放标准。它充当代理经济的普遍握手。 A2A 允许任何代理发布数字“名片”，称为代理卡。这个简单的 JSON 文件公布了代理的功能、其网络端点以及与之交互所需的安全凭证。 这使得发现变得简单和标准化。与专注于解决事务请求的 MCP 不同，Agent 2 代理通信通常用于解决其他问题。

Once discovered, agents communicate using a task-oriented architecture. Instead of a simple request-response, interactions are framed as asynchronous “tasks.” A client agent sends a task request to a server agent, which can then provide streaming updates as it works on the problem over a long-running connection. This robust, standardized communication protocol is the final piece of the puzzle, enabling the collaborative, Level 3 multi-agent systems that represent the frontier of automation. A2A transforms a collection of isolated agents into a true, interoperable ecosystem.

一旦被发现，代理就会使用面向任务的架构进行通信。交互不是简单的请求-响应，而是被构建为异步“任务”。客户端代理将任务请求发送到服务器代理，然后服务器代理可以在通过长时间运行的连接解决问题时提供流式更新。这种强大的标准化通信协议是解决这个难题的最后一块，它支持代表自动化前沿的协作式 3 级多代理系统。 A2A 将一组孤立的代理转变为一个真正的、可互操作的生态系统。

Agents and Money

As AI agents do more tasks for us, a few of those tasks involve buying or selling, negotiating or facilitating transactions. The current web is built for humans clicking “buy,” the responsibility is on the human. If an autonomous agent clicks “buy” it creates a crisis of trust – if something goes wrong, who is at fault? These are complex issues of authorization, authenticity, and accountability. To unlock a true agentic economy, we need new standards that allow agents to transact securely and reliably on behalf of their users.

随着人工智能代理为我们完成更多任务，其中一些任务涉及买卖、谈判或促进交易。当前的网络是为人类点击“购买”而构建的，责任在于人类。如果自主代理点击“购买”，就会产生信任危机——如果出现问题，谁有错？这些是授权、真实性和问责制的复杂问题。为了开启真正的代理经济，我们需要新的标准，让代理能够代表用户安全可靠地进行交易。

This emerging area is far from established, but two key protocols are paving the way. The Agent Payments Protocol (AP2) is an open protocol designed to be the definitive language for agentic commerce. It extends protocols like A2A by introducing cryptographically-signed digital “mandates.” These act as verifiable proof of user intent, creating a non-repudiable audit trail for every transaction. This allows an agent to securely browse, negotiate, and transact on a global scale based on delegated authority from the user. Complementing this is x402, an open internet payment protocol that uses the standard HTTP 402 “Payment Required” status code. It enables frictionless, machine-to-machine micropayments, allowing an agent to pay for things like API access or digital content on a pay-per-use basis without needing complex accounts or subscriptions. Together, these protocols are building the foundational trust layer for the agentic web.

这个新兴领域远未建立，但两个关键协议正在铺平道路。代理支付协议 (AP2) 是一种开放协议，旨在成为代理商务的权威语言。它通过引入加密签名的数字“授权”来扩展 A2A 等协议。这些充当用户意图的可验证证明，为每笔交易创建不可否认的审计跟踪。这使得代理可以根据用户授予的权限在全球范围内安全地浏览、协商和交易。对此的补充是 x402，这是一种开放的互联网支付协议，使用标准 HTTP 402“需要付款”状态代码。它支持无摩擦的机器对机器小额支付，允许代理按按使用付费的方式支付 API 访问或数字内容等费用，而无需复杂的帐户或订阅。这些协议共同构建了代理网络的基础信任层。

Security

Securing a Single Agent: The Trust Trade-Off

确保单一代理的安全：信任权衡

When you create your first AI agent, you immediately face a fundamental tension: the trade-off between utility and security. To make an agent useful, you must give it power—the autonomy to make decisions and the tools to perform actions like sending emails or querying databases. However, every ounce of power you grant introduces a corresponding measure of risk. The primary security concerns are rogue actions—unintended or harmful behaviors—and sensitive data disclosure. You want to give your agent a leash long enough to do its job, but short enough to keep it from running into traffic, especially when that traffic involves irreversible actions or your company’s private data.32

To manage this, you cannot rely solely on the AI model’s judgment, as it can be manipulated by techniques like prompt injection33. Instead, the best practice is a hybrid, defense-in depth approach.34 The first layer consists of traditional, deterministic guardrails—a set of hardcoded rules that act as a security chokepoint outside the model’s reasoning. This could be a policy engine that blocks any purchase over $100 or requires explicit user confirmation before the agent can interact with an external API. This layer provides predictable, auditable hard limits on the agent’s power.

The second layer leverages reasoning-based defenses, using AI to help secure AI. This involves training the model to be more resilient to attacks (adversarial training) and employing smaller, specialized “guard models” that act like security analysts. These models can examine the agent’s proposed plan before it’s executed, flagging potentially risky or policy-violating steps for review. This hybrid model, combining the rigid certainty of code with the contextual awareness of AI, creates a robust security posture for even a single agent, ensuring its power is always aligned with its purpose.

当您创建第一个人工智能代理时，您立即面临一个根本性的紧张局势：实用性和安全性之间的权衡。要使代理发挥作用，您必须赋予它权力 - 做出决策的自主权以及执行发送电子邮件或查询数据库等操作的工具。然而，您授予的每一盎司权力都会带来相应的风险。主要的安全问题是流氓行为——无意的或有害的行为——和敏感数据泄露。您希望给您的代理足够长的约束来完成其工作，但又足够短以防止其遇到流量，特别是当流量涉及不可逆转的操作或您公司的私人数据时。

为了解决这个问题，您不能仅仅依赖人工智能模型的判断，因为它可以通过提示注入等技术来操纵 。相反，最佳实践是混合的深度防御方法。 第一层由传统的确定性护栏组成——一组硬编码规则，充当模型推理之外的安全障碍。这可能是一个策略引擎，阻止任何超过 100 美元的购买，或者需要用户明确确认，然后代理才能与外部 API 交互。该层对代理的权力提供可预测、可审计的硬性限制。

第二层利用基于推理的防御，利用人工智能来帮助保护人工智能。这涉及训练模型以使其更能抵御攻击（对抗性训练），并采用更小的、专门的“守卫模型”来充当安全分析师的角色。这些模型可以在执行之前检查代理提出的计划，标记潜在风险或违反政策的步骤以供审查。这种混合模型将代码的严格确定性与人工智能的上下文感知相结合，甚至可以为单个代理创建强大的安全态势，确保其功能始终与其目的保持一致。

Agent Identity: A New Class of Principal 代理人身份：新型委托人

In the traditional security model, there are human users which might use OAuth or SSO, and there are services which use IAM or service accounts. Agents add a 3rd category of principle. An agent is not merely a piece of code; it is an autonomous actor, a new kind of principal that requires its own verifiable identity. Just as employees are issued an ID badge, each agent on the platform must be issued a secure, verifiable “digital passport.” This Agent Identity is distinct from the identity of the user who invoked it and the developer who built it. This is a fundamental shift in how we must approach Identity and Access Management (IAM) in the enterprise.

在传统的安全模型中，有些人类用户可能使用 OAuth 或 SSO，有些服务使用 IAM 或服务帐户。特工添加了第三类原则。代理不仅仅是一段代码；它是一个自主参与者，是一种需要自己可验证身份的新型主体。正如向员工发放身份证一样，平台上的每个代理都必须获得安全、可验证的“数字护照”。这位代理身份不同于调用它的用户和构建它的开发人员的身份。 这是我们在企业中实施身份和访问管理 (IAM) 的方式的根本转变。

Having each identity be verified and having access controls for all of them, is the bedrock of agent security. Once an agent has a cryptographically verifiable identity (often using standards like SPIFFE35), it can be granted its own specific, least-privilege permissions. The SalesAgent is granted read/write access to the CRM, while the HRonboardingAgent is explicitly denied. This granular control is critical. It ensures that even if a single agent is compromised or behaves unexpectedly, the potential blast radius is contained. Without an agent identity construct, agents cannot work on behalf of humans with limited delegated authority.

验证每个身份并对所有身份进行访问控制是代理安全的基石。一旦代理拥有可加密验证的身份（通常使用 SPIFFE 35 等标准），它就可以被授予自己特定的、最低权限的权限。 SalesAgent 被授予对 CRM 的读/写访问权限，而 HRonboardingAgent 则被明确拒绝。这种精细的控制至关重要。它确保即使单个代理受到损害或行为异常，潜在的爆炸半径也能得到控制。如果没有代理身份构建，代理就无法以有限的授权代表人类工作。

Principal entity Authentication / Verification Notes

Authenticated with OAuth or SSO
Verified with SPIFFE

Users Human actors with full autonomy and responsibility for

their actions

Agents (new category of principles)
Agents have delegated authority, taking actions on behalf of users

Service accounts Integrated into IAM Applications and containers, fully deterministic, no

responsible for actions

Table 1: A non-exhaustive example of different categories of actors for authentication

Policies to Constrain Access

A policy is a form of authorization (AuthZ), distinct from authentication (AuthN). Typically, policies limit the capabilities of a principal; for example, “Users in Marketing can only access these 27 API endpoints and cannot execute DELETE commands.” As we develop agents, we need to apply permissions to the agents, their tools, other internal agents, context they can share, and remote agents. Think about it this way: if you add all the APIs, data, tools, and agents to your system, then you must constrain access to a subset of just those capabilities required to get their jobs done. This is the recommended approach: applying the principle of least privilege while remaining contextually relevant.36

策略是授权 (AuthZ) 的一种形式，与身份验证 (AuthN) 不同。通常，政策会限制委托人的能力；例如，“营销部门的用户只能访问这 27 个 API 端点，无法执行 DELETE 命令。”当我们开发代理时，我们需要向代理、他们的工具、其他内部代理、他们可以共享的上下文以及远程代理应用权限。可以这样想：如果您将所有 API、数据、工具和代理添加到系统中，那么您必须限制对完成工作所需的部分功能的访问。这是推荐的方法：应用最小权限原则，同时保持上下文相关性。 36

Securing an ADK Agent

With the core principles of identity and policy established, securing an agent built with the Agent Development Kit (ADK) becomes a practical exercise in applying those concepts through code and configuration37.

确立了身份和策略的核心原则后，保护使用代理开发工具包 (ADK) 构建的代理就成为通过代码和配置应用这些概念的实际练习 37 。

As described above, the process requires a clear definition of identities: user account (for example OAuth), service account (to run code), agent identity (to use delegated authority). Once authentication is handled, the next layer of defense involves establishing policies to constrain access to services. This is often done at the API governance layer, along with governance supporting MCP and A2A services.

The next layer is building guardrails into your tools, models, and sub-agents to enforce policies. This ensures that no matter what the LM reasons or what a malicious prompt might suggest, the tool’s own logic will refuse to execute an unsafe or out-of-policy action. This approach provides a predictable and auditable security baseline, translating abstract security policies into concrete, reliable code38.For more dynamic security that can adapt to the agent’s runtime behavior, ADK provides Callbacks and Plugins. A before_tool_callback allows you to inspect the parameters of a tool call before it runs, validating them against the agent’s current state to prevent misaligned actions. For more reusable policies, you can build plugins. A common pattern is a “Gemini as a Judge”39 that uses a fast, inexpensive model like Gemini Flash-Lite or your own fine-tuned Gemma model to screen user inputs and agent outputs for prompt injections or harmful content in real time.

For organizations that prefer a fully managed, enterprise-grade solution for these dynamic checks, Model Armor can be integrated as an optional service. Model Armor acts as a specialized security layer that screens prompts and responses for a wide range of threats, including prompt injection, jailbreak attempts, sensitive data (PII) leakage, and malicious URLs40. By offloading these complex security tasks to a dedicated service, developers can ensure consistent, robust protection without having to build and maintain these guardrails themselves. This hybrid approach within ADK—combining strong identity, deterministic in-tool logic, dynamic AI-powered guardrails, and optional managed services like Model Armor—is how you build a single agent that is both powerful and trustworthy.

![][image6]
Figure 6: Security and Agents from https://saif.google/focus-on-agents

如上所述，该流程需要明确的身份定义：用户帐户（例如 OAuth）、服务帐户（用于运行代码）、代理身份（用于使用委派权限）。 处理完身份验证后，下一层防御涉及建立限制对服务的访问的策略。这通常在 API 治理层以及支持 MCP 和 A2A 服务的治理中完成。

下一层是在您的工具、模型和子代理中构建护栏以执行策略。这确保了无论 LM 的原因是什么或恶意提示可能建议什么，该工具自身的逻辑都将拒绝执行不安全或不符合策略的操作。 这种方法提供了可预测和可审核的安全基线，将抽象的安全策略转化为具体、可靠的代码 38 。

为了适应代理运行时行为的更动态的安全性，ADK 提供了回调和插件。 before_tool_callback 允许您在工具调用运行之前检查其参数，根据代理的当前状态验证它们，以防止出现不一致的操作。对于更多可重用的策略，您可以构建插件。一种常见的模式是“Gemini 作为法官”39，它使用快速、廉价的模型（如 Gemini Flash-Lite 或您自己的微调 Gemma 模型）来实时筛选用户输入和代理输出，以发现提示注入或有害内容。

对于更喜欢完全托管的企业级解决方案来进行这些动态检查的组织，可以将 Model Armor 作为一项可选服务进行集成。 Model Armor 充当专门的安全层，可筛选各种威胁的提示和响应，包括提示注入、越狱尝试、敏感数据 (PII) 泄露和恶意 URL 40 。通过将这些复杂的安全任务转移给专用服务，开发人员可以确保一致、强大的保护，而无需自行构建和维护这些护栏。 ADK 中的这种混合方法结合了强大的身份、确定性的工具内逻辑、动态 AI 驱动的护栏以及 Model Armor 等可选的托管服务，这就是您构建强大且值得信赖的单一代理的方式。

Scaling Up from a Single Agent to an Enterprise Fleet

从单个代理扩展到企业队列

The production success of a single AI agent is a triumph. Scaling to a fleet of hundreds is a challenge of architecture. If you are building one or two agents, your concerns are primarily about security. If you are building many agents, you must design systems to handle much more. Just like API sprawl, when agents and tools proliferate across an organization, they create a new, complex network of interactions, data flows, and potential security vulnerabilities. Managing this complexity requires a higher-order governance layer integrating all your identities and policies and reporting into a central control plane.

单个人工智能代理的生产成功是一次胜利。扩展到数百人的车队是架构上的一个挑战。如果您正在构建一两个代理，您的担忧主要是安全性。如果您要构建许多代理，则必须设计能够处理更多代理的系统。就像 API 蔓延一样，当代理和工具在整个组织中激增时，它们创建了一个新的、复杂的交互网络、数据流和潜在的安全漏洞。管理这种复杂性需要一个更高阶的治理层，将您的所有身份和策略以及报告集成到中央控制平面中。

Security and Privacy: Hardening the Agentic Frontier 安全和隐私：强化代理前沿

An enterprise-grade platform must address the unique security and privacy challenges inherent to generative AI, even when only a single agent is running. The agent itself becomes a new attack vector. Malicious actors can attempt prompt injection to hijack the agent’s instructions, or data poisoning to corrupt the information it uses for training or RAG. Furthermore, a poorly constrained agent could inadvertently leak sensitive customer data or proprietary information in its responses.

A robust platform provides a defense-in-depth strategy to mitigate these risks. It starts with the data, ensuring that an enterprise’s proprietary information is never used to train base models and is protected by controls like VPC Service Controls. It requires input and output filtering, acting like a firewall for prompts and responses. Finally, the platform must offer contractual protections like intellectual property indemnity for both the training data and the generated output, giving enterprises the legal and technical confidence they need to deploy agents in production.

企业级平台必须解决生成式 AI 固有的独特安全和隐私挑战，即使只有一个代理运行时也是如此。代理本身成为新的攻击媒介。恶意行为者可能会尝试通过提示注入来劫持代理的指令，或者尝试进行数据中毒来破坏其用于训练或 RAG 的信息。 此外，约束不力的代理可能会无意中在其响应中泄露敏感的客户数据或专有信息。

强大的平台提供深度防御策略来减轻这些风险。它从数据开始，确保企业的专有信息永远不会用于训练基础模型，并受到 VPC 服务控制等控制措施的保护。它需要输入和输出过滤，就像提示和响应的防火墙一样。最后，该平台必须为训练数据和生成的输出提供知识产权赔偿等合同保护，为企业提供在生产中部署代理所需的法律和技术信心。

Agent Governance: A Control Plane instead of Sprawl

代理治理：控制平面而不是蔓延

As agents and their tools proliferate across an organization, they create a new, complex network of interactions and potential vulnerabilities, a challenge often called “agent sprawl.” Managing this requires moving beyond securing individual agents to implementing a higher order architectural approach: a central gateway that serves as a control plane for all agentic activity.

随着代理及其工具在整个组织中激增，它们创建了一个新的、复杂的交互网络和潜在漏洞，这一挑战通常称为“代理蔓延”。 管理这一点需要超越保护单个代理的安全，而是实施更高阶的架构方法：充当所有代理活动的控制平面的中央网关。

Imagine a bustling metropolis with thousands of autonomous vehicles—users, agents, and tools—all moving with purpose. Without traffic lights, license plates and a central control system, chaos would reign. The gateway approach creates that control system, establishing a mandatory entry point for all agentic traffic, including user-to-agent prompts or UI interactions, agent-to-tool calls (via MCP), agent-to-agent collaborations (via A2A), and direct inference requests to LMs. By sitting at this critical intersection, an organization can inspect, route, monitor, and manage every interaction.

想象一下一个繁华的大都市，拥有数千辆自动驾驶汽车（用户、代理和工具），所有这些都在有目的地行驶。如果没有交通信号灯、车牌和中央控制系统，混乱就会盛行。网关方法创建该控制系统，为所有代理流量建立强制入口点，包括用户到代理提示或 UI 交互、代理到工具调用（通过 MCP）、代理到代理协作（通过 A2A）以及对 LM 的直接推理请求。通过坐在这个关键的十字路口，组织可以检查、路由、监控和管理每一次交互。

This control plane serves two primary, interconnected functions:

该控制平面提供两个主要的、相互关联的功能：

1. Runtime Policy Enforcement: It acts as the architectural chokepoint for implementing security. It handles authentication (“Do I know who this actor is?”) and authorization (“Do they have permission to do this?”). Centralizing enforcement provides a “single pane of glass” for observability, creating common logs, metrics, and traces for every transaction. This transforms the spaghetti of disparate agents and workflows into a transparent and auditable system.

1.运行时策略执行：它充当实现安全性的架构瓶颈。它处理身份验证（“我知道这个演员是谁吗？”）和授权（“他们有权限这样做吗？”）。集中执行提供了可观察性的“单一管理平台”，为每笔交易创建通用日志、指标和跟踪。 这将混乱的不同代理和工作流程转变为透明且可审计的系统。

2. Centralized Governance: To enforce policies effectively, the gateway needs a source of truth. This is provided by a central registry—an enterprise app store for agents and tools. This registry allows developers to discover and reuse existing assets, preventing redundant work, while giving administrators a complete inventory. More importantly, it enables a formal lifecycle for agents and tools, allowing for security reviews before publication, versioning, and the creation of fine-grained policies that dictate which business units can access which agents.

2.集中治理：为了有效执行策略，网关需要事实来源。这是由中央注册表提供的——一个用于代理和工具的企业应用程序商店。该注册表允许开发人员发现和重用现有资产，防止重复工作，同时为管理员提供完整的清单。更重要的是，它为代理和工具提供了正式的生命周期，允许在发布之前进行安全审查、版本控制以及创建细粒度的策略来规定哪些业务部门可以访问哪些代理。

By combining a runtime gateway with a central governance registry, an organization transforms the risk of chaotic sprawl into a managed, secure, and efficient ecosystem.

通过将运行时网关与中央治理注册表相结合，组织可以将混乱蔓延的风险转变为受管理、安全且高效的生态系统。

Cost and Reliability: The Infrastructure Foundation

成本和可靠性：基础设施基础

Ultimately, enterprise-grade agents must be both reliable and cost-effective. An agent that frequently fails or provides slow results has a negative ROI. Conversely, an agent that is prohibitively expensive cannot scale to meet business demands. The underlying infrastructure must be designed to manage this trade-off, securely and with regulatory and data sovereignty compliance.

最终，企业级代理必须既可靠又具有成本效益。经常失败或提供缓慢结果的代理会产生负投资回报率。相反，价格过高的代理无法扩展以满足业务需求。底层基础设施的设计必须能够安全地管理这种权衡，并符合监管和数据主权要求。

In some cases, the feature you need is scale-to-zero, when you have irregular traffic to a specific agent or sub-function. For mission-critical, latency-sensitive workloads, the platform must offer dedicated, guaranteed capacity, such as Provisioned Throughput41 for LM services or 99.9% Service Level Agreements (SLAs) for runtimes like Cloud Run42. This provides a predictable performance, ensuring that your most important agents are always responsive, even under heavy load. By providing this spectrum of infrastructure options, coupled with comprehensive monitoring for both cost and performance, you establish the final, essential foundation for scaling AI agents from a promising innovation into a core, reliable component of the enterprise.

在某些情况下，当特定代理或子功能的流量不规律时，您需要的功能是缩放至零。对于任务关键型、延迟敏感的工作负载，平台必须提供专用的、有保障的容量，例如针对 LM 服务的预置吞吐量 41 或针对 Cloud Run 等运行时的 99.9% 服务级别协议 (SLA) 42 。这提供了可预测的性能，确保您最重要的代理始终做出响应，即使在重负载下也是如此。通过提供一系列基础设施选项，再加上对成本和性能的全面监控，您可以为将 AI 代理从有前途的创新扩展到企业的核心、可靠组件奠定最终的重要基础。

How agents evolve and learn 代理如何演进和学习

Agents deployed in the real world operate in dynamic environments where policies, technologies, and data formats are constantly changing. Without the ability to adapt, an agent’s performance will degrade over time—a process often called “aging”—leading to a loss of utility and trust. Manually updating a large fleet of agents to keep pace with these changes is uneconomical and slow. A more scalable solution is to design agents that can learn and evolve autonomously, improving their quality on the job with minimal engineering effort

部署在现实世界中的代理在动态环境中运行，其中政策、技术和数据格式不断变化。如果没有适应能力，代理的表现会随着时间的推移而下降——这个过程通常称为“老化”——导致效用和信任的丧失。手动更新大量代理来跟上这些变化是不经济且缓慢的。更具可扩展性的解决方案是设计能够自主学习和进化的代理，以最少的工程工作提高其工作质量。

How agents learn and self evolve 代理如何学习和自我演进

Much like humans, agents learn from experience and external signals. This learning process is fueled by several sources of information:

就像人类一样，代理从经验和外部信号中学习。这一学习过程由多种信息来源推动：

• Runtime Experience: Agents learn from runtime artifacts such as session logs, traces, and memory, which capture successes, failures, tool interactions, and decision trajectories. Crucially, this includes Human-in-the-Loop (HITL) feedback, which provides authoritative corrections and guidance.

运行时体验：代理从会话日志、跟踪和内存等运行时工件中学习，这些工件捕获成功、失败、工具交互和决策轨迹。至关重要的是，这包括人在环 (HITL) 反馈，它提供权威的纠正和指导。

• External Signals: Learning is also driven by new external documents, such as updated enterprise policies, public regulatory guidelines, or critiques from other agents.

外部信号：学习也受到新的外部文件的推动，例如更新的企业政策、公共监管指南或其他机构的批评。

This information is then used to optimize the agent’s future behavior. Instead of simply summarizing past interactions, advanced systems create generalizable artifacts to guide future tasks. The most successful adaptation techniques fall into two categories:

然后，该信息用于优化代理的未来行为。先进的系统不是简单地总结过去的交互，而是创建可概括的工件来指导未来的任务。最成功的适应技术分为两类：

• Enhanced Context Engineering: The system continuously refines its prompts, few shot examples, and the information it retrieves from memory. By optimizing the context provided to the LM for each task, it increases the likelihood of success.

增强的情境工程：系统不断完善其提示、少量镜头示例以及从内存中检索的信息。通过优化为每个任务提供给 LM 的上下文，可以增加成功的可能性。

• Tool Optimization and Creation: The agent’s reasoning can identify gaps in its capabilities and act to fill them. This can involve gaining access to a new tool, creating a new one on the fly (e.g., a Python script), or modifying an existing tool (e.g., updating an API schema).

工具优化和创建：代理的推理可以识别其能力中的差距并采取行动来填补它们。这可能涉及访问新工具、动态创建新工具（例如 Python 脚本）或修改现有工具（例如更新 API 架构）。

Additional optimization techniques, such as dynamically reconfiguring multi-agent design patterns or using Reinforcement Learning from Human Feedback (RLHF), are active areas of research.

其他优化技术，例如动态重新配置多代理设计模式或使用人类反馈强化学习 (RLHF)，是活跃的研究领域。

Example: Learning New Compliance Guidelines 学习新的合规准则

Consider an enterprise agent operating in a heavily regulated industry like finance or life sciences. Its task is to generate reports that must comply with privacy and regulatory rules (e.g., GDPR).

This can be implemented using a multi-agent workflow:

1. A Querying Agent retrieves raw data in response to a user request. 2. A Reporting Agent synthesizes this data into a draft report.

3. A Critiquing Agent, armed with known compliance guidelines, reviews the report. If it encounters ambiguity or requires final sign-off, it escalates to a human domain expert.

4. A Learning Agent observes the entire interaction, paying special attention to the corrective feedback from the human expert. It then generalizes this feedback into a new, reusable guideline (e.g., an updated rule for the critiquing agent or refined context for the reporting agent).![][image7]

Figure 7: Sample multi agent workflow for compliance guidelines

For instance, if a human expert flags that certain household statistics must be anonymized, the Learning Agent records this correction. The next time a similar report is generated, the Critiquing Agent will automatically apply this new rule, reducing the need for human intervention. This loop of critique, human feedback, and generalization allows the system to autonomously adapt to evolving compliance requirements44.

Simulation and Agent Gym - the next frontier

模拟和代理健身房 - 下一个前沿

The design pattern we presented can be categorized as in-line learning, where agents need to learn with the resources and design pattern they were engineered with. More advanced approaches are now being researched, where there is a dedicated platform that is engineered to optimize the multi-agent system in offline processes with advanced tooling and capabilities, which are not part of the multi-agent run-time environment. The key attributes of such an Agent Gym45 are:

1. It is not in the execution path. It is a standalone off-production platform, and therefore can have the assistance of any LM model, and offline tools, cloud application and more

2. It offers a simulation environment, so the agent can ‘exercise’ on new data and learn. This simulation environment is excellent for ‘trial-and-error’ with many optimizations pathways

3. It can call advance synthetic data generators, which guide the simulation to be as real as possible, and pressure test the agent (this can include advance techniques, such as red teaming, dynamic evaluation and a family of critiquing agents)

4. The arsenal of the optimization tools is not fixed, and it can adopt new tools (either through open protocols such as MCP or A2A), or in a more advanced setting - learn new concepts and craft tools around them

5. Finally, even constructs such as Agent Gym, may not be able to overcome certain edge case (due to the well known problem of ‘tribal knowledge’ in the enterprise). In those cases we see the Agent Gym able to connect to the human fabric of domain experts, and consult with them on the right set of outcomes to guide the next set of optimizations

Examples of advanced agents

Google Co-Scientist

Co-Scientist is an advanced AI agent designed to function as a virtual research collaborator, accelerating scientific discovery by systematically exploring complex problem spaces. It enables researchers to define a goal, ground the agent in specified public and proprietary knowledge sources, and then generate and evaluate a landscape of novel hypotheses.

In order to be able to achieve this, Co-Scientist spawns a whole ecosystem of agents collaborating with each other.

![][image8]Figure 8: The AI co-scientist design system

Think of the system as a research project manager. The AI first takes a broad research goal and creates a detailed project plan. A “Supervisor” agent then acts as the manager, delegating tasks to a team of specialized agents and distributing resources like computing power. This structure ensures the project can easily scale up and that the team’s methods improve as they work toward the final goal.

![][image9]Figure 9: Co-scientist multi agent workflow

The various agents work for hours, or even days, and keep improving the generated hypotheses, running loops and meta loops that improve not only the generated ideas, but also the way that we judge and create new ideas.

AlphaEvolve Agent

Another example of an advanced agentis system is AlphaEvolve, an AI agent that discovers and optimizes algorithms for complex problems in mathematics and computer science.

AlphaEvolve works by combining the creative code generation of our Gemini language models with an automated evaluation system. It uses an evolutionary process: the AI generates potential solutions, an evaluator scores them, and the most promising ideas are used as inspiration for the next generation of code.

This approach has already led to significant breakthroughs, including:

• Improving the efficiency of Google’s data centers, chip design, and AI training. • Discovering faster matrix multiplication algorithms.

• Finding new solutions to open mathematical problems.

AlphaEvolve excels at problems where verifying the quality of a solution is far easier than finding it in the first place.

![][image10]Figure 10: Alpha Evolve design system

AlphaEvolve is designed for a deep, iterative partnership between humans and AI. This collaboration works in two main ways:

• Transparent Solutions: The AI generates solutions as human-readable code. This transparency allows users to understand the logic, gain insights, trust the results, and directly modify the code for their needs.

• Expert Guidance: Human expertise is essential for defining the problem. Users guide the AI by refining evaluation metrics and steering the exploration, which prevents the system from exploiting unintended loopholes in the problem’s definition. This interactive loop ensures the final solutions are both powerful and practical.

The result of the agent is a continuous improvement of the code that keeps improving the metrics specified by the human.

![][image11]Figure 11: Algorithm evolution

Conclusion 总结

Generative AI agents mark a pivotal evolution, shifting artificial intelligence from a passive tool for content creation to an active, autonomous partner in problem-solving. This document has provided a formal framework for understanding and building these systems, moving beyond the prototype to establish a reliable, production-grade architecture.

生成式人工智能代理标志着一次关键的演变，它将人工智能从被动的内容创建工具转变为主动、自主的解决问题的合作伙伴。本文档提供了一个用于理解和构建这些系统的正式框架，超越了原型，建立了可靠的生产级架构。

We have deconstructed the agent into its three essential components: the reasoning Model (the “Brain”), the actionable Tools (the “Hands”), and the governing Orchestration Layer (the “Nervous System”). It is the seamless integration of these parts, operating in a continuous “Think, Act, Observe” loop, that unlocks an agent’s true potential. By classifying agentic systems- from the Level 1 Connected Problem-Solver to the Level 3 Collaborative Multi-Agent System -architects and product leaders can now strategically scope their ambitions to match the complexity of the task at hand.

我们将代理解构为三个基本组件：推理模型（“大脑”）、可操作的工具（“手”）和管理编排层（“神经系统”）。正是这些部分的无缝集成，在连续的“思考、行动、观察”循环中运行，才能释放代理的真正潜力。通过对代理系统进行分类（从 1 级互联问题解决器到 3 级协作多代理系统），架构师和产品负责人现在可以战略性地确定他们的目标，以匹配手头任务的复杂性。

The central challenge, and opportunity, lies in a new developer paradigm. We are no longer simply “bricklayers” defining explicit logic; we are “architects” and “directors” who must guide, constrain, and debug an autonomous entity. The flexibility that makes LMs so powerful is also the source of their unreliability. Success, therefore, is not found in the initial prompt alone, but in the engineering rigor applied to the entire system: in robust tool contracts, resilient error handling, sophisticated context management, and comprehensive evaluation.

核心挑战和机遇在于新的开发模式。我们不再只是定义显式逻辑的“瓦工”；我们是“建筑师”和“导演”，必须指导、约束和调试一个自治实体。 LM 如此强大的灵活性也是其不可靠性的根源。因此，成功不仅仅在于最初的提示，还在于应用于整个系统的工程严谨性：强大的工具契约、弹性错误处理、复杂的上下文管理和综合评估。

The principles and architectural patterns outlined here serve as a foundational blueprint. They are the guideposts for navigating this new frontier of software, enabling us to build not just “workflow automation,” but truly collaborative, capable, and adaptable new members of our teams. As this technology matures, this disciplined, architectural approach will be the deciding factor in harnessing the full power of agentic AI.

这里概述的原则和架构模式可作为基本蓝图。 它们是探索软件新领域的路标，使我们不仅能够构建“工作流程自动化”，而且能够构建真正协作、有能力、适应性强的团队新成员。随着这项技术的成熟，这种严格的架构方法将成为充分利用代理人工智能力量的决定性因素。

Endnotes

1. Julia Wiesinger, Patrick Marlow, et al. 2024 “Agents”.

Available at: https://www.kaggle.com/whitepaper-agents.

2. Antonio Gulli, Lavi Nigam, et al. 2025 “Agents Companion”.

Available at: https://www.kaggle.com/whitepaper-agent-companion.

3. Shunyu Yao, Y. et al., 2022, ‘ReAct: Synergizing Reasoning and Acting in Language Models’. Available at: https://arxiv.org/abs/2210.03629.

4. Wei, J., Wang, X. et al., 2023, ‘Chain-of-Thought Prompting Elicits Reasoning in Large Language Models’. Available at: https://arxiv.org/pdf/2201.11903.pdf.

5. Shunyu Yao, Y. et al., 2022, ‘ReAct: Synergizing Reasoning and Acting in Language Models’. Available at: https://arxiv.org/abs/2210.03629.

6. https://www.amazon.com/Agentic-Design-Patterns-Hands-Intelligent/dp/3032014018

7. Shunyu Yao, et. al., 2024, ‘τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains’, Available at: https://arxiv.org/abs/2406.12045.

8. https://artificialanalysis.ai/guide

9. https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/vertex-ai-model-optimizer 10. https://gemini.google/overview/gemini-live/

11. https://cloud.google.com/vision?e=48754805\&hl=en

12. https://cloud.google.com/speech-to-text?e=48754805\&hl=en

13. https://medium.com/google-cloud/genaiops-operationalize-generative-ai-a practical-guide-d5bedaa59d78

14. https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/code-execution/overview 15. https://ai.google.dev/gemini-api/docs/function-calling

16. https://github.com/modelcontextprotocol/

17. https://ai.google.dev/gemini-api/docs/google-search

18. https://google.github.io/adk-docs/

19. https://google.github.io/adk-docs/sessions/memory/

20. https://cloud.google.com/architecture/choose-design-pattern-agentic-ai-system 21. https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview 22. https://cloud.google.com/kubernetes-engine/docs/concepts/gke-and-cloud-run 23. https://github.com/GoogleCloudPlatform/agent-starter-pack

24. Sokratis Kartakis, 2024, ‘GenAI in Production: MLOps or GenAIOps?’. Available at: https://medium.com/ google-cloud/genai-in-production-mlops-or-genaiops-25691c9becd0.

25. Guangya Liu, Sujay Solomon, March 2025 “AI Agent Observability - Evolving Standards and Best Practice”. Available at: https://opentelemetry.io/blog/2025/ai-agent-observability/.

26. https://discuss.google.dev/t/agents-are-not-tools/192812

27. Damien Masson et. al, 2024, ‘DirectGPT: A Direct Manipulation Interface to Interact with Large Language Models’. Available at: https://arxiv.org/abs/2310.03691.

28. MCP UI is a system of controlling UI via MCP tools https://mcpui.dev/.

29. AG UI is a protocol of controlling UI via event passing and optionally shared state https://ag-ui.com/.

30. A2UI is a protocol of generating UI via structured output and A2A message

passing https://github.com/google/A2UI.

31. https://cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/2-5-flash-live-api. 32. https://saif.google/focus-on-agents.

33. https://simonwillison.net/series/prompt-injection/.

34. https://storage.googleapis.com/gweb-research2023-media/pubtools/1018686.pdf. 35. https://spiffe.io/.

36. https://openreview.net/pdf?id=l9rATNBB8Y.

37. https://google.github.io/adk-docs/safety/.

38. https://google.github.io/adk-docs/callbacks/design-patterns-and-best-practices /#guardrails-policy-enforcement

39. TKTK

40. https://cloud.google.com/security-command-center/docs/model-armor-overview 41. https://cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/overview 42. https://cloud.google.com/run/sla

43. https://github.com/CharlesQ9/Self-Evolving-Agents

44. Juraj Gottweis, et. al., 2025, ‘Accelerating scientific breakthroughs with an AI co-scientist’. Available at: https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/.

45. Deepak Nathani et. al. 2025, ‘MLGym: A New Framework and Benchmark for Advancing AI Research Agents’, Available at: https://arxiv.org/abs/2502.14499.