设计模式详解之工厂模式

作者:刘文慧

本文将着眼于工厂模式,从简单工厂模式、工厂方法模式和抽象工厂模式出发,展开学习和深入探讨。

​

一、概述

我们在进行软件开发时要想实现可维护、可扩展,就需要尽量复用代码,并且降低代码的耦合度,而设计模式就是一种可以提高代码可复用性、可维护性、可扩展性以及可读性的解决方案。

大家熟知的23种设计模式,可以分为创建型模式、结构型模式和行为型模式三大类。其中,创建型模式是对类的实例化过程进行抽象,从而将对象的创建和使用分离开。工厂模式属于创建型模式的范畴,本文将着眼于工厂模式,从简单工厂模式、工厂方法模式和抽象工厂模式出发,展开学习和深入探讨。

二、基本概念

工厂模式的核心思想就是把创建对象和使用对象解藕,由工厂负责对象的创建,而用户只能通过接口来使用对象,这样就可以灵活应对变化的业务需求,方便代码管理、避免代码重复。

假设我们在工作中需要将产品a升级为产品A ,如果创建对象的工作是由用户来做,也就是用户通过new a()的形式创建对象,那么为了应对新的产品升级需求,我们还需要找到所有相关代码并将它们改为new A(),这对于淘宝下的很多庞大工程而言就是一项极为繁琐的工作;而通过应用工厂模式,将所有对象创建工作交由工厂管理时,我们就可以直接在工厂中将return new a()改为return new A(),用户仍然可以调用 factory.createProduct()方法而无须更改原本的代码。这样工厂可以通过复用来减少重复代码量,并且用户无需关注创建对象的逻辑。

工厂模式在Java程序员的工作中可以说是无处不在:我们最常用的Spring就是一个Bean工厂,IOC通过BeanFactory对Bean进行管理(可参考上面这张类图);我们使用的日志框架slf4j使用了工厂方法模式;JDK的Calendar使用了简单工厂模式……

下面本文将结合基本概念和具体示例来详细分析常用的几种工厂模式。

2.1 简单工厂模式

顾名思义,简单工厂模式是最简单的一种工厂模式,它定义了一个负责生产对象的工厂类,使用者可以根据不同参数来创建并返回不同子类,这些子类都共用一个接口(即父类)。

结构

简单工厂模式包含三种类,分别是抽象产品类、具体产品类、工厂类,下面分别对各类及它们之间的关系作进一步说明。

使用

有了上述的基本概念,我们将简单工厂模式的使用步骤概括为:

  • step1:创建抽象产品类,并为具体产品定义好一个接口;

  • step2:创建具体产品类,其通过接口来继承抽象产品类,同时也要定义计划生产的每一个具体产品;

  • step3:创建工厂类,其创建的静态方法可以对传入的不同参数做出响应;

  • step4:外界使用者就能调用工厂类的静态方法了,通过传入不同参数来创建不同具体产品类的实例。

下面以淘宝服装店铺的商品展示销售进行阐释,比如一个衬衫专卖店需要在淘宝上展示旗下商品,我们可以把所有衬衫都分别单独定义一个类,这样就可以随意添加或修改某一个新的衬衫类型,并使用Fcatory类来判断要创建哪一个衬衫类型的对象,即:先声明一个父类对象的变量,再根据用户输入的参数判断新建什么具体的衬衫类型对象。

代码实现

//step1:创建抽象产品类,定义具体产品的公共接口
public abstract class Shirt{
    public abstract void Show();
}
​
//step2:创建具体产品类(继承抽象产品类),定义生产的具体产品
//具体产品类A,女款衬衫
public class WomenShirt extends Shirt{
    @Override
    public void Show(){
        System.out.println("展示女款衬衫");
    }
}
//具体产品类B,男款
public class MenShirt extends Shirt{
    @Overside
    public void Show(){
        System.out.println("展示男款衬衫");
        }
}
​
//step3:创建工厂类,通过静态方法处理不同传入参数,从而创建不同具体产品类的实例
public class Factory{
    public static Shirt Exhibit(String ShirtName){
        switch(ShirtName){
            case "女款衬衫":
                return new WomenShirt();
            case "男款衬衫":
                return new MenShirt();
            default:
                return null;
        }
    }
}
​
//step4:外界调用工厂类的静态方法,传入不同参数创建不同具体产品类的实例
public class SimpleFactoryPattern{
    public static void main(String[] args){
        Factory exhibitFactory = new Factory();
        //用户搜索女款衬衫
        try{
            //调用工厂类的静态方法,传入参数并创建实例
            exhibitFactory.Exhibit("女款衬衫").Show();
        }catch(NullPointerException e){
            System.out.println("没有找到商品");
        }
        //用户搜索男款裤子
        try{
            exhibitFactory.Exhibit("男款裤子").Show();
        }catch(NullPointerException e){
            System.out.println("没有找到商品");
        }
        //用户搜索男款衬衫
        try{
            exhibitFactory.Exhibit("男款衬衫").Show();
        }catch(NullPointerException e){
            System.out.println("没有找到商品");
        }
    }
}

