OpenAI Codex Harness 源码解剖:它与 Codex CLI 到底是什么关系
OpenAI 最近开始频繁使用一个容易引起误解的词:Codex harness。 它不是一个需要单独安装的新产品,也不是 Codex CLI 改了名字。OpenAI 给出的最小定义是:harness 是围绕模型运行的执行系统,负责保存会话状态、组织工具循环、执行命令、施加 sandbox 与 approval 策略,并把过程事件交给上层界面。Codex CLI 则是这套系统最早、最直接的终端产品形态,同时也是它的发行入口和源码宿主。 因此,两者最准确的关系不是“同一个东西”,也不是“前端和后端”这么简单,而是: Codex CLI 包含并暴露 Codex harness;harness 可以脱离 TUI,被 codex exec、App Server、SDK 和其他 Codex 客户端复用。 这个判断可以同时解释几个看似矛盾的事实:为什么 OpenAI 会说 harness “通过 Codex CLI 暴露”,又说它驱动 Codex App、IDE 与 Web;为什么开源仓库叫 openai/codex,官方文档却称其中一部分为 Codex Core;为什么 TypeScri...
DeepSeek Harness:为什么插件机制比流程编排更像运行时
DeepSeek Harness(dsh)最值得研究的,不是它又接入了多少模型、工具或界面,而是它改变了 Harness 的架构主语。 传统工作流把任务图放在中心:节点做什么,边通向哪里,失败后重试还是补偿。许多 Coding Harness 也有插件、Hook、MCP 和扩展包,但 Agent Loop、会话状态与工具分发通常仍由一个固定运行时掌握。 DeepSeek Harness 选择了另一条路。模型适配器、工具注册表、Session Log、Agent Loop、Workflow Engine、沙箱、存储和 UI 都进入同一套插件装配与生命周期机制。Workflow 没有消失,它只是从架构中心降为一项可选能力。 这形成了一个很实用的判断: 流程图回答“下一步执行什么”,插件树回答“运行时由什么组成”。 两张图可以叠在一起,却不能互相替代。 本文以 2026-08-21 的官方源码快照 b150a55 为基线。项目在 2026-08-24 仍标注为 developer preview,公开 API 和插件边界可能继续发生破坏性变化。 先把两张图分开 “插件”和“流程”...
oh-my-claudecode vs oh-my-openagent:两大 Agent 编排框架深度对比与实用教程
2026 年的 AI 编程工具生态中,单模型 CLI 已不再是终点。围绕 Claude Code 和 OpenCode 两大基座平台,不仅各自拥有原生的多 Agent 并行能力,还分别涌现出 oh-my-claudecode(OMC) 和 oh-my-openagent(OmO) 两个编排插件。 本文的 OmO 部分以 2026 年 8 月 13 日能够核验的稳定版 v4.19.4 为基线。GitHub 同期已经出现 v5.0.0-beta.7,但它仍是预发布版,不能拿来替代稳定版说明。 项目在 v3.11.0 更名为 oh-my-openagent,仓库也迁到了 code-yeongyu/oh-my-openagent。命名迁移尚未把所有历史痕迹抹平:v4.19.4 的 package.json 仍以 oh-my-opencode 发布,同时提供 oh-my-openagent、omo 等命令别名。文章统一用新品牌名 OmO;安装与诊断命令使用新别名,涉及包元数据时保留旧包名,避免把兼容期写成已经彻底结束。 TL;DR:日常命令选择指南 如果你只想知道"该用哪个命...
深入 Lean 18:Lean 4 证明工程总结与路线图
本篇回顾系列的整体脉络,指出从当前知识基线出发的进阶路线,并以一个综合验证项目作为收束。 系列脉络回顾 第 01-03 篇建立工具链基础:Lake 项目结构与依赖管理(01)、term-mode 与 tactic-mode 的切换心法(02)、universe 与类型层级(03)。核心技能在这一阶段成型——配置 lakefile、读懂 InfoView 目标状态、在 term-mode 和 tactic-mode 之间做有意识的选择。 第 04-08 篇深潜 tactic 系统:核心 tactic 精讲(04)、simp 与 norm_num 重写引擎(05)、算术自动化族(06)、conv 与 calc 精确重写(07)、自定义 tactic 与宏(08)。这些工具覆盖了日常证明的绝大部分需求。 第 09-13 篇连接 Mathlib 生态:搜索技巧(09)、类型类层次(10)、端到端贡献流程(11)、拓扑与分析结构导览(12)、有限组合与数论(13)。读者到这一阶段能在 Mathlib4 上独立工作。 第 14-17 篇进入元编程领域:Expr/MVarId/MetaM 模型...
深入 Lean 17:可执行代码与 FFI
Lean 4 同时承担定理证明器与通用程序设计语言两种角色。前十六篇聚焦逻辑与证明工程;本篇转向可执行端:从 #eval 求值,到 lake build 编译本地二进制,再到通过 FFI 调用 C/Rust 代码,最后讨论影响运行期性能的属性与编译选项。 Lean 4 作为编程语言:#eval 与 IO Lean 4 的类型论本身不区分"证明代码"与"程序代码"——两者都是项(term)。运行 Lean 代码最轻量的方式是 #eval,它在编译时对表达式求值并在 InfoView 中显示结果。 123#eval 1 + 1 -- InfoView 输出:2#eval "hello".length -- InfoView 输出:5#eval List.range 5 -- InfoView 输出:[0, 1, 2, 3, 4] 涉及副作用(文件读写、网络、标准输入输出)时,表达式类型变为 IO α: 12#eval IO.println "hello from Lean"-- 输...
深入 Lean 16:用 Aesop 写声明式自动化
手动证明每一步的好处是透明可控,坏处是重复劳动积累。Aesop(Automated Extensible Search for Obvious Proofs)是 Lean 4 / Mathlib4 的声明式自动化框架:用户注册规则集,Aesop 在目标上做有界搜索,自动完成"显而易见但手写繁琐"的证明。本篇覆盖 Aesop 的规则注册、优先级系统、safe/unsafe/norm 三类规则、自定义规则集,以及与 Coq 的 auto/eauto 的设计差异。 Aesop 的基本用法 12345678import Aesop-- 标记引理为 Aesop 规则@[aesop safe]theorem and_comm_aesop : ∀ (p q : Prop), p ∧ q → q ∧ p := fun _ _ ⟨hp, hq⟩ => ⟨hq, hp⟩example (h : A ∧ B) : B ∧ A := by aesop @[aesop safe] 把 and_comm_aesop 注册为安全规则。aesop tactic 在遇到形如 _ ∧ _...
深入 Lean 15:编写 elaborator 与 command
第 14 篇展示了 tactic 如何操作 MVarId 和 Expr。本篇向上走一层:elab 不仅能定义 tactic,还能定义 term elaborator 和顶层 command。三者共享同一套 Expr 构造工具,但触发时机和返回值语义不同。 elab 的三种角色 elab 关键字根据后缀决定 elaborator 类别: 123elab "my_tactic" : tactic => ... -- 操作目标列表,无返回值elab "my_term" : term => ... -- 返回一个 Expr(证明项或值)elab "my_command" : command => ... -- 顶层副作用,无返回值 三者的 monad 环境: 类别 Monad 核心职责 tactic TacticM 消费/产生 MVarId term TermElabM 返回 Expr,可能带约束 command CommandElabM 修改环境、输出消...
深入 Lean 14:元编程模型:Expr/MVarId/MetaM
Lean 4 的 tactic 不是黑盒——每个 tactic 本质上是一段操作证明状态的程序。本篇拆解这套元编程基础设施:Expr 是表达式的内存表示,MVarId 标识待填充的证明目标,MetaM 和 TacticM 是承载副作用的 monad 栈。理解这三层之后,自定义 tactic 就不再是猜测 API 的过程。 Expr:表达式的内部表示 Lean 4 中一切类型、命题、证明项统一表示为 Expr。核心构造子(简化版): 12345678910111213inductive Expr where | bvar : Nat → Expr -- 局部绑定变量(de Bruijn index) | fvar : FVarId → Expr -- 自由变量 | mvar : MVarId → Expr -- 元变量(待填充的洞) | sort : Level → Expr ...
深入 Lean 13:有限组合与数论片段
Mathlib4 提供了一套完整的有限集合与大算子(BigOperators)机制,使得组合数学和初等数论的形式化证明可以在接近数学原文的符号层面进行。Finset 表示有限集合,Fintype 约束类型的有限性,BigOperators 引入求和与连乘的紧凑记号,Nat.Prime 与 Nat.primeFactorsList 覆盖自然数素数理论的基本引理。本篇在此基础上,进一步介绍 decide tactic 在有限域穷举中的作用,以及 Decidable 类型类的内部逻辑。 前置阅读:02 Term-mode 与 Tactic-mode 切换心法(tactic 基础);04 核心 tactic 精讲(rfl、ring、omega 等基础 tactic);05 simp 与 norm_num(自动化 tactic)。 Finset 与 Fintype Finset 的数据表示 Finset α 是 Mathlib4 中对有限集合的主要表示,定义于 Mathlib.Data.Finset.Basic: 123structure Finset (α : Type*) where...
深入 Lean 12:拓扑与分析基础结构导览
Mathlib 的分析库以 Filter 为核心抽象,在此之上叠加拓扑、度量和赋范结构,统一表达极限、连续、收敛等概念。理解这套分层设计,是读懂 Mathlib 分析证明的前提。本篇梳理 Filter、TopologicalSpace、MetricSpace 和 NormedSpace 四层结构的定义方式和证明惯用法,并通过具体可运行代码展示各层之间的关联。 前置阅读:本系列 09 Mathlib 搜索技巧、10 类型类层次、11 在 Mathlib 上证一个小定理。 Filter:分析库的基础抽象 为什么不直接用 ε-δ 经典分析教材用 ε-δ 定义极限:对每个 ε > 0,存在 δ > 0,使得……这个定义能精确刻画单个极限,但在证明库里它有两个缺陷。第一,同一个"极限"概念在不同情形(趋向实数点、趋向无穷、序列极限、网极限)下需要写出形状不同的 ε-δ 公式,导致同一条定理(如极限的线性性)在每种情形下各需一个版本。第二,组合两个极限结论时,条件匹配需要手动传递 ε/2 技巧,证明文本冗长。 Mathlib 选择用 Filter 把&quo...

