Codex自动探索优化技能：研究-测试-评判闭环

AI 编程 Agent 非常擅长快速生成实现方案。

但项目优化不仅仅是一个实现问题。

当我让一个 Agent 改进一个真实项目时，往往会出现以下问题：

它不会探索替代方案，只会实现第一个看起来合理的想法；

它会搜索论文，但从不将这些论文的机制与本地项目建立联系；

它在不同条件下比较实验；

它在看到结果后更改成功标准；

它不断调整一个失败的思路，却没有停止规则；

它报告某件事“更好”，却不解释因果机制；

它留下大量互不关联的笔记，难以续上。

我需要一个更有纪律性的工作流程：一个将研究、头脑风暴、实现、测量、评审和决策连接起来的流程。

这就是 Automation Exploration Pro，一个用于证据导向项目探索和重复优化的开源 Codex Skill。

👉 github.com/fancheng5840074-bit/automation-exploration-pro

该 Skill 将探索组织为一个可重复的循环：

Inspect the project
        ↓
Confirm performance and complexity metrics
        ↓
Freeze the promotion gates
        ↓
Research papers and relevant domain journals
        ↓
Brainstorm and adapt mechanisms to the local project
        ↓
Execute the smallest testable candidate
        ↓
Audit the evidence and comparison conditions
        ↓
Explain the result from first principles
        ↓
PROMOTE / RETAIN / REVISE / REJECT / INCONCLUSIVE
        ↓
Continue with the next justified candidate

在比较解决方案之前，用户需要确认：

推广或停止的门槛；

是否允许 subagent 并发；

最大循环次数。

这可以防止 Agent 在实验已经结束后发明一个方便的成功标准。

1. Cyclic Optimization

Cyclic optimization 专为已有可运行基线的项目设计。

适用场景包括：

降低 API 延迟而不破坏正确性；

在内存限制下提升模型精度；

在保持信号质量的同时减少硬件资源使用；

改进分析流水线而不将运行时间增加到可接受阈值以上；

减少实验工作流的成本或持续时间。

每个候选方案在冻结条件下与当前最优方案进行比较。

如果候选方案通过已确认的门槛，它就成为新的最优方案。下一个候选方案必须击败这个已被推广的结果——而不是那个过时的原始基线。

一个请求可能长这样：

Use $automation-exploration-pro in cyclic optimization mode.

Performance metric:
All conformance tests must pass.

Complexity metrics:
p95 latency and peak memory.

Promotion gate:
Reduce p95 latency by at least 15%, with no correctness regression
and no more than 5% additional peak memory.

Subagent concurrency:
Allowed.

Maximum cycles:
4.

目的不是生成无限的参数搜索。机制上有实质性不同的方案会成为一个新候选方案，并消耗一个新循环。

2. Project Exploration

Project Exploration 适用于技术路线仍不确定的场景。

该 Skill 不是优化一个最优方案，而是研究和比较几种机制上截然不同的方案。

文献工作流从实际的本地问题出发。它可以使用广泛的学术索引、预印本来源、出版商记录、与项目相关的领域数据库和期刊。

然而，找到一篇论文只是开始。

每个有文献支撑的候选方案都必须通过以下映射完成本地化：

Paper mechanism
    → local project constraint
    → required adaptation
    → predicted metric effect
    → cheapest falsification test

工作流还将证据分为三类：

Source-observed:
What the paper actually reported.

Local inference:
Why the mechanism might transfer to this project.

Local observation:
What the project's own implementation or experiment measured.

这种区分很重要，因为论文中报告的结果并不自动成为同一方法在不同代码库、数据集、样本类型、设备或实验室环境中也有效的证据。

没有足够文献支撑的想法仍然可以探索，但必须将其标记为第一性原理假设，而不是作为已发表的结论来呈现。

各阶段不必严格按顺序运行。

当候选方案 N 正在执行时，独立的车道可以准备后续工作：

Execution lane:
Test candidate N.

