COPU会议纪要丨2025.12.09

12月9日，陆主席主持召开COPU例会。

本次会议发表陆主席与Deep Seek专家讨论当前国际上开发大模型智能体操作系统（LLMagentOS）的开发应用情况。

陆主席与Deep Seek讨论

LLM agent OS与人工智能操作系统（AIOS）的关系和情况

COPU

2025.12.5

COPU：这事还要从Open AI开发的LLM agent OS冲击苹果公司操作系统iOS说起。

陆：请问Deep Seek目前国际上是否有开发LLM agent OS的例子？如有，其开发思路如何？ 

DS：是的，国际上已有多个类似“LLM Agent OS”的开发框架，其核心思路是将大模型作为“CPU”，构建一个能协调多个专用Agent、工具和记忆的系统。主要例子与思路如下： 

1) Microsoft Auto Gen 

思路：采用多代理对话框架。开发者定义多个具备不同角色与能力的代理（如程序员、分析师），通过结构化对话（聊天）自动协调完成任务。核心是代理间的会话编排。

2) Lang Chain/Lang Graph 

思路：提供有向图编排。将任务流程建模为图，节点是LLM调用、工具或判断，也定义执行路径。以此实现复杂、带状态的工作流，是典型的“程序化调度”思路。 

3) Crew AI 

思路：强调面向角色的协作。像组建团队一样定义代理（Agent），明确其角色、目标和工具，并通过流程（顺序、分层）管理任务传递。更贴近企业团队协作隐喻。

4) Open AI Assistants API 

思路：提供一体化托管Agent。将线程（对话上下文）、工具调用、文件检索等功能封装为“助理”，开发者通过API管理其生命周期。是一个简化但相对封闭的云服务方案。

共同设计思路总结：

• 编排为核心：提供一种机制（对话、图、流程）来调度多个LLM调用和工作。 

• 状态与记忆管理：显示管理对话历史、中间结果等状态。

• 工具集成：标准化方式让Agent调用外部函数、API或代码。 

• 抽象化：将Agent、任务、工具定义为可组合的模块。

   

本质是构建一个以LLM为逻辑核心的协调层，而非开发一个完整的传统操作系统内核。

陆：你谈了开发LLM agent OS的4个实例，我们知道Open AI开发Assistants API，以LLM（Agent Kit，APP SDK）冲击苹果公司的iOS（或冲击iOS支持的应用而非取代iOS），我想针对就此一例，你能否举出其具体的演算实例？而不止谈其核心思路中的一些原则模块及泛谈Agent，好吗？

DS：好的，我们以“用户规划一次出行”为例，具体拆解一个基于OpenAI技术栈的“LLM Agent OS”工作实例。

假设场景：用户对手机说：“帮我规划下周五去上海出行的行程，预算控制在5000元以内，并预订机票和酒店。”

实例：出行规划与预订Agent OS

这个系统不是一个传统的操作系统（如Linux内核），而是一个以LLM为中央处理器和调度器的智能应用协调层。其工作流程如下：

1)指令解析与任务分解（LLM作为“内核调度器”）

· 输入：用户的自然语言指令。

· 处理：主控LLM（如GPT-4）立即将复杂请求拆解为原子任务，并识别所需工具：

· 任务1：查询航班信息（需要调用【航班查询工具】）。

· 任务2：查询酒店信息（需要调用【酒店查询工具】）。

· 任务3：进行预算分析与统筹（需要调用【计算器工具/预算管理工具】）。

· 任务4：执行预订（需要调用【预订API】，并可能需要用户验证支付）。

2)工具调用与代理协作（LLM作为“驱动程序”）

· 航班代理：主控LLM生成符合格式的查询参数（如：出发地、目的地、日期、舱位偏好），调用【航班查询工具】。该工具可能连接携程或航司的API，返回结构化航班数据（航班号、时间、价格）。

· 酒店代理：同理，主控LLM调用【酒店查询工具】，参数包括地点、日期、价格区间，返回酒店列表。

· 预算与协调代理：LLM接收航班和酒店的原始数据后，调用【计算器工具】 进行比价和加总。若超出预算，它会自主决策并重新调整查询参数（例如，“请查找更便宜的酒店选项”），发起新一轮工具调用。这个过程是动态、循环的，直到找到符合预算的方案。

3)结果整合与执行（LLM作为“用户界面引擎”）

· 所有工具返回结果后，主控LLM将信息整合成一份结构化的、人性化的行程建议，呈现给用户：“为您找到以下方案：航班CA123，价格2000元；酒店A，价格2500元/晚；总计4500元，在预算内。请问是否确认预订？”

