从AI助手到工作现场:AURA OS的进化之路

过去两天，我一直在做一件看起来很工程、实际上非常影响产品方向的事情：把AURA OS的MCP Skill真正接到浏览器当前工作场景里。一开始，我以为这只是一个普通的功能开发：MCP接进来→Skill安装→根据URL判断→显示对应Skill。但真正把Tauri、Chrome Extension、WebSocket、ScenePanel和MCP Registry一层层串起来以后，我突然发现，这件事情的意义远远不只是“接入MCP”。它让我重新看清楚了AURA到底应该是什么。它可能根本不是一个传统意义上的AI软件，也不是一个让用户打开网页、输入问题、等待答案的Chatbot，甚至也不应该只是一个“企业AI工作台”。我越来越确定：AURA真正应该成为一个安装在用户电脑上的、持续存在于工作现场的Ambient AI Runtime。它不需要用户每次主动召唤。它应该知道用户正在什么环境里工作，知道当前是什么业务场景，知道这个场景下有哪些能力可以使用，并且在真正需要的时候，把合适的Agent和Skill放到用户面前。

过去做AURA的时候，我其实想得非常大。企业AI、World Model、Reality Model、Temporal Event Graph、Semantic Cloud、Causal Reasoning……这些东西从架构角度都很有吸引力。我也曾经把AURA描述成一个企业级智能资产和全域智能决策系统。但随着真正开始做产品，我越来越意识到：用户并不关心你的World Model有多复杂。一个老板真正关心的是：我今天正在处理这个客户，你能不能直接帮我把相关的信息、工具和动作准备好？一个跨境卖家真正关心的是：我现在就在Amazon商品页，你能不能直接告诉我这个页面上有什么事情值得做？一个运营人员真正关心的是：我正在处理这批订单，为什么还要自己打开五个系统找资料？一个销售真正关心的是：我刚刚跟客户聊完，你能不能自动知道接下来该干什么？这让我意识到一个非常重要的问题：AI的价值不一定发生在“用户打开AI”的那一刻。更大的机会可能是：AI直接进入用户工作的现场。

以前的软件逻辑是：打开软件→进入首页→寻找功能→选择Agent→输入任务→AI执行。这实际上还是传统软件。只不过按钮换成了Agent。而我现在更希望AURA是：用户正常工作→AURA在后台运行→感知当前工作现场→理解当前上下文→发现相关能力→主动出现→执行任务。这就是Ambient AI。不是把用户从工作现场拉走。而是：AI进入工作现场。这也是为什么我现在越来越重视AURA的桌面端。

过去我把Chrome Extension看得比较重。因为浏览器是一个非常丰富的信息入口。用户打开Amazon、微博、小红书、Shopify、Bilibili……浏览器天然知道用户正在看什么。但是浏览器有一个天然的边界：它只能看到浏览器。而真正的企业工作并不只发生在浏览器。用户还会使用：Excel、Word、PowerPoint、PDF、Outlook、微信、企业微信、ERP、CRM、本地文件、各种Windows软件。所以如果AURA最终只是一个Chrome Extension，它仍然只是一个“浏览器AI”。这不是我最终想要的形态。于是，AURA的架构开始发生一个非常重要的变化：Chrome Extension负责感知浏览器。Tauri Desktop负责成为整个系统的本地控制中枢。这也是我现在越来越明确的一点：Tauri Desktop Agent才是AURA的最终形态，Chrome Extension更像是AURA进入浏览器世界的一个Adapter。

这两天，我花了不少时间追踪一个非常基础的问题：Chrome到底是怎么告诉Tauri：“用户现在正在干什么”的？之前从Rust代码看，会看到：on_message()然后看到：on_context()很容易产生疑问：context到底是谁发过来的？真正把Chrome端代码翻出来之后，答案终于非常清楚。核心文件是：src/sceneReporter.js它连接的是：ws://127.0.0.1:47821而Tauri Rust端监听的也是：127.0.0.1:47821于是，两边之间形成了一条真正的本地通信总线：Chrome Extension ↕WebSocket ↕AURA Tauri Desktop不是云端。不是HTTP API。而是用户电脑内部的本地WebSocket。

答案其实非常简单。Chrome Extension监听浏览器Tab。当用户：切换Tab、URL发生变化、页面加载完成就会触发：report(tab)然后AURA做三件事情。第一步：detectPlatform(tab.url)判断用户在哪个平台。例如：Amazon、Weibo、Xiaohongshu、Bilibili、Shopify、Twitter/X、TikTok第二步：detectScene(platform, tab.url)判断用户正在做什么。例如：product、search、dashboard、seller、default第三步：getSceneCard(platform, scene)获取这个场景对应的界面描述和能力。最后，Chrome发给Tauri：{

"type": "context",

"platform": "amazon",

"scene": "product",

"tabId": 123,

"card": {}

}注意一个非常重要的设计：完整URL、页面标题、页面正文、DOM内容，并没有通过这条context通道直接发送给Tauri。发送的是：平台、场景、Tab、场景描述也就是说：Chrome知道现场，但它只把必要的语义现场告诉AURA。

