分布式 Multi Agent 安全高可用探索与实践
亦盏
|
Oct 10, 2025
|
在人工智能加速发展的今天，AI Agent 正在成为推动“人工智能+”战略落地的核心引擎。无论是技术趋势还是政策导向，都预示着一场深刻的变革正在发生。
最近，国务院印发《关于深入实施“人工智能+”行动的意见》，明确提出：到2027年，新一代智能终端和智能体普及率将超过70%；2030年突破90%，智能经济将成为我国经济发展的重要增长极；到2035年，全面步入智能经济与智能社会新阶段。
这一系列目标的背后，正是以 AI Agent 为核心的技术体系逐步走向成熟并大规模落地的信号。
OpenAI 创始人 Andrej Karpathy 曾提出一个经典的三段论，用以描述软件编程范式的演进：
这标志着应用开发形态的根本转变：AI Agent 的运行逻辑，越来越多地依赖于模型自身的智能能力。而在这样的背景下，AI Agent 的开发方式也经历了三个阶段的演进：低代码、高代码、零代码。
低代码：快速验证，但局限明显。
低代码平台以“拖拽式画布”为特征，极大降低了入门门槛，在早期概念验证（POC）中发挥了重要作用。但由于其高度抽象，灵活性差、性能受限，难以应对复杂业务场景，通常止步于实验阶段。
高代码：当前主流选择。
基于开发框架编写代码的方式来开发 AI Agent，相比低代码，高代码具备更强的性能、更高的灵活性，在当前模型能力还不是足够智能的情况下，能够平衡好模型的自主性与复杂场景下的业务要求确定性，是目前的主流。
零代码：未来愿景，尚不成熟
零代码希望用户仅通过自然语言就能驱动整个应用构建，完全依赖模型的规划与执行能力。虽然愿景美好，但受限于当前模型的认知边界和稳定性，还无法支撑真实业务的可靠交付。
综合来看，现阶段最可行且可持续的路径，依然是基于框架的高代码开发模式。
随着 Agent 场景日益复杂，开发框架也在不断演进。可以将其划分为三个代际：
Chat Client 模式
这是最原始的形式——输入一句话，模型回答，一问一答的模式。虽然他也支持工具调用和循环执行，但所有逻辑都依赖同一个模型，在相同的提示词和上下文下反复决策，受限于模型当前的能力，难以稳定处理复杂的业务场景，比如错误恢复、并行协作等。
Workflow 框架
这类框架以 LangGraph 为代表，它基于流程编排引擎，将任务拆解为多个节点，支持条件判断、循环、并行等逻辑，很好地解决了传统业务流程 AI 改造的问题，从“聊天式交互”升级到“结构化执行”。
然而这种人工编排的方式也有明显短板：随着业务规模扩大，流程越来越复杂，维护成本指数上升。更大的问题是这种 “静态”编排的架构，无法享受到模型能力不断提升的红利。
Agentic API
大家逐渐意识到，开发 AI Agent 需要面向 Agent 的抽象提供 Agentic API。阿里巴巴的 AgentScope、 Google 的 ADK 都是典型的代表。基于面向 Agent 抽象，让开发者既能享受模型的自主规划与动态决策能力，又能通过结构化设计确保稳定性与可控性。从而能开发出可扩展、可维护与可持续进化的 AI Agent。
在上个月初，阿里云官方发布了智能体开发框架 AgentScope 1.0 正式版，这是一个里程碑式的版本。
AgentScope 主要包含三大核心模块：
Framework：支持可中断、可恢复的执行控制，内置长短时记忆机制，支撑长期任务处理；同时提供高效的工具调用系统，支持按需激活与动态加载。
Runtime：基于容器技术构建安全沙箱，隔离外部操作风险，并提供强大的部署与运行引擎，支持快速发布与灵活管理。
Studio：提供完整的调试与观测能力，集成评测系统，帮助开发者理解执行过程、保障迭代质量。
过去，这些能力主要服务于 Python 开发者。但从今天起，AgentScope 正式推出 Java 版本！这意味着广大的 Java 开发者也能轻松接入这套先进的 Agent 开发体系。不仅如此，我们还将 Spring AI Alibaba 的内核全面升级为 AgentScope，打造了一个自动装配、开箱即用的 Java 原生 Agent 框架，助力企业快速构建生产级智能应用。
为什么 Multi-Agent 系统必然是分布式的？
对企业而言，开发 Agent 最大的挑战往往不在于技术本身，而在于复杂的业务流程——这不仅是开发过程中最困难的部分，也是企业的核心竞争力。
然而，现实中很少有一个团队能够完全了解企业内所有业务流程，更别说独立完成所有流程的开发与实现。因此，现实的情况还是多个不同的团队开发不同的业务系统，系统的架构最终往往会遵循康威定律：即组织架构决定了系统架构，架构自然会演变为模块化、分布式的架构。
再从高可用的角度来看，传统的单体架构始终面临单点故障和性能瓶颈的风险。为了实现高可用与弹性扩展，Multi-Agent 系统必须采用分布式架构。
所以说，无论是从业务的角度，还是技术的角度，分布式架构都是必然选择。
Agent 执行流程具备几个显著特点：执行流程长、输出结果不稳定、执行过程有状态、计算成本高。而当分布式 Agent 协同工作时，这些挑战会被进一步放大。
首先服务注册与发现成为关键问题—每个Agent如何注册自身能力？其他Agent又如何准确发现并调用它？
然后在分布式架构下，安全不容忽视。既要防止Agent被恶意攻击，保护API Key等敏感凭证不被泄露，同时确保生成内容符合合规要求，避免法律风险。
针对 AI 任务执行时间长的特点，引入消息队列作为异步中枢，实现任务解耦与非阻塞调用，提升系统吞吐量。同时，基于 MQ 构建了持久化 Checkpoint 机制：关键状态自动保存，任务中断后可从最近断点恢复，有效降低计算成本与失败损失。
最后，面对突发流量，必须构建完善的流量防护与高可用机制，通过熔断、限流 等手段，保障系统稳定运行。
可以说，构建一个高效、安全、可靠的Multi-Agent系统，不仅是AI的挑战，更是对工程架构的全面考验。而这一切，离不开AI中间件。
提到注册配置，大家都会想到 Nacos 。在微服务时代，Nacos 国内市场占有率有 60% 以上，包含 Azure 在内的海内外主流云厂商都提供了Nacos托管产品。 面向 AI 时代的今天，Nacos 升级成了 AI Registry。
在 AI 工具方面，Nacos 支持了 MCP Registry官方协议，无需任何代码改造，就能将传统应用快速转变为 MCP Server 并动态统一管理。
在多 Agent 协作方面，Nacos 是首个支持 A2A 协议的注册中心。Agent 注册到 Nacos之后，调用方只需填写 Nacos 地址，即可实现分布式多 Agent 的编排，让 Agent 的分布式协作像单体应用一样的简单和稳定。
在配置管理方面，基于 Nacos 的动态推送能力，还能实现 Agent 能力的动态更新：无需重新部署，即可灵活调整 Agent 运行时行为。
Nacos 3.1 版本已经在开源社区和阿里云MSE同步发布，大家可以直接在阿里云 MSE 中使用 Nacos 的最新版本。
AI 原生应用的全链路安全 ，安全主要关注三个方面：流量入口、AI资产安全和生成内容安全。首先，API 网关入口安全是第一道防线。通过 Higress API 网关，实现了 mTLS 双向加密通信，确保传输安全；同时集成 WAF 防火墙，抵御常见 Web 攻击。结合登录认证、IP 黑白名单和自定义鉴权，构建了多维度的访问控制体系，有效防范非法请求。
在 AI 相关配置安全方面，以 API Key 为例，引入 Nacos 作为统一配置中心，支持密钥加密存储与定时轮转，防止敏感信息泄露。并且在 Higress AI 网关中集成了多重防护机制。支持JWT、Oauth等多种消费者认证方式，确保调用方身份可信，有效保障 AI 资产安全。
最后，针对 AI 生成内容的安全，接入了阿里云 AI 安全护栏和第三方 SaaS 审核服务，对所有输出内容进行实时审查，防止生成违法、违规或有害信息。实现了“流量入口安全、AI资产安全、生成内容安全”的全链路安全。
在 AI 原生架构时代，传统的限流方式已经不再适用了。过去微服务限流方式很简单——比如限制每秒只能接受100个请求，简单好用。但到了AI时代，这套方法不灵了。在大模型时代，每个请求的长度是不一样的：有人让你写一句问候，有人让你生成一篇5000字报告。虽然都是“一个请求”，但消耗的计算资源可能是几十上百倍的差距。如果还按“请求数”来限流，就像打车收费都是一口价，只看次数不看里程，显然不合理。
AI时代的限流必须使用一套新的方式。
首先，要基于Token做精细化限流。Higress AI 网关支持实时统计每个请求的输入输出Token数量，并以此作为限流的依据。
然后，要做分级优先级调度。我们通过API网关给不同来源的流量打标——比如付费用户、免费用户等，标记成不同优先级。然后在AI网关处根据标签进行分级调度，确保高优任务不被低优流量挤占。
最后，限流阈值不是固定值，要实现动态自适应限流。AI网关能实时感知后端GPU的负载情况。一旦系统压力上升，就自动收紧免费用户的配额，优先保障核心业务。
阿里云 Higress 网关原生支持 Token 级限流、优先级调度和自适应限流，这些功能都是开箱即用的。不需要修改任何代码，您就可以直接使用阿里云 Higress 网关保障AI应用的高可用。
过去上线前的测试流程很简单：跑一遍回归测试，看看用例是不是都通过，通过了就能放心地上线。但现在的AI应用不一样了——同样的问题问两遍，答案可能就不一样。它的输出是灵活的、概率性的。我们没法在上线前穷举所有的测试用例，如果继续使用原来的测试方式，就会出现线下测得很好，一上线面对真实用户就“翻车”的情况。
我们必须把评估测试从“项目上线前的最后一步”变成贯穿应用生命周期的核心流程。每一个功能上线，都要走A/B测试，用真实流量去验证效果。
在真实流量产生之后，这个评估过程他必须是实时的、自动的。这里阿里云可观测产品支持通过日志、Metrics 等可观测数据，自动去做提取、去重、关联，生成测试集，触发实时评估。看看A/B测试中，到底哪个策略生成的质量更高、用户的体验更好，从而做出正确的决策。
更重要的是，这些评估过程不只是停留在“打分”阶段，还能沉淀下大量高质量的数据——既有效果明显提升的数据，也包含用户不满意的案例。把这些数据清洗标注后，反过来再去训练和优化模型。
这就是我们要打造的“正向数据飞轮”：以数据为中心，持续建设高质量数据集，训练竞争壁垒。评估不再只是验收环节，而是AI应用持续进化的“引擎”。只有这样，我们的AI应用才能真正地持续进化、越用越好用。
AI Agent 的时代已经到来。它不仅仅是技术的革新，更是开发范式、工程架构乃至组织协作方式的全面重构。
从开发框架的演进，到 Python、Java、Golang 全生态的支持；从分布式系统的落地实践，到全链路安全与智能评估机制——每一步都在推动 AI 原生应用走向成熟。
未来已来，只待躬身入局。如果你也在探索 Agent 的应用场景，欢迎关注 AgentScope 项目，或尝试使用 阿里云 MSE + Higress + Nacos 构建属于你的 AI 原生应用。一起，走进智能体的新世界。
