1. 从“工具人”到“多面手”为什么你的AI Agent需要扩展技能最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家花了不少功夫搭建了自己的AI Agent让它能写写代码、总结文档但真到了要处理一些稍微复杂点的任务比如自动分析Git仓库的提交历史、批量处理一批Excel文件或者根据一个模糊的需求去网上搜点资料回来整理Agent就有点“卡壳”了。它就像一个只会用螺丝刀的工人面对需要扳手、电钻甚至电焊的活儿只能干瞪眼。这其实就是“技能”Skills缺失的问题。一个基础的、基于大语言模型的Agent它的核心能力是理解和生成文本。你可以把它理解成一个极其聪明、知识渊博但“手无寸铁”的参谋。它知道扳手长什么样、电钻怎么用甚至能给你画出一张完美的施工图纸但它自己没有手去操作这些工具。Skills就是给这位“参谋”装上的一双双“手”和一件件“工具”让它从“纸上谈兵”的军师变成能“下场干活”的工程师。所以这篇内容不是要讲某个具体框架的API怎么调用那是手册干的事。我想聊的是在一个AI Agent项目中我们到底该如何系统地思考、设计和实现它的“技能扩展”。这背后涉及工具选型的逻辑、技能设计的模式、安全边界的把控以及如何让这些技能协同工作真正产生“112”的提效效果。无论你用的是LangChain、LlamaIndex还是自己从零搭建的Agent系统这套思路都是相通的。2. 技能的本质连接意图与行动的“适配器”在深入实操之前我们得先掰扯清楚“技能”到底是个啥。很多人容易把它和“函数调用”Function Calling或者“插件”Plugin混淆。它们有关联但视角不同。函数调用是大模型提供的一种基础能力。你告诉模型“这里有一堆工具函数的说明书schema用户现在说了句话你判断一下要不要用工具、用哪个、参数填什么。” 模型负责理解意图并生成结构化的调用请求但它不负责执行。这就像参谋看懂了任务写好了需要调用“工兵连”某个API和“炸药量”参数的指令。插件通常是一个更上层的概念它可能包含了一组相关的技能、特定的UI界面或者配置。比如一个“GitHub插件”里面可能集成了“查询仓库信息”、“创建Issue”、“审查代码”等多个技能。而技能Skill在我的理解里是连接“模型生成的调用指令”和“真实世界动作”之间的那个适配器或驱动程序。它的核心职责是声明告诉Agent“我能干什么”。这通常通过一个清晰的描述自然语言和一份结构化的“工具说明书”schema包含函数名、参数、描述来完成。执行当Agent决定调用时接收结构化的参数去执行一段具体的代码逻辑。这段逻辑可能很简单比如调用一个本地函数也可能很复杂比如串联多个API、处理中间状态。反馈将执行的结果成功或失败以及获取到的信息整理成Agent能理解的文本格式返回给Agent进行后续的思考。举个例子一个“获取天气”的技能。声明告诉Agent这里有一个叫get_current_weather的工具它需要location城市名这个参数功能是“获取指定城市的当前天气情况”。执行当Agent判断用户问“北京天气怎么样”时它会生成调用get_current_weather(location北京)的请求。技能接收到这个请求后其内部的代码会去调用像OpenWeatherMap这样的第三方天气API获取原始数据一堆JSON。反馈技能内部的代码不能直接把JSON扔回给Agent。它需要做一次“翻译”或“摘要”比如转换成“北京当前天气晴朗气温22摄氏度西北风3级湿度45%。” 这个文本格式的结果才是Agent能继续用于对话或推理的有效信息。所以设计一个技能远不止写一个函数那么简单。你需要考虑它的描述是否足够清晰能让Agent准确理解使用场景它的参数设计是否合理能否覆盖主要用例它的执行逻辑是否健壮能处理各种异常如网络超时、API限流它的反馈格式是否友好便于Agent消化并用于后续步骤这些都是技能设计中的关键点。3. 技能工具箱的选型与搭建框架还是自研明确了技能是什么接下来就要打造工具箱了。这里通常有两条路使用成熟的Agent框架开箱即用或者自己从零开始搭建核心机制高度定制。你的选择取决于项目阶段、团队资源和复杂度要求。3.1 主流框架方案站在巨人的肩膀上对于绝大多数应用场景尤其是快速原型验证和希望聚焦业务逻辑的团队我强烈建议直接从成熟的框架开始。它们提供了技能管理、对话编排、记忆、规划等一整套基础设施。1. LangChain / LangGraph这是目前生态最丰富、社区最活跃的选择之一。它的Tool抽象就是技能的实现。优点生态庞大有海量的社区贡献工具langchain-community从搜索引擎、数据库到各种SaaS API几乎应有尽有。与各种大模型提供商集成无缝。LangGraph更进一步提供了基于状态图的、更复杂的多Agent工作流编排能力非常适合设计需要多个技能按特定顺序和条件执行的复杂任务。缺点抽象层次有时较高在追求极致性能或需要非常精细控制时可能会感到有些“笨重”。版本更新较快需要留意兼容性。适用场景快速构建具备丰富能力的AI应用尤其是涉及复杂工作流和需要集成多种外部工具的场景。2. LlamaIndex虽然最初以“数据接入”闻名但LlamaIndex的Agent模块同样提供了强大的技能Tool集成能力。优点如果你项目的核心是让Agent深入理解和查询你自己的私有数据文档、数据库、知识库那么LlamaIndex几乎是首选。它在数据索引、检索以及基于此的智能体构建方面非常顺手技能可以很自然地与检索器结合。缺点在纯工具集成和通用工作流编排的生态广度上略逊于LangChain。适用场景以数据为中心的Agent例如企业内部的智能问答助手、数据分析助手需要深度结合RAG检索增强生成功能。3. AutoGen (by Microsoft)这是一个专注于多智能体对话协作的框架。优点为多Agent设计而生可以轻松定义不同角色程序员、测试员、产品经理的Agent并让它们通过对话协作完成任务。技能可以分配给特定的Agent。非常适合模拟评审、辩论、复杂问题分解协作等场景。缺点对于简单的单Agent工具调用场景可能显得有点杀鸡用牛刀。调试多Agent交互有时更复杂。适用场景需要多个AI智能体分工协作来解决复杂任务的研究或应用项目。框架选择的心得没有绝对的好坏只有合不合适。我个人的经验是早期原型阶段用LangChain最快因为它能让你在几小时内连接上几十种服务。当你的业务严重依赖特定数据源时深入看看LlamaIndex。如果你设想的工作流本质上是多个专家Agent的开会讨论那么AutoGen值得一试。很多时候它们也可以混合使用。3.2 自研核心机制追求极致的控制力如果你的需求非常特殊或者你对性能、依赖有极致要求自己实现技能调度的核心逻辑也是一个选择。这并不像听起来那么难因为现代大模型的Function Calling能力已经标准化了。核心流程可以简化为一个循环接收用户输入结合对话历史形成给模型的提示Prompt。准备技能清单将当前可用的所有技能按照模型要求的格式如OpenAI的JSON Schema进行描述并放入提示中。调用大模型请求模型根据输入和技能描述决定是直接回复还是调用某个技能。如果调用模型会返回一个结构化的调用请求如{“name”: “get_weather”, “arguments”: {“location”: “北京”}}。路由与执行你的程序解析这个请求找到对应的技能函数传入参数并执行。处理与反馈将技能执行的结果文本或结构化数据重新组织成自然语言描述附加到对话历史中然后回到步骤1让模型基于这个新信息继续思考或回复用户。自研的优势是轻量、可控你可以完全定制技能的管理方式、执行上下文和错误处理流程。缺点是所有轮子都需要自己造包括技能描述的管理、调用结果的规范化、复杂流程的编排等。我建议只有在对框架的某些限制无法忍受时才考虑这条路。4. 技能设计实战从简单工具到复杂工作流理论说再多不如动手写一个。我们以最常见的“让Agent能上网搜索”为例看看如何一步步设计并优化一个技能。假设我们使用LangChain框架。4.1 基础版封装一个搜索API最直接的想法就是调用SerpAPI、Google Search API或者Bing Search API。from langchain.tools import Tool from langchain.utilities import SerpAPIWrapper # 1. 利用LangChain内置的封装最简单 search_tool SerpAPIWrapper(serpapi_api_keyyour_key) # 这会自动创建一个符合LangChain Tool接口的对象 # 或者2. 完全自定义 def custom_search(query: str) - str: 执行网络搜索并返回摘要结果。 # 这里模拟调用某个搜索API # 实际代码中你会使用requests库调用SerpAPI等 import requests params { q: query, api_key: your_key, # ... 其他参数 } response requests.get(https://serpapi.com/search, paramsparams) results response.json().get(organic_results, [])[:3] # 取前三条 summary \n.join([f{r[title]}: {r[snippet]} for r in results]) return summary if summary else 未找到相关信息。 # 将函数包装成Tool search_skill Tool( nameweb_search, funccustom_search, description当需要获取最新的、未知的或实时信息时使用此工具。输入一个明确的搜索查询词。 )这个基础版技能已经能用了。Agent在遇到不知道的信息时可能会调用它。但问题很快会出现搜索质量不稳定返回的摘要可能冗长、无关甚至包含广告。消耗Token大段搜索结果直接塞回上下文很快会耗尽模型的上下文窗口。缺乏思考Agent可能过于频繁地搜索甚至用搜索来代替本应基于已有知识进行的推理。4.2 进阶版增加结果处理与智能过滤一个更好的技能应该能替Agent做一些预处理减轻它的负担。from langchain.tools import BaseTool from pydantic import BaseModel, Field from typing import Type, Optional import requests import json class SearchInput(BaseModel): query: str Field(description明确、具体的搜索查询语句) max_results: Optional[int] Field(default3, description需要返回的最大结果数量默认为3) class AdvancedSearchTool(BaseTool): name: str advanced_web_search description: str 在以下情况使用此工具 1. 问题涉及最新的、实时发生的事件如今天某地的新闻、股价。 2. 问题需要非常具体的事实性数据且不在你的知识库内如某公司2023年的具体营收。 3. 用户明确要求“搜索一下”或“查查网上的资料”。 输入必须是一个清晰的搜索查询语句。 args_schema: Type[BaseModel] SearchInput def _run(self, query: str, max_results: int 3) - str: 执行搜索并对结果进行清洗、排序和关键信息提取。 # 1. 调用搜索API示例 api_results self._call_search_api(query, max_results*2) # 多取一些方便过滤 # 2. 清洗和排序结果简单的启发式规则 filtered_results [] for r in api_results: # 过滤掉明显是广告或低质量来源的结果根据域名等 if not self._is_low_quality_source(r.get(link, )): # 可以在这里加入基于相关性的简单评分 filtered_results.append(r) filtered_results filtered_results[:max_results] # 3. 结构化关键信息而非返回整个摘要 formatted_output [] for i, r in enumerate(filtered_results, 1): # 提取标题、链接、核心片段 title r.get(title, 无标题) link r.get(link, #) snippet r.get(snippet, ) # 尝试从摘要中提取关键事实例如日期、数字、特定名词 key_facts self._extract_key_facts(snippet) formatted_output.append( f[结果{i}] {title}\n f链接: {link}\n f摘要: {snippet[:150]}...\n # 限制摘要长度 f关键信息: {, .join(key_facts) if key_facts else 无}\n ) final_output \n---\n.join(formatted_output) return final_output if final_output else 未找到高质量的相关信息。 def _call_search_api(self, query: str, num: int): # 模拟API调用返回假数据 return [ {title: AI Agent开发指南 - 知乎专栏, link: https://zhuanlan.zhihu.com/p/..., snippet: 本文详细介绍了如何为AI Agent设计和扩展Skills...}, {title: LangChain Tools官方文档, link: https://python.langchain.com/docs/..., snippet: Tools are the actions an agent can take...}, # ... 更多结果 ] def _is_low_quality_source(self, url: str) - bool: low_quality_domains [spam-site.com, advertisement.com] return any(domain in url for domain in low_quality_domains) def _extract_key_facts(self, text: str): # 简单的关键词/模式匹配提取实际可用更复杂的NLP方法 import re facts [] # 找日期 date_pattern r\d{4}年\d{1,2}月\d{1,2}日|\d{4}-\d{2}-\d{2} dates re.findall(date_pattern, text) facts.extend(dates[:1]) # 只取第一个日期 # 找百分比或货币 if % in text or 美元 in text or 亿元 in text: facts.append(包含数值数据) return facts # 使用这个进阶工具 advanced_search_skill AdvancedSearchTool()这个进阶版做了几件重要的事强化了描述在description里明确了使用场景和条件引导Agent更明智地做出调用决策。规范了输入通过args_schema定义了结构化的输入query参数要求更明确还增加了可选的max_results。优化了输出内部对搜索结果进行了清洗、过滤和结构化提取关键事实并以更紧凑、信息密度更高的格式返回大大节省了上下文Token。内置了简单逻辑加入了基于来源的质量过滤和关键信息提取虽然简单但比直接返回原始API结果好得多。4.3 组合技能构建复杂工作流单个技能再强大也有局限。真正的提效来自于技能的组合。例如一个“市场调研”任务可能涉及“搜索最新行业报告”、“从报告中提取关键数据”、“将数据整理成表格”、“生成分析摘要”等多个步骤。我们可以通过两种方式实现组合方式一在单个技能内部串联逻辑你可以创建一个名为market_research的“宏技能”在其_run方法内部按顺序调用多个子函数或子API。这种方式简单直接但技能会变得臃肿且逻辑固定不易复用。方式二利用Agent的规划能力动态组合多个基础技能这是更优雅和强大的方式。你只需要提供一系列基础技能如web_search,extract_data_from_text,create_markdown_table,write_summary然后给Agent一个高层次的目标“请对‘AI编程工具’这个领域做一份市场调研输出一份包含主要玩家、特点和趋势的摘要报告。”一个具备规划能力的Agent如使用ReAct模式或通过LangGraph编排会自行决定调用技能的步骤调用web_search(“AI编程工具 2024 市场报告”)。从搜索结果中选择最相关的一两份报告链接。调用某个read_webpage_content技能如果存在获取全文或者直接基于摘要。调用extract_data_from_text技能从文本中提取公司名、产品名、特点等结构化信息。调用create_markdown_table技能将信息整理成表格。最后调用write_summary技能基于表格生成最终报告。在这个过程中你作为开发者只需要设计和提供好每个原子技能。Agent的“大脑”大模型负责规划和组合。这极大地增强了系统的灵活性和解决复杂问题的能力。5. 技能管理、安全与性能优化当技能越来越多你就需要一个“技能管理器”了。管理不仅仅是存储更重要的是控制访问、保障安全和监控性能。5.1 技能的注册、发现与动态加载一个基本的技能注册表可以是一个Python字典但更好的做法是使用配置文件或数据库。class SkillRegistry: def __init__(self): self._skills {} def register(self, skill: BaseTool, category: str general): 注册一个技能并为其分类。 if skill.name in self._skills: raise ValueError(fSkill {skill.name} already registered.) self._skills[skill.name] {tool: skill, category: category} def get_skill(self, name: str) - Optional[BaseTool]: return self._skills.get(name, {}).get(tool) def get_skills_by_category(self, category: str) - List[BaseTool]: return [v[tool] for k, v in self._skills.items() if v[category] category] def list_all_skills(self) - List[str]: return list(self._skills.keys()) # 使用 registry SkillRegistry() registry.register(advanced_search_skill, categoryinformation) registry.register(Tool(namecalculator, funclambda x: eval(x), description计算数学表达式), categoryutility) # Agent初始化时可以从registry中加载指定类别的技能 agent_skills registry.get_skills_by_category(information)更进一步可以实现技能的动态加载。例如根据用户会话的上下文或权限加载不同的技能集。或者设计一个“技能市场”允许从安全的远程仓库按需加载技能插件。5.2 安全是生命线技能调用的风险管控赋予Agent技能的同时也打开了风险之门。必须建立严格的安全边界。权限控制最重要不是所有技能都对所有用户或所有会话开放。一个内部财务数据分析技能绝不能暴露给外部用户。实现上可以在SkillRegistry的get_skills_for_session方法中根据用户身份、角色或会话标签进行过滤。输入验证与净化任何来自用户输入或模型生成的参数在传入技能执行前都必须进行严格的验证和净化。特别是对于执行系统命令command_line、操作数据库sql_executor、读写文件file_editor这类高危技能。白名单机制对于命令执行只允许运行预定义的安全命令列表。参数转义防止SQL注入、命令注入。路径限制文件操作技能必须将访问范围限制在特定的沙箱目录内。资源访问限制网络访问控制技能可以访问的域名或IP白名单。API调用限额为调用第三方API的技能设置速率限制和每日限额防止意外或恶意消耗。计算资源对执行长时间计算或大数据处理的技能设置超时限制。操作确认人工在环对于极高风险的操作如“删除生产数据库”、“向所有用户发送邮件”技能的设计应该是在执行前先生成一个待确认的操作计划摘要并强制要求人工审核确认后才能继续执行。这可以通过在Agent工作流中插入一个“人工审批节点”来实现。5.3 性能优化与监控技能调用通常是Agent工作流中最耗时的环节尤其是网络I/O。优化至关重要。缓存对于结果相对稳定、频繁被查询的技能如“查询某产品的规格参数”引入缓存可以极大提升响应速度并减少外部API调用。可以使用内存缓存如functools.lru_cache或分布式缓存如Redis。注意设置合理的过期时间。异步执行如果一个任务需要并行调用多个独立的技能例如同时查询天气、新闻和股票一定要使用异步模式。LangChain等框架支持异步的Tool。import asyncio async def async_search(query): # 模拟异步API调用 await asyncio.sleep(0.5) return f搜索结果: {query}超时与重试为每个技能配置合理的超时时间并实现优雅的重试逻辑最好有退避策略如指数退避。避免因为一个外部服务的临时故障导致整个Agent卡死。监控与日志记录每个技能的调用次数、成功率、平均耗时、失败原因。这不仅能帮你发现性能瓶颈哪个技能最慢还能发现设计问题哪个技能最常被错误调用或调用失败。这些数据是迭代优化技能集和Agent提示词的重要依据。6. 从技能到智能体设计让Agent“善用”技能的提示词拥有了强大的技能工具箱并不等于Agent就能用好它们。Agent的“大脑”——大语言模型——需要被正确地引导。这就涉及到提示词工程中关于工具调用的部分。糟糕的提示词只是简单地把工具列表扔给模型。“Here are some tools you can use: [tool descriptions...]”结果Agent可能会滥用工具在不该调用的时候调用或者生成错误的参数。优秀的提示词需要教会Agent何时用、为何用、怎么用。在你的系统提示词System Prompt中应该包含以下关键部分角色与能力定义明确告诉模型它是一个可以调用外部工具的助手。“你是一个AI助手除了对话之外你还可以通过调用一系列工具来获取信息或执行操作以更好地帮助用户。”工具使用原则优先使用内部知识“对于常识性、非实时性的问题优先使用你自己的知识回答不要随意调用工具。”明确调用条件“仅在以下情况调用工具a) 需要实时信息如天气、股价b) 需要执行用户请求的具体操作如计算、查询数据c) 用户明确要求你查询或使用某项工具。”参数必须明确“调用工具时必须确保提供的参数是完整、清晰且符合工具要求的。如果你不确定参数可以先询问用户。”结果处理指导“工具返回的结果是供你参考的信息。你需要理解、整合这些信息并用友好、自然的方式回复用户不要直接复制粘贴工具的原始输出。”“如果工具调用失败或返回错误不要慌张。向用户解释你遇到了问题并尝试换一种方式帮助用户或者建议用户提供更详细的信息。”格式化输出要求如果框架支持明确要求模型以特定的JSON格式如OpenAI的function_call来响应这能提高工具调用的解析成功率。通过这样细致的提示词设计你是在训练Agent的“工作习惯”让它从一个乱用工具的新手变成一个懂得在合适时机、用合适方法、高效使用工具的专业助手。这部分的调优往往比多开发几个技能带来的效果提升更显著。7. 迭代与评估如何判断你的技能系统真的在“提效”开发完成只是开始。你需要一套方法来评估你的技能扩展是否真的提升了Agent的效能。定义评估指标任务完成率给Agent一系列标准测试任务如“查一下北京今天和明天的天气对比”、“计算一下我的房贷月供”看它能否通过调用正确的技能组合成功完成。工具调用准确率在需要调用工具的任务中Agent是否调用了正确的工具调用时提供的参数是否准确人工评分让真实用户或评估员对Agent在扩展技能前后的回答质量进行评分例如1-5分评估其有用性和准确性的提升。效率指标平均完成任务所需的对话轮次是否减少用户是否更少地需要介入纠正或提供额外信息建立测试集 创建一个涵盖不同技能、不同难度的测试用例库。包括单技能测试测试每个技能是否能被正确触发和执行。多技能串联测试测试Agent解决复杂任务时的规划和组合能力。边界与异常测试测试在参数错误、工具失效、模糊指令等情况下的Agent行为。持续监控与迭代分析日志定期查看技能调用日志找出“僵尸技能”几乎不被调用和“瓶颈技能”调用频繁但失败率高。收集反馈建立用户反馈渠道特别是对于工具调用产生的结果用户是否满意A/B测试如果你改进了某个技能的描述或提示词可以设计A/B测试看新版本是否能提高该技能的调用准确率或任务完成率。扩展技能不是一个一劳永逸的项目而是一个需要持续观察、分析和优化的运营过程。你的技能库应该像一个活的生态系统不断淘汰无效的优化低效的并引入新的能力来应对不断涌现的新需求。8. 避坑指南扩展技能路上常见的“坑”结合我自己和身边朋友趟过的坑这里总结几个最容易出问题的地方坑一技能描述过于模糊或过于宽泛现象Agent频繁误调用技能或者在该调用的时候不调用。例子给一个数据处理技能的描述是“处理数据”。Agent完全不知道什么时候该用它。解法描述要具体明确使用场景、输入格式和输出内容。例如“当用户提供结构化的CSV数据或JSON数据并请求进行基本统计分析如计算平均值、总和、最大值、最小值时使用此工具。输入应为明确的数据字符串或文件路径。”坑二技能输出“污染”对话上下文现象技能返回冗长的、结构化的原始数据如大段JSON、HTML这些内容挤占了宝贵的上下文窗口导致后续对话质量下降或Agent混乱。解法技能必须做“摘要”或“格式化”。在_run方法里将原始结果转换成简洁、关键的自然语言描述。如果信息量大可以尝试提取关键字段用“键值对”或简短列表的形式呈现。坑三忽视错误处理和超时现象某个外部API挂掉导致整个Agent线程卡死用户请求超时。解法每个技能内部必须有完善的try...except块捕获所有可能的异常网络错误、解析错误、API错误等并返回一个统一的、对Agent友好的错误信息格式例如“调用XX服务时失败网络连接超时。请稍后再试或检查网络。” 同时在技能注册或调用层面设置全局超时。坑四技能之间的冲突或重复现象有两个功能相似的技能比如search_web和search_internal_wikiAgent有时会混淆。解法在技能描述中清晰界定边界。例如search_web的描述强调“公开的、实时的网络信息”search_internal_wiki的描述强调“公司内部的、非公开的文档和知识”。也可以考虑设计一个更通用的“搜索”技能在内部根据查询词自动路由到不同的数据源。坑五把Agent当成“万能胶水”过度依赖技能现象所有逻辑都试图拆成技能Agent变成了一个单纯的“调度器”失去了其核心的推理和语言理解优势。反思技能是扩展Agent的能力边界而不是替代它的思考能力。那些需要复杂逻辑判断、创造性生成、深度上下文理解的任务应该留给大模型本身。技能应该用来处理模型不擅长或无法做到的“动作”获取实时数据、执行计算、操作外部系统。把握好这个平衡才能造出真正智能的助手而不是一个笨拙的自动化脚本。 AI Agent技能扩展：从工具连接到复杂工作流的设计与实践
1. 从“工具人”到“多面手”为什么你的AI Agent需要扩展技能最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家花了不少功夫搭建了自己的AI Agent让它能写写代码、总结文档但真到了要处理一些稍微复杂点的任务比如自动分析Git仓库的提交历史、批量处理一批Excel文件或者根据一个模糊的需求去网上搜点资料回来整理Agent就有点“卡壳”了。它就像一个只会用螺丝刀的工人面对需要扳手、电钻甚至电焊的活儿只能干瞪眼。这其实就是“技能”Skills缺失的问题。一个基础的、基于大语言模型的Agent它的核心能力是理解和生成文本。你可以把它理解成一个极其聪明、知识渊博但“手无寸铁”的参谋。它知道扳手长什么样、电钻怎么用甚至能给你画出一张完美的施工图纸但它自己没有手去操作这些工具。Skills就是给这位“参谋”装上的一双双“手”和一件件“工具”让它从“纸上谈兵”的军师变成能“下场干活”的工程师。所以这篇内容不是要讲某个具体框架的API怎么调用那是手册干的事。我想聊的是在一个AI Agent项目中我们到底该如何系统地思考、设计和实现它的“技能扩展”。这背后涉及工具选型的逻辑、技能设计的模式、安全边界的把控以及如何让这些技能协同工作真正产生“112”的提效效果。无论你用的是LangChain、LlamaIndex还是自己从零搭建的Agent系统这套思路都是相通的。2. 技能的本质连接意图与行动的“适配器”在深入实操之前我们得先掰扯清楚“技能”到底是个啥。很多人容易把它和“函数调用”Function Calling或者“插件”Plugin混淆。它们有关联但视角不同。函数调用是大模型提供的一种基础能力。你告诉模型“这里有一堆工具函数的说明书schema用户现在说了句话你判断一下要不要用工具、用哪个、参数填什么。” 模型负责理解意图并生成结构化的调用请求但它不负责执行。这就像参谋看懂了任务写好了需要调用“工兵连”某个API和“炸药量”参数的指令。插件通常是一个更上层的概念它可能包含了一组相关的技能、特定的UI界面或者配置。比如一个“GitHub插件”里面可能集成了“查询仓库信息”、“创建Issue”、“审查代码”等多个技能。而技能Skill在我的理解里是连接“模型生成的调用指令”和“真实世界动作”之间的那个适配器或驱动程序。它的核心职责是声明告诉Agent“我能干什么”。这通常通过一个清晰的描述自然语言和一份结构化的“工具说明书”schema包含函数名、参数、描述来完成。执行当Agent决定调用时接收结构化的参数去执行一段具体的代码逻辑。这段逻辑可能很简单比如调用一个本地函数也可能很复杂比如串联多个API、处理中间状态。反馈将执行的结果成功或失败以及获取到的信息整理成Agent能理解的文本格式返回给Agent进行后续的思考。举个例子一个“获取天气”的技能。声明告诉Agent这里有一个叫get_current_weather的工具它需要location城市名这个参数功能是“获取指定城市的当前天气情况”。执行当Agent判断用户问“北京天气怎么样”时它会生成调用get_current_weather(location北京)的请求。技能接收到这个请求后其内部的代码会去调用像OpenWeatherMap这样的第三方天气API获取原始数据一堆JSON。反馈技能内部的代码不能直接把JSON扔回给Agent。它需要做一次“翻译”或“摘要”比如转换成“北京当前天气晴朗气温22摄氏度西北风3级湿度45%。” 这个文本格式的结果才是Agent能继续用于对话或推理的有效信息。所以设计一个技能远不止写一个函数那么简单。你需要考虑它的描述是否足够清晰能让Agent准确理解使用场景它的参数设计是否合理能否覆盖主要用例它的执行逻辑是否健壮能处理各种异常如网络超时、API限流它的反馈格式是否友好便于Agent消化并用于后续步骤这些都是技能设计中的关键点。3. 技能工具箱的选型与搭建框架还是自研明确了技能是什么接下来就要打造工具箱了。这里通常有两条路使用成熟的Agent框架开箱即用或者自己从零开始搭建核心机制高度定制。你的选择取决于项目阶段、团队资源和复杂度要求。3.1 主流框架方案站在巨人的肩膀上对于绝大多数应用场景尤其是快速原型验证和希望聚焦业务逻辑的团队我强烈建议直接从成熟的框架开始。它们提供了技能管理、对话编排、记忆、规划等一整套基础设施。1. LangChain / LangGraph这是目前生态最丰富、社区最活跃的选择之一。它的Tool抽象就是技能的实现。优点生态庞大有海量的社区贡献工具langchain-community从搜索引擎、数据库到各种SaaS API几乎应有尽有。与各种大模型提供商集成无缝。LangGraph更进一步提供了基于状态图的、更复杂的多Agent工作流编排能力非常适合设计需要多个技能按特定顺序和条件执行的复杂任务。缺点抽象层次有时较高在追求极致性能或需要非常精细控制时可能会感到有些“笨重”。版本更新较快需要留意兼容性。适用场景快速构建具备丰富能力的AI应用尤其是涉及复杂工作流和需要集成多种外部工具的场景。2. LlamaIndex虽然最初以“数据接入”闻名但LlamaIndex的Agent模块同样提供了强大的技能Tool集成能力。优点如果你项目的核心是让Agent深入理解和查询你自己的私有数据文档、数据库、知识库那么LlamaIndex几乎是首选。它在数据索引、检索以及基于此的智能体构建方面非常顺手技能可以很自然地与检索器结合。缺点在纯工具集成和通用工作流编排的生态广度上略逊于LangChain。适用场景以数据为中心的Agent例如企业内部的智能问答助手、数据分析助手需要深度结合RAG检索增强生成功能。3. AutoGen (by Microsoft)这是一个专注于多智能体对话协作的框架。优点为多Agent设计而生可以轻松定义不同角色程序员、测试员、产品经理的Agent并让它们通过对话协作完成任务。技能可以分配给特定的Agent。非常适合模拟评审、辩论、复杂问题分解协作等场景。缺点对于简单的单Agent工具调用场景可能显得有点杀鸡用牛刀。调试多Agent交互有时更复杂。适用场景需要多个AI智能体分工协作来解决复杂任务的研究或应用项目。框架选择的心得没有绝对的好坏只有合不合适。我个人的经验是早期原型阶段用LangChain最快因为它能让你在几小时内连接上几十种服务。当你的业务严重依赖特定数据源时深入看看LlamaIndex。如果你设想的工作流本质上是多个专家Agent的开会讨论那么AutoGen值得一试。很多时候它们也可以混合使用。3.2 自研核心机制追求极致的控制力如果你的需求非常特殊或者你对性能、依赖有极致要求自己实现技能调度的核心逻辑也是一个选择。这并不像听起来那么难因为现代大模型的Function Calling能力已经标准化了。核心流程可以简化为一个循环接收用户输入结合对话历史形成给模型的提示Prompt。准备技能清单将当前可用的所有技能按照模型要求的格式如OpenAI的JSON Schema进行描述并放入提示中。调用大模型请求模型根据输入和技能描述决定是直接回复还是调用某个技能。如果调用模型会返回一个结构化的调用请求如{“name”: “get_weather”, “arguments”: {“location”: “北京”}}。路由与执行你的程序解析这个请求找到对应的技能函数传入参数并执行。处理与反馈将技能执行的结果文本或结构化数据重新组织成自然语言描述附加到对话历史中然后回到步骤1让模型基于这个新信息继续思考或回复用户。自研的优势是轻量、可控你可以完全定制技能的管理方式、执行上下文和错误处理流程。缺点是所有轮子都需要自己造包括技能描述的管理、调用结果的规范化、复杂流程的编排等。我建议只有在对框架的某些限制无法忍受时才考虑这条路。4. 技能设计实战从简单工具到复杂工作流理论说再多不如动手写一个。我们以最常见的“让Agent能上网搜索”为例看看如何一步步设计并优化一个技能。假设我们使用LangChain框架。4.1 基础版封装一个搜索API最直接的想法就是调用SerpAPI、Google Search API或者Bing Search API。from langchain.tools import Tool from langchain.utilities import SerpAPIWrapper # 1. 利用LangChain内置的封装最简单 search_tool SerpAPIWrapper(serpapi_api_keyyour_key) # 这会自动创建一个符合LangChain Tool接口的对象 # 或者2. 完全自定义 def custom_search(query: str) - str: 执行网络搜索并返回摘要结果。 # 这里模拟调用某个搜索API # 实际代码中你会使用requests库调用SerpAPI等 import requests params { q: query, api_key: your_key, # ... 其他参数 } response requests.get(https://serpapi.com/search, paramsparams) results response.json().get(organic_results, [])[:3] # 取前三条 summary \n.join([f{r[title]}: {r[snippet]} for r in results]) return summary if summary else 未找到相关信息。 # 将函数包装成Tool search_skill Tool( nameweb_search, funccustom_search, description当需要获取最新的、未知的或实时信息时使用此工具。输入一个明确的搜索查询词。 )这个基础版技能已经能用了。Agent在遇到不知道的信息时可能会调用它。但问题很快会出现搜索质量不稳定返回的摘要可能冗长、无关甚至包含广告。消耗Token大段搜索结果直接塞回上下文很快会耗尽模型的上下文窗口。缺乏思考Agent可能过于频繁地搜索甚至用搜索来代替本应基于已有知识进行的推理。4.2 进阶版增加结果处理与智能过滤一个更好的技能应该能替Agent做一些预处理减轻它的负担。from langchain.tools import BaseTool from pydantic import BaseModel, Field from typing import Type, Optional import requests import json class SearchInput(BaseModel): query: str Field(description明确、具体的搜索查询语句) max_results: Optional[int] Field(default3, description需要返回的最大结果数量默认为3) class AdvancedSearchTool(BaseTool): name: str advanced_web_search description: str 在以下情况使用此工具 1. 问题涉及最新的、实时发生的事件如今天某地的新闻、股价。 2. 问题需要非常具体的事实性数据且不在你的知识库内如某公司2023年的具体营收。 3. 用户明确要求“搜索一下”或“查查网上的资料”。 输入必须是一个清晰的搜索查询语句。 args_schema: Type[BaseModel] SearchInput def _run(self, query: str, max_results: int 3) - str: 执行搜索并对结果进行清洗、排序和关键信息提取。 # 1. 调用搜索API示例 api_results self._call_search_api(query, max_results*2) # 多取一些方便过滤 # 2. 清洗和排序结果简单的启发式规则 filtered_results [] for r in api_results: # 过滤掉明显是广告或低质量来源的结果根据域名等 if not self._is_low_quality_source(r.get(link, )): # 可以在这里加入基于相关性的简单评分 filtered_results.append(r) filtered_results filtered_results[:max_results] # 3. 结构化关键信息而非返回整个摘要 formatted_output [] for i, r in enumerate(filtered_results, 1): # 提取标题、链接、核心片段 title r.get(title, 无标题) link r.get(link, #) snippet r.get(snippet, ) # 尝试从摘要中提取关键事实例如日期、数字、特定名词 key_facts self._extract_key_facts(snippet) formatted_output.append( f[结果{i}] {title}\n f链接: {link}\n f摘要: {snippet[:150]}...\n # 限制摘要长度 f关键信息: {, .join(key_facts) if key_facts else 无}\n ) final_output \n---\n.join(formatted_output) return final_output if final_output else 未找到高质量的相关信息。 def _call_search_api(self, query: str, num: int): # 模拟API调用返回假数据 return [ {title: AI Agent开发指南 - 知乎专栏, link: https://zhuanlan.zhihu.com/p/..., snippet: 本文详细介绍了如何为AI Agent设计和扩展Skills...}, {title: LangChain Tools官方文档, link: https://python.langchain.com/docs/..., snippet: Tools are the actions an agent can take...}, # ... 更多结果 ] def _is_low_quality_source(self, url: str) - bool: low_quality_domains [spam-site.com, advertisement.com] return any(domain in url for domain in low_quality_domains) def _extract_key_facts(self, text: str): # 简单的关键词/模式匹配提取实际可用更复杂的NLP方法 import re facts [] # 找日期 date_pattern r\d{4}年\d{1,2}月\d{1,2}日|\d{4}-\d{2}-\d{2} dates re.findall(date_pattern, text) facts.extend(dates[:1]) # 只取第一个日期 # 找百分比或货币 if % in text or 美元 in text or 亿元 in text: facts.append(包含数值数据) return facts # 使用这个进阶工具 advanced_search_skill AdvancedSearchTool()这个进阶版做了几件重要的事强化了描述在description里明确了使用场景和条件引导Agent更明智地做出调用决策。规范了输入通过args_schema定义了结构化的输入query参数要求更明确还增加了可选的max_results。优化了输出内部对搜索结果进行了清洗、过滤和结构化提取关键事实并以更紧凑、信息密度更高的格式返回大大节省了上下文Token。内置了简单逻辑加入了基于来源的质量过滤和关键信息提取虽然简单但比直接返回原始API结果好得多。4.3 组合技能构建复杂工作流单个技能再强大也有局限。真正的提效来自于技能的组合。例如一个“市场调研”任务可能涉及“搜索最新行业报告”、“从报告中提取关键数据”、“将数据整理成表格”、“生成分析摘要”等多个步骤。我们可以通过两种方式实现组合方式一在单个技能内部串联逻辑你可以创建一个名为market_research的“宏技能”在其_run方法内部按顺序调用多个子函数或子API。这种方式简单直接但技能会变得臃肿且逻辑固定不易复用。方式二利用Agent的规划能力动态组合多个基础技能这是更优雅和强大的方式。你只需要提供一系列基础技能如web_search,extract_data_from_text,create_markdown_table,write_summary然后给Agent一个高层次的目标“请对‘AI编程工具’这个领域做一份市场调研输出一份包含主要玩家、特点和趋势的摘要报告。”一个具备规划能力的Agent如使用ReAct模式或通过LangGraph编排会自行决定调用技能的步骤调用web_search(“AI编程工具 2024 市场报告”)。从搜索结果中选择最相关的一两份报告链接。调用某个read_webpage_content技能如果存在获取全文或者直接基于摘要。调用extract_data_from_text技能从文本中提取公司名、产品名、特点等结构化信息。调用create_markdown_table技能将信息整理成表格。最后调用write_summary技能基于表格生成最终报告。在这个过程中你作为开发者只需要设计和提供好每个原子技能。Agent的“大脑”大模型负责规划和组合。这极大地增强了系统的灵活性和解决复杂问题的能力。5. 技能管理、安全与性能优化当技能越来越多你就需要一个“技能管理器”了。管理不仅仅是存储更重要的是控制访问、保障安全和监控性能。5.1 技能的注册、发现与动态加载一个基本的技能注册表可以是一个Python字典但更好的做法是使用配置文件或数据库。class SkillRegistry: def __init__(self): self._skills {} def register(self, skill: BaseTool, category: str general): 注册一个技能并为其分类。 if skill.name in self._skills: raise ValueError(fSkill {skill.name} already registered.) self._skills[skill.name] {tool: skill, category: category} def get_skill(self, name: str) - Optional[BaseTool]: return self._skills.get(name, {}).get(tool) def get_skills_by_category(self, category: str) - List[BaseTool]: return [v[tool] for k, v in self._skills.items() if v[category] category] def list_all_skills(self) - List[str]: return list(self._skills.keys()) # 使用 registry SkillRegistry() registry.register(advanced_search_skill, categoryinformation) registry.register(Tool(namecalculator, funclambda x: eval(x), description计算数学表达式), categoryutility) # Agent初始化时可以从registry中加载指定类别的技能 agent_skills registry.get_skills_by_category(information)更进一步可以实现技能的动态加载。例如根据用户会话的上下文或权限加载不同的技能集。或者设计一个“技能市场”允许从安全的远程仓库按需加载技能插件。5.2 安全是生命线技能调用的风险管控赋予Agent技能的同时也打开了风险之门。必须建立严格的安全边界。权限控制最重要不是所有技能都对所有用户或所有会话开放。一个内部财务数据分析技能绝不能暴露给外部用户。实现上可以在SkillRegistry的get_skills_for_session方法中根据用户身份、角色或会话标签进行过滤。输入验证与净化任何来自用户输入或模型生成的参数在传入技能执行前都必须进行严格的验证和净化。特别是对于执行系统命令command_line、操作数据库sql_executor、读写文件file_editor这类高危技能。白名单机制对于命令执行只允许运行预定义的安全命令列表。参数转义防止SQL注入、命令注入。路径限制文件操作技能必须将访问范围限制在特定的沙箱目录内。资源访问限制网络访问控制技能可以访问的域名或IP白名单。API调用限额为调用第三方API的技能设置速率限制和每日限额防止意外或恶意消耗。计算资源对执行长时间计算或大数据处理的技能设置超时限制。操作确认人工在环对于极高风险的操作如“删除生产数据库”、“向所有用户发送邮件”技能的设计应该是在执行前先生成一个待确认的操作计划摘要并强制要求人工审核确认后才能继续执行。这可以通过在Agent工作流中插入一个“人工审批节点”来实现。5.3 性能优化与监控技能调用通常是Agent工作流中最耗时的环节尤其是网络I/O。优化至关重要。缓存对于结果相对稳定、频繁被查询的技能如“查询某产品的规格参数”引入缓存可以极大提升响应速度并减少外部API调用。可以使用内存缓存如functools.lru_cache或分布式缓存如Redis。注意设置合理的过期时间。异步执行如果一个任务需要并行调用多个独立的技能例如同时查询天气、新闻和股票一定要使用异步模式。LangChain等框架支持异步的Tool。import asyncio async def async_search(query): # 模拟异步API调用 await asyncio.sleep(0.5) return f搜索结果: {query}超时与重试为每个技能配置合理的超时时间并实现优雅的重试逻辑最好有退避策略如指数退避。避免因为一个外部服务的临时故障导致整个Agent卡死。监控与日志记录每个技能的调用次数、成功率、平均耗时、失败原因。这不仅能帮你发现性能瓶颈哪个技能最慢还能发现设计问题哪个技能最常被错误调用或调用失败。这些数据是迭代优化技能集和Agent提示词的重要依据。6. 从技能到智能体设计让Agent“善用”技能的提示词拥有了强大的技能工具箱并不等于Agent就能用好它们。Agent的“大脑”——大语言模型——需要被正确地引导。这就涉及到提示词工程中关于工具调用的部分。糟糕的提示词只是简单地把工具列表扔给模型。“Here are some tools you can use: [tool descriptions...]”结果Agent可能会滥用工具在不该调用的时候调用或者生成错误的参数。优秀的提示词需要教会Agent何时用、为何用、怎么用。在你的系统提示词System Prompt中应该包含以下关键部分角色与能力定义明确告诉模型它是一个可以调用外部工具的助手。“你是一个AI助手除了对话之外你还可以通过调用一系列工具来获取信息或执行操作以更好地帮助用户。”工具使用原则优先使用内部知识“对于常识性、非实时性的问题优先使用你自己的知识回答不要随意调用工具。”明确调用条件“仅在以下情况调用工具a) 需要实时信息如天气、股价b) 需要执行用户请求的具体操作如计算、查询数据c) 用户明确要求你查询或使用某项工具。”参数必须明确“调用工具时必须确保提供的参数是完整、清晰且符合工具要求的。如果你不确定参数可以先询问用户。”结果处理指导“工具返回的结果是供你参考的信息。你需要理解、整合这些信息并用友好、自然的方式回复用户不要直接复制粘贴工具的原始输出。”“如果工具调用失败或返回错误不要慌张。向用户解释你遇到了问题并尝试换一种方式帮助用户或者建议用户提供更详细的信息。”格式化输出要求如果框架支持明确要求模型以特定的JSON格式如OpenAI的function_call来响应这能提高工具调用的解析成功率。通过这样细致的提示词设计你是在训练Agent的“工作习惯”让它从一个乱用工具的新手变成一个懂得在合适时机、用合适方法、高效使用工具的专业助手。这部分的调优往往比多开发几个技能带来的效果提升更显著。7. 迭代与评估如何判断你的技能系统真的在“提效”开发完成只是开始。你需要一套方法来评估你的技能扩展是否真的提升了Agent的效能。定义评估指标任务完成率给Agent一系列标准测试任务如“查一下北京今天和明天的天气对比”、“计算一下我的房贷月供”看它能否通过调用正确的技能组合成功完成。工具调用准确率在需要调用工具的任务中Agent是否调用了正确的工具调用时提供的参数是否准确人工评分让真实用户或评估员对Agent在扩展技能前后的回答质量进行评分例如1-5分评估其有用性和准确性的提升。效率指标平均完成任务所需的对话轮次是否减少用户是否更少地需要介入纠正或提供额外信息建立测试集 创建一个涵盖不同技能、不同难度的测试用例库。包括单技能测试测试每个技能是否能被正确触发和执行。多技能串联测试测试Agent解决复杂任务时的规划和组合能力。边界与异常测试测试在参数错误、工具失效、模糊指令等情况下的Agent行为。持续监控与迭代分析日志定期查看技能调用日志找出“僵尸技能”几乎不被调用和“瓶颈技能”调用频繁但失败率高。收集反馈建立用户反馈渠道特别是对于工具调用产生的结果用户是否满意A/B测试如果你改进了某个技能的描述或提示词可以设计A/B测试看新版本是否能提高该技能的调用准确率或任务完成率。扩展技能不是一个一劳永逸的项目而是一个需要持续观察、分析和优化的运营过程。你的技能库应该像一个活的生态系统不断淘汰无效的优化低效的并引入新的能力来应对不断涌现的新需求。8. 避坑指南扩展技能路上常见的“坑”结合我自己和身边朋友趟过的坑这里总结几个最容易出问题的地方坑一技能描述过于模糊或过于宽泛现象Agent频繁误调用技能或者在该调用的时候不调用。例子给一个数据处理技能的描述是“处理数据”。Agent完全不知道什么时候该用它。解法描述要具体明确使用场景、输入格式和输出内容。例如“当用户提供结构化的CSV数据或JSON数据并请求进行基本统计分析如计算平均值、总和、最大值、最小值时使用此工具。输入应为明确的数据字符串或文件路径。”坑二技能输出“污染”对话上下文现象技能返回冗长的、结构化的原始数据如大段JSON、HTML这些内容挤占了宝贵的上下文窗口导致后续对话质量下降或Agent混乱。解法技能必须做“摘要”或“格式化”。在_run方法里将原始结果转换成简洁、关键的自然语言描述。如果信息量大可以尝试提取关键字段用“键值对”或简短列表的形式呈现。坑三忽视错误处理和超时现象某个外部API挂掉导致整个Agent线程卡死用户请求超时。解法每个技能内部必须有完善的try...except块捕获所有可能的异常网络错误、解析错误、API错误等并返回一个统一的、对Agent友好的错误信息格式例如“调用XX服务时失败网络连接超时。请稍后再试或检查网络。” 同时在技能注册或调用层面设置全局超时。坑四技能之间的冲突或重复现象有两个功能相似的技能比如search_web和search_internal_wikiAgent有时会混淆。解法在技能描述中清晰界定边界。例如search_web的描述强调“公开的、实时的网络信息”search_internal_wiki的描述强调“公司内部的、非公开的文档和知识”。也可以考虑设计一个更通用的“搜索”技能在内部根据查询词自动路由到不同的数据源。坑五把Agent当成“万能胶水”过度依赖技能现象所有逻辑都试图拆成技能Agent变成了一个单纯的“调度器”失去了其核心的推理和语言理解优势。反思技能是扩展Agent的能力边界而不是替代它的思考能力。那些需要复杂逻辑判断、创造性生成、深度上下文理解的任务应该留给大模型本身。技能应该用来处理模型不擅长或无法做到的“动作”获取实时数据、执行计算、操作外部系统。把握好这个平衡才能造出真正智能的助手而不是一个笨拙的自动化脚本。