企业官网建设流程全解析

最近刷科技新闻，你大概率会频繁碰到这几个词：LLM、Agent、MCP、Skills……
它们频频出现在各类技术文章和AI产品发布会上，几乎成了AI行业的必修词汇，很多人会将它们混为一谈，但其实它们不是同一类东西。
今天我们就一次性把这这些概念讲明白，看懂 AI 是如何从只会聊天，一步步变成能独立完成任务的~

先用一句话概括他们是什么

小明通过 Vibe Coding 用自然语言提出“做一个记账网站”的需求，这个需求变成 Prompt 进入 LLM，在 Context Window 中理解后，通过 RAG 补充知识，再借助 Tool / MCP 获取外部能力，由 Agent Team 分工协作，内部通过 SubAgent 拆解任务，使用 Skill 完成功能实现，按照 Workflow 有序执行，并由 LangChain 进行工程化编排，最终通过 API 输出成一个真正可用的应用。

接下来我们一个一个说

一.基础层

1.1 LLM.大语言模型

LLM是整个AI世界的核心，这点没什么好说的。它通过海量文本数据训练，获得了理解和生成语言的能力。
现在主流的 LLM 有很多

• OpenAI的GPT-5.4
• Anthropic的Claude 4系列
• Google的Gemini
• 国内的话有文心、通义、混元等等

不同LLM擅长不同场景，选型的时候得看具体需求。比如Claude写代码能力强，GPT-4综合能力强等等。
有个概念得搞清楚：LLM本身只是"脑子"，上面还得套壳才能变成产品。ChatGPT、Claude这些产品，就是LLM加了一层UI，让你普通人能直接用。

1.2 Token.计量和处理的基本单元

AI处理文本的方式跟人不一样的。它会把所有内容切成小块，每块叫一个Token。
大概的换算关系是：

英文：1 Token ≈ 4个字符
中文：1 Token ≈ 1-2个汉字

API调用是按Token数收钱的.你发的越长,花的越多。还有Context Window这个限制，超过上限的内容会被直接截断.
写代码的时候一般会用tiktoken这种库来算Token数，提前知道自己发了多少.

1.3 Context Window,AI的内存

Context Window翻成"上下文窗口,就是AI单次能处理的最大Token数量.

这个数字非常重要.你跟AI的对话历史,你上传的文件,你给它的系统设定,全得塞进这个窗口里。塞不下的就被截断.

现在主流模型的Context对比：

工程实践里面,Context管理是个很重要的课题.超过几十轮的对话就得考虑怎么压缩或者截断，否则有效信息反而被"挤"掉了.

二.交互层

2.1 Prompt写的好不好直接决定输出质量

Prompt就是你给LLM的输入。Prompt Engineering已经成为AI应用开发的基础技能。
核心原则就那么几个：
第一，清晰。你到底要什么，说清楚，别让AI猜。
第二，具体。给够上下文，包括背景、格式要求、长度限制这些。
第三，结构化。用分隔符、列表这些把内容组织好，AI更容易理解。
第四，迭代。别想着一遍就写好，基于输出持续调优。
常见模式有这么几种：

Zero-shot：直接给任务，不给示例
Few-shot：给几个示例，让AI学习 pattern
Chain-of-thought：引导AI一步步推理

写Prompt这事真的得练。同一件事，prompt怎么写，决定了AI是给你精品还是给你一堆废话。

2.2 Chat/Chatbot 就是LLM的UI壳子

Chat本质上就是在LLM外面包了一层对话界面，让普通人能直接用.

Chatbot这个词就是这种交互形式的了统称,没什么神秘的.

三.能力层

3.1 RAG,检索增强生成

RAG解决的是LLM的两个固有问题：知识有截止日期、不知道私有内容。

原理很简单：
用户提问 → 去外部知识库检索相关内容 → 塞进Context → LLM基于这些参考资料生成答案

RAG的几个核心组件：
Embedding模型，负责把文本变成向量。向量数据库，负责存储和检索这些向量。检索策略，决定怎么找到最相关的内容.

