上周有人在群里甩了张截图他连着装了四五个 coding agent装完回头看命令历史清一色是npx xxx或者npm i -g xxx。他问我为什么市面上的 coding agent 大多数都基于 Node.js明明模型侧是 Python 的天下怎么一到 agent 这层就集体换船了。这个问题我琢磨过挺长时间。我自己做过 IDE 插件形态的 agent也从零写过命令行版本中间因为分发和依赖的破事返工过两次对运行时选型这件事的体感比看论文要深。先把结论放前面不是 Node.js 在技术上赢了而是它在让一个陌生人在三分钟内把东西跑起来这件事上赢了而 coding agent 恰好是一个极其吃分发体验的品类。下面我会按四条线索拆先核实大多数这个说法到底成不成立再讲分发链路为什么是决定性因素然后是 coding agent 的负载特征跟 Node 的契合点最后落到如果你要自己写一个从 Node 出发该怎么做、会在哪里疼。中间会夹一段我自己踩过的 PowerShell 拦 npm 的完整排查过程Windows 用户大概率会遇到。内容偏向有工程经验的读者但关键的原理部分我都会展开讲前端转过来的同学看也不会吃力。1. 先核实一下大多数这个说法1.1 我把常见项目按运行时列了张表讨论为什么之前得先确认现象是真的。下面这张表是我按印象整理的这些项目迭代都很快具体实现随时可能变请以各自仓库的最新代码为准项目主要形态核心运行时Claude CodeCLI IDE 插件Node / TypeScriptGemini CLICLINode / TypeScriptCodex CLICLI早期 TypeScript后部分组件重写为 RustCline / Roo CodeVS Code 插件TypeScript扩展宿主ContinueIDE 插件 CLITypeScript / NodeAiderCLIPythonOpenHandsWeb 服务 容器PythonSWE-agent研究型 CLIPythonGooseCLI 桌面端Rust看完表你会发现大多数这句话得加个限定条件面向日常开发者、以 IDE 插件或 CLI 形式分发的产品化 agentNode/TypeScript 占比明显更高而偏研究、偏评测、偏模型侧调优的项目Python 依然是主力。这两拨人的目标根本不一样——前者要的是用户能装上并且不卸载后者要的是我能快速改实验代码。1.2 真实原因不是Node 更强而是Node 的摩擦最小如果把选型当成一道加权评分题权重最高的一项往往不是性能、不是语言表达力而是从零到第一次成功运行的路径长度。这条路越短转化率越高项目传播越快社区反馈越多迭代越快——它是一个自我强化的正循环。Node 在这项上的得分不是最好而是最不容易出错。性能上它跑不过 Rust 或 Go类型系统比不上 Rust数据处理生态比不上 Python。但它在用户机器上大概率已经装了、装的时候不用管理员权限、装了之后一条命令能跑、跑完不污染全局环境这几件事上凑齐了一个非常难得的组合。换个角度想coding agent 的用户群体本身就是开发者而开发者的机器上Node 的渗透率是被一大批工具链硬拉上去的——ESLint、Prettier、Vite、Webpack、TypeScript 编译器、各种脚手架全都依赖它。你等于是在一个已经铺好的地基上盖房子。2. 分发链路的摩擦才是决定性因素2.1 一个 CLI 工具真实的成本在从零到跑起来很多人评估技术选型时习惯看这门语言写起来爽不爽但产品化 agent 的第一道生死线其实是安装。用户的心理预算大概是看到 README 里的一行命令复制、粘贴、回车三十秒内看到界面否则关掉页面。npx some-agent这条命令之所以被大量项目选为主推方式是因为它同时解决了好几个问题不需要全局安装、不需要管理员权限、不污染 PATH、自动拉取最新版、执行完可以缓存复用。对用户来说这是一次零承诺的尝试心理成本极低。当然npx也有代价比如每次冷启动可能有网络校验和版本检查在离线环境下会失败企业内网可能没法访问公共仓库。所以成熟项目通常会给两条路npx用于尝鲜全局安装或独立安装包用于长期使用。这个双轨策略几乎是 Node CLI 工具的标准做法了。2.2 换语言之后障碍会从哪冒出来Python 的障碍在环境隔离。写 Python 的人对此应该有肌肉记忆系统 Python 不能乱动很多系统工具依赖它于是要 venv、要 pipx、要处理多个 Python 版本共存。pipx 已经算是缓解方案了但它要求用户先知道 pipx 这个东西存在。另外 Windows 上的 Python 安装器还有Add to PATH这种默认不勾就容易翻车的选项。Rust 和 Go 的障碍在编译与平台矩阵。理想情况下你给每个平台产出一个静态二进制用户下载即用非常干净。但现实是你得维护 macOS 的 arm64/x64、Linux 的 glibc/musl、Windows 的 x64/arm64 这一整套构建流水线还要处理 macOS 的代码签名与公证。对一个两三个人的小团队这套基础设施的维护成本可能比业务代码还高。另外还有一层隐性成本想同时提供 CLI 和 IDE 插件时语言选择会被插件体系反向锁死。VS Code 扩展宿主是 Node你想进这个生态就只能用 TypeScript。这一点在第 4 节会展开它是很多项目被迫选 Node 的直接原因。2.3 npm 那套约定俗成省掉的是沟通成本npm 生态有一个被严重低估的价值它的约定足够统一。package.json里的bin字段、engines字段、files白名单、.npmrc配置这些东西全球一致用户看到就知道怎么用。对比一下其他语言Python 有 setup.py、setup.cfg、pyproject.toml 三代并存的过渡期Rust 的 cargo 虽然统一但分发依赖 crates.io 与自建渠道Go 的模块系统也经历过一段混乱。npm 这方面虽然历史包袱重但表层接口的稳定性反而更好。对 agent 这种工具本身还要调用一堆外部命令的品类来说统一约定还有一个额外好处可以在postinstall里下载对应的二进制比如 ripgrep或者干脆把跨平台二进制作为可选依赖分发。vscode/ripgrep就是这么干的它在optionalDependencies里按平台列出不同的包npm 只会装当前平台需要的那一个。这套机制其他生态要么没有要么需要自己造。3. coding agent 的负载特征恰好和 Node 对得上3.1 它几乎全是 I/O 等待而不是 CPU 计算把 agent 的一个完整回合拆开看把上下文序列化发给模型、等模型返回几百毫秒到几十秒、解析返回、读取几个文件、跑一次搜索、执行一条命令、再等模型。这整个过程里本地 CPU 真正在算的时间可能不到百分之几其余全是在等网络、等磁盘、等子进程。Node 的事件循环模型天生就是为这种负载设计的。它只有一个 JS 执行线程但 I/O 全部走异步回调等待期间不占线程。一个回合里同时读五个文件、跑两次搜索写起来就是Promise.all一行的事不需要操心线程池大小、锁、GIL 这些概念。这里要说句公道话Python 的 asyncio 同样能做这件事Aider 就做得很好。但 Python 生态的一个现实问题是大量历史库是同步阻塞的一个同步的 HTTP 客户端或在事件循环里调用的阻塞函数就能把整个循环卡住。你得像排雷一样逐个确认依赖是否异步友好。Node 生态虽然也有 CPU 密集的库图像处理、加密、压缩但主流的文件、网络、进程操作从第一天起就是异步的。3.2 流式输出和工具调用结构上和 async/await 是同一个形状所有主流模型的 API 都是流式的服务端不断推 SSE 事件过来客户端边收边渲染。这在 Node 里几乎不需要额外的抽象——原生fetch返回的body就是一个ReadableStreamasync迭代器直接消费配合for await语法非常顺手。工具调用这一层也对得很齐。模型返回的 tool use 是一个 JSON 对象本地执行的本质是解析参数 → 调用函数 → 拿返回值 → 序列化回去。这个链路用 async 函数表达就是最自然的写法不需要额外的调度框架。举个实际的例子一个最小可用的工具定义长这样import { z } from zod; const ReadFileArgs z.object({ path: z.string().describe(相对于工作区根目录的文件路径), offset: z.number().int().min(1).optional().describe(起始行号从 1 开始), limit: z.number().int().min(1).max(2000).optional().describe(最多读取的行数) }); export const readFileTool { name: read_file, description: 读取工作区内的文本文件可指定行区间避免一次性读入整个大文件, schema: ReadFileArgs, async run(args: z.infertypeof ReadFileArgs, ctx: { root: string }) { const abs resolveWithin(ctx.root, args.path); const text await fs.readFile(abs, utf8); const lines text.split(/\r?\n/); const start (args.offset ?? 1) - 1; const end args.limit ? start args.limit : lines.length; return lines.slice(start, end).join(\n); } };注意resolveWithin这个函数它是防止模型用../../etc/passwd这类路径逃出工作区的第一道闸。这类边界检查在 agent 里属于必做项后面第 8 节还会再提。3.3 CPU 密集的那部分怎么甩出去Node 不是没有性能陷阱。真正会卡住事件循环的活儿通常是这几类对大目录做递归遍历和模式匹配、用 tree-sitter 解析大文件、计算文件 diff、对超长上下文做分词计数。处理思路有三条按优先级排优先用外部二进制。搜索直接用 ripgrep、文件列表用 fd、git 操作用 git 本身。这些工具是编译型语言写的性能比任何 JS 实现都好而且你只需要解析它们的--json输出。这是最省事的做法。其次用 worker_threads。把解析、diff 这类纯计算任务丢进 worker主线程继续处理 UI 和 I/O。代价是数据传输需要序列化小任务反而不划算。最后才是自己优化。比如分词不要每次都重算按文件内容哈希做缓存。还有一条容易忘的如果 agent 需要跑子进程一定不要用spawnSync。同步版本会阻塞整个事件循环用户的界面上会直接卡住。用异步spawn并且记得在超时后把整个进程树都杀掉——Windows 上child.kill()默认只杀直接子进程需要taskkill /pid xxx /T /F才能连带孙进程一起处理。4. 真正的引力源整个编辑器和语言工具生态都在 TypeScript 这边4.1 LSP、语法高亮、解析器现成的全在 TS 侧这是我认为最关键、但被讨论得最少的一条。coding agent 要做到懂代码需要这几块能力知道符号在哪定义、知道语法结构、把代码渲染得有辨识度、做精确的文本替换。而这些能力对应的现成基础设施恰好都在 TypeScript 生态里LSP 客户端协议vscode-languageserver-protocol这套包是微软维护的用 TS 写的其他语言要接 LSP 得自己实现一遍协议类型。语法高亮TextMate 语法.tmLanguage和 Shiki、highlight.js 都是 JS 生态的产物VS Code 的主题直接能复用。增量解析web-tree-sitter是编译成 WASM 的能在 Node 里直接跑ast-grep/napi提供了原生绑定做结构化搜索和改写非常方便。diff 与补丁diff、parse-diff、diff-match-patch这些库覆盖了几乎所有补丁场景。这些不是能用而是已经在 VS Code 里打磨了十年。你在 Node 上写 agent等于白嫖了一套编辑器级别的语言工具链。换到其他语言光是接 LSP 和做语法高亮就够喝一壶。4.2 一套逻辑要同时跑在 CLI、插件、Web 面板三个壳里现在的 agent 产品很少只做终端。典型形态是终端里有个 CLI 用于脚本化和批处理编辑器里有个插件用于交互式改代码可能还有个 Web 面板用于看历史和团队协作。VS Code 扩展宿主是 Node 进程所以插件部分只能用 TS/JS。既然插件必须用 TS那理性的选择就是把核心逻辑提示词组装、工具调度、上下文裁剪、模型调用抽成一个独立的 npm 包CLI 和插件都依赖它。这样选 Node就不是偏好问题而是被架构倒逼的结果。我自己的做法是把代码分成三层core包纯逻辑不依赖任何终端 API也不依赖 VS Code API、cli包提供终端界面、extension包提供编辑器集成。三层之间的接口用纯数据定义这样核心逻辑可以单独做单元测试不需要起一个真实的编辑器环境。这个分层在项目早期多花两天时间后面省的时间是几十倍。4.3 类型系统的第二重身份给模型看的契约这一点挺有意思。在 agent 里TypeScript 的类型定义不只是给编译器和人类看的它还是给模型看的接口文档。你用 Zod 定义一个参数的 schema可以同时做三件事运行时校验模型返回的参数、生成 JSON Schema 塞进工具定义里给模型看、给调用方提供编译期类型推导。一份定义三处复用这在其他语言里要么需要额外的代码生成要么需要手写一套 schema。import { zodToJsonSchema } from zod-to-json-schema; const tools [readFileTool, grepTool, applyPatchTool].map(t ({ name: t.name, description: t.description, input_schema: zodToJsonSchema(t.schema, { target: jsonSchema7 }) }));description字段的写法其实很讲究。我踩过的坑是描述写得太笼统模型就会乱用工具写得太长又会挤占上下文。经验法则是描述里要包含什么时候该用这个工具以及什么时候不该用而不是只写这个工具能干什么。比如grep的描述里加上一句查找文本时优先用它而不是逐文件读取能显著减少模型盲目读文件的行为。5. coding agent 需要的那几块拼图JS 生态恰好都齐了5.1 文件遍历、搜索、diff这三个基础件需求我实际用过的包备注递归遍历与匹配tinyglobby、fast-glob后者功能全但依赖多前者更轻忽略规则解析ignore直接读.gitignore省得自己写规则文件变更监听chokidar跨平台差异处理得很到位文本搜索vscode/ripgrep提供二进制不要用 JS 自己实现搜索结构化搜索改写ast-grep/napi按语法树匹配比正则靠谱得多补丁解析与应用diff、parse-diff配合自定义的模糊匹配逻辑git 操作simple-git底层还是调 git 命令行这里有一条很重要的经验不要让模型输出统一 diff 格式让它输出精确的旧文本片段 新文本片段。原因是 diff 带行号和上下文行模型稍微数错行号或者省略一段中间行补丁就应用失败了。而精确文本块匹配的容错率高得多本质上就是做一次字符串查找替换找不到就报错让模型重试逻辑简单很多。如果非要用统一 diff就必须自己写模糊匹配层先精确匹配失败则忽略空白差异匹配再失败则按相似度找最接近的块。这类逻辑在 Aider 的代码里能看到比较完整的实现思路值得参考。5.2 终端界面的成熟度被严重低估很多人对 Node 写 CLI 的印象还停留在输出一堆带颜色的日志。实际上这块的生态已经非常成熟了Ink让你用 React 组件写终端界面布局和状态管理的心智模型跟写网页一样。clack/prompts提供了一套交互体验很现代的提问式界面适合初始化配置流程。ora做加载动画chalk或picocolors做颜色cli-table3做表格。node-pty提供真正的伪终端能跑需要 TTY 的交互式程序。这里有个实际设计问题agent 的输出是流式的而且要一边流式输出一边允许用户按键中断。你需要把 stdin 切到 raw mode、处理 CtrlC、处理窗口 resize 事件、还要在非 TTY 环境比如被管道接走时自动降级成纯文本。这几个分支我建议一开始就写清楚不要等出问题了再补因为它们的代码路径互相纠缠后期改起来很麻烦。另一个容易被忽略的是交替屏幕缓冲。全屏 TUI 程序通常会切到备用缓冲区退出时切回来这样不会污染用户的终端历史。但如果你同时还要支持管道输出和日志重定向就得判断process.stdout.isTTY再决定走哪条路径。5.3 进程管理与 PTY是 agent 干活的双手agent 最终要落地成改文件 跑命令。跑命令这块Node 的child_process提供了spawn、exec、fork三种模式配合AbortSignal可以统一处理超时和取消。几个实务要点用spawn而不是exec因为exec会把整个输出缓存在内存里跑一个输出几十兆的命令就容易炸。参数一律用数组形式传不要拼字符串避免引号和空格带来的注入风险。一定要设置超时。默认不设超时的话一个等待输入的交互式命令会把 agent 卡死。stderr 和 stdout 要分开收很多命令把进度信息写 stderr混在一起会让模型误判。如果你要支持交互式命令比如跑一个需要确认的构建脚本就得用node-pty而不是spawn因为普通管道模式下很多程序会检测到没有 TTY 而改变行为甚至直接退出。6. 反例和边界没选 Node 的那些项目在想什么6.1 Python 阵营的理由很实在Aider 是 Python 写的而且做得相当好。它选 Python 的理由很直接模型 SDK 的首发支持通常在 Python 侧评测脚本SWE-bench 那一类本身就是 Python 写的研究社区共享的代码片段九成是 Python。对于一个算法策略需要反复实验的项目语言之间的摩擦全在实验迭代上而不是在分发上。SWE-agent 这类项目更是如此它们的用户是研究者愿意为了复现结果去配一个 conda 环境。这种情况下安装麻烦根本不是问题因为用户本来就在一个已经配好的环境里工作。所以判断标准很清楚用户是终端用户还是研究者。前者要开箱即用后者要可改可复现。6.2 Rust 和 Go 的诱惑在于单二进制Rust 阵营的吸引力是实打实的编译出一个几兆的静态二进制用户下载就能跑没有运行时依赖没有版本冲突冷启动在毫秒级内存占用稳定可控。对一个需要在容器里频繁启动的 agent 来说这些优势非常明显。而且现在有个新趋势不少评测环境会把 agent 打进容器镜像里跑镜像大小和启动时间直接影响评测吞吐。Python 或 Node 的运行时加上依赖树镜像动辄几百兆到一两个 G换成静态二进制可能只有几十兆。所以有些项目选择了核心用 Rust 写、只留一个薄薄的外壳用脚本语言这种混合架构。代价也很直接开发速度慢终端界面和 HTML 渲染的生态弱人才池小。一个需要快速迭代提示词和工具策略的产品用 Rust 写会痛。6.3 Bun 和 Deno 带来的新变量Bun 的卖点很对 agent 的胃口可以直接跑 TypeScript 不用编译步骤内置打包器和包管理器还支持编译成单文件可执行程序。这就把Node 生态丰富和单二进制分发两个优势拼到一起了。目前主要的顾虑是运行时稳定性和某些原生模块的兼容性。Deno 的权限模型值得一提。它默认禁止文件读写和网络访问要用--allow-read、--allow-net显式开启。对一个要执行模型生成命令的程序来说这种默认拒绝的设计思路是对的——虽然实际项目里很少有人真的给 agent 套上这层但方向值得借鉴。真正的沙箱还是得靠容器或者系统级的隔离机制。7. 从 Node 出发搭一个最小 agent 的骨架7.1 环境准备先把版本固定住如果你要开始动手第一步不是写代码而是把 Node 版本管理好。我见过太多在我机器上能跑的事故根源都是 Node 大版本不一致。推荐用版本管理器Windows 上可以用nvm-windows或fnmmacOS 和 Linux 上fnm或volta都行。然后在项目里写死版本{ name: my-agent, type: module, engines: { node: 20.0.0 }, packageManager: pnpm9.0.0 }同时在仓库根目录放一个.nvmrc内容写20或者22。这样团队成员nvm use一下就能对齐。engines字段虽然 npm 默认只警告不阻止但配上engine-stricttrue就变成硬性检查了。包管理器我建议用 pnpm它对依赖的隔离更严格能避免幽灵依赖——也就是你用了没写在package.json里的包本地能跑但别人装了就报错。另外 pnpm 的磁盘占用和安装速度也更好。还有一点packageManager字段配合 Corepack 可以自动锁定包管理器版本避免你用 npm 9 我用 npm 10导致的锁文件格式冲突。7.2 工具层最小闭环就五个工具一个能用的 coding agent工具不需要多。我实践下来最小集合是五个list_dir列出目录内容用于让模型了解项目结构。read_file读文件必须支持行区间否则一个大文件就能把上下文撑爆。grep文本搜索底层调 ripgrep返回匹配的文件名和行号。apply_patch基于精确文本块替换的改写工具。run_command执行命令返回退出码和输出。这五个工具之外我建议再加一个todo_write之类的规划工具。它不操作任何外部状态纯粹是让模型把计划写下来然后后续每轮都能看到自己的计划。这个技巧对长任务的稳定性提升很明显成本几乎为零。工具的执行要统一走一个调度层而不是散落在各处。调度层的职责包括参数校验、权限检查、超时控制、结果截断、日志记录。结果截断尤其重要——run_command的输出可能有几万行直接塞给模型会瞬间吃满上下文通常会限制在几百行并加上输出已截断的提示。7.3 主循环与流式解析的写法要点主循环的结构其实很简单组装消息 → 调用模型 → 解析流式响应 → 如果有工具调用就执行 → 把结果追加进消息 → 再来一轮直到模型不再调用工具或者达到最大轮数。真正容易出错的是流式解析。SSE 协议以空行分帧一个data:行只是一帧的一部分而网络分片完全不保证和帧边界对齐。这意味着你不能用按行读取的方式处理流必须维护一个缓冲区。async function* parseSSE(res: Response) { const reader res.body!.getReader(); const decoder new TextDecoder(); let buf ; while (true) { const { value, done } await reader.read(); if (done) break; buf decoder.decode(value, { stream: true }); let idx: number; while ((idx buf.indexOf(\n\n)) ! -1) { const frame buf.slice(0, idx); buf buf.slice(idx 2); const payload frame .split(\n) .filter(line line.startsWith(data:)) .map(line line.slice(5).trim()) .join(); if (!payload || payload [DONE]) continue; yield JSON.parse(payload); } } }这里有两个细节值得注意。第一是decoder.decode(value, { stream: true })里的stream: true它保证多字节字符比如中文被网络分片切断时不会解码成乱码。第二是每帧的data:可能有多行需要拼接而不是只取第一行。工具调用的参数在流式响应里通常是分片到达的你得先把这些分片拼成完整的 JSON 字符串再解析解析失败就丢弃或者报错重试。这块各家 API 的格式略有差异建议写一层适配层把不同厂商的流式格式统一成内部事件文本增量、工具调用开始、工具参数增量、结束。8. 踩坑实录Node 路线上真实会疼的地方8.1 npm.ps1 被禁止运行脚本的完整排查链路这是 Windows 用户最容易撞上的一堵墙现象是执行npm -v直接报错无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。排查思路是这样的第一步确认 PowerShell 是怎么找到这个命令的。PowerShell 在执行命令时会按照PATHEXT里定义的扩展名顺序在 PATH 目录里查找而 Node 安装包在同一个目录里放了三个文件npm给 Git Bash 用的 shell 脚本、npm.cmd给 cmd.exe 用的批处理、npm.ps1给 PowerShell 用的脚本。PowerShell 优先选中.ps1于是它就去执行脚本了。第二步确认策略拦住了什么。执行Get-ExecutionPolicy -List可以看到各作用域的策略。Windows 客户端版本的默认值通常是Restricted这个级别会禁止执行所有.ps1脚本不管来源。这就是根因——不是 npm 装坏了是策略不允许。第三步选修复方式。三种做法取舍不一样方案命令影响范围我的建议改当前用户策略Set-ExecutionPolicy -Scope CurrentUser RemoteSigned只影响当前用户推荐覆盖面适中只放开当前会话Set-ExecutionPolicy -Scope Process Bypass只影响这个窗口临时调试可用重开就失效直接绕开改用npm.cmd -v或换 cmd.exe/Git Bash无应急可用但很多脚本内部还是调 npmRemoteSigned的含义是本地创建的脚本可以跑从网络下载的脚本必须有数字签名。这个级别在安全性和便利性之间比较平衡也是很多开发环境的标准配置。注意修改当前用户作用域不需要管理员权限这是个常见误解。这里有个坑我要特别提醒公司的组策略可能把MachinePolicy或UserPolicy作用域设成Restricted这种情况下你用Set-ExecutionPolicy改CurrentUser是无效的因为策略的优先级是MachinePolicy UserPolicy Process CurrentUser LocalMachine。Get-ExecutionPolicy -List会把这些作用域都列出来如果看到前两个不是Undefined那就说明有更高优先级的策略在压着得找 IT 处理。改完之后验证Get-ExecutionPolicy -Scope CurrentUser应该返回RemoteSigned然后再跑npm -v。别忘了重启一下终端因为策略是在会话启动时读取的。另外还有一类相关问题如果你用的是 pnpm那还涉及pnpm.ps1如果用了 Corepack会有corepack.ps1。它们遇到的是同一个问题解决方式也一样。8.2 依赖体积、冷启动和内存Node 路线的三个固有痛点我按实际影响排一下。依赖体积最直观。一个中等规模的 agent 项目node_modules轻松上到两三百兆因为很多包会带上源码、类型声明、测试 fixture 和文档。这些在发布时可以靠files字段白名单过滤但开发环境躲不掉。如果要把 agent 打进容器镜像一定要用多阶段构建只把打包产物拷进最终镜像不要整个node_modules一起带上。冷启动的体感比数字更重要。Node 进程启动本身大概几十到一百多毫秒npx还要加一层版本检查。单次调用感知不强但如果你的 agent 每处理一次工具调用就起一个 Node 子进程累积起来就很明显了。所以原则是长驻进程 少量子进程把所有工具都跑在同一个 Node 进程里。内存要盯着。默认的堆上限在不同版本和机器上不一样处理超大文件或者积累很长的会话历史时可能撞上限。可以用--max-old-space-size调整但更好的做法是从源头控制——限制单个文件读取的大小、对会话历史做滚动裁剪、大对象用完及时释放引用。8.3 依赖供应链和权限边界npm 生态的包数量庞大质量参差不齐历史上出过恶意包事件。对一个会执行模型生成命令的 agent 来说这两件事叠在一起风险不小。几个实际能做的事提交锁文件并且用npm ci或pnpm install --frozen-lockfile做可重复安装不要让 CI 自己解析版本范围。考虑--ignore-scripts禁止安装时自动执行脚本。这会挡掉一部分正常的原生模块编译所以要看项目实际情况。审核依赖数量。写工具前先想清楚这个功能值不值得引入一个新依赖。有次我为了做个进度条引了个包结果它带了十几个传递依赖后来自己写了三十行 ANSI 代码替换掉了。固定发布版本不要在生产环境用npx latest。权限边界这块最容易被忽略的是路径校验。所有文件操作都必须把路径规范化后检查它是否在允许的根目录内还要注意符号链接可能绕过检查。命令执行则要做白名单或者至少做危险模式的拦截同时给出明确的用户确认环节——不是每个操作都问而是对写文件、删除、执行任意命令这类操作问。我自己的做法是把权限分成三档只读操作读文件、搜索、列目录自动放行写操作改文件、创建文件在交互模式下需要确认在批处理模式下按配置决定执行命令默认需要确认但可以配置一个用户维护的安全命令列表比如git status、ls、测试命令走快速通道。这套分档跑下来既不会烦到用户也不会让 agent 有机会搞出无法挽回的事情。最后分享一个具体的观察这套东西真正的难点从来不在调用模型 API那部分可能只占总代码量的百分之五。剩下的百分之九十五全在上下文怎么裁剪、工具描述怎么写清楚、报错了怎么让模型自己纠正、界面怎么在流式输出时不闪烁这些琐事上。语言选型能帮你省掉其中一部分分发、编辑器集成、语言工具链但另一部分无论用什么语言写都得老老实实啃。所以与其纠结运行时不如早点把工具层和调度层的接口设计干净那才是后面改起来最贵的地方。