Skip to content

Commit f8da34a

Browse files
committed
rm hub, update docs
1 parent c5a3a13 commit f8da34a

17 files changed

Lines changed: 101 additions & 715 deletions

File tree

README.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@
1414

1515
<p align="center">
1616
<a href="https://edge-bench.org/"><img src="https://img.shields.io/badge/Project-edge--bench.org-blue" alt="Project"></a>
17-
<a href="assets/paper.pdf"><img src="https://img.shields.io/badge/Paper-PDF-red?logo=adobeacrobatreader" alt="Paper"></a>
17+
<a href="assets/paper.pdf"><img src="https://img.shields.io/badge/Tech%20Report-PDF-red?logo=adobeacrobatreader" alt="Tech Report"></a>
1818
<a href="https://huggingface.co/datasets/ByteDance-Seed/EdgeBench"><img src="https://img.shields.io/badge/%F0%9F%A4%97%20HuggingFace-Dataset-yellow" alt="Dataset"></a>
1919
<a href="https://github.com/ByteDance-Seed/SForge"><img src="https://img.shields.io/badge/GitHub-SForge%20Harness-green?logo=github" alt="Harness"></a>
2020
<a href="https://bytedance-seed.github.io/SForge/"><img src="https://img.shields.io/badge/Docs-SForge-purple" alt="Docs"></a>
@@ -26,7 +26,7 @@
2626

2727
**EdgeBench** is a benchmark of **134 real-world tasks** for evaluating how autonomous AI agents *learn from real-world environments*. Instead of measuring one-shot performance, EdgeBench places agents in executable task environments with realistic, multi-level feedback and lets them iterate for **12+ hours** per task — tracking the full trajectory of improvement, not just the final score. We publicly release **51 tasks** along with the full evaluation framework.
2828

29-
Analyzing ~25,000 hours of agent interaction across 1,932 runs on all 134 tasks, we find that **performance follows a log-sigmoid scaling law as a function of interaction time** ($R^2 = 0.998$), and that agent learning speed roughly doubles every three months across frontier model generations. See the [paper](assets/paper.pdf) for details.
29+
Analyzing ~25,000 hours of agent interaction across 1,932 runs on all 134 tasks, we find that **performance follows a log-sigmoid scaling law as a function of interaction time** ($R^2 = 0.998$), and that agent learning speed roughly doubles every three months across frontier model generations. See the [tech report](assets/paper.pdf) for details.
3030

3131
> To evaluate on the full 134-task suite, please contact [zhongshu@bytedance.com](mailto:zhongshu@bytedance.com).
3232

