解决AI编码助手进程残留：Kiro ACP包装器设计与实战

1. 项目概述：Kiro ACP 包装器的诞生与使命

如果你正在探索如何将 Kiro CLI 这个强大的 AI 编码助手无缝集成到 OpenClaw 的 ACP 运行时中，以实现持久的、支持多轮对话的编码会话，那么你很可能已经遇到了那个令人头疼的“幽灵进程”问题。这正是haliphax-ai/kiro-acp这个 Node.js 包装器项目要解决的核心痛点。简单来说，它是一座精心设计的桥梁，专门用来弥合kiro-cli与acpx运行器之间的一个关键生命周期鸿沟。这个项目不是简单的命令转发，而是一个针对特定“僵尸进程”问题的外科手术式解决方案，确保了会话的持久性和稳定性。

想象一下这个场景：你通过 OpenClaw 启动了一个 Kiro 会话，愉快地进行了一轮代码重构。当你结束任务，进程理应退出。但当你试图开启一个新会话时，却迎面撞上“Session is active in another process”的错误。这感觉就像你离开了房间却忘了关灯，门还被反锁了，导致你无法再次进入。问题的根源在于，kiro-cli在运行时，会悄悄地生成一个名为kiro-cli-chat的子进程。当父进程kiro-cli被终止时，这个子进程却常常“赖着不走”，像一个幽灵一样继续持有会话锁。标准的进程组终止信号对它无效，因为它运行在一个独立的进程组中。kiro-acp-wrapper的使命，就是充当一位尽职尽责的“清道夫”，在每次会话结束时，不仅关闭大门，还会深入每个房间，确保所有灯都已熄灭，所有进程（包括那些顽劣的子进程）都被彻底清理干净，为下一次会话扫清障碍。

这个包装器适合任何希望在 OpenClaw 生态中稳定、持久地使用 Kiro 进行 AI 辅助开发的工程师。无论你是想构建一个复杂的多步代码生成流水线，还是需要一个能记住上下文的长期编程伙伴，这个项目都提供了可靠的基础设施。它通过明确的进程树发现和清理机制，辅以精心设计的延迟等待，实现了真正的会话持久化，让你可以像与人类协作者对话一样，与 Kiro 进行连续、有上下文的多轮交互。

2. 核心设计思路与架构拆解

2.1 问题根源：进程生命周期管理的缺失

要理解这个包装器的设计，必须首先深入理解它要解决的问题的本质。在典型的命令行工具集成中，我们习惯于启动一个进程，进行交互，然后终止它。然而，kiro-cli的架构引入了一个复杂性：它采用了主从进程模型。主进程 (kiro-cli) 负责参数解析、配置加载和会话管理，而实际的、可能与远端 AI 模型进行网络通信和状态维护的“聊天”核心，则被委托给一个独立的子进程 (kiro-cli-chat)。这种设计可能源于模块分离、稳定性或资源管理的考虑。

当通过 ACP 协议调用时，acpx运行器会启动我们配置的代理命令（即包装器）。包装器随后启动kiro-cli acp子进程。问题出现在终止环节。如果包装器或acpx简单地通过 SIGTERM 信号终止kiro-cli主进程，那个 detached 状态的kiro-cli-chat子进程很可能成为“孤儿进程”，被系统的 init 进程（PID 1）接管，但它仍然持有最初会话的文件锁或套接字连接。当下一个包装器实例启动一个新的kiro-cli进程并尝试复用同一个会话时，系统会发现该会话资源仍被占用，从而抛出“Session is active in another process”错误。

2.2 解决方案：主动的进程树清理策略

面对这个问题，有几种潜在的解决思路。最简单粗暴的方法是每次会话后都用pkill -9强制杀死所有相关进程，但这会破坏优雅退出的机会，可能导致资源泄漏或数据丢失。另一种方法是修改kiro-cli本身的源码，使其子进程能随父进程优雅退出，但这依赖于上游项目的改动，不可控且周期长。

kiro-acp-wrapper选择了一条更实用、更可控的中间道路：在包装器层面实现一个健壮的进程树清理机制。其核心设计哲学是“谁创建，谁负责清理”。既然包装器是kiro-cli进程的创建者，那么它就有责任确保这个进程及其所有后代都被妥善终止。这个策略的关键在于两点：一是准确发现所有后代进程，二是在清理过程中引入合理的延迟，确保系统有足够时间释放资源。

2.3 架构流程与组件交互

