Agent OS：当企业拥有上千个智能体，谁来管理它们？（第7期）

TunerT_TQ

391人浏览 · 2026-09-01 00:00:00

TunerT_TQ · 2026-09-01 00:00:00 发布

Agent OS：当企业拥有上千个智能体，谁来管理它们？（第7期）

专栏：《大模型落地之道：智能体生态卷》
作者：Valhalla Matrix治理实验室
文章类型：原创技术实践与方法论总结
适用读者：技术负责人、架构师、AI 产品负责人、研发管理者
本文讨论一种面向多智能体系统的基础设施抽象：Agent Operating System，简称 Agent OS。
文中涉及的论文观点仅作为技术讨论背景，不代表本文对其结论进行了复现实验。
参考方向：

Towards an Agent Operating System: Lessons from Classical and Cloud OS，arXiv:2607.25076
Metis: Memory Foundation Model，arXiv:2607.26760
Memory Decoder at Scale: A Pretrained, Parametric Long-Term Memory，arXiv:2607.27919

一、问题不再是“模型够不够强”

过去讨论 AI 应用时，重点通常是：

模型参数规模；
推理速度；
上下文窗口；
工具调用能力；
单次任务成功率。

但当企业开始同时运行几十、几百甚至上千个智能体时，问题会发生变化。

系统需要回答的，不再只是：

这个智能体能不能完成任务？

而是：

它可以访问哪些数据？
它可以调用哪些工具？
它能运行多长时间？
它占用多少计算资源？
它失败后如何停止和恢复？
多个智能体之间如何共享信息？
哪些操作必须经过人工审批？
一个智能体失控后，如何避免影响整个系统？

这与早期计算机从“程序直接运行在裸机上”转向“由操作系统统一管理进程”非常相似。

操作系统解决的并不是某个程序的业务逻辑，而是为大量程序提供统一的基础能力：

资源抽象
进程调度
权限控制
隔离运行
生命周期管理
故障恢复

多智能体系统也正在遇到同一类问题。

当智能体从单个应用功能变成一种可大规模运行的计算单元时，系统需要一个类似操作系统的管理层。

二、什么是 Agent OS

Agent OS 不是一个更大的语言模型，也不只是一个任务编排器。

更准确地说，它是一层位于智能体应用和底层计算资源之间的基础设施，负责统一管理智能体的运行环境、状态、权限和资源。

可以将它抽象为：

它至少需要处理五类核心职责。

Agent OS 职责	传统操作系统类比	对智能体系统的意义
资源抽象	文件、内存、设备	统一访问数据、模型和工具
调度	进程调度	管理优先级、并发度和资源配额
隔离	进程、容器、用户空间	限制故障和越权影响范围
生命周期	启动、暂停、终止	管理创建、恢复、取消和回收
权限控制	用户、组和系统调用权限	约束智能体可以执行的操作

这五项能力共同决定了一个多智能体系统能否从演示环境走向长期运行。

三、Agent 与传统进程有哪些相似之处

将 Agent 类比为进程，并不是说二者完全相同，而是因为它们都具有几个重要特征：

1. 都会消耗系统资源

一个智能体运行时可能消耗：

模型推理额度；
CPU 和 GPU；
内存；
文件系统空间；
网络带宽；
外部 API 配额；
数据库连接；
人工审批资源。

如果没有统一的资源管理，少数长时间运行或高频调用的智能体就可能占满系统资源。

2. 都需要明确的生命周期

一个完整的智能体生命周期可能包括：

创建
  -> 初始化配置
  -> 分配记忆空间
  -> 获取任务
  -> 调用模型和工具
  -> 暂停或恢复
  -> 完成任务
  -> 保存结果
  -> 终止与回收

如果系统只关注“启动智能体”，而忽略暂停、超时、取消和回收，就容易出现：

僵尸任务；
重复执行；
状态丢失；
资源泄漏；
失败任务不断重试。

3. 都需要隔离

智能体可能读取文件、运行命令、访问数据库或调用第三方服务。不同智能体之间如果共享完整权限，就会形成较大的风险面。

理想情况下，每个智能体都应该拥有明确的运行边界：

可访问的项目
可读取的数据
可调用的工具
可使用的网络
可消耗的额度
可修改的资源

隔离并不一定意味着每个智能体都要启动一台虚拟机。根据风险和性能要求，可以采用不同层级：

