DOCSEARCHbyAlgolia
Submit Docs

SWE-agent

repository·main·Indexed 12 days ago

https://github.com/princeton-nlp/SWE-agent

An autonomous agent framework and Agent Computer Interface (ACI) that enables LLMs to interact with software environments to fix GitHub issues, solve coding challenges, and perform offensive cybersecurity tasks via EnIGMA. It is optimized for research and benchmarking on SWE-bench and is highly configurable via YAML.

Tokens
37.8K
Snippets
140
Records
207
Agent score
97%

What's inside SWE-agent

  1. Overview of SWE-agent capabilities

    main

    SWE-agent allows language models (such as GPT-4o or Claude Sonnet 4) to autonomously use tools to accomplish various tasks, including:

    • Fixing GitHub issues: Automatically resolving issues in real GitHub repositories.
    • Cybersecurity: Finding vulnerabilities (via EnIGMA).
    • Custom Tasks: Performing general coding challenges or custom automation tasks.

    Key features include being state-of-the-art on SWE-bench, providing maximal agency to the LM, and being fully configurable via a single yaml file.

  2. Overview of SWE-agent

    main

    SWE-agent is an autonomous agent framework that enables language models (such as GPT-4o or Claude Sonnet 4) to use tools to perform software engineering tasks. Key capabilities include:

    • Issue Fixing: Automatically fixing issues in real GitHub repositories.
    • Cybersecurity: Finding vulnerabilities via the EnIGMA mode.
    • Custom Tasks: Performing arbitrary coding challenges.

    Key Features:

    • State of the art: High performance on SWE-bench.
    • Generalizable: Provides maximal agency to the language model.
    • Configurable: Entirely governed by a single yaml configuration file.
    • Research-oriented: Designed to be simple and hackable.

  3. What is SWE-agent

    main
    SWE-agent is a system that transforms Large Language Models (LMs), such as GPT-4, into software engineering agents capable of resolving issues in GitHub repositories. It achieves state-of-the-art performance on the SWE-bench benchmark by utilizing an Agent-Computer Interface (ACI). The ACI consists of simple, LM-centric commands and feedback formats designed to help the model browse repositories, view and edit code, and execute files efficiently.

  4. Understand the SWE-agent configuration directory structure

    main

    The config/ directory contains various YAML configuration files used to define agent behavior, model settings, and tool availability. Key subdirectories and files include:

    • anthropic_filemap.yaml: The default configuration.
    • swebench_submissions: Configurations specifically used for SWE-bench submissions.
    • sweagent_0_7: Configurations from version 0.7, similar to those used in the original research paper.
    • human: Demo or debug configurations that use human type commands and run without a Language Model (LM).
    • demo: Configurations optimized for demonstrations or talks.
    • exotic: Niche or specific configurations for specialized use cases.

  5. What is SWE-agent EnIGMA

    main

    EnIGMA is an extension of SWE-agent designed for offensive cybersecurity. It is optimized for solving Capture The Flag (CTF) challenges (e.g., cryptography, reverse-engineering, forensics).

    Key features include:

    • Interactive Agent Tools (IATs): Enables the agent to use interactive tools like debuggers in a multitasking manner, allowing the agent to maintain access to the main shell while using the tool.
    • Summarizer Concept: A mechanism integrated into the agent to manage long context windows.
    • Category-Specific Demonstrations: Specialized demonstrations built for different CTF categories to improve task-solving capabilities.

  6. What is the Agent Computer Interface (ACI)?

    main
    The Agent Computer Interface (ACI) is the set of tools and interaction formats that allow an agent to interact with a computer-based environment to perform tasks like software engineering. In SWE-agent, the ACI is designed to optimize agent performance by providing specialized tools rather than generic shell commands. Effective ACI design is considered as critical as prompt engineering for agent success.

  7. Understand the SWE-agent execution lifecycle

    main

    When running sweagent run, the process follows these stages:

    1. Deployment Setup: SWE-agent starts a sandboxed environment (default is Docker, but can be Modal, AWS Fargate, or local). This is managed by SWE-ReX.
    2. Tool Setup: Specified tools are copied and installed within the environment.
    3. Prompting: The system and instance prompts (initial instructions) are provided to the LM.
    4. Main Loop: The LM iteratively suggests and executes actions.
    5. Submission: The LM calls submit, and SWE-agent extracts the resulting patch (the code changes that solve the problem).

    Detailed logs of the run are saved as a "trajectory" file.

  8. Configure message templates with TemplateConfig

    main

    SWE-agent uses templates to format inputs and outputs into prompts or messages sent to the Language Model (LM). You can define these message templates and formatting rules using the sweagent.agent.agents.TemplateConfig class. These templates control how the agent's internal state, tool outputs, and user instructions are structured before being queried by the LM.

    ::: sweagent.agent.agents.TemplateConfig

  9. Understand the structure of SWE-agent tool bundles

    main

    In SWE-agent, tools are organized into tool bundles. A tool bundle is a directory containing the tool's implementation, configuration, and installation scripts. This modular structure allows the agent to use diverse capabilities like bash, file viewers, and code editors.

    A standard tool bundle follows this directory structure:

    bundle/
├── bin/
│   └── <tool executable>
│   └── <state executable>
├── config.yaml
├── install.sh
├── README.md
└── pyproject.toml

    The bin/ directory is critical as it houses the actual executable implementations of the tool and its state management command.

  10. Use the Registry bundle for persistent state

    main

    The registry bundle provides a persistent key-value store that survives across multiple tool calls. It is recommended over environment variables for storing complex data structures like lists or dictionaries.

    Note: You must include tools/registry in your bundles list before your custom tools.

    1. Setting registry variables in config

    agent:
  tools:
    registry_variables:
      MY_LIST: ["item1", "item2"]
      DEBUG: true
    bundles:
      - path: tools/registry
      - path: tools/my_tool

    2. Accessing registry in Python tools

    Use the registry module to get and set values:

    from registry import registry

# Get value
val = registry.get("MY_LIST", [])

# Set value (persists across calls)
registry["LAST_CALL"] = "2024-01-01"

    3. Accessing registry in Bash tools

    Use the _read_env helper function within your scripts:

    #!/bin/bash
VALUE=$(_read_env "MY_LIST" "default_value")
echo "Value is: $VALUE"

  11. How to customize agent demonstrations

    main
    SWE-agent uses a demonstration trajectory at the start of each run to show the agent how to solve an example issue, which improves performance on novel tasks. You can modify or replace these demonstrations to better suit your specific use case by following the guidance in the demonstrations configuration guide.

  12. How the SWE-agent architecture works

    main

    SWE-agent operates through a coordinated loop between an Agent and a managed environment (SWEEnv).

    1. Initialization: The sweagent CLI entry point initializes SWEEnv, which manages the execution environment via the SWE-ReX package.
    2. Environment Setup: SWEEnv triggers a SWE-ReX Deployment, which can either start a local Docker container or a remote container (e.g., on Modal or AWS). Inside this container, a shell session is started, and ACI elements are installed as custom tools.
    3. The Agent Loop: The Agent class is initialized (often via a YAML configuration file). Its core method, forward(), drives the process:
      • History Management: A HistoryProcessor compresses the interaction history (prompts, actions, and outputs) to optimize the LLM's context window.
      • Model Interaction: The compressed history is sent to the Language Model (LM).
      • Action Execution: The model's output is parsed by a parser to extract a specific action. This action is then sent to SWEEnv, which communicates with the server running inside the Docker container to execute the command in the shell session.