Tencent Cloud Agent Runtime sandbox integration: lifecycle compatibility for #4992

Related issue: #4992

I would like to contribute the sandbox execution integration requested in #4992. This proposal is for Ideas scope alignment before a non-trivial implementation.

DeerFlow already has a provider abstraction and an E2B implementation that forwards a custom domain to create/connect/list. Tencent documents an E2B-compatible entry point, ap-guangzhou.tencentags.com, and an account-created sandbox-tool name supplied as template:

https://cloud.tencent.cn/document/product/1814/123816

However, the currently published sandbox-instance guide explicitly lists creation-time metadata and envs among unavailable parameters:

https://cloud.tencent.com/document/product/1814/123848

That matters because DeerFlow's E2B provider uses metadata for user/thread/skills-root ownership, startup adoption, duplicate cleanup, and shared capacity reconciliation. Merely changing the domain would not establish the same lifecycle contract.

Proposed initial capability:

• A clearly identified Tencent sandbox integration using the existing E2B SDK and reusable execution/file wrapper where their contracts match.
• Support command execution, exit status/errors/timeouts, file read/write/upload/download, user/thread-scoped acquisition, and explicit release/shutdown.
• Never emulate remote metadata with process-local values while claiming cross-worker recovery. If the service still lacks metadata, either use an accepted durable ownership registry or explicitly scope the initial integration to one Gateway process with fresh acquisition after restart and a finite server-side sandbox lifetime.
• Do not enumerate an account's untagged sandboxes and adopt or delete them. Cleanup may operate only on exact instances owned by the integration.
• Do not silently drop sandbox.environment if creation-time envs is unsupported. Decide whether the first implementation rejects it with an actionable error or uses a separately validated execution-time mechanism.
• Keep credentials on the Gateway/SDK side; do not inject the Tencent service credential into the sandbox environment.
• Document supported template requirements, file layout, timeout behavior, and restart semantics.

Offline validation matrix:

1. Management calls use the configured Tencent endpoint/template without unsupported create fields.
2. Identical user/thread acquisition is serialized and reused within the supported ownership lifetime; different user/thread scopes do not share a sandbox.
3. Failed creation, cancelled acquisition, partial file bootstrap, release, shutdown, and remote expiry have deterministic cleanup behavior.
4. Only owned sandbox IDs can be terminated; untagged account inventory is never treated as owned.
5. Execute a command, propagate nonzero status, and round-trip text/binary files through the real wrapper with a fake transport.
6. Async entry points do not block the event loop; offline tests require no cloud credentials.

Live validation must separately prove the behavior against a real Tencent sandbox tool and record the service region, template, and SDK version. A fake SDK result cannot establish cloud compatibility. No live validation has been performed yet.

Decisions requested:

1. Is an explicitly single-Gateway initial provider acceptable, or is durable cross-worker ownership required for the first PR?
2. Is the metadata/envs limitation still accurate for the target Tencent service? A current contract or reproducible response would prevent building around stale documentation.
3. Should the integration be a Tencent-specific provider, or an explicit capability profile on the E2B provider? Defaults and existing E2B guarantees would remain unchanged.

AI assistance: Codex helped inspect the source and Tencent documentation and draft this proposal. This is a design request, not an implementation or test-success claim.