设计模式详解之策略模式

作者:刘文慧

策略模式是一种应用广泛的行为型模式,核心思想是对算法进行封装,委派给不同对象来管理,本文将着眼于策略模式进行分享。

一、概述

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

大家熟知的23种设计模式,可以分为创建型模式、结构型模式和行为型模式三大类。其中,行为型模式可用于描述程序中多个类和多个对象如何协作完成复杂的任务,涉及不同对象间的职责分配、算法的抽象化。策略模式是一种应用广泛的行为型模式,本文将着眼于策略模式进行学习分享。

二、基本概念

策略模式的核心思想是对算法进行封装,委派给不同对象来管理。这样,我们就可以定义一系列算法,将每个算法封装到具有公共接口的一系列具体策略类中,从而使它们可以灵活替换,并让算法可以在不影响到客户端的情况下发生变化。同时,策略模式仅仅封装算法(包括添加、删除),但其并不决定在何时使用何种算法,算法的选择由客户端来决定。

比如,我们旅游时可以选择的出行策略有很多种:自行车、汽车、火车、飞机,每种出行策略都有各自的使用方法,只要能到目的地,我们可以随意更换各种策略。再比如我们去逛商场,商场会有很多促销活动:满减、返利等,这些促销方式本质上都是一些算法,而算法本身也是一种策略,随时都可以互相替换,针对同一件商品,今天满500减50、明天满300返100购物券,这些策略之间同样可以互换。

那么,我们应该如何使用策略模式呢?下面将从结构和使用步骤两个层面,对策略模式进行概念性介绍。

2.1 结构

策略模式包含三种类,分别是抽象策略类、具体策略类、环境类,它们各自负责完成特定任务,并且相互之间存在紧密的联系。

2.2 使用

有了上述的基本概念,我们将策略模式的使用步骤概括为:

  • step1:创建抽象策略类,为具体策略定义好一个公共接口;

  • step2:创建具体策略类,其通过接口来实现抽象策略类,同时封装了具体的算法;

  • step3:创建环境类,持有一个抽象策略类的引用,提供给客户端调用。

三、使用示例

除了双11购物狂欢节,每年都会打造很多其他的促销活动。试想一下,如果每种大促活动都使用一种促销模式,未免太过枯燥,于用户、商家、平台而言都不友好。因此,为了提升用户购买体验、突出商家营销特点,需要面向不同大促活动使用不同的策略进行促销。这里以促销策略为例,简单分析策略模式如何使用。

3.1 代码实现

//step1:定义抽象策略角色(Strategy):所有促销活动的共同接口
public interface Strategy {  
    void show();
}
​
//step2:定义具体策略角色(Concrete Strategy):不同类型的具体促销策略
//618大促活动 A
public class ConcreteStrategyA implements Strategy {
    @Override
    public void show() {
        System.out.println("618大促");
    }
}
​
//99大促活动 B
public class ConcreteStrategyB implements Strategy {
    @Override
    public void show() {
        System.out.println("99大促");
    }
}
​
//双11大促活动 C
public class ConcreteStrategyC implements Strategy {
    @Override
    public void show() {
        System.out.println("双11大促");
    }
}
​
//step3:定义环境角色(Context):把促销活动推送给用户,这里可理解为淘宝平台
public class Context{
    //持有抽象策略的引用
    private Strategy myStrategy;
    //生成构造方法,让平台根据传入的参数(type)选择促销活动
    public Context(Strategy strategyType) {
        this.myStrategy = strategyType;
    }
    //向用户展示促销活动
    public void taoPlatformShow(String time) {
        System.out.println(time + "的促销策略是:");
        myStrategy.show();
    }
}
​
//step4:客户端调用,需事先明确所有每种策略类如何使用
public class StrategyPattern{
  public static void main(String[] args){
        Context_TaoPlatform context;
    
        String time1 = "9月";
        Strategy strategyB = new ConcreteStrategyB();
        context = new Context(strategyB);
        context.taoPlatformShow(time1);
    
        String time2 = "11月";
        Strategy strategyC = new ConcreteStrategyC();
        context = new Context(strategyC);
        context.taoPlatformShow(time2);
    
        String time3 = "6月";
        Strategy strategyA = new ConcreteStrategyA();
        context = new Context(strategyA);
        context.taoPlatformShow(time3);
  }   
}

3.2 结果输出

9月的促销策略是:
99大促
11月的促销策略是:
双11大促
6月的促销策略是:
618大促

3.3 UML图

3.4 与简单工厂模式的区别

从上面的代码示例及类图可以看出来,策略模式和上一篇文章中介绍的简单工厂模式很像,两者主要区别在于Context类和工厂类。为了方便对比,我们把这两个类的代码单独拎出来看看:

