用 Agent 编程，但我为什么这么累？
用 Agent 编程，但我为什么这么累？
经常看到有人这样吐槽，我自己的体验也是如此，经常感觉用 Coding agent 写了一下午，精疲力尽，但是成果并不显著。
本文写一下我的看法，以及分享我在探索这个问题时做的开源 AI 助手 Pot。
先用最直白，最不绕弯子的话来解释为什么
总是有一些重复的细节习惯要去指引 AI
比如我会要求 AI 在单独 worktree 和 branch 进行开发，以及每次开发前让 main 分支同步 upstream，然后让 AI 在测试后 open pr。
Codex 可以记住这个需求，在下次处理时默认按照这样的流程。但是有时换会话，或者在上下文压缩后，有概率不会自动遵循这个习惯。Codex 现在把新 worktree 做到打开会话的工作流中了，能够解决 worktree 这个特定的问题。但是其他的细节还是需要每个会话都去明确要求 AI。
这种小细节可能让人类来判断的话几秒钟就可以处理，但是反反复复的进行会占用人的精力，让人感觉不耐烦。
逐渐的在 AGENTS.md 中写入一些明确场景的处理方式能解决此类问题，但是对于非个人项目，不方便去改 AGENTS.md 的话，暂时没找到特别好的办法。
没有对齐需求
每个人对需求的理解有偏差，这个理解由个人的品味，知识，和近期的思考上下文有关。前几年常见的梗就是老板和设计师之间互相说不通，老板会站在设计师后面指挥，按钮向左边挪两个像素。 现在来看这个梗是不是就很像在指挥 AI 干活一样。我们最终还是需要和 AI 对齐细节部分。
我来应对这个问题的方法就是做之前只进行概念上的对齐，减少细节层面的对齐。
比如做 agent 连接系统和 context 时，直接参考 codex 结合自己的需求，让 agent 生成一个 ascii 架构图。然后根据架构图进行对齐。
如果是 UI 开发就更方便了，可以直接让 agent 参考具体的 app 的界面(不要道德审判，AI 本来就是无数无版权数据训练出来的，如果你的目的是做有自己 idea 的东西，我认为就没必要有心理负担)。
无法生成想要的代码
这个问题最好的应对方式就是不追求代码细节。
Pot 项目的开发就是先用架构图对齐，然后让 AI 生成后自动 open pr 并附带上具体实现的 ascii 架构图和 UI 截图。这样可以保证我只看 pr 介绍就能确认实现的大方向是否有偏差，以及具体的 UI 是否是我想要的，如果架构图没什么大问题就直接合并，偶尔扫一眼代码。如果有细节问题，就再次询问 AI 要求解释并修改。
这些方法对于个人项目很有效，至于需要追求代码质量的公司项目则没什么太好的方法，还是需要人工核对代码。
至于如何提升代码质量，答案就是等更新的大模型发布，让他重构一遍就行了。
Pot AI 助手
我总结解决以上问题的核心思路就是如下两点：
- 把人的介入限制在高层面，能不插手就不插手，放弃在每个细节把控，把控的细节越多效率越低，只把控结果。
- 让 Agent 能逐渐有能力按照用户偏好去处理一些事情，Agent 能多处理一些，用户的效率就会提升一些。
总而言之，这些问题都可以用任意的 agent or harness 来解决，但是我希望以我的视角来推出一个 AI 助手，Pot 就是以这两点为核心思想设计的。
我认为目前来看助手型的 AI 是比较好的解决方案，聊天这种异步沟通方式很适合在不需要用户介入时免打扰。 而且助手天然就是持续会话，自然可以积累用户习惯的指令，记忆系统也容易从助手对话中提取出用户偏好。
至于自动化，助手的形式也很适合，从小龙虾时代最经典的用例就是定时整理最新的资讯。 而 Pot 设计时也重点考虑了这个场景，举个例子:
我们可以新建一个用来运维项目的助手，让这个助手每天去线上的服务检查日志中的异常问题并自动打开 Issue 并启动多个任务去检查 Issue 并修复打开 Pr。然后让另一个开发助手来进行 review 并自动合并，更新部署。助手间的沟通，定时任务，外部 Github 的通知，这些都由 Pot 打通，助手可以根据指令来判断该做什么。
注意我们使用了几个不同的助手，这些助手会长期维护自己的会话，因此用户指令以及习惯都会沉淀在会话记忆中。而每个助手只负责一个场景，那么它的上下文对于该场景理论上会更有用，不会积累很多无关的上下文。
Pot 的起因来源于 ChatGPT Dot，Dot 让我意识到现在的模型已经可以支撑起比小龙虾时更有用的 AI 助手了。可能我们又会回到养小龙虾的时候。
想要避免精疲力尽，我们可以培养一个 AI 助手来帮我们抽鞭子。
- Pot 官网：https://pot.jjylab.com/
- GitHub：https://github.com/jjyr/pot