ENZOMEGA.
Clipping 微信公众号

AgentScope 2.0：第一个让我觉得Agent可以认真上生产的框架

by Fox爱分享 原文 ↗
Created: 2026-06-14
#公众号文章

公众号名称：Fox爱分享

作者名称：Fox爱分享

发布时间：2026-06-14 07:00

事情是这样的。

上周五晚上，突然看到阿里通义实验室发的消息，AgentScope 2.0正式发布了。

说实话我当时没太当回事，因为1.0我就用过，给我的感觉就是一个还算好用的多智能体框架，跑个Demo挺方便的，但也仅此而已了，跟CrewAI、AutoGen比起来，也没有特别本质的区别。

然后我顺手点进去看了一眼changelog。

这一看，给我看愣住了。

这不是更新，这是把整个框架推倒重建了。

从核心抽象到API设计到架构范式，全部breaking change，连Agent类的调用方式都从__call__改成了reply_stream，连Message模块都重构了，连1.0的Memory模块都直接deprecate了。。。

这不是那种”加了几个新功能”的迭代，这是那种”我们觉得1.0的路线走不通所以重新来过”的重构。

我寻思了一下，没寻思明白为啥这么大动干戈。

然后我把文档从头到尾啃了一遍，把源码拉下来跑了几个例子，终于想明白了一件事。

AgentScope 2.0不是在做一个更好的多智能体框架。

它在做一个能跑在生产环境里的多智能体框架。

这两件事，听着差不多，其实差了十万八千里。

我非常理解很多朋友的感觉。

你可能试过CrewAI，写几行代码就能跑起来两个Agent互相聊天，觉得还挺酷的。你也可能试过AutoGen，搭了个多轮对话的Demo，发个朋友圈装了个逼。然后呢？然后你就发现，真要把这玩意用到生产环境里，问题一个接一个。

Agent要是调了个rm -rf怎么办？上下文撑爆了怎么办？模型API挂了整个任务链就断了怎么办？多个用户同时用怎么隔离？部署到线上怎么变成服务？

这些问题的答案，1.0给不了，CrewAI给不了，AutoGen也只能给你个大概的方向。

2.0给了。

而且给得非常工程化，非常具体，非常「这就是我们在生产环境里踩过的坑所以这么设计」的感觉。

所以今天，我想好好聊聊AgentScope 2.0。

从它是啥，到怎么用，到那些让我觉得「卧槽这设计真牛逼」的地方，一次性讲透。

先说说它到底是啥。

AgentScope是阿里通义实验室开源的多智能体开发框架，1.0的时候主打的卖点是「透明开发、可视化消息流」，就是让你能很直观地看到Agent之间在聊什么、干了什么。

2.0的定位完全变了。

官方的原话是，「聚焦真实场景下的稳定运行、安全控制与生产部署」。

翻译成人话就是，1.0是让你跑通Demo的，2.0是让你把Agent跑在生产环境里的。

这个转变，坦率的讲，非常关键。

因为整个行业现在正处在一个分水岭上，大家已经不满足于「AI Agent好酷啊」了，开始问「AI Agent怎么才能靠谱地干活」。从Demo到Production之间的鸿沟，才是真正要填的东西。

而2.0几乎所有的设计决策，都在填这个鸿沟。

先来看一张图，这是我把2.0的架构梳理完之后画的，整个框架的全貌。

从上往下看，最顶层是Agent核心，两个入口reply和reply_stream。中间是六个核心模块，各管各的事。最底下是基础设施，模型API、工具集、沙箱环境。

整个架构最让我印象深刻的地方，就是每一层的设计都在回答同一个问题，怎么让Agent在真实场景里跑得稳。

那具体填了啥呢？我挑几个我觉得最核心的，一个个聊。

先聊事件系统。

这是2.0最基础的设计范式转变，Agent从「被动回调」变成了「主动事件流」。

