1. 从“会聊天”到“会干活”为什么你的大模型总在空转每次看到“AI智能体”、“AI Agent”这些词我都有点哭笑不得。从业内视角看太多人把大模型当成了一个更聪明的聊天机器人以为给它一个任务它就能像科幻电影里的AI管家一样自动把事情办得漂漂亮亮。但现实往往是你让它“帮我分析一下这个季度的销售数据”它可能给你生成一段分析报告的文字却不会真的去数据库里拉取数据、计算环比增长率、生成可视化图表。你让它“监控服务器日志发现异常就告警”它可能只会复述一遍告警逻辑而不会去执行一个定时任务调用API发送告警信息。问题的核心在于我们混淆了“理解意图”和“执行任务”这两个完全不同的能力层级。当前的大语言模型LLM在“理解意图”上已经非常出色它能听懂你的自然语言指令甚至能拆解出复杂的步骤。但它的“执行能力”几乎为零——它没有手没有脚无法操作软件无法调用外部API无法读写数据库。它被困在文本的牢笼里空有一身“武艺”却无法施展。这就是“Skills”技能概念出现的背景。Skills不是魔法而是一种工程化的思想将人类在特定领域的操作经验封装成一个个可被大模型理解和调用的标准化“工具”或“函数”。你可以把它想象成给大模型打造一个“工具箱”。大模型负责理解你的需求并从工具箱里挑选合适的工具Skill然后按照工具的使用说明书函数定义去“使用”它。这个“使用”的过程实际上是由背后的代码逻辑来完成的。所以当我说“让大模型真正‘会干活’”时我指的是构建一个系统大模型作为“大脑”负责决策和规划而一个个封装好的Skills作为“四肢”负责具体执行。没有Skills大模型就是一个光说不练的“战略家”有了Skills它才能成为一个能落地、能交付结果的“实干家”。2. Skills的本质不是代码是经验的“乐高积木”很多人一听到“封装”第一反应就是写代码、定义API。这没错但只对了一半。Skills封装的核心远不止技术实现更在于对领域经验的抽象和标准化。2.1 一个Skill的完整构成一个设计良好的Skill应该包含以下四个层次意图描述自然语言用人类能理解的话告诉大模型“这个技能是干什么的”。例如“这是一个用于查询城市天气的技能。” 这部分直接决定了LLM能否在合适的场景下想起并调用这个技能。输入/输出规范结构化接口明确告诉大模型使用这个技能需要提供哪些参数以及会返回什么格式的结果。这就像函数的签名。例如输入{“city_name”: “string”}输出{“weather”: “string”, “temperature”: “number”, “humidity”: “number”}执行逻辑代码/配置技能背后真正的执行体。它可能是一段Python函数一个HTTP API调用一个数据库查询语句甚至是一个自动化脚本的触发。这部分对LLM是“黑盒”LLM不关心内部如何实现只关心调用它并得到结果。安全与错误处理边界定义这个技能在什么情况下不能使用以及执行失败时该如何反馈。例如天气查询技能需要检查城市名是否有效数据库操作技能需要严格的权限校验。这部分是保障系统稳定性的关键必须在设计时就考虑进去。2.2 与普通API/微服务的区别你可能会问这和我直接调用一个天气API有什么区别区别在于“认知层”。普通API调用需要开发者明确知道在代码的哪一行、什么条件下、以什么参数去调用哪个API。这是“硬编码”的逻辑是固定的。Skill调用开发者只需要告诉LLM“有什么工具可用”以及“工具的说明书”。LLM根据与用户的动态对话自主判断“此时此刻是否需要使用工具”以及“使用哪个工具、传入什么参数”。这是“动态规划”的逻辑是灵活的。举个例子用户说“我明天要去北京出差不知道要不要带伞。” 一个集成了天气Skill的智能体其内部思考链可能是理解用户意图查询北京明天的天气重点是降水情况。检索可用Skills发现有一个“查询城市天气预报”的Skill。规划执行调用该Skill参数city_name设为“北京”。处理结果收到{“weather”: “小雨”, “temperature”: 18, ...}然后组织语言回答“北京明天有小雨建议您带伞。”这个过程里“调用天气API”这个动作是由LLM自主决策触发的而不是开发者预先写死的。这就是Skills带来的根本性变革将固定的工作流转变为由自然语言驱动的、动态的智能工作流。2.3 经验封装的维度从简单到复杂Skills可以封装不同复杂度的经验原子操作如“发送邮件”、“查询数据库单条记录”、“生成一个随机数”。这是最基本的工具。业务流程如“新用户注册流程”包含验证邮箱、创建数据库记录、发送欢迎邮件等多个原子操作的组合。专业判断如“初步审核贷款申请材料完整性”基于规则和简单模型输出“通过”、“缺失XX材料”、“拒绝”等结构化结果。交互式任务如“引导用户完成产品配置”这个Skill可能需要与用户进行多轮对话动态收集信息。关键在于无论多复杂对外呈现给LLM的都应该是一个清晰的“意图描述”和“输入输出规范”。LLM不需要知道“审核贷款材料”背后是100条规则还是一个小型神经网络它只需要知道“给你一堆材料你能告诉我缺什么”。3. 手把手实战从零封装你的第一个Skill理论说再多不如动手做一遍。我们以一个非常实用且常见的场景为例封装一个“企业知识库问答”Skill。这个技能允许智能体根据用户问题自动从你公司的内部文档如Confluence、Wiki、PDF手册中查找相关信息并生成回答。3.1 第一步定义技能蓝图做什么在写任何代码之前我们先明确这个Skill的“说明书”。技能名称query_company_knowledge_base意图描述给LLM看“当用户询问与公司产品、制度、流程、历史等相关的问题时使用此技能从公司内部知识库中搜索最相关的信息片段用于辅助生成回答。”输入参数query(字符串必需): 用户的问题或需要查询的关键词。top_k(整数可选默认3): 返回最相关的信息片段数量。输出格式results(数组): 一个包含top_k个检索结果的数组。每个结果是一个对象包含content(字符串): 检索到的信息文本。source(字符串): 信息来源如文档标题、URL。relevance_score(浮点数): 相关性得分0-1之间。这个定义非常关键。它让LLM明白1什么时候该用这个技能2用的时候需要提供什么3用了之后会得到什么。3.2 第二步构建技能引擎怎么做这是技能的“黑盒”实现部分。我们采用目前最主流、效果也相对较好的技术方案文本嵌入向量检索。环境准备与核心工具选型编程语言Python生态丰富。向量数据库选用ChromaDB。理由轻量、易用、纯Python、支持内存和持久化模式非常适合中小规模知识库和快速原型验证。如果知识库极大百万级以上文档可以考虑Qdrant或Weaviate。文本嵌入模型选用text-embedding-3-small。理由OpenAI的API效果稳定接口简单且text-embedding-3系列在性价比和效果上取得了很好的平衡。如果要求完全本地化可以选用BAAI/bge-small-zh-v1.5这类开源模型但需要自己部署嵌入服务。文档加载与切分使用LangChain的DocumentLoader和TextSplitter。虽然我们强调不重复造轮子但LangChain在文档处理这块的封装确实能省去大量琐碎工作。核心实现代码拆解首先是知识库的构建只需运行一次或定期更新# knowledge_base_builder.py import os from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings import chromadb from chromadb.config import Settings # 1. 加载文档假设所有txt文档放在./docs目录下 loader DirectoryLoader(./docs, glob**/*.txt, loader_clsTextLoader) documents loader.load() # 2. 切分文档防止单个文档太长超出模型上下文 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个片段约500字符 chunk_overlap50 # 片段间重叠50字符保持上下文连贯 ) texts text_splitter.split_documents(documents) # 3. 初始化嵌入模型和向量数据库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection(namecompany_knowledge) # 4. 将文档转换为向量并存入数据库 for i, text in enumerate(texts): # 生成向量 embedding embeddings.embed_query(text.page_content) # 存入数据库元数据记录来源 collection.add( ids[fdoc_{i}], embeddings[embedding], metadatas[{source: text.metadata.get(source, unknown)}], documents[text.page_content] ) print(知识库构建完成)注意chunk_size的设置是门艺术。太小会丢失上下文太大会降低检索精度并增加成本。需要根据你的文档类型技术文档、会议纪要、QA进行微调。对于技术文档500-800是个不错的起点。接下来是Skill本身的实现# company_knowledge_skill.py import chromadb from chromadb.config import Settings from langchain_openai import OpenAIEmbeddings class CompanyKnowledgeSkill: def __init__(self, db_path./chroma_db): self.embeddings OpenAIEmbeddings(modeltext-embedding-3-small) self.client chromadb.PersistentClient(pathdb_path) self.collection self.client.get_collection(namecompany_knowledge) def query(self, query: str, top_k: int 3) - dict: 技能的核心函数对应我们定义的接口。 # 1. 将用户查询转换为向量 query_embedding self.embeddings.embed_query(query) # 2. 在向量数据库中搜索最相似的片段 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k ) # 3. 格式化输出符合我们定义的规范 formatted_results [] if results[documents]: for i in range(len(results[documents][0])): formatted_results.append({ content: results[documents][0][i], source: results[metadatas][0][i].get(source, N/A), relevance_score: round(results[distances][0][i], 4) # Chroma返回的是距离越小越相似 }) return {results: formatted_results} # 技能的使用示例在智能体框架中这个query方法会被调用 if __name__ __main__: skill CompanyKnowledgeSkill() answer skill.query(我们公司的年假制度是怎样的, top_k2) print(answer)3.3 第三步集成与测试怎么用现在我们需要把这个Skill“安装”到智能体框架中让LLM能调用它。以目前比较流行的Dify或LangChain的Agent框架为例集成方式本质上是将技能“注册”进去。在Dify中你可以在“工具”或“技能”配置页面通过“自定义工具”功能填入我们之前定义的“意图描述”、“输入参数”和“输出格式”并将API端点指向我们上面写的query方法需要包装成HTTP服务。在纯代码的LangChain Agent中你可以这样注册from langchain.agents import Tool from company_knowledge_skill import CompanyKnowledgeSkill knowledge_skill CompanyKnowledgeSkill() # 将技能包装成LangChain Tool company_knowledge_tool Tool( nameQueryCompanyKnowledge, funcknowledge_skill.query, # 这里绑定我们的核心方法 description当用户询问与公司产品、制度、流程、历史等相关的问题时使用此工具从公司内部知识库中搜索最相关的信息片段。输入应为一个明确的查询问题。 ) # 然后将这个tool加入到Agent的工具列表中测试环节至关重要你需要模拟各种提问正向测试“公司的产品定价策略是什么” - 应成功触发技能并返回相关文档片段。边界测试“今天天气怎么样” -不应触发此技能。这依赖于LLM对“意图描述”的理解能力。模糊测试“我怎么请假” - 应能触发并检索到休假流程相关文档。压力测试输入一个知识库中完全不存在的生僻词观察其返回结果应为空或低分片段并确保不会导致系统错误。4. 进阶设计可组合、可维护的Skills体系当你封装了十几个、几十个Skills后管理就成了大问题。如何让Skills体系不变成一团乱麻4.1 技能的分类与命名规范混乱始于命名。建议建立一套命名规范按领域前缀finance_财务、hr_人事、it_IT、sales_销售。按操作类型get_查询、create_创建、update_更新、calculate_计算、analyze_分析。按资源对象_user、_order、_document。例如hr_get_leave_balance查询剩余年假、sales_create_customer_record创建客户记录。清晰的命名能帮助LLM和开发者快速理解技能用途。4.2 技能的版本管理与依赖Skills不是一成不变的。API会变业务逻辑会变。你需要为Skill引入版本管理。在技能描述或元数据中明确版本号如version: 1.2.0。当技能更新时考虑向后兼容。如果必须做破坏性更新如输入参数变更最好创建一个新技能如query_knowledge_v2并在一段时间内并行支持旧版。明确技能的依赖比如某个数据分析Skill依赖于“数据查询Skill”的输出作为输入。这有助于在编排复杂任务时理解执行链。4.3 技能的可发现性与元信息除了基本的意图描述为每个Skill添加丰富的元信息能极大提升智能体调用它的准确性和效率使用示例提供2-3个典型的调用示例输入和输出。适用场景与限制明确说明在什么情况下推荐使用什么情况下不适用例如“本技能仅支持查询2023年之后的数据”。权限等级标注该技能所需的最低权限如“员工级”、“经理级”、“系统级”智能体在调用前可以进行初步的权限校验。执行成本/耗时对于可能消耗大量Token或执行时间较长的技能可以给出预估供LLM在规划时权衡。4.4 技能的编排与组合实现复杂工作流单个Skill能力有限真正的威力在于组合。智能体应该能够自动串联多个Skills来完成复杂任务。例如用户说“帮我分析一下上周销售冠军的业绩并给他写一封表扬邮件。”LLM规划这需要两个技能先sales_get_top_performer获取销售冠军信息再email_send_praise发送表扬邮件。LLM执行调用第一个技能获得输出{“name”: “张三”, “performance”: 150%}。LLM编排将第一个技能的输出张三的名字和业绩作为第二个技能的输入参数生成邮件内容并发送。这个过程中LLM扮演了“工作流引擎”的角色。为了让它更好地做到这一点我们在设计Skills时就要有“可组合性”意识输出标准化尽可能让输出是结构化的JSON方便后续技能解析。错误码统一定义一套通用的错误码和消息格式方便上层处理。提供“技能图谱”可以维护一个文件描述技能之间的输入输出关系辅助LLM进行规划。5. 避坑指南Skills开发中常见的“雷区”封装Skills听起来美好但踩坑是必经之路。下面是我从实际项目中总结的几个关键陷阱。5.1 意图描述模糊让LLM“猜不透”问题技能描述写成“处理数据”或“执行操作”。这太宽泛了LLM无法准确判断何时该调用。反面案例description: “这是一个有用的工具。”正确做法描述要具体包含触发条件和核心动作。使用“当……时用于……”的句式。正面案例description: “当用户需要将中文文本翻译成英文时使用此工具。输入是中文文本输出是对应的英文翻译。”5.2 忽视权限与安全打开潘多拉魔盒问题技能直接封装了删除数据库、发送全员邮件、审批付款等高危操作却没有做任何权限校验。一旦LLM被恶意诱导或误解指令后果严重。案例一个delete_user技能仅凭用户名就执行删除。解决方案技能层面在技能内部必须集成严格的权限验证逻辑。可以校验调用者的身份Token、角色或检查操作对象是否属于其权限范围。架构层面区分“高危技能”和“普通技能”。对于高危技能可以采用“人机协同”模式即LLM提出执行请求由用户二次确认后再执行。输入校验对所有输入参数进行严格的类型、范围、合法性校验防止SQL注入、命令注入等攻击。5.3 过度依赖LLM的“理解力”把复杂逻辑扔给提示词问题试图用一个超级复杂的提示词让LLM去完成本应由代码处理的精确逻辑。比如让LLM解析一段非标准格式的日志并提取出特定字段。后果输出不稳定格式容易出错难以调试且Token消耗大。正确思路Skills应该封装确定性的、精确的逻辑。把解析、计算、判断等硬核工作放在Skill的代码实现里。LLM应该只负责它擅长的部分理解用户自然语言意图并将其“翻译”成对确定性技能的调用。该LLM做的理解“帮我找出上个月销售额超过10万的客户”。该Skill做的接收结构化的查询条件{“time_range”: “last_month”, “min_sales”: 100000}执行优化过的数据库查询返回结构化的客户列表。5.4 技能“僵尸化”缺乏监控与迭代问题技能上线后就没人管了。不知道它被调用的频率、成功率、耗时也不知道返回的结果是否有效。后果技能可能早已失效如依赖的API已变更或效果很差但无人知晓成为系统中的“僵尸服务”影响智能体整体表现。必备的监控指标调用量每个技能每天的调用次数。成功率调用成功返回有效结果的比例。平均耗时从调用到返回的延迟。输入输出采样定期记录一些典型的输入和输出用于评估技能是否仍符合预期。错误日志详细记录每一次失败的原因参数错误、网络超时、权限不足等。基于这些数据你才能知道哪些技能是高频核心资产需要重点维护哪些技能是冗余可以下线哪些技能需要优化性能或准确率。6. 从Skills到智能体构建真正“会干活”的AI应用封装好Skills只是拥有了工具箱。如何让智能体Agent熟练地使用这些工具才是最终目标。这涉及到智能体的“大脑”配置。6.1 为智能体选择正确的“大脑”LLM不是所有LLM都擅长工具调用。你需要关注模型的几个关键能力工具调用Function Calling的可靠性这是基础。模型必须能严格按照你提供的工具描述来生成格式正确的调用请求。GPT-4系列、Claude 3系列、DeepSeek最新版本在这方面表现都很出色。长上下文规划能力对于需要串联多个工具的复杂任务模型需要有足够的上下文窗口来记住整个计划、已执行步骤的结果和剩余任务。拒绝不当请求的“判断力”一个好的智能体应该知道什么时候不该使用工具。比如用户询问敏感信息或提出不合理请求时它应该礼貌拒绝而不是强行调用一个可能出错的技能。6.2 设计高效的智能体提示词Prompt智能体的提示词是其“操作系统”。除了常见的系统指令“你是一个有帮助的助手…”针对工具调用必须明确工具列表与规范清晰列出所有可用工具及其详细描述、参数。这是最重要的部分。输出格式指令严格要求模型以指定格式如JSON返回工具调用请求和最终答案。推理链鼓励鼓励模型“一步一步思考”先解释它计划做什么、为什么选择这个工具然后再执行。这不仅能提高准确性也方便调试。错误处理指引告诉模型当工具调用失败时该怎么办例如“如果查询失败请向用户说明无法获取信息并询问是否想换一种方式提问”。6.3 实现闭环让智能体从结果中学习一个初级的智能体只会机械地调用工具。一个高级的智能体应该能根据工具返回的结果动态调整后续策略。结果验证技能返回了结果智能体应该能初步判断这个结果是否合理、是否回答了用户问题。如果结果为空或质量很差它应该尝试换一个关键词重新查询或者向用户澄清问题。多技能协同策略当第一个技能返回的结果不完整时智能体应能自动触发第二个、第三个技能来补充信息。例如先通过search_company_directory找到员工邮箱再通过check_calendar_availability查看其日程。状态管理对于多轮对话中的复杂任务智能体需要记住之前已经调用过哪些工具、得到了什么结果避免重复操作或陷入循环。6.4 评估与迭代智能体不是一次成型的上线不是终点。你需要一套评估体系来衡量智能体是否真的“会干活”。单技能准确率针对每个技能测试智能体在典型场景下是否能正确触发并传入正确参数。端到端任务成功率设计一系列真实的用户任务如“预订会议室并通知团队成员”看智能体能否独立完成。人工审核与反馈在初期对智能体的执行过程和结果进行人工抽样审核标注错误。这些数据可以用于优化提示词甚至微调模型如果使用可微调的模型。A/B测试尝试不同的提示词模板、不同的工具描述方式甚至不同的大模型通过实际用户交互数据选择效果最好的组合。说到底让大模型“会干活”是一个系统工程。它需要我们将模糊的人类经验拆解、提炼、封装成一个个边界清晰、定义明确的Skills需要我们对智能体进行精心“调教”让它学会在正确的时间、以正确的方式使用这些工具更需要我们建立监控和迭代机制让这个系统越用越聪明。这条路没有捷径但每一步都踩在实处每一次封装都是对你业务逻辑的一次深度梳理其价值远不止于一个AI应用本身。当你看到智能体流畅地串联起多个技能独立完成一个曾经需要多人协作的任务时你就会明白拒绝重复造轮子拥抱Skills化的智能体开发是通往下一代人机协同的必经之路。