2026 年 9 月 8 日，我们继续讨论 Mira。

上一篇草案停在 Agent、工具、触界、MCP、Mobile 和外部世界。那时我们已经意识到，Mira 正在长出越来越多可以接触现实环境的能力，但很多东西还没有被放到合适的位置。

这一次讨论没有继续往 Agent Runtime 的节点、Planner 或 Tool Schema 里面钻，而是有意停留在产品和架构边界上。

我们重新问了几个更基础的问题：

Mira 拥有什么能力？

Tool、MCP、微应用和 Agent 分别应该是什么？

当 Agent 真正开始替用户持续工作以后，那些工作又应该存在于哪里？

有些问题这次已经出现了相对清楚的方向，也有一些被明确放进了“需要继续调研”的小本本。

这仍然不是版本规划，也不是已经可以直接施工的架构合同。

它只是第二次草案。

审批不应该成为 Agent 每走一步都要敲一次门#

Mira 当前高风险操作的审批体验仍然比较重。

如果 Agent 连续执行一个工作任务，用户可能反复面对网络请求、文件操作、Shell、删除等授权。单次看，每一次确认都有安全理由；连续看，它却很容易把 Agent 重新变成一个必须由人逐步遥控的工具。

所以我们提出了一个新的方向：

审批对象应该从“这一次动作”，逐渐升级为“这一类能力在什么边界内可以自主执行”。

例如，用户第一次允许 Mira 在当前工作空间执行普通 Shell 命令以后，只要操作仍然处于相同的风险边界，就不应该每一条命令重新询问。

真正值得重新审批的，是边界发生变化：

同一种能力
+ 相同作用域
+ 相同目标性质
+ 相同副作用边界
→ 不重复询问

作用域 / 目标 / 风险发生变化
→ 重新审批

我们暂时把高风险能力粗分成三类：

  • 首次授权后可持续使用；
  • 作用域或目标变化时重新授权；
  • 即使已经授权，仍然保留强确认的不可逆操作。

但这一部分没有定案。

尤其是删除、外部数据发送、凭据使用、跨工作空间访问、远端资源修改，以及什么操作应该永远保留强确认，都需要专门做一轮安全与产品调研。

因此这条目前的状态很明确：

方向暂定，特别调研。

我们不准备因为嫌弹窗烦，就草率地把安全边界拆掉。

每个 Agent 对话应该先拥有一块自己的地方#

审批问题很快把我们带到了另一个更基础的问题：Agent 到底在哪里工作？

第二次草案提出了一条很具体的产品方向：

每一个默认 Agent Conversation，都应该拥有自己独立的小文件夹。

它不是一个用户需要主动创建的“项目”，更像这条对话天然拥有的工作空间。

Agent 可以在那里保存：

  • 用户交给它处理的文件；
  • 临时产物；
  • 下载内容；
  • 中间结果；
  • 脚本；
  • 最终 Artifact；
  • 为这条任务链生成的其他文件。

这块独立目录也天然提供了一条权限边界。

在自己的 Conversation Workspace 内，Agent 可以拥有相对自由的文件操作空间；一旦它需要访问用户其他目录、另一个项目，或者系统级路径，再进入更高一层权限判断。

这比简单地给一个 Agent “文件系统权限”更符合 Mira 想做的事情。

Agent 不是获得整台电脑。

它先获得一块属于当前工作的地方。

能力不应该继续由工具名字定义#

讨论 Mobile 调用 Desktop 能力时，我们最初尝试了一套很直觉的分类：

感知
看
读
搜
增
删
改

这套语言非常容易理解，但很快暴露出一个问题：它混合了不同层级。

“截图以后读文字”到底属于看还是读？

“搜索文件然后打开结果”到底属于搜还是读？

“网页请求”既可能只是获取公开信息，也可能把本地文件发送出去。

因此第二次草案更倾向于先把 Mira 的行动能力收敛成几个更稳定的一级概念：

感知
获取
变更
执行
外联

其中：

获取
├─ 看
├─ 读
└─ 搜

变更
├─ 增
├─ 改
└─ 删