1.0的时候，Agent是__call__的方式，你调用它，它给你返回结果，完事。就像你去餐厅点菜，点完等着上菜就行，后厨在干嘛你不知道。

2.0不一样了，Agent提供了两个方法，reply和reply_stream。reply还是等最终结果，但reply_stream会以流式的方式，一步一步地把Agent在干啥告诉你。

模型开始思考了，给你发个事件。模型在生成文本了，给你一段一段地推过来。Agent要调用工具了，给你发个事件告诉你它准备调哪个工具、传了什么参数。工具执行完了，结果也给你推过来。

每一步操作都是类型化的流式事件。

来看个代码，这是2.0里最基础的Agent创建和事件流消费的写法。

import asyncio
import os

from agentscope.agent import Agent
from agentscope.credential import DashScopeCredential
from agentscope.event import EventType
from agentscope.message import UserMsg
from agentscope.model import DashScopeChatModel
from agentscope.tool import Toolkit, Bash, Read, Write, Edit


asyncdef main() -> None:
    # 创建Agent
    agent = Agent(
        name="Friday",
        system_prompt="You are a helpful assistant named Friday.",
        model=DashScopeChatModel(
            credential=DashScopeCredential(
                api_key=os.getenv("DASHSCOPE_API_KEY"),
            ),
            model="qwen-plus",
        ),
        toolkit=Toolkit(tools=[Bash(), Read(), Write(), Edit()]),
    )

    user_msg = UserMsg(name="user", content="帮我看看当前目录下有哪些文件")

    # 方式一：同步等待最终结果
    reply_msg = await agent.reply(user_msg)

    # 方式二：流式获取增量事件（推荐）
    asyncfor event in agent.reply_stream(user_msg):
        match event.type:
            case EventType.TEXT_BLOCK_DELTA:
                # 模型在生成文本，一段一段推过来
                print(event.content, end="", flush=True)
            case EventType.TOOL_CALL_START:
                # Agent要调工具了
                print(f"\n[调用工具] {event.tool_name}")
            case EventType.TOOL_CALL_END:
                # 工具执行完了
                print(f"\n[工具结果] {event.result}")
            case _:
                # 其他事件：思考块、回复结束等
                pass


asyncio.run(main())

你看，整个设计是非常清晰的。Agent是个纯事件生产者，它不关心你怎么展示，只管把发生的事情通过事件流推出来。前端也好，CLI也好，AG-UI协议也好，都只是事件的消费者。

这玩意有啥用呢？

坦率的讲，如果你只是跑个脚本让它帮你写个文档，那确实没啥用。

但如果你要做前端应用，如果要让用户实时看到Agent在干啥，如果要接AG-UI协议做智能体交互界面，如果要做Human-in-the-Loop让人能在Agent执行中途拦一下说「等一下这个操作我确认一下」，那这个事件流就是基础设施级别的存在。

没有事件流，这些都是空中楼阁。

有了事件流，前端渲染、协议对接、人工介入，全部顺理成章。

而且2.0还把Agent的print接口给废弃了，Agent变成了一个pure producer，纯生产者，只负责产出事件，怎么展示是消费者的事。

这个设计决策，我觉得挺有魄力的。把渲染和逻辑彻底解耦，听起来简单，但在一个已经1.0的框架里做这种决定，要考虑向后兼容的代价，是需要一点决断力的。

顺着事件系统，再聊第二个我觉得特别重要的东西，权限系统。

这玩意，是2.0全新独立模块，1.0完全没有。

也是我觉得从Demo到Production最关键的分水岭。

你想想看，你写了个Agent，给了它执行Bash命令的权限，然后用户跟它说「帮我清理一下磁盘」，Agent一想，rm -rf /，执行了。。。

这特么谁扛得住。

或者Agent要写文件，啪一下写到了/etc/passwd里面去，或者要读文件，啪一下把你的AWS密钥给读出来了。

这些在Demo里不会发生，因为Demo的环境是可控的，Prompt是精心设计的，用户的输入是预期的。

