深入解析 AgentScope Service：如何实现 LangChain/Claude/DeepSeek 等多框架统一接入？

作者：刘军

AgentScope Java 社区开源发布 AgentScope Service 组件，从设计定位上与 Python 开源版本基本对齐，面向企业级分布式智能体场景，通过控制面组件为 AgentScope 数据面智能体提供多租户、可视化调试、多智能体编排能力。

同时，AgentScope Service 还支持 Claude、DeepSeek Harness、Langchain 等多种形态智能体接入。

AgentScope Service 为智能体调试、分布式部署提供开源解决方案，如果您需要企业级智能体编排、Teams 编排、观测评估等能力，请访问文章最后给出的阿里云 AgentTeams、AgentLoop 产品了解详情。

• AgentScope Service 是一个控制面。 为企业内的所有 agent 提供智能体注册、查询、分布式协调服务，兼容 AgentScope、LangChain、ADK、Claude / Qoder 等主流 Agent 运行时，让企业可以有一个集中的 Agent 指标查看入口，同时可以对运行中的 Session 会话进行上下文压缩等操作；
• AgentScope Service 提供低代码 Agent 创建与部署能力。 底层基于 AgentScope Harnes 运行时，可以让您快速将多个 Agent 运行在一套统一管理的 Managed Agents 平台上，平台提供 Harness 能力托管，工具执行则可以委托给用户自己控制的 sandbox 沙箱；
• 注册在 AgentScope Service 中的智能体，可以被组建为一个或多个 Teams 团队。 不论是自己部署的 AgentScope 运行时还是低代码托管的 agent harness 运行时，都可以被编排在一起，共同协作完成更复杂的任务。

什么是 AgentScope Service

AgentScope Service 的目标不是替换你现有的 Agent 框架，而是提供一层统一控制面，让你把用不同框架、不同技术栈（Claude、OpenClaw、QwenPaw等）搭建的智能体统一管控起来。

今天，构建企业级 Agent 已经有很多不同的选择。AgentScope 作为一款优秀的 Agent Framework，为企业提供了构建智能体的完整方案。但传统 Agent Framework 并不是当前唯一的智能体构建方式，我们看到 Coding Agent 产品正延伸到更多领域，比如使用 Claude SDK、Qoder CLI 等构建企业级智能体也正成为很多企业用户的选择。

1. 使用 Agent Framework。 用 AgentScope、LangChain、ADK 等在业务服务里直接跑 agent loop。灵活度高，但租户隔离、版本发布、Session 恢复、HITL、事件落库、跨副本协调都要自己补齐。每个业务线做一遍，标准很难对齐。

2. 使用 Coding Agent 或个人工作区助手。 如 Claude Code、各类 Coding Agent、个人工作区助手。启动快、体验好，但状态落在本机，难共享、难审计，也不适合多团队共管。电脑关机，任务也常常跟着停。

3. 使用低代码或 Managed Agents 平台。 传统低代码平台通过可视化节点拼装 Agent，上手容易，却常把记忆管理、上下文压缩、工具组装等拆成大量配置项，让用户为效果和稳定性负责。Managed Agents 则强调云端 Harness 能力全面托管，让用户不再为担心、客户 VPC 内 Hands、以及企业级多 Agent 协作仍不完整。

这些路径并不互斥，一家公司里，研发可能用 Coding Agent，业务中台用 AgentScope，新项目想直接上托管 Harness------这很常见。AgentScope Service 不绑定任何智能体框架或平台，它为所有智能体运行时提供统一的管控能力。

Control Plane

Control Plane（控制面）是 AgentScope Service 的核心组件，所有 Agent 应用都通过控制面进行统一注册，通过 SDK 或 Sidecar 方式支持主流 Agent Framework（AgentScope、LangChain、ADK）以及 Claude、Qoder 等注册与接入。

Dashboard 则是控制面的可视化 UI 控制台，为整个集群提供在线 Agent 列表、部署实例信息、活跃 Session 信息、token 消耗等全局观测信息，方便了解集群工作状况。

此外，还可以在 dashboard 中查看 Session 会话信息，查看活跃 Session 的实时上下文状态（各部分数据占比），动态调整或压缩会话上下文，介入会话过程等。

Managed Agents

Managed Agents 是由 agentscope-builder 平台升级而来，它的定位仍旧是一个低代码 Agent 平台，为开发者提供 Agent 定义、Agent 托管运行的 SaaS 化平台能力。同时更强调推理与工具执行的分离，推理 Harness 能力更彻底的托管，工具执行则开放给用户更多的控制权。

