Making Sense of LLM, Tool, Skill, Agent, and more

AI 发展得很快，codex 每周都在更新，学习速度已经跟不上了。

回想以前是通过 ChatGPT 网页来生成某个函数代码，再复制到项目里……后面用上了编辑器（trae、cursor）和 VS Code 插件，里面是对话的形式，再后面出来了一种 agent 的说法，社区叫它「智能体」——于是就有了「chat」和「agent」两种模式。

后面碰巧听到「LLM」，我还愣了一下，才反应过来是大语言模型。还有以前的「prompt」，再到「token」、还有什么「context」，动不动就冒出一些新词，已经跟不上了。后来又听到「harness」「MCP」「workspace agent」这些，更让人头大。

索性把这些词一个个揪出来，按它们冒出来的先后顺序捋一遍。捋到后面才发现，它们根本不是互相孤立的黑话，而是一条链——每个新词，都是在补上一个词留下的窟窿。

LLM 不是搜索引擎，是概率生成器

我一开始也以为，大语言模型就是一个更聪明的搜索引擎，你问它问题，它从某个数据库里找答案。后来才明白这个理解大错特错。

大语言模型的工作方式是：给它一段文字，它预测下一个最可能出现的词是什么，然后基于这个词再预测下一个，再下一个——一个字一个字接龙接出来的。这意味着什么？首先，它不是在「查找」答案，而是在「生成」答案，所以它会一本正经地胡说八道，因为它追求的是听起来合理，而不是事实正确，这就是所谓的幻觉问题。第二，它也因此具备了创造力，能写诗、编故事、写出你从没见过的一种组件实现方式，因为它本质上就是在做创造性的接龙。

记住：大语言模型是一个概率生成器，不是知识库。想通这一点，我就不再纠结「AI 为什么会说错」这种问题了。

token：AI 眼里的文字是被切碎的

第一次用 AI 工具的时候，输入一句话它就能写文案、写代码，看着挺神奇。但往底层看，AI 处理文字的方式和人不一样——它不会直接读完整篇文章，而是先把输入内容拆成一个个更小的信息单元，这种单元就叫 token。

举个例子，你输入「帮我写一个防抖函数」，在模型看来这可能不是完整的一句话，而是被切成了「帮我 / 写 / 一个 / 防抖 / 函数」之类的片段。不同模型的切法不太一样，有的中文词会被拆成好几个 token，有的英文单词（比如 debounce）也可能被切成好几段。具体怎么切不用纠结，记住一件事就行：这种被拆出来的小片段就是 token。

token 为什么重要？因为它直接影响三件事：一是 AI 一次能读进多少内容，二是调用 AI 的成本是多少，三是 AI 为啥偶尔会忘掉前面聊过的东西。好比一个模型一次只能处理 8000 个 token，那你的问题、历史记录、系统提示词、文件内容、返回结果加一块儿都不能超过这个数——对话越拉越长，超过这个上限，前面的内容就有被挤出去的风险。这就像编辑器一次最多能开 10 个标签页，继续打开新文件，最早那个标签就被自动挤掉了。

context window：标签页能开多少个

模型一次能装下多少 token，这个容量就叫 context window，也就是上下文窗口。所以「128K 上下文」「百万 token」「长上下文模型」「按 token 计费」这些说法，讲来讲去其实就是一件事：这个 AI 一次最多能处理多少信息，以及你往里塞了多少信息。

不过这里有个关键问题：上下文窗口越大，AI 就一定更聪明吗？我原来以为是的，后来发现真不一定。信息太少，AI 接不上话；信息太多，它又容易被没用的东西带偏。AI 想真的好用，关键不在模型能看多少，而在你能不能把任务交代明白。于是下一个词冒出来了。

prompt：AI 怎么听懂你的任务

早期刚用 AI 时最兴奋的是「我只要敲一句话，它立马就能给我答案」，可很快发现，同一个问题换种问法，结果差别非常大。

比如你跟 AI 说「帮我写个方法」，它可能随手甩给你一个看着能跑、但没考虑任何边界情况的函数——没有类型、没有异常处理，命名也是 foo、bar 那种，实际一点用都没有。但要是换种问法：「你是个高级前端工程师，请写一个防抖函数（debounce），要求支持立即执行选项、能取消、TypeScript 类型完整，并附上使用示例。」结果立马不一样——具体得多，更有条理，也更贴近你真正想要的东西。

