arXiv 8 月 27 日提交的 Naive Prompt Optimization: Rethinking the Need for Complex Prompt Search 提出一个很直接的问题：agentic AI 里 prompt optimization 已经能带来接近 fine-tuning 的收益，也能降低优化和服务成本，但最近的方法是否变得过于复杂？论文提出 Naive Prompt Optimization，简称 NPO，一个轻量单线性方法：用 teacher model 结合 rollout feedback 反复修订 prompt。摘要报告称，NPO 在更少 rollouts 下达到与 GEPA 相当或更好的表现，并且 teacher model 越强，优势越明显。参考来源：arXiv 论文页、arXiv cs.AI recent、Hugging Face Daily Papers。
这篇论文适合作为 agent 调优的降温剂。过去几个月，prompt 优化开始向多候选、多分支、搜索树、进化策略和 RL 化流程发展。这些方法当然有价值，但工程团队容易忽略一个前提：如果评测集、rollout 日志和失败归因还没做好，复杂优化器只是在放大噪声。NPO 的意义不是宣称“简单永远最好”，而是提醒我们先把最小闭环做到足够强。
NPO 的基本流程
NPO 可以被理解成一个单线性版本的“写 prompt、跑任务、看失败、修 prompt”。
第一步，准备初始 prompt。它可以是人工写的，也可以是从现有系统提示中抽出来的。
第二步，在固定任务集上跑 rollouts。对 agent 来说，rollout 不只是最终回答，还包括工具调用、观察、错误、成本、步数和验证结果。
第三步，把失败样本和成功样本交给 teacher model，让它总结 prompt 的缺陷，并生成一个修订版本。
第四步，用新 prompt 继续跑同一评测和增量评测。如果改进稳定，就沿这条 lineage 继续；如果退化，就回滚到上一个版本。
和复杂搜索相比，NPO 不同时维护大量候选，也不需要在每一代做大规模 tournament。它把优化压力更多交给强 teacher 的推理能力和真实反馈。
为什么它可能有效
Prompt 对 agent 的影响往往不是连续可微的，而是由少数关键规则控制。例如：
Before editing code, inspect the existing file and tests.
When a tool fails, classify the failure before retrying.
Never claim a command passed unless the command output is observed.
If evidence is insufficient, stop and ask for clarification.这类规则一旦补上，行为会出现明显跃迁。复杂搜索能找到它们，强 teacher 看失败轨迹也能找到。对于很多早期系统，瓶颈不是搜索空间太大，而是没有把失败轨迹整理给一个足够强的 reviewer。
NPO 的另一个优势是可解释。每一版 prompt 都有父版本、失败样本和修改理由。团队可以审查为什么新增某条规则，哪条评测驱动了变化，是否引入了副作用。复杂优化器如果只输出胜出候选，很容易丢掉这条可维护链路。
和 GEPA、GRPO 的关系
论文摘要中提到 NPO 与 GEPA 比较，并在 interactive games 中保持竞争力；GRPO 在某些不太适合 prompt optimization 的任务上表现更好。这组对比很合理。
GEPA 代表更复杂的 prompt 搜索和反思式优化路线。它的优势在于探索多个候选，可能更适合局部最优很多、反馈不稳定或任务分布很宽的场景。NPO 的优势是便宜、清晰、迭代快。
GRPO 更接近强化学习路线，它能改变模型行为分布，而不只是改变外部提示。对于需要形成新策略、长程信用分配或 prompt 无法表达的能力，RL 类方法仍然重要。但它的成本、基础设施和安全审核更重。
因此正确取舍不是“谁取代谁”，而是分层使用。先用 NPO 建立轻量优化基线；如果基线稳定但碰到探索瓶颈，再引入 GEPA；如果 prompt 层已经无法解决，且任务足够高频稳定，再考虑 GRPO 或 fine-tuning。
一个可落地的 NPO 骨架
小团队可以用下面的 JSONL 存评测样本。
{"id":"a1","task":"修复一个失败的 Astro MDX 构建","success":"pnpm run check passes","risk":"medium"}
{"id":"a2","task":"根据仓库规范新增一篇文章","success":"lint-tags and check pass","risk":"medium"}
{"id":"a3","task":"比较两个 API 的计费差异","success":"all prices cite source URLs","risk":"low"}每次 rollout 保存为结构化记录。
{"task_id":"a1","prompt_version":"v3","passed":false,"failure":"claimed check passed without observing output","cost_usd":0.18,"steps":14}然后把失败样本组织给 teacher。
You are optimizing the system prompt for a coding agent.
Given the current prompt, passed examples, failed examples, and failure labels,
produce a minimal prompt revision.
Do not add broad motivational text.
Return changed rules and rationale.注意这里有两个工程约束。第一，只允许 teacher 输出最小改动。Prompt 优化最常见的问题是越改越长，最后模型被几十条互相冲突的规则困住。第二，每次修改必须绑定失败标签。如果一条规则找不到对应失败，它就不该进入主 prompt。
评测比优化器更重要
NPO 的核心不是“让模型帮你改 prompt”，而是让 prompt 改动受同一套 rollouts 约束。没有固定评测，NPO 会退化成 prompt 打磨；没有失败分类，teacher 只能给泛泛建议；没有回滚，prompt 会持续膨胀。
一个健康的 prompt 优化流水线至少包含：
版本化 prompt。每次修改都有 diff、作者、触发样本和发布时间。
冻结评测集。保留一组永远不参与优化的 holdout，防止过拟合。
失败 taxonomy。把失败分成信息不足、工具误用、格式错误、越权、成本过高、验证缺失等类型。
成本记录。更好的 prompt 如果让平均步数翻倍，不一定值得上线。
人工审查。高风险规则必须有人看，尤其是会影响权限、拒答和安全边界的规则。
跨模型迁移的现实意义
论文摘要提到，NPO 优化后的 prompt 直接应用到其他 student models 时也能带来改进，尤其同模型家族内更明显。这对企业很重要，因为模型供应商和版本会频繁变化。一个好的 prompt 优化流程如果能产出跨模型规则，就能降低迁移成本。
但迁移不能省评测。不同模型对工具 JSON、长系统提示、拒答格式和 chain-of-thought 隐藏策略的敏感度不同。更稳的做法是把 prompt 拆成三层：通用任务原则、模型适配层、运行时策略层。NPO 可以优化通用层，也可以针对某个模型优化适配层，但不要把所有东西混在一个巨大的系统提示里。
结论
NPO 这篇论文最有价值的地方，是把 prompt optimization 从“复杂算法竞赛”拉回工程常识：强 teacher、真实 rollout、清晰失败、最小修订、严格回归。对大多数 agent 团队，这条路线应该先于复杂搜索和 RL。
复杂方法不会消失，但它们应该建立在强基线之上。先证明一条单线性 prompt 迭代链路已经跑到瓶颈，再增加搜索复杂度。否则你优化的可能不是 agent 行为，而是评测噪声和 prompt 长度。