AI发展史，带你了解AI圈的热词

你有没有发现，现在聊AI，开口全是新词？前两年大家还在说ChatGPT、Prompt提示词，后来突然冒出来RAG、向量数据库，接着又是Agent、Skill、MCP，最近又多了Context、Engine、Workspace这些词。很多人刚搞懂一个，新的就来了，越听越慌，觉得自己是不是跟不上AI的节奏了。

其实不用慌，这些词不是凭空冒出来的，每一个新词背后，都是AI在解决一个实际问题。顺着这个逻辑往下看，就能把它们串起来。

很多人第一次用ChatGPT的时候，觉得它什么都能写，写文章、写代码都不在话下。但往底层看，AI根本不是像人一样读完整段话，它会把你输入的内容拆成一个个最小的信息单位，这个单位就叫Token。比如你输入“我喜欢人工智能”，在模型眼里可能会被拆成“我、喜欢、人、工、智、能”。不同模型的拆分方式不一样，中文词可能拆成几个Token，英文单词也可能被拆分，但不用纠结具体怎么拆，只要知道这是AI处理信息的最小单位就行。

Token的数量直接决定了AI一次能处理多少内容，也影响调用AI的成本，更能解释为什么AI有时候会忘记之前的对话。如果一个模型最多能处理八千个Token，那你的问题、历史对话、系统提示词、文件内容加起来都不能超过这个数。就像你的桌面只能放十张纸，新的资料不断放进来，最早的就会被拿走。模型一次最多能处理的Token数量，就是大家常说的上下文窗口。所以看到“128k上下文”“百万Token长上下文”“按Token计费”这些说法，本质都是在说AI一次能处理多少信息。

但上下文窗口越大，AI不一定就越好用。信息太少AI答不出，信息太多又会被无关内容干扰。这时候大家发现，让AI准确理解任务比单纯堆信息更重要，于是Prompt工程火了。

早期大家用AI，随便输入一句“帮我写个方案”，AI可能会输出一堆空泛的话，什么提升效率、优化体验，看起来完整但没什么实际用处。但如果换个问法，明确告诉AI“你是资深产品经理，针对面向开发者的AI工具写产品方案，要包含目标用户、核心痛点、功能模块、商业模式和落地路径，用表格输出”，结果马上就不一样，内容会更具体，也更符合需求。

Prompt工程本质不是写什么“咒语”，而是给AI写一份清晰的工作说明，告诉它要扮演什么角色、完成什么任务、有什么背景信息、输出格式是什么，最好再给几个参考例子。早期那些“万能提示词”“神级Prompt”之所以火，就是因为它们解决了早期AI使用中最直接的问题：怎么让AI准确理解任务。

但Prompt再好用，也解决不了AI“没见过就不知道”的问题。你让它总结公司内部文档，它没看过；让它分析项目代码，它没读过；让它回答昨天刚发生的事，它训练时根本没接触过。这时候AI就会开始“编”，出现大家常说的“一本正经胡说八道”，于是RAG就出现了。

RAG的思路很简单，不让AI只靠记忆回答，先让它查资料再回答。比如你有一堆公司文档、产品手册、项目代码，直接问AI产品的退款规则，它大概率不知道，还可能编出一个看似合理的答案，这就很危险。RAG的做法是先把资料放进知识库，提问时系统先去知识库里找相关内容，再把内容交给AI，让它基于资料回答。

RAG背后还带出了Embedding、向量数据库、知识库这些概念。Embedding就是把文字变成一串数字，计算机不懂语义，但能比较数字之间的距离。比如“怎么申请退款”和“订单取消后钱怎么退”，字面上不一样但意思接近，用关键词搜索可能匹配不准，但变成向量后，系统就能判断它们的语义相似。向量数据库就是专门存这些向量，还能快速找到相似内容的地方。