结果输出

展示女款衬衫
没有找到商品
展示男款衬衫

UML图

优缺点

优点

1)将对象的使用和创建过程分离开,实现解藕。客户端不需要关注对象是谁创建的、怎么创建的,只要通过工厂中的静态方法就可以直接获取其需要的对象。

2)将初始化实例的工作放到工厂里执行,代码易维护, 更符合面向对象的原则,做到面向接口编程,而不是面向实现编程。

缺点

1)工厂类中需要选择创建具体某个对象,所以一旦添加新产品则必须要对工厂中的选择逻辑进行修改,导致工厂逻辑过于复杂,违背开闭原则。

2)工厂类集合了所有实例(具体产品)的创建逻辑,一旦这个工厂不能正常工作,整个系统都会受到影响。

3)静态方法不能被继承和重写,会造成工厂角色无法形成基于继承的等级结构。

适用场景

  • 具体产品类较少时,使用简单工厂模式可以实现生产者与消费者的分离,而且也不会在工厂类中设定太复杂的判断逻辑。

  • 使用者只知道传入工厂类的参数,不关心如何创建对象的逻辑时。

2.2 工厂方法模式

结构

工厂方法模式包含四种类,分别是抽象产品类、具体产品类、抽象工厂类、具体工厂类,下面分别对各类以及它们之间的关系作进一步说明。

使用

根据上述概念,下面将抽象工厂模式的使用步骤概括如下:

  • step1:创建抽象工厂类,定义具体工厂的公共接口;

  • step2:创建抽象产品类,定义具体产品的公共接口;

  • step3:创建具体产品类(继承抽象产品类),定义生产的具体产品;

  • step4:创建具体工厂类(继承抽象工厂类),定义创建相应具体产品实例的方法;

  • step5:外界调用具体工厂类的方法,创建不同具体产品类的实例。

还是以淘宝店铺下的宝贝分类展示功能举例,假如该服装店除男款衬衫和女款衬衫外,还要新增一个衬衫类型如中性衬衫,按照简单工厂模式我们依然可以继承Shirt抽象父类,override衬衫类型,然后在Fcatory中添加新分支,然而这样虽然扩展了衬衫类型,却对Fcatory类进行了修改,不符合“开放扩展、关闭修改”的开闭原则。为了应对这种需求变化,我们可以使用工厂方法模式,提取出一个工厂父类接口Fcatory,并创建各衬衫类型的工厂子类WomenShirtFactory、MenShirtFactory、NeutralShirtFactory,并分别使用对应的工厂子类来判断要创建哪一衬衫类型的对象。

代码实现 

//step1:创建抽象工厂类,定义具体工厂的公共接口
public abstract class Factory{
    public abstract Shirt Exhibit();
}
​
//step2:创建抽象产品类,定义具体产品的公共接口
public abstract class Shirt{
    public abstract void Show();
}
​
//step3:创建具体产品类(继承抽象产品类),定义生产的具体产品
//具体产品类A,女款衬衫
public class WomenShirt extends Shirt{
    @Override
    public void Show(){
        System.out.println("展示女款衬衫");
    }
}
//具体产品类B,男款衬衫
public class MenShirt extends Shirt{
    @Overside
    public void Show(){
        System.out.println("展示男款衬衫");
    }
}
​
//step4:创建具体工厂类,定义创建具体产品实例的方法
//具体工厂类A,展示女款衬衫类商品  
public class WomenShirtFactory extends Factory{
   @Overside
    public Shirt Exhibit(){
        return new WomenShirt();
    }
}
//具体工厂类B,展示男款衬衫类商品
public class MenShirtFactory extends Factory{
   @Overside
    public Shirt Exhibit(){
        return new MenShirt();
    }
}
​
//step5:外界调用具体工厂类的方法,创建不同具体产品类的实例
public class FactoryPattern{
    public static void main(String[] args){
        //用户在店铺搜索女款衬衫
        Factory exhibitWomenShirtFactory = new WomenShirtFactory();
        exhibitWomenShirtFactory.Exhibit().Show();
        
        //用户在店铺搜索男款衬衫
        Factory exhibitMenShirtFactory = new MenShirtFactory();
        exhibitMenShirtFactory.Exhibit().Show();       
    }
}

