Codex on 鬼哥的空间

别再只会提示词了：下一代程序员要会设计 Agent 循环

Wed, 17 Jun 2026 00:00:00 +0000

你以为 AI 编程的下一步是“写出更好的 prompt”？可能错了。

Addy Osmani 最近在 X 上写了一篇长文：Loop Engineering。他的判断很直接：你不应该再只是提示 coding agent，而应该设计会提示 agent 的循环。

这句话听起来像一句漂亮口号，但背后其实是 AI 编程工作流的重心迁移：从“人坐在驾驶位，一轮一轮指挥模型”，变成“人设计一个小系统，让它发现任务、分配任务、验证结果、记录状态，然后继续下一轮”。

Prompt engineering 还没死，但它不再是杠杆最大的位置

过去两年，我们跟 coding agent 协作，大概是这个姿势：

1
2
3
4
5
6


我写 prompt
 -> agent 生成代码
 -> 我读结果
 -> 我补充上下文
 -> agent 再改
 -> 我再验

这当然有效。到今天为止，直接提示 agent 依然是最高性价比的日常操作。

但它有个天花板：你始终是循环里的调度器。任务从哪里来、下一步做什么、做完怎么验、失败怎么记、明天怎么接着跑，全都靠你脑子里那条线牵着。

Addy 说的 loop engineering，本质上是把这条线从你的脑子里拿出来，做成外部系统：

1

发现任务 -> 分配执行 -> 隔离改动 -> 独立验证 -> 记录状态 -> 决定下一步

Prompt 还是存在，但它被放回了一个更大的机器里。你不再只是写一句话让 agent 干活，而是在设计 agent 干活的方式。

一个 Agent loop 至少需要五个零件

Addy 把这个循环拆成五个核心零件，再加一个外部记忆层。

零件	作用	没有它会怎样
Automations	定时发现任务、触发运行	每次都要人手动想起要检查什么
Worktrees	让多个 agent 并行但互不踩文件	并发一开，代码库变事故现场
Skills	固化项目知识和工作约定	每次会话都从零猜你的项目习惯
Plugins / Connectors	接入真实工具和数据源	agent 只能在文件系统里自言自语
Sub-agents	拆分执行者和验证者	写代码的人顺手给自己打满分
Memory	记录已做、待做、失败和下一步	模型每轮都忘，循环无法延续

这几个词看起来像产品功能列表，但组合起来才是重点。

单独看，automation 只是定时任务；worktree 只是 Git 技巧；skill 只是文档；connector 只是 MCP；sub-agent 只是多开一个模型。

但放在一起，它们变成了一种新的工作单元：不是一个 agent，而是一条可以重复运行的工程流水线。

Automations 是心跳：它让循环真的会“再来一次”

循环和一次性任务最大的区别，不是复杂度，而是有没有心跳。

没有 automation，你只是今天心血来潮跑了一次 agent。
有 automation，它明天还会来，后天还会来，出事时会把结果丢进你的 inbox。

Addy 举的例子很具体：

每天做 issue triage
总结 CI 失败
写 commit briefing
找出最近引入的 bug
定时运行某个 skill，而不是粘贴一大坨 prompt

这里的关键不是“自动化很酷”，而是任务发现被系统化了。

很多工程工作其实死在第一步：不是没人会修，而是没人持续看。CI 偶尔红一次、issue 堆一点、依赖慢慢旧一点、代码质量每天滑一点。人类对这种缓慢腐蚀很迟钝，循环不会。

Worktrees 是并行的刹车系统

只要你让多个 agent 同时改同一个 repo，最先坏掉的通常不是模型能力，而是文件冲突。

两个 agent 同时改同一个文件，本质上和两个工程师同时改同一段代码一样：不是不能做，而是你必须有隔离边界。

Git worktree 的价值就在这里。每个 agent 在自己的 checkout、自己的 branch 里工作，改动不会直接踩到另一个 agent 的现场。

这让并行从“看起来很爽”变成“至少机械上可控”。

但别高兴太早。worktree 解决的是文件层面的碰撞，不解决人的 review 带宽。

你可以同时开 5 个 agent，但如果你只能认真 review 1 个 PR，那么系统吞吐量的瓶颈仍然是你。并行不是免费午餐，它只是把瓶颈从执行转移到判断。

Skills 是意图的缓存

我越来越觉得，skill 最被低估的地方不是“复用提示词”，而是它把项目里的隐性规则变成了显性资产。

每个成熟项目都有一堆口头约定：

这个目录不能乱动
这个测试必须先跑
这个 API 不能破坏兼容性
这类 UI 不能做成营销页
我们上次踩过这个坑，所以现在不这么写

