从Prompt到Agent OS：看懂AI Agent架构的完整演进路线- 惊觉

文章目录

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/qq_34419312

前言

最近观察AI Agent圈有个特别有意思的规律：不管你一开始走什么路线，个人助手也好，CLI工具也好，开源社区项目也罢，做着做着，架构就往同一个方向跑。

不是谁抄谁，是复杂度到了那个份上，你没得选。

1 先戳破一个误区：Agent的核心根本不是Prompt

很多人到现在还觉得，Agent好不好用，全看Prompt写得妙不妙。

还有一派说，堆工具就完事了，工具调用接口越多，Agent越智能。

更有甚者说，只要模型够强，一切都不是问题，换个大参数模型直接起飞。

我就这么说吧：你觉得你电脑好用，是因为你会写机器语言吗？是因为有操作系统给你管着进程、内存、权限啊兄弟。

过去一年多的发展已经很说明问题了：真正决定下一代Agent上限的，既不是Prompt，也不是工具数量，更不是模型参数——是Runtime。

1.1 三个八竿子打不着的项目，居然长一副模样

就拿三个完全独立的项目说事儿：

OpenClaw，2024年就出来了，Python写的，主打个人助手
OpenAI的Codex，2025年4月开源，Rust写的，商业化CLI工具
NousResearch的Hermes，2025年7月出来，Python写的，开源社区向

语言不同，定位不同，目标用户天差地别，连上线时间都差了一年多。

结果呢？Skill系统、Plugin系统、Runtime生命周期管理、Subagent、调用分析、权限信任、工作流……这些组件，三家一个不落，全做了。

这就好比三个厨师，一个做川菜，一个做粤菜，一个做法餐，最后各自研究出来的后厨流程，居然一模一样。

不是约好的，是做饭这件事本身，就要求你有洗菜台、切菜板、灶台、冰箱，缺一样你都干不利索。

当Agent的复杂度突破某个临界点，它就一定会往操作系统的方向演化。这不是设计出来的，是被复杂度逼出来的。

2 Agent演化的五个时代，跟软件工程史一模一样

回头看这三年，Agent的架构演进，简直就是把软件工程几十年的路重新走了一遍。

我给大家捋捋：

2023年，Prompt时代：一个超长Prompt解决所有问题。主打一个“写好系统提示词就够了”，对应机器语言阶段，直接写指令，能用但维护起来想死
2024年，Tool时代：模型学会调用外部能力，Function Calling横空出世。对应函数阶段，能力被封装起来，可以复用了
2025年，Skill时代：能力开始模块化封装，SKILL.md成了行业约定。对应库（Library）阶段，有文档有依赖，能打包分享
2026年，Runtime时代：能力开始有生命周期管理，Skill从静态文件变成运行时对象。对应虚拟机/运行时阶段，可观测可统计可管控
未来，Agent OS时代：多个Agent协作运行，内存、工作流、调度、权限全套配齐。对应操作系统阶段，多进程协作，隔离调度

看见没？逻辑完全一致：复杂度增长→必须抽象→必须封装→必须管生命周期→最后变成操作系统。

说穿了，Agent的Skill，本质上就是AI时代的函数库。理解了这个主线，后面所有演化你都能想明白。

3 Skill为什么是Agent世界的“函数库”

3.1 SKILL.md怎么就成了行业标准

2025年有个特别有意思的现象：几乎所有主流Agent框架，都不约而同用上了同一种文件格式——带frontmatter的Markdown，文件名就叫SKILL.md。

长这样：

---
name: github-code-review
description: Review PRs: diffs, inline comments via gh or REST.
---

## 适用场景
当用户需要 review Pull Request 时使用本 Skill。

## 工作流程
1. 读取 PR diff
2. 检查代码质量
3. 提交 inline comments

OpenClaw用，Codex用，Hermes也用。

为什么是它？很简单，人能读，机器能解析，能配套子目录放参考文档、脚本、资源，还能直接用Git做版本控制。

