最近我越来越难回答一个看起来很简单的问题：Mira 下一步要做什么。
并不是缺少事情。相反，事情已经多到很难再用一张功能清单解释。Desktop 仍然在清理过去留下来的结构，Mobile 开始承担越来越独立的角色，云端的身份、设备、授权和 Relay 刚刚连成真正的运行链路，Agent 也从单纯调用工具，慢慢走到了彼此如何协作的问题上。
过去这些工作很容易被分开理解。桌面端是一条线，移动端是一条线，云是另一条线，多智能体似乎又是更远的以后。真正做进去以后，它们却开始互相牵扯。Mobile 想调用另一台设备上的能力，就绕不开身份和授权；一个 Agent 想把任务交给另一个 Agent，就必须先知道对方究竟能够做什么；一些事情想在没有人守着电脑的时候继续运行，云便不再只是部署方式。
我越来越觉得，我们面对的已经不是几个功能应该怎样排期，而是 Mira 本身正在发生形态上的变化。
这大概才是我现在所说的 Next。
能力从机器里溢出来#
过去的一条主线，是让 AI 能够接触真实世界。
文件、终端、Browser、外部服务，一点点进入模型可以使用的范围。最开始的问题很直接：怎样让它多做一些事情。
这个问题解决得越好，另一个问题反而越明显。能力多起来以后，系统不能永远只靠一张越来越长的 Tool 列表维持秩序。
在只有一个 Agent 的时候，这种做法还能工作。模型看到工具，自己判断该不该调用，即使有些边界模糊，问题也不会立刻暴露出来。但如果未来不同环境里都有自己的 Agent，模糊就会迅速变成麻烦。某个能力到底属于哪台机器，现在是不是真的可用，谁有权限调用，结果应该交给谁，这些东西都不能一直靠模型临场猜。
我们后来把 Tool 和 Capability 分开，把 MCP 放回协议层，再用 Connector 表达外部能力，多少带着一点架构洁癖。但做得越久，我越觉得这并不只是术语整理。
它实际上是在回答一个很具体的问题：如果以后系统里不止一个 Agent，它们怎样知道彼此究竟会什么。
这并不只是 Mira 在自找麻烦。A2A 这类正在形成的 Agent 协议，已经把“能力发现”明确做成了协议的一部分。一个 Agent 会通过 Agent Card 声明自己的身份、端点、认证要求、能力和技能，调用方先理解这些信息，再决定它是不是适合当前任务。换句话说，当 Agent 真正开始彼此协作以后，“你是谁、你会什么、我该怎样和你工作”本身就需要成为接口。A2A Protocol 的 Agent Card 设计已经把这件事放进协议核心。
我并不希望每一台机器里都复制一个完全相同的 Mira。服务器、开发电脑和手机面对的是完全不同的环境，它们拥有的工具、权限、上下文乃至工作节奏都不一样。一个长期在线的节点可能适合做持续研究和观察，一台拥有完整开发环境的电脑更适合处理工程任务，Mobile 则天然离人更近。
与其想办法把同一个 Agent 塞进所有地方，不如允许环境塑造 Agent，然后让它们通过清楚的接口合作。
Anthropic 在自己的多智能体研究系统里也碰到了类似的问题。他们最后甚至尽量避免让所有子 Agent 的成果都经过主 Agent 转述，而是让专门 Agent 把结果直接写进持久化的 artifact，再把引用交给协调者，因为多层转述本身就会造成信息损失。这个细节很有意思：Agent 数量增加以后，高质量交接有时比增加一个更聪明的协调者更重要。Anthropic 对多智能体研究系统的复盘里，这一点已经变成了明确的工程经验。
这件事听起来没有“多智能体”三个字那么华丽，但我越来越觉得，它才是关键。多个 Agent 之间真正稀缺的，并不是再多一点推理能力，而是一个节点交出来的东西，另一个节点能不能准确接住。
软件工程花了很多年研究接口，到大模型出现以后，人们一度产生了一种很诱人的想象：既然自然语言什么都能说，也许接口终于可以消失了。
现在看，事情可能正好相反。
模型越能做事，接口越不能含糊。
Linear 在构建自己的 Agent 时采取了一个颇有启发性的办法：他们没有规定一条固定的执行路径，而是把约束放进工具设计、运行范围、领域模型和 Harness 中，让 Agent 在边界之内保持足够的自由。甚至有些限制，他们认为写进工具本身比写进 Prompt 更可靠。Linear 对自家 Agent 的工程复盘很值得参考。
这和我们过去对“架构约束”的直觉有一点相似。好的边界并不是为了把 Agent 变笨，而是为了让它有资格在边界内部更加自由。
云让一些旧问题重新变得不确定#
Mira 上云也经历了类似的变化。
如果只是把一部分服务放到服务器上，这件事本身其实没有什么新鲜的。真正让我开始认真考虑云，是因为越来越多任务并不适合跟着一台个人电脑的开关机生活。
持续研究、信息观察、邮件、定时工作，以及以后可能出现的更多长期任务，都希望有一个稳定的运行环境。这样的环境如果拥有自己的 Agent，它就不必一直等待一轮新的对话，也不需要模仿 Desktop 上已经存在的那套东西。它可以围绕自己的工具、技能和任务形成稳定节奏。
于是云开始从“把服务放在哪里”，慢慢变成“一个 Agent 可以怎样存在”。
这也是最近 Cloud Account、设备发现、授权和 Relay 对我真正有意思的地方。我们当然是在解决跨设备调用，但跨设备一旦真的成立，原本非常简单的“本地软件”概念也就跟着松动了。一个任务可能从手机发起，在另一台电脑上执行，身份来自统一账户，中间通过 Relay 建立连接。再往后，一部分 Agent 甚至可能长期生活在外部环境里。
这些变化也让我不太愿意继续轻松地使用 local-first 这个词。
这并不意味着我准备放弃它。只是当系统越来越跨设备、跨环境以后，“尽可能运行在本地”已经不足以回答所有问题。如果身份存在于云端，授权可以远程改变，一些任务需要长期在线，那么我们究竟想通过 local-first 保护什么，就应该重新说清楚。
有意思的是，local-first 最初的经典论述本来就不是一份简单的“反云宣言”。Ink & Switch 把问题放在 collaboration 和 ownership 之间：云软件带来了跨设备和实时协作，却往往也把数据和软件运行本身的控制权重新集中到服务提供者手中；他们真正想保住的是用户的 ownership、agency、离线能力、长期保存和跨设备协作。《Local-first software》至今仍然值得重读。
从这个角度看，Mira 今天遇到的问题其实更有意思。云本身并不是敌人，问题在于它逐渐承担更多职责以后，是否会重新成为一个无法替换的权威中心。
用户能不能带走自己的东西，能不能撤销权限，能不能换掉一项服务，某个云端节点消失以后系统是不是还剩下足够多属于自己的部分，这些问题最终都比“本地还是云”麻烦得多，却也更接近真实的边界。
我现在没有一个漂亮的答案，也不急着给它一个。
如果 Next 还有价值，其中一个原因就是它允许一些过去已经说得很确定的事情重新变成问题。
AI 真正开始工作以后#
另一条变化发生在工程本身。
这几个月我越来越明显地感觉到，问 AI 和用 AI 是两回事。
问一个模型问题，回答不好可以换个提示词，重新来一次。把一项工作真正交出去以后，模型聪不聪明只占其中一部分。它需要正确的环境，需要知道任务边界，需要拿到恰当的权限，过程最好还能留下别人可以检查的东西。事情失败以后，也得有人知道应该从哪里接手。
Mira 的组织化就是在这些现实问题里一点点长出来的。
现在已经有 Worker 负责施工，有 CI 提供运行证据，有 Review 找问题，也越来越强调 Issue Contract、Source of Truth 和实际验收。这些词摆在一起很容易显得官僚，但我们引入它们的原因恰恰不是喜欢流程，而是 AI 参与者多起来以后，过去那些依赖人自然理解的东西会突然失效。
一个 Agent 完成了代码，只说明代码完成了；测试通过，只说明被测试的东西通过了；Review 没有提出阻塞意见，也只是多了一份证据。它们都很重要，却没有任何一项能够单独回答“这个东西现在是不是可以交给用户”。
这方面 Anthropic 最近给 Agent Eval 下的一个区分很有用：transcript 是 Agent 做过什么、说过什么的完整记录，outcome 则是事情结束以后真实环境处于什么状态。一个订票 Agent 完全可以在最后说“已经为你订好机票”，但真正的 outcome 是数据库里究竟有没有那张订单。Anthropic 关于 Agent Eval 的文章把这个区别讲得很清楚。
这个区别听起来简单，放进实际工程却很重要。
CI、日志、Agent 自己的报告、Review 意见，很多时候都属于 transcript 或 evidence。它们告诉我们过程发生了什么，却不能自动代替对最终状态的确认。也因此，我们越来越少把“流水线绿了”直接等同于“产品完成了”。
这也是为什么我一直希望发布权留在人这里。
并不是我认为人永远判断得更好。很多时候 AI 已经可以把局部工作做得比我更快、更细。但产品最终要进入真实环境，局部证据必须重新放回最初的目标里看一次，而这个判断不能因为前面的自动化越来越完善，就顺便消失掉。
这同样并非什么奇怪的人类执念。NIST 的 AI Risk Management Framework 在谈 AI 治理时，也把 accountability 单独作为组织结构问题处理，要求角色和责任边界明确，并且把部署前后的 go/no-go 决策放进治理职责里。NIST AI RMF 的 Govern 部分提供了一个很朴素的背景：随着 AI 进入真实工作流，最终责任由谁承担，本来就是系统设计的一部分。
这当然不能直接推出“所有 AI 产品都必须由人按发布按钮”。但它至少说明，随着 AI 开始进入真实工作流，最终责任由谁承担已经不再只是产品体验问题，而是系统设计本身的一部分。
我对多智能体真正担心的也不是某个 Agent 偶尔犯错。错误通常还能被发现。更麻烦的是每一个 Agent 都很好地完成了分配给自己的局部任务，最后整个系统却没有朝真正重要的方向前进。
这种事情在人类组织里并不少见，AI 只会让它发生得更快。
所以我们一边扩大 Agent 能做的事情，一边又不断给它增加边界、证据和接口。表面上有些矛盾，实际是在解决同一个问题：怎样让更多工作可以脱离人的持续看守，又不让最终结果变成一场没有负责人参与的自动化。
偶尔我会想到巴别塔。不是因为 Agent 太多，也不是因为不同模型说着不同的语言，而是一个足够复杂的系统很容易出现这样的局面：每个局部都运转正常，整体却渐渐失去共同的现实。
我们现在做的很多工程治理，不过是在尽量避免走到那里。
Next#
如果把这些变化放在一起，Mira Next 其实很难被画成一个清晰的终点。
云端还会继续向外走，本地 Agent 之间的协作也才刚刚开始，Capability、Connector、Mobile 和 Organization 都还有很多没有解决的问题。今天觉得正确的架构，以后可能会被替换；一些现在投入很多精力的东西，也可能最终证明没有想象中那么重要。
我反而觉得这很正常。
Next 对我来说，本来就不是“下一代 Mira”。工程需要 Phase，需要版本，需要在某一天宣布一件事情完成，但 Next 没有这样的边界。
精神上，它是一种持续的探索；真正落到日常里，则是持续精进。探索让我们可以承认过去的答案不一定继续成立，精进则要求每一次怀疑最后都落实到真实可用的东西上，而不是为了追逐新概念不断重来。
这段时间最有意思的，也许正是很多曾经没有关系的事情开始彼此解释。我们为了让 Agent 做更多事情整理能力体系，为了让能力离开一台机器开始做云，为了把工作真正交给 AI 又不得不建立组织和责任边界。没有哪一步一开始就是为了今天这个结果，但走到这里以后，早期那些模糊的愿望开始有了能够承受它们的工程结构。
外部世界也正在经历相似的变化：协议开始讨论 Agent 怎样声明能力，产品团队开始重新设计 Agent 的运行边界，多智能体系统开始把交接和 artifact 当成一等问题，Agent Eval 也逐渐从“模型说了什么”走向“世界最后变成了什么”。
它们当然不会替 Mira 给出答案。
真正让我在意的是，这些原本分散的问题正在同时出现。这大概说明，Agent 从“会调用工具的模型”继续往前走以后，行业正在共同撞上一批新的工程问题，而我们也刚好在其中。
这也是为什么我会觉得，未来正在发生。
它通常没有什么仪式感。更多时候，它藏在一次重构、一个权限模型、一条终于跑通的跨设备链路，或者某个原本需要人一直盯着、后来终于可以放心交出去的任务里。做这些事情的时候，很少有人觉得自己正在创造未来。
等回头看的时候，才发现原来的边界已经不在那里了。
Next 大概也会一直这样继续下去。
Mira，今天也要努力前行。
