面向 AI Agent 的 Agentic OS：架构、Skill、可观测性与安全机制

传统操作系统默认的使用者是人。人登录服务器，阅读命令输出，判断下一步该执行什么命令；应用程序则以进程的形式运行在操作系统之上，调用文件、网络、CPU、内存等资源。

AI Agent（智能体）进入服务器之后，情况变了。

Agent 不只是执行一条固定命令，而是会根据目标不断规划、调用工具、观察结果、修正动作。它可能要部署服务、排查故障、修复漏洞、调整系统参数，也可能和其他 Agent 协同完成一条较长的任务链。传统 Linux 环境当然也能运行 Agent，但它并不是围绕 Agent 的工作方式设计的：Agent 要花大量 Token 去理解环境，部署链路长，运行过程难监控，自主执行还会带来越权、误删、泄露敏感信息等风险。

Agentic OS 是阿里云基于 Alibaba Cloud Linux 推出的面向 AI Agent 的操作系统。它的核心思路不是简单把大模型接口塞进系统，而是把 Agent 运行所需的几类能力下沉到操作系统层：

换句话说，Agentic OS 要解决的是“Agent 作为操作系统使用者”时出现的新问题。

Agent 负载和传统软件负载有什么不同

传统软件负载一般比较确定。一个 Web 服务启动之后，监听端口、读写配置、访问数据库，行为边界比较清楚。即使服务内部逻辑复杂，它调用系统资源的模式也相对稳定。

Agent 负载更像一个会持续决策的执行者。给它一个目标，比如“检查这台机器是否存在某个 CVE（Common Vulnerabilities and Exposures，通用漏洞披露编号）风险并给出修复建议”，它可能会经历这样的过程：

flowchart TD
    A[接收任务目标] --> B[识别系统版本和软件包]
    B --> C[查询漏洞影响范围]
    C --> D[判断当前环境是否命中]
    D --> E{是否需要修复}
    E -- 否 --> F[输出评估结果]
    E -- 是 --> G[生成修复计划]
    G --> H[执行升级或配置调整]
    H --> I[验证修复结果]
    I --> F

在传统环境中，Agent 需要反复查询系统信息、解释命令输出、把历史上下文带回大模型，再决定下一步。这里的每一次环境摸底、工具描述、执行历史，都会变成 Token 成本。Token 是大模型处理输入和输出的计量单位，数量越多，调用成本和响应延迟通常也越高。

Agentic OS 的一个重要目标，就是减少 Agent 在“理解操作系统环境”上浪费的上下文，让它把更多推理能力用在任务决策本身。

整体架构：让 Agent 像应用一样运行在受控环境里

Agentic OS 借鉴了传统操作系统的分层思想，但上层面向的不是普通应用，而是智能体工作负载。

Agentic OS 的分层关系可以通过架构图理解：

架构里的关键点是：Agent 不直接散乱地调用系统命令和云资源，而是通过统一的交互入口、运行时、Skill 和安全模块访问底层能力。这样做的好处是，系统可以在任务执行前做能力匹配和完整性校验，在执行过程中做隔离和行为管控，在执行后统计 Token、健康状态和异常行为。

抽象成调用链，可以理解为下面这个结构：

flowchart TB
    U[人类用户] --> C[Copilot Shell / cosh]
    A[AI Agent] --> C

    C --> S[Skill 层<br/>系统管理、部署、调优、安全运维]
    C --> R[Agent Runtime<br/>受控执行环境]

    S --> ASC[AgentSecCore<br/>签名校验、行为管控、隐私保护]
    R --> ASC

    R --> OS[Alibaba Cloud Linux]
    OS --> INFRA[云基础设施<br/>ECS、网络、存储等]

    R --> OBS[可观测能力<br/>Token、健康状态、行为数据]
    S --> OBS

这套结构里有四个核心组件。

Skill：把复杂运维动作封装成 Agent 能理解的能力

Agent 在 Linux 上执行任务时，最大的问题之一是“有推理能力，但不一定熟悉系统环境”。比如部署一个服务，Agent 可能要先判断发行版、包管理器、Python 或 Node.js 版本、端口占用、权限边界、服务管理方式，再决定后续动作。

如果每次任务都让 Agent 自己摸索，成本会很高。Agentic OS 采用的做法是把高频动作封装成原生 Skill（技能）。

Skill 可以理解为操作系统提供给 Agent 的标准化能力单元。它不是一段随意脚本，而是围绕 Agent 的过程化执行方式设计，把复杂的 Linux 运维、部署、调优、安全操作封装成更稳定的调用入口。

典型 Skill 可以覆盖这些方向：

有了 Skill 之后，Agent 不必每次都把大量命令说明、环境探测结果、执行历史塞进上下文，而是可以调用系统已经封装好的能力。