Agent 定义总体围绕 AgentScope Harness 的核心设计理念设计，首先定义好 Workspace、Memory 等基础概念，通过将 workspace、memory 与 Agent 关联即可创建一个智能体。

定义 Workspace：

定义 Agent：

此次升级最大的变化是底层托管运行时逻辑与架构 -- Managed Agents。平台总体将静态定义（Agent、Workspace）与动态运行（Environment、Session）区分开来，通过 Environment、Session 等来编排 Agent 运行时行为。

创建 Session，绑定 self_hosted sandbox 运行时 environment：

Session 创建后，本身并不会启动 SSE Event 事件流，用户主动发起 user message 才会启动会话，执行整个推理过程。如下图，你可以在控制台 chat 页面发送 user message：

创建 Agent → 创建 Environment → 创建 Session → 发送第一条消息 → 在 Dashboard 观察事件流。Session 创建本身不会立刻跑 Agent。对长任务场景，Managed Agents 尤其关键的是可恢复：事件落库、状态可重建、HITL 可暂停续跑。前端刷新或服务副本切换，不应等于任务从头开始。

在运行架构上，设计与 Claude Managed Agents 非常类似，Harness 基础设施与运行时全托管（底层依赖 AgentScope Harness Runtime），基于 Brain/Hands 分离的架构让用户对工具执行环境有更多控制权。部署架构上，分为控制面、托管数据面两大组件，具体可参考后面的部署架构章节。

Agent Teams

注册在 AgentScope Service 控制面的所有智能体，不论是使用框架开发部署、自行注册到控制面的（Langchain、AgentScope、ADK、Claude SDK等）智能体，或者是使用 Managed Agents 低代码方式直接创建的托管 Agent，都可以把它们按照你想要的方式编排在一起，形成一个可以互相协作的 Agent Teams 来协作处理复杂。

在 AgentScope Service 设计中，Teams 团队不是聊天室，而是一套可运营的协作单元：任务可认领、计划可审批、成员可唤醒，状态也不会因为某个 Session 结束而全部消失。一个常见模式是 Lead 负责任务拆解与验收，Member 按能力认领调研、编码、核验等子任务，平台负责消息路由、任务板与生命周期，而不是让业务代码手写一套临时多进程通信。

值得特别说明的是，AgentScope 框架原生支持 Agent Teams 能力，这套机制是基于 AgentScope Service 控制面做分布式任务管理与调度，所以您既可以使用 AgentScope Framework 原生的 Teams 能力在主 Agent 编码阶段实现多 Agent 编排，也可以在控制台上根据需求将多个独立的 Agent 动态编排在一起完成某一项复杂任务。具体取决于您的使用场景。

整体架构

总体架构

Human 通过 Dashboard（浏览器操作）或 REST API（SDK / curl / 第三方系统集成）两条入口进入 AgentScope Service Control Plane；控制面之下统一管理四类 Agent 接入方式：AgentScope 原生接入、LangChain 通过 instrument() 接入，Claude 与 QwenPaw 则通过 Sidecar 旁路接入。

Managed Agents

Agent Teams 协作流程

一个 Team 里的成员不要求来自同一个框架、同一种托管方式。用户在控制台里选择若干个已经注册到控制面的 Agent，指定谁是 Lead、谁是 Worker，就完成了一次编排------Lead 负责创建与分配任务，Worker 负责认领与执行，协作状态则统一交给控制面维护：

图里几个关键点：

• 成员类型可以异构。 示例里的 Lead 与 Worker 1 是 Managed Agent（控制面为其创建绑定 teamContext 的 Session，直接投递 user.message 起跑），Worker 2 是自行部署的 AgentScope 原生运行时，Worker 3 则是 LangChain（或经 Sidecar 接入的 Claude）------控制面对不同成员下发的加入方式不同（Managed 走 find-or-create session，BYO 走 team_join 命令），但暴露给 Lead 的协作模型是一致的：都是 Team 里可以被分配任务、可以收发消息的成员。
• Lead 分配，Worker 认领，两条路径都存在。 Lead 创建任务时可以直接指定 owner（assign 给某个 Worker），该 Worker 收到后走 claim → start → complete；Lead 也可以创建一个不指定 owner 的任务扔进 Task Board，由空闲的 Worker 自己 POST .../claim 完成 self-claim------两种模式在同一个 Task Board 上并存，不需要 Lead 时刻盯着谁在忙。
• 消息分单播和广播。 Mailbox 支持指定 to=member 的定向消息（比如 Lead 单独提醒某个 Worker），也支持不填 to 的广播（所有成员可见），二者共用同一套持久化通道。
• 协作状态不挂在某一次会话上。 Task Board 和 Mailbox 的数据独立于任何单个成员的 Session 生命周期：某个 Worker 的进程重启、Session 结束，不影响任务是否还在、消息是否还能追溯------这也是为什么某个 Worker 崩溃后，控制面能够识别成员状态变为 Lost 并触发恢复，而不是直接丢掉整个团队的进度。

