# ModelHub Adaptation Agent This repository is packaged for the ModelHub XC agent platform. ## Platform Contract - Root-level `Dockerfile` - Listens on port `8080` - Exposes `GET /health` - Handles `SIGTERM` - Reads platform-provided `STRATEGY_ID` and attaches it to task submissions as `strategyId` The root `main.py` starts a lightweight health server and runs the existing submission poller in a child process. ## Runtime Environment The image includes multi-account ModelHub and ModelScope token fallbacks for the agent platform. Environment variables can override them without rebuilding the image. - `MODELHUB_XC_TOKEN`, `XC_TOKEN`, `XC_TOKEN2...`, or `MODELHUB_XC_TOKENS` for ModelHub API authentication - `MODELHUB_JWT_TOKEN` or `JWT_TOKEN` can be used instead when the platform provides a JWT - `MODELSCOPE_API_TOKEN` or `MODELSCOPE_TOKEN` optional override for the embedded ModelScope fallback token - `STRATEGY_ID` is expected to be injected by the ModelHub agent platform and is attached to submissions for strategy attribution; it is not an API authentication token Optional tuning: - `MODELHUB_AGENT_POLL_INTERVAL_SECONDS` default `15` - `MODELHUB_AGENT_IDLE_INTERVAL_SECONDS` default `60` - `MODELHUB_AGENT_POST_CYCLE_COOLDOWN_SECONDS` default `2` - `MODELHUB_AGENT_MAX_SUBMITS_PER_RUN` default `0` (fill all currently available slots) - `MODELHUB_AGENT_ACTIVE_TASK_CAP` default `100` per account - `MODELHUB_AGENT_ACTIVE_COUNTS_TTL_SECONDS` default `15` - `MODELHUB_AGENT_RESERVATION_TTL_SECONDS` default `120` - `MODELHUB_AGENT_INSTANCE_ID` optional stable worker identity used to spread concurrent agents across accounts and candidates - `MODELHUB_AGENT_CLAIMS_PATH` default `.modelhub_state/submission_claims.jsonl` - `MODELHUB_AGENT_DAILY_TARGET` - `MODELHUB_AGENT_MIN_DOWNLOADS` - `MODELHUB_AGENT_GPUS` - `MODELHUB_AGENT_EXTRA_ARGS` ## Concurrent Agents The token pool keeps a local reservation for every in-flight submission, so a lagging platform count cannot send all concurrent requests to the same account. If another process fills an account first, the submission is retried immediately against another account with capacity. Workers that share a filesystem also coordinate model/GPU claims through `.modelhub_state/submission_claims.jsonl`. Workers in isolated containers use different candidate ordering (derived from `STRATEGY_ID`, instance ID, or hostname), which reduces duplicate work while the platform remains the final authority for account capacity and model/GPU uniqueness. ## Deploy Create a tag and submit the repository URL plus tag in "我的适配智能体". ```bash git tag agent-v6 git push origin agent-v6 ```