1 引言
最近在调研AWS Bedrock AgentCore，其中有一个子模块是Browser：可以让Agent自主访问浏览器。在和我的MS Copilot讨论为什么要将Browser单独拆分出来，什么应用模块需要拆分出来时，它给了我一个非常精辟的结论。可以说这是至今为止，我认为Copilot"思考"最有深度的一次回答。
2 什么是AgentCore？
AWS Bedrock AgentCore是一个企业级Agent服务，用于构建、部署和运维Agent应用。此前对于Agent的印象是可以通过大量Web搜索进行深度研究，或者是如OpenClaw一样自由操作浏览器完成一系列操作。那么，让Agent直接访问浏览器就可以了，为什么还需要独立的Browser呢？AWS的设计理念是将Browser作为一等基础设施，置于隔离环境中来支持大规模并发访问运行。它提供了以下几个关键能力
- 录屏审计
- 会话(session)隔离
- 人可以随时通过Live View介入
- 错误隔离(Browser崩了，Agent还活着)
当然还解决一个问题是Browser本身过于重量级，而并不是所有Agent都需要Browser（甚至大部分不需要？）
更完整的架构如下图
AgentCore Runtime
Serverless架构，支持任意Agent框架任意LLM。负责运行主Agent（或者可能的SubAgent)，起到整体调度编排作用，支持最长8小时运行。重量级操作都应该不运行在这个Runtime里面。对应了Copilot的经典总结
规则① 凡是"为人类交互设计的应用"，都不应该和Agent同进程运行
AgentCore Browser
可以理解为隔离环境中的Chrome浏览器runtime。Agent访问浏览器来进行页面浏览、点击、滚动、填写表单等操作。有点类似UiPath RPA，只是Agent可以更智能的感知页面变化，传统的RPA面对页面改版一般就挂了。
AgentCore Interpreter
Sandbox环境，运行Agent生成的"不可信代码"，处理繁重复杂逻辑。Agent自动生成的代码可能意外或由于被攻击而造成破坏性影响，它绝不能直接运行在AgentCore runtime中，而Sandbox的特性可以最大程度规避此类风险。
AgentCore Gateway
独立托管的MCP Server runtime，连接Agent和所有外部工具/数据源。（MCP Server也不用自己搭了）
它提供以下几点关键能力
-
集中的二次身份认证（AgentCore runtime是第一次）
-
REST API(OpenAPI协议)或Lambda自动转MCP协议
-
语义搜索发现外部工具
除此之外AgentCore还集成了Memory、Observability、Policy等能力完成了整个Agent开发生态的闭环。尤其是Memory的设计我认为极具参考价值，由于与本文主题无关就不再赘述。
3 Bedrock vs OpenClaw
Bedrock AgentCore 的架构设计是令人印象深刻的。它成功铺平了一条进阶之路：将原本运行在本地 PC 上的"玩具"Agent，转化为了能够在企业环境中安全、合规且高效落地的生产级应用。
我们常把Agent比作AI员工，那么在AWS的设计中充分考虑到了人与Agent的核心差异
人控制PC的特点
- 人是唯一调度者
- 同一时刻只做一两件事
- 出错可以靠感知、经验、直觉兜底
- 安全与合规依赖"人负责"
Agent 的特点
-
并发执行
-
自动化
-
出错不易察觉，可能自我修复也可能崩溃
-
必须可审计、可回放、可终止
最近全网爆火的OpenClaw和让硅谷SaaS暴跌3000亿美元的Cowork，都是另一种设计哲学下的Agent。
它们通常工作在本地PC，OpenClaw更激进的是Agent在其中具备一切权限，Agent=用户本身，可以运行本地一切的应用程序，默认情况没有拆分，没有限制。
我觉得它能够爆火的一个原因是，这符合人们想要的Agent的样子。但通过Bedrock的对比不难看出，它不适用于企业级Agent开发。它缺少安全边界，没有执行隔离，甚至不需要Human-in-the-loop。可以说它在追求的是个人Agent的极限形态。
插一个题外话是，2018年我在某服务器上做过一个用微信进行ETL运维的玩具。在服务器上登录个人微信，然后手机端发送消息，就可以触发服务器运行命令。(下图中[Server]开头的对话是服务器返回的消息)。这个东西回头来看，和OpenClaw想要做的事有点类似，只是当时没有LLM，完全基于rule-based执行。(微信后来应该早已经封禁了这种开发方式)
再来谈到SaaS的暴跌，有个极端的观点是Agent未来直接对接底层Database，中间一切都被压缩，最终归0。（确实有点过于激进）
SaaS提供的复杂UI不再具备任何优势，我们要完成任务，Agent帮你执行，中间根本不需要UI，UI是给人看的，在Agent的世界里反而是累赘，不再有价值。
这就callback了引言中Copilot给出的
规则② 凡是"为程序访问设计的系统"，应该优先用 API/Tool，而不是UI自动化
所谓的UI自动化，只不过是高级版RPA，它将是一个过渡阶段。未来造Agent的需求越来越多，对UI的需求越来越少。那自然地，Browser需不需要拆分可能不再是问题，因为Agent就根本不需要Browser。
4 总结
2026年毫无疑问的是全球会有大量AI Agent在企业落地。我们不仅是拿着现在人们用的软件样子来造Agent，长远来看Agent本身更将颠覆整个软件业界的形态。我们距离如AWS这样的头部玩家，仍有不少差距，还需不断追赶。从架构层面思考欠缺的是什么？这不是"最后一公里"的事了。