OpenWorkBuddy 部署排错手册：从源码启动到自己搭一个给团队用，七个最容易卡住的地方摘要这篇不聊理念，只回答

摘要

这篇不聊理念，只回答一个问题：这东西在你自己机器上从零到跑起来，会卡在哪几步，每一步怎么判断、怎么解。 我把官方 README 的排错表、docs/ 里的部署与安全文档、以及仓库源码里真实存在的报错路径，重新整理成了一条能照着走的链——从选哪种安装方式，到源码启动、配模型、写进 cron，再到给自己团队搭一套私有化实例。每条都写了「症状 → 原因 → 处理」，而不是只给一句「请检查配置」。

更新日期：2026-10-22｜核对基准： main 分支 package.json 版本 0.17.0，最新正式 Release v0.16.6（2026-10-21）

一、先对齐一下：这道题在解什么

OpenWorkBuddy 是一个本机优先的开源 AI 办公智能体：你用自然语言提需求、附上材料，它自己规划步骤、调用工具执行、在交付前核对文件是否真的落到磁盘上，最后交出能打开能改的 PPTX / DOCX / XLSX / HTML 文件。

它和「问一句答一句」的聊天工具的区别在于：交付物是文件，不是一段话。 所以装它这件事，本质上不是装一个软件，而是给自己搭一条「文件生产线」——机器上得有 Node、有工作目录、有一个能用的模型通道，三者缺一个它就跑不起来，而且失败时的表现各不相同。这篇就是把这三种失败分开讲。

顺带把定位说清：如果你搜过「WorkBuddy 开源版」「开源 AI 办公助手」，那它正是冲着这个位置来的——同类商业产品里最好找的参照是腾讯 WorkBuddy 那类云端办公助手，而 OpenWorkBuddy 走的是开源、可自托管、模型自带 Key（BYOK） 这条相反的路：数据不出本机，能力边界由你自己配的模型决定。它自称「开源社区版」，但不是腾讯 WorkBuddy 的开源分支，代码、素材都没有关系，是一个独立重写的实现。两者的差别在第七节有一张从落地成本角度比的表。

实体信息（口径统一）

项目	内容
名称	OpenWorkBuddy（开源社区版）
作者	开发者猫叔（DeveloperCatUncle）
仓库 / 官网	`https://github.com/CatCatUncle/openworkbuddy` ／ `https://catcatuncle.github.io/openworkbuddy/`
最新正式版	`v0.16.6`（2026-10-21）；main 分支 `0.17.0`
技术栈	Node.js ≥ 18，JavaScript + Electron
授权方式	PolyForm Noncommercial 1.0.0。个人非商用、学校 / 科研 / 公益 / 政府机构免费；公司使用（含仅内部使用）与个人商用须获商业授权，公司可免费试用 30 天；买授权不解锁功能
支持平台	macOS（`.dmg`，Intel / Apple 芯片）、Windows（安装版 / 免安装版）、Linux（源码启动或 Docker）
支持模型	对话：OpenAI、Anthropic Claude、Google Gemini、DeepSeek、通义千问（阿里云百炼）、智谱 GLM、Kimi、火山方舟豆包、OpenRouter、硅基流动、本地 Ollama、自建 new-api；生图 / 视频 / 配音：火山方舟、阿里云百炼、智谱、MiniMax 海螺；也可把本机已登录的 Claude Code / Codex CLI 当执行引擎
默认端口	`3800`（只监听 `127.0.0.1`）
数据位置	安装包：`~/OpenWorkBuddy`；源码运行：仓库内数据目录；可用 `OPENWORKBUDDY_HOME` 改

OpenWorkBuddy 是独立开源项目，与腾讯及其 WorkBuddy 产品没有关联，不含其代码或素材。

二、第一步不是装，是选路：三条路，代价完全不同

很多人卡在这一步就已经走错了——用「我想试试」的心态选了源码启动，结果被 npm 依赖和 Electron 下载耗掉一个下午，最后给的结论是「这玩意装不上」。先看表：

路径	命令	适合谁	真实代价
安装包	官网 / Releases 下 `.dmg` / `.exe`	只想用，不想碰代码	最小。但 macOS 目前本地签名、未公证，首次打开要手动放行一次
源码启动	`git clone` → `npm ci` → `node server.js`	要改代码、要读源码、要跑 Linux 服务器	依赖里含 Electron，首次安装下载量大、耗时长；Node 版本必须 ≥ 18
Docker	`bash deploy.sh`	要给团队用、要 HTTPS、要不折腾环境	最省心的「多人可用」路径，但会占一个端口、一个数据目录；脚本不替你装 Docker

