Agent 架构 on Codexer

给 AI 装上记忆系统：Wienerdog 如何用纯文件让 Codex 变得更聪明

Sun, 09 Aug 2026 09:00:00 +0800

你有没有过这样的经历：每天早上打开 Codex CLI，敲下第一行指令，它就像第一次见到你一样，对你的项目结构、编码习惯、偏好设置一无所知。你不得不重复描述上下文，重新解释需求，花掉宝贵的 Token 和时间，只是为了让它"想起来"昨天你们一起写到哪里了。

这不是你的问题，也不是 Codex 的 bug。这是当前所有 AI 编程 Agent 的结构性缺陷：它们是无状态的。每次会话结束，记忆清零。下一轮对话，从零开始。

最近 Hacker News 上一个叫 Wienerdog 的开源项目引起了我的注意。它用一个极简的思路解决了这个问题：不改变 AI 模型本身，而是在它周围安装正确的文件。 9 分投票，2 条讨论，不算爆款，但它背后的架构哲学值得每个重度 AI 编程用户琢磨。

核心洞察：装对文件，AI 自己就变聪明了

Wienerdog 的 GitHub README 第一句话就点明了产品假设：

You already pay for a great AI model. Wienerdog makes it feel dramatically smarter, not by changing the model, but by installing the right files around it.

翻译过来：你已经为顶级 AI 模型付了钱。Wienerdog 让它感觉上聪明得多，不是靠改模型，而是靠安装对的「周边文件」。

什么样的文件？一个真实的个人档案、一份持续更新的 Markdown 记忆库、一组针对你重复性任务的技能文件，再加上一个每天晚上自动运行的「做梦」流程，它会回顾当天的对话，提炼重要信息，更新长期记忆。

设计哲学是纯文件的：没有守护进程，没有服务器，没有遥测。没有任何东西在监听，没有任何数据传回远程。wienerdog uninstall 会删除它写过的每一个文件。这个设计原则贯穿始终。

架构揭秘：不是应用，是「编译器 + 提示词」

Wienerdog 对自己的定位很有意思：「一个编译器加上一组提示词，不是一个应用。」目标代码量控制在 ~4000 行纯 Node.js，除了 Google API 库之外零运行时依赖。

不到 1MB 的 Codex：MicroCodex 如何用 C++ 重新定义编程 Agent

Fri, 07 Aug 2026 09:00:00 +0800

如果你用过 OpenAI 的 Codex CLI，你大概有过这样的体验：装一个 codex 需要先搞定 Node.js 运行时，然后 npm install 拉下来几百个依赖包，node_modules 动不动就几百 MB。每次启动，V8 引擎先预热，模块再加载，你好不容易等到提示符出现，已经过去了十几秒。

这不是 Codex 的问题，这是整个 JavaScript 工具链的通病。但当你的日常工作是靠编程 Agent 来提高效率时，这个"启动税"就开始让人难受了。

最近，一位名叫 Paolo Anzani 的开发者做了一个大胆的尝试：用 C++23 重写整个 Codex CLI，编译出来的二进制不到 1MB。项目叫 MicroCodex，上周在 Hacker News 上获得不少关注。

这不仅仅是"用 C++ 重写"的技术练习。MicroCodex 的设计背后，折射出对 AI 编程工具本质的一些有趣思考。

1MB 的野心：从 Node.js 到原生二进制

先看一组对比。Codex CLI 的安装流程是：确保 Node.js ≥ 18 → npm install → 等待几百个包下载 → 完成。而 MicroCodex 的安装是：

curl -fsSL https://github.com/paoloanzn/microcodex/releases/latest/download/install.sh | sh

一条命令，下载一个预编译的静态链接二进制，放到 $PATH 里，结束。没有运行时依赖（Linux 上需要 libcurl 和 OpenSSL，这几乎是任何系统的标配），不需要包管理器，不需要任何语言生态。

我们搞定了 Prompt Cache，流水线反而更慢了：Codex App-Server 的四个反直觉真相

Thu, 06 Aug 2026 09:00:00 +0800

你跟同事聊 Codex 的性能优化时，有没有听过这句话？

「你每次都 spawn 一个新的 codex exec 干嘛？直接跑个 app-server 复用线程啊，光 prompt cache 就值回票价了。」

听起来太对了，对到没人会去质疑。开一个常驻服务进程，预热几条线程，所有请求走同一个会话，cache 命中率拉满，token 消耗直接腰斩，对不对？

我们团队也是这样想的。然后我们测了四次。

结果是：prompt cache 最终打到了 86% 的命中率，但流水线比最朴素的基线更慢，原始 token 消耗反而多了 39%。

这篇文章讲的就是为什么，以及 app-server 到底是为谁设计的。

背景：两种运行模式

Codex CLI 有两种运行模式，很多人分不清它们的适用场景：

codex exec：每次调用启动一个独立进程，执行完就退出。没有状态，没有记忆，每次都是「从头来过」。
codex app-server --stdio：启动一个常驻服务进程，通过 JSON-RPC 协议维持长连接。可以创建线程、复用上下文、支持中断和恢复。

从表面上看，app-server 显然是更「高级」的选择。进程复用省启动时间，线程上下文省 token，还有一套完整的会话管理协议（thread/list、thread/resume、thread/fork、turn/interrupt）。

但表面正确不等于实际正确。

实验设计：公平对比

