首页 文章 精选 留言 我的

精选列表

搜索[消息对话],共10000篇文章
优秀的个人博客,低调大师

Codex 多场景自动化生产实战:从“对话工具”到“可交付工作台”

核心结论:Codex 在多场景自动化生产中的真正价值,不在于它能生成多少行代码或写多少篇文案,而在于它能否把“描述任务—规划执行—验证结果—交付产物”这个闭环稳定地跑通。OpenAI 内部和外部团队的实战数据表明,有效的自动化生产依赖三个支柱:可验证的完成标准、确定性与判断力的正确分层、以及生产反馈驱动的持续改进。缺少任何一个,所谓的“自动化”就退化为“需要人工反复纠正的草稿生成器”。本文从税务、工程运维、代码安全、办公协作四个真实场景切入,拆解 Codex 在多场景生产中跑通闭环的关键机制与避坑要点。

优秀的个人博客,低调大师

团队 Agent 记忆服务怎么设计:从对话存档到可治理的工程上下文

Agent 每次会话都“重新开始”,通常不是模型上下文不够长,而是团队没有把事实、决策、过程和偏好沉淀成可检索、可更新、可撤销的记忆。本文以近期腾讯云开发者社区推荐的团队版 Agent Memory 为背景,设计一套面向研发团队的记忆服务:区分记忆类型,建立写入门禁,通过混合检索组装上下文,并用租户隔离、版本和过期策略控制风险。

优秀的个人博客,低调大师

对话面试官:动态代理是如何实现的?JDK Proxy 和 CGLib 有啥区别?

