组队:建 Team、招 Agent、定角色

组队:建 Team、招 Agent、定角色

本节摘要:第 11 章把前面所有能力汇成一套完整玩法,本节是第一步——组一支会成长的 Agent 队伍。从「一个人的公司也能有一支 Agent 小队」这个场景出发,讲清组队的三步:建 Team、招 Agent、定角色。重点强调「角色不同、能够继承团队经验」——你不是在开几个彼此失联的聊天窗口,而是在组一支有分工、有协作、共享经验的队伍。

一、场景:「一个人的公司」也能有队伍

先理解为什么「组队」对个人/小团队也有价值:

没有组队(各自为战)
  你开 4 个聊天窗口:Scout/Builder/Reviewer/...
  每个 Agent 独立,互不知情,不共享经验
  → 4 个孤岛,经验不流动

组队之后(共享经验)
  一个 Team:你 + Scout + Builder + Reviewer
  角色不同,但共享团队记忆
  → Scout 查的资料,Builder 能用;Reviewer 的教训,全队继承
  → 经验在队伍里流动、复利
​

关键概念:组队的价值不在「多了几个 Agent」,而在「让 Agent 之间共享经验」。一个人的公司,也能通过组队让多个 Agent 像一支有默契的团队那样工作——Scout 查的 Builder 能用,Reviewer 犯的错全队不再犯。这是「1 人 N Agent」模式的竞争力来源。

二、组队三步

组一支队伍的标准三步:

组队三步
  ① 建 Team
     在控制台建一个 Team(如 "Tiny but Serious Inc.")
     确定共享边界(哪些资产团队共享)
  
  ② 招 Agent
     在 Team 内创建不同角色 Agent
     Scout(查资料)/ Builder(写代码)/ Reviewer(测试)
  
  ③ 定角色
     给每个 Agent 明确职责与 Loadout
     少给噪音多给所需(第3节详讲)
​

三、定角色的关键:职责清晰

招 Agent 不是「招一堆能干的」,而是「招分工明确的」。每个 Agent 一个清晰职责:

角色分工示例(一人公司)
  👤 You(人):定目标 / 做判断
  🔭 Scout(Agent):查资料 / 找机会
     职责:市场调研、竞品分析、用户访谈
  🛠 Builder(Agent):写代码 / 做产品
     职责:功能开发、技术实现、Bug 修复
  🧪 Reviewer(Agent):测试 / 挑毛病
     职责:代码审查、测试、发布检查
  🧠 Agent Memory(系统):让经验留在队伍里
​

为什么强调「职责清晰」?因为模糊的职责会导致 Loadout 混乱——如果 Scout 和 Builder 职责重叠,它们的 Loadout 也会重叠,带来噪音。清晰的职责是「差异化 Loadout」的前提(下一节讲)。

💡 技巧:定角色时,问自己「这个 Agent 唯一的核心职责是什么」。如果一个 Agent 你说出两个以上核心职责,考虑拆成两个 Agent。职责越专一,Loadout 越精准,Agent 表现越好——这与人岗匹配的道理一样。

四、Team 的共享边界

建 Team 时要确定「共享边界」——哪些资产团队共享,哪些保持私有。这涉及第 3 章的可见性模型:

共享边界的典型配置
  team 可见(全队共享):
    ├─ 团队排障 Skill
    ├─ 项目 CodeGraph
    └─ 团队约定 Chat Memory
  
  private(各自私有):
    ├─ 个人偏好(各人不同)
    └─ 未成型的想法
  
  restricted(角色专属):
    └─ 发布检查 Skill(只给 Reviewer)
​

共享边界的设定,决定了「经验如何在队伍里流动」。设得好,经验充分流动又保护隐私;设得不好,要么「什么都共享」(隐私泄漏),要么「什么都不共享」(各自为战)。

五、组队与后续的衔接

组队完成后,后续三步都建立在队伍之上:

组队与后续
  ① 组队(本节):建 Team + 招 Agent + 定角色
     ↓
  ② 冷启动读档(下节):给队伍喂已有资产
     ↓
  ③ 装配 Loadout(下下节):给每个 Agent 配装备
     ↓
  ④ Loop 复利(末节):让队伍越用越强
​

组队是地基——没有 Team,后续的读档、装配、复利都无从谈起。所以第 11 章从组队开始,它是整套玩法的起点。

⚠️ 注意:组队不是「一次性配置」。随着业务演进,你会调整角色(新增/拆分 Agent)、调整共享边界(新资产该 team 还是 restricted)。组队是个持续优化的过程,不是「配一次就永远对」。定期审视队伍结构,与第 5 章讲过的「定期审视 Loadout」一脉相承。

本节要点回顾

1. 组队价值:不在「多几个 Agent」,在「让 Agent 共享经验」——1 人 N Agent 模式的竞争力。
2. 组队三步:建 Team(定共享边界)→ 招 Agent(多角色)→ 定角色(清晰职责)。
3. 职责清晰:每个 Agent 一个核心职责,模糊的拆分——差异化 Loadout 的前提。
4. 共享边界:team 共享成熟经验、private 保护个人、restricted 角色专属——决定经验流动方式。
5. 持续优化:组队非一次性,随业务调整角色与边界——与 Loadout 审视一脉相承。

队伍组建好了,下一节看如何给它「读档」——导入已有的代码库、文档、历史 Session,让队伍从现有经验开始。