软件开发第三时代:人类开始带领 Code Agent 团队

2026 年 2 月 26 日，Cursor CEO Michael Truell 发表了《AI 软件开发的第三个时代》。文章把 AI 软件开发分成三个阶段：第一阶段是 Tab 自动补全，第二阶段是同步对话式 Agent，第三阶段是能够在云端独立运行、持续工作、完成更大研发任务的 Cloud Agent。

文章里提到一个关键数据：Cursor 内部合并的 PR 中，已经有 35% 是由在云端 VM 中自主运行的 Agent 创建的。采用这种工作方式的开发者，几乎所有代码都由 Agent 编写，他们把时间花在拆解问题、审查结果、提供反馈上，并且会同时启动多个 Agent，而不是手把手引导单个 Agent 完成任务。

这个判断说明，软件开发正在进入一个新阶段：

人类不再主要写代码，人类开始带领 Code Agent 团队完成研发工作。

一、软件研发的基本单位变了

过去的软件研发，基本单位是一个开发人员面对一个需求写代码。

产品经理提出需求，开发人员理解需求，设计方案，修改代码，调试问题，提交代码，测试人员验证，研发经理推进交付。

第三时代的研发基本单位开始变化。

一个系统分析师、系统架构师、技术负责人或者研发经理，把需求拆成多个工程任务，交给不同 Code Agent 执行。Agent 在自己的环境里读代码、改代码、跑测试、修问题、生成结果。人类负责人审查 Agent 的产出，判断是否符合目标，决定是否继续修改、合并、上线。

这时候，人类的核心工作已经不是写代码，而是定义目标、拆解任务、设定标准、调度 Agent、审查结果、承担责任。

继续把这个角色叫“开发人员”，已经不准确。

更准确的称呼是：Agent 研发负责人。

也可以叫：AI-native 软件工程负责人。

这个角色接近传统组织里的系统分析师、系统架构师、技术负责人和研发经理的组合。

二、模型只是大脑，Code Agent 才是工作系统

很多人把 Code Agent 的能力等同于模型能力。这个理解太窄。

模型当然重要。GPT、Claude、Gemini、Qwen、Composer 这类模型决定理解能力、推理能力和代码生成能力。但一个 Code Agent 能不能完成真实研发任务，取决于模型外面那一整套工作系统。

同一个模型，放在不同 Code Agent 产品里，能力差距会非常大。

原因很简单。完成一个研发任务，不是生成几段代码。Agent 要理解项目结构，找到相关文件，识别调用链，读取接口定义，分析数据库模型，调用终端，运行测试，查看错误日志，根据失败结果继续修复，生成可审查的 diff、日志、截图、预览和 PR。

这套东西可以叫 Agent Runtime，也可以叫 Agent Orchestration。在软件开发场景里，更准确的叫法是：Code Agent 编排系统。

模型决定 Agent 会不会思考。

Agent Runtime 决定 Agent 能不能工作。

工具系统决定 Agent 能不能进入真实工程环境。

测试体系决定 Agent 能不能验证结果。

上下文工程决定 Agent 会不会改错地方。

审查机制决定 Agent 的产出能不能进入生产系统。

Code Agent 的真实能力，可以写成一个公式：

Code Agent 能力 = 模型能力 × 上下文工程 × 工具系统 × 任务编排 × 验证闭环 × 人机交互。

模型是大脑。Runtime 是身体、工具、工作台和流程。

三、第三时代的核心角色是 Agent 研发负责人

Cursor 文章里有一句很关键的话：人的角色会从逐行引导代码编写，转变为定义问题并设定评审标准。

这句话点出了第三时代的人类位置。

人类不再主要承担编码执行工作。人类承担系统分析、架构判断、任务拆解、Agent 调度、质量审查和结果责任。

Agent 研发负责人需要做几件事。

把业务需求翻译成系统需求。
把系统需求拆成工程任务。
判断模块边界、数据结构、接口设计和权限规则。
给 Agent 提供足够上下文。
设定清晰的验收标准。
检查 Agent 的代码产出。
判断测试结果是否可信。
识别 Agent 没有意识到的风险。
决定结果是否可以合并上线。

这不是传统意义上的写代码工作。

这是组织软件生产的工作。

四、产品经理的价值会上升，但研发责任不会消失

Code Agent 越强，需求表达越重要。

产品经理必须把问题讲清楚，把目标讲清楚，把边界讲清楚，把验收标准讲清楚。模糊需求进入 Agent 系统，只会得到看起来合理、实际偏离目标的产出。

