观测云多租户场景 Agent Teams 数据隔离方案
本文介绍观测云 Agent Teams 在多租户场景下如何通过工作空间、角色权限和 Agent 执行范围实现数据隔离，并基于 A2A 授权委派完成跨空间关联分析，兼顾企业数据安全、权限管控与智能运维协作。
观测云 Agent Teams 为团队提供面向实际任务的智能体工作台。用户可通过自然语言发起任务，由 Agent 分析告警、日志、指标和链路，梳理故障原因并生成报告；通过 Skill 复用诊断方法，通过 MCP 连接工具与内部系统。不同 Agent 可以承担运维排障、成本分析、研发和安全等职责，在授权范围内执行任务。更多介绍可以查看：https://docs.guance.com/agent-teams/
在集团公司等组织结构复杂的企业中，Agent 需要同时服务多个业务团队。业务 A、B 各自拥有应用、数据和运维人员，而数据库、K8s 容器集群等公共服务则由集团统一管理。各业务之间需要保持数据隔离，故障排查则可能同时涉及应用与公共基础设施。因此，Agent 需要在遵循业务权限边界的基础上，支持跨团队的关联分析。
在观测云中，工作空间作为不同租户单元，业务数据和 Agent 分别归属各自空间，用户按空间与角色获得访问权限；涉及公共服务信息时，通过 A2A 向目标空间的 Agent 委派查询任务，并在当前任务中汇总分析结果。
总体架构：按工作空间组织数据与 Agent Teams
假设分别设置业务 A、业务 B 和公共数据库工作空间。业务观测数据接入对应空间，公共数据库监控数据统一接入公共空间，各空间的成员、数据和 Agent 由相应团队管理。
| 工作空间 | 数据与人员归属 | Agent Teams 分工 |
|---|---|---|
| 业务 A 工作空间 | A 的日志、指标、链路及研发运维人员 | 协调 Agent 组织分析，应用诊断 Agent 查询本业务数据 |
| 业务 B 工作空间 | B 的日志、指标、链路及研发运维人员 | 独立配置本业务的协调与诊断角色 |
| 公共数据库工作空间 | 数据库监控数据及数据库运维人员 | 数据库 Agent 查询性能、慢查询、连接及锁等待等信息 |
观测云的 Agent Teams 由不同职责的 Agent 组成。初期可配置单个业务 Agent，后续根据任务复杂度拆分协调、应用诊断等角色。各 Agent 均需明确所属工作空间，角色数量的增加不改变既有的业务数据边界。
如图中的架构，各业务团队自主维护诊断流程，公共服务团队继续承担相关数据与工具的管理职责。业务 A、B 可以复用相同的 Skill 与分析方法，但分别使用所属空间的数据和访问配置。
隔离机制：基于工作空间与角色权限控制数据访问
基于工作空间归属限定 Agent 数据查询范围
观测云以工作空间为单位进行数据隔离。本方案将 Agent 的直接查询范围限定在所属工作空间内：业务 A 的 Agent 查询 A 空间中的授权观测数据，业务 B 的 Agent 查询 B 空间中的授权观测数据，公共数据库 Agent 查询公共空间中的数据库监控信息。各业务空间不额外配置其他空间的直接数据查询授权。
公共空间的划分依据是服务的管理归属。例如，同一数据库团队维护多个业务使用的实例，可将监控数据统一接入公共空间，业务 A 的诊断请求仍应限定为与其关联的对象。若不同业务数据需要由独立主体管理，则应在空间规划阶段进一步拆分，以明确的数据归属和访问权限落实隔离要求。
观测云同时支持跨工作空间数据授权，管理员可通过显式配置授予其他空间数据的直接查询权限。本方案保留各空间的数据隔离，通过 Agent 任务委派实现协作（具体配置可以参考以下章节），无需配置跨空间直接数据查询授权。
基于空间成员身份与角色配置用户权限
工作空间同时构成用户权限的管理范围。用户加入工作空间后，其可访问的功能及可执行的操作由空间内的角色权限确定。集团组织关系不自动授予跨空间访问权限；需要参与多个空间的运维人员，应分别加入相应空间并获得授权。
观测云提供基于权限的角色管理，即我们熟知的 RBAC（Role Based Access Control）。观测云默认提供几种角色：Owner 管理空间全部操作，Administrator 承担管理职责，Standard 具有相应读写权限，Read-only 以查看为主。需要进一步限定空间内数据范围时，可结合数据访问规则配置；角色功能权限与数据访问范围应分别配置和管理。详细的角色配置可以参考：https://docs.guance.com/management/role-management/
Agent 默认权限
观测云提供系统预置的 Agent 角色，用于定义 Agent 相关的平台功能权限。用户角色管理人员在工作空间中的访问和操作权限，Agent 角色定义智能体执行任务所需的平台权限；二者的授权对象与用途不同。
根据当前 Agent 角色配置，其已启用权限主要包括以下类别：
| 权限类别 | 主要权限 |
|---|---|
| 观测数据查询 | 基础设施、日志、指标、应用性能、用户访问、Agent 监测、可用性监测、安全及云账单数据查询 |
| 诊断信息查看 | 事件数据查询、会话重放查看、监控器查看、错误查看、故障查看及统一目录实体查看 |
| 分析资源操作 | 仪表板与视图查看、仪表板新建及管理、定时报告查看、笔记查看及管理、新建快照 |
| 空间辅助信息 | 成员管理查看 |
工作空间与 Agent 权限配置流程
以业务 A 为例，建议按照以下顺序完成配置：
- 确定数据归属。 将业务 A 的观测数据接入 A 空间，公共数据库监控接入公共空间，避免采集阶段混用空间配置。
- 配置成员与角色。 邀请业务 A 人员加入本空间，按管理、分析和查看职责分配权限；在需要时补充数据访问规则。
- 创建 Agent 并配置可用范围。 在 A 空间创建所需角色，填写身份定义和行为边界，将可用范围限定为对应成员或角色，再按页面指引部署运行服务。
- 启用必要能力。 配置诊断所需的 Skill 和 MCP。对外部工具单独核对身份与资源权限，避免接入可读取所有业务数据的通用高权限账号。
工作空间隔离针对空间内的数据访问；外接系统和运行目录仍需按业务管理。各空间分别维护凭证、挂载文件和任务产物，防止额外连接或共享目录引入与方案不一致的访问范围。
跨空间协作：基于 A2A 授权委派查询任务
当故障分析涉及数据库或主机层时，所需证据可能位于公共工作空间。业务 Agent 可通过 A2A 委派该空间的专业 Agent，由目标 Agent 使用自身已有权限完成查询并返回结果。用户可在当前任务中继续分析，无需为本次诊断申请目标空间的直接访问权限。A2A 的配置可以参考：https://docs.guance.com/agent-teams/a2a/
A2A 协作涉及三个权限维度：数据权限限定查询范围，协作权限确定 Agent 之间的调用关系，执行权限限定目标 Agent 可使用的工具及操作。建立协作关系不会向调用方转移目标空间的查询身份，也不会改变既有的数据归属。
业务团队与数据库团队共同明确诊断范围后，可以按照以下步骤建立协作关系：
- 准备 Agent 名片：为调用方和目标 Agent 配置完整标识；在数据库 Agent 的能力说明中明确数据类型、输入要求和结果范围。
- 由目标方授权：数据库 Agent 管理人员进入“配置 > Agent 协作 > 授权给”，添加业务 A 协调 Agent 的完整标识，选择默认权限并启用授权。
- 查看可调用关系：在业务 A Agent 的“可调用”中查看数据库 Agent 的能力与在线状态，确认已具备本次分析所需的条件。
- 跨空间关联查询：以业务 A 的 service-a 响应时间增加为例，业务用户进入本空间协调 Agent 的工作台，在“我的任务”中新建任务并提交以下请求。示例中的时间范围和资源名称应按实际情况替换。
请分析业务 A 的 service-a 在今天 14:00—14:30（北京时间）响应变慢的原因。
先查询当前空间的告警、日志和调用链，找出耗时增加的环节。该服务使用公共数据库空间中的 db-a，请调用已授权的数据库诊断 Agent，查询同一时段该对象的慢查询、连接和锁等待情况。
仅做只读分析，返回与业务 A 相关的证据；最终整理异常时间线、双方证据、可能原因和下一步建议，区分已确认事实与待验证假设。
用户通过自然语言提交分析目标，无需手动编写跨空间查询语句。业务 Agent 根据已授权目标的能力说明选择适合的协作对象；需要指定目标时，可在请求中提供其完整 Agent 标识。
- 任务委派后，用户可通过调用卡片或任务洞察查看执行进度。数据库 Agent 在所属空间内查询相关信息并返回必要结果，业务 Agent 结合应用侧证据形成综合判断。同样的协作模式也适用于主机、K8s 容器集群等公共服务的性能分析。
四、总结
多租户场景下的 Agent Team 数据隔离，应以工作空间为基础，将数据归属、用户权限与 Agent 执行范围统一纳入考虑。各业务的 Agent 在所属空间内查询授权数据，空间成员角色与 Agent 可用范围共同限定使用权限，工具和运行环境的配置则与业务边界保持一致。
对于涉及公共数据库、主机等共享服务的诊断任务，A2A 通过明确的调用授权实现跨空间协作。目标 Agent 在自身权限范围内执行查询，按约定返回必要结果，使业务团队能够在当前任务中完成关联分析，同时保留公共服务团队的数据管理职责。
通过这一架构，集团可以兼顾业务数据隔离与专业能力复用。随着业务规模扩大，可沿用统一的空间规划、角色配置和协作授权规范部署新的 Agent Team，逐步形成职责明确、权限受控的智能运维体系。