docs/en/configuration/environment-variables.md

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -86,13 +86,6 @@ Judge CPU/memory limits are currently set through CLI flags (`--judge-cpu-limit`
8686
| `SFORGE_K8S_KUBECONFIG` | --- | Path to kubeconfig file |
8787
| `SFORGE_K8S_NODE_SELECTOR` | --- | Node selector for K8s pods, format: `"key1=val1,key2=val2"` |
8888

89-
## Experiment Hub Variables
90-
91-
| Variable | Purpose |
92-
|----------|---------|
93-
| `SFORGE_HUB_URL` | Experiment hub server URL. When set, run artifacts are mirrored to this shared server. |
94-
| `SFORGE_HUB_USER` | Hub user namespace. Run IDs are prefixed with `<hub_user>-` on the hub so each person's runs are isolated. |
95-
9689
## Path Variables
9790

9891
| Variable | Default | Purpose |
@@ -152,8 +145,4 @@ export SFORGE_WORK_MEM_LIMIT="8g"
152145
export SFORGE_BACKEND="k8s"
153146
export SFORGE_K8S_NAMESPACE="sforge-runs"
154147
export SFORGE_K8S_IMAGE_REGISTRY="registry.example.com/sforge"
155-
156-
# Experiment hub
157-
export SFORGE_HUB_URL="https://hub.example.com"
158-
export SFORGE_HUB_USER="alice"
159148
```

docs/en/guide/agents.md

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Supported Agents
22

3-
SForge manages different Code Agents through the `AgentSpec` registry. Each Agent defines installation commands, run commands, API configuration, and related metadata, and is executed by the unified `run_agent()` function.
3+
SForge manages different Code Agents through a plugin-style agent registry. To run EdgeBench evaluations, simply pick a built-in agent (e.g., `claude-code`) and provide an API key.
44

55
## Agent Registry
66

@@ -57,16 +57,15 @@ sforge run --task ad_placement_optimization --agent claude-code
5757

5858
The complete Agent lifecycle is:
5959

60-
1. **Build images**: build the Base, Work, and Judge images
61-
2. **Create container**: create a Docker container from the Work image and inject environment variables such as API key and Judge URL
62-
3. **Install Agent runtime**: run the Agent's `install_cmds` inside the container, such as installing Node.js or npm packages
63-
4. **Install evaluation tools**:
60+
1. **Create container**: create a Docker container from the Work image and inject environment variables such as API key and Judge URL
61+
2. **Install Agent runtime**: run the Agent's `install_cmds` inside the container, such as installing Node.js or npm packages
62+
3. **Install evaluation tools**:
6463
- `sforge-submit`: installed into `/usr/local/bin/`; the Agent calls this command to submit code
6564
- Stop Hook (optional): prevents the Agent from exiting too early
6665
- Auto-eval daemon (optional): periodically evaluates in the background
67-
5. **Generate enhanced prompt**: combine the original task description with evaluation instructions and strategy suggestions
68-
6. **Run Agent**: execute the Agent's `run_cmd`; the Agent starts working inside the container
69-
7. **Collect results**: after the Agent times out or finishes, read the best score from the state file
66+
4. **Generate enhanced prompt**: combine the original task description with evaluation instructions and strategy suggestions
67+
5. **Run Agent**: execute the Agent's `run_cmd`; the Agent starts working inside the container
68+
6. **Collect results**: after the Agent times out or finishes, read the best score from the state file
7069

7170
During the process, the Agent can call `sforge-submit` at any time to submit code and receive feedback. The background auto-eval daemon also periodically submits evaluations.
7271

@@ -114,8 +113,8 @@ Auto-resume handles **abnormal agent exits** (API disconnects, transient errors,
114113

115114
### Safety Guards
116115

117-
- If the agent exits in **under 30 seconds**, the harness assumes a systematic failure and stops retrying
118-
- Maximum of **50 resume attempts** per run
116+
- If the agent exits in **under 1 second**, the harness assumes a systematic failure and stops retrying
117+
- Maximum of **100 resume attempts** per run
119118

120119
### Disabling Auto-Resume
121120

docs/en/guide/introduction.md

Lines changed: 13 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,14 @@ SForge is a Code Agent evaluation framework designed for ultra-long-horizon iter
66

77
SForge natively supports EdgeBench, which contains **130+ evaluation tasks**. Tasks cover Python, Java, Go, Rust, C/C++, and other runtime environments, and support multiple evaluation types such as test-driven tasks, score optimization, interactive games, and theorem proving.
88

9+
## Key Mechanisms
10+
11+
SForge's design centers on three mechanisms:
12+
13+
1. **Two-container isolation** — work and judge environments are fully separated, preventing evaluation hacking at its root. The agent never sees the test suite.
14+
2. **Iterative evaluation with feedback** — agents don't submit once at the end for a one-shot score; instead they submit throughout the run, receive granular feedback (pass rates, failing tests, scores), and improve in a closed loop until timeout — the best result across all submissions is the final score.
15+
3. **Long-horizon execution** — stop hooks prevent premature agent exit, auto-resume recovers from transient failures, and the Kubernetes backend enables parallel runs at scale.
16+
917
## Two-Container Architecture
1018

1119
SForge's core design fully isolates the agent workspace from the evaluation environment:
@@ -46,10 +54,10 @@ SForge lets agents submit code for evaluation multiple times and receive feedbac
4654

4755
In addition, SForge includes an **auto-eval** mechanism: a background daemon periodically submits the code for evaluation (default: every 300 seconds), ensuring that agent progress is recorded in time even if the agent forgets to submit manually.
4856

49-
## Key Mechanisms
57+
## Long-Horizon Execution
5058

51-
SForge's design centers on three mechanisms:
59+
Evaluation tasks typically run for tens of minutes or even hours. SForge uses several mechanisms to ensure agents fully utilize the allocated time:
5260

53-
1. **Two-container isolation** — work and judge environments are fully separated, preventing evaluation hacking at its root. The agent never sees the test suite.
54-
2. **Iterative evaluation with feedback** — agents don't submit once at the end for a one-shot score; instead they submit throughout the run, receive granular feedback (pass rates, failing tests, scores), and improve in a closed loop until timeout — the best result across all submissions is the final score.
55-
3. **Long-horizon execution** — stop hooks prevent premature agent exit, auto-resume recovers from transient failures, and the Kubernetes backend enables parallel runs at scale.
61+
- **Stop Hook**: intercepts the agent's exit requests and prevents it from quitting before time runs out. When the agent decides the "task is done," the stop hook tells it to keep checking and improving.
62+
- **Auto-Resume**: when the agent crashes due to API disconnects, transient errors, or other abnormal exits, the harness automatically re-launches it using the agent's native session resume mechanism (e.g., `claude --continue`) and passes the remaining timeout budget to the resumed session.
63+
- **Kubernetes backend**: enables large-scale parallel runs, evaluating multiple tasks or agents simultaneously.

docs/en/reference/cli.md

Lines changed: 0 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,6 @@ Developer-oriented commands such as `build`, `push`, and `hub` are grouped at th
3838
|------------|---------|-----------|
3939
| `build` | Build base, work, and judge images locally | `--task`, `--force-rebuild`, `--force-rebuild-with-base` |
4040
| `push` | Push locally-built images to a registry | `--task`, `--registry` |
41-
| `hub` | Start the shared experiment hub | `--runs-dir`, `--tasks-dir`, `--host`, `--port` |
4241

4342
## Global Options
4443

@@ -264,25 +263,3 @@ sforge push --task ad_placement_optimization gitlet --registry registry.example.
264263
|------|-------------|
265264
| `--task` | One or more task IDs (required) |
266265
| `--registry` | Remote container registry URL (overrides `SFORGE_REGISTRY` env var) |
267-
268-
### sforge hub
269-
270-
Start the experiment hub server: shared file sync API plus visualizer over one runs directory. Remote harness machines push run artifacts here for centralized viewing.
271-
272-
```bash
273-
sforge hub --runs-dir logs/runs --port 8090
274-
```
275-
276-
| Flag | Default | Description |
277-
|------|---------|-------------|
278-
| `--runs-dir` | `logs/runs` | Directory to store received run folders |
279-
| `--tasks-dir` | `tasks/` | Directory of task JSON definitions |
280-
| `--host` | `0.0.0.0` | Bind address |
281-
| `--port` | `8090` | Listen port |
282-
283-
Configure harness machines to push results to the hub with:
284-
285-
```bash
286-
export SFORGE_HUB_URL="http://<hub-host>:8090"
287-
export SFORGE_HUB_USER="alice" # optional, namespaces runs as alice-<run_id>
288-
```

0 commit comments

Comments
 (0)