RAG让AI从“只靠脑子回答”变成了“能翻资料回答”，这一步很关键，第一次让AI有了接入外部知识的能力。但普通RAG也有局限，它更像一次搜索，问一次查一次，遇到复杂问题就不够用了。有时候第一次查到的资料不完整，有时候问题需要拆成几个小问题，有时候查完A才知道还要查B，有时候还要判断资料之间有没有冲突。于是就有了Agentic RAG，它更像一个研究助理，会判断资料够不够，不够就换关键词继续查，问题太大就拆成子问题，多个来源说法不一致还会交叉对比。

这时候AI已经能主动研究了，但新问题又来了：AI能告诉你怎么发邮件，却不能真的发；能告诉你怎么查订单，却不能真的查；能告诉你代码怎么改，却不能真的改你的项目。于是Tool Calling出现了。

RAG给AI配了资料室，Tool Calling就给AI配了手。从这里开始，AI不再只是生成文字，还能调用外部工具。比如你问“帮我查一下这个订单状态”，它可以调用订单系统；你说“帮我跑这段Python代码”，它可以调用代码执行环境。这就是Function Calling或Tool Calling，解决的核心问题是让AI从“给建议”变成“执行动作”。

以前你问AI“我今天下午有空吗”，它可能会让你自己看日历，这是建议。但如果AI接入了日历工具，就能直接查你的日历，告诉你“下午两点到三点有会，四点以后比较空”，这就不是建议了，它真的帮你完成了查询。

但工具一多，新的麻烦就来了。如果AI要接天气数据库、GitHub、浏览器、公司内部系统，每个工具都要单独开发接口，每个平台接法都不一样，每个Agent都要重复集成。工具描述怎么写、参数怎么传、权限怎么管、调用结果怎么返回、安全边界怎么控制，没有统一标准的话，这件事会变得非常混乱。于是MCP就出现了。

MCP能火，不是因为它让模型更聪明，而是因为AI要进入真实工作环境，必须解决“外部工具太多、连接方式太乱”的问题。你可以把MCP理解成AI连接外部工具和数据源的一套标准协议，就像AI世界里的USB-C。以前每个设备接口都不一样，手机、电脑、相机、充电器各有各的接口，USB-C出现后，大家都用统一接口连接。MCP在AI世界里做的事也类似，以前每个AI应用接工具都像自己焊电线，接GitHub要写一套，接数据库要写一套，接文件系统又要写一套，开发和维护成本都很高。

MCP要解决的是“工具怎么暴露给AI”“AI怎么知道可以调用哪些能力”“工具需要哪些参数”“调用结果怎么返回”“资源怎么提供”“权限和安全边界怎么控制”这些问题。它不是一个普通工具，更像是AI接入工具生态的连接层，解决怎么让AI更标准地连接很多工具和数据源。

这时候AI已经不只是聊天框了，更像一个可以接插件的系统。但新的问题又出现了：AI每次执行任务时，真正影响效果的不只是模型和工具，还有它当时到底看到了什么信息。这就进入了Context Engineering的范畴。

很多人以为Prompt Engineering过时了，其实不是，只是它不够用了。早期我们关注的是一句话怎么写得更好，但现在AI应用越来越复杂，真正的问题变成了“这次任务，系统应该给AI准备哪些信息”。它要不要看历史对话？要不要看用户资料？要不要看数据库状态？要不要看公司规范？要不要看工具调用结果？这不是一句Prompt能解决的，这就是Context Engineering。

你可以这样理解，Prompt Engineering是写一条好指令，Context Engineering是设计整个信息流。比如你让AI帮你回复客户，简单的Prompt可能只能让它根据当前输入的一句话回复，但真正好用的AI客服助手，需要知道这个客户是谁、之前买过什么、之前投诉过什么、公司退款政策是什么、这次回复要不要升级给人工。这些信息不能随便塞给AI，太少了判断不准，太多了会被干扰，信息过期了会做出错误判断，权限没管好还可能泄露敏感数据。所以Context Engineering的核心不是给AI更多信息，而是给AI刚好需要的信息。

