本文为作者原创首发于掘金现同步发布到 CSDN。内容整理自AI Mind项目的真实开发过程。GitHubhttps://github.com/HWYD/ai-mind对应代码版本v0.1.1AI Mind 是一个基于 Next.js 持续迭代的 AI Chat 项目项目从本地大模型聊天起步逐步扩展流式协议、工具调用、MCP、Skill Runtime 和 Agent 等能力。如果这篇文章或 AI Mind 项目对你有所帮助也欢迎到 GitHub 给项目点个 Star⭐这会是对我继续整理后续版本复盘很大的鼓励。如果你在做 AI 应用时或者接触 AI 项目经常会遇到一堆很容易混在一起的词Agent、RAG、Tool Calling、Skill、MCP、Prompt、Resource、Runtime……这些词看起来都和“大模型能力增强”有关也经常一起出现在 AI 应用架构图里。但真正落到工程实现时它们解决的问题并不是同一层。我在做 AI Mind 的过程中也踩过这个认知坑。AI Mind 是我自己做的一个 AI 应用运行时实验项目从普通聊天、工具调用、技能分组、MCP 接入一直迭代到最近的可控 Tasklist Agent。项目做得越往后我越明显感觉到如果不先把这些概念的边界拆清楚代码很容易越写越乱。这篇文章不做百科式定义而是从 AI 应用工程实现的角度聊聊这些概念到底怎么分工。先给一个结论读文档不等于 RAG调工具不等于 Agent接入 MCP 也不等于做了 Agent 平台。更工程化一点说概念一句话理解解决的问题Agent根据目标和上下文推进多步骤任务谁来决定下一步RAG检索外部知识并注入上下文知识从哪里来Tool模型可以调用的具体能力能执行什么动作Skill按场景组织起来的一组能力能力怎么分组MCP外部 Tool / Resource / Prompt 的标准化接入方式外部能力怎么连接Resource可读取的上下文资料读什么内容Prompt任务模板或行为约束怎么指导模型Runtime调度输入、能力、状态和输出整个链路怎么跑起来下面一个个拆开看。1. Agent不是会调工具就叫 Agent很多人一说 Agent就会想到“模型会调用工具”。但我现在更愿意把 Agent 理解成Agent 是围绕一个目标能够推进多步骤任务并根据中间结果决定是否继续、修正或结束的一条执行链路。普通聊天通常是这样用户问一句 模型答一句Tool Calling 通常是这样用户提出问题 模型判断需要某个工具 调用工具 模型基于工具结果回答Agent 则更进一步用户给出目标 Agent 读取上下文 生成中间产物 调用工具校验或补充信息 根据结果决定是否修正 最终输出结果所以 Agent 的关键不只是“有没有调用工具”而是它是否围绕一个目标进行多步骤推进。但在真实工程里可靠的 Agent 通常不应该完全自由。我不太认同“Agent 就应该让模型想干嘛就干嘛”。实际项目里Agent 应该有资源边界、工具边界、最大步骤数、失败策略和输出约束。否则模型一旦误判就可能读错资料、调错工具甚至进入无意义循环。比如 AI Mind 最近做的第一个 Agent是一个“版本方案转任务清单 Agent”。它的作用是基于项目里的版本方案文档生成一份可执行的 tasklist 草稿。它的触发条件很明确/tasklist docs://versions/*.md也就是说用户必须显式选择/tasklist命令并且引用一个版本方案文档系统才会进入这个 Agent。它的执行流程也很受控读取版本方案 - 提取方案里的关键信息 - 生成 tasklist 草稿 v1 - 校验 tasklist 结构 - 必要时最多自动修正一次 - 再次校验 - 输出最终 tasklist 草稿这里模型主要负责生成和修正文稿运行时负责控制路径、资源边界、状态转移和失败收束。所以我更愿意把它叫做可控 Agent而不是自由 Agent。Agent 的价值不是“模型无限自由”而是在有限边界内完成多步骤任务。2. RAG不是读文档就叫 RAGRAG 也是一个很容易被泛化的词。很多时候只要系统能读取文档大家就会说“这个项目做了 RAG”。但严格一点看读文档和 RAG 不是一回事。RAG 解决的是模型本身不知道某些知识时系统先从外部知识库里检索相关内容再把这些内容注入上下文让模型基于这些内容回答。一个相对完整的 RAG 链路一般会涉及文档切分 chunking 向量化 embedding 索引 indexing 检索 retrieval 重排 rerank 上下文注入 模型生成也就是说RAG 的核心不只是“读”而是“检索”。如果用户明确指定一个文件docs://README.md 总结这个文档系统直接读取这个文件并交给模型总结这更像 Resource 读取而不是完整 RAG。AI Mind 当前也没有把自己包装成 RAG 项目。现在 AI Mind 做的是受控文档资源读取例如docs://README.md docs://architecture/runtime-boundary.md docs://versions/*.md用户显式引用某个资源运行时读取这个资源然后把它注入当前任务上下文里。它没有做chunking embedding vector index retrieval rerank所以我不会说 AI Mind 当前已经实现了完整 RAG。这个例子反而说明了一个很重要的边界读文档不等于 RAG。后续如果 AI Mind 做文档切分、向量索引、按问题召回相关上下文那才是进入 RAG 方向。3. Tool模型可以调用的具体能力Tool 是 AI 应用里最容易理解但也最容易和 Agent 混淆的概念。我更倾向于把 Tool 理解成一个输入明确、输出明确、可以被运行时执行的具体能力。比如查询天气 计算日期 读取资源 校验 tasklist 结构 检查文档一致性Tool 通常会有结构化描述输入是什么 输出是什么 失败怎么表达 当前任务是否允许调用在 AI Mind 的 Tasklist Agent 里一个比较典型的 Tool 是任务清单结构校验工具validate_tasklist_structure它的作用不是生成 tasklist而是校验 Agent 生成出来的 tasklist 草稿结构是否合格。它会检查有没有标题 有没有来源方案 有没有 Step 有没有 checklist 有没有验证内容 有没有工程验证 有没有暂停点这个 Tool 的实现也不是“再问一次大模型”而是用 Markdown 结构解析和确定性规则来校验。大致思路是解析 Markdown 识别标题、列表、任务项 根据规则输出 pass / warning / fail这里的分工很关键生成由模型完成结构校验由确定性 Tool 完成。如果所有事情都交给模型系统会很飘如果把可确定的问题交给规则工具整个 Agent 链路就会稳定很多。Tool 和 Agent 的区别也可以这样理解Tool 是一个具体能力Agent 是组织这些能力推进任务的执行链路。调了一个 Tool不代表就是 Agent。4. Tool、RAG、Agent 放在一起对比这三个概念最容易混在一起可以单独放在一起看Tool 更像一个明确动作用户问题 - 调用一个明确工具 - 得到工具结果 - 模型整理回答RAG 更像知识增强链路用户问题 - 检索相关知识 - 注入上下文 - 模型基于知识回答Agent 更像目标驱动的多步骤任务目标任务 - 读取上下文 / 调用工具 - 观察结果并修正 - 最终完成任务所以Tool 解决动作问题RAG 解决知识问题Agent 解决任务推进问题。这三者可以组合但不是同一个东西。5. Skill不是单个函数而是一组能力的组织方式Skill 这个词不同项目可能叫法不一样。有人叫 Skill有人叫 Capability有人叫 Mode有人叫 Toolset。在 AI Mind 里我更愿意把 Skill 理解成按任务场景组织起来的一组能力。Tool 是单个能力而 Skill 是能力分组。比如 AI Mind 里有两类基础 Skill阅读技能reader-skill 工具技能utility-skill阅读技能更偏阅读类任务读取文档 总结内容 注入上下文 处理 Resource工具技能更偏通用工具类任务计算 日期 转换 结构化小工具为什么需要 Skill因为真实 AI 应用里Tool 会越来越多。如果每次都把所有工具直接暴露给模型模型选择工具的成本会上升误调用的概率也会上升。Skill 的价值在于先判断当前任务属于什么场景 再暴露这个场景下需要的有限能力也就是说Skill 是一个能力组织层。它不是最终执行层也不是 Agent 本身。它更像在运行时里帮我们回答一个问题当前任务应该让模型看到哪些能力在 AI Mind 的演进里我不是一开始就做 Agent而是先做 Tool Calling再做多工具运行时再逐步收敛出阅读技能和工具技能。到 v0.1.0才引入第一个受控单 Agent。这个顺序对我来说是比较自然的先有具体工具 再有工具运行时 再有能力分组 再有受控 Agent6. MCP不是 Agent也不是 RAG而是能力接入协议MCP 也很容易被误解成 Agent。但从工程上看MCP 解决的是另一个问题外部能力怎么标准化接入 AI 应用。MCP 可以暴露几类东西Tool Resource Prompt也就是说MCP 更像一个连接协议。它不负责决定任务怎么做也不负责知识怎么检索更不等于 Agent 平台。比如 AI Mind 接入 MCP 后可以用统一方式拿到本地文档资源 远程上下文资源 外部工具 任务模板 服务来源 执行状态这里 MCP 解决的是连接问题外部服务怎么告诉 AI 应用我有哪些 Tool 外部服务怎么告诉 AI 应用我有哪些 Resource 外部服务怎么告诉 AI 应用我有哪些 Prompt但至于什么时候用这些能力、怎么组织这些能力、失败后怎么办是 Runtime 或 Agent 要解决的问题。一句话MCP 提供能力Agent 决定什么时候用能力Runtime 负责把能力安全地跑起来。7. 放到 AI Mind 里看一遍把这些概念放回 AI Mind会更清楚。AI 应用概念AI Mind 中的体现Agent版本方案转任务清单 AgentTool任务清单结构校验工具Skill阅读技能 / 工具技能MCP本地 / 远程 MCP 能力接入Resource版本方案文档、README、架构文档Prompt文档总结 / tasklist 生成相关模板Runtime聊天运行时、工具运行时、流式输出内核RAG当前未做完整 RAG只做受控文档资源读取以 Tasklist Agent 为例。用户输入/tasklist docs://versions/v0.0.12-docs-resource-composer-capability-tool-runtime.mdAI Mind 不是直接把这句话丢给模型让模型自由发挥而是先从输入框里识别结构化信息命令/tasklist 资源docs://versions/*.md只有这两个条件同时满足才会进入 Agent。进入 Agent 后运行时会按受控路径推进1. 读取用户显式引用的版本方案 2. 提取版本方案里的目标、非目标、关键变更、测试计划等信息 3. 生成 tasklist 草稿 v1 4. 调用任务清单结构校验工具 5. 如果结构有问题最多修正一次 6. 再次结构校验 7. 输出可复制的 tasklist 草稿整个过程会通过 Agent 执行面板展示出来读取版本方案 生成 tasklist 草稿 v1 校验 tasklist 结构 v1 自动修正 tasklist 草稿 v2 再次校验 tasklist 结构 v2 输出最终答案AI Mind 的实际效果图这里可以看到几个概念的分工输入框负责结构化输入 Resource 负责提供版本方案上下文 Agent 负责多步骤任务推进 Tool 负责结构校验 Runtime 负责状态控制和边界约束 Stream 负责展示过程和结果这个例子里没有完整 RAG因为没有检索和召回。它只是用户显式引用版本方案系统读取这个 Resource 并用于生成 tasklist。这也是我想强调的边界受控 Resource 读取不是 RAG但它是很多 AI 应用走向 RAG 之前的一步。8. 一张图串起来再把这些概念放到一条链路里看用户输入 ↓ 输入层/命令 资源 ↓ 运行时 ↓ Skill / Agent ↓ Tool / Resource / Prompt ↓ MCP / 本地能力 ↓ 模型 ↓ 流式输出 / Agent 执行面板这张图里每一层解决的问题都不一样。输入层解决输入结构化问题用户到底是普通提问还是 /summary还是 /tasklist 用户有没有 引用资源运行时解决执行和边界问题当前任务应该走普通问答还是走 Skill还是进入 Agent 哪些资源能读 哪些工具能用 最多执行几步 失败后怎么收束Skill 解决能力分组问题这是阅读类任务还是工具类任务 应该暴露哪些能力Agent 解决多步骤推进问题现在走到哪一步 是否需要修正 是否可以输出最终结果Tool 解决具体执行问题校验结构 计算日期 查询信息 转换格式Resource 解决上下文来源问题读取哪个文档 读取哪个版本方案 读取哪个外部上下文MCP 解决外部能力接入问题外部服务怎么把 Tool / Resource / Prompt 暴露给 AI 应用流式输出解决可观察性问题用户怎么看到模型正在做什么 工具调用有没有完成 Agent 走到哪一步把这些边界拆开AI 应用就不会变成一坨混在一起的 prompt 和工具调用。9. 总结先分清层次再谈架构做 AI 应用时我现在越来越觉得概念本身不难难的是不要把所有东西混在一起。读文档不等于 RAG。调工具不等于 Agent。接入 MCP 不等于做了 Agent 平台。Skill 不是单个函数而是一组能力的组织方式。Tool 是具体能力Agent 是多步骤任务推进链路。MCP 是能力接入协议Runtime 才是把这些能力组织、约束、执行和展示出来的工程层。最后再用一句话收束Agent 解决决策问题。 RAG 解决知识问题。 Tool 解决动作问题。 Skill 解决能力组织问题。 MCP 解决外部能力接入问题。 Runtime 解决这些东西怎么安全、稳定、可观察地跑起来。AI Mind 目前也不是完整 AI 平台。它更像一个持续迭代的 AI Runtime 实验项目。从 Tool Calling到 Skill Runtime到 MCP 接入再到可控 Tasklist Agent我更关注的是一步步把这些边界拆清楚而不是一开始就把所有概念都堆进来。项目地址 GitHubhttps://github.com/HWYD/ai-mind 线上体验https://ai.hwyblog.cloud/instant-mind如果这篇文章或者 AI Mind 项目对你有所帮助也欢迎给项目点个 Star⭐。你的支持会是我持续更新这个系列、继续整理项目实现过程和设计复盘的很大动力。