研发团队里有开发、评审和测试 Agent，交付的产品本身也可能有 Agent。它们都放在工作空间中，很容易被当成同一种成员。可团队归档时，生产应用可能还在服务用户，清理规则不能相同。
我按职责和所有权区分团队成员、产品运行实例与外部依赖。工作空间只是一种承载方式，不能代替业务模型。
谁拥有对象，决定谁能修改和删除
研发成员参与阶段接力，归属研发团队；产品实例归属部署，按版本服务业务；外部依赖由其他主体维护，当前团队只获得使用资格。
团队可以在授权范围内创建或测试产品实例，不因此拥有所有被引用服务。对象出现在图里，不等于团队删除时可以一起回收。
归属还会变化。对象移交时，需要更新管理主体与清理责任，只换显示名称不能完成移交。已有使用者、绑定和部署记录也要能继续找到它。
逻辑能力不直接绑定生产实例
产品需要文档解析能力，这是稳定需求；在测试环境绑哪个运行实例，是环境决定。把环境藏在成员提示词和临时配置里，评审与测试就可能调用不同版本。
完整绑定记录调用方、能力、提供方、环境、兼容条件和凭证引用：
{
"caller": "product-runtime-demo",
"capability": "analyze-alert",
"provider": "external-service-demo",
"environment": "test",
"requiredVersion": "compatible-v1",
"credentialRef": "binding-only-no-secret",
"ownership": "external"
}这里是关系示意，引用不自动授予访问权。执行路径仍检查调用者、资源与动作，凭证由平台取用，不把目标长期秘密交给模型。
切生产环境时重新解析并确认绑定，测试凭证与临时目录不跟着复制。兼容要求不满足就不进入可用状态，名字相同不能当成兼容证明。
删除需要一份明确计划
团队归档时，列出停止执行、归档成员、保留部署和解除依赖的对象。生产实例与外部服务默认保留，并给出后续管理入口。
确认以后按对象版本执行。途中引用关系变化，就重新检查，不能删除仍被其他产品使用的实例。外部服务失败只影响调用状态，不改变所有权，也不触发“修复”式重建。
临时授权同样需要撤销与使用记录。一次为评审建立的访问关系，任务结束以后仍应能查到谁拥有、为何有效、何时清理。
分类用实际行为验证
删除研发团队后，已发布应用继续工作；测试部署不能得到生产绑定；外部依赖故障不导致被团队接管；移交后旧主体不再按原规则清理。覆盖这些情况，才知道对象分类确实进入了生命周期。
并非每项可调用能力都需要一个多角色团队。有些对象只作为服务依赖，不必增加没有职责的组织者。把开发组织、交付内容和调用关系分别表达，后续版本与权限规则才有稳定的落点。