为什么我选择 Codex-first，而不是一开始自建 Agent Runner

我选择 Codex-first，不是因为 Codex 是终点，而是因为它是现实入口。

做 AI-native 工具时，很容易陷入一个误区：既然我要治理 agent，那我是不是应该先做一个自己的 agent runner？

我的答案现在越来越明确：不应该。至少不应该一开始就这样做。因为用户已经在真实工具里工作，尤其是 Codex Desktop、Codex CLI、Claude Code 这类 coding agent 环境。

IntentDNA 的早期价值，应该是让这些真实入口变得更可治理，而不是要求用户放弃它们。

生产力工具的迁移成本，比技术架构图里看起来更高。

一个人习惯了某个 coding agent 的交互方式、快捷键、审批模型、文件浏览、终端集成和上下文处理，迁移到新 runner 并不只是换 UI。

如果我要求用户为了 IntentDNA 换入口，就等于把“治理价值”绑定到“迁移成本”。这会让一个本来应该轻量进入工作流的东西，变成沉重的平台替换。

所以更现实的策略是：先在用户已有入口旁边建立治理层。

自建 runner 会过早吞掉核心精力。

一个生产级 runner 要处理工具、沙箱、权限、上下文、状态、记忆、错误、验证、trace、UI、部署和安全。每一项都很深。

如果 IntentDNA 早期把这些全部自建，最容易变成另一个半成品 agent framework。它会消耗大量精力，却未必证明最核心的理论：组织意图能否跨 harness 编译。

我更愿意把自建 runner 推迟到有足够 workflow、adapter 和证据之后。

adapter-first 是更符合 IntentDNA 本质的路线。

IntentDNA 的核心是治理语言和编译层。那它最早应该证明的不是“我能跑 agent”，而是“我能把同一套意图映射到不同 agent 运行面”。

Codex-first adapter 可以先回答一些关键问题：AGENTS.md 能承载哪些软约束？哪些权限只能靠外部 guard？哪些行为无法硬拦截？如何记录 RuntimeDecisionEvent-compatible evidence？

这些问题比自建一个漂亮 runner 更接近真实价值。

Codex-first 也是我的 dogfood 路线。

我自己就在使用 Codex 推进项目、文章、页面和验证。这意味着 Codex-first 不是抽象选择，而是我的真实工作面。

把 IntentDNA 先适配到我自己的工作流，能更快发现治理语言哪里有用，哪里只是概念。

dogfood 的好处是残酷：如果一个规则让我自己都觉得累，它很可能不是好设计；如果一个 workflow 真能提升我的交付，它就有机会成为产品资产。

Codex-first 不等于 Codex-only。

我选择 Codex-first，不代表 IntentDNA 只服务 Codex。相反，它是为了更稳地走向跨 harness。

等 Codex adapter 把 contract、unsupported、evidence 和 dogfood 跑通，再接 Claude Agent SDK、OpenAI Agents SDK、LangGraph 或内部 runner，才有更强的比较基础。

长期看，IntentDNA 的价值不在某个单点 adapter，而在所有 adapter 共享同一套治理语言。

这些判断背后有清晰的行业信号。

我引用这些来源，是为了把个人判断放回更大的市场、资本和工程实践背景里。它们共同指向一个趋势：AI 的竞争点正在从“模型调用”转向“工作系统设计”。