gnhf介绍

这个项目与我之前一直提到的点：睡前规划任务，睡醒后起床验收！，非常契合！

项目地址：https://github.com/kunchenguid/gnhf

它的安装和使用方式非常简单：

1
2
3
npm install -g gnhf

gnhf --agent=codex "<prompt>"

运行数据

当你指定好任务运行后，它会在.gnhf/runs/xxxx文件夹下生成运行数据，大概有以下文件：

  • base-commit，运行任务前的git commit id
  • gnhf.log，自己的运行日志
  • iteration-x.jsonl，codex exec的原始输出
  • notes.md，记录了每轮迭代的情况、结果
  • output-schema.json，没啥用
  • prompt.md，该任务的原始prompt

prompt的最佳实践

就像我之前在b站视频里提到过的，这种长时间运行任务，为了防止模型在运行时跑偏，我们给它的prompt最好满足两个条件：

  1. 清晰的执行路线：告诉模型应该以什么方式完成这个任务
  2. 明确的验收标准：怎么样就算这个任务完成了

（PS：截止目前，codex 5.5模型对于部分复杂任务的执行，即使上述的两个条件都不满足，它也能很好的完成，当然，我们抛开最强模型不谈，其它模型建议还是满足上述的两个条件）

成功案例：精简代码

prompt很简单：

1
请你在不改变现有架构的情况下，精简GhostVMAgent的代码

效果：

我的评价：

虽然prompt没有经过优化，但整体效果还是不错的，把很多重复代码都重构的很好，比较差强人意的点在于，会存在过度优化的问题。

整体运行的效果和我敲shell命令跑while循环去调用codex是一样的。

翻车案例一：与主控结合，task_id与step发生漂移

当我尝试与zhukong skill结合时，意外发生了，ghnf从架构层面不支持这样做。

prompt：

1
2
<task_description_prompt>
请你使用主控模式来做这一点，保持task_ID不变，每一轮都是一个step。"

结果：

对于主控模式来说，每一轮迭代的task_id都不一样，这并不是由于模型智能程度不够没有遵守我的prompt，而是ghnf架构层面无法做到！

原因：

gnhf每轮都会重新调用一次codex exec，它只把原始目标、迭代次数、以及.gnhf/runs/<runId>/notes.md这个文本记忆传进去。

它没有一个结构化的“跨迭代主控任务状态”契约，也不会替内层主控固定 TASK_ID/RUN_ID/STEP_ID。所以主控层每轮都像重新接到一个任务，只会靠 notes 和 prompt 猜“现在是第几步”。

解决方案：

显式指定task_id与step_id，如以下prompt：

1
2
<task_description_prompt>
请你使用主控模式来做这一点，固定使用当前 `.gnhf/runs/<runId>` 中的 `<runId>`为task_id和run_id，每一轮迭代都是一个step，请从当前提示中的 `This is iteration N` 读取轮次 N，并使用 `step_id = S<N>`

翻车案例二：补充README文档

睡觉前，我下了如下prompt:

1
完善每个模块的README.md以及AGENTS.md、更正错误/漂移文档内容

睡醒看到：

卧槽，天塌了！！！

每个文件夹下，都多了一个AGENTS.md和README.md。

翻车案例三：简单任务无限迭代

为了测试这个场景，我进行了如下prompt:

1
请你使用python写一个快速排序算法

没有设置终止条件的情况下，跑了5个小时：

一共就写了两个文件，其中核心代码243行，测试代码2298行：

把日本的工匠精神发挥到了极致，牛逼！！！

gnhf不足

  • 1、默认情况下，任务会无限迭代运行下去，即使它是一个很简单的任务，所以使用时最好带上类似--max-iterations参数
  • 2、正如上述提到的翻车案例，gnhf每一次迭代都缺乏全局性内容，涉及到隐式信息传递的，一定要在prompt里讲清楚。
  • 3、note.md会无限制叠加下去，如果任务所需的迭代次数确实比较多的情况下，所花费的token可能是倍数级别增长，因为每一轮迭代中的prompt都会要求LLM读取note.md。