AgentScope原生框架 + 控制面

AgentScope 框架本身提供了完善的企业级 Agent 解决方案，支持 Harness、Agent Teams、Multi-agent 协作、Sandbox 隔离等，在真正的企业级部署架构下，很多能力依赖分布式组件协调，AgentScope Service 控制面为 AgentScope 提供了原生分布式协调能力。

控制面分布式协调

AgentScope HarnessAgent 一旦从单实例走向多副本部署，会话状态、工作区文件、沙箱快照与并发锁、跨副本消息、异步工具、子任务与 Turn 并发控制，都不能再假设"进程内存里就是权威数据"。

下图展示的是运行时拓扑：多个 HarnessAgent 副本如何分别与 Control Plane、AgentStateStore 后端交互，而不是 DistributedStore 的接口定义。

图中有两条互不经过彼此的独立链路，这一点很关键：

• 向上：协调类 API 调用。 每个 HarnessAgent 副本通过 SDK 调用 Control Plane，托管的是开发者实际感知到的四类 Harness 能力：底层分别对应 BaseStore、SandboxSnapshotSpec / SandboxExecutionGuard、MessageBus、TaskRepository、SessionTurnGate、AsyncToolRegistry 等接口，协调类状态落在控制面自己的 Postgres 里，业务方不需要另起一套基础设施。
• Workspace 共享： 工作区文件（MEMORY.md、skills/、sessions/ 等）以及沙箱快照与并发锁，让同一个工作区可以被任意副本读写、恢复；
• Agent Teams： 跨副本的消息投递与子任务委派，Lead / Member 之间的单播、广播与任务认领不受具体运行在哪个副本影响；
• Session 并发控制： 同一 Session 在多副本下的 Turn 级并发闸门，避免两个副本同时推进同一轮对话；
• 异步工具执行： 后台运行的长耗时工具，其执行状态与结果可以被任意副本感知和回收。
• 向下：直连会话状态后端。 AgentStateStore（对话上下文、压缩摘要、权限规则、Plan Mode 状态等）不经过控制面 ，而是由每个副本直接连接业务自备的 Redis / MySQL / Postgres / OSS。控制面只是可选地通过 Session 并发控制（SessionTurnGate）配合 AgentStateStore 自身的 getVersioned / saveIfVersion 乐观并发（CAS），减少多副本下重复触发同一个 LLM Turn------协调的是"谁能跑这一轮"，不是状态数据本身。

对开发者而言，这意味着只需在 HarnessAgent.builder() 上配置一个 distributedStore（协调类组件走 ControlPlaneStores.fromEnv()，AgentStateStore 单独指定一个共享后端），即可让 Agent 具备真正的水平扩展能力，而不必逐个自研会话恢复、文件共享、沙箱快照与任务队列。

自动编排 Agent Teams

AgentScope 框架本身有一套闭环的 Agent Teams 能力，组队的触发方式与控制面直接编排不同：开发阶段并不需要提前把成员编排成某个固定的 Team 结构，只需要像 Subagent 模式一样，给 Main Agent 预先注册好一批可调用的 Subagent（agentRef）；到了运行期，只要 Human（或上游系统）发给 Main Agent 的消息里带上"需要组队处理"的任务描述，Main Agent 自己就会判断要不要组队、挑哪几个预注册的 Subagent 来当 Worker，动态创建一个 Team：

上图几个关键点：

