从 AI Coding 到 Agent Teams：研发组织如何升级为可验证的智能执行系统
这是一份用于内部交流、访谈和试点设计的脑暴文档，覆盖研发方式变革、Agent Teams、Agent 编排、AI Coding、AI 日常工作与 AI 管理。
研发方式变革的核心，不是让每个工程师多用一个 AI coding 工具，而是把研发组织从“人独立完成任务”升级成“人管理任务系统 + agent 承担可验证工作单元”。
关键管理对象会从“谁写了多少代码”，迁移到“哪个 work item 有清晰 outcome、哪个 agent run 产出了证据、哪个风险需要人类判断”。
1. 这轮变革到底变的是什么？
个人效率工具
Cursor、Claude Code、Codex、Copilot 等帮助个人更快补全、解释、修改代码。收益大，但高度依赖个人能力和习惯。
任务执行方式
需求/bug 被拆成可验证 work item，agent 执行部分任务，人类负责定义、审查和验收。
Agent Teams
多个 agent/runtime 围绕同一个任务系统协作：coding、review、QA、ops、knowledge，而不是简单互相聊天。
组织管理方式
管理重点从人力排期和过程跟踪，转向 outcome、evidence、权限边界、执行闭环和团队级 harness。
2. Agent Teams：核心不是角色，而是协作协议
Agent Teams 不应先理解成“多个 AI 聊天”，而应理解成：一组 agent/runtime 围绕共享的 work item、上下文、权限和证据进行协作。
Coding Agent
读代码、改代码、写测试、跑测试、开 PR、修 CI。
Claude CodeCodexCursor AgentReviewer Agent
review diff、检查边界条件、安全风险、兼容性和测试覆盖。初期建议只评论，不自动改代码。
QA / Verification Agent
写验收用例、跑 E2E、复现 bug、检查 evidence 是否满足完成标准。
PM / Analyst Agent
把需求整理成 work item，补上下文，拆任务，识别风险，维护状态。
Ops / Release Agent
发版 checklist、CI/CD、migration 检查、changelog、release notes、rollback plan。
Knowledge Agent
从 PR、issue、事故中总结经验，更新 docs/runbook/skills，让组织知识沉淀。
3. 三个基础对象：Work Item、Agent Run、Evidence
Work Item
长期存在的工作项，不是聊天会话。至少包含 Owner、Outcome、Context、Next Step、Evidence Required、Status、Comments、Artifacts。
Agent Run
每次让 agent 做事都是一次短生命周期执行：queued → running → completed / failed / cancelled。一个 Work Item 可有多个 Agent Run。
Evidence
完成不能只靠 agent 说 done，而要有测试结果、CI 链接、PR diff、截图、日志、benchmark、before/after。
4. Agent 编排：先做简单模式，不要一开始上复杂 DAG
Sequential Pipeline
适合小功能和 bugfix。
Parallel Consult
适合方案设计、复杂排障和架构评审。多个 agent 独立分析，人或主 agent 汇总，不自动改代码。
Owner + Mention
一个 work item 只有一个 owner agent，但可以 @ 其他 agent 咨询，避免多个 agent 抢 ownership。
要避免一开始堆叠：任务 DAG、多状态流转、自动 blocker、自动 verifier、自动 retry、自动 handoff、自动 memory、自动 skill capture。每个机制单独都合理，但组合后容易让 agent 和人都不知道谁在推进。
5. AI Coding 的成熟度路径
| 阶段 | 形态 | 组织含义 |
|---|---|---|
| Level 0 | AI = autocomplete | 个人效率提升，组织影响有限。 |
| Level 1 | 局部改代码 / 解释 / 重构 | 适合 boilerplate、小 bug、单文件修改、测试生成。 |
| Level 2 | 任务级 Coding Agent | agent 读 repo、改代码、跑测试、提交 diff，是当前最值得试点的阶段。 |
| Level 3 | PR / CI 闭环 | agent 开 PR，CI 失败后自修，Reviewer Agent 初审，人最终合并。 |
| Level 4 | Agent Backlog Worker | agent 从 backlog 持续领取任务。前提是 issue 质量、测试、权限、CI、review 足够成熟。 |
6. AI 日常工作：不只写代码
信息整理
- meeting notes
- PR/issue summary
- incident timeline
- 论文/竞品调研
文档生产
- 设计文档初稿
- API docs
- release notes
- runbook / onboarding
研发辅助
- 读代码和调用链
- 生成测试
- 排查日志
- review diff
管理辅助
- 项目状态汇总
- blocked item 发现
- 风险列表
- 会议前 briefing
7. AI 管理：人管理 agent，而不是被 agent 管理
未来 TL/EM 的一部分工作会从“亲自解决所有技术问题”转向“设计任务、证据和 agent 执行边界”。
管理者的新动作
- 定义 outcome
- 拆 work item
- 设 evidence contract
- 分配 owner
- 监控 agent run
- review 关键 diff
- 沉淀 reusable workflow
建议指标
- PR lead time 是否下降
- bug 修复时间是否下降
- 测试覆盖是否提升
- review burden 是否变化
- 返工率是否上升
- agent PR merge rate
- agent run failure 原因分布
8. 先找哪些人聊？聊什么？
高水平 IC / TL
判断哪些任务适合 agent，哪些不适合。
- 最耗时间的研发任务是什么？
- 哪些任务上下文明确、验证清晰？
- 愿意让 agent 提 PR 吗？边界是什么？
普通工程师
判断采用阻力和实际体验。
- 现在用不用 AI coding？
- 哪些场景有帮助？
- 最大的不信任来自哪里？
QA / 测试负责人
寻找 verification 入口。
- 哪些回归测试最重复？
- AI 能否写测试/跑测试/整理报告？
DevOps / Infra
确认执行环境、权限边界和 CI 支持。
- agent 能否安全访问 repo？
- sandbox、secret、CI/CD 怎么做？
管理者 / PM
找到业务价值和试点项目。
- 哪些项目延迟最严重？
- 如果 agent 承担 20% 执行工作，最想用在哪里？
9. 试点项目选择与最小闭环
好试点特征
- 测试清晰，repo 结构相对清楚
- 任务粒度中小，需求稳定
- review owner 明确，部署风险可控
- 有愿意尝试的 TL
不适合一开始做
- 核心交易链路
- 测试缺失、需求模糊
- 多团队强依赖
- 安全/合规敏感
- 历史包袱巨大且没人懂
推荐试点 1：Bugfix 队列
低/中优先级 bug，由 agent 先复现、补测试、提交修复。
推荐试点 2：测试补齐
给老模块补单测/集成测试，风险低，evidence 明确。
推荐试点 3：内部工具/迁移任务
管理后台、小工具、依赖升级、lint 修复、类型补齐等重复型任务。
Minimal Pilot Loop
10. Work Brief 模板
11. 可用于交流的几个观点
观点 1：AI coding 的瓶颈不是生成代码，而是任务定义、上下文管理和验证闭环。
观点 2：Agent Teams 的核心不是多个 AI 聊天，而是多个 agent run 围绕同一个 work item 协作。
观点 3：未来 TL 的一部分工作会从“亲自解决技术问题”变成“设计任务、证据和 agent 执行边界”。
观点 4：没有测试和 evidence 的团队，很难真正吃到 agent coding 的红利。
观点 5：最先落地的不是全自动研发，而是 agent-assisted delivery：agent 做执行，人做定义、判断和最终责任。
观点 6：企业里真正有价值的不是某个单点 AI 工具，而是 team-level agent harness。
12. 下一步路径
访谈 5-8 个人
找高水平 IC、普通工程师、QA、DevOps、管理者/PM，输出 AI-native 研发试点机会地图。
选 1-2 个低风险试点
优先 bugfix 队列、测试补齐、内部工具、文档/runbook、迁移类任务。
建立最小 agent workflow
跑通 Work Brief → Agent Run → Evidence → Human Review → Metrics，连续观察 2-4 周。