Agent 团队使用规范：开发者、Reviewer、Tech Lead 如何分工

Agent 进了团队，人和工具的分工就变了。谁来创建任务？谁来审批？谁来合并 PR？出了事故谁负责？如果把这些责任搞混，要么所有人都觉得"Agent 的事跟我无关"，要么所有责任都推给了工具。本文给出一套清晰的责任矩阵，让开发者和 Agent 各司其职。

一、团队角色重新定义

引入 Agent 后，团队角色不是被替代，而是被重新定义：

角色	传统职责	引入 Agent 后的职责变化
开发者	写代码、修 Bug、写测试	拆任务、审 Agent 产出、处理复杂逻辑
Reviewer	审代码、查质量	审 Agent 的决策逻辑，不只审代码
Tech Lead	架构决策、技术选型	定义 Agent 的边界、审批高风险操作
QA	手动测试、回归测试	验证 Agent 的测试是否有效、做变异测试
PM	写需求、追进度	写清晰的需求（Agent 需要明确的输入）

二、责任 RACI 矩阵

yaml

# agent-team-raci.yaml
# R = Responsible（执行者）
# A = Accountable（最终负责人）
# C = Consulted（被咨询者）
# I = Informed（被通知者）

task_lifecycle:
  
  # 任务创建
  task_creation:
    developer: "R"        # 开发者创建任务
    tech_lead: "A"        # Tech Lead 负责任务质量
    agent: "C"            # Agent 可以建议拆分方式
    pm: "I"               # PM 被通知
  
  # 任务审批（是否交给 Agent 执行）
  task_approval:
    developer: "R"        # 开发者发起
    tech_lead: "A"        # Tech Lead 审批
    agent: "I"            # Agent 等待审批结果
  
  # Agent 执行
  agent_execution:
    agent: "R"            # Agent 执行
    developer: "A"        # 开发者对结果负责
    tech_lead: "C"        # 复杂任务可咨询
    qa: "I"               # 通知 QA 关注
  
  # 代码审查
  code_review:
    reviewer: "R"         # Reviewer 审查
    developer: "A"        # 开发者确保 Review 完成
    agent: "C"            # Agent 可以辅助审查
    tech_lead: "I"        # 高风险 PR 通知 TL
  
  # 合并决策
  merge_decision:
    reviewer: "R"         # Reviewer 批准
    developer: "A"        # 开发者触发合并
    agent: "I"            # 合并后通知 Agent
  
  # 事故响应
  incident_response:
    developer: "R"        # 开发者首先响应
    tech_lead: "A"        # Tech Lead 负责决策
    agent: "C"            # Agent 可以协助分析
    qa: "R"               # QA 验证修复

三、核心原则

3.1 谁创建任务，谁对任务质量负责

yaml

# task-ownership.yaml
principles:
  - rule: "任务的创建者对任务的描述质量负责"
    explanation: |
      Agent 的输出质量 80% 取决于输入质量。
      如果任务描述模糊，Agent 的输出也会模糊。
      不能怪 Agent"没理解"，而是任务描述没写清楚。
    
    example:
      bad: "修一下登录的问题"
      good: "修复 #BUG-1234：用户密码包含特殊字符时登录失败，报错 400 InvalidCredentials"
  
  - rule: "任务的审批者对任务的风险评估负责"
    explanation: |
      不是所有任务都适合交给 Agent。
      涉及生产数据、安全逻辑、金额计算的任务需要 Tech Lead 审批。
      审批者必须评估：这个任务 Agent 能做好吗？做错了代价多大？

3.2 谁合并代码，谁对代码质量负责

yaml

code-ownership:
  - rule: "Agent 写的代码和人类写的代码，适用同样的审查标准"
    explanation: |
      不能因为"这是 Agent 写的"就降低审查标准。
      实际上 Agent 写的代码应该被更仔细地审查——
      因为 Agent 可能不理解业务上下文。
  
  - rule: "Reviewer 不只审代码，还要审 Agent 的决策过程"
    explanation: |
      审查 Agent 的 PR 时，除了看代码变更，还要看：
      - Agent 为什么选择这种实现方式？
      - Agent 的上下文包是否足够？
      - Agent 有没有遗漏的边界条件？