• 预先定义的是"可用成员池"，不是"团队"。 开发阶段只是把 reviewer、security-scanner、perf-tester 这些 Subagent（跟 Subagent 模式共用同一套 agentRef 注册机制）挂到 Main Agent 上，谁跟谁组队、什么时候组队，这一步完全没有决定，也不需要提前设计好 Lead / Worker 结构。
• 组队的触发点是一条运行期消息，不是代码或控制台配置。 Human 发给 Main Agent 的一条普通消息里，只要带着"组个团队来处理"这类意图，Main Agent 的推理过程就会决定调用 createTeam（需要时再用 spawnMember 追加成员），把自己设为 Lead、把挑中的 Subagent 实例化成 Worker------这个决策发生在一次 LLM 推理里，既不用人工预先编排，也不用改一行代码。
• 组队之后走的是同一套 Team 协作机制： Lead 与各 Worker 共享同一个 TeamClient（Task Board + Mailbox），可以是不依赖 Control Plane 的 LocalTeamClient（闭环，直接基于 BaseStore 做乐观并发），也可以接入 ControlPlaneTeamClient 换取跨副本协调与 Dashboard 可观测性------这一点和上一张控制台动态编排图完全一致，区别只在"团队怎么形成"。

这套能力和前面提到的 Subagents 模式用的是同一批 Subagent 定义，但协作方式完全不同，容易混淆，值得专门对比一下：

Subagent 模式（单向委派，互相隔离）
    Main Agent ──task()──▶ Subagent A ──result──▶ Main Agent
    Main Agent ──task()──▶ Subagent B ──result──▶ Main Agent
    Subagent A 与 Subagent B 之间没有通信路径，也不共享任务列表
Agent Team 模式（对等协作，共享状态）
    Lead ──createTask / assignTask──▶ Worker A
    Worker A ◀── sendMessage / broadcastMessage ──▶ Worker B
    Worker A、Worker B 都能在共享 Task Board 上 claim 未分配的任务

• Subagent：单向委派，互相隔离。 Main Agent 通过 Task 工具把一段指令发给某个 Subagent，Subagent 在独立、无状态的上下文里执行，把结果原样报回 Main Agent；两个 Subagent 之间没有任何直接通信路径，也不知道对方存在，更不会共享任务列表------协作的全部逻辑都由 Main Agent 一个人持有。
• Agent Team：对等协作，共享状态。 Team 里的 Lead 和 Worker 共用同一个 Task Board 和 Mailbox：Lead 可以 assignTask 指定某个 Worker 做什么，Worker 之间也能通过 sendMessage / broadcastMessage 直接对话，未分配的任务谁空闲谁 claimTask------协作状态不再只由发起方一个人掌握，而是团队成员共同维护的一份共享数据。

一句话总结：Subagent 是"发指令、等结果"的层级委派；Agent Team 是"共享看板、互相认领、直接沟通"的对等协作。而这张图想说明的是，AgentScope 原生 Agent Teams 能让"从 Subagent 池组建一个对等协作的 Team"这件事，完全由 Main Agent 在运行时按需触发，不需要提前规划好团队结构------这与上一张控制台动态编排图（由 Human 在控制台上现场选人组队）是两种互补的路径，二者共享同一个 TeamTool / TeamClient 编程模型，可以按需选用。

多智能体协作 Remote Subagent

Agent Teams 或 AgentScope Subagent 委派的目标，不一定运行在同一个进程里------可能是同一 HarnessAgent 内的本地 Subagent，也可能是另一个 Managed Agent（跑在 Dataplane），甚至是一个通过 instrument() 接入的 LangChain Agent。

对于远端 AgentScope Service Control Plane 在其中扮演的角色，是让 Agent A 发起一次 delegate 调用时，不需要关心目标到底在哪、是什么框架：

上图体现了使用控制面实现 remote subagent 调用的流量代理能力，而不是一次特定的 API 设计：

• 本地优先，能不经过控制面就不经过。 如果 techlead 恰好是 Agent A 同一个 HarnessAgent 进程内声明的本地 Subagent，委派直接走进程内调用，控制面完全不参与------这是延迟最低、也是最常见的路径。
• 跨实例 / 跨框架时，控制面负责"发现 + 鉴权 + 代理"三件事： 先确认 Agent A 与 techlead 之间存在合法的协作关系（同一 Team、白名单 ACL），再按 Agent ID 在舰队注册表里查到目标实例------这里的目标可能是一个 Managed Agent（转发到 Dataplane 的 Session Turn 接口），也可能是一个通过 aistio.instrument() 注册上来的 LangChain Agent（转发到其上报的 chat 端点）------最后把请求代理转发过去，并把响应原样透传回 Agent A。
• Agent A 全程不知道对方是什么框架。 对发起方而言，delegate("techlead", ...) 的调用方式不因为目标是本地 Subagent、Managed Agent 还是 LangChain Agent 而改变；框架差异被控制面的路由层吸收掉了。

