bux 上手：把 Claude Code 变成 24 小时在线的浏览器 Agent

作者：Administrator 发布时间： 2026-05-01 阅读量：8 评论数：0
技术教程
#工具

把 Claude Code 装在自己电脑上，适合“坐在桌前写代码”。但真正想让 Agent 干活，问题很快就变成另一种：人不在电脑前怎么办？浏览器登录态怎么保留？任务跑到一半遇到 2FA 或验证码怎么办？手机上能不能只发一句话，让它继续处理？

bux 解决的正是这个缝隙。它不是另一个浏览器自动化框架，也不是给 Claude Code 换皮。它更像一台长期在线的 Agent 值班机：一台 Ubuntu 盒子，一个常驻 Claude Code，一个远端真实浏览器，一个 Telegram 入口，再加一套 systemd 把它们守住。

这类工具真正值得写的地方，不是“3 分钟部署”，而是它把移动端入口、浏览器接管、登录态、系统服务和安全边界放进了同一个最小闭环。做对了，它是个人 Agent 工作台；做歪了，它就是一台长期暴露的远程执行机器。得整明白。

bux 到底把什么串起来了

bux 的核心链路可以拆成四块。

第一块是 Claude Code。它仍然是实际执行任务的 Agent：读指令、调用工具、写文件、跑命令、通过 browser-harness 操作浏览器。

第二块是 Browser Use Cloud 的浏览器会话。bux 本机不跑本地 Chrome，也不依赖 Playwright 自己拉浏览器，而是通过 Browser Use Cloud 提供的 CDP 地址连接一个长生命周期浏览器。这个浏览器可以有 profile，cookie 和 localStorage 会保留。

第三块是 Telegram bot。手机发消息进来，bot 把消息排队，再用 claude -p --resume <session> 交给 Claude Code。也就是说，每条 Telegram 消息看着是一次短请求，背后仍然复用同一个会话记忆。

第四块是 systemd。bux-browser-keeper 负责维护远端浏览器，bux-ttyd 提供本地回环绑定的 Web Terminal，bux-tg 负责 Telegram 消息入口。这三件事跑成服务，机器重启后还能回来。

一个简化图是这样：

TEXT
Telegram / 手机消息 │ ▼ telegram_bot.py ──► claude -p --resume │ │ │ ▼ │ browser-harness-js │ │ ▼ ▼ tg-send / live URL Browser Use Cloud Chrome │ ▼ 持久 profile / cookies

注意这里的关键不是“Telegram 控制电脑”。关键是 bux 把一个会话型 Coding Agent 包成了可远程触发、可继续上下文、可接管浏览器的值班系统。

适合什么场景

bux 适合这种任务：

  • 你想在手机上让 Claude Code 查网页、整理邮件、跑脚本、生成报告。
  • 你有一台低成本 VPS 或闲置 Linux 盒子，希望 Agent 24 小时在线。
  • 你愿意让浏览器 profile 长期保存登录态，但又希望遇到登录/2FA 时能人工接管。
  • 你已经接受 Browser Use Cloud 作为浏览器执行层，不坚持所有浏览器都在本机跑。

它不适合这种场景：

  • 需要严格内网隔离，不能把浏览器会话放到第三方云浏览器。
  • 想让 Agent 自动绕过验证码、批量登录、规避风控。
  • 希望无审批执行付款、发信、删库、改生产配置这类高风险动作。
  • 不愿维护 API key、Telegram bot token、VPS 安全更新。

说白了，bux 是“长期在线工作台”，不是“无人监管黑盒”。尤其牵涉邮箱、后台、支付、客户系统时，必须把人类确认点留住。

准备一台干净盒子

官方要求不高：Ubuntu / Debian 22.04+，2GB RAM 起步。因为真正的浏览器跑在 Browser Use Cloud，VPS 本机主要跑 Claude Code、Python bot、ttyd、systemd 服务和一些 CLI 工具。

一个基础机器配置可以这样选：

TEXT
OS: Ubuntu 22.04 / 24.04 RAM: 2GB 起步，长期多任务建议 4GB Disk: 20GB 起步，注意日志和任务产物 Network: 能访问 GitHub、npm、Browser Use Cloud、Telegram API SSH: pubkey-only，禁止 root 登录

如果只是个人测试，最推荐拿一台独立实验机，不要和生产服务混在一起。Agent 能跑命令、能访问浏览器、能持久化登录态，这种东西就不该随便塞进业务服务器。