“执行”被单独拉了出来，因为 Shell、脚本、CLI、应用操作和自动化都无法自然塞进 CRUD。

“外联”也被单独拉了出来，因为访问互联网和向外部世界发送东西，在风险上完全不是同一件事。

这套 Capability 分类主要回答：

Mira 能做什么？

审批系统则回答：

这种能力在什么边界内可以执行？

两者不应该继续混成一个 taxonomy。

这也会影响 Mobile。

未来手机端不应该理解 Desktop 上到底安装了多少 MCP Server、多少 Tool、多少 Provider。

它更应该看到：

这台桌面 Mira 现在能提供哪些能力？

实际由哪个 Tool、MCP、浏览器 Runtime 或本地程序完成，是 Desktop Runtime 内部的事情。

Tool 不应该是 MCP Tool 的别名#

能力分类继续往下讨论时，我们发现了另一个历史理解可能需要纠正的地方。

Mira 当前有相当一部分内部工具体系围绕 MCP 组织，这在早期非常方便，因为 MCP 提供了现成的 Schema、发现和调用协议。

但它也容易产生一个错误印象：

Tool 必须先成为 MCP Tool，才能成为 Mira 的能力。

第二次草案现在更倾向于反过来理解：

Tool 是 Mira 自己的能力执行单位。MCP 是这些能力可能采用的一种互操作协议。

因此未来更自然的结构可能是：

Agent
  ↓
Capability
  ↓
Tool Runtime
  ├─ Native Tool
  ├─ MCP Adapter
  ├─ Browser Runtime
  ├─ Remote Capability
  └─ 其他 Provider

MCP 仍然非常重要。

Mira 仍然可以作为 Host 消费第三方 MCP Server，也可以把自己的精选能力通过 MCP 暴露给 Mobile 或其他客户端。

但 Mira 内部的工具不应该为了“能够被 Agent 使用”，先包装成 MCP。

否则权限、生命周期、可见性、调用和能力路由都会逐渐被一个外部协议反向定义。

这部分还需要结合当前代码进一步判断实际耦合程度。

如果现状只是“统一接口借用了 MCP Tool Schema”，问题不大。

如果 Tool 只有挂进 MCP 才能存在，那就真的需要重构。

微应用开始从“一个设置页里的大筐”变成真正的平台概念#

上一篇草案里，我们曾经尝试把 MicroApp 收缩成“拥有独立 UI 的领域能力”。

这一次，我们走得更远了一些。

首先确定的是：

微应用首先是一个长期存在的小产品。

它不是 Agent 完成一次任务以后临时长出来的 UI，也不从属于某一条 Conversation。

它应该拥有：

  • 自己的 UI；
  • 自己的状态；
  • 自己的数据；
  • 自己的生命周期；
  • 独立运行能力。

随后我们又做了一个更大胆的判断：

微应用是独立可执行程序。

它不一定必须经过 Mira 主 Tool Runtime 才能做任何事情。

一个微应用理论上可以拥有自己的：

  • 文件能力；
  • 网络能力；
  • Shell；
  • MCP；
  • 模型调用；
  • 甚至自己的 Agent Runtime。

这意味着 Mira 对微应用的定位不再只是“一个页面容器”。

我们选择了：

Mira 是微应用平台。

平台应该提供一层尽量轻的 Contract，例如应用标识、入口、生命周期、UI、能力声明、权限声明和版本信息；但平台不应该把微应用内部每一次执行都收编进 Mira 主 Runtime。

这里的原则更接近：

Mira 管平台边界，微应用保持程序自主性。

人可以打开微应用，Agent 也可以#

我们没有把微应用变成一个只给人使用的“应用中心”。

也没有把它降级成只有 Agent 才知道的隐藏 Tool。

第二次草案明确选择了双入口：

User
  ──→ Micro App

Agent
  ──→ Micro App

用户可以主动打开一个微应用，把它当一个长期存在的小产品使用。

Agent 也可以根据当前任务主动发现并唤起它。

微应用自己声明支持：

foreground
background
both

