Agent as a Service: Cloud-Native Architecture for Personal & Enterprise AI Agents

Agent as a Service: Architecture for Continuous Task Delivery

To satisfy both Personal Agent and enterprise intelligent agent requirements, an Agent as a Service architecture is needed that lets tasks progress across different entry points, execution nodes, and working environments. Personal Agents must continue organizing data after the user leaves the computer and resume via a local Harness preserving context and memory. Enterprise agents must conduct remote investigations, route tool calls to cloud sandboxes or intranet execution endpoints, and continue after tool waits, human confirmations, or execution node switches.

The common requirement is to make agent identity, task state, and long-term accumulation independent of any single client, Harness instance, or execution environment. This requires organizing Harness runtime, cloud management of Context and Memory, and actual tool execution, then connecting them via stable task identifiers and execution protocols.

Based on AgentScope, the article builds this path around Sandbox as Tool : hosting Harness as a remote service, connecting Context, Memory, and recovery state to a cloud state service, supporting local/remote continuation via execution handoff, and connecting differently located tool execution endpoints through Brain/Hands separation. These boundaries organize persistent task state, on-demand compute, and switchable execution environments into a complete task delivery chain.

What Continuous Work Requires from an Agent Service

Whether for individuals or enterprises, callers need to submit work, read progress, add requirements, handle confirmations, and retrieve results later. The service must accept these interactions while preserving what the task has completed, what it is waiting for, and how to continue next.

Agent as a Service is such a task-delivery-oriented service form. Managed Agent further clarifies runtime responsibility: the platform hosts the agreed-scope Harness, execution scheduling, and state management; the application team provides business tools, authorization, and acceptance criteria. The platform can be deployed on the enterprise's own infrastructure.

An agent thus involves at least several distinct lifecycles: agent definition (long-term reuse), user session (spans multiple tasks), inference instance (runs briefly), sandbox (retained or recycled per file/process needs). Separating these lifecycles is a key design task for a Managed Agent platform.

Build Entry and Deployment Mode: Two Dimensions

Four build approaches exist:

High-code framework self-build Harness — frameworks like AgentScope provide code abstractions for model, messages, tools, state; teams compose task loops, context policies, business capabilities. Requires custom storage, runtime, recovery mechanisms.

Reuse productized Harness — mature Coding Agents or workspace assistants already organize planning, file ops, command execution, context management, permission interaction. Teams can use CLI or embed via SDK, then add business tools, identity, acceptance rules.

Define agent around model, platform hosts Harness and runtime — developers configure model, instructions, tools, Skills, execution environment; submit tasks via API and consume events/results. Platform bears runtime responsibility; app side focuses on data/tool integration, authorization, result delivery, business acceptance.

Use cloud product prebuilt capabilities — assemble model, knowledge, memory, tools, credentials into an agent via product UI or open APIs, then enter platform versioning, release, management flows. Emphasizes build/governance entry integration; can coexist with managed runtime.

These four can be combined. Enterprises may customize core agents with frameworks, reuse mature Harness for workspace tasks, and manage via a unified platform. For applicability boundaries and responsibility division among Harness, Runtime, Sandbox, and enterprise, refer to the AI Agent Handbook's "Harness Mainstream Build Methods and Responsibility Boundaries".

After choosing a build entry, decide how inference and execution deploy: Is the Harness responsible for the inference loop inside the same sandbox boundary as the environment that executes model-generated code? Two patterns emerge:

Agent IN Sandbox — agent runtime components placed inside the sandbox.

Sandbox as Tool — agent outside sandbox calls sandbox execution capabilities.

Agent runtime components mainly refer to Harness, model calls, tool orchestration code; the model itself can be provided via remote API. Service deployment containers are not necessarily the same as sandboxes for untrusted code; the key is their respective permission and isolation boundaries.

The classification maps each concrete build method to Harness location and pattern:

High-code framework, deploy custom Harness with task env into sandbox — Harness inside sandbox → Agent IN Sandbox

Reuse productized Harness, launch CLI/SDK agent components in sandbox — Harness inside sandbox → Agent IN Sandbox

Managed agent or cloud product, platform runs full agent components in task sandbox — Harness inside sandbox → Agent IN Sandbox

High-code framework, run Harness on server side, access sandbox via tools; this article's AgentScope-based service uses this way — Harness server side outside sandbox → Sandbox as Tool