但生产环境不是。

生产环境里用户会说各种你意想不到的话，Agent会产生各种你意想不到的行为，模型会幻觉，工具会误判。

所以2.0做了这么一套权限系统。

来看一张流程图，这玩意是怎么在Agent调工具之前做判断的。

从图上可以看得很清楚，Agent要调工具的时候，系统会先检查工具类型，然后分析输入内容有没有访问敏感路径、是不是危险命令、有没有在读密钥文件，最后根据风险等级做判断，低风险自动放行，中等风险转给用户审批，高风险直接拦截。

而且2.0还支持沙箱隔离，不受信任的代码可以在Docker容器或E2B云沙箱里跑，碰不到宿主机的文件系统。

这设计，我只能说，这是真的在生产环境里被锤过的人才会做出的选择。

看起来，没在真实生产环境里被模型幻觉教训过的团队，是不容易把权限系统提到这个高度的。

说到沙箱，就顺势聊聊第三个核心特性，Workspace系统。

这是2.0最大的架构升级，没有之一。

Workspace这个东西，其实就是个执行环境的抽象层。

它支持三种后端，LocalWorkspace在本地跑，DockerWorkspace在Docker容器里跑，E2BWorkspace在E2B云沙箱里跑。

关键在哪呢？关键在于，这三个实现共享同一套Agent-facing API。

啥意思呢？就是你的Agent代码，一行都不用改，只需要换一行配置，就能从本地开发环境无缝切换到Docker容器，再切换到E2B云沙箱。

一次编写，到处运行。

听起来是不是有点耳熟？

对，就是Java当年那句著名的slogan。虽然Java后来因为各种原因没完全兑现这个承诺，但这个理念本身是对的。执行环境的解耦，是工程化最核心的命题之一。

来段代码感受一下。

from agentscope.workspace import LocalWorkspace, DockerWorkspace, E2BWorkspace

# 本地开发
workspace = LocalWorkspace(base_dir="./workspace")

# 切到Docker容器，代码一行不用改
workspace = DockerWorkspace(image="python:3.11-slim")

# 再切到E2B云沙箱
workspace = E2BWorkspace(template="base")

# Agent代码完全一样，只是workspace不同
agent = Agent(
    name="Friday",
    model=model,
    toolkit=Toolkit(tools=[Bash(workspace=workspace)]),
)

而且Workspace还支持MCP客户端集成，每个Workspace里可以独立配置自己的MCP Server。还有预热池机制，支持并行场景下批量初始化环境。还有三级隔离粒度，用户级、智能体级、会话级。

这些设计，都在解决同一个问题，就是多租户。

在生产环境里，不可能一个Agent一个实例，必然是多个用户共享同一套基础设施。而多租户的核心挑战就是隔离，不能让A用户的数据被B用户的Agent读到，不能让A用户的会话状态影响B用户的执行。

Workspace的整个设计，就是在回答这个问题。

再来聊个更偏工程效率的东西，上下文管理。

这可能是所有做多智能体的人最头疼的问题了。

Agent跟模型对话，对话历史会越来越长，工具返回的结果会越来越大，一个Bash命令的输出动辄几千行，一个Read操作读完整个代码库，这些东西全部塞进上下文里，token蹭蹭蹭往上涨。

1.0其实有Memory模块做长期记忆，聊天历史的持久化是有的。但对话内的token压缩、工具结果截断、文件缓存这些工程优化基本是空白，只能硬扛。

2.0重构了整个上下文管理。

首先，长对话会自动做结构化压缩，不是粗暴地截断，而是保留任务目标、当前状态、关键发现和下一步计划这些核心信息，把冗余的中间过程压缩掉。

其次，工具的输出结果会自动截断，超大日志不会撑爆上下文。

然后，文件读写还加了缓存机制，强制「先读后改」，减少重复IO。

