长链路 Agent 的能力与限制

小任务，暴露出脆弱的模型循环

要检验长周期 Agent 是否靠谱，最好的 sanity check 不是 benchmark，而是一项容易验证、却很难蒙混过关的任务。

这就是为什么我一直非常喜欢自己那个小型的 hyperlink_button 实验。表面上看，它简单得不能再简单：做一个 Streamlit 控件，外观看起来像文本链接，行为却像按钮。实际上，这恰好是最能检验 Agent 是否真的会干活的那类任务。

这个任务足够小，你很容易判断它是否成功；但它又足够棘手，涉及 Streamlit 端的 Python、前端的 React/TypeScript、打包、集成、文档、测试，以及所有那些“看起来可行”却不等于“真正能用”的地方。

所以我认为，这类项目比花哨的 benchmark 更适合作为测试。真正的问题不在于模型能不能生成代码，而在于围绕模型构建的工作流能否约束它诚实做事：让它阅读正确的文档，实现真正的需求，并证明自己没有作弊。

这个问题眼下尤其值得关注，因为 2026 年初出现了大量信心十足的说法，宣称长周期 Agent 已经跨过了一个真正的临界点。

METR 一直在用 Agent 能完成多长时间跨度的任务来衡量 AI 进展，而不只是看它在狭窄 benchmark 上的表现。Sequoia 的《2026: This is AGI》提出了一个刻意强调实用性的定义：AGI 就是“把事情琢磨明白”的能力。Anthropic 的《Measuring AI agent autonomy in practice》则补充了真实的部署数据：Claude Code 的单次运行时间越来越长，自动批准变得更有策略，用户的监督方式也从逐步审批转向主动监控和及时中断。

与此同时，各大产品团队也都发表了各自关于前沿进展的故事：

• Cursor 介绍了如何扩展长时间运行的自主编程

• Anthropic 让一支由多个 Claude 并行组成的团队构建了一个 C 编译器

• OpenAI 讲述了如何使用 Codex，把一个 Agent-first 代码库扩展到约一百万行代码

如果你只看标题，很容易落入两种偷懒的结论之一。

要么，开发者要完蛋了。

要么，这一切都只是烟雾弹。

我认为，这两种反应都没有抓住真正发生的变化。

真正的突破在于操作能力

最重要的转变，并不是模型突然变成了自主运行的软件团队。更有意思的变化在于，它们现在能够在真实环境中开展操作。

它们可以使用 CLI，可以检查文件和日志，可以运行代码，可以阅读文档，可以验证一项改动是否真的生效。它们能够在反馈循环中持续迭代，而不是把一大坨代码扔给人类，然后祈祷一切顺利。

这远比“更好的自动补全”或“更大的上下文”更具颠覆性。

这也解释了为什么软件开发会自然成为长周期 Agent 最先落地的领域。软件具有非同寻常的可读性、可测试性和可逆性。你可以运行程序、比较输出、检查日志，然后判断结果是否可以接受。在许多其他领域，验证工作的难度与完成工作本身一样高。

这也是 Anthropic 的自主性数据如此有趣的原因之一。数据呈现出的模式并不是“有经验的用户会更加盲目地信任 Agent”，实际情况要微妙得多。他们会批准更多操作自动执行，但也会在更关键的时机进行干预。监督方式发生了变化。

这几乎与我自己的体验完全一致。

成熟的工作流并不是“永远逐项批准每一个操作”。

而是“让系统自行推进，但保持足够近的距离，以便它开始跑偏时及时纠正”。

那些旗舰演示是真的，但它们也处在格外有利的条件下

我确实认为那些大型公开演示很重要，但我也认为，人们很容易误读它们。

Cursor 那篇文章真正有意思的地方，不在于一群 Agent 能通过暴力堆叠把软件硬生生造出来，而在于协调工作原来如此困难：扁平化的自我协调非常脆弱，简单的 planner/worker 结构反而比更聪明的方案效果更好。

Anthropic 的 C 编译器实验真正有意思的地方，也不只是“一个 LLM 构建了编译器”，而是这些 Agent 工作在一个反馈条件异常充分的世界里：严格的测试、已知正确的 oracle、结构化的任务，以及拥有数十年既有成果的领域。Chris Lattner 的评审和 Pushpendre Rastogi 的分析之所以有价值，恰恰是因为它们让这些条件变得清晰可见。

OpenAI 关于 harness engineering 的文章，或许最清楚地阐明了这种新的角色分工：人类负责引导，Agent 负责执行。环境、可观测性、仓库文档、架构规则和反馈循环，都成为一等工程产物。

这并不意味着这些演示是假的。

但这确实能帮助我们更准确地理解它们。

