1. 引言在最近的一个 AI Agent 项目中我陆续编写了 10 个不同的 Agent Skill。每个 Skill 都负责一个独立的业务能力比如查询天气、发送邮件、调用内部 API、解析文档等。写第一个 Skill 时很顺畅写第二个也还行但写到第五个时我发现自己陷入了 CtrlC / CtrlV 的泥潭。每个 Skill 都包含几乎相同的模板代码参数校验、错误处理、日志记录、结果格式化……10 个 Skill 下来光这些重复的“骨架”代码就堆了将近 300 行。这不仅让代码库变得臃肿更可怕的是——每次要修改公共逻辑比如统一日志格式就得手动改 10 个文件。于是我决定重构。最终通过抽象公共基类和装饰器模式我把这 300 行重复代码压缩到了 30 行。这篇文章就来分享我是怎么做到的。2. 问题重现一个典型的 Agent Skill 长什么样先看一个典型的 Skill 实现。假设我们有一个WeatherSkill用于查询天气classWeatherSkill:def__init__(self,name:strweather):self.namename self.loggerlogging.getLogger(self.name)defcan_handle(self,intent:str)-bool:returnintentquery_weatherdefexecute(self,params:dict)-dict:# 参数校验ifcitynotinparams:return{success:False,error:Missing city parameter}# 业务逻辑try:resultself._query_weather(params[city])# 结果格式化return{success:True,data:result}exceptExceptionase:self.logger.error(fFailed to query weather:{e})return{success:False,error:str(e)}def_query_weather(self,city:str)-dict:# 实际的 API 调用return{temperature:25,condition:sunny}看起来还不错但当你写出第 2 个、第 3 个 Skill 时你会发现__init__、can_handle、execute里的参数校验、异常捕获、日志记录、返回格式——这些代码几乎一模一样。3. 重复代码的统计与分析我整理了 10 个 Skill 的代码统计了重复部分重复模块每个 Skill 行数10 个 Skill 总行数__init__初始化3 行30 行can_handle意图匹配3 行30 行execute参数校验5 行50 行executetry-except 包裹6 行60 行日志记录4 行40 行结果格式化3 行30 行其他类型注解、文档字符串等6 行60 行合计30 行300 行核心业务逻辑真正的 API 调用、数据处理只占每个 Skill 的 20% 左右。80% 的代码都是“基础设施”。4. 重构方案抽象基类 装饰器我的目标是让每个 Skill 只写业务逻辑其余全部由框架自动完成。4.1 定义抽象基类首先创建一个BaseSkill把公共逻辑全部收进来importloggingfromabcimportABC,abstractmethodfromfunctoolsimportwrapsclassBaseSkill(ABC):def__init__(self,name:strNone):self.namenameorself.__class__.__name__.lower()self.loggerlogging.getLogger(self.name)defcan_handle(self,intent:str)-bool:# 默认通过类名匹配子类可覆盖returnintentself.namedefexecute(self,params:dict)-dict:# 统一的执行入口自动包裹校验和异常处理try:self._validate(params)resultself._execute(params)returnself._format_result(result)exceptExceptionase:self.logger.error(fExecution failed:{e},exc_infoTrue)return{success:False,error:str(e)}def_validate(self,params:dict):子类可重写默认不做校验passabstractmethoddef_execute(self,params:dict)-dict:子类必须实现真正的业务逻辑passdef_format_result(self,result:dict)-dict:子类可重写默认包装为成功响应return{success:True,data:result}4.2 用装饰器处理参数校验对于需要参数校验的 Skill我写了一个装饰器避免在每个_execute里写 if-elsedefrequire_params(*required_keys):defdecorator(func):wraps(func)defwrapper(self,params:dict,*args,**kwargs):missing[kforkinrequired_keysifknotinparams]ifmissing:raiseValueError(fMissing required parameters:{missing})returnfunc(self,params,*args,**kwargs)returnwrapperreturndecorator4.3 重构后的 Skill 长什么样现在一个 Skill 只需要 3 行核心代码classWeatherSkill(BaseSkill):require_params(city)def_execute(self,params:dict)-dict:return{temperature:25,condition:sunny}另一个 Skill 也类似classEmailSkill(BaseSkill):def__init__(self):super().__init__(namesend_email)require_params(to,subject,body)def_execute(self,params:dict)-dict:# 真正的发邮件逻辑return{message_id:12345,status:sent}5. 效果对比重构前后对比指标重构前重构后每个 Skill 平均代码行数30 行3 行10 个 Skill 总行数300 行30 行公共逻辑修改改 10 个文件改 1 个基类新增一个 Skill 成本30 行模板 业务3 行业务单元测试覆盖难模板代码干扰易只测业务更重要的是可维护性得到了质的提升。后来我又加了 5 个 Skill每个只花了 5 分钟写业务逻辑再也不用复制粘贴了。6. 总结与思考这次重构让我深刻体会到重复代码是万恶之源。当你在写第 3 个相似的类/函数时就该停下来思考抽象方案了。抽象基类 装饰器是消除 Agent Skill 模板代码的绝佳组合。基类负责骨架装饰器负责横切关注点参数校验、权限检查等。不要过度抽象。我的原则是只有出现 3 次以上重复时才考虑抽象。过早抽象反而会增加理解成本。代码行数不是唯一目标。虽然从 300 行压到了 30 行但更重要的是代码的可读性和可维护性。30 行清晰的代码远胜 300 行重复的代码。如果你也在写 Agent 或类似的插件化系统不妨试试这个模式。你会发现写代码可以是一件很清爽的事。