这些优化单独拿一个出来看都不算惊天动地，但组合在一起，就是让长链路任务不至于跑到一半因为上下文溢出而崩掉。

坦率的讲，这种优化是最不性感的，也是最必要的。

谁会在Demo里跑一个50轮的对话呢？但生产环境里，Agent可能要连续执行上百步工具调用，上下文管理就是生死线。

还有个东西我觉得挺有意思，Middleware机制。

1.0用的是Hook，就是在Agent的关键节点挂一些回调函数。2.0把Hook重构成了更通用的Middleware系统。

Middleware可以在模型调用、思考规划、工具执行这些关键节点插入自定义逻辑，而且不需要修改框架源码，即插即用。

from agentscope.middleware import TracingMiddleware, MiddlewareContext

# 自定义Middleware，在模型调用前后加逻辑
class LogMiddleware(TracingMiddleware):
    asyncdef on_model_call(self, ctx: MiddlewareContext):
        print(f"模型调用开始: {ctx.model_name}")

    asyncdef on_model_call_end(self, ctx: MiddlewareContext):
        print(f"模型调用结束, 耗时: {ctx.duration}ms")

# 注册即生效
agent = Agent(
    name="Friday",
    model=model,
    toolkit=toolkit,
    middlewares=[LogMiddleware()],
)

内置的Middleware有TracingMiddleware做OpenTelemetry链路追踪，AGUIProtocolMiddleware支持AG-UI协议的流式传输，ToolOffloadMiddleware处理超大工具输出的卸载。

你想想看，这玩意其实就是Web框架里中间件的概念。Express有中间件，Django有中间件，FastAPI有中间件，现在Agent框架也有中间件了。

这种设计模式的迁移，其实反映了一个趋势，Agent框架正在变得越来越像传统的软件工程基础设施。

以前写Agent像是做研究，现在写Agent越来越像写Web服务。这本身就是一种成熟。

回到这块，再聊聊Agent Service。

这是2.0新加的基于FastAPI的生产级服务。

它把Agent变成了一个可以通过REST + SSE访问的服务，支持多租户、多Session并发，内置了可续传流、持久化会话、定时任务、凭据管理这些生产必备的能力。

from agentscope.service import AgentService, ServiceConfig

# 一行启动生产级Agent服务
service = AgentService(
    agent=agent,
    config=ServiceConfig(
        host="0.0.0.0",
        port=8000,
        workers=4,  # 多worker并发
    ),
)

service.start()
# 现在Agent可以通过 REST + SSE 被外部调用了
# POST /v1/chat  →  同步对话
# GET  /v1/chat/stream  →  SSE流式对话

你不需要自己搭服务脚手架，不需要自己处理并发和状态管理，启动Agent Service就能用。

这玩意解决的是最后一公里的问题。

你的Agent写得再好，如果只能python main.py本地跑，那它就永远是个Demo。只有变成了可以被前端调用、可以被外部系统集成、可以被工作流编排的服务，它才是生产级的。

Agent Service就是干这个的。

聊到这儿，可能有些朋友已经有点心动了，想上手试试。

那我把整个事件流的交互过程也画出来了，从用户发消息到Agent最终返回结果，中间经历了哪些事件、哪些决策点，一目了然。

你可以看到，整个流程最关键的几个节点，模型调用、工具调用、权限检查，全部被事件流串联起来了。每一步对前端来说都是可见的、可交互的。这就是2.0和1.0最本质的区别，Agent不再是一个黑盒。

安装就一行命令，pip install agentscope，Python要求3.11以上。

切换模型也很方便，把DashScopeCredential和DashScopeChatModel换成OpenAICredential和OpenAIChatModel，就完事了。整个模型层的凭证是解耦的，不在Model类里，统一由Credential模块管理。

import os

# 用阿里云Qwen
from agentscope.credential import DashScopeCredential
from agentscope.model import DashScopeChatModel