Reuse remote-capable productized Harness, delegate file/command ops to independent sandbox — Host process or server side outside sandbox → Sandbox as Tool

Managed agent or cloud product, platform runs Harness on server side, sandbox only handles tool execution — Platform server side outside sandbox → Sandbox as Tool

Classification looks at where the Agent Loop actually runs. An SDK may initiate calls from outside the sandbox, but if the full Harness it starts runs inside, it remains Agent IN Sandbox. The article's AgentScope-based service places Harness on the server side and uses an independent tool execution layer to access the sandbox, adopting Sandbox as Tool. "Framework", "SDK", "Managed", "Cloud Product" describe build entry or responsibility division; the concrete deployment mode decides final classification.

Agent IN Sandbox Working Mode

In this mode, the task environment installs agent runtime components that read the workspace, call the model, execute commands, and maintain the task process. External applications pass input via network and receive events/results. This approach is close to local workspace development. The agent can directly use files, dependencies, and tools in the environment; if it heavily relies on existing CLIs, complex toolchains, or extensive local operations, colocating runtime components with the environment is often easier to start. Correspondingly, upgrades, environment recovery, and process management must be considered together.

Sandbox as Tool Working Mode

Here Harness runs on the server side. It organizes context, calls the model, decides the next action; when file operations or code execution are needed, it calls a remote Sandbox. Execution results return, and Harness continues the task.

This split establishes independent boundaries for agent state and execution environment, and allows model-access credentials to stay outside the sandbox. The trade-off: tool calls add network interaction, and the system must handle remote execution and failures. Some agent remote sandbox integration examples demonstrate file operations and command execution via this approach.

From a platform-building perspective, further implications can be derived:

Task bearing unit : Agent IN Sandbox tends to use complete agent environment as unit; Sandbox as Tool can manage inference instances and execution environments separately

Long-term state : Agent IN Sandbox must extract and externalize from environment; Sandbox as Tool can organize around independent task records

Resource scheduling : Agent IN Sandbox has inference and environment lifecycles tightly coupled; Sandbox as Tool can schedule separately per different loads

Permission design : Agent IN Sandbox must separate runtime component vs generated code permissions; Sandbox as Tool can centralize checks at remote tool boundary

Failure handling : Agent IN Sandbox must judge process and environment state simultaneously; Sandbox as Tool must clarify whether tool executed and how results hand off

These differences are opportunities and responsibilities brought by architectural choices. The first pattern can also achieve servitization via externalized state, credential proxies, and permission separation; the second also requires investment in reliable execution protocols. Choice should depend on task-environment coupling degree and which engineering responsibilities the platform is willing to bear.

Building Agent as a Service with AgentScope

Building an agent service with AgentScope starts by using Harness to organize model, tools, workspace, memory, and task execution, then establishing access, scheduling, persistence, and tool execution chains around it. Adopting Sandbox as Tool places Harness on the server side, delegates file/command operations to an independent execution layer; enterprise APIs and MCP tools connect per their authorization boundaries. The service responsibilities and their AgentScope-based construction methods:

Definition & resource management : Manage agent model, instructions, tools, Skills, config versions; define workspace and resource authorization

Request & event access : Verify identity, accept sessions/tasks, provide progress query, event subscription, supplemental input, human confirmation

Task scheduling & execution control : Persistently receive work, control session ordering/concurrency/budget, manage execution rights and recovery scheduling

Agent runtime : Use Harness to build context, call model, organize tool calls, save execution progress

Tool execution : Invoke sandbox, MCP, or business systems; record stable execution IDs, progress, results; handle queries and cancellations

State & workspace storage : Save session logs, checkpoints, todos, tool records, artifacts; configure workspace persistence and isolation

In practice, first configure a reusable Harness build entry, determine model, tools, workspace backend. Each execution passes authorized user/session identity via RuntimeContext, connects Session Log and required state to persistent storage. After model produces tool calls, check permissions and record execution intent, then execution layer calls sandbox or business tools; upon confirmed results written back, Harness continues.

In the diagram: ① = remote Harness hosting, ② = local/remote Harness execution handoff, ③ = cloud management of Context, Memory, recovery state, ④ = Brain calling different Hands via unified protocol. Solid lines = task/state/tool result interactions; dashed lines = Harness execution handoff.

