编程智能体的“测试通过”消息，仍然只是一条消息
摘要
微软的 Agensh 仓库提供了一个共享笔记板，供编程智能体协调工作，但它只存储上报的验证结果，而不会自行运行检查，因此“测试已通过”的说法并不能作为证据。这篇文章强调了多智能体工作流程中协调工作与验证工作之间的区别。
微软的 Agensh 仓库有一个供编程智能体使用的共享笔记板。有一点值得分享：这个笔记板存储的是上报的验证结果，但它本身并不执行这些检查。当一个智能体要判断是否信任另一个智能体的工作进展时，这一点很重要。笔记板的 README 描述了几个有用的机制：• 笔记分为以下类型：FACT、OBSERVED、FAIL、CLAIM 和 PATCH_SUMMARY。• 大多数笔记最多为 100 个字符；补丁摘要最多为 300 个字符。更完整的细节可以单独获取。• 默认情况下，任务认领记录在一小时后就不会再出现在实时读取结果中，因此被放弃的认领不会一直保持有效。• 匹配的 FAIL 会使该作者最新的候选补丁失效。• 新的补丁摘要会替换同一作者针对同一工作标签提交的旧摘要。但这些机制都不能保证上报的结果属实。该服务检查的是提交的文本，而不是验证命令是否确实执行成功。关键在于区分协调工作与验证工作。共享笔记板可以告诉智能体，其他智能体尝试了什么、声称了什么或上报了什么。在将补丁视为就绪之前，工作流程仍然需要一种检查结果本身的方法。
相似文章
当你的编码 agent 说“测试通过”时，你实际会检查什么才接受这项工作？
一位为编码 agent 构建独立验证原型的开发者分享了两个复现案例：pytest 在测试失败的情况下仍报告通过（退出状态为 0、基于配置的测试跳过），并询问社区在接受 agent 生成的变更之前如何进行验证。
@addyosmani：验证是让你的智能体产出出色结果的最重要因素之一。事先明确定义“完成”的标准……
Addy Osmani 强调，验证是让 AI 编程智能体取得良好成果的关键：在审查之前明确定义“完成”的标准，为智能体提供必须通过的可执行检查（bash 命令、测试、浏览器测试），并且只有在没有任何阻碍合并的问题时才发布。
智能体自行报告“这已经完成，所有测试都通过了”，你如何验证这一点？如何在大规模智能体场景下进行验证？
开发者讨论在 AI 代理规模化工作流中如何验证代理自称的“已完成且测试通过”，提出需要外部独立的验证步骤与可留证的调用记录，而非信任代理的自测结果。
外部验证一直是我编码代理运行中缺失的关键环节
作者指出，在有效使用 AI 编码代理时，外部验证是一个关键缺失的组成部分。
你如何验证你的智能体确实做了它声称做过的事？
一位从业者提出了一个常见的生产环境问题：底层操作失败时，AI 智能体却错误地报告任务已完成，并询问其他人在实际部署中如何验证智能体的输出。作者正在研究这一问题，并计划分享社区回答的汇总。