public class Context_TaoPlatform{
    //持有抽象策略的引用
    private Strategy myStrategy;
    //生成构造方法,让平台根据传入的参数(type)选择促销活动
    public TaoPlatform(Strategy strategyType) {
        this.myStrategy = strategyType;
    }
    //向用户展示促销活动
    public void taoPlatformShow(String time) {
        System.out.println(time + "的促销策略是:");
        myStrategy.show();
    }
}

public class Factory{
    public static Shirt exhibit(String ShirtName){
        switch(ShirtName){
            case "女款衬衫":
                return new WomenShirt();
            case "男款衬衫":
                return new MenShirt();
            default:
                return null;
        }
    }
}

首先看一下接收参数:工厂类Factory中的exhibit()方法接收字符串,返回一个Shirt对象;环境类Context_TaoPlatform初始化时需要接收一个Strategy对象。也就是说:工厂类中是根据接收的条件创建一个相应的对象,而Context类接收的是一个对象,可以调用方法去执行此对象的方法。

举个例子:笔有很多种,假设有一个工厂专门负责生产不同用途的笔。

工厂模式:根据用户给出的目的来生产不同用途的笔,如:要写毛笔字就生产毛笔、要写钢笔字就生产钢笔。即根据用户给出的某种属性,生产能做出相应行为的一种对象返回给用户,重点在于创建何种对象。

策略模式:用工厂生产的笔去出做对应的行为,如:用毛笔写毛笔字、用钢笔写钢笔字。即根据用户给出的某种对象,执行相应的方法,重点在于选择何种行为。

四、JDK源码赏析

这里以Comparator比较器为例,通过分析其源码实现来深入理策略模式。

在JDK中,我们调用数组工具类Arrays的一个排序方法sort()时,可以使用默认的排序规则(升序),也可以自定义一种排序的规则,即自定义实现升序或降序的排序。源码如下:

public class Arrays{
    public static <T> void sort(T[] a, Comparator<? super T> c) {
        if (c == null) {
            //若没有传入Comparator接口的实现类对象,调用默认的升序排序方法
            sort(a);
        } else {
            if (LegacyMergeSort.userRequested)
                //jdk5及之前的传统归并排序,新版本中LegacyMergeSort.userRequested默认false
                legacyMergeSort(a, c);
            else
                //改进后的归并排序
                TimSort.sort(a, 0, a.length, c, null, 0, 0);
        }
    }
}

此时我们需要传入两个参数:一个是待排序的数组,另一个则是Comparator接口的实现类对象。其中,Comparator接口是一种函数式接口,该接口中定义了一个抽象方法int compare(T o1, T o2),用于定义具体的排序规则。这里Comparator接口就是策略模式中的抽象策略接口,它定义了一个排序算法,而具体策略(具体的排序算法)将由用户来定义,那么Arrays就是一个环境类,sort() 方法可以传入一个策略c ,让Arrays根据这个策略进行排序任务。

public class demo {
    public static void main(String[] args) {
​
        Integer[] data = {12, 2, 3, 2, 4, 5, 1};
        // 实现降序排序
        Arrays.sort(data, new Comparator<Integer>() {
             // 排序策略 降序
            public int compare(Integer o1, Integer o2) {
                return o2 - o1;
            }
        });
        System.out.println(Arrays.toString(data)); //[12, 5, 4, 3, 2, 2, 1]
    }
}

在上面这个测试类中,我们在调用Arrays.sort()方法时,第二个参数传递的是Comparator接口的子实现类对象。由此可见,Comparator充当的是抽象策略角色,而具体的子实现类充当的是具体策略角色,环境角色类 Arrays应该持有抽象策略的引用来调用。那么,Arrays.sort()方法究竟有没有使用Comparator子实现类中的compare()方法?下面再看看TimSort.sort()方法,源码如下:

class TimSort<T> {
    static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,
                         T[] work, int workBase, int workLen) {
        assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;
​
        int nRemaining  = hi - lo;
        if (nRemaining < 2)
            return;  // Arrays of size 0 and 1 are always sorted
​
        // If array is small, do a "mini-TimSort" with no merges
        if (nRemaining < MIN_MERGE) {
            int initRunLen = countRunAndMakeAscending(a, lo, hi, c);
            binarySort(a, lo, hi, lo + initRunLen, c);
            return;
        }
        ...
    }   
        
    private static <T> int countRunAndMakeAscending(T[] a, int lo, int hi,Comparator<? super T> c) {
        assert lo < hi;
        int runHi = lo + 1;
        if (runHi == hi)
            return 1;
​
        // Find end of run, and reverse range if descending
        if (c.compare(a[runHi++], a[lo]) < 0) { // Descending
            while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) < 0)
                runHi++;
            reverseRange(a, lo, runHi);
        } else {                              // Ascending
            while (runHi < hi && c.compare(a[runHi], a[runHi - 1]) >= 0)
                runHi++;
        }
        return runHi - lo;
    }
}

