智能体如何“看见”网页与“控制”系统？Action Space 建模与操控机制全解析

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注大模型的压缩部署、多模态理解与 Agent 架构设计。 热爱“结构”与“秩序”，相信复杂系统背后总有简洁可控的可能。
我叫观熵。不是在控熵，就是在观测熵的流动
个人主页：观熵
个人邮箱：[email protected]
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从 模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理 的完整全流程
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解 从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。

---

智能体如何“看见”网页与“控制”系统？Action Space 建模与操控机制全解析

摘要：

从 OpenAI Function Calling 到 DeepSeek Tool 使用，智能体系统的工具能力日趋成熟。但真正让智能体拥有“执行力”的关键能力，不是调用接口，而是“看见界面，理解结构，并做出精准操作”**。本篇文章将围绕智能体的 Action Space 接口设计展开，系统拆解 Manus 架构中的动作感知层（Perception Layer）与动作控制层（Control Layer），并结合浏览器控制、API 控制、文件操作三类典型动作通路，设计通用的 Action Schema 协议。最终目标，是帮助你构建一个支持多端行为联动、可感知、可控制、可扩展的智能操作系统。

---

目录

1. 引言：让智能体“看见 × 控制”，是系统化落地的第一步

• 为什么函数调用还不够？
• OpenAgents 等框架的现实局限
• “动作可感知 × 行为可控”才是闭环

---

2. Action Space 是什么？从函数调用到通用行为接口的进化

• 函数 ≠ 动作，行为需要空间模型
• 动作三要素：感知（看得见）/ 意图（选得准）/ 执行（控得住）
• ActionSpace v.s. Tool v.s. API 的本质差异

---

3. 【感知层】网页、应用、API：智能体如何“看见”可交互对象？

3.1 浏览器感知：Playwright 自动元素提取 + 属性描述

3.2 桌面应用感知：UIAutomation / OCR / 组件识别（Windows/Linux/Mac）

3.3 API 感知：OpenAPI / JSON Schema 自动参数提示系统

• 最新实践：DeepSeek-Agent + LangGraph 中的上下文感知做法
• 可复用方法：结构化页面解析器 + 节点属性编码器 + 参数提取器

---

4. 【控制层】动作执行系统设计：让 Agent 控得住

4.1 网页控制：Playwright / Puppeteer 动作封装

4.2 API 控制：统一参数 → JSON 函数执行器

4.3 本地执行：Shell / Python / CLI 封装与沙箱机制

• 多通路执行封装方案（执行桥接器设计：ExecutorAdapter）

---

5. 通用动作协议设计：Action Schema + Action Plan 建模标准

• 定义：每个动作 = 动作类型 + 操作目标 + 输入参数 + 条件
• 支持嵌套执行 / 异步任务 / 条件判断

---

6. 系统对比分析：OpenAgents / AutoGPT / LangGraph / Manus 谁做得最好？

• OpenAgents（浏览器可控，但感知能力弱）
• AutoGPT（无结构化动作系统，执行依赖语言生成）
• LangGraph（结构可控但不感知 UI）
• Manus（感知 × 控制 × 状态 × Trace 全闭环）

---

7. 工程落地实战：如何一步步构建你自己的智能操作中枢？

• 3 步快速构建执行桥接层：
  1. 元素解析器（感知层）
  2. 动作执行器（控制层）
  3. 日志 + 状态更新器（Trace & State）
• 提供参考实现（Python + Playwright + FastAPI）
• 最小可复用框架模板结构

---

1. 引言：让智能体“看见 × 控制”，是系统落地的第一步

如果你正在构建一个 Agent 系统，无论是“自动写周报”、“对接网页表单”、“处理本地文件”还是“驱动 API 自动化任务”，你一定会遇到这样的问题：

• 模型能生成操作指令，但不知道点哪个按钮、填哪个输入框；
• 上文让它点击“提交”，结果点的是“取消”；
• 网页上有多个可选项，它选了一个最远的；
• 明明是让它“上传文档”，它却用的是错路径；
• 函数调用完成了，但没有写回系统状态，下一步就失控了。

