文章探讨了软件开发中AI编码代理的兴起，并提出了远程代理环境的概念。这种环境通过可扩展性、自动上下文管理、标准化工具和安全性等优势，将AI代理应用于更复杂的企业软件开发。文章还讨论了技术、安全和组织方面的挑战，并介绍了Runbooks作为支持企业规模远程代理环境的基础。
译自：The Rise of Remote Agentic Environments
作者：Ankit Jain
想象一下这样一个场景：一个开发团队将以下任务分配给一个 AI 系统：“将我们的用户身份验证从 JWT 令牌迁移到 OAuth 2.1 with PKCE，同时确保向后兼容。”
这个 AI 系统会启动多个专门的代理，让它们并行工作。一个代理分析代码库，提出澄清问题并制定迁移计划。另一个代理实现 OAuth 处理程序，第三个代理构建兼容性层，第四个代理生成测试套件，第五个代理构建和验证结果。
开发团队（人类）审查进度，批准计划并做出战略决策，而协调代理管理依赖关系并升级冲突，使开发人员能够专注于高层次的指导，而不是实现细节。
我既不是在谈论氛围编程，也不是在谈论所有开发人员都会失业的世界末日。相反，我正在观察软件开发的演变。
编码代理的崛起
软件工程师使用 AI 工具的方式的转变已经到来。每家主要的 AI 编码公司都推出了命令行界面（CLI）编码代理。这些工具通过有限的用户交互，实现了更自主的工作流程。
我们正从开发人员使用 AI 工具，转向 AI 代理为开发人员工作，承担起之前需要手动且耗时的整个类别的工作。
AI 编码代理通常被比作初级开发人员，他们可以在收到明确的指示后完成任务。这对于构建一个很酷的网站或创建一个病毒式的待办事项应用程序来说效果很好。但是，我们不能仅仅依靠初级开发人员来管理混乱、复杂或包含大量业务细微差别和陈旧文档中存在的部落知识的企业软件。
进入远程代理环境
将远程代理环境 视为一种新的范例，在这种范例中，AI 代理在基于云的开发环境（公共云或私有云）中运行，理解自然语言指令，持续学习业务背景，规划复杂的多步骤任务并自主执行它们。
与供开发人员构建和测试的云开发环境类似，这些系统主要供 AI 代理独立工作，提出澄清问题并寻求对重大更改的批准。
这种环境的关键要求包括：
- 访问代码库： 代理可以与 git 交互以获取整个代码库，创建拉取请求，并从拉取请求中获得反馈以重新进行更改。
- 上下文： 也许是最重要的部分。这些系统维护状态和记忆，从过去的行动中学习，并根据项目模式和团队偏好调整未来的行为。
- 构建环境： 代理可以构建、运行和测试代码。大多数代理工具都分多个步骤工作，因此它们能够编译代码、运行测试和验证更改非常重要。这通过添加反馈循环来提高质量。
- 自然语言界面： 开发人员以交互方式与代理合作，确定需求范围和规划任务。
- 使用的工具： 与基于 IDE 的 AI 工具类似，代理可以使用 模型上下文协议（MCP）连接其他工具。与 IDE 不同，这些环境可以限制可以使用哪些 MCP。
远程代理环境的优势
与基于 IDE 的 AI 工具相比，这种框架具有多个优势。
可扩展性
远程代理环境具有独立于人力资源的可扩展性。您可以为每个开发人员分配多个代理环境，或者让多个开发人员使用以下方式共享相同的资源：
- 资源优化： 计算资源的分配基于实际的任务要求，而不是开发人员的可用性。复杂的编译任务、大规模测试和数据密集型操作可以访问高性能资源，而不会影响开发人员的工作站。这些资源可以根据需求进行扩展或缩减。
- 并行执行： 多个独立的任务可以同时执行，由多个团队成员一起或独立协调。
自动上下文管理
远程代理环境不断从代码存储库、审查和过去的更改中提取上下文，构建一个随着代码发展的知识库。
- 利用上下文： 定期捕获来自拉取请求的反馈以改进上下文。
- 缩短入职时间： 集中式上下文使新开发人员更容易上手并理解业务需求。
- 生成实时文档： 后台代理在代码更改时更新注释、文档字符串和文档。
- 跨 AI 工具同步： Git 同步的上下文文件可在本地和远程 AI 环境中工作。
标准化工具
远程代理环境通过提供标准化、完全配置的开发环境来消除“在我机器上可以运行”的问题，使用：
- 预配置环境： 每个必需的构建工具、编译器、测试框架和依赖项都已预先安装和配置。
- 一致的设置： 没有版本不匹配、缺少依赖项或配置漂移，因为每个任务都在具有可预测行为的已知良好环境中执行。
- 专门的环境： 一个 Python 机器学习（ML）项目可以与一个 Node.js 微服务和一个遗留 Java 应用程序一起运行，每个都有其最佳的工具链版本。
- 规范的版本控制： 团队可以跟踪导致代码生成的规范和提示的确切版本，几乎没有猜测的空间。这也可以作为一个很好的纠正手段。
安全和控制
与本地设置相比，这些环境提供更好的安全性，因为您可以使用以下方式控制安装的内容以及这些机器可以访问的内容：
- 入口和出口控制： 在私有云上运行时，您可以轻松控制服务器可以访问哪些 URL，并限制所有入站请求，从而降低社会工程或渗透的风险。
- API 访问控制： 像 Claude Code 这样的 CLI 代理工具包括上下文感知检查，该检查尝试检测恶意指令并主动阻止它们，具有提示注入保护措施并限制或禁用有风险的工具。
- MCP 服务器治理： 组织可以精确控制代理可以访问哪些外部工具和数据源，从而为自主操作创建一个安全沙箱，同时保持合规性要求。
- 审计跟踪： 自主代理采取的每个操作都会被记录下来，为合规性、调试和流程改进提供完整的可追溯性。
代理规划和反馈循环
规划和反馈能力是将远程代理环境与早期自动化尝试区分开来的原因。
任务分析和分解
当收到像“将我们的身份验证系统迁移到 OAuth 2.1”这样的高级请求时，现代代理不会简单地执行预定义的脚本。相反，它们会：
- 分析当前状态： 扫描代码库以了解现有的身份验证实现，识别所有接触点并编目依赖关系。
- 研究最佳实践： 查询文档、最近的安全公告和实现模式，以了解 OAuth 2.1 要求和迁移策略。
- 规划迁移： 创建一个逐步实施计划，以最大程度地降低风险，识别测试要求并计划回滚方案。
- 评估影响： 分析哪些组件将受到影响，估计测试要求并识别潜在的重大更改。
执行计划
规划阶段产生详细的执行策略，人类开发人员在实施之前对其进行审查。这可能包括：
## OAuth 2.1 迁移计划
### 第 1 阶段：基础设施准备（预计：2 小时）
- 设置 OAuth 2.1 提供程序配置
- 更新环境变量和密钥
- 创建向后兼容的端点存根
### 第 2 阶段：核心实施（预计：4 小时）
- 实施新的 OAuth 2.1 流程处理程序
- 更新令牌验证逻辑
- 修改用户会话管理
### 第 3 阶段：集成更新（预计：3 小时）
- 更新前端身份验证调用
- 修改 API 中间件
- 更新移动应用程序身份验证
### 第 4 阶段：测试和验证（预计：2 小时）
- 运行全面的身份验证测试套件
- 针对安全检查表进行验证
- 执行集成测试
### 回滚计划
- 数据库迁移反转脚本
- 配置回滚程序
- 紧急身份验证绕过机制
人工参与的工作流程
- 计划审查和批准： 代理首先提交他们的分析和提出的方法以供人工审查。开发人员可以修改计划，添加约束或请求替代方法。
- 基于检查点的执行： 在关键里程碑处，代理暂停执行并报告进度，允许开发人员在继续下一阶段之前验证正确性。
- 异常处理和升级： 当代理遇到意外情况或模糊的要求时，它们会将问题升级给人类开发人员，并提供有关该问题的上下文和建议的解决方案。
技术、安全和组织挑战
就像本地生成的 AI 代码一样，远程代理环境也存在技术、安全和组织方面的挑战，必须在广泛采用之前加以解决。
技术挑战
- 代码质量和一致性： 虽然代理可以生成功能代码，但这并不能取代人工对更改进行仔细审查和验证的需要。事实上，由于 AI 生成代码，人工审查变得更加关键。
- 调试自主更改： 一些错误可能很容易通过 AI 进行调试，但我们需要更好的日志记录和解释，以便人类可以理解代理的推理过程。
- 集成复杂性： 一个有缺陷的输出可能会给所有下游代理引入错误。如果需求代理误解了某个功能，则开发人员代理可能会编写错误的代码，而测试人员代理可能会完全错过该问题。
安全和治理
无论代码是由人类编写还是由 AI 代理编写，都始终存在安全风险。即使进行了完全自主的更改，人类仍然有责任确保对代码进行仔细审查和验证。此外，组织应制定以下策略：
- 让第二位审查员查看关键任务代码更改。
- 使用自动安全扫描工具。
- 为代理可以访问和修改的内容定义精细的权限。
- 跟踪哪些更改是由哪些代理进行的以及原因。
组织挑战
大型企业中大多数 AI 采用挑战都是组织性的，而不是技术性的。在每个组织中，从真正的信徒到强烈的反对者，都存在着广泛的采用范围。
随着软件开发人员的角色正在从代码编写者演变为 AI 协调者和系统架构师，一些挑战可以通过重建开发人员平台来支持这个新的生态系统、建立对自主系统的信任和信心以及支持工程师学习和适应新的工作方式来解决。
具有 Runbooks 的远程代理环境
为了使远程代理环境能够以企业规模运行，我们需要一个坚实的基础来定义和控制代理执行的操作。这就是我们所说的 Runbooks。团队创建 Runbooks 作为详细的操作指南，以便团队中的每个人，无论其经验或对该事项的熟悉程度如何，都可以轻松理解和协作。
Runbooks 是实时文档，可从存储库和代码审查中捕获上下文，将其与团队的 AI 提示知识和执行模式相结合，并通过每次使用进行改进。它们充当清晰的蓝图，为后台代理生成的工作创建审计跟踪，并为 AI 时代的协作奠定坚实的基础。