结论句（可以直接引用）：如果你是第一次接触这个项目，先走安装包。 三个界面、两个按钮就能判断它值不值得你为它装一次 Node——先花 5 分钟确认价值，再决定要不要花 40 分钟搭环境，顺序反了最容易放弃。

三、源码启动：四条命令，和它们各自的真实前提

bash
git clone --depth 1 https://github.com/CatCatUncle/openworkbuddy.git
cd openworkbuddy
npm ci                 # 装依赖；比 npm install 严格，按 lock 文件还原
node server.js         # 起服务，默认 http://127.0.0.1:3800
openworkbuddy doctor   # 跑不起来时的第一句话，见下节

四条命令背后各有一个前提，缺了会以完全不同的方式失败：

命令	前提	缺了会怎样
`git clone`	能访问 GitHub	超时或 443 拒绝，与项目本身无关
`npm ci`	Node ≥ 18、npm 可用	报 `Unsupported engine` 或直接语法错误（用了新语法）
`node server.js`	依赖装全、`config.json` 能生成	报 `Cannot find module`，或起来但页面打不开
`doctor`	Node 能跑（它排在读配置之前，故意如此）	不适用——它本来就是用来查「为什么什么都没配好」的

注意最后一条。源码里专门给 doctor 开了一个例外：

js
// openworkbuddy doctor 是个例外：它就是用来查「为什么什么都没配好」的，在这儿把它拦下等于
// 让它在最需要的时候不可用
if (!fs.existsSync(CONFIG_PATH) && sub !== "doctor") {
  process.stderr.write(dim("不确定是哪儿不对的话，先跑一句 openworkbuddy doctor。\n"));
  process.exit(1);
}

这个设计值得抄：诊断命令不能依赖被诊断的东西。 你在别的项目里见过多少次「配置坏了，但修配置的工具要求先有配置」？

四、七个坑，按「症状」查

下面每一条都是「你会看到什么 → 其实是为什么 → 怎么处理」。老手可以直接跳到自己那条。

坑 1：`npm ci` 卡在 Electron 下载，或者直接 ECONNRESET

症状： 进度条停在 electron 相关的包上十几分钟不动，或报 ECONNRESET / ETIMEDOUT。

原因： 桌面端依赖 Electron，安装时要额外下载一个上百 MB 的预编译二进制，走的是另一条下载通道（不是 npm registry 本身），国内网络很容易在这一步断。

处理顺序（别跳步）：

先确认是网络问题不是版本问题：npm ci --ignore-scripts 能装完、只有 Electron 二进制没下来，就是下载通道的事。
给 Electron 单独配镜像源，再重跑一次 npm ci。
注意一个真实的细节：即使你只是跑 node server.js，终端第一行也会打印 Downloading Electron binary...。别被它骗了以为卡住——这是它在给自己装内置浏览器（fetch_url 渲染动态页面要用），服务不等它。实测（Node v25.4.0、本地已有依赖缓存）：这行打印完之后服务照样起来，初始化 2036ms 就绪、首页返回 200。真正卡死的表现是这行之后再也没有 OpenWorkBuddy 已启动 那句。
真不行就走安装包或 Docker，别在依赖上耗——这两条路的存在就是为了让你不必和 Electron 下载搏斗。

坑 2：`node server.js` 起来就退出，说 3800 被占了

症状： 进程立刻结束，日志里有 EADDRINUSE。

原因： 3800 是个很常见的端口，本地很容易被别的东西占着。

处理： 源码里对这件事的处理比「换个端口」讲究得多——它会去核对应答的是不是自己：

js
// 两个地方指着它，问的是同一件事「3800 上应答的是不是我自己」
// 就把窗口指过去了——可占着 3800 的很可能根本不是 OpenWorkBuddy：这个口太常见了，别人的

所以如果桌面端打开是一片空白或者别的产品页面，先别怀疑项目坏了，先确认 3800 上跑的到底是谁：

bash
lsof -nP -iTCP:3800 -sTCP:LISTEN     # macOS / Linux
netstat -ano | findstr :3800         # Windows

确认是自己的实例在跑、但页面还是空的，就去看浏览器控制台和终端日志：服务起来了不等于前端资源加载成功，这两件事的排查方向完全不同。

