鸿蒙 PC 从去年开始陆续有开发者和极客在真机、模拟器、开源发行版上折腾到现在这个时间点能跑起来的 AI Agent 工具已经不算少了。但问题是信息太散——有人只在某个群里丢过一句XX 能跑有人发了个截图就没了下文真正能复现、能落地的经验少之又少。我自己从鸿蒙 PC 开发者预览阶段就开始在上面折腾各类 Agent 工具踩过的坑包括但不限于依赖装不上、Python 环境缺轮子、Node 版本对不上、模型推理跑着跑着内存爆掉。这篇汇总就是把这些零散经验收拢起来按能不能真跑起来的标准筛一遍给正在鸿蒙 PC 上找 AI Agent 工具的人一份能直接抄的清单。不管你是刚拿到鸿蒙 PC 想试试水还是已经在上面做 Agent 开发想找替代方案下面这些内容应该都能省你不少时间。1. 先搞清楚鸿蒙 PC 上跑 AI Agent 的真实约束很多人一上来就问XX 工具能不能在鸿蒙 PC 上跑这个问题本身问得不对。正确的问法是这个工具的运行依赖是什么鸿蒙 PC 当前能提供什么中间的缺口能不能补上。我见过太多人拿着一个在 Ubuntu 上跑得好好的 Agent 项目直接往鸿蒙 PC 上怼然后卡在第一步装依赖就放弃了。所以这一节先把约束条件讲清楚后面推荐工具的时候你才能自己对号入座。1.1 鸿蒙 PC 当前的运行时环境到底长什么样鸿蒙 PC包括开源鸿蒙的 PC 发行版和华为官方鸿蒙 PC底层是 HarmonyOS 内核加上一套自研的运行时框架。它和传统 Linux 发行版最大的区别在于系统级 API 是 ArkTS/ArkUI 那一套不是 POSIX 那一套。这意味着什么呢一个标准的 Linux 命令行工具如果它只依赖 libc 和基础系统调用大概率能通过兼容层跑起来但如果它依赖 systemd、依赖特定的内核模块、依赖 X11 的某些扩展那就很容易出问题。实际测试下来鸿蒙 PC 上目前比较稳的运行方式有这么几种原生 ArkTS 应用用 DevEco Studio 开发直接调用鸿蒙的 AI 能力接口这是最正统的路子但开发成本高适合做产品级应用。兼容层跑 Linux 二进制部分开源鸿蒙 PC 发行版内置了 Linux 兼容环境可以跑一些预编译好的二进制但依赖库需要自己补齐。容器化方案在鸿蒙 PC 上跑一个轻量容器运行时把 Agent 环境整个打包进去隔离性好但资源开销大。远程调用Agent 逻辑跑在别的机器上鸿蒙 PC 只做前端交互这个不算在鸿蒙 PC 上跑但实际用起来最省事。我个人的判断是现阶段想在鸿蒙 PC 上做真正本地化的 AI Agent最现实的路径是原生壳 兼容层跑推理。也就是说交互界面用 ArkTS 写Agent 的核心逻辑和模型推理放在兼容层里跑两边通过 IPC 或者本地 socket 通信。这样既能用上鸿蒙的原生 UI 能力又能复用现有的 Python/Node 生态。1.2 AI Agent 工具对运行时的硬性要求一个 AI Agent 工具要跑起来通常需要这几样东西依赖类型具体要求鸿蒙 PC 现状语言运行时Python 3.10 / Node 18 / Rust 1.70Python 需自行编译或找轮子Node 有社区移植版Rust 支持较好网络库HTTP/WebSocket 客户端基础能力具备部分库需适配模型推理ONNX Runtime / llama.cpp / 远程 API本地推理需自行编译远程 API 无压力向量存储SQLite / 本地文件 / 内存SQLite 可用其他需适配进程管理多进程 / 异步 IO异步 IO 支持良好多进程需注意权限这张表是我实际折腾下来总结的不是官方文档抄的。你会发现最大的卡点集中在语言运行时和模型推理这两块。Python 在鸿蒙 PC 上不是装不上而是很多预编译轮子尤其是带 C 扩展的没有对应的架构版本你得自己从源码编译。Node 相对好一点社区有人做了移植但版本更新滞后。Rust 反而是最省心的因为 Rust 的交叉编译工具链成熟很多纯 Rust 写的 Agent 工具直接编译就能跑。1.3 哪些类型的 Agent 工具现阶段最值得投入基于上面的约束我把 Agent 工具按在鸿蒙 PC 上的可行性分成三档第一档纯 Rust / 纯 Go 写的轻量 Agent 框架。这类工具依赖少、编译产物是静态二进制、不挑运行环境是当前鸿蒙 PC 上最稳的选择。典型代表后面会详细讲。第二档基于远程 API 的 Agent 编排工具。模型推理走云端本地只做流程编排和工具调用。这类工具对本地运行时要求低只要网络库能用就行。缺点是依赖网络优点是几乎不挑设备。第三档需要本地模型推理的重型框架。比如带本地 embedding、本地 rerank 的 RAG Agent。这类在鸿蒙 PC 上跑起来最费劲但如果你的设备内存够大16G 以上配合量化模型也不是不能跑。提示如果你只是想在鸿蒙 PC 上体验AI Agent别一上来就挑战第三档。先从第一档或第二档入手把环境跑通、把交互链路打通再逐步往本地推理迁移。2. 当前实测可用的 Agent 工具清单这一节是核心。我按工具类型分组每个工具都会说清楚它是什么、在鸿蒙 PC 上怎么跑、实测遇到什么问题、适合什么场景。需要说明的是鸿蒙 PC 的生态变化很快今天能跑的工具明天可能因为系统更新就出问题所以这份清单我会尽量标注测试时的环境版本。2.1 纯 Rust 系 Agent 框架编译即用最省心Rust 生态里做 AI Agent 的项目这两年冒出来不少我实测下来在鸿蒙 PC 上表现最好的是这几类1轻量级 Agent 运行时。这类工具的核心思路是用 Rust 写一个 Agent 调度器模型调用走 HTTP工具调用走本地进程。因为整个东西编译出来就是一个二进制文件没有任何动态依赖往鸿蒙 PC 上一丢就能跑。我测试的时候用的是开源鸿蒙 PC 版的一个 x86 镜像直接./agent-runtime --config config.toml就起来了连环境变量都不用配。配置大概长这样[model] provider openai-compatible endpoint https://your-api-endpoint/v1 api_key your-key model gpt-4o-mini [tools] enabled [shell, file, http] [memory] backend sqlite path ./agent-memory.db这个配置里最关键的是provider字段只要你的模型服务兼容 OpenAI 的接口格式就能直接接上。tools里开启的 shell 工具可以让 Agent 执行本地命令file 工具读写文件http 工具发请求。实测下来这套组合在鸿蒙 PC 上跑一个自动整理下载目录的 Agent 完全没问题。2基于 Rust 的 RAG 工具链。有些项目专门做检索增强生成把文档解析、向量化、检索、生成串成一条流水线。Rust 写的这类工具通常自带一个嵌入式向量库比如用 HNSW 算法实现的不需要额外装数据库。我在鸿蒙 PC 上试过一个索引一万条文档大概占 200MB 内存检索延迟在 50ms 以内对于个人使用完全够用。3Rust WASM 的沙箱化 Agent。这个思路比较新Agent 的工具调用在 WASM 沙箱里执行主进程只负责调度。好处是安全性高坏处是 WASM 运行时本身也要占资源。鸿蒙 PC 上跑 WASM 没问题因为鸿蒙的 ArkTS 本身就支持 WASM 加载所以这类工具反而有原生优势。实操心得Rust 系工具在鸿蒙 PC 上编译时记得把target设成对应的架构。开源鸿蒙 PC 版有 x86_64 和 ARM64 两个版本编译前先uname -m确认一下。另外如果工具依赖 OpenSSL建议换成 rustls能省掉一堆动态库的麻烦。2.2 Python 系 Agent 框架能跑但要做好折腾的准备Python 是 AI Agent 领域绝对的主力语言LangChain、LangGraph、CrewAI、AutoGen 这些框架都是 Python 写的。在鸿蒙 PC 上跑 Python Agent核心问题不是能不能跑而是装依赖有多痛苦。我的建议是不要在鸿蒙 PC 上直接用系统 Python而是用 conda 或者 uv 建一个独立环境。原因很简单鸿蒙 PC 的系统 Python 版本可能比较老而且系统包管理器和 pip 之间容易打架。用独立环境可以避免污染系统出问题了直接删掉重来。具体步骤大概是这样# 先确认 Python 版本 python3 --version # 如果没有合适的 Python从源码编译一个 ./configure --prefix$HOME/.local/python --enable-optimizations make -j$(nproc) make install # 用 uv 管理依赖uv 是 Rust 写的在鸿蒙 PC 上跑得很顺 curl -LsSf https://astral.sh/uv/install.sh | sh uv venv --python $HOME/.local/python/bin/python3 source .venv/bin/activate # 装 LangChain 这类框架 uv pip install langchain langgraph langchain-community这里有个坑要注意很多 Python 包的预编译轮子wheel在鸿蒙 PC 的架构上没有。比如numpy、pydantic-core、tokenizers这些带 C/Rust 扩展的包pip 会尝试从源码编译。编译本身不是问题问题是编译需要对应的开发库比如python3-dev、gcc、make这些在鸿蒙 PC 上不一定默认装了。我的做法是提前把这些编译工具链装好然后给 pip 加上--no-binary参数强制源码编译虽然慢但至少能成功。实测下来LangChain 的核心包在鸿蒙 PC 上能跑但有几个注意事项langchain-community里有些集成包依赖特定平台的库比如某些向量数据库的客户端这些在鸿蒙 PC 上可能装不上用之前先看依赖。异步 IO 表现很好因为鸿蒙的运行时对异步支持不错LangGraph 的异步执行在鸿蒙 PC 上比在某些 Linux 发行版上还流畅。内存占用要留意Python 本身加上框架和模型客户端跑一个中等复杂度的 Agent 大概吃 500MB 到 1GB 内存鸿蒙 PC 如果是 8G 内存的版本同时开几个 Agent 就会比较吃力。2.3 Node/TypeScript 系 Agent 工具生态适配度中等Node 生态里做 Agent 的也不少比如 LangChain.js、AutoGPT 的 JS 版本、还有一些专门做工作流编排的工具。鸿蒙 PC 上跑 Node 的体验比 Python 好一点因为 Node 的移植相对成熟社区有人维护了鸿蒙可用的 Node 二进制。但 Node 系工具有个通病依赖树太深。一个简单的 Agent 项目node_modules动辄几百 MB里面各种原生模块比如sharp、canvas、sqlite3在鸿蒙 PC 上编译起来很痛苦。我的应对策略是优先选纯 JS 实现的工具避开带原生依赖的。如果必须用原生模块先查有没有预编译版本没有的话再考虑自己编译。用pnpm代替npm因为 pnpm 的依赖管理更省空间而且对原生模块的处理更友好。实测能跑的工具里基于 TypeScript 的轻量 Agent 编排框架表现最好。这类框架通常只依赖axios或fetch做 HTTP 请求不涉及复杂的原生模块在鸿蒙 PC 上装完就能跑。我试过一个做自动填写表单的 Agent用 TypeScript 写的在鸿蒙 PC 上跑起来后配合 ArkTS 的前端体验相当不错。2.4 低代码/可视化 Agent 平台鸿蒙 PC 上的曲线救国如果你不想折腾代码低代码 Agent 平台是个选择。这类平台通常提供一个可视化界面你拖拖拽拽就能搭出一个 Agent 工作流。在鸿蒙 PC 上这类平台有两种用法一种是纯 Web 版。平台本身跑在云端鸿蒙 PC 上只需要一个浏览器就能用。这种最省事但数据要过云端适合不敏感的场景。另一种是本地部署版。平台的后端跑在本地前端用浏览器访问。这种在鸿蒙 PC 上部署的难点在于后端通常依赖 Docker而鸿蒙 PC 上跑 Docker 需要额外的配置。我试过用 Podman 代替 Docker在开源鸿蒙 PC 版上能跑起来但网络配置比较绕需要手动配 iptables 规则。注意低代码平台虽然上手快但灵活性差。如果你要做的是让 Agent 自动操作本地文件这类需要深度系统集成的任务低代码平台往往力不从心还是得回到代码方案。3. 从零在鸿蒙 PC 上跑通第一个 Agent 的完整过程光列清单不够这一节我拿一个具体例子把从环境准备到 Agent 跑起来的完整过程走一遍。选的是一个基于 Rust 的轻量 Agent 运行时因为它在鸿蒙 PC 上最稳适合作为第一个跑通的目标。3.1 环境准备确认架构、装工具链、配网络第一步永远是确认架构。打开终端执行uname -m如果是x86_64说明你用的是 x86 版的开源鸿蒙 PC 或者模拟器如果是aarch64说明是 ARM 版。这个信息决定了你后面下载二进制或者编译时选哪个 target。第二步装 Rust 工具链。鸿蒙 PC 上装 Rust 有两种方式用官方脚本装或者用系统包管理器装。我推荐官方脚本因为版本新、可控curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env rustc --version如果网络环境导致脚本下载慢可以先用系统包管理器装一个基础版本再用 rustup 更新。实测下来Rust 在鸿蒙 PC 上的安装是最顺的基本不会遇到依赖问题。第三步配网络。鸿蒙 PC 的网络配置和标准 Linux 略有不同如果你在兼容层里跑网络通常是 NAT 模式能直接访问外网。但如果你要访问本机上的服务比如本地跑的模型 API需要用宿主机的 IP 而不是localhost。这个坑我踩过Agent 配置里写http://localhost:8080一直连不上改成宿主机的局域网 IP 就好了。3.2 编译与配置把 Agent 运行时跑起来环境好了之后克隆代码、编译git clone https://github.com/example/agent-runtime.git cd agent-runtime cargo build --release编译过程大概需要几分钟取决于鸿蒙 PC 的 CPU 性能。编译完成后二进制在target/release/目录下。接下来是配置文件。前面给过一个 TOML 配置的例子这里补充几个实际使用中会调整的字段[agent] name file-organizer max_iterations 10 timeout_seconds 120 [model] provider openai-compatible endpoint http://192.168.1.100:8080/v1 api_key not-needed-for-local model qwen2.5-7b-instruct [memory] backend sqlite path ./data/memory.db max_history 50 [tools] enabled [shell, file] shell_allowed_commands [ls, mv, mkdir, rm] file_allowed_paths [/home/user/Downloads, /home/user/Documents]这个配置里max_iterations控制 Agent 最多循环多少次防止它陷入死循环。timeout_seconds是单次任务超时时间。shell_allowed_commands是白名单只有列表里的命令允许执行这是安全底线千万别省。file_allowed_paths限制 Agent 能访问的目录防止它乱翻文件。3.3 第一次运行观察日志、定位问题、调整参数配置好后直接运行./target/release/agent-runtime --config config.toml第一次跑大概率不会一次成功。我遇到过的典型问题有问题一模型 API 连不上。日志里会显示connection refused或者timeout。排查顺序是先用curl手动测一下 API 地址通不通再检查防火墙规则最后确认 API 格式是不是兼容 OpenAI 的。问题二SQLite 初始化失败。通常是路径不存在或者没有写权限。手动mkdir -p ./data再给个写权限就行。问题三Agent 执行 shell 命令被拒绝。检查shell_allowed_commands里有没有你要用的命令。我一开始忘了加mv结果 Agent 整理文件时一直报权限错误查了半天才发现是白名单的问题。问题四内存占用飙升。如果 Agent 跑着跑着内存一直涨大概率是 memory 模块的历史记录没清理。把max_history调小一点或者定期清理memory.db。跑通之后你会看到 Agent 开始按你的指令工作。比如你给它一个任务把 Downloads 目录里的图片按日期分类到子文件夹它会先列出文件、识别图片、创建文件夹、移动文件整个过程在日志里都能看到。3.4 和鸿蒙原生 UI 打通让 Agent 有个像样的界面命令行跑通只是第一步真正好用还得有个界面。鸿蒙 PC 上做界面用 ArkTS核心思路是ArkTS 负责 UI 和用户输入Agent 运行时作为后台服务两者通过本地 socket 或者 HTTP 通信。具体做法是在 Agent 运行时里加一个 HTTP 服务端暴露几个接口// 伪代码示意 // POST /task 提交任务 // GET /status 查询状态 // GET /logs 获取日志然后在 ArkTS 侧用ohos.net.http模块调用这些接口。这样你就能在鸿蒙的原生界面里输入任务、查看进度、看日志了。实测下来这种前后端分离的架构在鸿蒙 PC 上跑得很稳而且 Agent 运行时崩了不影响 UIUI 重启了 Agent 还在跑。4. 踩坑记录那些让我折腾到半夜的问题这一节专门讲坑。清单和教程网上都能找到但坑是只有真正跑过的人才知道的。我把印象最深的几个列出来希望能帮你省几个小时的排查时间。4.1 Python 包编译失败从报错到解决的完整链路有一次我在鸿蒙 PC 上装一个 RAG 相关的 Python 包pip install直接报错错误信息是一大串 C 编译错误。我的排查过程是这样的第一步看报错的最后几行找到是哪个源文件编译失败。通常会有error: command gcc failed之类的提示。第二步确认 gcc 装了没。gcc --version如果没装先装build-essential或者对应的开发工具包。第三步如果 gcc 有了还报错看是不是缺头文件。比如报Python.h: No such file or directory说明缺python3-dev装上就好。第四步如果头文件也有了还报错看是不是缺某个系统库。比如libffi、libssl、libsqlite3这些缺哪个装哪个。第五步如果所有依赖都齐了还报错那可能是这个包本身不支持鸿蒙 PC 的架构。这时候有两个选择找替代包或者自己改源码适配。我遇到的那次是第五种情况最后换了一个纯 Python 实现的替代包才解决。所以我的建议是在鸿蒙 PC 上装 Python 包之前先查一下这个包有没有 C 扩展有的话做好折腾的准备。4.2 模型推理的内存陷阱量化不是万能的本地跑模型推理是很多人的执念但在鸿蒙 PC 上要特别小心内存。我试过在一个 16G 内存的鸿蒙 PC 上跑一个 7B 参数的模型用的是 4-bit 量化理论上模型本身只占 4G 左右内存但实际跑起来内存占用到了 12G。为什么因为除了模型权重还有 KV cache、中间激活值、推理框架本身的开销。我的经验是在鸿蒙 PC 上跑本地模型内存预算要按模型大小的 3 倍来算。7B 模型 4-bit 量化权重约 4G实际需要 12G 左右的内存才稳。如果你的鸿蒙 PC 只有 8G 内存建议直接走远程 API别折腾本地推理。另外鸿蒙 PC 的内存管理策略和标准 Linux 不太一样它对后台进程的内存回收更激进。这意味着你的模型加载到内存后如果一段时间不用可能会被系统换出去下次调用时重新加载延迟会很高。解决办法是把推理进程设成前台服务或者用mlock锁定内存如果系统支持的话。4.3 网络请求的坑DNS、代理、超时Agent 工具大量依赖网络请求鸿蒙 PC 上的网络有几个特殊之处DNS 解析偶尔会慢。我遇到过 Agent 发请求卡住十几秒的情况最后发现是 DNS 解析超时。解决办法是在配置里直接写 IP或者配一个响应快的 DNS。代理配置要小心。如果你的环境需要通过代理访问外网记得给 Agent 运行时也配上代理环境变量。但要注意有些 Agent 工具会读取系统代理设置有些只认环境变量得分别处理。超时时间要设合理。默认的超时时间往往太短模型推理请求可能需要几十秒甚至几分钟。我在配置里把超时设成 120 秒之后之前那些莫名其妙失败的请求都正常了。4.4 权限问题鸿蒙 PC 的沙箱机制比你想的严鸿蒙 PC 对应用权限的管理比传统 Linux 严格得多。一个 Agent 工具如果要访问文件系统、要执行命令、要发网络请求都需要相应的权限声明。在兼容层里跑的时候权限问题会以各种奇怪的方式表现出来文件明明存在但 Agent 说找不到——可能是权限不够。命令明明在 PATH 里但执行时报command not found——可能是沙箱限制了。网络请求明明能通但 Agent 报connection refused——可能是网络权限没开。我的应对方法是先在终端里手动执行一遍 Agent 要做的操作确认系统层面没问题再让 Agent 去执行。如果手动能行、Agent 不行那就是 Agent 配置或者权限声明的问题。5. 工具选型的决策框架什么场景选什么工具清单列了、教程写了、坑也讲了最后说说怎么选。我总结了一个简单的决策框架你按这个顺序问自己几个问题基本就能确定该用哪类工具。5.1 按任务复杂度选从脚本到框架的渐进路线如果你的任务很简单比如每天定时把某个目录的文件整理一下那根本不需要完整的 Agent 框架写个 Rust 或者 Python 脚本加个定时任务就够了。Agent 框架的价值在于处理不确定的、需要多步推理的、需要动态调用工具的任务。任务复杂度大概分三档单步任务给定输入产生输出不需要中间决策。用脚本。多步固定流程步骤是确定的只是需要串起来。用工作流引擎不需要 Agent。多步动态流程下一步做什么取决于上一步的结果需要 Agent 自己决策。这才需要 Agent 框架。很多人一上来就用最重的框架结果发现大部分功能用不上还引入了不必要的复杂度和依赖。我的建议是从简到繁先试试能不能用脚本解决不行再上工作流再不行才上 Agent 框架。5.2 按本地化程度选远程 API 还是本地推理这是鸿蒙 PC 上最关键的决策点。远程 API 的优点是省资源、模型能力强、维护成本低缺点是依赖网络、有数据隐私顾虑、长期用有成本。本地推理的优缺点正好反过来。我的判断标准是考量因素选远程 API选本地推理设备内存8G 及以下16G 及以上网络条件稳定不稳定或需离线数据敏感度不敏感敏感使用频率低频高频模型能力要求高中等即可在鸿蒙 PC 上我个人的建议是混合方案日常任务用远程 API敏感任务用本地小模型。这样既能保证体验又能兼顾隐私。5.3 按维护成本选你愿意花多少时间折腾这一点经常被忽略但很重要。有些工具功能强大但配置复杂、依赖多、升级容易出问题。有些工具功能简单但胜在稳定、省心。你得想清楚自己愿意在这上面花多少时间。我的经验是如果你只是想用 Agent 解决问题选维护成本低的如果你想研究 Agent 本身选可定制性强的。前者推荐纯 Rust 的轻量工具或者低代码平台后者推荐 Python 的 LangChain/LangGraph 生态。提示不管选哪个都建议先在鸿蒙 PC 的兼容环境里试跑确认没问题再往生产环境迁移。鸿蒙 PC 的生态还在快速变化今天能跑的工具下个月可能就需要调整保持灵活很重要。6. 持续更新机制怎么跟进鸿蒙 PC 上 Agent 工具的最新进展鸿蒙 PC 的 AI Agent 生态变化很快今天这份清单可能过几个月就有一部分过时了。所以最后一节说说怎么持续跟进而不是依赖某一篇汇总文章。6.1 值得关注的几个信息源开源鸿蒙的代码仓库和邮件列表。系统层面的变化会最先在这里体现比如新增了某个运行时接口、修改了权限模型这些都会直接影响 Agent 工具的可用性。Rust 和 Python 生态的 Agent 项目更新。很多项目会在 release notes 里提到增加了对某平台的支持鸿蒙 PC 的支持往往就是这么来的。鸿蒙开发者社区的实践分享。真正在鸿蒙 PC 上跑 Agent 的人不多但这些人分享的经验往往最有价值。我自己的很多坑就是从这些分享里提前避开的。6.2 自己维护一个可复现的测试环境比起追着别人的更新跑更靠谱的做法是自己维护一个可复现的测试环境。具体来说把鸿蒙 PC 的系统版本、兼容层版本、工具链版本都记录下来。每个 Agent 工具用一个独立的目录和配置文件互不干扰。定期比如每月跑一遍测试用例确认工具还能正常工作。把测试结果和遇到的问题记录下来形成自己的知识库。这样做的好处是当某个工具突然不能用了你能快速定位是系统更新导致的、还是工具本身的问题、还是配置被改了。我自己的测试环境已经跑了半年多积累了几十条问题记录现在遇到新问题基本能十分钟内定位。6.3 参与贡献把你的适配经验反馈回去如果你在鸿蒙 PC 上成功跑通了某个 Agent 工具建议把适配经验反馈给上游项目。方式可以是提 issue、提 PR、或者在项目讨论区发帖。这样做有两个好处一是帮助了后来者二是让项目维护者知道有人在鸿蒙 PC 上用后续版本可能会更重视这个平台的兼容性。我自己给两个 Rust 项目提过鸿蒙 PC 的适配 PR一个是修了编译时的架构判断一个是加了平台特定的配置项。虽然改动不大但维护者反馈很积极后续版本里直接合并了。这种正向循环对生态建设很重要。最后分享一个我自己的习惯我会在鸿蒙 PC 上保留一个干净的兼容环境里面只装最基础的工具链用来做对照测试。当某个 Agent 工具在主力环境里出问题时我会在干净环境里复现一遍这样能快速判断是环境被污染了还是工具本身的问题。这个习惯帮我省了很多排查时间推荐你也试试。