同一个任务跑十次用隔离环境评测编码 Agent 的决策差异同一个编码任务交给 Agent 两次往往能得到两种都能编译的实现。真正值得追问的是哪些选择是稳定的哪些选择只是任务描述没有写清最后由模型自行决定了Multirun 的原文介绍了一种评测方式把同一个仓库快照和任务交给多次隔离运行再比较代码与数据库差异。本文保留其中的工程方法原作者的运行数字均作为案例转述不代表本地复现结果。1. 为什么一次运行看不到问题假设任务是“给单用户应用加入团队功能”。实现通常会增加团队表、成员表以及数据归属字段。但下面这些问题并没有唯一答案删除团队后团队数据删除还是保留已有个人数据是否迁入个人团队成员表用联合主键还是独立 IDAgent 可以替你补齐这些决定测试也可能全部通过。此时通过测试只说明满足了测试覆盖的条件不能证明符合产品预期。原文报告的十次运行在主要表结构上趋于一致但删除策略等决定出现分歧。样本量只有十次不能据此认定模型在总体上以某个精确概率选择方案。能确定的是任务中存在需要显式说明的分叉。2. 一个运行单元应包含什么run (source, task, variant) - artifactssource是固定提交和可选数据库种子task是版本化任务说明与检查variant可以是模型、提示词变体也可以完全相同artifacts包括代码 diff、数据库 diff、日志和检查结果。比较之前先固定起点仓库提交、依赖锁文件、数据库种子、任务文件与模型配置。若每次环境不同观察到的差异就混入了环境变化。3. 代码隔离之外还要隔离数据库Git worktree 可以给不同运行提供独立工作目录但不能隔离共享数据库。多个 Agent 同时修改同一个数据库会污染彼此的实验。原项目为每次运行创建独立的 Postgres 分支。支持写时复制的数据库服务可以减少完整复制的成本具体创建延迟、限制和费用取决于服务及工作负载不能把原作者小规模样例的结果外推到任意数据库。没有数据库分支能力也可以使用独立数据库或容器。关键要求是起点一致、写入互不影响、清理过程可审计。涉及真实数据时还要控制种子数据和外部服务访问防止“数据库隔离了但邮件接口仍指向真实用户”。4. 把清理作为一个有记录的阶段运行可以经历以下主路径PENDING - PROVISIONING - RUNNING - DIFFING - TEARDOWN - DONE失败、超时或取消也必须进入清理阶段。需要先生成差异再删除数据库分支否则会失去评测证据。新增的工程检查点是资源 ID、创建时间和清理状态都写入结果存储并有独立机制检查遗留资源。只在进程内部写一个finally无法覆盖宿主机退出或进程被强杀的所有情形。5. 不只看测试通过率还要审查决策比较维度可以发现什么表结构与约束外键删除策略、NULL 语义、唯一性差异数据变化迁移是否保留旧数据是否遗留测试数据权限行为团队之间能否越权访问代码差异新增接口、依赖、迁移方式执行记录工具失败、重试、耗时与资源使用原文中的构建检查和“是否存在 team 相关结构”的检查较弱不足以验证租户隔离或产品语义。优化后的评测应增加行为断言例如团队 A 不能通过新接口访问团队 B 的数据。发现分歧后不要简单投票。多数运行都采用CASCADE也不能替产品决定删除团队是否应该删除资产。先确认需求再把决定写回任务和验收条件。6. 可复用的实验步骤选择一个有多种合理实现的任务固定提交和数据快照。给每次运行分配独立代码目录、数据库及受限凭据。限制并行度记录模型和执行配置。保存代码、数据、检查与日志产物后再清理环境。归纳分歧把产品约束补进任务再做下一轮比较。这类实验衡量的是稳定性和任务歧义不自动等于正确性。多个 Agent 也可能稳定地犯同一个错误。最终仍需要需求、行为测试和人工审查共同判断方案是否可用。
)
