AI操作系统
“你们现在还在做 RAG 吗？”
“还在做，但 RAG 已经不是我们现在思考的全部了。”
“那现在在做什么？”
“AI OS。”
“AI 操作系统？又是一个新概念？”
“其实不是。更准确地说，是做了两年 RAG、Agent、Graph RAG 以后，我们被真实企业场景一步一步逼到了这里。”
Graph RAG 深度解析：从向量检索到知识推理的技术演进
上一篇写 Graph RAG 的时候，我最后讲了一句话：
Graph RAG 不是终点。
当时我的理解，更多还停留在知识层面。
从向量检索，到多智能体，再到 Graph RAG，我们一直在解决一个问题：
怎么让 AI 更准确、更结构化地使用企业知识。
但继续往真实业务里走以后，我开始发现一个更大的问题。
企业真正需要的，好像已经不只是一个“回答更准确的 AI”了。
它还要知道：
什么数据可以看？
什么数据不能看？
当前任务里，哪些知识有效？
哪些信息虽然存在，但当前身份无权访问？
哪个模型可以使用？
哪些 Tool 可以调用？
一次任务最多允许消耗多少资源？
AI 的行为边界在哪里？
一次错误到底来自数据、知识、检索、Context、模型、Tool，还是执行流程？
更进一步：
如果 AI 不只是回答问题，而是开始真正影响企业业务，那么它有没有资格执行？
谁来授权？
什么操作必须审批？
出了问题谁负责？
能不能回放？
能不能审计？
能不能解释？
能不能恢复？
做到这里以后，我们越来越确定：
企业 AI 从 Demo 走向生产以后，瓶颈会逐渐从“Agent 是否足够聪明”，转向“这些智能能力能否在统一的数据、权限、运行时和治理体系下长期运行”。
我们把正在建设的这层基础设施，暂时称为：
AI OS。
它不是行业已经统一定义的一套标准。
而是我们对“企业 AI 长期运行基础设施”的一种理解。
一、回头看，这两年的路线其实非常清晰
最开始，我们做的是最传统的 RAG。
它解决的是：
怎么让大模型使用企业自己的知识。
简单来说就是：
企业文档
↓
检索
↓
上下文
↓
大模型
↓
回答
这个阶段最大的价值，是让大模型第一次真正进入企业私有知识体系。
但很快我们就发现：
简单问题可以。
复杂问题不行。
当一个任务涉及多个业务维度、多个知识点、多个步骤的时候，单一路径 RAG 很容易丢失关键关系。
于是我们开始做任务拆解、智能路由、多智能体协作。
这个阶段主要解决的是：
一个复杂任务应该怎么拆、怎么查、怎么协作。
但后来我们又发现一个问题。
Agent 再聪明，如果底层拿到的仍然是一堆关系不明确的文本碎片，它很多时候依然是在“拼信息”。
于是我们开始做 Graph RAG。
把过去主要面向：
文本块
的知识组织方式，逐渐扩展成：
实体
关系
事件
时间
证据
结构化知识
AI 不再只是寻找“语义上相关的内容”。
系统开始能够显式表示：
谁和谁存在关系。
某件事情发生在什么时间。
某个结论依赖哪些证据。
一个业务事实和哪些实体相关。
一个问题可能需要沿着哪些关系继续检索。
需要特别说明的是：
Graph RAG 并不天然等于因果推理，也不意味着 AI 自动“理解了世界”。
它真正提供的，是一种更结构化的知识组织和检索基础，让跨文档、多跳关系、全局结构类问题更容易被系统处理。
再继续往复杂产业场景走，我们又遇到了 Hypergraph、Event、Time、Evidence。
因为现实世界很多关系，本来就不是简单的：
A → B
而更接近：
A + B + C + 条件 + 时间
↓
某个结果
到这里的时候，我原本以为：
“我们应该已经走得很深了。”
但后来才发现：
这仍然主要解决的是 AI 怎么获得、组织和使用知识。
接下来还有一个更难的问题：
AI 获得了知识和能力以后，系统应该允许它做什么？
二、RAG 给了 AI“书”，Agent 给了 AI“手和脚”，缺一套运行秩序
我现在经常用一句话概括这几个阶段：
RAG 给 AI 书。
Agent 给 AI 手和脚。
Graph 给 AI 一张更结构化的世界地图。
但如果没有一套系统告诉它：
哪里能去。
哪里不能去。
什么可以看。
什么不能看。
什么可以调用。
什么操作可以自动执行。
什么操作必须审批。
什么时候必须停止。
出了问题以后怎么定位。
那么这个 AI 越强，风险反而可能越大。
这也是为什么我越来越不认同一种设计：
把所有能力都塞进一个“超级 Agent”。
给它知识库。
给它 Memory。
给它 Planner。
给它 Tool。
给它浏览器。
给它数据库。
再给它真实业务系统权限。
然后希望它自己决定：
查什么。
查多少。
什么时候停止。
该不该执行。
Demo 看起来会非常震撼。
但到了企业生产环境，这套逻辑很难让我真正放心。
因为企业需要的不是：
“AI 大部分时候应该不会乱来。”
而是：
“即使 AI 判断错了，它也不能突破系统给它划定的边界。”
这两个目标，本质上不是一回事。
前者依赖模型自己遵守规则。
后者依赖模型之外的系统真正执行规则。
我现在越来越认为：
Prompt 里的规则不等于边界。
真正的边界必须存在于运行时、权限系统和执行链路里。
三、所以我们开始重新定义：什么才是 AI OS？
做到这里以后，我们也越来越理解，为什么 Palantir 长期强调 Ontology，以及为什么它最终会把 Foundry、AIP 和 Apollo 描述成一套 Enterprise Operating System。
虽然我们的技术路径并不一样。
Palantir 更像是从 Enterprise Software、Data Platform 和 Ontology 一路走向 AI。
而我们更多是从 RAG、Agent、Graph RAG 和企业知识系统一路往生产环境里走。
但走到最后，大家遇到的问题开始越来越相似：
当 AI 真正进入业务以后，问题就不再只是模型够不够强、Agent 够不够聪明。
它会自然延伸到：
数据。
语义。
Context。
权限。
运行。
Action。
评测。
审计。
治理。
而这中间，有一个过去在很多 Agent Demo 里并不显眼、但进入生产以后越来越重要的层：
Agent Runtime。
如果说 Agent Framework 主要解决的是：
怎么定义一个 Agent，怎么给它模型、Tool、Memory 和 Workflow。
那么 Agent Runtime 解决的是：
一个 Agent 真正进入生产以后，任务到底怎么被执行、约束、暂停、恢复和追踪。
它需要处理的已经不只是一次模型调用。
而是：
任务状态怎么保存。
Context 怎么装配。
Tool 怎么调用。
权限什么时候校验。
失败以后怎么重试。
Worker 出问题以后怎么恢复。
长任务怎么做 Checkpoint。
重复消息怎么保证幂等。
Action 执行以前怎么经过 Policy。
高风险操作什么时候需要审批。
整个过程怎么留下 Trace。
所以我们现在越来越觉得：
Agent Framework 解决的是“怎么构建 Agent”。
Agent Runtime 解决的是“怎么让 Agent 可靠地运行”。
但如果再继续往企业里走一步，我们又会发现：
仅仅有 Agent Runtime 仍然不够。
因为企业还需要解决另外一组问题：
AI 使用什么事实？
企业世界怎么被定义？
不同 Agent 是否共享同一套业务语义？
模型和 Tool 怎么统一管理？
权限从哪里来？
Context 为什么能看到这些数据？
Evaluation 怎么判断结果是否可靠？
Action 怎么真正影响业务系统？
一次执行以后还能不能回放和审计？
所以我们现在对 AI OS 的理解，并不是：
再做一个更强的 Agent Framework。
也不只是：
做一个更复杂的 Agent Runtime。
我们更希望把它理解成：
一套承载企业 AI 长期运行的数据、知识、能力、执行和治理基础设施。
如果一定要拆开，我现在更愿意把它理解成三个平面。
1. Knowledge / Data Plane
负责：
AI 能够使用什么事实，以及企业世界是如何被描述的。
包括：
Data
Ontology
Relationship / Graph
Event
Time
Evidence
Memory
Provenance
也就是：
事实从哪里来。
企业里有哪些对象。
对象之间是什么关系。
什么事情在什么时候发生。
某个结论依赖什么证据。
哪些信息属于企业共享知识。
哪些信息属于局部工作记忆。
这里解决的，本质上是：
AI 到底在一个什么样的“企业世界”里工作。
2. Control Plane
负责：
谁可以在什么条件下使用什么能力。
包括：
Identity
Permission
Policy
Model Registry
Tool Registry
Skill Registry
Budget
Evaluation
Governance
也就是：
当前是谁。
他属于哪个业务空间。
拥有什么权限。
允许使用哪个模型。
允许调用哪些 Tool 和 Skill。
任务允许消耗多少资源。
什么结果算合格。
什么行为违反规则。
哪些 Action 必须经过审批。
这里解决的，本质上是：
AI 有什么资格做什么。
3. Execution Plane
负责：
AI 的任务真正怎么被执行。
包括：
Context
Agent / Workflow
Runtime
Sandbox
Checkpoint
Trace
Approval
Action
Recovery
也就是：
当前任务拿到什么 Context。
任务怎么拆解。
由哪个 Agent 或 Workflow 执行。
在哪个 Runtime 里运行。
Tool 怎么调用。
状态怎么保存。
失败以后怎么恢复。
过程怎么记录。
什么时候必须停下来等待审批。
最终怎么安全地改变真实业务状态。
这里解决的，本质上是：
AI 怎么在明确边界之内，把一个任务真正做完。
所以如果再翻译成人话：
Data：AI 使用什么事实。
Ontology：企业世界如何被定义。
Relationship：真实业务对象之间如何连接。
Context：当前任务实际允许 AI 使用哪些信息。
Model：由谁来完成推理。
Tool：AI 能调用什么外部能力。
Skill：知识、规则、工具和流程如何被组合成稳定能力。
Agent：谁以什么角色使用这些能力。
Evaluation：系统怎么判断结果是否达到要求。
Runtime：这些能力如何被可靠地执行、约束、恢复和追踪。
Action：AI 怎么在明确权限和规则下影响真实世界。
所以我们现在越来越不把 Agent 放在整个系统的中心。
Agent 很重要。
但 Agent 只是整个执行体系中的一层。
Agent Runtime 是 AI OS 最关键的执行基础设施之一。
但 AI OS 又不等于 Agent Runtime。
因为 Runtime 解决的是“怎么运行”。
而 AI OS 还必须回答：
它基于什么数据运行。
如何理解企业世界。
谁有权限运行。
可以调用什么能力。
运行结果怎么评测。
真实 Action 怎么治理。
出了问题以后怎么审计和追责。
所以如果一定要说 AI OS 真正的核心是什么，我现在反而更愿意说：
不是某一个 Agent，也不是某一个模型，而是一套受治理的运行秩序。
因为真正决定 AI 能不能进入企业生产环境的，并不是模型“愿不愿意遵守规则”。
而是：
即使模型判断错了，整个系统依然有能力保证它不能突破边界。
四、企业数据和知识，不应该锁死在某一个 Agent 里
这是我们现在非常坚持的一点。
未来一个企业可能会有：
客服 Agent。
研发 Agent。
采购 Agent。
生产 Agent。
质量 Agent。
管理 Agent。
如果每个 Agent 都重新维护自己的一套：
知识库。
数据。
Tool。
权限。
Prompt。
业务规则。
长期一定会形成新的信息孤岛。
以前的信息孤岛叫：
CRM。
ERP。
MES。
以后可能变成：
客服 Agent 的知识。
研发 Agent 的知识。
生产 Agent 的知识。
所以我们希望反过来：
企业事实属于平台。
共享知识属于平台。
模型能力属于平台。
Tool 属于平台。
Skill 属于平台。
Agent 只是根据角色、任务和权限，去组合这些能力。
这样以后换 Agent，不需要重新建设企业知识。
换模型，也不需要重新建设业务体系。
但这里也不能走向另一个极端。
不是说 Agent 完全不能拥有自己的 Memory。
Agent 可以有：
任务状态。
临时工作记忆。
局部会话摘要。
执行过程中产生的中间结果。
但这些内容和企业的 canonical knowledge 应该被明确区分。
简单来说：
企业共享事实，不应该被封装进某一个 Agent。
Agent 可以拥有受治理的局部状态。
我觉得这个边界非常重要。
五、Context 必须成为一种被管理的资源
这个观点，是我这段时间越来越看重的。
今天很多 Agent 的工作方式，本质上是：
“信息不够？那我再找一点。”
“还不够？继续搜索。”
“还不知道？再调一个 Tool。”
不断循环，直到 Agent 自己觉得信息够了。
这种方式在实验阶段没有问题。
但是到了企业系统里，它会带来非常现实的问题：
成本不可控。
延迟不可控。
权限范围不可控。
检索空间不可控。
最终甚至连：
“它为什么会得到这个答案？”
都很难完整还原。
所以我们开始把 Context 看成一种独立资源。
AI 不应该天然拥有无限上下文。
它应该拥有的是：
完成当前任务所需要的、经过授权的、有限的上下文空间。
这里有一个很重要的区别。
并不是说：
系统必须一次性把所有 Context 准备好，Agent 不能继续检索。
更合理的方式其实是：
系统先定义 Agent 能搜索什么、不能搜索什么、最多搜索多少、可以调用哪些数据源；Agent 再在这个授权空间内部动态获取 Context。
也就是说：
不是：
Agent 想看什么就看什么。
而是：
系统先决定 Agent “有资格看什么”，Agent 再决定当前任务“需要看什么”。
这样一来，Agent 仍然保留一定自主性。
但自主性发生在明确边界内部。
我觉得这是企业 Context Engineering 和普通 Prompt Engineering 很大的区别。
未来任何一次重要回答，我们都希望能够回答这些问题：
它当时看到了什么？
为什么能够看到这些？
哪些信息因为权限没有进入上下文？
哪些信息因为预算没有继续检索？
使用的是哪个版本的数据？
使用的是哪个知识版本？
当时用户拥有什么身份和权限？
最终模型真正拿到了哪些 Context？
这才是真正可审计的 AI。
六、模型应该可替换，但“可替换”不等于零成本替换
过去做 AI 项目，很容易围绕某一个模型设计整个系统。
模型接口这样写。
Prompt 按这个模型调。
Tool Calling 按这个模型适配。
结构化输出按它的格式做。
上下文也按照它的窗口设计。
结果模型一换，整个系统都要跟着变化。
但我越来越觉得：
企业真正长期值钱的东西，不应该是某一个模型。
模型当然非常重要。
但模型能力未来一定会持续变化。
真正属于企业自己的应该是：
数据。
Ontology。
业务语义。
权限体系。
业务流程。
Skill。
Evaluation。
历史运行结果。
业务经验。
这些才是应该长期沉淀的资产。
所以我们的目标一直是：
今天用 A 模型，未来可以换 B 模型。
今天使用云端模型，未来也可以切换到私有模型或本地模型。
模型变化，不应该导致整个业务体系被推倒重来。
当然，“模型可替换”不意味着：
所有模型可以完全无差别地一键切换。
不同模型在：
Tool Calling。
Structured Output。
上下文长度。
多模态能力。
推理方式。
延迟。
成本。
安全策略。
行为稳定性。
这些方面都可能不同。
所以真正要建立的是：
一层 Model Abstraction，加上一套持续 Evaluation。
模型可以被替换。
但替换以后，必须重新证明：
它仍然满足业务要求。
所以我更愿意把模型理解成：
AI OS 里的重要计算设备。
而不是 AI OS 本身。
七、Tool 和 Action 必须在治理层面被区别对待
这是我们进入真实业务场景以后，特别强调的一条边界。
比如 AI 可以：
查库存。
查设备状态。
查生产计划。
做模拟计算。
做数据分析。
这些能力的共同特点是：
主要在读取、计算和获取信息。
但如果 AI 要：
修改库存。
调整生产计划。
创建采购单。
改变设备状态。
写入 ERP。
发出真实指令。
它就开始改变业务状态。
严格来说，在很多 Agent Framework 里，这些操作依然可能被实现成 Tool。
所以这里真正需要区分的，并不是接口名字到底叫 Tool 还是 Action。
而是：
这个调用有没有副作用。
它是否会真正改变现实世界。
因此我们会把能力分成不同风险等级。
例如：
Read-only
↓
Simulation
↓
Reversible Write
↓
Business Write
↓
High-risk Action
AI 可以提出：
我建议执行这个操作。
但“提出”和“真正执行”之间，应该存在明确的治理边界。
要检查权限。
要经过 Policy。
要判断风险等级。
必要的时候需要 Human Approval。
要留下证据。
要知道是谁提出的。
为什么提出。
基于什么 Context。
使用了什么规则。
最终谁批准。
执行结果是什么。
当然，并不是所有写操作都需要人工审批。
低风险、权限明确、可回滚的业务操作，可以自动执行。
但高风险 Action 不能只依赖：
“模型应该知道这个操作很危险。”
因为一个回答错了，最多让用户不满意。
但一个真实 Action 错了，可能直接影响：
钱。
设备。
库存。
订单。
生产。
安全。
这不是一个风险等级。
八、AI 系统必须具备“故障归因能力”
这一点也是我这几年做 AI 系统特别深的感受。
AI 答错以后，最常见的一句话是：
模型不行。
但真正做过复杂企业 AI 的都知道：
很多时候根本不是模型的问题。
可能是：
数据本身错了。
知识结构有问题。
检索没找到。
权限过滤掉了关键数据。
Context 选择有问题。
Tool 调错了。
Skill 设计有问题。
业务规则已经变化。
运行过程中出现了失败。
模型只是整个链条中的其中一层。
如果系统没有 Evaluation，没有完整版本记录，没有 Runtime Trace，没有输入输出留痕，最后就会变成：
“感觉这次回答不好。”
然后换模型。
模型换完还是不好。
继续换 Prompt。
最后整个系统越来越不可解释。
所以我们希望以后任何一次失败，都能够尽可能回答：
问题最可能发生在哪一层？
然后再决定：
该补数据。
改 Ontology。
改检索。
改 Skill。
改 Context。
改 Policy。
还是换模型。
当然，在复杂系统里，失败不一定存在一个唯一根因。
它完全可能是一条链式故障：
检索结果偏差
↓
Context 发生变化
↓
Planner 选择错误路径
↓
Tool 调用异常
↓
最终回答失败
所以我们真正追求的不是：
系统百分之百知道“唯一根因”。
而是：
系统拥有足够完整的运行证据，可以把故障范围不断缩小。
我觉得这才是 AI 系统真正能够长期进化的基础。
九、为什么我现在不太追求“100 个 Agent 协同”的故事了
前几年大家特别喜欢比：
谁的 Agent 更多。
谁的 Workflow 更复杂。
谁能让 Agent 自己规划几十步。
谁能自动创建 Subagent。
谁能让一个任务自主跑几个小时。
这些技术当然有价值。
我们自己也做过多智能体，而且在复杂任务上确实有效。
但是做到今天，我反而越来越保守。
因为我发现：
能力越强，越需要边界。
一个可以调用三个 Tool 的 Agent，治理难度可能还不高。
一个可以不断创建 Subagent、自由扩大 Context、持续发现 Tool、并且长时间运行的 Agent，本质上已经是一个高度复杂的分布式软件系统。
它不再只是一个 Prompt。
里面会开始出现传统分布式系统早就面对的问题：
任务状态。
消息重复。
幂等。
并发。
超时。
重试。
恢复。
检查点。
资源竞争。
权限传播。
故障隔离。
审计。
所以我们现在的思路反而是：
先把底层秩序建立起来，再逐渐释放智能。
而不是反过来：
先让 Agent 什么都能做。
出了问题以后，再一层一层补安全。
十、AI OS 最终解决的，其实不是 AI 的“聪明问题”
很多人第一次听 AI OS，可能会觉得：
是不是又要做一个更强的 Agent Framework？
其实恰恰相反。
我们真正想解决的是：
怎么让 AI 在企业里长期运行。
它需要做到：
数据有来源。
知识有版本。
身份可验证。
权限有边界。
Context 可管理。
模型可以替换。
能力可以装配。
运行可以恢复。
行为可以追踪。
结果可以评测。
Action 可以治理。
高风险操作可以审批。
失败可以归因。
业务空间能够隔离。
历史过程可以回放。
新的行业能力可以持续扩展。
而不是：
做一个项目，就重新搭一套 AI。
如果这些东西能够真正建立起来，那么以后进入一个新的行业时，理想状态应该是：
接入数据
↓
定义业务世界
↓
建立权限与策略
↓
装配 Skill
↓
配置 Agent / Workflow
↓
评测
↓
上线
↓
持续观测与迭代
而不是：
重新开发一套系统
这才是我们现在理解的 AI OS 最大长期价值。
十一、这东西现在做到哪一步了？
先说结论：
还没有完成。
我也不想把一个正在建设中的东西包装成“已经成熟”。
现在我们更多是在一块一块验证那些：
真正决定它能不能进入生产的问题。
不是 Demo 能不能跑。
而是：
服务重启以后，任务还能不能继续。
Worker 出问题以后，状态能不能恢复。
没有权限，是不是真的一定拿不到数据。
伪造身份有没有用。
跨业务空间能不能被阻止。
Context 权限能不能真正下沉到数据访问层。
模型能不能在不重写业务逻辑的情况下替换。
替换模型以后，Evaluation 能不能验证能力有没有退化。
离线环境能不能运行。
重复消息会不会造成重复业务操作。
一个 Action 是否具备幂等机制。
一个高风险 Action 是否真的无法绕过审批。
执行以前的上下文和规则以后还能不能还原。
一个任务从输入、检索、模型、Tool 到 Action 的完整链路，以后还能不能追溯。
这些事情没有：
“AI 自动写代码。”
“Agent 自主完成十步任务。”
“100 个 Agent 自动协作。”
那么有传播性。
甚至很枯燥。
但我现在越来越相信：
真正决定企业 AI 能不能落地的，恰恰就是这些枯燥的东西。
十二、从 Graph RAG 到 AI OS，我最大的认知变化是什么？
以前我一直在想：
怎么让 AI 更聪明？
怎么让检索更准？
怎么让 Agent 更会规划？
怎么让模型推理更强？
现在我的关注点开始慢慢变化。
我越来越关心：
AI 能不能被管理。
更准确地说：
AI 的能力能不能被系统约束、记录、评测和治理。
因为当模型能力越来越强以后，“聪明”这件事情很可能会越来越普及。
今天需要工程团队特别优化的能力，明天模型原生可能就具备了。
但是：
企业的数据不会自动治理。
权限不会自动建立。
业务语义不会自动沉淀。
Context 不会自动变得可信。
错误不会自动归因。
责任不会自动划分。
生产系统也不会因为 AI 更聪明，就自动变得安全。
所以如果让我现在判断：
未来企业 AI 最重要的基础设施是什么？
我的答案可能已经不只是：
更大的模型。
也不是：
更多的 Agent。
而是：
一套能够承载 AI 长期运行的、受治理的 Runtime。
如果把它再扩大一点：
就是我们现在所说的——
AI OS。
写在最后
回头看这两年的路线：
向量 RAG
↓
任务拆解 / 多智能体
↓
Graph RAG
↓
Hypergraph / Event / Time / Evidence
↓
Context
↓
Runtime
↓
Evaluation
↓
Action
↓
AI OS
这不是行业统一的技术演进路线。
它更像是我们自己在真实项目里，一步一步踩出来的路径。
表面上看，是技术栈越来越复杂。
但底层逻辑其实一直没有变。
我们一直在减少一件事情：
让模型自己“猜”。
同时不断增加另外几件事情：
结构。
边界。
证据。
权限。
确定性。
可追溯。
可治理。
这和我之前做 Graph RAG 时的感受其实完全一致。
真正的企业 AI，不应该建立在：
“相信模型大部分时候是对的。”
这件事情上。
而应该建立在：
即使模型有可能错，整个系统依然知道它能看什么、能做什么、为什么这么做，以及出错以后怎么办。
如果有一天 AI 真正成为企业里的“数字员工”，甚至开始参与真实业务决策和执行，那么我们需要的就不只是一个聪明的大脑。
还需要：
规则。
权限。
身份。
记忆。
运行时。
审计。
评测。
责任边界。
以及一整套长期运行秩序。
而这，可能就是 AI OS 真正存在的意义。
这条路还很长。
但至少现在，我们越来越知道：
自己真正想做的，到底是什么。
编辑： LYDZA2025 \ 责任编辑: LYiAgent \ 审核: LYiAgent
声明：凡“灵怡Agent”原创稿件，转载或引用请注明来源！部分素材来自网络，版权归原作者所有，如有侵权，请联系我们！谢谢