The same logical task is advanced by the Harness holding execution right at any moment; both local and remote ends can access cloud state per authorization. When switching Hands, subsequent calls route per execution endpoint selection; already dispatched tools still confirm results via original execution ID. Workspace files shared per auth or explicitly synced; active processes managed per execution endpoint.

Separate Task State from Inference Instance Management

Four arrangements achieve this:

Stable identifiers for sessions and tasks — save input, config version, progress, results separately. Include model context, todos, tool state in log/checkpoint recovery flows. After execution node exits, scheduler obtains new execution right, reads committed state, restores task, avoiding reliance on original process context.

Separate inference and tool resource management — model calls and Harness execution consume inference capacity; time-consuming tests consume execution environment; human confirmation saved as persistent todo. Release inference resources during waits; before recycling sandbox, confirm active processes, incomplete tools, workspace saving. Thus waiting for tools or users doesn't require the whole task to occupy the same compute resources.

Enforce authorization at different capability entry points — model access, controlled business tools, arbitrary code execution each use required identities, credentials, network policies. Example: ticket query via approved business tool; test sandbox gets only access needed for tests. Harness permission judgment and execution layer restrictions jointly enforce this boundary.

Separate version management for agent behavior and execution environment — record model, instructions, tool definitions, Harness config, environment version used for task; clarify change effective scope for new vs in-progress tasks. Update context strategy with compatible execution environment; upgrade runtime dependencies with recovery compatibility verification; avoid config updates changing existing task execution semantics.

Through these arrangements, the platform schedules on-demand instances around persistent task records. Sessions and tasks continue; inference and tool execution scale per their own loads — this is the value of Sandbox as Tool in Managed Agent scenarios.

Implement Long Tool Tasks as Suspension and Resumption

Example: investigate an issue and run a time-consuming test. The six-step execution flow:

Accept task — complete identity/resource auth checks; persist input, session ID, task ID, config version; network retries reuse same request ID.

Start inference — scheduler obtains current task execution right, loads session state and workspace, advances task via Harness.

Dispatch tool — model proposes running test; check tool permissions, save call parameters and stable execution ID, hand work to tool execution layer.

Save wait — tool needs long time; save state needed to continue, waiting tool set, checkpoint; after confirming persistence, suspend task and release inference resources.

Receive result and resume — execution layer confirms and saves test result, notifies scheduler; resume by verifying current wait conditions, obtain execution right, merge matching results, Harness continues original task.

Submit delivery — save task final state, reply, artifact references for business app query/subscribe/accept; browser disconnect doesn't change task execution state.

Service layer implements this flow by saving separate records for task state, tool execution state, recovery conditions. Async dispatch uses persistent delivery records or transaction Outbox; receiver deduplicates by stable ID; task suspension and result arrival meet by rechecking readiness conditions, avoiding tool completed but task still sleeping.

Two key state types when implementing suspension/resumption:

State needed to continue execution — checkpoint includes model context, incomplete tools/interactions, recovery phase. Chat history cannot fully distinguish tool not dispatched, running, or returned but not yet fed to next model input. Workspace files and active processes have their own recovery mechanisms, must be co-designed with Harness state recovery.

External action confirmation state — after network timeout, actions like ticket creation, notification may have taken effect. Preserve as unknown, query original operation via stable execution ID, verify saved results or escalate to human, avoid re-execution due to missing confirmation. For idempotent-key business systems, thread same key through call and retry; platform deduplication must align with external system's actual execution semantics.

Tool dispatch, result confirmation, and recovery together form the service layer's execution protocol. Agree on identity, persistence order, deduplication rules, cancellation, timeout handling; connect these protocols to Harness tool and state interfaces to continue the same work after releasing the inference instance.

Connect Harness Capabilities to Service Layer

AgentScope Harness organizes Workspace, Memory, Skill, Subagent, context management, filesystem, interaction control around the inference loop. Building the service, connect platform storage, tools, scheduling mechanisms along these capability interfaces, preserving a task semantics that runs through the execution process.

Three key boundaries to bridge:

Identity and session state — pass stable user/session IDs via RuntimeContext; connect session logs and checkpoints to required persistent backend. Entry auth, resource access, state reading use consistent identity mapping; set execution right control for same task, enabling cross-request, cross-instance continuation with clear ownership.

