Android Studio Rabbit 2 现在能跑 40+ 编码代理：周一真正会变的是什么

2026 年 10 月 28 日，Android Dev Summit 当天，Google 把 Android Studio Rabbit 2（2026.2.2）推进了稳定渠道。头条不是一个新模型，而是 IDE 不再只认自家的助手：Bring Your Own Agent 转为稳定，40 多个说开放 Agent Client Protocol 的编码代理——Google 点名了 Claude Agent、Codex、Junie 和 Antigravity——可以直接在 IDE 里安装并接管项目。后半句既是有意思的地方，也是有风险的地方。只带聊天窗口的代理写代码；能碰模拟器、构建系统和 Logcat 的代理可以自己验证代码能不能跑，而那套循环过去是你的。

笔记本上正在做代码评审的 IDE 界面

一、这次真正发布的是什么

Rabbit 2 包含 Bring Your Own Agent、新的 XR 模拟器特性、LeakCanary 更新、代理 skills 管理器，以及 AI Change Review。机制是这样：打开代理窗口选一个代理，或者进 Settings > Tools > AI > Agents，用你自己的订阅或企业套餐认证，然后开始提问。接上的代理能拿到 IDE 对项目结构与构建的了解、符号解析、Compose Preview 渲染、模拟器和 Logcat，还能加载 Android skills 来处理多步 Android 任务。skills 的入口在代理面板三点菜单的 Manage Agent Skills、聊天框里输入 @，或 Settings > Tools > AI > Skills Manager。

#!/usr/bin/env bash
# verify-agent-work.sh — run this on every branch an agent produced.
set -euo pipefail
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
echo "== verifying $BRANCH =="

# 1. It compiles in the variant you actually ship
./gradlew :app:assembleDebug --offline=false

# 2. Unit tests still pass (agents love editing production code only)
./gradlew :app:testDebugUnitTest

# 3. Android Lint has no new errors
./gradlew :app:lintDebug

# 4. Nothing was added that nobody reviewed
git diff --numstat "$(git merge-base HEAD origin/main)" | sort -k1 -nr

# 5. No debug leftovers
git diff "$(git merge-base HEAD origin/main)" | grep -nE '\+.*(Log\.d|println|printStackTrace)' && {
  echo "debug output found in diff"; exit 1; } || true

二、重点是协议，不是代理数量

「四十个代理」听起来像营销，但数量本身不如它意味着什么重要：一个集成点，而不是四十个。IDE 是客户端，每个代理是标准协议另一侧的一个进程。所以一家把企业协议签给某个厂商的团队，和一家全押在另一家身上的团队，可以用同一套工具、同一套评审流程。它也意味着关键决策从厂商决策变成了策略决策：允许哪些代理、它们能碰什么、合并需要满足什么。而策略恰恰是多数团队没写下来的那部分。

#!/usr/bin/env bash
# capture-context.sh — give the agent evidence, but bound the firehose.
set -euo pipefail

DEVICE="${1:-emulator-5554}"
OUT="agent-context/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"

# Last 400 lines only; full buffers are 10 MB and useless in a prompt
adb -s "$DEVICE" logcat -d -t 400 > "$OUT/logcat.txt"

# Quiet assertions the agent can act on
adb -s "$DEVICE" shell dumpsys meminfo > "$OUT/meminfo.txt"
adb -s "$DEVICE" shell dumpsys gfxinfo com.example.app > "$OUT/gfxinfo.txt"

# Record the exact build under test so a regression has a name
git rev-parse HEAD > "$OUT/git-sha.txt"
echo "context written to $OUT"

三、给代理项目上下文，别给它一本运行手册

让托管代理在 Android 仓库里变废的最快方式，是让它每个会话都重新猜一遍你们的约定。把约定放进它读的文件里，写短，并且明确写出「不要做什么」。我们那份覆盖：构建（只用 wrapper，不写内联版本号）、模块边界、只用 Compose、测试同提交、以及一张必须找人确认的清单：schema 迁移、权限变更、minSdk 提升、签名配置、CI。最后这张清单比其余都重要，因为它是「代理加速」和「代理悄悄扩大攻击面」之间的分界线。

# AGENTS.md — point every ACP agent at the same rules

