什么任务值得交给 AI 自主优化：创始人的准入与上线门

一篇发布于 7 月 8 日的 GPU 优化实录，在 8 月 16 日重新成为开发者社区的热门讨论。作者称，他结合 Codex、性能分析和 1,500 多次提交，把一段运行在 B200 上的 QR 分解内核从约 419,000 微秒优化到 1,805 微秒，最终在 183 个参赛结果中排名第 12。最抓眼球的数字是 232 倍。

对正在做 AI 产品的创始人来说，真正值得借鉴的并不是“让 Agent 跑一夜，所有工作流都能快 232 倍”。这个任务具备少见的优越条件：结果可以自动校验，性能可以用明确数值衡量，错误候选能够低成本淘汰，实验环境边界清楚，而且有专家持续调整搜索策略。大多数产品任务恰好相反：反馈嘈杂、结果滞后、质量带有主观性，真实用户也不能被当成可随意试错的 benchmark 样本。

因此，今天真正需要回答的问题是：哪些任务值得投入长时间的自主优化循环？一个候选方案在改变产品前，必须拿出什么证据？ 本文为非技术创始人和小型产品团队提供一套任务准入评分表、一个完整的客服 Agent 场景、一份可复用的上线凭证、明确的停止条件和分阶段发布流程。目标不是搭建一套“无人研究系统”，而是只在反馈可信的地方购买 Agent 时间，并把搜索结果限制在独立证据通过之前。

232 倍结果证明了什么，又没有证明什么

这显然不是“把任务扔给 Codex，第二天醒来收获突破”。它是一套被认真设计过的搜索作业。作者学习了 QR 分解的数学和硬件行为，向其他模型征求思路，阅读 profile，持续引导有前景的路线，也不断改进给 Agent 的规则。就连 232 倍本身也需要保留口径：它比较的是约 419,000 微秒的初始基线和 1,805 微秒的最终结果，而作者展示的 lineage 图从更晚的 108,803 微秒开始。这个倍数适合作为结果摘要，但不能独自解释每一部分提升来自哪里。

评测环境同样关键。GPU Mode 的官方数据说明把 qr_v2 列为 leaderboard 题目，明确区分 test、benchmark、profile 和正式 leaderboard 运行，并说明执行时间越低越好。它的参考内核仓库则公开题目材料和参考实现。候选方案可以快速得到来自外部 checker 和性能执行器的机器可读反馈。

所以，这次结果能够证明：在一个评估严格、边界明确的技术空间里，Agent 与专家组成的系统可以有效搜索。它不能证明 Codex 平均能带来多少倍提升，不能说明 1,500 次尝试的投资回报，也不能证明系统可以无人值守，更不能直接推广到产品战略、客服、定价、设计或合规。这些领域需要完全不同的评估器。

先把“优化循环”里的术语说清楚

为什么 QR 优化特别适合长时间搜索

这次案例至少具备六个适合自主搜索的条件。

第一，正确性可以执行。Checker 能拒绝无法重建所需结果的输出，不需要有人凭感觉判断“听起来像对的”。

第二，目标是数值化且高频的。每次运行都能很快返回性能，Agent 不必等待几周后才看到留存或退款变化。

第三，搜索空间有边界。候选只修改一个已定义问题在固定运行时和硬件上的代码，不会在优化途中悄悄改写公司的业务目标。

第四，失败可逆。速度变慢或结果错误的内核可以直接归档，不会触达客户、发出消息或污染生产数据。

第五，实验谱系被保留下来。日志、命名候选、profile 和分支笔记让系统能够比较不同思路，而不是不断重新踩同一个坑。

第六，专家始终能够介入。作者持续调整策略、补足领域知识并提出新假设。这与 Anthropic 在高效 Agent 构建指南中总结的 evaluator-optimizer 模式一致：只有当评估标准足够清楚，而且反馈确实能带来可测提升时，迭代优化才是好选择。

Google DeepMind 的 AlphaEvolve 论文展示了更正式的同类结构：语言模型提出程序变更，评估器负责打分，程序数据库支持演化选择。DeepMind 的官方介绍也强调，当进展能够被客观、系统地度量时，这类方法尤其有用。这是一项任务适配条件，不是“所有业务流程都能写成可靠 fitness function”的承诺。

用任务准入评分表决定是否值得投入

在给优化循环拨预算前，先对以下八个维度分别打 0 到 2 分。0 表示应该停止，1 表示只能做受限实验，2 表示条件较好。前两项不能被平均分掩盖：如果真值不可靠，或者尝试会产生危险副作用，即使其他分数很高也不应自主搜索。

可以先采用一条保守规则：真值和副作用都必须拿到 2 分，总分至少达到 13/16，并且必须有实名的晋级负责人。这是本文提出的产品起点，并不是研究得出的普适阈值；只有拿到自己业务的数据后才应该调整。分数较低不等于“不能使用 AI”，通常只是说明应该选择一次性助手、固定工作流或人工复核批处理，而不是自主爬坡。