Chrome发出：ws.send(JSON.stringify({

type: 'context',

platform,

scene,

tabId,

card

}));Tauri收到以后：Rust ws.read()拿到消息。然后：on_message()负责判断：type == context于是进入：on_context()所以整个链路实际上是：Chrome ↓ report() ↓ WebSocket ↓ Rust ws.read() ↓ on_message() ↓ on_context() ↓ AURA当前Scene ↓ ScenePanel这件事情看起来简单，但我认为它是AURA最重要的基础设施之一。因为它意味着：AURA已经不是等待用户输入的AI。它已经开始拥有“当前工作现场”这个概念。

更有意思的是，这个WebSocket并不只是Chrome→Tauri。它是双向的。例如用户在AURA的ScenePanel里点击：抓取商品Tauri可以发送：{

"type": "run_action",

"tabId": 123,

"actionId": "scrape_product"

}Chrome的sceneReporter.js收到以后，会调用：chrome.tabs.sendMessage(...)把任务交给真正运行在网页里的：content.js于是：Tauri ↓ sceneReporter ↓ content.js ↓ 网页DOM ↓网页执行完成以后：content.js ↓ action_result ↓ sceneReporter ↓ WebSocket ↓ Tauri ↓ ScenePanel这就形成了完整闭环：感知→理解→决策→执行→结果这也是我现在很喜欢的一种架构形态：手脑分离。Chrome更像是“手”和“眼睛”。Tauri更像是“脑”。

当这条通道真正跑起来以后，我开始重新思考MCP。MCP最大的价值之一，是它让AI可以连接外部能力。但是一个问题马上出现：如果用户安装了50个MCP，难道AURA每次都把50个工具展示出来？当然不是。真正应该发生的是：用户正在Amazon商品页 ↓ AURA判断当前场景 ↓ 找到Amazon相关Skill ↓ 只显示相关能力所以MCP的真正价值，不只是：“AURA支持MCP。”而是：AURA能把MCP放到正确的工作现场。这两者是完全不同的。

现在AURA的Skill Registry已经保存：Skill ID、Skill类型、Endpoint、Tools、权限、是否enabled、match_patterns例如：amazon_inventorymatch:*://*.amazon.com/*另一个：shopify_ordermatch:*://*.shopify.com/*于是就可以建立一条新的链路：Tauri Skill Registry ↓ skills_sync ↓ Chrome Extension ↓ 保存match_patterns ↓ 当前URL ↓ 本地匹配 ↓ mcp_matches ↓ Tauri ↓ Registry再次校验 ↓ ScenePanel这个设计里有一个我非常看重的原则：Chrome负责“发现”。Tauri负责“信任”。Chrome可以告诉Tauri：我认为当前页面匹配了Skill A和Skill B。但最终是否允许使用，必须由Tauri Registry决定。

因为Chrome是感知层，不应该成为安全边界。真正的权限判断仍然应该在Rust：Skill是否存在？↓ 是否enabled？↓ 是否是MCP？↓ 这个Tool是否存在？↓ 是否是auto_run？↓ 如果不是，用户有没有确认？只有全部通过，才能真正执行。这其实让AURA形成了一个非常清晰的分层：Chrome负责：“我看到了什么？”Tauri负责：“我允许什么？”MCP负责：“我能做什么？”Agent负责：“应该做什么？”我认为这个结构非常适合继续扩展。

其实已经不远了。目前需要完成的主要是：1.Tauri下发skills_sync2.sceneReporter接收skills_sync3.Chrome保存MCP match_patterns4.当前URL执行matchSkills()5.Chrome发mcp_matches6.Rust增加on_mcp_matches()7.Registry校验skill IDs8.生成安全的SkillView9.emit mcp-matched10.ScenePanel监听mcp-matched11.当前页面只显示匹配的MCP12.Skill安装/删除/启停后重新同步这些并不需要重造架构。最重要的是：已经存在的本地WebSocket可以直接复用。

### 十二、这让我意识到，AURA真正需要的可能不是“Skill Center”

传统软件的逻辑是：我安装了什么？↓ 我打开Skill Center↓ 我选择Skill而AURA更应该是：我现在在哪里？↓ 我正在做什么？↓ 有哪些能力与当前现场有关？↓ 直接出现所以：Skill Center解决的是：我有什么？而：Context Routing解决的是：我现在需要什么？这就是Ambient AI与传统AI工作台之间一个非常关键的差异。

