6 篇文章带有标签 “codex”

基于 deepseek-ai/deepseek-harness（TypeScript / Cordis 插件总线）与 openai/codex（Rust / codex-rs crate 体系）两个成熟开源项目的真实源码整理。 本文把每层的关键数据结构、控制流、不变量讲清楚，并为每个核心模块附上实现逻辑——这些是写 Agent 时真正会踩坑的地方。 所有 代码路径 均为实际文件，可下钻核对。伪代码为便于阅读对真实实现做了抽象，但结构与关键分支与源码一致。

0. 先定位：Agent 是什么

Agent = 以 LLM 为决策核心、以 Tool 为手、以 Sandbox 为边界、以 Append-Only 会话日志为记忆的闭环。

两条跨实现的底层信条：

1. 会话日志是模型上下文的唯一真相（model-visible ⟺ logged）。 任何进模型请求的内容都必须能从日志重建。
2. 能力是可替换的 seam。 模型、工具、文件系统、沙箱都通过接口/adapter 解耦。

分层总览

基于 deepseek-ai/deepseek-harness（TypeScript / Cordis 插件总线）与 openai/codex（Rust / codex-rs crate 体系）两个成熟开源项目的源码与架构文档整理。 目标：用「分层 + 核心模块详解」的方式，把一个 Agent 讲清楚。

0. 先定位：什么是 Agent

一个 Agent 本质上是一个以 LLM 为决策核心、以工具为手、以沙箱为边界、以会话日志为记忆的闭环系统：

• 它接收用户意图（自然语言 / 注入上下文）；
• 把意图和环境信息组装成模型上下文，向 LLM 发请求；
• 解析 LLM 返回的「思考」与「工具调用」；
• 在受控环境里执行工具（读文件、跑命令、改代码）；
• 把结果写回会话日志，再驱动下一轮，直到任务完成。

无论 TS 还是 Rust 实现，所有 Agent 的模块都收敛到同一组子系统。下面按自底向上的依赖顺序分成 7 层。

分层总览

1. 项目概述

• 项目：openai/codex —— OpenAI 的本地编码 Agent（Codex CLI）
• 核心定位：在用户本机运行的编码智能体，支撑三种宿主形态：终端 TUI、IDE 插件（经 app-server）、非交互 exec 模式
• 代码规模：Rust workspace 含约 90–115 个 crate（codex-rs/Cargo.toml），crate 统一以 codex- 前缀命名；另有 codex-cli（Node 包装层）与 sdk/
• 主要语言：Rust（核心）+ TypeScript（CLI 分发包装）
• 构建系统：同时使用 Bazel（根目录 MODULE.bazel）与 Cargo workspace

设计哲学（见 codex-rs/docs/protocol_v1.md）是：Core 引擎与 UI 解耦 —— "Codex runs locally, either in a background thread or separate process"，并通过一对队列 SQ（Submission Queue，UI→Core） 与 EQ（Event Queue，Core→UI） 通信。任何 UI（TUI、桌面 App、IDE 插件、MCP 客户端）都可驱动同一个 Core。

关键抽象

通过 2026 年 git 提交历史记录，分析 Peter Steinberger (steipete) 开发 OpenClaw 的工作流程及 Agent 编码秘诀。

关键洞察总结

AI 是放大器，不是替代品

AI 的作用：

• ✅ 做人类不想做的重复工作（去重、重构）
• ✅ 快速覆盖大量代码（3天1400次提交）
• ✅ 标准化和系统化（按模板提交）

人类的作用：

• ✅ 创造性工作（新功能）
• ✅ 质量把关（代码审查）
• ✅ 决策和发布（版本管理）

可借鉴的经验

经验	说明
人机分工	人类做 creative，AI 做 repetitive
明确周期	人类开发期 → AI 重构期 → 人类收尾期
标准化	AI 喜欢模板，建立标准流程
小步快跑	每个阶段有明确目标，快速迭代

一、提交统计概览

总提交数: 8443 次提交在两个月内

峰值日产量:

• 2026-02-22: 578 次提交
• 2026-02-15: 478 次提交
• 2026-02-16: 472 次提交

提交类型分布:

fix:     1557 (26%)
test:     815 (14%)
docs:     857 (14%)
refactor: 308 (5%)
feat:     363 (6%)
chore:    352 (6%)
style:    134 (2%)
build:     21 (0.3%)

二、工作流程核心模式

1️⃣ "Land #PR" 工作流

Peter Steinberger (OpenClaw 的创造者) 分享了核心主张 “拒绝套路，直接对话”。他认为当前的 AI 智能体（尤其是 GPT-5-Codex）已足够强大，无需过度依赖 RAG、复杂的子智能体或繁琐的规格文档等“炒作”手段。

最近我在这里变得安静了许多，因为我正埋头于最新的项目。Agent 智能体工程（Agentic engineering）已经变得如此强大，以至于现在它几乎包揽了我 100% 的代码编写。然而，我看到仍有许多人在解决问题时，还在搞那些华而不实的复杂套路，而不是专注于把活干完（Getting sh*t done）。

这篇文章的灵感部分来自昨晚在伦敦参加的 Claude Code Anonymous 交流会，部分原因是从我上次更新工作流以来已经过了“AI 领域的一年”（实际才几个月，但变化巨大）。是时候同步一下进度了。

所有的基本理念仍然适用，所以我不会再提上下文管理等简单的事情。你可以阅读我的 《AI 开发最佳工作流》 作为入门。

背景与技术栈

我独立工作，当前项目是一个约 30 万行代码（LOC）的 TypeScript React 应用，包含 Chrome 扩展、CLI、基于 Tauri 的客户端以及基于 Expo 的移动端。我使用 Vercel 托管，一个 PR（拉取请求）大约在 2 分钟内就能交付新版本网页进行测试。

Peter Steinberger (OpenClaw 的创造者) 分享了他在使用 AI 智能体构建软件方面的最新经验，特别是关于如何以推理速度交付代码，以及他对模型（如 GPT 5.2 和 Opus）的看法。

自五月以来的变化

“氛围编程”（Vibe Coding）在今年取得的进步令人不可思议。大约在五月份时，我对某些提示词（prompts）能直接生成可运行的代码感到惊讶，而现在，这已经成了我的预期。我现在的代码交付速度快到不真实。从那时起，我消耗了大量的Token。是时候更新一下心得录了。

这些智能体（Agents）的工作方式很有趣。几周前有人争论说，为了感受糟糕的架构，人必须亲手写代码，使用智能体会导致脱节——我完全不同意这种观点。当你花足够多的时间与智能体合作，你就会准确地知道某件事应该花多少时间。当 codex 回来时如果未能一次性解决问题，我立刻就会产生怀疑。

我能创建的软件数量，现在主要 受限于推理时间 和 硬核思考。坦率地说——大多数软件并不需要硬核思考。大多数应用只是把数据从一个表单搬运到另一个表单，也许存进某个地方，然后以某种形式展示给用户。最简单的形式是文本，所以默认情况下，无论我想构建什么，它都始于 CLI（命令行界面）。智能体可以直接调用它（CLI）并验证输出——从而闭环。

模型转变

真正解锁像工厂一样构建软件能力的，是 GPT 5。