整个包装器的工作流程可以分解为几个清晰的阶段：

1. 启动阶段：包装器被acpx调用，解析传入的参数和环境变量（如日志路径、代理名称、模型选择）。随后，它使用 Node.js 的child_process.spawn方法，以detached: true的模式启动kiro-cli acp进程。这个detached选项是关键，它允许子进程在父进程退出后继续存在，但同时也使得包装器后续需要更精细的手段来追踪和清理它。

2. 代理阶段：包装器在kiro-cli进程的标准输入（stdin）、标准输出（stdout）和标准错误（stderr）与acpx运行器之间建立管道。所有数据流都经过包装器转发，这为可选的日志记录提供了钩子。在此期间，包装器自身几乎不处理业务逻辑，仅充当一个透明的、可观察的字节流通道。

3. 清理阶段：这是包装器的核心价值所在。当acpx关闭输入流（发送 EOF）或发送 SIGTERM 信号时，包装器启动清理序列。它首先获取kiro-cli主进程的 PID，然后利用pgrep -P <pid>命令递归地查找所有直接和间接的子进程 PID。接着，它按照“从叶子到根”的顺序，先向所有后代进程发送 SIGTERM 信号，等待一秒，再向主进程发送 SIGTERM，再等待一秒。最后，包装器自身再延迟半秒后退出。这个总长约 3.5 秒的延迟链，是确保锁被释放、端口被关闭、临时文件被删除的关键。

注意：选择pgrep而不是纯 Node.js 的进程管理模块，是基于实用性的考虑。pgrep是 Unix/Linux 系统的标准工具，能稳定、高效地遍历进程树。在 Node.js 中实现同等功能的跨平台代码会更复杂，且可能不如系统工具可靠。

3. 部署与配置详解

3.1 环境准备与前置检查

在开始配置之前，你需要确保基础环境已经就绪。这个包装器本身是 Node.js 脚本，但它依赖于几个外部组件。

首先，确认Node.js已安装。包装器代码相对简单，对 Node.js 版本要求不苛刻，通常 Node.js 12 及以上版本均可运行。你可以通过node --version来检查。

其次，也是最重要的，是Kiro CLI的安装与配置。包装器并不包含 Kiro CLI 本身，它只是一个“调度员”。你必须按照 Kiro 官方的指南正确安装kiro-cli，并确保其可执行文件位于系统的 PATH 环境变量中。一个快速的验证方法是打开终端并执行：

which kiro-cli

这条命令应该返回kiro-cli可执行文件的完整路径，例如/usr/local/bin/kiro-cli。如果返回“not found”，你需要重新安装或调整 PATH。此外，请确保你已经完成了 Kiro 的认证登录（通常通过kiro-cli login命令），因为未经认证的 CLI 无法调用 AI 服务。

最后，你需要OpenClaw 环境以及其中的acpx运行器。OpenClaw 是一个更大的 AI 智能体开发生态，ACP 是其定义的智能体控制协议。你需要确保 OpenClaw 项目已正确设置，并且acpx命令可用。

3.2 包装器脚本的获取与放置

接下来是包装器本身。你可以直接从haliphax-ai/kiro-acp仓库克隆或下载kiro-acp-wrapper.js这个单文件脚本。你需要将它放置在一个合适且永久的位置，因为 OpenClaw 的配置需要引用它的绝对路径。

一个常见的做法是为你的 AI 开发工具创建一个专属目录，例如~/ai-tools/。你可以在此目录下克隆整个仓库或只下载脚本文件：

mkdir -p ~/ai-tools cd ~/ai-tools git clone https://github.com/haliphax-ai/kiro-acp.git # 或者直接下载脚本 curl -o kiro-acp-wrapper.js https://raw.githubusercontent.com/haliphax-ai/kiro-acp/main/kiro-acp-wrapper.js

下载后，建议给脚本添加可执行权限，虽然这不是必须的（因为 Node.js 会直接解释执行），但有时能避免一些权限问题：

chmod +x ~/ai-tools/kiro-acp/kiro-acp-wrapper.js

3.3 OpenClaw ACP 配置实战

OpenClaw 的代理配置集中在用户主目录下的~/.acpx/config.json文件中。如果这个文件或目录不存在，你需要手动创建。

mkdir -p ~/.acpx

现在，用你喜欢的文本编辑器打开（或创建）~/.acpx/config.json文件。其基本结构是一个 JSON 对象，其中agents字段下定义了各个可用的代理。

