在 Claude 子代理系统中，团队信息通过一个统一的配置文件进行管理。每个团队都有一个专属的配置文件，存储在 ~/.claude/teams/{name}/config.json 路径下。这个 JSON 文件是整个团队的核心元数据仓库，所有成员发现、角色识别和通信路由都基于此文件。
配置文件的 members 数组包含了团队中所有成员的记录。每个成员条目都包含三个核心字段：name 用于标识成员的人类可读名称，agentId 是该成员在系统中的唯一标识符，agentType 则描述了该成员具备的能力类型。这种结构化的设计使得子代理能够在运行时快速了解整个团队的构成。
配置文件的结构设计遵循了几个重要原则。首先是可读性，使用清晰的字段命名和层级关系，让开发者和管理员都能直观理解。其次是可扩展性，members 数组支持动态增减，不会破坏整体的 JSON 结构。第三是版本兼容性，version 字段的存在允许系统在未来的升级中识别和处理不同格式的配置文件。
子代理发现其他团队成员的第一步是读取团队的配置文件。在实际运行中，子代理可以使用 Read 工具打开 ~/.claude/teams/{name}/config.json 文件，解析其中的 JSON 内容，从而获得所有成员的列表。这个操作通常在子代理初始化阶段完成，是整个团队协作流程的起点。
在获取到 members 数组后，子代理可以从每个成员条目中提取 name 字段。这个名称字段在 SendMessage 通信机制中充当收件人标识，子代理通过指定目标的 name 来路由消息。例如，一个子代理可以通过 SendMessage("文档撰写员", "请帮我整理这段技术文档") 的方式向特定成员发送协作请求。
除了通信路由，agentType 字段还提供了每个成员的角色和能力信息。通过遍历 members 数组并检查每个条目的 agentType，子代理能够了解团队中谁负责研究、谁负责规划、谁负责执行。这种角色意识是高级协作的基础，让子代理能够将任务精准分配给最合适的同伴。
在实际实现中，建议子代理在初始化后建立一份团队成员的内存缓存。这份缓存包含一个以 name 为键、以完整成员信息为值的映射表，以及一个以 agentType 分组的成员索引。这样，当需要按名称发送消息或按类型筛选通信对象时，子代理可以快速查找而无需反复读取磁盘文件。
子代理系统中，不同 agentType 对应着不同的能力倾向和职责范围。正确识别队友的角色类型并据此选择合适的通信对象，是高效团队协作的关键能力。
Explore 类型的成员擅长探索性任务，包括信息检索、技术调研、趋势分析等。当一个子代理需要了解某个未知领域、查找最新资料或验证某个技术假设时，向 Explore 类型的队友发送查询请求是最佳选择。它们通常具备强大的搜索和信息整合能力，能够快速返回结构化的调研结果。
Plan 类型的成员则是规划和审查方面的专家。它们擅长分析需求、制定执行计划、评估方案可行性以及进行代码审查。当一个子代理完成了初步工作，需要获得结构化的反馈或方案评审时，向 Plan 类型的队友寻求帮助是最合适的。Plan 类型的成员往往能发现实现方案中的逻辑漏洞和设计缺陷。
General-purpose 类型的成员是通用的实现者，具备广泛的执行能力。它们适合承担具体的编码实现、文档撰写、数据处理等任务。当一个子代理需要实际的交付产出时，向 General-purpose 类型的队友分配执行任务是最直接的协作方式。
根据角色分配任务的策略可以总结为以下决策模式：当需要探索未知领域时，优先与 Explore 类型通信；当需要审查已有成果或规划下一步方向时，转向 Plan 类型；当需要具体执行和产出时，选择 General-purpose 类型。这种基于角色类型的任务分配方式能够最大化团队的整体效率。
核心要点：角色识别不仅仅是读取 agentType 字段，更重要的是理解每种类型的能力边界。在实际协作中，一个子代理可能同时具有多种角色特征，但 agentType 标识了其最擅长的领域。灵活运用角色识别策略，可以让团队的协作效率提升数倍。
子代理团队不是静态的——成员可以动态加入和离开。动态成员管理机制确保了团队配置能够随着实际运行情况实时更新，保持团队信息的准确性。
新成员注册流程：当一个新子代理被创建并准备加入团队时，它首先会读取当前的 config.json，然后通过写操作将自己的成员信息追加到 members 数组中。这个注册过程需要包含完整的 name、agentId 和 agentType 信息。注册完成后，团队中的所有现有成员在下一次读取配置时就能发现这个新加入的同伴。
成员注销流程：当子代理完成了它的工作任务并准备退出时，它应当从 members 数组中移除自己的条目，然后更新配置文件。或者，主代理也可以在确认子代理的工作已经结束后，主动执行移除操作。成员注销后，其他子代理将不再尝试向已注销的成员发送消息，避免了通信失败和资源浪费。
主代理的维护职责：在大多数情况下，主代理（协调者代理）负责团队成员列表的最终维护。主代理监控整个团队的生命周期，在新子代理创建时执行注册操作，在子代理任务完成时执行注销操作。主代理还可以定期检查成员列表的完整性，清理长时间无响应的异常成员记录。
变更通知机制：当团队配置发生变更（成员加入或离开）时，需要一个通知机制来告知所有活跃的子代理。常见的实现方式包括：在配置文件中增加一个递增的版本号或变更时间戳，让子代理在每次通信前检查版本是否有变化；或者由主代理主动向所有成员广播一条配置更新通知消息，触发成员刷新本地缓存。
在实际应用中，一个复杂的任务可能需要多个团队之间的协作。跨团队协作机制允许不同 Team 的子代理相互发现和通信，从而构建更大规模的代理协作网络。
跨团队发现：当一个子代理需要与另一个团队的成员协作时，它可以通过读取其他团队的 config.json 文件来实现跨团队成员发现。例如，一个在 team-alpha 中的子代理可以通过读取 ~/.claude/teams/team-beta/config.json 来了解 team-beta 的成员构成。这种方式允许子代理突破单个团队的边界，发现更广泛的协作资源。
跨团队消息路由：与同一团队内的通信相比，跨团队的消息路由需要额外的寻址信息。消息中需要包含目标成员的完整标识，包括其所属的团队名称和成员名称。路由机制会先根据团队名称定位到目标团队的配置文件，然后查找目标成员的通信地址，最后完成消息的投递。
权限控制：跨团队协作带来了权限控制的需求。不是所有团队的信息都应当对其他团队开放。常见的权限策略包括：白名单模式——只有被明确授权的团队才能读取某团队的配置文件；角色限制——只有特定 agentType 的子代理才被允许发起跨团队通信；操作审计——记录所有跨团队通信行为，便于回溯和问题定位。
在实际部署中，跨团队协作通常用于以下场景：共享基础组件库（如通用工具函数、数据访问层）、联合排查复杂问题（需要多团队专业知识的叠加）、以及大型项目的阶段性交付（不同团队负责不同模块的集成）。在这些场景中，跨团队协作的配置和权限管理就成为了系统架构的关键组成部分。