AGENT ENGINE SURVEY

把几套 Agent 引擎摊开看

这页只回答一个问题： 这些项目里，Codex 到底是从哪里进来的，谁握着主循环， 事件又被翻成什么样子。

READING MAP

先看四个判断

LITELLM 外口统一

harness 对外说一种流。Codex、Claude 等在里面各跑各的。

AGENT-KANBAN 看板派活

daemon 从卡片取任务。runtime 选 Codex 时才进入 Codex provider。

HERMES 自己就是 agent

Hermes 有自己的 session、tools、MCP、Kanban。Codex 是其中一种后端选择。

TOBATSU 保留原生能力

Engine Adapter 收口。Codex 还能走 appserver fork，再 CLI resume。

LAYER VIEW

谁握着主循环，一眼分清

PROJECT CONTROL ADAPTER / PROVIDER RUNTIME OUTPUT LiteLLM agent-kanban Hermes Tobatsu InsForge harness session runTurn(prompt) provider.createRuntime codex/index.mjs @openai/codex-sdk startThread Claude stream-json 外面只看这一种 daemon 取卡 taskRunner providers/registry codexProvider.execute @openai/codex-sdk start / resume AgentEvent 写回卡片状态 Hermes session tools / MCP / Kanban runtime_provider openai-codex responses 或 app-server 可切换 Hermes event/state 自己维护上下文 run / ask / continue workflow run Engine Adapter launch / resume / fork native CLI Codex appserver fork run events + resume token fork 后继续跑 外部 agent Claude / Codex MCP / CLI / Skills 工具入口 后端资源 DB / Auth / Storage 不是 agent engine 不启动 Codex 蓝框是最关键的接入点 这段和 Codex 最相关

真正要看的不是“支不支持 Codex”，而是谁在做 agent 的主循环。 LiteLLM、agent-kanban 把 Codex 当后端；Hermes 自己跑 agent； Tobatsu 让 native CLI 保持主角。

LITELLM DETAIL

LiteLLM：Codex 被包成 provider

CLIENT 外部调用 prompt HARNESS session.mjs provider.createRuntime CODEX PROVIDER createRuntime() new Codex(options) SDK @openai/codex-sdk startThread RUNTIME Codex runtime CLI/native RUN TURN runTurn() runStreamed(prompt) EVENTS ThreadEvent Codex 原始事件 TRANSFORM transformation.mjs event -> frame WIRE OUT stream-json frame Claude 风格外口 LITELLM OPTION 如果配了 LiteLLM API base/key baseUrl -> Codex CLI openai_base_url LITELLM_API_KEY -> OPENAI_API_KEY

LiteLLM 的重点是“外口像一种协议”。Codex 不是被重写了， 只是被 provider 包住，然后事件被翻成 harness 想要的形状。

AGENT-KANBAN DETAIL

agent-kanban：卡片派给 Codex provider

BOARD 任务卡 runtime=codex DAEMON scheduler claim / run REGISTRY getProvider(codex) claude/codex/gemini CODEX PROVIDER execute(opts) buildPrompt SDK Codex SDK start/resume LOCAL CHECKS resolveCodexPath() auth / sessions / model cache THREAD runStreamed() ThreadEvent MAP EVENTS mapThreadEventStream ThreadEvent -> AgentEvent STATE taskRepo 更新 log / status / token WHAT IT HAS Codex 支持 start 和 resume send(): "multi-turn send not implemented"

agent-kanban 的核心不是 Codex 本身，而是“任务卡如何被机器接走”。 Codex 只是 provider registry 里的一个选项。

HERMES DETAIL

Hermes：自己跑 agent，Codex 是可选后端

SURFACES CLI / Web / ACP prompt AGENT CORE Hermes session history / state RUNTIME PICK runtime_provider provider=openai-codex DEFAULT codex_responses Hermes 仍跑 agent OPTION codex_app_server turn 交给 Codex TOOLS MCP / toolsets Hermes 自己调工具 KANBAN goal / card / swarm Hermes 内部能力 ACP fork_session Hermes 会话 fork OUTPUT Hermes state 不是 Codex session 原样外露 这里最容易混：ACP 的 `SessionMode` 是编辑批准策略，不是 Kanban 的 `goal_mode`。 goal_mode / kanban card / /goal loop 是另一套；Codex runtime switch 又是另一套。

Hermes 比较像“自己有完整 agent，再选择模型和 runtime”。 所以它和 LiteLLM、agent-kanban 的 provider 包装不一样。

INSFORGE DETAIL

InsForge：它不是跑 agent 的地方

AGENT OUTSIDE Claude / Codex agent 自己跑 ENTRY MCP Server tool calls ENTRY CLI + Skills terminal commands INSFORGE 后端资源面 不是 agent loop Database Auth / Storage Functions Model Gateway 所以 InsForge 的“支持 Codex”不是启动 Codex。 它让 Codex CLI 或 Claude Code 通过 MCP/CLI 拿后端能力。

这类项目可以借鉴工具面和资源面，但不能拿来对比 agent runtime。 它服务 agent，不替 agent 跑。

TOBATSU COMPARE

Tobatsu：你现在这套不是没有 Adapter

USER ACTION run / ask / continue 工作流入口 ENGINE ADAPTER LegacySubprocessEngineAdapter profile 决定命令 NORMAL build_launch_command RESUME build_resume_command ASK / FORK build_inquiry_or_fork NATIVE CLI claude / codex / ... NATIVE RESUME codex exec resume ID - CODEX FORK appserver thread/fork EVENTS parse_activity_events 日志和状态 RUN RECORD resume_token session_strategy PLAIN WORDS 你现在不是没 Adapter。 只是 Adapter 后面保留的是各家 CLI/native 能力。 蓝框：Tobatsu 比较特别的地方

所以现在的问题不是“要不要有 Engine Adapter”。 你已经有了。真正的取舍是：以后要不要再多一层 SDK provider 接法。 这不是今天必须改的事。

CODE REFERENCES

源码定位，方便回头查

LiteLLM
入口

`src/lite-harness-sdk/server/session.mjs` 调 `provider.createRuntime()`。

Codex

`providers/codex/index.mjs` 里 `new Codex()`、`startThread()`、`runStreamed()`。

agent-kanban
入口

`packages/cli/src/providers/registry.ts` 注册 `codexProvider`。

Codex

`providers/codex.ts` 里 `startThread()` / `resumeThread()`，输出 `AgentEvent`。

Hermes
入口

`hermes_cli/runtime_provider.py` 解析 `openai-codex`。

Codex

`codex_runtime_switch.py` 切 `auto` / `codex_app_server`。

Tobatsu
入口

`engine_profiles.py` 的 Adapter 负责 launch / resume / fork。

Codex

`codex_appserver.py` 调 `thread/fork`，`subprocess_runner.py` 再 CLI resume。

最短结论： LiteLLM 和 agent-kanban 是“把 Codex 包成可插拔后端”； Hermes 是“自己跑 agent，再选择 Codex 相关后端”； Tobatsu 是“保留 CLI/native 能力，由 Adapter 收口”。