当我们聊 Agent OS 时，我们聊些什么
- ID: c5c9715a
- 原文链接: https://mp.weixin.qq.com/s?__biz=MzkzNTk2MDUxMg==&mid=2247484348&idx=1&sn=cbf6bd580b44738c6f501f9ffd6383bb&chksm=c3f5eb56a9d66370fc52075887c47735629523dabdbc4cac41a5b90fe09da491d20fd3c16c15
- 作者: 非共识进化论 / Fortune OS
- 日期: 2026-07-26
- 分类: agents
- 标签: agent-os, memory, skills, agent-orchestration, data-fabric
- 质量评分: 4/5
- 抓取时间: 2026-07-26T23:35:50+08:00
- Obsidian 证据: Cubox/当我们聊Agent OS时，我们聊些什么-2026-07-26.md
一句话
Agent OS 的核心不是更强聊天框，而是围绕记忆、技能、权限和数据编织的系统层
中文导读
这篇访谈把 Agent OS 从消费级 Agent 热潮中拆出来：它要解决的不是让单个 Agent 更会聊天，而是让 Agent 能被调度、组合、持久化和信任。文中把核心模块拆成身份人格、分层记忆、Skill Schema 与沙箱、编排调度、权限边界和 Data Fabric，并强调场景容器与共享能力引擎分离，适合作为 Agent 产品架构讨论材料。
Obsidian 证据摘录
开手机要解决的是"消磨时间"的问题，这是两条完全不同的需求曲线。再往下看，生产力工具想产生价值，终究要扎进具体的生产场景，可现在经济周期收缩，真正能提供持续红利、值得被自动化的场景其实很有限，剩下的大多是贩卖焦虑的课程。
但这不是给Agent判死刑。恰恰相反，在那些已经存在、结构清晰的生产场景里，当Agent真正深入场景、和数据打通之后，效率的提升是实打实的。问题从来不是"Agent有没有用"，而是"Agent该长在哪儿"------这也是我们为什么会往Agent OS这个方向走。
**Q：那什么是Agent OS？跟"一个更强的Agent"有什么本质区别？**
Jensen：区别很大。Agent OS不是一个更强的Agent，也不是给Agent套一层UI壳子。
传统操作系统解决的是"如何让软件安全高效地调度硬件资源"，Agent OS要解决的是"如何让Agent安全高效地调度智能资源"------只是这里的资源不再是CPU和内存，而是数据、工具、记忆和信任。
可以做个不完全严谨但很直观的类比：传统OS里的进程，对应Agent OS里的单个Agent实例；文件系统对应记忆与上下文管理；驱动程序对应技能（Skill）与工具调用层；内核调度器对应多Agent编排与任务分发；权限管理对应数据边界与人格边界。一句话概括，Agent OS是让Agent从一个孤立的对话窗口，变成一个能被调度、被组合、被持久化、被信任的系统级智能单元的底层设施。
**Q：具体拆开看，一个真正意义上的Agent OS要具备哪些核心元素？**
Jensen：我们内部大概分六块。
第一是身份与人格，Agent不再是无状态的问答机器，要在不同会话、不同设备之间保持"我是谁、我记得什么、我的立场是什么"的一致性。第二是记忆系统，短期上下文解决"这一轮在说什么"，长期记忆解决"这个人是谁、我们之间发生过什么"，检索、压缩、遗忘机制决定了Agent是活得像个人，还是每次都在装失忆。第三是技能与工具层，这是Agent真正产生生产力的地方，技能能不能被复用、被组合，直接决定了Agent OS的天花板。第四是调度与编排，任务复杂到需要多个Agent协作时，谁分工、谁仲裁冲突、谁做最终决策，这是操作系统级的调度问题。第五是权限与信任边界，Agent能看到你哪些数据、能替你做哪些决定、出错了谁负责------这层缺失，Agent就只能停留在聊天玩具阶段。
第六个是数据编织层，我觉得是当下最被低估、也最卡脖子的一层。大多数场景做不起来，不是模型不够聪明，而是数据和应用之间存在结构性割裂------Agent想帮你订机票，却拿不到你的日历；想帮你做决策，却调不动业务系统里最新的数据。Data Fabric要做的，就是把这些割裂的数据源编织成Agent能理解、能调用的统一语义层。
**Q：现在市面上做Agent OS的技术路线好像不太一样，你们选了哪一条？**
Jensen：目前基本分两个流派。一个是"真OS"，自上而下，照搬传统操作系统的设计哲学，先定内核再定协议再定生态，追求通用性，想成为下一个Android或iOS，野心大，但周期长、见效慢，生态没起来之前很难证明自己比一个场景化产品更有效率。
另一个是"场景容器"，自下而上，先扎进一个具体场景，把这个场景需要的数据、技能、交互方原文 / 抓取内容
当我们聊Agent OS时，我们聊些什么
热闹属于风口上的故事，价值属于愿意做脏活的人
非共识进化论
📝 这里不提供标准答案，这里只记录那些敢于离开标准答案的人。
8篇原创内容
<br />
公众号
，
**本期受访者**
**Fortune OS产品负责人**
Q：先聊聊大背景吧。这段时间"全民Agent"的热度好像降下来了，小龙虾、爱马仕这些梗当时挺火的，你怎么看这个转折？
Jensen：今年上半年"全民Agent"的势头是真的猛。OpenClaw和Hermes Agent这两个开源框架，几个月内就冲到了几十万star，几乎每个做产品的人电脑里都跑着一个自己搭的Agent。热闹得像一场全民狂欢。但潮水退得比涨得还快，半年不到，大多数人打开自己那个Agent，发现能稳定完成的事情，还是"你好""你是谁""今天天气怎么样"------一个披着智能外壳的天气预报机器人。
但我不觉得这是一次失败，更像是一次误诊。我们把Agent当成了一个要卖给十几亿人的消费品，可它骨子里从来都是一个生产力工具。生产力工具解决的是"做事"的效率问题，大多数人打开手机要解决的是"消磨时间"的问题，这是两条完全不同的需求曲线。再往下看，生产力工具想产生价值，终究要扎进具体的生产场景，可现在经济周期收缩，真正能提供持续红利、值得被自动化的场景其实很有限，剩下的大多是贩卖焦虑的课程。
但这不是给Agent判死刑。恰恰相反，在那些已经存在、结构清晰的生产场景里，当Agent真正深入场景、和数据打通之后，效率的提升是实打实的。问题从来不是"Agent有没有用"，而是"Agent该长在哪儿"------这也是我们为什么会往Agent OS这个方向走。
Q：那什么是Agent OS？跟"一个更强的Agent"有什么本质区别？
Jensen：区别很大。Agent OS不是一个更强的Agent，也不是给Agent套一层UI壳子。
传统操作系统解决的是"如何让软件安全高效地调度硬件资源"，Agent OS要解决的是"如何让Agent安全高效地调度智能资源"------只是这里的资源不再是CPU和内存，而是数据、工具、记忆和信任。
可以做个不完全严谨但很直观的类比：传统OS里的进程，对应Agent OS里的单个Agent实例；文件系统对应记忆与上下文管理；驱动程序对应技能（Skill）与工具调用层；内核调度器对应多Agent编排与任务分发；权限管理对应数据边界与人格边界。一句话概括，Agent OS是让Agent从一个孤立的对话窗口，变成一个能被调度、被组合、被持久化、被信任的系统级智能单元的底层设施。
Q：具体拆开看，一个真正意义上的Agent OS要具备哪些核心元素？
Jensen：我们内部大概分六块。
第一是身份与人格，Agent不再是无状态的问答机器，要在不同会话、不同设备之间保持"我是谁、我记得什么、我的立场是什么"的一致性。第二是记忆系统，短期上下文解决"这一轮在说什么"，长期记忆解决"这个人是谁、我们之间发生过什么"，检索、压缩、遗忘机制决定了Agent是活得像个人，还是每次都在装失忆。第三是技能与工具层，这是Agent真正产生生产力的地方，技能能不能被复用、被组合，直接决定了Agent OS的天花板。第四是调度与编排，任务复杂到需要多个Agent协作时，谁分工、谁仲裁冲突、谁做最终决策，这是操作系统级的调度问题。第五是权限与信任边界，Agent能看到你哪些数据、能替你做哪些决定、出错了谁负责------这层缺失，Agent就只能停留在聊天玩具阶段。
第六个是数据编织层，我觉得是当下最被低估、也最卡脖子的一层。大多数场景做不起来，不是模型不够聪明，而是数据和应用之间存在结构性割裂------Agent想帮你订机票，却拿不到你的日历；想帮你做决策，却调不动业务系统里最新的数据。Data Fabric要做的，就是把这些割裂的数据源编织成Agent能理解、能调用的统一语义层。
Q：现在市面上做Agent OS的技术路线好像不太一样，你们选了哪一条？
Jensen：目前基本分两个流派。一个是"真OS"，自上而下，照搬传统操作系统的设计哲学，先定内核再定协议再定生态，追求通用性，想成为下一个Android或iOS，野心大，但周期长、见效慢，生态没起来之前很难证明自己比一个场景化产品更有效率。
另一个是"场景容器"，自下而上，先扎进一个具体场景，把这个场景需要的数据、技能、交互方式打包成一个高度定制的容器，更像垂直的应用运行环境。优点是见效快、场景贴合度高，代价是难以复用，换个场景容器基本要推倒重来。
我们走的是第二条，但做的时候刻意规避了"容器难复用"这个坑：容器只负责配置，不负责造轮子。每个场景容器下面垫着同一套共享能力引擎------记忆引擎、Skill执行引擎、权限引擎都是复用的，容器与容器之间真正不同的，只是挂载了哪些数据源、装配了哪些技能、记忆颗粒度怎么设。容器是配置态，引擎是运行态，二者分离，才能既保住场景深度，又不至于每次都从零开始。
Q：能再展开讲讲吗，具体到记忆、Skill这些模块，你们是怎么设计的？
Jensen：拆到四个模块来说。
记忆模块不是一个向量数据库加检索这么简单，要分层：工作记忆只活在当前会话里，管这一轮在聊什么，用完即弃；情景记忆按时间线记录交互过程，是发生过什么的流水账，天然带时间衰减权重；语义记忆是从情景记忆里提炼出来的结构化知识和用户画像，是"我理解你是谁"的沉淀层。写入策略上也要取舍，不是每一轮对话都值得沉淀成长期记忆，需要一个重要性打分机制过滤闲聊噪音；遗忘也不能简单粗暴地设过期删除，更合理的是老记忆做压缩摘要而不是直接丢弃。容器之间的记忆天然隔离，但检索算法、压缩算法、打分模型都跑在共享引擎上，不需要每个容器重新造一遍。
Skill模块是容器真正产生生产力的地方，也最容易被低估复杂度。核心不是接一堆API，而是把每个Skill定义成规范的Schema：输入输出结构、需要哪些权限、是否幂等、失败了怎么重试、大致成本和延迟是多少。有了这份Schema，Skill才能被容器动态挂载、被编排层安全调用。往上一层是Skill编排，多个Skill协作时用DAG或状态机显式描述执行顺序，而不是完全依赖模型临场去猜。再往下是执行沙箱，每次调用都在隔离环境里跑，避免一个场景出问题污染到其他容器。最后是反馈闭环，每次调用的成功率、耗时、成本都要被记录下来，反哺路由策略，效果差的Skill甚至可以自动降级。
编排调度层是容器的大脑，负责把模糊的用户意图拆解成具体执行步骤。设计难点在边界感，不能退化成只会顺序执行的脚本，也不能完全交给模型自由发挥导致不可控，我们的做法是给关键路径定规则、给长尾路径留推理空间。
数据接入层最不性感，但往往决定场景能不能真正跑起来，要解决业务系统数据能不能实时同步、权限能不能收敛到"这个容器只能看这个场景该看的数据"、多个数据源字段和语义能不能对齐。这层做得扎实，上层的记忆和Skill才有干净可信的数据可用；这层做得糙，上面堆得再花哨也是空中楼阁。
Q：那你们为什么没有直接去做最"正统"的强生产力场景，比如企业办公、CRM这些，而是选了预测和陪伴？
Jensen：这个问题我们内部认真算过账。
强生产力场景看着最容易讲清楚ROI的故事，但也是竞争最惨烈、护城河最浅的战场。问题不在模型能力，而是这类场景的价值高度依附在别人的系统和数据之上------CRM、ERP、OA，原生厂商天然掌握着数据和入口的先发优势。一旦这些厂商把Agent能力内嵌进自己的产品，第三方Agent OS很容易被降维打击成一层可有可无的壳，能力再强也绕不开入口不在自己手里这个结构性劣势。更现实的是商业化路径，强生产力场景通常意味着标准的B端销售，决策链条长，POC周期动辄半年，很难规模化复制。这跟"经济下行、真正有红利的场景本就稀缺"的判断是一致的。
陪伴和预测恰好站在这条拥挤赛道的两端，不是取巧，是它们的价值来源不依赖抢别人的系统入口。陪伴场景的数据是自产自销的，每一轮对话本身就是数据，护城河靠时间和记忆的积累自然形成，不需要先打通任何第三方业务系统才能起步，门槛低，但复利效应很强，用得越久，记忆越厚，用户的替换成本就越高。预测场景的门槛则相反，不在入口，而在算法和数据处理的深度，只要能拿到一个相对封闭、边界清晰的数据集，就可以独立打磨模型、独立验证准确率，验证周期短，价值也更容易被单独衡量和定价。
简单说，强生产力场景比拼的是谁能先接入更多系统，这是巨头凭渠道就能赢的主场；陪伴和预测比拼的是谁的记忆更准、谁的预测更准，这是能靠技术积累打出差异化的战场。我们选后者，是判断这个阶段这两个场景更容易把Agent OS真正的核心能力------记忆的深度、数据编织的精度------跑出壁垒，而不是沦为随时可以被替换掉的中间件。
Q：具体到产品上，现在有哪些已经跑通的案例？
Jensen：目前有四个相对成熟的场景，正好能印证前面说的架构设计。
一个是玄学陪伴，人设是命理师，长期记忆锚定在用户的生辰八字、过往关注的人生议题上，让每次对话都能接上上一次的话头，而不是每次都从头起卦。这个场景对情感边界的设计要求特别高，陪伴很容易滑向过度承诺或者贩卖焦虑，话术层面必须有明确的克制原则。
一个是玄学测算，本质是"经验规则+概率"的预测，排盘、五行生克这些规则相对封闭、结构清晰，很适合沉淀成标准化的Skill计算引擎。这个场景在数据接入层上最简单，不需要打通任何第三方业务系统，核心数据就是用户自己填的信息加一套历史规则库，门槛低、闭环快，是我们验证预测能力的一个很干净的起点场景。
一个是足球赛事预测，数据接入层的挑战集中在实时性上，赛事进程、赔率变化、伤病动态都要接近实时同步进来，是对数据编织能力的直接考验。这个场景对可解释性要求也高，不能只给一个结论，要把近期状态、历史交锋、伤病情况这些关键变量作为支撑一起呈现，对Skill模块的编排能力要求更高。
一个是金融场景预测，容错率最低，模型每一次判断都要有可追溯的依据链条，权限和数据合规要求也最高，通常还要跟客户已有的风控、交易系统对接，是四个场景里对数据编织能力要求最高的，某种程度上已经带上了一部分强生产力场景的特征，这也说明预测和生产力之间不是非黑即白的分界线，而是一条连续的光谱。
Q：如果外部客户想接入Fortune Agent OS，具体怎么合作，能有多快落地？
Jensen：这四个场景能快速交付，靠的不是每次重新搭一套系统，而是"容器只做配置、引擎负责复用"这套架构真正在起作用。接入路径大致分三层，复杂度和交付周期依次递增。
最快的是SDK或API接入，客户不用碰底层架构，直接调用已经跑通的场景容器，比如玄学测算的排盘引擎、足球赛事的预测接口，嵌进自己已有的App或小程序里，接口层面做好身份和调用量对接就能上线，通常天级到周级就能交付。
中间是模板化定制，在共享引擎不变的前提下，客户可以换人设、换品牌视觉、调整记忆和技能的挂载范围，比如同一套陪伴引擎，换一套人设话术和知识库，就能从命理陪伴变成另一个垂直方向的陪伴产品，核心能力不用重新造，只是重新配置容器。
最深的是深度定制接入，面向有自己私有数据源的大客户，比如金融机构要接自己的风控系统、体育媒体要接自己独家的数据供应商，这条路径要走完整的数据接入层对接流程，牵涉权限收敛和合规审查，周期更长，但换来的是更贴合客户自身数据资产的预测精度。
这三层背后的共同逻辑是，因为记忆引擎、Skill执行引擎、权限引擎都是复用的，新客户接入的边际成本主要花在配置而不是重建上，这也是我们能把交付周期压缩到周级别而不是月级别的核心原因。
Q：最后聊聊未来，全民个人助理这个叙事算是失败了，Agent OS还有没有未来？
Jensen：我的判断是有，但方向要修正。
第一，人手一个通用助手的消费级叙事会持续降温，产业级、场景级的Agent OS会先一步跑出来，因为生产场景里有明确的ROI可以计算，消费场景的kill time需求，Agent的性价比打不过短视频。
第二，真正的瓶颈不在模型能力，而在数据编织层，模型的推理能力这两年已经跑得足够快，卡住大多数场景落地的，恰恰是数据孤岛怎么打通、权限怎么划分这些不性感的问题，谁先把这层脏活累活做扎实，谁就先吃到场景红利。
第三，真OS和场景容器这两条路线大概率会走向融合，真OS流派会向下兼容更多垂直定制能力，场景容器流派会向上沉淀出可复用的通用协议。
第四，技能会成为下一个生态位的争夺焦点，就像应用商店定义了移动互联网的下半场，谁能建立起一个开放、可信、可组合的技能市场，谁就掌握了Agent OS真正的话语权。
潮水退去之后，留在沙滩上的不会是那些曾经喊得最响的全民Agent，而是那些安静地扎进具体场景、把数据和技能一点点缝合起来的系统。这大概就是技术叙事的常态------ 热闹属于风口上的故事，价值属于愿意做脏活的人。