model = DashScopeChatModel(
    credential=DashScopeCredential(api_key=os.getenv("DASHSCOPE_API_KEY")),
    model="qwen-plus",
)

# 换成OpenAI，只改两行
from agentscope.credential import OpenAICredential
from agentscope.model import OpenAIChatModel

model = OpenAIChatModel(
    credential=OpenAICredential(api_key=os.getenv("OPENAI_API_KEY")),
    model="gpt-4o",
)

坦率的讲，上手门槛不算低。

不是那种「三行代码跑起来一个Agent」的框架，2.0的设计取向从一开始就是面向有工程经验的开发者的。

但我觉得这也合理。如果你要的是快速体验多智能体的酷炫感，CrewAI确实更友好。但如果你要做的是真正跑在生产环境里的Agent系统，那这些抽象和配置就是你绕不过去的基建。

一开始可能会有点笨拙，花的时间比用简单框架还长。但当你真正面对上下文溢出、模型故障、权限控制、多租户隔离这些问题的时候，你会发现2.0给的东西，每一件都不是多余的。

说真的，把2.0从头到尾看完之后，我脑子里一直在想一个事儿。

Agent框架这个行业，正在经历一个很关键的转折。

去年大家比的是谁的Demo更酷，谁能更快地让两个Agent聊起来。今年风向明显变了，大家开始问更务实的问题，怎么保证安全，怎么保证稳定，怎么保证在生产环境里不翻车。

这种转变，让我想起了一个很古老的类比。

1880年代，电力开始在美国普及。很多工厂主花大价钱买了发电机和电动机，装在自己的工厂里。但装完之后，很多人发现生产效率并没有显著提升。

因为他们只是用电动机替代了蒸汽机，整个工厂的布局、流程、管理方式都没有变。

那些真正吃到电力红利的人，不是最早买发电机的人，而是最早想明白电力到底意味着什么的那波人。他们重新设计了工厂的布局，让生产线围绕电力来组织，而不是简单地把电动机塞进原来蒸汽机的位置。

Agent框架也是一样。

1.0时代的框架，就是那个把电动机塞进蒸汽机位置的阶段。我们能跑Agent了，能跑多Agent了，很酷，但酷完之后呢？

2.0做的事情，是开始重新设计整个工厂的布局。

事件流是新的电力传输方式，权限系统是新的安全标准，Workspace是新的厂房结构，Agent Service是新的配电系统。

每一个模块都不是为了酷而存在的，是为了让Agent能像电力一样，稳定地、安全地、可扩展地，流到每一个需要它的角落。

当然，2.0也不是没有遗憾。

Memory模块被deprecate了，RAG和长期记忆还在重构中，文档虽然已经很详尽了但迁移指南还可以更完善一些，对纯新手来说上手曲线还是比较陡的。

而且2.0和1.0是完全不兼容的breaking change，如果你已经在1.0上有了项目，迁移的工作量不小。

但话说回来，一个框架敢做这种程度的breaking change，本身就说明团队对方向有很清晰的判断。他们不是在1.0上修修补补，而是认定了「生产级」这个方向，然后把所有偏离这个方向的设计都砍掉重做。

这种决断力，我觉得挺值得尊敬的。

毕竟在这个行业里，最稀缺的不是新功能，是做减法的勇气。

大时代啊，朋友们。

我们正站在Agent从「实验室玩具」变成「生产基础设施」的转折点上。

而AgentScope 2.0，是这条路上，目前我看到的，走得更远的那一个。

如果你在做Agent相关的开发，不管你之前用的是CrewAI还是AutoGen还是LangGraph，我真心建议你花点时间看看2.0的设计。不是为了换框架，而是为了看看，当一个人认真思考「Agent怎么跑在生产环境里」这个问题的时候，他会给出什么样的答案。

答案本身可能不是标准答案，但思考问题的角度，值得学习。

磨平一些信息差。

哪怕，只是很小很小的一点。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。

内容效果不满意？点此反馈

输入关键词开始搜索