有些任务适合后台运行，例如批量整理、转换和索引；有些任务需要立即打开 UI；还有一些可以先后台工作，真正需要用户介入时再拉起界面。

微应用内部理论上也允许拥有自己的 Agent Runtime。

但它不是微应用的必备条件，只是一种高级形态。

微应用之间不应该长成一张硬依赖网#

我们还讨论了微应用之间如何协作。

最后没有选择 App A 直接调用 App B。

更倾向于：

Micro App A
    ↓
   Agent
    ↓
Micro App B

微应用保持独立。

跨应用协作由 Agent 完成发现、选择、上下文传递和任务协调。

这样可以避免 Mira 最终长成一张复杂的应用依赖图。

同时，微应用向 Agent 暴露的也不应该只是几十个底层 Tool。

我们选择了更产品化的一层：

微应用向 Agent 暴露“服务 / 意图”。

例如：

整理录音
分析表格
编辑图片
生成演示文稿

Agent 需要知道的是：

这个应用能替我完成什么？

至于内部最终使用 Tool、MCP、Workflow 还是它自己的 Agent，是微应用自己的实现。

这也意味着 Mira 需要某种 Micro App Registry。

但 Registry 不应该把全部微应用描述每轮都塞进模型上下文。

更合理的是：

Micro App Registry
       ↓
任务相关候选筛选
       ↓
少量能力渐进式披露
       ↓
Agent

这部分和我们之前对 Tool 渐进式发现的方向很相似。

但“微应用是不是插件体系”没有讨论出结果#

这里我们停住了。

一个很诱人的方向是：

Mira 的微应用最终可能承担插件体系。

因为它已经具备 UI、独立执行、能力扩展、Agent 调用和长期存在这些特点。

但继续往下推以后，又会遇到反例：

  • 纯 Skill 没有 UI；
  • 一个 MCP Server 未必是应用；
  • Connector 可能只有授权配置；
  • Headless Tool Provider 也可能扩展 Mira；
  • 浏览器扩展有自己的产品形态。

因此目前存在两个候选方向。

一种是：

Mira 一级扩展能力
└─ Plugin System
   ├─ Micro App
   ├─ Skill
   ├─ Tool Provider
   ├─ MCP
   └─ Connector

另一种则更激进：直接让“微应用”成为 Mira 插件体系本身。

这次没有结论。

我们明确把它留在第二次草案的小本本里，而不是因为其中一个结构看起来漂亮，就提前把产品命名钉死。

浏览器能力可能会吞掉一批现在看起来必要的专用能力#

我们也重新提到了 News Hub 和网页搜索。

现在回头看，很多所谓“网络能力”其实可能只是浏览器能力尚未成熟时的过渡形态。

例如：

  • 查新闻；
  • 搜索网页；
  • 查某个网站；
  • 阅读论坛；
  • 获取登录后页面；
  • 操作 SaaS；
  • 上传与下载。

未来它们未必值得分别拥有一个专用 Tool。

更自然的方向可能是：

Web 世界优先收敛到 Browser Capability。

浏览器能力本身则可以包含：

看网页
读网页
搜网页
操作网页
使用登录态
提交
上传
下载

于是“查新闻”只是浏览器能力的一次任务。

“搜索 GitHub”也是。

“进入某个后台检查状态”仍然是。

这不意味着所有外部能力都会被浏览器替代。

邮件、IM、API、系统服务、企业集成等场景，专用协议依然可能更加稳定、高效和可治理。

但我们不应该因为一种 Web 场景今天还不好做，就不断创造新的长期 Tool 名称。

浏览器很可能成为 Mira 连接数字世界的一块基础能力。

Mira 不能只有行动能力，还需要认知能力#

讨论到这里，我们又碰到一个看起来很性感的词：

洞见。

一开始很容易把 Insight 当成一个高级 Tool。

但继续想下去以后，我们发现它和“获取、执行、外联”不是同一种东西。

行动能力回答的是：

Mira 能做什么动作？

洞见回答的是：

Mira 从已经拥有的信息里看出了什么？

它可能来自：

  • 对话历史；
  • 用户文件；
  • 浏览器环境；
  • 微应用数据；
  • 项目状态；
  • 邮件；
  • 日程；
  • 长时间积累的事件变化。

