AgentScope 2.0 is both a deeply customizable Agent Framework and, more importantly, a general-purpose Agent Harness for enterprise tasks.
Throughout the development of AI, we have consistently led industry practice in building agents for enterprises. From Spring AI Alibaba and AgentScope 1.0 to AgentScope 2.0, almost every product has seen widespread enterprise adoption. At the same time, it is hard not to marvel at how quickly technical approaches are evolving in the Agent era. The latest AgentScope 2.0 has been fully upgraded to a general-purpose Harness. I will examine its underlying core mechanisms as a general-purpose Harness across three layers—tasks, information, and actions—and explain how its architecture of ‘unified orchestration on the service side, isolated execution inside sandboxes’ supports enterprises in building Managed Agents platforms and delivering the Harness as a service.
Enterprise requirements for Agents are expanding beyond connecting models and tools to handling complex tasks on an ongoing basis and providing services to multiple business teams. Four common starting points for building Agents have emerged around these requirements:
These four starting points reflect different divisions of responsibility and can also be combined. When choosing among them, enterprises need to consider the depth of customization, data and execution boundaries, and operational capabilities. Deterministic workflows suit tasks with clearly defined paths; Agents are appropriate when dynamic exploration is needed; and the two can be combined when boundaries such as approvals are fixed but judgments within individual steps are complex.
These practices reveal a common trend: general-purpose working mechanisms are consolidated into reusable Harnesses and subsequently delivered as services. Business teams focus on domain knowledge, tools, and result acceptance, while platform teams centrally provide state management, isolated environments, permissions, and observability, reducing duplicated effort.
AgentScope provides both the code-level control of a framework and the mature working mechanisms of a general-purpose Harness. This makes it well suited to enterprises that want to reuse foundational capabilities while retaining control over their own business logic and operational boundaries. An important architectural advantage for enterprise service delivery is the Tool-In-Sandbox pattern, which decouples unified orchestration from isolated execution: the Agent Loop, model calls, and context orchestration run on the service side, while file operations, commands, and code execution that require isolation enter a sandbox through tool interfaces, with execution results returned to the Harness. Enterprises can therefore maintain and upgrade the Harness centrally, configure execution environments per user or session, and scale orchestration services and sandbox resources independently, reusing the same set of Agent capabilities while preserving clear execution boundaries.
Building on this architecture, enterprises can combine shared state, task scheduling, sandbox resource management, and identity systems to build their own Managed Agents platforms more quickly. Business applications can submit tasks, receive progress updates, participate in approvals, and obtain artifacts through APIs, putting Harness-as-a-service delivery into practice across the full task lifecycle.
The initial challenge for Java developers was how to integrate model capabilities into existing applications: standardize calls to different models, use enterprise data for retrieval augmentation, expose existing APIs as tools that models can use, and retain familiar application development and operations practices.
Spring AI Alibaba addresses these requirements by providing integration and capability enhancements for the Java application ecosystem, while further exploring Agent and multi-Agent orchestration. This phase lowered the barrier to AI application development for Java developers and enabled models to connect meaningfully to enterprise data and services.
Spring AI Alibaba official positioning statement: https://java2ai.com/en/blog/saa-agentscope-announcement/
As Agent application requirements and model capabilities developed, the focus began to shift from ‘how to call a model’ to ‘how to organize ongoing interaction between models and their environments.’
Following this line of technical exploration, the AgentScope 1.0 phase focused more closely on the Agent itself: how models reason and act, how tool results inform the next round of judgment, how multiple Agents collaborate, and how developers control and extend execution.
The ReAct loop provides a clear foundation: the model decides what to do next based on the information currently available, calls tools to obtain new facts, and then continues making judgments. Developers do not have to enumerate every possible branch in advance; the Agent can adjust its path based on environmental feedback.
Yet even with this foundational abstraction, every team still encounters similar engineering work: maintaining plans for long-running tasks, designing storage for large results, compacting historical messages, limiting context for sub-Agents, adding confirmation for dangerous operations, and persisting state for execution across calls.
These capabilities often determine whether an Agent can move from a demonstration to everyday use, yet they must repeatedly be built for different business applications.
AgentScope 2.0 consolidates these shared capabilities into HarnessAgent. Developers receive not only components such as models, messages, and tools, but also the mechanisms through which these components work together on long-horizon tasks.
For example, oversized tool results can be offloaded to the workspace; tasks that require planning can enter Plan Mode; independent exploration can be delegated to sub-Agents; growing history can be compacted and model inputs reorganized; and the execution environment can switch from a local file system to a sandbox or remote storage.
This progression can be summarized as follows:
| Stage | Primary Focus | Value for Developers |
|---|---|---|
| Spring AI Alibaba | Integration of models, data, and tools with Java applications | Faster integration of AI capabilities into enterprise systems |
| AgentScope 1.0 | Agent loops, tool interactions, and multi-Agent collaboration | More flexible development of Agent applications |
| AgentScope 2.0 HarnessAgent | Context, state, collaboration, and execution mechanisms for long-horizon tasks | Building business Agents on a general-purpose Harness |
What is described here is an evolution in technical focus. Spring AI Alibaba and AgentScope each have their own independent product positioning. Within AgentScope, Harness capabilities also accumulated gradually; they did not suddenly appear with version 2.0. The key change in 2.0 is to make the general-purpose Harness the primary development entry point for complex tasks.
The difference between a Framework and a Harness can be understood in terms of what each delivers to developers.
A Framework provides abstractions such as models, tools, messages, state, and extension points to help developers organize code. Building on these foundations, a Harness provides a set of mechanisms that already work together: how to supply information to the model, advance tasks, call tools, save progress, and involve people in execution.
The Runtime provides execution infrastructure, including scheduling, state persistence, recovery, and event delivery. These three concepts overlap, but they answer different questions: the Framework concerns how to build, the Runtime concerns how to run, and the Harness concerns how to enable the model to work effectively throughout a task.
The Harness is receiving greater attention because Agent failures increasingly occur during sustained work.
A model may correctly understand a vulnerability advisory but upgrade the wrong dependency because it has not seen the project's constraints. It may write a correct patch but forget to test it after context compaction. Or it may complete its checks yet mistake the old code associated with a test report for the current version. In such cases, merely improving the quality of an individual response cannot resolve problems across the entire task chain.
Enterprises also cannot rely on model capabilities as a substitute for execution contracts. However capable a model may be, it still needs systems to provide real-time business facts, persistent state, actual credentials, and an execution environment. Whether a release is permitted, whether a write operation actually occurred, and which version a verification result applies to must all be established by code and systems outside the model.
The value of a Harness therefore lies in two areas: reducing forgetting and drift during long-horizon tasks, and integrating model capabilities into enterprise work processes that can be controlled and inspected. As models improve, some prompting strategies may be simplified, but the engineering responsibilities for state, permissions, and environments remain.
This does not mean every application must enable a complete Harness. A single structured extraction, short-chain question answering, or a business workflow with a predetermined path is still suited to lighter-weight calls and orchestration. HarnessAgent primarily addresses work in which paths must be discovered dynamically, tasks require multiple steps, and information accumulates continuously.
Coding Agent products offer a valuable window into an important question: why can models work in code repositories for extended periods while continuously producing results that can be inspected?
Coding scenarios naturally have well-defined objects of work. Files hold inputs and artifacts, the command line provides an interface for actions, tests and execution results supply feedback, and version history helps explain changes. Plans, progress files, and context management further support continuation across stages. Published research on long-horizon Agents also demonstrates this approach: explicit task lists, incremental progress, and handoff materials help subsequent execution understand the work already performed.
Harness practices for long-horizon Agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
From the perspective of enterprise applications, these mechanisms can be generalized to other objects of work:
| Objects in a Coding Agent | Corresponding Objects in an Enterprise Agent |
|---|---|
| Code repositories and project rules | Business workspaces, policies, task inputs, and constraints |
| Files, Shell, and testing tools | Data queries, enterprise APIs, analysis scripts, and business tools |
| Code patches and build artifacts | Reports, tables, proposals, work orders, and business changes |
| Unit tests and execution checks | Data validation, business rules, and result acceptance |
| Project experience and operational methods | Memory, Knowledge, and Skill |
These transferable working mechanisms are precisely what AgentScope Java aims to consolidate. For a software development Agent, the workspace may contain code; for a research Agent, source materials and reports; and for a data analysis Agent, query results, analysis scripts, and data quality evidence. The objects of work may change, but the basic structure of task progression, information organization, and action feedback remains valid.
The following enterprise task will serve as a running example across all three layers: analyze high-severity dependency vulnerabilities in a payment service, complete remediation and verification, and prepare change documentation ready for approval. The current authorization scope does not include a production release.
HarnessAgent reuses ReActAgent internally, incorporating capabilities such as workspaces, plans, memory, sub-Agents, and execution environments into the execution chain through Middleware, tools, and a dedicated boundary for preparing model requests.
This structure preserves the clarity of the Agent loop: read the current information, call the model, execute tools, receive results, and decide what to do next. New engineering capabilities can intervene at well-defined points, such as assembling a task view before a model call, checking permissions during tool execution, or triggering compaction when the history becomes too long.
Once acceptance checks for the specific business application are integrated, task progression can be represented by the following logical closed loop. The business acceptance checks and completion determination shown in the diagram must be configured and implemented by the application:
In the vulnerability remediation example, new dependency analysis results may change the upgrade proposal, failed tests may generate remediation items, and additional user constraints may narrow the scope of modifications. Sustained progress depends on this feedback continuously informing the next round, rather than requiring the model to predict the entire path at the outset.
Long-running tasks cannot rely solely on chat history to represent progress. Hundreds of messages may contain old plans, new requirements, outdated test results, and canceled actions at the same time. Having the model infer ‘exactly how far we have progressed’ anew in every round wastes context and can easily introduce ambiguity.
AgentScope saves execution state through AgentState and passes information such as the user and session for the current call through RuntimeContext. The task list is updated by todo_write, and Plan Mode state is also saved with AgentState. On each reasoning step, the model can receive a projection of the current progress.
Task state must also distinguish three things: the goal the user wants to achieve, the progress maintained during execution, and the evidence supporting the validity of the result. The current task-state design further distinguishes candidate requirements from confirmed requirements: the model may propose constraints or acceptance criteria that need to be followed, while the application is responsible for confirming their source and authorization. A requirement proposed by the model does not mean it has already made a decision on the user's behalf.
In the vulnerability remediation task, ‘remediate the vulnerabilities and prepare change documentation’ is the goal, ‘integration tests are running’ is progress, and only ‘this patch passed the tests for the specified version’ is a verified fact. Each of these pieces of information should have its own clearly defined meaning.
For tasks with a broad impact, a practical approach is to explore first, formulate a plan, and execute only after confirmation.
AgentScope provides plan_enter, plan_write, and plan_exit. Once Plan Mode is entered, general modification tools are blocked, while read-only tools and tools on the allowlist for planning and task collaboration remain available. Plans can be written to plans/PLAN.md; when the model requests to exit, the process moves to human confirmation.
The key to this design is where constraints are enforced. ‘Write a plan first’ can be stated in a prompt, but prohibiting general write operations during planning must be enforced by the execution chain. The dedicated plan_write tool allows plans to be produced without enabling arbitrary file writes.
Enabling the Plan Mode capability and actually entering the mode are two different things. If business requirements dictate that a task must begin with planning, the application should enter the mode explicitly rather than relying solely on the model to choose it.
The following is a configuration snippet from an application; model and workspace are supplied by the caller:
HarnessAgent agent = HarnessAgent.builder()
.name("remediation-agent")
.model(model)
.workspace(workspace)
.enablePlanMode()
.enableTaskList()
.planFileDirectory("plans")
.build();
RuntimeContext context = RuntimeContext.builder()
.userId("engineer-42")
.sessionId("remediation-42")
.build();
agent.enterPlanMode(context);
agent.call(
new UserMessage("Analyze dependency vulnerabilities in the payment service and submit a remediation plan first; do not release to production."),
context).block();Plan approval governs the transition between phases; production releases should still be controlled by a separate permission policy. The tool scope of sub-Agents must also be configured explicitly: a parent task being in a read-only phase does not mean that all executors are automatically read-only.
Complex tasks often contain parts that can be handled independently. In vulnerability remediation, one sub-Agent can be delegated to investigate dependency impact, and another to conduct an independent review once the patch has stabilized.
The first benefit of sub-Agents is context isolation: dependency trees, long logs, and candidate proposals can be explored within a subtask, while the main Agent receives only the conclusions and evidence references it needs to integrate. Different subtasks can also use different models, tools, and workspace configurations. When tasks are independent of one another, parallel execution can then reduce waiting time.
AgentScope supports declaring sub-Agents through workspace specification files or Java configuration, launching tasks with agent_spawn, and executing them synchronously or in the background. Background tasks have trackable task identifiers, and their results can be consumed as the task progresses.
Delegation requires clear boundaries: what to deliver, what may be read and written, which version to use, and how to report failures. A separate context does not automatically imply separate permissions, much less branch-level isolation in the code repository. Shared modifications require additional workspace arrangements and conflict controls.
The main Agent remains responsible for integrating results. A sub-Agent's response of ‘no issues’ is merely a conclusion awaiting adoption; it should be assessed against the actual objects, scope, and evidence the sub-Agent examined.
Long-running tasks may span multiple calls and context windows. AgentScope saves the information needed to continue working through AgentStateStore, the workspace, and session records. With shared storage and the corresponding execution infrastructure configured, continuation across processes or nodes can be supported.
Session recovery must be distinguished from recovery of external actions. Reloading progress cannot prove that a timed-out request to create a change ticket did not succeed. Business tools still need to provide idempotency keys, status queries, and recovery strategies to avoid duplicate execution when a response is lost.
For the vulnerability remediation task, the continuation point should specify where the current patch is located, which checks have been completed, which results remain valid, whether confirmation is pending, and what comes next. Only then does a new round of execution have a clear starting point.
The longer a task runs, the more information it accumulates, yet the model can process only a limited window at a time. The Harness must continually decide which information needs to enter the window now, which should be stored outside it, and which is worth reusing across tasks.
Model inputs for a task typically come from multiple sources: Agent instructions, project rules, user requirements, plans, recent interactions, historical summaries, tool descriptions, and relevant knowledge and memory.
These sources carry different responsibilities and levels of trust. Project rules can guide the work, whereas web pages returned by tools are material to be analyzed. Past experience may help, but it cannot override facts about the current environment. Concatenating all of these into a single prompt loses these distinctions.
AgentScope's current context-construction implementation uses HarnessContextBuilder to centrally handle materials, budgets, and layout before the actual model request is sent. System instructions, conversations, transient task state, and reference materials have clearly defined positions. Tool calls must remain paired with their results, and tool Schema definitions also count toward the input budget.
This makes ‘what the model sees’ an engineering behavior that can be inspected. The construction process produces a Context Manifest that records source identifiers, content versions, budgets, and transformation information, making it easier to determine whether a particular material entered the request and whether it was compacted or removed. The Manifest itself does not need to duplicate the full original text.
The current budgeting strategy is not equivalent to a relevance engine that can already understand the value of all materials automatically. Enterprises still need to supply suitable candidate materials through knowledge retrieval, tool filtering, and business rules, and enforce identity and data permissions at the reading stage.
Suppose a security scan returns tens of thousands of lines of results. In the next round, the Agent may need to know only which blocking issues remain and how to find them. Resending the full report with every request continuously consumes window capacity.
Tool-result offloading stores the complete content in an external file, while retaining a compact representation and a reference for reading it in the active context. When the model needs details, it retrieves them through search, range reads, or other tools. This approach is particularly suitable for logs, dependency trees, search results, and scan reports.
History compaction addresses a different kind of growth: multiple rounds of exploration accumulate many messages, much of whose process can already be represented by summaries. Compaction needs to preserve task goals, key decisions, unresolved issues, and the continuation point, while retaining recent interactions verbatim in the active window.
Both mechanisms should work with structured state. Information such as Todo items, permission modes, and verification summaries can be projected anew from the current state, rather than relying entirely on the model to summarize old conversations. The current context pipeline also commits a candidate history replacement only after the final budget and structural checks have passed, reducing the impact of compaction failures on the active history.
When evaluating these mechanisms, it is important to look beyond Token savings and check whether the task can continue after compaction, whether key facts can still be retrieved, and whether failed attempts have been forgotten. A shorter window is valuable only if the task remains coherent.
Workspace is an important foundation for a Harness: an Agent can place inputs, plans, intermediate analyses, and final artifacts in an addressable, inspectable space, reading and modifying them incrementally.
AgentScope abstracts workspace access as a pluggable file system that can connect to local directories, remote storage, or sandboxes. The Agent uses a consistent set of file operations, while the underlying storage and execution location are determined by deployment configuration.
In the vulnerability remediation example, the workspace could be organized as in the illustrative structure below. This is a business-specific directory design, not a complete layout whose generation is mandated by the framework:
workspace/
├── AGENTS.md Project rules
├── skills/ Remediation and review methods
├── subagents/ Sub-Agent specifications
├── plans/PLAN.md Current plan
├── inputs/ Vulnerability advisories and task inputs
├── scratch/ Temporary analyses
├── artifacts/ Patches and change documentation
└── evidence/ Test and scan reportsThe role of files here extends beyond storage. They also serve as an interface through which people and Agents can jointly inspect the work: whether the plan is sound, what the patch changed, and whether the reports are complete can all be checked directly.
However, authoritative task state must not be arbitrarily mixed into working files that the model can rewrite. Execution and verification records managed by the framework should reside in their corresponding state stores, while report files and paths serve as referenceable artifacts and evidence. A file having been written and that file having passed acceptance checks remain different states.
The information needed for long-horizon work extends beyond the files of the current task.
Knowledge provides facts maintained by the enterprise, such as dependency upgrade policies, system architecture, and release standards. Memory stores experience worth reusing in subsequent tasks, such as special compatibility constraints for a particular module. Skill encapsulates methods for completing a class of tasks, including instructions, scripts, templates, and reference materials.
AgentScope's memory mechanism distinguishes memory logs with entries appended by date from curated long-term memory and also supports extracting valuable information before compaction. This provides a foundation for accumulating experience, but explicit governance rules are still needed to determine whether that experience is trustworthy, which user or project it belongs to, and when it becomes invalid. An unverified conjecture should not be promoted to an established fact simply because it has been written into memory.
Skill further turns reusable methods into maintainable capability packages. In vulnerability remediation, for example, a Skill can describe how to read advisories, check dependency chains, generate proposals, run checks, and organize delivery materials, assigning repetitive, deterministic steps to scripts and leaving the parts that require understanding and judgment to the model.
To control context costs, Skill uses on-demand loading: first provide the name and description, load detailed instructions after selection, and read reference files and scripts when needed. AgentScope integrates different sources, including workspaces and Git, through Skill Repository, allowing business teams to maintain their own collections of methods.
The distinctions among the three affect how they are updated: policy changes should update Knowledge, verified project experience can enter Memory, and stable methods should be consolidated into Skill. Skill instructions must still comply with current tool permissions; loading a capability package does not grant additional authorization.
The first two layers address task progression and information organization, respectively. The third answers how the system executes an action after the model proposes it, and how execution results influence the next round of judgment.
When a model generates a tool name and parameters, it expresses only the action it wishes to take. Before actual execution, the system must also validate parameters, bind identity, evaluate permissions, and obtain any necessary human confirmation.
AgentScope's permission mechanism supports ALLOW, DENY, and ASK: permit execution, reject execution, or wait for confirmation. Combined with Plan Mode, the task phase can also affect which actions are executable.
Tool registration, tool disclosure, and execution authorization must be understood separately. Registering a tool means the system knows how to call it; showing the tool to the model means the model can consider that capability; whether a particular call is allowed depends on the policy at execution time. Enterprises cannot protect high-impact operations merely by adding ‘use with caution’ to a tool description.
In the vulnerability remediation task, ‘create change documentation pending approval’ and ‘release to production’ should be designed as separate business actions. Even if they connect to the same change-management platform, their authorization scopes, input requirements, and acceptance methods differ. Approval of the remediation plan should not directly extend to authorization for a release.
Files, Shell, and code execution allow Agents to handle many tasks that have not been encapsulated in advance, such as analyzing logs, transforming data, and running tests. Business tools provide more explicit semantics, such as querying service dependencies, creating change tickets, and checking approval status.
AgentScope can integrate external tools through mechanisms such as MCP, and can also delegate work with an independent execution process to remote Agents. Connection protocols reduce integration costs, but business permissions and result acceptance still need to be enforced within the call chain.
The Tool-In-Sandbox pattern introduced earlier implements this division between orchestration and execution in the tool-call chain: the service-side Harness initiates a tool call; the sandbox returns results and artifacts after execution; and the Harness then continues reasoning and advancing the task. Other tools, such as enterprise business APIs, can still execute through their own controlled entry points. The platform can manage the capacity and lifecycles of Harness service instances and sandboxes separately. Once shared state, workspace recovery, and concurrency controls are configured, it can provide ongoing services for multiple users and long-horizon tasks.
For general-purpose execution capabilities, the sandbox is responsible for constraining the actual execution environment. The Harness's file-system and sandbox integrations allow the same Agent logic to work across different environments; production deployments must also specify networking, mounts, credentials, and resource quotas.
For example, the remediation environment can permit code modifications and test execution without injecting production-cluster credentials; release actions occur only through dedicated enterprise tool entry points. Permission controls and environment isolation enforce the same business boundary at different layers.
A tool returning ‘success’ is one of the signals most easily overestimated. A successful HTTP request does not necessarily mean the business object has reached its target state, and a Shell exit code of zero does not prove that the complete test suite was executed.
AgentScope's current execution-feedback implementation stores action observations separately, associates tool calls with execution attempts, and preserves structured facts supplied by the producer. For example, Shell can directly supply the exit code and information about output truncation, avoiding guesses about success based on natural-language logs.
On this basis, deterministic verification can read action records explicitly selected by the caller, check conditions such as exit codes or JSON Schema compliance, and bind the report to task requirements and the version of the object being checked.
Version binding is especially important. Test results for patch A are valid only for the corresponding version; if further modifications produce patch B, the original passing conclusion cannot continue to serve as current evidence. Maintaining the current version requires the application to explicitly integrate object-change and invalidation handling. Git HEAD, which does not reflect uncommitted changes, cannot simply substitute for the actual workspace version.
This chain provides more reliable inputs for completion determination, but its boundaries must be clear: existing execution observations and local deterministic checks do not mean the framework already performs automatic acceptance of the entire business task by default. In the current implementation, the objects to check, acceptance criteria, and verifiers are explicitly specified by the caller; a unified completion gate for exiting the loop still requires further development.
For the example in this article, an enterprise application can define acceptance as follows: the affected dependencies have been eliminated, the required tests and security scans have passed, the patch scope conforms to the plan, and the change documentation is complete. Only when these conditions are met can a ‘change ready for approval’ be delivered. If the goal does not include a production release, the absence of a release should not be misjudged as task incompletion.
This design also applies to non-coding scenarios. Data analysis checks data definitions and result consistency; reports check source coverage and evidence citations; business work orders check the actual state in authoritative systems. The general-purpose Harness provides execution and feedback mechanisms, while business systems define which results merit acceptance.
Long-running tasks need to provide users with continuous status feedback. AgentScope's event stream can expose text deltas, tool calls, execution results, and related custom events, which services or channels can then adapt into business interfaces. Users can intervene effectively only when they can see that a task is awaiting confirmation; they can inspect delivery quality only when they can see artifacts and evidence.
For development teams, these events must also be linked to model calls, context construction, subtasks, and execution records. It should be possible to trace the execution process to determine whether a failure arose from missing information, incorrect tool selection, an environmental issue, or inadequate acceptance rules.
A Verifier for an individual task and Evaluation across versions serve different purposes. The former checks whether the current result satisfies specified conditions; the latter compares whether the Agent as a whole improves after changes to models, prompts, tools, Skill, or context strategies.
Evaluation should examine not only final artifacts, but also the process and cost: whether goals were missed, exploration was repeated, direction drifted after compaction, unnecessary approvals occurred, or verification was performed against the wrong version. Different versions should also use comparable environments, data, and budgets.
Only this kind of feedback can guide targeted changes: adjust retrieval and context when facts are missing, improve task state and methods when the Agent repeatedly takes unproductive paths, adjust Schema and permissions when tools are misused, and strengthen acceptance checks when completion is incorrectly declared. Each change should then undergo regression testing, rather than simply adding ever more exceptions to the prompt.
Returning to the initial vulnerability remediation task, the three layers form a continuous chain of work: the task layer maintains goals, plans, and collaboration relationships; the information layer supplies the rules, facts, and evidence currently needed; and the action layer executes within an authorized environment and feeds actual results back into the task process.
The same structure can be transferred to business performance analysis, research reports, business operations, and customer service. Developers need to define domain facts, business tools, reusable methods, and acceptance criteria, while the Harness provides the shared mechanisms that allow these capabilities to work continuously.
AgentScope 2.0's architecture preserves openness in this division of responsibility: developers can use HarnessAgent directly or customize execution through Middleware and the underlying ReActAgent; they can adopt different models, state stores, and execution environments, or embed the Harness into existing enterprise services. General-purpose default capabilities and low-level extensibility together form the new development entry point.
From Spring AI Alibaba to AgentScope 1.0 and then to AgentScope 2.0 HarnessAgent, we have continually expanded the scope of work Java developers can entrust to Agents. Today, what the framework helps developers manage has extended to sustained task progression, information accumulation, controlled actions, and result delivery throughout a task.
This is also AgentScope's new positioning as a general-purpose Harness: enabling enterprises to build agents on top of their own models, data, tools, and execution environments—agents that can work continuously, accept intervention, and support their deliverables with evidence.
HiRoute New Release: Choose the Best-Fit Model for Your Real-World Work
Alibaba Cloud DevOps AI Assistant Update: AI at Every Stage of DevOps Collaboration
816 posts | 61 followers
FollowAlibaba Cloud Native Community - June 2, 2026
Alibaba Cloud Native Community - June 23, 2026
Alibaba Cloud Native Community - June 8, 2026
Alibaba Cloud Native Community - April 3, 2026
Alibaba Cloud Native Community - May 18, 2026
Alibaba Cloud Native Community - October 28, 2026
816 posts | 61 followers
Follow
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn More
Wan3.0
Unleash Your Creativity Try Wan 3.0 now — longer narratives, greater control, endless creativity.
Learn More
Qoder
From Assisted to Autonomous — Adapting to Every Programming Need
Learn More
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn MoreMore Posts by Alibaba Cloud Native Community