开发一个能“跑通 Demo 演示”的智能体并不难。
难的是，让它在真实场景里稳定地完成任务。
长链路任务中途断裂、工具调用缺乏安全边界、上下文越跑越臃肿、本地脚本难以接入生产环境……这些才是智能体走向落地时，开发者每天面对的硬骨头。
过去，AgentScope 1.0 以“透明开发”为核心，让开发者能清晰可见智能体的消息流转、工具调用和协作过程，从而降低理解与调试门槛。如今，面对更复杂的真实场景，AgentScope 2.0 在延续透明理念的基础上，进一步聚焦真实场景下的稳定运行、安全控制与接入需求，带来一次更严肃、更完备、更整体的系统性升级。
AgentScope 2.0 继续保持开放的模型接入能力，支持 Qwen、Anthropic、DeepSeek、Gemini、OpenAI 等主流模型，并进一步扩展 Grok、Moonshot 等模型的支持。但 2.0 的重点不只是“接入更多模型”，而是让模型调用在复杂任务中更加稳定可靠。
在真实任务中，Agent 往往需要多轮推理和多次工具调用。一次模型接口失败、超时或不可用，都可能影响后续执行。为此，AgentScope 2.0 在模型层引入统一的重试与备用模型机制。开发者可以配置最大重试次数，也可以设置备用模型；当主模型调用失败时，框架可以自动尝试备用模型，尽可能保持任务执行的连续性。
模型接入部分的升级，让 Agent 不只是“能调用模型”，而是具备了更稳健的模型运行策略。对于需要持续推理和多步执行的任务来说，模型层的稳定性也成为 Agent 能否顺利完成任务的重要基础。
告别“黑盒回复”。在普通聊天应用中，消息或许只是文本；但在智能体执行需要看清每一步。
AgentScope 2.0 对消息模块进行了重构，通过统一的 Content Block 承载以上不同的消息类型。其中，DataBlock 支持 base64 与 URL 两类数据源，可以更好地兼容不同模型 API 的多模态与文件能力。
在此基础上，AgentScope 2.0 引入事件系统。一次 Agent 回复不再只是返回最终文本，而是可以流式产生模型调用开始、文本增量、工具调用、工具结果、用户确认、外部执行等事件。这让前端 UI 可以实时展示 Agent 的执行过程，也让人工确认、人工介入和外部工具执行成为框架内生能力。
例如，当智能体要执行某个敏感工具时，可以触发用户确认；当工具需要在外部环境中执行时，也可以等待外部执行结果后继续任务。
因此，消息模块与事件系统的升级，不只是延续了 AgentScope 对“透明”的强调，也让智能体的执行过程变得可展示、可交互、可干预。开发者看到的不只是最终答案，而是一个可以被持续观察和继续推进的智能体执行过程。
为了更好地发挥大模型的能力，智能体需要拥有更强的自主性：它不只被动地产生回应，还能够根据任务进展主动选择工具、读取信息、执行操作。
但智能体越能自主行动，就越需要明确权限的边界。
AgentScope 2.0 引入了更加系统化的权限系统，用来控制智能体在调用工具、读写文件、执行命令时的行为边界。工具调用不再是简单的允许或禁止，AgentScope 可以根据静态规则、工具类型和输入内容，判断一次操作应该被允许、拒绝，还是交给用户确认。
例如，文件读写工具会检查是否涉及危险目录和敏感文件；命令执行工具会分析高风险命令、动态 shell 结构和危险删除操作；对于未知或高风险行为，AgentScope 可以自动进入用户审批流程。
权限系统的引入，让智能体不只是“能调用工具”，而是能够在清晰可控的边界内自主执行任务。对于需要持续使用工具、访问文件或执行命令的复杂任务来说，安全边界也成为智能体能否稳定完成任务的重要基础。
处理长期任务不止是把历史对话塞进窗口就行。哪些该留？哪些该截？文件怎么避免重复读取？任务状态如何跨轮次延续？
AgentScope 2.0 的上下文管理进一步走向系统化，会结合任务状态、工具结果和文件读写过程管理上下文：
压缩结果不只是简单摘要，而是结构化保留任务目标、当前状态、关键发现、下一步计划和需要长期保留的信息；
工具结果自动截断，避免超长日志或搜索结果撑爆上下文；
内置文件读写新增缓存机制，并强制“先读后改”，减少重复 IO，提升性能和操作可靠性。
因此，上下文管理在 AgentScope 2.0 中不只是“压缩历史”，而是升级为支撑长期任务执行的系统策略。它让智能体能够更有组织地维护任务状态、控制上下文规模，并在持续推理和多次调用工具的过程中保持稳定。
真实业务往往需要接入专属日志、安全策略、上下文注入或模型调度逻辑。如果每次都要改框架源码，扩展成本会很高，也会影响框架本身的稳定性。
AgentScope 2.0 引入 Middleware 机制，让开发者可以在 Agent 的关键执行环节插入自定义逻辑，例如模型调用前后的日志追踪、工具执行前的安全检查、reasoning 和 acting 流程中的业务策略，以及 system prompt 构造阶段的动态上下文注入。
通过 Middleware，AgentScope 2.0 可以在保持核心框架稳定的同时，为不同应用场景留下足够灵活的扩展空间；这也延续了 AgentScope 1.0 的透明理念：框架不是黑盒，开发者可以清晰地理解它、介入它。
随着智能体能力变强，它不再只是调用模型，而是需要使用工具、访问文件、加载技能、连接 MCP 服务，并在不同环境中执行任务。如果这些能力都写进智能体运行逻辑里，一旦切换本地环境、容器环境或云沙箱，开发者就需要反复适配。
AgentScope 2.0 引入 Workspace，正是为了把“智能体要做什么”和“在哪里执行”分开，让执行环境成为可替换、可管理的系统组件。
Workspace 是 AgentScope 2.0 对智能体执行环境的抽象。它为智能体提供工具、MCP 服务、Skills 技能库以及上下文持久化能力，并将本地文件系统、Docker 容器、E2B 云沙箱等不同执行后端统一到同一套接口下。
这样，同一个智能体可以在不同环境中运行，而不需要改动运行逻辑。它的设计主要体现在三个方面：
第一，统一接口。WorkspaceBase 抽象出身份标识、生命周期、资源发现、上下文卸载和动态资源管理等通用能力，不同后端只需要实现同一套接口，就可以接入到 AgentScope 的执行体系中。
第二，组合解耦。智能体本身不直接依赖具体 Workspace，而是通过工具集（Toolkit）和指令（instructions）间接使用工具与资源。这样既保留了执行环境的可替换性，也保持了智能体运行逻辑的稳定性和可迁移性。
第三，池化支持。Workspace 内置预热池机制，支持提前批量初始化执行环境，并提供获取、归还和失效替换等管理能力。在面对 RL 训练中的并行 rollout 等场景中，它可以降低环境频繁创建的开销，提高资源复用和任务执行效率。
Workspace 的引入，让智能体不只是“能调用工具”，而是能够在可替换、可管理的执行环境中持续工作。对于需要在本地、容器或云沙箱之间切换的复杂任务来说，执行环境的抽象也成为智能体稳定运行和灵活扩展的重要基础。
智能体不该只停留在 Terminal 或单进程脚本里。真实场景需要的是能被前端、工作流或外部系统稳定调用的服务。
AgentScope 2.0 将原本 AgentScope Runtime 中的 Agent Service 能力完整合并至主库，打通开发与部署的割裂。
过去，如果智能体核心逻辑和运行时服务能力分散在不同体系中，开发者需要在本地开发、接口封装、状态管理、日志恢复、沙箱执行和部署运维之间反复衔接。
AgentScope 2.0 将这些能力整合进来，是为了减少这种割裂，让智能体从开发阶段开始就按照可服务化、可恢复、可观测、可安全运行的方式构建。
通过标准化服务接口，智能体可以以流式方式对外输出执行过程，支持前端实时展示；通过 Session 日志恢复，任务可以在中断后继续；通过工具后台运行管理，长耗时工具可以更稳定地执行。Agent Service 的合并，让智能体不只是“能在本地跑起来”，而是能够作为稳定服务接入不同应用和执行场景，成为智能体系统持续运行的重要支撑。
AgentScope 的每一次升级，都围绕一个核心：让智能体在真实场景中稳定地完成任务。模型容错、事件流、权限边界、结构化上下文、中间件扩展、环境抽象、服务化部署……这些不再是零散的功能叠加，而是构成可靠智能体系统的底层工程底座。AgentScope 2.0 也由此从关注“如何构建智能体”，进一步走向关注“如何让智能体可靠运行”。