最后形成的不是简单总结，而可能是：

这几个需求其实指向同一个问题。

这个项目最近的执行节奏出现了异常。

用户几次看似无关的修改，实际上都在绕同一项技术债。

两条原本分开的信息，应该被放在一起重新判断。

这让我们开始尝试把 Mira 的一级能力分成两组：

行动能力
├─ 感知
├─ 获取
├─ 变更
├─ 执行
└─ 外联

认知能力
├─ 记忆
├─ 上下文
└─ 洞见

其中：

Memory 负责沉淀。

Context 负责在当前任务里调度什么。

Insight 负责从这些信息中发现新的关系、趋势和判断。

这目前只是概念层。

但它带来了一个很重要的变化：

Mira 不再只是拥有越来越多“手和脚”。

她开始需要一个真正持续工作的认知底座。

Agent 不再是一个模式，而是 Mira 的行动主体#

第二次草案最后回到了 Agent。

我们这次没有继续讨论 Agent Loop 的节点，而是重新定义了产品层的 Agent：

Agent 是 Mira 的行动主体。

它不是一个聊天里的高级开关，也不是某个特殊任务才进入的模式。

聊天、Tool、Browser、MicroApp、Memory、Insight 等能力，最终都可以由 Agent 根据当前目标进行协调。

但产品上，Agent 又可以表现为不同的个体。

我们暂时把它理解为：

Agent 是继承 Mira 统一 Agent 架构的个体化行动主体。

不同 Agent 可以拥有自己独立的：

  • 人格；
  • Tool 可见性；
  • 特殊 Skill；
  • 领域知识；
  • 工作方式；
  • 行为偏好。

一个代码 Agent、一个研究 Agent、一个更偏生活协助的 Agent，可以明显不同。

但它们不需要复制一整套 Runtime。

它们继承同一个 Agent 架构。

短期我们不准备一上来做一个复杂的“Agent 工厂”。

先做我们认为真正靠谱的少量 Agent。

但长期来看：

Agent Definition 必然需要向用户开放。

用户应该拥有定义自己 Agent 的能力。

开放的是人格、能力、Skill 和工作方式，而不是让普通用户重新实现 Planner 和 Runtime。

Agent 做出的工作不能最后只剩在聊天记录里#

这一轮讨论里，我们还定了一条非常产品化的原则：

Agent 做出的工作，需要进入看板。

这并不意味着每句话、每次 Tool Call 都要变成一张卡。

真正需要进入看板的，是形成了持续工作价值的对象：

  • 任务；
  • 工作包；
  • Artifact；
  • 需要用户确认的结果；
  • 尚未完成的工作；
  • 已完成但值得继续管理的成果。

因此聊天和看板承担不同职责。

聊天更像：

理解、讨论、委托、协调。

看板则承接：

任务、状态、产物和持续工作。

一个 Agent 不能每次聊完以后，工作事实就重新埋进 Conversation History。

如果 Mira 真正开始长期替用户工作，她必须拥有一个用户可以重新找到、继续管理和接管这些工作的地方。

Forge 已经展示出一条很初级、但真实的流水线#

讨论看板时，我们重新看了已经进入 Mira Desktop 的淬行 / Forge。

它目前已经存在一条比较清晰的工程闭环：

Project
  ↓
Main Thread
  ↓
Repository Task
  ↓
Dispatch
  ↓
Builder
  ↓
Review / Fix
  ↓
Result Handoff

同时它拥有 Batch、Runtime Task、Dispatch、Session、Review、Runtime Event 和 Handoff 等执行期状态。

这意味着 Forge 已经不只是“一个代码 Agent”。

它开始形成一种更长期的生产关系：

工作对象被创建，进入执行，经历状态变化，由不同角色接力，最后形成可追踪的结果。

这和我们刚刚讨论的 Agent 看板很接近。

因此第二次草案出现了一个新的判断：

Forge 可以被看作 Mira Agent 工作流体系的第一个专业化样本。

