AI buzzwords 越来越多，哪些真的值得懂？

最近整理 AI-native 的时候，我顺手把这两年经常遇到的 AI 术语也梳理了一遍。

Agent、MCP、Context Engineering、Harness、Evals、Long-horizon、Skills、Memory、Multi-agent……

数量很多，而且还在不断增加。

我觉得没有必要背一份 50 个词的 glossary。

对 PM、builder，甚至只是希望更好理解 AI 产品的人来说，更有用的是：听到一个新词时，大概能判断它背后真的出现了新的能力或产品结构，还是只是给旧东西换了一个 AI 名字。

如果只看现在比较值得认识的一批，我会先记住这些：

Agent / Agentic workflowAI 不只回答问题，还可以调用工具、判断下一步并持续执行。现在最重要的产品范式之一，但 hype 也很多。

Long-horizonAI 能不能持续几十分钟甚至数小时，把一个复杂任务做下去。2026 年越来越值得关注。

Context Engineering管理模型在每一步到底应该看到哪些 instructions、history、tools、retrieval、memory 等信息。

Harness / Scaffolding围绕模型搭起来的运行系统，包括工具、执行循环、环境、权限、状态和反馈。

Agent Skills / Skills把专业流程、instructions、scripts、resources 等包装成 Agent 可以按需调用的能力。

Agent Memory / Memory让 Agent 从过去的交互和任务中保留、整理并重新使用信息，而不是每次从零开始。

MCP让 AI 应用用更标准的方法连接工具、数据和外部系统。重要，但它解决的是连接问题，不会让模型本身变聪明。

Evals先定义什么叫“做得好”，再系统性地测量。现在已经是 AI 产品工程的核心能力。

另外几个词也值得认识，但我不会在这篇展开：

Reasoning model、Multi-agent、Grounding、Guardrails、RAG。

前两个仍然很热，后三个已经更接近 AI 产品里的基础概念。

把这些词放在一起看，其实比逐个背定义更有意思。

因为它们共同反映了一件事：

AI 行业关注的问题，正在从“模型有多聪明”，慢慢扩展到“怎样把一个聪明的模型变成可靠的系统”。

从 Chat 到 Agent：工作的基本单位变了

以前使用 ChatGPT，最常见的单位是一次 interaction：

我问一句，它回答一句。

Agent 开始把这个单位变成：

一个任务。

用户给出目标以后，系统可以自己查资料、调用工具、修改文件、运行代码，再根据中间结果继续执行。

OpenAI 今年在讨论 Agent 对工作的影响时，就把这种变化描述成从短暂的 chatbot interaction，走向 delegated, long-horizon tasks。

这里的 Long-horizon 不只是“模型可以想久一点”。

真正困难的是：

• Agent 工作了几十步以后，还记不记得最初目标？
• 中间状态变化了怎么办？
• 某一步失败以后能不能恢复？
• context 快满了以后怎么处理？

一个任务从几十秒变成几十分钟甚至更久以后，这些问题都会被放大。

所以 Agent 和 Long-horizon 往前走，Context、Memory、Harness、Evals 也会一起变得更重要。

它们并不是随机同时流行起来的。

Prompt → Context：问题已经不只是“怎么问”

前几年谈怎么用好 LLM，经常绕不开 Prompt Engineering。

Prompt 当然依然重要。

但当 Agent 真正开始工作，需要管理的已经远远不只是一段 prompt。

Context Engineering 关心的是：

模型在这一刻，到底应该知道什么？

这里面可能包括：

system instructions、用户历史、当前任务状态、可用 tools、检索出来的数据、memory，以及前面几十步留下来的中间结果。

Agent 工作时间越长，这个问题越明显。

也不可能简单地把所有历史都一直塞进 context。信息过多，本身就可能影响模型表现。

所以才会出现 compaction、structured memory、just-in-time retrieval、sub-agent 等一整套处理方式。

我觉得 Context Engineering 是这几年少数很值得认真理解的新词。

它描述的是一个真实变化：

以前主要在优化“我应该怎么告诉模型”；现在还要设计“这个时刻应该让模型知道什么”。

Skills 和 Memory：Agent 怎么学会具体工作方式，又怎么利用过去的经验

这两个词我觉得也越来越值得关注。

Agent Skills / Skills

通用模型知道很多东西，但真实工作往往有自己的流程和方法。

一个公司的代码规范、审稿方法、数据分析流程、内部操作步骤，都不应该每次重新写成长 prompt 塞给 Agent。

Skills 的思路，是把这些 instructions、scripts 和 resources 组织起来，在需要完成对应任务时再加载。

所以它解决的其实是：

怎样把一个 general-purpose Agent，变成更懂某种具体工作方式的 Agent。

这和“模型有没有知识”不是同一件事。

一个模型可能知道怎么写代码，但它不一定知道：

这个团队怎么写代码、怎么 review、哪些步骤不能跳、哪些工具必须使用。

Skills 更像是在给通用能力增加一层可复用的方法。

Agent Memory / Memory

Memory 处理的则是另一个问题：

Agent 以前做过的事情，哪些值得留下来？

以后什么时候应该再拿出来？

这里也不只是“保存聊天记录”。

把所有历史原封不动塞给模型，很快会又长又乱。

真正有用的 Memory，需要考虑：

• 什么值得记？
• 怎么整理？
• 什么时候检索？
• 哪些信息已经过期？
• 哪些东西应该被忘掉？

当 Agent 从一个一次性工具，慢慢变成长期一起工作的系统时，Memory 自然会从一个小 feature，变成系统设计问题。