RAG应用现在遍地开花，企业知识库问答,客服系统,文档智能检索,用的都是这个.

3.2 Tool,让LLM能操作外部世界

LLM以前只能"说话"，Tool给了它"动手"的能力。
比如：

搜索工具：让AI能查实时信息
日历工具：让AI能看和创建日程
邮件工具：让AI能发邮件
数据库工具：让AI能查数据

Function Calling就是让LLM判断什么时候该调用哪个工具、传什么参数的技术。
调用链路大概是这样的：LLM分析用户意图 → 决定需要调用哪个Tool → 生成调用参数 → 执行 → 把结果整合进回答。

3.3 Skill,封装好的流程

Skill就是把"怎么做一件事"的流程固化下来打包，让AI每次都按这个流程执行。
比如一个"代码审查Skill"，可能包含这些步骤：

• 读取代码文件
• 运行ESLint做静态分析
• 做安全扫描
• 生成审查报告
• 输出改进建议

有些事你经常做，比如下载PDF→翻译成中文→保存成Word。每次让Agent从头想，又慢又费钱，调用LLM要花token，按字收费。

3.4 Agent,自主规划执行

Agent是现在最火的概念。
本质上就是：给AI一个目标，AI自己制定计划、调用工具、执行任务、中间可能反思和调整、直到达成目标。

对比一下：

• Chat：你问，它答
• Agent：你说"帮我整理会议纪要并发给同事"，它会自动读邮件、整理内容、写邮件、确认收件人、点击发送

Agent的典型架构大概是这样的:

Agent ├── LLM（大脑） ├── Memory（记忆） ├── Tools（工具集） ├── Planning（规划） └── Reflection（反思）

现在做Agent的框架很多，LangChain、AutoGPT、还有Claude自己的Agent SDK。选哪个看具体需求。

3.4.1 SubAgnet,子任务执行者

在复杂任务中，单个 Agent 往往不够用。

这时候 Agent 会把任务拆解，然后交给多个 SubAgent（子执行单元） 去并行处理。

可以理解为：

• Agent：项目经理
• SubAgent：外包团队 / 小组成员

举个例子
比如用户说：

“帮我写一个电商系统设计方案”

Agent 会这样拆：

SubAgent1：数据库设计
SubAgent2：接口设计
SubAgent3：权限系统设计
SubAgent4：前端结构设计

Agent 汇总所有 SubAgent 的结果 → 输出完整方案

3.4.2 Agent Team,多Agent协作系统

当任务复杂度继续提升时，单个 Agent 已经不够用了。

于是系统会引入 Agent Team（智能体团队）.

可以把 Agent Team 看成一个“小公司”：

• 不同 Agent 扮演不同角色
• 每个 Agent 有自己的职责范围
• 由一个 Coordinator（主 Agent）统一调度

一个典型分工

• Research Agent：负责查资料（RAG）
• Coding Agent：负责写代码
• Planning Agent：负责拆解任务
• Review Agent：负责检查结果

工作流程如下:

用户需求 ↓ Coordinator Agent（总控） ↓ 分发任务给多个 Agent ↓ 各 Agent 并行执行 ↓ 汇总结果 ↓ 输出最终答案

Agent Team, SubAgent以及Workflow的区别

3.5 Workflow,流程编排

Agent 解决的是“一个任务怎么完成”，但在真实场景中，往往是多个步骤组成一个完整流程，这时候就需要 Workflow。
Workflow 本质上就是：把多个 AI 能力按顺序串起来。
有些事你经常做，比如下载PDF→翻译成中文→保存成Word。每次让Agent从头想，又慢又费钱，调用LLM要花token，按字收费。

能不能把流程固定？当然可以。
比如一个典型流程：

用户提问
→ RAG 检索资料
→ LLM 总结内容
→ 调用 Tool 生成结果
→ 输出最终答案

3.6 LangChain,AI应用开发框架

LangChain 就是一个专门用来搭建 AI 应用的框架，帮你把这些能力组织起来。

