自定义工具怎么接入和内置工具一样的沙箱

[zxqQing]

public class ShellExecuteTool {
public static final String NAME = "execute";
private final AbstractSandboxFilesystem sandbox;

public ShellExecuteTool(AbstractSandboxFilesystem sandbox) {
    this.sandbox = sandbox;
}

@Tool(
    description = "Execute a shell command. Use for git, npm, build, test, and other terminal operations. Returns combined output and exit code. If a dedicated tool exists (e.g., read_file, write_file), you MUST use it instead of shell commands."
)  自定义工具 在 new对象 怎么注入 private final AbstractSandboxFilesystem sandbox;

[stanleys12]

You can't inject it through the constructor, because the sandbox filesystem doesn't exist yet when you build your tool. Let the tool receive the sandbox per call through RuntimeContext instead.

Why: HarnessAgent.build() creates the SandboxBackedFilesystem itself, and only new ShellExecuteTool(sandbox) inside the builder gets it (HarnessAgent.java#L2641-L2647, L2916-L2918). That filesystem is only a stable proxy. The real sandbox is acquired per call by SandboxLifecycleMiddleware and stored on the RuntimeContext as a SandboxAcquireResult (SandboxLifecycleMiddleware.java#L131). The proxy looks it up the same way (SandboxBackedFilesystem.java#L239-L258). The doc comment there says this per-call binding is what keeps concurrent sessions isolated.

So declare a RuntimeContext parameter on your @Tool method. The framework fills it in and it is not an LLM argument, as ShellExecuteTool.execute already does (ShellExecuteTool.java#L43-L66). Then take the sandbox from the context:

public class MyTool {
    @Tool(description = "Run a command in the sandbox")
    public ToolResultBlock run(
            RuntimeContext rc,
            @ToolParam(name = "command", description = "Shell command") String command) throws Exception {
        SandboxAcquireResult acq = rc == null ? null : rc.get(SandboxAcquireResult.class);
        if (acq == null || acq.isReleased()) {
            return ToolResultBlock.error("No active sandbox for this call");
        }
        ExecResult r = acq.getSandbox().exec(rc, command, 30);
        return ToolResultBlock.text("exit=" + r.exitCode() + "\n" + r.combinedOutput());
    }
}

Sandbox.exec(RuntimeContext, String, Integer) is at Sandbox.java#L71. Register the tool on a Toolkit and pass it with HarnessAgent.builder().toolkit(toolkit) (HarnessAgent.java#L1696), together with .filesystem(new DockerFilesystemSpec()...) so sandbox mode is on. The tool then runs in the same per-user or per-session sandbox as the built-in execute.

Check the SandboxAcquireResult for null as in the snippet. It is only set when a sandbox filesystem spec is configured. I read this from the code and did not run the snippet. Check the ToolResultBlock factory names against your version.

(I looked this up in the code with help from an AI assistant; the links are to the lines I checked.)