Posts

微服务 Spring Cloud Spring Cloud Alibaba

🔍索引 多智能体 Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies 代码生成 代码生成是指通过机器学习模型生成代码的过程，是自然语言处理和程序生成的结合。代码生成技术在软件开发、自动化测试、代码补全等领域有着广泛的应用。 MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework Paper2Code: Automating Code Generation from Scientific Papers in Machine Learning DocAgent: A Multi-Agent System for Automated Code Documentation Generation 代码生成评估指标 Evaluating Large Language Models Trained on Code

🚏 导论 设计模式是软件开发中解决常见问题的最佳实践，它们凝聚了多年的工程经验与智慧，是提升代码质量、可维护性和灵活性的关键工具。设计模式通过提供一套通用的解决方案，使得开发人员能够应对不同的需求和挑战，而不必从零开始设计系统架构。 在这部分内容中，我将通过学习经典的《大话设计模式》一书，深入理解和探讨23种设计模式。从实际应用的角度出发，我们不仅关注每种模式的定义和结构，更会探索它们在现实世界中的应用场景。 💻 代码 Java代码实现 🔍 索引 设计模式的七大原则 单一职责原则(Single Responsibility Principle) 开放-封闭原则(Open Closed Principle) 依赖倒置原则(Dependency Inversion Principle) 里氏替换原则(Liskov Substitution Principle) 接口隔离原则(Interface Segregation Principle) 迪米特法则(Law of Demeter) 合成复用原则(Composite Reuse Principle) 设计模式的三大类 创建性(Creational Pattern) 抽象工厂模式(Abstract Factory Pattern) 建造者模式(Builder Pattern) 工厂方法模式(Factory Method Pattern) 原型模式(Prototype Pattern) 单例模式(Singleton Pattern) 结构性(Structural Pattern) 适配器模式(Adapter Pattern) 桥接模式(Bridge Pattern) 组合模式(Composite Pattern) 装饰模式(Decorator Pattern) 外观模式(Facade Pattern) 享元模式(Flyweight Pattern) 代理模式(Proxy Pattern) 行为型(Behavioral Pattern) 观察者模式(Observer Pattern) 模板模式(Template Pattern) 命令模式(Command Pattern) 状态模式(State Pattern) 职责链模式(Chain of Responsibility Pattern) 解释器模式(Interpreter Pattern) 中介者模式(Mediator Pattern) 访问者模式(Visitor Pattern) 策略模式(Strategy Pattern) 备忘录模式(Memento Pattern) 迭代器模式(Iterator Pattern)

基本信息 标题: Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies 作者: Han Zhou（通讯作者）、Ruoxi Sun、Hamid Palangi、Shariq Iqbal、Ivan Vulić、Anna Korhonen和Sercan Ö. Arık。 作者单位: Google和剑桥大学 期刊/会议: ArXiv 发表年份: 2025.02.04 DOI: 2502.02533 开源地址: Github 关键词: Multi-Agent System, Large Language Models 研究问题 (Research Questions) 大语言模型，作为多个相互交互协作的智能体，可以解决复杂任务。这些智能体通过声明其功能的提示词以及协调智能体间交互的拓扑结构进行编程。本文所研究的主要问题是优化多智能体系统中的提示词以及智能体的拓扑结构。 研究背景 (Background) 尽管最近的研究探讨了自动化智能体设计各个方面，但在理解哪些因素对改进MAS性能最为关键方面仍存在差距。例如，DSPy自动化了设计示例以改进提示编程的过程。J Li(More agents is all you need作者)提出通过扩大多数投票中的代理数量来优化MAS。ADAS通过基于LLM的元代理编程代码表达的新拓扑。AFlow在预定义操作集中使用蒙特卡洛树搜索来寻找更好的拓扑。然而，包括提示词和拓扑在内的多个设计空间之间的相互作用仍然不明确。 核心贡献 (Key Contributions) 深入分析了影响基于LLM的MAS性能的设计因素，强调了prompt的重要性，并确定了有影响力的拓扑结构。 提出了一种名为Mass的新型多阶段优化器，通过在具有影响力的搜索空间中交错优化prompt和拓扑结构来自动化MAS设计。 大量数据在各种评估基准上显示出显著的性能提升，为构建有效的未来多智能体系统提供了指导。 设计多智能体系统（Designing Multi-Agent Systems） 作者认为MAS的设计可以分为两个层级：块级设计(Block-level)和工作流编排(Workflow-level orchestration)。对于块级，目标是设计单个智能体，通过更好的提示词设计最好的提示词来表现出特定的角色。对于工作流编排，它的优化涉及要包含智能体的类型和数量，以及如何以最有效的方式编排他们，这被称为拓扑优化。 $\mathcal{W}^{*}(a)=\arg\max\mathbb{E}_{(x,y)\sim\mathcal{D}}[f(\mathcal{W}(a)(x)),y]$ 块级：智能体的提示词设计（Block-level: Prompt Design for Agents） 对于块级，对下游任务影响最主要的是prompt，它定义了智能体的角色（例如，“You are an expert in reflecting on errors…”），提供额外的指令来塑造其行为（例如，“You should think step by step…”）以及可选地包含少量示例（zero-shot/one-shot/few-shot）来指导智能体的回复。比如，一种SOAT提示词优化器同时搜索指令和少量示例，其中示例是从模型自身在验证集上的正确预测中引导出来的，基于验证指标。基于这些示例，提示词优化器会为指令提出一些候选方案，并提供数据集摘要或各种提示词以提高候选方案的多样性。然后指令和示例会被联合优化。...

