workbuddy无内置崩溃自启机制，需依赖系统级守护：windows用sc failure配置服务重启策略，linux在systemd中设restart=always+restartsec等参数，macos通过launchdaemon启用keepalive并规范plist权限。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 本身不提供“崩溃后自动重启”的内置机制，它依赖操作系统级服务守护来实现进程异常退出后的拉起。直接双击启动或普通后台运行无法应对崩溃场景，必须将其注册为系统服务（Windows/Linux）或 LaunchDaemon（macOS），并配置失败重启策略。
Windows：用 sc failure 设置服务级崩溃恢复
仅注册为服务（sc create）不够，必须显式配置失败响应动作，否则进程崩溃后服务状态会卡在“已停止”，不会自动拉起。
- 先确保 Agent 已注册为服务，例如服务名为
WorkBuddyAgent - 执行命令：
sc failure WorkBuddyAgent actions= restart/60000/restart/60000/restart/60000 reset= 86400，表示三次崩溃后每次间隔 60 秒重启，86400 秒（24 小时）后重置计数器 - 务必检查服务 Log On 账户：若使用
LocalSystem，需确认其对%APPDATA%\WorkBuddy目录有读写权限；若用普通用户，则该用户必须处于“自动登录”状态或启用“允许服务与桌面交互”（不推荐） - 验证方式：在任务管理器中结束
agent.exe进程，观察 60 秒内是否重新出现 —— 若无，检查 Windows 事件查看器中System日志下的Service Control Manager错误
Linux：systemd 的 Restart=always 不等于“崩溃即重启”
Restart=always 会在进程退出（无论是否崩溃）时触发重启，但默认不记录退出原因，且若进程启动即闪退（如配置错误），systemd 会进入快速失败循环并暂停重启。
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
- 在
/etc/systemd/system/workbuddy-agent.service中，除Restart=always外，必须添加：RestartSec=10（避免高频重启）、StartLimitIntervalSec=600、StartLimitBurst=5（允许 10 分钟内最多重启 5 次） - 关键点：
Type=simple要求进程在前台运行；若 Agent 启动后自行 fork 到后台（如带--daemon），应改用Type=forking并设置PIDFile= - 日志排查优先看：
sudo journalctl -u workbuddy-agent.service -n 50 -f，崩溃时通常显示Process exited with code=exited, status=1/FAILURE或段错误信号
macOS：LaunchDaemon + KeepAlive 的真实行为
macOS 的 KeepAlive 默认只监控进程是否存在，不区分“正常退出”和“崩溃”。若 Agent 因 SIGSEGV 崩溃，LaunchDaemon 会立即重启；但若它因未捕获的 Objective-C 异常静默退出，可能被判定为“主动退出”，不触发重启。
- 必须在
com.workbuddy.agent.plist中显式启用：<key>KeepAlive</key><true></true>，并补充：<key>AbandonProcessGroup</key><true></true>防止子进程残留干扰 - 崩溃日志不在 Console.app 的用户日志里，而是在：
sudo log show --predicate 'process == "agent"' --last 24h - 常见陷阱：plist 文件权限必须是
root:wheel且644，否则launchctl load会静默失败；可用sudo launchctl bootstrap system /Library/LaunchDaemons/com.workbuddy.agent.plist替代旧版load命令提升兼容性
真正难处理的是“假崩溃”：Agent 进程仍在，但 Claws 通道断开、心跳停滞、任务队列卡死。这种状态系统服务无法感知，必须配合 /status 指令轮询或外部健康检查脚本主动 kill 后触发重启。服务级守护只解决进程消失问题，不解决逻辑僵死。
