Skip to main content

multi-agent-focus

Generic skill for self-organizing multi-agent teams that collaborate on an optimization problem. Agents discuss dimensions, form teams, run experiments, and adapt when stagnating. Uses AnonAPI posts for discussion and workspaces for shared state.

소스 정보

저장소
mims-harvard/AutoScientists
최근 소스 활동
2026년 5월 28일 05:00
감지된 SKILL.md 언어
영어
스타
790
포크
126

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
6 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
multi-agent-focus
description
Generic skill for self-organizing multi-agent teams that collaborate on an optimization problem. Agents discuss dimensions, form teams, run experiments, and adapt when stagnating. Uses AnonAPI posts for discussion and workspaces for shared state.
# Multi-Agent Focus Area A **focus area** is a group of AI agents collaborating on an optimization problem. Agents self-organize into teams, each attacking a different dimension of the problem. ## Core Concepts | Concept | What it is | AnonAPI feature | |---|---|---| | **Workshop** | The focus area container — all agents subscribe | `POST /workshops` | | **Main workspace** | Shared state: champion config, all results, cross-team knowledge | `POST /workspaces` | | **Team workspace** | Team-internal state: queue, hypotheses, dead ends, strategy | One per team | | **Posts** | Discussion: proposals, results, strategy debates, votes | `POST /posts` | | **Workspace files** | Structured data with YAML frontmatter, versioned, searchable | `PUT /workspaces/{id}/files/{path}` | ## How It Works ``` 1. BOOTSTRAP — Monitor creates workshop + main workspace + kickoff post 2. DISCUSS — All agents propose dimensions, debate, vote on teams 3. EXECUTE — Teams run experiments in parallel, share results 4. ADAPT — Stagnating teams restructure via discussion + vote ``` See `reference/PHASES.md` for detailed lifecycle. ## Agent Roles | Role | Count per team | What they do | |---|---|---| | **Monitor** | 1 (global) | Bootstrap, facilitate team formation, monitor health | | **GPU Agent** | 2 per team | Claim experiments, train models, record results | | **Analyst** | 1 per team | Research mechanisms, propose experiments, prune dead ends | See `templates/ROLE-MONITOR.md`, `templates/ROLE-GPU.md`, `templates/ROLE-ANALYST.md`, `templates/ROLE-TEAM.md`. ## Main Workspace — Initial Files These files are created during bootstrap. Agents may create additional files as needed — other agents discover them via LIST. ``` champion.md — Current best config (ESSENTIAL ANCHOR — always read) results/{exp_id}.md — One file per experiment result (write-once) teams/roster.md — Team assignments and workspace IDs (ESSENTIAL ANCHOR) ``` Additional files are created organically by agents (e.g., `knowledge/lr-schedules.md`). Use `GET /files` to discover what exists. ## Team Workspace — Initial Files ``` queue.md — Pending experiments + active claims (ESSENTIAL ANCHOR) dead_ends.md — Mechanisms ruled out by this team strategy.md — Current team approach ``` Agents may create additional files (analysis docs, hypothesis lists, etc.). Use descriptive paths — see `templates/ROLE-TEAM.md` § File Naming Convention. ## Coordination Model - **Discovery over prescription** — agents LIST workspace files each cycle and decide what to read, rather than following hardcoded file checklists. See `templates/ROLE-TEAM.md` § File Discovery Protocol - **Posts for discussion** — proposals get debated before entering a queue - **Workspaces for state** — structured data with version history - **Notifications for alerts** — `notify_agents` on post creation - **PATCH for concurrency** — dot-notation frontmatter updates don't conflict - **Client-side YAML parsing** — the API stores files as raw text. Agents must parse YAML frontmatter themselves (see `API-REFERENCE.md`) - **Champion propagation** — orchestrator copies winning train.py to `{FOCUS_ROOT}/champion/train.py` after each KEEP. All GPU agents read from this canonical path ## Discussion-Before-Queuing Rule Every experiment MUST start as a `[PROPOSAL]` post. At least 1 team member must comment before it enters the team queue. This ensures peer review of ideas before spending GPU time. ## Cross-Team Coordination 1. All results go to **main workspace** `results/` — visible to every team 2. **Near-misses** (delta < threshold) trigger cross-team joint experiments 3. **KEEP results** (new champion) update main `champion.md` — all teams rebase 4. Monitor posts periodic `[AUDIT]` summarizing all team progress ## Using This System This system is **problem-agnostic**. The specific optimization problem is defined in a **task file** (a `TASK.md` inside the directory passed via `--task` to `launch.py`). The task defines: - What metric to optimize - How to run an experiment - What the search space looks like - Hardware constraints To start a new focus area: read your task file, then follow `PHASES.md`.
GitHub에서 보기