分层代理架构

本页解释分层代理模式背后的设计思想。想看逐行的数据流与实现细节，见分层代理深入分析。

为什么要分层

单模型（经典模式）把「想清楚要干什么」和「在屏幕上怎么点」压在同一个模型、同一轮推理里。任务一复杂——需要多轮判断、根据中间结果改计划——单模型就容易迷失：它既要做长程规划，又要盯着像素级操作，两件事互相干扰。

分层代理的思路是职责分离：

• 规划层专注「想」——拆解任务、判断进展、决定下一个子目标。
• 执行层专注「做」——只接收一个明确的原子子任务，观察屏幕并操作。

这和人类「先想好步骤，再一步步动手」的方式一致，也让每一层的模型只需擅长一件事。

两层如何协作

规划层是一个会工具调用的智能体。它能调用的工具包括：

• list_devices() —— 查看有哪些设备
• chat(device_id, message) —— 把一个原子子任务交给执行层去做

规划层每次发出一个子任务（如「打开美团」「在搜索框输入霸王茶姬」），执行层用 autoglm-phone 视觉模型在有限步数内完成它，并把结果/屏幕情况反馈回来。规划层据此决定下一步——继续、换策略、还是结束。

这个过程在界面上完全可见：你能看到规划层每一次工具调用和返回，便于理解它「为什么这么决策」并调试。

关键约束

执行层是「手」，不是「脑」，所以它不负责记忆与信息提取：它不会替你保存中间数据、不会把屏幕上的文字抽成变量。规划层若需要屏幕上的信息，必须显式提问，让执行层把内容「念」回来。这个约束是有意为之——它逼迫信息流经规划层，使决策链路清晰、可追溯。

代价与取舍

• 更强：多轮推理、动态调整、过程透明。
• 更贵更慢：两层各自调用模型，轮次更多。
• 需要决策模型：规划层建议用「会推理、上下文长」的通用大模型，需要单独配置。

因此分层代理是「实验性的增强能力」，不是默认。简单任务用经典模式更划算，复杂任务才值得分层。

实现细节、消息格式、会话存储等见分层代理深入分析。