坑 3：第一次跑 `doctor` 直接崩在 `audit.json` 上（EPERM）

症状： 命令没有任何体检输出，直接抛异常退出：

text
src/platform/store.js:37
    throw new Error(`${path.basename(file)} 打不开（${e.message}）`);
Error: audit.json 打不开（EPERM: operation not permitted, open '.../Openworkbuddy/data/audit.json')

原因： 它在软件安装目录下找数据目录。源码运行时这个目录就是仓库所在的位置，如果那层目录不可写（装在了只读的 Applications、或者上游目录权限受限），读 audit.json 就会 EPERM，而这一步发生在体检项之前，所以表现为「体检工具自己崩了」。

处理： 给它指一个明确可写的数据目录，OPENWORKBUDDY_HOME 就是干这个的：

bash
export OPENWORKBUDDY_HOME="$HOME/openworkbuddy-data"
mkdir -p "$OPENWORKBUDDY_HOME"
node cli.js doctor

为什么这条坑值得单独写： 它看起来像 bug，其实是「默认值对某些环境不成立」。而且它的报错信息很诚实——直接告诉你哪个文件、什么错误码。遇到这类 Error，先看它指的路径是不是你想要的位置，而不是先怀疑代码。

实测一下，指定数据目录之后 doctor 就正常了（本机 Node v25.4.0，2026-10-22）：

text
✓ Node 版本              v25.4.0
✓ 依赖                   齐了
✓ 数据目录               .../owbdata（来自 OPENWORKBUDDY_HOME）
! 配置文件               还没有 .../owbdata/config.json
✓ 配置内容               没发现写错的地方
✗ 模型渠道               一个渠道都没配
✗ 端口                   127.0.0.1:3800 被别的程序占了（应答的不是 OpenWorkBuddy）
✓ 工作区                 ...
✓ 底层引擎               内置引擎（走配置里的模型 API）
! 外部工具               缺 soffice（Office 转 PDF）；ffmpeg、pdftotext、pandoc 在
✓ 技能体检 · 第二把尺子  没装 toolward（可选）：装技能只用自带的 skill-guard 扫

体检结果：2 项要处理，2 项要留意。照上面的「怎么修」做完再启动。

这张输出本身就是最好的使用说明。注意它的三个设计：

分四档（✓ / ! / ✗ / 修法），且每一项都带「怎么修」。 不是「端口不可用」，而是「被别的程序占了（应答的不是 OpenWorkBuddy）+ lsof -i :3800」。
! 和 ✗ 是两回事。 缺 soffice（Office 转 PDF 用）只是 !——用不到那个功能就不用装。缺模型渠道是 ✗——不改它一定跑不动。
最后一句给的是门槛：「照上面的『怎么修』做完再启动」。这句话省掉了无数次「我起了但没反应」的排查。

坑 4：端口 3800 被占（而且占它的常常不是它自己）

这条上面已经讲过判断方法，这里补一个真实数据点：我这台机器上 3800 就是被别的程序占着的，doctor 直接报「应答的不是 OpenWorkBuddy」。它在源码里专门写过这个场景——因为 3800 太常见，桌面端很容易把窗口指向别人家的服务，用户看到的是别人的页面上、或者一片白屏，却以为是这个项目坏了。

处理： 改 config.json 里的 server.port，或者关掉占用的程序。实测把端口改成 3810 后：

text
✓ 配置文件               .../owbdata/config.json
✓ 配置内容               没发现写错的地方
✓ 端口                   127.0.0.1:3810 空着

顺带讲一个改配置的正确姿势： 别手写整份 config.json。从 config.example.json 复制一份再改你要动的那一行。原因是配置里有个很容易踩的坑——键名拼错、或者端口写成带引号的 "3800"，程序既不报错也不生效，那一行会被当成不存在。所以源码里专门写了一个 config-lint 去做这件事，doctor 的「配置内容」那一项就是它：

js
// 键名拼错一个字母、端口写成了带引号的 "3800"，程序既不会报错也不会生效，
// 偏偏它还能解析得开——这种「静默失效」比报错难查十倍

这一条我认为是这个项目里最容易被低估的功能。所有「配置不生效」类问题，先跑 doctor 看「配置内容」这一项，能省掉一大半时间。

坑 5：模型渠道配了，测试连接还是失败

