Cognition 押注 Devin GPT-6 Astra 测试可用证据取代代码审查
Cognition 已将 Devin GPT-6 Astra 测试扩展至三款产品，使验证成为自主软件工程的最新竞争战场。该模型现已支持在 Devin Cloud、Devin Desktop 和 Devin CLI 中执行测试。它能够操作应用、检查结果，并在书面报告之外提供可视化证据。
关键变化并非 Devin 能生成更多代码。编码智能体早已能够生成补丁、创建拉取请求并运行测试套件。Cognition 现在希望 Devin 能够展示其改动确实有效的证据，从而减少工程师必须手动检查的生成代码量。
这一承诺给传统的“先审查再开发”模式带来压力。它也向 Cognition、OpenAI 以及所有竞争性编码智能体提出了一个棘手问题：智能体能否可靠地评估由同一自动化系统产出的工作，还是说人工注意力只是从代码审查转移到了证据审查？
Devin GPT-6 Astra 测试现在会产出可审查的证据
Cognition 正将测试证据，而非单纯的代码生成，定位为工程师应当评估的交付成果。
OpenAI 于 2026 年 9 月 11 日发布了其 Devin 测试案例。该公司表示，Cognition 正在其云端智能体、命令行界面和桌面应用中采用 GPT-6 Astra。
Cognition 此前已于 9 月 3 日将 Astra 添加至 Devin。其 模型发布公告称，Astra 可直接在 Devin Desktop 和 Devin CLI 中使用。该模型也是 Devin Cloud 所采用模型组合的一部分。
这一集成将编码产品常常包装为连续工作流的两项任务分开处理。一个模型可以实施改动，而 Astra 则可协助推进测试阶段。这一区分很重要，因为编辑代码与验证应用需要不同的能力。
编码模型主要围绕代码仓库、规格说明和源代码改动进行推理。应用测试人员还必须理解界面、跟踪界面状态、操作软件，并判断观察到的行为是否符合预期结果。
Cognition 表示，Astra 在第二类任务上表现尤为出色。该公司称其在内部测试基准上取得了业界领先的结果，但尚未公布足够细节，供外部人士复现或独立验证这一具体结果。
公开示例说明了 Cognition 所说的自主验证意味着什么。在一项演示中，Devin 在模拟器内测试 iPhone 游戏 Otter Run。它会返回游戏运行录屏，以及一份说明哪些检查通过的报告。
报告还指出了 Devin 未测试的部分。这一限定很重要，因为精致的视频否则可能会让人误以为此次运行实现了更广泛的覆盖。
录屏展示可观察到的行为，而报告则界定所声称的范围。二者结合，让审查者获得的更接近测试工件，而非传统的智能体摘要。
另一种工作流从客户提供的漏洞截图开始。Cognition 表示，团队可以将该图像发送给 Devin；后者会诊断问题、修改代码，并返回另一张展示结果的截图。
这一流程将可见的缺陷与可见的结果联系起来。对于难以仅通过日志或拉取请求评论来解释的界面问题，它能够缩短反馈周期。
不过，截图只能证明某一时刻显示的内容。它无法证明相关路径仍然有效、底层实现具备可维护性，或该缺陷在不同条件下仍能保持修复状态。
因此，更有价值的功能是证据包。工程师可以在决定是否合并前，对照所要求的行为、声明的测试计划、记录的操作以及任何未测试区域。
这改变了审查的单位。工程师收到的不再只是差异对比和智能体写下的保证，而是一项由执行轨迹支撑的主张。
这一转变构成了 Cognition 的核心押注。如果审查者信任该轨迹，他们就可以花更少时间从生成代码中还原发生了什么；如果不信任，这些额外工件便会成为另一层需要检查的内容。
为什么验证已成为编码智能体的瓶颈
智能体开发中的限制性资源，正从代码产出转向可信审查能力。
编码智能体生成改动的速度，可能快过大多数团队的评估速度。一旦多个智能体并发运行，每次成功的会话都可能产生新的分支、拉取请求、测试报告或后续决策。
Cognition 表示，其工程师曾并行运行 10 至 20 个 Devin 会话。每个会话都可在云端运行独立的开发服务器。如此程度的并发在一名工程师的笔记本电脑上并不方便实现。
更多并发并不会自动创造更多生产价值。相反，它可能生成一条等待人工验证的、看似合理的改动队列。
这条队列尤其棘手，因为生成代码在实际运行失败前可能看起来很合理。审查者可能需要重建环境、运行应用、重复报告中的流程，并检查相邻行为。
Cognition 将这一挑战描述为迈向异步开发这一更广泛转变的一部分。如今，通过计划任务、自动化、事件和其他 Devin 实例触发的 Devin 会话，已多于通过直接交互请求触发的会话。
异步编码智能体会在其人类使用者忙于其他事务时工作。只有在返回的结果易于理解且足够可信时，这种安排才能节省注意力。
缺少验证时，工程师回来面对的是一堆未加说明的差异。他们必须重新找回每项任务的上下文，才能判断这些工作是否有用。
Cognition 此前对 智能体验证的说明称，在数个月内，获批的每日测试运行次数增长了一倍以上。这是公司自行报告的产品活动，并非对可靠性或客户价值的独立衡量。
不过，这一方向合乎逻辑。随着智能体生成更多改动，团队需要简明的证据，帮助他们判断哪些结果值得关注。
目标并非立即消除人工判断，而是通过让相关观察结果更贴近已完成任务，降低作出判断的成本。
在工程师阅读实现前，一份有用的证据包可以回答若干问题：应用是否正确启动？改动的功能是否出现？智能体测试了哪条用户路径？哪些内容仍未纳入测试？
这些问题往往比智能体声称所有测试均已通过更有价值。传统测试套件只能评估那些被人预先设想并编码的断言。
界面录屏可以揭示从未在单元测试中表示的状态变化。书面的范围说明也可以暴露覆盖缺口，而不是将其埋没在冗长的执行日志中。
压力并不限于 Cognition。OpenAI 的 Codex、Anthropic 支持的编码系统、Google 的开发者智能体、Cursor 以及开源框架，都在争夺工程工作负载。
每个产品都可以提升自己的代码生成分数。然而，企业采用取决于生成之后发生的事情——届时必须由负责任的人批准一项影响重大的改动。
因此，主要对手并非某个竞争模型，而是围绕在信任结果前阅读每一行重要代码所建立的“先审查”工作流。
这一工作流存在充分理由。代码传达了架构、未来维护成本、安全假设和故障行为，而简短的演示可能永远无法揭示这些信息。
Cognition 并未声称这些考量会消失。其明确目标是让工程师随着时间推移检查更少代码，同时交付更多已完成的工作。
这一表述为选择性审查留下了空间。团队可能会仔细检查高风险模块，同时对范围狭窄的界面修复、常规迁移或边界明确的内部工具采用以证据为主导的审查。
实际效果将取决于团队如何保留任务上下文。一个工程知识库可以帮助审查者将智能体的证据与需求、设计决策和过去的故障联系起来。
当验证反映这些来源时，其价值会更高。如果智能体误解了定义成功的需求，再清晰的录屏也意义有限。
Astra 将测试转变为独立的智能体技能
Astra 的价值在于将计算机操作、视觉判断、代码库推理和简洁报告结合在同一个测试循环中。
计算机操作模型能够理解视觉界面，并执行点击、输入、滚动和在页面间导航等操作。测试还增加了一项要求：这些操作必须支持有关预期行为的明确断言。
Cognition 的测试循环从基于代码库的计划开始。智能体会在声明测试内容前检查相关代码。这降低了它编造应用不支持的界面路径或假设的可能性。
该计划也为最终报告提供了参照点。审查者可以看到此次运行是否覆盖了预期行为，而不是在缺乏明确标准的情况下评判一段录屏。
在执行过程中，Devin 可以使用设置说明和具名测试阶段标注时间线。它可以将断言标记为通过、失败或未测试。
Cognition 表示，要求智能体在操作前说明预期，可减少事后合理化。智能体在看到结果后，重新将意外界面解释为成功的空间更小。
这类似于测试驱动开发，即在实施前定义预期行为。这里的承诺发生在行为验证期间，而不是每次代码改动之前。
智能体随后可以操作浏览器、模拟器或桌面应用。它会捕捉发生的情况，并返回供人类异步检查的工件。
Astra 似乎适合这一阶段，因为该模型接受过计算机操作和长时、多步骤专业任务的训练。OpenAI 表示，它能够安装软件、排查可见问题并执行前端质量检查。
在 OpenAI 公布的 计算机操作结果中，Astra 在 OSWorld 2.0 上获得了 72.6%。据报告的对比，GPT-5.6 Sol 得分为 65.7%。
OpenAI 还表示，Astra 平均约 40 分钟即可完成这些模拟任务。较早的模型则大约需要 75 分钟。这些数字来自 OpenAI 的评估设置，不应被视为通用的生产环境指标。
同一份发布材料显示，Astra 在 Terminal-Bench 4.0 上得分为 57.9%。GPT-5.6 Sol 得分为 37.3%，Claude Fable 5.1 得分为 55.8%。
在 FrontierCode 1.1 Extended 上，Astra 得分为 64.5%。Claude Fable 5 得分为 64.9%，因此 Astra 在 Cognition 的该基准中略低于该模型。
Cognition 将 FrontierCode 描述为一项针对真实工程任务的专有评估。其评分会考虑质量和可合并性，未通过阻断性标准的解决方案不会获得分数。
这些比较表明，Astra 的吸引力并不只是更高的原始编程性能。Cognition 的公开声明强调了更清晰的报告、更全面的测试，以及更易于理解的视频。
这些特质会直接影响审查时间。即使一次运行在技术上获得成功，如果证据令人困惑、冗长，或与所请求的改动脱节，仍会浪费人工注意力。
一份简洁的报告应说明已测试的行为、环境、观察到的结果及尚存的不确定性。一段有用的录屏应让关键转换节点易于定位，而不是迫使审查者观看一整段未经剪辑的会话。
Cognition 还为重复性的配置工作构建了确定性脚本。确定性脚本会执行预先定义的步骤，而不是要求模型即兴决定每一个操作。
身份验证便是一个例子。通过截图驱动登录流程，可能耗费时间，并引入与被测功能无关的失败。
保存好的脚本可以快速创建已认证的浏览器会话。随后，智能体便能将推理重点放在真正重要的行为上。
这种混合式设计揭示了一项重要的工程经验：更好的自主测试，并不意味着把每一项操作都交给语言模型。
可靠的系统会将可预测的步骤留给传统自动化工具处理，并在解释、恢复或灵活导航能够创造价值的地方使用模型。
Cognition 还允许 Devin 在解决棘手的配置问题后，提出可复用的测试技能。用户可以在将该自动化加入代码仓库前对其进行审查。
随着时间推移，这可以将反复出现的发现转化为稳定的基础设施。模型即兴探索出的路径，会成为供未来运行使用的、经过审查的脚本。
这一组合还能控制变异性。如果每次测试都以不同的配置行为开始，结果将难以比较，故障诊断的成本也会变得高昂。
Astra 提供灵活的感知与推理能力。确定性脚本约束重复操作。测试计划定义成功标准，而证据报告则揭示此次运行覆盖了什么。
这一机制比又一个基准测试领先更具意义。它勾勒出编程智能体如何从产出看似合理的补丁，转向参与受控的工程工作流。
智能体仍无法独自批改自己的作业
证据可以减少审查工作量，但无法让自我验证变得独立、完整或天然可信。
最明显的风险是相关性失败。如果智能体在实现过程中误解了任务，同一系统可能会将这种误解带入其测试计划。
代码与测试随后可能彼此一致，却都不符合用户的实际需求。一份干净的报告记录的是一致性，而不是正确性。
当独立测试来自规范、另一位工程师或独立的评估系统时，能够减轻这一问题。既有的回归测试套件同样提供了实现智能体在当前会话中并未自行创造的约束。
Cognition 的方法通过将计划建立在源代码之上，并在每项操作前说明预期来提供帮助。这些措施可以减少偏移，但并不能创造真正的独立性。
该公司曾公开描述过早期的失败。Devin 有时会测试无关领域、陷入环境配置，或遗漏拉取请求原本意图修改的行为。
这些问题解释了为何该系统需要计划、注释和确定性的配置工具。它们也表明，精致的证据依赖于底层模型之外的编排能力。
视觉证据也存在额外限制。视频可以展示某个流程在一种环境和数据状态下成功运行。它无法证明在不同浏览器、权限、负载条件或恶意输入下的广泛正确性。
报告可能会准确地将这些缺口标记为未经测试。审查者仍必须决定，被省略的路径是否重要到足以阻止部署。
对于后端、基础设施和安全变更，覆盖范围尤为重要。许多严重故障不会在一次短暂运行中产生明显的视觉症状。
数据库迁移可能看似成功，随后却破坏某个边缘情况。权限变更可能对演示账户有效，却暴露了另一租户的数据。
安全敏感代码需要对抗性思维，而不仅是确认预期行为确实发生。团队需要设计用于打破假设的测试，而不是重演理想路径。
OpenAI 本身也对 Astra 的高级网络安全能力施加限制。该模型可以协助进行安全审查和修补，但某些与漏洞利用相关的工作流仍受到限制或监控。
对 Astra 发布的独立报道也强调，围绕复杂自主工作仍存在尚未解决的安全问题。现实世界的可靠性仍不如受控演示所暗示的那样确定。
软件质量带来了一个更长期的挑战。通过今天的测试，并不能说明反复的智能体改动是否会让代码库保持易于理解和适应。
一项对编程基准测试局限的批判性分析指出，当前测试往往会遗漏结构性退化。代码可以仍然可用，同时变得更难以安全修改。
这一担忧直接限制了“少审查代码”的主张。工程师阅读代码的目的不止是确认即时正确性。他们还会检查抽象、所有权边界、重复逻辑、可观测性和未来维护成本。
执行视频无法揭示所有这些品质。专注于可见行为的报告同样做不到。
合适的审查策略很可能取决于风险。内部仪表盘中的视觉调整，理应获得不同于身份验证逻辑、支付处理或安全关键基础设施的审查力度。
团队可以定义结合多种证据类型的合并门槛。低风险变更可能要求测试套件通过、录制的用户流程以及完整的范围报告。
高风险变更还可能需要人工设计审查、独立安全测试和对敏感文件的手动检查。智能体的证据可以支持这些控制措施，但无法取代它们。
另一个问题是证据完整性。审查者需要确信，录制内容对应于提交的 commit、环境、配置和测试数据。
如果工件与正在审查的确切代码脱离关联，它们可能描述的是更早的构建，或配置不同的构建。强有力的可追溯性应将每项断言与其执行状态关联起来。
Cognition 尚未公开详述其重点展示工作流背后的每一项可追溯性控制措施。其内部基准测试仍属专有，也限制了与独立实验室之间的比较。
因此，这项基准测试主张应被视为产品信号，而不是对自主测试质量的既定衡量标准。
即使 OpenAI 的公开结果衡量的也是有边界的任务。生产代码仓库包含未记录的假设、不稳定的依赖、私有服务以及组织特定的发布规则。
Astra 可以提升智能体应对这种复杂性的能力。它不会消除工程判断——即判断何种证据才算充分——的必要性。
关键区别在于证明与证据。在日常软件实践中，测试提供的是证据：选定行为在明确条件下已成功运行的证据。
它很少能够证明完全正确性。Cognition 的公开表述有时会在口语中使用“证明”，但团队应保留更狭义的工程解释。
这种谨慎并不会降低该功能的重要性。它界定了该功能能够创造价值的范围，同时避免鼓励不安全的信任。
三个信号将表明工程师能否少审查代码
下一项考验在于，Cognition 能否将更强的演示转化为生产团队中可衡量、具备风险意识的采用。
第一个信号是独立可复现性。Cognition 应公布足够多有关其测试基准的细节，让外部人士理解任务选择、评分、模型路由和故障处理方式。
可复现的结果将强化这样一项主张：Astra 改善的是测试本身，而不只是产出更好看的工件。它们还将显示系统多久会诚实地报告失败或不完整的覆盖。
证据质量必须与任务完成情况分开评估。测试智能体可能得到正确结果，却给出无法使用的报告；也可能为不完整的测试创造颇具说服力的文档。
有价值的衡量指标可包括断言准确性、遗漏缺陷、误判通过、覆盖校准和审查者时间。它们还应追踪审查者是否做出了正确的合并决策。
如果独立评估确认这些维度均有改善，Cognition 的轻量审查工作流将获得可信度。如果结果在不同代码仓库之间差异显著，团队将需要更严格的部署规则。
第二个信号是生产环境中的表现。Cognition 表示，每日获批准的测试运行次数有所增加，但批准量本身并不能证明软件更好，或审查成本更低。
更有力的指标包括已合并的变更、逃逸缺陷率、回滚频率，以及审查每项获接受贡献所花的时间。团队应将这些结果与通过传统审查处理的类似变更进行比较。
Cognition 已探索过将“高效工程工时”作为业务指标。其评估使用了 233 个留出的会话，并报告约一半落在人类估算的两倍范围内。
该公司也承认，个体估算仍存在噪声。根据其发布的分析，双向相差两倍或三倍的误差都很常见。
这种坦率很重要，因为生产力主张可能与软件结果脱节。对节省工时的估算，无法捕捉部署后才发现缺陷的成本。
最具说服力的证据，应将减少的审查时间与稳定或提升的质量联系起来。如果团队审查更少代码，却经历更多回归问题，那么该工作流只是将成本转移到了下游。
如果审查时间下降，却没有恶化缺陷、回滚或维护情况，Cognition 的核心论点就会显著增强。
第三个信号是竞争对手如何重新设计验证机制。模型提供商和编程智能体公司可以通过独立审查智能体、更强的执行轨迹或标准化证据格式作出回应。
有意义的竞争回应将证实，验证已成为主要的产品层。它也会为买家提供替代方案，以避免由同一个智能体给自己的输出打分。
分离实现与审查模型能够引入有益的多样性。不同的提供商、提示词或测试生成系统，不太可能完全复现同一种误解。
然而，模型多样性本身并不能保证独立性。两个智能体仍可能依赖同一份不完整的规范或既有测试套件。
最好的系统将结合独立测试设计、确定性控制、工件可追溯性和明确的风险策略。届时，人工审查便可聚焦于自动化无法安全压缩的决策。
工程负责人应从可控范围内的任务开始选择，在这些任务中，可观察行为能强烈反映成功与否。界面 bug 修复、常规内部工作流和定义清晰的回归问题，都是合理候选。
他们应要求 Devin 说明哪些内容未被测试。还应将其证据与提交的 commit 进行比对，并为敏感变更保留常规控制措施。
开发者可以将这一新工作流作为注意力过滤器，而非权威。报告指出应查看的地方，录制展示发生了什么，而当风险要求检查时，代码仍然可供审阅。
Cognition 想要实现的结果是可信的，但并不会自动发生。只有当证据始终立足事实、范围明确，并与生产环境结果相连时，更好的测试才能降低审查工作量。
因此，对团队而言最重要的问题很实际：哪些改动可以依据执行证据批准，哪些仍需要逐行审阅所有关键代码？在将 Devin GPT-6 Astra 测试纳入默认合并流程之前，请有意识地检验这条边界。
