微软执行副总裁 Yusuf Mehdi 在内部备忘录中确认，他将于 2027 年 6 月离职，结束长达 35 年的微软生涯。但离职前的最后一年，他给自己定了一个硬任务：把 Windows 从传统操作系统推进到 Agentic OS——一个由 AI Agent 驱动、以 Copilot 为统一入口的智能平台。从 Windows 3.1 到 Copilot，Mehdi 见证了整个 PC 时代的变迁；而 Agentic OS，是他给微软留下的最后一笔赌注。
Agentic OS 到底在说什么
"Agentic OS"不是换个壳、加个聊天窗口那么简单。它的核心命题是：操作系统不再只是资源调度器，而是变成一个能理解意图、编排任务、自主执行的协作引擎。
传统 OS 的交互模型是"人 → API → 应用 → 结果"。用户要知道哪个应用能做什么，手动打开、手动配置、手动串联。Agentic OS 的模型变成"人 → 意图 → Agent → 多应用协同 → 结果"。用户说"帮我整理昨天的会议纪要并发给团队"，Agent 自己调度 Outlook、Word、Teams，完成提取、整理、分发，中间不需要人逐步操作。
这对 Windows 的架构意味着几件事：
- Shell 层重构：Copilot 不再是侧边栏的附属工具，而是 Shell 的第一入口。Start Menu、Taskbar、Explorer 的交互逻辑都会围绕 Agent 重新设计。
- 权限模型升级：Agent 要跨应用操作，必须有一套比当前 UAC 更细粒度的授权机制——哪些数据 Agent 可以读、哪些操作可以自动执行、哪些必须人工确认。
- 应用接口从 GUI 转向 Agent-API：现有应用的菜单、按钮是给人用的；Agentic OS 要求应用暴露语义级接口（intent-based API），让 Agent 能直接调用功能而非模拟点击。
One Copilot：统一入口背后的工程挑战
Mehdi 推动的 "One Copilot" 愿景，本质上是把目前散落在 Bing、Edge、Office、Windows 各处的 Copilot 实例合并为一个跨场景的统一 Agent。用户在任何入口发起的意图，都由同一个 Copilot 实例承接，上下文连续、能力一致。
这件事的工程难度不小：
- 上下文持久化：用户在 Edge 里搜到的信息，要能无缝带入 Word 的写作流程。这意味着 Copilot 需要一个跨应用的共享记忆层，而非每个应用各自维护 session。
- 能力路由：同一个 Copilot 收到意图后，要判断该调用哪个应用的哪个能力。这需要一个能力注册与发现机制——类似微服务的 service mesh，但注册的是"应用能做什么"而非"服务在哪"。
- 安全边界：One Copilot 拿到了跨应用的操作权限，一旦 prompt injection 或意图误判，影响范围远超单个应用。防御机制必须在架构层面内置，不能靠事后修补。
现在能做什么：在 Windows 上搭建 Agent 工作流的实践
Agentic OS 还在路上，但开发者今天就可以用 Windows + Python + LLM API 搭出 Agent 工作流的雏形。下面是一个最小可运行的示例：用 Python 调用 OpenAI API，模拟一个能读取本地文件、整理摘要、再调用 PowerShell 发邮件的 Agent。
先安装依赖：
pip install openai pydantic
核心 Agent 逻辑：
import os
import subprocess
import json
from openai import OpenAI
from pydantic import BaseModel
client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
# ---- 定义 Agent 可用的工具 ----
class ToolCall(BaseModel):
tool: str
args: dict
TOOLS = {
"read_file": {
"desc": "读取本地文本文件内容",
"params": ["path"],
},
"send_email": {
"desc": "通过 PowerShell 发送邮件（需本机配置 SMTP）",
"params": ["to", "subject", "body"],
},
"list_dir": {
"desc": "列出目录下的文件名",
"params": ["path"],
},
}
def tool_schema():
"""生成供 LLM 选择的工具描述"""
return json.dumps(
{name: t["desc"] for name, t in TOOLS.items()},
ensure_ascii=False,
)
# ---- 工具执行层 ----
def execute_tool(call: ToolCall) -> str:
if call.tool == "read_file":
with open(call.args["path"], "r", encoding="utf-8") as f:
return f.read()[:4000] # 限制长度，防止 token 爆炸
elif call.tool == "list_dir":
return "\n".join(os.listdir(call.args["path"]))
elif call.tool == "send_email":
# 调用 PowerShell 发邮件——实际使用前需配置 SMTP
ps_script = f"""
$Outlook = New-Object -ComObject Outlook.Application
$Mail = $Outlook.CreateItem(0)
$Mail.To = '{call.args["to"]}'
$Mail.Subject = '{call.args["subject"]}'
$Mail.Body = '{call.args["body"]}'
$Mail.Send()
"""
result = subprocess.run(
["powershell", "-Command", ps_script],
capture_output=True, text=True, timeout=30,
)
return result.stdout or result.stderr
else:
return f"未知工具: {call.tool}"
# ---- Agent 主循环 ----
def agent_run(user_intent: str, max_steps: int = 5) -> str:
messages = [
{
"role": "system",
"content": f"你是一个 Windows Agent，可以调用以下工具完成任务：\n{tool_schema()}\n"
"每一步返回 JSON 格式 {{\"tool\": ..., \"args\": ...}} 或最终答案文本。",
},
{"role": "user", "content": user_intent},
]
for _ in range(max_steps):
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=messages,
temperature=0,
)
text = resp.choices[0].message.content
messages.append({"role": "assistant", "content": text})
# 尝试解析为工具调用
try:
call = ToolCall.model_validate_json(text)
result = execute_tool(call)
messages.append({"role": "tool", "content": result})
except Exception:
# 不是工具调用 → 视为最终回答
return text
return "达到最大步数限制，任务未完成。"
# ---- 运行示例 ----
if __name__ == "__main__":
# 示例意图：读取会议纪要并发邮件
answer = agent_run(
"读取 C:\\Users\\me\\Documents\\meeting_notes.txt 的内容，"
"整理成三句话的摘要，然后发送到 team@example.com，"
"主题为'昨日会议摘要'。"
)
print(answer)
运行前需要：
- 设置环境变量
OPENAI_API_KEY。 - 确保目标文件路径存在，或改为你自己的路径。
- 邮件发送依赖 Outlook COM 对象，本机需安装 Outlook 并配置好账户。如果不想依赖 Outlook，可以把
send_email替换为调用 SMTP 库（如smtplib）的纯 Python 实现。
这个示例虽然简陋，但它演示了 Agentic OS 的核心循环：意图 → 规划 → 工具调用 → 观察 → 继续或完成。Windows 真正的 Agentic OS 会把这个循环内置到 Shell，工具注册由系统统一管理，安全边界由 OS 强制执行——但开发者的 Agent 设计思路，今天就可以开始验证。
落地前要想清楚的几件事
Agentic OS 听起来顺滑，实际落地有几个硬问题不会自动消失：
- 权限爆炸：Agent 能跨应用操作，意味着一次误判的代价远高于手动操作。OS 必须提供"确认门槛"——高风险操作（删除文件、发送邮件、支付）必须弹窗让用户确认，低风险操作（读取非敏感文件、格式化文本）可以静默执行。门槛的阈值怎么定，是产品决策也是安全决策。
- 调试困境：Agent 链路长、步骤多，出错时用户很难定位是哪一步出了问题。Agentic OS 需要内置执行日志和回溯机制——类似浏览器 DevTools，但面向 Agent 调用链。
- 应用生态的配合：如果第三方应用不暴露 Agent-API，Copilot 只能退回模拟 UI 操作的旧路，可靠性大打折扣。微软需要给出足够强的开发者激励（流量、分发、收入）让应用主动适配。
- 本地 vs 云端的平衡：Agent 的推理跑在云端，但文件操作、系统调用跑在本地。网络中断时 Agentic OS 退化到什么程度？哪些 Agent 能离线运行？这决定了用户体验的下限。
给开发者的行动清单：
- 现在就开始设计 intent-based API——你的应用对外暴露的接口，不要只有 REST endpoint，还要有语义描述（"这个接口能做什么"），方便未来 Agent 注册发现。
- 在 Windows 上跑一个 Agent 原型——用上面的代码或类似框架（LangChain、AutoGen）验证你的场景是否适合 Agent 串联，而不是等微软把 OS 做完再动手。
- 关注 Windows Copilot SDK 的演进——微软已经在逐步开放 Copilot 的扩展点，尽早接入意味着你的应用在 Agentic OS 时代有优先曝光位。
- 划定安全边界——在设计 Agent 工作流时，提前标注哪些步骤需要人工确认，不要等到上线后再补。
Mehdi 用 35 年走完了 Windows 从图形界面到 AI 入口的全程。Agentic OS 是他最后的押注，也是 Windows 在 AI 时代重新定义"操作系统"这个词的机会。概念已经亮出来了，接下来看的是工程执行力——以及开发者生态跟不跟得上。