Zero 中的 A2A 是什么？
Zero A2A 是产品内部智能体之间通信的一种实用形式。它允许一个智能体开启多个相互隔离的对话，允许协调者将有边界的工作委派给专业智能体，还允许你在对话输入框中输入 @ 将现有对话引入比较、交接或决策流程。
当一项任务范围过广、信息过于嘈杂或风险过高，不适合在一个漫长的对话中完成时，这种方式就非常有用。与其让一个智能体在同一上下文中承载所有测试、来源和决策，不如为每项工作划定清晰的归属，只将关键证据汇总回来。
A2A 在 Zero 中的三种使用方式
| 你想做什么 | 使用此设置 | 适合的入门场景 |
|---|---|---|
| 在干净的上下文中重复同一方法 | 一个智能体，多个对话 | 分别测试注册、账单、权限和移动端 |
| 将任务的各个部分交给不同专家 | 一个协调者，多个专业智能体或子智能体 | 将发布工作拆分为研究、浏览器 QA、写作和发布 |
| 复用已有的工作成果 | 在输入框中 @ 另一个对话 | 比较两份 QA 报告，或将研究内容传入写作任务 |
这些模式背后有三个产品对象：
- 智能体是可复用的工作单元。它拥有指令、工作流、连接器、权限、语气、角色和模型选择。
- 对话是与智能体进行的一次隔离会话。它将测试、审查或生产任务保存在各自独立的上下文中。
- 运行是对话中的一次活跃响应。运行负责执行工作，当工作区达到并发限制时可能会等待。
有一个重要细节需要注意：新建的子对话不会继承控制对话的完整历史记录。其第一条消息应包含完成任务所需的全部信息。
A2A、多对话、子智能体、工作流与自动化
这些术语解决的是不同的问题。请使用能满足你边界需求的最小配置。
| 产品模式 | 改变的内容 | 最适合的场景 |
|---|---|---|
| Zero 中的 A2A | 智能体与对话协调工作的方式 | 委派、比较、交接和最终汇总 |
| 同一智能体下的多个对话 | 上下文，而指令和权限保持不变 | 并行测试、本地化检查、研究批次和模型评估 |
| 专业智能体或子智能体 | 角色、指令、模型、工具或权限 | 研究、QA、写作、数据分析和受控发布 |
| 工作流 | 智能体可重复执行的已保存流程 | 稳定的检查清单或多步骤方法 |
| 自动化 | 触发智能体启动工作流的触发器 | 定时报告、事件驱动的分类处理和周期性检查 |
一个实用的经验法则：当方法保持不变时拆分为多个对话；当方法或访问权限发生变化时拆分为专业智能体；当流程需要以相同方式重复执行时使用工作流。
1. 一个智能体开启多个干净的对话
你即将发布产品。注册、账单、权限和移动端都需要最终检查。将所有检查放入一个漫长的对话看似方便，但状态可能从一个流程泄漏到下一个。账单升级可能在权限测试开始之前就改变了账户状态。
请改为每个流程使用一个独立对话。
一份共享简报，四次独立检查，最终生成一份报告。
我们于 2026 年 8 月 25 日在预发布产品中重现了这一设置。同一个 Zero 智能体为引导流程、账单、团队成员权限以及移动端加本地化测试分别开启了四个真实对话。
每个流程都有自己的对话，因此证据易于查阅。
试试这个提示词：
将此次预发布检查作为四项独立任务进行。分别开启一个对话用于注册和引导流程，一个用于账单升级，一个用于团队成员邀请和权限拒绝，一个用于移动端加本地化检查。每个对话使用同一个演练智能体。每个工作单元必须返回：测试的 URL、账户角色、编号步骤、截图、通过/失败状态以及精确的复现步骤。将结果汇总到此处，并将重复的阻塞问题归类。
此模式同样适用于：
- 每个浏览器或设备尺寸一个对话
- 每个语言区域或账户角色一个对话
- 每个 Pull Request 或功能开关一个对话
- 每位审查者一个对话，在最终阶段前保持发现结果相互独立
- 每批客户访谈或每组研究来源一个对话
- 每个模型一个对话，以便公平比较输出结果
通常出问题的原因是什么？简报太简短。"检查账单"让工作单元不知道账户、构建版本、预期结果和证据格式是什么。请为每个对话提供相同的检查清单，并在流程会改变共享数据时提供独立的测试账户。
2. 使用 @ 将另一个对话引入当前任务
有时有用的工作已经存在。某个研究对话中有客户引言。某个 QA 对话中有截图。第二次审查得出了不同的结论。你不需要将所有内容复制粘贴过来。
点击输入框并输入 @，Zero 会打开你现有对话的列表。
开始输入标题以缩小列表范围，然后选择所需的对话。
选中的对话会以可点击的橙色标签形式出现。
该标签指向具体的引导流程对话。回答将在当前对话中生成。
然后加上一个动作词。告诉 Zero 如何处理该对话：
- "将
@Onboarding QA与此账单审查进行比较。" - "从
@Customer research batch 2继续，并在此处撰写建议。" - "对
@Security review中风险最高的结论提出质疑。" - "将
@Mobile walkthrough中的截图整理成缺陷报告。" - "从
@Launch research中提取所有未解决的问题。"
输入 @，选择对话，然后说明你希望 Zero 如何处理它。
@ 提及是一个地址，而不是模糊的文字标签。它将 Zero 指向所选对话，而无需将完整对话内容粘贴到输入框中。这使当前消息保持简洁，但你的指令仍需包含明确的动作。"用这个"太模糊。"比较失败步骤并对共同阻塞问题排序"才是清晰的表达。
3. 将不同部分交给专业智能体或子智能体
当你需要同一工作单元的干净副本时，使用多个对话。当任务需要不同的指令、工具、模型或权限边界时，使用专业智能体。为协调者执行有边界任务的专业智能体通常被称为子智能体。
产品发布是一个很好的例子。研究侦察员可以核实证据。浏览器 QA 可以检查已发布的产品。发布撰写员可以起草页面。发布操作员可以在声明通过审查后创建 CMS 草稿。
预发布工作区中有一个核心智能体和四个命名专家，每个都准备好接受有边界的任务。
协调者负责最终结果。专家返回证据和产出物，然后由一位负责人撰写最终结果。
以下是一个实用的发布简报：
为功能 X 协调一套发布包。请研究侦察员核实客户证据和竞品声明。请浏览器 QA 在预发布环境中复现每一项产品声明并附上截图。请发布撰写员仅在证据到位后起草页面。发布操作员可以创建 CMS 草稿，但不得发布。在此对话中报告缺失的证据和相互冲突的声明。
其价值来自真实的边界。研究智能体可以保持只读状态。发布智能体可以拥有草稿访问权限而无发布权限。QA 智能体每次都可以遵循固定的浏览器检查清单。Zero 的权限控制有助于将这些边界保持在最小范围内。
不要仅仅为了让侧边栏看起来更丰富而创建专业智能体。只有当角色会改变工作方式时，才创建一个专业智能体。
4. 让独立审查者各抒己见，然后使用裁判
只有当第二位审查者不是在照搬第一位的结论时，两次审查才有价值。开启干净的对话，给两位审查者相同的证据，并将他们的初始报告分开保存。
然后开启一个裁判对话，在一条提示词中同时提及两份报告。
一条提示词可以引用两个真实的 QA 对话，并要求 Zero 找出共同的阻塞问题。
例如：
比较
@Onboarding QA与@Billing QA。列出两个对话都发现的阻塞问题、仅由一个对话发现的问题，以及仍然缺失的证据。然后决定是否应该发布此版本。为每个阻塞问题引用支持它的截图或步骤。
此模式适用于设计审查、安全审查、供应商选择、架构决策、合同审查和模型比较。在报告到来之前先定义裁判标准。否则裁判可能会奖励最自信的表述，而非最有力的证据。
5. 将工作从一个智能体交接给下一个
有些任务不应同时运行。研究必须在起草之前完成。起草必须在 QA 之前完成。QA 必须在发布之前完成。
将每次交接视为一份简短的交付说明：
- 指明接收智能体或对话。
- 附上或引用产出物。
- 说明验收标准。
- 说明接收方需在何处汇报结果。
"告诉撰写员你发现了什么"难以核实。以下表达更好：
将已批准的研究摘要发送给发布撰写员。草稿必须仅使用经过核实的声明，保留已批准的术语，并用
[EVIDENCE NEEDED]标记任何缺失的证明。将草稿链接和未解决的问题返回到此对话。
@ 对话标签在此处非常有用，因为它为下一个工作单元提供了精确的来源。对于文件较多的任务，同时传递产出物链接。协调者需要的是状态、决策和最终汇总，而不是将每条草稿笔记都复制到自己的上下文中。
AI 智能体如何在 Zero 中共享上下文？
Zero 中的智能体不需要一个庞大的共享对话。上下文通过明确的简报、@ 对话提及、产出物链接和返回的摘要来传递。每个工作单元接收最小必要上下文，完成有边界的任务，然后将证据或决策发送回协调者。
这种方式避免了两个常见的多智能体问题。第一，无关的历史记录不会占用工作单元的上下文。第二，协调者可以清楚地看到哪个来源或对话支持某一声明。
使用以下四种上下文共享模式：
- 自包含简报： 最适合需要从干净状态开始的新子对话。
@对话提及： 最适合以现有对话作为来源的情况。- 产出物链接： 最适合文档、截图、数据集和代码变更。
- 结构化返回： 最适合多个工作单元需要以相同格式汇报的情况。
不要假设子对话已经知道控制对话的决策。如果某个术语、约束条件、账户、日期范围或输出格式很重要，请将其写入第一条消息。
更多 A2A 和多智能体工作流场景
| 场景 | 如何拆分 | 返回内容 |
|---|---|---|
| 发布演练 | 同一智能体，每个用户流程一个对话 | 截图、通过/失败检查和共同阻塞问题 |
| 本地化 QA | 同一智能体，每个语言区域一个对话 | 字符串错误、布局问题和特定区域截图 |
| 浏览器和设备测试 | 同一智能体，每个浏览器或视口一个对话 | 带证据的可比较兼容性矩阵 |
| Pull Request 审查 | 同一智能体，每个 PR 或审查角度一个对话 | 缺陷、风险说明和行级建议 |
| 客户研究 | 同一智能体，每批访谈一个对话 | 引言、规律、异议和来源链接 |
| 事故响应 | 协调者加应用、API、部署和客户影响智能体 | 一条包含共识与分歧的时间线 |
| 内容生产 | 研究、写作、设计、QA 和发布智能体 | 经过审查的草稿和受控的发布交接 |
| 客户支持分类 | 协调者加账户、产品、账单和回复智能体 | 根本原因、优先级、负责人和草稿回复 |
| 数据分析 QA | 分析师智能体加独立审查者 | 已核查的关联、分母、时区和假设 |
| 模型比较 | 使用相同简报和不同模型的干净对话 | 准确性、成本、延迟和格式评分 |
正确的拆分方式能创造有价值的边界。它可以隔离上下文、保护权限、保持审查独立，或让已就绪的工作同时运行。
什么时候应该使用一个对话、多个对话或多个智能体？
当每个后续步骤都立即依赖前一个步骤的答案时，使用一个对话。顺序调试会话就是一个很好的例子。
当指令保持不变但需要干净的上下文或独立证据时，使用同一智能体下的多个对话。这通常是测试、研究批次和公平比较的最佳起点。
当每个部分需要不同的专业知识、连接器、权限或模型时，使用多个专业智能体。将最终决策的责任交给一个协调者。
当流程需要可重复执行时，使用工作流。只有当该流程还需要时间表或事件触发器时，才添加自动化。Zero 将这两个构建模块分开记录：工作流定义方法，而自动化决定何时运行。
A2A 安全性与权限边界
当访问权限与任务分配相匹配时，多智能体工作会更安全。只给每个专业智能体分配其任务所需的连接器和权限。研究智能体很少需要发布权限。QA 智能体可能需要预发布环境的登录权限，但不需要生产环境的账单控制权。发布智能体可能需要草稿访问权限，但最终发布仍需人工审批。
将外部写入操作交由一个指定负责人管理。多个智能体可以读取代码仓库、CRM 或 CMS，但应由一个智能体创建最终工单、更新记录、发送客户回复或发布页面。这可以防止重复写入，并使审计追踪更易于跟踪。
对于风险较高的工作，在简报中添加停止条件："仅起草"、"不要发送"、"如果证据冲突则上报"或"在更改生产环境之前请求批准"。A2A 使委派更加便捷，但并不能免除明确问责的必要性。
保持 A2A 工作整洁的四条规则
1. 让每条第一消息自包含
包含目标、源材料、约束条件、输出格式、目标位置和停止条件。子对话不应该需要猜测控制对话已知的内容。
2. 给工作单元相同的响应格式
如果四个 QA 对话返回四种不同的格式，协调者就要花时间整理文本。要求每个工作单元提供相同的字段：环境、步骤、证据、状态和下一步行动。
3. 将共享写入操作交给一个负责人
两个正确的智能体仍然可能因为写入两次而造成混乱。指定拥有最终外部操作的智能体。
4. 只拆分能从拆分中获益的工作
创建八个对话并不意味着八个运行会同时执行。工作区并发限制仍然适用，有依赖关系的工作应等待其输入就绪。当每个后续步骤都依赖前一个答案时，将任务保留在一个对话中。
Zero A2A 与 Google 的 Agent2Agent 协议相同吗？
本文不声明任何协议等同性。本指南描述的是 Zero 内部跨智能体和对话的产品级协调：工作如何通过界面进行拆分、引用、裁判和交接。
Google 的 Agent2Agent 开放协议是一种用于远程智能体系统之间通信的技术标准，包括能力发现、任务管理、消息和产出物。搜索"A2A"时，结果通常聚焦于该协议，因此这一区别很重要：Zero A2A 是本文所涵盖的实用产品工作流。
常见问题
对话与智能体是同一回事吗？
不是。智能体是可复用的工作单元配置。对话是与该智能体进行的一次隔离会话。一个智能体可以拥有多个对话。
子对话会共享控制对话的上下文吗？
不会。请为每个子对话提供完整的简报。工作单元可以将结果返回或将有边界的产出物传递给另一个对话，但不应假设存在共享历史记录。
当我 @ 一个对话时会发生什么？
Zero 会插入一个指向你所选对话的结构化引用。该引用标识你所指的对话，但不会将完整对话内容粘贴到输入框中，因此请添加明确的动作，例如比较、审查、继续或提取。
Zero 中的子智能体是什么？
子智能体是从协调者处接受有边界任务的专业智能体。它可以使用不同的指令、工具、权限或不同的模型，然后将结果返回给控制对话。
多个对话可以并行运行吗？
可以，当工作区并发可用且任务相互独立时。当达到限制时，额外的任务可能会排队等待。有依赖关系的工作应按顺序运行。
什么时候应该使用不同的智能体？
当工作需要不同的指令、工作流、模型、连接器或权限时，使用不同的智能体。当你主要需要干净的上下文时，在同一智能体下使用多个对话。
先从预发布演练开始
在 Zero 中开启一个新对话，将一次真实的发布检查拆分为四个干净的对话。在每个对话中要求提供截图和相同的通过/失败格式。一旦这个方式奏效，将其中一个分支替换为专业智能体，或在裁判提示词中同时提及两个已完成的对话。
更多灵感，请参阅20 个 AI 智能体使用案例及精确提示词与工具。