这些问题并不是提示词的问题，而是系统层面缺失了感知能力与动作控制机制。

---

✅ 大模型 ≠ 智能体，执行闭环才是关键

我们常说的 GPT、Claude、DeepSeek 本质是语言模型（LLM），它们只擅长在给定上下文中进行生成，但无法主动“看见”或“操控”外部世界：

模型能力	是否具备
理解语义	✅ 很强
规划任务	✅ 可用
执行行为	❌ 仅依赖外部系统实现
感知界面结构	❌ 无法识别 DOM 或 API 字段
控制真实操作	❌ 只能输出文本，无法真正操作按钮/API/File

所以，仅靠语言模型做不到 Agent 的系统级闭环。

---

✅ 什么才是一个真正能“动起来”的智能体系统？

真正具备执行力的 Agent 系统，必须具备三层能力：

1. 看得见（Perception）：识别界面结构、表单字段、按钮属性、API 参数等；
2. 选得准（Reasoning）：在多个候选动作中做出合理选择，规划执行路径；
3. 控得住（Execution）：将计划变为真实动作，跨端执行并反馈状态。

也就是说，“看见”是前提，“操作”是路径，“回写状态”才是闭环。

---

✅ 当前主流方案为什么仍然“看不见”？

框架	感知能力	控制能力	闭环程度
OpenAI Function Calling	❌ 需要手动注册函数	✅ 调用函数本身	❌ 无状态反馈
AutoGPT	❌ 语言生成模拟操作	❌ 控制力弱	❌ 黑箱链路
LangGraph	❌ 状态流有，界面结构无感知	✅ 函数驱动强	✅ 状态支持
OpenAgents	✅ 可识别浏览器 DOM（基于 Playwright）	✅ 真实网页操作	❌ 无状态建模
Manus	✅ UI + API 感知统一建模	✅ 动作桥接器多通路封装	✅ 全状态追踪闭环

可以看出，感知能力 + 控制能力 + 状态系统三者缺一不可，而 Manus 正是在这三点上完成了系统闭环。

---

2. 什么是 Action Space？从函数调用到通用行为接口的进化

在传统的 Agent 系统中，开发者往往只关注一件事：“模型如何调用函数？”但当你开始尝试自动控制网页、填表、下载文档、上传文件、触发脚本……你会发现，仅仅注册一个函数是不够的。

你需要的是：

• 一个行为空间模型（Action Space）：Agent 能知道“我有哪些动作可以做”；
• 一个动作接口协议（Action Schema）：Agent 能理解“每个动作的结构是什么”；
• 一个执行桥接系统（Executor Adapter）：Agent 能将抽象动作投送到“真实世界”。

这就是从“函数调用”进化到“行为建模”的关键。

---

✅ 函数调用 ≠ 动作执行，真正的行为建模需要三件事：

维度	函数调用	通用动作建模（Action Space）
感知	需要人手注册函数	自动感知界面 / API / 文件结构
意图生成	模型生成 JSON 调用结构	模型生成结构化 Action Plan
控制通道	单一函数入口	多通路（网页 / API / Shell）桥接器

也就是说，传统函数调用是“控制单一动作”的封装，Action Space 是“为智能体描述一个完整可操作世界”的行为结构图。

---

✅ Action Space 的本质是什么？

是一种面向“行为决策”的空间建模方式，定义了“Agent 在某个状态下，所有可用操作的集合”。

和强化学习中的概念一致，它不只描述做什么，还包括在哪做、怎么做、能不能做。

---

✅ Action 的基本结构应包含什么？

每一个动作都应是一个结构化描述对象（通常为 JSON / Protobuf / YAML 等），包含如下字段：

字段	类型	说明
action_type	string	动作类别，如 click、fill、get、post、upload、run 等
target	object	动作作用目标，如 DOM 元素、API 路径、本地路径等
payload	object / null	传入数据，例如输入内容、上传文件
conditions	list / null	前置条件，例如 DOM 必须出现、状态为 ready 等
priority	int / optional	优先级控制，便于并发调度或打断
retry	int	失败重试次数设置
trace_id	string	用于链路追踪和日志一致性标记