## Build
- JDK 21, Gradle wrapper only. Never edit `gradle-wrapper.properties`.
- Always run with `--offline` first; if it fails, say so, do not "fix" by adding deps.

## Modules
- `:app` shell only. Feature code goes to `:feature:*`; shared code to `:core:*`.
- New dependency requires an entry in `gradle/libs.versions.toml`. No inline versions.

## UI
- Jetpack Compose only. Do not add XML layouts for new screens.
- Previews are required for new composables; give them sample data, not mocks.

## Tests
- Any behaviour change needs a test in the same commit.
- Robolectric for logic, instrumented tests only for device APIs.

## Stop and ask
- Schema migrations, permission changes, `minSdk` bumps, signing config, CI YAML.

四、评审成了新瓶颈，Change Review 也知道

Google 自己的说法很能说明问题：当代理写代码越来越快，评审与验证成了瓶颈。AI Change Review 从三个入口工作——代理改动、待提交改动、Git 日志——先产出 Recommended Fixes，再生成一个按主题分组的引导式走查，而不是逼你按文件名字母序读。这是个不错的默认值，但它仍然是一个 LLM 在总结另一个 LLM 的工作。走查告诉你该读什么，不告诉你代理碰了它不该碰的东西。后面那几个脚本就是干这个的。

# diff-triage.py — rank an agent's changed files by risk before you read them
import subprocess, sys

BASE = subprocess.check_output(
    ["git", "merge-base", "HEAD", "origin/main"], text=True).strip()
numstat = subprocess.check_output(
    ["git", "diff", "--numstat", BASE, "--"], text=True).strip().splitlines()

RISK = [
    ("app/src/main/AndroidManifest.xml", 9, "permissions / exported components"),
    ("build.gradle", 6, "build config"),
    ("gradle/libs.versions.toml", 6, "dependency versions"),
    ("/res/xml/", 5, "network & backup rules"),
    ("/src/main/res/", 2, "resources"),
    ("/src/test/", 1, "tests"),
    ("/src/main/", 3, "production code"),
]

rows = []
for line in numstat:
    added, removed, path = line.split("\t")
    score = next((w for frag, w, _ in RISK if frag in path), 3)
    churn = (int(added) if added.isdigit() else 0) + (int(removed) if removed.isdigit() else 0)
    rows.append((score * 10 + min(churn // 20, 9), path, churn))

for s, path, churn in sorted(rows, reverse=True)[:15]:
    print(f"{s:3d}  {churn:5d} lines  {path}")
print("\nRead the top five before approving anything.", file=sys.stderr)

五、代理能看见什么，你就必须圈住什么

一旦代理能驱动模拟器、读 Logcat，你的设备数据就进了它的上下文。我们靠两条规则保持可控。第一，代理只能用模拟器或专用测试机，绝不能用登了账号的手机，更不能用能签正式包的 keystore。第二，绝不把无界日志丢给代理：400 行加时间戳、一个 git SHA、外加被测的确切构建，比 10MB 的倾倒有用得多，token 成本只是一个零头。下面的抓取脚本会把这个包写到磁盘，方便以后由人复现回归。

# Makefile — one target the whole team can shout at an agent
.PHONY: agent-check
agent-check:
	@./scripts/verify-agent-work.sh
	@git diff --check
	@echo "--- changed files ---"
	@python3 scripts/diff-triage.py
	@echo
	@echo "Approval requires: build green, unit tests green, no new lint errors,"
	@echo "no new dependency without a catalogue entry, and a manual read of the top five files."

# Rules that keep the IDE honest:
# - agents get a device, not a signed production keystore
# - agents get a branch, never main
# - no agent output is merged on a green pipeline alone

六、第一周可以这样过

第一天：装一个代理，接到废弃分支上，让它做一件你已经知道答案的事——一个 Compose Preview、一个 Robolectric 测试、或在 Profiler 里修一个 LeakCanary 报的内存泄漏。第二天：写 AGENTS.md 的边界清单，加上那三条禁则。第三天：把 verify-agent-work.sh 挂到 make 目标后面，并设为必需检查。第四天：用 diff-triage.py 跑代理的改动，把你的判断和走查结果对照。到周五你会知道两件演示永远不会告诉你的事：代理的产出能不能过你的 CI，以及你这一周有多少时间花在评审上。第二个数字才是要盯的，因为它决定这件事值不值得开。