论最小 Agent 计算机的形态
摘要：本文从经典计算机类比出发，提出「最小 Agent 计算机」由 Model、Loop、Sandbox、Persistent Storage、Permission Boundary 五个不可约元素构成，并给出约 200 行 Python 的最小实现示意。通过与 AgentOS 蓝图对比，帮助读者区分「计算机」与「操作系统」，避免在 harness 层过度工程化。
引言：当我们谈论 AgentOS 时，我们在谈论什么？
当前 Agent 架构正在向一种类操作系统的方向演化，从 K8s 类比出发，描绘了一个宏大的 AgentOS 蓝图------Profile Router、Swarm Scheduler、A2A Protocol、Memory Hierarchy、Sleep-time Compute------一整套分布式编排系统。
这幅蓝图令人兴奋，但也引出了一个更基础的问题：剥离掉所有优化层后，一个最小的 Agent 计算机到底是什么形态？ 就像理解 K8s 需要先理解单台 Linux 服务器一样，理解 AgentOS 也需要先定义「Agent 计算机」的最小形态。
本文论证：最小 Agent 计算机由五个不可约元素构成------Model、Loop、Sandbox、Persistent Storage、Permission Boundary。文章中描述的 AgentOS 不是最小 Agent 计算机本身，而是这台最小计算机之上的 K8s。
一、从经典计算机到 Agent 计算机
经典计算机的最小形态是冯·诺依曼架构：CPU + 内存 + 存储 + I/O + 指令周期。无论是树莓派还是超级计算机，它们的本质差异只是这些基本元素的规模和数量，而非种类。
Agent 计算机与经典计算机存在一个关键差异：它的 CPU 不是确定性的。LLM 作为计算核心，其行为是概率性的、非确定性的。这一特征带来了一系列架构后果------但并不改变「最小计算机」问题的分析方法。
我们的方法论是：逐一检验每一个候选组件，判断它是「最小构成」还是「优化层」。判断标准只有一个------去掉它之后，系统是否仍然是一台可用的 Agent 计算机。
二、五个不可约元素
元素一：Model（计算核心 = CPU）
Agent 计算机的第一个不可约元素是 Model------一个具备推理和工具调用能力的大语言模型。它对应经典计算机的 CPU，是整个系统的计算与决策核心。
Model 在 Agent 架构中的独特之处在于它同时承担了两个角色：执行引擎 和策略层。在经典计算机中，CPU 只负责执行指令，策略由操作系统提供；而在 Agent 计算机中，Model 既做推理（执行），又做规划和工具选择（策略）。随着模型能力增强，它正在持续吸收原本由 harness 层承担的路由、任务拆解、工具选择等职责------这正是原文所说的「Model 正在蚕食 Harness」。
最简实现：一个支持 function calling / tool use 的 LLM API 调用。
元素二：Agent Loop（执行循环 = 指令周期）
第二个不可约元素是 Agent Loop ------think → act → observe 的循环。它对应经典 CPU 的指令周期 fetch → decode → execute。
没有循环，Model 只是一个一次性的问答系统；有了循环，它才获得了自主性（autonomy）------能够根据环境反馈持续推进任务，直到完成或放弃。这是 Agent 与 Chatbot 的根本区别。
循环还包含一个隐含但至关重要的子能力：Context 管理。当对话历史增长到接近 context window 上限时，系统需要压缩上下文------保留结论，丢弃过程。这类似于 CPU 的缓存管理，是循环能够持续运行的前提。
最简实现：一个 while not done 循环 + tool dispatch + context compaction 逻辑。
元素三：Sandbox（执行环境 = RAM + I/O）
第三个不可约元素是 Sandbox------Agent 与外部世界交互的执行环境。它对应经典计算机的 RAM（临时状态）和 I/O 设备（环境接口）。
Agent 与环境交互的方式收敛为两种：终端（bash） 和 浏览器 。原文也指出："高级程序员操作电脑的方式其实朴实无华，就是终端和浏览器"。在最小形态下，一个 bash 终端就足以覆盖绝大多数操作------文件读写、代码执行、网络请求、系统管理。
最简实现：一个 subprocess 调用，在临时目录中执行 bash 命令。
元素四：Persistent Storage（持久存储 = 磁盘）
第四个不可约元素是 Persistent Storage。LLM 本质上是无状态的------一旦会话结束，所有上下文信息就会丢失。如果 Agent 今天做了一个调研，下周要基于结论继续工作，它必须有某种持久化存储超越单次会话的生命周期。
但这个持久存储不需要是复杂的向量数据库或知识图谱。一个持久化的文件目录 即可------如 Claude Code 的 CLAUDE.md 或 .claude/ 目录。Manus 用 todo.md 管理任务状态，用文件系统做中间结果的卸载存储，本质上也是文件系统即记忆。
原文描述了从 MemGPT 到 Zep 到 AFS 的复杂记忆层级，但这些都是 Persistent Storage 的精细化，而非最小构成。正如你不会说一台计算机的「最小形态」需要包含 Redis 或 PostgreSQL------一个磁盘分区就够了。
最简实现：一个 .agent/memory/ 目录 + JSON 文件。
元素五：Permission Boundary（权限边界 = Ring 0/Ring 3）
第五个不可约元素是 Permission Boundary------这是最容易被忽视、但论证起来最具穿透力的一个。
前四个元素（Model、Loop、Sandbox、Storage）对应的是 Agent 的能力维度 ------推理、行动、记忆。但 Agent 还有一个定义性特征：自主性（autonomy）。而自主性 + 真实世界副作用 = 必须有约束边界。
核心论证：没有约束边界的自主体不是工具，是隐患。Permission Boundary 不是「有了更好」的优化层，而是「没有就不成立」的架构要件。
物理世界的类比很有说服力：
| 类比 | 论证 |
|---|---|
| 汽车与刹车 | 没有刹车的汽车不是「简化版汽车」，是一颗子弹。刹车是汽车的架构组成部分，不是附加配件。 |
| 核电站与控制棒 | 没有控制棒的反应堆不是「最小核电站」，是一颗核弹。控制是能量系统的本质属性。 |
| CPU 与特权级 | 没有 ring 0/ring 3 分级的处理器不是「简化版 CPU」，是一个任何程序都能宕掉整个系统的灾难。特权分级是现代 CPU 架构的一部分。 |
| Agent 与权限边界 | 没有权限边界的 Agent 不是「最小 Agent 计算机」，是一个可以 rm -rf /、发任意邮件、部署恶意代码的自主体。 |
但最小的权限边界不等于完整的企业治理体系（RBAC + hooks + 审批流 + audit trail）。它只需要两个原语：
- Permission Boundary：一个白名单/黑名单配置，定义哪些操作允许、哪些禁止
- Confirmation Gate：对不可逆操作暂停执行，要求人工确认
这对应 CPU 的 ring 分级------不是完整的 SELinux，只是用户态与内核态的基本分离。对应汽车的刹车------不是 ABS + ESP + 自动紧急制动，只是一个基本的制动机构。
最简实现：一个 YAML 配置文件 + 一个 input("确认？[y/n]") 确认逻辑。
三、五元组的定义性质
完备性
五个元素覆盖了 Agent 的全部本质特征------推理、行动、记忆、安全。去掉任何一个元素，系统就不再是一台完整的 Agent 计算机：
- 没有 Model → 没有推理能力 → 不是 Agent
- 没有 Loop → 没有自主执行 → 只是一次性问答
- 没有 Sandbox → 无法与环境交互 → 只是推理引擎
- 没有 Persistent Storage → 无法跨会话积累 → 每次从零开始
- 没有 Permission Boundary → 无法安全赋予自主权 → 定时炸弹
最小性
每个元素都取其最简实现形式------API 调用、while 循环、subprocess、JSON 文件、白名单配置。不存在比这更简的构成，也不存在可以进一步合并的元素。
可扩展性
原文描述的所有高级能力，都是在这五个基本元素之上的扩展，而非新的基本元素：
| AgentOS 高级能力 | 五元组的扩展方向 |
|---|---|
| Swarm Scheduler | 多个 (Model + Loop) 实例的编排 |
| Memory Hierarchy / Sleep-time Compute | Persistent Storage 的精细化（向量库、知识图谱、异步整理） |
| Profile Router | Model 选择的优化（强模型决策 + 弱模型执行） |
| A2A Protocol | 多实例间通信的标准化 |
| RBAC / Hooks / Audit | Permission Boundary 的企业级扩展 |
四、与经典计算机的完整映射
| 经典计算机 | 最小 Agent 计算机 | 本质角色 | 最简实现 |
|---|---|---|---|
| CPU | Model | 计算与决策核心 | 一个支持 tool use 的 LLM API |
| 指令周期 | Agent Loop | 执行循环 | while not done: think → act → observe |
| RAM + I/O | Sandbox | 临时状态 + 环境交互 | 一个终端（bash），可选浏览器 |
| 磁盘 | Persistent Storage | 跨会话记忆 | 一个持久目录（如 .agent/） |
| Ring 0/Ring 3 | Permission Boundary | 行为约束与安全边界 | 白名单 + 确认闸门 |
五、代码验证：200 行 Python 的最小实现
为验证五元组的可实现性，我们用约 200 行有效 Python 代码构建了一台完整的最小 Agent 计算机。代码开源于 GitHub。
bash
.
├── agent.py # 主程序（~200 行有效代码）
│ ├── think() # ① Model：LLM API 调用
│ ├── agent_loop() # ② Loop：主执行循环
│ ├── Sandbox # ③ Sandbox：bash 执行器
│ ├── load/save_memory # ④ Storage：持久记忆
│ └── permission_check # ⑤ Boundary：权限检查
├── .agent/
│ ├── permissions.yaml # 权限配置
│ └── memory/ # 持久记忆目录
└── Thinking.md # 思考过程记录这个 200 行的实现与 Claude Code、Codex CLI 的核心逻辑是同构的------它们本质上做的是同一件事，只是工程化程度不同。
六、被排除在最小构成之外的能力
以下能力在实际生产中很重要，但它们属于优化层 而非最小构成。判断标准始终是：去掉它之后，系统是否仍然是一台可用的 Agent 计算机。
| 能力 | 为什么不是最小构成 | 何时需要引入 |
|---|---|---|
| Multi-agent / Swarm | 单 agent 在架构上完备，多 agent 是吞吐量优化 | 任务需要并行或专业分工时 |
| 异构模型调度 | 单模型虽昂贵但架构完备，异构是成本优化 | 生产环境需要控制成本时 |
| 向量数据库 / 知识图谱 | JSON 文件即可实现最小持久化 | 记忆量大、需要语义检索时 |
| RL 训练调度器 | 模型自身 CoT 已具备任务拆解能力 | 需要大规模优化调度策略时 |
| 完整 RBAC 体系 | 白名单 + 确认闸门覆盖核心安全场景 | 多用户、企业级部署时 |
七、结论与启示
最小 Agent 计算机 = Model + Loop + Sandbox + Persistent Storage + Permission Boundary
它的实体形态就是今天的 Claude Code / Codex CLI------一个在终端里运行的、带有确认机制的 agent loop。
这个结论对 AgentOS 建设者有三层启示：
第一，区分「计算机」和「操作系统」。 AgentOS 不是最小 Agent 计算机，而是这台最小计算机之上的 K8s------一个分布式编排系统。正如 K8s 的伟大不在于发明了新的计算原语，而在于把已有的计算原语编排到了新的规模。
第二，构建的核心挑战不在硬件层。 五元组的实现复杂度极低（约 200 行代码），真正的挑战在于「软件层」------prompt engineering、tool design、memory strategy------即如何在这台计算机上跑出好的应用。
第三，为删除而构建。 原文最后一章的洞察值得反复强调：harness 中的编排规则应该附带一个预设问题------「当模型能原生完成这件事时，这段代码是否可以直接删除？」如果答案是否定的，说明你在过度工程化。Harness 应随模型变简单，而非变复杂。