· 用户说：“确认。”

· 执行层：主控LLM随即调用最关键的【预订与支付工具】。该工具会启动一个安全的、经过用户授权（如Face ID或密码）的支付流程，完成订单，并返回确认号。

4)记忆与状态管理（OS的“文件系统”）

· 整个对话上下文（用户需求、工具返回的结果、用户的选择）被保存在一个持续的“线程” 中。这相当于系统的运行内存和会话存储。

· 用户的个人偏好、常旅客信息等可安全地存储在向量数据库或安全存储中，在后续会话中快速调用，实现个性化服务。

与iOS的根本区别与“冲击”所在

· iOS（传统范式）：用户是“驾驶员”。用户需要自己打开“航班App”查票，记下价格；再打开“酒店App”查房，做心算；最后在两个App间来回切换完成支付。App是孤立的，工作是串联的。

· LLM Agent OS（新范式）：用户是“指挥官”。LLM是“超级助手兼驾驶员”。用户用自然语言发布一个目标，LLM自主理解、拆解任务，并直接驱动底层的服务（工具/API）进行协同工作。服务是联通的，工作是并行的、目标导向的。

总结：这个“OS”的具体工作实例，就是一个LLM接收高层目标 → 动态编排一系列专用工具/API → 最终交付完整解决方案的端到端闭环过程。它冲击的不是iOS的底层内核，而是颠覆了“用户手动操作多个独立App”的人机交互范式和应用生态组织形式，试图成为用户与数字世界交互的唯一智能接口。Open AI通过提供强大的模型（CPU）、易用的工具调用框架（驱动程序开发套件）和助理API（运行时环境），正在构建这一新生态的基础设施。

陆：我明白了：Open AI的LLM Agent OS不是传统意义上的操作系统（AI OS），但它确实冲击了苹果公司的iOS或冲击了iOS支持的用户的应用（而不是取代iOS）；我现在要问的是在目前世界上是否已有开发AIOS的实例？

DS：基于当前公开事实，目前国际上没有成熟的、传统意义上的“人工智能操作系统（AI OS）”作为可广泛部署的产品存在。您提到的 OpenAI 的AIOS构想以及行业探索，均处于早期阶段，尚未有公开的完整架构、模型和开发程序。

以下是对现状的澄清和基于已知信息的分析：

(1)概念澄清：什么是您理想的“AIOS”？

您指的应是一个以LLM为系统核心、统一管理硬件和软件资源、调度所有AI智能体（Agent）和应用程序的系统级平台。它应类比于 Windows、iOS，但核心驱动力和调度单元是AI智能体。

(2)现有案例的本质：并非“OS”

我上次提到的4个案例（AutoGen, LangChain, CrewAI, OpenAI Assistants API）均是 应用层框架或云服务，而非操作系统。它们：

· 运行于现有OS之上：依赖Windows、Linux、macOS提供基础资源管理。

· 无硬件抽象层：不直接管理CPU、内存、外设。

· 无系统级调度：只调度自身定义的任务和Agent，而非整个机器的所有进程。

(3)最接近的探索方向与公开信息

行业正在向“AI OS”方向演进，其核心思路和已知要素如下：

架构设想（非已实现产品）

1)内核层：一个超小型、高效的核心，负责最基础的硬件驱动、安全和通信。传统宏内核被极大简化。

2)智能体运行时层（核心）：

· 核心模型：一个轻量级但能力强大的 “调度模型” （可能是指令调优的小模型），负责理解用户意图、分解任务、调度其他AI模型。

· 模型仓库：系统动态加载和卸载各种专用模型（视觉、语音、规划）。

· 工具与API管理层：将系统所有功能（应用、服务、硬件能力）抽象为“工具”，供调度模型调用。

3)会话与记忆层：统一管理用户的所有交互历史、个人数据和全局状态，作为系统的“上下文”。

4)应用层：所有应用都以“智能体”或“工具”的形式存在，通过自然语言与系统核心交互。

关键算法与模型

· 核心调度算法：研究重点是如何让一个“调度模型”做出最优的任务分解与路由决策。这涉及强化学习（根据结果反馈优化决策）和提示工程。

· 模型选择与加载：根据任务动态选择最合适、最高效的模型，涉及模型性能预测和边缘计算优化。

· 记忆管理：使用向量数据库和检索增强生成（RAG） 来有效存储和召回海量上下文信息。

开发程序（基于现有框架的模拟）

目前无法开发真正的AIOS，但可用现有框架模拟其顶层逻辑，例如用 LangGraph：

