11-大模型智能体开发工程师：Agent概念起源与发展历程
系列文章导航：AI系列文章导航目录-持续更新中
第11课：Agent概念起源与发展历程
📝 本文摘要：本文从"什么是Agent"出发，梳理Agent概念从哲学到AI的演变，然后深度解析LLM Agent发展史上每一个关键项目和事件——它为什么出现、做了什么、结果如何、现状怎样。涵盖ReAct、AutoGPT、BabyAGI、MetaGPT、Function Calling、Devin、SWE-Agent、OpenHands、Manus、Claude Code、Cursor Agent、MCP协议、A2A协议等。最后讲解Agent的核心架构模式。
从这节课开始，你进入最核心的领域——Agent智能体。理解Agent的本质和发展脉络，你才能理解后面所有技术为什么是这样设计的。
一、什么是Agent
1.1 最简定义
一句话理解：Agent就是一个"能自己做事"的AI。普通LLM只能聊天，Agent能规划、执行、检查，直到任务完成。
Agent = LLM + 自主决策 + 工具使用
与普通LLM应用的区别:
普通应用: 用户问 → LLM答 → 结束（一问一答）
Agent: 用户给目标 → Agent规划 → 选择工具 → 执行 → 观察 → 继续 → 完成目标
关键区别:
普通应用是"一次性"的，用户问一句就回答一句
Agent是"多步骤"的，会自己循环执行直到任务完成
1.2 Agent的核心特征
1. 自主性（Autonomy）: 能独立做决策，不需要每步都问人
2. 感知性（Perception）: 能获取环境信息（通过工具、检索等）
3. 行动性（Action）: 能执行操作（调API、写代码、发邮件等）
4. 目标导向（Goal-oriented）: 以完成目标为终点，不是以一次回答为终点
5. 迭代性（Iterative）: 能循环"思考-行动-观察"，直到目标完成
1.3 一个类比
这个类比非常重要，记住它你就能理解后面所有内容：
普通LLM: 顾问（你说一句，他回一句，不会主动做事）
Agent: 员工（你给一个任务，他自己规划、执行、汇报）
好的Agent = 好的员工
- 理解任务（理解目标）
- 制定计划（任务分解）
- 选择方法（工具选择）
- 执行操作（工具调用）
- 检查结果（自我验证）
- 遇到问题会调整（动态规划）
- 知道什么时候该问人（边界意识）
坏的Agent = 坏的员工
- 不理解任务就动手（盲目执行）
- 没有计划就乱做（无规划）
- 同样的错误反复犯（不反思）
- 永远不停下来（死循环）
- 超出权限做事（安全问题）
二、Agent概念的历史渊源
2.1 哲学源头
亚里士多德 (公元前384-322)
→ "实践推理"（Practical Reasoning）
→ 人通过"思考做什么"和"执行行动"来实现目标
→ 这就是Agent的"推理-行动"循环的原型
笛卡尔 (1596-1650)
→ "我思故我在"
→ 思考是智能的本质 → Agent的核心就是"思考"
图灵 (1950)
→ 《计算机器与智能》
→ 图灵测试: 机器能否表现出与人类不可区分的智能？
→ 这是最早的"Agent评估"思想
2.2 AI领域的Agent概念演变
1995 Stuart Russell & Peter Norvig《人工智能: 一种现代方法》
定义了四种Agent类型:
1. 简单反射Agent（Simple Reflex Agent）
感知 → 规则 → 行动（没有记忆）
2. 基于模型的Agent（Model-Based Agent）
感知 → 更新内部状态 → 规则 → 行动（有记忆）
3. 基于目标的Agent（Goal-Based Agent）
感知 → 目标 → 搜索规划 → 行动（有目标）
4. 基于效用的Agent（Utility-Based Agent）
感知 → 评估效用 → 选择最优 → 行动（有偏好）
今天的LLM Agent = 基于目标的Agent + 基于效用的Agent
2.3 从传统Agent到LLM Agent
传统Agent (1995-2022):
规则/搜索驱动 → 有限领域 → 可靠但死板
例: 国际象棋AI（Deep Blue）、路径规划（A*算法）、游戏AI（AlphaGo）
特点: 人类把"怎么做决策"的规则写死在代码里
→ 只能处理规则覆盖到的情况
→ 遇到新情况就傻了
LLM Agent (2023-至今):
语言模型驱动 → 开放领域 → 灵活但不可靠
例: AutoGPT、Devin、Manus、Claude Code
特点: 用LLM的"推理能力"代替人写的规则
→ 能处理从未见过的新情况
→ 但可能"推理错误"导致做错事
关键区别:
传统Agent: 人写规则 → 机器执行（可靠但死板）
LLM Agent: 机器自己推理 → 机器执行（灵活但不可靠）
这就是为什么Agent开发的核心挑战是"可靠性"——
如何让一个"会犯错的推理引擎"可靠地完成任务？
三、LLM Agent发展史：深度解析每一个关键事件
这一节是本文的核心。我会把每个关键项目/事件讲透——它为什么出现、做了什么、结果如何、对后来有什么影响。
3.1 理论奠基期（2022）
3.1.1 ReAct论文（2022.10）⭐⭐⭐
背景：2022年，GPT-3已经展示了强大的推理能力（Chain-of-Thought），但有两个问题：
- 纯推理容易"胡说"——模型在脑子里想，但不去验证，容易产生幻觉
- 纯行动没有规划——直接让模型调工具，但它不知道为什么要调、调完之后该干嘛
做了什么：普林斯顿大学的Yao等人提出了ReAct（Reasoning + Acting）框架——让模型交替进行推理和行动：
传统方式1: 纯推理（Chain-of-Thought）
Think → Think → Think → Answer
问题: 没有外部信息验证，容易幻觉
传统方式2: 纯行动（Act-only）
Action → Action → Action → Answer
问题: 没有规划，盲目执行
ReAct方式: 推理+行动交替
Think → Action → Observe → Think → Action → Observe → Answer
优势: 每次行动前先想清楚为什么，行动后观察结果再决定下一步
结果：在多个基准测试上，ReAct显著优于纯推理和纯行动。更重要的是，它提供了一个通用范式——后来几乎所有Agent框架都是ReAct的变体。
现状与影响：ReAct已成为Agent的"基本操作系统"。你今天用的任何Agent产品（Cursor、Claude Code、Manus），底层都是ReAct循环的某种变体。
为什么重要：这篇论文回答了一个根本问题——"AI应该怎么做事？"答案是：像人一样，边想边做。
3.1.2 Toolformer论文（2023.02）
背景：LLM的知识有截止日期，不能访问实时信息，也不擅长精确计算。能不能让模型自己学会"什么时候该用工具"？
做了什么：Meta AI的研究团队训练了一个模型，让它自己决定何时插入工具调用。比如遇到数学题就调计算器，遇到时事问题就调搜索引擎。
结果：证明了LLM可以学会"自主使用工具"，而不需要人类在每个场景都手动编排。
影响：这为后来的Function Calling和Tool Use奠定了理论基础——模型不只是被动地被告知"你有这些工具"，而是能主动判断"我现在需要用工具"。
3.2 狂热探索期（2023.03-2023.06）
3.2.1 AutoGPT（2023.03）⭐⭐
背景：GPT-4刚发布（2023.03），能力惊人。一个叫Toran Bruce Richards的开发者想：既然GPT-4这么聪明，能不能让它完全自主——自己给自己定目标、自己规划、自己执行？
做了什么：AutoGPT是第一个"全自主AI Agent"——你只需要给它一个高层目标（比如"帮我研究并写一篇关于电动车市场的报告"），它就会：
- 自己分解任务
- 自己搜索信息
- 自己写内容
- 自己检查质量
- 自己决定下一步
AutoGPT的工作流:
用户: "研究电动车市场并写报告"
Agent自己的循环:
Thought: 我需要先了解电动车市场的现状
Action: 搜索"2023年全球电动车市场规模"
Observe: [搜索结果]
Thought: 接下来我需要了解主要玩家
Action: 搜索"电动车市场份额 特斯拉 比亚迪"
Observe: [搜索结果]
... (可能循环几十次)
Action: 写文件"电动车市场报告.md"
Done!
结果：
- 🔥 GitHub上2周获得10万+星标，成为增长最快的开源项目之一
- ❌ 实际使用体验很差：
- 经常陷入死循环（反复搜索同样的东西）
- 偏离目标（本来要写报告，跑去研究不相关的话题）
- 成本失控（一个任务可能花费几十美元的API费用）
- 质量低下（生成的内容往往不如人类直接写）
教训（极其重要）：
AutoGPT证明了一个核心教训:
"完全自主" ≠ "有用"
没有约束的自主性是灾难。就像一个没有经验的实习生，
你让他"自己想办法完成"，他可能忙活一天什么都没做好。
好的Agent需要:
1. 明确的边界（什么能做什么不能做）
2. 人类监督（关键节点需要确认）
3. 成本控制（不能无限循环）
4. 质量检查（输出要有标准）
现状：AutoGPT项目仍在维护，但已经从"全自主"转向了更务实的方向。它的历史意义在于：点燃了全世界对AI Agent的想象力，同时也用失败教育了整个行业"什么不该做"。
3.2.2 BabyAGI（2023.04）
背景：AutoGPT太复杂了，有人想做一个更简单的版本来验证"AI自主完成任务"的可行性。
做了什么：Yohei Nakajima（一位风险投资人）用不到100行Python代码实现了一个极简Agent：
- 维护一个任务队列
- 每次取出优先级最高的任务
- 用GPT-4执行任务
- 根据执行结果生成新任务
- 循环
# BabyAGI的核心逻辑（伪代码）:
task_queue = ["研究电动车市场"]
while task_queue:
task = task_queue.pop(0) # 取出任务
result = gpt4.execute(task) # 执行
new_tasks = gpt4.generate_tasks(result) # 生成新任务
task_queue.extend(new_tasks) # 加入队列
task_queue = gpt4.prioritize(task_queue) # 重新排序
结果：同样的问题——无限生成新任务，永远停不下来，成本失控。
教训：简单不等于有效。Agent需要的不是更简单的循环，而是更好的"停止条件"和"质量判断"。
现状：作为教学项目仍有价值，让人理解Agent的最小实现。但没有实际生产价值。
3.2.3 MetaGPT（2023.06）⭐
背景：AutoGPT和BabyAGI都是"单Agent"，一个Agent做所有事。但人类社会不是这样运作的——公司里有产品经理、架构师、程序员、测试，各司其职。能不能让多个Agent模拟一个软件公司？
做了什么：MetaGPT（由DeepWisdom团队开发）模拟了一个软件开发团队：
MetaGPT的多Agent架构:
用户需求: "做一个贪吃蛇游戏"
↓
[产品经理Agent] → 输出PRD（产品需求文档）
↓
[架构师Agent] → 输出系统设计、API设计
↓
[程序员Agent] → 输出代码
↓
[测试Agent] → 输出测试用例、运行测试
↓
[最终产品]
结果：
- ✅ 比单Agent效果好很多——因为每个Agent有明确的角色和输出格式
- ✅ 引入了"标准化操作流程"（SOP）的概念——Agent之间通过文档交接，而不是自由对话
- ❌ 仍然不够可靠，复杂项目容易出错
- ❌ 成本高（多个Agent = 多次LLM调用）
影响：MetaGPT证明了"多Agent协作"比"单Agent包打天下"更有效。它的核心洞察是：给Agent明确的角色和标准化的交接流程，比让Agent自由发挥更可靠。这个思想影响了后来所有多Agent框架。
现状：仍在活跃开发，GitHub 45K+星标。作为多Agent框架的先驱，学术价值大于实用价值。
3.2.4 OpenAI Function Calling（2023.06）⭐⭐⭐
背景：在Function Calling之前，让LLM调用工具的方式是这样的：
# 之前的"Prompt Hacking"方式:
system_prompt = """
你有以下工具可用:
- search(query): 搜索互联网
- calculator(expression): 计算数学表达式
当你需要使用工具时，请输出以下格式:
<tool_call>
{"name": "search", "arguments": {"query": "xxx"}}
</tool_call>
"""
# 问题:
# 1. 模型经常输出格式错误（少个引号、多个逗号）
# 2. 模型有时候"忘记"自己有工具可用
# 3. 模型有时候在不该用工具的时候用工具
# 4. 解析输出需要复杂的正则表达式，容易出错
做了什么：OpenAI在GPT-3.5/GPT-4的API中原生支持了Function Calling——你在API请求中声明可用的函数，模型会在需要时结构化地输出函数调用：
# Function Calling方式（结构化、可靠）:
response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
tools=[{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
}
}
}
}]
)
# 模型返回结构化的工具调用（不是自由文本，而是JSON）:
# tool_calls: [{"function": {"name": "get_weather", "arguments": '{"city": "北京"}'}}]
结果：Agent的可靠性大幅提升。从"靠Prompt骗模型输出特定格式"变成了"模型原生支持结构化工具调用"。
为什么这是关键转折点：
Function Calling之前: Agent可靠性 ≈ 60-70%（格式经常出错）
Function Calling之后: Agent可靠性 ≈ 90-95%（结构化输出，几乎不出格式错误）
这不是渐进式改进，而是质变。
它让Agent从"玩具"变成了"可以用于生产"的东西。
现状：Function Calling（现在更常叫Tool Use）已成为所有主流模型的标配能力。OpenAI、Anthropic、Google、DeepSeek都支持。这是Agent开发的基础设施。
3.3 工程化落地期（2023.07-2024.06）
3.3.1 LangChain Agent（2023年持续迭代）
背景：有了ReAct理论和Function Calling能力，开发者需要一个框架来快速构建Agent，而不是每次都从零写。
做了什么：LangChain提供了Agent的工程化封装：
- 预置了ReAct、Plan-and-Execute等Agent模式
- 封装了各种工具（搜索、计算、代码执行等）
- 提供了记忆管理（对话历史、长期记忆）
- 支持多种LLM后端
结果：
- ✅ 大幅降低了Agent开发门槛
- ❌ 过度抽象，调试困难（"黑盒"问题）
- ❌ 性能开销大，不适合生产环境
- ❌ API频繁变动，学习成本高
现状：LangChain仍是最流行的Agent框架之一，但争议很大。很多资深开发者选择自己实现Agent循环（因为核心逻辑其实很简单），而不是依赖LangChain的重抽象。
对初学者的建议：了解LangChain的概念有助于理解Agent架构，但不建议在生产中重度依赖它。后面的课程会教你如何从零实现Agent。
3.3.2 GPTs / Custom GPTs（2023.11）
背景：OpenAI想让非技术用户也能创建Agent。
做了什么：GPTs允许用户通过自然语言对话来"配置"一个Agent——设定它的角色、知识库、可用工具，然后发布给其他人使用。
结果：
- ✅ 极大降低了Agent创建门槛（不需要写代码）
- ❌ 能力有限（只能用OpenAI预置的工具）
- ❌ 商业模式不清晰（GPT Store没有成功）
- ❌ 对开发者来说太受限
影响：GPTs证明了"Agent配置化"的方向是对的，但"一刀切"的平台化方案不够灵活。真正的Agent需要能连接任意外部系统。
3.3.3 多Agent框架涌现（2024.01-2024.06）
这个时期，大量多Agent框架出现：
CrewAI（2024.01）：
- 定位：简单易用的多Agent协作框架
- 核心概念：Agent有角色（Role）、目标（Goal）、工具（Tools），多个Agent组成Crew协作
- 现状：社区活跃，适合快速原型
AutoGen（Microsoft，2023.09）：
- 定位：微软研究院出品，支持多Agent对话式协作
- 核心概念：Agent之间通过"对话"协作，支持人类参与
- 现状：学术界常用，工程实践中较重
对比：
框架选择指南:
快速原型/简单场景 → CrewAI
学术研究/复杂对话 → AutoGen
生产环境/需要控制 → 自己实现（推荐）
为什么推荐自己实现？
因为Agent的核心循环很简单（后面课程会教），
框架带来的抽象层反而增加了调试难度和不可控性。
3.4 编程Agent爆发期（2024.03-2024.12）⭐⭐⭐
这是Agent发展史上最重要的阶段之一。编程Agent证明了Agent可以在真实场景中创造巨大价值。
3.4.1 Devin（2024.03）⭐⭐
背景：之前的Agent大多是"演示性质"的——看起来很酷但实际没什么用。Cognition Labs想证明Agent可以做真正有价值的事——写代码。
做了什么：Devin号称是"世界上第一个AI软件工程师"。它可以：
- 理解GitHub Issue
- 规划解决方案
- 写代码
- 运行测试
- 修复Bug
- 提交PR
它有自己的"电脑环境"——浏览器、终端、代码编辑器，像一个真正的程序员一样工作。
结果：
- 🔥 发布时引起巨大轰动，被认为"程序员要失业了"
- ❌ 实际测试后发现：
- 在SWE-bench（软件工程基准测试）上解决率约14%（当时）
- 只能处理简单的、定义明确的任务
- 复杂任务经常失败
- 定价昂贵（$500/月）
- ✅ 但它证明了方向是对的——AI可以做端到端的编程任务
影响：Devin引爆了"编程Agent"赛道。之后大量竞品出现。
现状（2026）：Devin仍在运营，能力持续提升，但已不是唯一选择。市场上有大量更好的替代品。
3.4.2 SWE-Agent（2024.04）⭐
背景：Devin是闭源商业产品，学术界需要一个开源的、可研究的编程Agent。
做了什么：普林斯顿大学（又是他们！ReAct也是他们的）开发了SWE-Agent：
- 开源的编程Agent
- 专门针对GitHub Issue修复
- 设计了一套"Agent-Computer Interface"（ACI）——让Agent更高效地与代码环境交互
SWE-Agent的核心创新: Agent-Computer Interface (ACI)
传统方式: 让Agent直接用bash命令操作文件
→ 容易出错（路径错误、权限问题等）
SWE-Agent方式: 设计专门的命令集给Agent用
→ open_file(path) 打开文件
→ goto_line(n) 跳到第n行
→ edit(start, end, content) 编辑指定行
→ search(pattern) 搜索代码
这些命令比原始bash更"Agent友好"——
减少了Agent犯错的机会，提高了成功率。
结果：在SWE-bench上达到了12.5%的解决率（当时接近Devin）。
影响：SWE-Agent的核心贡献不是性能数字，而是ACI的设计理念——为Agent设计专门的交互接口，比让Agent用人类的接口更有效。这个思想影响了后来所有编程Agent的设计。
现状：仍在活跃维护，是编程Agent研究的重要基线。
3.4.3 OpenHands（原OpenDevin，2024.04）⭐⭐
背景：Devin闭源且昂贵，社区想做一个开源替代品。
做了什么：OpenHands（最初叫OpenDevin，后改名避免法律问题）是一个开源的通用Agent平台：
- 提供完整的沙箱环境（Docker容器）
- Agent可以写代码、运行命令、浏览网页
- 支持多种LLM后端
- 社区驱动，快速迭代
OpenHands的架构:
┌─────────────────────────────────────┐
│ 用户界面（Web UI） │
└──────────────┬──────────────────────┘
↓
┌─────────────────────────────────────┐
│ Agent Controller（控制器） │
│ - 管理Agent循环 │
│ - 处理用户交互 │
│ - 成本控制 │
└──────────────┬──────────────────────┘
↓
┌─────────────────────────────────────┐
│ Agent（可选择不同的Agent实现） │
│ - CodeAct Agent（代码执行型） │
│ - Browsing Agent（浏览器型） │
└──────────────┬──────────────────────┘
↓
┌─────────────────────────────────────┐
│ Sandbox（沙箱环境） │
│ - Docker容器 │
│ - 文件系统、终端、浏览器 │
│ - 安全隔离 │
└─────────────────────────────────────┘
结果：
- ✅ 开源社区最活跃的编程Agent项目之一
- ✅ SWE-bench成绩持续提升（2025年已超过50%）
- ✅ 支持多种模型，不绑定特定厂商
- ❌ 部署和配置相对复杂
现状（2026）：OpenHands是目前最成熟的开源Agent平台之一，GitHub 40K+星标。如果你想自己部署一个编程Agent，OpenHands是首选。
3.4.4 Cursor（2024年持续迭代）⭐⭐⭐
背景：上面说的Agent都是"独立运行"的——你给它任务，它自己去做。但程序员的日常工作不是这样的——程序员需要的是一个"坐在旁边的AI助手"，在IDE里实时协作。
做了什么：Cursor是一个AI-native的代码编辑器（基于VS Code），它把Agent能力嵌入到了编程工作流中：
- Tab补全（极快的代码补全）
- Cmd+K（选中代码，用自然语言修改）
- Chat（在编辑器里和AI对话，AI可以直接修改文件）
- Agent模式（给一个任务，Agent自动修改多个文件）
- Composer（多文件编辑）
Cursor的设计哲学:
不是: "AI替你写代码"（全自主）
而是: "AI和你一起写代码"（人机协作）
关键区别:
- Devin: 你给任务，AI自己做，做完给你看结果
- Cursor: 你和AI一起工作，每一步你都能看到、修改、确认
这就是为什么Cursor比Devin更成功——
因为它尊重了"人类需要控制感"这个基本需求。
结果：
- 🔥 2024-2025年最成功的AI编程产品，估值超过百亿美元
- ✅ 真正改变了程序员的工作方式
- ✅ 证明了"人机协作"比"全自主"更实用
影响：Cursor证明了Agent的最佳形态可能不是"全自主"，而是"嵌入到人类工作流中的智能助手"。这个洞察影响了整个行业的产品设计方向。
现状（2026）：Cursor是目前最流行的AI编程工具，几乎所有程序员都在用。
3.4.5 Claude Code（Anthropic，2025.02）⭐⭐
背景：Anthropic（Claude的开发商）看到编程Agent的巨大潜力，决定自己做一个终端里的编程Agent。
做了什么：Claude Code是一个命令行工具，你在终端里和Claude对话，它可以：
- 读取和修改你的代码文件
- 运行命令
- 搜索代码库
- 理解项目结构
- 执行复杂的多步骤编程任务
# Claude Code的使用方式:
$ claude
> 帮我把这个项目的所有console.log替换成proper logging
Claude: 我来分析一下项目结构...
[读取文件列表]
[搜索所有console.log]
[找到23处]
[逐一替换为logger调用]
[运行测试确认没有破坏]
Done! 已替换23处console.log为structured logging。
结果：
- ✅ 与Claude模型深度集成，工具调用极其可靠
- ✅ 终端原生体验，适合高级开发者
- ✅ 支持"agentic"模式——给一个大任务，自动完成
- ❌ 只能用Claude模型（不支持其他模型）
影响：Claude Code代表了"模型厂商自己做Agent产品"的趋势——因为他们最了解自己模型的能力边界。
现状（2026）：Claude Code是专业开发者最常用的终端Agent工具之一。
3.5 通用Agent与协议标准化（2024.10-2025）
3.5.1 Claude Computer Use（2024.10）
背景：之前的Agent只能调API、写代码。但人类的很多工作是在GUI（图形界面）上完成的——点击按钮、填表单、操作软件。能不能让Agent也操作电脑？
做了什么：Anthropic发布了Computer Use功能——Claude可以看到屏幕截图，然后决定点击哪里、输入什么。
Computer Use的工作方式:
1. 给Claude一张屏幕截图
2. Claude分析截图，决定下一步操作
3. 执行操作（点击坐标、输入文字、滚动等）
4. 截取新的屏幕截图
5. 重复
就像一个远程桌面操作员——看屏幕、动鼠标键盘。
结果：
- ✅ 证明了"通用Agent"的可能性——不需要为每个软件写API集成
- ❌ 速度慢（每步都要截图+分析）
- ❌ 容易出错（GUI元素识别不准确）
- ❌ 安全风险（Agent操作你的电脑）
影响：Computer Use开启了"GUI Agent"这个新方向。虽然目前还不够成熟，但长期来看，这可能是Agent的终极形态——能操作任何软件。
3.5.2 Manus（2025.03）⭐⭐
背景：之前的Agent要么只能写代码（Devin），要么只能聊天（ChatGPT），要么需要技术背景才能用（Claude Code）。有没有一个Agent能让普通人也用起来，完成各种复杂任务？
做了什么：Manus（由中国团队Monica AI开发）是一个"通用任务Agent"：
- 有自己的虚拟电脑环境（浏览器、终端、文件系统）
- 可以上网搜索、写文档、写代码、分析数据
- 用户只需要用自然语言描述任务
- Agent自动规划和执行
Manus的典型使用场景:
用户: "帮我调研深圳南山区的3居室租房市场，
整理成Excel表格，包含价格、面积、地铁距离"
Manus:
1. 打开浏览器，搜索租房网站
2. 浏览多个房源页面
3. 提取关键信息
4. 整理成结构化数据
5. 生成Excel文件
6. 返回给用户
结果：
- 🔥 发布后引起巨大关注，被认为是"最接近通用Agent"的产品
- ✅ 用户体验好，非技术人员也能用
- ✅ 任务完成率相对较高
- ❌ 复杂任务仍然容易失败
- ❌ 速度较慢（需要等待Agent执行）
- ❌ 成本不低
影响：Manus证明了"通用Agent"是有市场需求的。它的成功在于降低了Agent的使用门槛——你不需要懂技术，只需要描述你想做什么。
现状（2026）：Manus持续迭代，是通用Agent赛道的代表产品。
3.5.3 MCP协议（Anthropic，2024.11）⭐⭐⭐
背景：Agent需要连接外部世界（数据库、API、文件系统等），但每个Agent框架都自己定义一套工具接口，导致：
- 工具不能跨框架复用
- 每接入一个新系统都要写适配代码
- 生态碎片化严重
做了什么：Anthropic提出了MCP（Model Context Protocol，模型上下文协议）——一个标准化的Agent-工具通信协议：
MCP的类比:
没有MCP之前:
每个Agent框架有自己的工具接口
就像每个网站用不同的通信协议
→ 混乱、不兼容
有了MCP之后:
所有Agent用统一的协议连接工具
就像所有网站都用HTTP协议
→ 标准化、可互操作
MCP之于Agent ≈ HTTP之于Web ≈ USB之于外设
MCP的架构:
┌──────────────┐ MCP协议 ┌──────────────┐
│ Agent/LLM │ ←──────────────→ │ MCP Server │
│ (客户端) │ │ (工具提供方) │
└──────────────┘ └──────────────┘
MCP Server可以是:
- 数据库连接器（查询MySQL、PostgreSQL）
- 文件系统访问（读写本地文件）
- API网关（调用第三方服务）
- 代码执行器（运行Python/JS）
- 浏览器控制器（操作网页）
- 任何你能想到的工具...
结果：
- 🔥 迅速被行业采纳，成为事实标准
- ✅ 大量MCP Server涌现（GitHub、Slack、数据库、搜索引擎等）
- ✅ 主流IDE和Agent产品都支持MCP（Cursor、Claude Code、VS Code等）
- ✅ 工具生态开始统一
为什么MCP如此重要：
MCP解决的核心问题: "Agent如何连接外部世界"
之前: 每个Agent产品自己实现工具连接
→ Cursor有Cursor的工具格式
→ Claude Code有Claude Code的工具格式
→ 开发者要为每个平台写不同的适配
之后: 写一个MCP Server，所有支持MCP的Agent都能用
→ 写一次，到处用
→ 工具生态可以独立发展
→ Agent和工具解耦
🔑 关键问题：MCP工具是怎么被LLM调用的？
你可能会问：MCP Server的工具，是不是也是通过Function Calling的方式被LLM调用的？
答案：是的，完全一样。 MCP没有发明新的调用机制，它复用的就是Function Calling / Tool Use这套标准流程。
┌─────────────────────────────────────────────────────────────────────┐
│ MCP工具的完整调用流程 │
│ │
│ ① Agent启动时，从MCP Server获取工具列表（tool discovery） │
│ MCP Client ──JSON-RPC──→ MCP Server │
│ MCP Server 返回: [{name: "search_docs", description: "...", │
│ inputSchema: {...}}] │
│ │
│ ② Agent把这些工具描述，和普通工具一起，塞进LLM的请求中 │
│ messages + tools: [普通工具A, 普通工具B, MCP工具C, MCP工具D] │
│ │
│ ③ LLM推理后，决定调用某个工具（可能是MCP的，也可能是普通的） │
│ LLM返回: {type: "tool_use", name: "search_docs", │
│ input: {query: "退货政策"}} │
│ │
│ ④ Agent程序（编排层）收到这个tool_use消息 │
│ - 判断这是MCP工具 → 通过MCP Client转发给对应的MCP Server │
│ - 判断这是普通工具 → 直接调用本地函数 │
│ │
│ ⑤ MCP Server执行完毕，返回结果给Agent程序 │
│ │
│ ⑥ Agent程序把结果包装成tool_result消息，回传给LLM │
│ messages: [..., {role: "tool", content: "结果..."}] │
│ │
│ ⑦ LLM根据结果继续推理（可能再调用工具，或者给出最终回答） │
└─────────────────────────────────────────────────────────────────────┘
核心要点：LLM根本不知道哪个是MCP工具
对LLM来说，所有工具长得一模一样——都是一个 {name, description, inputSchema} 的描述。LLM不知道也不关心：
- 这个工具是本地函数？
- 还是MCP Server提供的？
- 还是远程HTTP API？
这些路由逻辑全部由Agent程序（编排层）负责。LLM只负责"决定调用哪个工具、传什么参数"。
# Agent编排层的伪代码——展示MCP工具和普通工具对LLM来说没有区别
async def agent_loop(user_message):
# 1. 从MCP Server收集工具定义
mcp_tools = await mcp_client.list_tools() # [{name, description, inputSchema}]
# 2. 合并所有工具（MCP的 + 本地的），对LLM来说没有区别
all_tools = local_tools + mcp_tools
# 3. 调用LLM（LLM看到的就是一个统一的工具列表）
response = await llm.chat(
messages=[...],
tools=all_tools
)
# 4. LLM返回tool_use → Agent负责路由到正确的执行方式
if response.type == "tool_use":
tool_name = response.name
tool_input = response.input
if tool_name in mcp_tool_registry:
# MCP工具 → 通过MCP协议转发给对应的MCP Server
result = await mcp_client.call_tool(tool_name, tool_input)
else:
# 本地工具 → 直接调用本地函数
result = await local_tool_registry[tool_name](tool_input)
# 5. 把结果回传给LLM，继续推理
messages.append({"role": "tool", "content": result})
# 继续循环...
所以MCP的价值不在调用机制，而在"标准化发现与连接"：
没有MCP的世界:
每个工具都要自己写适配代码（解析API文档、处理认证、转换格式...）
工具A用REST、工具B用GraphQL、工具C用gRPC → 每个都要单独对接
有MCP的世界:
所有工具提供方都实现MCP Server接口（统一的JSON-RPC协议）
Agent只需要一个MCP Client就能连接任意MCP Server
工具的发现、描述、调用、结果返回 → 全部标准化
现状（2026）：MCP已成为Agent生态的基础设施。你后面学的MCP课程会深入讲解如何开发MCP Server。
3.5.4 Google A2A协议（2025.02）
背景：MCP解决了"Agent连接工具"的问题，但还有一个问题没解决——“Agent之间如何通信”？
做了什么：Google提出了A2A（Agent-to-Agent）协议——让不同的Agent之间可以互相发现、通信、协作：
A2A解决的问题:
场景: 你有一个"旅行规划Agent"和一个"酒店预订Agent"
没有A2A: 你需要手动编排两个Agent的协作流程
有了A2A: 旅行Agent可以自动发现并调用酒店Agent
A2A定义了:
1. Agent Card（名片）: Agent声明自己能做什么
2. 发现机制: 如何找到合适的Agent
3. 通信格式: Agent之间如何交换信息
4. 任务委托: 如何把子任务交给另一个Agent
现状：A2A还在早期阶段，尚未像MCP那样被广泛采纳。但它代表了未来的方向——Agent之间的协作将越来越重要。
3.5.5 OpenAI Agents SDK（2025.02）
背景：OpenAI看到Agent开发的需求爆发，决定提供官方的Agent开发框架。
做了什么：一个轻量级的Python SDK，帮助开发者快速构建Agent：
- 内置了Agent循环（ReAct模式）
- 支持工具调用、代码执行
- 支持多Agent编排（Handoff机制——Agent之间转交任务）
- 内置了Guardrails（安全护栏）
影响：代表了"模型厂商提供Agent开发工具"的趋势。相比LangChain等第三方框架，官方SDK与模型的集成更紧密。
3.6 推理模型驱动的Agent进化（2025）
3.6.1 DeepSeek-R1（2025.01）⭐⭐
背景：之前的Agent用的是"普通"LLM（GPT-4、Claude 3.5等）。这些模型擅长对话，但在复杂推理上有局限——它们"想"得不够深。
做了什么：DeepSeek-R1是一个专门优化了推理能力的模型。它会在回答前进行长时间的"思考"（Chain-of-Thought），把推理过程展示出来：
普通模型回答: "答案是42"（直接给结果，可能错）
推理模型回答:
<think>
让我分析一下这个问题...
首先，条件A意味着...
其次，条件B和A结合意味着...
等等，这里有个矛盾，让我重新想...
啊，我之前的假设有误，正确的推导应该是...
所以答案是42。
</think>
答案是42。（经过深思熟虑，更可靠）
对Agent的影响：
推理模型让Agent的"规划能力"质变:
之前（普通模型做Agent）:
Thought: 我搜索一下吧 ← 想得太浅，经常走错方向
之后（推理模型做Agent）:
Thought: 让我先分析这个任务...
- 目标是X
- 要达到X，我需要先知道A和B
- A可以通过工具1获取
- B需要先获取C，再推导出B
- 所以执行顺序应该是: 工具1→工具3→推导B→最终回答
← 想得更深，规划更合理
现状：推理模型（DeepSeek-R1、OpenAI o1/o3、Claude的extended thinking）已成为高质量Agent的标配。"先想清楚再动手"让Agent的成功率大幅提升。
3.6.2 Claude 4系列 / GPT-4.1（2025.05）
背景：模型厂商开始意识到，Agent是LLM最重要的应用场景。于是开始专门为Agent场景优化模型。
"为Agent优化"意味着什么：
1. 更强的指令遵循: Agent的System Prompt通常很长很复杂，
模型必须严格遵循每一条指令
2. 更可靠的工具调用: 参数格式不能出错，
该调工具时必须调，不该调时不能调
3. 更好的长上下文理解: Agent的对话历史很长
（包含大量工具调用结果），模型必须能理解
4. 更强的规划能力: 复杂任务需要多步规划
5. 更好的错误恢复: 工具调用失败时，
模型应该能理解错误并换一种方式重试
现状：2025-2026年的模型已经是"Agent-native"的——它们从设计之初就考虑了Agent场景。这就是为什么现在的Agent比2023年的AutoGPT可靠得多。
3.7 发展脉络总结
一句话总结每个阶段：
2022: 理论奠基（ReAct告诉我们Agent该怎么做）
2023上: 狂热探索（AutoGPT告诉我们什么不该做）
2023下: 基础设施（Function Calling让Agent可靠了）
2024: 编程Agent爆发（证明Agent能创造真实价值）
2025: 标准化+推理增强（MCP统一生态，推理模型提升规划）
2026: 工程化落地（如何让Agent可靠地跑在生产环境）← 你在这里
四、Agent的核心架构模式
4.1 基本循环
┌──→ Thought (思考) ──┐
│ ↓
用户目标 Action (行动)
↑ │
│ ↓
└── Observation ←─────┘
(观察结果)
循环直到:
- 目标完成
- 达到最大步数
- 遇到无法解决的问题（转交人工）
4.2 ReAct模式（Reasoning+Acting，推理+行动，最经典）
Question: 用户的问题/目标
Thought 1: 我需要先搜索相关文档
Action 1: search_docs("退货政策")
Observation 1: [检索到的文档内容]
Thought 2: 文档说7天无理由退货，但需要确认用户的订单时间
Action 2: query_order(order_id="12345")
Observation 2: 订单创建于2026-05-20，今天是2026-05-22
Thought 3: 在7天内，可以退货。我来生成退货申请
Action 3: create_refund(order_id="12345", reason="7天无理由退货")
Observation 3: 退货申请已创建，退款将在3-5个工作日内到账
Thought 4: 任务完成，回复用户
Answer: 您的退货申请已提交，订单在7天退货期内，退款将在3-5个工作日到账。
4.3 规划模式（Plan-and-Execute）
Step 1: 规划（用推理模型效果最好）
用户目标 → LLM生成执行计划（多个步骤）
例: "部署一个博客网站"
计划:
1. 选择技术栈（Next.js + Vercel）
2. 初始化项目
3. 创建首页和文章页
4. 配置部署
5. 部署并验证
Step 2: 执行
逐步执行计划中的每一步（每步可以是一个ReAct循环）
Step 3: 重规划（可选）
如果执行中发现问题，重新规划剩余步骤
优势: 全局视角，避免"走一步看一步"的盲目性
适用: 复杂多步任务（如软件开发、数据分析）
4.4 反思模式（Reflection）
在Agent循环中加入"自我反思"环节:
执行动作 → 获得结果 → 反思: 结果好不好？ → 决定是否重试
例子:
Action: 写了一段代码
Observation: 代码运行报错 "TypeError: undefined is not a function"
Reflection: 我调用了一个不存在的方法，应该查看API文档确认正确的方法名
Action: 搜索API文档，找到正确的方法名
Action: 修正代码重新运行
Observation: 测试通过 ✅
反思模式的价值:
没有反思: Agent遇到错误 → 用同样的方式重试 → 再次失败 → 死循环
有反思: Agent遇到错误 → 分析原因 → 换一种方式 → 成功
4.5 几种架构模式的本质区别与联系 ⭐⭐⭐
你可能会觉得这几种模式"长得很像"——确实如此！因为它们底层都是同一个循环。区别在于思考的深度、时机和范围不同。
核心答案：它们是同一个循环的不同"配置"
所有Agent架构的底层都是同一个循环：
感知 → 思考 → 行动 → 观察 → 思考 → 行动 → ... → 完成
区别在于三个维度：
1. 思考的"深度"（想多深）
2. 思考的"时机"（什么时候想）
3. 思考的"范围"（想当前一步还是想全局）
四种模式的本质区别
| 模式 | 思考深度 | 思考时机 | 思考范围 | 类比 |
|---|---|---|---|---|
| ReAct | 浅（一步） | 每步之前 | 只想当前这一步 | 走一步看一步 |
| Plan-and-Execute | 深（全局） | 开始时+出错时 | 想全部步骤 | 先画地图再出发 |
| Reflection | 中（回顾） | 失败之后 | 回顾已做的步骤 | 做完后复盘 |
| LATS/树搜索 | 极深（多路） | 每步之前 | 想多种可能性 | 下棋时想多步 |
用一个例子讲透区别
假设任务是：“帮我订一张明天北京到上海的机票，最便宜的”
ReAct模式（边想边做）：
Thought 1: 我需要搜索航班信息
Action 1: search_flights("北京", "上海", "明天")
Observe 1: [返回10个航班]
Thought 2: 我看到最便宜的是东航MU5101，520元，我来订它
Action 2: book_flight("MU5101")
Observe 2: 预订失败，该航班已满
Thought 3: 那我订第二便宜的，南航CZ3901，580元
Action 3: book_flight("CZ3901")
Observe 3: 预订成功！
Answer: 已为您预订南航CZ3901，580元。
特点: 每一步只想"下一步做什么"，不提前规划。遇到问题临时应对。
Plan-and-Execute模式（先规划再执行）：
=== 规划阶段 ===
Plan:
Step 1: 搜索明天北京→上海的所有航班
Step 2: 按价格排序，选最便宜的
Step 3: 检查该航班是否有余票
Step 4: 如果有票就预订，没票就选下一个
Step 5: 确认预订成功，返回结果
=== 执行阶段 ===
Execute Step 1: search_flights(...) → [10个航班]
Execute Step 2: 排序 → MU5101最便宜(520元)
Execute Step 3: check_availability("MU5101") → 无票
→ 重规划: Step 3改为选CZ3901(580元)
Execute Step 4: book_flight("CZ3901") → 成功
Execute Step 5: 返回结果
特点: 先想好所有步骤，再逐步执行。遇到问题时"重新规划"剩余步骤。
Reflection模式（做完后复盘）：
=== 第一次尝试 ===
Action: search_flights("北京", "上海", "明天") → [10个航班]
Action: book_flight("MU5101") ← 直接订最便宜的
Observe: 失败，已满
Action: book_flight("CZ3901")
Observe: 失败，支付超时
=== 评估：失败了 ===
=== 反思 ===
Reflection:
1. 我没有先检查余票就直接预订，浪费了一次尝试
2. 支付超时可能是因为我没有先确认用户的支付方式
下次应该: 先查余票 → 确认支付方式 → 再预订
=== 第二次尝试（带着反思经验） ===
Action: check_availability("CZ3901") → 有票
Action: confirm_payment_method() → 用户有绑定的信用卡
Action: book_flight("CZ3901", payment="credit_card") → 成功！
特点: 失败后不是简单重试，而是先"复盘"——分析为什么失败、下次怎么避免。
它们的联系：层层递进的关系
ReAct是基础（所有模式的底层都是ReAct循环）
│
├── + 全局规划 = Plan-and-Execute
│ （在ReAct循环外面套一层"规划"）
│
├── + 失败后复盘 = Reflection
│ （在ReAct循环外面套一层"反思"）
│
└── + 规划 + 反思 = 完整的高级Agent
（三者组合使用）
实际生产中，这三种模式是组合使用的：
简单任务(1-3步): 只用ReAct就够了
中等任务(3-7步): ReAct + Plan
复杂任务(7+步): ReAct + Plan + Reflection
一张图总结
┌─────────────────────────────────────────────────────────────┐
│ Agent架构模式关系图 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Plan-and-Execute（全局规划层） │ │
│ │ "先想好所有步骤" │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ ReAct（执行层） │ │ │
│ │ │ "每步：想→做→看" │ │ │
│ │ │ Think → Act → Observe → Think → ... │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↕ 失败时触发 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Reflection（反思层） │ │
│ │ "为什么失败？下次怎么避免？" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
什么时候用哪个？
"帮我查下天气" → ReAct（一步就完成，不需要规划）
"帮我订机票" → ReAct（2-3步，简单任务）
"帮我做一份市场调研报告" → Plan-and-Execute（需要多步规划）
"帮我修复这个复杂的Bug" → Plan + Reflection（可能失败，需要反思）
"帮我重构整个项目" → Plan + Reflection + 人工确认（复杂+高风险）
总结一句话：ReAct是"怎么做一步"，Plan是"做哪些步"，Reflection是"做错了怎么办"。它们解决的是不同层面的问题，组合起来才是一个完整的Agent。
五、Agent vs 传统软件
| 维度 | 传统软件 | Agent |
|---|---|---|
| 执行逻辑 | 确定性流程（if-else） | 动态决策（LLM推理） |
| 适应性 | 固定场景 | 开放场景 |
| 可靠性 | 高（测试覆盖） | 中（概率性，需要护栏） |
| 开发方式 | 写代码逻辑 | 设计Prompt+工具+流程 |
| 错误处理 | 预定义异常处理 | 自主判断+重试 |
| 成本 | 计算+存储 | +Token消耗（可能很贵） |
| 适合场景 | 规则明确、重复性高 | 灵活多变、规则难穷举 |
核心洞察：Agent不是要取代传统软件，而是处理传统软件难以处理的"灵活性要求高、规则难以穷举"的场景。
选择指南：
用传统软件:
- 流程固定（如订单状态机）
- 需要100%可靠（如支付系统）
- 高并发低延迟（如搜索引擎）
用Agent:
- 任务多变（如客服、代码审查）
- 需要理解自然语言（如文档分析）
- 需要灵活决策（如故障诊断）
最佳实践: 传统软件做骨架，Agent做灵活决策层
例: 工单系统（传统软件）+ 智能分派Agent（决定工单分给谁）
六、当前Agent生态全景图（2026）
┌─────────────────────────────────────────────────────────────┐
│ Agent 生态全景图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─ 模型层 ─────────────────────────────────────────────┐ │
│ │ Claude 4系列 | GPT-4.1/o3 | DeepSeek-R1 | Qwen3 │ │
│ │ (为Agent优化的基座模型) │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↕ Tool Use / Function Calling │
│ ┌─ 协议层 ─────────────────────────────────────────────┐ │
│ │ MCP (Agent↔工具) | A2A (Agent↔Agent) │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↕ │
│ ┌─ 框架层 ─────────────────────────────────────────────┐ │
│ │ OpenAI Agents SDK | LangGraph | CrewAI | 自研框架 │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↕ │
│ ┌─ 产品层 ─────────────────────────────────────────────┐ │
│ │ 编程: Cursor | Claude Code | Windsurf | Copilot │ │
│ │ 通用: Manus | ChatGPT | Claude │ │
│ │ 垂直: 客服Agent | 运维Agent | 数据分析Agent │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
📝 作业
作业1：设计一个Agent的场景
选择一个你日常工作中遇到的问题，设计一个Agent来解决。描述：
- 目标是什么
- Agent需要什么工具
- 大致的Thought-Action-Observation循环过程
参考答案：
场景: 运维告警处理Agent
目标: 接收到告警后，自动诊断问题并给出处理建议
需要的工具:
1. query_metrics: 查询监控指标
2. query_logs: 查询服务日志
3. query_deployment: 查询部署信息
4. execute_command: 执行诊断命令（受限）
5. create_ticket: 创建工单
ReAct循环:
Question: 收到告警——API服务P99延迟超过500ms
Thought 1: 先查看具体是哪个接口延迟高
Action 1: query_metrics(service="api", metric="p99_latency", group_by="endpoint")
Observation 1: /order/create 接口P99延迟1200ms，其他接口正常
Thought 2: 看看order服务的日志有没有异常
Action 2: query_logs(service="order-service", level="ERROR", last="30min")
Observation 2: 大量数据库连接超时错误: "connection pool exhausted"
Thought 3: 连接池耗尽，检查数据库实例状态
Action 3: query_metrics(service="order-db", metric="connections")
Observation 3: 活跃连接数达到最大值200，等待连接数50+
Thought 4: 数据库连接池满了，查最近的部署变更
Action 4: query_deployment(service="order-service", last="24h")
Observation 4: 2小时前部署了v2.3.1，新版本增加了批量查询接口
Thought 5: 新接口可能没有正确释放连接，创建工单
Action 5: create_ticket(
title="order-service数据库连接池耗尽",
severity="high",
description="v2.3.1部署后，新增批量查询接口可能导致连接泄漏",
suggestion="回滚v2.3.1或hotfix批量查询接口的连接释放逻辑"
)
Observation 5: 工单已创建 TICKET-20260522-001
Answer: 诊断完成。根因是v2.3.1新增的批量查询接口可能导致数据库连接泄漏。
已创建工单TICKET-20260522-001，建议回滚或hotfix。
作业2：思考题
ReAct模式中，Agent可能在什么情况下陷入死循环？如何防止？
参考答案：
死循环的典型情况：
- 工具返回空结果：Agent反复调用同一个工具，每次都得到空结果，但不知道换思路
- 格式解析失败：工具返回了结果，但Agent无法正确理解，反复重试
- 目标定义不清：Agent不确定什么算"完成"，一直在执行
- 错误不收敛：每次修复一个错误又引入新错误，无限循环
防止方法：
- 最大步数限制：设置max_iterations，超过就强制停止
- 重复检测：检测Agent是否连续做同样的Action，如果是就换策略或停止
- 明确的完成条件：在System Prompt中定义什么情况下算任务完成
- 人工兜底：超过一定步数或检测到循环时，转交人工处理
- 成本预算：设置Token消耗上限，超过就停止
作业3：对比分析
对比AutoGPT（2023）和Cursor Agent（2024-2025），分析为什么后者更成功。
参考答案：
| 维度 | AutoGPT | Cursor Agent |
|---|---|---|
| 自主程度 | 完全自主 | 人机协作 |
| 用户控制 | 几乎没有 | 每步可见可控 |
| 任务范围 | 任何任务 | 聚焦编程 |
| 可靠性 | 低（经常失败） | 高（聚焦场景优化） |
| 成本 | 不可控 | 可预测 |
| 用户体验 | 等待+祈祷 | 实时协作 |
核心原因：
- 聚焦 > 通用：Cursor只做编程，做到极致；AutoGPT什么都想做，什么都做不好
- 协作 > 自主：人类需要控制感，Cursor让你随时介入；AutoGPT让你完全失控
- 嵌入工作流 > 独立运行：Cursor在你的IDE里，无缝融入；AutoGPT是独立的，需要额外学习
- 渐进式信任 > 一步到位：Cursor从补全→编辑→Agent逐步增加自主性；AutoGPT一上来就全自主
下一篇文章见：AI系列文章导航目录-持续更新中
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
18
0- 0
已为社区贡献4条内容
所有评论(0)