企业官网建设流程全解析

• 文档
• 教程
• 后端

导读

本节为 MobileOpenClaw（智能体手机）场景应用打通第一条「用户 → 智能体 → 安卓设备」的完整链路：在 AI Agent Scaffold 脚手架上初步添加一个智能体配置，让智能体分析用户意图并作出决策，再通过手机网关把决策翻译成安卓端可执行的设备动作；同时提供前端操作页面，实时渲染手机当前屏幕的最新结果，让用户以可视化的方式看到手机的动作变化。读完本节，你将掌握"智能体配置 + 前端页面串联 + 网关指令下发"的最小可用闭环是如何搭建的，为后续的工作流编排、异步响应与专属手机模型接入打下基础。

本节内容位于 docs/md/project/ai-agent-scaffold/part-5/第5-4节：初步通过智能体，操作手机设备.md，属于《AI Agent 场景应用 - MobileOpenClaw》第 5 部分（业务场景）的核心一章。前序章节 第5-1节：初始化工程搭建、第5-2节：手机网关动作调度设计、第5-3节：服务端网络通信设计(Netty).md) 分别完成了工程搭建、网关动作设计与 Netty 通信底座，本节正是站在这些底座之上，让智能体真正"动起来"。

一、本章诉求

本节的目标非常聚焦，一共两件事：

1. 初步配置 AI Agent 智能体：让智能体具备分析用户意图的能力，并把意图转化为对手机设备的操作指令；
2. 串联前端操作页面：通过一个页面把"用户发起 → 智能体分析决策 → 安卓设备指令应答"的完整流程串起来，并实时渲染手机当前屏幕的最新结果，让用户能够直观看到手机的动作变化。

也就是说，本节不追求复杂的编排能力，而是先跑通"能对话、能决策、能动手机、能看结果"的最小闭环。

可扩展点：将来可以在智能体功能上对接微信公众号，通过手机端微信以文字或语音的方式，操作这台放在家中的手机设备完成一些任务的处理。这意味着整个链路天然支持"远端消息入口 → 智能体 → 手机"的扩展形态。

二、流程设计

本节整体流程设计如下（从前端用户请求到安卓设备指令应答）：

前端用户请求 ↓ 智能体意图分析和执行（轮询处理 → 拿到决策结果） ↓ 安卓设备指令应答（网关执行点击、滑动、截图等动作） ↓ 实时回传手机屏幕结果 → 前端可视化渲染

• 第一步：初步添加一个智能体配置，并提供一个页面来串联"用户发起 → 智能体分析、决策、执行 → 传递指令给安卓端"的操作流程。这里的"智能体配置"正是复用 AI Agent 脚手架 的 Armory 装配域能力——通过结构化配置定义智能体所需的模型、提示词、工具与执行方式，避免硬编码。
• 第二步：整个智能体的操作（轮询处理和拿到决策结果），本节先直接放到 trigger 层执行，后续再细化拆分到编排层（这一步对应 第5-5节：智能体工作流设计，将 trigger 中的复杂逻辑下沉到 case 编排层）。

关于"轮询处理"：智能体调用大模型进行意图分析通常不是一次请求就能得到最终动作，而是需要多轮"思考 → 调用工具（如截图）→ 观察 → 再思考"的循环。本节将这些循环直接放在 trigger 层的chat接口流程中处理，先保证功能可用。

三、智能体配置：基于脚手架的装配方式

智能体的配置依托于脚手架底座中 第2部分「基础底座开发」 所实现的装配域（Armory）能力。底座通过agent.yml之类的结构化配置，将智能体构建过程拆解为一系列节点（Node）：

• AiApiNode：配置大模型 API 端点与密钥，负责对接模型服务；
• ChatModelNode：构建具体的 ChatModel 实例（基于 Spring AI / Google ADK）；
• AgentNode：实例化智能体，绑定提示词（Instruction）；
• AgentWorkflowNode：处理工作流编排（Sequential / Parallel / Loop）；
• RunnerNode：装配 Runner 执行器，控制执行过程中的数据采集与拦截。

这些节点对应章节可参阅 第2-5节：装配域节点-AiApiNode 至 第2-10节：装配域节点-RunnerNode。在 5-4 节中，我们只需要为手机操作场景配置一个"能看懂屏幕、能决策动作"的智能体即可，把用户诉求交给智能体分析，由它决定要下发哪些设备指令。

脚手架中"通过配置文件编排即可组装复杂智能体"的机制，可以参考 ai-agent-scaffold.md 中 AI + Draw.io 场景给出的agents配置结构（name、description、instruction、output-key等字段），体会"业务需要什么能力，就组装什么节点"的配置化思想——手机操作场景的智能体配置同样遵循这一套字段规范，只是把 instruction 换成"分析屏幕截图、输出设备动作指令"的提示词。

四、trigger 层：智能体操作流程的直接落地

根据本节的设计，智能体的操作流程（轮询处理和拿到决策结果）目前先直接放到 trigger 里执行。这是 DDD 分层架构中的一个有意为之的"先跑通、后重构"决策：

• trigger 层：暴露 HTTP 接口（后续演进为AgentServiceController#chat），接收前端页面发来的用户消息；
• 流程内容：把用户消息送入智能体 → 智能体轮询调用模型进行分析决策 → 拿到决策结果后，把动作指令通过 Socket 服务下发到手机端；
• 回传渲染：手机端执行动作后回传屏幕截图/结果，前端页面据此实时渲染手机当前屏幕。

