eframe 如何启用 inspection 特性并用 EGUI_INSPECTION 环境变量接入 egui_mcp 外部检查器【免费下载链接】eguiegui: an easy-to-use immediate mode GUI in Rust that runs on both web and native项目地址: https://gitcode.com/GitHub_Trending/eg/egui你有一个用 eframe 写的 egui 应用想让外部工具如egui_mcp这个 MCP 服务器从进程外面读取它的 AccessKit 控件树、注入点击/输入/滚动事件、抓取截图——典型用途是让 AI agent 驱动应用、复现 bug 并验证修改。egui 0.35.02026-06-25引入了 inspection 协议egui_inspectioncrate 提供协议和InspectionPlugineframe 提供配套的inspectionfeature运行时通过EGUI_INSPECTION环境变量打开一个 TCP 检查端口。这篇文章覆盖如何给 eframe 应用启用该特性、如何用环境变量控制绑定地址、如何安装并接入egui_mcp以及如何验证接入成功。适用前提native桌面构建。文档明确说明 inspection 在 wasm 上是 no-op截图抓取还需要窗口可见见“验证与限制”一节。准备工作给 eframe 启用 inspection feature在应用的Cargo.toml中为eframe依赖加上inspectionfeatureeframe { version ..., features [inspection] }eframe 中该 feature 的定义是 Cargo.tomlinspection [dep:egui_inspection, accesskit]也就是说启用 inspection 会连带启用accesskit——协议读取的正是 AccessKit 控件树这是它的必要依赖。仓库里 egui_demo_app 的 Cargo.toml 给出了现成写法注释说明了行为边界eframe { workspace true, features [inspection, system_fonts] } # 注释始终在 native 上启用 eframe 的 inspection feature # 这样 EGUI_INSPECTION1 cargo run -p egui_demo_app 就会为 # egui_mcp 打开检查端口环境变量未设置时为 no-op。如果你不想改Cargo.toml也可以只在启动时用--features inspection临时启用egui_inspection README 中的命令就是这种用法。用 EGUI_INSPECTION 环境变量启动feature 启用后是否真正打开端口完全由EGUI_INSPECTION环境变量决定。解析逻辑在 lib.rs 的bind_addr_from_env中取值规则如下环境变量取值行为未设置、空、0、falseinspection 完全关闭文档称 production-safe1/true启用绑定默认地址127.0.0.1:5719其他值作为host:port绑定地址例如0.0.0.0:5719对应启动命令来自 egui_inspection READMEEGUI_INSPECTION1 cargo run --features inspection # 绑定 127.0.0.1:5719 EGUI_INSPECTION0.0.0.0:5719 cargo run --features inspection # 可跨设备访问启动时 eframe 的 glow/wgpu 集成会调用attach_from_env见 eframe/src/lib.rs它注册InspectionPlugineframe 会自动把应用名作为插件 label 传入并在配置地址上serve。serve内部绑定一个 TCP listenerspawn 一个 accept 线程加每条连接一个线程线程随进程存活见 plugin.rs。安装并接入 egui_mcpegui_mcp是该协议第一个消费者安装与接入命令来自 CHANGELOG 0.35.0 一节cargo install --git https://github.com/rerun-io/kittest_inspector egui_mcp claude mcp add egui egui-mcp第一条会在本地编译并安装egui_mcp二进制副作用向本机 cargo 安装目录写入二进制第二条把它注册进 Claude 的 MCP 配置。egui_mcp的attach默认连接127.0.0.1:5719与EGUI_INSPECTION1的默认绑定地址一致见 lib.rs 中DEFAULT_INSPECTION_ADDR的注释所以主路径下不需要额外配置端口。接入后外部检查器可以执行四类请求协议严格为 request → response走 TCP socketGetTree读取应用的 AccessKit 树HandleEvents注入输入事件点击、输入、滚动等Screenshot按需抓取当前帧以 PNG 编码返回Resize调整窗口尺寸。验证接入是否成功eframe 源码给出了三类日志作为判断依据eframe/src/lib.rsattach 成功info 日志egui_inspection plugin attached地址绑定失败端口被占用等warning 日志egui_inspection attach failed: {err}此时应用继续运行但没有检查端口环境变量设了真值、但编译时没启用inspectionfeaturewarning 日志Inspection env var set but app was compiled without eframe/inspection feature——这是“设置了变量却没生效”时最快的排查线索。此外协议本身有握手PROTOCOL_MAGICPROTOCOL_VERSION当前版本为 1单条消息上限 256 MiB见 protocol.rsegui_mcp连上并完成 GetTree 查询即说明链路可用。限制与边界wasm 无此能力inspection 在 wasm 上是 no-op只有 native 构建有意义。截图需要可见窗口读树和注入输入在应用处于后台时也能工作但抓截图需要 OS 产生渲染帧窗口被完全遮挡或最小化时文档特别提到 macOS 上拿不到 GPU surfaceScreenshot请求会超时。把窗口切到前台再抓。非 loopback 绑定无认证EGUI_INSPECTION0.0.0.0:5719这类绑定会把应用的完整控制权含截图暴露给任何能到达该端口的访问者且没有认证机制eframe 在这样做时会记录 warning。文档建议远程调试用 loopback SSH 隧道。文档中的一处不一致eframe/Cargo.toml 的 feature 注释提到EGUI_INSPECTION_ADDR这个变量名但egui_inspection的实现bind_addr_from_env见 lib.rs只读取EGUI_INSPECTION一个变量且注释称其为“控制 inspection 的唯一环境变量”。按实现为准使用EGUI_INSPECTION。不经过 eframe 时直接接入插件如果你在自己的 egui 应用里手动管理ContextREADME 给出的直接用法ctx.add_plugin(egui_inspection::InspectionPlugin::new(Some(my app.to_owned()))); egui_inspection::serve(ctx, 127.0.0.1:5719).unwrap();new的参数是应用名 label上面示例中my app即占位示例值换成你自己的应用名serve的地址需与你告诉egui_mcp的地址一致。日常开发保持默认即可不设置EGUI_INSPECTION时特性完全关闭需要让工具接入时再按本文主路径feature EGUI_INSPECTION1egui_mcpattach 到 127.0.0.1:5719打开。协议细节与请求/响应结构可以继续参考 protocol.rs 和 egui_inspection README。【免费下载链接】eguiegui: an easy-to-use immediate mode GUI in Rust that runs on both web and native项目地址: https://gitcode.com/GitHub_Trending/eg/egui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考