执行链路会从这种模式：

flowchart LR
    A[Agent] --> B[探测系统环境]
    B --> C[解释命令输出]
    C --> D[生成下一条命令]
    D --> E[继续探测]
    E --> F[完成任务]

变成更直接的模式：

flowchart LR
    A[Agent] --> B[识别任务意图]
    B --> C[匹配系统 Skill]
    C --> D[调用标准化能力]
    D --> E[返回结构化结果]

在系统管理和运维场景中，Agentic OS 相比传统操作系统环境可以降低明显的 Token 开销。以 OpenClaw 做操作系统漏洞看护修复为例，在 CVE 评估阶段，使用相同大模型底座时，Agentic OS 相比传统操作系统可节省约 60% Token。

这里节省的不是任务本身的推理，而是减少了大量“我现在在哪台机器上、系统是什么版本、应该用什么工具、命令输出是什么意思”这类上下文消耗。

Copilot Shell：人和 Agent 共用的系统入口

传统 shell 主要面向人类。bash 很强大，但它要求使用者知道命令、参数、管道、权限和系统路径。Agent 当然也可以操作 bash，但它需要把 shell 当作一个外部工具使用，并且不断解析输出。

Agentic OS 引入 Copilot Shell，简称 cosh。它承担两个角色：

这意味着 cosh 不只是一个命令行外壳，而是 Agentic OS 的交互控制面。人可以用更接近自然语言的方式描述目标，Agent 也可以通过它调用系统能力。

交互意图可以长这样，实际可用表达取决于运行环境支持的能力：

cosh> 部署 OpenClaw，并开启漏洞看护任务

cosh> 检查过去 24 小时各 Agent 的 Token 消耗

cosh> 评估当前系统是否受某个 CVE 影响，并生成修复计划

cosh 的价值在于把“使用系统资源”这件事从命令级操作提升到任务级操作。人不必手工拼接一串初始化命令，Agent 也不必为每个任务重新探索系统能力。

Token 可观测性：把 Agent 成本拆开看

传统可观测性主要关注 CPU、内存、磁盘、网络、日志、链路追踪等指标。Agent 运行之后，还需要看一个新的核心指标：Token。

如果多个 Agent 长时间运行，只知道总调用量是不够的。真正需要知道的是：

• 哪个 Agent 消耗最多 Token；
• Token 用在了输入还是输出；
• 输入里 system prompt、Skills 注册表、历史上下文分别占多少；
• 是否某个 Agent 因为异常循环导致 Token 激增；
• 是否某个任务的 Skill 描述过长，导致每次调用都携带过多上下文。

Agentic OS 内置系统级 Token 统计能力，可以按照 Agent 维度统计 Token 消耗，并分析 Token 的组成。

flowchart TD
    A[Agent 请求] --> B[输入 Token]
    A --> C[输出 Token]

    B --> B1[system prompt]
    B --> B2[Skills 注册表]
    B --> B3[History 历史上下文]
    B --> B4[任务输入]

    C --> C1[推理结果]
    C --> C2[工具调用计划]
    C --> C3[执行总结]

    B1 --> D[Token 分析]
    B2 --> D
    B3 --> D
    B4 --> D
    C1 --> D
    C2 --> D
    C3 --> D

Token 可观测性的意义不只是算费用。它可以帮助定位 Agent 运行效率问题。例如，一个 Agent 如果长期携带过长 History，成本会持续上升；一个 Skill 如果注册描述过于冗余，所有调用它的 Agent 都会付出额外 Token；一个 Agent 如果不断失败重试，Token 曲线也会出现异常。

对长期运行的“数字员工”来说，这类指标和 CPU、内存一样重要。

AgentSecCore：给自主执行加上安全边界

Agent 被赋予执行权限之后，安全问题会明显放大。传统脚本通常按固定逻辑运行，而 Agent 可能根据模型输出动态选择工具和命令。一旦提示词被注入、Skill 被篡改、权限边界设置过宽，风险就可能从“回答错误”升级为“系统被误操作”。

Agentic OS 使用 AgentSecCore 做系统级防护，主要覆盖四类风险。

1. Skill 签名与完整性校验

Skill 是 Agent 调用系统能力的入口，一旦 Skill 供应链被投毒，Agent 可能在不知情的情况下执行恶意逻辑。

AgentSecCore 对内置 Skills 做数字签名和哈希校验，在加载前确认 Skill 没有被篡改。这个机制类似软件包签名校验：只有通过完整性检查的能力，才应该进入 Agent 可调用范围。