Workspace and execution environment — use workspace and filesystem abstractions to read/write files; route user task files, long-term memory, temporary execution data to corresponding backends; connect sandbox commands to tool execution layer. Configure workspace save, restore, isolation, artifact export rules so service instance switch still finds task-required files.

Long-running tasks and interactions — configure memory, context compression, skills, subtasks per task needs; connect human confirmation, supplemental input, cancellation, recovery into same execution process. Record parent-child relationships and result destinations for subtasks; save actual parameters and decisions for pending confirmations, so user interventions accurately apply to the advancing task.

Application teams integrate business tools, data authorization, result acceptance; platform teams centrally build task acceptance, persistent state, execution scheduling, resource management. AgentScope handles how the agent works; the service layer organizes this mechanism into continuously available task delivery capability.

Implementation: first run one agent through submit, execute, wait, resume, result retrieval; verify disconnect, node exit, duplicate delivery, human confirmation paths. Then extend concurrency and runtime resources around same identity, state, tool protocols; this foundation serves both Personal Agent and enterprise event-driven agents.

Use Service Architecture for Personal Agent and Enterprise Agents

Personal assistants and enterprise agents reuse the same Agent Service, feeding authorized Harness with different scenario inputs, returning progress, todos, artifacts to respective entry points.

Personal scenario: stable identity continues session/memory, handoff between local/remote Harness, call local/cloud Hands as needed. Enterprise scenario: convert events to tasks with input version and acceptance requirements, get evidence via intranet/cloud Hands, business app completes review, approval, write-back.

Runtime mechanisms and interfaces reusable; Context, Memory, workspace, tool permissions organized per individual, team, business process. Tool routing selects execution endpoint per task; already dispatched calls still confirm via original execution ID; subsequent four layers explain how these boundaries combine.

Four Composable Service Layers

When applying the architecture to concrete scenarios, decide where Harness runs, who saves Context/Memory, where tools execute. These choices combine into four layers:

Remote hosted Harness — move model calls, context organization, task loop to remote service; web, mobile, desktop submit tasks, consume events, participate in confirmation. With AgentScope, connect Harness to service runtime chain so task continues after client disconnect. First solves persistent agent execution process.

Handoff execution between local and remote Harness — configure compatible task state, tool definitions, workspace access for both ends, using stable Agent, user, session, task IDs. At round boundary or recoverable checkpoint, confirm original executor exits or execution right revoked, then other end obtains execution right, loads state, continues. User uses local Harness at computer, leaves → remote continues, returns → local resumes, all via handoff protocol; this is Harness execution location switch.

Manage Context and Memory as cloud state services — Context includes session history, compressed summaries, plans, reference materials for current task; Memory saves facts, preferences, experience across sessions. Configure stable ownership, version, access interfaces for both, allowing local/remote Harness to load/update per auth. Recovery execution also needs saved checkpoints, todos, tool states; workspace files prepared via shared access or explicit sync. Thus task state and long-term accumulation transcend single Harness instance lifecycle.

Separate Brain and Hands, switch tool execution endpoints — treat Harness reasoning and task control as Brain; file, command, browser, business tool execution layer as Hands. Via unified tool protocol, route approved calls to local device, cloud sandbox, or enterprise intranet execution service; Brain stays in place. Switching Hands: check target endpoint capabilities, dependencies, workspace, auth; already dispatched tools still query/settle via original execution ID, subsequent calls switch routing. Need to migrate active execution: separately complete stop confirmation, state save/restore, avoid duplicate external actions.

Therefore, local Harness can use cloud Context/Memory; remote Harness can call local Hands or enterprise intranet Hands. First two layers organize who handles reasoning; third maintains state/memory; fourth decides where actual actions occur. Based on these boundaries, build access methods for personal assistant and enterprise tasks.

Connect Personal Agent Identity, Memory, Multi-Entry

Building Personal Agent: establish stable identity for user and Agent; connect web, mobile, desktop, messaging channels to same service entry. Access layer maps channel identities to authorized user identity, uses unified task/session records to continue work, letting user switch entries and still view progress, add requirements, retrieve results.

State organization: model long-lived Agent, specific session, one task, execution environment separately. Pass user/session IDs via RuntimeContext; connect session Context and long-term Memory to state services with clear ownership. Use consistent identity and access rules for local/remote Harness; different sessions keep own execution context, share memory/files only within authorized scope.