如果Chrome能感知：用户正在Amazon商品页。那么为什么不能感知：用户正在Excel里修改报价单？为什么不能感知：用户正在Word里修改澳大利亚客户合同？为什么不能感知：用户刚刚下载了一个PDF？为什么不能感知：用户正在处理某个客户的邮件？为什么不能感知：用户在ERP里打开了某个订单？于是，我开始重新理解AURA的Semantic Cloud。

以前讲Semantic Cloud，很容易把它想成：客户 ↓ 产品 ↓ 订单 ↓ 公司 ↓ 员工 ↓ 项目但如果没有真实的数据来源，这些东西只是模型想象出来的。真正的Semantic Cloud应该从：Observation开始。也就是：AURA观察到用户正在发生什么。例如：Browser ObservationOffice ObservationFile ObservationDesktop ObservationEmail ObservationERP ObservationMeeting Observation然后再进入：Observation↓Normalization↓Entity Resolution↓Evidence↓Reality Store↓Semantic Cloud这就开始和我之前设计的Reality Model真正连接起来了。

比如用户打开：报价表.xlsxAURA不一定需要把整个Excel文件上传到云端。本地Agent可以先得到结构化观察：{

"source": "office",

"app": "excel",

"document": "报价表.xlsx",

"activity": "editing",

"entities": [

"客户A",

"SKU-1024",

"报价单"

]

}于是：Excel ↓ Office Sensor ↓ Observation ↓ AURA Desktop再进入：Reality Store

比如用户正在编辑：澳大利亚客户合同.docxAURA可以逐步形成：客户：XXX国家：Australia产品：SKU-A文档：合同状态：editing与此同时，浏览器里可能又发现：Amazon SKU-A邮件里又发现：客户XXXERP里又出现：订单XXX原本分散在不同软件里的信息，就开始有可能被连接起来。

它不是用户自己手工维护的知识库。而是：用户每天工作 ↓ 不断产生Observation ↓ AURA本地持续理解 ↓ Entity Resolution ↓ 形成实体与关系 ↓ 逐渐形成个人/企业Semantic Cloud最终可能形成：用户│├──客户│ ├──Australia客户│ ├──合同│ ├──邮件│ └──订单├──产品│ ├──SKU-A│ └──SKU-B├──项目├──任务└──报价关键不是画出一张漂亮的图。真正重要的是：AURA开始拥有关于这个用户工作世界的持续上下文。

比如：Excel里出现：SKU-1024邮件里出现：Product 1024Amazon里出现：B0XXXXERP里出现：1024AURA不应该马上武断地说：它们一定是同一个实体。而应该建立：EXACTLIKELYPOSSIBLEAMBIGUOUSNEW同时保存：FACTBELIEFCONFLICTHYPOTHESIS也就是说：语义云图不是“AI猜出来的世界”。而应该是一个带有证据、来源和置信度的Reality Model。这会让整个系统从“聊天AI”慢慢走向真正的“工作环境AI”。

我现在越来越倾向于把AURA理解成下面这个结构：AURA DesktopLocal Context Runtime│├──Browser Sensor├──Office Sensor├──Files Sensor└──ObservationContext BusReality / EvidenceEntity ResolutionReality StoreSemantic CloudAgent / MCP RouterScenePanelActionsExecutionChrome只是其中一个Sensor。MCP只是一个其中一个能力来源。ScenePanel只是一个其中一个交互入口。真正的核心，是中间这条：Context → Reality → Agent → Action

工作流平台的逻辑通常是：用户设计流程↓ 触发流程↓ 执行流程而AURA的逻辑是：现实发生↓ AURA感知↓ AURA理解↓ 发现相关能力↓ Agent出现↓ 执行一个是：Workflow-first另一个是：Context-first这可能是AURA真正应该坚持的方向。

MCP本身并不是产品。它更像是：AURA的能力生态接口。未来一个企业可以安装：ERP MCPCRM MCPShopify MCPAmazon MCPInventory MCPFinance MCPEmail MCPInternal Database MCP但是用户不需要面对这些复杂的MCP名称。AURA应该自动知道：当前场景+当前实体+当前任务然后选择合适的能力。所以用户看到的不是：调用MCP Tool xxx。而是：帮你查询这个客户的库存。已经找到对应订单。这个商品最近7天有3个相关询盘这才是MCP对普通用户真正有价值的方式。

不要让AI把用户带离工作现场。这是传统AI产品很容易做错的事情。用户在Amazon。AI让用户：复制URL↓ 打开AI↓ 粘贴↓ 描述问题↓ 等待↓ 复制结果↓ 回到AmazonAURA希望变成：用户就在Amazon↓ AURA已经知道↓ 相关Agent自动出现↓ 点击↓ 直接在页面执行这才是我理解的：AI at the worksite。AI不再是另一个目的地。AI变成工作环境的一部分。

