会跑一整夜的 Agent，才是 AI 编程的下半场

Tue, 09 Jun 2026 08:00:00 +0800

这两天刷到几条关于 Loop Engineering（循环工程） 的讨论，我第一反应其实有点警惕。

AI 圈太爱造词了。Prompt Engineering（提示词工程）还没完全冷掉，Context Engineering（上下文工程）又被讲了一轮，现在又来了 Loop Engineering（循环工程）。中文区已经有人开始说“提示词工程死亡”。这类话听多了，很容易让人把它当成又一个包装出来的新概念。

但这次我觉得可以多看一眼。原因不是这个词多漂亮，而是它背后那个场景已经很具体了：

一个 Agent 不再只是跑 5 分钟，而是要连续跑 1 小时、6 小时，甚至一整夜。它应该跑在哪里？出错了谁知道？跑偏了怎么停？

这不是模型榜单上的问题，也不是一句 prompt（提示词）能解决的问题。它更像软件工程里那些不太性感、但最后一定会决定成败的东西：运行环境、权限、日志、回滚、验收。

开着笔记本等 Agent 跑完，这件事挺荒唐的

AWS 最近发了一篇文章，标题叫 It’s safe to close your laptop now。

开头那个画面很容易让用过 coding agent（编程智能体）的人会心一笑：开发者抱着半开合的笔记本从一个地方走到另一个地方，因为里面有 Claude Code、Codex、Kiro、Gemini CLI 或 Cursor CLI 正在跑。要去开会，也不敢合盖；要回家，也得确认电源和网络别断。

这听起来有点滑稽，但并不离谱。现在很多长任务 Agent 的默认宿主，确实还是开发者自己的电脑。

问题不只是“不方便”。

你的笔记本不是一台干净的沙箱。它有 SSH key，有浏览器登录态，有 .env，有公司 VPN，有私有仓库凭证，也有一堆你早就忘了放在哪里的 token。Agent 跟这些东西共享同一个 shell、同一个文件系统、同一个网络出口。平时这叫方便，出事时就叫攻击面。

本地并行也没有看起来那么美。git worktree 可以让几个 Agent 分别改不同分支，但它们还是挤在同一台机器上：同一个 Postgres 端口，同一个 dev server 端口，同一份全局缓存，同一个 SSH keyring。代码目录分开了，宿主机没分开。

再往后看，合盖本身就是一个很原始的 kill switch。一个 90 分钟的重构，一个跨模块迁移，一个要反复跑测试的修复任务，不应该取决于“我的电脑今天能不能一直亮着”。当 Agent 的任务长度从几分钟变成几个小时，这个小麻烦就会变成工作流瓶颈。

AWS 那篇文章讲 AgentCore，表面上是在推云服务，但它戳中的痛点是对的：coding agent（编程智能体）迟早要从个人电脑里搬出去。它需要一个可以隔离、可以恢复、可以审计的远程运行环境。

长任务坏掉时，通常不是突然坏掉

我们习惯用 prompt（提示词）修 AI 的毛病。

模型不认真，就写“请认真”。模型漏测，就写“请仔细测试”。模型容易自信，就写“如果不确定请说明”。这些话有时能改善一点输出，但对长任务来说，它们只能算止痛片。

长任务的麻烦在于，它经常不是第一步就错。

一个 Agent 可能一开始理解了需求，第一版代码也写得像模像样。后来为了修一个测试，它顺手改了不该改的抽象；为了补一个边界条件，它加了一层新的状态；为了让构建通过，它绕开了真正的问题。最后它生成一段总结，说任务已经完成，而且语气很笃定。

如果你只看总结，很难判断。你必须看 diff、跑测试、打开页面、查日志、确认数据状态。也就是说，长任务能不能交付，关键不是 Agent 会不会说“我完成了”，而是外部世界有没有给它足够多的反馈。

OpenAI 的 Harness Engineering（支架工程）文章里有个经验很值得注意。他们让 Codex 在一个新仓库里完成大量开发工作，人类不再主要写代码，而是搭环境、写规则、设计反馈回路，让 Agent 能打开应用、读日志、跑测试、发 PR，并根据评审意见继续改。

这里的重点不是“Codex 写了多少代码”。真正的变化是：执行交给模型，可信度交给系统。

Loop Engineering（循环工程）如果有价值，价值就在这里。不是让 Agent 一直转圈，而是让每一圈都有真实反馈，有边界，有验收，也有停下来的条件。

真正缺的，是一间“给 Agent 用的工作间”

如果你把 coding agent（编程智能体）当成一个偶尔帮忙的助手，本地终端已经够用了。

但如果你希望它接一个 issue，跑半小时，自己修、自己测、自己开 PR，那它需要的就不只是一个聊天窗口了。它需要一间工作间。

这间工作间首先要隔离。一个任务一个 workspace，最好连依赖、端口、缓存和临时文件都分开。这样你才敢让多个 Agent 同时跑，也不用担心 A 任务的残留状态污染 B 任务。

它还要能保存现场。长任务最怕“跑到一半没了”。代码改到哪里，依赖装到哪里，测试失败在哪一步，这些状态都应该能恢复。否则 Agent 越会干长活，你越得像看炉火一样守着它。