基础配置：这是最简形式，直接使用默认的 Kiro 代理和模型。

{ "agents": { "kiro": { "command": "/home/your-username/ai-tools/kiro-acp/kiro-acp-wrapper.js", "runtime": "acp", "description": "Kiro CLI development agent" } } }

请务必将command路径替换为你实际存放kiro-acp-wrapper.js脚本的绝对路径。runtime必须设置为"acp"，这是告诉acpx使用 ACP 协议与代理通信。description字段是帮助你在 OpenClaw UI 或日志中识别这个代理的。

启用调试日志：在集成初期或遇到问题时，启用日志是至关重要的排错手段。你可以通过环境变量KIRO_ACP_WRAPPER_LOG指定一个日志文件路径。

{ "agents": { "kiro-debug": { "command": "/home/your-username/ai-tools/kiro-acp/kiro-acp-wrapper.js", "runtime": "acp", "description": "Kiro with debug logging", "env": { "KIRO_ACP_WRAPPER_LOG": "/tmp/kiro-acp-debug.log" } } } }

注意，环境变量是在env对象中配置的，这会由acpx在启动包装器时注入。日志文件（如/tmp/kiro-acp-debug.log）需要有可写权限。

自定义代理与模型：Kiro CLI 支持通过命令行参数指定使用哪个预配置的“代理”以及 AI 模型。包装器完美地将这些参数转发给底层的kiro-cli。这在你想针对不同任务使用不同特化的 Kiro 配置时非常有用。

{ "agents": { "kiro-refactor": { "command": "/home/your-username/ai-tools/kiro-acp/kiro-acp-wrapper.js --agent code-specialist --model claude-3-opus --trust-all-tools", "runtime": "acp", "description": "Kiro configured for heavy refactoring tasks" }, "kiro-docs": { "command": "/home/your-username/ai-tools/kiro-acp/kiro-acp-wrapper.js --agent documentation --model claude-3-sonnet", "runtime": "acp", "description": "Kiro tuned for documentation generation" } } }

在这个例子中，我们定义了两个不同的代理入口：kiro-refactor使用一个专注于代码的代理配置和强大的 Opus 模型，并信任所有工具调用；kiro-docs则使用一个为文档优化的代理和 Sonnet 模型。你可以在 OpenClaw 中根据任务类型灵活选择。

实操心得：在配置路径时，我强烈建议使用绝对路径，而非相对路径或依赖$HOME环境变量。因为acpx运行时的环境可能与你的交互式 Shell 环境不同，相对路径容易导致“找不到命令”的错误。另外，在 JSON 中配置命令行参数时，确保整个command字符串是一个完整的、可直接在 Shell 中执行的命令。

4. 核心工作流程与代码级解析

4.1 启动与进程生成：细节中的魔鬼

包装器的启动逻辑始于 Node.js 脚本的标准入口。它首先会检查是否设置了KIRO_ACP_WRAPPER_LOG环境变量，如果设置了，就会创建一个可写流用于记录日志。这个日志对于理解包装器内部行为和排错至关重要。

接下来是参数处理。包装器使用process.argv获取命令行参数。关键之处在于，它不会尝试解析或修改这些参数（除了可能移除自身的脚本名），而是将它们原封不动地传递给即将生成的kiro-cli进程。这种“透明转发”的设计减少了耦合，使得包装器无需关心 Kiro CLI 参数格式的变化。

生成子进程是核心操作，这里有几个精妙的细节：

// 这是一个概念性代码，展示关键参数 const child = child_process.spawn('kiro-cli', ['acp', ...args], { stdio: ['pipe', 'pipe', 'pipe'], // 建立 stdin, stdout, stderr 管道 detached: true, // 允许子进程在父进程退出后独立存在 // 注意：没有设置 `shell: true`，这避免了额外的 shell 进程层 });

• detached: true：这个选项是双刃剑。它使得kiro-cli进程脱离了与包装器进程的“领导”关系，从而不会被包装器进程收到的信号（如 SIGINT）默认连带终止。这正是后续需要手动清理进程树的原因，也是解决“子进程残留”问题必须面对的挑战。
• stdio: ['pipe', 'pipe', 'pipe']：三个管道分别对应标准输入、输出和错误。包装器随后会监听这些管道上的data事件，将数据从acpx转发到kiro-cli，或者反向转发。同时，如果启用了日志，它会将数据流（标注方向）写入日志文件。