如果这些东西只存在于人的脑子里，agent 每次进来都会重新猜一遍。猜对了叫聪明，猜错了叫事故。

Skill 的意义是把这些判断写在外部，让 agent 每次运行都能读到。

这也是 loop engineering 里很关键的一点：循环要长期跑，就不能每次都重新理解世界。 它需要一套可积累、可维护、可版本化的项目知识。

Connectors 让循环碰到真实世界

一个只能看本地文件的 agent，能做的事很有限。

真正有用的 loop 往往要碰到真实系统：

GitHub issue 和 PR
Linear / Jira ticket
Slack / 飞书通知
CI 日志
数据库查询
线上监控
staging API

这就是 connector 的位置。MCP 这类协议的价值，不只是“让 agent 多几个工具”，而是让 loop 能把状态从真实工作流里拿进来，再把结果写回去。

差别很大：

普通 agent	Loop + connectors
“我建议你这样改”	直接开 PR
“这个 issue 可能相关”	自动链接 ticket
“CI 好像失败了”	读取日志、定位原因、发修复分支
“你可以通知团队”	CI 绿了以后发 Slack

前者是助手，后者更像一个后台工作人员。

Sub-agents：不要让写代码的人当唯一裁判

在无人值守循环里，最危险的一句话是：“看起来完成了。”

模型很擅长把自己刚刚做的事解释得很合理。它写了代码，它也知道自己想表达什么，所以它很容易忽略读者、测试、边界条件和真实需求。

所以 loop 里最值得花 token 的地方，往往是 maker / checker 分离：

1
2
3


Explorer 负责读上下文
Implementer 负责改代码
Verifier 负责按 spec 和测试挑刺

Verifier 不一定总是另一个大模型。能用确定性检查的地方，应该优先用测试、lint、type check、schema validation。

但只要涉及模糊质量，比如架构是否过度、文案是否误导、交互是否符合用户习惯，一个独立的 sub-agent 就很值钱。

循环越自动化，验证越不能省。 因为你不在现场时，错误也会自动化。

Memory 是循环的脊柱

Addy 在文里提到一个看起来很朴素、但非常重要的东西：外部记忆。

它可以是一个 Markdown 文件，也可以是 Linear board，甚至是一个很普通的状态表。关键是它必须活在单次对话之外。

原因很简单：模型会忘，repo 不会；聊天会结束，文件还在。

一个长期运行的 loop 至少要记住：

昨天发现了什么
哪些任务已经尝试过
哪些方案失败了
哪些检查通过了
哪些问题需要人类决策
下一轮应该从哪里继续

没有这个状态文件，所谓 loop 只是每天重复失忆。
有了它，agent 才能在多次运行之间接力。

这也是我觉得很多 AI 自动化项目跑不久的原因：大家拼命优化 prompt，却没有给系统一个可靠的记忆脊柱。

一个真实 loop 可以长什么样

把这些零件拼起来，一个早晨自动运行的 coding loop 大概长这样：

1
2
3
4
5
6
7
8
9


每天 9:00 automation 启动
 -> 调用 triage skill
 -> 读取昨天 CI、issues、recent commits
 -> 把发现写入 state.md 或 Linear
 -> 对值得处理的问题创建 worktree
 -> sub-agent A 起草修复
 -> sub-agent B 按项目 skill 和测试验证
 -> connector 创建 PR / 更新 ticket / 通知频道
 -> 未处理事项回到 triage inbox

你实际设计的是一条小型生产线。

最有意思的是，人类的工作没有消失，而是换了位置。你不再逐步提示每个 agent，而是在设计：

哪些任务值得自动发现
哪些检查必须硬性通过
哪些情况要中断给人
哪些状态要写下来
哪些权限不能交出去

这不是“少干活”那么简单。它更像从写脚本的人，变成设计操作系统的人。

Loop Engineering 的风险：你会更快地失控

Addy 的文章里有个很重要的提醒：这东西还早，而且 token 成本、质量下降、slop 都是真问题。

我会把风险拆成三类。

第一，验证风险。
没有可靠 verifier 的 loop，只是在自动制造自信的错误。

第二，理解债务。
loop 帮你产出越快，如果你不读、不理解、不复盘，你和代码库之间的距离就会越拉越大。

第三，认知投降。
最舒服的姿势是“让它跑吧”。但如果你只是为了逃避判断而设计 loop，它会把你的懒惰放大成系统性风险。

这就是 loop engineering 比 prompt engineering 更难的地方：prompt 错了，通常只坏一次；loop 错了，会重复坏。