这时候才反应过来：AI 很多时候不是不会干，而是你没把活交代明白。于是 prompt engineering（提示词工程）火了起来。说白了，prompt engineering 不是让你念咒语，而是让你给 AI 写一份工作说明书：它现在扮演什么角色，要完成什么任务，背景信息有哪些，输出格式长什么样，哪些内容不许写，什么样的结果才算合格——要是能给几个例子就更好了。所以早期 AI 圈特别流行「万能提示词」「神级 prompt」这类内容，它们之所以火，是因为确实解决了早期用 AI 时很现实的问题：怎么让 AI 更准确地领会我的意图。

但 prompt 再厉害，也只能解决「任务怎么说清楚」，解决不了另一个更致命的问题：模型不知道的东西，它就是不知道。你让 AI 总结公司内部文档，它压根没看过；你让 AI 分析你项目里的代码，它完全没读过；你让 AI 回答昨天才发生的事，它训练的时候可能根本没有这条信息。你要是非让它回答，它就只能靠猜——而 AI 一旦开始猜，就会开始一本正经地胡说八道。于是下一个词登场了。

RAG 和 embedding：先查资料，再回答

RAG 要解决的问题很简单：别让 AI 光凭记忆回答，先让它去查资料，再回答。

比如你手上有一堆项目文档、组件库说明、接口规范，以前你直接问 AI「我们项目里 Button 组件的 loading 状态该怎么用」，要是 AI 没看过你的组件库文档，它大概率答不上来，可它偏偏很会组织语言，于是可能给你编一个听着很合理、实际根本不存在的 API——这就有点危险了。而 RAG 的思路是：先把资料放进知识库，等你提问的时候，系统先到知识库里翻相关内容，再把找到的东西交给 AI，最后让 AI 照着这些资料作答。

RAG 的全称是「检索增强生成」（Retrieval-Augmented Generation），名字听着挺唬人，逻辑其实特别简单：先检索，再生成。你问 AI「这个项目提交代码前要过哪些检查」，要是它没看过项目的 CI 配置，只能瞎猜。但如果系统先在项目 wiki 或 CI 配置文件里搜到对应说明，才把内容喂给 AI，AI 就能回答「根据项目规范，提交前要跑 ESLint、单元测试和类型检查，三项都过了才能合并」——这就不算瞎编，而是照着资料回答。

RAG 背后还牵出两个概念：embedding（向量）和向量数据库。embedding 说白了就是把文字变成一串数字——为什么要变成数字？因为计算机不理解含义，但它能比较数字之间的距离。比如「怎么给这个接口加缓存」和「这个接口调用太频繁怎么优化」，这两句话字面差很多，但意思其实很近，只做关键词搜索可能对不上号，可一旦把它们变成向量，系统就能看出这两句话意思很接近。向量数据库就是专门存放这些向量、还能帮你快速找出相似内容的地方。

所以 RAG 让 AI 从「光靠脑子回答」变成了「会翻资料回答」，这一步相当关键，因为它让 AI 头一回拥有了接入外部知识的能力。但新问题也跟着出现：AI 现在能查资料，可它还是没法真正动手干活——它能告诉你这个组件该怎么拆，却没法真的帮你建文件；它能告诉你这段测试该怎么写，却没法真的帮你跑一遍；它能告诉你代码怎么改，却没法真去动你的项目。

tool：AI 怎么从回答变成动手

RAG 让 AI 有了资料室，tool 给了 AI 一双手。从这一步起，AI 不再只会生成文字，它开始能调用外部工具了。

以前你问 AI「这个页面为什么白屏了」，它可能会回你「你可以打开控制台看看有没有报错」，这叫给建议。但如果 AI 接上了浏览器和日志工具，它就能直接去读 console 报错和网络请求，然后告诉你「是这个接口返回了 500，第 32 行那个 fetch 没做错误处理」——这就不光是建议，它是真帮你去查了。这解决的核心问题是：AI 怎么从「给建议」变成「执行」。

可工具一多，新麻烦也就跟着出现：如果 AI 要接数据库、Git、浏览器、公司内部系统，每个工具都得单独开发一套接口。每个平台都有自己的接法——工具说明怎么写、参数怎么传、权限怎么管、调用结果怎么返回、安全边界怎么控制，要是没有一套统一方式，这事会乱成一锅粥。

MCP：AI 世界里的 USB-C

MCP 为什么这么火？不是因为它让模型本身变聪明了，而是因为 AI 想进入真实工作环境，必须搞定一个很现实的问题：外部工具太多，连接方式太乱。