权限也得重新设计。Agent 当然要访问 GitHub、Jira、Slack、内部 API，不然它只能在本地自言自语。但把一堆永久 token 塞进它能读写的环境里，是非常糟糕的做法。更稳妥的方式，是让身份层和工具网关替它拿临时权限，工具能用，钥匙不进屋。

还有一个经常被低估的东西：可观测性。日志、测试结果、浏览器截图、API 响应、性能指标，应该成为 Agent 继续下一步的依据。不要问它“你觉得完成了吗”，要让它看到系统到底有没有工作。

最后是停机机制。很多 Loop Engineering（循环工程）的讨论会强调自动循环，但循环最重要的一半其实是停止。连续失败几次要不要停？改动超过多大范围要不要交给人？测试通过但日志异常要不要继续？这些规则不写清楚，Loop 就会从自动化变成自动放大错误。

所以，所谓长期运行 Agent，不是把 Claude Code 丢到云主机上这么简单。它更像是在搭一套面向 Agent 的开发平台。

工程师不是消失了，而是坐到了更上游

每次聊 Agent，都会有人把话题推到“程序员是不是没用了”。

我觉得这个问题问得太急。

更接近现实的变化是：工程师不再只盯着每一行代码，而是要决定 Agent 在什么边界里行动。

以前你亲自改代码。现在你要定义任务范围。以前你自己跑测试。现在你要决定哪些测试算验收。以前你自己查日志。现在你要把日志和页面状态变成 Agent 能读懂、能使用的反馈。以前你担心代码有没有 bug。现在你还得担心 Agent 的权限是不是太大，它有没有在错误方向上跑太久，有没有把一个局部修复扩大成半个系统重构。

举个很小的例子。

你可以对 Agent 说：“修复登录页 bug。”这是一句 prompt（提示词）。

也可以给它一个更像工作流的任务：在独立环境里拉分支，复现登录失败，修改代码，跑单元测试，启动应用，用浏览器走一遍登录流程，抓控制台错误；如果失败，继续修；连续两轮通过后生成 PR；如果 30 分钟内还没通过，停止并报告卡在哪里。

两者看起来都在“让 AI 修 bug”，但差别很大。

前者是在拜托模型。后者是在设计一个可检查的执行环境。

这大概就是未来一部分工程师工作的变化：少写一点具体代码，多写一点任务边界、验收规则和失败处理。

这件事为什么现在开始冒出来

过去我们不太在意 Agent 的运行时，因为任务还短。

让 AI 改一个函数、写一个脚本、生成一个页面，本地跑就够了。失败也没关系，人很快能接回来。

现在任务开始变长。Claude Code、Codex、Kimi Work 这类工具，都在把自己从“辅助写代码”推向“接管一段工作”。AWS 在讲远程托管 coding agents（编程智能体），O’Reilly 在讲 long-running agents（长期运行智能体），InfoQ 在讨论从 MCP、Vibe Coding（氛围编程）到 Harness Engineering（支架工程）的演化，社区里也开始用 Loop Engineering（循环工程）形容这种新工作方式。

这些线索不完全相同，但方向很接近：AI 编程的竞争不只在模型，也在运行环境。

模型当然重要。没有足够强的模型，一切都只是空架子。但当模型已经能完成相当多的局部任务之后，新的差距会出现在别的地方：谁能让 Agent 更安全地拿到工具，谁能更好地保留现场，谁能把真实反馈接进循环，谁能让团队审计每一步动作。

这也是为什么“会跑一整夜”开始变得比“会写一段代码”更重要。

写一段代码，可以靠模型能力。跑完一个长任务，靠的是环境、权限、状态、反馈和退出条件一起工作。

我们以后可能会这样用 Agent

我猜短期内会出现一个分层。

个人开发者还是会在本地用 Claude Code、Cursor、Codex CLI。它们启动快、反馈快，适合探索、原型、小修小补。很多时候，本地就是最顺手的地方。

但团队里的长任务，会越来越像 CI job 或云端任务。你不会守着笔记本等它跑完，而是把任务提交到一个受控环境里：每个 Agent 一个隔离 workspace，每次工具调用有身份记录，每个结果经过验证器，失败后能恢复，必要时停下来等人接手。

到那时，AI 编程的核心技能也会变得更杂。

会写 prompt（提示词）仍然有用，但不够。你还要会拆任务、写验收、配权限、设停止条件，知道哪些事可以让 Agent 自己继续，哪些事必须把人叫回来。

这听起来没有“十倍程序员”那么刺激，但它更像真实的软件工程。

过去两年，我们一直在问：模型能不能替我写代码？

现在更该问的是：我能不能搭出一个环境，让 Agent 在里面长时间工作，而且别把事情搞坏？

这也是 Agent 和 Harness（支架）之间最容易被忽略的关系：Agent 不是一个孤零零的模型，而是模型进入真实工作环境后的形态；Harness 则是包在它外面的那套支架，负责给它工具、权限、反馈、记忆、验证和刹车。

没有 Harness，Agent 很容易退回成一个“会调用工具的聊天模型”：它能写、能改、能解释，但跑久了会漂移，权限边界也不清楚。Harness 不替模型思考，却决定模型能不能安全地行动；它不直接生成代码，却决定生成出来的代码能不能被验证、被追踪、被团队接住。

所以 AI 编程的下半场，可能不是谁拥有一个更会说话的 Agent，而是谁能给 Agent 搭出一套更可靠的 Harness。

这听起来没那么像科幻，但更像真实的软件工程。

参考来源：