我现在越来越不认为：Chrome Extension是AURA的产品。更准确地说：Chrome Extension是AURA感知互联网世界的一个器官。而：Tauri Desktop Agent是AURA的本地运行时。未来可以继续增加：Chrome AdapterOffice AdapterFile AdapterWindows AdapterEmail AdapterERP Adapter它们都进入：AURA Local Context Bus然后统一进入：Reality Store最后服务：AgentMCPSemantic CloudScenePanel

之前谈到具身智能，我也会想到机器人、机械臂、视觉模型。但如果把“具身”理解成：AI是否真正进入现实环境，并拥有感知和行动能力？那么电脑本身就是一个非常重要的数字环境。AURA已经开始拥有：视觉/感知：Chrome、Office、文件、窗口行动：点击、填写、调用API、运行Skill记忆：Reality Store理解：Entity Resolution / Semantic Cloud能力：MCP / Agent控制：Tauri Runtime这实际上是一种：Software EmbodimentAI不再只存在于一个聊天窗口里。它开始拥有：感知环境→理解环境→调用能力→改变环境的闭环。

这是这两天思考以后，我给自己划的一条边界。不要一上来就：“我要感知用户电脑的一切。”那会马上变成一个巨大、复杂、隐私压力极高的工程。更合理的路径应该是：第一阶段：BrowserChrome↓ Context↓ MCP Matching↓ Agent第二阶段：FilesPDFExcelWord本地文件第三阶段：OfficeExcelWordPowerPoint第四阶段：Desktop应用窗口活动第五阶段：Browser+Office+Files+Desktop+Email+ERP+CRM+Meeting最终才形成：Personal / Enterprise Semantic Cloud这样每一步都有真实价值，而不是先造一个庞大的“世界模型”。

以前我会说：企业AI智能资产与全域智能决策系统。现在我觉得这句话太像一个PPT。如果让我更直白地描述：AURA是一个安装在电脑上的企业AI Runtime：它持续感知用户的工作现场，把相关的Agent和能力主动带到当前场景，并直接帮助用户完成工作。或者更产品化一点：AURA：企业专属AI秘书，实时感知工作现场，主动告诉你重要的事，并直接帮你完成。这两句话，其实比World Model、Cognitive OS、Semantic Cloud更容易让真实用户理解。而后面的那些复杂架构，应该成为它的底座，而不是成为用户必须理解的产品概念。

表面上，我这两天做的是：MCP↓ URL Matching↓ ScenePanel但实际上完成的是更重要的一次架构验证：真实工作现场Chrome Sensor↓ Local Context Bus↓ Tauri Runtime↓ Context Understanding↓ Capability Routing↓ Agent↓ Action↓ Reality Changed这条链如果成立，那么未来接入什么，其实只是Adapter问题。今天是：Amazon明天可以是：Excel后天可以是：ERP再往后：企业内部系统而底层不需要重新发明。

模型当然重要。但对AURA来说，更重要的是：AI到底能不能知道用户现在在哪里、正在做什么、手上有什么东西、下一步可能需要什么，以及它有没有办法真正执行。模型负责“大脑”。但：SensorContextMemoryRealityToolsActions决定了这个“大脑”究竟有没有进入现实。这可能才是Ambient AI真正难的地方。

最开始：AI Chat然后：AI Assistant再往后：AI Agent而我现在真正想做的是：Ambient AI它不要求用户每天打开一个AI网站。它存在于：电脑浏览器Office文件企业系统这些用户本来就要工作的地方。它不断获得：Context逐渐形成：Reality积累：Semantic Cloud连接：MCP / Agents最终实现：Observe→ Understand→ Decide→ Act→ Remember这可能才是我这两天真正想清楚的事情。

做AURA到现在，我越来越觉得，真正有价值的不是再造一个AI聊天框，也不是再做一个Agent Marketplace。真正值得做的，是解决一个更底层的问题：如果AI真正进入人的工作世界，它应该如何知道“世界正在发生什么”？浏览器是一个入口。Office是一个入口。文件是一个入口。企业系统是一个入口。未来甚至物理世界也可以成为入口。而AURA Desktop的意义，就是把这些原本孤立的入口，逐渐汇聚成一个持续存在的Context Runtime。最终，用户不需要不断告诉AI：我是谁。我现在在做什么。这个客户是谁。这个文件是什么。这个订单和刚才那个邮件有什么关系。因为这些信息已经逐渐成为AURA对用户工作世界的理解。那时候，AI才真正开始从：“一个你偶尔使用的工具”变成：“一直与你一起工作的数字同事。”而这，也是我现在越来越想做的AURA。不是让用户进入AI。而是：让AI进入用户正在发生的现实。