AI编程进入「第三时代」:云端Agent如何重塑软件开发?

AI编程进入第三时代,云端Agent可在更少人工干预下独立完成更大规模任务,大幅提升开发效率。

原文标题:Cursor:AI编程「第三时代」来了

原文作者:机器之心

冷月清谈:

Cursor CEO Michael Truell 认为 AI 编程已进入第三时代,其核心特征是Agent 能够在更长的时间跨度内、更少人工干预下,独立完成更大规模的任务。与依赖 Tab 自动补全的第一时代和需要开发者同步 prompt-response 循环的第二时代不同,第三代 AI 编程通过云端 Agent 实现,开发者只需给出初始方向,Agent 即可自主迭代、测试,并生成包含日志、视频录屏等易于审查的内容。目前 Cursor 内部已有 35% 的代码提交由云端 Agent 完成,开发者主要负责拆解问题、审查产物和提供反馈。这种模式的挑战在于确保 Agent 以最高效率运行,并获得所需的完整工具与上下文访问权限,且需建立可靠的测试和环境,以避免系统性故障。后续发展方向将是移除“源代码”这一持久化产物,实现“意图”的直接执行。

怜星夜思:

1、文章提到AI编程的第三时代,云端Agent可以自主完成大规模任务。你认为未来程序员的角色会发生怎样的变化?是更偏向于架构师,还是更像AI的训练师?
2、文章中提到“意图可以直接被执行”是下一次跃迁。你认为“意图”如何才能被准确地传达给AI?现在的prompt方式是否足够?如果不够,还需要哪些技术或方法?
3、文章提到大规模使用云端Agent可能导致系统性故障。你认为应该如何设计和管理这些Agent,才能保证整体系统的稳定性和可靠性?

原文内容

图片
机器之心编辑部

近日,Cursor CEO Michael Truell 在 X 上发文称,当下已正式迈入 AI 编程的「第三时代」,而这个新时代的典型特征是,Agent 能在更长的时间跨度内、更少人工干预下,独立完成更大规模的任务。


AI 编程的新范式已经到来……



Michael Truell 表示,几年前开始打造 Cursor 时,大多数代码还是通过一个又一个按键敲出来的。Tab 自动补全改变了这一点,并开启了 AI 辅助编程的第一个时代。


随后,Agent(智能体)登场,开发者开始通过同步的 prompt-response(提示词 - 响应)循环来指挥智能体,这是第二个时代。而如今,第三个时代正在到来。它的特征是:智能体能在更长的时间跨度内、更少人工干预下,独立完成更大规模的任务。


因此,Cursor 的核心已不再仅仅是「写代码」,而是帮助开发者构建一座生产软件的「工厂」。这座工厂由成群的智能体组成,开发者以队友的方式与它们协作:给出初始方向、为它们配备可独立工作的工具,并对其产出进行审查……


在 Cursor 内部,许多人已经在用这种方式工作,合并的代码提交(PR)中,现在超过三分之一是由运行在云端、独立运作的智能体创建的。团队预计,一年之后,绝大多数开发工作都将由这类智能体完成。


下面来具体来看一下这三个时代的变革。


从 Tab 到 Agent


Tab 最擅长识别低熵、重复性的工作,并将其自动化。在近两年的时间里,它带来了显著的效率提升。


随后,模型能力提升。Agent 能承载更多的上下文、调用更多的工具,并执行更长的动作序列,开发者的使用习惯开始转变 —— 先是在整个夏天缓慢发生,然后在过去的几个月里突飞猛进。


这种转变是如此彻底,以至于如今许多 Cursor 用户几乎不再触碰 Tab 键。


数据显示,2025 年 3 月,Cursor 的 Tab 用户数量大约是 Agent 用户的 2.5 倍,而现在,这一比例已经反转 ——Agent 用户数量是 Tab 用户的 2 倍,且 Agent 使用量仍在快速攀升。


过去一年中,Cursor 的 Agent 使用量增长了 15 倍以上。


但这波转变本身,已经在为更宏大的变革让路,Tab 时代怎么说也持续了近两年,而大多数工作由同步 Agent 完成为主的第二时代,可能连一年都不会持续……


云端 Agent 与产物(Artifacts)


相比 Tab,同步 Agent 在技术栈更上层的位置工作,它们可以处理需要上下文和判断力的任务,但仍要求开发者在每一步骤中都保持在线参与。然而,这种实时交互模式,加上同步 Agent 需要争用本地算力资源,使得开发者一次只能实际管理少数几个 Agent,处理少数几个任务。


而云端 Agent 则同时消除了这两个限制。每个 Agent 都运行在独立虚拟机上,开发者可以把任务交出去,然后去做别的事情。Agent 会在数小时内自主迭代、测试,直到对输出结果充满信心,再带着易于审查的内容返回:日志、视频录屏、实时预览,而不只是代码差异(diff)。


这使得并行运行大量 Agent 成为现实,因为这些产物(Artifacts)和预览(preview)提供了足够上下文,让人类无需从头复盘每个会话就能评估结果。人类的角色,也从逐行指导代码转变为定义问题与设定评审标准。


变革正在 Cursor 内部发生


数据显示,在 Cursor 内部,合并的代码提交(PR)中有 35% 是由在云端虚拟机中自主运行的 Agent 创建的。据观察,采用这种新工作方式的开发者具有三个典型特征:


  • Agent 几乎编写了他们接近 100% 的代码;

  • 开发者把时间主要花在拆解问题、审查产物 / 代码,以及提供反馈上;

  • 他们会同时启动多个 Agent,而不是手把手地盯着一个 Agent 跑完。