三家的目录结构都高度相似：主文件SKILL.md，旁边references放参考、scripts放脚本、assets放资源。

这就好比npm包一定有package.json，Python包一定有__init__.py。不是谁抄谁，是这个问题的解空间就这么大，最优解就这一个。

当能力需要被复用、被分享、被组合，它就一定会被封装成库。SKILL.md就是这个时代的包描述文件。

3.2 Skill一多，静态文件就扛不住了

但Skill这东西，数量一上来，问题马上就来。

我给大家算个账：

Skill少于10个：目录扫描就够用，翻两下就找到了
Skill到50个左右：你得整个缓存，不然每次加载都卡
Skill到200个：必须有聚合入口，不然用户根本记不住名字
Skill到1000个以上：没有Runtime管理，你根本玩不转

这就是为什么2026年开始，三家都在干同一件事：把Skill从静态的Markdown文件，变成有生命周期的运行时对象。

就像你手机里的APP，不能只是一堆安装包文件放在那，你得有运行、有后台、有统计、有卸载，对吧？

4 OpenClaw：第一个吃螃蟹的，但也第一个遇到瓶颈

4.1 它证明了Agent能当个人助手用

OpenClaw是2024年最早跑通的应用级Agent，架构很清晰：用户通过Telegram、Discord或者Web入口进来，到Agent核心，然后调用工具，再加载Skill，还有第三方插件做扩展。

它最大的贡献，就是第一个证明了“一个Agent真的能当日常用的个人助手”。用户入口做的好，生态扩展快，个人助手这个场景算是被它跑通了。

4.2 扁平架构的天花板，说来就来

但问题也来得快。当Skill从几十个涨到几百、几千个，这种扁平架构就顶不住了。

灵魂拷问来了：

谁调用了这个Skill？
为什么调用它？
权限边界在哪？
调用成本是多少？
版本怎么管理？依赖怎么处理？

这些问题，你换再强的大模型都解决不了。这是工程问题，得靠运行时管理系统来回答。

OpenClaw的SKILL.md本质还是静态文件，缺调用追踪、缺运行时统计、缺插件隔离、缺子Agent生命周期管理、缺项目级的信任边界。

不是它做的不好，是它正好处在“应用级Agent”向“运行时Agent”过渡的坎上。

打个比方：OpenClaw解决了“怎么造出一辆能跑的车”，而Codex和Hermes正在解决“怎么管理一万辆车的车队”。

5 Skill变Runtime，是必然中的必然

这章是核心。Skill从静态文件变成运行时对象，到底多了啥？咱们掰开揉碎说。

5.1 聚合入口：谁记得住几百个Skill名字啊

Skill超过几十个之后，用户不可能记住每一个名字。你总不能让用户每次用之前，先背一遍Skill列表吧？那也太反人类了。

于是三家都发明了“聚合入口”，就是把相关的Skill打成一个包，用一个命令触发。

Hermes的方案叫Skill Bundle，就是一个YAML配置文件：

name: backend-dev
description: Backend feature work — code review, testing, PR workflow.
skills:
  - github-code-review
  - test-driven-development
  - github-pr-workflow
instruction: |
  Focus on small, reviewable changes.

用户只要输入/backend-dev，系统自动把这一组Skill全加载好，注入到上下文里。

背后一整套东西：解析命令、读取配置、校验Skill是否存在、拼接提示词、缓存机制、冲突处理，全套配齐。

Codex那边叫Skill Root / Package / Alias，思路是一个插件根目录对应多个Skill资源，虽然组织形式不一样，但解决的是同一个问题。

说白了就是：Skill多了就得打包，打包就得有入口，入口就得有管理。这不是谁的巧思，是规模上来之后的必然结果。

任何Agent，只要Skill足够多，就一定会发明Bundle这种东西，无非是叫名字不一样罢了。

5.2 调用追踪：不统计你都不知道哪些Skill在吃干饭

Skill变成运行时对象之后，下一个问题马上就来：到底哪些Skill是真的有人用？

