1. 从“会用”到“用好”AI大模型应用的能力分水岭很多人用AI大模型的路径都差不多打开对话框输入问题等它吐出一段文字复制粘贴完事。这个阶段我称之为“问答模式”本质上就是把大模型当成一个更聪明的搜索引擎在用。但如果你仔细观察身边那些真正把AI用出生产力的人会发现他们的操作方式完全不同——他们不是在“问”AI而是在“指挥”AI干活。这个区别就是普通用户和高效使用者的分水岭。我自己在这个转变上踩过不少坑。早期我也是把大模型当聊天机器人用写文案、查资料、翻译文档效率确实有提升但总觉得差点意思。直到我开始接触Agent Skills、MCP协议、LangChain这些概念才意识到问题的核心大模型本身只是一个“大脑”它没有手没有脚不能主动去读取你的文件、不能调用你的数据库、不能操作你的浏览器。你要让它真正“下地干活”就必须给它配上工具和技能。这一篇要聊的就是怎么把AI大模型从“嘴炮王者”变成“实干家”。核心围绕四个东西展开Agent Skills智能体技能、SKILL.md技能描述文件、MCP模型上下文协议、LangChain智能体编排框架。这四个概念不是孤立的它们之间有清晰的层次关系。我会从整体设计思路讲起然后逐个拆解核心细节再给出一套可复现的实操流程最后把我遇到过的问题和排查经验整理出来。无论你是刚接触AI应用开发的新手还是已经在用LangChain搭东西的老手应该都能从中找到对自己有用的部分。提示这篇文章不涉及任何需要特殊网络环境才能访问的内容所有工具和框架均为公开可获取的开源项目或正规商业产品。2. 整体设计思路为什么需要“技能”和“协议”2.1 大模型的能力边界在哪里先搞清楚一个基本问题大模型能做什么不能做什么。大模型的核心能力是理解和生成自然语言它能读懂你的意图能写出通顺的文字能进行逻辑推理。但它有几个硬伤第一它不能主动获取实时信息训练数据截止之后就一无所知第二它不能操作外部系统不能帮你发邮件、查数据库、点按钮第三它没有持久记忆每次对话都是从零开始。这三个硬伤决定了如果你只用一个裸的大模型它能帮你做的事情非常有限。你问它“今天天气怎么样”它只能根据训练数据编一个答案因为它没有实时数据。你让它“帮我把这份Excel里的数据整理一下”它做不到因为它碰不到你的文件系统。所以要让大模型真正有用就必须解决这三个问题给它接上实时数据源、给它操作外部系统的能力、给它记住上下文和历史。这就是Agent Skills和MCP要解决的核心问题。2.2 Agent Skills的本质给大模型装“操作手册”Agent Skills这个概念说白了就是给大模型写一份“操作手册”告诉它在什么场景下应该做什么、怎么做。你可以把它理解成给一个新员工写的SOP标准作业程序。新员工能力再强如果不告诉他公司的流程、工具怎么用、遇到问题找谁他也干不了活。一个Skill通常包含几个要素触发条件什么情况下用这个技能、执行步骤具体怎么做、所需工具需要调用哪些外部能力、输出格式结果应该长什么样。比如你做一个“日报生成”的Skill触发条件是“用户要求生成日报”执行步骤是“读取当日工作记录→提取关键事项→按模板组织→输出”所需工具是“文件读取API”输出格式是“Markdown格式的日报”。这里的关键在于Skill不是代码而是描述。它用自然语言告诉大模型“你应该怎么做”大模型根据这个描述来规划自己的行动。这跟传统的编程思路完全不同——传统编程是你写死每一步逻辑Skill是你给大模型一个框架让它自己填充细节。2.3 SKILL.md的角色技能的标准载体SKILL.md就是承载Skill描述的文件格式。为什么用Markdown因为大模型对Markdown的理解能力最强结构清晰、层次分明而且人类也能直接阅读和编辑。一个典型的SKILL.md文件长这样# 日报生成技能 ## 触发条件 当用户说“生成今天的日报”或“帮我写日报”时触发。 ## 执行步骤 1. 调用文件读取工具获取 ~/worklog/today.md 的内容 2. 提取其中的关键事项按“完成/进行中/待办”分类 3. 按照公司日报模板组织内容 4. 输出Markdown格式的日报 ## 所需工具 - 文件读取工具read_file - 日期获取工具get_current_date ## 输出格式 参考 ~/templates/daily_report.md 的格式这个文件的好处是它既是给大模型看的指令也是给人看的文档。你团队里任何人拿到这个文件都能理解这个技能是干什么的、怎么工作的。而且修改起来极其方便改几个字就能调整大模型的行为不需要重新编译部署。2.4 MCP协议统一工具调用的“插座标准”MCP的全称是Model Context Protocol翻译过来叫“模型上下文协议”。你可以把它理解成AI世界的USB接口标准。在没有MCP之前每个大模型平台调用外部工具的方式都不一样OpenAI有一套Function Calling的格式Anthropic有自己的一套开源模型又各有各的做法。你想让大模型调用一个数据库得针对每个平台写不同的适配代码烦不胜烦。MCP的出现就是为了解决这个问题。它定义了一套标准的协议规定了大模型怎么发现工具、怎么调用工具、怎么接收结果。任何工具只要实现了MCP协议就能被任何支持MCP的大模型调用。这就像USB接口统一了外设连接标准一样你不需要关心鼠标是罗技的还是雷蛇的插上就能用。MCP的工作模式是这样的你运行一个MCP Server它暴露一组工具比如“查询数据库”“发送邮件”“读取文件”。大模型通过MCP Client连接到这个Server发现有哪些工具可用然后根据任务需要调用相应的工具。整个过程是标准化的跟具体的大模型平台无关。2.5 LangChain的定位智能体的“总调度”LangChain是一个用来构建大模型应用的框架。如果说MCP是插座标准Agent Skills是操作手册那LangChain就是整个系统的总调度。它负责把大模型、工具、记忆、技能这些东西串起来形成一个完整的智能体。LangChain的核心抽象包括Model大模型、Tool工具、Agent智能体、Memory记忆、Chain链。你用LangChain搭一个智能体大概的流程是定义一个Agent给它配一个大模型挂上几个Tool设置好Memory然后Agent就会根据用户的输入自动决定调用哪个工具、怎么处理结果、怎么组织回复。LangChain的好处是它把很多底层细节封装好了你不需要从零实现工具调用、上下文管理、错误处理这些东西。但坏处是抽象层次比较高出了问题排查起来比较麻烦。我后面会专门讲这块的坑。2.6 四者的协作关系把这四个东西串起来看LangChain是骨架负责整体调度MCP是神经负责连接外部工具Agent Skills是肌肉记忆告诉智能体在特定场景下怎么做SKILL.md是载体把技能描述固化下来。一个完整的智能体应用大概是这样的结构LangChain Agent作为主控通过MCP Client连接多个MCP Server每个MCP Server提供一组工具Agent根据SKILL.md中的描述决定调用哪些工具执行结果返回给AgentAgent组织成最终回复这个架构的好处是高度模块化。你想加一个新能力只需要写一个MCP Server暴露新工具再写一个SKILL.md描述怎么用这个工具不需要改动核心逻辑。这种可扩展性是构建复杂AI应用的基础。3. 核心细节解析与实操要点3.1 怎么写一份大模型能看懂的SKILL.md写SKILL.md看着简单实际上很考验功力。我见过太多人写的Skill大模型根本执行不了问题出在描述太模糊。比如“处理用户请求”这种描述大模型看了等于没看它不知道具体要做什么。一份好的SKILL.md核心原则是“具体到不需要思考”。你要假设读这个文件的是一个能力很强但完全不了解你业务的新人他需要知道什么情况下触发、第一步做什么、第二步做什么、每一步用什么工具、遇到异常怎么办、最终输出什么格式。我总结了一个模板结构实测下来大模型执行准确率最高# 技能名称 ## 何时使用 [具体的触发条件越具体越好] ## 前置检查 [执行前需要确认的事项] ## 执行步骤 1. [第一步包含调用的工具和参数] 2. [第二步说明如何处理上一步的结果] 3. [第三步说明如何组织输出] ## 异常处理 - 如果[某步骤]失败则[备选方案] - 如果[某数据]缺失则[默认行为] ## 输出要求 [格式、长度、语气等要求]这里有个关键技巧步骤描述要用“动词开头”比如“调用”“提取”“判断”“输出”而不是“对……进行处理”这种被动描述。大模型对动词开头的指令执行得更准确。另一个技巧是在SKILL.md里可以嵌入示例。比如你写一个“代码审查”的技能可以在文件末尾附上一段示例输入和期望输出。大模型看到示例后执行准确率会明显提升。这跟Few-shot Prompting是一个道理。3.2 MCP Server的搭建与工具暴露搭建一个MCP Server本质上就是把你已有的能力包装成标准接口。假设你有一个内部数据库你想让大模型能查询它你需要写一个MCP Server暴露一个“query_database”工具。MCP Server的实现方式取决于你用什么语言。Python的话官方有mcp库可以用。一个最简单的MCP Server大概长这样from mcp.server import Server from mcp.types import Tool, TextContent server Server(my-database-server) server.list_tools() async def list_tools(): return [ Tool( namequery_database, description查询内部数据库输入SQL语句返回查询结果, inputSchema{ type: object, properties: { sql: {type: string, description: 要执行的SQL查询语句} }, required: [sql] } ) ] server.call_tool() async def call_tool(name: str, arguments: dict): if name query_database: result execute_sql(arguments[sql]) return [TextContent(typetext, textstr(result))]这段代码的关键在于description字段。大模型就是靠这个描述来判断什么时候该调用这个工具的。所以描述要写得清楚这个工具是干什么的、输入是什么、输出是什么。不要写“查询数据库”就完了要写“查询内部销售数据库支持标准SQL语句返回JSON格式的查询结果”。工具的参数定义也很重要。inputSchema用的是JSON Schema格式你要把每个参数的类型、描述、是否必填都写清楚。大模型会根据这个Schema来构造调用参数Schema写得越清楚大模型传参的准确率越高。3.3 LangChain Agent的配置与调优用LangChain搭Agent核心是选对Agent类型和配好工具。LangChain提供了几种Agent类型常用的有zero-shot-react-description、conversational-react-description、openai-functions等。选哪种取决于你的场景如果只是简单的工具调用用openai-functions最省事如果需要多轮对话带记忆用conversational-react-description如果需要复杂的推理链可以考虑plan-and-execute。配置Agent的时候有几个参数特别关键max_iterations最大迭代次数控制Agent最多执行多少步。设太小了任务完不成设太大了可能陷入死循环。一般设10-15比较合适。max_execution_time最大执行时间防止Agent卡死。根据任务复杂度设一般60-120秒。early_stopping_method提前停止策略当Agent认为任务完成时怎么处理。一般用force强制返回当前结果。handle_parsing_errors解析错误处理当大模型输出的格式不对时怎么办。建议设为True让LangChain自动重试。工具配置方面每个工具都要有清晰的name和description。name要简短且唯一description要详细说明工具的用途和输入输出。我见过有人把工具名写成tool1、tool2大模型根本不知道什么时候该用哪个。工具名应该像search_web、read_file、send_email这样一看就知道是干什么的。3.4 工具调用的参数传递与结果处理工具调用最容易出问题的地方是参数传递。大模型根据工具的Schema生成参数但有时候会生成格式不对的参数。比如Schema要求整数它传了个字符串Schema要求数组它传了个对象。这种问题在LangChain里通常表现为ValidationError。处理这类问题我的经验是在工具函数入口加一层参数校验和转换。比如def safe_int(value): if isinstance(value, int): return value if isinstance(value, str): return int(value.strip()) raise ValueError(f无法转换为整数: {value})然后在工具函数里用这个safe_int来处理参数。这样即使大模型传参格式不太对也能自动纠正。结果处理方面工具返回的结果要尽量结构化。不要返回一大段自然语言而是返回JSON格式的数据。大模型对结构化数据的处理能力更强而且后续步骤如果需要提取字段结构化数据更方便。如果工具返回的是自然语言建议在返回前做一次结构化转换。3.5 多工具协作的编排策略当Agent挂载了多个工具时怎么编排它们的调用顺序是个关键问题。LangChain的ReAct模式是让大模型自己决定调用顺序但实际用下来大模型有时候会选错工具或者顺序搞反。我的做法是在SKILL.md里明确写出工具调用的顺序。比如一个“竞品分析”的技能我会写清楚第一步用search_web搜索竞品信息第二步用read_file读取内部产品文档第三步用compare_data对比数据第四步用generate_report生成报告。这样大模型就不会乱来了。另一个技巧是给工具设置优先级。在工具描述里加上“优先使用此工具”或“仅当其他工具不可用时使用此工具”这样的提示。大模型对这类提示的遵循度还不错。如果工具之间有依赖关系比如工具B的输入是工具A的输出那就在SKILL.md里明确写出来“将第一步的输出作为第二步的输入”。不要让大模型自己去推断依赖关系它有时候会搞错。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说一下我的环境Python 3.11macOS16GB内存。这个配置跑LangChain和MCP Server完全够用。如果你用Windows建议用WSL2因为有些MCP Server在Windows原生环境下会有路径问题。安装依赖pip install langchain langchain-openai mcp python-dotenv如果你要用Anthropic的模型再加一个pip install langchain-anthropic环境变量配置创建一个.env文件OPENAI_API_KEY你的key ANTHROPIC_API_KEY你的key这里注意不要把key硬编码在代码里用python-dotenv加载。我见过有人把key提交到GitHub上结果被人盗刷了几百美元。4.2 搭建第一个MCP Server我们来搭一个实用的MCP Server文件操作服务。它暴露三个工具读取文件、写入文件、列出目录。import os from mcp.server import Server from mcp.types import Tool, TextContent server Server(file-server) server.list_tools() async def list_tools(): return [ Tool( nameread_file, description读取指定路径的文件内容返回文本, inputSchema{ type: object, properties: { path: {type: string, description: 文件的绝对路径} }, required: [path] } ), Tool( namewrite_file, description将内容写入指定路径的文件如果文件不存在则创建, inputSchema{ type: object, properties: { path: {type: string, description: 文件的绝对路径}, content: {type: string, description: 要写入的内容} }, required: [path, content] } ), Tool( namelist_directory, description列出指定目录下的所有文件和子目录, inputSchema{ type: object, properties: { path: {type: string, description: 目录的绝对路径} }, required: [path] } ) ] server.call_tool() async def call_tool(name: str, arguments: dict): if name read_file: with open(arguments[path], r, encodingutf-8) as f: content f.read() return [TextContent(typetext, textcontent)] elif name write_file: with open(arguments[path], w, encodingutf-8) as f: f.write(arguments[content]) return [TextContent(typetext, textf已写入 {arguments[path]})] elif name list_directory: entries os.listdir(arguments[path]) return [TextContent(typetext, text\n.join(entries))]这个Server跑起来后大模型就能通过MCP协议调用这三个工具了。注意read_file和write_file的路径参数我要求传绝对路径避免相对路径带来的歧义。4.3 编写SKILL.md并接入LangChain现在写一个“代码审查”的SKILL.md# 代码审查技能 ## 何时使用 当用户要求审查代码、检查代码质量、或提供代码改进建议时使用。 ## 前置检查 - 确认用户提供了代码文件路径或代码内容 - 确认审查的语言类型Python/JavaScript/Java等 ## 执行步骤 1. 如果用户提供的是文件路径调用 read_file 读取文件内容 2. 分析代码检查以下方面 - 语法错误和潜在bug - 代码风格一致性 - 性能问题 - 安全隐患 3. 按严重程度分类问题严重/警告/建议 4. 对每个问题给出具体的修改建议和示例代码 5. 输出审查报告 ## 异常处理 - 如果文件不存在提示用户检查路径 - 如果代码语言无法识别默认按Python处理 ## 输出要求 - 使用Markdown格式 - 每个问题包含位置、问题描述、修改建议 - 最后给出总体评分1-10分然后在LangChain里加载这个Skillfrom langchain.agents import initialize_agent, AgentType from langchain_openai import ChatOpenAI from langchain.tools import Tool from mcp_client import MCPClient # 连接MCP Server mcp_client MCPClient(http://localhost:8000) # 把MCP工具包装成LangChain Tool tools [] for mcp_tool in mcp_client.list_tools(): tools.append(Tool( namemcp_tool.name, descriptionmcp_tool.description, funclambda input, tmcp_tool: mcp_client.call_tool(t.name, input) )) # 加载SKILL.md作为系统提示 with open(skills/code_review.md, r) as f: skill_prompt f.read() # 初始化Agent llm ChatOpenAI(modelgpt-4, temperature0) agent initialize_agent( toolstools, llmllm, agentAgentType.OPENAI_FUNCTIONS, verboseTrue, max_iterations10, early_stopping_methodforce, agent_kwargs{system_message: skill_prompt} ) # 执行任务 result agent.run(请审查 ~/projects/demo.py 这个文件) print(result)这段代码的关键在于agent_kwargs{system_message: skill_prompt}把SKILL.md的内容作为系统提示注入。这样Agent在执行任务时就会按照SKILL.md中描述的步骤来操作。4.4 完整案例自动生成周报我们来走一个完整的案例自动生成周报。这个案例会用到文件读取、日期获取、文本生成三个能力。首先MCP Server需要增加一个获取日期的工具from datetime import datetime server.list_tools() async def list_tools(): return [ # ... 之前的工具 ... Tool( nameget_current_date, description获取当前日期返回格式为YYYY-MM-DD, inputSchema{type: object, properties: {}} ) ] server.call_tool() async def call_tool(name: str, arguments: dict): # ... 之前的处理 ... if name get_current_date: return [TextContent(typetext, textdatetime.now().strftime(%Y-%m-%d))]然后写周报生成的SKILL.md# 周报生成技能 ## 何时使用 当用户说“生成本周周报”或“帮我写周报”时触发。 ## 执行步骤 1. 调用 get_current_date 获取当前日期 2. 计算本周的日期范围周一到周五 3. 调用 read_file 读取 ~/worklog/ 目录下本周的所有日志文件 4. 从日志中提取关键事项按以下分类整理 - 已完成事项 - 进行中事项 - 遇到的问题 - 下周计划 5. 按照周报模板组织内容 6. 调用 write_file 将周报保存到 ~/reports/weekly_YYYY-MM-DD.md ## 输出要求 - 使用Markdown格式 - 每个事项用一句话概括 - 问题部分要包含解决方案或需要的支持执行这个Agentresult agent.run(帮我生成本周周报)Agent会自动执行获取日期→计算周范围→读取日志→提取事项→生成周报→保存文件。整个过程不需要人工干预。4.5 参数计算与选择过程在配置Agent的时候有几个参数需要根据实际情况计算。我拿max_iterations举例说明怎么定这个值。假设你的任务平均需要调用3个工具每个工具调用算一步加上大模型思考和最终输出大概需要5-7步。那么max_iterations至少设10留一些余量。但如果设太大比如50当Agent陷入循环时它会一直调用工具直到达到上限浪费时间和token。我的经验公式是max_iterations 预期工具调用数 × 2 3。比如预期调用3个工具那就是3×239取整设10。max_execution_time的计算类似。每个工具调用平均耗时2-5秒大模型思考耗时3-10秒。如果预期7步那就是7×(510)105秒设120秒比较安全。这些参数不是固定的需要根据实际运行情况调整。我建议先用保守值跑几次观察实际耗时和步数再优化。5. 常见问题与排查技巧实录5.1 工具调用失败排查表问题现象可能原因排查方法解决方案Agent不调用任何工具工具描述不清晰检查工具description是否说明了用途重写description明确工具功能和适用场景调用工具时报ValidationError参数类型不匹配打印大模型生成的参数在工具函数入口加类型转换工具调用后Agent不继续返回值格式不对检查工具返回的内容确保返回TextContent类型Agent陷入循环调用任务目标不明确查看Agent的思考过程在SKILL.md中明确终止条件MCP连接失败Server未启动或端口错误检查Server日志和端口确认Server运行且端口正确工具调用超时工具执行时间过长检查工具函数执行时间增加超时设置或优化工具性能5.2 大模型“不听话”的几种典型情况第一种大模型不按SKILL.md的步骤走。这种情况通常是因为SKILL.md的描述不够具体或者步骤之间有歧义。解决办法是把步骤拆得更细每一步只做一件事并且用明确的动词开头。第二种大模型选错工具。比如该用read_file的时候用了search_web。这通常是因为两个工具的description太相似。解决办法是在description里明确区分使用场景比如read_file写“读取本地文件”search_web写“搜索互联网信息”。第三种大模型生成的参数格式不对。比如Schema要求数组它生成了字符串。解决办法是在工具函数里做参数兼容处理同时可以在SKILL.md里加一个参数示例告诉大模型正确的格式。第四种大模型提前终止任务。比如任务还没完成就返回了结果。这通常是因为early_stopping_method设成了force而大模型误判任务已完成。解决办法是在SKILL.md里明确写出完成条件比如“必须生成报告文件后才能结束”。5.3 性能优化的几个实用技巧第一个技巧缓存工具调用结果。如果某个工具调用结果在短时间内不会变化可以加一层缓存。比如读取文件内容如果文件没修改第二次读取可以直接用缓存。LangChain有内置的Cache机制配置一下就行。第二个技巧并行调用无依赖的工具。如果两个工具之间没有依赖关系可以让它们并行执行。LangChain的AgentExecutor支持并行工具调用在SKILL.md里标注哪些步骤可以并行即可。第三个技巧限制上下文长度。Agent执行过程中会产生大量中间结果如果不加限制上下文会越来越长导致token消耗剧增。可以在Agent配置里设置max_tokens或者在SKILL.md里要求大模型对中间结果做摘要。第四个技巧用更小的模型做工具调用决策。工具调用决策不需要太强的推理能力用GPT-3.5或者更小的模型就够了。只在最终生成内容时用GPT-4。这样能大幅降低成本。5.4 安全与权限控制让大模型操作外部系统安全是个必须考虑的问题。我踩过的坑包括大模型误删了文件、大模型把敏感数据写到了日志里、大模型调用了不该调用的接口。我的做法是加三层防护第一层在MCP Server层面做权限控制敏感操作需要额外的token验证第二层在工具函数里做输入校验比如文件路径必须在指定目录下SQL语句必须是SELECT开头第三层在SKILL.md里写明禁止操作比如“禁止删除文件”“禁止修改生产数据库”。另外所有工具调用都要记日志。日志内容包括调用时间、工具名、参数、返回值、执行结果。出了问题可以追溯。5.5 调试与日志记录LangChain的verboseTrue会打印Agent的思考过程调试的时候很有用。但生产环境建议关掉或者把日志写到文件里。我习惯在MCP Server里也加日志import logging logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(mcp_server.log), logging.StreamHandler() ] ) server.call_tool() async def call_tool(name: str, arguments: dict): logging.info(f调用工具: {name}, 参数: {arguments}) try: result await execute_tool(name, arguments) logging.info(f工具 {name} 执行成功) return result except Exception as e: logging.error(f工具 {name} 执行失败: {str(e)}) raise这样出问题的时候翻日志就能定位到是哪一步出了错。5.6 版本兼容性避坑LangChain的版本更新非常快不同版本之间的API差异很大。我遇到过升级LangChain后原来的Agent代码跑不起来的情况。建议在requirements.txt里锁定版本langchain0.1.0 langchain-openai0.0.5 mcp0.1.0MCP协议本身也在演进不同版本的MCP Server和Client之间可能有兼容性问题。建议Server和Client用同一个版本。另外大模型的API也在变。OpenAI的Function Calling格式改过好几次Anthropic的Tool Use格式也调整过。如果你的代码依赖特定的API格式升级前一定要看Changelog。6. 从单技能到技能库规模化扩展的思路当你掌握了单个Skill的开发和接入之后下一步自然是构建一个技能库。我目前的技能库里有二十多个Skill覆盖了日常工作的方方面面代码审查、文档生成、数据分析、竞品调研、会议纪要整理等等。技能库的管理有几个要点。第一是命名规范我用领域-功能.md的格式比如dev-code_review.md、doc-meeting_notes.md这样一眼就能看出技能属于哪个领域。第二是版本控制每个Skill的修改都走Git方便回溯和协作。第三是定期清理有些Skill用了几次发现效果不好或者场景已经不需要了就及时删掉避免技能库臃肿。技能之间的组合也很重要。比如“竞品调研”这个任务可以拆成“搜索竞品信息”“读取内部文档”“对比分析”“生成报告”四个子技能每个子技能独立维护需要的时候组合起来用。这种模块化的思路让技能库的扩展变得非常灵活。我现在遇到一个新任务第一反应不是“怎么写代码实现”而是“有没有现成的Skill可以用没有的话怎么组合出来”。这种思维方式的转变才是高效使用AI大模型的核心。最后分享一个我最近在用的技巧把常用的SKILL.md放在一个目录里用LangChain的DirectoryLoader自动加载。这样新增技能只需要往目录里扔一个md文件不需要改代码。配合MCP的动态工具发现整个系统就是自扩展的。新工具接入后写一个对应的SKILL.md描述怎么用Agent就能自动学会这个新能力。这套机制跑通之后我的AI助手是真的能“下地干活”了不只是聊天。