Takeaway：先设计循环，再让 agent 跑

我觉得 Addy 这篇长文最值得带走的，不是某个工具功能，而是一种工作顺序：

先定义循环要解决什么问题。
再决定它如何发现任务。
给每个执行单元分配隔离环境。
把项目知识写成 skill。
用 connector 接入真实工具。
用 verifier 或 sub-agent 检查结果。
把状态写到对话之外。
最后才是：让 agent 开始跑。

换句话说，不要一上来就问“我该怎么 prompt 它”。先问：这个循环的输入、状态、验证、退出条件和人工接管点在哪里？

Loop engineering 不是把工程师拿掉。恰恰相反，它要求工程师更像工程师：少一点临场催促，多一点系统设计；少一点“帮我改一下”，多一点“这条生产线为什么可信”。

Build the loop. Stay the engineer.

参考资料

ai-convo-exporter：别让 AI 对话死在终端里

Fri, 08 May 2026 00:00:00 +0000

你每天和 AI 讨论架构、修 bug、拆任务，最后这些高价值判断都去哪了？

大概率是：死在终端日志里。

这有点荒谬。我们愿意把代码提交到 Git，把笔记放进 Obsidian，把文档同步到云端，却经常把最密集的工程思考过程留在 ~/.codex 和 ~/.claude 这种“存在但不会再看”的角落里。

所以我做了一个小工具：ai-convo-exporter。

问题不是“没有记录”，而是“记录不可用”

Codex 和 Claude Code 其实都会保存对话。

Claude Code 的记录大致在：

1

~/.claude/projects/**/*.jsonl

Codex 的记录大致在：

1
2


