这类教程最值得先看的不是功能列表，而是能不能帮你把零散的概念串成一条能跑通的链路。很多人学 AI Agent 时，容易卡在“每个词都听过，但不知道怎么连起来用”的阶段。2026年的最新进展，核心是把架构、工具调用、RAG增强和MCP协议这些模块，从理论概念变成了有明确输入、输出和判断标准的生产流程。
如果你是想自己动手搭建一个能处理实际任务的智能体，或者想理解企业里是怎么把这些技术落地的，那这篇梳理会直接告诉你每一步该准备什么、先做什么、成功长什么样、出问题该看哪里。我不会深究每个底层算法的推导，而是聚焦在“怎么把它们组装成一个能工作、可调试的系统”上。
1. 先拆解“AI Agent”到底在解决什么问题
很多人一上来就去看架构图，但更容易上手的方式是先明确你要用 Agent 干什么。它不是一个万能的黑盒，而是针对特定问题的一套自动化处理流程。
1.1 从“聊天”到“做事”的转变
传统的大模型对话，是你问一句，它答一句，答案基于训练数据。而 AI Agent 的核心是“做事”，它需要能理解复杂指令，拆解成步骤，调用外部工具（比如查数据库、发邮件、执行代码），并管理整个执行过程的状态。比如，你让它“分析上周销售数据并生成报告邮件发给经理”，这就是一个典型的 Agent 任务，它需要调用数据查询工具、分析工具、报告生成工具和邮件发送工具。
所以，判断一个场景是否需要 Agent，就看这个任务是否需要多步骤决策和与外部系统交互。如果只是简单问答，用增强后的 RAG 可能就够了；如果需要串联多个动作并处理过程中的不确定性，那就得上 Agent。
1.2 智能体的基本组成：大脑、记忆与手脚
一个可运行的 Agent 通常由几个核心模块组成，理解这些模块是后续搭建的基础：
- 大脑（推理与规划）：通常是一个大语言模型（LLM）。它负责理解用户意图、拆解任务、制定计划（Plan）和在执行中做决策（Reasoning）。这是 Agent 的“指挥官”。
- 记忆（短期与长期）：Agent 需要有记忆来保存对话历史（短期记忆）和从过往经验中学习（长期记忆）。这能让它在多轮交互中保持上下文，避免重复或矛盾。简单的实现可以用对话历史列表，复杂的会引入向量数据库来存储和检索相关经验。
- 工具（手脚）：这是 Agent 与真实世界交互的接口。工具可以是一个函数、一个 API、一个命令行程序。比如，
search_web（搜索）、execute_sql（查数据库）、send_email（发邮件）。Agent 需要知道在什么情况下调用哪个工具，并处理工具的返回结果。 - 工作流（协调器）：当任务复杂时，可能需要多个 Agent 协同（Multi-Agent），或者一个 Agent 内部有复杂的执行循环（如 ReAct 模式：思考-行动-观察）。工作流引擎负责调度这些步骤，处理分支、循环和错误。
搭建时，不要试图一次性实现所有模块。我建议先从“一个能调用简单工具的单一 Agent”开始，跑通整个循环，再逐步增加记忆、复杂工作流和多 Agent 协同。
2. 环境与工具准备：选型决定上手速度
在写第一行代码之前，选对工具栈能省掉一大半的折腾时间。2026年的生态已经比较成熟，不需要从零造轮子。
2.1 核心框架与平台选择
目前主要有两类选择：开源框架和低代码平台。
- 开源框架（适合开发者，灵活度高）：
- LangChain / LangGraph：生态最丰富，社区活跃，文档和示例多。LangChain 用于构建链，LangGraph 专门用于构建有状态的、多环节的工作流（Agent 本质就是一种工作流）。入门时可能会觉得概念多，但它是理解 Agent 组件的最佳教材之一。
- LlamaIndex：如果你构建的 Agent 严重依赖 RAG（从私有数据中获取信息），LlamaIndex 在数据连接、索引和检索方面更专精，可以很好地与 LangChain 配合使用。
- Semantic Kernel (Microsoft)：与 .NET 生态结合紧密，概念清晰（Plugins, Planners, Memories）。如果你主要使用 C# 或 Azure 云服务，这是个好选择。
- AutoGen (Microsoft)：专注于多 Agent 对话和协作，预设了多种 Agent 角色（如 UserProxy, Assistant），能快速搭建多 Agent 讨论场景。
- 低代码/云平台（适合快速原型和业务人员）：
- Dify, Flowise：这类平台提供了可视化编排工作流的能力。你可以通过拖拽组件（LLM、工具、条件判断）来构建 Agent，无需深入编码。对于验证想法和构建内部工具非常快，但自定义复杂逻辑和深度调试可能受限。
怎么选？如果目标是学习和深度控制，从 LangChain 开始。如果目标是快速给业务部门做一个演示或内部工具，用 Dify 这类平台可能几小时就能出原型。
2.2 大模型 API 与本地部署
Agent 的大脑需要一个大模型。你有两个选择：
- 调用云端 API：OpenAI GPT-4/4o, Anthropic Claude, 国内各大厂的模型。优点是不用操心部署，性能稳定，功能新。缺点是持续使用有成本，且数据需要出境（国内模型无此问题）。对于学习和原型开发，这是最快的方式。
- 本地部署开源模型：使用 Ollama, LM Studio 或 vLLM 等工具在本地运行 Llama、Qwen、DeepSeek 等模型。优点是数据完全私有，无网络延迟，长期成本可能更低。缺点是对硬件（GPU 内存）有要求，模型能力可能略逊于顶级闭源模型。
起步建议：直接用 OpenAI 或 Claude 的 API。先确保你的 Agent 逻辑是正确的，再考虑成本和数据隐私问题，将大脑替换为本地模型。这样能避免早期同时调试模型部署和 Agent 逻辑两方面的复杂问题。
2.3 其他基础设施
- 向量数据库：用于实现 RAG 和长期记忆。轻量级起步可以用ChromaDB（内存型，简单）或FAISS（Facebook 开源的高效相似性搜索库）。生产环境可以考虑Qdrant,Weaviate,Milvus等，它们支持持久化、分布式和更丰富的过滤条件。Spring AI 2.0 与 Qdrant 的集成就是一个企业级 RAG 的常见组合。
- 开发环境：Python 3.9+ 是主流。准备好虚拟环境（conda 或 venv），管理好依赖包版本，这是避免“在我机器上能跑”问题的第一步。
3. 核心环节一：让 Agent 学会使用工具（Tool Calling）
工具调用是 Agent 从“空想”到“实干”的关键一步。这里的目标是让 LLM 能根据你的描述，在合适的时机调用正确的工具，并理解返回结果。
3.1 如何定义工具
工具本质上是一个函数，你需要用框架能理解的方式描述它。以 LangChain 为例：
from langchain.tools import tool from langchain.agents import AgentExecutor, create_react_agent from langchain import hub # 1. 定义一个简单的计算器工具 @tool def calculator(expression: str) -> str: """计算一个数学表达式。例如：`calculator(\"2 + 2\")` 返回 `4`。""" try: # 安全提示：生产环境请勿使用eval，此处仅为示例 result = eval(expression) return f"计算结果: {result}" except Exception as e: return f"计算错误: {e}" # 2. 定义一个查询天气的工具（模拟） @tool def get_weather(city: str) -> str: """查询指定城市的天气。""" # 这里应该调用真实的天气API，返回模拟数据 return f"{city}的天气是晴朗，25摄氏度。" # 将工具放入列表 tools = [calculator, get_weather]关键点在于@tool装饰器和函数文档字符串（docstring）。LLM 主要靠这个文档字符串来理解工具的用途、输入参数和格式。所以，文档字符串要写得清晰、具体，包含示例。
3.2 创建 Agent 并执行
有了工具，你需要一个 Agent 来使用它们。ReAct 模式是一个经典且有效的起点。
# 3. 选择LLM（这里以ChatOpenAI为例，需设置你的API_KEY） from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4o", temperature=0) # 4. 获取一个预设的ReAct提示词模板 prompt = hub.pull("hwchase17/react") # 5. 创建ReAct Agent agent = create_react_agent(llm, tools, prompt) # 6. 创建执行器 agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True) # 7. 运行！ result = agent_executor.invoke({ "input": "请问北京现在的天气怎么样？如果温度高于20度，就计算一下（温度+5）的平方是多少。" }) print(result["output"])当你运行这段代码，并设置verbose=True时，会在控制台看到 Agent 的思考过程：
Thought: 用户想知道北京天气，然后根据温度做一个计算。我需要先调用天气工具。 Action: get_weather Action Input: {"city": "北京"} Observation: 北京的天气是晴朗，25摄氏度。 Thought: 现在温度是25度，高于20度。我需要计算（25+5）的平方。我需要调用计算器工具。 Action: calculator Action Input: {"expression": "(25+5)**2"} Observation: 计算结果: 900 Thought: 我得到了所有信息，可以回答用户了。 Final Answer: 北京现在天气晴朗，25摄氏度。因为温度高于20度，我计算了（25+5）的平方，结果是900。这就是工具调用的核心流程：思考（Thought）- 决定行动（Action）- 执行工具（Action Input）- 观察结果（Observation）- 继续思考。verbose=True是调试 Agent 逻辑的利器，一定要善用。
3.3 常见问题与排查
- 工具不被调用：首先检查工具的文档字符串是否清晰。LLM 可能无法理解工具的用途。其次，检查提示词（Prompt），确保它鼓励 Agent 使用工具。ReAct 模板通常已经优化过这一点。
- 工具输入格式错误：LLM 有时会生成不符合工具函数参数格式的输入。使用
handle_parsing_errors=True可以让执行器尝试修复小错误。更稳妥的做法是在工具函数内部做好参数校验和类型转换。 - 无限循环或错误使用工具：Agent 可能陷入“思考-调用-失败-再思考”的循环。可以设置
max_iterations（最大迭代次数）和max_execution_time（最大执行时间）来强制终止。例如：AgentExecutor(..., max_iterations=10, max_execution_time=30)。
4. 核心环节二：用 RAG 为 Agent 注入专业知识
如果 Agent 只能调用通用工具，那它还是个“通才”。RAG（检索增强生成）能让它变成某个垂直领域的“专家”，比如回答公司内部文档问题、分析特定技术资料。
4.1 RAG 全链路拆解：不止是向量检索
一个完整的 RAG 系统远不止“文本切块-向量化-搜索”那么简单。企业级应用时，痛点往往出现在全链路的各个环节：
- 文档加载与解析：支持 PDF、Word、PPT、HTML、Markdown、数据库等。痛点：格式复杂（扫描版PDF、表格、图表）导致信息提取不全或错乱。
- 文本分割（切块）：策略直接影响效果。盲目按固定字符数切分（如 500 字一块）会割裂语义。更好的策略是：
- 按语义分割：使用自然语言处理（NLP）模型识别段落、句子边界。
- 递归分割：先按大标题分，再按小标题分，最后按段落分，形成层次结构。
- 重叠分割：让相邻块有部分文字重叠，避免答案恰好被切在块边界。
- 向量化与索引：将文本块转换为向量（Embedding），存入向量数据库。痛点：Embedding 模型对专业术语表征能力不足；索引速度慢，影响实时性。
- 检索：用户提问时，将问题也向量化，从数据库中找出最相似的几个文本块（Top-K）。痛点：单纯的余弦相似度可能检索不准，需要结合关键词过滤（Metadata Filtering，如按文档类型、日期过滤）和重排序（Rerank）模型来提升精度。
- 增强生成：将检索到的文本块作为上下文，连同问题一起送给 LLM，让它生成答案。痛点：上下文太长超出模型限制；上下文包含无关或矛盾信息，导致答案“幻觉”。
4.2 动手搭建一个简单的 RAG 系统
我们用 LangChain 和 Chroma 快速实现一个基础版，让你感受全流程。
from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA # 1. 加载文档（这里用文本文件示例） loader = TextLoader("./公司制度.txt", encoding="utf-8") documents = loader.load() # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个块大小 chunk_overlap=50, # 重叠大小 length_function=len, separators=["\n\n", "\n", "。", "！", "？", "，", " ", ""] # 递归分割符 ) docs = text_splitter.split_documents(documents) # 3. 创建向量存储 embeddings = OpenAIEmbeddings() # 需要OPENAI_API_KEY vectorstore = Chroma.from_documents(documents=docs, embedding=embeddings, persist_directory="./chroma_db") # 持久化到本地目录，下次可直接加载 # 4. 创建检索器 retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) # 检索最相似的3个块 # 5. 创建问答链 llm = ChatOpenAI(model="gpt-4o", temperature=0) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 简单地将所有检索到的上下文“塞”进提示词 retriever=retriever, return_source_documents=True # 返回来源文档，便于溯源 ) # 6. 提问 question = "我们公司的年假制度是怎样的？" result = qa_chain.invoke({"query": question}) print("答案:", result["result"]) print("\n来源文档:") for doc in result["source_documents"]: print(f"- {doc.page_content[:200]}...") # 打印前200字符这个流程跑通后，你就有了一个最简单的知识库问答系统。但这就是 RAG 的全部吗？远不是。这只是一个起点。
4.3 从“能用”到“好用”：RAG 的优化实战
企业级 RAG 的痛点，需要针对性优化：
- 检索质量差（找不准）：
- 优化 Embedding 模型：尝试
text-embedding-3-small/large或开源模型如BGE-M3、voyage-2，在专业语料上微调效果更佳。 - 引入重排序（Rerank）：使用 Cohere Rerank、BGE Reranker 等模型对初步检索结果重新打分排序，把最相关的排到最前面。这能显著提升精度，尤其是当 Top-K 设置较大时。
- 混合检索（Hybrid Search）：结合向量检索（语义相似）和关键词检索（如 BM25，字面匹配）。有些问题用关键词更准（如产品型号“ABC-123”）。
- 优化 Embedding 模型：尝试
- 生成答案有幻觉（编造）：
- 引用溯源（Groundedness）：要求 LLM 在生成答案时，必须引用来源文档的片段。这既能增强可信度，也方便人工核查。在提示词（Prompt）中明确指令：“请基于以下上下文回答，并引用相关段落。”
- Prompt 工程：设计更好的提示词，如：“如果上下文信息不足以回答问题，请直接说‘根据现有资料无法回答’，不要编造信息。”
- 处理复杂问题（多跳问答）：
- Agentic RAG：这就是将 RAG 和 Agent 结合。让 Agent 来主导检索过程。例如，对于一个复杂问题“我们产品A和竞争对手B在Q3的销量对比如何？”，Agent 可以规划：第一步，检索产品A的Q3销售报告；第二步，检索竞争对手B的市场分析；第三步，调用计算工具进行对比；第四步，生成最终报告。这比一次性检索所有信息更精准。
评估 RAG 系统，不能只靠感觉。可以看几个指标：检索命中率（检索到的块是否包含答案）、答案相关性、事实准确性（与源文档对比）、引用正确率。用一批测试问题来量化评估。
5. 核心环节三：理解 MCP 协议——工具的“通用插座”
当你为 Agent 开发了越来越多的工具，会发现一个麻烦：每个框架（LangChain, AutoGen等）定义工具的方式略有不同，工具也难以在不同项目间复用。这就是MCP（Model Context Protocol）要解决的问题。
5.1 MCP 是什么？为什么需要它？
你可以把 MCP 想象成工具的“USB-C 接口”或“通用插座”。它是一个开放协议，定义了工具、数据源如何以一种标准化的方式向 LLM 应用（如 Agent）描述自己、提供能力。
在没有 MCP 之前：
- 你在 LangChain 里写了一个
@tool。 - 换到另一个基于 Claude 的 Agent 平台，可能得用它的 SDK 重新定义一遍。
- 工具的逻辑（比如连接公司数据库的代码）是相同的，但“包装形式”要改。
有了 MCP 之后：
- 你按照 MCP 协议的标准格式，将你的数据库连接能力写成一个MCP 服务器。
- 任何支持 MCP 协议的客户端（比如 Claude Desktop, 新的 LangChain 版本）都能自动发现、加载并使用这个工具。
- 一次开发，处处可用。工具实现了与上层应用框架的解耦。
5.2 MCP 的核心概念与工作流程
- MCP 服务器（Server）：提供工具和数据源的一方。它暴露出一些“资源”（Resources，如数据库表、API端点）和“工具”（Tools，如查询、更新操作）。服务器启动后，等待客户端连接。
- MCP 客户端（Client）：使用工具的一方，比如 Claude Desktop、你的自定义 Agent 应用。客户端通过标准方式（如 stdio 或 HTTP）连接到服务器，获取服务器提供的资源和工具列表。
- 协议通信：客户端和服务器通过 JSON-RPC 消息进行通信。消息类型包括：
list_tools（列出工具）、call_tool（调用工具）、read_resource（读取资源）等。
一个简化的工作流：
- 你写了一个
CompanyDBServer，它通过 MCP 协议提供了query_sales_data工具。 - 你在 Claude Desktop 中配置它连接到这个服务器。
- 你在 Claude 的聊天框里说：“帮我查一下上海地区本季度的销售数据。”
- Claude（作为 MCP 客户端）自动识别出这个请求可以调用
query_sales_data工具，它通过 MCP 协议向你的服务器发送call_tool请求。 - 你的服务器执行真正的数据库查询，并将结果通过 MCP 协议返回给 Claude。
- Claude 将结果组织成自然语言回复给你。
5.3 对开发者的意义
- 工具生态标准化：未来可能会出现一个“MCP 工具市场”，你可以像安装插件一样，为你的 Agent 添加天气预报、股票查询、项目管理等各种能力，而无需关心底层是哪个框架。
- 关注点分离：你可以专注于编写工具的核心业务逻辑（MCP 服务器），而让不同的前端（Chatbot, Agent 框架，低代码平台）来消费它。
- 安全与管控：企业可以统一开发和部署 MCP 服务器，严格控制内部工具如何被 LLM 访问，而不是在每个应用里重复编写和授权。
目前，MCP 主要由 Anthropic 推动，但正在成为行业趋势。学习它，意味着你在为未来更模块化、更开放的 Agent 开发模式做准备。即使你现在不深入实现，理解这个概念也能帮你更好地规划工具层。
6. 企业级应用落地：从 Demo 到生产系统
把单个 Agent 跑通只是第一步。要把它变成企业里一个可靠的生产系统，需要跨越好几个台阶。
6.1 架构设计考量
- 单体 vs 微服务：简单的内部工具可以是一个单体应用。但如果涉及多个部门、高并发、独立扩缩容，就需要将 Agent 核心、工具服务、RAG 索引服务等拆分成微服务。
- 状态管理：Agent 对话是有状态的。在 Web 应用中，需要为每个用户会话维护独立的状态（记忆、对话历史）。不能把状态简单放在内存里，需要用 Redis、数据库或专门的会话存储来管理。
- 异步与流式响应：复杂的 Agent 任务可能耗时很长（几十秒）。必须采用异步处理（如 Celery 任务队列）和流式响应（Server-Sent Events 或 WebSocket），让用户能看到实时进展，而不是一直白屏等待。
- 可观测性：这是生产系统的生命线。必须记录详细的日志（Agent 的思考过程、工具调用、耗时）、监控指标（请求量、延迟、错误率、Token 消耗）和链路追踪（一个请求在所有微服务间的流转）。使用 Prometheus, Grafana, LangSmith 等工具。
6.2 安全、合规与成本控制
- 数据泄露防护：确保 Agent 不会在提示词或工具调用中，将敏感数据（PII）发送给外部 LLM API。需要在调用前做数据脱敏。对于本地模型，也要注意内部系统的访问权限。
- 工具调用权限：不是所有用户都能调用所有工具。需要建立权限体系，例如，只有财务人员能调用“生成财务报表”工具。这需要在 Agent 调用工具前进行身份认证和授权校验。
- 内容安全与审核：对用户的输入和 Agent 的生成结果进行安全过滤，防止生成违法、违规或有毒内容。可以接入内容安全 API 或使用本地审核模型。
- 成本控制：监控每个请求的 Token 消耗，特别是当使用了长上下文、大量检索内容时。设置预算告警和用量限制。对于内部工具，可以考虑缓存常见问题的答案。
6.3 工作流编排与多 Agent 协同
对于复杂业务流程，单个 Agent 可能力不从心，需要引入工作流引擎和多 Agent 协同。
- 工作流引擎：使用LangGraph或n8n这类工具来编排复杂、有状态的流程。LangGraph 更贴近代码，适合开发者；n8n 是可视化低代码平台，适合业务人员参与设计。
- 场景示例：一个客户投诉处理流程。先由“分类 Agent”判断投诉类型；然后路由给“技术支持 Agent”或“售后 Agent”；它们各自调用工具查询订单、知识库；如果需要升级，再通知“人工坐席 Agent”。
- 多 Agent 协同：让多个各有所长的 Agent 合作完成任务。例如，一个“规划 Agent”负责拆解任务，一个“研究 Agent”负责搜索信息，一个“写作 Agent”负责整理报告，一个“审核 Agent”负责检查质量。它们通过共享的工作区或消息总线进行通信。AutoGen框架专门为此设计。
6.4 持续迭代与评估
上线不是终点。需要建立评估体系：
- 单元测试：为每个工具函数、RAG 检索器写测试。
- 集成测试：模拟端到端的用户对话，验证整个 Agent 流程。
- 人工评估：定期抽样检查 Agent 的处理结果，标注好坏，形成评估数据集。
- A/B 测试：对比新老版本的 Agent 或不同的提示词策略，用真实用户反馈和数据指标（任务完成率、用户满意度）来决定哪个更好。
- 反馈循环：提供用户反馈入口（如“这个回答有帮助吗？”），将不满意的案例加入改进池，用于优化提示词、工具或检索策略。
7. 学习路径与实战建议
面对这么多概念和技术，一个可行的学习路径能让你少走弯路。
7.1 分阶段学习路线
- 第一阶段：建立直觉（1-2周）
- 目标：跑通一个最简单的 Agent 和 RAG。
- 行动：用 LangChain + OpenAI API，按照本文第3、4节的代码，亲手实现一个能调用2个工具（如计算器、网络搜索模拟）的 Agent，以及一个基于 TXT/PDF 文档的问答 RAG。关键是要看到完整的输入-处理-输出循环。
- 第二阶段：深入核心组件（2-4周）
- 目标：理解每个模块的细节和可选项。
- 行动：
- 工具调用：尝试更多类型的工具（读写文件、调用真实 API），学习 ReAct 之外的 Agent 类型（如 Plan-and-Execute）。
- RAG 优化：体验不同的文本分割策略、换用不同的 Embedding 模型、尝试加入重排序（Rerank）步骤。用一组问题评估优化前后的效果差异。
- 记忆：实现一个能记住对话历史的简单记忆模块。
- 第三阶段：系统集成与生产化（4周+）
- 目标：搭建一个接近生产可用的原型。
- 行动：
- 将 Agent 封装成 REST API。
- 接入真实的向量数据库（如 Qdrant）。
- 实现简单的异步任务队列。
- 加入日志和基础监控。
- 了解 MCP 协议的概念和前景。
- 第四阶段：探索前沿与架构（持续）
- 目标：解决更复杂的问题。
- 行动：学习 LangGraph 编排复杂工作流、用 AutoGen 搭建多 Agent 系统、研究 Agentic RAG 模式、关注最新的开源框架和论文。
7.2 给新手的避坑指南
- 不要一开始就追求完美架构：先用最直接的方式跑通端到端流程，哪怕代码很“丑”。有了可工作的原型，再考虑重构和优化。
- 重视提示词（Prompt），但别神话它：清晰的指令、上下文和格式要求对 Agent 表现至关重要。但很多问题不是改 Prompt 能解决的，可能是工具定义不清、检索结果不准或模型能力边界。
- 日志是你的第一调试工具：一定要打开 Agent 执行过程的详细日志（
verbose=True）。看到它的“思考”过程，你才能定位问题到底出在规划、工具调用还是生成阶段。 - 从模拟工具开始：在连接真实数据库或内部系统前，先用一个返回固定数据的“模拟工具”来验证 Agent 的逻辑是否正确。避免早期陷入网络、权限等无关问题的调试。
- 评估重于感觉：不要只靠几个例子判断好坏。准备一个包含各种边界情况的测试集，用一致的指标（正确性、完整性、相关性）来评估每次改动。
AI Agent 的开发是一个系统工程，它结合了软件工程、提示词工程和大模型能力。最好的学习方式就是动手：选一个具体的、小的问题（比如“个人旅行规划助手”、“技术文档问答机器人”），从零开始搭建，遇到问题就查资料、调试。当你完整地走完开发、调试、优化和部署的流程后，对这些概念的理解才会真正深刻。