上面的代码最后会执行到countRunAndMakeAscending()方法中,在执行判断语句时调用了compare()方法。那么如果只用了compare()方法,在调用Arrays.sort()方法时只要传具体compare()重写方法的类对象。

五、优缺点及适用场景

5.1 优点

  • 具体策略类之间可自由切换,由于具体策略类都实现同一个抽象策略接口,所以它们之间可以自由切换。

  • 支持“开闭原则”,扩展增加一个新策略时只需添加一个具体策略类即可,基本不需要改变原有的代码。

  • 避免使用多重条件选择语句(if else),充分体现面向对象设计思想。

5.2 缺点

  • 客户端必须知道所有的具体策略类,并理解不同具体策略的区别、自行决定使用哪一个策略类。

  • 策略模式将产生很多具体策略类,在一定程度上增加了系统中类的个数(可通过使用享元模式在一定程度上减少对象数量)。

5.3 适用场景

  • 一个系统需要动态地在几种算法中选择一种时,可将每个算法封装到具体策略类中。

  • 一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现,可将每个条件分支移入它们各自的策略类中以代替这些条件语句,就能避免使用难以维护的多重条件选择语句,并体现面向对象涉及的概念。

  • 系统中各算法彼此完全独立,且要求对客户隐藏具体算法的实现细节,提高算法的保密性与安全性。

  • 多个类只区别在表现行为不同,可以使用策略模式,在运行时动态选择具体要执行的行为。

六、总结

策略模式是一个比较容易理解和使用的设计模式,它仅封装算法,方便新算法插入系统中、老算法从系统中退休。本文在分析策略模式的缺点时提到,策略模式并不决定在何时使用何种算法,算法选择由客户端来决定,虽然这在一定程度上提高了系统的灵活性,但客户端需要理解所有具体策略类之间的区别,以便选择合适的算法,增加了客户端的使用难度。

策略模式和工厂模式有一定相似之处,在于它们的模式结构,因此有时候会让人混淆不清。实际上,这两者之间存在较多差异:工厂模式是创建型模式,作用是创建对象,它关注对象如何创建,主要解决的是资源的统一分发,将对象的创建完全独立出来,让对象的创建和具体的使用客户无关;策略模式是行为型模式,作用是让一个对象在许多行为中选择一种行为,它关注行为如何封装,通过定义策略族来实现策略的灵活切换与扩展,并让策略的变化独立于使用策略的客户。

另外,很多场景下策略模式和工厂模式可以结合使用,共同发挥优势起到相辅相成的作用。比如,策略模式的缺点之一是用户必须清楚所有的具体策略算法,这样具体策略难免暴露出去,并且要由上层模块初始化,这与迪米特法则相悖(最少知识原则),而上层模块和底层模之间的解耦,可以让工厂模式来完成。两者结合之后,对于上层模块而言不需要知道每种具体策略,只要通过Context就可以实现策略模式。

相关推荐

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

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

阿里技术 272

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

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

阿里技术 110

高分智能体为何反而更脆弱?阿里 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进入自我迭代新阶段。

阿里技术 405

清华×阿里 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 将反馈、设计和生产验证组织成一个可以持续运行的闭环,把专家经验之外的结构维度纳入搜索,也把一次性能突破沉淀为下一次优化的系统能力。

阿里技术 190

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

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

阿里技术 158

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

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

阿里技术 958

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

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

阿里技术 268

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

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

阿里技术 277

垂类业务如何落地生产级 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高效迭代与生产落地。

阿里技术 442

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 的结构规范、触发机制、作用域优先级,以及最佳实践。(文章内容基于作者个人技术实践与独立思考,旨在分享经验,仅代表个人观点。

阿里技术 321

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

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

阿里技术 370

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 负责。

阿里技术 362

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从代码协作者进化为能自主判断的工程

阿里技术 693

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

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

阿里技术 677

面向复杂业务场景的智能分析 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共同构成

阿里技术 169
上一篇: 设计模式详解之工厂模式
下一篇: ICASSP 2023 | 深度窄带网络消除实时语音通信中的干扰音
阿里技术
阿里技术 阿里技术官方账号 阿里技术官方账号
博客等级 码龄5年 5210粉丝 280原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值