AI Agent 上线容易稳定难？阿里云 AgentLoop 推出“经验自进化”闭环治理方案

作者刘军Managed Agents 让 Agent 运行在云端环境中一方面推理、编排、Harness 管理等核心环节均由云端统一托管架构稳定性与运行效果由平台保障另一方面长周期任务不再依赖本地设备持续在线——即使个人电脑关机任务依然可以在云端持续运行。基于 AgentScope 2.0 的 Harness 内核与 Sandbox 隔离能力AgentScope 可以作为 Managed Agents 的底层运行时 Runtime为其提供稳定可靠的执行环境。把 AgentScope 2.0 中已经工程化的 Harness Agent 直接作为 Brain 运行时托管内核提供稳定的推理与 Harness 能力文件系统、workspace、工具执行则完全隔离在 Sandbox 沙箱环境。平台层负责租户、权限、版本、事件和执行面选型。控制面Agent、Environment、Memory、Vault、Deployment和数据面Session、Events、SSE把这些能力组织成可多租、可审计、可运维的托管产品。如果您看过我们此前发布的开源 Agent Builder[1]可以把 Managed Agents 理解为它的产品化升级底层运行时和主要代码路径没有换变化的是资源模型、API 契约、执行面边界以及面向多租户的治理方式。Managed Agents 背景市面上包括百炼、Claude Code、LangChain 等都有类似的 Managed Agents 产品发布。从本质上来讲我不认为 Managed Agents 产品与以往的低代码 Agent 平台在产品形态上有本质区别它们都是给你一个包含“Agent 定义 运行”能力的托管平台只不过在产品表现形式上Managed Agents 在 harness 时代更突出以下两点1. 不再让业务开发者拼装 Harness。传统平台常常把记忆维护、上下文压缩、状态恢复、工具权限和子任务回收拆成大量配置项。Managed Agents 把这些通用工程能力收进统一 Harness开发者主要定义与业务相关的 Skills、Tools、Subagents 和权限策略。平台保证机制的一致性与可升级性但最终任务效果仍取决于模型、system prompt、Skill 质量、工具返回值和业务评测。2. 让客户掌握工具执行和数据回传边界。对企业用户而言Agent 真正产生价值的地方是与企业数据资产连接而 shell、文件读写、MCP 和业务工具正是数据流动的入口。为此系统刻意拆分Brain推理编排与Hands工具执行Brain 负责下一轮推理、状态恢复和上下文管理Hands 负责真正接触文件、网络与业务系统。Hands 可以运行在平台托管的 Cloud Sandbox也可以运行在客户 VPC 内的 Self-hosted Worker。第 1 点真正改变的是平台的抽象层级。传统低代码平台往往让用户决定“什么时候总结记忆、超长上下文怎么截断、工具异常重试几次、子任务怎样回收”。这些选项看起来灵活实际上把 Harness 的工程责任转嫁给了业务开发者同一个 Agent 因为配置者经验不同效果和稳定性可能完全不同。Managed Agents 则只暴露业务差异例如角色提示、Skills、MCP、工具权限和 Environment至于压缩时机、会话恢复、工具结果淘汰、长期记忆刷新等交给持续演进的 Harness。平台升级 Harness 后所有 Agent 都能获得同一套工程改进而不必逐个修改流程图。第 2 点改变的是信任边界。模型决定“要调用什么”不等于模型所在的进程必须“亲自执行什么”。只要工具调用被表示为稳定的 schema、tool_use_id 和结果事件Hands 就可以被迁移到平台云沙箱或客户 VPC而不改变 Brain 中的推理循环。这让安全团队能够分别回答三个问题模型能看到哪些上下文工具能访问哪些网络和文件工具结果中哪些内容可以回传给 Brain这三个问题被拆开以后权限审核和故障定位都比“一整个 Agent 容器”清晰得多。以 Claude Managed Agents 为例它被开发者接受的一个重要背景是 Claude Code 已经证明了成熟 Coding Agent Harness 的产品价值。用户看到的是模型推理和任务结果平台真正托管的却是可恢复的会话状态、工程化运行策略和可替换的 Hands。AgentScope 2.0 采用了相似的分层思路HarnessAgent处理长任务、上下文溢出、状态恢复和任务委派Managed Agents 再向外补上多租户资源、Environment 与稳定的数据面契约。有了 Managed Agents 后Anthropic 在个人、企业用户之间几个不同层次都有对应的解决方案层层递进Claude Code CLI面向个人或单机开发工作流Agent 与本地工作区、终端和会话记录直接结合。Claude Agent SDK把 Session、事件流和工具交互 API 化适合嵌入企业应用身份、租户和资源隔离仍由接入方负责。Managed Agents进一步把 Agent、Environment、Session 与执行面变成托管资源由平台处理版本、权限和运行时治理。这三层的区别不只是“封装越来越厚”而是状态归属逐步上移为什么 AgentScope 2.0 适合做 Managed Agents 底座AgentScope 2.0 的模型抽象、工具与 MCP、消息与事件、状态存储、远程文件系统 / 分布式 BaseStore以及可插拔沙箱都为进程外持久化和多副本部署预留了扩展点。这使 Managed Agents 无需从零实现会话恢复、工具结果落盘与跨请求上下文延续数据面副本必须共享 AgentStateStore、Workspace 后端并正确处理 turn 租约与节点切换。其中Workspace 是 Agent 使用的逻辑目录Filesystem 和 Sandbox 是承载它的物理后端。两者通过 AbstractFileSystem 解耦同一套文件工具既可以指向本机目录也可以指向分布式 BaseStore 或 E2B 沙箱。正因为逻辑工作区与物理执行面分离Agent 定义才能在不改业务提示词的情况下切换隔离策略。具体来说HarnessAgent 在 ReActAgent 之上通过 Hook 装配长期运行所需的工程默认项例如工作区驱动的人格与知识AGENTS.md/MEMORY.md/KNOWLEDGE.md等注入系统提示。会话持久化按 sesionId 恢复 Agent 状态进程重启后仍能续聊。压缩与溢出处理Harness 默认启用 compaction 与 tool-result eviction并允许业务覆盖阈值或显式关闭。Skills / Subagents工作区 skills、任务委派task 等开箱可用。统一文件系统抽象本地、远程 KV、云沙箱E2B 等走同一套工具语义便于 Managed Agents 用 Environment 类型切换执行面而不改 Agent 业务定义。这些能力不是互相独立的名词。一次长任务可能先从 AgentStateStore 恢复消息与 agent state再由工作区 Hook 注入 AGENTS.md 和已安装 Skills推理过程中如果上下文逼近窗口上限压缩 Hook 会收敛历史而较大的工具结果可以被淘汰到文件系统中仅把可检索引用留在上下文里需要并行研究时主 Agent 又可以把任务交给 Subagent。最终无论文件系统落在本地、远程 KV 还是 E2B模型看到的工具语义保持一致。这种组合后的稳定性才是 Harness 作为平台内核的意义。另外HarnessAgent 与 Session 不是同一个生命周期。前者是在具备共享AgentStateStore与可恢复 Workspace 后端的数据面节点上重建的运行对象后者是有稳定 ID、事件序列和持久状态的产品资源。分清这两者才能做真正的水平扩展节点挂掉时可以丢弃 Java 对象但对话与长期记忆必须从共享状态恢复工作区是否连续则取决于 BaseStore、沙箱快照或客户侧持久化Local 目录并不具备这一保证。从单个企业智能体应用走向 Managed Agents关键不是改写推理内核而是把运行能力提升为稳定的平台资源。这里所说的“增加一层平台 API”绝不只是增加几个 Controller真正产品化还要补齐租户 ACL、Agent 版本快照、Session 状态机、append-only 事件、turn 租约、HITL ticket、Environment key、Worker 队列、共享协调存储和归档审计。Harness 让平台不必重写 AgentLoop但这些分布式职责仍是独立的工程系统。由此 Managed Agents 的完整形态就是SaaS 控制面负责资源治理AgentScope 2.0 提供运行内核FC Sandbox / E2B 或客户 Worker 承接不同信任边界下的 Hands。企业级 Managed Agents 平台详解总体部署架构核心组件图Control PlaneData Plane核心数据流转客户端通过session/event接口发送任务请求到 Managed Data PlaneBrainBrain 从共享状态恢复 Agent进而执行整个推理、编排流程如果中间有工具调用Brain 再按 Environment 配置将工具调用请求路由到 Worker可能是托管 Sandbox 环境、用户自管理 Sandbox 环境等。结合上面的架构分析与实现可以把整套系统读成四层创建一个 Agent 并运行下面先完成最小初始化登录 Managed Agents创建一个可复用的 Workspace Copilot Agent再演示 Local、Cloud Sandbox 和 Self-hosted 三种 Wroker 运行模式可以直观的看到“Agent 定义不变Hands 位置改变”。下文假设 Managed Agents 已启动在http://localhost:8080并已配置模型密钥如DASHSCOPE_API_KEY。0. 登录export BASEhttp://localhost:8080 TOKEN$(curl -fsS -X POST $BASE/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin} | jq -er .token)1. 定义示例 Agent我们创建一个「copilot 工作区助手」Agent包含简短的系统提示词配套 read_files、list_fukes、write_files 等工具便于演示不同工具在不同 worker 模式下的运行情况。AGENT$(curl -fsS -X POST $BASE/api/agents \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d { name: Workspace Copilot, description: blog demo agent, system: You are a workspace copilot. Prefer tools when listing or reading files. Keep answers concise., tools: [{ type: agent_toolset, defaultConfig: { enabled: true, permissionPolicy: { type: always_allow } }, configs: [ { name: read_file, enabled: true }, { name: list_files, enabled: true }, { name: write_file, enabled: true } ] }] }) AGENT_ID$(echo $AGENT | jq -er .id) echo AGENT_ID$AGENT_ID接下来是三种 worker 模式的展示同一个 Agent同一套 Brain 推理编排执行环境在三条 Hands 路径上的运行方式已有 Session 不支持中途切换 worker 执行环境要更换信任边界应创建新 Session以免同一条事件历史跨越不同执行语义。Worker in Local 模式Local 模式最适合开发联调。Session、Harness 推理、模型请求和工具执行都由 Managed 集群发起文件与 shell 直接落在 Brain 进程可见的本地环境中。在Local模式下Environmenttypelocal文件系统与若启用的shell 都在托管集群宿主机命名空间内完成没有独立 Hands 队列也不调用云沙箱。适合开发联调与可信内网。Worker in Cloud Sandbox 模式Cloud Sandbox 保留托管 Brain但把文件和 shell 移入独立沙箱。Harness 推理、模型请求以及工具调用的发起方仍在 Managed 集群真正的命令执行和文件读写发生在 FC Sandbox / E2B 兼容环境中。Agent 通过 E2B 客户端协议申请容器并在容器内执行 shell / FS 操作Brain 主动发起调用Worker 不参与。若使用兼容 E2B 协议的 Aliyun FC Sandbox需要先准备服务地址、模板和 API Key。Cloud Sandbox 的托管边界可以拆成三个动作创建沙箱、在沙箱里执行、在 Session 结束或超时后回收/持久化。Managed Agents 通过E2bFilesystemSpec把文件和 shell 工具映射到同一沙箱上下文isolationScopeSESSION时不同 Session 默认不会共享工作目录。若选择快照或 TAR 等持久化模式恢复策略还需要与AgentStateStore一起考虑恢复了模型上下文却没有恢复文件或反过来都会造成“Agent 记得做过、工作区却不存在”的不一致。生产系统必须把两者当作一个恢复单元设计。Worker in Self-hosted 模式Self-hosted 把 Hands 进一步移动到客户环境。Brain 仍在 Managed 集群中完成 Harness 推理但工具任务进入队列由客户侧 Worker 主动出站轮询、管理本地工作目录或沙箱并把结果回传给 Brain。整个过程中Brain 不需要进入客户网络。在 Self-hosted 下Brain关闭本地 shell/FS 实执行把相关工具注册为外化 schema模型一旦tool_use事件落库并进入挂起/排队由用户侧 Worker 持 Environment Key出站poll → 管理本地工作目录并执行或接入客户自有沙箱 → 回传user.tool_result续跑。这与 Cloud Sandbox「Brain 主动打沙箱 API」正好相反执行发起权在用户侧是否使用以及如何管理沙箱也由客户侧实现决定。Self-hosted 的目标场景是让数据库、代码仓库和发布系统等企业资源留在客户边界内但当前参考 Worker 开箱支持的范围是内置 shell / FS 工具。数据库、自定义业务工具与内网 MCP 仍需要后续 Worker 扩展 SPI或由使用方自行在 Worker 外封装。对于已经接入 Worker 协议的工具Brain 能看到 schema、调用参数和最终回传结果但不必直接连入客户 VPCWorker 只需主动向平台发起 HTTPS 请求并可在回传前做结果脱敏、大小限制和审计。一个更复杂的 Agent Team 编排示例定义多个 Agent下面用 AgentDev 场景展示一个三角色团队输入是一项 Java 库发布规划任务Repo Surgeon 从代码质量视角给出检查项只拥有工作区读取与检索能。Ops Publisher 从发布流程视角生成工单草案在本次演示中只生成文本草案外部 MCP 接入作为可选配置单独说明。Team Lead 汇总风险与验收清单Team Lead 尽量不直接接触业务数据只负责委派和汇总。拆成三个 Agent 不是为了堆叠角色而是为了分别约束工作区权限、外部系统接入和汇总职责这样做的收益是最小权限与独立审计而不是把所有工具塞进一个超级 Agent 后只靠提示词约束。先创建可直接参与 fan-out 的 Ops Publisher。它只生成发布草案不调用外部系统因此不会让/api/multiagent/run卡在人工确认阶段OPS_BODY$(jq -n { name: Ops Publisher, system: Draft changelogs and ticket outlines. Do not invoke tools or modify external systems., tools: [{ type: agent_toolset, defaultConfig: { enabled: false, permissionPolicy: {type: deny} }, configs: [{ name: read_file, enabled: true, permissionPolicy: {type: always_allow} }] }] }) # 发布规划 Agent本次只生成文本草案 OPS$(curl -fsS -X POST $BASE/api/agents \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d $OPS_BODY) OPS_ID$(echo $OPS | jq -er .id)如果要在生产中接入工单 MCP可在 Agent body 中增加如下片段enableTools只暴露明确允许的工具URL 与工具名必须替换为真实值{ mcpServers: [{ name: ticket-mcp, url: https://mcp.example.com/tickets, transport: http, enableTools: [draft_ticket] }] }如需发布 Skill也可以在确认 Workspace 已安装对应内容后增加skills: [{type: workspace, name: release-notes}]。当前mcp_toolset.defaultConfig.permissionPolicy不会进入ToolConfirmationMiddleware因此高风险 MCP 写操作还需要在 MCP 网关侧做身份、审批与幂等控制不能只依赖 Agent body 中的always_ask。随后创建只读访问代码工作区的 Repo Surgeon# 操作用户侧资源 —— 例如「代码/仓库」类 Agent偏 filesystem tools skills REPO$(curl -fsS -X POST $BASE/api/agents \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d { name: Repo Surgeon, system: You review the user workspace in read-only mode and report release risks., tools: [{ type: agent_toolset, defaultConfig: { enabled: true, permissionPolicy: { type: always_allow } }, configs: [ { name: read_file, enabled: true }, { name: grep_files, enabled: true }, { name: list_files, enabled: true } ] }] }) REPO_ID$(echo $REPO | jq -er .id)如果已安装代码审查 Skill可再加入 “skills”: [{“type”: “workspace”, “name”: “code-review”}]。最后创建 Team Lead。它保留委派与结果收集工具并通过真实 MultiagentSpec 记录前两个成员当前运行入口不会仅凭这个字段自动启动成员实际执行仍由下面的 Harness 委派或平台 fan-out 发起。LEAD_BODY$(jq -n --arg repo $REPO_ID --arg ops $OPS_ID { name: Team Lead, system: You coordinate Repo Surgeon and Ops Publisher. For a direct task, delegate concrete work and collect results. When the prompt already contains member results, do not call tools or spawn sessions; only summarize risks and produce the final checklist. Use sessions_pending_completions for finished child sessions and wait_async_results only for the generic async inbox., tools: [{ type: agent_toolset, defaultConfig: { enabled: true, permissionPolicy: {type: always_allow} }, configs: [ {name: sessions_spawn, enabled: true}, {name: sessions_list, enabled: true}, {name: sessions_pending_completions, enabled: true}, {name: wait_async_results, enabled: true} ] }], multiagent: { type: agent_team, agents: [ {type: agent, id: $repo}, {type: agent, id: $ops} ] } }) LEAD$(curl -fsS -X POST $BASE/api/agents \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d $LEAD_BODY) LEAD_ID$(echo $LEAD | jq -er .id) printf OPS_ID%s\nREPO_ID%s\nLEAD_ID%s\n $OPS_ID $REPO_ID $LEAD_IDMultiagentSpec的 wire schema 是type agents[]成员引用包含type、id和可选version。wait_async_results用于阻塞等待通用异步 inboxsessions_pending_completions用于枚举已经完成但尚未消费的子 Session 结果。两者服务于不同的异步模式因此 Team Lead 同时启用它们但应由 system prompt 明确什么时候使用哪一种。编排在一起系统提供两种不同的多 Agent 运行方式Harness 原生委派Team Lead 在推理过程中使用sessions_spawn/ Subagent 工具动态拆解任务父子任务之间存在明确的委派与结果回收关系。平台 fan-out/api/multiagent/run为多个 Agent 分别创建 Managed Session并把同一消息顺序或并行发送给它们适合独立分析、批处理和投票。深入了解工作原理前文从使用者视角介绍了 Brain、Hands 协调工作过程并通过一个 Agent Team 示例演示了多 Agent 编排场景。下面进一步拆开控制面、数据面与 Worker说明每一层保存什么状态、承担什么故障责任以及 AgentScope 2.0 在其中扮演什么角色。一句话控制面管「定义与权限」数据面管「跑起来并记下来」Worker 管「在谁的机器上动手」AgentScope 2.0 的HarnessAgent 文件系统/沙箱抽象是数据面与 Hands 的内核SaaS API 做好平台层语义建设不重新实现推理循环。控制面控制面负责“定义什么可以运行以及谁可以使用它”。它管理 Agent 静态定义及其版本也管理 Model、Skills、MCP、Tools、Environment、Memory、Vault 和 Resources 等可复用资源。资源既可以属于单个用户并按 owner / ACL 隔离也可以由平台全局预置例如公共 Skill、MCP 目录和内置工具集。这些资源可以按“定义、引用、挂载”三种关系理解。Model、Tools、MCP、Skills 进入 Agent 版本定义Environment 独立存在由 Session 引用Memory Store、Vault、Files/Resources 则在 Session 创建时挂载。全局预置资源提供平台默认能力用户资源带 owner / share ACL。这样既避免每个 Agent 重复复制公共 Skill也不会因为共享目录而让不同租户相互看见数据。控制面还承担变更治理。Agent 更新生成新版本旧 Session 可以继续记录并恢复当前已支持的历史字段Environment key 可以 rotate资源可以 archive 而不是立即物理删除高风险内置工具权限随版本记录。对生产平台而言这些能力往往比“能否调用一个新模型”更关键因为它们决定回滚、灰度和事故追责是否可行。Environment 与 Session 容易混淆但两者属于不同层次。本文采用如下边界Environment 归属控制面它是「执行面模板」local / sandbox / remote / self_hosted config environment key可被多个 Session 引用带归档与分享本身不产生对话事件。Session 归属数据面它是 Agent × Environment 的一次运行实例带状态机与事件日志创建参数会引用控制面的 agentId / environmentId但生命周期 APIevents / stream / interrupt是数据面核心。因此发起 session →数据面下一节展开。定义 Environment →控制面POST /api/environmentsrotate keyarchive。数据面数据面负责“让一个记录了 Agent 版本的 Session 真正运行起来并完整记录过程”。它承载模型调用、ReAct loop、Harness hooks、turn 租约、Session 状态机、事件持久化与 SSE 推送也处理 interrupt、HITL 和外化工具结果续跑。这些操作不是普通 CRUD 的补充而是围绕状态机展开创建 Session 记录 Agent 版本和 Environment 引用user.message把状态从 idle 推向 running工具确认把 requires_action 恢复为 runninginterrupt 尝试取消当前 turnarchive 终止后续使用但保留审计历史delete 才清理会话及事件。客户端应该根据事件驱动 UI而不是轮询某个内部线程是否仍然存活。数据面由对等 SaaS 副本组成请求可以到达任意实例。副本先通过agentId找到控制面的版本定义再根据 Agent 版本、Environment 与挂载信息计算构建键命中缓存就复用HarnessAgent未命中才重新构建。每个 turn 都通过包含userId、sessionId的RuntimeContext定位会话状态因此这里的“无状态副本”是指不持有不可替代的权威状态而不是每个请求都重新创建 Java 对象。RuntimeContext可以理解为一次运行的“身份与资源定位器”而不是把所有状态塞进一个 Map。userId决定多租命名空间与 ACLsessionId定位可恢复的短期 brain stateEnvironment 决定文件系统/沙箱实现Memory Store 与 Vault 则在构建阶段解析成文件系统路由和凭证。Harness 只依赖这些稳定抽象因此同一个请求打到另一台副本时可以重新装配出语义等价的运行环境。数据面实际托管了四类生命周期不同的状态这四层不能用一个“保存对话历史”概括。比如 Session 事件能证明模型曾请求写文件但不能代替文件本身AgentStateStore 能恢复上下文却不自动恢复外部数据库的副作用。恢复流程必须分别恢复每一层再用事件 ID、tool call ID 和资源引用把它们重新关联起来。当 Harness 推理需要调用工具时具体怎么执行由 Environment 决定。Cloud Sandbox 直接复用 Harness 的 filesystem / sandbox 抽象由 Brain 发起 E2B 兼容调用Self-hosted 则把工具替换为 schema-only 定义在agent.tool_use后挂起 turn经 work queue 和 Worker 协议回传结果。AgentScope 2.0 在这里的角色非常明确提供 HarnessAgent 与 FS/Sandbox 抽象保证「效果默认项」和「执行面可替换」Managed Agents 负责租约、事件契约、多租与 ACL而不是再包一层私有化的 ReAct。WorkerWorker 关注工具如何从 Brain 到达真正的执行环境系统有两条路径区别在于谁发起工具调用、谁管理沙箱生命周期。在全托管模式下Brain 负责创建和回收 Sandbox也主动通过 AgentScope 提供的 E2B 兼容 API 发起文件或 shell 调用。后台可以由 FC Sandbox 等兼容服务承接工具进程与工作目录都位于沙箱实例中。平台掌握完整句柄因此可以统一设置超时、隔离范围和持久化策略。在 Self-hosted 模式下Brain 收到模型的 tool call 后不会连接客户 VPC而是持久化agent.tool_use并创建 work item。客户侧 Worker 主动 poll 队列在自己的主机或沙箱中执行工具再通过user.tool_result回传结果使 Brain 恢复下一轮推理。两者在故障恢复上的责任也不同。全托管模式下Brain 知道沙箱句柄并可以统一设置超时、快照和回收策略Self-hosted 下Brain 只知道 work 状态和工具结果客户 Worker 必须负责本地沙箱是否仍存活、重复任务是否安全、结果是否需要脱敏。平台提供协议和状态机但不能替客户定义业务工具的幂等语义。Work 状态机为queued → starting → active → stopping → stopped。部署独立 Worker 时需要同时配置 Brain 和客户侧进程。下面给出最小启动方式与生产检查项。总结AgentScope 2.0 定位面向企业级分布式场景它既可以做分布式 Agent Framework用来开发企业内的 DataAgent、SreAgent 等又可以用同一套 Harness 撑起企业内的 Managed Agents成为 Managed Agents 底层的 Agent Runtime。可以让企业不必在「自己拼积木」和「完全黑盒托管」之间二选一同一套 Harness 内核两种模式都能实现。相关链接[1] AgentScope Builderhttps://github.com/agentscope-ai/agentscope-java/tree/main/agentscope-examples/agents/agentscope-builder[2] 文档https://java.agentscope.io[3] GitHubhttps://github.com/agentscope-ai/agentscope-java