一句话导读:2026 年想搭一套能整夜接 issue、改代码、开 PR 的 AI Coding Agent,很多人第一步就搞错了——以为装个 Cursor 或买个 API 就够了。真正跑得久的 autonomous coding agent,背后还得有常驻执行面、任务调度与客观验证。下文按架构分层、部署拓扑、最小可行栈、生产加固四条线展开,是一份可以直接照着做的完整部署指南。
部署前先分清两层
AI Coding Agent 是能自主读上下文、改代码、跑命令的程序(如 OpenHands、Claude Code、Cursor Background Agent);它跑在 AI coding agent server——即24/7 在线的执行与调度节点——之上。没有常驻节点,Agent 只是你笔记本合盖就停的脚本;没有 Agent,节点只是空转的 Mac mini。
1. 24 小时 AI Coding Agent 到底是什么?
和 IDE 里装的 Copilot、Cursor Tab 不同,24 小时 AI Coding Agent 解决的是另一件事:当你不在场时,谁有权在真实环境里改仓库、跑命令、拿验证信号?
一套能跑通的部署通常包含四块能力,缺任何一块都称不上「24 小时 autonomous coding agent」:
- 常驻执行环境(L0)——不断电、不断网的 macOS 或 Linux 节点,能跑
git、npm、xcodebuild。 - 编码 Agent 进程(L3/L5)——结对层(Claude Code)或自主层(OpenHands),负责读上下文、写 Diff。
- 任务入口与队列——GitHub issue label、Webhook、定时 cron、Slack 指令等,把「要做的事」喂给 Agent。
- 客观验证(L1)——GitHub Runner 或本地测试脚本,产出组织能信的 Fact,而不只是 Agent 自称「搞定了」。
一句话:执行节点是地基和水电;Agent 是干活的工人;Runner 是质检员。 许多团队翻车,是因为只买了模型 API、在 MacBook 上跑了个脚本,就指望它能当 24/7 AI Coding Agent——合盖、休眠、内存争抢、出口 IP 变化,都会在凌晨三点把任务掐断。
2. 一张图:从任务入口到可合并 PR
下面用因果链概括一条典型的 autonomous coding agent 流水线。左侧是主链,右侧是「能跑通」与「会翻车」的对照。
24/7 AI Coding Agent 主链
跑通所需
- 节点 24/7 不断电
- Agent token 与 git 权限分离
- MCP 默认只读
- 分支保护 + 必过 CI
- 任务超时与并发上限
典型翻车
- 笔记本合盖任务中断
- 无 Runner,PR 无人敢合
- Agent 写生产库
- 大仓无 CodeGraph 盲改
- 多任务抢内存触发 Swap
3. 五层组件拆解
与 AI Agent 基础设施分层 一致,24/7 Agent 部署不必一次买齐,但要知道每层缺了会怎样:
| 层 | 在部署里的角色 | 典型选型 | 24/7 必需? |
|---|---|---|---|
| L0 执行环境 | Agent 的 24/7 运行底座 | Cloud Mac / Mac mini | ✅ 必需 |
| L1 验证 | PR 能否合并的客观信号 | GitHub self-hosted Runner | 团队场景必需 |
| L3 结对编码 | 白天人工在场、复杂改动 | Claude Code / Cursor Agent | 可选(与 L5 叠用) |
| L4 上下文 | 大仓导航、issue、API | MCP(GitHub / CodeGraph) | 大仓强烈建议 |
| L5 自主工作流 | autonomous coding agent 核心 | OpenHands、Cursor Background Agent | 无人值守必需 |
Claude Code 生产 Diff,Runner 生产 Fact,OpenHands 生产 Workflow——这三句是部署 AI Coding Agent 时的分工口诀。若你只想夜间自动清 lint issue,L0 + L5 + L1 往往就够;若还要白天结对啃架构,再加 L3,同机叠跑时注意内存排程(见 并行内存排班)。
4. 部署拓扑:本地 Mac mini vs Cloud Mac
24 小时 AI Coding Agent 的执行节点可以是物理机、虚拟机或云租用实例,选型看在线 SLA而不是看牌子:
| 维度 | 办公室 Mac mini | Cloud Mac(数据中心) |
|---|---|---|
| 24/7 可靠性 | 依赖办公室不断电、不断网 | 机房级供电与骨干出口 |
| 出口 IP | 家用宽带可能变化 | 常配独享 IPv4,Webhook 白名单稳定 |
| 与 Runner 同机 | 可以,注意 16GB 是否够 | 常见做法,一 job 一 workspace |
| 适合人群 | 已有闲置 Mac、能管硬件 | 不想买机、要快速上线 autonomous agent |
| iOS / Xcode 构建 | 真 macOS,可行 | 真 macOS,可行(非模拟器替代) |
纯后端仓库(Go / Node / Python)理论上 Linux VPS 也能跑 AI Coding Agent,但一旦 workflow 里出现 xcodebuild、swift test 或 Apple 签名,执行面必须回到 macOS。这也是 2026 年多数部署指南默认写 Mac 的原因——不是情怀,是 ABI 边界。
5. 最小可行栈(MVP):先跑通一条夜间任务
别第一天就搭 Kubernetes + 向量库。下面是一套我们见过最快跑通「issue → PR → CI 绿」的组合:
- 节点:M4 Mac mini 16GB 或同等 Cloud Mac;叠 OpenHands + Runner 建议 24GB。
- Agent:OpenHands(自主)或 Claude Code + 简单 shell 包装(半自动)。
- 模型:Claude / GPT API;本地 Ollama 可选,非 24/7 必需。
- 入口:给 issue 打
agentlabel 触发 GitHub Webhook。 - 验证:同机 self-hosted Runner,
runs-on: [self-hosted, macOS]。 - 上下文:GitHub MCP 只读 + 仓库
AGENTS.md写清红线。
第一条任务怎么选
从 lint cleanup、依赖小版本升级、补单元测试 开始——输入清晰、行为可验证、改坏了容易回滚。别让第一条 autonomous coding agent 任务是无测试的大重构。
6. 7 步部署清单
以下按顺序执行,每步都可单独验收——这是本指南的核心实操部分,避免「装完全套才发现 Runner 没注册」。
Step 1 — 准备 L0 节点。 确保 SSH、时钟同步、磁盘 ≥ 256GB(Xcode + 多 workspace 很吃空间)。Cloud Mac 用户先完成实例初始化与静态 IP 确认。
Step 2 — 创建受限 git 身份。 为 Agent 单独建 GitHub App 或 deploy key:只写 feature 分支,默认无 main 写权限。生产密钥、npm token 不进 Agent 环境变量。
Step 3 — 安装编码 Agent。 OpenHands 示例(Docker 或原生安装依官方文档):
# 在 L0 节点上,克隆 OpenHands 并按官方文档配置 LLM API Key git clone https://github.com/OpenHands/OpenHands.git cd OpenHands # 配置 .env:MODEL、GITHUB_TOKEN(只读 issue)、WORKSPACE_BASE make run
Step 4 — 接入 MCP(可选但推荐)。 大仓接 CodeGraph MCP,让 autonomous agent 先「看得见」依赖关系再动手。
Step 5 — 注册 GitHub Runner。 与 Agent 同机注册,label 如 macos-agent。workflow 片段:
# .github/workflows/agent-verify.yml name: Agent PR Verify on: pull_request: types: [opened, synchronize] jobs: verify: runs-on: [self-hosted, macOS, agent] steps: - uses: actions/checkout@v4 - run: swift test # 或 npm test / go test
Step 6 — 配置任务入口。 GitHub Webhook 指向 server 上的轻量 HTTP 服务,或使用 OpenHands 内置集成;用 label agent-ready 过滤,避免每个 comment 都触发。
Step 7 — 监控与熔断。 记录每次任务的 token 用量、耗时、改动文件数;单任务超时(如 90 分钟)自动 kill;并发设为 1,直到稳定后再开 2。
7. 生产加固:别让 Agent 半夜改坏主线
Autonomous coding agent 最大的风险不是「模型笨」,而是权限过大 + 无人复核。上线前至少落实:
| 红线 | 做法 |
|---|---|
| 分支保护 | main 禁止直接 push;Agent 只能开 PR |
| 必过 CI | required checks 包含 Runner job,无绿灯不可合并 |
| 密钥隔离 | 生产 DB、App Store Connect API 不进 Agent 环境 |
| MCP 最小暴露 | 默认只读;写操作需人工开闸(见 MCP 权限) |
| 审计日志 | 保留 Agent 每步 shell、diff、模型请求 ID |
| 资源上限 | cgroup / ulimit 限制子进程;防 fork 炸弹 |
「全自动合并」是下一阶段
24/7 AI Coding Agent 的第一目标应是稳定产出可审查的 PR,而不是自动 merge。人类或另一套策略 Agent 审过再合,比「半夜自动合了带后门的 PR」便宜得多。
8. 成本与规格怎么估
一套 24 小时 AI Coding Agent 的账单通常分三块:
- 算力节点:Mac mini 一次性 + 电费;Cloud Mac 按日/周订阅(对比见 租 vs 买)。
- 模型 API:autonomous agent 多轮循环,单次任务常是结对编码的 5–20 倍 token;建议任务级预算上限。
- 人力运维:初期每周几小时看日志、调 prompt、清 stuck 任务;别假设「装上就零维护」。
规格经验:仅 OpenHands + 中等仓库,16GB 可跑但易 Swap;Agent、Runner、可选 Ollama 同机时,24GB 是更省心的起点(见 16GB vs 24GB)。
9. 常见翻车点
- 把结对工具当 autonomous agent——Claude Code 会话结束就停,除非你再包一层调度。
- 无 Fact 层——Agent 自称测试通过,Runner 从未跑过(为何值得自建 Runner)。
- 并发过大——两台 autonomous task 同时跑,16GB 机器直接 Swap 到怀疑人生。
- 上下文裸奔——百万行 monorepo 不让 Agent 用 CodeGraph,等于盲人 refactor。
- 忽略时区与通知——任务失败无告警,早上才发现仓库里躺着半成品 PR。
10. 常见问题
Q:Cursor Background Agent 算不算 24 小时 AI Coding Agent?
A:Cursor 提供托管执行面,你本地不必 24/7 开机——但仓库权限、CI 验证、合规边界仍要你自己配。自托管部署的意义是数据与执行完全在你控制的节点上。
Q:能不能用 GitHub Copilot Workspace / OpenAI Codex?
A:可以作 L3/L5 的模型与界面层;部署层仍是执行环境 + 调度 + 验证。Codex 与 ChatGPT 合并后更偏结对,无人值守仍需 workflow 包装(见 Codex 合并解读)。
Q:Linux 上跑 Docker 版 OpenHands 够吗?
A:纯 Web / 后端够;任何 Apple 工具链步骤都必须切到 macOS 节点。混合团队常见架构:Linux 跑调度,macOS Cloud Mac 跑构建与 Agent。
Q:一个人维护有必要上 24/7 吗?
A:若你只想白天结对编码,不必。24/7 AI Coding Agent 适合:issue 积压、跨时区团队、或想把「清技术债」从白天挪到夜间机器时间。
Q:和 Devin / Factory 等商业 autonomous agent 比?
A:商业产品卖的是打包好的 Agent + 执行面 + 界面;自部署的意义是可审计、可定制权限、可与现有 Runner/MCP 栈对齐。许多团队最终是「商业 Agent 做探索,自托管节点跑量产任务」。
ZavCloud Cloud Mac
把 AI Coding Agent 部署在不断电的 macOS 上
数据中心级 Mac mini M4 独享实例:适合叠 OpenHands、Claude Code 与 GitHub Runner,作为 24 小时 AI Coding Agent 的执行底座。
查看 Cloud Mac 方案