Devin and OpenInspect: 向后台代理和自主编程的转变
Devin and OpenInspect: 向后台代理和自主编程的转变
向后台代理的转变
AI 编程正在从 IDE 中的“手把手教导”转向“后台代理”——即能够自主驱动开发流程的云端系统。2025 年 12 月左右发生了一个关键的模型拐点（伴随着 Opus 4.5 和 GPT 5.2 等模型），使得“从规格说明到拉取请求”的实用工作流成为可能，代理可以以极低的摩擦从规格说明转向完成的 PR。
在 Cognition，这种转变导致合并的 PR 数量增长了 7 倍，并且 Devin 贡献的提交百分比从 1 月份的 16% 跃升至 3 月份的 80%。
后台代理架构
构建生产级后台代理需要为代理的执行环境在两种主要的架构模式之间做出选择：
Harness In-the-Box vs. Out-of-the-Box
- Harness In-the-Box: 代理直接在沙箱内运行。虽然管理状态更简单，但它带来了安全风险，因为密钥必须放置在盒子内，增加了被不可预测的 AI 意外泄露的风险。
- Harness Out-of-the-Box: “大脑”（代理的逻辑和控制平面）在外部运行，而沙箱充当“双手”（执行环境）。这是一种更复杂但更安全的架构，因为它将高权限密钥与代理操作的机器分离。
基础设施和沙箱要求
- Full VMs vs. Docker: 虽然 Docker 对基础设施很有用，但对于代理运行真实应用程序、执行嵌套虚拟化（例如，运行 Android 模拟器）并提供真正的安全边界，通常需要完整的 VM。
- Repo Setup: 代理部署中最难的问题之一是“仓库设置”——确保代理拥有正确的依赖项、凭据和环境来自主运行和测试代码。
- Fast Restore: 为了避免漫长的启动时间，Cognition 开发了一种块差异（block-diff）文件存储格式，通过仅处理文件系统的差异而非整个磁盘，使 VM 可以快速启动和关闭。
测试挑战
测试是一个独特的解决问题挑战，它超出了简单的“计算机使用”（在屏幕上点击坐标的能力）。有效的自主测试需要代理：
- 通过正确的代码版本来编排前端和后端应用程序的方式进行推理。
- 触发特定功能，这可能需要管理员权限或特定的功能标志（feature flags）。
- 使用截图和视频录制来验证结果，从而为人类审核员提供一个“我知道它有效”的合并时刻。
记忆与知识管理
记忆仍然是一个在很大程度上尚未解决的检索问题。目前的方法包括：
- Auto-generated Memories: Devin 使用一种系统，它向用户建议记忆（例如，“你想让我记住 Cole 喜欢 draft PRs 吗？”），然后由用户批准或拒绝。
- Memory Pruning and Editing: 系统正在不断进化，允许代理在偏好发生变化时编辑现有记忆。
- File-System Based Memory: 目前有一种趋势是将记忆视为文件系统（例如，一个
memory.md文件），代理可以自主地对其进行导航和维护。
“Vibe Coding” 的风险与代码库衰退
不受控制的“Vibe Coding”（即在没有严格审查的情况下自动合并 AI 代码）会导致代码库衰退。实验表明，一个代码库可以以此种方式维持大约两周，然后由于重复和不一致的模式而变得无法管理。
关键风险：
- Regression to the Worst Engineer: 如果工程师使用 AI 而不审计代码，AI 会学习这些糟糕的模式并进行复制，从而呈指数级增加“slop”（垃圾代码）。
- AI Code Smells: 常见的 AI 生成模式包括在 Python 中过度使用
getattr（为了避免崩溃而进行的奖励黑客行为）以及为了避免修改模块名称而进行的不必要的向后兼容性导入。
后台代理的生产级用例
除了标准的特性开发，后台代理正被部署用于：
SRE Auto-Triage: 代理作为警报（来自 Sentry, DataDog 等）的第一响应者，从日志和数据库中收集上下文，并提出一个修复问题的 PR 来在人类介入之前解决问题。
Non-Engineer Contributions: 产品经理 (PMs) 或营销团队通过 Slack 提示直接发布快速的错误修复或更改。
Customer Support: 代理分析带有完整代码库上下文的客户报告的错误，以提供即时的技术回答或进行工程分流。
Security Scanning: 持续的自主安全审查。 }