夜雨聆风最近两年，AI行业出现新名词的速度越来越快。
Token、Context Window、Prompt、RAG、Tool Calling、MCP、Context Engineering、Skill、Agent、Vibe Coding、Harness Engineering、Loop Engineering、Workflow、Workspace Agent……
这些词单独看，好像每一个都能找到解释。
但把它们放到一起，很多人还是会困惑：
它们到底是什么关系？
哪些是模型能力，哪些是工程方法，哪些是产品形态？
为什么刚弄明白RAG，又开始讨论MCP；刚开始做Agent，又出现 Harness 和Loop？
其实，这些概念并不是互不相干的黑话。
它们背后有一条很清楚的主线：
AI 从理解和生成文字，逐步发展到连接资料、使用工具、执行复杂任务，并进入真实业务流程。
每出现一个新概念，通常都是因为前一种能力还解决不了某个问题。
1. Token 与 Context Window：AI首先要怎么“读”文字
AI 并不像人一样，直接把一整句话当作完整意思读进去。
在模型处理之前，文字通常会先被拆成一个个 Token。
比如“我想吃香蕉”，在不同模型中，可能被拆成不同数量、不同形式的Token。模型真正接收和计算的，是这些Token，而不是我们看到的完整句子。
Context Window，也就是上下文窗口，决定了模型一次最多可以处理多少 Token。
它包含的不只是用户刚输入的问题，还可能包括系统指令、历史对话、工具结果、检索资料和模型输出。
窗口越大，可以放入的信息越多，但并不意味着模型一定更聪明。
信息太少，模型缺少判断依据；信息太多，也可能让真正重要的信息被干扰。
2. Prompt：把任务交代得更清楚
既然模型是根据输入内容生成结果，那么输入方式就会直接影响输出质量。
这也是 Prompt Engineering 出现的原因。
比如只说：
“帮我写一个产品方案。”
模型很容易给出一份正确但空泛的内容。
如果补充产品背景、目标用户、业务目标、限制条件和输出标准，模型才更容易生成符合要求的结果。
Prompt 可以理解成给 AI 写工作说明。
但它有一个明显限制：
Prompt 能把已有信息组织得更清楚，却不能凭空补上模型不知道的资料。
企业内部制度、最新产品数据、客户记录和私有文档，并不会因为提示词写得好，就自动出现在模型里。
3. RAG：先查资料，再回答问题
为了让模型使用外部知识，RAG开始被广泛使用。
RAG 的基本逻辑并不复杂：
先从资料库中找到与问题相关的内容，再把这些内容交给模型回答。
比如员工询问公司的请假规定。
模型不需要凭记忆猜测，而是先从员工手册中检索对应制度，再根据真实资料生成回答。
在这个过程中，Embedding会把文字转换成可以比较的数字表示，向量数据库则根据语义相似度找到相关内容。
这样一来，即使用户的提问和原文用词不完全相同，系统仍然可能找到表达相近的资料。
RAG 解决了外部知识问题。
但它仍然只是让模型“看到资料”，不能让模型真正完成系统操作。
4. Tool Calling：让 AI 开始使用工具
如果用户不只想知道订单状态，而是希望系统查询真实订单，模型就需要调用外部工具。
Tool Calling 让模型可以：
·查询订单；
·读取日历；
·执行代码；
·调用企业接口；
·发送消息；
·操作业务系统。
模型通常负责判断应该使用哪个工具，并生成调用参数。
真正访问数据库、执行代码或操作系统的，仍然是外部应用程序。
可以把 RAG 理解成给 AI 一双眼睛，把 Tool Calling 理解成给 AI 一双手。
但随着工具越来越多，新的问题也出现了。
每一个系统都可能有不同的接口、参数、权限和返回格式，连接成本越来越高。
5. MCP：统一 AI 与外部系统的连接方式
MCP 经常被比喻成 AI 世界的 USB-C。
在没有统一连接方式时，每接入一个数据库、文件系统或企业工具，都可能需要单独开发和维护一套适配逻辑。
MCP 希望统一工具发现、能力描述、参数传递和结果返回的方式，让不同 AI 应用更容易使用外部资源。
需要注意的是，MCP是一种连接协议，不是一个具体工具。
它也不会自动解决权限、安全和数据隔离问题。
统一连接之后，系统仍然要决定：谁能访问什么数据，哪些操作需要审批，哪些信息不能进入模型上下文。
6. Context Engineering：不只是写好一句提示词
Prompt Engineering 并没有过时。
但在复杂 AI 应用里，只写好一段提示词已经不够了。
例如，一个客服 Agent 在回复用户时，可能需要同时知道：
·客户身份；
·历史购买记录；
·当前订单状态；
·过去的投诉记录；
·退款规则；
·当前可用工具；
·人工接管条件。
真正困难的，不是把所有信息全部塞给模型。
而是判断在当前任务、当前步骤中，模型究竟应该看到哪些信息。
信息太少会导致判断不准确，信息太多会造成干扰，过期资料和越权信息还可能引发错误。
Context Engineering 关注的不是“给模型更多信息”，而是：
在正确的时间，把正确的信息交给模型。
7. Skill：把重复方法保存下来
很多任务并不需要每次从头教 AI。
例如生成项目周报时，可能始终需要包含：
·本周完成的工作；
·当前项目进度；
·存在的问题；
·下周计划；
·固定的表达风格。
如果每次都重新描述完整要求，效率很低，也容易出现偏差。
于是，一些产品开始把可重复使用的方法、规则和操作步骤组织成 Skill。
它可以用于周报生成，也可以用于代码仓库分析、财务表格处理或固定格式审核。
需要注意的是，不同产品对 Skill 的定义和实现方式并不完全相同。
但它们解决的是同一个问题：
同一类任务，不应该每次都重新教 AI 一遍。
8. Agent 与 Vibe Coding：从回答问题到围绕目标做事
当模型能够获取信息、使用工具、保存方法以后，它就可以开始围绕一个目标推进任务。
这就是理解 Agent 的关键。
Agent 不是一个更会聊天的模型。
它需要能够：
1.理解目标；
2.制定或调整计划；
3.选择工具；
4.执行动作；
5.观察结果；
6.根据新情况继续调整。
比如排查一个无法启动的软件项目。
Agent 可能先查看错误日志，再检查配置文件、依赖版本和接口调用，然后运行测试，根据新的错误继续排查。
它的核心不是一次生成正确答案，而是形成：
计划—行动—观察—调整
编码任务的反馈相对明确，所以 Coding Agent 发展得很快。
Vibe Coding 则进一步降低了写代码的操作门槛，但这不等于人可以完全不理解工程。
人仍然需要负责目标、架构、任务拆解、代码审查和质量判断。
否则，误改文件、危险代码和 Token 失控等问题仍然会出现。
9. Harness Engineering：让 Agent 可以被约束
一个 Agent 能运行，不代表它可以安全地进入真实业务。
真实系统还需要考虑：
·数据权限；
·工具白名单；
·沙箱环境；
·操作轨迹；
·输出校验；
·重试机制；
·人工审批；
·成本限制；
·回滚与停止。
如果把模型比作发动机，Harness就像方向盘、刹车、安全带和仪表盘。
它不是为了让模型更聪明，而是为了让模型的行为更加可控、可追踪和可验证。
Harness Engineering 更适合作为一类工程方法理解，而不是一个拥有唯一标准定义的技术产品。
10. Loop Engineering：让任务能够持续推进
Harness 解决的是 Agent 不要失控。
但即使系统足够安全，它仍然可能做不完任务。
Loop Engineering 关注的是：
·目标如何拆分；
·是否完成当前步骤；
·失败后如何重试；
·中间状态如何保存；
·什么时候算完成；
·什么时候必须停止；
·预算和迭代次数如何控制。
比如写一份方案，系统可能先生成初稿，再检查是否满足要求，发现缺失后继续补充，直到达到标准或触发停止条件。
它可以理解成一种帮助 Agent 形成闭环、持续纠错的工程视角。
11. Workflow：让 AI 进入连续业务流程
现实业务通常不是一次问答。
例如一个客户提交咨询表单后，系统可能需要：
1.识别客户类型；
2.生成跟进建议；
3.分配销售人员
4.发送邮件；
5.通知工作群；
6.等待人工确认；
7.写入客户数据库；
8.生成日报；
9.继续后续跟进。
这不是一次工具调用，而是一条完整业务流程。
Workflow 负责把API、数据库、消息、审批、定时和条件判断串联起来。
AI 可以负责其中的判断和生成，工作流负责让每一步按照业务要求持续执行。
工作流并不比 Agent 低级。
对于固定、高风险、需要稳定执行的任务，明确的工作流往往比完全自主的 Agent 更合适。
12. Workspace Agent：成为长期存在的团队角色
Workflow 通常是一条已经设计好的流程。
Workspace Agent 则更像一个长期存在于团队工作空间里的角色。
它需要持续了解：
·当前项目；
·团队文档；
·成员职责；
·客户历史；
·阻塞任务；
·敏感数据；
·权限边界；
·提醒与交接。
普通 Agent 写一份周报时，可能需要临时收集信息。
Workspace Agent 则可以在授权范围内读取任务系统、代码提交、会议记录、文档更新和历史周报，再持续协助团队工作。
它可能成为销售助手、数据分析助手、项目管理助手或研发助手。
但真正困难的，仍然不是“它能不能回答”。
而是：
·谁有权访问哪些信息；
·数据如何隔离；
·自动操作到什么程度；
·哪些动作必须人工审批；
·记忆保存多久；
·过期信息何时失效；
·出现错误由谁负责。
这些名词背后，其实只有一条线
回过头看，这些概念并不是十二座互不相关的孤岛。
它们连接起来，是一张 AI 进入真实工作的演进图：
·Token 和 Context Window，决定 AI 如何接收信息；
·Prompt，帮助人把任务交代清楚；
·RAG，让 AI 获得外部知识；
·Tool Calling 和MCP，让 AI 连接外部系统；
·Context Engineering 和Skill，让信息与方法能够被有效组织；
·Agent，让 AI 开始围绕目标行动；
·Harness 和Loop，让行动更加安全、持续；
·Workflow，让 AI 进入业务流程；
·Workspace Agent，让 AI 成为长期协作角色。
以后再出现新的 AI 名词，不用急着背定义。
先问一个问题：
它解决的是 AI 进入真实工作时的哪一个新问题？
只要这条主线没有丢，再多的新概念，也能找到它应该放在什么位置。
看到这里，如果有收获的话，点个三连吧~