后来又出现了Context Engine这个更产品化的词。Context Engineering更像方法，Context Engine更像系统，它的作用是每次AI执行任务时，自动帮它组装最合适的上下文。比如该查哪些资料、该带哪些历史记录、该过滤哪些敏感信息、该压缩哪些长内容、该把重要信息放在前面。它不是让模型本身变聪明，而是让模型每次工作时都能拿到更合适的材料。

但这里又有个问题，如果每次都要手动告诉AI怎么写周报、怎么分析代码、怎么处理Excel，还是很麻烦。于是Skill就出现了。

Skill这个概念很好理解，它解决的是“不想每次都重新教AI一遍”的问题。比如你每周都要写工作周报，每次让AI帮你写，都要重新交代很多要求：这周做了哪些事、哪些项目有进展、哪些问题没解决、下周计划怎么写、语气要正式但不要太空、不要写成流水账、要突出成果。你说少了，AI写出来不符合要求；你说多了，每次都像重新培训新人。这时候你就会想，能不能把这套要求保存下来，以后只要说“按我的周报格式来写”，AI就知道怎么做。它会先整理本周事项，再提炼成果和问题，然后按固定格式输出，最后把语气调整成适合公司汇报的风格。

这就是Skill的用法，Prompt更像一次性指令，Skill更像一份长期SOP。它把一套重复出现的工作方法，沉淀成AI可以反复调用的能力。写周报是一种Skill，分析代码仓库是一种Skill，处理财务表格也是一种Skill。它的意义在于，AI不再只是临时听你指挥，还能积累一类任务的固定做法。

这对个人和团队都很重要，个人可以把自己的工作风格沉淀下来，团队可以把标准流程沉淀下来，企业可以把岗位经验变成可复用的AI能力。但到这里，AI主要还是通过文本、文件、API和工具来实现工作，而现实里还有大量系统没有那么理想，很多系统没有API，有些系统的API非常难接。还有很多操作本来就发生在网页、软件和后台系统里，比如点击按钮、填写表单、上传文件、复制粘贴、筛选数据、下载报表、登录后台，在多个页面之间来回操作，这些事不是简单调用一个API就能完成的。于是AI又往前走了一步，开始尝试像人一样使用电脑，这就引出了Computer Use这个方向。

Tool Calling是AI调用API，Computer Use是AI像人一样操作电脑。这两件事看起来都叫执行动作，但本质不一样。如果一个系统有API，AI可以直接调用接口，比如查天气、查订单、查数据库。但如果一个系统没有API，比如老旧后台、网页管理系统、内部审批页面、只能人工点击的表单，过去AI很难处理，因为它不能只靠文字生成完成这些操作。

Computer Use的思路是让AI看屏幕、理解界面，然后用鼠标和键盘操作。它可以打开网页、点击按钮、输入内容、滚动页面、选择下拉框、提交表单、下载文件、上传资料。比如你要报销一张发票，公司系统没有API，以前你只能自己打开网页、登录后台、点击报销、填写金额、上传发票、选择部门、提交审批。如果AI只能调用API，就帮不上忙。但如果AI能Computer Use，就可以像人一样操作浏览器，打开报销系统，找到新增报销入口，识别发票金额，填写表单，上传文件，提交申请。

这一步的意义很大，因为它让AI不再只服务于接口完善的新系统，还有机会进入很多原本只能人手操作的旧系统。这也是为什么AI Browser、Browser Agent、Operator这些概念会火。浏览器原来是人上网的入口，未来也可能变成AI替你办事的入口。

不过Computer Use也有明显的难点，网页布局会变、按钮可能识别错、登录可能需要验证码，一点点错后面就全错。有些操作还涉及权限和安全，所以Computer Use很有想象力，但要真正稳定落地还需要很多工程配套。

当AI既能查资料又能调用工具，还能操作电脑、复用Skill，下一个问题就变成了它能不能自己完成一个复杂任务，这就是Agent。

