AgentScope Service 发布

• **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

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 协作仍不完整。

​

Control Plane

​

Managed Agents

​

Agent Teams

​

整体架构

​

总体架构

​

Managed Agents

​

Agent Teams 协作流程

• 成员类型可以异构。示例里的 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原生框架 + 控制面

​

控制面分布式协调

• 向上：协调类 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——协调的是”谁能跑这一轮”，不是状态数据本身。

​

自动编排 Agent Teams

• 预先定义的是”可用成员池”，不是”团队”。开发阶段只是把 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 可观测性——这一点和上一张控制台动态编排图完全一致，区别只在”团队怎么形成”。

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——协作状态不再只由发起方一个人掌握，而是团队成员共同维护的一份共享数据。

​

多智能体协作 Remote Subagent

• 本地优先，能不经过控制面就不经过。如果 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 而改变；框架差异被控制面的路由层吸收掉了。

​

生产部署架构

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

​

Agent 如何接入

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

​

Agent Framework

​

AgentScope

​

LangChain

​

Coding Agent

​

本地快速体验

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）

1. 在 Managed Agents 创建 Agent；
2. 创建一个 local Environment；
3. 打开 Sessions，绑定 Agent 与 Environment，发送第一条消息；
4. 回到 Dashboard 查看在线状态、事件与运行时信息；
5. 如需协作，再进入 Agent Teams 创建团队并观察任务与成员状态。
6. 如果要体验 BYO Agent 注册，可以使用源码仓库中的示例 agentscope-samples/agents/agentscope-paw，启动后即可在 dashboard 中看到智能体注册成功。

​

Roadmap & 总结

1. 围绕 AgentScope Framework 原生能力持续迭代，提供
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。