先用一句话概括他们是什么
小明通过 Vibe Coding 用自然语言提出“做一个记账网站”的需求，这个需求变成 Prompt 进入 LLM，在 Context Window 中理解后，通过 RAG 补充知识，再借助 Tool / MCP 获取外部能力，由 Agent Team 分工协作，内部通过 SubAgent 拆解任务，使用 Skill 完成功能实现，按照 Workflow 有序执行，并由 LangChain 进行工程化编排，最终通过 API 输出成一个真正可用的应用。
接下来我们一个一个说
- OpenAI的GPT-5.4
- Anthropic的Claude 4系列
- Google的Gemini
- 国内的话有文心、通义、混元等等
Context Window翻成"上下文窗口,就是AI单次能处理的最大Token数量.
这个数字非常重要.你跟AI的对话历史,你上传的文件,你给它的系统设定,全得塞进这个窗口里。塞不下的就被截断.
现在主流模型的Context对比：
工程实践里面,Context管理是个很重要的课题.超过几十轮的对话就得考虑怎么压缩或者截断，否则有效信息反而被"挤"掉了.
写Prompt这事真的得练。同一件事，prompt怎么写，决定了AI是给你精品还是给你一堆废话。
Chat本质上就是在LLM外面包了一层对话界面，让普通人能直接用.
Chatbot这个词就是这种交互形式的了统称,没什么神秘的.
RAG解决的是LLM的两个固有问题：知识有截止日期、不知道私有内容。
RAG应用现在遍地开花，企业知识库问答,客服系统,文档智能检索,用的都是这个.
- 读取代码文件
- 运行ESLint做静态分析
- 做安全扫描
- 生成审查报告
- 输出改进建议
有些事你经常做，比如下载PDF→翻译成中文→保存成Word。每次让Agent从头想，又慢又费钱，调用LLM要花token，按字收费。
对比一下：
- 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 会这样拆：
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的区别
LangChain 就是一个专门用来搭建 AI 应用的框架，帮你把这些能力组织起来。
它主要解决三件事：
- 封装 LLM 调用（不同模型统一接口）
- 提供 RAG 能力（embedding、检索、向量库）
- 支持 Agent 和 Workflow 编排
LangChain,Skill,Workflow对比
程序员直接写代码，用LangChain框架把流程写死，稳定但不灵活。
不会代码的，用Workflow工作流，像搭积木一样拖拽，简单但还是不够灵活。
想又灵活又省事？用Skill技能。
- OpenAI（GPT系列）
- Anthropic（Claude系列）
- Google（Gemini）
- 国内：文心、通义、混元
调用方式都是RESTful API，发HTTP请求，传JSON参数，没多复杂。
MCP是Anthropic提出的开放协议，全称Model Context Protocol。
解决的问题是：以前AI连接外部工具，每个组合都得单独开发。N个AI乘M个工具，是N乘M的工作量。
MCP搞了个统一标准：
- 传统：每个AI × 每个工具 = N×M次开发
- MCP：每个工具实现一次MCP → 所有支持MCP的AI都能用
这就像USB接口统一了各种外设一样，一次开发，到处使用。
- @聊天：基于整个项目上下文
- Cmd+K：跨文件编辑
- 自动代码生成和解释
用Cursor写代码真的快很多。尤其是不熟悉的语言或者框架，让AI先跑一遍，自己再 review 就行。
- 想清楚要什么（产品设计）
- 描述清楚需求
- Review AI生成的代码
- 做决策
AI负责：
- 代码实现
- 语法正确性
- 基础测试
现在很多非程序员都在用这个方式做自己的小工具、产品原型。门槛真的降低了很多。
AI 应用开发的核心知识体系其实可以压缩成一条清晰的分层结构：
地基打好了，上层怎么变化都能跟上。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/272090.html