🔗 Spring官方介绍 [⚠️Spring官方对Spring Cloud Alibaba的更新不及时] 🔗 Spring Cloud Alibaba官网 📝 代码记录 Nacos（服务注册与发现） Nacos(Dynamic Naming and Configuration Service, Nacos)，一个易于构建 Al Agent 应用的动态服务发现、配置管理和AI智能体管理平台。 Nacos = Eureka + Config + Bus = Spring Cloud Consul Nacos官网 组件名 语言 CAP 服务健康检查 对外暴露接口 Spring Cloud集成 Eureka Java AP 可配支持 HTTP 已集成 Consul Go CP 支持 HTTP/DNS 已集成 Zookeeper Java CP 支持 客户端 已集成 Nacos Java AP 支持 客户端 已集成 Nacos 在阿里巴巴内部有超过 10 万的实例运行，已经过了类似双十一等各种大型流量的考验，Nacos默认是AP模式， 但也可以调整切换为CP，一般用默认AP即可。 下载与安装...

📝 代码记录 Consul（服务注册与发现 + 分布式配置管理） 拥有服务治理功能，实现微服务之间的动态注册与发现 ❌不在使用Eureka：1. 停更进维 2. 注册中心独立且和微服务功能解耦 Consul官网 Spring官方介绍 三个注册中心区别 组件名 语言 CAP 服务健康检查 对外暴露接口 Spring Cloud集成 Eureka Java AP 可配支持 HTTP 已集成 Consul Go CP 支持 HTTP/DNS 已集成 Zookeeper Java CP 支持 客户端 已集成 Nacos Java AP 支持 客户端 已集成 CAP 一个分布式系统最多只能同时满足其中的两个属性。 Consistency: 强一致性，每次读取都能获取到最近一次成功写入的数据。 Availablity: 可用性，每次请求都会在有限时间内返回结果，无论结果是否为最新。 Partition tolerance: 分区容错性，系统在遇到网络分区（节点之间无法通信）时仍能继续运作。（必须有） 经典CAP： AP（Eurake）：当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。 CP：当网络分区出现后，为了保证一致性，系统返回错误信息。 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性结论：违背了一致性C的要求，只满足可用性和分区容错，即AP 当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性，Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。结论：违背了可用性A的要求，只满足一致性和分区容错，即CP 使用 ./consul --version # 查看版本号 ....

基本信息 标题: DocAgent: A Multi-Agent System for Automated Code Documentation Generation 作者: Dayu Yang（通讯作者）、Antoine Simoulin、Xin Qian等。 作者单位: Meta AI 期刊/会议: ArXiv 发表年份: 2025.04.11 DOI: 2504.08725 开源地址: Github 关键词: Code Documentation, Multi-Agent System, Large Language Models 研究问题 (Research Questions) 如何自动生成代码文档注释，尤其是处理函数/类中复杂的依赖关系和上下文信息？ 研究背景 (Background) 像现在的方法FIM（Fill in the Middle）和 chat agent可以实现自动化生成文档注释，但还是有一些局限性： 省略了必要的信息（例如，参数或返回值描述）。 它们通常提供最少量的上下文或理由，限制了生成文档注释的价值。 由于LLM的幻觉，会虚构不存在的组件，尤其是规模比较大的项目中。 核心贡献 (Key Contributions) DocAgent，一个多智能体、拓扑结构化的上下文感知文档生成系统。 一个衡量代码文档完整性、实用性和事实一致性的稳健评估框架。 全面实验表明，DocAgent在多个数据集中持续优于最先进的基线。 方法 (Methodology) DocAgent分两个阶段来处理复杂的依赖关系并确保上下文的相关性。 用一个Navigator确定一个最佳的依赖感知的处理顺序 Multi-Agent System系统增量地生成文档注释，利用专门的Agent进行代码分析、信息检索、编写文档注释和验证 Navigator: 感知依赖顺序 生成文档注释需要理解依赖代码之间的关系，然而如果给出所有内容，很容易超出上下文窗口的限制。Navigator模块就是为了解决这个问题，Navigator建立了一个处理顺序，确保处理依赖关系之后才对组件做文档注释，从而实现增量上下文构建。 构建依赖图 首先对整个存储库进行静态分析，解析源文件的抽象语法树（AST，Abstract Syntax Tree），以识别代码组件（函数、方法、类）及其相互关系（函数调用、继承、属性方法和模块导入），用一个有向无环图（DAG， Directed Acyclic Graph）来表示，节点是组件，边是依赖关系。为了实现拓扑排序，用Tarjan算法检测图中的循环，并将其浓缩单个超级节点。...