是用户主动选的，还是模型自己触发的？调用频率怎么样？哪个插件提供的Skill最受欢迎？

这些问题答不上来，你就没法优化Prompt，没法淘汰没用的Skill，也没法给插件方做归因分账。

于是Hermes做了Skill Metrics，把Skill的整个生命周期拆成：发现→预处理→注入→调用→统计，全链路追踪。

甚至连Skill里的变量替换、内嵌Shell执行、超时保护、输出长度限制，全给你管起来。

Codex那边做的是Invocation Analytics，还特意区分了显式调用和隐式调用，用HashSet去重，避免同一个Skill重复统计。

为什么要分显式隐式？混在一起统计数据就失真了啊。用户主动敲命令用的，和模型自己偷偷调用的，能是一回事吗？

当Skill开始被统计、被分析、被归因，它就不再是一段Prompt了，它变成了产品。

6 插件系统，异步化是唯一活路

6.1 同步插件就是定时炸弹

最简单的插件架构啥样？Agent执行到一半，调用插件，插件同步返回结果，Agent再继续。

听着没问题对吧？那我问你：插件崩溃了怎么办？超时了怎么办？死锁了怎么办？

答案是：整个Agent主流程直接被卡死。

一个坏插件拖垮整个会话，Skill少的时候还能忍，上百个插件的时候，你天天就等着救火吧。

这就好比你家电脑，一个软件崩溃了直接整机蓝屏，你受得了吗？操作系统之所以要做进程隔离，就是为了防这个。

6.2 两边都选了同一条路：旁路+隔离

所以Hermes和Codex又想到一块去了：插件必须异步化，做成旁路观察者，不能阻塞主流程。

Hermes搞了Stream Observer Hooks，给每个插件消费者分配独立队列，单独线程消费，队列满了就丢旧事件，插件出异常直接捕获打日志，绝不往上抛。

核心代码逻辑大概是这样：

@dataclass
class _ConsumerDispatcher:
    hook_name: str
    callback: Callable[..., Any]
    events: "queue.Queue[dict[str, Any] | object]"
    thread: threading.Thread | None = None

try:
dispatcher.callback(**payload)
except Exception as exc:
logger.warning(
"Hook '%s' callback %s raised: %s",
dispatcher.hook_name,
_callback_name(dispatcher.callback),
exc,
)

Codex那边也差不多，Async Command Hooks安排上，后面还接入了MCP工具的钩子能力。

说白了就一个原则：插件是第三方代码，不可信。必须隔离，必须异步，绝不能让第三方代码堵死主流程。

这不是Agent框架独有的创新，这是所有插件系统发展到一定规模后的工程常识。生态越大，越要讲隔离。

7 多Agent？单Agent根本扛不住复杂活

7.1 单Agent的五大致命短板

一个Agent再厉害，也没法单挑复杂任务。原因很朴素：

上下文窗口就那么大，复杂任务必须拆成子上下文
单线程执行，长任务直接把主会话堵死
没法并行，互不相关的子任务只能排队等
没有隔离，一个子任务出错，整体全崩
没有恢复机制，中途断了就只能重来

这跟操作系统从单进程进化到多进程，一模一样的逻辑。

单Agent就是光杆司令，啥都自己干。真要干大活，你得有团队，有分工，有上下级。

7.2 两边又撞了：状态机、生命周期、父子关系

Hermes直接公开了一整套Subagent生命周期API，状态机给你拆得明明白白：PENDING、STARTING、RUNNING、SUCCEEDED、FAILED、INTERRUPTED、CANCEL_REQUESTED、CANCELLED、UNKNOWN。

从启动请求、身份标识、父子会话关联，到取消、恢复、递归深度限制、能力范围控制，全套都有。

服务接口就这几个：launch() / status() / wait() / cancel() / result() / reconnect()，非常清晰。

Codex那边也有完整的MultiAgent工具集：spawn_agent创建子Agent，send_message发消息，followup_task派新任务，wait_agent等结果，interrupt_agent打断，resume_agent恢复，close_agent关闭。