把硬门槛和优化分数彻底分开

优化循环需要两类评估。硬门槛保护不能交易的条件，例如输出 schema 有效、没有泄露密钥、授权正确、不会重复扣费、包含必要说明、延迟不超过上限，或事实覆盖达到最低要求。只要有一项硬门槛失败，候选就应被拒绝，即使总分更高。

例如：

eligible(candidate) =
  schema_pass
  AND forbidden_action_count == 0
  AND critical_slice_pass_rate == 100%
  AND p95_latency_ms <= 4500

score(candidate) =
  0.50 * task_success_rate
  + 0.25 * reviewer_quality_rate
  + 0.15 * coverage_rate
  - 0.10 * normalized_cost_per_accepted_result

这些权重只是示例，并非通用答案。真正重要的设计是：便宜不能补偿越权动作，高平均分也不能遮住关键切片的失败。

面对开放式 Agent 工作，只靠一种 grader 不够。Anthropic 建议组合不同类型的评估器并进行重复 trial，因为同一个 Agent 在多次运行中的行为会波动。SWE-bench Verified也说明了类似问题：其中 500 个任务经过人工检查，确认问题描述清楚、测试补丁正确、任务确实可解，之后才成为更可靠的评测子集。自动化测试数量很多，并不等于每条测试都真的在测你以为的东西。

具体场景：优化一个客服分流 Agent

假设一家小型 SaaS 公司 CedarDesk 用 AI app builder 做了客服 Agent。它会识别请求类型、读取账户上下文、起草回复，并建议进入自助解决、人工处理或某个已批准动作。创始人希望让系统每晚自动优化 prompt、模型路由、检索参数和工具说明。

这其实不是一个优化任务，而是至少四个证据结构完全不同的表面：

CedarDesk 准备 600 条脱敏历史案例：400 条作为可见开发集，100 条作为隐藏晋级集，另 100 条留待之后做漂移检查。团队还会特意补足少见但后果严重的类别，包括取消订阅、安全事件、支付争议、数据删除，以及涉及其他租户的请求。这些类别不能只按出现频率加权，每个都要有独立硬下限。

优化循环每次只能修改一个表面。所有候选都在 replay 环境中运行，只能读取账户快照，所有写动作都由 stub 代替。每次输出必须包含路由、回复草稿、引用、拟调用工具参数、延迟和预估成本。确定性断言会直接拒绝跨租户检索、不受支持的退款承诺、虚构引用和格式错误的动作参数。人工审核员再对轮换样本的实用性和语气打分。Agent 可以提出动作建议，但评估环境绝不会把真实账单或删除工具交给它。

跑到第 300 次左右，184 号候选提高了可见集上的路由准确率，也降低了成本，但它在隐藏的支付争议切片上明显退步，因此不能晋级。241 号候选的平均提升小一些，却通过了所有关键切片，多次运行落在预期波动范围内，也通过了隐藏集。它才有资格进入影子运行。

这里的产品结论很直接：“最高分”不一定等于“可以上线”。可晋级的方案，是在所有不变量下表现最好、而且能泛化到未见反馈的候选。

防止优化循环过拟合或钻评估器空子

长时间运行的循环一定会利用评估器奖励的一切，包括评估器本身的错误。这不需要假设 Agent 有恶意，只是优化压力的正常结果。

至少要保留四类证据分区：

1. 可见开发案例：每次尝试后都可以得到详细反馈。
2. 隐藏晋级案例：只返回聚合后的通过或失败，而且应尽量少用。
3. 对抗案例：专门检查捷径、泄露、歧义指令和禁止效果。
4. 时间漂移案例：来自之后的生产分布，用来判断昨天的赢家是否还适合今天。

对于具有随机性的模型，必须重复运行。一次幸运通过不等于真正提升。METR 的任务完成时长方法把成功率与任务难度的关系建模，同时报告 50% 和 80% 可靠性时长，并特别提醒：time horizon 不是 Agent 能连续自主行动多少小时。映射到产品团队，就是应该报告结果分布和关键切片可靠性，而不是挑出一次漂亮运行。

评估器还必须位于可编辑搜索面之外。候选可以修改 prompt 或工具说明，但不得重写硬门槛、隐藏标签、花费计量或晋级规则。修改评估器必须走另一条独立审核流程并生成新版本，依赖旧指标的前后结果也不能直接比较。

按“有效学习”买预算，而不是按活动量买预算

QR 复盘里有 1,500 多次提交，但这不是所有产品都应模仿的目标。一个产品优化循环至少需要四种预算：

• 尝试预算：候选数量和重复 trial 上限。
• 算力预算：模型、评估器、沙箱和外部服务的总成本。
• 审核预算：人工标注、争议处理和晋级最多可使用多少时间。
• 副作用预算：搜索期间最好为零；canary 阶段也必须明确封顶。

出现以下任一条件时，应停止循环：

