我为AI首席参谋打造了手机界面 — 基于现有费用，零额外成本
一个补丁任务队列，让我随时随地用手机信号提交工作，在60秒内被我的家用桌面电脑拿起，以近实时的方式流回手机。支持多轮对话。零新增订阅。这是架构的工作原理。
摘要
I built a phone interface for my AI chief of staff that lets me submit work from anywhere with cell signal, picked up by my home desktop within 60 seconds, with live-streaming output back to the phone every 1.5 seconds. • Multi-turn conversation is handled as an immutable chain of database rows — each turn is a fresh CLI invocation, not a persistent session. • The whole stack costs $0/mo on top of what I already pay because it runs on my existing Claude Pro Max plan, my existing Neon database, my existing Vercel deployment, and Windows Task Scheduler. • Three hours of focused build time. No new SaaS, no new server, no new auth surface.
Quick Check
对还是错：AI 工具将在 2 年内完全取代 SEO 的需求。
过去六个月，我一直在构建 Aaron——我的 AI 首席参谋。他以 Claude Code 会话的形式运行在我家的 Windows 桌面上，协助我管理 23 个客户项目。问题在于：我有 70% 的时间坐在桌前，但 Aaron 最有价值的使用场景恰恰发生在我不在桌前的时候。走出客户会议，脑子里涌出一个想法。坐在机场候机厅，还有 90 分钟可以利用。深夜 11 点躺在床上，突然想起主页头部区域还需要重写。
在这周之前，我的选项都很糟糕。我可以通过 Retell 语音拨打家用电话。我可以打开笔记本电脑。或者只是把想法记下来，等真正坐下来执行时，那股劲儿早就散了一半。这些都比不上让 Aaron 像真正的助手一样随时待命在我手机上。
于是我构建了一个手机接口。以下是最终正确的架构方案——以及我之前考虑过的每条"把 AI 智能体接入手机"路径为何行不通。
我先尝试了什么，每条路径又为何失败？
Claude 移动版应用。 Claude.ai 移动端是一个聊天客户端。它没有工具访问权限。它无法读取我的文件、运行代码、查询数据库或推送到 GitHub。对于一个需要真正执行任务的首席参谋智能体来说，这是个硬伤，根本行不通。Anthropic 官方确认移动端应用仅限对话功能——工具调用专属于 API 和 Claude Code 界面（来源：Anthropic 帮助中心，Claude 应用文档，2025 年）。
从手机 SSH 连接到家用桌面。 Termius 配合 Tailscale 可以在手机上打开 Windows PowerShell 提示符。从那里运行 `claude` 完全可行——完整的工具访问、完整的会话状态、所有技能。但在 6 英寸屏幕上敲长提示词很痛苦，体验像"Linux 管理员的怀旧时光"，而不是"现代应用"。可以作为备用方案，但不适合作为主要日常工具。
构建实时 WebSocket 聊天连接到托管的 Claude 会话。 这是大多数团队的选择。也是大多数团队最终止步的地方，因为在 WebSocket 上保持 Claude Code 会话持久运行既繁琐、成本高昂，又会增加延迟。Vercel 2024 年 AI 基础设施报告的行业基准数据显示，38% 的 LLM 功能交付团队将"会话持久性与空闲计算"列为最大的意外基础设施成本（来源：Vercel AI State of Build 2024）。会话"保持存活"的每一分钟都在消耗计算资源，无论用户是否在积极输入。
最终奏效的路径不是上述任何一种。它是一个队列。
用一段话描述这个架构是什么？
我从手机表单（SEO 控制台上的移动端响应式网页）提交一项任务。提交操作向 PostgreSQL 数据表写入一条记录。家用桌面上的 Windows 任务计划程序每 60 秒触发一次，通过 `SELECT ... FOR UPDATE SKIP LOCKED` 原子性地认领最旧的待处理记录，并以我的提示词通过 stdin 管道方式启动 `claude` CLI。CLI 以完整的工具访问权限运行——就像我坐在键盘前操作一样——并流式输出结果。运行脚本每 1.5 秒将最新积累的输出写回同一条 PostgreSQL 记录。我的手机每 1.5 秒轮询该记录并渲染持续增长的输出内容。任务完成后，运行脚本通过 Resend 将结果以邮件形式发送给我。如果我想继续对话，表单有一个"回复"按钮，会创建一个携带先前提示词和结果作为上下文的跟进任务。Aaron 每次都能看到完整的对话线程。
这就是整个系统。
为什么这比实时 WebSocket 更好？
人们对"手机上的智能体"默认想到的是聊天应用。你输入，智能体流式回复，你再回复，如此循环。要实现这个效果，需要在用户阅读期间保持服务器端智能体会话存活。而这个会话会在计算和工程时间上持续消耗成本——Claude 需要记住对话内容、保持工具状态、管理超时。
队列模型颠倒了这种关系。两次对话之间，会话不需要保持存活。每一轮都是全新的 `claude` CLI 调用。对话历史存储在 PostgreSQL 中——而非进程内存里。当我点击"回复"时，新任务会启动一个新的 CLI 进程，并将完整对话线程作为上下文传入。该 CLI 加载自身上下文（通过我的脑部同步仓库），给出回复，然后退出。
这个模型带来三个结果：
零空闲计算。 没有智能体会话在等待我的下一条回复。当我没有主动驱动任务时，什么都不在运行。如果你按分钟或按 token 计费，这一点至关重要。a16z 2024 年对生产级 AI 聊天应用的基准测试发现，空闲会话计算平均占总运行时成本的 41%（来源：a16z，"AI Cost Structure Benchmarks"，2024 年）。
状态永久存活。 任务进行中浏览器崩溃？记录继续写入。手机没电？在桌面打开同一个 URL，进行中的任务就在那里。想把一个线程分享给队友？发给他们任务 ID 的 URL 就行。PostgreSQL 自 1996 年以来一直在可靠地做崩溃恢复；依赖它而不是内存中的会话，是无聊但正确的选择。
并发轻而易举。 多个排队任务就安静地坐在队列里。运行器一次取一个。没有竞态条件，没有会话冲突，没有"智能体是否忙碌"的 UI 状态。数据库记录的状态字段是唯一的事实来源。通过 SKIP LOCKED 实现的原子认领是 PostgreSQL 9.5（2016 年）引入的特性——在生产作业队列系统中已经久经考验近十年。
流式输出的"幻觉"是如何实现的？
人们期望 AI 聊天能流式输出——字母一个一个地出现。队列模型没有持久套接字，所以我用轮询来模拟流式效果。
诀窍在这里。CLI 运行脚本不等待 `claude` 完成再写入输出。它注册了一个 stdout 监听器，持续积累实时输出，并每 1.5 秒将最新积累的文本刷新到 PostgreSQL 记录中。手机每 1.5 秒轮询该记录。端到端来看，你看到输出以 1.5 秒为间隔持续增长。
这和真正的流式协议一样流畅吗？不。每次"跳跃"是一段文字突然出现，而不是流畅的逐字打字机效果。但足够接近，用户体验读起来像"实时"。对于手机驱动的工作流——我是在喝咖啡的间隙查看任务进展——"1.5 秒内实时"与真正实时无从区分。
Nielsen Norman Group 的基础 UX 研究确立了这样的标准：1 秒以内的响应感觉是即时的，10 秒以内的响应能保持用户的心流（来源：Jakob Nielsen，"响应时间：三个重要极限"，NN/g，1993 年，至今仍被广泛引用）。1.5 秒对于"查看进度"这种交互场景来说，舒适地落在那个"足够即时"的窗口内。
如果我需要低于 200ms 的流式输出来实现真正的聊天消息 UX，轮询就不够用了——我需要 WebSocket 或 Server-Sent Events。但对于"智能体正在做实际工作，每隔几秒汇报进度"这种场景，1.5 秒轮询是正确的权衡。架构与使用场景相匹配。
没有会话，多轮对话是如何处理的？
这是我描述这个系统时最常被问到的问题。如果每轮对话后会话都结束，Aaron 如何记住我们刚才聊的内容？
答案是：他不记住——他重新阅读。每一个跟进轮次都是一个新任务，将上一个任务的提示词和结果作为上下文携带在自己的 payload 中。组合后的 payload 大致如下：
# 先前对话上下文
>
## 第 N-1 轮——用户的原始任务
[先前提示词]
[Aaron 的回复]
>
---
>
# 第 N 轮——用户的跟进
[新提示词]
>
请回应跟进问题。自然地运用先前上下文。
这段内容以 stdin 形式传入全新的 `claude` 调用。Aaron 阅读完整的线程，结合先前上下文回答新问题，然后退出。新一轮写入自己的记录，成为下一次跟进的上下文。
对话是一条不可变记录的链，而不是一个会话。每条记录可以永久查询。我可以将一个线程导出为 markdown 文件，通过 URL 与队友分享某一轮对话，或者通过重新提交任何记录的 payload 来重放旧线程。对话历史是数据，而非进程状态。这就是整个架构上的核心收益。
这实际上花费多少？
这个系统使用：
- Claude CLI，在我的 Pro Max 订阅下。 每次任务运行器调用都会启动一个新的 `claude` 进程。Pro Max 给了我充足的配额；在一个月的真实使用中我从未触及上限。一个额外任务的边际成本实际上是 $0——假设我在计划配额内，我确实是。
- Neon PostgreSQL，我的控制台已经在用了。新的 `patch_tasks` 表只有几 KB，远低于 Neon 免费层的存储限制（3 GB）。
- Vercel 托管控制台。新 API 路由是三个小型处理器，完全适配现有项目。每条路由新增的冷启动时间：低于 50ms。
- Windows 任务计划程序，内置于我的操作系统，免费。替代了我本来需要花 $5/月在 VPS 上运行的 cron 守护进程。
- Resend 用于结果邮件。免费层每天 100 封邮件。对于一个每天提交不超过 20 个任务的用户来说绰绰有余。
- 没有新服务器，没有新 SaaS，没有新 SSO。 我的技术栈中唯一的新增是数据库表和三条 API 路由。
每月总成本：在原有基础上仍为 $0。整个构建花了三小时专注的智能体驱动工作——没有手工工程。我来指挥，Claude 来实现，我来验证。这就是我的内容引擎在所有项目上运行的开发循环。
相比之下，过去 60 天里我看到的最常见"手机上的 AI 智能体"SaaS 报价，起步价是每用户 $29/月（托管 Claude 会话，自定义 UI），高端可达 $199/月的"团队工作区"。对于一个已经自己付基础设施费的个人操作来说，那纯粹是浪费。
这开启了哪些工作流？
工作流 1：在健身房捕捉想法。 跑步时我想到了一件事。我打开手机上收藏的控制台 URL，输入三行，点击提交，关闭浏览器。40 分钟后我冲澡时，结果已经在我的收件箱里了。从"想法捕捉"到"执行落地"的延迟，从"今晚坐到桌前再搞"缩短为"冲澡前就完成了"。
工作流 2：候机厅审计。 我在 YVR 机场，候机 90 分钟。我想对一个竞争对手的主页做竞品拆解。我从手机提交"用 master-architect REVIEW 审计 X，并提出 3 项改进建议"。到达登机口时，报告已经在我的邮箱里了。我在飞机上阅读。斯坦福大学 2023 年对知识工作者的生产力研究发现，90 分钟以下的碎片化时间块通常被浪费——太短无法进行深度工作，太长又不能什么都不做（来源：Nicholas Bloom 等，斯坦福经济政策研究所，2023 年）。队列将这些碎片化时间变成了智能体驱动的产出时间。
工作流 3：多轮草稿撰写。 我提交一封给客户的邮件初稿。结果返回。我点击"回复"，输入"压缩 30%，删掉截止日期"。新任务带着完整上下文启动。两分钟后新结果返回。重复直到满意为止。每一轮写入一条新记录，但读取先前线程。对话是不可变记录的链，而不是会话。
工作流 4：临睡前修复队列。 晚上 11:30。我突然想到某个客户网站的主页 hero 区域还显示着旧的上线日期。我打开队列，输入"把 [客户网站] 的 hero 日期从 4 月 30 日改为 5 月 20 日"，提交，放下手机。早上起来，有封邮件说已经推送到生产环境了。我从来没有打开过笔记本电脑。
这个构建不是什么
这不是一个试图与 Claude 移动应用竞争的聊天客户端。Claude 应用是用来提问的。这是用来分配工作并观察执行过程的。不同的工具，不同的任务。
这不是实时多人聊天。它是单用户——我——向单一执行器——我的家用桌面——提交任务。添加队友意味着在队列上增加多用户身份验证，那是一个不同的系统。今天我不构建它，因为今天我不需要它。（未来的我可以在真正有第二个用户时再构建。）
这不是我坐在桌前做专注工作时的替代品。它适用于我有 30% 的时间不在桌前但仍需要做出行动决策的场景。桌面会话和手机队列是互补的，而非竞争关系。
这不是新奇的计算机科学。带原子认领的作业队列已有数十年历史。PostgreSQL SKIP LOCKED 于 2016 年发布。轮询状态是分布式系统中最古老的模式。新颖之处在于将这些原语围绕 LLM CLI 组合起来，产生出感觉像现代智能体产品的东西，却没有任何"现代智能体产品"的基础设施。
我接下来要构建什么？
队列是第二阶段。第一阶段（Tailscale + Termius SSH 从手机连接到家用桌面）适用于我想在手机上使用原生 Claude Code 的场景。第三阶段可能是一个"审核队列"——一个跨所有客户的所有任务的控制台视图，支持筛选和批量操作。
更深层的收益是，队列现在成为了任何未来智能体能力的通用手机接口。当我添加一项新技能——比如对客户网站进行 master-architect 设计审查——它自动可以从手机调用，因为手机需要知道的只是队列端点。智能体获得新能力，队列 UI 不需要改变。这个特性——免费的可扩展性——在软件设计中很罕见。只有当接口与底层能力层真正正交时才会发生。我构建它所基于的控制台在 Zealous Digital 案例研究中有更详细的记录。
关于智能体系统，我一再重新学到的道理是：瓶颈不在于模型能力。在于接口设计。构建能够完成工作的智能体，现在已经是容易的部分。构建能够在真实生活中经受考验的人机交互循环——手机、飞机、淋浴间、多日项目——这才是大多数团队投入不足的地方。
我投入不足。现在我追上来了。如果你想了解我如何从战略层面思考这类问题，我的构建日志存档有完整的系列文章。
Where Are You Right Now?
你的业务目前在 AI 方面最大的挑战是什么？
常见问题
Why not just use the Claude.ai mobile app?
The Claude mobile app is a chat client without tool access. It cannot read your files, run code, query your databases, push to GitHub, or execute any of the actions an agent needs to do real work. It's a conversation tool, not an automation tool. The queue gives the phone a way to dispatch real work to a desktop Claude Code session that does have full tool access.
How long does the phone wait before the task starts?
Up to 60 seconds. Windows Task Scheduler is configured to fire the runner every minute. In practice, average first-touch latency is around 30 seconds — half the scheduler interval. If you need sub-second pickup, you would run a persistent runner instead of a scheduled one, but that costs idle compute.
What happens if my home desktop is asleep when I submit a task?
The task sits in the queue with status `queued` until the desktop wakes up and the runner fires. The system has no opinion about machine state — it just keeps polling. I set my desktop to "never sleep when plugged in" so this is a non-issue in practice. For travel scenarios, I leave the machine on.
How does this compare to commercial AI agent SaaS products?
The closest commercial equivalents I've evaluated charge $29–$199/mo per user for a managed session and a chat UI. None of them give you full tool access (file system, shell, GitHub) — they're sandboxed by design. The queue gives me a personal AI agent with full local-machine privileges, running on infrastructure I already pay for, with zero marginal cost. The tradeoff is that I'm responsible for keeping the desktop on and the runner healthy. For a solo operator, that's a fair trade.
Could I run this without the Claude Pro Max plan?
Yes, but the economics change. Pro Max gives me effectively unlimited quota for my volume. Without it, each task would hit the Anthropic API directly and cost a few cents to a few dollars per task depending on length. The architecture works either way; only the cost line item changes. If you're running this at scale for a team, the API-billing model probably makes more sense than the subscription model.
How is conversation memory handled across turns?
Each turn is a new database row. Follow-up turns carry the prior turn's prompt and result inside their own payload as context, then a fresh `claude` CLI invocation reads the full thread and responds. The session itself is ephemeral — only the rows are durable. This means you can resume a conversation from any device, share a thread by URL, or replay an old turn by re-submitting its payload. The conversation history is data, not process state.