顺手提一嘴，像 bux 这种长期在线 Agent 值班机，最好单独开一台轻量云服务器，把 Claude Code、浏览器 profile、日志和测试项目都隔开。雨云这类 VPS 拿来做 Agent 实验机比较合适：环境干净，重装方便，出问题也不会波及生产机器。

给 24 小时在线 Agent 单独留一台实验机
适合部署 bux、Claude Code、Browser Harness、Telegram bot 和临时任务脚本，和生产环境隔离，翻车也好回滚。
查看雨云服务器方案 →

准备密钥，不要写进聊天记录

bux 至少需要一个 Browser Use Cloud API key。Telegram bot 是可选的，但如果你想手机控制，基本也会配。

需要准备：

TEXT
BROWSER_USE_API_KEY Browser Use Cloud API key TG_BOT_TOKEN Telegram bot token，可选 Anthropic 登录 Claude Code 首次 /login 时完成

Telegram token 通过 BotFather 创建：

TEXT
/newbot my-agent my_agent_bot

拿到 token 后，不要贴到公开群、不要写进文章、不要进 git。安装时用环境变量传进去即可。

如果你要记录部署步骤，建议写成这样：

BASH
export BROWSER_USE_API_KEY='[REDACTED]' export TG_BOT_TOKEN='[REDACTED]'

不要把真实值放进笔记。Agent 系统最常见的事故，不是模型“觉醒”，而是人把 token 粘得到处都是。

最小安装路径

进入服务器：

BASH
ssh root@your-box

一条命令安装：

BASH
curl -fsSL https://raw.githubusercontent.com/browser-use/bux/main/install.sh \ | sudo BROWSER_USE_API_KEY='[REDACTED]' bash

如果要同时启用 Telegram bot：

BASH
curl -fsSL https://raw.githubusercontent.com/browser-use/bux/main/install.sh \ | sudo BROWSER_USE_API_KEY='[REDACTED]' TG_BOT_TOKEN='[REDACTED]' bash

更稳的方式，是先 clone 下来，检查脚本，再跑：

BASH
git clone https://github.com/browser-use/bux.git cd bux less install.sh sudo BROWSER_USE_API_KEY='[REDACTED]' TG_BOT_TOKEN='[REDACTED]' ./install.sh

为什么建议先读脚本？因为这个安装过程会以 root 安装系统包、写 systemd unit、创建用户、改 SSH 配置、安装 Node.js、Claude Code、ttyd、browser-harness。对个人实验机没问题，但它不是普通 npm 包，不能闭眼往生产机里灌。

安装脚本实际做了什么

bux 的安装脚本做得比较实在，几个关键点值得看。

它会安装系统依赖：

TEXT
curl, git, build-essential, python3, python3-venv, jq, ripgrep, fd-find, htop, tmux, vim, less, tree, at ...

它会启用 atd，这样后续 Agent 可以用 at 做一次性提醒或计划任务：

BASH
systemctl enable --now atd.service

它会安装 Node.js 24 和 Claude Code：

BASH
npm install -g @anthropic-ai/claude-code

它会创建一个独立用户：

TEXT
user: bux home: /home/bux runtime: /opt/bux config: /etc/bux logs: /var/log/bux

这一点很重要。Agent 不应该长期跑在 root 下。bux 的主执行环境是 bux 用户，并且脚本明确没有给 bux 配 passwordless sudo。缺什么工具，应该加进安装脚本或做用户级安装，而不是让 Agent 随便 sudo。

systemd 三件套

部署完成后，重点看这三个服务。

BASH
systemctl status bux-browser-keeper systemctl status bux-ttyd systemctl status bux-tg

bux-browser-keeper 维护 Browser Use Cloud 浏览器。它会写一个环境文件：

TEXT
/home/bux/.claude/browser.env

里面包含：

TEXT
BU_PROFILE_ID=<profile-id> BU_BROWSER_ID=<browser-id> BU_CDP_WS=<wss://...> BU_BROWSER_LIVE_URL=<https://live.browser-use.com/...> BU_BROWSER_EXPIRES_AT=<unix-epoch>

其中 BU_CDP_WS 是浏览器控制入口，不能乱暴露。BU_BROWSER_LIVE_URL 是给人类接管或观察的 live view，也要当成敏感链接处理。

bux-ttyd 提供 Web Terminal，但默认绑定 localhost：

TEXT
/usr/local/bin/ttyd -i lo -p 7681 -W /usr/bin/claude

