我构建的 Auto-Coder 开发平台，把来自手机和其他 Agent 的请求，与电脑上的实际工作连在一起。我搭建了服务器，也开发了电脑桌面端软件：安卓客户端 AndroidMiao 把请求发到服务器，电脑桌面端连接服务器并拉取任务，随后调用 Codex CLI 执行。执行过程和结果再经过服务器回到客户端，由客户端实时显示出来。
入口不只有安卓客户端，其他 Agent 也能走同一套流程。Grok Bot 就是另一个入口，它通过 AC Chat 命令与服务器沟通。发起请求的一端、连接两端的服务器和承担执行的电脑各有分工。
一次请求怎样到达电脑
可以用一个示意请求来理解这个过程：“检查一个项目里的问题，修改后把结果告诉我。”这里举的是任务例子，不代表下方截图记录了这次执行。
用户在 AndroidMiao 里提出请求后，客户端先把它送到服务器。电脑桌面端连接服务器，主动拉取需要执行的任务。也就是说，请求先到服务器，接着由电脑把任务取回来。
任务到达电脑后，桌面端调用 Codex CLI。Codex CLI 在电脑上做具体工作，执行时产生的过程和最终结果由桌面端送回服务器。客户端收到这些更新后，继续渲染界面，用户就能在手机上查看进展和结果。
架构示意图。五个节点对应五个角色，八段箭头展示两个入口与共用的执行链路。Grok Bot 所在的云电脑通过 AC Chat 命令对接服务器。任务由服务器流向电脑桌面端，拉取动作由桌面端主动发起。
打开可交互的 Three.js 架构图。图中可以逐步查看两个入口与后续的八段关系，也可以回到完整链路。这是用于解释架构的示意动画，不连接真实任务。
Grok Bot 也能发起请求
Grok Bot 有一台云电脑，云电脑里安装了对接我们服务端的 CLI。Grok Bot 使用 AC Chat 命令与服务器沟通，把请求送进同一套流程。安卓客户端是人从手机进入这个平台的方式，Grok Bot 则是另一个 Agent 发起请求的入口。
请求换了入口，后面的执行分工仍然一样：电脑桌面端连接服务器、拉取任务，再调用 Codex CLI 做真实工作。执行过程和结果由桌面端送回服务器，客户端依据收到的更新实时渲染。Grok Bot 负责发起请求，不会代替桌面端里的 Codex CLI。
服务器和桌面端各自做什么
服务器接收 AndroidMiao、Grok Bot 等入口发来的请求，也接收电脑桌面端返回的执行信息。它把发起任务的一端和实际工作的另一端连接起来，让客户端能够拿到后续更新。
桌面端负责把服务器上的任务带到电脑执行。它连接服务器、拉取任务、调用 Codex CLI，再把执行过程和结果送回去。把“电脑桌面端”和“Codex CLI”分开来看，分工就更清楚了：前者接起整条任务链路，后者在电脑上完成具体工作。
这种工作方式也有一个直接的前提：承担执行的电脑需要可用，桌面端需要能够连接服务器，Codex CLI 需要具备完成任务所需的工作条件。无论请求来自手机还是另一个 Agent，都要等电脑这一端实际执行，才会有工作结果。
客户端为什么能持续显示进展
返回的信息包含执行过程和最终结果。电脑端执行时把过程送回服务器，客户端依据收到的更新实时渲染。等执行结束，最终结果也沿着同一条返回路径到达客户端。
因此，用户可以从手机发起工作，再从手机查看工作进行到了哪里。界面上的进展帮助人了解执行情况，最终是否完成，仍要结合返回的结果和实际产物判断。
界面截图
下面的图片分别来自安卓模拟器和公开官网页面。它们展示产品入口与界面，与上面的架构示意图分开呈现。
真实界面截图：安卓模拟器中的 AndroidMiao，使用应用自带的演示数据，实例名称已遮盖。画面用于展示界面，不是一次真实任务的执行记录。
真实网页截图：auto-coder.chat 官网的公开介绍区域。截图裁去了顶部导航和登录状态区域。
Auto-Coder 把提出请求、在电脑上执行和查看结果接成了一条完整的工作路径。对我来说，这个平台最实在的作用，就是让手机或另一个 Agent 发出的请求能够到达电脑上的工作环境，再让工作的过程和结果回到发起请求的一端。