再没有小软件团队了：并行 Agent 正在重写团队规模的含义

据 Jake Gold 的分析 观察，过去五到十人的小团队通常不需要像 Uber 那样拆分成大量微服务；但当一个小团队同时运行 20 到 100 个编码 Agent 时，它一天产生的提交、推送和 Pull Request 数量，可能已经接近过去大团队的规模。

这不是在说 Agent 会自动解决组织问题。文章真正指出的是，软件团队的“并发度”正在从人的数量转移到任务和 Agent 的数量。一个人可以同时启动多个任务，但每个任务仍然会修改文件、占用测试环境、产生依赖冲突，并要求有人判断结果是否可合并。

因此，模块化不再只是架构偏好，而是并行工作的边界条件。服务、目录、配置和测试如果没有清晰的所有权，Agent 越多，冲突越快发生。过去小团队可以靠口头沟通解决的共享状态，可能很快变成队列、锁、分支策略和自动验证问题。

这也解释了为什么“让 Agent 多写一点代码”并不等于生产力线性增长。真正的瓶颈会转移到任务拆分、依赖图、代码审查和合并。一个 Agent 能在几分钟内生成补丁，但如果十个 Agent 同时修改同一层抽象，最后的人类工作可能变成重新理解全部变更。

小团队未来需要的，可能不是更大的会议和更复杂的管理，而是更细的可观测性：每个任务修改了什么、依赖了谁、测试是否覆盖、失败后能否回滚。软件架构也会更像一套给人和 Agent 同时使用的并发协议。

关键事实

• 文章举例：传统小团队一天可能产生几十次提交和推送。
• Agent 并行场景：20-100 个 Agent 会把提交、推送和 PR 数量提高一个数量级。
• 核心问题：模块边界、共享状态、合并队列和验证能力。

OC 判断

AI 编程让“团队规模”从人数指标变成并发任务指标。小团队不会因此消失，但它们需要像大规模分布式系统一样管理工作流，否则 Agent 带来的速度会被合并和复核成本吃掉。

为什么重要

• 对开发者：先设计任务边界和验证路径，再增加 Agent 数量。
• 对团队：代码所有权、测试隔离和合并策略会比单纯购买更多模型额度更重要。
• 对工具厂商：下一代 AI IDE 需要解决的不是生成一段代码，而是管理一组并行变更。

参考来源

• Jake Gold：There’s no such thing as a small software team anymore