Literature lane:
Investigate mechanisms for candidate N+1.

Brainstorming lane:
Adapt those mechanisms to local constraints.

Review lane:
Check whether the benchmark or experimental comparison remains fair.

如果用户允许 subagent，独立 Agent 可以拥有这些车道。如果 subagent 不可用，主 Agent 可以交错执行同样的工作。

已准备好的研究不能替代当前解决方案，直到该候选方案有自己的执行证据、审计、解释和裁决。

每个被评估的候选方案最终都有且仅有一种裁决：

PROMOTE — 通过门槛，成为新的最优方案；

RETAIN — 有价值作为替代方案，但不替换最优方案；

REVISE — 机制仍然合理，有限的下一个测试有边界；

REJECT — 证据与候选方案矛盾，或未通过硬性约束；

INCONCLUSIVE — 现有证据不足以做出有效决策。

候选方案不能仅因为实现看起来合理就获得正面裁决。

Skill 首先要求：

审计指标、基线和混淆因素；

第一性原理解释；

与用户确认的门槛进行比较。

我还希望最终的解释超越对编辑文件的总结。

对于软件项目，Skill 追踪实际的实现路径：

Input
→ entry point
→ changed function
→ downstream state transition
→ measured output
→ performance or complexity effect

它解释成本来自哪里，哪些假设是必要的，存在哪些边缘情况，以及为什么观察到的指标应该发生变化。

对于非代码项目，如工程或生物工作流，它遵循相应的协议和数据流：

Sample or input
→ preparation
→ intervention
→ measurement
→ calibration
→ decision rule
→ reported metric

这使得该 Skill 可以用于软件开发之外的领域。只要项目有可衡量的目标和安全的验证路径，它就可以支持工程、数据分析、算法和研究工作流。

工作流维护一份实时的 Markdown 账本：

docs/automation-exploration.md

账本包含冻结的契约、候选方案状态、活跃车道、证据、审计结果、解释、裁决和恢复状态。

它复用项目原生的测试、基准、分析输出或实验记录，而不是为每个候选方案创建单独的报告目录。

一个无依赖的 Python 辅助工具强制执行候选方案生命周期，并防止在执行、评审和解释完成之前记录裁决。

Automation Exploration Pro 不需要另一个 Skill 来进行文献发现或第一性原理解释。

它的代码库包括：

完整的操作协议；

基于项目的文献工作流；

第一性原理关闭方法；

可恢复的账本模板；

状态管理辅助工具；

测试和详细的跨领域示例。

它使用宿主环境中可用的任何普通搜索、浏览器、学术索引、PDF 阅读、编码和执行工具。

克隆代码库：

git clone https://github.com/fancheng5840074-bit/automation-exploration-pro.git

将 Skill 复制到 Codex Skill 目录：

mkdir -p ~/.codex/skills

cp -R \
  automation-exploration-pro/skills/automation-exploration-pro \
  ~/.codex/skills/

重启或刷新 Codex，然后显式调用它：

Use $automation-exploration-pro to explore several
research-backed solutions for this project.

Use $automation-exploration-pro in cyclic optimization mode
to improve this baseline.

这个 Skill 不能保证每个项目都有更好的解决方案。

它不会将论文结果转化为本地证据，也不会隐藏失败的实验。如果没有候选方案通过已确认的门槛，正确的结果是“没有推广的候选方案”。

目标不是制造成功。目标是使探索更加系统化、可重复、可解释，并对不确定性保持诚实。

Automation Exploration Pro 采用 MIT 协议发布。

我特别欢迎以下方面的反馈：

文献到本地适配的工作流；

性能和复杂度门槛设计；

跨阶段 Agent 并发；

证据评审和裁决语义；

传统软件项目之外的应用。

如果这个工作流看起来有用，你可以在这里找到源代码、安装说明、测试和两个详细示例：

👉 Automation Exploration Pro on GitHub

欢迎提交 Issue 和贡献。