你可以把 MCP 理解成「AI 连接外部工具和数据源的一套标准协议」，就好比 AI 世界里的 USB-C。以前每个设备都有自己的接口——手机一个口，电脑一个口，相机一个口，充电器一个口；后来 USB-C 出现后，大家就能用一个统一接口连接它们。MCP 在 AI 世界里干的事也差不多：以前每个 AI 应用接工具都像重新拉一遍电线——接数据库要写一套，接文件系统又要写一套，接企业内部系统还得再写一套，开发成本高，维护成本也跟着高。MCP 想搞定的是：工具怎么开放给 AI，AI 怎么知道它能调用哪些能力，工具要哪些参数，调用结果怎么返回，资源怎么提供，权限和安全边界怎么控制。

所以 MCP 不是一个普通工具，它更像是 AI 接入工具生态的一层连接协议。这时的 AI 已经不只是一个聊天框，它开始有点像一个可以接插件的系统。可问题还没完：AI 每次执行任务时，真正影响效果的不仅是模型，也不光是工具，还有一个很要紧的东西——它那一刻到底看到了哪些信息。

面试要是被问「MCP 和 CLI 有什么区别」，先别急着背标准答案，大概率是面试官自己也是这两天才看的公众号。往实在了说：CLI 是给人（或者写死的脚本）用的，命令、参数、输出格式全靠你翻文档硬记；MCP 是给 AI 用的，工具自己声明「我是谁、要什么参数、能干什么」，AI 现场发现现场调用，不用你把说明书提前塞进 prompt 里喂给它。真要抬杠还可以补一句：不少 MCP server 底层其实就是包了一层 CLI——所以更准确的说法大概是，这俩根本不在一个维度上打架，一个是给人操作的接口，一个是给 AI 发现能力的协议。答完记得顺嘴反问一句「贵司线上环境接了几个 MCP」，通常能把面试官问沉默。

context engineering：不是更多信息，是刚好够用的信息

很多人觉得 prompt engineering 已经过时，其实不是过时，而是不够用了。早期关心的是「这句话怎么写更好」，可 AI 应用越来越复杂之后，真正的问题变成了：这次任务，系统该给 AI 准备哪些信息？要不要看到历史对话？要不要看到用户资料？要不要看到数据库结果？要不要看到上一次的任务状态？要不要看到公司规范？要不要看到工具调用结果？这就不是一句 prompt 能摆平的了，这叫做 context engineering。

可以这么理解：prompt engineering 是写一条好指令，context engineering 是设计一整个信息流。「帮我 review 一下这个 PR」是一个简单 prompt，可能只能照着这次 diff 本身给点意见；但一个真正好用的 AI code review 助手，需要掌握更多信息——这个模块是谁维护的，之前有没有出过类似的 bug，项目的代码规范是什么，这次改动要不要拉核心维护者二次确认。这些信息不是一股脑全塞给 AI 就行：太少了，AI 判断不准；太多了，AI 会被干扰；信息过期了，AI 会做出错误判断；权限没管好，还可能露了敏感数据。

context engineering 的核心不是给 AI 更多信息，而是给 AI 刚刚够用的信息。这件事很关键，因为越往后走，AI 的效果越不只看模型会不会答，而是看系统有没有把对的信息交到它手上。但这里又冒出个新问题：如果每次都得手动教 AI「你该怎么写 PR 描述」「你该怎么分析代码」，还是太麻烦。

skill：把反复出现的活儿存下来

skill 这个概念特别接地气，因为它解决的是一个特别实在的问题：不想每次都得重新教 AI 一遍。

假设你每次提交代码都要写 PR 描述，每次让 AI 帮你写都得重新讲一大堆要求——改了哪些文件、为什么改、有没有破坏性变更、要不要贴截图、测试是怎么跑的，语气要简洁但不能漏关键信息，也不能写成流水账。说少了，AI 写出来不是你要的样子；说多了，每回又像是在从头教一个新人。这时候你就会琢磨：能不能把这套要求直接存下来，以后我只要说「按我们项目的 PR 模板来写」，AI 就知道该怎么做——先帮你梳理这次改动，再提炼影响范围和测试情况，按固定格式输出，最后把语气调成适合团队 review 的风格。

这就是 skill 的价值所在：prompt 更像一次性指令，skill 更像一份长期可复用的工作说明书，它把一套反复出现的工作方法沉淀成 AI 能直接调用的能力——写 PR 描述可以是一种 skill，生成单元测试同样可以是一种 skill。这件事对个人和团队都意义不小：个人能把自己的工作风格沉淀下来，团队能把标准流程沉淀下来，企业能把岗位经验变成可复用的 AI 能力。

而当 AI 既能查资料、又能调工具、还能复用 skill，下一个问题就变成了：它能不能自己搞定一个复杂任务？

