如何排查 WorkBuddy 与其他 AI 软件的端口冲突？

WorkBuddy默认监听18789端口（OpenClaw协议），若被占用将导致服务启动失败或连接中断；可通过netstat（Windows）或lsof（macOS/Linux）查PID及进程名，常见冲突源包括旧版OpenClaw、Llama.cpp、Ollama等；建议修改config.yaml中openclaw.port为备用端口（如18790）并同步更新调用方URL。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

检查 WorkBuddy 默认监听端口是否被占用

WorkBuddy 启动后会默认监听 18789 端口（OpenClaw 协议通信端口），若该端口已被其他进程占用，WorkBuddy 服务将无法正常启动或连接中断，日志中常见错误为 address already in use 或 Failed to bind to port 18789。

实操建议：

• Windows：打开命令提示符，执行 netstat -ano | findstr :18789，查出占用该端口的 PID；再用 tasklist | findstr "PID号" 定位进程名
• macOS/Linux：运行 lsof -i :18789 或 ss -tuln | grep :18789
• 确认是哪个软件占用了端口——常见冲突源包括：旧版 OpenClaw 实例、本地部署的 Llama.cpp API 服务、Ollama（默认 11434，但部分自定义配置可能改用 18789）、或其他 AI 工具如 Dify 的本地后端

修改 WorkBuddy 的 OpenClaw 端口并同步更新配置

不建议强行 kill 冲突进程（尤其当它是生产环境服务），更稳妥的方式是让 WorkBuddy 使用备用端口，并确保上下游链路全部对齐。

实操建议：

• 编辑 WorkBuddy 配置文件（通常是 config.yaml 或通过 UI「设置 → 高级 → 网络」修改），将 openclaw.port 改为未占用端口，例如 18790
• 重启 WorkBuddy 后，用 netstat -tuln | grep 18790 验证是否成功监听
• 若你通过外部工具（如 Python 脚本、Postman）直连 OpenClaw 接口，需同步更新请求 URL 中的端口号，例如从 http://localhost:18789/v1/chat/completions 改为 http://localhost:18790/v1/chat/completions
• 注意：飞书/企微等平台回调不受此端口影响，它们走的是 WorkBuddy 的 HTTP webhook 入口（如 /api/feishu/event），与 OpenClaw 端口无关

识别 Chrome Remote Debugging 端口（9222）与 WorkBuddy 的潜在干扰

WorkBuddy 在启用自动化浏览器操作（如 RPA 场景）时，会尝试启动带 --remote-debugging-port=9222 的 Chrome 实例。如果此时系统已有其他 Chrome 实例（比如你日常在用的浏览器）已占着 9222，WorkBuddy 的自动化流程就会卡住或报 501 Not Implemented 错误。

Muse AI

下一代无广告视频托管平台

下载

实操建议：

• 不要依赖全局 Chrome，务必为 WorkBuddy 指定独立 --user-data-dir 和显式端口（如 --remote-debugging-port=9223）
• 检查 WorkBuddy 日志中是否出现类似 Could not connect to Chrome on port 9222 的提示；有则说明调试端口冲突
• Chrome 136+ 版本强制要求同时传入 --user-data-dir 和 --remote-allow-origins=*，缺一不可，否则 --remote-debugging-port 会被静默忽略

避免 Docker 容器与宿主机端口重叠

如果你在本地同时运行了 Docker 化的 AI 服务（如 FastChat、Text Generation WebUI），它们常默认暴露 7860、8000、8080 等端口，虽不直接冲突，但容易造成混淆或代理转发失败。

实操建议：

• 用 docker ps -a 查看所有容器及其 PORTS 列，重点关注 0.0.0.0:xxx-> 映射
• WorkBuddy 自身不依赖 Docker，但它的插件（如某些 Skill）可能调用本地 http://localhost:7860 接口；若该端口被占，对应 Skill 将失效且无明确报错，需手动验证连通性：curl -I http://localhost:7860
• 临时调试可用 docker stop $(docker ps -q) 停掉所有容器，再单独启动必要服务

端口冲突真正难排查的地方，往往不是“哪个端口被占了”，而是“哪个服务悄悄监听了你以为它不会监听的端口”——比如某个后台更新的 AI 插件自动启用了内置 HTTP server，却没在文档里写明端口号。建议每次新增 AI 工具前，先用 netstat 或 lsof 快扫一遍常用端口段（18780–18799、9220–9230、7860–7870）。