---

✅ 示例：点击网页按钮的结构化动作表示

{
  "action_type": "click",
  "target": {
    "type": "button",
    "selector": "#submit-btn",
    "text": "提交"
  },
  "payload": null,
  "conditions": ["element_exists"],
  "trace_id": "trace_20250422_001"
}

这个结构比“模型生成 click(‘#submit-btn’)”更安全、可控，也更易于追踪、调试、复现。

---

✅ 为什么一定要结构化动作空间？

问题	原因	Action Space 的解决方案
模型选错操作对象	不知道有哪些按钮	显式提供候选对象列表
模型调用参数错	prompt 中没有参数说明	每个动作都有参数 Schema
执行后无法调试	无法复现上下文	每个动作结构都被日志记录
多通道调用混乱	Web 和 API 执行方式不同	每类动作绑定对应执行器（Adapter）

总结一句话：动作空间是智能体行为的“地图 +接口 +协议”。没有它，智能体再聪明也只会乱点乱填。

---

✅ 与传统 Tool / Function 的差异

类型	感知能力	多通路控制	状态写回	行为调度
OpenAI Tool Calling	❌ 无界面感知	❌ 单路调用	❌ 需手动管理	❌ 模型决定顺序
LangChain Tool	❌ 函数注册为主	部分支持	手动插入日志	✅ 可组合
AutoGPT	❌ 靠大模型推测调用方式	❌ 多数 hardcode	❌ 调用即结束	❌ 线性执行
Manus Action Space	✅ 自动感知结构	✅ 多通路控制器桥接	✅ 写入状态图谱	✅ 支持 DAG、条件与多轮计划

---

3. 感知层设计：智能体如何“看见”网页、桌面与 API 中的可交互对象？

一个真正可控的智能体系统，必须首先具备“可交互对象发现能力”——它需要知道哪里能点击、哪里能填内容、哪里能触发操作。这背后就是**感知层（Perception Layer）**的任务。

感知层的核心目标是：

将任意 UI（网页、桌面、接口）中可执行动作的“目标对象”提取为结构化可调用项（ActionCandidate），并提供上下文属性供模型参考或系统决策。

我们从三个典型场景切入：网页、桌面应用、API 接口。

---

### 3.1 网页场景：智能体如何感知网页上的“按钮 / 输入框 / 表格”？

✅ 技术路径：使用浏览器自动化引擎提取 DOM 元素 + 属性结构

推荐工具：

• Playwright（微软官方支持，Node / Python / Java 多语言）
• Puppeteer（适合前端项目 NodeJS）

✅ 操作流程：

1. 启动浏览器上下文（无头或有头）
2. 加载目标页面，等待 DOM Ready
3. 扫描所有可交互元素（如 button, input, select, a, textarea）
4. 提取以下属性：
   • tag（元素类型）
   • textContent（可视文本）
   • placeholder
   • id / class
   • aria-label
   • xpath / css selector
   • enabled / visible 状态

✅ 示例代码（Python + Playwright）：

from playwright.sync_api import sync_playwright

def extract_interactive_elements(url):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(url)
        elements = page.query_selector_all("button, input, select, textarea, a")

        structured = []
        for el in elements:
            structured.append({
                "tag": el.evaluate("e => e.tagName.toLowerCase()"),
                "text": el.inner_text(),
                "selector": el.evaluate("e => e.id || e.className || e.name || e.outerHTML.slice(0,100)"),
                "type": el.get_attribute("type"),
                "aria_label": el.get_attribute("aria-label"),
                "visible": el.is_visible(),
                "enabled": el.is_enabled()
            })

        browser.close()
        return structured

✅ 返回示例结构：

[
  {
    "tag": "button",
    "text": "提交",
    "selector": "#submitBtn",
    "type": "submit",
    "visible": true,
    "enabled": true
  },
  {
    "tag": "input",
    "placeholder": "请输入手机号",
    "type": "text",
    "selector": "#phone"
  }
]

该结构可直接供模型生成 JSON 调用计划，也可展示为 UI 按钮供用户选择。

---

### 3.2 桌面应用场景：如何感知 Windows / Mac / Linux 界面控件？

✅ 推荐技术栈：

• Windows：UIAutomation / pywinauto
• Mac：AppleScript + UI Scripting / Accessibility API
• Linux：AT-SPI（Assistive Technology Service Provider Interface）

✅ 操作流程（以 Windows 为例）：

1. 使用 pywinauto.Application().connect() 连接应用窗口
2. 遍历控件树（button / textbox / comboBox / tab）
3. 提取属性：
   • 控件类型、名称、位置、是否可操作
   • ControlID / AccessibilityName / BoundingBox
   • 支持动作列表（Invoke、Click、SendText）

✅ 示例结构：

{
  "control_type": "Edit",
  "automation_id": "username",
  "name": "用户名输入框",
  "bounding_box": [110, 220, 320, 240],
  "actions": ["set_value"],
  "is_enabled": true
}

该结构可被注册为 Action Candidate，在后续 Agent 执行层通过 pywinauto 控制该窗口对象。

---

### 3.3 API 感知场景：如何自动感知接口的调用方式与参数要求？

✅ 技术路径：解析 OpenAPI / Swagger / Postman Collection

推荐工具：

• openapi-typescript-codegen
• swagger-parser

✅ 结构化提取内容：

• API Endpoint（路径 + 方法）
• 请求参数（query / body / path）
• 每个字段的数据类型 / required / 默认值
• 接口说明（description）

✅ 示例结构（自动生成）：

{
  "endpoint": "/user/create",
  "method": "POST",
  "params": {
    "username": {
      "type": "string",
      "required": true,
      "description": "用户名称"
    },
    "email": {
      "type": "string",
      "required": false,
      "default": null
    }
  },
  "auth_required": true
}

✅ 可用于生成 ActionPlan、函数模板、甚至用作模型输入中的工具选择依据。

---

✅ 小结：感知层的统一抽象目标

无论是网页、桌面还是 API，感知层的目标都是将“可交互目标”抽象为如下结构：

{
  "object_id": "string",
  "object_type": "button/input/api",
  "display_name": "string",
  "location": "css/xpath/apiPath",
  "capabilities": ["click", "fill", "submit"],
  "constraints": ["visible", "enabled"],
  "metadata": { ... }
}

所有这些结构都将成为智能体的 Action Space 候选项，输入到模型或执行计划中，是后续 “选动作” 与 “做动作” 的基础。

---

4. 控制层设计：智能体如何操控网页、API、文件系统等行为路径？

在上一章中，我们完成了“看见”：构建了一个结构化的 Action Space，智能体已经知道有哪些按钮、输入框、接口字段可以被操作。

但下一步，系统必须回答更关键的问题：

✅ 我该怎么操作它？在哪执行？谁来调？执行完如何记录？

这就进入了**控制层（Control Layer）**的设计范畴，它是整个 Action 系统中真正驱动行为执行、落地到“现实世界”的引擎模块。

---

✅ 控制层的技术目标：

构建一个支持多通路（浏览器、接口、Shell、本地文件等）、可追踪、可插拔、可扩展的行为执行桥接器体系（Executor Adapter System），核心能力包括：

• 接收结构化 Action 请求；
• 匹配对应的执行器；
• 执行行为 → 捕获结果 / 错误；
• 回写状态 + Trace 记录。

---

我们将以三类典型控制通路展开讲解：网页控制、API控制、本地行为控制。

---

### 4.1 网页控制：Playwright / Puppeteer 动作桥接设计

网页是多数智能体“落地场景”最常见的控制目标，例如：

• 自动化网页填表
• 登录网页系统
• 点击查询、导出、上传等按钮

✅ 推荐方案：使用 Playwright 封装动作桥接器

模块职责：

• 接收结构化 Action 请求（JSON）
• 解析 action_type 与 target.selector
• 调用 Playwright 完成真实浏览器动作
• 捕捉成功状态 / 错误信息 / 页面反馈

✅ 示例代码片段：

def execute_click_action(action):
    selector = action["target"]["selector"]
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(action["context"]["url"])
        page.click(selector)
        browser.close()

✅ 可扩展为并发执行池、浏览器缓存、页面快照回传等能力

---

### 4.2 API 控制：构建通用 REST / RPC 执行器

很多任务不是点击按钮，而是调用后端接口：

• 创建用户、提交任务、触发流程
• 上传文件、获取数据、下载报告

✅ 推荐设计：抽象一个统一的 API 调用执行器

核心结构：

{
  "endpoint": "/submit/task",
  "method": "POST",
  "headers": {
    "Authorization": "Bearer xxx"
  },
  "body": {
    "title": "报告1",
    "type": "monthly"
  }
}

✅ Python 示例封装：

import requests

def execute_api_action(action):
    method = action["method"]
    url = action["endpoint"]
    headers = action.get("headers", {})
    data = action.get("body", {})

    response = requests.request(method, url, headers=headers, json=data)
    return response.status_code, response.json()

✅ 建议加入错误重试、超时控制、Token 管理、失败回写功能

---

### 4.3 本地控制：Shell / 文件系统 / Python 函数执行封装

对于部署在服务器或边缘端的智能体，很多操作是：

• 拷贝文件 / 解析文档 / 启动脚本
• 执行 Python 函数 / Bash 指令

✅ 建议设计“本地动作执行器”：

关键设计点：

• 控制安全（仅允许白名单动作）
• 支持异步调用 / 容器隔离 / 沙箱执行
• 输出写入标准日志格式（trace_id + status）

✅ 示例执行结构：

{
  "action_type": "run_script",
  "target": {
    "script_path": "/opt/agents/convert.py"
  },
  "args": ["--input", "file1.pdf", "--output", "file1.txt"],
  "timeout": 10
}

✅ Python 调用执行器（子进程方式）：

import subprocess

def run_local_action(action):
    cmd = [action["target"]["script_path"]] + action["args"]
    try:
        result = subprocess.run(cmd, capture_output=True, timeout=action["timeout"])
        return result.stdout.decode()
    except Exception as e:
        return str(e)

✅ 可加入执行环境隔离（如 Docker）、权限控制（sudo 限制）等安全扩展。

---

✅ 控制层桥接器总览图（Executor Adapter 总体架构）

+-------------------+
|  Action Dispatcher|
+--------+----------+
         ↓
+--------+----------+         +------------------+
| Action Router     |─────▶──▶| Web Executor     |
|  (Match by type)  |         | (Playwright)     |
|                  └────────▶| API Executor     |
|                  └────────▶| Shell Executor   |
|                  └────────▶| Desktop Executor |
+----------------------------+------------------+

---

✅ 控制层的关键工程建议

项	建议
模块设计	每类动作对应独立执行器，接口统一为 run(action: dict)
通道封装	使用适配器模式（ExecutorAdapter）屏蔽具体库差异
日志	每次执行必须记录：trace_id + 输入参数 + 输出状态
安全控制	控制白名单命令 / 接口权限 / 外部路径访问
状态更新	执行结果写入状态树 / memory / 调度系统

---

5. 通用动作协议封装：Action Schema + Plan 编排设计

“所有行为都应该被结构化表达。”

仅靠 prompt 输出 "点击确认按钮" 是无法驱动真实系统的。我们需要将每个动作转化为结构化、可校验、可追踪、可复用的行为协议单元，这就是 Action Schema 的使命。

进一步地，我们还需要描述多个动作之间的顺序、依赖关系与条件控制，即 Action Plan。

---

✅ 5.1 动作协议结构设计（ActionSchema）

✅ 动作的六要素：

字段	含义	说明
action_type	动作类型	click / fill / run_script / post_api 等
target	操作对象	DOM 节点 / API 路径 / 本地路径等
payload	操作内容	输入的值、参数、文件路径等
precondition	执行条件	页面加载完 / 对象存在等
retry	错误重试策略	次数、等待时间等
trace_id	日志标识符	支持行为链统一追踪

✅ 示例 Schema：

{
  "action_type": "click",
  "target": {
    "type": "button",
    "selector": "#submit-btn",
    "text": "提交"
  },
  "payload": null,
  "precondition": ["document_loaded", "element_visible"],
  "retry": 2,
  "trace_id": "trace_20250422_091"
}

---

✅ 5.2 执行计划结构设计（ActionPlan）

“单一动作靠执行器，多动作靠编排器。”

ActionPlan 是多个 Action 的组合体，支持：

• 顺序执行
• 条件判断
• 并发触发
• 依赖链路控制（类似 DAG）

✅ 核心字段设计：

字段	含义
plan_id	当前计划唯一 ID
steps	动作步骤列表（结构见下）
meta	描述、创建者、任务背景等元数据

---

✅ 单步动作结构：

{
  "step_id": "step_03",
  "action": "fill",
  "target": {
    "type": "input",
    "selector": "#username"
  },
  "payload": "zhangxin2025",
  "depends_on": ["step_01"],      // 依赖步骤
  "condition": "input_is_empty",  // 执行条件
  "retry": 1,
  "timeout": 10
}

---

✅ 完整 Action Plan 示例（多步）

{
  "plan_id": "login_sequence",
  "steps": [
    {
      "step_id": "s1",
      "action": "fill",
      "target": {"selector": "#username"},
      "payload": "admin"
    },
    {
      "step_id": "s2",
      "action": "fill",
      "target": {"selector": "#password"},
      "payload": "123456"
    },
    {
      "step_id": "s3",
      "action": "click",
      "target": {"selector": "#login"},
      "depends_on": ["s1", "s2"]
    }
  ],
  "meta": {
    "agent": "LoginBot",
    "created_by": "Manus/PlanCore"
  }
}

---

✅ 5.3 高级能力设计：并发 / 条件 / 回滚

能力	字段设计	功能说明
并发执行	group_id: 同组任务可并发	加快任务处理效率
条件执行	condition: 表达式	可基于状态、历史结果执行
错误跳转	on_fail: fallback_step_id	柔性回退
回滚机制	rollback_plan: ActionPlan	用于事务型任务撤销处理

---

✅ 5.4 建议实现方式

模块	建议实现
Schema 定义	使用 JSON Schema 进行标准化约束，支持 VSCode 联想与校验
Plan 编排器	使用类 LangGraph 的 DAG 实现，支持动态添加节点
表达式判断	内置 条件表达式解释器（如 input_is_empty && step2.success）
状态同步	每一步执行后写入状态树，供下游读取
模型接入	将 Action Space + 状态输入模型，使用 ToolPicker / FunctionCaller 接入大模型决策流程

---

✅ 统一 Action 协议的意义：

层级	意义
模型生成层	提示词更标准、输出可控、减少 hallucination
执行调度层	可追踪、可调度、可监控、可中断
工程协作层	多端 Agent 通用协议、跨模型交互、平台化
安全控制层	可插入权限控制、行为审计、异常阻断机制

---

6. 系统对比解析：OpenAgents / AutoGPT / LangGraph / Manus 谁的行为控制更强？

目前主流 Agent 系统在“动作空间”和“执行机制”上各有取向。很多框架强调 prompt 协作、工具调用、对话控制，但一旦进入“多步骤行为 + 真实系统调用 + 状态同步 + 可观测行为”阶段，差距便逐渐拉开。

我们将从五个维度对比分析：

对比维度	OpenAgents	AutoGPT	LangGraph	Manus
动作感知能力	✅ 浏览器 DOM 感知	❌ 基于模型猜测	❌ 静态计划	✅ 网页/API/UI 多通感知
动作协议结构化	部分 JSON	无结构协议	基于函数节点	✅ ActionSchema + Plan 编排
执行控制粒度	可控但难定制	线性 prompt 调用	状态流触发节点	✅ 每步动作 + 依赖链可控
执行可追踪性	日志打印	控制台输出	✅ Trace 状态流图	✅ TraceID + 全日志结构
状态写回能力	❌ 无显式状态系统	❌ 黑盒执行	✅ 节点状态流	✅ 状态树 + 快照 + 回滚机制

---

✅ 6.1 OpenAgents：感知能力最强，但缺乏结构化动作建模

优势：

• 内置 Playwright 控制器，真实网页感知与交互能力强；
• UI 上有按钮映射图，适合展示与教学场景；

局限：

• 动作计划非结构化，执行路径由 prompt 暗示生成；
• 缺乏统一计划控制结构，不支持多步骤依赖；
• 无状态追踪系统，无法恢复中断任务或跨轮复用。

适用场景：

• 演示型、低复杂度网页 Agent；
• 简单流程型任务。

---

✅ 6.2 AutoGPT：语言驱动行为模拟，控制弱、状态不可控

优势：

• LLM 计划能力与语言组织力极强；
• 自动推理、循环执行能力优秀；

局限：

• 所有行为计划基于“模型脑补”，不可靠；
• 动作执行无结构、无状态记录；
• 容易进入反复尝试、死循环、任务漂移。

适用场景：

• AI 创意类、探索性任务；
• 但不适合系统级流程执行。

---

✅ 6.3 LangGraph：有序状态流控制，缺乏界面感知与 UI 动作能力

优势：

• 支持 DAG 状态流，行为路径清晰可控；
• 每个节点有明确状态记录，可用于条件执行、容错设计；
• 良好的多 Agent 协调基础。

局限：

• 每一步动作依赖“开发者预设节点”；
• 无界面感知，无 Action 空间探索能力；
• 不适合 Agent 自主发现与动态执行路径构建。

适用场景：

• 可预测任务链的企业级流水线；
• 多 Agent 协作平台。

---

✅ 6.4 Manus：感知 × 控制 × 状态 × 行为协议“四层闭环”能力最强

优势：

• 具备完整 ActionSpace 构建能力（多通道感知 + Schema 结构）；
• 控制器桥接机制统一支持 Web / API / Shell / File 多路径执行；
• 动作结构清晰，支持多轮计划 / 条件依赖 / 并发与容错；
• 日志与状态系统融合，TraceID 全流程记录，支持回滚。

局限：

• 工程复杂度较高，需要规划状态建模体系；
• 更适合平台化 / 企业级 / 多模型编排 Agent 系统。

适用场景：

• 企业内流程型 Agent、SaaS 智能助手、操作型 LLM 应用；
• 高稳定性 + 可调试 + 多 Agent 编排系统。

---

✅ 技术选择建议

你要做的 Agent	推荐方案
演示网页交互	OpenAgents
研究型推理 Agent	AutoGPT
可配置流程任务	LangGraph
操控网页 + 控制接口 + 多步骤计划 + 回写状态	✅ Manus Action 架构体系

---

✅ 小结

Manus 的设计核心在于：

为大模型智能体补齐感知 + 控制 + 状态三大工程能力，用结构化的执行协议完成从“看得见”到“动得了”的闭环。

而这也正是从“语言智能”向“操作智能”跃迁的必经之路。

---

7. 工程实践建议：如何构建你的行为接口桥接器？

---

✅ 7.1 三步构建自己的 Action Space 控制系统

第一步：构建 元素感知器（Perception Layer）

• 任务：将网页 / 应用 / API 中的可操作对象结构化输出为 JSON
• 推荐技术：
  • 网页：Playwright / Puppeteer DOM 元素扫描器
  • API：Swagger Parser / OpenAPI Loader
  • 桌面应用：pywinauto / OCR + 控件识别
• 输出结构：
  • Object Type、Text、Selector、Actions、State（enabled/visible）、Meta

✅ 可构建 perception.extract(url) 方法：输入网页地址，输出结构化动作候选集。

---

第二步：实现 控制器桥接器（Control Executor Layer）

• 任务：根据结构化 Action JSON 调用真实执行路径（Web / API / Shell）
• 推荐模式：注册型适配器（Adapter Pattern）

# 示例注册执行器
ACTION_EXECUTORS = {
  "click": WebClickExecutor,
  "fill": WebFillExecutor,
  "post_api": ApiRequestExecutor,
  "run_script": ShellScriptExecutor
}

✅ 每个执行器类实现标准 run(action: dict) 方法，统一接口方便替换与扩展。

---

第三步：规划 计划器 + 调度器 + 状态管理器（Plan + Control + State）

• Plan 模块：生成 Action Plan JSON，支持嵌套步骤、依赖关系
• Control 模块：解析 Plan → 分发步骤 → 调用 Executor
• State 模块：执行成功后写入状态堆栈 / 快照，便于后续查询或回滚

✅ 建议使用 DAG 计划执行器（如 networkx）+ Redis 状态快照缓存 + JSON Log 存储链路

---

✅ 7.2 推荐系统目录结构

/action_runtime/
  ├── perception/              # 元素感知器（Web / API / UI）
  │    └── extractor.py
  ├── executor/                # 控制器适配器（Web / API / Shell）
  │    ├── base.py
  │    ├── web_executor.py
  │    ├── api_executor.py
  │    └── shell_executor.py
  ├── plan/                    # Plan 编排器
  │    └── planner.py
  ├── controller/              # 执行器调度器（依赖控制 + 重试逻辑）
  │    └── controller.py
  ├── state/                   # 状态堆栈与快照
  │    └── state_tracker.py
  ├── trace/                   # Trace 日志模块
  │    └── trace_logger.py
  ├── schema/                  # ActionSchema / PlanSchema 定义
  │    └── action_schema.json
  └── config.py                # 路径、日志、运行配置等

---

✅ 7.3 技术选型建议（可立即复用）

模块	推荐技术栈
网页感知	Playwright（支持 Python / Node）
API 感知	openapi-typescript-codegen, swagger-parser
Plan 编排	networkx（DAG）、jsonschema
执行器桥接	自定义 ExecutorAdapter 类体系
状态缓存	Redis + PostgreSQL 组合
日志追踪	loguru + OpenTelemetry + trace_id
安全机制	动作白名单 + 执行沙箱（subprocess / Docker）

---

✅ 7.4 最小可运行示例接口（FastAPI）

@app.post("/run_action")
async def run_action(action: dict):
    executor = ACTION_EXECUTORS.get(action["action_type"])
    if not executor:
        raise HTTPException(400, "Unknown action type")
    result = executor().run(action)
    trace_logger.log(action, result)
    return {"status": "ok", "result": result}

---

✅ 7.5 快速启动建议

步骤	建议操作
本地跑通	用 FastAPI + Playwright 写一个“智能网页点击”脚本
JSON 标准	定义好动作结构（Action Schema），后续全部基于它生成与调用
执行抽象	每种动作写一个 run() 方法，确保可控、可替换、可测试
日志回写	每次动作都写入 trace.log，追踪链路（可用于可视化）
状态存储	每轮动作写入 state.json，便于恢复与 Debug

---

✅ 总结

如果说大语言模型擅长“说”，那么 Action Space 就是让它们“动起来”的核心接口。

本篇博客完整介绍了 Manus 执行机制中的感知层、控制层、动作协议、桥接器实现与系统对比，并通过工程实战路径帮你从 0 构建可控、可执行、可复用的 Agent 操作中枢。

不论你是做网页控制、API 处理、流程机器人还是企业智能助手，只要具备以下四层：

可感知（Perception）× 可理解（Plan）× 可控（Execute）× 可复盘（Trace）

你就完成了“让智能体真正动起来”的第一步。

---

如果本文对你有帮助，欢迎三连支持！

点个赞，给我一些反馈动力
⭐ 收藏起来，方便之后复习查阅
关注我，后续还有更多实战内容持续更新

---

写系统，也写秩序；写代码，也写世界。
观熵出品，皆为实战沉淀。