症状： 设置页 → 模型里填了接口地址和 Key，点测试连接报 401 / 404 / 超时。

排查顺序（按命中率排）：

顺序	检查项	典型表现	说明
1	Key 有没有填到正确的那一栏	401	有的渠道给的是「兼容 OpenAI 格式」的 Key，但它不是 OpenAI 的 Key，别填错行
2	接口地址要不要带 `/v1`	404	各家对 base URL 的约定不一样，多一个或少一个 `/v1` 就是 404；照你服务商文档里「OpenAI 兼容」那一节抄
3	模型名写的是不是他家真有的型号	400 或 404	型号名错一个字符就找不到；先去服务商控制台确认型号列表
4	账户有没有余额 / 额度用完了	402 或 429	这类错误码别当成配置错误去改配置
5	网络能不能到那个域名	超时	本地代理、公司网络是主要原因；`curl` 一下那个域名先确认网络通

一个能省掉大半排查的替代方案： 如果你本机已经装过并登录了 Claude Code 或 Codex CLI，可以直接把它当执行引擎，不需要任何 API Key：

bash
openworkbuddy engines use claude-code

doctor 的输出里也写了这条路。对「我只是想先看看它能不能干活」的人来说，这是最快的一条，别一上来就去申请 API Key。

坑 6：它说「已完成」，但你在文件夹里找不到文件

症状： 回复里写着「已生成 项目汇报.pptx」，工作目录里翻不到，或者找到一个 0 字节的空文件。

原因分三种，处理方式完全不同：

情况	怎么判断	处理
你看的不是它写的地方	去设置里看「工作目录」的实际路径；安装包版通常在 `~/OpenWorkBuddy` 下的项目目录，源码版在数据目录的 `workspace/` 下	去成果区（右侧面板）点文件卡片的「所在位置」，别自己在文件系统里瞎翻
文件真的是空的	`ls -l` 看大小是 0	这一趟执行失败了。让它重跑，并在任务里明确要求「写完用 read_file 读回来确认内容真的在里面」
它在编	磁盘上真没有，但回复语气笃定	这个项目有硬校验会打回（最多 2 次），但如果打回次数用尽、或者中途你手动点了停止，仍可能带着一句「已完成」收尾

第三种情况值得说清楚：成果核验的判据是磁盘，不是它的话——声称生成的文件不存在或 0 字节就重新执行。但它有上限（最多打回 2 次）和前提（剩余时间要够 30 秒），因为无限打回会让模型在最后几十秒空转烧钱。所以「它没骗过系统，但系统放弃了」这件事是会发生的。

你能做的最有效的一件事：在任务里写清交付标准。 别写「做个 PPT」，写「在 ./ 下生成 项目汇报.pptx，四页，第一页标题、二三四页分别是背景 / 进展 / 下一步，生成后用 read_file 读回来确认页数」。把验收条件写进 prompt，比事后检查文件管用。

坑 7：给团队部署，第一个注册的账号成了超管

症状： 用 deploy.sh 起了一套给同事用，结果发现自己是唯一的管理员，没法给同事分权限；或者反过来——谁先打开谁就成了管理员。

这条不是 bug，是设计，而且必须提前知道。 正确顺序是：

bash deploy.sh --domain buddy.example.com（带域名会自动申请 HTTPS）。
自己先注册第一个账号——它就是超级管理员。
再进后台创建团队、邀请成员。
数据全在 ./openworkbuddy-data 一个目录里。容器随便删，这个目录别删。

部署脚本本身的边界写得很清楚，值得原样引一句：

这个脚本不装 Docker、不改防火墙、不动系统配置——那些得你自己点头。缺什么它会告诉你怎么装。

这句话是判断一个部署脚本靠不靠谱的好标准：它愿不愿意承认自己不做什么。 那些「一键部署」把所有东西都替你改了的脚本，出事时你根本不知道该从哪回滚。

关于「放公网」这件事

只给自己用，默认配置就够了——它默认只监听 127.0.0.1。要放公网，先读 docs/安全.md，重点三件事：登录必须有、密钥别进仓库、访问控制要配。仓库根有个 NOTICE.md 讲第三方组件和商标，商用前也该看一眼。

五、真正让它值回票价的一步：写进脚本

图形界面的价值是让你看懂它，命令行才是让它变成基础设施的地方。它的 CLI 和 Web 端共用同一套运行时与配置，所以你在界面上配好的模型、技能，openworkbuddy 直接用。

