作者刘军陆龟AgentScope Java 2.0 的核心思路是基于 ReActAgent 推理内核基础上增加 Harness 工程化层。开发者既可以继续使用轻量的 ReAct 循环也可以按需启用 Workspace、持久记忆、Session、Sandbox、Skill 和 Subagent 等能力将同一套 Agent 逻辑落地部署到企业级分布式服务中。经过 5 个 RC 版本迭代AgentScope Java 2.0 GA 版本正式发布文档https://java.agentscope.ioGitHubhttps://github.com/agentscope-ai/agentscope-javaRelease Noteshttps://github.com/agentscope-ai/agentscope-java/releases/tag/v2.0.0本文根据刘军 2026-07 月份关于 AgentScope 2.0 的公开技术分享演讲整理而成完整复现现场演讲内容。点击此处立即查看现场演讲视频。AgentScope 2.0 介绍AgentScope 框架推出已经有两年的时间了。我们在上半年发布了 2.0 版本2.0 版本主要的一个核心能力就是把 Harness 整套方案内置到了框架里面。这也意味着我们面向的场景主要是企业级的分布式智能体这样一个场景。本文主要从三部分来给大家介绍。第一部分是大家都关心的 2.0 主要有哪些核心能力。有一些开发者包括企业内已经非常重度地用 AgentScope 1.0 构建了很多生产级的应用和智能体这套设计理念的差异和怎么迁移我会简单介绍一下。中间一大部分是介绍整个 Harness 的核心设计和它到底有哪些能力。最后是几个示例我们来看一下它能做真正的企业级的事情。AgentScope 生态全景图先从全景图开始。大家可以直观地把 AgentScope 理解为一个框架也就是图中蓝色的这一部分。作为一个框架我们现在有 Python、Java 和 TypeScript 三个语言实现Go 语言的实现也在开发当中所以整个框架已经基本涵盖了所有主流的语言实现。框架这一层更多定义的是 Agent 怎么开发、怎么定义。比如中间就是整个 Agent Loop 的循环里面的 Reasoning、Tool Call 都有非常好的设计这些实现大家不需要去关心。包括里面的 Model以及整个 Event、Message 的传递这些都是内置的。在 2.0 里我们加了 Workspace 这样一个非常核心的抽象同时也做了更多上下文管理的事情。这就是中间蓝色部分的框架。往外延伸的是我们围绕 Agent 的构建过程做的很多生态适配。比如模型这一侧左边这部分就是国内的 DeepSeek、OpenAI 兼容的这些模型还有 Qwen 模型都是支持的。观测这一块整个框架现在有默认的 OpenTelemetry 埋点所以观测数据可以上报到任何兼容 OpenTelemetry 的平台比如开源的 LangFuse或者阿里云上的产品——以前微服务时代叫 ARMS现在有一款专门针对 Agent 时代的 Agent Loop 的产品都是可以接进去的。然后是 Higress前面讲 Agent Teams 的时候提到过不论是模型的代理还是 MCP 的代理包括用 Nacos 做 Skill 或者 MCP 市场的管理整个 Agent 生态都已经完整对接了。再往上QwenPaw 和 AgentTeams 都是我们基于这个框架生态衍生出来的具体产品和企业级的 Agent 管理能力。ReactAgent 内核与核心组件看完大图我们回到 AgentScope 框架本身。整个 2.0 对底层来说是不变的也就是 ReAct Agent 这套核心的推理和工具之间的循环这个没有变。我这里列了几个核心能力和 1.0 区别不太大底层能力这一层是没变的顶多是做了一些设计上的优化。或者看下面加了一个 Permission就是工具调用权限这块额外的设计因为以前是没有工具权限管控能力的。中间还有个 Middleware 中间件这个和以前的 Hook 是对等的只不过在新版本中我们对整个事件的传递和中间的介入做了一些优化。所以整体看起来Model、Tool 定义、中间的上下文上下文这块对应的就是我们以前产生的内容整体来说是差不多的就是整个 ReAct Agent 这一块。1.0-2.0 迁移指南虽然核心的底层逻辑不变我这里还是列了 1.0 到 2.0 需要关注的三个迁移要点我们从左到右从三个层次来看。先说绿色这部分。升级的时候我们总体保证了兼容性也就是说前面提到的所有这些能力总的来说都保持了兼容。即使有些 API 做了废弃——比如 Hook 从设计上被 Middleware 替代了——在 2.0 版本里我们还是把它标记为废弃但保留了下来。所以理论上来说绝大多数能力都可以兼容并且平滑升级。中间这部分列出来的是你必须要改的。虽然大部分能力保持了兼容性但还是有些东西改掉了这部分内容如果不改可能会有一些编译或者运行的报错。主要体现在几个方面第一个是状态管理这块。我们现在在整个框架里引入了一套 Agent State 的概念整个 Agent 运行的状态都通过 Agent State 来管理。它和以前的 Session 在底层数据格式上是有一定差异的这个大家要认识到。如果你以前有运行中的 1.0 版本 Agent 的状态现在我们做了一层兼容——你把它切到 2.0 然后发布上线它还是能认你以前 1.0 的状态。但要知道从 API 到实现上状态管理是发生了变化的。还有一块非常大的变化由于我们非常强调多租户能力——不论是 User 维度的隔离还是 Session 维度的隔离——我们在 Agent 调用的 call 方法和 stream 方法的入口都加上了 Runtime Context 这样一个概念。也就是说你必须把运行的上下文——比如当前是哪个 User、哪个 Session——这些信息传进来。同时它也提供了 Runtime Context 的拓展性你可以基于它做很多拓展的事情。下面几个都是和 State、Session 强相关的。最后一部分属于大家可以慢慢迁移的。如果你改掉了中间这部分 API 相关的破坏性修改后面这部分就是标记为废弃的内容可能我们会在 2.1 版本移除掉方便大家先迁到 2.0后面再逐步升级。这块整体讲起来比较繁琐官网上有专门的链接讲怎么迁移大家可以去看看。AgentScope Harness 核心设计与功能详解接下来讲今天比较重要的一部分就是 AgentScope 整套 Harness 的设计。我们先看整个 Harness 在 AgentScope 上的总体架构。Harness 总体架构看中间这个大蓝色的部分。Harness 是构建在 AgentScope——不论是 1.0 还是现在——底层 Agent 推理执行组件之上的可以理解为在以前 1.0 的 ReAct Agent 之上又包了一层。在这一层之上是把你长期运行一个 Agent 必备的能力——上下文管理、上下文压缩、Agent 编排、Skill 的运行、在沙箱环境里隔离工具的执行、推理规划和任务状态的跟踪、甚至包括和一些 IM 消息系统的对接、工具的权限管控——统一作为一个 Harness 套件在框架底层内置支持了。你可以用一些开关或者遵循这套 Harness 的开发模式就可以把它用起来。相当于增加了这么一层能力。Harness 快速体验这里用一个 Java 版本的示例来讲。AgentScope Java 里如果要用 Harness 这一层怎么用呢第一你要加一个依赖。因为我们在上面又加了一层你要把这一层的依赖加进来。其次是开发的入口。ReActAgent 的 API 入口还在但现在多了一层新的 API 入口叫 HarnessAgent。你可以直接用它构建一个 Agent——它底层还是用的 ReAct Agent但在 API 的感知上你可以直接用 Harness Agent。我们可以看它们中间的差异前面是一样的——Name、System、Model下面你可以看到它有了 Workspace 的概念可以指定它的 Workspace可以指定一些压缩策略还有更多的配置包括 Sandbox 隔离的配置都可以在这一层直接用 API 来做。下面的区别就是调用的时候需要前面提到的 Context 上下文。这里定义了一个 Runtime Context接下来调用时主要是传 User 和多租户隔离的一些信息。Workspace – 智能体进化的 Source of TruthWorkspace 是现在主流的 Agent——不论是 Agent 产品还是 Agent 框架——的一个核心设计。我们可以把它理解为一个逻辑概念。它里面有哪些资产呢第一部分是偏静态的资产就是 Agent 定义相关的比如 AGENTS.md、Skills 或者 Sub-Agent相当于定义了我这个面向业务的 Agent 里都有哪些东西。这是我定义的、会随着我的镜像打包走的叫静态资产。还有一部分是运行时的数据。这部分数据是 Agent 在运行过程中自己产生的是用户和它交互沉淀下来的——不论是一些实时的 Session 状态记录、Task 任务状态等信息还是 MEMORY.md 这种沉淀下来的记忆。所有这些静态的或运行时的资产都沉淀在 Workspace 里。这就是 Workspace 的核心概念。抽象文件系统 – Workspace 的物理载体并且在 AgentScope 中我们对 Workspace 做了更细粒度的处理。比如一个 Agent 有一个 Workspace但一个 Agent 会被很多用户使用。对于不同的用户我们在这一个 Workspace 里做了逻辑上的多租户隔离——可以是用户维度的隔离、Session 维度的隔离或者是 Agent 维度的。这是不同的隔离维度。在底层我们说 Workspace 是一个逻辑概念那它的物理存储是什么呢最直观的理解一定是磁盘这是最直接的。但磁盘有一个问题比如 On-premise 场景它就只能在你本地的磁盘上这就是 Workspace 绑定磁盘的限制。为了解决这个问题——尤其我们面向的是企业级分布式场景——我们把 Workspace 的上层逻辑实现往底层物理实现走的时候抽象了一个接口就是中间黑色的部分叫做 Abstract File System一个抽象的文件系统接口。Agent 操作 Workspace 时物理层面使用的就是这个抽象文件系统接口。我们为它提供了默认的三种实现当然你也可以任意拓展第一种是左边的本地 On-premise装在本机直接操作的是磁盘。如果你要做用户的隔离就是树形文件系统一个树状的结构。在生产环境部署时因为一个 Agent 要多实例部署每个实例都要看到同一个 Workspace这时你可以把抽象文件系统接口接到数据库比如 MySQL 或者 Redis或者是阿里云的 OSS。这就实现了 Workspace 的共享——同一个 Workspace 实例能够被不同的 Agent 实例看到。如果你对 Workspace 的隔离有更高的要求——比如工具的执行工具执行也是在 Workspace 的空间里进行的你可以把它接到 Sandbox。一个 Workspace 映射一个 Sandbox这时只要做好 Sandbox 的生命周期管理就可以实现多租户隔离了。这就是 Harness 中 Workspace 的逻辑概念和物理存储实现这样也就支持了分布式的场景。内置上下文压缩策略 – 四道防线在 Workspace 里我们怎么管理所有的上下文呢第一我们内置提供了一些压缩策略。Agent 在一个会话运行的过程中模型是有上下文窗口限制的我们怎么保证上下文在这个限制之内呢这里提供了几种压缩策略图中只展示了其中一部分实际还有更多详细的配置。比如工具执行的结果大于多少之后我们有截取加落盘的实现——落盘以后给到文件引用的路径工具入参过大时也有一些字数上的截断策略这些都是基本的措施还包括对过往消息进行压缩、保留最近几条这些都是大家熟悉的常规压缩策略。在压缩的过程中还是有一些注意事项的。最典型的就是压缩的时候尽量不能丢信息。哪些信息是尽量不能丢的呢右下角这部分有几个例子。比如整个任务执行的规划——有些复杂任务是要做规划的这个规划可能在你消息的前几条如果不做特殊处理直接压缩规划就丢掉了。还有基于这个规划我可能拉起了一些子 Agent有些子 Agent 是异步的或者任务是异步的。异步的情况下任务很可能还没有返回我要持续地追踪任务状态。这时如果直接粗暴地压缩这个子 Agent 的状态可能就丢掉了。因此像这种需要在全局进行更新的状态——不论是规划的详情、子 Agent 的异步任务状态、我的清单还是各种工具的权限授权记录——这些信息都要保证不被压缩。所以这两部分内容要进行区别处理。双层长期记忆 – 事实自动沉淀还有一个是长期记忆的沉淀。前面讲的压缩偏瞬时状态——是运行当中瞬时状态的管理和控制。做压缩的时候必然会丢掉一些信息这些信息可以把它沉淀为长期记忆。框架里的一些策略是在会话压缩以前可以做一次 Flush 分拣。第一层是记到每天专属的一个文件里这个结构其实和 QwenPaw 是差不多的可以记进去。同时我们还有一个后台任务它会定期回去扫描当天的、整个 Memory 下沉淀的记忆把它蒸馏为全局的 MEMORY.md。这个 MEMORY.md 在每次请求进来的时候都会全局加载到你的 System Prompt 里所以它的大小和里面数据的质量就非常重要。同时还配套了几个 Memory 管理的相关工具Memory Search、Memory Get 和 Session Search。模型会根据 MEMORY.md 等内容的引导在适当的时候去查你的流水账等信息。这是一套相互配合的长期记忆沉淀策略。所有这些环节——不论是做每日流水账的 Memory 提取还是定时蒸馏 MEMORY.md还是做压缩——里面的 Prompt 提示词都是可以定制的方便大家在不同场景引导做更优化的提取和记忆实现。下面这几个在框架上都有提示词的 Config 入口。子智能体编排、委派、并行、异步通知Harness 当中还有一个非常重要的点是关于智能体的编排。这张图要表达的是主 Agent 直接指导所有的子 Agent。一个任务进到主 Agent 以后我们内置了 Agent Fork、Agent Spawn 这些工具主 Agent 会根据需求来拉起子 Agent。拉起的子 Agent 首先有两种类型一种是同步的子 Agent一种是异步的子 Agent。异步的子 Agent 适用于处理时间比较长的任务并且现在我们支持它在完成以后主动把结果通知回主 Agent。还有一种特殊类型是远程的子 Agent这种模式现在也是支持的可以拉起一个远端的子 Agent。同时我们给主 Agent 配套了一个叫 Task List 的 Toolkit覆盖了所有的配套工具。主 Agent 可以主动地去看有哪些子 Agent、每个子 Agent 处于什么状态这些都有配套的工具。还有一点值得一提也是很多企业用户的核心诉求通常来说用户直接对话的是主 Agent主 Agent 拉起所有子 Agent 是它自己的事情它管理子 Agent 是为了完成自己的任务。但实际上有很多用户包括我们用 Claude Code 的时候也是会希望直接切到主 Agent 拉起的某个子 Agent和这个子 Agent 对话来引导它完成自己的子任务。同样在 AgentScope 中我们也支持你直接和子 Agent 进行对话。虽然这个子 Agent 是主 Agent 拉起来的但有一种方式可以把它暴露出来让你直接和它对话。子 Agent 的整套设计前面讲的是几个比较大的层次里面还有一些细节。比如主 Agent 和子 Agent 之间的上下文是不是共享的就是下面列的这几项包括子 Agent 的事件怎么通过主 Agent 透传出来、怎么区分是哪个子 Agent 的还是主 Agent 的因为大家的事件流都混在一起我们都是有标记在的。然后是权限问题——主 Agent 拉起子 Agent 以后子 Agent 的权限是什么、是不是继承主 Agent 的权限这些比较细节的事情在整个框架里都有一套机制存在。沙箱管理隔离、恢复与分布式还有一套机制是关于沙箱的。沙箱主要解决 Agent 执行的安全问题是其中非常重要的一环。Agent 工具执行的过程中我们可以把工具执行放在沙箱里整个框架里有一套沙箱生命周期的管理系统。这里就不展开了感兴趣的话可以进一步查阅官方文档。Skills四层注册中心 沙箱内执行关于 Skill 有两部分可以讲一下。第一部分是 Skill 的管理。AgentScope Harness 对于 Skill 管理对接了类似 Nacos 这种中心化的 Skill 管理系统可以自动地把中心化管理的 Skill 加载到本地进行识别和使用。同时基于前面讲的 Workspace 细粒度管理机制你也可以实现不同用户之间 Skill 的隔离使用——我这个用户有自己的 Skill另一个用户有另外的 Skill互相是看不到的。这个也是可以实现的。另一部分是 Skill 的执行。Skill 有时不只是简单的流程里面还有配套的脚本和一些资源文件这时它的执行就要受到安全管控。我们现在支持把整个 Skill 投影到 Sandbox 中让 Skill 的所有脚本都能在 Sandbox 里闭环执行。计划模式想清楚 - 写下来 - 再动手Harness 里现在也支持计划模式。熟悉 1.0 的用户应该知道我们在 1.0 中也有一套叫做 Plan 的计划模式——给一个任务先规划再执行。1.0 的实现更偏向于一个内部管理的状态机由一套状态机来运转和执行。在 2.0 中我们对整个 Plan 模式做了优化首先内置了一整套 Plan 相关的配套工具比如 PlanEnter、PlanExit 等等。当用户请求进来的时候你可以直接开启 Plan。如果大家熟悉 Coding Agent可以直接理解为和 Coding Agent 的 Plan 模式一样——比如在 Codex 或者 Claude Code 中你可以打开 Plan。我们用 AgentScope 开发的业务 Agent 也是一样的前面有一个接口可以调你告诉它要开启 Plan 模式它就开启了接下来你问它问题它就会生成 Plan后面切到 Agent 模式让它执行它就基于之前的 Plan 直接往下执行。或者你让它进入自主识别的模式它可以根据你的任务自己切到 Plan 模式。因为这里每个工具都有 Permission 权限它切到 Plan 模式的时候可能会先问你Plan 执行完了就像 Coding Agent 那样它要切换回 Agent 模式时会弹出一个弹窗来问你。整个流程上是一样的我们可以在前端的 UI 上把这一套串起来。Channel消息平台 - Gateway- Agent在一些企业的业务场景里是有对接 Channel 平台的需求的——要把后台运行的任务和企业内的即时通讯系统等对接起来。这块整个框架也提供了原生的支持。AgentScope 企业级智能体实战官方示例前面就是关于整个 Harness 的部分。Harness 的设计内容相对比较多大家可以去看官方文档里具体的使用方式。最后我们介绍几个示例。个人助手 —— 直连本机 FS 与 Shell随用随长第一个示例——这几个示例都在我们官方的 GitHub 仓库里——是 AgentScope Java 版的一个类 QwenPaw 产品。它实现了一个非常简化版本的 QwenPaw不是一个具体的发行产品我们做它只是为了验证用 AgentScope 怎么开发一个个人助手产品。和前面讲到的一样它用的 Workspace 模式是完全绑定本地磁盘的因此它不支持分布式部署。多租户 Managed Agent 平台 —— 一套自进化 Agent一个组织共用还有一个示例是一个多租户的 Agent 平台你可以理解为一个零代码开发的 Agent 平台叫做 Agent Builder。它有一个 UI 界面可以在公司里集中化部署。部署以后它就是一个 SaaS 平台公司里的每个人都可以在上面创建 Agent。作为管理员我也可以创建一个共享的 Agent给公司里的所有人用。每个用户虽然用的是同一个 Agent但底层可以做到多租户隔离——依赖的就是下面的 Workspace 和物理 File System 的分组。这样就实现了一个 Agent 的多租户平台每个用户的数据都是隔离的。同时我也可以定义自己的 Agent还可以把我的 Agent 共享给别人。这其实就是 Claude Managed Agents、Langchain Managed Agents、Qoder Cloud Agents 平台的原型使用 AgentScope 2.0 可以非常快速的搭建出来只需要开放控制面、数据面 API 即可。数据 Agent 平台 —— per-用户进化 审批式能力市场最后还有两个示例。一个是 Data Agent这也是一个多租户场景的示例。这个 Data Agent 针对每个用户的使用数据基础都有一套隔离的空间。每个用户还可以有自己的 Skill不同用户沉淀的 Skill 在这套体系里还有一套审批机制——我的 Skill 可以申请共享给大家走一个审批流程通过以后它就是共享的所有用户都可以用。自主编码机器人 —— Thread 路由 一次性 Docker 容器最后一个示例是 Coding Agent。这个 Coding Agent 和我们本地安装的比如 Claude Code 或者 Cursor 的使用场景不太一样。它是一个企业级服务的共享 Agent 场景。比如把这个 Coding Agent 在企业里集中部署以后一个典型的场景是对接 GitLab——把部署好的 Coding Agent 服务接到 GitLab 上。每个人在 GitLab 上处理 Issue 或者 Pull Request Review 的时候发送的所有请求都会被这个 Coding Agent 服务接收。你的整个任务运行和其他用户的运行环境是隔离的——它会自己拉起 Sandbox专门为你这个用户服务。它确保你处理的所有 Issue 和 Pull Request 状态是连续的不同用户之间互不影响。包括你处理每个 Issue 时可能会有连续的对话整个 Issue 的状态也不会和其他 Issue 或者 Pull Request 混在一起、互相影响。所以它是一个部署在企业内部、为大家的研发协作服务的 Coding Agent 示例。包括把它作为一个 CI/CD 平台架起来、用 AI 来驱动也是没问题的。整套机制底下用的都是 AgentScope Harness 的底层设计。AgentScope 在企业中获得广泛应用自 2024 年开源发布以来AgentScope 智能体框架已逐步成为一款被企业用户广泛采用的 Agent Framework尤其是面向分布式、生产级可用的智能体场景。在阿里巴巴集团内部AgentScope Java Python已经是使用最广泛的一款框架了覆盖的具体业务线包括飞猪、淘宝闪购、虎鲸文娱、AIDC、阿里控股、淘天交易、淘天手淘、1688、千问 APP、高德、阿里云、蚂蚁国际、蚂蚁全球支付等业务线而在开源与阿里云公有云用户侧则广泛覆盖金融、交通/物流、消费零售、制造、能源、医疗、教育/政媒、互联网、SaaS、咨询等众多行业头部企业。