3.3 出了事故，人负责而不是工具负责

yaml

incident-accountability:
  - rule: "Agent 是工具，工具出了问题，使用工具的人负责"
    explanation: |
      Agent 合并了有 Bug 的代码 → 审查者的责任（没有发现问题）
      Agent 漏测了边界条件 → 开发者的责任（没有补充测试）
      Agent 修改了不该改的文件 → 审批者的责任（权限给得太宽）
    
    anti_pattern: |
      ❌ "Agent 写了有 Bug 的代码"
      ✅ "我审查了 Agent 的代码，没有发现 Bug"
      
      ❌ "Agent 删了生产数据"
      ✅ "我给 Agent 的权限范围包含了生产数据删除"
  
  - rule: "事后复盘关注流程改进，不关注追责"
    explanation: |
      事故复盘的问题不是"谁该负责"，而是"流程哪里可以改进"：
      - 审查流程是否足够？
      - 权限范围是否过宽？
      - 测试覆盖是否充分？

四、具体场景的职责划分

4.1 Bug 修复流程

text

开发者                 Agent                  Reviewer              Tech Lead
  │                      │                      │                      │
  │ 1. 创建任务          │                      │                      │
  │──────────────────────▶                      │                      │
  │                      │                      │                      │
  │ 2. 评估风险          │                      │                      │
  │──┐                   │                      │                      │
  │  │ 简单？            │                      │                      │
  │  └──是──▶ 3a. 直接   │                      │                      │
  │         交给 Agent   │                      │                      │
  │                      │                      │                      │
  │  │ 复杂/高风险？     │                      │                      │
  │  └──是──▶ 3b. 请 TL 审批─────────────────────────────────────────▶│
  │                      │                      │                      │
  │                      │ 4. Agent 执行        │                      │
  │                      │──────────────────────▶                      │
  │                      │                      │                      │
  │                      │                      │ 5. 审查代码+决策     │
  │                      │                      │◀─────────────────────│
  │                      │                      │                      │
  │ 6. 补充测试          │                      │                      │
  │◀─────────────────────│                      │                      │
  │                      │                      │                      │
  │ 7. 合并              │                      │                      │
  │─────────────────────────────────────────────▶                      │

4.2 生产发布流程

yaml

production-deploy:
  steps:
    - step: "创建发布任务"
      owner: "developer"
      action: "创建发布计划，列出变更内容"
    
    - step: "风险评估"
      owner: "tech_lead"
      action: "评估发布风险，决定是否需要维护窗口"
      approval_required: true  # 必须 TL 审批
    
    - step: "Agent 准备发布包"
      owner: "agent"
      action: "生成 changelog、更新版本号、创建发布分支"
      supervision: "developer"  # 开发者监督
    
    - step: "发布验证"
      owner: "qa"
      action: "在预发布环境验证，运行回归测试"
    
    - step: "发布执行"
      owner: "tech_lead"
      action: "确认验证通过后执行发布"
      note: "Agent 不能独立执行生产发布"
    
    - step: "发布后监控"
      owner: "developer"
      action: "监控错误率、性能指标，准备回滚"

五、团队规范文档模板

yaml

# agent-team-guidelines.yaml
team_name: "电商平台团队"
version: "1.0"
effective_date: "2024-06-01"

# 基本原则
principles:
  - "Agent 是团队的工具，不是团队成员"
  - "使用 Agent 的人对 Agent 的输出负责"
  - "高风险操作必须人工审批"
  - "Agent 的权限遵循最小权限原则"
  - "所有 Agent 操作必须有审计日志"

# Agent 允许的操作
allowed_operations:
  - "读取代码和文档"
  - "编写和修改代码"
  - "运行测试（非生产环境）"
  - "创建 PR（非直接合并）"
  - "生成文档"