但我们不准备把 Forge 的全部结构抽成 Mira 的通用 Agent 模型。

Builder、SHA Review、Task Card、工程 Branch 等很多东西都属于软件开发领域。

普通研究、写作或生活任务不应该被强迫套进一条软件流水线。

真正值得继续观察的，是 Forge 已经表现出来的四个抽象：

工作对象
→ 状态流转
→ Agent / 能力接力
→ 产物落板

如果未来 Mira 真的形成更一般的工作流能力，Forge 可能不是那个通用系统本身。

它更像第一个证明：

Agent 的工作可以从一次聊天，成长为一个持续存在的生产过程。

还有哪些事情没有讨论完#

这次比上一篇走得更远，但远没有结束。

审批模型#

首次同类授权、风险签名、跨作用域重新审批和强确认到底怎么定义，需要专项调研。

这是安全边界，不适合靠产品直觉拍板。

微应用 Contract#

我们已经形成产品定义，但还没有研究最小 Manifest、运行承载、进程隔离、数据目录和生命周期协议。

微应用权限#

既然微应用可以是独立执行程序，它自己的 Shell、网络、文件操作与 Mira 主审批系统之间是什么关系，需要单独设计。

微应用的数据边界#

微应用有自己的长期数据，Conversation 有自己的 Workspace。

两者怎样交换文件、引用 Artifact 和转移工作，还没有讨论。

Desktop 与 Mobile 的微应用关系#

手机是否能发现桌面微应用、遥控后台任务、进入部分 UI，Mobile 自己是否也拥有微应用平台，这一轮没有展开。

微应用与插件体系#

没有结论。

这是明确保留的问题，不应该被当前任何一版示意图提前定案。

洞见#

Insight 很吸引人，但它如何产生、何时主动出现、怎样避免成为一个不断“自作聪明”的提醒系统，还需要非常克制地讨论。

通用 Agent 看板与工作流#

我们只确定 Agent 的持续工作需要落板，也发现 Forge 已经具有初级流水线特征。

但 Mira 是否需要一套通用工作流，以及它应该薄到什么程度，这一轮没有继续设计。

第二次草案暂时走到这里#

和上一篇一样，我们没有准备马上把这些方向全部变成任务卡。

今天最值得留下来的，不是某一个具体 Schema，而是几个逐渐变清楚的层级：

  • 审批应该面向能力边界，而不是无限重复确认单次动作，但安全规则需要专项调研；
  • 每条默认 Agent Conversation 应该拥有自己的独立工作空间；
  • Mira 的行动能力可以先按感知、获取、变更、执行、外联理解，风险审批使用独立维度；
  • Tool 应该是 Mira 自己的能力执行单位，MCP 是其中一种互操作协议，而不是所有 Tool 的根；
  • 微应用正在从一个混合的 Settings 大筐，重新被定义为真正独立、可执行、有 UI、可以被人和 Agent 使用的小产品；
  • 微应用向 Agent 暴露的应该是“它能完成什么服务”，而不是一堆内部 Tool；
  • 微应用与插件体系之间的关系暂时没有结论；
  • Web 世界里的很多专用能力，未来可能逐渐收敛到 Browser Capability；
  • Mira 除了行动能力，还需要记忆、上下文和洞见这样的认知能力；
  • Agent 是 Mira 的行动主体，不是一个特殊模式；不同 Agent 共享统一架构，但可以拥有自己的人格、工具、Skill 与工作方式；
  • Agent 形成的持续工作不能只留在聊天历史里，而应该进入看板；
  • Forge 已经展示出一种初级但真实的长期工作流水线，它可能成为未来通用 Agent 工作流的重要参考，而不是通用模型本身。

如果上一篇草案在问：

Mira 怎样真正把手伸向外部世界？

那么这一篇更像是在问：

当 Mira 已经拥有越来越多手、眼睛、工具和工作台以后，她要怎样把这些东西组织成一个真正会持续工作的自己？

答案还没有完成。

但至少，很多原来堆在一起的东西，开始慢慢回到属于自己的位置。

Tomz Dang × Mira

上一篇← 让生图和声音进入角色对话