隔离层级	适用场景
逻辑隔离	低风险、只读任务
进程隔离	普通本地工具调用
容器隔离	需要执行代码或访问独立环境
沙箱隔离	处理不可信输入或高风险命令
独立运行环境	高敏感、高权限或强合规场景

四、记忆为什么像 Agent OS 的存储层

对传统程序来说，文件系统和数据库用于保存状态；对智能体来说，记忆承担着类似作用。

但智能体记忆并不只是“把聊天记录保存下来”。它至少包括：

用户偏好；
任务历史；
项目上下文；
工具使用记录；
已确认的事实；
中间推理结果；
失败经验；
跨会话的工作状态。

如果所有内容都塞进当前上下文，系统会面临几个问题：

上下文窗口有限；
历史信息难以检索；
不同任务之间容易相互污染；
敏感记忆难以进行权限控制；
信息生命周期无法管理。

因此，Agent OS 中的记忆层更像一个经过治理的状态系统：

记忆层需要解决的四个问题

持久化

记忆应当跨越单次会话存在，但不是所有内容都永久保存。

可检索

系统需要根据任务、用户、项目和时间范围查找相关信息，而不是简单地线性加载全部历史。

可治理

记忆应当具备：

所属主体；
访问权限；
来源信息；
创建时间；
过期时间；
删除机制；
修改记录。

可解释

当智能体依据某条记忆作出决策时，系统最好能够回答：

这条信息来自哪里？
什么时候写入？
谁可以修改？
是否经过人工确认？
当前是否仍然有效？

因此，“记忆越多越好”并不是正确目标。更重要的是记忆的准确性、相关性、来源和可控性。

五、一个具体场景：1000 个智能体同时运行

假设企业部署了一个包含 1000 个智能体的任务系统：

一部分负责代码分析；
一部分负责客户支持；
一部分负责数据处理；
一部分负责监控和告警；
一部分负责自动生成报告。

如果没有统一的基础设施，系统可能出现以下情况：

场景	缺少统一管理	有 Agent OS 管理层
资源使用	各任务相互争抢	按优先级和配额调度
文件访问	权限边界模糊	按项目和任务隔离
工具调用	每个智能体自行配置	统一注册和授权
失败处理	任务可能持续重试	超时、取消并自动回收
记忆共享	上下文互相污染	按主体和权限检索
故障影响	单点故障可能扩散	失败域隔离
审计追踪	难以还原行为	记录任务、工具和权限事件

一个成熟的调度器至少要考虑：

任务优先级
资源配额
并发上限
超时策略
重试次数
依赖关系
人工审批
故障隔离

调度目标也不能只有“尽快完成”。在企业环境中，还需要同时考虑：

成本；
延迟；
可靠性；
权限；
数据敏感等级；
业务优先级；
合规要求。

六、权限：不要只给 Agent 一个“能或不能”

传统权限模型经常是二元判断：

允许
拒绝

但智能体执行任务时，权限通常需要更加细致。

例如，以下几种操作的风险并不相同：

读取公开文档
读取内部代码
修改测试文件
修改生产配置
发送外部邮件
删除数据库记录

可以采用分层能力模型：

能力层	典型操作	默认策略
L1	读取文件、查询资料	可自动执行
L2	修改非关键文件、生成补丁	受限执行并保留回滚
L3	调用外部服务、发送消息	明确授权后执行
L4	修改生产状态、删除数据	强制审批并完整审计

这里的关键不是简单地给 Agent 打一个“可信”标签，而是将权限绑定到具体操作：

谁发起
执行什么操作
操作作用于什么资源
使用什么凭据
风险等级是多少
是否需要审批
结果如何记录

即使是长期运行、历史表现良好的智能体，也不应因为“信任度较高”而绕过高风险操作的审计与审批。

七、Agent OS 的控制闭环

一个可持续运行的系统不能只负责执行，还要持续观察执行结果并调整策略。

可以将这个过程表示为：

每个环节都需要有明确输入和输出。

Monitor：观察什么

任务成功率；
工具调用次数；
权限拒绝次数；
异常和超时；
资源消耗；
数据访问范围；
人工干预次数；
重试与回滚情况。

Analyze：如何分析

不能只看“任务是否完成”，还要看：

是否通过不安全方式完成；
是否访问了不必要的数据；
是否频繁触发权限边界；
是否产生高成本调用；
是否出现异常重试；
是否与历史行为明显偏离。

Plan：调整什么

降低或提高资源配额；
收紧工具权限；
增加人工审批；
暂停某类任务；
更新检索范围；
调整重试和超时策略。

