Cognition 正在借助 GPT‑6 Astra 提升 Devin 测试软件、展示验证结果的能力。这里真正值得工程团队关注的，不只是模型能否生成更多代码，而是智能体能否把“我改完了”推进到“我执行了这些检查，结果如下，你可以据此审查”。目标也很明确：让工程师减少逐行阅读低风险代码的时间，把注意力放在行为变化、边界条件和发布风险上。
目前给出的信息没有披露 GPT‑6 Astra 的具体 API、评测数据或 Devin 的内部实现，因此不能据此判断它使用了哪种测试生成算法。更稳妥的解读是：软件智能体的交付单位正在从代码补丁扩展为“补丁、测试和可复核证据”。
从代码生成转向可验证交付
传统编码助手通常停在 diff：它修改文件，然后等待开发者自己运行测试、重现页面或检查日志。面向完整任务的智能体则需要闭合更长的反馈回路：
- 理解验收条件和仓库约束。
- 修改实现及必要的测试。
- 在真实环境中执行测试、静态检查和构建。
- 根据失败输出继续修复。
- 汇总执行过的命令、结果与尚未验证的部分。
第五步很关键。“测试通过”本身不是充分证据。审查者还需要知道测试范围、运行环境、退出状态，以及哪些风险根本没有被覆盖。例如，只运行一个单元测试不能证明数据库迁移可回滚；一张正常页面截图也不能证明权限边界正确。
因此，智能体的最终报告应该区分三类信息：
- 已观察事实：实际执行的命令、退出码、测试数量、构建产物。
- 合理推断：根据测试结果判断某项行为大概率未回归。
- 未验证事项：生产数据规模、外部服务故障、浏览器兼容性或人工视觉判断。
这种区分能防止一份流畅的总结掩盖验证空白。
审查对象应该是证据，而不是一句“完成”
如果团队希望少审代码、快交付，智能体就必须输出结构化、可追踪的证据。一个实用的任务结果至少应包含：
| 内容 | 审查者需要看到什么 |
|---|---|
| 变更范围 | 修改了哪些模块，是否触碰公共接口或数据结构 |
| 验收条件 | 每条需求对应哪个测试或检查 |
| 执行记录 | 完整命令、退出码、耗时和环境摘要 |
| 失败过程 | 哪些检查曾失败，以及后续如何修复 |
| 残余风险 | 没有执行或无法自动判断的事项 |
这会改变代码审查的重心。低风险改动可以先看验收条件和自动化证据，再抽查关键 diff；涉及鉴权、计费、迁移、并发或供应链的改动，仍然应进行深入人工审查。模型能力增强不能替代风险分级。
可以这样实践：让每个改动生成验证清单
下面是一个可以直接放进仓库的最小 GitHub Actions 工作流。它不依赖某个尚未公开的 GPT‑6 Astra API，而是演示如何为 Devin 或其他编码智能体提供确定、可重复执行的验证入口。
运行前需要把 python -m unittest discover 和 python -m compileall 替换为项目已有的测试、类型检查或构建命令。将文件保存为 .github/workflows/agent-verification.yml：
name: Agent verification
on:
pull_request:
workflow_dispatch:
permissions:
contents: read
jobs:
verify:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.12"
cache: pip
- name: Install dependencies
run: |
python -m pip install --upgrade pip
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
- name: Run unit tests
run: python -m unittest discover -s tests -v
- name: Check Python syntax
run: python -m compileall -q .
- name: Record verification metadata
if: always()
run: |
mkdir -p verification
{
echo "commit=${GITHUB_SHA}"
echo "run_id=${GITHUB_RUN_ID}"
echo "python=$(python --version 2>&1)"
echo "generated_at=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
} > verification/environment.txt
- name: Upload verification evidence
if: always()
uses: actions/upload-artifact@v4
with:
name: verification-${{ github.sha }}
path: verification/
if-no-files-found: error
仓库还可以增加一份机器和人都能读取的验收文件，例如 verification-plan.yaml。智能体在修改代码之前填写它，完成后更新结果：
change: "Reject empty display names"
risk: low
acceptance:
- id: valid-name
behavior: "A non-empty display name is accepted"
command: "python -m unittest tests.test_profile.ProfileTest.test_valid_name -v"
- id: empty-name
behavior: "An empty display name returns a validation error"
command: "python -m unittest tests.test_profile.ProfileTest.test_empty_name -v"
not_verified:
- "Rendering differences in unsupported browsers"
本地或智能体环境可以逐条运行这些命令：
set -euo pipefail
python -m unittest tests.test_profile.ProfileTest.test_valid_name -v
python -m unittest tests.test_profile.ProfileTest.test_empty_name -v
git diff --check
这套约定的价值不在 YAML 本身，而在于建立稳定接口：需求对应检查，检查对应原始输出，原始输出对应具体提交。智能体可以自主迭代，但不能只用自然语言宣布成功。
自动测试仍有边界
更强的测试能力会降低审查成本，也会引入新的错误模式。智能体可能编写一个与错误实现相互迎合的测试，可能只验证顺利路径，也可能在不等价的本地环境中得到绿色结果。生成大量测试还会带来维护成本，尤其是过度绑定实现细节的测试。
落地时应保留几道硬约束：
- 智能体不能自行降低覆盖率阈值、删除失败测试或放宽安全策略，除非变更中明确标记并由人批准。
- 测试证据必须绑定提交哈希，避免审查到的代码和被验证的代码不一致。
- 高风险模块需要独立检查，例如迁移演练、权限矩阵、依赖漏洞扫描和人工威胁建模。
- 报告必须列出未执行的检查，不能把“没有观察到失败”写成“已证明安全”。
- 对 UI、性能和分布式行为，应结合截图、基准数据、追踪记录或临时环境，而不是只依赖单元测试。
采用建议：先定义完成，再扩大自治范围
团队不必一开始就让智能体独立交付所有改动。更可靠的路径是先统一 test、lint、build 等仓库命令，再要求每个智能体任务提交结构化验证报告。随后根据风险逐级开放权限：文档和低风险修复可以自动合并；公共 API、数据迁移、权限和资金相关代码继续强制人工批准。
GPT‑6 Astra 对 Devin 的意义，最终不应只用生成速度衡量。更有价值的指标包括首次验证通过率、人工重跑后的一致性、逃逸缺陷率、无效测试比例，以及审查者确认一个变更所需的时间。只有当证据可重复、边界写清楚、失败也如实呈现时，“少审代码、多交付”才会成为可持续的工程能力。