Agent这个词很火也最容易被讲乱，很多人把Agent理解成更聪明的聊天机器人，但这不准确。Agent真正关键的不是聊天，而是它能围绕一个目标自己拆步骤、选工具、观察结果，再继续调整。普通聊天机器人是你问一句它答一句；Tool Calling是你让它做一个动作，它调用一个工具；Agent更像是你给它一个目标，它自己想办法往前推进。

比如你说“帮我分析这个项目最近为什么启动失败”，普通AI可能会告诉你可以检查配置、依赖、端口、日志，这叫建议。但一个编程Agent可能会真的开始做事，它先看错误日志，再读配置文件，再检查依赖版本，再搜索代码里的相关调用，再尝试运行测试，如果出现新的报错，它再继续定位，最后给出修改方案，甚至直接改代码。

Agent的核心是一个循环，先计划，再行动，观察结果，根据结果调整下一步。这也是为什么Agent最先在编程领域爆发，因为代码特别适合Agent。代码项目有明确的文件、报错信息很具体、测试结果能反馈对错、版本控制可以记录改动、改完还能自动运行验证。一个写代码的Agent不只是生成一段代码，它可以读项目、理解文件结构、搜索函数、修改代码、运行测试、根据报错继续改，最后生成提交说明，甚至提交PR。所以这两年AI IDE和AI Coding Agent爆发得非常快，Cursor、Cloud Code、Codex、Gemini CLI、SWE Agent本质上都在往这个方向走。

这也催生了Vibe Coding这个很出圈的词。什么是Vibe Coding？简单说就是以前是你写代码，AI辅助你，现在是你描述目标，AI生成实现，你负责验收和调整。它更像是在改变程序员的工作重心，以前很多时间花在写具体实现，以后更多时间会花在定义需求、拆解任务、设计架构、审核代码、控制质量以及管理AI Agent。

但Agent越强，风险也越明显，它会犯错、会乱改文件、会误删内容、会生成不安全代码、会跑偏、会消耗大量Token，也可能做出一个看起来能跑，但你完全不敢上线的东西。所以Agent不是越自由越好，真正要落地必须给它套上一套工程约束，于是Harness Engineering就出现了。

很多Agent的Demo看起来非常震撼，你输入一个目标，它自己拆任务、查资料、调用工具、写代码，几分钟之后结果就出来了。但一到真实生产环境，问题就复杂了，它能不能控制权限、能不能知道哪些操作不能做、生成的结果谁来验证、什么时候需要人类审批、会不会越权访问数据。这时候你会发现，Agent真正难的地方不只是模型本身，更难的是模型外面的工程系统，这就是Harness Engineering。你可以把它理解成给AI Agent套上的安全带、方向盘、仪表盘和刹车系统。如果模型是发动机，Harness就是整辆车的控制系统。发动机越强越需要控制，否则它不是跑得更快，而是更容易出事故。

Harness里通常会包括权限控制、工具白名单、执行沙箱、日志追踪、错误重试、输出验证、人工审批、成本控制、安全边界、回滚机制、评测系统这些内容。比如你让AI Agent帮你整理电脑文件，如果没有Harness，它可能会误删重要文件。如果有Harness，系统就可以限制它只能访问某个文件夹、只能重命名、所有操作都要记录、危险动作需要人工审批、出错后可以回滚。再比如你让Agent改代码，没有Harness，它可能直接改生产代码。有Harness，它只能在一个沙箱分支里改，改完以后必须跑测试，测试通过后才能提交，提交前还要人工Review。

所以企业真正需要的不是一个看起来很聪明的Agent，而是一个安全可控、可追踪、能被验证的Agent。这也是AI落地过程中很关键的变化，难点正在从“模型够不够聪明”转向“系统够不够可靠”。

讲到这里，AI已经从聊天机器人变成了能查资料、能调用工具、能写代码、能执行任务的Agent。但真实业务里还有一个问题，企业工作不是一个Agent单独完成的，真实工作往往是一条流程，于是Workflow开始变得重要。

