Build 2026 上，微软抛出了一个信号：AI Agent 不只是跑在现有硬件上的软件，它需要一种从芯片到云端都为之重新设计的计算平台。代号 Project Solara 正是这个方向的首次落地——一个"Agent 优先"的硬件与软件整合方案。
Windows 与设备副总裁 Steven Bathiche 在博客中明确表态：AI Agent 正在成为新的编程单元和人机交互单元。这句话的分量不轻——它意味着微软不再把 Agent 当作应用层的一个功能，而是把它提升到与"进程""线程"同级别的计算原语，并据此重构硬件架构。
Agent 为什么需要专属硬件？
现有计算设备的假设是：人类坐在屏幕前，发出一条指令，等一条结果。键盘、鼠标、触屏，都是围绕"人→机器→人"的短回路设计的。
Agent 打破了这个回路。一个 Agent 可能同时监听多个信号源、维护长期上下文、在后台持续推理、与其它 Agent 协商——它不是"执行一次就结束"的程序，而是一个持续运行、自主决策的实体。这对硬件提出了几类新需求：
- 低延迟持续推理：Agent 不像传统应用那样"等用户点击再计算"，它需要几乎不间断的小批量推理，对芯片的推理吞吐和功耗曲线要求与一次性大模型推理完全不同。
- 多模态感知并行：Agent 同时处理文本、语音、图像、传感器数据，需要硬件层面更高效的多模态数据通路，而非靠 CPU 做软件级调度。
- 长期上下文保持：Agent 的记忆可能跨天甚至跨周，对存储层级和内存带宽的占用模式更像数据库而非临时进程。
- Agent 间通信：多个 Agent 协作时，通信延迟和一致性要求接近分布式系统，但又必须跑在端侧设备上。
Project Solara 的架构围绕三个支柱展开（微软博客原文在此处截断，但从已公布信息可推断方向）：芯片级推理加速、设备-云混合调度、Agent 原生操作系统抽象。下面逐层拆解。
芯片层：推理不是"跑一下"，而是"一直在跑"
传统 NPU 设计的基准是"单次推理延迟"——拍一张照片，识别出物体，结束。Agent 场景下，推理更像一个常驻服务：每秒可能做几十次小推理（判断是否需要行动、更新记忆、评估环境），偶尔做一次大推理（规划多步任务）。
这意味着芯片需要：
| 传统 NPU 关注 | Agent NPU 关注 |
|---|---|
| 单次峰值吞吐 | 持续稳态吞吐 + 功耗包络 |
| 批量越大越好 | 小批量低延迟 + 大批量可弹性扩展 |
| 算完即释放 | 长期上下文驻留（KV Cache 不丢弃） |
| 单模态输入 | 多模态并行通道 |
Solara 的芯片层大概率会引入类似"推理常驻单元"的设计——一块专用的硅区域始终为 Agent 推理保持热状态，而非每次推理都经历完整的加载→计算→卸载周期。
设备-云混合：Agent 的身体在端侧，大脑可以弹性伸缩
一个 Agent 不可能所有推理都跑在本地——复杂规划、大规模知识检索、多 Agent 协调，算力需求远超端侧芯片容量。但全部跑在云端又会破坏 Agent 的实时感知能力（延迟、隐私、离线可用性）。
Solara 的混合调度模型可以理解为：
端侧（常驻） 云端（弹性）
───────── ─────────
感知推理 ←→ 规划推理
短期记忆 ←→ 长期记忆 / 知识库
单 Agent 决策 ←→ 多 Agent 协调
端侧芯片负责"身体"——持续感知、快速反应、隐私敏感操作。云端负责"大脑"——复杂规划、知识增强、跨设备协调。两者之间不是简单的"本地不够就上云"，而是Agent 自身根据任务复杂度和延迟要求动态选择执行位置。
操作系统层：Agent 成为一级调度单元
这是最深远的变化。现有 OS 的调度单位是进程和线程，Agent 在 OS 眼里只是一个普通进程。Solara 要做的，是把 Agent 提升为 OS 的一级抽象：
- Agent 有自己的生命周期管理（创建、休眠、唤醒、销毁），而非依附于某个 app 的生命周期。
- Agent 有独立的资源配额（推理算力、内存、网络带宽），OS 按配额调度而非按进程优先级。
- Agent 有标准化的通信协议，类似进程间的 pipe/socket，但语义是"请求→承诺→结果"而非"发送→接收"。
这意味着未来的 Windows 可能会有一个 Agent Runtime，和今天的 .NET Runtime 或 V8 Engine 同级别——它不是跑在用户态的库，而是内核集成的执行环境。
实践：在现有基础设施上模拟 Agent 优先调度
Solara 的完整硬件还没上市，但 Agent 优先的调度思路现在就可以实践。下面是一个用 Kubernetes + 自定义调度器模拟"Agent 资源配额"的示例——把 Agent 当作独立调度单元，分配专属推理算力和内存配额。
1. 定义 Agent 资源配额 CRD
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: agentquotas.solara.example.com
spec:
group: solara.example.com
versions:
- name: v1alpha1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
agentName:
type: string
inferenceQuota:
type: object
properties:
npuMillicores:
type: integer
description: "推理算力配额，单位毫核"
memoryMB:
type: integer
maxConcurrentInferences:
type: integer
contextQuota:
type: object
properties:
longTermMemoryGB:
type: integer
shortTermMemoryMB:
type: integer
schedulingPolicy:
type: object
properties:
preferEdge:
type: boolean
description: "优先调度到端侧节点"
allowCloudBurst:
type: boolean
description: "端侧不足时允许溢出到云端"
scope: Cluster
2. 为一个 Agent 分配配额
apiVersion: solara.example.com/v1alpha1
kind: AgentQuota
metadata:
name: home-assistant-quota
spec:
agentName: home-assistant
inferenceQuota:
npuMillicores: 500 # 占用半核 NPU
memoryMB: 2048
maxConcurrentInferences: 10
contextQuota:
longTermMemoryGB: 5 # 5GB 长期记忆存储
shortTermMemoryMB: 512 # 512MB 短期上下文
schedulingPolicy:
preferEdge: true # 优先跑在家庭边缘节点
allowCloudBurst: true # 复杂任务可溢出到云端
3. Agent 部署清单（带配额引用）
apiVersion: apps/v1
kind: Deployment
metadata:
name: home-assistant-agent
spec:
replicas: 1
selector:
matchLabels:
app: home-assistant-agent
template:
metadata:
labels:
app: home-assistant-agent
solara.example.com/agent: home-assistant
spec:
containers:
- name: agent-runtime
image: solara/agent-runtime:0.1
env:
- name: AGENT_NAME
value: "home-assistant"
- name: QUOTA_NAME
value: "home-assistant-quota"
- name: EDGE_PREFERENCE
value: "true"
resources:
requests:
memory: "512Mi"
solara.example.com/npu: "500m"
limits:
memory: "2Gi"
solara.example.com/npu: "1000m"
volumeMounts:
- name: long-term-memory
mountPath: /agent/memory/longterm
- name: short-term-memory
mountPath: /agent/memory/shortterm
volumes:
- name: long-term-memory
persistentVolumeClaim:
claimName: agent-longterm-5gb
- name: short-term-memory
emptyDir:
medium: Memory
sizeLimit: 512Mi
nodeSelector:
solara.example.com/capability: edge-npu # 优先调度到有 NPU 的边缘节点
运行前需要做什么：这个示例假设你已有一个 K8s 集群。你需要先安装 CRD（步骤 1），然后创建 AgentQuota 资源（步骤 2），最后部署 Agent（步骤 3）。
solara.example.com/npu是自定义资源类型，需要你注册对应的 Device Plugin 才能真正调度——可以参考 Kubernetes Device Plugin 文档 实现一个 NPU 插件。当前没有真实 NPU 硬件时，可以用 CPU 资源模拟推理配额，把npu换成cpu即可跑通。
这个示例的核心思路是：Agent 不再是一个普通 Pod，它有声明式的推理配额、记忆配额和调度偏好——这正是 Solara 在操作系统层要做的事情，只是我们用 K8s 的扩展机制提前模拟了。
落地前的几个现实问题
Solara 的方向很清晰，但落地还面临几道硬坎：
应用生态断层。现有 Windows 应用全是"人→应用"模式，Agent 优先的交互需要全新的 UI 框架——不是"按钮+菜单"，而是"对话+意图+后台行动"。开发者需要新的 SDK 和设计范式，这比硬件更难铺开。
芯片制造周期。从架构设计到量产通常 2-3 年，Solara 的芯片即使架构已定，真正到消费者手中还要等。第一批设备大概率是开发者套件或企业端设备，而非消费级 PC。
Agent 安全边界。Agent 作为一级 OS 抽象，意味着它有持续运行权和资源配额——一旦失控，影响远超一个崩溃的 app。OS 层需要 Agent 级别的沙箱、审计和熔断机制，这比容器隔离更复杂。
云-端信任链。Agent 在端侧和云端之间迁移推理时，上下文数据如何加密传输、云端推理结果如何验证完整性，都是尚未标准化的领域。
开发者现在可以做什么
Solara 离全面商用还有距离，但 Agent 优先的思路不需要等硬件：
- 把 Agent 当独立服务设计，而非嵌在某个 app 里的功能模块。给它独立的持久化存储、独立的 API 边界、独立的生命周期管理。
- 声明式资源配额，用 K8s 或类似机制为 Agent 分配推理算力和内存配额，而非让它和普通服务争抢资源。
- 端云混合推理，用延迟和复杂度双维度做调度决策——简单感知跑本地，复杂规划上云端——现在就可以用标准 HTTP/gRPC 实现。
- 关注 Agent 通信协议，A2A（Google 提出的 Agent-to-Agent 协议）和类似方案正在成型，尽早参与标准化比等 Solara OS API 更现实。
Project Solara 的意义不在于它立刻改变了什么，而在于微软正式把"Agent 是计算原语"这个假设写进了硬件路线图。当芯片、OS、云端都围绕这个假设重构时，Agent 就不再是应用层的一个时髦概念——它是计算的基础单元。