人家文档里直接写了：子Agent还可以再生自己的子Agent，无限套娃（当然有深度限制）。

有意思的是，Codex的MultiAgent雏形其实比Hermes早，后来Hermes出了更完整的生命周期API，Codex又反过来强化历史记录、MCP、分析这些能力。

这就是典型的共同演化，你追我赶，最后都收敛到同一套状态机模型上。

为什么都要拆这么多状态？因为真实的任务不是“跑完/没跑完”这么二元。等父任务反馈、被用户中途取消、执行失败要恢复现场，这些都是家常便饭。

单一的运行/完成两态，根本装不下现实世界的复杂度。

8 未来Agent Runtime，还差哪几块拼图

如果Prompt→Skill→Runtime→Agent OS这条演化路径是对的，那接下来的竞争重点，绝不是堆更多工具，而是围绕能力管理、执行控制、安全治理、任务编排，建一套完整的Runtime。

目前来看，至少还有五个核心组件需要补齐。

8.1 Skill Registry：给能力做个应用商店

现在的Skill大多还是靠本地目录、Git仓库、插件包、项目内置这些方式分发。

Skill数量少还好，多了之后，版本管理、依赖解析、安全扫描、来源认证、升级回滚，这些都是问题。

未来一定会出现类似软件包管理器的东西，可能长这样：

agent install github-code-review
agent update code-analysis
agent remove security-check

让Skill从项目里的文件，变成可以独立管理、独立分发的能力资产。

8.2 执行编排器：当Agent多到管不过来

现在的多Agent，基本还停留在创建子Agent、发任务、等结果的阶段。

等Agent数量再涨涨，就需要更高层的管理了：任务拆分、优先级控制、资源限制、失败恢复、并行执行、状态追踪。

就像Kubernetes管容器一样，未来的执行编排器管的是智能任务。

用户丢一个大任务进来，规划Agent拆成子任务，编排器分配给不同的Agent去执行，中间出问题自动兜底。

8.3 权限系统：安全永远是头等大事

Agent能读文件、能执行Shell、能访问网络、能调企业系统、还能创建子Agent，权限不管住那还得了？

现在大家已经在探索Skill信任、插件权限、工具白名单、沙箱执行这些东西，但还不够细。

未来一定是细粒度权限模型：这个Skill只能读代码不能改文件，那个Skill只能跑测试不能访问网络，这个插件最多创建两层子Agent。

就像操作系统的权限体系一样，安全边界会越划越清。

8.4 记忆运行时：不是存聊天记录那么简单

很多人以为Memory就是保存聊天记录，太浅了。

现在已经有会话记忆、向量记忆、知识记忆、会话状态，但缺一个统一的记忆运行时。

什么时候存？存什么？什么时候检索？怎么更新？怎么遗忘？谁能访问？这些都是问题。

未来的Memory更像数据库系统，不光存，还要管生命周期、管权限、管冲突、管重要性排序。

Agent的长期能力，很大程度就看记忆管理做的好不好。

8.5 工作流引擎：动态规划才是灵魂

现在的多Agent还是线性的：创建→执行→等待→返回。

但真实的复杂业务，需要条件判断、并行执行、人工审批、失败重试、状态恢复。

未来的Agent工作流，和传统DAG工作流不一样。传统的是固定路径A→B→C，Agent工作流是先给目标，Agent自己规划路径，执行中根据结果动态调整。

相当于工作流引擎+规划器+反馈循环，三者合一。

9 最后说句掏心窝子的

过去的软件世界，从一行行机器代码，发展出了操作系统。

今天的AI世界，正在经历一模一样的过程。

Prompt只是Agent的汇编语言，Skill是它的函数库，Runtime是它的操作系统雏形。

当Agent的数量、能力、复杂度不断增长，最终拼的一定不是谁的Prompt写的花，谁的工具堆的多，而是谁能更高效、更安全地管理智能能力。

Agent框架不是被设计成操作系统的，是被复杂度一步步逼成操作系统的。

这一天，比很多人想的都要近。