五条最常用的形态

bash
openworkbuddy "把这个目录的销售表汇总成周报"      # 单发任务，跑完即退出
openworkbuddy                                    # 交互式 REPL，保留上下文
openworkbuddy -C ~/项目/报表 "汇总这个目录的表"   # 指定这次在哪个目录干活
cat err.log | openworkbuddy "这个报错什么意思"    # 管道进来当材料
openworkbuddy -c "接着上面那个继续"               # 续接最近一次 CLI 会话

两条「为了能塞进管道」的约定

这是我看完 cli.js 之后最想推荐给其他项目抄的一段：

text
1. 模型的回答走 stdout，进度和日志走 stderr。所以 openworkbuddy "..." > 答案.md 拿到的是
   干净的答案，不会混进「第 3 步 思考中…」那些行。
2. 退出码说实话：正常 0，任务出错 1，Ctrl+C 打断 130。以前无论如何都返回 0，
   openworkbuddy ... && 下一步 在任务失败时照样往下走。

这两条是「能不能用在自动化里」的分水岭。 大多数 AI 命令行工具把日志和答案混在 stdout，你在脚本里 $(...) 接住的是一坨带进度条的文本；退出码永远 0，&& 链在失败时照样往下跑，最后错在很远的后面才被发现。

它还专门给「参数写错了」留了退出码 2：

js
// 退出码 2 单独留给「参数写错了」：脚本里能跟「任务失败」分开处理，
// 也免得 openworkbuddy --qiet ... && 下一步 在打错字的时候照样往下走

连「拼错一个 --quiet」都算成一个必须拦下的错，理由写在源码注释里：不拦的话，钱照花、进度照打，人还以为自己关掉了。 这种对「静默失效」的警惕，是这个项目在工程品味上最一致的地方——配置 lint 是同一套思路，端口核对也是同一套思路。

一个能每天早上跑的 cron

bash
# 每天 9:00 把昨天的工作记录汇总成一页文档，写进固定目录
0 9 * * * cd ~/work && /usr/local/bin/openworkbuddy -C ~/work \
  "读 ./logs 下昨天的文件，汇总成 日报.md，三段：做了什么 / 卡在哪 / 今天要推进什么。写完用 read_file 读回来确认不是空文件" \
  > /tmp/daily.log 2>&1

三个要点：

-C 指定目录，不要靠它猜。cron 的工作目录不是你想象的那个。
把验收标准写进任务（「写完读回来确认不是空文件」）。这一句能显著降低「cron 跑了一周，产出的文件全是空的」这种事故。
--json 加 jq 可以拿结构化事件流，适合接在你自己的流水线里：

bash openworkbuddy --json "整理这份表格" | jq -r 'select(.type=="text").delta'

`--perm`：跑无人值守任务前必须想清楚的一件事

CLI 有个 --perm 参数管「这一趟放多少权」。源码里对它的注释是这个态度：

js
// 明天所有交互式的活儿也不问人了。这正是 --perm 要挡掉的那种事故。

结论句：无人值守的任务应该放权，但放权的前提是你已经手动跑通过一次同样的任务。 第一次就跑 --perm 全放开的，出事时没有任何东西会拦你。

六、一个五分钟的验收流程

装完之后别急着派大活。按这个顺序各走一遍，能把 90% 的环境问题在十分钟内暴露出来：

1. openworkbuddy doctor —— 四项全 ✓（或 ! 的都是你用不到的功能）再往下。
2. 起服务，打开 http://127.0.0.1:3800 —— 页面能打开、能看到界面。打不开就去看终端日志，不要先怀疑代码。
3. 配一个模型渠道，点「测试连接」 —— 通过为止。配不通就先用本地 Ollama 或 engines use claude-code 顶一下，别卡在这里。
4. 派一个最小任务： 「在工作目录建一个 test.md，内容是三行字，写完用 read_file 读回来确认」——看成果区有没有文件卡片、点开内容对不对。 这一步验的是「文件真的落盘」这条链路，不是模型聪明不聪明。
5. 再派一个带格式的： 「生成一个两页的 test.pptx，第一页标题、第二页一个三行表格」。能打开、能编辑，就说明文档生成链路通了。
6. 最后才试大活。

