AI 编码代理已经不是"试试看"的阶段了——它们正在重塑 Python 开发者写代码、改代码、审代码的方式。但市面上的代理形态差异极大：有的嵌在你的编辑器里，有的在命令行跑，有的挂在 PR 上自动审查，还有的在云端整仓操作。选错类型，不仅效率上不去，反而会引入混乱。这篇文章把四种工作流拆开讲清楚，帮你判断哪种适合当下的项目节奏。
IDE 代理：边写边改，最直觉的协作方式
IDE 代理（Cursor、GitHub Copilot、Windsurf 等）直接嵌入 VS Code 或 JetBrains，你在编辑器里写代码，它在旁边补全、重构、解释。核心特征是实时、局部、人主导——代理只在你光标所在的位置附近行动，不会擅自跨文件大改。
典型场景：你在写一个 FastAPI 路由，写到一半卡住了，直接在聊天框里描述需求，代理生成补全代码，你 review 后采纳。
# 你只写了函数签名和 docstring，IDE 代理补全了实现
from fastapi import APIRouter, HTTPException
from pydantic import BaseModel
router = APIRouter()
class ItemCreate(BaseModel):
name: str
price: float
description: str | None = None
@router.post("/items/", response_model=dict)
async def create_item(item: ItemCreate):
"""创建新商品，返回包含 id 的字典。"""
# --- 以下由 IDE 代理生成，你确认后保留 ---
item_id = await db.items.insert_one(item.model_dump())
if not item_id:
raise HTTPException(status_code=500, detail="插入失败")
return {"id": str(item_id), **item.model_dump()}
适合谁：日常开发中需要高频局部修改的人——写新功能、修小 bug、补测试。IDE 代理不会替你做架构决策，但能显著减少"写重复代码"的疲劳感。
边界：它只看当前打开的文件和项目索引，对跨模块的连锁影响感知有限。你让它改一个 model 字段，它未必会同步更新所有引用该字段的序列化逻辑。
终端代理：命令行里的全仓手术刀
终端代理（Aider、OpenHands CLI 等）在 shell 里运行，你用自然语言下达指令，它直接读写本地文件、运行测试、查看 git diff。核心特征是全仓可见、操作透明、可回滚——每次改动都落在 git 里，你可以 git diff 审查，不满意就 git reset。
典型场景：你有一个遗留 Python 项目，需要把所有 print 日志替换成 structlog，还要保证测试不挂。一条指令下去，终端代理扫全仓、逐文件修改、跑测试、报告结果。
# 安装 aider 并让它执行一个跨文件重构任务
pip install aider-chat
# 在项目根目录启动，指定要操作的文件
aider app/models.py app/routes.py app/utils.py \
--message "把所有 print() 调用替换为 structlog 的 logger.info()，保留原始消息文本，确保不破坏现有测试"
# 审查改动
git diff HEAD
# 如果不满意，一键回滚
git reset --hard HEAD
适合谁：需要跨多文件批量重构、补测试、修 lint 的人。终端代理的 git 集成让它在"大动作"场景下比 IDE 代理更可控——你永远有回退路径。
边界：它依赖你提供正确的文件列表和清晰的指令。模糊的指令（"优化代码"）会产生大量无关改动。另外，它对运行环境有要求——项目必须能在本地跑起来，否则代理无法验证自己的改动。
PR 代理：代码审查的自动化搭档
PR 代理（CodeRabbit、GitHub Copilot for PRs 等）挂在代码仓库的 PR 流程上，每次提交 PR 时自动审查、留评论、建议修改。核心特征是异步、团队级、聚焦差异——它只看 diff，不替你写新代码，但能捕捉你遗漏的问题。
典型场景：团队成员提交了一个 200 行的 PR，PR 代理逐行审查，指出缺少类型标注、有潜在竞态条件、建议用 asyncio.Lock 保护共享状态。
下面是一个 GitHub Actions 配置，让 PR 代理在每次 pull request 时自动介入：
# .github/workflows/pr-review.yml
name: AI PR Review
on:
pull_request:
types: [opened, synchronize]
jobs:
ai-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 需要完整历史才能理解 diff 上下文
- name: Run CodeRabbit AI Review
uses: coderabbitai/ai-pr-review@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
# 只审查 Python 文件的变更
path_filters: "*.py"
# 审查维度：安全、性能、类型安全、测试覆盖
review_profile: "strict"
适合谁：团队协作中需要快速、一致的代码审查的人。PR 代理不会替代人类 reviewer，但能先筛一遍明显问题，让人类 reviewer 把精力放在架构和业务逻辑上。
边界：它只看 diff，对 PR 之外的上下文（比如项目整体架构约定）了解有限。如果 PR 很大（超过 500 行变更），审查质量会下降——信息密度太高，代理容易遗漏关键问题。
云端代理：远程沙箱里的独立开发者
云端代理（Devin、Factory、Sweep 等）在远程沙箱环境里运行，你给它一个任务描述，它自己拉代码、建分支、写代码、跑测试、提交 PR，全程不需要你盯着。核心特征是自治、隔离、异步交付——你分配任务后去做别的事，完成后收到一个 PR 供你审查。
典型场景：你用 Factory 给一个 Django 项目分配任务："给 User model 加软删除字段 is_active，更新所有查询默认过滤 is_active=True，补迁移文件和测试"。几分钟后你收到一个 PR，包含 model 改动、迁移、测试更新，CI 也通过了。
# 用 Factory SDK 提交一个云端代理任务（伪代码，展示调用模式）
from factory_sdk import FactoryClient
client = FactoryClient(api_key="your-api-key")
task = client.create_task(
repo="https://github.com/your-org/django-app",
branch="feature/soft-delete",
description=(
"给 User model 加 is_active boolean 字段（默认 True）。"
"更新所有 UserManager 查询方法，默认过滤 is_active=True。"
"生成 Django migration 文件。"
"在 tests/test_user.py 补充软删除相关测试。"
"确保现有测试全部通过。"
),
# 指定 Python 版本和依赖安装方式
setup_commands=["pip install -r requirements.txt"],
test_commands=["python -m pytest tests/ -x"],
)
# 任务完成后会自动创建 PR，你可以稍后审查
print(f"任务已提交，ID: {task.id}")
print(f"完成后 PR 链接: {task.pr_url}")
注意：Factory SDK 的具体接口以官方文档为准，上面的调用模式是典型用法，实际参数名可能不同。
适合谁：有明确边界的小任务——补功能、修 bug、加测试。云端代理最强的一点是你不需要停下手里的事，任务在后台跑，你只审查最终 PR。
边界：自治意味着失控风险。任务描述不够精确时，代理可能走偏——改了不该改的文件、引入了风格不一致的代码。沙箱环境也可能和你本地环境有差异（依赖版本、环境变量），导致代理本地跑通了但 CI 挂了。永远审查云端代理的 PR，不要直接 merge。
四种代理的选用清单
| 维度 | IDE | 终端 | PR | 云端 |
|---|---|---|---|---|
| 操作范围 | 当前文件 | 全仓（你指定） | PR diff | 全仓（自治） |
| 介入时机 | 实时 | 实时 | PR 提交后 | 异步 |
| 人控程度 | 高 | 高 | 中 | 低 |
| 回滚难度 | 低（手动 undo） | 低（git reset） | 低（忽略评论） | 低（关闭 PR） |
| 适合任务 | 局部补全/重构 | 跨文件批量操作 | 代码审查 | 独立小任务 |
实践建议：
- 起步选 IDE 代理——学习曲线最低，风险最小，先习惯"人机协作"的节奏。
- 重构选终端代理——跨文件改动必须有 git 保障，终端代理天然满足。
- 团队必上 PR 代理——哪怕只用免费额度，自动审查能筛掉 30%-50% 的低级问题。
- 云端代理慎用——只给边界清晰、验证手段明确的小任务，且必须逐 PR 审查。
- 不要让任何代理触碰生产配置和密钥——代理能读到的内容就是它能泄露的内容，敏感文件用
.gitignore和环境隔离保护。
四种代理不是互斥的。一个健康的 Python 项目可以同时用 IDE 代理写代码、终端代理做重构、PR 代理做审查、云端代理处理积压的小任务。关键是每个代理放在它最擅长的环节，而不是指望一个代理解决所有问题。