Example: user on phone says "continue organizing last week's research and generate comparison report". Remote Harness reads original task progress, context, workspace from state service, continues processing. Public data organization to cloud Hands; when involving user's computer files, route approved tool calls to online local Hands. After report generation, save artifact references for user review on web. User returns to computer, if local Harness to continue, reconnect via checkpoint and execution right handoff.

Provide user choice of Harness execution location and tool execution environment: switching local/remote Harness hands off context, checkpoint, task execution right; switching Hands verifies tool capabilities, files, dependencies, credentials, confirms original tool state. Cloud state service continuously saves identity, tasks, memory, enabling both switches to use same work record.

Background work via persistent scheduler into same task chain. User sets organize materials, monitor projects, conditional reminders; save trigger rules, auth scope, result delivery location; trigger submits stable-ID task, runs, decides whether to notify user based on result.

After adopting Sandbox as Tool, save Agent identity, memory, tasks, todos on service side; start inference and execution only when actually needed. During tool wait or human confirmation, release inference resources per suspension protocol; task wakeup loads state continues. Sandbox retain/recycle decided based on active tools, workspace saving, subsequent task needs.

Include model and Harness config in version management; long-term memory and skill assets use stable ownership and storage boundaries. Upgrade: first check state compatibility, then task regression verify context, tool calls, result quality; clarify new config effective scope for existing sessions, so user-accumulated work assets evolve with service.

Establish clear management process for memory and skill accumulation: distinguish facts, preferences, temporary task info; extract valuable experience per strategy; provide view, revise, delete entry points. Load long-term info as task-required reference context, letting personalized capabilities grow within manageable data boundaries.

Convert Enterprise Business Events into Executable Tasks

Building enterprise agents: configure access adapters for alerts, doc uploads, customer demand updates, ticket timeouts. First deduplicate events and associate business, determine execution identity, available tools, data scope, then create task, save business object, input version, session, task ID mapping.

Example: fault investigation. Connect monitoring alert to investigation agent service entry, fix event, repo/log scope, acceptance requirements for this investigation.

Service accepts, remote Harness as Brain loads task context, reads authorized logs and change records, forms investigation hypotheses. Route tools to enterprise intranet Hands or isolated sandbox per data location and execution permissions, complete reproduction and testing. Save patches, test results, investigation evidence as task artifacts for developer review; if release involved, continue via enterprise existing permission and approval processes.

During long tests, waiting for supplementary info, human confirmation, use same suspension/resumption protocol to save state. Original execution endpoint continues tracking dispatched tools; when results ready or todos answered, Harness with execution right resumes task. Subsequent tools switch to other Hands per auth, still retain original call execution records. User returns to business page, restores display via query and event replay, no need to re-submit investigation.

Document verification reuses same access chain: upload event carries doc version and verification requirements; Agent checks fields against original, saves issues, evidence locations, structured results; business rules decide human review or next step. Material changes create associated new version verification task; write-back re-verifies version, avoiding old results overwriting new facts.

Customer engagement scenario: feed demand change events and periodic tasks into service. Agent uses approved product and customer data to generate proposal draft, sends references, pending confirmations, artifacts back to original business interface. Actions like contact customer, send content, write back CRM go through respective business tools checking auth and confirmation conditions, deduplicate via stable request ID.

These business adapters reuse same task execution chain. Current Harness reads cloud state per execution right, calls selected Hands via authorized routing; tool results and human replies resume along original task.

At adapter and result write-back, enforce business rules: duplicate events reuse original task ID, business input changes create new version; after task ends, verify results, artifacts, current business state, then update business records. Retain execution IDs and confirmation results for external actions, enabling retry, cancellation, human takeover to trace original ops.

Hand determined steps, approvals, transaction boundaries to workflow or business code; use Agent for data understanding, investigation analysis, action adjustment based on feedback. Workflow advances based on verifiable results, giving model judgment and business state updates clear entry points.

Reuse Runtime Foundation, Configure Different Business Boundaries

Personal assistant and enterprise agents reuse identity, task, state, tool execution, recovery mechanisms; configure service objects, trigger methods, memory scope, human participation rules separately.

Primary service object : Personal Agent — Individual and their continuous goals; Enterprise Event-Driven Agent — Team, role, or business process

