只需要 Codex CLI 和正在运行的 Docker Engine。首次验证不需要其他依赖。
公开容器已发布 linux/amd64 与 linux/arm64 两个平台。
在 Apple Silicon 上,请在下方命令的镜像名前加 --platform linux/amd64:
arm64 标签目前带的是 x86-64 原生模块,受治理工具在该架构上会加载失败
(见 #190)。
默认路径不会读取 Provider Key;除非另行提供明确、受限的真实 Provider 授权,
Chat 始终使用确定性的本地 Fake Provider。
步骤 01 / 注册
添加固定版本的 MCP Server。
在终端执行下面的命令。-- 后面的内容,就是 Codex 建立 MCP
连接时启动的 stdio Server 命令。
codex mcp add unified-ai-system -- docker run --rm -i ghcr.io/happy520ai/unified-ai-system/mcp-server:0.8.0
在启动新会话前,先确认 Codex 保存了预期的镜像和参数:
codex mcp get unified-ai-system --json
同一个仓库还附带 SKILL.md:除了 MCP 服务器,也可以把操作说明作为技能装进 agent。下面这条就是 README 里写的命令,这里重复一遍,读到这一页的人不必再去别处找:
npx skills add happy520ai/unified-ai-system --skill unified-ai-gateway --agent codex --copy --yes
步骤 02 / 检查
重启 Codex,确认 15 个工具。
注册完成后打开一个新的 Codex 会话,在终端界面运行
/mcp verbose。连接应显示以下 15 个工具:
gateway_health、gateway_readiness、gateway_prompt_enhance、gateway_prompt_enhance_llm、gateway_chatagent_governance_status、agent_governance_list、agent_governance_describeknowledge_readiness、knowledge_retrieveworkflow_health、workflow_actions、workflow_runworkforce_health、workforce_agents已经打开的 Codex 会话不会热加载刚注册的 MCP 定义,因此重启会话是安装步骤的一部分。
步骤 03 / 验证链路
先增强需求,再验证 Chat 执行证据。
把下面的内容作为普通 Codex Prompt 发送。它会先证明提示增强没有调用 Provider,再检查安全边界并调用 Gateway Chat。
先使用 gateway_prompt_enhance 把“帮团队做一个小型 API”整理成编程提示词,并证明没有调用 Provider;然后检查网关健康状态和就绪状态,只有网关明确证明处于纯 Fake 模式时,才通过 Gateway Chat 发送 MCP_READY。报告 Provider、Model、执行模式和响应。
连接成立
Codex 能完成 MCP initialize、tools/list 和 tools/call。
纯 Fake 模式
网关明确报告本地 Fake Provider 和 Fake 执行模式。
自动清理
受管网关与容器会跟随 MCP 会话一起停止。
证据边界
准确理解这次测试证明了什么。
成功运行可以证明:Codex 已加载 stdio Server,受管网关通过健康边界, 已发布的 Fake Provider 路径返回了响应;同时可以使用无需 Provider 的提示 增强,并读取 Agent 治理、Knowledge、Workflow 和 Workforce 的只读检查面。
诊断 / 卸载
让安装过程始终可检查、可撤销。
如果看不到 Server,先确认 Docker,再检查保存的 MCP 定义,并在重新启动
Codex 后使用 /mcp verbose。
docker info
不再使用时可以直接移除。下一个 Codex 会话将不再启动该 Server。
codex mcp remove unified-ai-system
更多安全任务见源码快速上手; 已发布包的元数据可在官方 MCP Registry 条目中独立核验。