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

个人简介

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

专栏导航

观熵系列专栏导航：
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
执行后无法调试	无