Google Cloud跨项目Agent目录预览：入了管理边界，为什么仍搜不到？

Google Cloud的Agent Registry发布记录在2026年10月30日条目列出跨项目management boundaries，状态为Preview。它让一个管理项目集中发现、搜索和治理多个成员项目中的Agent、MCP服务器及工具。本文于2026年11月1日核验。

Agent Registry主服务此前已列为GA，不能据此把这项跨项目能力也写成GA。准备使用预览功能时，仍需核对当前可用性与支持条件。本文适合维护多项目Agent目录的平台工程师、FDE及系统负责人，不是创建真实云资源的操作脚本。

自定义独立Skill、SkillRevision、Publisher和AiApplication也保留项目范围，不随成员项目聚合；Google管理的独立skills另有可发现规则。不要将“支持跨项目Agent目录”理解为复制所有类型的资源。

做目录清点时，先按相应资源类型读取集合并核对稳定标识，避免只用一句自然语言搜索估计资产总数。官方搜索说明指出，Endpoint不支持search查询，应使用相应列表与过滤方式。

假设管理项目为M，A与B已加入同一有效管理边界，C在边界外。所列自动发现流程和手工登记均已完成；执行身份具备所需目录读取权限，读取过程成功且集合已完整取回。

下面从M查询us-central1的Agent集合。手工Agent指相应的手工Service登记；本表不把Skill、Endpoint或Binding混进同一个Agent集合。预期结果按文档规则推演，未在Google Cloud实测，也不保证实际环境不存在故障或延迟。

按这些假设，中央结果应覆盖R1、R2、R4。R3没出现在中央结果，并不能单独证明它没有登记；先到成员A的对应范围核对。R5则应在匹配其location的查询中检查，不能靠把location改成global来代替。

若改为直接查询成员A的us-central1范围，预期可见R1、R3，不再汇入B或M的资源。两份列表不同，可能只是请求范围不同，不能只比较总数便判定谁缺数据。

官方边界模型允许按标签筛选成员；没有标签过滤时，文件夹或组织边界默认包含其下全部子项目。标签继承还可能把整支资源层级纳入。本站建议在启用前保存实际成员清单，而不是仅记录“已配置prod标签”。

多个boundary若绑定到同一个CapabilityConfig，成员会汇入同一个管理项目目录。需要prod与dev独立可见时，官方文档要求分别配置CapabilityConfig及管理项目；只把boundary或标签命名成prod/dev，并不能据此宣称目录已经隔离。

发布记录仍列着一项已有known issue：global的SearchAgents/SearchMcpServers结果可能错误混入us/eu资源。因此，“global只对应global”是范围设计，实际搜索异常应按记录排查，不能据一次混入认定全地域汇总已经受支持。

对从成员项目自动发现并汇总的资源，从管理项目查询时，返回的resource name使用管理项目；组件ID不变，registry identifier和runtime reference仍保留原成员项目归属。看到name前缀改变，不能单独作为运行时搬迁证据。

本文给出的是教学对照方法。实际执行时应补上请求时间、结果、错误及负责人，让另一位同事能够解释每个“纳入”“排除”和“未知”，而不是只留下一个中央资源总数。

可以先选择一个location和一种资源类型，清楚列出自动发现、手工登记与不纳入的样本，再扩大项目范围。团队讨论的重点是中央目录服务谁、应覆盖哪些资源，以及哪些信息应保留在成员项目。

AI随心创的企业AI / FDE服务涉及需求诊断、系统集成与交付。需要讨论多项目Agent目录时，可准备脱敏的项目关系、登记方式、location、缺项样本和预期使用者，用于约定集成范围与验收。本文不代表Google Cloud合作资质或客户实施成果。