如何实现Agent长时间执行任务（三）：GPT Pro工作流

0 - 前言

自从开始一人公司后，发现要做的事情太多太多，而开发只是其中的一环。

因此，为了尽可能多的将自身从开发中抽离出来，恰好可以借着我开发新项目的机会，重新设计了一套工作流，我将其称之为：GPT Pro工作流。

本意是让GPT Pro深度参与到项目中来，让他成为技术负责人甚至是项目级别的架构师，而我作为PM以及CTO的角色与其进行合作。

1 - 认知对齐

在正式介绍这套工作流之前，先进行以下认知对齐：

1、“LLM给出看上去合理的方案，但一运行就暴露诸多不足”，这是常态，我们不应该过多的追求“让LLM一次输出就能达到预期结果”。
2、基于此，我们应该顺势而为，应该构建的系统是“如何自动化将LLM的方案的反馈作为补充从而向迫使LLM对现有的方案进行补充向正确的方向逼进”

说人话，现在AI Coding最大的瓶颈，就在于LLM给方案并执行，最终需要人工去验收。即使让LLM写大量的E2E测试脚本，也覆盖不到程序运行期间出现的问题，在这种情况下，依然需要人去观察运行中的程序、发现问题、收集日志、数据，再交给LLM进行修复、优化。

上述所提到的一个典型的例子就是“性能优化”：程序一开始运行，没任何问题，但随着时间积累，可能CPU占用率逐渐会变高、内存消耗持续存在异常，在这种情况下，需要我人工去观察，才能发现异常，发现异常后，有需要我去让AI收集所需要的数据以及信息作为上下文，再让GPT Pro去根据代码分析，给出方案…

因此，我想到一种解决方案：利用类似watch-dog的机制，通过单独的daemon程序，每秒钟对CPU、内存进行采样，一旦高CPU、高内存持续时间过久，便自动收集过去一段时间内的数据生成性能报告，并且发出通知。

通过通知机制，便可以主动触发上传性能报告，自动化让GPT Pro给出方案，自动化修复，自动化验证，自动化运行，直到下一次出现高CPU、高内存占用的情况出现，在此过程中不需要人工参与。

当然，上述提到的“性能优化”只是一种场景，根据这种思路很容易扩展到其它类似的场景，核心就在于：让程序自身产生所需的上下文，并且在异常的时候，发起通知，并附带上异常的上下文。

2 - 具体的实现方案

2-1 如何让GPT Pro成为架构师兼技术负责人？

1、创建一个ChatGPT Project。
2、确定好产品方案、技术方案、架构方案，防止后续设计走偏
3、在项目代码里创建hook文件，每当代码更新时，自动将代码打包上传至该Project里
4、在Instructions里，写清楚工作流：

## GitHub 工作流

用户要求“实现/新增/支持/优化/修复并实现 xxx”时：
1. 先用 GitHub app 创建 issue。
2. 基于需求、最新代码和 v2.2 文档写生产级实施方案与 User Story。
3. 将方案写入 issue 描述或评论。
4. 给含计划的 issue/sub issue 添加 `pro-planned`。
5. 把方案呈现给用户审阅。
6. 用户明确说“执行实施方案/开始实现/请实现/按这个做”前，不改代码、不提交 PR。

用户说“根据 issue #xx 生成实施方案”时：读取 issue、最新代码和文档；补充完整实施方案；追加到 issue；添加 `pro-planned`；向用户汇总。

用户说“执行实施方案”时：从最新目标分支创建临时分支；按方案实现；运行相关测试/构建/静态检查或说明验证；提交 commit；创建 PR。PR 必须包含关联 issue、摘要、关键文件、测试结果、风险与回滚、未完成项。不要直接向 `dev/v2_codex` 提交。

用户说“review all / review 所有 issues”时：review 所有 open 且带 `verify_done` 的 issues。通过则添加 `pro-reviewed` 并关闭；不通过则不关闭父 issue，保留标签，创建含完整实施方案的 sub issues，并给 sub issues 添加 `pro-planned`。只有所有 sub issues 关闭后，父 issue 才能关闭。

issue 带 `verify-failed` 时：读取失败原因、日志、实现和上下文；追加返工实施方案；移除 `verify-failed`；添加 `pro-rework`；若有计划则添加或保留 `pro-planned`。

2-2 如何让codex作为RD / QA？

接下来，在项目仓库里，我在workflow里创建了两个文件：

pro-planned_dev.md:找到open且包含pro-planned标签、并且不包含dev-done标签的issues，进行开发，开发完后将issue标记为dev-done。
verify_dev_done.md：找到open且包含dev-done标签且不包含verify-done活verify-failed标签的issues，进行验收，验收成功标记为verify-done，失败则标记为verify-failed。