这也是为什么前面在"如何接入"里强调 AgentScope、LangChain、Claude 可以用不同方式接入同一个控制面：一旦接入完成，它们就都具备了被其他 Agent 找到、委派任务、并拿到结果的能力，而不需要每一对框架之间单独打通。

生产部署架构

四类平面的职责可以这样理解：

产品上还有一个关键拆分：Brain 与 Hands。

• Brain： 管理上下文、推理、工具决策和事件日志；由平台托管的 AgentScope Harness 承担。
• Hands： 决定工具在哪里执行。可选 local、sandbox（如 E2B）、remote、以及客户侧出站 Worker 的 self_hosted。

这意味着企业可以分别回答三个问题：模型能看到哪些上下文？工具能访问哪些网络和文件？工具结果中哪些内容可以回传 Brain？信任边界被拆开后，权限审核与故障定位都会清晰得多。

这也解释了为什么「托管」不等于「所有数据都必须离开客户环境」。对脱敏可在云侧推理的场景，可用托管沙箱；对必须触达内网系统或敏感文件系统的场景，可把 Hands 放在客户 VPC，由出站 Worker 执行工具并回传结果。Brain 仍然负责编排与状态恢复，只是执行面被替换了。

对希望进一步理解 Turn 路径、事件契约与 schema 边界的读者，我们另有一篇技术向文章：AgentScope Service 技术解读（java.agentscope.io/v2/zh/blogs... ）。

Agent 如何接入

AgentScope Service 同时服务两类用户：

1. 平台服务型团队，提供 SaaS 化平台方便快速构建托管智能体------用 Console / API 创建 Managed Agent。2. 业务研发团队，已有不同技术方案开发的 Agent 应用、希望纳入统一治理------通过扩展 / SDK / Sidecar 接入控制面。

两条路径可以并存，很多团队会先用 Managed Agents 跑通新产品，再把存量自研 Agent （BYO）逐步纳入 Dashboard。

下来我们分析就分析第 2 种模式，自己开发部署的 Agent 如何接入 AgentScope Service 控制面，总的来说有 SDK、Sidecar 两种接入方式，对于 Agent Framework 类应用，可以通过引入 SDK 实现到控制面的注册，可以通过。

Agent Framework

AgentScope

AgentScope Java 目前原生支持 Agent 应用接入，通过引入 agentscope-extensions-aistio 依赖，即可自动将现有 AgentScope Runtime 注册到控制面，与 Managed Agent 一同出现在 Dashboard。会话状态、健康信息与运行时观测沿同一套契约上报。

同时 AgentScope 分布式部署需要的 Agent Teams 跨副本的消息投递与子任务委派、跨节点异步任务状态跟踪、Session 并发控制、Workspace 状态同步等，都可以由控制面提供原生支持。

LangChain

目前我们在社区提供了 python sdk ** **1 ，用户可以通过 aistio.instrument() wrapper 实现接入。对 LangChain / LangGraph 应用，控制面侧以旁路方式采集 Session 快照、上下文与运行时指标；主业务路径先成功，上报失败不影响推理本身。

这样一来，LangChain 开发的 Agent 也能进入 AgentScope Service 的舰队管理与 Session 观测，而不必重写业务链路。

DeepSeek Harness

AgentScope Service 支持把 DeepSeek Harness 开发的智能体注册到控制面，DSH 继续用自己的 loop 和 Web UI，以 DSH 插件的形式实现。

在不改 DSH 源码的基础上，只需要把 AgentScope Service 提供的拓展包装进 profile 即可（dsh plugin add 会写 profile 的 bundle 列表和依赖）。

# 本目录：agentscope-java/agentscope-service/aistio/sdk/dsh
cd /path/to/agentscope-java/agentscope-service/aistio/sdk/dsh
npm install
npm run build
dsh plugin --profile web add "$(pwd)"

源码启动 DSH 时把 dsh 换成 pnpm dsh。装好后可用下面命令确认配置树里出现了 # == @agentscope/dsh-aistio 或 id: aistio 这一层：

dsh --profile web --dump-config

此时，按如下命令启动 DSH 智能体进程：

