MirrorCode 与长周期 AI 编程 Agent：团队现在该改变什么
Epoch AI 和 METR 发布的 MirrorCode 把 AI 编程评测推到了更接近真实工程的位置：它不是让模型修一个小 bug，而是让 Agent 根据规格重建完整程序。最醒目的案例是一次大任务花费约 2600 美元、连续运行 19 天。这个数字不代表团队应该马上让 Agent 自己跑三周，而是提醒我们：分钟级、小预算 benchmark 已经不足以判断 AI 编程工具的真实价值。
对 NxCode 用户来说，MirrorCode 的重点不是“AI 是否会替代工程师”，而是“AI 是否能在明确边界内持续完成可审查的工程工作”。真正的工程任务包含需求澄清、环境配置、测试失败、依赖冲突、代码审查、成本控制和安全边界。只看一次 patch 是否通过测试，容易忽略这些环节。
先把几个术语说清楚
Agent 不是“会写代码的聊天框”。在编程场景里，Agent 通常能读取仓库、选择工具、编辑文件、运行命令、观察错误并继续下一步。模型只是推理引擎，真正决定体验的是围绕模型的工作循环。
Harness 是这个工作循环的控制系统。它决定 Agent 能看到哪些上下文、能调用哪些工具、什么时候要审批、如何重试、如何切换模型、何时停止。同一个模型放在不同 harness 里，成本、稳定性和最终 diff 可能完全不同。
Benchmark 是可重复测试。SWE-bench 更偏真实仓库 bug fix，TerminalBench 更偏命令行任务，MirrorCode 更偏长周期程序重建。它们都不是你的生产环境，但能让供应商声明变得可检验。
Token efficiency 不是越省越好，而是在结果质量相近时，用更少 token、更少工具调用、更少 review 循环完成任务。对于长周期 Agent，token 会在读文件、重试、跑工具、总结日志时快速消耗，所以成本必须成为评测指标。
Review evidence 是人类审查者判断结果所需的证据：diff、测试输出、命令日志、截图、假设、未运行检查的原因，以及为什么改这些文件的解释。没有证据的 Agent PR 往往比人工 PR 更贵，因为 reviewer 要重新推理一遍。
Acceptance criteria 是“完成”的定义。模糊的“优化 onboarding”会让 Agent 做出看似合理但不一定有用的改动；明确的“新用户能创建项目、邀请一名队友、进入 dashboard，且无 console error”才可测试。
团队应该怎么评测
最实用的做法是建立自己的内部任务集。选取过去两个季度已经完成的 20 到 50 个真实任务，包含 bug fix、测试补齐、小功能、依赖升级、迁移和文档修复。每个任务都写清楚目标、验收标准、相关约束和验证命令。然后用同一组任务比较 Codex、Claude Code、Cursor、Copilot Agents、NxCode workflow 或内部 harness。
不要只记录成功率。还要记录 wall-clock time、token 成本、工具调用、改动文件数、测试命令、失败重试次数、审查意见和最终说明是否与 diff 一致。这样你衡量的是“这个 Agent 系统能不能交付可 review 的工程结果”，而不是“它能不能在 demo 中写出一段代码”。
一个具体例子：迁移账单设置页
假设团队要把 billing settings page 从旧表单库迁移到新的组件系统。表面上只是 UI 技术栈迁移，实际上它可能牵涉验证规则、已保存支付方式、analytics 事件、feature flag、翻译文件、测试和回滚策略。
如果只给 Agent 一句“迁移这个页面”，它可能生成一个看起来干净的 diff，也可能通过一个单元测试。但真实风险在细节里：漏掉财务团队依赖的 analytics event，改坏某个 locale 的 translation key，遗漏无障碍属性，或改变边界条件下的表单验证。
更好的委托方式是分阶段。第一阶段只探索：让 Agent 找出相关页面、schema、测试、翻译、analytics 和 feature flag，输出文件地图和风险。第二阶段写计划：列出要改的文件、不会碰的文件、验证命令和已知风险，由人批准。第三阶段再实现，且限制在独立分支。第四阶段输出验证证据，包括测试结果、截图或本地路由检查、analytics/translation 是否保留。
这个流程比“直接让 Agent 写代码”慢，但更接近可合并的工程工作。长周期 Agent 不会消灭流程，反而会放大好流程的价值。
长周期 Agent 必须有预算
MirrorCode 的 2600 美元案例让成本变得具体。长周期 Agent 不是免费劳动力，它会持续消耗模型 token、CI、外部 API、云环境和人工审查时间。团队应该按任务类型设预算：简单 bug 可能只有 10 分钟，小型测试任务 20 分钟，迁移任务可以更长，但必须先有人批准计划。
预算也会倒逼任务拆分。一个大需求可以拆成探索、计划、实现、验证四个阶段。探索阶段输出相关文件和风险；计划阶段输出步骤和验收标准；实现阶段输出 diff；验证阶段输出命令结果和测试证据。没有这些证据的 Agent PR 不应该直接合入。
Harness 比提示词更关键
提示词仍然重要，但长周期工程主要是 harness 问题。Harness 决定 Agent 能看到哪些上下文、能调用哪些工具、什么时候需要审批、如何恢复错误、如何总结进度、何时停止。模型越强，harness 越重要，因为强模型更容易做出大范围改动。
模型路由也应建立在可测量的 workflow 之上。并不是每一步都需要最贵模型：架构判断可能需要旗舰模型，重复编辑可以用更便宜模型，日志总结可以用快速模型。但如果系统不知道当前步骤是高风险还是低风险，就无法正确路由。
如何阅读供应商声明
MirrorCode 之后，团队读 AI coding 产品发布时要多问几句。供应商说“能完成复杂工程任务”时，先问任务是什么：公开 benchmark、内部样例、合成任务，还是客户真实仓库？需求是否足够明确？Agent 是否能访问测试、文档、issue 历史和真实环境？
再问预算。5 美元跑通的任务和 2600 美元跑通的任务都可能有价值，但它们回答的是不同问题。还要问尝试次数：展示 best-of-many 和稳定的一次成功不是同一件事。最后看证据：认真可用的 agent workflow 应该留下日志、测试、diff 和面向 reviewer 的解释，而不只是 demo 视频。
人类仍然应该掌握什么
人类应该负责问题定义、验收标准、架构边界、安全策略、产品取舍和最终批准。Agent 可以探索、实现、测试、总结，但不应该悄悄重定义目标，也不应该无审查地上线。尤其是模糊需求，Agent 的第一步应是提出问题或方案，而不是立刻写代码。
MirrorCode 最有价值的启示是：AI 编程正在从“写代码”进入“受约束的工程委托”。团队如果想获得真正杠杆，就要把 Agent 当成工程系统来管理：有任务集、有预算、有日志、有验证、有 review。
