01引言大多数人第一次接触大模型都是从聊天开始的输入一个问题等它返回一段文字。翻译文章、整理会议纪要、编写代码甚至起草销售报告都能在这个对话框里完成。可到了真实工作中一段文字经常只是半成品。例如老板要的是一份本月销售汇报。你得读取真实数据找出异常变化核对历史记录再把结论写进公司的模板。中途发现字段缺失还要决定是继续查询还是停下来补数据。大模型能理解和生成内容却不会天然连接公司的数据库也不会凭空获得文件操作权限。如何在模型之外接上数据和工具并把整个过程组织起来正是大模型应用开发要处理的事情。02先看全貌一个大模型应用由什么组成先把模型放到一边看看一个完整应用还需要什么。组成部分主要作用大模型理解需求、生成内容参与判断下一步动作提示词与上下文告诉模型当前任务、已有信息和执行要求数据与知识提供业务数据、文档和模型原本不知道的信息工具查询数据库、搜索资料、运行代码或生成文件应用程序组织执行过程管理权限并把结果呈现给用户这里的“工具”并不一定是一款独立软件。一个查询数据库的函数、一段生成 Excel 的程序或者某个业务系统提供的 API都可以成为模型应用中的工具。API 是软件之间交换请求与结果的一种接口。模型通常不会直接控制这些系统。应用程序先告诉模型有哪些工具可用模型给出选择和参数应用程序执行操作再把结果送回来。模型负责理解、生成和判断真正连接数据、工具与业务流程的仍是外围程序。03直接对话模型先成为内容生成器最基础的大模型应用就是对话●●●CODE用户输入 → 大模型 → 文本回答问答、翻译、总结和内容创作都适合这种方式。用户只要说清楚需求不必先学会一套复杂的菜单和命令。仍以销售分析为例。如果把整理好的数据直接贴进对话框模型可以帮助概括趋势、分析可能的原因并起草报告内容。问题也很直接数据没给它就不知道真实销量没接文档工具它通常只能返回文本没有权限它也不能替你更新业务系统。对话让模型变得好用却还不足以稳定完成一项业务任务。04工作流把模型放进一条确定的流程如果任务步骤比较固定可以先把流程编排出来再让大模型负责其中适合语言处理的部分。这种方式通常称为工作流Workflow。例如一份销售报告可以按下面的步骤生成●●●CODE读取销售数据 ↓按照固定规则完成统计 ↓调用大模型归纳异常和趋势 ↓把结果写入报告模板 ↓生成 Word 或 PPT 文件在这条流程中读取哪个文件、先算什么指标、最后使用哪个模板都是开发者提前确定的。大模型不必负责所有工作它可以只处理“解释数据”和“组织语言”这两个环节。工作流的路径清楚测试起来也相对容易。日报生成、合同信息提取、工单分类这类规则稳定的任务往往不需要更复杂的方案。它的局限也来自固定性。如果业务规则出现了流程之外的情况就需要提前增加判断分支。例如数据文件缺少某个字段时是直接报错、询问用户还是改用另一套分析方法都要在流程中安排好。这里有个容易误解的地方工作流里的模型并非一定看不到后续结果应用照样可以把每一步结果再交给它。工作流和 Agent 真正的差别是下一步由预设流程决定还是由模型根据现场情况来选。05Agent让模型参与决定下一步当任务路径无法完全提前确定时可以让模型根据当前状态选择下一步操作。这类系统通常称为 Agent也就是智能体。Agent 不只是生成一段最终答案。应用会提前告诉它有哪些工具、每个工具能做什么以及哪些操作必须经过确认。接到任务后模型先判断是否需要调用工具再根据工具返回的结果继续行动。一个简化的执行过程是●●●CODE理解任务 ↓选择工具与参数 ↓应用程序执行工具 ↓把执行结果返回给模型 ↓继续判断或者给出最终结果在销售分析任务中Agent 可能先读取本月数据发现华东地区销量异常下降再决定查询上个月记录。如果历史数据仍不足以判断它还可以继续检查退货数据最后生成报告。执行路径到了这里不再完全写死。模型会看到中间结果并在允许的范围内调整下一步。不过我并不认为自主性越高就越好。模型会判断错工具也会执行失败。尤其是删除数据、发送消息、修改订单这类操作一旦出错影响已经超出聊天窗口。因此一个可用的 Agent 还需要明确可调用的工具和参数范围设置最大执行次数和停止条件记录每一步操作和返回结果对敏感动作加入人工确认在失败或信息不足时交还给用户处理。固定而且不能出错的步骤继续放在工作流里更稳妥。需要根据现场信息调整的部分再交给 Agent。06MCP统一工具和数据的接入方式Agent 要调用工具应用首先得知道工具叫什么、需要哪些参数、执行后会返回什么。如果每个 AI 应用都有一套接入格式同一个数据库查询工具就得反复适配。模型上下文协议Model Context ProtocolMCP处理的是这个问题让 AI 应用以相对统一的方式连接外部工具和数据。MCP 采用 Host、Client 和 Server 组成的架构。入门阶段可以先这样理解Host 是承载模型和交互过程的 AI 应用Client 负责与某个 MCP Server 建立连接Server 按照协议对外提供工具、资源和提示模板等能力。例如开发者可以建立一个销售系统 MCP Server对外提供“查询月度销量”“读取退货数据”等工具。支持 MCP 的 AI 应用通过 Client 连接后就能发现这些能力并按照统一的结构发起调用。●●●CODEAI 应用中的 Agent ↓ MCP Client ↓ MCP Server ↓销售数据库或其他业务系统MCP 经常被比作 AI 世界的 USB 接口用来理解“统一连接方式”确实很直观。但这个比喻到这里就该停了MCP 统一的是通信和能力描述方式不会顺手把工具开发、权限和安全问题也解决掉。工具仍然要有人开发和维护身份认证、访问权限、用户确认和异常恢复也得由应用处理。Server 声明了某项能力也不等于所有 Host 都完整支持。所以Agent 并非必须使用 MCP。应用只连接少量固定接口时直接调用普通 API 可能更省事等到同一套工具要被多个 AI 应用复用标准化接入才更有吸引力。07Skill把完成任务的方法交给 Agent连接工具之后还有另一个问题Agent 知道工具能做什么却未必知道一项具体工作应该怎样完成。例如数据库工具可以返回销售数据但一份合格的销售分析还要遵守公司的业务规则先检查哪些字段怎样判断异常报告需要包含哪些章节哪些结论必须给出数据依据。这类可以反复使用的任务方法可以整理成 Skill。把它理解成 Agent 的工作说明书就行里面通常会写清楚这项技能适用于什么任务执行任务时要遵循哪些步骤可以使用哪些模板、资料和工具输出结果应采用什么格式哪些情况必须停止或向用户确认。销售分析 Skill 可以要求 Agent 先检查数据完整性再对比历史趋势然后标记异常区域最后使用统一模板生成报告。业务规则变化时可以修改说明和模板而不必把所有细节都写进主程序。有些 Agent 系统会按需加载 Skill。模型先看到技能名称和简短描述确认任务相关后再去读取完整说明和资料。这样不用一开始就把所有规则塞进上下文。不同产品对 Skill 的文件结构和加载方式并不一致它也不是一套跨平台通用协议。更值得关注的是背后的做法把任务经验整理出来让 Agent 能找到、能复用也方便后来修改。Skill 和 MCP 解决的也不是同一个问题概念主要解决什么问题SkillAgent 应该怎样完成某一类任务MCPAI 应用怎样连接外部工具和数据一个 Skill 可以指导 Agent 通过 MCP 调用工具也可以使用应用内置工具或普通 API。二者可以配合并不是前后替代关系。08真实应用通常是多种方式的组合看到这里最容易产生的误解是把对话、工作流、Agent、MCP 和 Skill 排成五代技术认为后面的会淘汰前面的。实际项目很少这么整齐它们经常同时出现。一套销售分析应用可能采用下面的组合●●●CODE用户在应用界面提交任务 ↓工作流完成身份检查和数据准备 ↓Agent 判断需要分析哪些异常 ↓按需加载销售分析 Skill ↓通过 MCP 或普通 API 查询业务数据 ↓工作流审核格式并生成最终文档 ↓涉及外发操作时等待人工确认这套组合里每部分各管一段工作流负责必须稳定执行的固定步骤Agent 负责无法提前穷举的动态判断Skill 提供完成任务的方法和业务经验MCP 或 API 负责接入外部数据与工具应用程序负责权限、状态、日志和结果展示。做应用时与其争论应该选哪个名词不如先划清边界哪些地方值得让模型判断哪些地方必须继续由确定性的程序控制。09开发时应该怎样选择面对一个需求可以先问三个问题要不要读取外部数据步骤是否固定执行中是否需要临时改变主意。任务特点可以优先考虑只需要问答、总结或内容生成直接调用大模型步骤固定结果需要稳定复现工作流需要根据中间结果决定下一步Agent多个 AI 应用需要复用相同工具MCP希望沉淀可重复使用的任务方法Skill既有固定步骤也有动态判断工作流与 Agent 组合还要算一笔错误成本。任务即使步骤很多只要路径明确、结果要求严格工作流往往更合适。资料调查、异常分析这类很难提前列出全部路径的任务才值得让 Agent 在边界内动态处理。一个实用的原则是能用简单方式稳定完成的任务不必为了追求“智能”而强行改造成全自主 Agent。我的建议是先从一次模型调用开始。遇到真实问题后再增加数据检索、工具调用和 Agent 决策。系统每多一层都要付出调试和维护成本最好让这份复杂度来得有理由。