这些演示并不能证明自主 Agent 集群可以取代软件团队。它们证明的是：强大的 harness、丰富的反馈和明确的结构，如今已经可以释放出数量惊人的有效工作成果。

这非常重要，只是它的重要性与标题所暗示的并不相同。

这些演示之所以拥有格外有利的条件，还有一个更简单的原因：它们并不是从零开始的任务。浏览器建立在标准、参考实现和海量既有成果之上；编译器建立在数十年的规范、测试、文献和工程模式之上。即便最终成果是新的，这片地形也早已被详细测绘过。

两种编排模式，都没有魔法

演讲结束后，我发现，把人们目前编排长时间运行 Agent 工作的方式大致分成两类，会很有帮助。

第一种是 Ralph 模式：在循环中不断启动全新的 Agent 实例，并把记忆外置到 git 历史、进度文件和任务状态中。这种方式很粗糙，但也很诚实。每次运行都会从干净的上下文开始。

第二种是 LLM-native orchestration，也就是由一个主 Agent 在共享工作流中管理 subagent 或团队成员。Claude Code agent teams 就是很好的例子：各自独立的上下文、共享的任务、Agent 之间的直接通信，以及一个职责明确的负责人。

理论上，第二种模式应该显得聪明得多。

但在实践中，我自己的实验并没有让我相信，prompt 层面的编排才是真正的突破口。

我看到的情况要混乱得多。manager 经常想把自己变成 executor。它会停下来请求确认，会无视委派策略。在某些运行中，它甚至会彻底违背任务要求，退回到我已经明确禁止使用的 CSS 或 JS 变通方案。

这并不意味着 subagent 没有用。

它意味着编排仍然非常脆弱。

眼下看来，这更像是一个产品和训练问题，而不是靠写一段足够严厉的 prompt 就能解决的问题。

真正效果更好的做法

真正有效的模式没那么浪漫。

• 给模型一个 CLI。

• 把文档放在它触手可及的地方。

• 在它编写代码之前运行 preflight check。

• 让验证变得便宜。

• 优先使用 headless 检查，而不是脆弱地四处进行视觉探索。

• 只有当任务真正相互独立时，才使用并行处理。

• 在真正交接给人类之前，先增加一次 QA 风格的交接。

• 作为观察者，要警惕任务漂移。

• 及时中断并介入。

• 做好迎接冲击的准备——百分之百会有 bug 和缺陷。

这些做法改变了工作的经济性。

一旦 Agent 能够运行代码、检查输出并直接验证行为，它就不再像一个单纯的代码生成器，而开始表现得更像一个 operator。它不是自主工程师，也不是什么神奇同事，更像是在优秀 harness 中工作的一名速度极快的执行者。

这种区别很重要。

价值并不只是“模型变聪明了”。

真正的价值在于，模型现在能够参与到循环之中。

为什么我仍然不相信完全自动驾驶的故事

在这个光谱的最远端，是 software factory 的愿景，也就是 Simon Willison 在介绍 StrongDM 时所称的 Dark Factory：由 Agent 编写代码、由 Agent 测试代码、再由 Agent 审查代码，而人类基本退出实现循环。

我觉得这个方向非常迷人。

但我也认为，它清楚地说明了在“无需人工审查”听起来稍微可信之前，我们究竟还需要多少基础设施。

在我自己的工作中，完全无人值守的运行往往仍会产出一些功能上没问题，但用起来别扭、实现草率或复杂得莫名其妙的东西。它们可能通过狭窄的 verifier，却违背了任务的本意；可能完成简单的 95%，然后悄悄放弃困难的 5%；也可能通过所有检查，但整体感觉依然不对。

这并不是理论层面的反对意见。

这是我一次又一次看到的现实。

说实话，这也符合公开演示中更普遍的模式。最终产出可以令人印象深刻、真正有用而且确实存在，同时依然粗糙、不稳定，或者比标题所暗示的更难以信任。

因此，我认为最有价值的结论，其范围比炒作宣传更窄，但力度又比怀疑论更强。

长周期 Agent 的真实现状

长周期 Agent 确实已经成为现实。它们已经在改变软件的构建方式。

但在今天，其实际价值与其说来自自主运行的软件团队，不如说来自受到监督的软件操作：清晰有力的 spec、强大的 harness、低成本的验证、明确的上下文，以及主动引导。

那个完全自主、一路飞向火星的版本，仍然让我失望。

但另一个版本已经真正有用了：我同时启动五个 Agent，让它们分别处理边界明确的任务，然后像一名严格的技术负责人或 QA 工程师那样质疑和检验它们的结果。

在我看来，这才是 2026 年初 Agentic Engineering 的真实状态。

部分评论可能仅对已登录的访客可见。登录后可查看所有评论。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。