Execute：如何落地

将策略应用到下一次任务；
记录策略变更原因；
保留原有审计信息；
支持撤销错误调整；
避免调整逻辑本身失去监督。

八、三个容易踩中的误区

误区一：把 Agent OS 做成一个超大的总控服务

如果所有功能都集中在一个服务中，短期看起来便于管理，长期可能导致：

权限边界混乱；
单点故障；
部署和升级困难；
不同团队无法独立演进；
任何变更都影响全局。

更合理的方式是明确划分：

调度层
策略层
执行层
记忆层
协议层
审计层

模块可以独立演进，但通过稳定的接口和事件协议协作。

误区二：把记忆等同于向量数据库

向量检索只是记忆系统的一种实现方式，并不能解决全部问题。

一个可用的记忆系统还需要考虑：

原始来源；
文档版本；
时间有效性；
冲突信息；
访问权限；
删除请求；
事实确认；
召回结果排序。

“能检索出来”不代表“应该被使用”。

误区三：把成功率当成唯一评价指标

如果只奖励任务完成率，智能体可能倾向于：

选择风险更高的捷径；
跳过必要审批；
忽略数据权限；
反复尝试高成本操作；
隐藏失败原因。

更完整的评价体系应同时关注：

任务结果
安全性
可解释性
成本
延迟
资源使用
权限合规
人工干预次数

九、从工程角度如何开始建设

不建议一开始就建设完整的“智能体操作系统”。更现实的路径是从最小可用闭环开始。

第一阶段：统一任务和工具协议

先统一以下对象：

Agent
Task
Tool
Resource
Permission
Memory
AuditEvent

每个对象都需要有明确的标识、状态和生命周期。

第二阶段：建立执行边界

为每个任务定义：

工作目录；
可访问资源；
可调用工具；
最大运行时间；
最大资源额度；
是否允许网络；
是否需要人工审批。

第三阶段：补充审计和恢复

至少记录：

谁创建了任务；
使用了哪个模型；
调用了哪些工具；
修改了哪些文件；
使用了哪些凭据；
任务何时开始、结束或失败；
是否发生重试、回滚和人工接管。

第四阶段：再建设统一记忆层

记忆层应先解决正确性和权限问题，再追求复杂的检索和学习能力。

建议从以下字段开始：

memory_id
owner
source
content
created_at
updated_at
expires_at
sensitivity
access_policy
verification_status

第五阶段：引入策略自动调整

当系统积累足够的运行事件后，再考虑根据数据调整：

任务优先级；
工具权限；
资源配额；
审批阈值；
检索范围；
自动恢复策略。

自动调整必须保留人工覆盖和回滚机制。

十、如何判断一个 Agent OS 是否成熟

可以从以下四个问题开始评估：

1. 资源是否可管理

系统是否知道每个智能体消耗了多少模型、计算、存储和外部服务资源？

2. 权限是否可解释

系统是否能够说明某次操作为什么被允许，使用了哪条策略？

3. 状态是否可恢复

任务中断后，能否从明确的检查点继续，而不是从头开始或重复执行？

4. 故障是否可隔离

一个智能体出现异常时，系统能否限制其影响范围，并保证其他任务继续运行？

如果这四个问题无法回答，即使单个智能体表现良好，整个多智能体系统仍然可能不具备稳定运行能力。

十一、结语

Agent OS 的核心价值，不是把智能体变得更聪明，而是让大量智能体能够被可靠地运行、观察、限制和恢复。

它需要从传统操作系统和云基础设施中吸收已经验证的工程思想：

资源抽象
统一调度
权限控制
运行隔离
状态管理
故障恢复
行为审计

与此同时，智能体又带来了新的挑战：

行为具有概率性；
工具调用路径动态变化；
记忆会影响后续决策；
任务目标可能存在歧义；
模型输出不等于安全计划；
成功结果不一定代表过程合规。

因此，未来的智能体基础设施不会只是“模型调用平台”，也不会只是“工作流编排器”。它更可能是一套围绕任务、资源、权限、记忆和审计建立的系统级运行环境。

单个智能体解决的是一个任务；Agent OS 解决的是一群智能体如何长期共存。

参考资料

Towards an Agent Operating System: Lessons from Classical and Cloud OS，arXiv:2607.25076
Metis: Memory Foundation Model，arXiv:2607.26760
Memory Decoder at Scale: A Pretrained, Parametric Long-Term Memory，arXiv:2607.27919