从 2012 年 AlexNet 让计算机能"看图"开始,到 2026 年的 Agent 框架之争——这条链路上, 每一步都是下一步的瓶颈。感知能力先到位,语言模型才有意义; 语言模型先规模化,推理能力才会出现;推理能力先够用,Agent 才能真去"做事"。 下面这份页面,从模型能力出发,最后衔接到上一节讨论的框架层 vs 应用层之争。
把 agent loop、prompt 组装、session、tool 注册全包进去的"大底座"。 灵活度最高,但用户必须自己组装一切,且每个厂都会做自己的。
长期碎片化Tool/能力注册、Skill/方法论、Agent 分发——这三层机会不同。 Tool 层已露头(SKILL.md、MCP),其它还在等。
分收敛、分继续散这六个阶段不是按"时间顺序"硬切,而是按"能力跃迁"划分——每一步都在解决上一步留下的核心瓶颈。 读到这里,你会发现后面要讲的 Agent 框架之争,本质上是"模型能力溢出之后,基础设施层跟不跟得上"的争议。
2012 年 AlexNet 在 ImageNet 上把图像识别错误率从 26% 砸到 16%——这一下让整个学界意识到, 深度神经网络在感知任务上,真的能赢。之后 CNN / RNN 各自统治了图像和语音两个领域, 2016 年前后,语音识别首次在标准测试集上超越人类转写员水平。
这个阶段的核心命题是"机器能不能识别像素和波形里的模式"。答案是能,而且越来越好。 但感知模型和语言模型还是两套独立体系——看图的不读字,读字的不看图。
2017 年 Google 发表《Attention Is All You Need》,提出 Transformer。 这一架构的核心优势是并行训练 + 长距离依赖,让"大规模预训练"第一次变得可行。 之后 BERT(2018,Google)和 GPT-2(2019,OpenAI)分别走通了两条路——BERT 走"理解"(encoder 双向), GPT 走"生成"(decoder 单向)。
这一阶段确立的范式叫"预训练 + 微调":先在海量无标注文本上训练一个基础模型, 再用小量下游数据微调成具体任务的模型。这个范式影响至今——所有大模型公司都在走这条路。
GPT-3(2020)有 1750 亿参数,在 few-shot 任务上展现出涌现行为——很多能力不是 显式训练出来的,而是规模到了之后自然出现的。这一发现改写了整个领域的研究方向: Scale is all you need——数据、参数、算力,堆到一定量,能力会自己冒出来。
但 GPT-3 本身还是不够"听话"。2022 年 InstructGPT 论文引入了RLHF(Reinforcement Learning from Human Feedback): 让人类标注员对模型输出打分,用打分训练一个奖励模型,再用强化学习把大模型往"高分方向"对齐。 ChatGPT(2022 年 11 月)就是这条路线的产物——它第一次让"AI 助理"成为大众产品。
2022 年 Google 团队发表 Chain-of-Thought(CoT)论文:让模型在回答前先把推理步骤写出来, 再给最终答案。这一招看似简单,但直接让数学题、逻辑题、常识推理的准确率大幅跃升。 后续又演化出 Tree-of-Thought、Self-Consistency、ReAct 等变体。
同时期出现了长上下文和多模态两条线—— Claude 把上下文推到 100K → 200K tokens,让模型能"读完一本书再回答"; GPT-4V、Gemini 让模型能同时处理图像和文字。 模型的能力边界在被反复推高。
2023 年起,OpenAI 在 API 里正式引入 function calling:模型不再只能吐文本, 还能吐出一个 JSON,描述"我想调哪个工具、传什么参数"。这一步把模型从"对话界面" 释放到了"执行界面"——它可以查数据库、调用 API、写文件、跑命令。
围绕工具调用,学术界和工业界演化出了一整套 Agent 模式: ReAct(推理+动作交替)、Plan-and-Execute(先规划再执行)、 Reflexion(执行完反思一下)、Multi-Agent(多个 agent 协作)。 模型本身没变太多,但被包装成了能"做事"的形态。
当模型已经能"看到、听懂、推理、用工具"之后,真正的瓶颈从能力转移到了基础设施: 工具怎么注册?session 怎么持久化?prompt 怎么组装?多 agent 怎么协作? 每个有野心的厂都做了自己的答案——这就是你正在看的这个页面要讨论的事。
到这一步,大模型这条主线已经从"做出更强的模型"转入"用模型做出更好的产品"。 后面几年的故事,大概率不再是"哪个模型更强",而是"哪个框架能活下来"和 "哪个应用层标准能被大家用出来"。
框架层做的事越多,灵活度越高,但用户门槛也越高。 这是一个物理意义上的"面积守恒":你能调的旋钮越多,意味着你必须知道每个旋钮在做什么。
DeepSeek Harness 把"agent loop 本身"做成可替换的插件——这是灵活度最高的形态。 但代价是:用户必须理解 Cordis 框架、必须知道怎么 mount / unmount、必须自己装配 SOUL/MEMORY/SKILL。
Hermes 反过来:它帮你装配好一切,代价是你只能"在它的框架里玩"。 改 prompt 组装?改 agent loop?——基本上做不到。
Hermes 的用户是想立刻有个 AI 助理的开发者;DeepSeek Harness 的用户是想搭"搭积木框架"的元开发者;OpenClaw 的用户是想接20 个聊天平台的产品人。 它们 不是同一类问题。
硬做一个统一框架,等于让所有用户削足适履——而用户不会容忍这种事,他们会 fork 你的代码然后改。
每个有野心的厂都会做自己的框架——这是技术品牌的一部分。 你做了 harness,我做了 hermes,他做了 openclaw——名字本身就是壁垒。
哪怕有人真定义出标准,也不会有人主动跟随,因为跟随意味着承认对方是"标准制定者"。
模型有 benchmark——谁跑分高谁好。框架没有。 你怎么证明"事件瀑布"比"函数调用循环"更好?在大多数场景下你证明不了,因为它们都能跑、都能跑出 demo。
没有 benchmark 就没有收敛。框架之争最后会变成"信仰之争",而不是"工程之争"。
代表:Anthropic 的 MCP(Model Context Protocol)。 一份 JSON manifest 就能接入,不绑模型,OpenAI / Google 都接了。
这是目前最有机会统一的那层。 门槛低——一个 manifest 文件就行;不蚕食自家模型——是"我提供更多工具";已经形成事实标准。
代表:Hermes 的 SKILL.md(frontmatter + markdown)。 写起来自由,价值在内容不在格式。
门槛最低但也最难统一。 你说 SKILL.md 标准,我也可以搞 SILL.md / CAPABILITY.md。 这层会有"事实标准"(谁的用户多谁就是事实),但不会有"协议标准"。
代表概念:一个 Agent 怎么打包——SOUL.md + skills + tools + memory 全打包分发。
想象一个 white-rain.agent.tar 能跨框架跑。
最难但最有想象空间。 但这条线要等 A 和 B 先收敛——你得先有"统一的 tool 注册"和"统一的 skill 写法",才能打包出一个能在任何框架上跑的 agent。
真正能跑出来的标准,从来不靠 RFC、不靠白皮书——而是靠"大家用着用着就这么写了"。 下面这条时间线,展示了几个事实标准是怎么长出来的。
Anthropic 出了 Anthropic Messages、Google 出了 Gemini、阿里出了 DashScope—— 但所有人写 SDK 时都默认先支持 OpenAI 那个格式。 因为用户已经写了太多 OpenAI 调用了。
一开始各家叫法都不一样——function_call / tool_use / functions。 后来慢慢收敛成"tool calls"这个统一名字——不是因为谁说了算,而是因为大家都这么写最顺。
Anthropic 先做了 MCP——一份 JSON manifest 描述工具能力。 OpenAI 和 Google 看到自己也省事,主动接了,然后大家发现"哦原来大家都这么用"。
DeepSeek Harness 的 `cordis.patch.yml`、Hermes 的 `~/.hermes/config.yaml`—— 这些 manifest 互不兼容。一个 skill 写出来,在 Hermes 里能跑,在 Harness 里得重写注册。
框架层不会收敛,会长期碎片化。
应用层有机会收敛——但只在 Tool 注册这层先实现。
其它子层跟在 Tool 后面慢慢成形。
关于"框架层碎片化":我比较有信心。 数据库、操作系统内核、编程语言之争已经证明,基础设施层永远不会收敛。
关于"Tool 层先统一":我比较有信心。 MCP 已经过了最难的"被多家接纳"关。
关于"Agent manifest 分发":我 不太 有信心。 这是我的猜测,不是判断——可能根本不会出现,可能以一种完全没想到的形态出现(比如不是 OCI 而是 npm-like)。
这页面的判断我 敢押 60%,但剩下的 40% 留给被现实打脸。