北京
最近，我与一家软件工厂供应商争论一个问题：编码智能体到底能不能被评估？对方坚持认为“无法评估”。理由听起来很合理：软件工程是开放式问题，需求不完整，代码仓库里藏着多年的未记录决策，两个工程师可能用完全不同的方式解决同一个问题，而且都是正确的。智能体可能这次失败，下次成功。任何基准测试都无法重现发布生产级软件所需的全部上下文、协商和判断。 但这些理由只说明“难以评估”，而不是“无法评估”。我们一直都在评估那些拥有无数可能实现的传统软件系统。编码智能体也应该用同样的标准来对待。 第一个原则：要认清智能体不等于模型。编码智能体不仅仅是一个模型，它由模型、工具、仓库上下文、指令、权限、执行环境和反馈回路组成。任何一部分变化都可能导致结果显著不同。一个更强的模型如果仓库上下文不足，可能不如一个拥有合适工具和快速测试套件的较小模型。公共基准测试往往容易被误用，因为一个分数通常被描述成在衡量底层模型，但实际上它衡量的是某个特定模型-智能体-环境组合在特定token和时间预算下的表现。所以评估编码智能体，评估的是整个系统。 第二个原则：要评估行为，而不是对比答案。有人反对编码智能体评估，是因为精确匹配的评分方式行不通。智能体可以生成一个有效的补丁，但看起来和人工编写的参考补丁完全不同。这确实是个问题，但这恰恰说明我们不应该把生成结果与参考答案做逐字对比，而应该评估行为。行为包括：智能体是否真正理解了需求？是否修改了正确的文件？是否运行了测试？测试是否通过？是否产生了额外的破坏？通过行为观察，我们可以判断它是否完成了任务，而不必要求它和人类写法一致。 第三个原则：要用真实任务，设置可验证的标准。基准测试需要包含实际的任务，比如修复一个特定bug、实现一个小功能、重构一段代码。每个任务都要有明确的验收标准：代码是否通过所有测试？是否遵循项目风格？是否引入了新的错误？甚至可以定义硬性指标，比如执行时间、成功率、平均修复次数。这样，即使智能体是非确定性的，我们依然可以通过多次运行、统计分布来评估其可靠性。 总而言之，编码智能体的确难以像聊天机器人那样用简单问答来评分，但这不是放弃评估的理由。我们只需要认真定义“工作成果”，并设计出可观察、可验证的评估体系。就像评估人类工程师一样，我们看他们交付的代码，看他们解决的问题，而不是看他们是否复制了参考答案。智能体也应该如此：评估它们的工作，而不是把它们的输出与标准答案机械对比。这样，我们才能真正知道哪些智能体值得信赖，哪些只是看起来聪明。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
