如果你最近在看 AI Agent会反复遇到这些词PromptRAGFine-tuningTool Call / Function Calling状态机WorkflowMCP它们都和 Agent 有关但又不在一个层面上。最常见的困惑不是“不会写代码”而是这些概念分别在解决什么问题边界在哪做项目时又该怎么组合这篇文章的目标很简单把这些概念放到同一张架构地图里讲清楚让你对 AI Agent 建立一套能直接指导工程落地的认知框架。先记住一句话如果只想先抓住主线可以先记住下面这 7 句话Prompt告诉模型这次该怎么做RAG给模型补充这次需要参考的知识Fine-tuning让模型长期习惯这样做Tool Call让模型从“会说”变成“会做”状态机描述 Agent 当前运行到哪一步Workflow规定任务接下来该怎么走MCP让工具、资源和上下文用统一协议接入你会发现这些概念并不是替代关系而是分工关系。一张图看懂 AI Agent从这张图里可以先得到一个很重要的判断Prompt 是任务入口RAG 解决知识补充Tool Call 解决行动能力Workflow 解决多步编排状态机解决运行过程可控MCP 解决外部能力标准化接入微调则作用在模型本身用来提升长期稳定性概念速览先看边界再看定义这张表建议反复看。很多项目里的混乱根源就是把这些职责混在了一起。1.PromptAI Agent 的起点不是终点Prompt 到底是什么Prompt 可以理解为你给模型的任务说明书。但在真实 Agent 系统里它通常不是一句简单提问而是一组动态拼装后的上下文。常见组成包括System Prompt角色、目标、边界Developer Prompt开发者约束User Prompt用户当前请求Conversation Context多轮对话历史Retrieved ContextRAG 返回的资料Tool Results工具执行结果Output Schema输出格式要求所以Prompt 的本质不是“问一句话”而是给模型一份当前任务的完整执行说明。Prompt 主要解决什么问题它主要负责三件事定义角色你是谁定义任务你现在要做什么定义规则你应该怎样做不能怎样做比如你是一个企业客服助手不允许编造订单状态如果参数不全优先追问用户最终必须输出 JSONPrompt 的优势和边界Prompt 的优势很明显上手快成本低试错快适合 MVP 和规则频繁变化的场景但它也有天然边界上下文一长规则容易被稀释约束越多冲突越多稳定性不如训练后的能力复杂系统不能只靠 Prompt 硬撑一个实用判断是Prompt 适合“快速控制”不适合“长期硬编码一切”。2.RAG让模型具备“查资料”的能力RAG 是什么RAG 的全称是 Retrieval-Augmented Generation中文通常叫“检索增强生成”。它的核心思想很直白先查资料再回答问题。也就是说RAG 不是把知识训练进模型而是在运行时把相关内容检索出来临时补充给模型。RAG 最适合解决什么问题RAG 最适合处理下面这类问题模型原本不知道模型知道但不够准确知识经常变化需要来源可追溯典型场景包括企业内部制度问答产品文档问答API 文档问答合同条款检索运维 SOP 查询私有知识库问答RAG 的基本流程真实工程中的 RAG 通常还会涉及文档切片embedding 向量化lexical 词汇检索hybrid retrieval 混合检索rerank 重排引用来源展示低置信度兜底RAG 的核心边界RAG 擅长补充知识但不擅长固化行为。例如“公司退款规则是什么”适合 RAG“永远使用统一客服语气回复”更适合 Prompt 或微调所以可以用一句话记忆RAG 解决的是“模型这次需要知道什么”。3.Fine-tuning把能力练进模型微调是什么Fine-tuning 指的是在已有模型基础上用特定任务数据继续训练让它更擅长某个领域、某种输出方式或某类固定任务。一个很直观的比喻是Prompt考试前提醒注意事项RAG考试时允许查资料微调平时就把这类题练熟微调最有价值的地方微调最适合解决的不是“补知识”而是“固化模式”。典型收益包括固定输出格式更稳定统一语气和风格更一致分类、抽取、路由更可靠减少超长 Prompt 依赖让小模型承担专用任务特别适合的任务有文本分类意图识别结构化抽取风险标签识别标准化报告生成微调不该承载什么下面这些内容通常不适合靠微调承载经常变化的业务规则最新文档内容实时数据库真值需要精确查询的外部信息一句话概括它的边界微调解决的是“模型长期习惯怎么做”不是“模型这次该查什么”。4.Tool Call让模型真正开始“做事”Tool Call 是什么Tool Call 或 Function Calling本质上是让模型在推理过程中不只输出自然语言还能请求调用某个外部函数。比如用户说帮我查一下今天上海的天气。模型不需要直接猜答案而是可以生成这样的调用意图{ ”tool”: ”get_weather”, ”arguments”: { ”city”: ”Shanghai”, ”date”: ”today” } }然后由系统实际执行工具把结果再交回模型完成最终回答。为什么 Tool Call 是 Agent 的关键分水岭没有 Tool Call模型更多是在“表达”会说会解释会分析会建议有了 Tool Call模型才真正有机会“执行”查数据库调业务接口发邮件创建工单查询订单控制设备写入系统记录也就是说Tool Call 是 AI Agent 从“会聊天”走向“会执行”的关键一步。一个典型执行链路Tool Call 的工程难点真正的难点从来不只是“接口能不能调通”而是什么时候该调工具该调哪个工具参数如何补齐参数是否合法工具失败如何重试或兜底多工具如何协作如何避免死循环调用如何做权限校验和审计所以Tool Call 很重要但它本身并不等于完整的 Agent 系统。5.状态机管理 Agent 的运行过程为什么 Agent 需要状态机一个真实 Agent 并不是永远处于“回答中”这一种状态。它通常会经历很多中间态空闲等待任务规划工具执行中等待工具返回等待用户确认汇总结果已完成已失败如果没有状态机你会很快遇到这些问题前端无法展示中间态日志难排查执行链路不易追踪暂停、恢复、重试难实现状态机到底在定义什么状态机定义的是Agent 有哪些状态以及这些状态之间允许如何转换。例如状态机的价值状态机最大的价值在于让 Agent 具备更强的可控性和可观测性前端可以展示真实运行阶段后端更容易做日志收口更方便 trace 和 replay更适合做中断恢复和失败治理对于产品化 Agent 而言状态机几乎是标配。6.Workflow让复杂任务可以被编排Workflow 是什么Workflow 可以理解为把复杂任务拆成多个明确步骤并定义输入、输出、执行顺序、条件分支和异常处理。例如一个企业客服 Agent 的工作流可能是识别用户意图判断是否需要查知识库判断是否需要查订单调知识库检索调订单系统查询汇总结果记录日志或创建工单这就是一条完整的 Workflow。Workflow 和状态机最容易混淆它们的区别可以直接用一张表看懂一个很好记的类比是状态机像“演员当前状态”Workflow 像“整部戏的剧本流程”二者经常同时出现但并不是一回事。为什么生产环境离不开 Workflow因为真实业务任务往往都包含多步判断条件分支工具协作用户确认异常兜底人工介入如果没有 Workflow系统很容易退化成一切都交给模型自由发挥。这对 Demo 也许足够对生产环境通常不够。7.MCP统一工具与上下文接入的标准协议MCP 是什么MCP 通常指 Model Context Protocol。你可以先把它理解为一种用于标准化接入工具、资源和上下文的协议。它不替代 Tool Call也不替代模型本身而是在解决更底层的问题当 Agent 需要接越来越多外部能力时如何用统一方式接入和治理MCP 在解决什么如果没有统一协议接一个工具通常都要分别处理参数定义schema 说明调用方式返回格式鉴权方式错误处理能力暴露方式当你要接 GitHub、Jira、数据库、CRM、文档系统、内部 API 时重复适配的成本会越来越高。MCP 的价值就在于统一工具暴露方式统一资源暴露方式统一 schema 约束统一上下文读取方式统一能力发现机制MCP 和 Tool Call 的区别这是最容易被混淆的一组概念。一个更直白的类比是Tool Call 像“我要打电话”MCP 像“统一的通讯录、号码规范和拨号协议”所以两者不是替代关系而是协作关系。8.把这些概念重新放回同一张架构图到这里再看下面这张图层次就会清晰很多如果要把它们再压缩成一句话Prompt 定义本次任务RAG 提供本次知识Fine-tuning 提升长期稳定性Tool Call 提供行动能力Workflow 规定步骤状态机管理过程MCP 标准化外部接入9.一个真实场景运维分析 Agent 是怎么工作的为了让上面的概念更落地我们看一个典型场景。用户对运维 Agent 说帮我看看昨天生产环境 API 错误率为什么突然升高。一个成熟的 Agent 系统通常会这样工作。第一步Prompt 定义任务系统先告诉模型你是运维分析助手不允许编造监控数据需要先查监控再查日志输出必须包含结论、证据和建议第二步Workflow 决定执行顺序工作流可以定义为识别这是“故障分析”请求查询监控平台查询日志平台对齐时间窗口汇总证据输出结论和建议第三步状态机描述运行阶段这个过程里Agent 可能会依次经历planningrunning_toolwaiting_toolsummarizingcompleted前端就可以把这些中间态实时展示给用户。第四步Tool Call 调工具模型可能发起query_metrics(service, time_range)query_logs(service, level, time_range)第五步MCP 提供统一接入如果监控平台、日志平台、工单平台都通过 MCP 暴露能力Agent 的接入和治理成本就会低很多。第六步RAG 补充背景知识如果还需要引用系统架构文档错误码说明历史故障复盘那么就可以通过 RAG 把这些资料补充给模型。第七步微调提升稳定性如果这个 Agent 长期要输出固定格式的故障分析报告并且组织内部有统一术语和风格那么微调就会有明显价值。这个例子最能说明的一点是AI Agent 从来不是某一个技术点而是多个能力模块的协同。10.做 AI Agent 最常见的 6 个误区误区 1把 Prompt 当成万能解法Prompt 很重要但它更像快速控制手段不是万能底座。规则一多、流程一长只靠 Prompt 往往会变脆。误区 2把 RAG 当成训练模型RAG 不会修改模型参数它只是把外部资料在运行时补充给模型。误区 3把微调当成知识库如果知识经常更新优先应该考虑 RAG、数据库查询或工具调用而不是微调。误区 4把 Tool Call 理解成接口代理难点不在“能不能调接口”而在“何时调、调什么、调完怎么处理、失败怎么兜底、权限如何治理”。误区 5把 Workflow 和状态机混为一谈Workflow 负责步骤编排状态机负责运行状态管理。一个回答“怎么走”一个回答“走到哪”。误区 6把 MCP 当成另一份接口文档MCP 的价值不只是描述接口而是让工具、资源和上下文以统一协议被发现、接入和治理。11.从 0 到 1AI Agent 应该按什么顺序搭如果你准备从零开始做一个 Agent通常可以按这个顺序推进第一阶段先把 Prompt 跑通先验证两件事这个任务是否真的适合用 LLM模型是否能在 Prompt 驱动下完成基础能力这一步的目标不是做完整系统而是快速验证价值。第二阶段补上 RAG如果业务依赖私有知识、规则手册、产品文档那么应尽早引入 RAG让回答更准确、更可追溯。第三阶段接入 Tool Call如果任务不只是问答还需要查数据、改状态、联动系统那么 Tool Call 很快就会成为核心能力。第四阶段加入状态机和 Workflow当系统进入多步执行、长链路任务、前端中间态展示阶段状态机和 Workflow 就会从“可选项”变成“刚需”。第五阶段再考虑微调当你已经遇到下面这些问题时再认真考虑微调Prompt 越写越长few-shot 越堆越多输出风格不稳定高并发下成本压力大希望小模型承担专用任务已积累足够高质量样本第六阶段平台化时引入 MCP当你的 Agent 开始接入越来越多外部系统面向多个业务团队复用需要统一工具治理与纳管这时 MCP 的价值会越来越明显。结语AI Agent 不是“大模型外面套一层壳”而是一整套围绕理解、检索、调用、编排、执行和治理展开的系统能力组合。真正重要的不是死记术语而是搞清楚三件事每个概念分别解决什么问题它们各自的边界在哪里你的业务到底需要哪几层能力当你把这张“能力地图”看清楚之后再做架构设计、技术选型和工程落地很多问题都会简单得多。附一句话速记版Prompt告诉模型这次该怎么做RAG给模型补充这次需要参考的知识Fine-tuning让模型长期习惯这样做Tool Call让模型可以调用外部能力状态机描述 Agent 当前处于哪个运行阶段Workflow规定任务接下来该怎么走MCP统一工具、资源和上下文的接入协议最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。