这设计是对的。Web Terminal 绝对不应该直接裸奔到公网。如果你非要远程访问，优先走 SSH tunnel 或 Tailscale，不要开放 7681 给全世界。

bux-tg 是 Telegram bot。只有传了 TG_BOT_TOKEN 才启用。

第一次启动 Claude Code

安装完成后切到 bux 用户：

BASH
sudo -iu bux cd ~ claude

首次运行时执行登录：

TEXT
/login

用浏览器完成 OAuth，退出 Claude Code：

TEXT
/exit

之后 Telegram 或脚本再调用 Claude Code，就能复用这个登录状态。

如果你想确认浏览器 keeper 已经写入环境：

BASH
cat /home/bux/.claude/browser.env

不要把完整输出贴给别人。里面有会话相关地址。

绑定 Telegram：第一条消息很关键

如果启用了 Telegram bot，安装结束会提示打开 bot 地址。打开后发送任意消息，比如：

TEXT
hi

bux 的设计是 first-message-wins：第一个 chat_id 会被写进允许列表，后续其他聊天会被忽略。这比“谁知道 token 谁能用”安全一些，但仍然要注意两个点。

第一，部署完成后尽快绑定，不要把 bot 放着半天不管。

第二，最好不要把 bot 加到大群里。个人 Agent 值班机就应该是私聊入口，别给自己挖坑。

绑定后可以测试：

TEXT
/live

它会返回当前浏览器 live view。以后 Agent 遇到登录、2FA、验证码、人机确认，就可以把 live URL 发给你，让你接管一下再继续。

browser-harness 是怎么接进去的

bux 会把 browser-harness-js 安装到：

TEXT
/home/bux/.claude/skills/cdp

并把 CLI 链到：

TEXT
/usr/local/bin/browser-harness-js

Claude Code 需要操作浏览器时，会读取 browser.env，再通过 CDP 连接远端浏览器：

BASH
source ~/.claude/browser.env browser-harness-js 'await session.connect({wsUrl: process.env.BU_CDP_WS})' browser-harness-js 'await session.Page.navigate({url: "https://example.com"})' browser-harness-js 'await session.Runtime.evaluate({expression: "document.title"})'

这和传统 Playwright 脚本最大的区别，是浏览器会话可以长期存在。cookie、localStorage、登录态都跟着 profile 走。Agent 不需要每次从一个全新浏览器开始，也不用每次都让你扫码登录。

但这也意味着：profile 是资产。里面可能有邮箱、后台、管理台登录态，必须像 SSH key 一样保护。

遇到登录墙，不要让 Agent 硬闯

bux 有一个很重要的产品判断：遇到登录、2FA、验证码、Cloudflare、人机确认时，把 live view 发给用户，让用户接管，而不是让 Agent 猜密码、绕验证码、硬试。

正确流程应该是：

TEXT
Agent 发现登录墙 -> 停止操作 -> 发 live URL 给用户 -> 用户完成登录/验证 -> 用户回复 done -> Agent 继续原任务

这点非常关键。很多浏览器 Agent 项目容易把“自动化”讲成“绕过一切”。bux 反而走了更稳的路线：需要人的地方就让人介入，Agent 负责把介入成本降到一次点击。

写进你自己的操作规程里，可以这样约束：

MARKDOWN
## Human handoff policy - Never attempt to bypass CAPTCHA or 2FA. - If a site asks for login or identity verification, stop and share live URL. - Resume only after the user explicitly replies "done". - Before sending email, submitting forms, paying, deleting, or publishing, ask for confirmation.

别觉得这啰嗦。长期在线 Agent 最大的风险不是“不会做”，而是“做得太顺手”。

加 SSH：不要开密码登录

bux 会预创建 /home/bux/.ssh，并把 sshd 配成 pubkey-only、禁止 root 登录。你要登录 bux 用户，需要把自己电脑的公钥放进去。

在你自己的电脑上执行：

BASH
cat ~/.ssh/id_ed25519.pub

把输出的一整行追加到服务器：

BASH
sudo -iu bux mkdir -p ~/.ssh && chmod 700 ~/.ssh printf '%s ' 'ssh-ed25519 AAAA... your-key' >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

之后从本地登录：

BASH
ssh bux@your-box-ip

不要为了省事打开密码登录。Agent 服务器一旦有浏览器登录态和 API key，SSH 入口就必须收紧。

日志和排障路径

浏览器 keeper 出问题，先看：

BASH
sudo journalctl -u bux-browser-keeper -n 80 --no-pager sudo tail -n 120 /var/log/bux/keeper.log