我们的实验设计刻意保持了公平性。不搞连接池，不搞常驻守护进程。app-server 为每个 formation 私有启动、跑完所有 turn 后立即销毁，生命周期跟 codex exec 子进程一模一样。

这样对比的只有一件事：复用同一个线程到底能不能省钱省时间？

在正式测量之前，我们先写了一个探针程序去直连真实的 app-server，验证了八个关键行为，顺手挖出了三个文档里没写但会坑死你的细节：

cwd 和 sandboxPolicy 是粘性参数。如果你不每个 turn 显式传一遍，turn 3 会悄悄继承 turn 2 的写权限。
token 用量上报在 thread/tokenUsage/updated 事件上，不在 turn/completed。等 turn 结束再去读，永远晚一步。
空线程不会被物化。一个从未跑过任何 turn 的线程，你无法恢复它。线程池预热是个陷阱。

然后探针跑了一个简单的两轮对话，turn 2 报告了 15,104 个缓存的输入 token。Cache 管用！赶紧上线！

深入理解 Codex 嵌入架构：App Server 与 SDK 双路径解析

Wed, 05 Aug 2026 09:00:00 +0800

你跟同事聊 Codex 的时候，有没有过这种体验？你说「我用 Codex 写了个脚本」，「我用 Codex 审查了 PR」，他说「我在 VS Code 里用 Codex 重构了模块」。听起来都是 Codex，但背后走的路径完全不同。

你用的是 CLI，他是 IDE 插件，运维那边用 codex exec 跑 CI，平台组在往自己的产品里嵌入 Codex SDK。七种入口，七种交互方式，但底层跑的是同一套东西：一个 Agent 循环。

这篇文章把 Codex 的嵌入架构从里到外拆开：先从 Agent 循环讲起，然后看 Sandbox 和 Approval 两个关键控制点，最后深入 App Server 协议和两个 SDK 的本质差异。读完你就知道什么时候该用 SDK，什么时候必须直接上 App Server。

Codex 的七扇门

先看全局。Codex 的入口可以分成三类：

交互式入口（给人用的）

CLI：在终端里直接跟 Codex 对话，检查代码、做修改、跑命令，沙箱和审批策略按会话配置。
IDE 扩展：支持 VS Code 和 JetBrains，直接把打开的文件和选中内容送进 Prompt，就地审查修改，还能把长任务丢到云端。
桌面应用：2026 年 7 月 9 日起合并进了 ChatGPT 桌面应用，像一个指挥中心，可以同时管理多个项目和 Agent。
Codex Cloud：完全跳过你的本地机器，在隔离的云端环境里执行任务。你可以从网页、GitHub、Linear 或 Slack 派发任务，等结果就行。

编程式入口（用来集成和构建的）

代码即工具：为什么让 AI Agent 写代码比给它一百个工具更聪明

Thu, 23 Jul 2026 09:00:00 +0800

你用 Codex 写过一个稍复杂的任务吗？配置数据库、查 API、处理 CSV、发通知。如果你装了五个 MCP 服务器，每个暴露十几个工具，模型还没开始干活，光读懂这些工具的描述就烧掉了上万 Token。更要命的是，它还得在几十个相似的工具名之间反复推敲，“query_database” 和 “db_query” 到底是不是同一个东西？

这是当前 Agent 架构里一个被严重低估的问题：工具箱越膨胀，模型越糊涂。

工具箱悖论：工具越多，效率越低

Agent 的工具生态正在经历一场军备竞赛。一个 MCP 服务器提供 12 个工具，下一个提供 30 个。加上 CLI、沙箱、数据库、CRM、浏览器，模型要花大量上下文窗口来学习接口，而不是完成任务。

有人做过估算：40 个常驻工具的 schema 描述，光 JSON 定义就能吃下约 12,000 Token。这还没算工具之间的语义重叠带来的认知负担。模型需要推断 search_repo 和 find_repository 是不是同一个东西，create_issue 的参数格式跟 open_ticket 有什么不同。

第一代 Agent 确实需要显式的工具，那时候模型还不够可靠，上下文窗口也小，每个操作都需要紧耦合的护栏。但现在已经不一样了。前沿模型在一件事上练得极其出色：写代码。

代码模式：给模型一个它本来就会的界面

“代码模式”（Code Mode）的核心思想很简单：不要给模型一堆它需要重新学习的工具接口，给它一个类型安全的执行环境，让它写代码。

具体怎么做？你不再定义 tool_create_database、tool_query_database、tool_insert_record 三个独立工具。你暴露一个 Database 类型，它有 create()、query()、insert() 方法。模型自己写代码调用它们。

这看起来只是换了一种调用方式，但实际影响是质变的：

并行不再是奢望。 三个工具调用需要三次模型往返，但一段代码可以同时发起三个请求，在 JavaScript 里就是三行 await Promise.all([...])。

中间结果不用全塞进上下文。 一个工具调用返回 20MB 的 API 响应，如果直接塞给模型，Token 账单立刻爆炸。但一段代码可以先过滤出关键的 10 行，把剩下的写到磁盘，只把精华返回给模型。

控制流回到代码手里。 分支、循环、异常处理、重试，这些是编程语言的基本功。但在工具调用模式里，每一个分支都需要模型重新决策一次。代码模式让所有这些逻辑在 TypeScript（或 Python）里确定性执行，模型只需要做一次决策：写什么程序。