aws-samples/sample-autonomous-cloud-coding-agents

ABCA

AWS 上的自主后台编码代理

[!注] 当前版本的ABCA仍然可供使用，未被弃用。 目前处于维护状态，并将持续接受更新和安全修复。

团队正在投资下一版本的ABCA（V2），基于客户反馈、经验教训和行业进展。我们提前分享这一方向，以示未来转型。目前无需迁移。

什么是ABCA

ABCA（AWS 上的自主后台编码代理） 是 AWS 上自托管后台编码代理平台的一个示例。你提交编码任务（通过 Slack、线性、Jira、CLI 或 webhook），离开后回来即可查看的 PR。代理会克隆仓库，编写代码，运行测试，并在孤立的云环境中自主打开 PR。没有看护，没有 IDE 会话，也没有来回沟通。

为什么重要

• 重新找回工程师时间——常规工作在后台运行，而人类专注于设计和决策
• 更快的周期时间 — 任务全天候执行，无需排队排队

[!NOTE] The current version of ABCA remains available for use and is not deprecated. It is in maintenance mode and will continue to receive updates and security fixes.

The team is investing in the next version of ABCA (V2), informed by customer feedback, lessons learned, and advances across the industry. We are sharing this direction early to signal a future transition. No migration is required at this time.

What is ABCA

ABCA (Autonomous Background Coding Agents on AWS) is a sample of what a self-hosted background coding agents platform might look like on AWS. You submit a coding task (via Slack, Linear, Jira, CLI, or webhook), walk away, and come back to a ready-to-review PR. The agent clones the repo, writes code, runs tests, and opens the PR autonomously in an isolated cloud environment. No babysitting, no IDE sessions, no back-and-forth.

Why it matters

• Reclaim engineer time — routine work runs in the background while humans focus on design and decisions
• Faster cycle time — tasks execute 24/7, no queue behind a human’s calendar
• Consistent quality — every run includes lint, tests, and policy checks by default
• Learns over time — memory system captures PR feedback and improves future runs
• Cost-controlled — per-task budgets, concurrency limits, and blast-radius enforcement built in

The Use Case

Users submit tasks through webhooks, CLI, Slack, Linear, Jira,… For each task, the orchestrator executes the blueprint: an isolated environment is provisioned, an agent clones the target GitHub repository, creates a branch, works on the task, and opens a pull request.

Key characteristics:

• Ephemeral environments — each task starts fresh, no in-process state carries over
• Asynchronous — no real-time conversation during execution
• Repository-scoped — each task targets a specific repo
• Outcome-measurable — the PR is either merged, revised, or rejected
• Fire and forget — submit, forget, review the outcome
• Learns over time — the more you use it, the more it self-improves

How it works

Each task follows a blueprint — a hybrid workflow that mixes deterministic steps (no LLM, predictable, cheap) with agentic steps (LLM-driven, flexible, expensive):

1. Admission — the orchestrator validates the request, checks concurrency limits, and queues the task if needed.
2. Context hydration — the platform gathers context: task description, GitHub issue body, repo-intrinsic knowledge (CLAUDE.md, README), and memory from past tasks on the same repo.