当然,Michael Truell 也承认,要让这种模式成为软件开发的标准范式,还有大量工作要做。在工业规模下,一个单独开发者可以临时绕过的不可靠测试或损坏的环境,可能会演变成中断所有 Agent 运行的系统性故障。


更广泛地说,Michael Truell 认为,「我们仍需确保 Agent 能以最高效率运行,并获得其所需的完整工具与上下文访问权限。」


另外,Michael Truell 表示,最近 Cursor 的重磅更新,是朝这个方向迈出的一个初步但重要的一步。


而在这次更新中,Agent 不仅能快速上手你的代码,还能在云端电脑上直接搞定修改,最后再甩给你一段成品演示视频,使得远程桌面的操作体验简直「丝滑」得不像话。



针对 Michael Truell 的分享,网友 Ken Granville 认为,从 Tab 到同步 Agent 再到云端 Agent 的演进,确实是正在发生的,但这仍然是在同一范式下的优化:代码依然是最终产物。下一次真正的跃迁,不是让一群 Agent 工厂化地写代码,而是彻底移除「源代码」这一持久化产物本身。「当意图可以直接被执行时,整个技术栈都会随之改变。」



网友 Siarhei Kernoga 则认为,随着 Agent 从自动补全迈向长时运行的云端执行,验证仍然是必要的 —— 但已不再充分。当自主系统能够规模化地打开并合并代码提交时,问题已不只是「代码是否正确」?而是「究竟由什么样的执行模型来决定 —— 谁被允许合并,以及在什么条件下可以合并」。



那么你呢,如何看待,大家可以在评论区分享、讨论。


参考链接:

https://x.com/mntruell/status/2026736314272591924

https://x.com/leerob/status/2026369424450523348

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

我认为这是个进化的机会!初级程序员可以把 Agent 当成超级导师,让它帮忙处理繁琐的任务,然后自己去研究 Agent 生成的代码,学习背后的逻辑和最佳实践。这样既能快速上手项目,又能不断提升自己的技术水平。当然,前提是保持好奇心和求知欲,不能只做个“提需求”的工具人。

我认为编程语言不会完全消失,但会向更高级、更抽象的方向发展。未来的程序员可能需要掌握以下技能:

1. 领域知识: 深入理解特定领域的业务需求和知识,以便更好地将问题转化为 Agent 可以理解的意图。
2. Agent Orchestration: 能够有效地组织和管理多个 Agent 协同工作,解决复杂问题。
3. 验证与测试: 确保 Agent 的输出符合预期,并具有足够的鲁棒性和可靠性。
4. 沟通与协作: 与 Agent 和其他程序员进行有效的沟通和协作,共同完成项目目标。

编程语言应该不会消失,毕竟机器最终还是要执行指令的。但是编程方式可能会发生巨大变化,例如,直接用自然语言描述需求,AI 自动生成并优化代码。未来的软件开发可能更像是一种“意图工程”,开发者专注于表达清晰、准确的意图,而 AI 负责完成剩余的工作。

我感觉有点像现在很火的no code平台,只不过现在no code平台还是需要手动拖拽配置,未来可能只需要说一句“帮我做一个电商网站”,一个网站就自动生成了,想想都可怕。

搞个 Agent 的“反作弊系统”怎么样?专门检测 Agent 是否在“偷懒”或者“犯错”。比如,可以设定一些规则,如果 Agent 生成的代码不符合规范,或者测试失败率太高,就自动把它“踢出局”,换一个表现更好的 Agent 来接替它的工作。

除了技术手段,完善的监控和告警机制也必不可少。我们需要实时监控每个 Agent 的运行状态,一旦发现异常,立即发出告警,及时进行处理。最好还能有自动化的故障恢复机制,让系统能够自动修复一些常见的问题。

我觉得可以借鉴微服务的思路,把 Agent 设计成一个个独立的、可插拔的组件。每个 Agent 负责一个特定的任务,相互之间通过 API 进行通信。这样即使某个 Agent 挂了,也不会影响到整个系统的运行。

我觉得关键在于 AI 对业务的理解。现在 AI 只能理解代码层面的逻辑,但对业务流程、用户需求这些高层面的东西理解不够。需要给 AI 注入更多的业务知识,让它能够更好地理解我们的“意图”。这可能需要大量特定领域的数据训练。

别忘了还有安全!现在安全问题就挺多的,如果AI写代码出了安全漏洞,那可不是小事儿。所以我觉得未来程序员还得是安全专家,专门负责审查AI生成的代码,防止出现安全隐患

嗨,说白了,还是得靠 更牛逼的 AI!现在的 AI 理解能力还不够强,等有一天 AI 真的能像人一样思考了,自然就能理解我们的“意图”了。不过那时候,可能程序员就真的要失业了(手动狗头)。

我觉得未来程序员的角色会更像一个AI的驯兽师。与其说是训练师,不如说是引导者,我们需要理解AI的能力边界,知道如何更好地引导它们完成任务,同时也要对AI的产出进行把关,确保最终的质量和安全性。

个人觉得会变成架构师 + 领域专家。AI 把繁琐的代码工作做了,程序员需要更多地关注系统整体的架构设计,以及对业务领域的深刻理解,才能更好地定义问题,并指导 AI 完成任务。代码民工估计要消失了。

现在的 prompt 方式肯定不够啊!Prompt 太依赖自然语言了,容易有歧义。我觉得得有一种更形式化的语言或者接口,让我们可以清晰地表达需求,比如用模型驱动架构(MDA)的方法,把业务需求转换成模型,再让AI根据模型生成代码。