一个念头，Agent 接手
之前我做了一个 Bark Notify Skill 安装到 Codex 里面，导致我对 Bark Server 的需求更大了，原来 Bark Server 运行在 homelab K8s 上，但我的 homelab 也不是 24h 开机，所以有时候就无法收到 Agent 给我的通知。
于是想着将 Bark Server 搬到 “赛博活菩萨” Cloudflare 上面，这样我就能 24h 接收 Agent 的通知信息了。
当前我已经把大部分配置、运维工作交给 Agent 来完成了，这次也一样，整个事项还是会交给 Agent。从调研、选型、资源评估、部署、数据迁移和验证都由 Agent 完成。我全程没有打开终端，只在关键节点提供要求和操作授权。
两段 Prompt 实现一次完整迁移
Prompt 一：研究可行方案
我发出的第一段 Prompt 是：
我不想在本地部署 bark server 了，你研究下有没有能够满足以下条件的方案：
1. 托管在 cloudflare workers
2. 开源
3. 满足当前 repo 的所有调用参数且能在 iOS Bark 实现这些参数调用的结果这三个条件对应了运行平台、程序要求、兼容范围。Agent 随即检查当前 repo 对 Bark 的调用参数，再到 GitHub 搜索候选实现，逐项核对接口、参数解析、维护状态和部署方式。
最终选中 cwxiaos/bark-worker。它采用 GPL-3.0 许可证，运行在 Cloudflare Workers，而且非常贴心地查看了这个仓库的活跃度，告诉我最近一直有 commit！说明这个仓库一直有人维护。
技术方案支持 Bark Server 的 register、ping、healthz、info 和 push 接口，也支持路径参数。现有 repo 使用的标题、正文、分组、图标、通知级别等参数可以继续传给 iOS Bark。
Cloudflare 平台的兼容方面，Agent 推荐 D1 版本。设备 key 与 APNs token 的映射保存在 D1，日常推送会查询设备记录和 APNs authorization token。
可行性满足之后，就可以继续评估资源和迁移方式。
Prompt 二：评估资源与无缝迁移
第二段 Prompt 进一步明确了用量和兼容要求：
现在不考虑 key 过期的问题。
现在评估：
1. 我部署之后会占用 Cloudflare 哪类、分别多少资源？假设按1000次推送/天
2. 我想保持本机私有配置中的 BARK_SERVER 和 BARK_KEY，只改当前 bark server 的域名指向无缝迁移，是否可以实现？（不保留历史推送信息）Agent 按每次推送查询设备映射和 APNs authorization token 进行估算：
| Cloudflare 资源 | 1000 次推送/天的估算 | 当前免费额度 |
|---|---|---|
| Workers 请求 | 约 1000 次/天 | 10 万次/天，占约 1% |
| Workers CPU time | 约 1000 次短时执行/天 | 免费计划每次调用 10 ms CPU time |
| D1 读取 | 基础约 2000 行/天 | 500 万行/天，占约 0.04% |
| D1 写入 | APNs authorization token 刷新约数十行/天；注册、更新和迁移时也会写入 | 10 万行/天 |
| D1 存储 | 只保存设备映射，个人用量很小 | 5 GB |
| APNs 外部请求 | 约 1000 次/天 | Worker 发出的 subrequest 不单独计费 |
实际 D1 读写量还会受到查询、索引和建表语句影响，部署后可以在 D1 Metrics 中查看 rows_read 与 rows_written。这个量级有充足余量，预计新增账单为 0 元。免费额度和计费规则以 Cloudflare 当期文档为准。
无缝迁移也可以实现：
BARK_SERVER继续使用我当前的域名，只把该域名切到 Worker（不迁移也可以，但我想让 Agent 全自动维护解析记录，所以也一起迁移）。BARK_KEY继续使用原值，把对应的 APNs token 映射导入 D1。- 历史推送记录不迁移。
- 所有客户端和 Agent Bark Notify Skill 保持原配置。
第二段 Prompt 给出了明确结论：资源成本可接受（免费额度足够了），域名和 key 可以保留。我随后让 Agent 执行迁移。
Agent 执行迁移
基于上面两段 Prompt 及中间一些交流性质的对话，Codex 已经完全理解我想要达成的目标（上下文已经足够了），所以我向 Codex 下达部署的命令，它就能完成整套操作：
- Fork bark-worker，创建 Worker 和 D1 数据库。
- 配置最小权限的 Cloudflare 凭据与部署流程。
- 从旧服务提取 device key 和 APNs token 映射，导入 D1。
- 配置 Bark Server 自定义域名。
- 关闭不需要的新设备注册与查询接口。
- 部署 Worker，检查健康状态和运行日志。
- 使用原
BARK_SERVER和BARK_KEY发出测试通知。
迁移数据只包含继续推送所需的设备映射。临时使用的迁移凭据在导入后删除，旧 K8s 的 Bark Server 服务暂时保留，用于观察期内回滚。
整个过程我只协助配置了 Cloudflare 部署所需要的 TOKEN，也是在 Agent 的提示下来操作。
验收结果
Agent 依次验证 Worker 路由、D1 设备记录和 APNs 返回。
我去掉内网 Bark Server 解析记录，再让 Agent 使用原有私有配置触发了一条真实通知，手机正常收到，服务端迁移完成。
以上过程，从想法提出到上线验收，大约用了两小时。我的实际输入集中在两段 Prompt、Cloudflare TOKEN 配置。Agent 负责其余工作，并把调研结论连续推进到部署结果。
小结
从这次以及最近的实践来看，2026 年的 Agent 已经完全可以以极低的使用门槛来完成大部分工作：先给出目标和约束条件，让 Agent 调研及给出方案，人只要评估结论满足要求后，直接授权执行和验证。