人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载install-codex是 oh-my-openagentOmO项目中专用于 Codex CLI Light 版的插件安装器它负责把omo插件及其捆绑的 Agent、MCP 清单、Hook 信任哈希与 CLI 入口完整写入用户的~/.codex/目录并同步改写~/.codex/config.toml。本文以仓库中的 packages/omo-opencode/src/cli/install-codex/AGENTS.md 为主线结合其底层实现位于 packages/omo-codex/src/install/逐阶段拆解安装流程、产物布局与设计约束读完即可理解该安装器的全部内部机制也能独立排查安装产物与卸载残留问题。一、定位一个指向规范实现的 OpenCode CLI 适配垫片文档开篇即点明这个目录的本质——它不再是独立的安装器实现而是一个 OpenCode CLI adapter shim适配垫片。真正的安装器源码被收敛到packages/omo-codex/src/install/而packages/omo-opencode/src/cli/install-codex/下的同名文件只做一件事从oh-my-opencode/omo-codex/install/install-codex与oh-my-opencode/omo-codex/install/types重新导出例如 packages/omo-opencode/src/cli/install-codex/install-codex.ts 全文只有一行export * from oh-my-opencode/omo-codex/install/install-codextypes.ts 同理。这种垫片 规范实现的双层结构让 OpenCode CLI 侧只保留命令路由入口所有安装逻辑单点维护避免双实现漂移。安装的触发方式有两种等价命令文档明确给出bunx oh-my-openagent install --platformcodex别名形式npx lazycodex-ai install入口函数是runCodexInstaller()它接收一个可选的CodexInstallOptions参数并返回CodexInstallResult这两个类型定义在 packages/omo-codex/src/install/types.ts。二、目录结构与关键文件install-codex目录内共 39 个文件文档以表格形式给出了最核心的 8 个文件及其职责这是理解整个安装器的最小清单文件职责install-codex.ts主编排器runCodexInstaller()——解析路径、遍历 marketplace 插件、驱动 cache/install/config 各阶段types.tsCodexInstallOptions、CodexInstallResult、MarketplaceManifest、PluginManifest、InstalledPlugin等类型codex-marketplace.ts读取packages/omo-codex/marketplace.json与各插件的.codex-plugin/plugin.json校验路径段codex-cache-install.ts构建源码、拷贝到临时缓存目录、执行npm ci --omitdev、改写 MCP 清单、原子提升到~/.codex/plugins/cache/{marketplace}/{name}/{version}/codex-cache-bins.ts发现package.json的bin条目把组件 CLI 链接进 bin 目录写入omo运行时包装器POSIX shell / Windows.cmdlink-cached-plugin-agents.ts发现components/*/agents/下捆绑的 Agent TOML拷贝到~/.codex/agents/保留既有model_reasoning_effort与service_tier写.installed-agents.json清单codex-marketplace-snapshot.ts把本地 marketplace 快照写入~/.codex/.tmp/marketplaces/{marketplace}/codex-config-toml.ts改写~/.codex/config.toml启用特性、写入 marketplace/plugin/agent/hook-trust 块、可选的自主任权限codex-cleanup.ts卸载编排器移除 cache、agents、config 块与项目本地残留需要提醒的是上表中的文件路径在规范实现仓库中全部位于 packages/omo-codex/src/install/ 下如 codex-cache-install.ts、codex-config-toml.ts、codex-cleanup.ts 等OpenCode 垫片目录里只有转发的薄壳阅读源码时应以omo-codex包为准。三、安装入口与配置项CodexInstallOptions 全解runCodexInstaller的默认路径解析逻辑集中在 install-codex.tsconst repoRoot resolve(options.repoRoot ?? findRepoRoot({ importerDir: import.meta.dir, env })) const codexHome resolve(options.codexHome ?? env.CODEX_HOME ?? join(homedir(), .codex)) const projectDirectory resolve(options.projectDirectory ?? env.OMO_CODEX_PROJECT ?? process.cwd()) const binDir resolveCodexInstallerBinDir({ binDir: options.binDir, codexHome, env }) const versionOverride env.LAZYCODEX_DEV_VERSION?.trim() || undefined从这段代码可以看出四个关键路径的优先级显式参数 环境变量 默认值。repoRoot安装器的工作根目录通过findRepoRoot向上最多探测 7 层父目录寻找同时满足packages/omo-codex/plugin/.codex-plugin/plugin.json存在的目录见findRepoRootFromImporter与isRepoRootWithCodexPlugininstall-codex.ts也支持用OMO_WRAPPER_PACKAGE_ROOT环境变量直接指定包装包根目录。codexHome默认为~/.codex可被CODEX_HOME覆盖所有安装产物都落在该目录内。projectDirectory项目目录默认取OMO_CODEX_PROJECT或当前工作目录用于后续项目本地 Codex 产物修复阶段。binDir由resolveCodexInstallerBinDir解析涉及CODEX_LOCAL_BIN_DIR等环境变量是组件 CLI 与omo运行时包装器的落盘位置。versionOverride开发期可用LAZYCODEX_DEV_VERSION强制覆盖插件版本号。CodexInstallOptions的完整字段types.ts如下选项类型含义codexHomestringCodex 主目录默认~/.codexbinDirstringCLI 链接目录默认由resolveCodexInstallerBinDir决定repoRootstring仓库/包装包根目录projectDirectorystring项目目录用于项目本地清理platformCodexInstallPlatform目标平台默认process.platformenv{ [key: string]: string \| undefined }环境变量快照gitBashResolverGitBashResolverWindows 下 Git Bash 解析器仅 win32 使用autonomousPermissionsboolean是否写入 Codex 自主任权限块默认true非 falsereasoningstring统一的 omo 配置推理等级覆盖捆绑目录中的model_reasoning_effortoff映射为noneastGrepInstallerRunAstGrepSkillInstallast-grep 安装器供 LSP 类技能使用runCommandRunCommand命令执行器默认为defaultRunCommandlog(message: string) void日志回调默认空操作runCodexInstaller返回CodexInstallResulttypes.tsmarketplaceName、installedInstalledPlugin[]、configPath、codexHome、gitBashPath、projectCleanup。四、安装主流程九阶段编排逐层拆解文档给出了安装流程的完整示意runCodexInstaller()的 9 个阶段与源码一一对应install-codex.tsrunCodexInstaller() 1. resolve repoRoot / codexHome / binDir / projectDirectory 2. git-bash.ts: Windows Git Bash preflight仅探测发现不自动 winget/system 安装 3. codex-marketplace.ts: 读取 marketplace.json 插件清单 4. lazycodex-version-stamp.ts: 从发行清单解析插件版本 5. 对每个 marketplace 插件 a. codex-cache-install.ts: 构建、拷贝、npm ci、改写 MCP 清单、提升到 cache b. codex-cache-bins.ts: 链接组件 CLI omo 运行时包装器 c. link-cached-plugin-agents.ts: 拷贝 Agent TOML 到 ~/.codex/agents/ 6. codex-cache-prune.ts: 清理过期插件 旧 marketplace 缓存 7. codex-config-toml.ts: 改写 ~/.codex/config.toml 8. codex-project-local-cleanup-best-effort.ts: 修复项目本地 .codex/config.toml 冲突 9. Telemetry: 记录 install_completed4.1 阶段 1-2路径解析与 Windows Git Bash 预检路径解析见上文第三节。Git Bash 预检只针对win32平台调用prepareGitBashForInstallinstall-codex.ts如果gitBashResolution.found为false安装会直接抛出带installHint的错误。值得注意的设计是预检是发现优先discovery-firstGitBashResolution的source字段标注了发现途径not-required/env/program-files/program-files-x86/path安装器只探测并报告不会自动执行 winget 或系统级安装——这是文档明确强调的边界。4.2 阶段 3读取 marketplace 与插件清单readMarketplace读取 packages/omo-codex/marketplace.json其真实内容为{ name: sisyphuslabs, interface: { displayName: Sisyphus Labs }, plugins: [ { name: omo, source: ./plugins/omo, category: Developer Tools, policy: { installation: AVAILABLE, authentication: ON_INSTALL } } ] }校验逻辑在 codex-marketplace.tsname必须是非空字符串plugins必须是数组每个插件的source支持字符串路径或{ source: local, path }对象且本地路径必须以./开头、不得包含..路径穿越段validateLocalSourcePath。validatePathSegment则用正则^[A-Za-z0-9._-]$校验 marketplace 名、插件名与版本号并拒绝.与..——这套校验直接作用于后续缓存目录的路径拼接是防止路径注入的关键一环。随后readPluginManifest读取每个插件根目录下.codex-plugin/plugin.jsonname、可选version、可选hooks并在安装器内强制校验manifest.name entry.name不一致即抛错。4.3 阶段 4版本解析与发行清单打戳resolveLazyCodexPluginVersion综合manifestVersion、marketplaceName、pluginName、发行清单distribution manifest与LAZYCODEX_DEV_VERSION覆盖值确定最终安装版本随后validatePathSegment(version, plugin version)再次校验。对sisyphuslabsmarketplace 的omo插件安装完成后还会执行stampLazyCodexPluginVersion与writeLazyCodexInstallSnapshotinstall-codex.ts并在插件根记录 binDir 位置writeInstalledCodexBinDir——源码注释解释了原因CODEX_LOCAL_BIN_DIR常是一次性覆盖one-shot override卸载时无法从环境变量重新计算该位置因此必须在安装期落盘存档。4.4 阶段 5a缓存安装——构建、拷贝、npm ci、改写 MCP 清单、原子提升这是安装器的核心阶段实现于installCachedPlugincodex-cache-install.ts构建默认先对源插件执行npm install与npm run buildmaybeRunNpmInstall/maybeRunNpmBuild均以package.json存在为前提buildSource: false时跳过构建并改为后续执行npm run sync:skills。拷贝到临时目录目标路径为{codexHome}/plugins/cache/{marketplace}/{name}/{version}临时目录是它的兄弟目录.tmp-{basename}-{pid}-{Date.now()}。拷贝时过滤掉.git、node_modules并且绝不拷贝嵌套组件里的.mcp.json——因为 Codex 只从插件根目录的.mcp.json加载 MCP 服务器嵌套清单里的相对 daemon 路径在拍平后的缓存布局中会悬空isNestedComponentMcpManifest。改写本地依赖与运行时rewriteCachedPackageLocalFileDependencies把file:本地依赖改写为缓存内路径copyBundledMcpRuntimeDists/copyRootRuntimeDists把仓库dist/cli、dist/cli-node等运行时拷入copyCanonicalPromptSources把packages/prompts-core/prompts/ultrawork/codex.md等规范提示词固化到插件根避免sync-skills在缓存布局下解析不到仓库相对路径。npm ci 依赖安装改写本地依赖会令package.json与package-lock.json漂移npm ci会以 EUSAGE 中止源码注释引用 lazycodex#137方案归功于 oh-my-openagent#6202 的社区修复因此改写过依赖 → 用npm install --omitdev --no-audit --no-fund让 npm 自行调和 lock未改写 → 走确定性更快的npm ci --omitdev。 同时sanitizeNpmInstallEnv会过滤掉npm_config_allow_scripts防止脚本执行策略被意外放宽。校验与清单改写rewriteCachedMcpManifest重写 MCP 清单、rewriteCachedManifestRoot把根路径改写为最终缓存路径assertHookCommandTargets校验 Hook 命令目标不越界assertNoRemovedSparkshellPromptReferences还会在.codex-plugin、agents、bundled-rules、hooks、skills等提示面目录中扫描已移除的 sparkshell 引用发现即中止安装。原子提升promoteDirectory采用先拷临时兄弟目录 →rename()提升 → 失败恢复备份的原子策略已有目标先改名为.backup-*提升失败则回滚备份成功才删除备份codex-cache-install.ts。4.5 阶段 5bCLI 链接与 omo 运行时包装器linkCachedPluginBinscodex-cache-bins.ts递归扫描插件根目录下所有package.json的bin字段跳过node_modules、.git、dist生成链接POSIX创建符号链接symlinkWindows写入带COMMAND_SHIM_MARKER标记的.cmdshimwindowsCommandShim。其中有一组保留名RESERVED_NESTED_BIN_NAMESomo、omo-agent-toolkit、lazycodex、lazycodex-ai、oh-my-opencode、oh-my-openagent——嵌套包非插件根声明的这些 bin 名会被跳过避免子组件抢占顶层命令名。此外 bin 目标必须解析在包根内resolvePackageBinTarget拒绝..越界与\0assertSafeCommandName则拒绝空名、.、..、路径分隔符等非法命令名。对omo插件还会额外执行linkRootRuntimeBincodex-cache-bins.ts生成omo-agent-toolkit运行时包装器POSIX 下写 shell 包装并chmod 0o755Windows 下写.cmd包装器内容带RUNTIME_WRAPPER_MARKER标记旧版omo遗留包装器会被安全移除。若仓库缺少dist/cli/index.js安装器仅记录 warning 而不会失败。4.6 阶段 5cAgent 配置落盘与设置保留linkCachedPluginAgentslink-cached-plugin-agents.ts扫描插件根components/*/agents/下的全部*.toml逐个拷贝到~/.codex/agents/以拷贝而非符号链接的方式落盘并执行两个关键的用户设置保留动作restorePreservedReasoning安装前先用capturePreservedAgentReasoning记录用户已有的model_reasoning_effort拷贝后写回restorePreservedServiceTier同理保留service_tier。这是升级不丢用户偏好的核心机制。若存在lazycodex-worker-medium.toml还会调用installDefaultAgentRole安装默认角色。最终把已安装 Agent 路径写入.installed-agents.json清单供卸载阶段精确回收。文档还提示当前受管managed的 Codex Agent 名单为explorer、librarian、metis、momus、plan。4.7 阶段 6缓存剪枝与旧 marketplace 清理pruneMarketplaceCache删除当前 marketplace 下不再被引用的插件版本legacyCacheMarketplacesinstall-codex.ts在安装sisyphuslabs时会额外清理旧 marketplacelazycodex与code-yeongyu-codex-plugins的缓存。同时reapLspDaemons会尽力回收遗留的 Codex LSP daemon失败仅记录 warning 不阻断安装。4.8 阶段 7config.toml 改写updateCodexConfigcodex-config-toml.ts是字符串级 TOML 改写通过toml-section-editor.ts逐段编辑不引入 TOML 解析器依赖按顺序完成先移除旧 marketplacelazycodex等遗留的 marketplace 块、插件块与 hook 状态块以及当前 marketplace 中过期插件的块移除不再受管的 Agent 配置块removeStaleManagedAgentBlocks依次确保开启plugins、plugin_hooks、multi_agent特性ensureFeatureEnabled移除不支持的旧版 multi-agent mode 配置写入基于模型目录readCodexModelCatalog的 reasoning 配置支持options.reasoning覆盖off→none写入 multi-agent v2 配置ensureCodexMultiAgentV2ConfigautonomousPermissions ! false时写入自主任权限块ensureAutonomousPermissions写入 marketplace 块本地源sourceType: local指向缓存根逐个启用插件{plugin}{marketplace}与内置 MCP 策略ensureOmoBuiltinMcpPolicies写入每个可信 Hook 状态的哈希ensureHookTrusted写入每个 Agent 的config_file ./agents/xxx.toml引用。最终通过writeFileAtomic原子落盘config.trimEnd() \n配置不存在时从空串开始构建。4.9 阶段 8-9项目本地修复与遥测repairProjectLocalCodexArtifactsBestEffort从projectDirectory向上扫描修复项目本地.codex/config.toml与全局配置的冲突——只做尽力而为发现遗留项目产物只记录不删除。最后trackCodexInstallTelemetry记录install_completed事件并返回完整的CodexInstallResult。五、安装产物WHAT IT WRITES 全表安装完成后~/.codex/或自定义CODEX_HOME下的布局如下路径内容~/.codex/plugins/cache/{marketplace}/{plugin}/{version}/构建完成的插件缓存已 npm 安装、MCP 清单已改写、原子提升~/.codex/.tmp/marketplaces/{marketplace}/本地 marketplace 快照插件源码拷贝 marketplace.json~/.codex/agents/*.toml从捆绑组件拷贝的 Agent 配置~/.codex/config.toml被改写marketplace 块、插件启用、特性开关、Agent 配置、hook 信任哈希、MCP 策略~/.local/bin/自定义 home 时为~/.codex/bin组件 CLI 的符号链接或.cmdshim omo包装器值得注意的是~/.local/bin/是默认 binDir由resolveCodexInstallerBinDir决定只有自定义 home 时才回退到~/.codex/bin。六、设计约定与反模式文档归纳了三条必须遵守的设计约定CONVENTIONSTOML 改写一律基于字符串经由toml-section-editor.ts做文本级操作刻意不引入 TOML 解析器依赖ANTI-PATTERNS第一条Never use a real TOML parser原子目录提升先拷贝到临时兄弟目录再rename()失败时恢复备份绝不允许直接写活缓存ANTI-PATTERNS第二条Never skip the temp-and-rename promotion平台差异Windows 用.cmdshimPOSIX 用符号链接。第三条例外约束同样重要新增受管 Agent 时必须同步更新MANAGED_CODEX_AGENT_NAMES同时存在于codex-config-agents.ts与codex-cleanup-config.ts否则卸载时无法精确回收对应 Agent 文件ANTI-PATTERNS第三条Never hardcode new agent names。此外文档还强调兼容性负担保留的 legacy purge 代码仍在追踪已退役的 reviewer agent用于清理旧版本安装残留的陈旧配置与 Agent 文件。七、卸载与安装严格对称的清理编排虽然文档正文聚焦安装其产物与约定同样定义了卸载语义。cleanupCodexLightcodex-cleanup.ts是卸载编排器与安装形成镜像先读后删在删除任何受管目录前先读取.installed-agents.json与安装期记录的 binDirreadInstalledCodexBinDir——因为清单文件本身就位于将被删除的受管树内Agent 回收结合MANAGED_CODEX_AGENT_NAMES与清单路径.tmp/marketplaces/sisyphuslabs/plugins/omo/.installed-agents.json及各缓存版本下的清单收集 Agent 路径逐条安全校验必须在~/.codex/agents/内、文件名必须匹配受管名单后移除受管状态目录删除plugins/cache/sisyphuslabs、.tmp/marketplaces/sisyphuslabs、runtime/ast-grep、runtime/node、plugins/data/omo-sisyphuslabs/bootstrap并以 glob 兜底深度 ≤ 5清理布局漂移的 bootstrap 目录源码注释明确安全不变量——只删受管子树绝不整体删除runtime/安全校验validateManagedCleanupTarget会拒绝指向文件系统根或越界的清理目标codex-cleanup-safety.tsbin 链接清理同理项目本地修复复用与安装相同的repairProjectLocalCodexArtifactsBestEffort重试语义removeManagedPathBestEffort采用单次重试策略——正在运行的 bootstrap worker 可能在首次删除后重建状态若重试后仍存在命令依然以 0 退出再次执行lazycodex-ai uninstall即可清干净。结语install-codex安装器的设计可以概括为三个关键词原子性temp-and-rename 提升与原子 config 写入、可逆性.installed-agents.json清单 安装期记录的 binDir让卸载能精确还原、兼容性保留旧 marketplace 清理、旧 Agent 追踪与 sparkshell 引用扫描平滑迁移历史安装。如果你要在自己的 Codex 环境里排查插件问题建议按本文第三节的路径优先级检查CODEX_HOME、CODEX_LOCAL_BIN_DIR、OMO_CODEX_PROJECT等环境变量再对照第五节的产品表核对每个目录是否存在若需彻底重装则走npx lazycodex-ai uninstall它会依据清单精确回收全部受管产物。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐CANN/asc-devkit创建算子工程指南创建算子工程a nameZH CN_TOPIC_0000001618617245 /a CANN开发套件包中提供了自定义算子工程生成工具msOpGen人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排用 Codex app-server 做一手钩子验证oh-my-openagent 的 Codex 插件 QA 通道全解析用 Codex app server 做一手钩子验证oh my openagent 的 Codex 插件 QA 通道全解析 本篇文章围绕 oh my open人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排如何通过 Codex 插件市场安装 LazyCodex omo 插件并批准 hooks如何通过 Codex 插件市场安装 LazyCodex omo 插件并批准 hooks 如果你已经在使用 OpenAI Codex CLI想完全在 Code人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排上一篇CC Switch ccswitch:// 协议把配置打包成一条链接同事点一下就导入下一篇ClaraVerse革命性AI平台一站式解决8大AI工具集成难题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考