最近在梳理各种 AI Agent 框架和 Runtime 的架构时，我产生了一个越来越强烈的感觉：我们正在重新发明 Unix。
不是比喻。是字面意义上的重新发明。当你把今天主流的 Agent 架构摊开来看——Skill、Workspace、Tool、Pipeline、Orchestrator——你会发现，这些概念和 50 年前 Unix 的设计哲学几乎一一对应。区别只是换了一层 AI 的皮。
两条被反复验证的 Unix 原则
Unix 哲学有很多条目，但最核心的两条，几乎定义了整个操作系统的灵魂：
1. Make each program do one thing well.
Write programs that do one thing and do it well. Write programs to work together. — Doug McIlroy
2. Everything is a file.
在 Unix 中，普通文件是文件，目录是文件，设备是文件，管道是文件，套接字也是文件。一切通过统一的 open/read/write/close 接口操作。
这两条原则经过了 50 年的实战验证，支撑了从大型机到智能手机的几乎所有计算平台。它们之所以长盛不衰，是因为抓住了复杂系统设计的本质：通过简单的基元和统一的接口，实现无限的可组合性。
现在，让我们看看 AI Agent 的世界发生了什么。
Skill CLI ≈ Unix Command
在 AI Agent 架构中，“Skill”（技能）是一个核心概念——它定义了 Agent 能做什么。一个 Skill 通常封装了一个特定的能力：写博客、做代码审查、执行部署、分析数据。
这像什么？这就是 Unix command。
Unix Command AI Skill CLI
───────────────────── ─────────────────────
grep "pattern" file skill search --query "pattern"
wc -l file skill analyze --type wordcount
sort file | uniq skill deduplicate --input data
curl url | jq '.data' skill fetch --url url --extract data
核心特征完全一致：
- 单一职责：每个命令/技能只做一件事
- 标准接口：通过命令行参数输入，通过标准输出返回结果
- 可组合：多个命令/技能可以串联成复杂的工作流
- 自描述：
--help/SKILL.md就是使用说明
在之前的一篇文章中，我论证过 CLI 风格的工具在 LLM Tool Use 中可以达到 99% 的准确率，远高于复杂 JSON Schema 的 87%。现在回头看，这个结论背后的逻辑恰恰是 Unix 哲学——简单的、扁平的、单功能的工具，天然就更容易被正确调用，无论调用者是人类还是 AI。
Skill CLI 本质 = AI 时代的 Unix Command
这不只是类比。如果你去看今天真正好用的 Agent 工具设计，它们几乎无一例外地遵循了 Unix command 的设计模式：
# Unix 时代
ls -la /home/user/projects/
git commit -m "fix: resolve issue"
docker run -d -p 8080:80 nginx
# AI 时代
claude-code read /home/user/projects/
claude-code commit -m "fix: resolve issue"
openclaw deploy --service api --env staging
同样的模式，同样的哲学。一个命令，做好一件事，通过参数控制行为，通过组合实现复杂功能。
Unix 管道（pipe）的精髓在于：你不需要预先设计一个万能程序，只需要把一系列小工具用 | 连起来。AI Agent 的 Skill 编排本质上就是 AI 时代的管道——Agent 根据任务需求，自主选择和串联多个 Skill，每个 Skill 的输出成为下一个 Skill 的输入。
# Unix 管道
cat access.log | grep "500" | awk '{print $1}' | sort | uniq -c | sort -rn
# AI Agent 的 Skill 编排（概念等价）
read_log → filter_errors → extract_ips → aggregate → rank
区别在于，Unix 管道需要人类来编排，而 AI Agent 可以自主决定该调用哪些 Skill、以什么顺序调用。Agent 就是一个有智能的 shell。
Agent Workspace ≈ Unix Filesystem
Unix 的第二条核心原则是 “Everything is a file”。在上一篇文章中，我详细展开过这个类比。这里做一个更聚焦的对照：
Unix Filesystem Agent Workspace
───────────────────── ─────────────────────
/etc/ CLAUDE.md, 配置文件
系统配置 Agent 的行为配置
/home/user/ 项目源代码, 文档
用户数据 Agent 的工作数据
/var/log/ MEMORY.md, 执行日志
系统日志 Agent 的记忆和历史
/usr/bin/ skills/
可执行程序 Agent 的技能定义
/tmp/ .worktrees/, 临时文件
临时文件 Agent 的隔离工作空间
/proc/ Agent 状态, 任务进度
进程信息 Agent 运行时信息
文件系统不仅仅是"存放文件的地方"。在 Unix 中，文件系统是一切交互的统一接口。进程通过读写文件来通信（管道是文件），硬件通过设备文件来访问，网络通过套接字文件来连接。
Agent Workspace 扮演了完全相同的角色：Agent 通过读写 Workspace 中的文件来感知世界、产出结果、与其他 Agent 协作。CLAUDE.md 是 Agent 的 /etc/ 配置，MEMORY.md 是 Agent 的 /var/log/ 日志，skills/ 是 Agent 的 /usr/bin/ 程序目录。
这不是巧合，而是殊途同归。因为"通过统一接口操作一切"这个设计，在复杂系统中就是最优解。
完整的对照表
把这个类比展开，你会发现 Unix 系统和 AI Native 系统之间存在惊人的结构性对应：
Unix 系统 AI Native 系统
═══════════════════ ═══════════════════
Small tools Small skills
做好一件事的小工具 做好一件事的小技能
Loose coupling Shared workspace
通过管道和文件松耦合 通过工作空间和文件共享状态
Composable systems Composable agents
自由组合构建复杂功能 自由编排构建复杂工作流
Shell Agent Runtime
用户交互和脚本执行 理解意图和编排执行
Pipe (|) Skill chaining
数据流串联 技能串联
stdin/stdout Tool input/output
标准输入输出 工具参数和返回值
man pages Skill descriptions
手册页 技能描述文件
Shell script Agent prompt/plan
自动化脚本 Agent 的任务规划
Process Agent session
进程 Agent 会话
File permissions Agent permissions
文件权限控制 Agent 能力边界
Package manager Skill registry
软件包管理 技能注册与发现
Filesystem Workspace
文件系统 工作空间
每一行的映射都不是牵强附会，而是在解决同一类问题时，独立演化出的同一种解法。
今天的 Agent Runtime 本质上在重新发明 Unix
这个结论听起来可能有些刺耳，但越是深入分析各种 Agent 框架，越觉得这是一个不可回避的事实。
看看今天 Agent Runtime 在做的事情：
- 任务调度——Unix 的
cron和进程调度器 - 权限控制——Unix 的文件权限和用户组
- 进程隔离——Unix 的进程模型和 namespace
- 工具注册和发现——Unix 的
PATH和包管理器 - 状态持久化——Unix 的文件系统
- 进程间通信——Unix 的管道、信号、共享内存
- 日志和审计——Unix 的 syslog
每一个 Agent 框架都在重新实现这些能力，只不过换了名字：Task Scheduler 变成了 “Orchestrator”，File System 变成了 “Memory Store”，Process 变成了 “Agent Instance”，Pipe 变成了 “Tool Chain”。
甚至连设计上的演化路径都类似：
- 第一阶段：单体架构（一个大程序做所有事）→ 类比早期的单一 Agent 做所有任务
- 第二阶段：模块化（拆成小程序通过管道组合）→ 类比多个专业 Skill 通过编排组合
- 第三阶段：标准化接口（POSIX 标准）→ 类比 MCP、Tool Use 标准化协议
- 第四阶段：包管理生态（apt、npm）→ 类比 Skill 市场、工具注册中心
历史不会简单重复，但会押同样的韵。
为什么会这样？
这不是偶然。根本原因在于，Unix 哲学解决的问题——如何在复杂系统中管理工具、数据和执行——是一个永恒的问题。AI Agent 面对的挑战和 50 年前操作系统面对的挑战本质上是同构的：
- 如何让工具之间协作？→ 统一接口 + 松耦合
- 如何管理复杂的状态？→ 文件系统 + 版本控制
- 如何隔离不同任务？→ 进程模型 + 权限控制
- 如何让系统可扩展？→ 小工具 + 自由组合
当问题相同时，最优解也趋同。Unix 哲学之所以在 AI 时代回归，不是因为我们刻意模仿，而是因为它确实是这类问题的最佳解法。
那我们应该怎么做？
如果认同 “Agent Runtime 本质上是在重新发明 Unix” 这个判断，那接下来的行动方向就很清晰：
1. 不要重新发明轮子，站在巨人肩膀上
Unix 已经花了 50 年验证了这套哲学。与其从零设计一个全新的 Agent 运行时，不如直接复用 Unix/Linux 已有的基础设施：
- 用文件系统做状态管理，而不是发明一个新的 Memory Store
- 用 Git 做版本控制和协作，而不是发明一个新的 State Sync 机制
- 用 CLI 做工具接口，而不是发明一个新的 Tool Protocol
- 用进程模型做隔离，而不是发明一个新的 Sandbox
2. 设计 Skill 时遵循 Unix 命令的设计原则
✓ 做好一件事 ✗ 一个 Skill 包揽太多功能
✓ 接受标准输入，产出标准输出 ✗ 依赖复杂的全局状态
✓ 沉默是金（无事不报） ✗ 输出冗余信息
✓ 快速失败，明确报错 ✗ 吞掉错误静默失败
✓ 可以和其他工具组合 ✗ 只能独立运行
3. 把 Workspace 当操作系统来设计
你的 Workspace 结构就是你的"操作系统"。CLAUDE.md 是内核配置，skills/ 是程序目录，MEMORY.md 是系统日志，.claude/ 是系统配置目录。像设计操作系统的文件层级一样，认真设计你的 Workspace 结构。
结论
Unix 哲学的核心——小工具、松耦合、可组合——正在 AI Agent 架构中全面回归。
这不是复古，而是收敛。当 AI Agent 系统面对"如何组织工具、管理状态、编排执行"这些根本性问题时，它最终会收敛到和 Unix 相同的解法上。因为这些问题的最优解，50 年前就已经被找到了。
Small tools → Small skills Loose coupling → Shared workspace Composable systems → Composable agents
今天很多 Agent Runtime 都在从零开始搭建调度器、权限系统、工具注册中心、状态管理——本质上是在用新的语言重写 Unix。这不是不可以，但也许更聪明的做法是：承认 Unix 哲学的胜利，直接站在这个巨人的肩膀上。
AI 时代不需要重新发明操作系统。它需要的，是一个理解 Unix 哲学的 Agent。