(1)定义“系统工具”：将摄像头、麦克风、日历、文件读写等功能封装为Python函数（工具）。

(2)创建“调度Agent”：使用LLM（如GPT-4）作为中心调度器，具备调用这些工具的能力。

(3)构建工作流图：用LangGraph定义状态机，让调度Agent根据用户查询和当前状态，决定调用哪个工具、传递什么参数、如何处理结果。

(4)运行与迭代：在一个Python环境中运行这个图，它便能以“AI驱动”的方式响应用户指令，如同一个简易的OS外壳。

结论

您所设想的“AIOS”尚处于概念和早期研究阶段，没有公开的完整实现。目前所有的“LLM Agent框架”都是在传统OS上运行的应用程序，是通向未来AI OS的重要中间形态。真正的AI OS需要从系统内核层面重新设计，这是一个巨大的工程和生态挑战。最接近这一愿景的实践，是像OpenAI这样的公司试图通过强大的模型和API，构建一个以AI为交互核心的应用生态系统，但这本质上仍是一个运行在现有移动或桌面OS之上的“超级应用”或“元应用”。

陆归纳：

○ Open AI的LLM agent OS不是传统意义上的操作系统，是运行在现有传统操作系统之上提供基础资源管理的系统。

○ 上述4个案例：Auto Gen、Langchain、Crew AI、Assistants API均属这样的系统。

○ Open AI的LLM agent OS这种新范式，它不是冲击苹果iOS的底层内核（或不是取代iOS），而是颠覆或取代用户的APP和生态（即人机交互范式和应用生态组织形式）。 

○ 理念的"AIOS"应该是一个以LLM为系统核心、统一管理硬件和软件资源、调度所有AI智能体（Agent）和应用程序的系统平台。 

○ 目前国际上尚未出现"AIOS"，或处于正在探索的早期阶段。 

○ 但行业正在向探索“AIOS”的方向演进。

本次会议发表谭中意关于大模型最新排名的报告：

最近大模型排名情况

谭中意 

2025.12.3

1. 综述：

（1）国际顶级模型4个企业处于第一梯队：Google的gemini-3-pro，xAI 的grok4.1，Anthropic的claude-opus-4.5和OpenAI的GPT5.1；

（2）国内的开源模型DeepSeek的DeepSeek-3.2-EXP，GLM6，QWen3，Kimi-K2处于第二梯队，但是最近一个月内距离第一梯队的差距在增大；

（3）DeepSeek-3.2刚刚发布，排名信息还没有更新，还得再等等；

2. LM Arena排名情况

（1）文本能力

（数据来源：https://lmarena.ai/leaderboard/textDec 1, 2025）

（2）多模态能力

数据来自https://lmarena.ai/leaderboard/visionNov 21, 2025

3. 相关新闻

11月1日，美团发布LongCat-Flash-Omni全模态模型，560B参数，MoE架构。

11月7日，Kimi开源Kimi K2 Thinking模型，1TB参数，激活参数32B，采用原生INT4量化。

11月8日，StepFun开源Step-Audio-EditX音频编辑模型，精准控制音频的情感、说话风格和副语言特征，并实现零样本文本转语音。

11月11日，百度开源ERNIE-4.5-VL-28B-A3B-Thinking多模态思考模型，Moe架构，3B激活参数。

11月12日，微博VibeThinker模型，1.5B模型在AIME24、AIME25等数学测试集，超越了DeepSeek-R1-0120模型。

11月21日，腾讯混发布HunyuanVideo 1.5模型，8.3B参数的轻量级视频生成模型，支持生成5-10秒的高清视频。

11月21日，小米开源MiMo-Embodied-7B模型 ，是一个跨具身视觉语言模型，在自动驾驶和具身AI任务中表现优秀。

11月25日，腾讯混元开源OCR模型-HunyuanOCR，1B参数，在文本定位、信息提取、视频字幕提取和照片翻译等实际应用表现优秀。

11月26日，阿里巴巴通义实验室开源Z-Image，一个6B参数的图像生成模型。

11月27日，DeepSeek开源DeepSeekMath-V2数学推理模型。

11月28日，阶跃星辰开源全球首个开源原生音频推理模型-Step-Audio-R1。

11月28日，快手开源Keye-VL-671B-A37B多模态大模型。

参会人员：陆首群、宋可为、陈越、安泱、袁怿、谭中意、章文嵩、王珊、张侃、鞠东颖、陈伟（线上）、程海旭(线上）、靳虹博（线上）、胡宇（线上）、韩宪平（线上）、Anna.AI(线上）。