进程生成后，包装器会记录主进程的 PID。这个 PID 是后续整个清理操作的“根”。

4.2 数据流代理与日志记录：让通信可见

在进程运行期间，包装器扮演着一个“接线员”的角色。它设置了四个关键的事件监听器：

1. 对acpx的输入：监听包装器自身的process.stdin，将收到的数据写入child.stdin（发给kiro-cli），同时可选地在日志中标记为[IN]。
2. 来自kiro-cli的输出：监听child.stdout，将数据写入process.stdout（发回给acpx），日志标记为[OUT]。
3. 来自kiro-cli的错误：监听child.stderr，将数据写入process.stderr，日志标记为[ERR]。这确保了kiro-cli的任何错误信息都能传递到acpx和最终用户。
4. 子进程退出：监听child的exit事件。虽然清理主要由包装器主动触发，但监听子进程自然退出也是一个安全措施。

日志格式的设计非常清晰。每一条日志都带有时间戳和方向标签，让你可以精确地重建一次会话中发生的所有数据交换。例如，当你发送一个代码片段给 Kiro 时，你会在日志中看到[IN]后面跟着你的代码；Kiro 的回复则会以[OUT]开头。任何来自 Kiro CLI 的警告或错误信息则会出现在[ERR]行中。

4.3 清理流程的深度剖析：确保万无一失

清理流程是包装器最复杂也最重要的部分。它由两个主要事件触发：process.stdin的end事件（表示acpx关闭了输入连接），或者进程收到 SIGTERM 信号。

清理函数cleanup的执行逻辑是一个精心编排的序列：

1. 防止重复清理：首先设置一个cleaningUp标志。如果清理函数被多次调用（理论上可能发生），这个标志能确保清理逻辑只执行一次。

2. 查找后代进程：这是最关键的一步。包装器使用execSync('pgrep -P ' + pid)来获取指定 PID 的所有直接子进程的 PID 列表。但kiro-cli-chat可能只是第一代子进程。为了确保彻底，包装器需要递归地查找。原始项目文档提到它查找“所有后代进程”，这意味着它可能实现了一个循环或递归函数，不断对找到的子进程 PID 再次调用pgrep -P，直到找不到新的子进程为止，从而构建出完整的进程树。

3. 顺序终止：获取到所有后代进程的 PID 列表后，包装器开始“剪枝”。它首先向列表中的每一个后代进程发送 SIGTERM 信号。SIGTERM 是一个“礼貌”的终止请求，进程可以捕获这个信号并执行一些清理工作（如关闭文件、回滚事务）后再退出。这比 SIGKILL（即kill -9）要优雅得多。

4. 引入延迟（第一轮）：发送完 SIGTERM 后，包装器使用setTimeout等待 1000 毫秒（1秒）。这个延迟至关重要。操作系统处理信号、进程执行退出处理程序、内核释放资源（如文件锁、网络端口）都需要时间。立即进行下一步操作可能导致资源竞争。

5. 终止主进程：等待一秒后，包装器向最初的kiro-cli主进程发送 SIGTERM 信号。

6. 引入延迟（第二轮）：再次等待 1000 毫秒，让主进程有时间完成它的清理工作。

7. 包装器自毁：最后，包装器进程自己再等待 1500 毫秒，然后调用process.exit(0)退出。这个额外的延迟是为了给整个系统一个“喘息”的机会，确保所有子进程确实已经退出，会话锁已被释放，然后再让包装器进程本身消失。总延迟约 3.5 秒，这个经验值平衡了清理的可靠性和用户感知的延迟。

注意事项：这个清理逻辑严重依赖pgrep命令。在非 Unix 系统（如标准的 Windows）上，这个命令可能不可用。虽然项目文档提到它“standard on Linux/macOS”，但如果你在 Windows 的 WSL 或 Cygwin 环境下运行，需要确保pgrep可用。此外，如果进程树非常深或子进程数量极多，递归查找可能需要调整以避免性能问题，不过对于kiro-cli这种通常只产生一个子进程的场景，这不成问题。

5. 实战应用与集成示例

5.1 在 OpenClaw 工作流中调用 Kiro

配置好代理后，你可以在支持 OpenClaw ACP 协议的任何环境中使用 Kiro。最常见的是在 OpenClaw 自己的 JavaScript/TypeScript SDK 或相关工具中。

假设你有一个 OpenClaw 项目，你想在一个代码审查任务中启动一个持久的 Kiro 会话。你的代码可能看起来像这样：