基本信息 标题: Paper2Code: Automating Code Generation from Scientific Papers in Machine Learning 作者: Minju Seo, Jinheon Baek, Seongyun Lee, Sung Ju Hwang等。 作者单位: KAIST, DeepAuto.ai 期刊/会议: ArXiv 发表年份: 2025 DOI: 2504.17192v2 开源地址: Github 关键词: Large Language Models (LLMs), Code Generation（Machine Learning） 研究背景 (Background) 尽管机器学习研究的迅速增长，但相应的代码实施通常无法实现，这使研究人员重现结果并在先前的工作基础上进行劳动密集型。同时，最近的大型语言模型（LLMS）在了解科学文档并生成高质量代码方面表现出色。 研究问题 (Research Questions) 用agent复现机器学习相关的论文方法与实验 核心贡献 (Key Contributions) 提出从科研论文自动生成代码的框架: PaperCoder ​​三阶段工作流程​​：PaperCoder框架将代码生成任务分解为三个结构化的阶段，规划、分析、编码。 构建基准数据集（包含90篇来自ICML、NeurIPS和ICLR 2024的论文） 在PaperBench基准测试中的优异表现：在新发布的PaperBench基准测试中，PaperCoder表现出色，显著优于其他强基线方法。 方法（Methods） 作者引入了PaperCoder，是一种新颖的框架，用于实现研究仓库（论文复现出来的代码仓库）的生成。作者将工作过程建模为M(R) = C，其中M是模型，R是论文，C是代码。受软件开发方法的启发，作者采用了一种结构化的方法，该方法反映了良好的经验验证的软件工程原则，即：规划-分析-实现的工作流程。为了实现这一目标，作者将过程分解为三个阶段：1）规划（Planing）. 2）分析（Analyzing）. 3）编码（Coding）。每个阶段都利用多智能体方案。更加规范化的定义是C = M (P) = M_code(R, P, A)，其中R是论文，P是规划，A是分析。每个部分的生成遵循：P = M_plan(R), A = M_analysis(R, P) and C = M_code(R, P, A)。完整的流程如下图所示：...

基本信息 标题: PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving 作者: Mihir Parmar、Xin Liu等 作者单位: Google、Arizona State University 期刊/会议: ArXiv 发表年份: 2025 DOI: 2502.16111 开源地址: 🈚️ 关键词: Agent 研究背景与问题 (Background & Questions) 有效的计划是设计在解决复杂现实世界问题的系统的关键组件。传统的用模板化的方式缺乏通用性。 LLM 可以较好的做一些规划任务，比如用 LLM 在自然语言中做规划可以解决一些代码问题。因此作者考虑增强 LLM 生成计划的能力，并证明其在科学和金融领域下游任务的实用性。 核心贡献 (Key Contributions) 总结本文的主要贡献点： PlanGEN，一种新颖的、模型无关的、可扩展的多智能体框架，用于增强LLM的自然规划。 在一些复杂规划和推理的 Benchmarks 上达到了 SOTA 级别。 一种基于约束的验证和基于实例级复杂性的推理算法选择的新方法。 PlanGEN LLM Agents PlanGEN 包括三个 大模型 Agent：Constraint Agent、 Verification Agent 和一个 Selection Agent。每个Agent使用现成的 LLM（如：Gemini, GPT）。...

🚏 导论 代理模式（Proxy Pattern）为其他对象提供一种代理以控制对这个对象的访问。 代理模式的应用场景 远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。 虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。 安全代理，用来控制真实对象访问时的权限。 智能指引，是指当调用真实的对象时，代理处理另外一些事。 🚦 结构 UML类图 classDiagram class Client{ } class Subject{ <<abstract>> +Request() } class RealSubject{ +Request() } class Proxy{ -realSubject: RealSubject +Request() } Client --> Subject Subject <|.. RealSubject Subject <|.. Proxy 代码实现 Subject类，定义了RealSubject和Proxy的公共接口，这样就在任何使用RealSubject的地方都可以使用Proxy public class abstract Subject { public abstract void Request(); } RealSUbject类，定义Proxy所代表的真实实体 public class RealSubject extends Subject { @Override public void Request() { System.out.println("真实的请求"); } } Proxy类，保存一个引用使得代理可以访问实体，并提供一个与Subject相同的接口，这样代理就可以用来代替实体 public class Proxy extends Subject { private RealSubject realSubject; @Override public void Request() { if (realSubject == null) { realSubject = new RealSubject(); } realSubject....