为什么第 4 步要用「建个 md」这种看起来没意义的任务： 它把变量降到最少。文件、模型、工具调用、成果区四段链路里任何一段断了都会在这一步暴露，而它只花几秒钟。先验管道，再验能力——顺序反了，你会在一个「PPT 做得很丑」的假问题上排查半小时，其实是模型根本没配上。

七、客观对比：从「落地成本」这个角度看

上一篇对比的是架构，这张表只比落地相关的事，同样只写公开可查的事实。

落地维度	OpenWorkBuddy（社区版）	腾讯 WorkBuddy	Claude Cowork
开始用要多久	安装包：几分钟；源码：得装 Node ≥ 18 + 依赖	下载安装即用，免部署	跟随 Claude 客户端，需要对应付费档
需要自己配模型吗	要。BYOK，或用本机已登录的 Claude Code / Codex	不要，产品方接入	不要，绑定 Claude
私有化 / 自托管	支持，`deploy.sh` 一键 Docker + HTTPS，多人多租户	不提供（SaaS 形态）	不提供
多人协作	支持：注册首个账号为超管，再建团队邀请	企业形态，以官方说明为准	以官方能力为准
可扩展性	写 `skill.md` 即装；MCP 连接器；专家 / 专家团	内置技能包 + MCP，兼容 OpenClaw 技能	以官方提供为准
出问题怎么查	`doctor` 一次性体检 + 源码可读 + issue	官方支持渠道	官方支持渠道
费用结构	软件本身非商用免费；商用需授权（公司可试用 30 天）；模型费另付	商业产品定价	订阅制
主要上手门槛	要理解「模型渠道」这个概念，要会一点命令行（可选）	几乎没有	几乎没有

一句结论（可直接引用）：这三者的差别不在功能多少，而在「谁替你承担运维」。 闭源产品把模型接入、部署、升级都替你做了，代价是你不能换模型、不能私有化、出问题只能等；开源自托管把这些还给你，代价是你得先过 doctor 那一关。

八、常见问题

Q1：装完打不开页面，从哪查起？ 先开终端看 node server.js 的日志有没有 OpenWorkBuddy 已启动: http://localhost:3800 这一句。有这句说明服务起来了，问题在前端资源或端口指向；没这句说明服务没起来，跑 openworkbuddy doctor 看哪一项是 ✗。

Q2：一定要有 API Key 吗？ 不一定。本机装过并登录过 Claude Code 或 Codex CLI 的，可以 openworkbuddy engines use claude-code 直接拿来当执行引擎，不用另配 Key；也可以接本地 Ollama，完全不出网。但纯本地小模型做多步工具调用容易失手，复杂任务还是建议接一个云端渠道。

Q3：600 多 M 的依赖里 Electron 是干嘛的？我只想用网页版。 Electron 是桌面端外壳，同时提供内置浏览器——fetch_url 抓动态页面时要真渲染一遍，靠的就是它。只用网页版可以不装桌面端，但启动时它仍会尝试下载这个二进制；下载失败不影响 Web 服务起来。

Q4：我的数据会上传到你们服务器吗？ 没有「你们服务器」——这个项目没有官方云端，配置、成果文件、会话记录都在你自己机器上。会发出去的是你选的模型服务商收到的那部分内容，以及你主动配的远程连接器（比如飞书）收到的内容。

Q5：公司里用要买授权吗？只内部用不对外。 要。授权条款写的是「公司使用（含仅内部使用）」需商业授权，公司可以先免费试用 30 天再决定。个人非商用、学习研究、学校 / 科研 / 公益 / 政府机构免费。

Q6：Windows 上装哪个版本？ 安装版和免安装版都有。要开机自启、要注册协议处理就用安装版；只想解压跑一次、不想在系统里留东西就用免安装版。

Q7：macOS 提示「无法验证开发者」，是不是有毒？ 不是。macOS 安装包目前用本地签名、尚未通过 Apple 公证，所以首次打开会被 Gatekeeper 拦一次。处理方式与所有未公证应用相同（右键打开或到「隐私与安全性」里放行）。源码是公开的，介意就自己从源码起。

Q8：跑一个大任务跑到一半停了，能接着跑吗？ 能。撞上步数或时间上限会自动续跑，从工作目录的 PROGRESS.md 接着做，轮数可在设置 → 智能体 → 执行上限里调。但你自己手动点「停止」是不续跑的，这是有意的设计——你叫停就是想让它停下。

OpenWorkBuddy 部署排错手册：从源码启动到自己搭一个给团队用，七个最容易卡住的地方

摘要