结果输出

展示女款衬衫
展示男款衬衫

UML图

优缺点

优点

1)符合开闭原则。新增一种产品时,只需要增加相应的具体产品类和工厂子类即可,可方便的生产或切换产品,而无须像简单工厂模式那样修改工厂类的判断逻辑,具有更高的扩展性 。

2)符合单一职责原则。每个具体工厂类只负责创建对应的具体产品,而简单工厂中的工厂类存在复杂的switch逻辑判断。

3)相比于简单工厂模式,使用的不是静态方法,可形成基于继承的等级结构。

缺点

1)一个具体工厂只能创建一种具体产品。添加新产品时,除增加新产品类外,还要提供与之对应的具体工厂类,类的个数成对增加,在一定程度上增加了系统复杂度;同时有更多的类需要编译和运行,给系统带来额外开销。

2)由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到DOM、反射等技术,增加了系统的实现难度。

3)虽然保证了工厂方法内的对修改关闭,但对于使用工厂方法的类,如果要更换另外一种产品,仍然需要修改实例化的具体工厂类。

4)难以对父类接口进行修改,因为一旦修改接口,就必须要对众多的帮忙子类进行修改。

适用场景

一个类不确定它所必须创建的对象的类。在工厂方法模式中,客户端不需要知道具体产品类的类名,只需要知道所对应的工厂即可。

你期望获得较高的扩展性。

一个类希望由它的子类来指定它所创建的对象。在工厂方法模式中,对于抽象工厂类只需提供一个创建产品的接口,而由其子类来确定具体要创建的对象,利用面向对象的多态性和里氏替换原则,在程序运行时,子类对象将覆盖父类对象,从而使系统更容易扩展。

当类将创建对象的职责委托给多个工厂子类的中的某一个,且用户知道将要使用哪一个工厂子类。

2.3 抽象工厂模式

抽象工厂模式,提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们的具体类。抽象工厂模式与工厂方法模式最大的区别:抽象工厂中每个具体工厂可以创建多类具体产品;而工厂方法每个具体工厂只能创建一类具体产品。

结构

工厂方法模式包含五种类,分别是抽象产品族类、抽象产品类、具体产品类、抽象工厂类、具体工厂类,下面分别对各类以及它们之间的关系作进一步说明:

使用

根据上述概念,下面将工厂方法模式的使用步骤概括如下:

  • step1:创建抽象工厂类,定义具体工厂的公共接口;

  • step2:创建抽象产品族类,定义抽象产品的公共接口;

  • step3:创建抽象产品类(继承抽象产品族类),定义具体产品的公共接口;

  • step4:创建具体产品类(继承抽象产品类),定义生产的具体产品;

  • step5:创建具体工厂类(继承抽象工厂类),定义创建相应具体产品实例的方法;

  • step6:外界调用具体工厂类的方法,创建不同具体产品类的实例。

这里继续以网店销售服装举例,假设上述衬衫淘宝专卖店的运营总部还有一家裤子淘特专卖店,随着用户需求变化,淘宝用户也要购买裤子,同时淘特用户要购买衬衫,那么我们可以使用抽象工厂模式升级这两个店铺,令淘宝店铺展示销售衬衫+裤子,淘特店铺展示销售裤子+衬衫。

代码实现