export BUILDER_INTERNAL_TOKEN=local-dev-internal-token-at-least-32chars
export AISTIO_CONTROL_HTTP=http://localhost:8081
export AISTIO_AGENT_NAME=deepseek-harness
dsh --profile web

启动日志里应有类似：

[aistio] instrumented DeepSeek Harness as 'deepseek-harness' (contract :18091, control http://localhost:8081, team-coordination=true)
[aistio] registered <instanceId> at http://127.0.0.1:18091 with http://localhost:8081

本机可先探活契约端口：

curl -s http://127.0.0.1:18091/agentscope/health
# {"status":"ok"}

没有 BUILDER_INTERNAL_TOKEN 时，插件仍会起 /agentscope/*，但不会向 aistiod 注册，Dashboard 里也看不到实例。

更多框架如 Claude Agent SDK、Google ADK 等将陆续提供支持，具体请查看 roadmap。

Coding Agent

对于 Claude Code、QoderCli 等难以直接改二进制的 Coding Agent，则可借助 Sidecar 桥接：旁路观察本地 Session 目录与运行状态，上报到控制面，并承接压缩、终止等运营命令。

这条路径的意义在于：企业不必在「用最强 Coding Agent」和「纳入统一治理」之间二选一。研发提效工具可以继续跑在开发者环境，平台仍能看见它、管理它、在必要时干预它。

QwenPaw 等个人工作区助手理论上也可以通过 Sidecar 方式实现接入，具体请查看 roadmap。

本地快速体验

AgentScope Service 处于快速迭代阶段，如果你想先完整体验产品面，可以下载仓库源码启动，在本地环境快速体验。

1. 启动控制面、Managed Agents 数据面等所有组件（如上文中的生产部署架构图）：

git clone https://github.com/agentscope-ai/agentscope-java.git
cd agentscope-java

export DASHSCOPE_API_KEY=sk-xxx
cd agentscope-service
scripts/dev-down.sh && BUILDER_REBUILD=1 scripts/dev-up.sh

2. 打开 http://localhost:8080 ，输入用户名/密码（admin / admin）。

接下来就可以直接体验 Managed Agents 快速创建智能体了：

a. 在 Managed Agents 创建 Agent；

b. 创建一个 local Environment；

c. 打开 Sessions，绑定 Agent 与 Environment，发送第一条消息；

d. 回到 Dashboard 查看在线状态、事件与运行时信息；

e. 如需协作，再进入 Agent Teams 创建团队并观察任务与成员状态。

3. 如果要体验 BYO Agent 注册，可以使用源码仓库中的示例 agentscope-samples/agents/agentscope-paw，启动后即可在 dashboard 中看到智能体注册成功。

Roadmap & 总结

AgentScope Service 把不同模式构建的 Agent（Framework、Coding Agent、Managed Agents）等收敛在统一控制平面内，为 Agent 间协作提供统一视图。无论你从 Console 新建第一个 Agent，把 Harness 运行托管给 AgentScope Service 平台，还是把现有 AgentScope / LangChain / Claude 应用接入控制面，目标都一样------让企业拥有一站式的 Agent 管控与治理中心。

接下来，AgentScope Service 会沿着「更开放的接入、更完整的自动化、更强的事件驱动」继续演进。近期重点包括：

1. 围绕 AgentScope Framework 原生能力持续迭代， 提供更完善的面向企业级分布式场景的在线 Agent 能力。

2. 支持更多 Agent 框架与 Coding Agent 接入。 补齐并深化 LangChain、ADK、Claude、Qoder、OpenAI Agents 等适配，降低 BYO 接入成本，让异构Agent 进入同一契约更容易。

3. Automation。 围绕 Deployment、Cron、Webhook、Channel 扩展自动触发与闭环执行，让 Agent 从人主动发起会话，走向事件驱动的任务处理模式。

4. 更多事件驱动集成。 接入 GitHub / GitLab、钉钉、企微等研发与协作入口，把代码变更、工单、群消息直接变成 Agent Turn 或 Team Task。

阿里云提供 Agent 构建、Teams 编排、观测评估全生命周期平台，如果您需要企业级平台能力请关注：

• AgentTeams： agentteams.console.aliyun.com/

• AgentLoop： agentloop.console.aliyun.com/

相关链接：

1 python sdk / 智能体接入 SDK

github.com/agentscope-...

2 AgentScope Service

github.com/agentscope-...