Antibody Design

Sandboxed Ascend antibody Protenix pipeline

Run the model pipeline as one managed background Shell Execution. Use the same Runner and managed scientific environment for preparation, validation, launch, monitoring, and output transfer.

Execution contract

• Launch model/NPU work only with run_shell(background=true) and the bundled scripts/run_sandbox_pipeline.sh. Do not use run_npu_job, a host bridge, nohup, a persistent kernel, or an Agent-authored copy of the bundled scripts.
• Select runner_id from the Runners authorized for the Session. Do not hardcode local. A remote Runner has an independent workspace and independent managed environments.
• Retain the returned Shell Execution ID. Monitor it with execution_status and execution_logs; these calls do not take the workspace write lock. Never submit the pipeline again because a wait ended or an execution is unknown.
• Model code, checkpoints, input PDBs, and outputs must resolve inside the selected Runner workspace. Put model assets below antibody_pipeline/models/. Config paths are workspace-relative. Do not use host absolute paths, symlink escapes, python, scripts_dir, pipeline_env, or cann_set_env in config.json.
• Python packages belong to the selected Runner's managed scientific environment. Install or update them through environment_*, never with pip, conda, or an environment activation script inside run_shell.
• The NPU cards selected for a Runner are exposed inside the sandbox as logical devices 0..N-1. npus uses those sandbox-local IDs, not the host's physical card numbers. If one card is selected, use "0".
• There is no default antigen or antibody framework. Require a target PDB, framework PDB, and chain-labelled hotspots such as [B45,B46,B49].
• Treat a missing target, framework, or hotspot list as missing user input. Stop and ask for that input; do not infer an epitope, launch a SubAgent, search the web, or choose residues from geometry without an explicit user request.
• On first use in a Session, prepare model code and checkpoints inside the selected Runner workspace with the bundled --prepare-only entrypoint. It uses pinned official sources, applies the bundled RFdiffusion MindSpore Tensor-to-PDB compatibility patch, downloads the official RFdiffusion, ProteinMPNN, and Protenix checkpoints, verifies their size and SHA-256, and reuses verified files on later runs in the same Session. Do not invent mirror URLs, scan unrelated host paths, or copy assets from another Session.

1. Choose and prepare the Runner

Use the Runner catalog in the run_shell / environment_list tool schema and the Session settings. Choose the machine requested by the user, or the single authorized NPU Runner. Keep its ID as <runner-id> for every Runner-scoped call.

For a remote Runner:

1. Call sync_remote_workspace(operation="list", runner_id="<runner-id>").
2. Push only missing local inputs with operation="push". Model repositories and checkpoints already present in this Session's remote workspace should stay there; do not copy them back and forth.
3. Use remote-workspace paths in config.json. Local file tools cannot inspect remote-only files.

Before preparation, check the three required user inputs. If one is missing, ask once and stop this run. The first preparation needs outbound access to the official gitcode.com, gitee.com, tools.mindspore.cn, and af3-dev.tos-cn-beijing.volces.com domains. The last domain is used by Protenix for its CCD cache. If the Session sandbox network policy does not allow these domains, report the required allowlist change before launching the download. Do not switch the sandbox to unrestricted network access.

The user or operator must select usable Ascend cards for that Runner in system settings before launch. The sandbox receives only those cards and renumbers them from zero.

2. Select and probe the managed environment

Call environment_list(runner_id="<runner-id>"). Probe a candidate environment on the same Runner with a short foreground run_shell call and keep its environment ID. The environment must provide the packages in requirements.txt. Always pass that explicit environment_id to the probe; never validate against the Runner's starter/default Python. Probe ready task environments whose names identify this antibody pipeline first (for example, a name containing antibody), then probe the remaining ready task environments if needed. After one candidate fails, continue to the next candidate instead of inspecting model source or the uploaded PDBs for a Python dependency problem. Validate that complete, single-source dependency manifest with the selected environment's Python:

python "$SCIENCEDISCOVERY_SKILLS_DIR/antibody-design/scripts/validate_managed_environment.py" \
  "$SCIENCEDISCOVERY_SKILLS_DIR/antibody-design/requirements.txt"

The validator reads every dependency and exact pin directly from requirements.txt; do not maintain a separate partial package list.

If no environment passes, create or update one on the same Runner with environment_create / environment_install, then probe it again. For a remote Runner, push any workspace-local wheel before installing it.