Telegram bot 不回复，先看：

BASH
sudo journalctl -u bux-tg -n 80 --no-pager sudo tail -n 120 /var/log/bux/tg.log

常见问题就几类。

Browser Use API key 错了：

BASH
sudoedit /etc/bux/env sudo systemctl restart bux-browser-keeper

Claude Code 太旧，不支持 --session-id 或 --resume：

BASH
sudo npm install -g @anthropic-ai/claude-code@latest sudo systemctl restart bux-tg

browser.env 没生成：

BASH
sudo systemctl restart bux-browser-keeper sudo -iu bux cat ~/.claude/browser.env

Telegram 绑定错 chat：

BASH
sudo rm -f /etc/bux/tg-allowed.txt /etc/bux/tg-state.json sudo systemctl restart bux-tg

然后重新从正确账号发第一条消息。

清理重装

实验环境玩乱了，别在原地修半天。bux 提供了比较清楚的清理路径：

BASH
sudo systemctl stop bux-tg bux-browser-keeper bux-ttyd sudo rm -rf /etc/bux /opt/bux /home/bux/.claude /home/bux/.bux sudo userdel -r bux

然后重新运行安装脚本。

如果这是长期使用的机器，清理前先备份你要保留的东西：

TEXT
/home/bux/CLAUDE.md /home/bux/.claude/skills /home/bux/.claude/browser.env 只用于核对，不建议备份传播 /home/bux/任务产物目录

浏览器登录态是否保留，主要取决于 Browser Use Cloud profile，不只是本机文件。换 profile 前要想清楚。

上线前做一轮安全收口

装完能跑不代表能长期用。至少做这几项。

BASH
# 服务状态 systemctl is-active bux-browser-keeper systemctl is-active bux-ttyd systemctl is-active bux-tg || true # ttyd 是否只监听 localhost ss -lntp | grep 7681 || true # SSH 是否禁用密码和 root 登录 sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication' # 敏感 env 权限 ls -l /etc/bux/env /etc/bux/tg.env 2>/dev/null || true # bux 是否没有 sudo 特权 sudo -l -U bux || true

还要做一次行为验收。

TEXT
1. Telegram 发 /live，看能否拿到 live view。 2. 让 Agent 打开一个普通网页并返回标题。 3. 让 Agent 进入一个需要登录的网站，确认它会停下来发 live URL，而不是硬闯。 4. 让 Agent 写一封邮件草稿，确认它不会未经确认直接发送。 5. 重启服务器，确认 systemd 服务能恢复。

这些验收比“安装成功”更重要。长期在线 Agent 不是一次命令跑完就算上线，得看它遇到边界时会不会停。

可以怎么改得更适合自己

bux 把 Claude Code 的长期上下文放在：

TEXT
/home/bux/CLAUDE.md

你可以改这里，让 Agent 更像自己的值班员，而不是默认模板。

比如加一段邮件策略：

MARKDOWN
## Email policy - Summaries are allowed without confirmation. - Drafting replies is allowed. - Sending replies requires explicit user confirmation. - Never open attachments from unknown senders without asking.

加一段浏览器策略：

MARKDOWN
## Browser policy - Share a screenshot before irreversible actions. - Stop on login, 2FA, CAPTCHA, payment, delete, publish, or account setting changes. - Prefer read-only inspection unless the user explicitly asks for changes.

加一段文件策略：

MARKDOWN
## File policy - Put task outputs under /home/bux/work/<task-name>/. - Keep raw downloads separate from generated summaries. - Delete temporary files older than 14 days unless marked keep.

改完后重跑安装脚本或手动同步文件，下一次 Claude Code 会读到新的规矩。

最后说清楚它的边界

bux 这个方向很有价值，因为它把 Agent 从“我电脑上的一个会话”推进到了“我随时可以呼叫的一台工作机”。这一步看着小，实际是 Agent 产品化的关键：常驻、可恢复、有浏览器、有消息入口、有日志、有人工接管。

但它不是免维护系统。你仍然要管密钥、管 SSH、管浏览器 profile、管确认点、管日志。Agent 越长期在线，越不能靠信任感运行，必须靠边界运行。

真正稳的用法是：让 bux 接管重复、可观察、可回滚的事情；把登录验证、发送发布、付款删除、生产变更这些动作留给人确认。这样它就不是一个吓人的远程执行黑盒，而是一台能干活、会等你点头的 Agent 值班机。

上一篇：Recordly 上手：开源录屏工...
下一篇：TempKit.io Review...

评论