Common triggers : Personal Agent — Conversation, scheduled tasks, user-authorized events; Enterprise Event-Driven Agent — Alerts, messages, tickets, business state changes

Long-term info : Personal Agent — Personal preferences, project and work memory; Enterprise Event-Driven Agent — Business knowledge, rules, historical handling experience

Human participation : Personal Agent — User supplemental requirements and confirmation actions; Enterprise Event-Driven Agent — Review and approval per role and process

Result delivery : Personal Agent — Files and task results user can continue using; Enterprise Event-Driven Agent — Verifiable business artifacts and state changes

Implementation: reuse AgentScope Harness workspace, memory, context, interaction mechanisms, and service layer task acceptance, execution scheduling, persistent state, resource management. Configure Harness runtime location, Context/Memory services, Hands execution endpoints separately; then determine data and auth scope per individual, project, team, business process. Define tool sets, state handoff, acceptance rules for each agent type, letting same foundation support different runtime combinations.

After business integration, verify task submission, disconnect resume, tool wait, recovery, human confirmation, result write-back; further check local/remote Harness handoff, cloud state read, Hands routing switch behavior; check execution right, input version, original tool results. Then connect agent apps and required storage, execution resources to cloud hosting environment, provide continuous service via these protocols.

Use Alibaba Cloud AgentCore to Host Agent Service

After building the AgentScope-based service, use Alibaba Cloud AgentCore to host agent app runtime and access. For solutions needing custom Harness and business logic, package app and dependencies as container image, deploy via AgentCore high-code agent entry, continue using original framework and service interfaces.

Deployment steps:

Prepare app image — encapsulate AgentScope Harness, business tool adapters, service entry; implement chat and health check interfaces.

Configure runtime and access — set startup command, service port, instance resources, required execution roles; configure network access for model, business systems, storage.

Connect persistent state and execution resources — connect session logs, checkpoints, workspace, scheduling, tool execution backends; using Sandbox as Tool, Harness service accesses independent code execution sandbox via tool interfaces.

Connect app invocation and runtime observation — declare protocol and paths per actual implementation; configure invocation identity, logs, observability; connect returned progress, todos, artifacts back to user entry or business system.

Deployment clarifies platform vs app responsibilities. AgentCore hosts app instances and external access; task state, recovery, tool idempotency, business acceptance reuse built service protocols; databases, scheduling, workspace, execution endpoints deployed and authorized per solution. Full agent environment packaged into execution sandbox → Agent IN Sandbox; Harness and code execution sandbox deployed separately → Sandbox as Tool; pattern still determined by actual execution boundaries.

If choosing to reuse platform's existing execution mechanisms, can use AgentCore managed Harness entry, configure model, role, tools, Skills around provided QwenPaw or Qoder. For custom service architecture based on AgentScope, use custom image to retain Harness and service layer design, leverage platform resources, access, management capabilities.

Future directions for AgentCore as Agent as a Service platform: extend app hosting to continuous Agent service management: let self-built Harness based on AgentScope and platform-managed Harness connect via compatible identity, task, event protocols; provide version release, task scheduling, human intervention, recovery run, result delivery around agent full lifecycle. High-code deployment becomes one entry for developers to access platform; business definition and Harness implementation still freely chosen.

Along this direction, Context and Memory can become independent cloud services, supporting local/remote Harness task continuation under compatible permissions, state, tool protocols; after Brain/Hands separation, platform can coordinate local devices, cloud sandboxes, enterprise intranet execution endpoints by capability, permission, data location. Combined with unified identity auth, resource budgets, runtime observability, effectiveness evaluation, such platform provides cross-device, long-running service foundation for Personal Agent, and event-driven, recoverable, governable task delivery foundation for enterprise agents.

Conclusion

From Personal Agent to enterprise agents: first use AgentScope to organize workspace, memory, context, action; then service layer implements continuous task delivery; finally AgentCore hosts app runtime and connects cloud resources. Maintain consistent identity, state, execution protocols across three layers, enabling personal assistant long-term experience and enterprise task delivery processes to run and evolve continuously.

Related Links

[1] AgentScope project: https://java.agentscope.io/ [2] Alibaba Cloud AI Agent Handbook: https://github.com/aliyun/ai-agent-handbook [3] Alibaba Cloud AgentCore deployment guide:

https://help.aliyun.com/zh/agentcore/high-code-agent-deployment-guide