// 导入 OpenClaw 的会话管理函数 import { sessions_spawn, sessions_send } from '@openclaw/sdk'; async function codeReviewWithKiro(filePath) { // 1. 启动会话 const sessionInfo = await sessions_spawn({ agentId: "kiro-refactor", // 使用我们之前配置的自定义代理 runtime: "acp", mode: "session", thread: true, // 启用线程模式，支持多轮对话 task: `请仔细审查位于 ${filePath} 的源代码，找出潜在的性能问题、代码坏味道和安全漏洞。请先给出一个高层面的概述。` }); console.log(`会话已创建，Session Key: ${sessionInfo.sessionKey}`); // 模拟等待 AI 回复，在实际中可能是基于事件或回调 await new Promise(resolve => setTimeout(resolve, 10000)); // 2. 发送后续消息（基于 AI 的回复进行深入） const followUpResponse = await sessions_send({ sessionKey: sessionInfo.sessionKey, // 使用上面返回的 sessionKey message: "很好。现在请针对你提到的第二个性能问题，给出具体的重构代码示例。" }); // 3. 可以继续交互... // const finalResponse = await sessions_send({ // sessionKey: sessionInfo.sessionKey, // message: "将这些改动整合到一个 Pull Request 描述中。" // }); // 会话会一直保持，直到你显式关闭它或 acpx 超时。 // 包装器确保了即使这个 Node.js 脚本结束，下一次用同一个 sessionKey 发送消息时， // 也不会遇到“会话被占用”的错误。 }

在这个例子中，sessions_spawn初始化了一个长期会话。sessionKey是这个会话的唯一标识符，用于后续的所有交互。由于包装器确保了进程的干净退出，这个sessionKey可以被安全地持久化（例如存入数据库），并在几天后甚至另一个服务中重新用来继续对话，而不会遇到进程冲突。

5.2 通过命令行直接测试

在深入集成到复杂应用之前，直接使用acpx命令行工具测试你的配置是个好习惯。这能帮你快速验证包装器是否工作，以及日志是否正常输出。

# 启动一个交互式会话，使用你配置的 'kiro' 代理 acpx --agent kiro

执行这条命令后，acpx会根据~/.acpx/config.json中的配置，启动kiro-acp-wrapper.js，进而启动kiro-cli。你应该会进入一个交互式提示符，可以直接与 Kiro 对话。输入一些代码相关问题，看看是否能得到回复。

要测试日志功能，你可以先配置一个带日志的代理（如之前的kiro-debug），然后运行：

# 在另一个终端窗口，实时查看日志 tail -f /tmp/kiro-acp-debug.log # 然后回到第一个终端，运行带日志的代理 acpx --agent kiro-debug

在交互式会话中输入文字并接收回复时，观察日志窗口。你应该能看到[IN]和[OUT]标签的流量记录。结束会话（通常按 Ctrl+D 或输入exit）后，观察日志中是否出现了Found descendants:和Killed descendant等清理记录。这是验证包装器清理逻辑是否生效的最直接方法。

5.3 在自动化脚本中集成

包装器的真正威力体现在自动化流程中。例如，你可以编写一个脚本，自动将一段代码发送给 Kiro 进行优化，并解析返回的结果。

#!/bin/bash # 这是一个简单的 Bash 脚本示例，通过 acpx 非交互式地使用 Kiro SESSION_FILE="/tmp/kiro_session_$$.txt" # 使用进程 ID 创建唯一会话文件 # 启动一个会话，并将初始任务通过管道传入 echo "优化以下 Python 函数，提高其可读性： def process_data(items): result=[] for i in items: if i%2==0: result.append(i*2) else: result.append(i*3) return result" | acpx --agent kiro --session-file "$SESSION_FILE" > optimized_code.txt 2>&1 # 从输出中提取 session key (假设 acpx 输出中包含) SESSION_KEY=$(grep -o 'sessionKey:[^ ]*' optimized_code.txt | head -1 | cut -d':' -f2) if [ -n "$SESSION_KEY" ]; then # 使用提取到的 session key 发送后续请求 echo "将优化后的函数改为使用列表推导式。" | acpx --agent kiro --session "$SESSION_KEY" >> optimized_code.txt 2>&1 fi echo "优化结果已保存到 optimized_code.txt" cat optimized_code.txt