sequenceDiagram
    participant A as Agent
    participant S as Skill 注册表
    participant C as AgentSecCore
    participant R as Runtime

    A->>S: 请求调用某个 Skill
    S->>C: 校验签名和哈希
    C-->>S: 返回校验结果
    alt 校验通过
        S->>R: 允许加载并执行
    else 校验失败
        S-->>A: 拒绝调用
    end

2. 运行时行为管控与沙箱隔离

Agent 的执行行为需要被限制在可控范围内。Agentic OS 使用 Bubblewrap 和 seccomp 等技术提供运行时隔离。

Bubblewrap 常用于创建轻量级沙箱环境，可以通过命名空间隔离文件系统、进程、网络等资源。seccomp 是 Linux 的系统调用过滤机制，可以限制进程能够调用哪些内核接口。

结合起来，系统可以对危险操作进行拦截，例如非法删除、越权访问、访问不该暴露的路径等。同时，每个 Agent 进程可以运行在独立的轻量级容器沙箱中，避免一个 Agent 的异常行为影响其他 Agent 或宿主机。

3. 宿主机隐私信息保护

Agent 在执行任务时可能通过多种方式接触宿主机信息，例如直接查询系统标识、读取配置文件、调用工具链、受到间接提示注入诱导后输出敏感信息。

Agentic OS 在系统层提供宿主机隐私标识保护，重点拦截敏感主机信息被获取和外传。这里防护的不是某一个命令，而是一类攻击向量：让 Agent 在看似正常的任务中泄露环境标识、主机信息或其他敏感数据。

4. 系统安全基线加固

Agent 运行得再安全，也需要宿主系统本身有基本安全水位。Agentic OS 通过 LoongShield seharden 工具做安全基线扫描与加固，检查操作系统配置是否符合安全要求，并对不安全项进行修复或提示。

安全链路可以概括为：

适合使用 Agentic OS 的场景

Agentic OS 主要面向“Agent 需要长期或高频操作系统资源”的场景。如果只是偶尔调用一次大模型问答，它的优势不明显；如果 Agent 要承担运维、部署、安全看护等任务，系统层能力会更有价值。

上手路径

Agentic OS 已在阿里云 ECS（Elastic Compute Service，弹性计算服务）控制台上架，也提供了 GitHub 仓库。实际使用时可以按这样的路径理解：

1. 在 ECS 环境中选择 Agentic OS 镜像，创建或准备运行实例。
2. 登录系统后，通过 Copilot Shell 使用系统内置 Agent 能力。
3. 根据任务部署 OpenClaw 等常见 AI Agent。
4. 为 Agent 分配合适的 Skill 和权限范围。
5. 观察 Token 消耗、执行行为和健康状态。
6. 对高风险任务开启更严格的沙箱、权限和安全基线策略。

相关地址：

GitHub:
https://github.com/alibaba/ANOLISA

阿里云 ECS 使用 Agentic OS 快速入门:
https://help.aliyun.com/zh/alinux/agentic-os-getting-started

使用时需要注意的坑

Agentic OS 把很多能力放到了系统层，但这不代表 Agent 可以无边界执行。几个问题尤其需要提前设计。

Skill 不能无限授权

Skill 越强，Agent 能做的事情越多，风险也越大。生产环境中应该按任务分配 Skill，而不是给所有 Agent 开放完整系统管理能力。

比较合理的做法是：

Token 异常通常意味着流程异常

Token 突然升高不一定只是模型变贵了，也可能说明 Agent 在重复失败、历史上下文过长、Skill 注册表过大，或者某个任务拆解方式不合理。Token 可观测性需要和日志、任务状态一起看。

沙箱不是万能保险

Bubblewrap、seccomp 和进程隔离能限制很多运行时风险，但如果 Agent 已经拿到了明文密钥，或者任务输入里包含敏感数据，沙箱并不能自动阻止所有泄露。密钥管理、最小权限、输出审计仍然必须保留。

自定义 Skill 要有版本和校验机制

一旦团队开始编写自己的 Skill，就要把它当成系统能力的一部分管理。签名、哈希、版本、变更记录、回滚策略都不能省。否则 Skill 层会从“降低复杂度”变成新的供应链风险点。

Agentic OS 的核心价值

Agentic OS 的意义在于把操作系统从“人操作软件的底座”推进到“Agent 执行任务的底座”。它围绕 Agent 运行方式做了几件具体的事：

• 用 Skill 减少环境探索和重复调教；
• 用 Copilot Shell 统一人和 Agent 的交互入口；
• 用 Token 可观测性管理 Agent 成本和异常行为；
• 用 AgentSecCore 给自主执行加安全边界；
• 用沙箱和基线加固控制多 Agent 运行风险。

当 Agent 从演示脚本走向长期在线的生产系统时，问题会从“能不能调用大模型”变成“能不能稳定、安全、低成本地执行任务”。Agentic OS 解决的正是后一个问题。