//step1:创建抽象工厂类,定义具体工厂的公共接口
public abstract class Factory{
    public abstract Clothing ExhibitShirt();
    public abstract Clothing ExhibitTrousers();
}
​
//step2:创建抽象产品族类,定义抽象产品的公共接口
public abstract class Clothing{
    public abstract void Show();
}
​
//step3:创建抽象产品类,定义具体产品的公共接口
//衬衫抽象类
public abstract class Shirt extends Clothing{
    @Override
    public abstract void Show();
}
//裤子抽象类
public abstract class Trousers extends Clothing{
    @Override
    public abstract void Show();
}
​
//step4:创建具体产品类(继承抽象产品类),定义生产的具体产品
//衬衫产品类A,淘宝衬衫
public class TBShirt extends Shirt{
    @Override
    public void Show(){
        System.out.println("展示淘宝店铺衬衫");
    
}
//衬衫产品类B,淘特衬衫
public class TTShirt extends Shirt{
    @Overside
    public void Show(){
        System.out.println("展示淘特店铺衬衫");
    }
}
//裤子产品类A,淘宝裤子
public class TBTrousers extends Trousers{
    @Override
    public void Show(){
        System.out.println("展示淘宝店铺裤子");
    }
}
//裤子产品类B,淘特裤子
public class TTTrousers extends Trousers{
    @Overside
    public void Show(){
        System.out.println("展示淘特店铺裤子");
    }
}
​
//step5:创建具体工厂类,定义创建具体产品实例的方法
//淘宝工厂类A,展示衬衫+裤子  
public class TBFactory extends Factory{
    @Overside
    public Clothing ExhibitShirt(){
        return new TBShirt();
    }
    @Overside
    public Clothing ExhibitTrousers(){
        return new TBTrousers();
    }
}
//淘特工厂类B,展示裤子+衬衫
public class TTFactory extends Factory{
    @Overside
    public Clothing ExhibitShirt(){
        return new TTShirt();
    }
    @Overside
    public Clothing ExhibitTrousers(){
        return new TTTrousers();
    }
}
​
//step6:外界实例化具体工厂类,调用工厂类中创建不同目标产品的方法,创建不同具体产品类的实例
public class AbstractFactoryPattern{
    public static void main(String[] args){
        TBFactory exhibitTBFactory = new TBFactory();
        TTFactory exhibitTTFactory = new TTFactory();
        //淘宝用户搜索衬衫
        exhibitTBFactory.ExhibitShirt().Show();
        //淘宝用户搜索衬衫
        exhibitTBFactory.ExhibitTrousers().Show();
        //淘特用户搜索衬衫
        exhibitTTFactory.ExhibitShirt().Show();
        //淘特用户搜索衬衫
        exhibitTTFactory.ExhibitTrousers().Show();     
    }
}

结果输出

展示淘宝店铺衬衫
展示淘宝店铺裤子
展示淘特店铺衬衫
展示淘特店铺裤子

UML图

优缺点

优点

1)降低耦合度。抽象工厂模式将具体产品的创建延迟到具体工厂类中,这样将对象的创建封装起来,可以减少客户端与具体产品类之间的依赖,从而降低系统耦合度,有利于后期的维护和扩展。

2)符合开闭原则。新增一种产品类时,只需增加相应的具体产品类和工厂子类即可,简单工厂模式需要修改工厂类的判断逻辑。

3)符合单一职责原则。每个具体工厂类只负责创建对应的产品,简单工厂模式中的工厂类需要进行复杂的 switch 逻辑判断。

4)不使用静态工厂方法,可以形成基于继承的等级结构。

5)便于添加更换产品族。因为具体产品都是由具体工厂创建的,所以在更换产品族的时候只要简单修改具体工厂即可。

6)具体产品的创建过程和客户端隔离。客户端通过操作抽象产品接口实现操作具体产品实例,具体产品的类名不会出现在客户端中。

缺点

1)难以支持新种类产品的变化。这是因为抽象工厂接口中已经确定了可被创建的产品集合,如果需要添加新产品,此时就必须去添加抽象产品接口,还要在抽象工厂接口中添加新方法,并在所有具体工厂中实现该新方法。这样就会改变抽象工厂类以及所有具体工厂子类的改变,违背开闭原则。

2)类图有点复杂,可读性没有工厂方法模式高。

适用场景

  • 系统不要求依赖产品类实例如何被创建、组合和表达,这点也是所有工厂模式应用的前提。

  • 系统要求提供一个产品类的库,所有产品以同样的接口出现,客户端不需要依赖具体实现。

  • 系统中有多个产品族,但每次只使用其中某一族产品。(切换产品族只需修改具体工厂对象即可)

三、总结

简单工厂模式:让一个工厂类负责创建所有对象;但没有考虑后期扩展和维护,修改违背开闭原则,静态方法不能被继承。

工厂方法模式:主要思想是继承,修改符合开闭原则;但每个工厂只能创建一种类型的产品。

抽象工厂模式:主要思想是组合,本质是产品族,实际包含了很多工厂方法,修改符合开闭原则;但只适用于增加同类工厂这种横向扩展需求,不适合新增功能方法这种纵向扩展。

其实这三种工厂模式在形式和特点上都非常相似,甚至存在一定的内在联系,而且最终目的都是解耦。在使用时,我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式,因为它们之间也是可以灵活转变的。

比如你原本使用的是工厂方法模式,加入一个新方法后就可能会让具体产品类构成不同等级结构中的产品族,代码结构就变成抽象工厂模式了;而对于抽象工厂模式,当减少一个或多个具体产品类时,使原有产品族只剩下一个产品后,代码结构也就转变成了工厂方法模式。

相关推荐

阿里巴巴 12 篇论文入选全球系统顶会 ATC 2026(内附下载)

