对象明确为 OpenAI 官方开源的 openai/codex，也就是现在的 Codex CLI / Codex Harness，不是第三方 “Codex Harness” 项目。官方仓库当前是公开的 Apache-2.0 项目，主体为 Rust；仓库包含 codex-rs、CLI、app-server、skills、plugin/runtime、sandbox、MCP、SDK 等完整实现。当前 main 已经是一个非常大的代码库，GitHub 页面显示约 9,845 次提交。
下面按照前面 DSH / OpenCode / Pi / ZCode 的方式，重点做**源码能力拆解**，而不是产品介绍。尤其关注：
> Codex 到底有哪些实际能力 → 源码怎么实现 → 核心调用链是什么 → 哪些能力本质属于 Work → 哪些属于 Runtime → 哪些是 Work + Runtime 协同 → 最后哪些能力值得 ADR 吸收。
---
# OpenAI Codex Harness 源码能力分析
## 1. 先给结论
这次源码阅读之后，Codex 和前面几个项目有一个非常明显的区别：
> Codex 已经不是“Agent + 一组 Tools”这么简单，而是一个完整的 Agent Execution Harness。
它实际上已经形成：
```text
Codex Harness
│
┌─────────────────┼─────────────────┐
│ │ │
Agent Tools Runtime
│ │ │
│ ┌──────┼──────┐ │
│ │ │ │ │
Session Shell Patch MCP Sandbox
Turn Image Search Agent Exec
Context Plan UserInput Network
Memory Apps Plugins FS
│ │ │ │ │
└──────────┴──────┴──────┴──────────┘
│
Tool Orchestrator
│
Approval / Policy / Sandbox
│
Effect
```
而且最重要的是：
```text
ToolRouter
↓
ToolRegistry
↓
PreToolUse Hook
↓
ToolOrchestrator
↓
Approval / Policy
↓
Sandbox
↓
ToolRuntime
↓
Effect
↓
PostToolUse
↓
Tool Result
↓
Agent
```
这个链路已经和你们 ADR 的：
```text
Decision
→ CandidateAction
→ Authorization
→ Execution
→ Effect
→ Evidence
→ Reconcile
→ Audit
```
产生了非常强的结构对应关系。
---
# 2. Codex 的源码总结构
官方仓库顶层目前包括：
```text
codex/
├── codex-cli
├── codex-rs
│ ├── core
│ ├── core-plugins
│ ├── core-skills
│ ├── agent
│ ├── tools
│ ├── sandboxing
│ ├── execpolicy
│ ├── hooks
│ ├── codex-mcp
│ ├── app-server
│ ├── app-server-protocol
│ ├── config
│ ├── session
│ ├── rollout
│ ├── ...
│
├── sdk
├── docs
├── scripts
└── tools
```
官方仓库本身也明确把 codex-rs 作为主要实现，而不是一个简单 CLI 包装层。
因此这次不能像 ZCode 那样只研究 Plugin。
Codex 的 Harness 本身就是研究对象。
---
# 3. Codex 的真正核心不是 CLI
源码结构说明：
```text
CLI
↓
Session
↓
Core
↓
Tool System
↓
Runtime
```
而：
```text
TUI
App Server
SDK
CLI
Desktop
```
都是不同入口。
真正共享的是：
```text
codex-rs/core
```
因此：
> Core 才是 Codex Harness。
CLI 只是一个 Host。
这和你们 ADR 目前的：
```text
Core
Plugin Runtime
Work Runtime
```
划分高度类似。
---
# 4. Tool 系统的三层架构
这是这次源码分析最重要的发现之一。
Codex 明确实现了：
```text
ToolRouter
↓
ToolRegistry
↓
ToolRuntime
```
源码：
```text
core/src/tools/router.rs
core/src/tools/registry.rs
core/src/tools/orchestrator.rs
```
ToolRouter 持有：
```text
ToolRegistry
model_visible_specs
```
负责把模型侧的工具调用映射到实际 Tool。
ToolRegistry 则维护：
```text
ToolName
→
RegisteredTool
→
CoreToolRuntime
```
并支持：
```text
trusted tool
external tool
tool exposure
namespace
collision detection
parallel tool calls
tool search
```
因此：
```text
Router
=
“模型要调用哪个能力？”
Registry
=
“这个能力在哪里？”
Runtime
=
“这个能力怎么真正执行？”
```
---
# 5. Tool Exposure
Codex 不是把所有工具一次性暴露给模型。
源码中存在：
```text
ToolExposure
```
以及：
```text
deferred tools
namespace discovery
tool search
tool suggestion
```
Registry 可以发现：
```text
namespace
```
并将 deferred tools 按 namespace 聚合。
这说明 Codex 已经实现：
```text
Capability Discovery
```
而不是：
```text
全部 Capability → 全部塞进 Prompt
```
这和我们之前分析 ZCode 的 Progressive Disclosure 是同一个方向。
---
# 6. Tool Search
Codex 当前有：
```text
tool_search
tool_suggest
```
并且 Tool Registry 支持：
```text
ToolExposure::Deferred
```
源码中 tool_search 已经成为独立模块。
因此：
```text
Agent
↓
Tool Search
↓
Capability Discovery
↓
Load Tool
↓
Tool Call
```
这其实就是：
> 动态 Capability Routing。
### ADR
直接对应：
```text
Work Capability Selection
```
而不是 Runtime。
---
# 7. Shell / Exec 是 Codex 最核心的 Runtime
Codex 的 Shell 不是简单：
```python
subprocess.run()
```
而是：
```text
Shell Tool
↓
Shell Handler
↓
Shell Runtime
↓
ToolOrchestrator
↓
Approval
↓
Sandbox
↓
Process
```
源码中的 shell.rs 明确构造：
```text
ShellRequest
```
包含：
```text
command
cwd
timeout
environment
network
sandbox permissions
additional permissions
justification
approval requirement
```
然后交给：
```text
ToolOrchestrator
```
执行。
---
# 8. Unified Exec
Codex 现在还有一个更完整的：
```text
Unified Exec
```
源码：
```text
core/src/unified_exec/
```
它负责：
```text
interactive process
PTY
process reuse
output buffering
approval
sandbox
retry
```
官方源码注释直接描述：
```text
approval
→ sandbox selection
→ attempt
→ retry
```
然后：
```text
sandbox transformed ExecRequest
→ PTY
→ streaming output
```
因此：
```text
Unified Exec
=
Process Runtime
+
Interactive Runtime
+
Sandbox orchestration
```
---
# 9. Exec 的完整源码流程
可以还原成：
```text
LLM
↓
exec / shell tool call
↓
ToolRouter
↓
ToolRegistry
↓
ShellCommandHandler
↓
ShellRequest
↓
ToolOrchestrator
│
├── network approval
├── exec policy
├── user approval
└── sandbox selection
↓
SandboxManager
↓
ExecRequest
↓
Process / PTY
↓
stdout/stderr
↓
ToolEmitter
↓
Tool Result
↓
LLM
```
这不是普通 Tool。
这是完整的：
> Effect Runtime。
---
# 10. ToolOrchestrator
Codex 的 ToolOrchestrator 是整个 Harness 最值得 ADR 研究的代码之一。
源码明确写明：
> Central place for approvals + sandbox selection + retry semantics.
其核心顺序是：
```text
Approval
↓
Sandbox Selection
↓
Attempt
↓
Retry
```
并且 sandbox denial 时可以按照策略重新执行。
所以 Codex 实际上把：
```text
Tool
```
和：
```text
Execution Governance
```
分开了。
这是非常成熟的架构。
---
# 11. Approval 不是 Tool 的责任
ToolRuntime 可以提供：
```text
exec_approval_requirement()
```
但统一处理由：
```text
ToolOrchestrator
```
完成。
审批状态包括：
```text
Skip
NeedsApproval
Forbidden
```
并支持：
```text
proposed execpolicy amendment
```
这意味着：
```text
Tool
↓
声明自己的风险要求
↓
Orchestrator
↓
统一 Policy
```
而不是：
```text
每个 Tool 自己实现权限
```
---
# 12. Approval Policy
当前源码支持：
```text
Never
OnRequest
Granular
UnlessTrusted
```
并且 Granular 模式进一步拆：
```text
sandbox approval
request_permissions
rules
MCP elicitation
skill approval
```
配置 schema 对这些都有明确结构。
所以 Codex 的 Authorization 实际上已经形成：
```text
Global Policy
+
Tool-specific Requirement
+
Exec Policy
+
Sandbox Policy
+
User Approval
```
---
# 13. Exec Policy
这是 Codex 另外一个非常重要的 Runtime Governance。
独立 crate：
```text
codex-rs/execpolicy
```
其职责是：
```text
command
↓
parse
↓
rule match
↓
allow / prompt / deny
```
并且可以：
```text
proposal
→ amendment
→ future command auto-approval
```
也就是说：
> Codex 不仅有一次性的 Permission，还存在持久化的执行规则。
这已经非常接近：
```text
Policy Engine
```
---
# 14. Sandbox
Codex 的 sandbox 是独立 crate：
```text
codex-rs/sandboxing
```
核心：
```text
SandboxManager
```
源码支持不同平台的 sandbox backend。
Core 不直接把：
```text
subprocess
```
当成执行。
而是：
```text
ExecRequest
↓
SandboxManager
↓
platform sandbox
↓
process
```
这正是 Runtime Domain 的典型实现。
---
# 15. Filesystem Permission
Codex Sandbox 不是简单：
```text
sandbox = on/off
```
Filesystem 有：
```text
read
write
deny
```
而且存在冲突优先级：
```text
deny > write > read
```
因此 Runtime 的资源模型已经具备：
```text
Capability
+
Resource
+
Access Mode
```
---
# 16. Network Permission
Shell Request 中已经包含：
```text
network
```
ToolOrchestrator 还会进行：
```text
network approval
```
而 sandbox request 又携带：
```text
managed network
```
因此 Codex 把：
```text
Filesystem
Network
Process
```
作为不同 Runtime Resource。
这比简单的：
```text
sandbox=true
```
成熟很多。
---
# 17. Sandbox Retry
Codex 一个非常重要的设计：
```text
sandbox execution
↓
sandbox denial
↓
policy permits escalation?
↓
retry without sandbox
```
而不是：
```text
第一次失败
→ Tool failed
```
源码明确把 retry 纳入 ToolOrchestrator。
所以：
```text
Recovery
```
已经进入：
Runtime orchestration layer。
---
# 18. Apply Patch
Codex 有独立：
```text
apply_patch
```
handler/runtime。
源码路径：
```text
core/src/tools/handlers/apply_patch.rs
core/src/tools/runtimes/apply_patch.rs
```
Apply Patch 并不是直接修改文件。
它会经过：
```text
Patch parsing
↓
permission calculation
↓
ToolEmitter
↓
ToolOrchestrator
↓
ApplyPatchRuntime
↓
filesystem mutation
```
所以：
```text
Patch Strategy
```
属于 Work，
而：
```text
Patch Execution
```
属于 Runtime。
---
# 19. Codex 的 File Mutation 模型
因此：
```text
Agent
↓
决定修改什么
↓
ApplyPatch
↓
Authorization
↓
Sandbox
↓
File Mutation
↓
Diff Evidence
```
其中 SharedTurnDiffTracker 负责跟踪本轮修改。
这已经非常接近：
```text
CandidateAction
→ Effect
→ Evidence
```
---
# 20. View Image
Codex 有：
```text
view_image
```
独立 handler/spec。
它不是普通文件读取。
它是：
```text
Image
↓
Tool
↓
Model Context
```
即：
> 视觉 Observation Capability。
### ADR
```text
Work:
Visual analysis
Runtime:
image loading / conversion / resource access
```
---
# 21. Web Search
Codex 当前存在：
```text
web_search
web_search_request
```
以及多种 Web Search mode。
源码/配置中明确区分：
```text
disabled
cached
indexed
live
```
这说明 Web Search 不是一个简单 Tool。
它是：
```text
Search Strategy
+
Search Backend
+
Network Policy
```
---
# 22. MCP
Codex 的 MCP 不是简单把 MCP SDK 嵌进 Tool。
有独立：
```text
codex-mcp
```
模块，负责：
```text
server
runtime
connection_manager
OAuth
elicitation
resources
apps
```
而 Core 的 Config 直接维护：
```text
mcp_servers
```
因此：
```text
MCP Server
↓
Connection Manager
↓
Tool Discovery
↓
ToolRegistry
↓
ToolOrchestrator
↓
MCP Runtime
```
---
# 23. MCP Tool 最终仍进入 Tool Registry
这一点非常关键。
MCP Tool 并没有绕过 Codex Core。
它最终形成：
```text
ToolName
+
namespace
+
ToolRuntime
```
然后进入：
```text
ToolRegistry
```
Registry 对 MCP Tool 还有：
```text
mcp_server
mcp_server_origin
```
telemetry 标签。
这意味着：
> 外部 MCP Capability 被纳入统一 Tool Runtime，而不是旁路。
这与 ADR 的：
```text
Plugin A → Core → Plugin B
```
原则高度一致。
---
# 24. MCP Namespace
Codex Tool Registry 明确支持：
```text
namespace
```
同时对 external tool 做 collision detection。
默认 namespace 中甚至保留：
```text
exec_command
shell_command
```
防止外部 Tool 抢占。
所以：
```text
MCP Tool
=
External Capability
```
但：
```text
Core Tool
=
Reserved Authority Capability
```
---
# 25. MCP Elicitation
当前配置里还有：
```text
auth_elicitation
tool_call_mcp_elicitation
```
以及 Granular：
```text
mcp_elicitations
```
这意味着 MCP Server 可以在执行过程中请求用户参与。
因此：
```text
MCP Tool
↓
requires user input
↓
Elicitation
↓
Approval / User Input
↓
continue
```
这是一个完整的：
Interactive Runtime Capability。
---
# 26. Skills
Codex 有独立：
```text
codex-rs/core-skills
```
源码实现：
```text
discovery
environment
namespace
loader
```
Skill 是：
```text
Metadata
+
Instructions
+
Optional scripts
+
References
+
Dependencies
```
它不是 Runtime Tool。
它是：
> Work Capability Definition。
---
# 27. AGENTS.md
Codex 会加载：
```text
AGENTS.md
```
并支持：
```text
global
project
nested
```
不同层级。
Config loader 明确调用：
```text
AgentsMdManager::load_global_instructions
```
因此：
```text
AGENTS.md
=
Durable Work Context
```
不是 Runtime。
---
# 28. Skill Progressive Loading
Skill Loader 不是简单：
```text
all skills → prompt
```
它有：
```text
discovery
identity
metadata
load
environment
```
等阶段。
所以 Codex 和 ZCode、OpenCode 都已经形成：
```text
Capability Metadata
↓
Discovery
↓
Load
↓
Execute
```
---
# 29. Plugin
Codex 目前已经拥有完整 Plugin Runtime。
Manifest 支持：
```text
name
version
description
keywords
skills
mcpServers
apps
hooks
interface
```
源码 core-plugins/src/manifest.rs 已经直接解析这些字段。
官方内部 Plugin Spec 也明确包含：
```text
skills
hooks
mcpServers
apps
```
---
# 30. Codex Plugin 和 ZCode Plugin 的区别
ZCode：
```text
Plugin
├── Skill
├── Command
├── Agent
├── Hook
└── MCP
```
Codex：
```text
Plugin
├── Skill
├── MCP
├── App
└── Hook
```
Codex 当前 Plugin 更偏：
```text
Capability Packaging
```
而 Agent/Subagent 是 Core Agent System 自己管理。
---
# 31. Plugin Store
Codex 有：
```text
core-plugins/src/store.rs
```
负责：
```text
install
cache
uninstall
version
filesystem copy
```
因此 Plugin 已经不是：
```text
“扫描一个目录”
```
而是完整：
```text
Marketplace
↓
Install
↓
Cache
↓
Manifest
↓
Load
↓
Enable
↓
Capability Registration
```
---
# 32. Marketplace
Codex 现在有：
```text
marketplace/add
marketplace/remove
marketplace/upgrade
plugin/list
plugin/read
plugin/install
plugin/uninstall
```
App Server API 已经把这些操作暴露出来。
因此：
```text
Plugin Ecosystem
```
已经成为 Codex Harness 的正式组成部分。
---
# 33. Plugin Discovery
Codex 还有：
```text
core-plugins/src/discoverable.rs
```
用于：
```text
plugin discovery
tool suggestion
```
因此 Plugin 和 Tool Search 已经发生了连接：
```text
Agent
↓
Capability unavailable
↓
Plugin Discovery
↓
Install / Enable
↓
Capability becomes available
```
这比传统静态 Plugin Registry 更进一步。
---
# 34. Plugin Hooks
当前 main 已经把 Plugin Hooks 纳入实际 Hook Runtime。
Session 中：
```text
plugins_manager
↓
plugins_for_config
↓
effective_plugin_hook_sources
↓
HooksConfig
```
也就是说：
```text
Plugin
├── Skill
├── MCP
├── App
└── Hook
↓
Hook Runtime
```
已经形成统一链路。
---
# 35. Hook
Hook Runtime 是独立 crate：
```text
codex-rs/hooks
```
包括：
```text
registry
engine
discovery
events
command runner
```
Hook 可以进入：
```text
PreToolUse
PostToolUse
Session
Compaction
```
等生命周期。
---
# 36. PreToolUse 是一个非常重要的能力
ToolRegistry::dispatch_any_with_terminal_outcome() 在实际执行 Tool 前：
```text
pre_tool_use_payload
↓
run_pre_tool_use_hooks
```
Hook 可以：
```text
Block
Continue
Modify Input
```
源码明确存在：
```text
PreToolUseHookResult::Blocked
PreToolUseHookResult::Continue
updated_input
```
所以 Codex 允许：
```text
Tool Call
↓
Policy Hook
↓
修改参数
↓
执行
```
这已经非常接近：
> Action Interception Layer。
---
# 37. PostToolUse
Tool 完成后：
```text
post_tool_use_payload
```
会带：
```text
tool_name
tool_use_id
tool_input
tool_response
```
因此完整：
```text
PreToolUse
↓
Tool
↓
PostToolUse
```
形成了一个标准的：
Execution Middleware Pipeline。
---
# 38. Tool Event
Codex 还有：
```text
ToolEmitter
ToolEventCtx
ToolEventStage
```
这些组件负责：
```text
tool started
tool output
tool completed
tool failed
patch diff
```
等执行证据。
因此：
```text
Tool Runtime
↓
Event
↓
Observation
```
是第一等公民。
---
# 39. Memory
当前 Codex Config 已经有：
```text
memories
memory_tool
```
同时 Registry 在 Tool Output 包含 external context 时可以修改：
```text
thread memory mode
```
源码里甚至有：
```text
mark_thread_memory_mode_polluted
```
逻辑。
这说明 Codex 已经认识到：
> 外部工具结果会改变 Memory 的可信上下文状态。
这是非常值得 ADR 学习的设计。
---
# 40. Session / Thread
Codex 的：
```text
Session
Thread
Turn
```
是核心状态模型。
从 SDK 的测试可以直接看到：
```text
thread_start()
↓
turn()
↓
stream()
↓
completed
```
并且一个 Thread 可以连续执行多个 Turn，历史会保持：
```text
user
agent
user
agent
```
所以：
```text
Thread
=
长期 Work Context
Turn
=
一次 Agent Execution Cycle
```
---
# 41. Turn
Codex 的 Turn 是实际执行单位。
基本：
```text
Turn
↓
Model
↓
Response
↓
Tool Calls
↓
Tool Results
↓
Model
↓
...
↓
Final
```
因此它和 ADR 的：
```text
Work Invocation
```
非常接近。
---
# 42. Context Compaction
Codex 有：
```text
compact
new_context_window
remote_compaction
```
相关能力。
TUI 也明确提供：
```text
/compact
```
用于长对话上下文压缩。
所以 Codex 的 Context Runtime：
```text
Active Context
↓
Token pressure
↓
Compaction
↓
New Context Window
↓
Continue Work
```
这是：
Work State Recovery / Context Management。
---
# 43. Multi-Agent
Codex 当前已经有完整 Multi-Agent。
Feature：
```text
multi_agent
multi_agent_v2
collab
collaboration_modes
enable_fanout
```
源码：
```text
core/src/agent/
core/src/tools/handlers/multi_agents*
```
---
# 44. Spawn Agent
当前 Agent Tool：
```text
spawn_agent
```
可以指定：
```text
task
agent_type
fork_context
model
reasoning_effort
service_tier
```
因此：
```text
Parent Agent
↓
spawn_agent
↓
Child Thread
↓
Independent Work
```
---
# 45. Multi-Agent V2
Codex 当前不只是：
```text
spawn
```
而是完整 Agent Control：
```text
spawn_agent
send_message
send_input
wait_agent
resume_agent
list_agents
close_agent
```
这已经形成：
```text
Agent Tree
```
而不是简单 Subagent。
---
# 46. Agent Registry
AgentRegistry 维护：
```text
active_agents
agent_tree
thread_paths
nicknames
agent_role
```
并且有：
```text
total_count
```
限制。
Config 还有：
```text
agent_max_threads
agent_max_depth
agent_job_max_runtime_seconds
agent_roles
```
所以 Codex 已经有：
```text
Agent Resource Governance
```
---
# 47. Agent Depth
Codex 对 Agent Tree 有：
```text
max depth
max threads
runtime limit
```
这不是 Prompt 层面的约束。
它是 Runtime Resource Control。
所以：
```text
Agent
=
Work Entity
Agent Registry
=
Runtime Governance
```
---
# 48. Fork Context
Subagent 可以：
```text
fork_context = true
```
即：
```text
Parent Thread
↓
Fork
↓
Child Thread
↓
inherits selected history
```
这与 ADR E13/E15 的：
```text
Fork
CallerIdentity rebinding
```
有很强的对应关系。
但 Codex 重点是：
Context Fork。
ADR 重点是：
Identity + Execution Isolation。
---
# 49. Agent Communication
Codex Agent 可以：
```text
send_message
send_input
```
其中：
```text
interrupt=true
```
可以立即打断当前 Agent。
所以：
```text
Agent A
↓
Message
↓
Agent B
```
形成 Agent-to-Agent Communication。
但它不是 Plugin A 直接调用 Plugin B。
这是：
Work-level coordination。
---
# 50. Plan
Codex 有独立：
```text
plan
```
Tool/handler。
这不是普通文本。
它是：
```text
Plan State
```
Agent 可以：
```text
Plan
↓
Steps
↓
Execution
↓
Update
```
### ADR
直接对应：
```text
Work Strategy
```
---
# 51. User Input
Codex 有：
```text
request_user_input
```
Tool。
因此 Agent 在执行过程中可以：
```text
Agent
↓
uncertainty
↓
request_user_input
↓
User
↓
continue
```
这属于：
Interactive Work Control。
---
# 52. Request Permissions
另外还有：
```text
request_permissions
```
这是一个完全不同的能力。
它不是：
```text
request_user_input
```
而是：
```text
Agent
↓
needs extra resource permission
↓
request_permissions
↓
Policy / User
↓
temporary additional permission
```
官方权限 Prompt 也明确区分：
```text
network.enabled
file_system.read
file_system.write
```
以及：
```text
require_escalated
```
---
# 53. 这说明 Codex 有“双请求模型”
```text
Request User Input
=
业务问题
Request Permissions
=
资源授权
```
这是一个非常重要的架构区别。
ADR 应该保留。
---
# 54. Apps / Connectors
当前 Codex Feature 中存在：
```text
apps
connectors
enable_mcp_apps
```
以及 App Server：
```text
app/list
```
Plugin Manifest 也支持：
```text
apps
```
所以：
```text
App / Connector
=
External Capability Provider
```
和 MCP 类似，但具有更强的产品级连接器语义。
---
# 55. Browser Use
当前 Codex Feature 已经明确包含：
```text
browser_use
browser_use_external
browser_use_full_cdp_access
in_app_browser
```
因此 Codex 当前已经有：
```text
Browser Agent Integration
```
而不是单纯 Web Search。
---
# 56. Computer Use
Feature 也明确包含：
```text
computer_use
```
并且 Config Requirements 有：
```text
ComputerUseRequirements
allow_locked_computer_use
```
所以 Codex 已经开始从：
```text
Code Agent
```
扩展成：
```text
Computer Agent
```
---
# 57. Image Generation
当前 Feature 还有：
```text
image_generation
```
因此 Codex 的 Agent Capability 已经不仅是：
```text
Read / Write / Execute
```
还包括：
```text
Generate
```
这是另一个外部 Effect Capability。
---
# 58. Realtime
Config / protocol 中已经存在：
```text
RealtimeConversation
```
以及：
```text
realtime_conversation
responses_websockets
```
这意味着：
```text
Agent
↓
Realtime Session
↓
Audio / Text
```
已经进入 Codex Runtime 能力集合。
不过它不是当前 Coding Agent 主路径的核心能力。
---
# 59. Remote Control
当前 Feature 还存在：
```text
remote_control
```
以及 App Server 相关能力。
这表示 Codex 已经可以将：
```text
Thread / Agent
```
暴露给外部控制面。
从架构角度：
```text
Control Plane
```
正在从 CLI 内部扩展出来。
---
# 60. Chronicle / Goals / Memories
当前 feature model 中还存在：
```text
chronicle
goals
memories
memory_tool
workspace_dependencies
```
这些属于：
```text
Long-running Work Management
```
而不是底层 Runtime。
因此未来 ADR 如果要达到 Codex 的完整 Work 能力：
```text
Goal
↓
Work
↓
Memory
↓
Dependency
↓
Evidence
```
需要考虑。
---
# 61. Undo
当前源码 feature registry 中仍能看到：
```text
undo
```
但 features/src/lib.rs 明确标注部分旧 Feature 为：
```text
Removed compatibility flag
```
例如：
```text
JsRepl
JsReplToolsOnly
Undo
```
等。
因此不能把：
```text
config.schema.json
```
中的每一个 flag 都当成当前实际能力。
这点非常重要。
---
# 62. JS REPL
同理：
```text
js_repl
```
在当前 Feature 代码中已经标记为：
> Removed compatibility flag
所以：
不能把 JS REPL 算作当前 Codex 核心能力。
这是源码审查比产品文档更重要的一个例子。
---
# 63. 当前真正有效的能力集合
结合：
```text
handlers
runtime
features
config requirements
agent
plugins
sandbox
MCP
app-server
```
可以把 Codex 当前有效能力归纳为：
```text
A. Agent / Work
────────────────────
Planning
Goal
Turn
Session
Context
Compaction
Skills
AGENTS.md
Memory
Tool Discovery
Tool Suggestion
Multi-Agent
Agent Delegation
Agent Messaging
Agent Fork
User Input
Permission Request
Steering
Review
Verification
B. Local Runtime
────────────────────
Shell
Unified Exec
PTY
Filesystem
Apply Patch
Image View
Process
Environment
Git
Network
C. External Runtime
────────────────────
MCP
Apps
Connectors
Browser
Computer Use
Web Search
Image Generation
Remote Control
D. Governance Runtime
────────────────────
Approval
Exec Policy
Sandbox
Network Policy
Filesystem Policy
Hooks
PreToolUse
PostToolUse
Guardian
Permission Profiles
Resource Limits
E. Capability Packaging
────────────────────
Skills
Plugins
Marketplace
Plugin Install
Plugin Upgrade
Plugin Hooks
Plugin MCP
Plugin Apps
```
---
# 64. Codex 的真正核心调用链
如果把所有源码压缩成一条主链：
```text
User
↓
Session
↓
Turn
↓
Model
↓
Response
↓
Tool Call
↓
ToolRouter
↓
ToolRegistry
↓
PreToolUse
↓
ToolOrchestrator
├── Policy
├── Approval
├── Network
└── Sandbox
↓
ToolRuntime
↓
External Effect
↓
ToolEmitter
↓
PostToolUse
↓
Evidence / Telemetry
↓
Tool Result
↓
Model
```
这是 Codex Harness 最核心的架构。
---
# 65. 对 ADR 最重要的结构对应
把 Codex 与 ADR 当前语义模型对齐：
| Codex | ADR |
|---|---|
| Session | Work Context |
| Thread | Work Instance |
| Turn | Invocation / Execution Cycle |
| Agent | Work Agent |
| Tool Spec | Capability Declaration |
| Tool Registry | Capability Registry |
| Tool Router | Capability Selection |
| ToolOrchestrator | Execution Governance |
| Approval | Authorization |
| Exec Policy | Policy / Authorization Rule |
| Sandbox | Execution Domain |
| Tool Runtime | Runtime Capability |
| Tool Result | Effect / Observation |
| Tool Event | Evidence |
| PreToolUse | Pre-Execution Policy |
| PostToolUse | Post-Execution Evidence |
| Hook | Runtime Event Extension |
| MCP | External Runtime Capability |
| Skill | Work Capability |
| Plugin | Capability Package |
| Marketplace | Capability Distribution |
| Agent Registry | Agent Resource Governance |
| Compaction | Work Context Recovery |
| Memory | Work State |
| Request Permissions | Authorization Escalation |
| Multi-Agent | Work Delegation |
这个对应关系已经非常稳定。
---
# 66. 最值得 ADR 直接吸收的不是 Codex Tool
如果只看：
```text
shell
apply_patch
view_image
web_search
MCP
```
其实没什么特别。
真正值得 ADR 吸收的是：
```text
ToolRouter
ToolRegistry
ToolOrchestrator
ToolRuntime
Approval
ExecPolicy
Sandbox
Hook
Tool Exposure
Tool Search
Agent Registry
Plugin Manager
```
因为这些才组成了：
> Harness。
---
# 67. Codex 的 Tool Runtime 抽象非常重要
源码定义：
```text
CoreToolRuntime
```
它不是简单：
```text
fn execute()
```
而是附带：
```text
tool name
spec
exposure
telemetry
hooks
argument diff
parallel support
MCP metadata
```
所以：
```text
Tool Runtime
=
Execution
+
Metadata
+
Governance Integration
+
Observation
```
这个设计非常值得 ADR 参考。
---
# 68. Codex 的 External Tool 也进入 Registry
Registry 明确存在：
```text
register_external()
```
并处理：
```text
namespace
collision
reserved tool
exposure
```
所以：
```text
Built-in Tool
External Tool
MCP Tool
Plugin Tool
```
最终都能进入：
```text
Tool Registry
```
形成统一 Capability Plane。
---
# 69. 但 Governance 仍然掌握在 Core
这是 Codex 和很多 Agent Framework 的关键差异。
外部 Tool：
```text
register_external
```
不等于：
```text
external tool owns permission
```
真正执行仍经过：
```text
ToolRegistry
→ PreToolUse
→ ToolOrchestrator
→ Approval
→ Sandbox
→ Runtime
```
这与 ADR 的：
> Plugin 零治理权
非常一致。
---
# 70. Codex Plugin 的正确理解
不要理解成：
```text
Plugin
=
Tool
```
应该是：
```text
Plugin
=
Capability Package
```
里面可以放：
```text
Skill
MCP
App
Hook
```
源码 manifest 已经明确体现这一点。
---
# 71. Work / Runtime 最终分类
## Work
```text
Planning
Goal
Skill
Skill Discovery
Tool Discovery
Tool Selection
Tool Suggestion
Agent
Subagent
Delegation
Agent Messaging
Agent Fork
Verification
Review
Memory
Context Strategy
Compaction Strategy
User Interaction
Workflow
```
---
## Runtime
```text
Shell
Process
PTY
Filesystem
Patch
Image
Browser
Computer
MCP
Apps
Connectors
Network
Web Search Backend
Image Generation Backend
Sandbox
Exec Policy
Permission Runtime
Hook Runtime
Plugin Loader
Marketplace
Credential Runtime
Session Store
SQLite
```
---
## Work + Runtime
```text
Tool
MCP
Browser
Computer Use
Apply Patch
Web Search
Agent
Plugin
Skill
Memory
Multi-Agent
Permission Request
Hook
```
这些不能简单地归入一边。
---
# 72. Browser 的正确拆法
例如：
```text
Work
└── Web Investigation
├── Search Strategy
├── Page Reasoning
└── Verification
↓
Runtime
└── Browser
├── Browser Instance
├── Page
├── Navigation
├── CDP
└── Input
```
---
# 73. Multi-Agent 的正确拆法
```text
Work
└── Delegation
↓
Agent Registry
↓
Runtime
├── Thread
├── concurrency
├── depth
├── cancellation
└── lifecycle
```
所以：
```text
Delegation
=
Work
Agent Lifecycle
=
Runtime
```
---
# 74. MCP 的正确拆法
```text
Work
└── “我要调用 GitHub / DB / Browser / Search”
↓
Runtime
└── MCP Server
├── connection
├── auth
├── OAuth
├── elicitation
├── tool
└── resource
```
---
# 75. Plugin 的正确拆法
```text
Plugin
│
├── Work
│ └── Skills
│
├── Runtime
│ ├── MCP
│ └── Apps
│
└── Runtime Governance
└── Hooks
```
Plugin 本身是：
```text
Package / Distribution Unit
```
而不是执行层。
---
# 76. Codex 与 ADR 的最大相似点
这是我认为这次源码分析最值得审查组注意的地方：
```text
Codex
ADR
────────────────────────────────────────
Tool Call CandidateAction
ToolOrchestrator Authorization + Execution
Approval Authorization
Sandbox Execution Domain
ToolRuntime Runtime Plugin
Tool Result Effect / Evidence
Tool Event Evidence
PreToolUse Pre-Execution Gate
PostToolUse Post-Execution Evidence
```
这不是概念上的“看起来像”。
是源码调用链上的结构对应。
---
# 77. Codex 与 ADR 的最大差异
Codex 的中心：
```text
Agent
↓
Tool
↓
Effect
```
ADR 的中心：
```text
Decision
↓
CandidateAction
↓
Authorization
↓
Execution
↓
Effect
↓
Evidence
↓
Reconcile
↓
Audit
```
所以：
> ADR 不应该把 Codex Core 搬过来。
ADR 应该吸收的是 Codex 已经验证过的：
```text
Runtime Orchestration Pattern
```
而不是它的：
```text
Agent Product Semantics
```
---
# 78. 对你们当前 ADR 的实际价值排序
如果目标是：
> 让 ADR 拥有接近 DSH + OpenCode + Pi + ZCode + Codex 的能力
那么 Codex 这次源码分析之后，优先级我会这样排：
### P0
```text
1. Tool Registry
2. Tool Router
3. Tool Runtime
4. Tool Orchestrator
5. Approval Integration
6. Sandbox Integration
7. Pre/Post Tool Hooks
8. External Tool Registration
9. Tool Exposure / Deferred Capability
10. Multi-Agent Registry
```
### P1
```text
11. Skill Loader
12. Plugin Manager
13. Plugin Marketplace
14. MCP Runtime
15. Request Permissions
16. Agent Messaging
17. Agent Fork
18. Context Compaction
19. Memory
20. Browser Runtime
```
### P2
```text
21. Computer Use
22. Apps / Connectors
23. Image Generation
24. Remote Control
25. Realtime
26. Goals
27. Workspace Dependencies
```
---
# 79. 最终形成的 ADR 能力模型
结合 DSH、OpenCode、Pi、ZCode、Codex 五套系统，目前已经可以把 ADR 的目标能力抽象成：
```text
ADR
│
┌────────────┴────────────┐
│ │
WORK RUNTIME
│ │
┌───────┼────────┐ ┌───────┼────────┐
│ │ │ │ │ │
Agent Skill Delegation Exec MCP Browser
│ │ │ │ │ │
Plan Workflow MultiAgent Shell Apps Computer
│ │ │ │ │ │
Goal Context Messaging FS Git Network
│ │ │ │ │ │
└───────┴────────┘ └───────┴────────┘
│ │
└────────────┬────────────┘
│
CAPABILITY REGISTRY
│
CAPABILITY SELECTION
│
ADR CORE AUTHORITY
│
EXECUTION DOMAIN
│
EFFECT
│
EVIDENCE
│
RECONCILE
│
AUDIT
```
这比单纯复制 Codex 的 Tool 系统要强，因为：
Codex 把 Governance 集成进 Tool Orchestrator；ADR 可以进一步把它提升为统一 Core Authority。
---
# 80. 最终结论
这次 Codex 源码分析，我认为最重要的不是“Codex 有哪些工具”，而是下面这 8 个源码事实：
### ① Codex 已经把 Tool 分成三层
```text
Router
Registry
Runtime
```
### ② Codex 有统一的 Tool Orchestrator
```text
Approval
→ Sandbox
→ Execution
→ Retry
```
### ③ External Capability 不绕过 Core
MCP / external tools 最终进入统一 Registry / Runtime 链路。
### ④ Sandbox 和 Authorization 是两个不同维度
Codex 同时存在：
```text
Approval
Exec Policy
Filesystem Permission
Network Permission
Sandbox
```
这和你们 ADR 当前 Isolation ≠ Authorization 的设计高度一致。
### ⑤ Hook 已经进入 Tool 生命周期
```text
PreToolUse
→ Tool
→ PostToolUse
```
并且 PreToolUse 可以：
```text
Block
Modify Input
Continue
```
### ⑥ Multi-Agent 已经成为正式 Runtime
不是简单 Subagent，而是：
```text
Agent Registry
Agent Tree
Depth
Concurrency
Lifecycle
Messaging
Fork
Resume
Close
Wait
```
### ⑦ Plugin 已经成为 Capability Package
```text
Plugin
├── Skill
├── MCP
├── Apps
└── Hooks
```
### ⑧ Codex 最值得 ADR 吸收的是 Harness，而不是 Agent UI
最终可以浓缩成：
```text
Agent
↓
Capability Selection
↓
Tool Registry
↓
Policy / Approval
↓
Sandbox / Runtime
↓
Effect
↓
Evidence
↓
Agent
```
这条链与 ADR 当前的 Decision → Authorization → Execution → Effect → Evidence 主链已经高度同构。
所以到目前为止，五套系统放在一起后，我认为已经可以进入下一阶段：**把 DSH / OpenCode / Pi / ZCode / Codex 五套源码分析结果合并成一张“全能力基准矩阵”，逐项标记“已有 ADR / Work 应接入 / Runtime 应接入 / 两层组合 / 尚缺失”，用它作为后续插件接入的唯一能力清单。**