agent：给它一个目标，它自己想办法推进

这是我听到之后最容易犯迷糊的一个词。Agent 特别火，也特别容易被讲乱，很多人把它当成「更聪明的聊天机器人」，这个理解不准确。Agent 真正关键的不在「聊天」，而在于它能围绕一个目标自己拆步骤、选工具、看结果，然后继续调整。普通聊天机器人是你问一句它答一句，tool 是你让它做一个动作、它去调一个工具，agent 更像是你给它一个目标，它自己想办法往前推进。

比如你说「帮我分析一下这个项目最近为什么启动失败」，普通 AI 可能会回你「可以查查配置、端口、依赖」，这叫给建议；但一个编程 agent 可能真的会动手干起来——先看错误日志，再读配置文件，再搜代码里的相关调用，再试着跑测试，要是冒出新的报错，再接着定位，最后给出修改方案甚至直接改代码。Agent 的核心是一个循环：先计划，再动手，观察结果，再照着结果调整下一步。

这也是为啥 agent 现在在编程领域爆发得特别猛，因为代码特别适合它——代码项目有清晰的文件结构，报错信息很具体，测试结果能反馈对错，版本控制能记录改动，改完还能自动跑一遍验证。一个写代码的 agent 不光是生成一段代码，它能读项目、懂文件结构、搜函数、改代码、跑测试、照着报错继续改，最后生成提交说明。这两年编程 agent 发展得特别猛，也催生了一个很出圈的词：vibe coding。

vibe coding：重心从写代码挪到验收代码

这个词不是哪个大厂公关部憋出来的，是 Andrej Karpathy 在 2025 年 2 月一条随手发的推文里顺嘴造出来的：

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

— Andrej Karpathy

简单讲，vibe coding 就是：以前你写代码、AI 给你打辅助；现在你描述目标、AI 负责实现，你来验收和调整。它更像是在挪动程序员的工作重心——以前大量时间花在写具体实现上，以后更多时间会花在定义需求、拆解任务、设计架构、审代码质量，以及管理 AI 的产出上。

可 agent 能力越强，风险也越明显：它会犯错，会乱改文件，会误删内容，会生成不安全代码，会跑偏，会烧掉大量 token，还可能弄出一个看着能跑、但你完全不敢上线的东西。所以 agent 不是越自由越好，真想落地，必须给它套上一套工程约束。

harness engineering：给 agent 装上安全带和刹车

很多 agent 演示看起来特别震撼：输入一个目标，它自己拆任务、查资料、调工具、写代码，几分钟之后一个结果就摆在你面前。但一进真实生产环境，问题就变得复杂：它能不能管住权限？知不知道哪些操作不能碰？生成的结果谁来验证？什么时候需要人来审批？会不会越权访问数据？这时才发现，agent 真正难的不只是模型本身，更难的是模型外面的工程系统——这就是 harness engineering，驾驭工程。

可以把它理解成给 agent 配上的安全带、方向盘、仪表盘和刹车系统：如果说模型是发动机，harness 就是整辆车的控制系统——发动机越猛，越需要管住它，不然它不是跑得更快，而是更容易出事故。harness 里通常会包含：权限控制、工具白名单、执行沙箱、操作追踪、错误重试、输出验证、人工审批、成本控制、安全边界、回滚机制、评测系统。

举个例子，你让 agent 帮你清理项目里没用的依赖，要是没有 harness，它可能把还在用的包也一并删了；有 harness，系统就能约束它——只能删除确认没有引用的包，所有操作都得留记录，危险操作要人来审批，出了错还能回滚。再比如你让 agent 改代码，没有 harness，它可能直接动生产代码；有 harness，它只能在沙箱分支里改，改完必须跑测试，测试过了才能提交，提交前还得人工审查。

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

loop engineering：不只是不闯祸，还要能把事做完

很多 agent 项目都是：安全是管住了，可干活依然费劲——做一半就卡，出错就停，出个草稿就交差，好坏不自查，全靠人一遍遍盯着改。这时候会发现，harness 管的是「不闯祸」，loop 管的是「能成事」，这就是 loop engineering，循环工程。

如果说模型是发动机，harness 是刹车和安全带，loop 就是自动导航与纠错系统——不用人全程指挥，它自己规划、自己改错，没达标不罢休。loop 里通常有这些目标：任务拆解、自检复盘、自动重试、进度追踪、达标判定、成本管控。

