编码 Agent 搬进了「别人的电脑」：常驻云主机的机会与风险

2026 年 9 月 15 日，TermSquad 发布了一台面向 AI 编码 Agent 的「常驻云主机」。按官方新闻稿的说法，它把三件事放进同一个 Linux 环境：持久会话（persistent sessions）、共享项目记忆（shared project memory）和多 Agent 编排（multi-agent orchestration）。开发者可以合上笔记本，让 Agent 继续运行，再换一台设备的浏览器、手机或 SSH 工具接回来；仓库、文件和配置都留在远端环境里，不再依赖本地设备。它提供的是「那台电脑」，Agent 与模型由你自己挑。这个方向很实在：编码 Agent 越来越像需要长期驻留的工作负载，而不是一次性的命令行。但它也把一个老问题摆到了台面上——你的代码、密钥和运行环境，现在住在一台永远不睡觉的机器上。

一、它提供了什么：把开发环境搬到远端的意义

它的卖点可以一句话概括：会话不再随设备生死。你在手机或另一台电脑上重新接入，之前跑着的 Agent 还在原来的目录里、还持有原来的上下文。共享项目记忆让多个 Agent 不必每次都从零重建对项目的理解，多 Agent 编排则让它们在同一台机器上协同。对经常在通勤路上、在另一台设备上想继续推进的人来说，这确实解决了真实痛点。但请注意这句话的技术含义：一旦会话与设备解耦，你的开发环境就变成了一个需要独立运维的服务端。它需要认证、需要防火墙、需要资源限制，也需要一台在你不看它的时候仍然自律的机器。

# A persistent box is a server. Treat it like one from minute one.
sudo apt-get install -y openssh-server tmux
# Key-only auth, no passwords, no root login.
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/'            /etc/ssh/sshd_config
sudo systemctl restart ssh

# Then firewall to your known hosts only - the agent host is public by default.
sudo ufw default deny incoming
sudo ufw allow from YOUR_OFFICE_IP to any port 22
sudo ufw enable

一台永不下线的开发机，也是永不下线的攻击面

二、持久化把「进程」变成了「服务器」

本地跑 Agent，你合上盖子它基本就停了；云上常驻，它就是 7×24 在线的服务。这个差别意味着三件事。第一，认证方式要升级：SSH 必须只用密钥、禁止 root 直登、端口只对可信来源开放——因为一台公网可达的开发机，默认状态就是被扫描的对象。第二，资源要有上限：一个失控的循环在本地只烧你的电池，在云上会持续占用 CPU 与内存，并可能影响同一台机器上其它 Agent。第三，成本会持续累积：Agent 在你睡觉时继续工作，token 也在继续消耗，如果只在人盯着时才计量，你永远看不到真实账单。

# Three agents, one repository: give each its own worktree and branch,
# so a refactor in one cannot rewrite files another is still reading.
git worktree add ../wt-refactor -b agent/refactor
git worktree add ../wt-tests    -b agent/tests
git worktree add ../wt-docs     -b agent/docs

# Each agent runs in its own directory while sharing one object store,
# and you merge branches the way you always do. No shared mutable state.

三、多 Agent 同机：先隔离，再谈协作

把多个 Agent 放进同一台机器，最容易被忽略的是文件层面的相互踩踏。两个 Agent 同时改同一个仓库，一个在重构、一个在读文件，很容易出现「读到的文件在半路被改写」。Git worktree 是这里最省事的解药：给每个 Agent 一个独立的工作树和独立分支，共享同一个对象库，互不干扰，最后照常合并分支。这一招把「共享可变状态」变成「各自的分支」，让并行的代价落到合并那一步、而不是运行中的混乱。完成隔离之后，共享记忆和多 Agent 协作才有意义——协作的前提是彼此不破坏对方正在做的事。

# Do NOT bake tokens into the image or clone a .env onto the box.
# Inject per session, keep it out of shell history, and let it expire.
export ANTHROPIC_API_KEY="$(pass show agents/anthropic)"
tmux new-session -d -s refactor -c ~/wt-refactor \
  "ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY claude"

# A long-lived cloud box is a long-lived credential. Rotate on a schedule,
# and prefer short-lived tokens over keys that outlive the task.

凭据不要烘进镜像，要按会话注入

四、凭据：不要烘进镜像，要按会话注入

常驻机器上最容易犯的错误，是图省事把 API key 写进镜像、或者把本地的 .env 直接拷上去。这两件事都等于把长期有效的凭据永久地放在一台 24 小时在线的机器上。更稳的做法有三条：按会话注入而不是烘进镜像；注入过程不要进入 shell 历史与日志；优先使用能过期的短期令牌，而不是永不过期的密钥。另外要定期轮换——一台常驻的开发机，就是一个常驻的凭据。把它当作生产服务器来管，而不是当作一次性的 sandbox。

# Cap each agent's CPU, memory and IO so one runaway loop cannot take the box.
sudo systemd-run --unit=agent-refactor \
  --property=CPUQuota=200% \
  --property=MemoryMax=4G \
  --property=IOWeight=50 \
  --working-directory=/home/dev/wt-refactor \
  /usr/bin/tmux new-session -d -s refactor

# Cap the network the agent may reach, not just the CPU it may use.
# An agent that can POST your repo to any host will eventually do so.

五、落地代码：从 sshd 到按 Agent 计量

第一段是把开发机当服务器来加固：只允许密钥认证、禁止 root 登录、防火墙只放行可信来源。第二段用 git worktree 给每个 Agent 一份独立工作树与分支，避免同机互踩。第三段演示按会话注入密钥，并强调轮换与短期令牌。第四段用 systemd-run 给每个 Agent 设 CPU、内存与 IO 上限，顺带提醒你网络出口同样需要限制。第五段是按 Agent 计量的会话成本表——常驻环境的意义在于你不在时它也在干活，所以计量也必须在你不在时继续跑。

// Persistent sessions accrue cost in the background. Meter them on a timer.
type SessionTick = {
  session: string;
  agent: string;
  tokens: number;
  usd: number;
  ts: string;
};

export function tick(s: SessionTick) {
  db.sessions.insert(s);
}
// Report per-agent spend per day. The whole point of an always-on box
// is that work continues - so your meter has to run while you sleep too.

多 Agent 共处一机，先做隔离再谈协作

六、清单：把常驻开发机当成服务来运维

五个检查项。第一，这台机器只允许密钥登录、禁止 root 直登、端口只对可信来源开放了吗？第二，每个 Agent 是否都有自己的工作树与分支，而不是共享同一份可变的检出一？第三，凭据是按会话注入的，还是被永久烘进了镜像与磁盘？第四，CPU、内存、IO 与网络出口是否都设了上限？第五，你有没有一个在你不看屏幕时仍然运行的计量与告警？常驻云主机的吸引力是「你不用在场」；而它的风险恰恰也是「你不用在场」。把这句话反过来读，就是这张清单。