• 连续若干候选家族都没有带来有意义的隐藏集提升；
• 大部分收益只来自一个可见切片，而关键切片停滞；
• 重复 trial 与当前版本的置信范围高度重叠；
• 评估争议或人工审核负担超出预算；
• Agent 没有新假设，却不断重试已被淘汰的思路；
• 基础设施成本已经高于可量化收益的预期价值；
• 硬门槛失败暴露出沙箱或任务边界本身不完整。

用一份“晋级凭证”结束搜索

搜索日志最终应收敛成一份紧凑 artifact，让另一个人不必阅读 300 段 transcript 也能完成审计。可以从下面这份模板开始：

optimization_promotion:
  task_id: "support-triage-routing-v3"
  candidate_id: "cand-0241"
  parent_id: "cand-0198"
  changed_surface: "routing-prompt-and-threshold"
  evaluator_version: "triage-eval-2026-08-16.2"
  environment_hash: "sha256:..."
  model_and_settings: "provider/model/version + temperature + seed policy"
  evidence:
    development_trials: 5
    promotion_set_exposures: 1
    critical_slices_passed: ["security", "billing", "deletion", "tenant-boundary"]
    incumbent_score: 0.812
    candidate_score: 0.846
    uncertainty_or_range: "record method and interval"
  hard_gates:
    forbidden_effects: "pass"
    tenant_isolation: "pass"
    citation_integrity: "pass"
    latency_ceiling: "pass"
  cost:
    search_total_usd: "measured"
    human_review_minutes: "measured"
    cost_per_accepted_case: "measured"
  decision:
    stage: "shadow"
    owner: "named human"
    expires_at: "timestamp"
    rollback_to: "incumbent-version"

不要让 Agent 把未知字段用“看起来合理”的估计补齐。成本、环境身份或隐藏集暴露次数缺失时，应明确保留 unknown，并且可能因此阻断晋级。

依次经过影子、canary 和回滚门

实验赢家不应直接进入全量生产。可以采用四个阶段。

每个阶段都要把真实结果与晋级时的主张重新比较。NIST 的 AI RMF Core要求在生产环境中持续监控 AI 的行为和功能。保留集胜出只足以支持一次试运行，不是永久认证；数据分布、工具、供应商模型、用户行为和业务政策都会变化。

七类可预见的失败模式

哪些场景不应该做自主优化

如果成功标准本来就需要创始人决定“产品应该重视什么”，就不要启动自主循环。定价伦理、品牌定位、员工评价、医疗判断、法律结论、危机沟通和新政策选择，不会因为写了一段模型 grader prompt 就变成客观问题。

反馈滞后或污染严重时也不适合。留存、信任和 marketplace 质量往往需要几周才能观察，同时还受到产品改版、季节、获客渠道和客户预期影响。如果 Agent 在结果成熟前就继续迭代，它优化的多半是噪声。

尝试不可逆或社会成本很高时同样不适合。你不需要拿真实退款决定、公开帖子、销售邮件、账号封禁或生产数据库迁移做 1,500 次实验。应该使用模拟、回放，或者把人留在动作链上。

如果没有稳定旧版本和明确回滚，也不要开始。搜索必须和已知基线比较；团队若无法恢复当前配置和数据状态，就还没有准备好进行自主探索。

最后，如果简单的固定工作流已经达到要求，就没必要增加 Agent 复杂度。Agent 系统用成本和延迟换取灵活性。确定性规则、普通 A/B 测试、批量分析或受监督助手，可能以更容易证明的方式创造同样业务价值。

创始人的 48 小时检查清单

创始人最终要做的判断

232 倍内核优化之所以重要，不只是数字大，而是它把自主优化真正需要的条件暴露出来：快速的外部裁判、有边界的可编辑对象、低成本且可逆的失败、持久的实验历史，以及一个同时改进代码和搜索方式的专家。这些条件本身才是产品。

对 AI app builder 用户来说，正确做法不是复制 1,500 次尝试，也不是承诺一夜突破，而是寻找那些“真值可执行”的窄表面，隔离每次尝试，保护保留证据，保存候选谱系，计算人工审核成本，并把上线权留在优化循环之外。当这些条件成立时，自主优化可以把机器时间转化为持续积累的产品学习；条件不成立时，它只会把模糊问题变成看似自信的高速运动。

参考资料

1. Sankalp，Auto-research with Codex：如何把 GPU 内核从基线优化 232 倍。
2. GPU Mode，KernelBot 数据集说明。
3. GPU Mode，官方参考内核与题目集。
4. Google DeepMind，AlphaEvolve：用 Gemini Agent 设计高级算法。
5. Novikov 等，AlphaEvolve：用于科学与算法发现的 coding agent。
6. Anthropic，如何设计 AI Agent 评估。
7. Anthropic，构建高效 Agent。
8. SWE-bench，SWE-bench Verified。
9. METR，前沿 AI 模型的任务完成时长。
10. Google Cloud，使用 canary 部署策略。
11. NIST，AI 风险管理框架核心。