2 --> 知识解读 动态代理的常用实现方式是反射。反射机制是指程序在运行期间可以访问、检测和修改其本身状态或行为的一种能力,使用反射我们可以调用任意一个类对象,以及类对象中包含的属性及方法。 但动态代理不止有反射一种实现方式,例如,动态代理可以通过 CGLib 来实现,而 CGLib 是基于 ASM(一个 Java 字节码操作框架)而非反射实现的。简单来说,动态代理是一种行为方式,而反射或 ASM 只是它的一种实现手段而已。 JDK Proxy 和 CGLib 的区别主要体现在以下几个方面: JDK Proxy 是 Java 语言自带的功能,无需通过加载第三方类实现; Java 对 JDK Proxy 提供了稳定的支持,并且会持续地升级和更新 JDK Proxy,例如 Java 8 版本中的 JDK Proxy 性能相比于之前版本提升了很多; JDK Proxy 是通过拦截器加反射的方式实现的; JDK Proxy 只能代理继承接口的类; JDK Proxy 实现和调用起来比较简单; CGLib 是第三方提供的工具,基于 ASM 实现的,性能比较高; CGLib 无需通过接口来实现,它是通过实现子类的方式来完成调用的。 重点分析 很多人经常会把反射和动态代理划为等号,但从严格意义上来说,这种想法是不正确的,真正能搞懂它们之间的关系,也体现了你扎实 Java 的基本功。和这个问题相关的知识点,还有以下几个: 你对 JDK Proxy 和 CGLib 的掌握程度。 Lombok 是通过反射实现的吗? 动态代理和静态代理有什么区别? 动态代理的使用场景有哪些? Spring 中的动态代理是通过什么方式实现的? 知识扩展 1.JDK Proxy 和 CGLib 的使用及代码分析 JDK Proxy 动态代理实现 JDK Proxy 动态代理的实现无需引用第三方类,只需要实现 InvocationHandler 接口,重写 invoke() 方法即可,整个实现代码如下所示: import java.lang.reflect.InvocationHandler; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Proxy; /** * JDK Proxy 相关示例 */ public class ProxyExample { static interface Car { void running(); } static class Bus implements Car { @Override public void running() { System.out.println("The bus is running."); } } static class Taxi implements Car { @Override public void running() { System.out.println("The taxi is running."); } } /** * JDK Proxy */ static class JDKProxy implements InvocationHandler { private Object target; // 代理对象 // 获取到代理对象 public Object getInstance(Object target) { this.target = target; // 取得代理对象 return Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), this); } /** * 执行代理方法 * @param proxy 代理对象 * @param method 代理方法 * @param args 方法的参数 * @return * @throws InvocationTargetException * @throws IllegalAccessException */ @Override public Object invoke(Object proxy, Method method, Object[] args) throws InvocationTargetException, IllegalAccessException { System.out.println("动态代理之前的业务处理."); Object result = method.invoke(target, args); // 执行调用方法(此方法执行前后,可以进行相关业务处理) return result; } } public static void main(String[] args) { // 执行 JDK Proxy JDKProxy jdkProxy = new JDKProxy(); Car carInstance = (Car) jdkProxy.getInstance(new Taxi()); carInstance.running(); 以上程序的执行结果是: 动态代理之前的业务处理. The taxi is running. 可以看出 JDK Proxy 实现动态代理的核心是实现 Invocation 接口,我们查看 Invocation 的源码,会发现里面其实只有一个 invoke() 方法,源码如下: public interface InvocationHandler { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable; } 这是因为在动态代理中有一个重要的角色也就是代理器,它用于统一管理被代理的对象,显然 InvocationHandler 就是这个代理器,而 invoke() 方法则是触发代理的执行方法,我们通过实现 Invocation 接口来拥有动态代理的能力。 CGLib 的实现 在使用 CGLib 之前,我们要先在项目中引入 CGLib 框架,在 pom.xml 中添加如下配置: <!-- https://mvnrepository.com/artifact/cglib/cglib --> <dependency> <groupId>cglib</groupId> <artifactId>cglib</artifactId> <version>3.3.0</version> </dependency> CGLib 实现代码如下: package com.lagou.interview; import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; import java.lang.reflect.Method; public class CGLibExample { static class Car { public void running() { System.out.println("The car is running."); } } /** * CGLib 代理类 */ static class CGLibProxy implements MethodInterceptor { private Object target; // 代理对象 public Object getInstance(Object target) { this.target = target; Enhancer enhancer = new Enhancer(); // 设置父类为实例类 enhancer.setSuperclass(this.target.getClass()); // 回调方法 enhancer.setCallback(this); // 创建代理对象 return enhancer.create(); } @Override public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { System.out.println("方法调用前业务处理."); Object result = methodProxy.invokeSuper(o, objects); // 执行方法调用 return result; } } // 执行 CGLib 的方法调用 public static void main(String[] args) { // 创建 CGLib 代理类 CGLibProxy proxy = new CGLibProxy(); // 初始化代理对象 Car car = (Car) proxy.getInstance(new Car()); // 执行方法 car.running(); 以上程序的执行结果是: 方法调用前业务处理. The car is running. 可以看出 CGLib 和 JDK Proxy 的实现代码比较类似,都是通过实现代理器的接口,再调用某一个方法完成动态代理的,唯一不同的是,CGLib 在初始化被代理类时,是通过 Enhancer 对象把代理对象设置为被代理类的子类来实现动态代理的。因此被代理类不能被关键字 final 修饰,如果被 final 修饰,再使用 Enhancer 设置父类时会报错,动态代理的构建会失败。 2.Lombok 原理分析 在开始讲 Lombok 的原理之前,我们先来简单地介绍一下 Lombok,它属于 Java 的一个热门工具类,使用它可以有效地解决代码工程中那些繁琐又重复的代码,如 Setter、Getter、toString、equals 和 hashCode 等等,像这种方法都可以使用 Lombok 注解来完成。 例如,我们使用比较多的 Setter 和 Getter 方法,在没有使用 Lombok 之前,代码是这样的: public class Person { private Integer id; private String name; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } 在使用 Lombok 之后,代码是这样的: @Data public class Person { private Integer id; private String name; } 可以看出 Lombok 让代码简单和优雅了很多。 Tips:如果在项目中使用了 Lombok 的 Getter 和 Setter 注解,那么想要在编码阶段成功调用对象的 set 或 get 方法,我们需要在 IDE 中安装 Lombok 插件才行,比如 Idea 的插件如下图所示: 接下来讲讲 Lombok 的原理。 Lombok 的实现和反射没有任何关系,前面我们说了反射是程序在运行期的一种自省(introspect)能力,而 Lombok 的实现是在编译期就完成了,为什么这么说呢? 回到我们刚才 Setter/Getter 的方法,当我们打开 Person 的编译类就会发现,使用了 Lombok 的 @Data 注解后的源码竟然是这样的: 可以看出 Lombok 是在编译期就为我们生成了对应的字节码。 其实 Lombok 是基于 Java 1.6 实现的 JSR 269: Pluggable Annotation Processing API 来实现的,也就是通过编译期自定义注解处理器来实现的,它的执行步骤如下: 从流程图中可以看出,在编译期阶段,当 Java 源码被抽象成语法树(AST)之后,Lombok 会根据自己的注解处理器动态修改 AST,增加新的代码(节点),在这一切执行之后就生成了最终的字节码(.class)文件,这就是 Lombok 的执行原理。 3.动态代理知识点扩充 动态代理和静态代理的区别?静态代理其实就是事先写好代理类,可以手工编写也可以使用工具生成,但它的缺点是每个业务类都要对应一个代理类,特别不灵活也不方便,于是就有了动态代理。 动态代理的常见使用场景有 RPC 框架的封装、AOP(面向切面编程)的实现、JDBC 的连接等。 Spring 框架中同时使用了两种动态代理 JDK Proxy 和 CGLib,当 Bean 实现了接口时,Spring 就会使用 JDK Proxy,在没有实现接口时就会使用 CGLib,我们也可以在配置中指定强制使用 CGLib,只需要在 Spring 配置中添加 <aop:aspectj-autoproxy proxy-target-class=“true”/> 即可。 总结 本文介绍了 JDK Proxy 和 CGLib 的区别,JDK Proxy 是 Java 语言内置的动态代理,必须要通过实现接口的方式来代理相关的类,而 CGLib 是第三方提供的基于 ASM 的高效动态代理类,它通过实现被代理类的子类来实现动态代理的功能,因此被代理的类不能使用 final 修饰。 除了 JDK Proxy 和 CGLib 之外,我们还讲了 Java 中常用的工具类 Lombok 的实现原理,它其实和反射是没有任何关系的;最后讲了动态代理的使用场景以及 Spring 中动态代理的实现方式,希望本文可以帮助到你。

优秀的个人博客,低调大师

浪迹天涯的骨灰级开源爱好者——对话阿里云 MVP吴晟

云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 简介: 吴晟是我见过最“浪”的程序员,喜欢买买买,热爱公路自驾。格子间拘不住他向往自由的灵魂,七大洲才能承载他追逐梦想的印记。作为SkyWalking创始人的吴晟,远不止诗与远方齐飞的魅力。 以下为吴晟的个人专访,推荐阅读(约4分钟)。 不妨做个自得其乐的俗人 SkyWalking 给我带来最大的收获是成就感和知名度。我想每一个项目的深度参与者都会有不同的收获,不但可以磨练自己的技术,也会对代码和产品更加执着,苛求细节、强调逻辑,业务能力方面也会有较大的提升。首先自己的社交圈扩大并提高,国内外技术圈、媒体、其他领域专家等都有机会接触到。其次,沟通能力甚至英语能力也会有长进,彻底从技术宅,变成一个擅长沟通、演讲(亦或忽悠)的产品经理兼售前兼自动化测试兼写手。在各方面都得到训练后,最终变得愈发自信和优秀。 开源的成就,也给了我实现爱好的经济基础。我是一个生活比较随性的人,喜欢车喜欢表,喜欢公路自驾。2012年至今,护照上已经记录下美国、新加坡、韩国、意大利、法国、瑞士、乌克兰、泰国、印度等等。自驾自然离不开车,买车也是我的一大乐趣,这10年来,从最入门的高尔夫开始,我陆陆续续买了6台车,现在有一台GLE 450 Coupe和X3。车和程序很相似——给定输入,一定会有标准输出。也是圆我自己大学没有选择车辆工程,而是软件工程的一个情结吧。目前的小目标是911 Turbo S和GLE AMG 63S。 除了满足我对技术的诉求,开源的全球会议也促成了各地旅游的好机会。对我来说,一个月内出现在4个不同场合,做不同受众的演讲是家常便饭;一星期需要出现在两个洲三个国家的Keynote上的生活也习以为常。不能说这种生活很轻松,我也时长在半夜写着文档,在10个小时的国际航班上构思会议内容,但这是符合我自己预期的方式。可以在会议的间隙,走遍欧洲城市的大街小巷,感受异国风情。在自己和家人的护照上盖满各国的入境章,是很有意思的事情。大家以同样的速度度过时间,而我们拥有更多记忆。 技术地位的确可以改变收入,哈哈,原谅我是个俗人。不过更重要的还是收获了志同道合的团队和技术宅们,也有了更好的公司和团队支持自己,这种财富是不可替代的。 初识架构,崭露头角 我正式的工作和架构历程开始于研究生在读期间,在当时的微软MSC和微软MVP指导下,学习和编写一家保险公司的核心系统架构,包括整套的MVC、ORM框架、分布式通讯架构、以及自动化测试和性能测试等。2007-2009两年的实习工作,为我对整套分布式系统的理解奠定了良好的基础,也深深体会到了分布式对于系统的助力和挑战。 毕业之后,我先后在大唐软件和亚信中国,参与电信运行上的系统建设,期间一直在架构团队工作。在2011年,我参与到中国联通首个全国集中系统的建设中——一个8厂商合作的巨型SOA架构的分布式系统。首次引入分布式服务(以Web Service为技术代表,当时还没有微服务的概念)和SOA的系统架构,想要解决多厂商多应用间的问题定位、效率短板分析出现定位难的问题。这个项目为我之后设计ShardingSphere项目原型,和创立SkyWalking项目积累了重要的经验。 2014年,我以培训为目的开始建立SkyWalking项目,并先后在OneAPM及现在的北美Service Mesh公司tetrate.io,从不同的角度带领SkyWalking项目和社区。在大家的努力下,SkyWalking得以从Apache孵化器顺利毕业,成为顶级项目,并走向全球。 平步青云,共建开源生态 我与开源的结缘说来已久。在2014年,国内的开源市场可谓一片空白,顶级项目绝大多数来自国外,国内除了几个大厂背书的项目,很少有人涉足开源。项目从起步到发展,完全是摸着石头过河,全靠我们自己一步步的探索。从SkyWalking到CNCF基金会的OpenTracing项目,再到大名鼎鼎的Zipkin社区,最后深深根植于Apache基金会。没有任何前车之鉴,全靠大家齐心协力和多名社区老手的鼎力相助,他们开放和共享的工作态度与方式,给了我很深的印象。比如Google Dapper论文第一作者--Benjamin H. Sigelman ,Zipkin社区Leader--Adrian Cole,还有Apache Mentor,Mick Semb Wever和姜宁,以及其他无数国外的社区朋友。他们让我将一个中国的个人项目带进Apache孵化器,并帮助我学习建设社区的思路、方法,使其得以成功毕业并成为顶级项目。 孵化器是Apache为了新项目能够顺利创建而专门设立的工程,主要职责包括:过滤关于创建新项目或子项目的意向书;帮助创建项目及其所需的基础设施;监督和指导孵化的社区,从而实现开放的优秀文化氛围;评估孵化项目的成熟度,或者将其提升为官方项目/子项目的状态,反之若结论是失败的,则通过退役来解决。但孵化器不会根据技术问题执行过滤,因为基金会尊重和建议各种技术方法,甚至会允许在功能上重叠的项目之间进行内部的相互竞争。 而我本人也用了2年成为Apache基金会成员,现在兼任项目VP、孵化器PMC成员,从统计学来讲算是很快的速度,一般需要4-5年甚至更久时间的投入。在Apache基金会,一般会根据在整个基金会内的贡献(代码和非代码),得到认可后内部member提名、推举、和最终投票。每年只有全员大会一次机会认证。在其他基金会根据基金会性质会有所差异。 今天,我们的项目几乎覆盖了国内的所有大厂,以阿里云为首的各大共有云、私有云厂商,也都提供了相应的服务。项目被集成到大量的商业产品,甚至招标书中,已经成为事实标准。大量的基础社区反馈、国外社区的模型和理论共享、用户压力测试回馈,才造就了SkyWalking现在的设计和性能。所以可以说,没有开源社区这个有机整体的强大助力,就不会有今天 SkyWalking 的核心和高性能。 追逐开源有利可图 首先,开源不应该被神化。熟悉我的人,都知道我喜欢用『各怀鬼胎』来形容开源社区。很多人喜欢将开源定义为情怀,其实我很反对这样的想法。开源,可以是一个爱好,可以是一种技术追求,可以是一项工作,也可以是一种合作模式,可以是一个学习平台,更可以是一种盈利手段。无论企业还是个人,对开源的追逐都可以带来利益。 倘若公司内员工对知名开源项目有优秀贡献,会对公司自身的市场营销和技术品牌形成明显的正向反馈。而开源爱好者平等包容的开放心态,无论面对客户需求还是跨实体合作,都更具竞争力。开源公司自身的招聘吸引力、产品化能力优势亦然。对于个人来说,拥有开源项目经历,对个人能力和职业素养都有显著提升。2018年的开源职业报告显示,87%的雇主希望招聘到具备开源能力的员工,而55%的开源业内人士表示他们可以轻松地找到一份新工作。 请不要把道德高尚和开源扯上关系,他们没有什么必然的联系。如果你喜欢技术、勇于挑战,那么开源社区这个公开、开放而又竞争惨烈的地方,是一个好的选择。闭源或开源之间没有对与错,商业开源和KPI开源之间没有好与坏,大家都是各取所需、共同发展。至少,全球的开源风极大地提高了中国的软件水平。 吴晟的碎片化时间很多都用来思考和讨论方案,自由的工作时间背后是无限强大的自律心,支撑这位浪迹天涯的阿里云 MVP,更加笃定和从容。 我要成为阿里云 MVP 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册