Browser + Memory + Subagent + Sandbox 正在成为 Agent 的标准基础设施

北京时间 2026 年 9 月 19 日 16:18:42 正式发布了 Qwen Code v0.24.1。
官方 Release:
摘要
Qwen Code v0.24.1 正式版将一组关键 Agent Runtime 能力集中到同一版本:基于 Playwright 的 Browser SDK、Chrome Native Messaging relay、子 Agent 显式工具 Allowlist、子 Agent 容器执行、可配置 Mem0 外部记忆 Provider,以及根据实际工具集合动态组装 System Prompt。
这次更新的意义并不在于发布了一个新的 Qwen 基础模型,而在于 Qwen Code 正在从传统的 "LLM + Shell" Coding Agent,逐步演化为一个包含 浏览器、长期记忆、多 Agent、权限控制和隔离执行 的完整 Agent Runtime。
更值得注意的是,Qwen 同时在做两件必须同步推进的事情:
一边扩大 Agent 能力边界,一边收紧 Agent 权限边界。
1. 本次更新的要点
如果从 Agent 架构角度看,v0.24.1 最值得关注的是以下几项:
| 能力 | v0.24.1 的变化 | 对 Agent 的意义 |
|---|---|---|
| Browser Use | 新增 Playwright Browser SDK | Agent 可以操作真实浏览器 |
| Chrome Relay | 新增 Native Messaging relay | 可以连接用户已有 Chrome 会话 |
| Subagent Permission | 支持显式 Tool Allowlist | 对不同子 Agent 实施最小权限 |
| Subagent Sandbox | 增加 Container Execution | 将子 Agent 执行环境隔离 |
| External Memory | 支持可配置 Mem0 Provider | 引入跨任务/跨会话外部记忆 |
| Dynamic Prompt | 根据 Resident Tool Set 组装 System Prompt | Prompt 与实际工具能力保持一致 |
一句话概括:
text
Qwen Code
LLM
+
Browser
+
Memory
+
Subagents
+
Sandbox
+
Tool Permission
也就是说,本次的更新表明,Qwen 正在构建一个:
一个完整的 Agent Runtime。
2. Browser SDK:Agent 开始真正操作用户浏览器
此次 v0.24.1 正式加入:
Playwright-based Browser SDK
其底层采用 Playwright,并通过自定义 Chrome DevTools Protocol(CDP)适配与本地通信层连接 Chrome。
官方 PR 中明确说明,Browser SDK 可以支持:
text
Tab Management
Navigation
Input
Screenshot
Dialog
Download
其架构大致如下:
text
Qwen Agent
↓
Browser SDK
↓
Playwright
↓
CDP Adapter
↓
Native Messaging
↓
Chrome Relay
↓
Existing Chrome Session
其中最值得关注的一点是:
它的设计目标不是启动一个完全独立的新浏览器,而是操作用户已有的 Chrome 标签页和登录状态。
因此 Agent 理论上可以利用:
text
Existing Tabs
Existing Login State
Existing Browser Context
完成真实 Web 任务。
3. Browser Use 对模型的重要性
传统 Browser Agent 通常运行在:
text
Fresh Browser
或者:
text
Isolated Browser
中。
这意味着很多真实任务无法直接完成,例如:
text
登录 GitHub
登录企业后台
访问内部 Dashboard
操作个人账号
修改云平台设置
而 Qwen Browser Use 的目标更接近:
text
User's Existing Chrome
↓
Existing Authentication
↓
Agent Browser Operation
这会显著增强 Agent 的真实任务执行能力。
但与此同时:
浏览器状态本身就是权限状态。
当 Agent 能够使用用户已有登录状态时,权限、安全与身份边界就会变得更加重要。
4. Browser Use 并不是一个 PR 就完成的
Qwen 官方将 Browser Use 分成三个阶段:
| 阶段 | 内容 | 作用 |
|---|---|---|
| PR1 | Browser SDK | 提供面向模型的浏览器 API |
| PR2 | Chrome Connection | Native Messaging + Chrome Relay |
| PR3 | Product Integration | 集成进 Qwen Code CLI |
流程可以表示为:
text
PR1
Browser SDK
↓
PR2
Chrome Connection
↓
PR3
Qwen Code Integration
↓
Complete Browser Use Stack
5. 子 Agent Tool Allowlist:能力越强,权限越需要收紧
另一个值得关注的更新是:
agent() 可以为每个子 Agent 指定显式工具 Allowlist。
过去一个子 Agent 可能继承大量工具:
text
read_file
write_file
shell
browser
MCP
network
database
...
但某个任务可能只需要:
text
read_file
run_shell_command
v0.24.1 可以将子 Agent 限制在明确的工具集合内。
6. 这不是 Prompt 约束,而是 Runtime 约束
传统方法可能只是在 Prompt 中告诉 Agent:
text
You must not use browser.
You must not access database.
本质上属于:
text
Prompt-level Permission
而 Qwen 的 Tool Allowlist 属于:
text
Runtime-level Permission
官方实现说明:
不在 Allowlist 中的工具不会声明给子 Agent。
如果 Agent 尝试调用未声明工具:
text
Tool not found
并且工具不会被执行。
因此安全边界从:
text
"模型最好不要调用"
变成:
text
"Runtime 根本不给它这个能力"
7. Principle of Least Privilege:最小权限原则
这实际上对应经典计算机安全原则:
Principle of Least Privilege(最小权限原则)
也就是:
一个程序只应该拥有完成当前任务所需要的最小权限。
放到 Multi-Agent 中,可以是:
text
Planner Agent
↓
Planning Tools Only
Code Agent
↓
Read / Write / Test
Research Agent
↓
Browser / Search
Database Agent
↓
Read-only SQL
而不是:
text
Every Agent
↓
Every Tool
8. Container Execution:把子 Agent 放进隔离环境
v0.24.1 还增加:
Container Execution for Subagents
其目标是让部分子 Agent 不直接运行在 Host 环境,而是在:
text
Docker / Podman Container
中执行。
简化架构:
text
Main Agent
↓
Subagent Manager
↓
Execution Backend
↓
Container
↓
Worker
↓
Tool Execution
这样可以限制:
text
Filesystem Access
Network Access
Environment Variables
Credentials
Process Capability
9. Tool Allowlist + Container 是两层不同安全机制
| 机制 | 控制的是什么 |
|---|---|
| Tool Allowlist | Agent 能调用什么工具 |
| Container Execution | 工具在什么环境里执行 |
例如:
text
Subagent
↓
Allowlist
↓
shell
↓
Container
↓
Restricted Filesystem
No Network
Limited Credentials
完整结构可以理解为:
text
Parent Agent
│
▼
Subagent
│
┌────────┴────────┐
▼ ▼
Tool Allowlist Container
│ │
What can it do? Where can it do it?
│ │
└────────┬────────┘
▼
Controlled Action
也就是:
Capability Control + Environment Isolation
10. Mem0:Agent 开始接入外部长期记忆
v0.24.1 还加入:
Configurable Mem0 Providers
Qwen Code 可以通过 External Context 接口接入:
text
Mem0 Platform
Self-hosted Mem0
Aliyun PolarDB Mem0
模型侧主要暴露:
text
context_search()
用于记忆检索。
在显式允许写入时,还可以使用:
text
context_remember()
用于长期记忆写入。
基本流程:
text
Current Task
↓
context_search()
↓
External Memory
↓
Relevant Context
↓
Agent Reasoning
以及:
text
Agent Result
↓
context_remember()
↓
Persistent Memory
↓
Future Task
11. 与普通 Context Window 的区别
普通 Context:
text
Conversation
↓
Context Window
↓
Session Ends
↓
Context Disappears
External Memory:
text
Conversation
↓
Memory Write
↓
External Memory Store
↓
Session Ends
↓
Memory Persists
↓
Future Session
↓
Memory Retrieval
所以:
text
Long Context
≠
Long-term Memory
12. 与 Grok Build Memory 的区别
| 维度 | Qwen Code + Mem0 | Grok Build |
|---|---|---|
| Memory Backend | External Provider | Markdown Topic Files |
| 主要形式 | API / External Context | 项目主题文件 |
| 可替换性 | 高,可切换 Provider | 更偏内置体系 |
| 可读性 | 取决于 Provider | 高 |
| Project Scope | 可以配置 Scope | 原生强调 Project / Global |
| 适用场景 | Agent Runtime 通用记忆 | Coding Project Memory |
可以简单理解为:
text
Grok
=
Memory as Documents
而 Qwen Code 更接近:
text
Memory as External Service
13. Dynamic System Prompt:Prompt 与 Runtime 同步
此次还有一个重要更新:
根据 Resident Tool Set 动态组装 System Prompt。
传统 Agent 可能拥有固定 System Prompt:
text
You can use:
- shell
- browser
- file
- ...
但如果实际 Runtime 中:
text
Browser Disabled
MCP Unavailable
Shell Restricted
Prompt 仍然描述这些能力,就会出现:
text
Prompt / Runtime Mismatch
Qwen Code 开始让:
text
System Prompt
↓
Derived from
↓
Actual Resident Tool Set
从而减少:
text
调用不存在工具
错误规划
能力幻觉
14. Qwen Code 正在从 Coding Agent 开始转变
传统 Coding Agent:
text
LLM
+
Shell
+
File Editor
而 v0.24.1 之后更接近:
text
Qwen Model
│
▼
Agent Runtime
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Browser Memory Subagents
│ │ │
▼ ▼ ▼
Playwright Mem0 Tool Allowlist
│
▼
Container
也就是:
Agent Orchestration Runtime
15. 完整 Agent Stack 正在路上
text
┌───────────────────────────────┐
│ L6 --- User / Application │
├───────────────────────────────┤
│ L5 --- Agent / Subagent │
├───────────────────────────────┤
│ L4 --- Memory / Context │
├───────────────────────────────┤
│ L3 --- Tools / Browser / MCP │
├───────────────────────────────┤
│ L2 --- Permissions / Sandbox │
├───────────────────────────────┤
│ L1 --- Model │
└───────────────────────────────┘
此次 v0.24.1 主要强化的是:
text
L2 Permissions / Sandbox
L3 Browser / Tools
L4 Memory
L5 Subagents
它更像是:
Agent System Engineering
而不是:
Foundation Model Scaling
16. 为什么"能力扩展"和"权限收缩"必须同时进行?
Qwen 一边加入:
text
Browser
Memory
Subagents
External Context
另一边同时加入:
text
Tool Allowlist
Container Execution
Dynamic Tool-aware Prompt
可以表示成:
text
Agent Capability ↑
│
│ requires
▼
Agent Control ↑
如果只有能力增长,没有控制能力同步增长,风险也会随之扩大。
可以粗略表示为:
A g e n t R i s k ∝ C a p a b i l i t y × A c c e s s × A u t o n o m y I s o l a t i o n × P e r m i s s i o n C o n t r o l Agent\ Risk \propto \frac{ Capability \times Access \times Autonomy }{ Isolation \times Permission\ Control } Agent Risk∝Isolation×Permission ControlCapability×Access×Autonomy
这不是严格数学模型,但能很好描述 Agent Runtime 的设计方向。
总结
Qwen Code v0.24.1 并不是一次基础模型升级。
它真正值得关注的地方,是 Qwen Code 的技术重心正在从:
text
LLM + Shell
逐渐演化到:
text
Browser
+
Memory
+
Subagents
+
Tool Permissions
+
Container Sandbox
+
Dynamic Runtime
也就是一个越来越完整的:
Agent Runtime。
其中最重要的趋势是:
Agent 能力正在快速扩张,但与此同时,权限系统和执行隔离也必须同步升级。
未来 Coding Agent 的竞争,可能不再只是:
text
谁的模型写代码更强?
而会进一步变成:
text
谁能构建一个
能力更强
记忆更长
工具更多
同时又更安全可控
的 Agent Runtime?
这可能是 Coding Agent 从"模型产品"迈向"智能体操作系统"的关键一步。
参考资料
-
Qwen Code v0.24.1 官方 Release
-
Browser SDK PR #11241
-
Subagent Tool Allowlist PR #12051
-
Configurable Mem0 Provider PR #9952
-
Container Execution for Subagents PR #11711