前言
在 AI Agent 爆发的今天,让大模型“聊天”已不再稀奇,真正的圣杯在于让 AI 像人一样“操作”。北京智源人工智能研究院(BAAI)推出的 Cradle 框架,正是向 通用计算机控制(General Computer Control, GCC) 迈出的重要一步。它不仅能玩《荒野大镖客2》,还能操作各种软件。
本系列博文将剥开 Cradle 的外壳,深入源码层面,分析它是如何“看”、如何“想”、如何“动”的。作为系列的第一篇,我们将从上帝视角审视 Cradle 的架构设计、目录结构以及 Agent 核心的生命周期。
1. 什么是 GCC?Cradle 的核心理念
在深入代码之前,我们需要先对齐概念。通用计算机控制 (GCC) 不同于传统的脚本自动化(如 Selenium 或按键精灵):
-
传统自动化:基于 DOM 树、API 或固定的坐标脚本,脆弱且不通用。
-
GCC (Cradle):Visually Grounded(视觉为基)。它像人类一样,通过看屏幕(截图)来获取信息,通过模拟键盘鼠标(HID)来输出动作。
Cradle 的核心目标是构建一个通用的 Agent,它不依赖游戏或软件的内部接口,而是完全依赖视觉反馈和通用输入输出。
在源码层面,这意味着 Cradle 必须处理三个核心问题:
-
多模态输入处理:如何把连续的视频流转化为大模型能理解的 Prompt。
-
决策推理:如何在没有明确 API 返回值的情况下,判断任务是否完成。
-
动作执行:如何将“向左走”这样抽象的指令,转化为底层的键盘长按操作。
2. 庖丁解牛:项目目录结构分析
Clone 下 Cradle 的仓库后,面对复杂的目录,我们需要关注以下核心模块。以下是精简后的目录树及其功能解读:
Plaintext
Cradle/
├── conf/ # 配置文件 (基于 Hydra)
│ ├── config.yaml # 总入口,定义了使用哪个 LLM,哪个 Game 环境
│ └── env/ # 不同环境的配置 (如 rdr2, software 等)
├── cradle/ # 【核心源码目录】
│ ├── agent/ # Agent 的大脑
│ │ ├── agent.py # Agent 基类,定义了核心 Loop
│ │ └── lmm/ # 大模型接口层 (OpenAI, Gemini 等)
│ ├── environment/ # 环境交互层
│ │ ├── cap/ # 屏幕捕获 (Capture)
│ │ └── input/ # 键鼠控制 (Input)
│ ├── memory/ # 记忆模块 (向量数据库、短时记忆)
│ ├── provider/ # 第三方服务封装 (OCR, Object Detection)
│ └── utils/ # 工具库 (图像处理, JSON 解析)
├── res/ # 资源文件 (图标模板、参考图像)
├── runner.py # 程序启动入口
└── requirements.txt # 依赖包
源码阅读建议:
初学者应从 runner.py 入手,追踪配置加载流程,然后直接跳到 cradle/agent/agent.py,这是整个系统的“心脏”。
3. 核心生命周期:Agent 的 Main Loop
Cradle 的运行机制并不是黑魔法,本质上是一个无限循环的 感知-决策-执行 (Perception-Decision-Action) 闭环。
在 cradle/agent/agent.py 中(代码逻辑简化版),我们可以看到这个核心 Loop:
Python
# 伪代码示意
class Agent:
def run(self):
while not self.task_completed:
# 1. 观察 (Observation)
screenshot = self.environment.capture()
# 2. 信息处理 (Information Gathering)
# OCR 识别文字,CV 模型识别图标,组装成 context
info = self.provider.process(screenshot)
# 3. 推理 (Reasoning)
# 将历史操作、当前截图信息喂给 GPT-4V
plan, action = self.lmm.chat(history, info)
# 4. 执行 (Execution)
self.environment.execute(action)
# 5. 反思与记忆 (Reflection & Memory)
result = self.check_success()
self.memory.add(action, result)
这个 Loop 揭示了 Cradle 源码实现的四个关键步骤:
3.1 观察 (Observation)
Agent 首先调用 environment 模块截取当前屏幕。这不仅仅是截图,还包括了对图像的预处理(如 Resize、Grayscale 等),以便后续处理。
3.2 信息增强 (Information Augmentation)
单纯把截图扔给 GPT-4V 往往不够精确(尤其在识别细小 UI 坐标时)。Cradle 引入了 provider 层,利用传统的 CV 技术(如 PaddleOCR, SAM, GroundingDINO)提取屏幕上的文字和物体坐标,将这些结构化数据作为辅助信息(Prompt 的一部分)喂给大模型。
3.3 决策 (Decision Making)
这是 LLM 发挥作用的地方。源码中会有大量的 Prompt Engineering,引导模型进行“思考链(CoT)”推理。模型不仅输出要按哪个键,还要输出“为什么这么做”,这对于 Debug 非常重要。
3.4 执行 (Action)
Cradle 将大模型输出的高级指令(如 click(mailbox))映射为底层的 pyautogui 或 ctypes 调用。
4. 总结与下篇预告
通过对架构的初步拆解,我们发现 Cradle 实际上是一个精心设计的胶水层:它将传统的计算机视觉技术(眼睛)、强大的多模态大模型(大脑)和底层操作系统接口(手脚)粘合在了一起。
它的强大之处不在于单一模块的复杂度,而在于这套 GCC Loop 的鲁棒性设计。
下一篇预告:
Agent 是如何“看懂”屏幕上密密麻麻的图标和文字的?在下一篇 【Cradle 源码解析二】由眼入心:LMM 如何“看懂”屏幕与 UI 识别机制 中,我们将深入 provider 和 environment 目录,揭秘 Cradle 的视觉处理管线与 Prompt 构建的秘密。

307

被折叠的 条评论
为什么被折叠?



