OpenAI与Cognition展示了GPT-6 Astra如何协助AI工程师代理Devin完成代码编写、运行测试并提交录像与报告作为证明，从而把关注点从生成代码转向验证与可审查性。Cognition与OpenAI公布的内部基准和案例演示显示Astra在测试覆盖、报告清晰度和证据呈现上有提升，但这些结果尚缺独立复现与更广泛的长期数据支持。
OpenAI在一篇关于Cognition与Devin的案例文章中表示，Cognition正把GPT-6 Astra用于其AI软件工程师Devin的测试流程，让Devin不仅编写和修改代码，也能运行软件、记录结果，并提交更容易供工程师检查的测试证据。
这项合作把焦点从“AI能否生成代码”推进到另一个更实际的问题：当代码由AI代理完成时，谁来确认它真的按照预期工作？Cognition在OpenAI发布的一篇案例文章中说，Astra改善了Devin测试软件、展示测试结果以及处理客户反馈的能力。
从写代码转向证明代码有效
Cognition是Devin背后的公司。公司将Devin定位为能够规划、编写、测试并交付生产代码的自主软件工程师。随着这类代理承担的任务变多，代码审查本身可能成为新的瓶颈：工程师需要检查更大量的改动，同时判断代理声称完成的功能是否真的可用。
在OpenAI的案例文章中，Cognition工程师Alex Yan表示，Astra的一项重要改进，是“测试并证明它的工作确实按照预期运行”的能力。按照Cognition的说法，Devin现在可以把测试过程本身，以及测试结果的记录，一并交给负责审查的人类工程师。
OpenAI举出的一个例子是iPhone游戏《Otter Run》。Devin使用Astra测试这款游戏后，返回一段游戏在模拟器中运行的录像，同时附上测试报告。报告列出哪些检查已经通过，也说明哪些部分尚未覆盖。
这类输出与传统的自动化测试报告并不完全相同。录像可以帮助工程师直接观察应用行为，报告则说明测试范围和剩余空白。它不能证明软件不存在缺陷，但能够让审查者更快了解代理实际做了什么、没有做什么。
Cognition还表示，当客户通过截图报告一个软件问题时，团队可以把截图交给使用Astra的Devin。代理修复问题后，再返回一张显示修复结果的截图。公司认为，这有助于缩短从收到反馈到回复客户之间的时间。
OpenAI与Cognition公布了哪些数据
在GPT-6 Astra发布文章中，OpenAI引用了Cognition的内部测试结果。Cognition称，在其名为FrontierCode 1.1的工程任务基准上，Astra的表现与此前的前沿模型Fable 5相差不到0.4个百分点，但成本低64%。在Devin的测试能力中，Cognition还称Astra在其内部测试基准上取得了新的最高成绩，生成的测试更加全面，报告更清晰，视频证据也更容易理解。
这些数字目前主要来自Cognition和OpenAI的公司披露，并非一项公开、独立复现的评测。FrontierCode 1.1是Cognition自有的基准，按照Devin方面的说明，它评估真实软件工程任务中的质量和代码可合并性。外部读者可以据此了解公司的测试方法和产品定位，但不应把这些结果直接等同于所有代码库、团队或生产环境中的普遍表现。
OpenAI在9月发布GPT-6 Astra时，将其定位为面向计算机操作、软件工程和专业工作的模型。公司称，Astra能够执行包括浏览器操作、软件安装和测试、前端质量检查在内的多步骤任务；同时，Astra也通过API以及多个云平台逐步开放。具体可用性和权限，仍取决于产品、地区和账户类型。
Cognition在Devin的产品说明中表示，Astra不只被用于Devin云端代理，也被用于公司的CLI和桌面产品。这意味着模型在Cognition产品中的角色，并不只是负责生成代码，而是被放入一个更大的“代理—工具—测试—反馈”工作流中。
AI代理的瓶颈可能从生成转向验证
过去，软件开发中的AI工具主要被用于补全代码、生成函数或提出修改建议。随着代理开始直接操作代码库、运行命令和提交变更，验证工作的重要性随之上升。一个代理如果能够快速完成更多任务，却不能清楚地说明测试覆盖范围，反而可能增加工程师的审查负担。
Devin与Astra的组合试图解决的，正是这一问题：让代理交付的不只是代码差异，还包括运行证据、测试报告和对未覆盖部分的说明。对工程团队而言，这种“可审查性”可能比单纯的生成速度更关键，因为生产软件的风险通常来自遗漏、边界条件和上下文误解，而不仅是语法错误。
但测试录像和自动生成报告也有局限。录像只能展示被执行的场景，不能代表所有用户路径；报告的完整程度也取决于代理选择了哪些测试，以及它是否正确理解了产品需求。即使测试全部通过，也不意味着代码没有安全漏洞、性能问题或尚未发现的业务逻辑错误。
因此，Cognition所描述的流程更像是对人工审查的补充，而不是完全替代。公司希望工程师“手动查看更少的代码，最终交付更多软件”，但这一目标能否在不同规模的代码库和高风险行业中成立，还需要更长期的实际数据验证。
模型提供商开始进入软件交付链条
这项合作也显示，模型公司与AI编程工具之间的关系正在变得更深。模型不再只是在开发者输入问题后返回一段文本，而是直接参与规划任务、操作开发环境、运行测试并整理证据。模型的判断质量、工具权限和监控机制，都会影响最终的软件交付过程。
OpenAI在GPT-6 Astra安全说明中承认，模型能力的提升也带来了更高的网络安全风险。公司称，Astra在网络安全任务上的能力达到其“关键”级别，因此为模型部署增加了更严格的隔离、监控和使用限制。对于能够操作代码库和计算机环境的代理来说，如何限制越权操作、保护客户代码和识别错误的测试结论，仍是产品落地必须面对的问题。
就目前公开信息而言，Astra在Devin中的表现主要得到两类证据支持：一类是OpenAI和Cognition公布的内部基准与案例，另一类是具体产品演示，例如游戏模拟器录像和修复后的截图。它们说明了产品希望实现的工作方式，但还不足以独立证明代理已经能够在各种生产环境中可靠地完成端到端软件开发。
对软件工程团队来说，真正值得关注的或许不是AI能否一次性写出更多代码，而是它能否持续提供可信、可追踪、边界清楚的工作证据。Devin利用GPT-6 Astra测试自身工作的尝试，正把这一问题推到AI编程竞争的中心。