人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载本篇以 docs/insights/codex-tool-bridge.md产品层 Why为骨架结合 docs/handover/codex-tool-bridge.md工程实现 HOW与 docs/exec-plans/completed/phase-5c-codex-tool-bridge.md执行子计划展开并对照 src/lib/codex/proxy/builtin-bridge.ts 等源码逐项印证。本文讲解 CodePilot 多模型 Agent 桌面客户端中的一个关键架构组件当用户在 Codex Runtime 下选择 CodePilot 自有 providerGLM / Kimi / OpenAI-compat 等时如何让模型仍然调用 CodePilot 自有的图片生成、媒体导入、助理记忆、Widget 指南、通知与定时任务等内置工具。读完你不仅能理解proxy 内执行 侧通道事件总线这套桥接方案的设计取舍还能掌握桥接工具的挂载规则、schema 参数、安全边界与可复制的测试/smoke 验证方法。问题信号换 Runtime 后工具凭空消失2026-05-16 的真实 smoke 暴露了一个典型的运行时能力断档问题Codex Account GPT-Image-2.0走 Codex 原生路径图片生成稳定可用GLM-5 Turbo / KimiCodePilot provider Codex Runtime GPT-Image-2.0模型进入一条复杂的异常路径——读到imagegenSkill 说明 → 猜应该调用image_gen→ 发现内置工具不可用 → 尝试 CLI fallback → 查OPENAI_API_KEY→ 尝试读取~/.codex/auth.json→ 尝试npm install openai→ generation stopped。关键点在于这不是 GPT-Image 单点故障。同一轮对话里codepilot_memory_recent/codepilot_list_tasks也没有被调用模型只能用 Codex 自带的 Bash / file 工具假装回答。从源码可以确认根因parse-request.ts早期把所有 non-function 工具静默丢弃translate-tools.ts又显式写着built-in tools NOT supported yet——模型只看到 Skill 文本却拿不到真实可调用的工具于是开始自己拼凑恢复路径。用户底线能力属于产品层不属于 Runtime项目对这次修复立下两条硬性底线每个 Agent 框架可以保留自己的特色能力但 CodePilot 自有的核心能力不能因为换 Runtime 就消失。Widget、助理 Memory、定时任务、图片/媒体、Dashboard、CLI tools 是 CodePilot 的产品层能力不是某个 Runtime 的 plugin模型不能为了让自己能干活自己拼凑 fallback碰auth.json、装openai包、跑scripts/image_gen.py、找OPENAI_API_KEY都不是 CodePilot 的真实路径。产品定位上CodePilot 是多模型 Agent 桌面客户端。用户买 Kimi 套餐 用 Codex Runtime 套着用期望是我习惯的 CodePilot 能力都在。如果换 Runtime 就丢一半工具等于告诉用户换框架 换产品。因此 Phase 5c 的修复不是给 Codex 加 plugin而是把 CodePilot 已经存在的能力桥接到 Codex Runtime 的执行管线里从用户视角看是一个产品从工程视角看是多了一条 adapter 而非多了一个新功能。桥的位置为什么是proxy 内执行 侧通道 SSE三种候选位置都被认真权衡过方案结论原因Codex CLI 反调 CodePilot HTTP API模型生成 Bash 调内部端点否决绕开 schema、permission、origin session、media serve、delivery log 等所有产品约束把 function_call 转发回 CodexRuntime由 CodePilot 端执行后 turn 续接否决Codex 协议没有 server-side execute 槽需新增turn/continue中转加状态同步工程成本远超本期proxy 内执行 侧通道 SSE采用采用ai-sdk v6streamText({ stopWhen })天然支持 server-side tool execute 多步续聊Codex 看不到 function_call但 CodePilot UI 通过 sessionId 侧通道直收事件数据流全景从 docs/handover/codex-tool-bridge.md 与 src/lib/codex/proxy/unified-adapter.ts 归纳用户在 ChatView 发消息 → CodexRuntime.stream() 1. subscribeBuiltinEvents(sessionId, listener) ← 先订阅 2. buildCodexThreadParams({sessionId, workingDirectory, ...}) 3. thread/start 或 thread/resume注入 http_headers x-codepilot-target-provider / x-codepilot-session-id / x-codepilot-workspace-path 4. turn/start → Codex app-server子进程以 model_providercodepilot_proxy 发起 HTTP 请求 → POST /api/codex/proxy/v1/responsesproxy route 读 headers → ProxyHandlerInput → unified-adapter 1. createModel(targetProviderId, model) 2. translateResponsesInput → ModelMessage[] 3. translateResponsesTools(body.tools) → Codex function tools 4. createCodePilotBuiltinTools({sessionId, workspacePath, targetProviderId}) → bridge tools 5. merge toolsbridge 在名字冲突时胜出 6. 桥接系统提示拼到 body.instructions 7. streamText({ ..., stopWhen: stepCountIs(8) }) → streamText loop - model 输出 tool-call(codepilot_generate_image) → ai-sdk 调 bridge tool 的 execute() runWithEventsemit tool_started → 执行底层 handler → 构造 MediaBlock → materializeCodexEventMedia导入 .codepilot-media→ emit tool_completed → ai-sdk 把 tool result 回填给 model 继续输出 → translateStream - codepilot_* 的 tool-call / tool-result 静默吞掉不发 Codex - Codex 自己的 shell 等其它 tool-call 正常发 response.output_item.done → SSE → Codex app-server → JSON-RPC notifications → CodexRuntime → 同时侧通道事件已 emit 给 listener → materializeCodexEventMedia → canonicalToSseLine → SSE侧通道与 Codex JSON-RPC 通道并行输出到同一个 SSE 流——这正是 MediaPreview 能直接拿到tool_result.media而不需要改客户端代码的原因。桥的颗粒度共享底层 handler不做第二套实现桥不另写一套工具实现直接复用generateSingleImage/importFileToLibrary/searchWorkspace/getGuidelines/sendNotification//api/tasks/*。MCP、builtin-tools/、Codex 桥共享同一个底层 handler。桥只负责四件事AI SDK 形状的 schema 包装tool({ description, inputSchema, execute })tool_started/tool_completed事件 emitMediaBlock 构造失败路径的结构化文案。在 builtin-bridge.ts 中所有工具的执行体统一被runWithEvents()包裹先生成cpb_前缀的 toolId与useSSEStream在 Codex 通知路径上使用的约定一致在 handler 运行前 emittool_started让 UI 显示工具运行中handler 成功后再 emittool_completed带 output 文本和可选 MediaBlock失败则 emit 带error字符串的tool_completed并把错误文本返回给 ai-sdk 供模型感知。明确的不做清单不重新写工具描述清单——BUILTIN_MCP_CATALOG是单一来源不为 Codex 原生 shell / apply_patch 在 proxy 路径上做反向桥需要时单独立项不静默丢弃未识别的 Codex tool type——parse-request.ts返回结构化unsupported_tool_kind让用户能看见不把 memory / dashboard 大段内容塞进 system prompt——继续走工具按需调用避免上下文污染。触发场景三个不挂桥的分支桥只在Codex Runtime 非 codex_account provider时生效三种情况明确不挂桥Codex Runtime Codex Account走 Codex 自己的 auth 原生工具Skills、image_gen、shell、apply_patch桥拒挂。源码中createCodePilotBuiltinTools对targetProviderId codex_account直接返回空结果并附带skippedReasonCodePilot Runtime / Native Runtime原本就有 MCP /builtin-tools/双链路与本桥无关x-codepilot-session-idheader 缺失旧 build / 手动 smoke 场景桥拒挂proxy 回退到 chat-only 行为。此外从 builtin-bridge.ts 可以看到第三重守卫isManagedCodexSubagentSession(sessionId)时也返回空结果委托深度限制为 1。侧通道事件总线进程内、按 sessionId 索引、挂在 globalThis 上为什么不能用 Responses 输出承载工具完成事件因为 Responses-API 的 output_item 只有message和function_call两种形状tool_completed携带的 MediaBlock 在两个 shape 里都没有合适槽位Codex app-server 也不会把陌生 output 转成 JSON-RPC 通知。唯一的选择是绕过 Codex把事件直接送入 CodexRuntime 的 SSE 流。事件总线契约当前实现在 src/lib/harness/builtin-event-bus.ts原src/lib/codex/proxy/builtin-event-bus.ts已降级为 re-export shimsubscribeBuiltinEvents(sessionId: string, listener: (event: RuntimeRunEvent) void): () void emitBuiltinEvent(sessionId: string, event: RuntimeRunEvent): void设计要点globalThis上的MapsessionId, Setlistener避免 Next.js 热更 / 双 module-graph 导致 proxy 模块与 runtime 模块各持一份总线实例这正是当初从模块级 Map 改为挂globalThis的原因emit 在无订阅者时丢弃、绝不缓冲缓冲会导致跨 turn 状态泄漏——上一轮的图片如果没被消费下轮订阅时会突然冒出来。约定执行顺序是每次 turn 开始 runtime 先订阅再turn/startlistener 异常隔离每个 listener 调用包 try/catch一个坏订阅者不能打挂工具执行循环也不能阻断其它订阅者收事件跨运行时复用Phase 5e 把它提升为跨运行时 harness 原语Native Runtime 的agent-loop.ts也用它把tool_completed里的 MediaBlock 拼进 SSEtool_result事件模型可见文本保持干净。工具清单与 schema 详解桥挂载的工具在 builtin-bridge.ts 以CODEPILOT_BUILTIN_TOOL_NAMES声明实际挂载受 gate 控制工具gate副作用核心参数来自 inputSchemacodepilot_generate_image默认挂调generateSingleImage→.codepilot-media→ MediaBlockprompt必填英文provider: active \| grok-buildaspectRatio: 1:1/16:9/9:16/4:3/3:4imageSize: 1K \| 2KreferenceImagePaths[]codepilot_generate_videoGrok OAuth 可用时挂调generateGrokVideoGrok Imagine Video 1.5→ GallerypromptimagePath首帧referenceImagePaths[]max 7duration: 6 \| 10aspectRatio7 种resolution: 480p \| 720pcodepilot_import_media默认挂调importFileToLibrary→.codepilot-media→ MediaBlockfilePath必填prompt/source/model/tags[]type字段由 mimeType 前缀决定video/*→ videoaudio/*→ audio其余 → image与media-saver.mimeToMediaType同源codepilot_memory_recentworkspace 必须有读memory.mdmemory/daily/*.md复用createMemoryAdapterQueryTools的 schemacodepilot_memory_searchworkspace 必须有调searchWorkspacefile_typedaily/longterm/notes按路径过滤tags经workspace-indexer.loadManifest()过滤同上codepilot_memory_getworkspace 必须有path-safe symlink-escape 校验后读文件同上codepilot_load_widget_guidelines默认挂调getGuidelines(modules)返回文本modules[]必填min 1interactive/chart/mockup/art/diagramcodepilot_notify默认挂调sendNotificationtitle/body必填priority: low \| normal \| urgentlow仅 toastnormaltoast系统urgenttoast系统Telegramcodepilot_schedule_task默认挂durable false→ 调addSessionTaskin-memory否则 POST/api/tasks/schedule两条路径都注入origin_session_id/working_directoryname/prompt/kindreminder|ai_task/schedule_typecron|interval|once/schedule_value必填prioritynotify_on_completedurablecodepilot_list_tasks默认挂GET/api/tasks/list拿 durable 列表再合并getSessionTasks()status 过滤同时作用于两者status: active/paused/completed/disabled/allcodepilot_cancel_task默认挂先试removeSessionTask命中即返否则 DELETE/api/tasks/:idtask_id必填codepilot_list_subagent_runs/codepilot_spawn_subagent随桥挂载委托 Codex Runtime 子线程按精确 ProviderModel 路由跑一次性 Sub Agent走 DB 持久化生命周期后者要求prompt/provider_id/model支持workflow_idtask_keydepends_on依赖编排workspace-gated 的细节memory 三个工具仅当workspacePath存在且getSessionMemoryWorkspace()能解析出 memory workspace 时才注册不注册时工具名仍在集合里模型被告知不可用避免拿到泛化的Failed: ENOENT。未支持Phase 5c 范围外Dashboard 工具族codepilot_dashboard_*、CLI tools 管理codepilot_cli_tools_*、codepilot_hatch_buddy。如果模型尝试调用这些名字ai-sdk 会以工具不存在返回下游 catalog drift 测试只锁本桥实际挂载的名字。Codextools[]允许列表与 ToolSpec enum 同源parse-request.ts的KNOWN_NON_FUNCTION_TYPES必须与资料/codex/codex-rs/tools/src/tool_spec.rs的ToolSpecenum带#[serde(tag type)]保持同源。除function走主路径外其它六个值都进passthroughTools原样保留type来源处理namespaceMCP / Skill bundle含嵌套tools[]passthrough原 payload 保留嵌套 function tools 暂未 flatten后续 slicetool_searchCodex tool-discovery 表面passthroughlocal_shellCodex shell toolpassthroughimage_generationOpenAI Responses 内建passthroughweb_searchOpenAI Responses 内建passthroughcustomCodex freeformapply_patch 等passthrough不在列表中的type直接返回unsupported_tool_kind结构化错误。这个列表经历过一次收敛早期曾臆测性地包含plugin/file_search/code_interpreter/web_search_preview对照 Rust 源码确认这些 discriminant 实际不会发出后即被裁剪——防止宽松默认值掩盖未来的 schema 扩展。新增 Codex enum variant 时必须同步本表 KNOWN_NON_FUNCTION_TYPES由codex-proxy-namespace-tool.test.ts锁住。五个关键设计决策1. 为什么在 proxy 内执行而不是 turn 续接Codex Responses API 没有 server-side tool execute 槽。若 proxy 把function_call发给 CodexCodex 会当成客户端需要执行的工具而 CodexRuntime 端原本没有这套 round-trip 机制。要支持 turn 续接需要新增turn/continue中转、把工具结果反馈进 Codex thread state、重新编排 streamText 状态——成本太高。而 ai-sdk v6 的streamText({ tools, stopWhen })原生支持 server-side execute 多步续聊只需在出口把 function_call 吞掉即可。2. 为什么用侧通道事件总线而不是塞进 Responses 输出如前所述output_item 只有两种形状装不下 MediaBlockCodex app-server 也不会把陌生 output 转成 JSON-RPC 通知。侧通道是唯一可行路径。桥执行execute()时按 sessionId emit 事件runtime.ts里subscribeBuiltinEvents(sessionId, ...)的 listener 在turn/start之前完成订阅事件经materializeCodexEventMedia→canonicalToSseLine→tryEnqueue进入 SSE与 Codex JSON-RPC 通知合并输出。3. 为什么 emit-before-subscribe 必须丢弃不缓冲。缓冲会造成跨 turn 状态泄漏上一轮未被消费的图片会在下一轮订阅时突然冒出。每次 turn 开始 runtime 先订阅再turn/start这是约定的执行顺序。4. 为什么 stopWhen: stepCountIs(8)仅在桥挂载时启用多步。8 是经验值足够让模型先读 memory → 生成 image → 写 notify → 文末解释又不至于让出错的模型在工具调用里无限循环。从 unified-adapter.ts 可见Phase 5b chat-only 的 smoke 不挂桥、保持单步行为不改变现有契约后续 Phase 5d 已把步数上限收敛为harness/context-compiler.ts的CODEX_BRIDGE_STEP_LIMIT常量由 runtime capability adapter 统一下发stream 与 non-stream 两条路径对称读取。5. 为什么绝不读~/.codex/auth.json/ 跑scripts/image_gen.py/npm install openai这些是模型自己幻觉出来的恢复路径。pre-5c 模型看到imagegenskill 文本但工具不可调用时按试着拼一拼能用的环境的思路写了这堆 fallback。codex-builtin-no-anti-patterns.test.ts用 source grep 把这四个字符串列为禁用项断言src/lib/codex/proxy/**/*.ts中任意一处出现都会让 CI 变红。安全边界media serve所有图片/媒体路径必须落到dataDir/.codepilot-media。materializeCodexEventMedia在事件离开 bridge 之前完成导入/api/media/serve拒绝非此目录的请求既有 boundary。在runWithEvents里成功路径也会先用探测事件走一遍materializeCodexEventMedia把带localPath的 MediaBlock 先复制进.codepilot-media再 emitworkspace path traversalcodepilot_memory_get复用memory-search-mcp.ts的路径校验逻辑path.relativestartsWith..检查 realpath链跟随后再校验防 symlink escapetask hidden contextcodepilot_schedule_task的origin_session_id/working_directory从 bridge closure 写入 POST body——模型即使在 input 里塞同名字段也无效POST body 后写覆盖。两条分支session-only 与 durable POST都注入保证定时任务 runner 之后能定位正确的项目与会话。反模式与教训模型recovery 创造力的危险性核心教训模型在缺少明确工具时的recovery 创造力非常危险——它不会停下来报错会按训练数据里见过的 OpenAI 接入指南拼凑 fallback。auth.json/npm install openai/OPENAI_API_KEY都不是从 CodePilot 代码里来的是模型自创的。对策三条工具必须真实可调用而不是只在 prompt 里提及——让模型看到 Skill 文本却给不出工具等于逼它自创工具失败时返回结构化、具体的错误如Image generation succeeded but no image was returned. Try a different prompt.而不是泛泛的tool failed——前者抑制模型继续猜下一步。源码中NoImageGeneratedError被专门转换为这条具体文案后抛出CI 用 source-grep 把反模式关键词锁死在禁用列表再出现就红。此外还有两条 smoke 期间修出的 P1/P2 细节值得注意import_media的type字段曾一律为image导致导入.mp4/.wav落到错误渲染器后改为按 mimeType 前缀推断与media-saver.mimeToMediaType同源schedule_task的durable: false曾走 durable POST 路径导致本应仅会话内存的任务意外持久化后改为addSessionTask分支并与notification-mcp.ts行为对齐。Widget 格式契约与错误可见性S4 smoke 显示模型在 widget 任务里会1误读 Chart.js / SVG 示例把 raw HTML 当成show-widget内容2多余调用codepilot_generate_image。Phase 5c slice 6 加四道防线单一 wire format 来源——WIDGET_WIRE_FORMAT_SPEC在widget-guidelines.ts系统提示 on-demandgetGuidelines()输出都嵌入这段禁止 drifton-demand guidelines 前置 reminder——getGuidelines()输出第一段就是 wire format spec 与HTML/SVG examples 是 INSIDE widget_code不是 wire format的提醒image-gen 工具禁用——系统提示 bridge 提示都明示 widget 任务期间不许调codepilot_generate_image除非用户独立要求生成图片渲染层错误可见——MessageItem.parseAllShowWidgets不再静默丢弃格式不对的show-widgetfence三类失败raw HTML 体 / JSON 缺widget_code/ JSON 解析错都返回malformed_widgetsegment由MalformedWidgetNotice渲染成可见警告卡。契约由codex-widget-format-contract.test.ts的 12 个 pin 锁定spec → 系统提示 → 桥提示 → 渲染层的端到端契约。另一个错误可见性问题是 proxy preflight 错误的持久化chat route (src/app/api/chat/route.ts) 的持久化条件是contentBlocks.length 0而 preflight 错误只有 error event、没有文本/思考/工具结果导致实时 SSE 显示了错误refresh 后转录里只剩用户气泡。修复方案是在主路径 catch 路径都加 fallback若hasError contentBlocks.length 0push**Error:** message文本块再走持久化分支文案与stream-session-manager.ts客户端 snapshot 同源保证 refresh 前后转录一致。测试矩阵与 Smoke 矩阵单元测试覆盖对应 src/tests/unit 下的文件测试文件测试什么codex-proxy-builtin-event-bus.test.ts总线subscribe/emit/unsubscribe、多订阅者广播、session 隔离、drop-before-subscribe、listener 异常隔离codex-proxy-parse-classification.test.tsparse-request 分类function / 已知 non-function / 未知类型结构化错误codex-proxy-headers.test.ts新 headers默认不发、有值时发、空串不发、codex_account 不注入codex-builtin-bridge.test.ts/codex-builtin-bridge-parity.test.ts桥本体挂载/跳过、工具集完整性、execute() 事件形状、跨 session 隔离、错误路径不含反模式codex-builtin-stream-suppression.test.tstranslate-stream内建工具不发 function_call、外部工具正常发、index 序列无空缺codex-builtin-codex-account-guardrail.test.tscodex_account 不挂桥bridge 层 thread params 层codex-builtin-no-anti-patterns.test.tssource-grepauth.json / image_gen.py / npm install / OPENAI_API_KEYcodex-proxy-namespace-tool.test.tsnamespace tool 分类与 passthrough 契约用户必须跑的真实 smokeSmokePrompt / 操作通过标准Codex Account GPT-Image用 GPT-Image-2.0 画一张小猫走原生路径图片正常显示本桥未介入log 里看不到 bridge eventsGLM-5 Turbo Codex Runtime 图片同上工具调用记录里出现codepilot_generate_imageMediaPreview 立刻显示无 CLI fallbackreload 仍可见Kimi Codex Runtime 图片同上同上GLM/Kimi widget生成一个 widget 展示销售数据必要时先加载 guidelines调用codepilot_load_widget_guidelines最终生成 show-widget fenceGLM/Kimi memory用 codepilot_memory_recent 看看最近记忆命中codepilot_memory_recent不是 Bash 读文件GLM/Kimi tasks用 codepilot_list_tasks 列出现有任务命中codepilot_list_tasks从 DB / API 读到结果每条 smoke 必须确认工具调用真实出现在转录里不是 Bash 假冒、副作用可观察media 卡 / DB 行 / 通知、失败路径有结构化错误且不出现 trying CLI / checking auth.json 类文案。实施方式七个提交切片Phase 5c 按七个切片落地每片独立 commitpre-commit hook 跑npm run test切片内容单测5c-step-1计划 事件总线 parse-request 分类 types 扩展codex-proxy-builtin-event-bus.test.ts、codex-proxy-parse-classification.test.ts5c-step-2proxy headers 路由读取 provider-proxy 注入 runtime 透传 ProxyHandlerInput 类型codex-proxy-headers.test.ts5c-step-3工具桥模块image / media / memory / widget / tasks 侧通道事件codex-builtin-bridge.test.ts5c-step-4unified-adapter 合并工具 stopWhen translate-stream 抑制内建工具事件codex-builtin-adapter-integration.test.ts、codex-builtin-stream-suppression.test.ts5c-step-5CodexRuntime 订阅事件总线codex-runtime-builtin-bus.test.ts5c-step-6防回归 Codex Account 守卫 反模式 source-grepcodex-builtin-codex-account-guardrail.test.ts、codex-builtin-no-anti-patterns.test.ts5c-step-7交接 / 产品 doc closeout 状态更新无未来方向与已知遗留能力族健康卡Settings → Runtime 里给 Codex 卡加CodePilot tool bridge健康状态把当前哪些工具挂载、哪些跳过、为什么跳过暴露出来——pre-Phase-5c smoke 失败难诊断部分原因正是工具桥状态对用户不可见。Codex 原生工具反向接入当用户在 Codex Runtime 下选 CodePilot provider 时让 Codex 自己的apply_patch/shell也能跑——需要 proxy 把 function_call 委托给 CodePilot 的 Native Runtime tool 实现本期不做。Bridge as template for future RuntimesGemini / OpenClaw / Hermes 等接入时复用同一套契约——ProviderProxyBridge八个 hook见 docs/handover/provider-proxy-bridge.mdCodePilotToolBridge工具挂载 侧通道事件总线UI 可见性。Phase 5c 是这套模式的第一个落地参考。Dashboard / CLI tools 工具族写类工具需要走 permission 协议本期 deferred下一轮专门设计 Codex Runtime 下的 permission round-trip。已明确的遗留点还包括Codex passthrough toolscustom/namespace/local_shell/tool_search/web_search/image_generation目前仅记录到passthroughTools字段、没有真实执行能力namespace的嵌套 function tools 尚未 flatten 进 ai-sdk ToolSet让 GLM/Kimi 也能用 Codex 自身 MCP 插件需单独立项stopWhen: stepCountIs(8)是经验值若遇到工具链超过 8 步需按场景调整。赞分享人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载相关推荐CodePilot Codex 运行时工具桥让 GLM/Kimi 等第三方模型在 Codex Runtime 中调用原生内置工具CodePilot Codex 运行时工具桥让 GLM/Kimi 等第三方模型在 Codex Runtime 中调用原生内置工具 本文基于 Phase 5c人工智能AI 应用AI Agent交互助手MCP Clients本地部署CodePilot Codex Runtime 接入实战从 app-server JSON-RPC 到 provider proxy 与 Tool Bridge 的多 Runtime 架构落地CodePilot Codex Runtime 接入实战从 app server JSON RPC 到 provider proxy 与 Tool Bridg人工智能AI 应用AI Agent交互助手MCP Clients本地部署fish_key_reader 完全指南在 fish-shell 中探明按键序列并一键生成 bind 绑定命令fish_key_reader 完全指南在 fish shell 中探明按键序列并一键生成 bind 绑定命令 导读 fish_key_reader 是 fi人工智能AI 应用AI Agent交互助手MCP Clients本地部署上一篇Fluent UI多语言切换终极指南动态语言加载与状态保持方案下一篇国家中小学智慧教育平台电子课本下载神器三步快速获取教材PDF创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考