【Cradle 源码解析一】架构总览与通用计算机控制 (GCC) 的实现思路

前言

在 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 必须处理三个核心问题：

1. 多模态输入处理：如何把连续的视频流转化为大模型能理解的 Prompt。

2. 决策推理：如何在没有明确 API 返回值的情况下，判断任务是否完成。

3. 动作执行：如何将"向左走"这样抽象的指令，转化为底层的键盘长按操作。

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 构建的秘密。

---