从 LLM OS 到 Agent OS

我突然想到的事

最近我反复看到一个说法：AI 会长出自己的操作系统，只是大家还没有想清楚，这个系统究竟长什么样。

我原本觉得这还是一个有点远的概念。直到看了 OpenAI、ElevenLabs 和 Flowith 最近推出的可视化流程编辑器，忽然感觉脚手架已经搭起来了。它们都在做同一件事：不再把模型藏在一个输入框后面，而是把任务拆成一段可以看见、可以调整、可以再次运行的流程。

今天早上，我又回头翻了翻自己以前写过的 Prompt，顺手问了 DeepSeek：一个好 Prompt 的标准是什么？“角色—任务—约束”，答案并不新鲜。真正让我停了一下的是后半句：把个性化的内容拆出来，让它可以被复用。

这个小小的提醒，突然把几件原本分开的事串到了一起。上下文的历史消息和缓存，是为了少重复计算；Agent 被设计出来，是为了把一类相似的工作反复做好；流程编辑器，则是在把一次性的指令变成可复用的工作单元。

于是我开始怀疑，Prompt 走向 Context，和 LLM OS 走向 Agent OS，也许本来就是同一条路上的两个说法。

模型变强以后，复杂度去了哪里？

回头看这几年，模型的工作方式其实已经变了几次：最初是续写和问答，后来有了成对的 QA，再后来模型开始调用工具、拆解任务、分多轮完成工作。推理模型把这条线又往前推了一步。

但模型变强，并不意味着系统可以把所有事情都交给模型。相反，复杂度只是换了地方。以前我们要为每一种任务写一套工具；现在可以用 Bash 处理一大类操作。以前一个大任务只能塞进一个上下文；现在可以用 Sub-agent 把它拆开。上下文太长了，就做自动压缩，牺牲一点细节来保住整个系统。

这不是把工程工作做少了，而是把工程工作推到了更高一层：我们开始设计模型应该在什么时候判断，系统应该在什么时候接管。

我想到一个很俗、但很准确的例子。外卖送到熟悉的小区，找到电梯几乎不需要思考；送到一条没去过的巷子口，地址可能只差一个拐弯，接下来就必须靠试错。前一种情况适合交给规则和流程，后一种情况才值得调用模型去理解现场。

如果把所有事都交给模型，系统会变得昂贵、缓慢，而且很难解释。把确定的部分固定下来，反而是给不确定性留下空间。

工程接住确定性，算法处理不确定性

我现在越来越相信，算法和工程不是谁取代谁的关系。它们更像在同一个任务里分工：一方负责那些还没有办法写成规则的判断，另一方负责把已经看清楚的部分做得稳定、便宜、可复用。

所以，“角色—任务—约束”并不只是 Prompt 写作技巧。它更像一个很小的系统设计：把一团非结构化的意图，切出几个可以调试的接口。

这也是我对 Agent OS 还算乐观的原因。它不一定要先拥有一个宏大的、统一的操作系统；它可以从很多个被写清楚的流程开始。流程越多，边界越清楚，模型才越有机会把力气用在真正困难的地方。

从“会说”到“能做”，靠的不是模型单打独斗

我不太愿意把 Agent 想象成一匹终于被驯服的野马。更准确的比喻可能是：我们给它铺了一条足够清楚的路，在路口设置护栏，也给它留下必要的岔路。

模型负责那些我们还说不清楚的部分：理解意图、判断现场、寻找方案、在失败后换一条路。工程负责那些已经知道应该怎样做的部分：权限、格式、缓存、重试、回滚、日志和验收。

如果一定要给最近的这点新发现留一句话，我会写成：
Agent OS 的起点，不是让 AI 做一切，而是知道什么应该交给 AI，什么不应该。