用途
该技能面向平台架构师，帮助回答一个具体问题：平台应如何让外部合作伙伴或第三方应用向其公开 GraphQL 图谱贡献字段或数据。核心立场是：Federation 工具本身假设每个子图作者都是同一组织内受信任的团队，一旦伙伴参与，组合校验仍能验证 schema，但不再保护平台安全。因此，把“伙伴直接把子图发布进我们的超级图”视为需要逐步赢得的高阶能力，而不是默认做法。
主要能力
- 需求分类：先把伙伴需求归入四类——在平台对象上挂存储数据、需要响应平台事件、由伙伴侧实时计算的数据、伙伴自有的全新独立能力。不同类别对应不同的扩展梯级，分类会直接删除无关梯级，而不是对梯级排序。
- 六级扩展阶梯：从 0 级 Webhook 加 API 回调，到 1 级应用自有命名空间扩展数据，2 级平台摄取连接器，3 级平台托管连接器或远程 schema，4 级平台中介扩展字段，5 级隔离伙伴变体或路由器中的伙伴子图。每一级都详细列出伙伴提供什么、平台投入、能否在单次查询中获得实时伙伴数据、安全合规暴露面以及耐久性。
- 访谈与排序：设计前先问清伙伴需求原话、伙伴数量与绑定方式、谁能看到伙伴字段、伙伴需要哪些平台数据、现有图谱栈、客户端延迟 SLA、首个伙伴上线日期与投入上限；再按效率、投入、价值、合规成本、耐久性五个维度对剩余梯级排序，并说明哪个访谈答案推动了哪个梯级。
- 伙伴契约：针对 4-5 级，要求建立可扩展实体白名单、伙伴命名空间、平台类型上伙伴字段只允许可空、指令策略（拒绝 @override、@shareable、@provides、@inaccessible、@interfaceObject，限制 @requires），并将策略作为每次伙伴发布的阻断式检查。
- 数据与凭证控制：按实体列出数据放行清单，优先暴露派生粗粒度字段；不向伙伴转发终端用户令牌、会话 cookie 或平台 API 密钥，而是签发短期、绑定伙伴受众、租户与授权范围的令牌；要求显式请求头白名单；伙伴端点必须认证每次调用并只对平台响应 _service 与 introspection；受监管数据需租户同意、签署数据处理条款并检查托管区域。
- 故障半径控制：按伙伴设置超时与熔断、请求级截止时间作为兜底、将伙伴字段纳入查询成本模型并按伙伴限流、对伙伴路由 URL 做 SSRF 校验、将伙伴响应排除在共享缓存和跨请求去重之外。
- 可见性与生命周期：伙伴数据只对安装了该伙伴并同意的租户可见；1-2 级按值而非按 schema 字段控制访问；3-5 级用仅包含规则按受众过滤 schema，并在请求时按租户安装情况执行策略。
使用方式
技能以工作流形式组织：先分类伙伴需求，再选择梯级，撰写伙伴契约，限定数据与凭证，控制故障半径，确定可见性，最后运行发布、变更与下线生命周期。当请求是对现有或已批准设计的审查时，跳过材料已能回答的访谈问题，先按严重程度列出阻断项，再对剩余梯级给出排序。文档还说明 3-7 步完整适用于 4-5 级，0-2 级不把伙伴代码放入请求路径，3 级只适用第 3 步的命名空间规则。
适用场景与限制
适用于平台开放 API 生态设计、合作伙伴扩展方案评审、发布清单审查和伙伴下线规划。资料明确建议拒绝将伙伴子图直接合成进第一方生产超级图，并指出没有主流公开 API 平台可验证地把伙伴自有原始子图组合进生产公开图谱。文档中提到的记忆文件、参考文件和主机托管细节属于建议性内容；具体路由器默认超时数值、不同引擎的请求头转发行为等以文档描述为准。实际实施中需要使用支持按请求执行代码的路由器扩展、协处理器或出口代理来实现租户绑定令牌等控制。