~/.codex/sessions/**/*.jsonl
~/.codex/archived_sessions/*.jsonl

问题是，保存了不等于可复用。

这些 JSONL 原始 transcript 对机器友好，对人不友好。你想找“上次那个 ads-attribution 项目里，我和 Codex 讨论 Diana UI 怎么启动来着”，通常不会去翻一堆 UUID 文件。更现实的情况是：重新问一遍 AI，重新烧一遍上下文，重新踩一遍坑。

我想要的是另一种形态：

需求	直接翻原始日志	导出到 Obsidian
按项目查找	很难，要理解工具内部目录规则	直接按 project 文件夹
全文搜索	可以 grep，但体验粗糙	Obsidian 原生搜索
跨机器复用	路径不同，容易散	vault 同步即可
保留原始记录	有，但不适合阅读	Markdown + raw JSONL 双份保存
后续再加工	成本高	frontmatter + tags + Dataview

这就是 ai-convo-exporter 的核心目标：把 AI 对话从“工具内部状态”变成“个人知识资产”。

它怎么组织你的对话？

工具的设计原则很简单：按项目，而不是按 AI 工具。

因为你真正关心的不是“这条对话来自 Codex 还是 Claude Code”，而是“它属于哪个项目”。同一个项目里，今天可能用 Codex 查代码，明天用 Claude Code 写实现。最后应该沉淀到同一个知识空间里。

导出后的目录长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Obsidian Vault/
 AI Conversations/
 Projects/
 luoli523__ads-attribution/
 _index.md
 sessions/
 2026-05-08 0947 codex 019e0544 保存对话.md
 2026-04-27 1621 claude fd7d3855 实现 FxRate.md
 raw/
 codex/
 019e0544-7beb-7983-a458-de94206793f8.jsonl
 claude/
 fd7d3855-0b5d-482d-a008-0827ab6cd875.jsonl

这里有一个小细节：项目文件夹不是直接用本机绝对路径。

如果一个项目有 git remote，工具会优先用 remote path 做稳定 ID，比如：

1

git@github.com:luoli523/ads_attribution.git

会被转换成：

1

luoli523__ads-attribution

这样换一台机器，即使 checkout 路径从 /Users/li.luo/dev/git/... 变成 /Users/foo/code/...，同一个项目仍然会进入同一个 Obsidian 文件夹。

每篇笔记都不是纯文本，而是可查询对象

每段对话会生成一篇 Markdown，开头带 frontmatter：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


---
type: ai-conversation
provider: codex
session_id: 019e0544-7beb-7983-a458-de94206793f8
project: luoli523/ads_attribution
project_slug: luoli523__ads-attribution
created: 2026-05-08T09:47:14+08:00
cwd: /Users/li.luo/dev/git/ads_attribution
git_repo: https://github.com/luoli523/ads_attribution
git_branch: main
machine: macbook
raw_transcript: ../raw/codex/019e0544-7beb-7983-a458-de94206793f8.jsonl
tags:
 - ai/conversation
 - provider/codex
 - project/luoli523__ads-attribution
---

这让它不只是“看起来像笔记”，而是能被 Obsidian、Dataview、搜索和标签系统继续使用。

比如你可以查：

最近一周我在哪些项目里大量使用了 Codex？
某个项目里 Claude Code 和 Codex 分别处理过哪些任务？
哪些对话发生在某台机器上？
哪些讨论和某个 git repo 或 branch 有关？

AI 对话一旦结构化，就不只是聊天记录，而是工程过程的审计日志。

安装方式：checkout 后一条命令生效

我不想为这个工具引入复杂依赖，所以它只使用 Python 标准库。

安装方式：

1
2
3


git clone https://github.com/luoli523/ai-convo-exporter
cd ai-convo-exporter
./install.sh --vault "$HOME/Documents/Obsidian Vault"

安装脚本会做几件事：

动作	文件
写本地配置	`~/.config/ai-convo-exporter/config.json`
安装命令包装器	`~/.local/bin/ai-convo-exporter`
添加 Claude Code Stop hook	`~/.claude/settings.json`
添加 Codex Stop hook	`~/.codex/hooks.json`
启用 Codex hooks	`~/.codex/config.toml`

后续每次 Codex 或 Claude Code 对话结束，Stop hook 会自动调用：

1
2


ai-convo-exporter hook --provider codex
ai-convo-exporter hook --provider claude

安装是幂等的。重复执行 ./install.sh 不会不断追加重复 hook，这一点很重要。配置工具最怕“装一次能用，装三次变成玄学现场”。

历史记录也能补导入

如果你已经用了很久 Codex 或 Claude Code，可以执行：

1

ai-convo-exporter backfill

它会扫描默认位置：

1
2
3


~/.claude/projects/**/*.jsonl
~/.codex/sessions/**/*.jsonl
~/.codex/archived_sessions/*.jsonl

然后批量导入到 Obsidian。

如果你想先看看当前配置是否正确：

1

ai-convo-exporter doctor

典型输出类似：

1
2
3
4
5
6
7


Config: /Users/li.luo/.config/ai-convo-exporter/config.json
Vault: /Users/li.luo/Documents/Obsidian Vault
Conversations dir: AI Conversations
Timezone: Asia/Singapore
Claude settings: /Users/li.luo/.claude/settings.json
Codex hooks: /Users/li.luo/.codex/hooks.json
Codex config: /Users/li.luo/.codex/config.toml

我真正想保留下来的不是“答案”

很多人把 AI 对话当成一次性问答：问完、复制、结束。

但在编程场景里，真正有价值的往往不是最终答案，而是中间过程：

这个方案为什么被放弃？
当时为什么选这个目录结构？
某个 bug 的根因是怎么定位出来的？
哪个测试失败暴露了真实问题？
我是怎么让 Agent 从错误方向回来的？

这些内容如果不沉淀，会变成一种很可惜的损耗：你花钱、花 token、花时间训练出来的上下文，只活了一次。

ai-convo-exporter 解决的不是“备份聊天记录”这么小的事情。它更像是在给个人开发工作流补一个缺口：让 AI 协作过程变成可检索、可复盘、可迁移的工程资产。

适合谁用？

如果你只是偶尔问 AI 一个命令怎么写，这个工具可能没那么必要。

但如果你有下面这些习惯，它会很有用：

用 Codex 或 Claude Code 深度探索项目
让 AI 帮你做架构决策和代码审查
经常跨多个项目切换
多台机器同时开发
已经在用 Obsidian 管理长期知识
想复盘自己和 AI 协作的工作方式

一句话：当你的 AI 对话已经有复用价值，就值得被当成知识来管理。

Takeaway：把 AI 对话纳入你的知识系统

如果你想试用，只需要三步：

clone 仓库：git clone https://github.com/luoli523/ai-convo-exporter
安装 hook：./install.sh --vault "$HOME/Documents/Obsidian Vault"
可选补导入：ai-convo-exporter backfill

以后每次 Codex 或 Claude Code 对话结束，它都会自动进入 Obsidian。

这件事的收益不是第一天就爆炸，而是一个月后你搜索某个项目时，突然发现：原来那些曾经散落在终端里的判断、踩坑和上下文，现在都回来了。

参考资料

GitHub 仓库：luoli523/ai-convo-exporter
Codex Hooks 文档：OpenAI Codex Hooks
Claude Code Hooks 文档：Claude Code Hooks
Obsidian Dataview：Dataview Plugin