之所以先在 trigger 中直接写，是为了以最小的代码量验证"意图分析 + 指令下发 + 屏幕回传"整条链路是否通畅。正如 第5-5节 所述，随着逻辑变复杂，会把 trigger 内实现的流程迁移到 case 编排层，按照功能职责拆分出不同的类，让"以后看到类就能知道它在做什么"，保持复杂业务迭代中的可扩展性与可维护性。

五、网关通信底座：智能体指令如何到达手机

智能体拿到决策结果后，指令需要经由通信网关下达到安卓端。这部分底座由前序章节完成，理解它有助于看懂 5-4 节的整条链路：

• 第5-2节：手机网关动作调度设计：安卓手机端作为网关终端，通过 AccessibilityService（无障碍服务）接收指令并完成一系列动作，包括**启动应用、点击指定坐标、输入文本、滑动屏幕、长按、双击、请求人工接管（登录/验证码）**等。手机端成为"指令执行器"，具体操作全部由服务端控制，这样后续 AI 才能按需操作手机。
• 第5-3节：服务端网络通信设计(Netty).md)：服务端引入 Netty 搭建 Socket Server 通信模型，在领域层提供MobileClawService服务，基础设施层完成收发处理，并采用Future 等待响应的方式获取客户端（手机）反馈结果——解决"Netty 是异步通信，而业务层需要同步结果"的矛盾。

结合 notes.md 中的面试归档，通信协议的具体形态可以归纳为：

• 粘包/拆包：使用 Netty 自带的LineBasedFrameDecoder，以换行符\n作为消息结束标志，发送端在 JSON 数据后追加换行符，接收端据此切分完整消息帧；
• 协议格式：JSON 文本协议，例如请求{"type": "action", "command": "click", "x": 100, "y": 200}\n，响应{"type": "response", "status": "success", "data": "..."}\n；
• 异步转同步：发送指令前创建CompletableFuture并存入线程安全的ConcurrentHashMap（Key 为请求 ID），业务线程future.get(timeout)阻塞等待；NettychannelRead收到响应后按 ID 取出 future 并complete(response)唤醒线程，超时则移除防止内存泄漏。

从源码结构看，服务端与安卓端的通信采用"长连接 + 指令/响应"模型：智能体每决策出一个动作（如"点击坐标 (100, 200)"），服务端就通过这条 Socket 连接下发指令，并在同一会话中等待手机端返回执行结果与最新截图，从而支撑后续多轮"看屏 → 决策 → 动作"的迭代。

六、前端页面：实时渲染手机屏幕

为了让用户"看得见"智能体对手机的操作，本节还提供了一个前端操作页面，承担两个职责：

1. 发起请求：用户通过页面输入诉求（例如"打开抖音""帮我点击屏幕中间"），请求进入 trigger 层的智能体接口；
2. 实时渲染：页面实时渲染手机当前屏幕的最新结果——智能体每执行一步动作，手机端回传的屏幕内容都会同步呈现在页面上，用户能看到手机的动作变化过程，而不是只拿到一句"操作完成"的最终回复。

这一"过程可见"的诉求，在后续 第5-6节：智能体异步响应展示执行过程 中进一步升级：把Response<ChatResponseDTO>调整为 Spring 的ResponseBodyEmitter，让服务端在一个 HTTP 请求生命周期内异步、多次地向客户端推送当前执行动作，实现真正的实时过程渲染。

七、场景串联效果与后续演进

完成本节后，MobileOpenClaw 的整体效果是：

• 用户在前端页面输入一句自然语言诉求；
• 智能体分析用户意图，进行多轮轮询决策（看屏幕 → 决定动作）；
• 决策结果经 Netty Socket 网关下发到安卓手机端；
• 手机端执行启动应用、点击、滑动、截图等动作，并回传屏幕结果；
• 前端页面实时渲染手机屏幕，用户可视化地看到手机被"隔空操作"。

后续章节则沿着"从可用到好用"的路径持续演进：

同时，章节开头提到的可扩展点——对接微信公众号，让用户通过手机端微信以文字或语音操作家中设备——正是这套"消息入口 + 智能体 + 手机网关"架构的自然延伸。

小结

本节用最直接的方式把 MobileOpenClaw 的第一条闭环跑通：配置一个智能体 → 页面发起请求 → trigger 层轮询决策 → Netty 网关下发指令 → 手机执行动作并回传屏幕 → 前端可视化渲染。它验证了 AI 操作物理设备的核心可行性，也明确划出了"先实现、后重构"的演进路径。理解本节，你就掌握了把"大模型意图分析"与"真实设备控制"焊接在一起的关键一步。

相关阅读：

• 第5-1节：初始化工程搭建 —— 服务端与安卓网关工程的创建与开发环境
• 第5-2节：手机网关动作调度设计 —— 手机端可执行动作清单与调度模型
• 第5-3节：服务端网络通信设计(Netty).md) —— Netty Socket 通信与 Future 等待响应
• 面试：技能、简历、问题汇总 —— 网关通信协议、异步转同步等高频面试点的参考答案

• 文档
• 教程
• 后端