你想象一个真实业务场景，一个客户提交了咨询表单，系统要先获取表单、推断客户类型、查询CRM、生成跟进建议、分配销售、发送邮件、通知群聊、等待人工确认、写入数据库、生成日报，后续还要继续跟进。这不是一次聊天，也不是一个工具调用，这是一条业务流程，所以Workflow变得非常重要。n8n、Dify、Zapier、Make、LangGraph这类工具解决的就是这个问题，它们的价值不是让模型本身更强，而是把AI、API、数据库、消息系统、人工审批、定时任务和条件判断串起来。这里面AI只负责一部分判断和生成，真正让整个事情跑起来的是Workflow。

可以这样理解，Agent更像负责思考和判断；Workflow更像负责把步骤按顺序串起来。一个没有Workflow的AI往往只能完成单点任务，但有了Workflow就可以进入一个持续运转的业务流程。这就是为什么n8n、Make这类工具会受到关注，它们给了普通人一种可能性：不一定要从零写一套系统，可以把现有工具像搭积木一样串起来，中间需要判断和生成的地方再接入AI。这也是AI从好玩的聊天框进入真实生产流程的关键一步。

但到这里还差最后一层，Workflow解决的是一条流程怎么跑，企业真正想要的往往不是一个跑完就结束的流程，而是一个能长期存在于工作空间里的AI，这就到了Workspace Agent。

Workflow和Workspace Agent很容易被混在一起，但它们不一样。Workflow更像是一条流程，设计好步骤按步骤执行；Workspace Agent更像是一个长期待在团队里的岗位助手，不只是执行某一次任务，还要理解团队长期积累的上下文。比如团队有哪些项目、文档放在哪里、谁负责什么、这个客户之前发生过什么、哪个任务卡住了、哪些信息是敏感的、哪些操作需要审批、谁有权限看什么、什么时候应该提醒、什么时候应该交给人类。

普通Agent更像临时工，给它一个任务做一次。Workspace Agent更像岗位助手，长期待在一个工作空间里，理解流程、权限、上下文和协助关系。比如让一个普通Agent帮我写一份项目周报，它可能会问项目内容是什么、进度是什么、风险是什么、下周计划是什么，因为它不知道团队发生了什么。但一个Workspace Agent不一样，它已经在工作空间里，能看到任务系统、能看到代码提交、能看到会议纪要、能看到文档更新、能看到成员分工、也能看到上周周报。所以它可以自动整理出本周完成了哪些事项、哪些任务延期了、哪个模块风险最大、下周应该推进什么、哪些内容还需要负责人确认。这就不是普通聊天机器人了，它开始进入组织的工作空间。

所以Workspace Agent的重点不止是更智能，它真正代表的是一种产品形态变化。AI不再只是一个临时打开的工具，它开始变成团队工作空间里长期存在的一类角色。比如AI销售助理、AI数据分析助理、AI项目管理助理、AI研发助理，它们不再只是回答问题，而是长期处理某一类工作，并且和团队流程结合在一起。

当然这件事也非常难，因为一旦AI进入工作空间就会遇到更多现实问题。权限怎么管？数据怎么隔离？不同成员看到的信息不一样怎么办？AI的建议错了谁负责？什么时候自动执行？什么时候必须人工确认？它长期记住的信息哪些应该保留？哪些应该过期？所以Workspace Agent不只是一个更酷的Agent，它背后其实牵扯到企业协作、权限、安全、流程和组织管理，这也是为什么它会成为AIGC领域的一个重要方向。

现在再回头看这些词，就不会觉得乱了。这些词不是一堆孤立的概念，背后有一条清晰的主线：AI正在从一个会聊天的工具，变成一个能进入真实工作情境的数字员工。过去大家以为AI的进步主要是模型越来越强、参数越来越多、速度更快、回答更聪明。但现在会发现，真正的变化不止发生在模型里，更大的变化来自于如何让AI与真实世界咬合得更好。这就是为什么AI圈会不断出现新词，不是因为大家喜欢制造黑话，而是因为AI每往真实工作靠近一步，就会遇到一个新问题，为了解决这些问题，才出现了新的概念、新的工具、新的工程方法。