这个脚本展示了如何以非交互式、脚本化的方式利用 ACP 会话。--session-file和--session是acpx可能提供的参数（具体请参考 OpenClaw 文档），用于管理和复用会话。包装器在背后确保了每次调用都不会因为残留进程而失败。

实操心得：在自动化集成中，错误处理尤为重要。包装器进程本身如果遇到问题（如kiro-cli未安装），会以非零退出码退出。你的脚本应该检查acpx命令的退出状态（在 Bash 中是$?），并记录日志。此外，对于长时间运行的自动化任务，要考虑acpx或包装器可能存在的超时机制，避免僵尸会话。

6. 故障排除与深度调试指南

6.1 常见错误与解决方案

即使配置正确，在实际运行中也可能遇到问题。下面是一个快速排查指南：

6.2 高级调试：深入日志分析

当遇到复杂问题时，你需要像侦探一样分析日志。一份完整的调试日志可能包含以下关键行：

[2023-10-27T10:00:00.000Z] Spawned kiro-cli PID: 12345 [2023-10-27T10:00:05.000Z] [IN] < 来自 acpx 的初始任务消息... [2023-10-27T10:00:06.123Z] [OUT] > Kiro 回复的第一部分... [2023-10-27T10:00:06.456Z] [OUT] > Kiro 回复的第二部分... [2023-10-27T10:00:10.000Z] [IN] < EOF (stdin closed) // acpx 关闭了输入 [2023-10-27T10:00:10.001Z] Starting cleanup for PID: 12345 [2023-10-27T10:00:10.005Z] Found descendants: [12346, 12347] // 发现了子进程 [2023-10-27T10:00:10.006Z] Killed descendant 12347 [2023-10-27T10:00:10.006Z] Killed descendant 12346 [2023-10-27T10:00:11.007Z] Killed main process 12345 [2023-10-27T10:00:12.008Z] CHILD EXIT: code=0 signal=null [2023-10-27T10:00:13.509Z] Wrapper exiting

如何解读：

• Spawned kiro-cli PID：这是所有操作的起点。记下这个 PID。
• [IN]/[OUT]：确认数据流是否正常。如果只有[IN]没有[OUT]，可能是kiro-cli卡住了或网络有问题。
• Starting cleanup：标志着清理开始。如果这一行之后没有后续的Found descendants或Killed日志，说明清理逻辑可能提前返回或出错了。
• Found descendants：列出了找到的所有子进程 PID。如果这个列表是空的，但之后仍然出现会话被占用的错误，那可能意味着pgrep没有找到正确的进程，或者子进程是在清理开始后才产生的（竞态条件）。
• Killed descendant/main process和CHILD EXIT：确认每个进程都被发送了终止信号并最终退出。code=0表示正常退出，code非零或signal不为null表示进程被信号终止。
• 时间戳的间隔可以验证延迟逻辑是否按预期工作（例如，在Killed descendant和Killed main process之间应该有大约1秒的间隔）。

6.3 性能调优与参数调整

包装器中的延迟参数（1秒，1秒，1.5秒）是经验值，在大多数情况下是足够的。然而，在某些极端情况下，你可能需要调整它们：

• 系统负载极高：如果服务器非常繁忙，进程清理和资源释放可能需要更长时间。你可以尝试增加延迟。在包装器脚本中找到setTimeout调用，将 1000 毫秒适当增加（如 1500 或 2000）。
• 需要更快迭代：在开发或测试环境中，如果 3.5 秒的清理延迟显得太长，你可以尝试谨慎地减少延迟。但务必在减少后进行全面测试，确保不会因此增加“会话被占用”错误的发生率。
• pgrep性能：如果你管理的机器上pgrep命令本身很慢（极罕见），或者进程树异常复杂，递归查找可能成为瓶颈。可以考虑在包装器中为execSync调用pgrep设置一个超时，或者寻找替代的 Node.js 原生模块来获取子进程列表（如ps-tree包），但这会增加外部依赖。

踩坑记录：我曾经在一个 Docker 容器内使用这个包装器时遇到过一个棘手的问题。日志显示清理逻辑执行了，但偶尔还是会话冲突。后来发现，容器内/proc文件系统的挂载方式或速度有时会导致pgrep在进程已退出但/proc/<pid>目录还未被内核清理的瞬间执行，从而漏掉一些进程。解决方案不是调整包装器，而是确保容器有足够的 CPU 和时间片来及时处理进程终止的内务操作。有时，系统层面的问题需要系统层面的解决。