开发一个能“跑通Demo演示”的智能体，坦白说，技术门槛并不算高。
真正棘手的挑战，在于让它在真实业务场景中稳定可靠地完成任务。
长链路任务中途断裂、工具调用缺乏安全边界、上下文越跑越臃肿、本地脚本难以接入生产环境——这些才是智能体走向落地时，开发者每天都会遇到的硬骨头。
AgentScope 1.0 的核心主张是“透明开发”，让开发者能够清晰看到智能体的消息流转、工具调用和协作过程，从而降低理解和调试的门槛。到了 2.0 版本，团队在延续这一理念的基础上，把重心转向了真实场景下的稳定运行、安全控制与集成需求——可以说，这是一次更严谨、更全面、也更成体系的升级。
模型接入：不只是“更多”，而是“更稳”
AgentScope 2.0 继续保持开放的模型接入能力，支持 Qwen、Anthropic、DeepSeek、Gemini、OpenAI 等主流模型，并进一步扩展了对 Grok、Moonshot 等模型的支持。不过，2.0 的升级重点并不只是“接入更多模型”，而是让模型调用在复杂任务中变得更加稳定可靠。
在实际任务中，Agent 往往需要多轮推理和多次工具调用。一次模型接口失败、超时或不可用，都可能让后续执行直接“卡壳”。为此，AgentScope 2.0 在模型层引入了统一的重试与备用模型机制。开发者可以配置最大重试次数，也可以设置备用模型；当主模型调用失败时，框架会自动切换至备用模型，尽可能保持任务执行的连续性。
这一层升级的实质，是让 Agent 不再仅仅是“能调用模型”，而是拥有一套更稳健的模型运行策略。对于需要持续推理和多步执行的任务来说，模型层的稳定性，已经成为决定智能体能否顺利完成任务的基础条件之一。
消息与事件：从“黑盒回复”到“全流程可见”
在普通的聊天应用里，消息可能只是文本。但在智能体执行场景中，看清每一步的流转比什么都重要。
AgentScope 2.0 对消息模块进行了重构，通过统一的 Content Block 来承载不同类型的消息内容。其中，DataBlock 支持 base64 与 URL 两类数据源，能更好地兼容不同模型 API 的多模态与文件处理能力。
在此基础上，AgentScope 2.0 引入了事件系统。一次 Agent 回复不再只返回最终文本，而是可以流式地产生模型调用开始、文本增量、工具调用、工具结果、用户确认、外部执行等一系列事件。这让前端 UI 可以实时展示 Agent 的执行过程，也让人工确认、人工介入和外部工具执行，成为了框架的内生能力。
举个例子，当智能体要执行某个敏感工具时，可以触发用户确认；当工具需要在外部环境中执行时，也可以等待外部执行结果后继续任务。
消息模块与事件系统的升级，不仅延续了 AgentScope 对“透明”的强调，更让智能体的执行过程变得可展示、可交互、可干预。开发者看到的不只是最终答案，而是一个能被持续观察和推进的执行过程。
权限系统：自主行动，但必须有边界
为了充分发挥大模型的能力，智能体需要更强的自主性——它不能只是被动响应用户，还要能根据任务进展主动选择工具、读取信息、执行操作。
但自主性越强，权限边界就越要清晰。
AgentScope 2.0 引入了一套更系统化的权限机制，用来控制智能体在调用工具、读写文件、执行命令时的行为边界。工具调用不再是简单的“允许”或“禁止”，而是可以根据静态规则、工具类型和输入内容，动态判断一次操作应该被允许、拒绝，还是交给用户确认。
例如，文件读写工具会检查是否涉及危险目录和敏感文件；命令执行工具会分析高风险命令、动态 shell 结构和危险删除操作；对于未知或高风险行为，AgentScope 可以自动进入用户审批流程。
这套权限系统的引入，让智能体不只是“能调用工具”，而是能在清晰可控的边界内自主执行任务。对于需要持续使用工具、访问文件或执行命令的复杂场景来说，安全边界已经成为智能体能否稳定完成任务的重要基础。
上下文管理：不只是压缩历史，更是系统化策略
处理长期任务，远不止是把历史对话一股脑塞进窗口那么简单。哪些信息该保留？哪些该截断？文件如何避免重复读取？任务状态怎么跨轮次延续？
AgentScope 2.0 的上下文管理进一步走向系统化。它会结合任务状态、工具结果和文件读写过程来管理上下文：
- 压缩结果不再是简单的摘要，而是结构化保留任务目标、当前状态、关键发现、下一步计划和需要长期保存的信息；
- 工具结果自动截断，避免超长日志或搜索结果撑爆上下文；
- 内置文件读写新增缓存机制，并强制“先读后改”，减少重复 IO，提升性能和操作可靠性。
可以说，上下文管理在 AgentScope 2.0 中已经升级为支撑长期任务执行的系统策略。它让智能体能更有组织地维护任务状态、控制上下文规模，并在持续推理和多次调用工具的过程中保持稳定。
Middleware：不改源码，也能深度定制
真实业务往往需要接入专属日志、安全策略、上下文注入或自定义的模型调度逻辑。如果每次都去改框架源码，扩展成本会很高，也容易影响框架本身的稳定性。
AgentScope 2.0 引入了 Middleware 机制，让开发者可以在 Agent 的关键执行环节插入自定义逻辑。比如模型调用前后的日志追踪、工具执行前的安全检查、reasoning 和 acting 流程中的业务策略，以及 system prompt 构造阶段的动态上下文注入。
通过 Middleware，AgentScope 2.0 能在保持核心框架稳定的同时，为不同应用场景留出足够的灵活扩展空间。这也延续了 AgentScope 1.0 的透明理念：框架不是黑盒，开发者可以理解它、介入它。
Workspace：把“做什么”和“在哪儿做”分开
随着智能体能力变强，它不再只是调用模型，还需要使用工具、访问文件、加载技能、连接 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 也因此从关注“如何构建智能体”，进一步走向了关注“如何让智能体可靠运行”。
在 2.0 的更新中，AgentScope 也在多语言层面做了更多支持：
- Python 版已全面升级至 2.0
- TypeScript 版本已正式发布
- JA VA 版本将在近期同步更新到 2.0
基于 AgentScope 构建的智能体应用 QwenPaw，也将在近期同步升级至 AgentScope 2.0 基座，提供更稳定、更安全、更易扩展的智能体体验。