2026 ATC 会议中,阿里巴巴以12篇论文录用数居全球企业首位。研究聚焦大模型服务与Agent基础设施、云资源调度、安全计算等关键瓶颈,提出CacheFS(P2P权重缓存)、Axon(异步KV感知调度)、Chorus(GPU-CPU协同解码)等创新系统,显著提升推理效率与资源利用率。论文基于真实生产数据,推动系统优化从理论走向落地,彰显中国产业界在计算机系统领域的前沿影响力。

阿里技术 265

Personal Agent 对比分析及未来技术发展趋势

近期,Personal Agent赛道迅速升温,大厂与独角兽密集发布新品。从Anthropic的Claude Tag、SpaceXAI的Grok Bot,到Meta的Muse、OpenAI的Dots等,均聚焦个人用户场景,强调“数字同事”与个性化服务。相比早期Agent多用于开发或企业协作,新版本更注重跨平台集成、主动任务执行与用户情感连接。技术上,其核心差异在于更强的自主决策能力、长期记忆与多模态交互。这标志着Agent正从工具向“智能代理”演进,预示着人机协同的新范式。

阿里技术 109

高分智能体为何反而更脆弱?阿里 Token Foundry 揭示「协同进化陷阱」,提出 CODA 可靠性评测协议

本文揭示智能体在技能—策略协同进化中存在“协同进化陷阱”:尽管训练阶段分数持续提升,但模型对特定技能库依赖加深,导致部署后技能变化时性能显著下降。阿里巴巴团队提出可靠性评测协议CODA,引入一致率、抗干扰率与最差成功率等指标,系统评估模型在技能漂移下的稳定性。实验表明,原始增益52%–93%被抵消,凸显当前评测仅关注峰值成绩的局限性。研究呼吁从“追求高分”转向“保障可靠”,推动智能体在动态环境中持续可信运行。

阿里技术 350

手把手带工程同学从零实现一个完整的 LLM(CS336)——Transformer 篇

本文是学习斯坦福CS336课程的首篇笔记,从零构建MLP入手,逐步理解神经网络训练原理。通过线性回归与非线性拟合实验,揭示损失函数、梯度下降与激活函数的作用。文章以手搓MLP为例,为后续实现带RoPE、SwiGLU的Transformer打下基础,强调深入理解LLM底层机制对Agent开发的重要性。

阿里技术 280

深度解析 RSI:当 AI 开始实现自我迭代提升

2026年,RSI(递归自我改进)因Anthropic与多位AI巨头论文引爆热议。其核心是AI自主优化自身,形成正反馈循环,理论上可催生智能爆炸与超级智能。虽严格意义上的RSI仍存挑战,但广义上已涵盖自进化、持续学习等技术。从人工编码到AI自主开发,研发效率呈指数提升。尽管RSI非实现AGI/ASI的唯一路径,也未必必然引发智能爆炸,但其作为“如何达成智能跃迁”的关键机制,正推动AI进入自我迭代新阶段。

阿里技术 403

清华×阿里 AI Native人才培养计划暨格造社启动日活动举行

10月15日,清华大学无穹书院与阿里巴巴联合启动“格造社AI开源俱乐部”,以“从好奇到创造”为主题,发布近40个涵盖算力、模型与公益创新的AI真实课题。通过校企协同、开源共享与项目实践,学生将在导师指导下开展选题、开发与验证,成果将开源发布于魔搭社区,推动技术转化与创新成长。活动还配套开展多场工作坊,助力AI Native人才培养。

阿里技术 153

从榜单走向真实业务负载:Kernel Agent 刷新 Qwen3.8-Max 核心推理算子性能

Kernel Agent 的公开研究已经表明,Agent 可以在标准题目上生成并优化 GPU Kernel;AKA 这次把问题推进到了生产契约:面对 Qwen3.8-Max 的真实关键算子、复杂调度约束,以及专家已经深度优化过的实现,Agent 仍然找到了新的执行路径,并在三条独立算子线的几何平均时延上全部低于专家版本。AKA 将反馈、设计和生产验证组织成一个可以持续运行的闭环,把专家经验之外的结构维度纳入搜索,也把一次性能突破沉淀为下一次优化的系统能力。

阿里技术 188

代码生成越来越快,软件交付真正的瓶颈转向了哪里?

2026年云栖大会,阿里巴巴探讨AI Native研发范式转型。嘉宾指出,尽管代码生成提速,但交付瓶颈已转向需求明确、上下文连续、环境复现与验证机制等环节。许晓斌强调需构建完整工程系统支撑Agent生产落地;李英各提出“统一上下文+验证”降低协作成本;黄挺揭示基础设施正从服务人转向服务Agent;陈烨主张将AI前置至需求入口重构流程;彭鑫以“可驾驭性”界定AI边界;李亚洲则警示个人效率提升不等于团队效能跃迁。最终,《AI Native研发实践手册》发布,推动研发从“辅助编码”迈向“系统重构”。