但软件研发中间还有大量系统性判断。

业务规则如何变成系统规则，流程如何转成状态机，权限如何设计，数据模型如何演进，接口边界如何划分，旧数据如何兼容，异常场景如何处理，性能风险如何评估，上线失败如何回滚，长期架构如何维护。

这些事情需要系统分析和工程判断。

第三时代的研发组织结构，会更接近：

产品经理 / 业务负责人 → Agent 研发负责人 → Code Agent 团队 → 审查、测试、发布治理。

产品经理负责业务目标和需求边界。

Agent 研发负责人负责把需求变成可执行、可验证、可交付的工程任务。

Code Agent 团队负责执行。

人类负责人负责最终判断和责任承担。

五、Code Agent 团队会有明确分工

未来的软件研发，不会只依赖一个万能 Agent。

更合理的形态，是一组 Agent 各司其职。

需求分析 Agent 负责把业务需求整理成规格说明、用户流程和边界条件。
架构 Agent 负责分析模块关系、数据结构、接口方案和技术路径。
编码 Agent 负责实现功能、修改代码、补充测试。
测试 Agent 负责构造用例、运行测试、检查边界场景。
Review Agent 负责检查代码质量、安全风险、性能问题和技术债。
DevOps Agent 负责部署、CI、环境、日志和回滚。
文档 Agent 负责生成接口文档、变更说明、用户说明和运维说明。

人类负责人像带一个研发团队一样，给不同 Agent 分派任务，检查中间结果，处理冲突，决定取舍，推动交付。

过去管理的是人。

第三时代管理的是 Agent 工作流。

六、企业研发能力会重新排序

过去评价一家软件公司的研发能力，主要看开发人员数量、测试人员数量、架构师水平和项目管理能力。

第三时代会看另一组东西。

代码库结构是否清晰。
模块边界是否明确。
文档是否完整。
测试是否稳定。
开发环境是否可复现。
CI/CD 是否可靠。
权限规则是否清楚。
数据边界是否明确。
接口定义是否标准化。
业务流程是否结构化。
内部工具是否可调用。
验收标准是否清楚。
发布机制是否可回滚。

Cursor 文章里提到，在大规模工业化场景下，单个开发者尚能绕过的不稳定测试或损坏环境，会演变成导致每一次 Agent 运行都被中断的故障。Agent 还需要尽可能高效地获取所需工具和上下文。

这句话非常重要。

Agent 会放大组织工程质量的差异。

文档混乱，Agent 会迷路。测试不稳定，Agent 会反复失败。环境不可复现，Agent 无法验证。需求边界不清，Agent 会做出看起来正确、实际错误的功能。代码结构混乱，Agent 会在错误位置打补丁。权限规则不清，Agent 会引入安全风险。

第三时代对企业提出了更高要求。

企业必须把需求、流程、代码、工具、环境、测试、权限和审查机制结构化。

结构化程度越高，Agent 越能工作。

结构化程度越低，Agent 越容易制造混乱。

七、写代码能力会贬值，驾驭软件生产系统的能力会升值

传统开发人员的很多工作会被 Code Agent 压缩。

写 CRUD，写接口，写页面，补测试，改普通 bug，复制类似模块，根据需求文档完成常规功能，这些任务已经进入 Agent 的能力范围。

未来更稀缺的能力，是理解业务背后的系统逻辑，把模糊需求拆成清晰工程任务，设计合理的数据模型，判断架构方案的长期影响，制定可验证的验收标准，组织多个 Agent 并行工作，审查 Agent 的代码产出，识别 Agent 没有意识到的风险，并且为系统质量承担责任。

低层级编码执行力的价值会下降。

高层级系统驾驭力的价值会上升。

会不会写代码仍然重要。

但更重要的是，能不能组织代码被正确地产生。

八、软件开发第三时代的本质

软件开发第三时代，本质是软件生产责任上移。

Code Agent 开始成为软件生产的执行单元。人类从代码生产者，转向软件生产系统的设计者、调度者和责任人。

未来的软件研发团队，可能不再是十几个开发人员围着一个需求写代码。更常见的形态，会是一个 Agent 研发负责人带领一组 Code Agent，在多个隔离环境里并行完成需求分析、架构设计、代码实现、测试验证、代码审查、部署准备和文档生成。

人类负责目标、判断、标准和责任。

Agent 负责执行、迭代、验证和产出。

这就是软件开发第三时代。

它不是 IDE 多了一个功能。

它是软件生产方式开始重组。