过去使用 AI 编程工具时，很多人的典型场景是这样的：遇到报错，把错误日志贴给 AI；要写函数，把输入输出描述给 AI；要补测试，让 AI 根据现有代码生成几个用例。这些任务边界清楚，通常几分钟内可以完成，开发者也能很快判断结果是否正确。
这类能力已经有实际价值，但它还不是 Agentic Coding 的完整形态。真正的软件开发不是由一堆孤立小任务组成的。一个真实需求往往需要理解上下文、制定计划、修改多个文件、运行测试、处理失败，并在中途根据新发现调整方向。它不是一次问答，而是持续推进目标的过程。
Anthropic 在《2026 Agentic Coding Trends Report》中提出的第三个趋势是：长时间运行的 Agent 将构建完整系统。报告认为，早期 Agent 主要处理几分钟内完成的 one-shot task，例如修复 Bug、写函数、生成测试；到了 2025 年后期，更强的 Agent 已经可以在数小时内产出完整 feature set；到 2026 年，Agent 将能够连续工作数天，在少量人类战略监督下构建完整应用和系统。
这篇文章要讨论的核心问题是：为什么 Long-running Agent 是 Agentic Coding 走向成熟的关键？
短任务 Agent 的价值很明确。它能快速完成边界清楚、输入明确、验证容易的任务。例如让 AI 写一个字符串处理函数，生成一段 SQL，解释一个异常栈，或者根据某个类补充单元测试。这些任务的共同特点是范围有限、目标清晰、依赖较少、结果容易检查。
这也是过去 AI 编程最容易落地的场景。开发者仍然掌控任务整体方向，只把其中一个局部动作交给 AI。AI 给出结果后，开发者复制、修改、运行、验证，然后继续下一步。
这种模式的问题在于，它没有真正覆盖软件开发中最困难的部分。真实工程任务很少像写一个函数那么干净。更多时候，任务一开始并不完整，代码库里有历史包袱，测试可能不充分，文档可能过期，模块之间有隐含依赖，需求在实现过程中还会暴露新的边界条件。
短任务 Agent 可以解决局部执行问题，但很难独立推进完整工程目标。
例如，一个需求是为现有系统增加新的计费规则。这看似只是一个功能开发，但实际可能涉及多条链路。
| 环节 | 可能的问题 |
|---|---|
| 需求理解 | 新规则和旧规则如何兼容 |
| 数据模型 | 是否需要新增字段或迁移历史数据 |
| 后端逻辑 | 哪些服务和接口需要修改 |
| 前端展示 | 用户看到的价格如何变化 |
| 测试验证 | 需要覆盖哪些计费边界 |
| 回归风险 | 是否影响已有订单或历史账单 |
| 文档更新 | 是否需要更新 API 和运营说明 |
这样的任务不是一次 prompt 能解决的。它需要持续分析、逐步执行、根据反馈调整，并在关键节点做判断。Long-running Agent 的意义就在这里：它不只是生成局部代码，而是持续推进一个复杂目标。
长时间运行容易被误解为让 Agent 多跑几个小时。实际上，Long-running Agent 的关键不在于时间长度，而在于它能否在较长任务周期内保持目标一致、处理复杂反馈，并持续修正自己的执行路径。
报告中明确提到，未来 Agent 的 task horizon 会从分钟扩展到天或周。它们不只是完成离散任务，而是能够构建和测试完整应用与系统，并在周期性人类检查点下持续工作。
这意味着 Long-running Agent 至少需要具备几类能力。
| 能力 | 说明 |
|---|---|
| 规划能力 | 能把目标拆成多个阶段和子任务 |
| 上下文保持 | 能在长任务中维持对代码库、需求和约束的理解 |
| 迭代能力 | 能根据测试、错误和反馈继续修改 |
| 失败恢复 | 能从编译失败、测试失败或方案错误中恢复 |
| 状态管理 | 能记录已完成内容、未完成内容和决策依据 |
| 检查点机制 | 能在关键不确定点请求人类确认 |
| 一致性控制 | 能保证多轮修改不破坏系统整体一致性 |
这些能力合起来，才构成真正的 Long-running Agent。
一个只能长时间生成内容的模型不是 Long-running Agent。真正的 Long-running Agent 必须能处理软件开发的混乱现实。报告中也用了类似表述：长时间运行的 Agent 需要能够跨多个工作会话进行规划、迭代和精炼，适应新发现，从失败中恢复，并在复杂项目中保持连贯状态。
这正是它和普通代码生成工具的区别。
软件开发不是一次性写对的过程，而是一个不断反馈和修正的过程。
开发者写代码时，经常会遇到这样的情况：实现到一半发现原方案不适合现有架构；跑测试发现一个旧逻辑被破坏；联调时发现接口约定不一致；上线前发现性能或权限边界有问题。每一次反馈都会迫使开发者重新理解任务，并调整后续实现。
短任务 Agent 往往只处理一个静态输入。它假设问题已经被人类整理好，目标已经明确，边界已经给出。但 Long-running Agent 需要面对动态过程。它要能在执行过程中发现问题、解释问题、修复问题，并继续推进。
比如，Agent 接到一个功能开发任务后，可能先读取相关代码，生成修改计划，然后开始实现。实现过程中，它发现某个模块没有现成接口，于是需要新增抽象；新增抽象后，原有测试失败，它需要判断是测试过期还是实现错误；修复测试后，它又发现文档中有旧行为描述，需要同步更新。
整个过程不是简单的输入到输出，而是持续执行、反馈、修正。软件开发中的真实复杂性，不在于写出某一段代码，而在于在不完整、不稳定、有历史包袱的系统里持续推进正确变更。
报告中最适合说明 Long-running Agent 的案例，是 Rakuten 对 Claude Code 的测试。
Rakuten 的工程师给 Claude Code 一个复杂技术任务：在 vLLM 中实现一种特定的 activation vector extraction 方法。vLLM 是一个大型开源库，报告中提到它包含 1250 万行代码，并涉及多种编程语言。Claude Code 在单次运行中自主工作 7 小时，完成了整个任务，最终实现与参考方法相比达到 99.9% 的数值准确性。
这个案例的重点不是 AI 写代码很快，而是它体现了三个变化。
第一，Agent 能进入大型复杂代码库工作。它不是在空白项目里生成一个 demo，而是在已有复杂系统中理解上下文、定位修改点并完成实现。
第二，Agent 能持续工作多个小时。7 小时意味着它不是一次短回答，而是经历了较长的分析、实现、验证和修正过程。
第三，结果有明确验证标准。99.9% 的数值准确性说明任务不是主观文本生成，而是需要满足工程和数学上的准确要求。
这类案例说明，Agentic Coding 正在从代码片段生成转向工程任务执行。这才是 Long-running Agent 的真正意义。
报告中还提出一个重要判断：当 Agent 能长时间自主工作时，软件开发的经济性会发生变化。很多过去不值得做的项目，可能会变得可行；多年积累的技术债，也可能由 Agent 系统性地处理。
这点非常关键。
在传统团队里，很多事情不是没有价值，而是不值得投入人工成本。
| 类型 | 过去常被搁置的原因 |
|---|---|
| 技术债清理 | 工作量大，短期业务收益不明显 |
| 老代码重构 | 风险高，需要大量上下文 |
| 内部工具 | 有用但优先级低 |
| 测试补齐 | 重要但耗时，容易被延期 |
| 文档更新 | 价值长期存在，但经常没人维护 |
| 小体验优化 | 单个收益小，排期困难 |
如果这些事情都需要高成本人工投入，它们很容易被放进 backlog，长期排不到期。但如果 Long-running Agent 可以在低监督模式下持续推进，并通过测试和检查点控制风险，这些任务的可行性就会提高。
尤其是技术债和测试补齐。它们通常不是一次性任务，而是一批长期、重复、需要耐心的工程工作。人类工程师做这些事时，往往会被更紧急的业务需求打断；Agent 则适合在明确规则和验证体系下持续推进。
因此，Long-running Agent 改变的不只是开发速度，也会改变团队对 backlog 的处理方式。以前团队只能把工程资源集中在最重要的功能上；未来，Agent 可能让更多重要但不紧急的维护性工作真正被完成。
报告还提到，Long-running Agent 会加速 path to market，创业者可以用 Agent 在几天内从想法走到部署应用，而不是过去的数月。
这里并不是说所有生产级系统都能几天完成，而是说明早期产品构建的路径会明显缩短。
过去，一个想法要变成可运行应用，需要经历需求整理、原型设计、前后端开发、数据库设计、部署配置、测试验证和文档整理。即使是一个简单产品，也要投入大量时间。如果创始团队技术资源有限，很多想法会停留在概念阶段。
Long-running Agent 可以把其中大量战术性工作自动化。人类提出目标和约束，Agent 负责搭建项目骨架、实现基础功能、生成测试、配置部署、修复错误，并在关键决策点请求人类选择。这样，想法到原型、原型到可部署应用之间的距离会缩短。
这会改变早期产品验证方式。过去验证一个产品想法，往往需要先投入较高开发成本；未来，团队可能更快构建可运行版本，用真实用户反馈决定是否继续投入。
不过，这里仍然要注意报告的边界：人类监督依然重要。Long-running Agent 可以推进实现，但产品方向、业务判断、用户价值和关键技术取舍仍然需要人来决定。
Long-running Agent 能力越强，对工程流程的要求也越高。
短任务 Agent 出错时，影响范围通常有限。开发者可以快速检查一段代码是否正确。但 Long-running Agent 如果连续工作数小时甚至数天，它产生的修改范围会更大，涉及文件更多，影响面更复杂。如果没有良好的约束机制，它的错误也可能被放大。
因此，Long-running Agent 要真正进入生产流程，需要配套机制。
第一，需要明确任务边界。Agent 在开始工作前，必须知道目标是什么、不能改什么、验收标准是什么、哪些地方需要人类确认。任务边界越模糊，长时间运行的风险越高。
第二，需要持续验证。Agent 每完成一部分工作，都应该通过测试、静态检查、构建验证或其他机制确认方向没有偏离。不能等到几小时后才发现基础假设错误。
第三，需要中间检查点。涉及架构变更、数据迁移、安全边界、兼容性破坏等关键决策时，Agent 不应该自行决定，而应该请求人类确认。
第四，需要可追溯记录。团队要知道 Agent 做了什么、为什么这么做、修改了哪些文件、测试结果如何、失败后如何恢复。没有可追溯性，就很难审查长时间运行的结果。
第五，需要回滚能力。Long-running Agent 可能做出大量修改，必须能在结果不可接受时安全回退。
这些要求说明，Long-running Agent 不是把 AI 放在那里跑就行。它必须被纳入严肃的软件工程体系，接受任务管理、质量控制、权限控制和审计机制约束。
Long-running Agent 并不意味着工程师只需要等待结果。相反，工程师的工作会从逐行实现，转向目标设定、过程监督和结果验收。
在这种模式下，工程师需要做几件重要的事。
首先，定义清晰目标。Agent 能否成功，很大程度取决于任务是否被正确描述。模糊的目标会导致 Agent 在长时间执行中不断偏离。
其次，设计验收标准。Agent 完成任务后，不能只看代码是否生成，还要看测试是否覆盖、行为是否正确、性能是否可接受、是否符合架构原则。
再次，设置检查点。工程师要判断哪些地方可以让 Agent 自主推进，哪些地方必须停下来确认。比如简单重构可以让 Agent 连续执行，但涉及数据模型或权限策略时就需要人类审批。
最后，评估最终结果。Long-running Agent 可以产生大量输出，但最终责任仍然在人。工程师需要判断这些输出是否真的能进入生产环境。
所以，Agent 工作时间变长之后，人类并不是退出，而是从执行者变成监督者和决策者。这与报告中对 Agentic Coding 的总体判断一致：AI 可以处理更多实现细节，但人类仍然负责战略监督和关键判断。
Trend 3 的核心，不是 AI 能连续运行几个小时，而是 Agent 开始具备持续完成工程任务的能力。
短任务 Agent 解决的是局部效率问题。它能帮开发者更快写函数、修 Bug、补测试。Long-running Agent 解决的是完整交付问题。它能围绕一个目标进行规划、实现、验证、失败恢复和持续迭代，最终产出完整功能、应用甚至系统。
这会带来三个直接变化。
第一，软件开发中更多战术性工作可以被 Agent 承担，工程师把精力放到目标、架构和判断上。
第二，过去因为成本高而长期搁置的任务，例如技术债清理、测试补齐、内部工具和文档维护，会变得更容易启动。
第三，从想法到可部署应用的路径会变短，团队可以用更低成本验证更多可能性。
但 Long-running Agent 也要求更强的工程约束。任务边界、测试验证、人工检查点、执行日志、权限控制和回滚机制，都会成为它能否安全落地的基础。
因此，第三个趋势可以用一句话概括：
Agentic Coding 的成熟标志，不是 AI 能生成多少代码，而是它能否在长时间任务中持续保持目标、处理反馈、修复错误，并最终交付一个可验证的工程结果。
相关阅读
##### FunTester 名片｜万粉千文，百无一用