阿里技术 157

《AI Native 研发范式实践手册》重磅发布

在云栖大会发布的《AI Native 研发范式实践手册》揭示了AI研发从“辅助编码”迈向“自主交付”的关键转折。随着MCP协议、Agent Harness框架及多模型协同的成熟,行业进入Agentic时代。阿里巴巴通过AIDC数字投手、千问用增Agent等实践,探索企业级AI研发基础设施建设,聚焦环境验证、知识沉淀、组织变革三大挑战,推动Agent实现从写代码到可靠交付的跃迁,构建覆盖工具链、安全管控与可观测性的系统化工程体系。

阿里技术 953

当 AI 开始真正“做事”,基础设施准备好了吗?

Agent 可以写代码、修改配置并提交变更,但“任务已完成”不能只由 Agent 自己判断。代码进入生产之前,仍然需要稳定、准确、可追溯的评审机制。

阿里技术 266

把「达标判定」从大模型手里收回来:Graph Engineering实践

回看整个 Agent 的演进过程,模型换过,编排的流程换过,Agent 合过也拆过,但工程方向始终一致:我们在不断地减少模型的自主权,把可被代码验证的确定性决策,从模型侧逐项收回到控制面。首先是把「达标判断」从模型手里收回:给予客观的评测手段,并在评测里加入对侧样本,防止过度优化走向过拟合。其次是把「核心目标」给模型解释清楚:先理清楚优化的最终目标是什么,可以从什么方向进行优化,要解决的是过拟合还是无效优化。才能保证模型的方向不会跑偏。

阿里技术 276

垂类业务如何落地生产级 Agent

在AI技术快速迭代背景下,AI Agent从概念走向生产需跨越稳定性、可控性、可审计性与业务闭环四道关。尽管工具链与模型能力成熟带来窗口期,但真实业务中复杂场景与风险要求系统化工程支撑。企业应聚焦“大模型+工具+循环”核心范式,以标准化协议与可复现流程实现从“能跑”到“能产”的跃迁,把握垂类落地先机。

阿里技术 144

5 人 7 天干完 20 人数周的活:Spec-Driven Development 如何重新定义 AI 编程

5人7天用Qoder完成传统需20人数周的工作,核心在于Spec-Driven Development(SDD)。通过Day 0精心撰写可验证、有边界、带约束的Spec,将“WHAT”明确化,让AI高效执行“HOW”。SDD以spec.md为唯一真实来源,辅以plan.md与tasks.md拆解任务,constitution.md固化原则,实现人机协同、并行开发与自举迭代。其本质是:在AI时代,代码只是思考的副产品,而规范才是工程的锚点。

阿里技术 234

AI Agent 应用精细化评测:评测体系设计与工程实践

本文构建了一套面向AI Agent的精细化评测体系,突破传统粗粒度评估局限,从感知、规划、记忆、工具四大模块入手,实现“质量×成本×性能”三维量化。通过模块级拆解与端到端结合,支持根因定位、幻觉检测与多轮交互评估,结合自动化数据集映射与埋点采集,打造可持续、可追溯的评测基础设施,助力Agent高效迭代与生产落地。

阿里技术 440

zg 正式开源:本地检索,不止于关键词

<think>我们根据文章内容写一段≤150字的摘要。文章主要介绍zg(zvec-grep)本地优先检索工具,解决人和Agent在本地文件中查找信息困难,结合向量检索、BM25和rg,提供语义检索、精确匹配,支持CLI/MCP,本地优先,多语言格式。摘要需简洁,涵盖核心要点。字数限制严格。输出摘要即可。</think>zg(zvec-grep)是面向人与 Agent 的本地优先检索基础设施,结合 Zvec 向量检索、BM25 与 ripgrep,实现从语义探索、相关性排序到精确验证的全流程检索。它支持多种代

阿里技术 493

Agent 终章(Harness 成本篇):一次百炼账单降低 88% 实战

回头看,成本优化并不是一套外挂式的 Token 优化技巧,它们就是 Harness 实践。模型只负责生成,Harness 决定哪些内容要发、哪些过程要隔离、什么时候该停,以及这次任务应该用什么模型,最终怎么高效完成这个 prompt。Agent Loop 的成本本身也没有什么单一解法。前缀少一点、缓存多命中一点、探索少带回来一点、无效轮次少跑一次,单看都不惊人;但这些开销会在每一轮、每一次任务里重复,最后的差距就是这样乘出来的。这就是开头提示写出一个能跑的 Agent 很容易。

阿里技术 232

阿里巴巴 12 篇论文入选全球网络顶会 SIGCOMM 2026(内附下载)