它主要解决三件事：

• 封装 LLM 调用（不同模型统一接口）
• 提供 RAG 能力（embedding、检索、向量库）
• 支持 Agent 和 Workflow 编排

LangChain,Skill,Workflow对比

程序员直接写代码，用LangChain框架把流程写死，稳定但不灵活。

不会代码的，用Workflow工作流，像搭积木一样拖拽，简单但还是不够灵活。

想又灵活又省事？用Skill技能。

四.技术层

4.1 API,AI能力的出口

API是标准化的软件接口，这个搞开发的肯定熟悉。
AI API就是让你在自己的应用里面调用AI能力的通道。不用自己训练模型，按用量付费，接上就能用。
主流AI API提供商：

• OpenAI（GPT系列）
• Anthropic（Claude系列）
• Google（Gemini）
• 国内：文心、通义、混元

调用方式都是RESTful API，发HTTP请求，传JSON参数，没多复杂。

4.2 MCP,新兴的协议标准

MCP是Anthropic提出的开放协议，全称Model Context Protocol。

解决的问题是：以前AI连接外部工具，每个组合都得单独开发。N个AI乘M个工具，是N乘M的工作量。

MCP搞了个统一标准：

• 传统：每个AI × 每个工具 = N×M次开发
• MCP：每个工具实现一次MCP → 所有支持MCP的AI都能用

这就像USB接口统一了各种外设一样，一次开发，到处使用。

4.3 AI+IDE,开发新范式

Cursor是第一个真正意义上的AI原生IDE，内置了GPT-4和Claude。
几个核心功能：

• @聊天：基于整个项目上下文
• Cmd+K：跨文件编辑
• 自动代码生成和解释

用Cursor写代码真的快很多。尤其是不熟悉的语言或者框架，让AI先跑一遍，自己再 review 就行。

4.4 Vibe Coding,自然语言驱动开发

核心思路：你描述你想要什么，AI生成代码。
你的角色从"打字员"变成了"产品经理+评审"。
你负责：

• 想清楚要什么（产品设计）
• 描述清楚需求
• Review AI生成的代码
• 做决策

AI负责：

• 代码实现
• 语法正确性
• 基础测试

现在很多非程序员都在用这个方式做自己的小工具、产品原型。门槛真的降低了很多。

实战串联

拿企业智能助手这个场景举例：
用户说：“帮我查一下Q1销售数据，做成PPT”
Agent接管之后大概会这样执行：
第一步，规划。拆解成几个子任务——查数据、分析数据、生成PPT内容。
第二步，Tool调用。用数据库查询Tool拿到Q1销售数据。
第三步，RAG检索。查一下有没有历史销售报告模板或者分析框架可以参考。
第四步，LLM处理。分析数据，提取关键洞察。
第五步，Skill执行。调用PPT生成Skill，按模板填充内容。
第六步，返回结果。
整个过程用户只说了一句话。

简要概括

总结

AI 应用开发的核心知识体系其实可以压缩成一条清晰的分层结构：

LLM 是核心引擎——决定整个系统的智能上限，需要理解它的能力边界（上下文、推理能力、幻觉问题等）。
Prompt 是交互接口——所有能力调用的入口，本质是“如何正确指挥模型”。
RAG / Tool / Skill 是能力扩展层——RAG负责补知识，Tool负责连外部世界，Skill负责封装可复用能力，让模型从“会说”变成“能做”。
Agent 是执行进化层——从单次问答升级为目标驱动的任务执行者，能够规划、拆解、调用工具并完成闭环。
Workflow / Agent Team / SubAgent 是系统组织方式——解决复杂任务的结构化编排与分工协作问题。
API / MCP 是基础设施层——统一连接模型、工具与外部系统，是AI应用真正落地的工程接口。
LangChain 等框架是工程封装层——把上述能力标准化、模块化，降低构建复杂AI系统的成本。
Vibe Coding 是开发范式——改变人和AI的协作方式，让自然语言成为新的“编程语言”。

地基打好了，上层怎么变化都能跟上。