将近22天，单一目标，180万行代码库：我们是否错误地衡量了代理的自主性？

我正在构建 AutoNodo，一个受管理的自主执行系统。我不会将此作为发布或商业演示来公开。我也不会包含任何链接或其内部架构的细节。我想分享一个数据，它引发了一个有趣的技术问题：AutoNodo 当前的执行接近22天，对一个约180万行代码库中的单一技术目标进行连续自主工作。这不是一个独立的工单队列。不是多个目标的总和。不是每天由人工引入的新任务。这是一次相同的技术执行，在代码库因自身工作而变化数百次的过程中，保持了一个单一目标。在这近三周内，AutoNodo 经历了数百次提交、数千个验证步骤和难以在传统会话中容纳的大量决策。人工干预是零星的。执行仍在活跃进行。这并不仅仅是代理工作更长时间。大多数当前的编程代理在相对有限的工作单元上操作：接收一个任务。分析代码库。产生更改。运行测试。然后交付一个拉取请求或最终响应。这种模式可能运行得很好，但它仍然是一种面向会话或限定任务的自主性。AutoNodo 正在探索一个不同的类别：对持久目标的长期自主执行。区别不在于保持一个进程运行。而在于当代码库状态已被先前决策数百次改变时，系统继续追求同一使命。几小时后，代理在接收的代码上工作。几周后，它也在自身工作累积的后果上工作。那里困难完全改变。里程碑不仅仅是持续时间。近22天引起关注，但这并不是最重要的部分。真正的里程碑是目标没有被替换、分解或重新定义以促进完成。执行并非完美线性，就像任何如此规模的人类项目也不会是线性的。它需要审查决策、纠正轨迹，并继续穿越巨大的技术表面。但标准没有降低以产生一个吸引人的关闭。在之前的一个点，部分工作似乎已完成。后续执行确定仍然没有足够的基础来关闭完整目标。AutoNodo 没有结束使命。它继续。我不认为这是实验的弱点。我认为这正是将精心准备的演示与设计为在真实条件下运行的系统区分开来的行为。为什么我认为这很重要？因为我们开始用太小的指标衡量自主性。每任务小时数。拉取请求数量。通过的测试。关闭的工单。生成的代码。所有这些指标都很有用，但当自主性持续数周时，它们没有回答出现的问题：一个系统在累积数千次决策并持续在自身修改的环境上工作后，能否保持目标的方向？这就是 AutoNodo 正在测试的极限。这不仅仅是生成更长时间的代码。而是当原始代码库与累积自主工作的后果之间不再有清晰边界时，保持连贯的执行。我现在能肯定的是：这是一次连续的单一执行；它工作于一个单一技术目标；接近22天的持续时间；在一个180万行的代码库中操作；经历了数百次提交和数千次验证；需要零星的人工干预；并且仍在活跃，因为目标尚未满足所有关闭条件。我不断言所有时间都产生了相同的进展。我不断言执行是完美的。但我能说的是，我没有找到一个直接可比的公开演示，结合了这种持续时间、单一持续目标、如此规模的代码库以及具有可追溯证据的受管理执行。如果有人知道一个，我有兴趣研究它。当它结束时会发生什么当执行关闭目标时，重要的结果不会是一个显示计数器的截图。而是能够重建整个过程中发生了什么：什么改变了；什么进展被接受；什么决策需要被审查；多少工作产生了实际减少；多少人工干预是必要的；以及为什么系统最终认为目标完成。在此之前，执行仍然开放。也许这才是整个实验最重要的点：真正的自主性不在于AI能独立工作很长时间。而在于它能在过早结束是最简单选项时，继续工作于同一使命。我想向正在构建自主代理的人提出三个问题：你们知道任何类似的在单一目标上持续数周的公开执行吗？你会要求什么证据来接受长期持续自主性的主张？我们是否应该根据完成的任务或随时间维持复杂目标的能力来衡量代理？我不寻求提出一个确定的结论。我想知道我们是否正在进入一个当前指标还无法描述的执行类别。