在网计算将集合通信卸载到网络交换机进行,可以压缩流量,进而加速传输过程。在网计算系统的构成通常包括交换机、网卡、协议栈、通信库、网络管理器;但是在开放以太网生态中,上述组件分属不同的供应商或者开发者,彼此之间存在依赖。以太网生态的的供应商和开发者在自己的功能范围内无法实现整体的系统;在单独一个生态位实现自己功能而缺乏其他厂商配合的情况下,其研发投入无法体现为系统级别的加速能力,造成低效的投入回报比。

阿里技术 483

Harness 工程之道:Skill 原理与最佳实践

Agent Skills 是一种轻量、开放的能力扩展规范,用于为 AI Agent 扩展专业知识和工作流。本文从概念原理出发,结合真实的工程化项目 trade-ab-skill,系统性地讲解 Skill 的结构规范、触发机制、作用域优先级,以及最佳实践。(文章内容基于作者个人技术实践与独立思考,旨在分享经验,仅代表个人观点。

阿里技术 320

Agent 越改越乱之后,我用评测和轨迹把它拉回来了

如果你也在反复手改 agent 的 skill、打地鼠似的顾此失彼,不妨试试让这件事跑起来:让 agent 完成任务的能力,沿着评测结果自己进化。参考资料:《别让大模型"想太多":SKILL 开发中的语义陷阱与抗幻觉设计》

阿里技术 369

Qoder CLI 上运行 Qwen3.8-Max:5 个硬核任务实测

这次评测开始前,我们关心的问题是:在单轮提示词驱动下,这些模型能不能独立跑完数小时量级的工程任务。实际上五个任务中,所有模型均独立走完了全程,没有一家中途失控。真正需要关注的问题是,在没有人规定「好」是什么的空白处,模型只能依靠自己的标准决定做到什么程度才算完成。这一代模型+Harness之间比的,已经不是能不能达到要求,而是在无人要求时,它对自己的要求是什么。最后是本文全部结论共同的边界:每个任务均为单次运行,小分差不构成排名依据;

阿里技术 379

连续五天登上 GitHub Trending 首页的思考

现在是做开源最好的时代。AI 把那些原本吃掉维护者大量时间的重复性工作(Issue 分类、代码评审、测试编写、发版……)自动化了。一个小团队甚至一个人,就能撑起过去十人团队的节奏。门槛降低了,但上限没降——省下来的时间用在真正需要判断力的地方:定方向、做决策、经营社区。几个我觉得最重要的认知:**别开源一个 demo。**AI 时代做 0-1 太容易了,社区不缺 demo,缺的是经过验证的方案。你的“判决书”越硬(生产数据、benchmark、真实用户规模),别人帮你传播的时候底气就越足。

阿里技术 467

从 Agent Flow 到 AI Native:为什么通用 Agent 是“饮鸩止渴”

我最近一直在做一个“小玩具”:Agent Flow。最初的目的很明确,就是想在某些特定场景和受众群里,取代现有的 Agent Skill。这个 Flow 本质上是传统 Flow 的强化,但它的核心不是让用户理解节点、连线和 JSON,是让用户用自然语言描述目标,然后让 LLM 去理解目标、生成 Flow、修改 Flow、运行 Flow。Flow 本身的重要性也降级了,它只是一个编排层,不对 Node 和细节负责,只负责链路控制、任务下发和结果回收,具体的任务由 Node 负责。

阿里技术 361

NL2SQL 在超大规模数仓场景的架构突破与工程实践

本文介绍了高德数据团队基于QoderWork Agent Skill构建的NL2SQL智能取数系统从V1到V2的架构演进。V1采用分域独立Skill设计,验证了LLM在企业数仓场景生成准确SQL的可行性,但暴露了用户选择成本高、Skill间路由困难等5个结构性问题。V2通过统一Skill+确定性两级路由的四层架构(域路由层、知识加载层、标准工作流层、公共服务层)实现智能路由和渐进式知识加载,解决了V1的域间冲突问题。文章重点分享了架构设计思路、知识工程方法论和实践中提炼的设计原则,为类似企业数仓的NL2SQ

阿里技术 489

分解一座冰山:后端系统「AI 知识库体系」建设实践(长文干货)

本文探讨了如何让AI在复杂后端系统中正确行动,指出仅靠代码可读性和文档完整性无法解决关键问题——AI缺乏系统全局认知。作者强调技术方案设计是AI Coding的核心环节,其质量直接影响执行正确性。文章提出需构建结构化知识库,贯穿需求理解、影响分析、方案设计、编码执行等全流程,将分散的系统知识显式化,包括架构、依赖关系、业务约束等,帮助AI获得准确上下文。特别指出业务概念与技术实现的映射、变更红线规则等关键知识,并强调知识库需要持续闭环更新,避免成为过期文档。最终目标是让AI从代码协作者进化为能自主判断的工程

阿里技术 687

阿里开源 skill-up:让 Agent Skill 可评测可回归

摘要: 阿里巴巴开源了Agent Skill评测框架skill-up,旨在解决AI技能开发中的质量验证难题。该框架通过声明式YAML配置支持多引擎测试,提供expect+judge分层判定机制,降低LLM抖动对CI的影响。核心设计包括:1) 声明式评测配置,提升可读性;2) 分层判定策略优化资源消耗;3) 多引擎适配能力;4) 结构化报告输出,支持CI集成。skill-up特别强化了多轮对话测试,可验证复杂交互场景下的技能表现,如危险操作确认流程。项目已开源并应用于阿里内部,帮助开发者确保技能迭代的可靠性和