举个例子，你让 agent 写一个组件，没有 loop，写完一版就交，边界情况和各种 rough edge 全部得靠你提修改意见；有 loop，它自己查缺补漏、调整逻辑、反复优化，合格了才交付。再比如让 agent 修 bug，没有 loop，一次不行就放弃；有 loop，它会反复排查、复盘原因、调整方法，直到修好或触发停止规则。

所以企业要的 agent 不只是安全可控，更要能自主闭环、自动迭代，把事真正落地做完。这也是 AI 落地的新趋势：从拼「系统安不安全」走向拼「任务能不能闭环」。但真实业务里还有一个问题：企业里的活不是靠一个 agent 单独完成的，真实工作往往是一条流程，于是 workflow 开始变得重要。

workflow：AI 怎么进入业务流程

想象一个真实的研发场景：一次代码提交后，系统得先跑 lint、再跑单元测试、构建打包、跑 e2e 测试、通知相关人 review、部署到测试环境、群里发通知、更新工单状态，后面还得继续跟进有没有回归——这不是一次聊天，也不是一次工具调用，而是一条完整的 CI/CD 流程。

所以 workflow 变得特别重要，n8n、扣子这类工具解决的就是这个问题：它们的价值不是让模型本身变强，而是把 AI、API、数据库、消息系统、人工审批、定时任务和条件判断串起来。这里面 AI 只负责一部分判断和生成，真正让整件事转起来的是 workflow。可以这么理解：agent 更像负责思考和判断，workflow 更像负责把步骤按顺序串起来。一个没有 workflow 的 AI 通常只能做单点任务，可一旦有了 workflow，它就能进入一条持续运转的业务流程。

这也是为啥 n8n、扣子这类工具会被关注——它们给了普通人一种可能：不一定非得从零搭一套系统，可以把现有工具像搭积木一样串起来，中间需要判断和生成的地方再接上 AI。这也是 AI 从「好玩的聊天框」迈进「真实生产流程」的关键一步。但到这里还差最后一步：workflow 解决的是「一条流程怎么跑」，企业真正想要的往往不是一个跑完就结束的流程，而是一个能长期待在办公空间里的 AI。

workspace agent：从临时工变成数字同事

workflow 和 agent 很容易被混为一谈，但它们不一样：workflow 更像一条流程，你设计好步骤，它照着步骤执行；workspace agent 更像一个长期待在团队里的岗位助手，它不只是执行某一次任务，还要理解团队长期攒下来的上下文——团队有哪些项目，代码放在哪个仓库，谁负责哪个模块，这个模块之前踩过什么坑，哪个任务卡住了，哪些信息是敏感的，哪些操作要审批，谁有权限查看，什么时候该提醒，什么时候该交给人工。

普通 agent 更像临时工，你给它一个任务，它做一次；workspace agent 更像岗位助手，它长期待在一个工作空间里，懂流程、权限、上下文和协作关系。你让一个普通 agent 帮你 review 一个 PR，它可能会反过来问你：这个模块是谁维护的、之前有没有出过类似的问题、这次改动要重点关注哪里？因为它不知道你的团队里发生了啥。但一个 workspace agent 不一样，它已经在你的工作空间里，能看代码提交历史、issue 记录、之前的 review 意见、CI 状态，也能看谁最近改过这块代码，所以它能直接给出有针对性的意见：哪块改动跟历史 bug 有关联、哪个函数复杂度已经超标、哪些分支的测试覆盖还不够。

这就不是普通聊天机器人了，它开始走进组织的工作空间。所以 workspace agent 的重点不只是「更智能」，它真正代表的是一种产品形态的变化：AI 不再只是你临时打开的一个工具，它开始变成团队工作空间里长期存在的一类角色——AI 代码审查助理、AI 测试助理、AI 发布助理、AI 研发助理，它们不再只是回答问题，而是长期处理某一类工作，并且跟团队流程绑在一起。

当然这件事也特别难，因为一旦 AI 进入工作空间，就会碰上更多现实问题：权限和数据怎么隔离，不同成员看到的信息不一样怎么办，AI 给的建议错了谁负责，什么时候自动执行、什么时候必须人来确认，它长期记住的信息哪些该留、哪些该过期。所以 workspace agent 不只是一个更酷的 agent，它背后其实是流程和组织管理的问题，这也是为什么它会成为 AI 落地里的一个重要方向。

---

捋到这儿再回头看开头那种「跟不上」的烦躁，好像没那么焦虑了——不是因为词变少了，而是发现它们本来就不是并列的知识点，是一条有先后顺序的因果链，记住这条链，比背下每个缩写管用得多。当然，过两个月大概率又会冒出几个新词把这条链继续拉长，到时候大概还得再捋一遍。