智能体作为 Workload
智能体作为 Workload：从代码实体到可治理执行单元
提示
只有将智能体建模为可调度的 Workload，才能真正纳入云原生治理，实现安全、可观测与高效协作。
在 Agentic Runtime 体系中，“Agent 是什么”这个问题已经有了明确答案：
提示
Agent 是一种可调度、可治理、可审计的 Workload，而不是代码结构。
如果一个智能体（Agent）仍然只能以 class、SDK 实例或进程内对象的形式存在，那么它往往只能停留在 Demo 阶段，难以进入企业级生产环境。
为什么 Agent 必须是 Workload
Workload（工作负载）是云原生体系中最重要的抽象之一。它关注的核心并非“代码怎么写”，而是：
- 谁在运行
- 运行多久
- 消耗什么资源
- 如何被调度
- 如何被回收和治理
这些问题，正是 Agent 系统在实际落地时无法回避的关键挑战。
一个真实的智能体具备如下属性：
- 长生命周期：Session、Memory、Context 持续存在
- 非确定执行路径：推理循环与任务分解动态发生
- 多资源消耗：Token、KV Cache、GPU、IO、工具配额
- 强治理需求：权限、成本、安全、审计
- 可中断与可恢复：失败是常态，而非异常
这些属性共同指向一个结论：
提示
治理对象必须是“执行单元”，而不是代码本身。
因此，Agent 必须被建模为 Workload。
Workload 不是容器，而是执行语义
在云原生语境下，容器只是 Workload 的一种实现方式，而非定义本身。
在 Agentic Runtime 中，Workload 的本质是一段可治理的执行过程，它至少包含以下要素：
- 执行边界（Execution Boundary）
- 资源声明（Resource Contract）
- 生命周期（Lifecycle）
- 状态语义（Session / Task / Trace）
- 调度与回收策略
容器、Sandbox（受控执行域）、MicroVM（微型虚拟机）、Wasm（WebAssembly）等，都是承载这种语义的不同载体。
Agent Workload 的常见载体形态
不同的底层载体代表了不同的执行语义与治理能力。下表总结了主流载体的适用场景与特点。
内嵌表格
| 载体类型 | 适用场景 | 主要特点 |
|---|---|---|
| 容器（Container） | Agent Worker、Planner、MCP Tool Server | 生态成熟、可观测性完善、易于集成 Kubernetes，隔离强度有限 |
| Sandbox（受控执行域） | 浏览器自动化、代码执行、文件与系统操作 | 行为级权限控制、强隔离、可审计执行轨迹 |
| MicroVM（如 Firecracker） | 企业级高隔离、多租户、高风险工具链 | 虚拟机级隔离、启动速度快、安全边界清晰 |
| Wasm（WebAssembly） | 规则执行、轻量 Agent、内部 DSL Runtime | 无系统调用、高可移植性、极低启动成本 |
| 托管执行（Hosted Runtime） | 无需自建基础设施、轻量工具执行 | 执行语义不可控、治理能力受限 |
表 1: Agent Workload 常见载体形态与适用场景
在 Agentic Runtime 中，Sandbox 是执行域，而不是“工具容器”，强调行为级权限和可审计性。
RuntimeClass：用声明式方式选择执行语义
Kubernetes 体系通过 RuntimeClass 提供了一种声明式选择 Workload 执行环境的能力。
提示
通过声明而非代码，决定 Workload 的执行环境。
下表展示了典型 RuntimeClass 及其承载形式和适用场景：
内嵌表格
| RuntimeClass | 承载形式 | 适用场景 |
|---|---|---|
| runc | 标准容器 | 通用 Agent |
| gvisor | 沙箱容器 | 受控工具执行 |
| kata / firecracker | MicroVM | 高隔离企业场景 |
| wasm32-wasi | Wasm | 轻量规则与 DSL |
表 2: 常见 RuntimeClass 类型与适用场景
Agentic Runtime 可以根据任务类型、风险级别、资源需求，动态选择 RuntimeClass，而不是在代码中硬编码执行方式。
调度重点：Agent 的资源不是 CPU
与传统 Pod 调度不同，Agent 的核心调度资源并非 CPU，而是推理与工具相关资源。
下方列表总结了 Agentic Runtime 关注的主要资源类型：
- 推理资源：如 GPU、KV Cache、Batch Slot
- 工具资源：如 Sandbox、Tool Executor
- 状态资源：如 Session Memory、Execution Graph
- 协作资源：如多 Agent DAG 依赖
Kubernetes 主要负责节点与基础资源的分配、隔离与生命周期管理，而 Agentic Runtime 则聚焦于语义调度、推理与工具协同、状态推进。这构成了一个双层调度模型。
Agent 的 CRD：以资源定义语义
当 Agent 被建模为 Workload 后，其治理对象转变为资源对象。下表列举了典型的 Agentic Runtime CRD 及其作用：
内嵌表格
| CRD | 作用 |
|---|---|
| Agent | 能力、Prompt、工具、权限声明 |
| Session | 长生命周期上下文 |
| Task / Query | 一次执行请求 |
| Tool | 工具能力与沙箱绑定 |
| Eval | 审计、评测与审批 |
表 3: Agentic Runtime 典型 CRD 及其作用
通过 CRD，Agent 生命周期可控、权限可治理、执行可回放、成本可约束，智能体正式进入云原生治理体系。
Workload 是 Sandbox 与执行图的连接点
Workload 在智能体系统中起到结构性纽带作用：
- 执行图（Execution Graph）定义“要做什么”
- Sandbox 定义“在哪里做”
- Workload 定义“谁在做，以及如何被治理”
如果缺少 Workload 抽象，执行图无法被调度，Sandbox 难以统一治理，状态也无法绑定到具体执行实体。Workload 是三者之间的关键连接点。
总结
在 Agentic Runtime 体系下：
- 智能体必须以 Workload 形式存在，才能纳入云原生治理
- Workload 承载的是执行语义，而非代码本身
- 执行环境通过 RuntimeClass 声明，具备灵活性
- 调度以推理与工具资源为核心，区别于传统 CPU 调度
- CRD 是治理与扩展的基础，实现生命周期、权限、成本等多维度可控
Agent 从 class 走向 Workload，不是众多演进路径之一，而是当前实现规模化、可治理与企业级落地的必经之路。
这是智能体系统迈向大规模生产、可治理与企业级应用的前提条件。