阿里技术 676

面向复杂业务场景的智能分析 Skills 架构设计与演进实践

本文复盘了一个面向本地生活业务的分析类AI Skill的架构演进过程。面对数十个行业复杂的经营框架和指标体系,团队经历了三次重构:从V1过度工程化的分层解耦架构,到V2采用知识收拢与按需加载,最终在V3实现稳定知识与时效知识的分离。这一过程提炼出六条Skill设计原则:1)知识组织应服务于模型的推理需求而非工程规范;2)按变更频率分层管理知识;3)动态路由实现按需加载;4)写入与读取采用不同粒度;5)保持核心知识文件的轻量化;6)通过分层加载平衡维护效率与token经济性。该案例为处理领域知识密集型AI应用

阿里技术 472

阿里荣膺 ACL 2026 最佳资源论文 | HSCodeComp 揭开智能体「分层规则应用」的能力鸿沟

先从任务本身说起。HS Code(Harmonized System Code,商品名称及编码协调制度)是支撑全球每年约 26 万亿美元贸易的商品"唯一数字身份证"。每一笔跨境货物通关都必须申报 HS Code,它直接决F f f F f定了超过所有跨境商品的关税计算和合规性,跨境商品的编码如果报错,轻则多缴关税,重则触发合规风险和货运延误。如下图1所示,在阿里巴巴跨境电商海关商品编码(HS Code)场景中,该专家级任务需要将商品沿着人类专家编写的规则树逐层向下推导、精确归类到唯一国际通用编码上。

阿里技术 415

从 Coder 到 Designer :电商团队数据研发的 Harness Engineering 实践

本文介绍了AI Data团队在数据研发效率提升方面的实践,重点通过知识工程和Harness Engineering架构设计解决NL2SQL转化中的核心问题。团队构建了语义层基础设施,采用Multi-Agent协作框架,将数据研发经验结构化并形成标准化流程,实现从自然语言到SQL的精准转化。方案通过三层质量保障体系和闭环知识管理机制,确保AI在复杂任务中稳定运行并持续积累经验。目前该方案已在大促场景落地,显著提升了NL2SQL的研发效率和质量。

阿里技术 129

一个小模型意图识别系统的 5 天进化实录|支付宝618

本文摘要: 支付宝618大促中,团队探索了AI在电商优惠场景的两种交互模式:一期基于推荐逻辑的"AI找优惠",二期升级为对话式交互。作者负责意图识别模块,将用户自然语言转化为结构化查询。面对模型选型的时间压力,团队快速评估了Qwen3系列模型,最终基于性能、成本和准确率平衡选择了Qwen3-14B。文章详细记录了从业务需求分析到技术方案落地的完整决策过程,为AI产品化提供了实战参考。

阿里技术 206

为什么 Agent 时代,大家都在做 CLI ?

AI时代的CLI复兴:从人类友好到Agent友好的范式转变 随着AI Agent的崛起,命令行界面(CLI)正经历一场复兴。本文探讨了人机交互从CLI到GUI,再到Agentic CLI的发展历程,指出CLI因其文本输入输出特性、自描述性、Unix哲学组合能力等优势,成为AI Agent操作数字世界的高效入口。文章提出未来产品设计需兼顾人类和Agent需求,分为完全面向人、完全面向Agent和人机协作三层架构,并强调"AI友好"应具备可调用、可理解、可组合、可恢复四大特征。CLI与MCP、SKILL共同构成

阿里技术 168
上一篇: DDD在前端应用中的一些思考
下一篇: 设计模式详解之策略模式
阿里技术
阿里技术 阿里技术官方账号 阿里技术官方账号
博客等级 码龄5年 5210粉丝 280原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值