# Agent 禁止的操作
disallowed_operations:
  - "直接推送到 main/master 分支"
  - "访问生产数据库"
  - "执行生产环境命令"
  - "删除代码仓库"
  - "修改权限配置"

# 审批要求
approval_requirements:
  - condition: "涉及金额计算代码"
    approver: "tech_lead"
  - condition: "涉及安全相关代码"
    approver: "security_team"
  - condition: "修改超过 10 个文件"
    approver: "tech_lead"
  - condition: "涉及数据库迁移"
    approver: "dba + tech_lead"

# 审查要求
review_requirements:
  - "Agent 的所有 PR 必须人工审查"
  - "审查者必须检查 Agent 的决策逻辑"
  - "审查者必须验证测试覆盖"
  - "高风险 PR 需要两人审查"

# 事故响应
incident_response:
  - "Agent 相关的事故，使用 Agent 的人首先响应"
  - "事故复盘关注流程改进，不追责个人"
  - "每次事故后更新 Agent 使用规范"

六、真实经验与踩坑

6.1 "Agent 写的"成为偷懒的借口

场景：开发者把不想做的任务都扔给 Agent，不审查直接合并。理由是"Agent 写的，测试也过了"。问题：Agent 写的代码质量参差不齐。不审查就合并等于"闭着眼睛合并"。几个月后代码库里堆满了"能跑但没人看得懂"的代码。 解决方案：明确规定"Agent 的 PR 必须人工审查，审查标准和人类 PR 一致"。同时在 PR 模板中增加"Agent 决策说明"一节——审查者不仅看代码，还要看 Agent 为什么这样写。

6.2 权限给得太宽导致事故

场景：为了让 Agent "能自己处理一切"，给了 Agent 生产数据库的只读权限。问题：Agent 在做"数据分析"任务时，读到了用户隐私数据（手机号、身份证号），并写进了分析报告。报告被分享到了团队 Slack。 解决方案：生产数据的访问权限必须经过安全团队审批。Agent 的默认权限是"不访问生产数据"。需要访问时，走审批流程，且访问范围必须精确到表/字段级别。

6.3 新人的 Agent 使用培训不够

场景：新人入职第一天就开始用 Agent，没人教他怎么正确使用。问题：新人不知道什么任务适合 Agent、什么不适合，也不知道审查 Agent 产出要注意什么。结果要么过度依赖 Agent（什么都让 Agent 做），要么完全不信任 Agent（不敢用）。 解决方案：新人入职培训增加"Agent 使用规范"模块——包括：①什么任务适合 Agent；②如何写好任务描述；③如何审查 Agent 产出；④权限边界和审批流程。安排一位"Agent 导师"在前两周指导。

七、参数说明表

参数	类型	默认值	说明
`role`	string	必填	团队角色：developer / reviewer / tech_lead / qa / pm
`allowed_operations`	list	见 5	允许的操作列表
`disallowed_operations`	list	见 5	禁止的操作列表
`approval_requirements`	list	见 5	需要审批的条件
`review_policy`	string	`"human_required"`	审查策略：`human_required` / `auto_if_small`
`audit_log_enabled`	bool	`true`	是否启用审计日志
`training_required`	bool	`true`	是否需要完成培训才能使用 Agent
`mentor_period_days`	int	`14`	新人导师辅导期

八、落地检查清单

团队每个角色都清楚自己的 Agent 使用职责
RACI 矩阵已定义并全员知晓
高风险操作有审批流程
Agent 的所有 PR 必须人工审查
Agent 权限遵循最小权限原则
生产数据访问必须审批
事故响应流程已明确（人负责，不推给工具）
新人培训包含 Agent 使用规范
团队定期复盘 Agent 使用情况
规范文档可查询、版本可控

九、系列导航

上一篇：插件使用技巧：以 superpowers 为例增强任务拆解、反思和复盘下一篇：Agent 审计日志规范：工具调用、Prompt、diff 与审批记录