趁着周末时间，又利用时间在科研路上。

在埋入从产品经理埋入计算机博士道路之后，最大的感受就是产品的技术壁垒直线型提升。我带着团队寻找科研论文的有趣的算法与公开项目框架，从而基于此来做产品框架与研发，会比以前的产品更加有坚实的技术基础。

现在很多产品经理还停留在功能性产品设计与交互界面，并且专注在娱乐、大厂工具等厂家，没有办法在产品黑科技功能上做产品规划从而满足用户需求。

那么读了计算机博士之后，基于产品研究方向与公司战略，寻找到科研论文研究，并且以科研的思路做产品研发，产品的技术避壁垒性就会直接提高，还不用担心性能，因为论文中势必会有对比实验与结果。

最近阅读到一篇文章，我认为是AI产品经理未来发展的最终阶段就是朝着AIOS的系统做产品设计，分享几点AInative的产品经理工作技能。

随着越来越多的AI编码IDE平台，我认为他们就是AIOS的前身，包括现在的各类agent类产品，如下是AIOS的系统信息架构。

AIOS将会是下一个OS系统的产品经理机会

在AI模型下，我们native的AIAPP都会有全新的UI界面，而不再是给用户一个框定好的框框或矩形，而是用户想要什么界面，就可以实时生成。

这种AI模型生成的技术革命，意味着现在熟悉的所有产品研发思路，都在底层上要更换，比如我们传统的产品做AI新增功能，都是AI+。而AIOS的用户虽然使用的业务场景还是固定的，不过他们不再是固定按钮、标签、入口，而是可以随着用户场景变化与需求变化进行替换的。

如上是wordlabs推出的3D世界，用户在前景过程中，都是AI依据路线生成而，而不是固定的路径与背景。

AIOS 的固定产品框架：输入与输出

在AIOS里，产品经理仍然要给用户一个操作按钮与输入框，甚至是某些固定界面来完成具体的业务操作。

用户的熟悉门槛是很高的，如果全新的界面，那么用户就会又要花费时间去熟悉了，所以在AI操作系统里，我们熟悉的浏览器、笔记、社交聊天工具仍然是他们，区别是他们没有固定的界面，他们的软件界面是实时生成的或者基于你个性进行匹配升级的。

在这篇论文里，提到了AI操作系统的信息技术架构架构，通过大语言模型为基础设施，用一样的硬件来完成的系统堆叠。一共有三层，分别是应用层、AIOS核心层与传统OS核心层以及硬件，针对没有用户交互、逻辑推理的需求部分用传统OS层来完成接入，有用户输入与交互的就是AIOS核心部分。

我们熟悉的Cursor以及Manus这类IDE工具逐步演变都是类似于AIOS的架构，他们在里面搭配了各类工具，从而将其在AIOS系统的AIOS核心部分，比如我们提到的各类编码环境、预览工具，都可以属于里面的scheduler、tools部分，从而得到更高效率。

上面AIOS 核心部分，包含了计划、行动、记忆和存储部分，以及调度控制，在传统的AI应用里，，用户发出去旧金山飞机的任务命令，可以看到agent完成了7个步骤，分别是信息检索、航班与酒店推荐、以及最后的回复所有综述，都是来自LLM运行，而针对数据校验、支付、以及日历日程信息添加都是来自AI，这是非常低效的使用AI资源的，并且如果任务多之后就会变得越来越臃肿。

而随着代理任务越来越多，LLM的处理以及OS的信息读取也越来越频繁，处理计算机硬件资源、以及模型任务就成了AIOS解决方式，我们可以衍变出下面的信息系统架构

应用层来自AI应用，而内核部分的进程、闪存、系统文件部分、以及硬件驱动都交给传统OS内核，而日产任务、文本任务、记忆任务、存储管理以及工具管理和权限全力交给LLM 的内核，从而形成OS系统底层。

这里存在的代理服务分别是

代理调度器(Agent Scheduler)：优先处理和安排代理请求，以优化LLM的利用。

上下文管理器(Context Manager)：支持在LLM中快照和恢复中间生成状态以及LLM上下文窗口的管理。

记忆管理器(Memory Manager)：为每个代理的交互日志提供短期记忆。

存储管理器(Storage Manager)：将代理的交互日志持久化到长期存储，以便未来检索。

工具管理器(Tool Manager)：管理代理调用外部API工具（例如搜索、科学计算）。

访问管理器(Access Manager)：在代理之间执行隐私和访问控制策略。

在AI OS操作系统下，势必是多个模型代理，由此多个模型代理的切换与内部通信就至关重要了，所以AIOS操作系统提供了不同模型之间内核的切而保证在不同特定任务下可以运行模型最佳的操作系统。

AI编程IDE，下一代AIOS系统

从目前来看，我们选择一些IDE编程的AI模型还是手动选择，需要用户自己根据特定的任务来切换最合适的大语言模型

虽然在AIOS里面存在多个SDK管理，方便AI模型可以驱动各类任务，如下是论文里面提到的注册、生产计划、创建计划、更新计划、初始计划，涵盖agent的生命周期管理，从而有效降低延迟时间，如下是在论文提到的AIOS实验，在有AIOS的任务重，任务等待时间要减少接近一半。

AI操作系统的产品经理：专注在模仿类似人类与电脑的交互

在应用层面上，AI操作系统的交互就是模仿人类打开电脑各类终端服务，比如浏览器、办公文件、编码编译环境等，这些步骤都是产品经理要同步映射到AI OS 里，而不是给用户一个执行结果，让用户无法监管到过程步骤，增加用户对于产品执行过程中的可信性。

如下类似Manus产品的产品界面，都是有对应的任务进度留、任务时间、以及任务操作页面。包括了CHATGPT 代理模式的交互，产品经理提供了预览计算机操作浏览的网页以及文档页面

如下是左边任务对话框，右边是任务流，可以再任务流中查看解压文件包以及浏览网页的操作环境。

以上任务都是还是在一个agent的情况下，而理论上我们可以封装更多数量的代理，从而获得不同的结果再来进行取最优解。比如将相同的任务发给10个不同的Manus类的产品，就会有10个结果，从而再进行比较。

刚好全新的Manus就是往这方向迭代的，支持多个任务agent的同时并发，并且agent之间还能互相协作。

如下是论文里AIOS系统中的AI调度机制，允许调度不同的AI模型，通过特定规则从而实现高内存使用。

这就是我们所谓的AI操作系统LLMS应用部分与调度机制。

AI产品经理将在2-3年成为最热门的职业，没有之一

有了IDE编程与交互设计工具，几乎每个人都可以成为独立开发者，前提是要能够挖掘到用户在AI时代的新需求与过往场景的结合。

AI产品经理我认为在未来2年-3年左右，所有市面上的传统软件都将会被Native的AI产品进行替代，任何产品不是固定的界面，而是每次操作的输入与输出功能、与交互路径是固定的，其他的AI任务结果交互则不是统一的，没有固定的GUI，可以随着用户的变化进行变化的。

以上计就是今天的分享

论文参考：

https://arxiv.org/pdf/2403.16971

本文来自微信公众号“Kevin改变世界的点滴”（ID：Kevingbsjddd），作者：Kevin那些事儿，36氪经授权发布。