所以我现在理解 Agent Memory 时，更愿意把它看成：

把过去的 interaction 变成以后真正能用的 context。

而不是简单的“AI 记得越多越好”。

Model → Harness：很多产品差异其实发生在模型外面

Harness 是我最近觉得特别值得认识的一个词。

可以粗略理解成：

让模型真正能够作为 Agent 工作的外围运行系统。

比如：

• 模型能调用哪些工具？
• 怎么循环执行？
• 在哪个环境里运行？
• 什么时候需要用户批准？
• 状态怎么保存？
• context 满了怎么办？
• 失败以后怎么 retry？
• 它做过什么，怎么留下记录？

这些都不是模型本身的能力。

两个 AI 产品即使调用同一个基础模型，最终表现也可能差很多。

因为它们可能给模型：

不同的 context、不同的 tools、不同的 permissions、不同的 feedback loop，以及完全不同的 execution environment。

这也是我现在看 AI 产品时越来越在意的一点：

看到一句：

Powered by OpenAI / Anthropic

信息量已经很有限了。

更值得继续问的是：

模型外面搭了什么？

大家可以买到类似的 frontier model。

真正决定产品能不能稳定工作、敢不敢交给真实用户的，经常是外围这一整套系统。

所以 AI-native 的很多差异，其实发生在模型之外。

MCP 很重要，但它解决的是连接问题

MCP 已经不算 AI 新词了。

它解决的问题相对明确：

怎样让 AI client / Agent 更标准化地连接 tools、data 和外部系统。

以前不同 AI 应用连接 Google Drive、数据库、GitHub 或内部系统，往往各做各的 integration。

MCP 想做的是把这层连接标准化一些。

这很重要，因为 Agent 如果只能待在聊天框里，能完成的事情终究有限。

但这里也很容易 hype。

一个产品说：

“我们支持 MCP。”

并不代表它突然有了什么 AI moat。

MCP 解决的是连接与 interoperability。

连接上一个系统，和知道怎样把事情做好，是两层不同的问题。

有点像支持 HTTP 对互联网产品当然很重要，但支持 HTTP 本身并不能说明你的产品好不好。

Demo → Evals：能跑起来以后，怎么知道它真的变好了？

Evals 可能是这批词里最不 buzzword 的一个。

它做的事情非常朴素：

先定义什么叫成功，再用可重复的方法去测。

AI 系统麻烦的地方是，它不像传统 deterministic software 那么容易测试。

同一个任务跑几次，结果可能不一样。

换一个模型、改一段 prompt、增加一个 tool，某些 case 可能变好，另外一些又退化。

Agent 更复杂。

它可能跨很多轮调用工具、修改环境，中间任何一步出错，都可能影响后面的结果。

所以评估 Agent 时，看的已经不只是最后一句答案。

还可能包括：

• 它走了怎样的 trajectory？
• 工具有没有正确使用？
• 有没有完成最终任务？
• 环境最后处于什么状态？

这也是为什么我越来越觉得：

Evals 不只是最后 QA 验收的时候才做。

它其实属于产品定义的一部分。

一个团队首先得说清楚：

我们所谓的“AI 做得好”，到底是什么意思？

这个问题如果一直很模糊，后面的优化也很容易变成：

“我试了一下，好像不错。”

Reasoning 和 Multi-agent 呢？

这两个词我仍然会认识，但不会放在这篇的主线上。

Reasoning model 是真实的模型能力变化：模型在回答复杂问题时投入更多 inference-time compute。

但它更偏模型层。

而这篇我更关心的是：模型能力已经很强之后，产品层开始发生什么。

Multi-agent 也是真东西。

多个 Agent 可以分工、并行、互相检查，某些复杂任务确实适合这样做。

但它也非常容易被过度设计。

一个 Agent 能解决的问题，没有必要为了听起来先进，硬拆成五个 Agent 开会。

所以看到 “multi-agent system”，我不会天然觉得比 single-agent 更高级。

还是要看：

为什么需要多个？它具体解决了什么问题？

Buzzwords 其实也可以当行业地图看

把这些词按时间放在一起，我觉得能看到一条挺清楚的变化。

前几年大量讨论：

Prompt Engineering

重点是怎么让模型回答得更好。

后来大量讨论：

Agent / Tool use / MCP

模型开始需要从“回答”走向“行动”。

现在越来越常见的是：

Context Engineering / Harness / Long-horizon / Skills / Memory / Evals

关注的问题变成：

• 怎么让 Agent 拿到正确的信息；
• 怎么让它掌握特定工作方式；
• 怎么让它保留真正有用的经验；
• 怎么让它持续工作；
• 以及怎么知道它到底有没有把事情做好。

所以 buzzword 不一定只是 marketing。

有些词突然被大量工程团队讨论，是因为技术往前走了一步以后，新的瓶颈开始真正卡住产品了。

从这个角度看，新词本身也可以当作一张行业地图。

它会告诉你：

现在大家正在解决什么问题。

怎么判断一个 AI buzzword 值不值得学？

我大概会看四件事：

• 它描述了什么以前没有的新能力？
• 它解决了哪个真实存在的限制？
• 它有没有改变产品的 workflow、architecture 或 economics？
• 如果真的在做产品，这个概念会改变我的某个设计决定吗？

如果答案都很模糊，它可能暂时只是一个好听的标签。

如果它会影响怎么组织 context、怎么给权限、怎么连接工具、怎么保存状态、怎么测试质量，那就值得认真一点。

AI 术语大概还会继续快速增加。

全部记住没有太大必要。

更有用的是慢慢能看出来：这些新词背后，到底发生了什么真实变化。