AI助手等你提问。人工智能代理被赋予一个目标并采取行动，直到实现它，或者直到它在尝试中陷入困境。
这种差异是当今人工智能发展中最重要的前沿。编码代理不建议片段：他们接受任务，打开存储库，更改文件，运行测试，读取失败的内容，修复它并打开拉取请求以供审查。
对于那些领导者来说，问题不在于这种能力是否存在。它存在并且有效。问题是如何在不以生产力换取混乱的情况下采用它。
实践中什么是编码代理
代理在循环中工作。他收到一个目标，计划步骤，执行行动，观察结果并决定下一步。重复此操作，直到完成或放弃。
代理人与助理的区别在于行动的自主权。他不只是编写代码：他运行命令，读取终端输出，意识到测试被破坏并重试。您不会陷入每次迭代的中间。
这允许您委派整个任务。 “将此服务迁移到新的库版本并确保测试通过”不再是您手动执行的脚本，而是由代理完成的请求，您可以查看最终结果。
它很强大。而正是因为它强大，所以才需要规则。
代理执行的地方
代理擅长于定义明确、可验证且乏味的任务。准备的定义越清晰，结果就越好。
他们为现有代码编写测试是有回报的，因为标准是客观的：测试通过与否，覆盖与否。它们会导致在数十个文件中重复进行机械重构，这种变化会让人类感到疲倦并导致他们缺乏注意力。它们会导致依赖项迁移、语法更新以及构建中出现的错误的更正。
他们还从探索未知基地中受益。要求客服人员详细说明功能的工作原理或业务规则的实施位置，可以节省数小时的阅读时间。维护阶段始终是持久系统中最昂贵的阶段，也是我认为回报最大且风险最小的阶段。
共同点很简单：具有可验证的成功标准的任务。如果测试表明“有效”，那么代理就会提供指导。
代理执行的任务的另一个特点是快速反馈。当代理运行命令并在几秒钟内看到结果时，它会自行迭代并更正它。当成功信号缓慢、模糊或仅出现在生产中时，循环就会中断，代理就会继续旋转。这就是为什么值得做好准备：一个具有良好测试和快速构建的基地比没有安全网的基地能从代理那里获取更多的价值，而在没有安全网的情况下，每个错误只会晚点出现。
代理失败的地方
如果成功标准不明确或不存在，他们就会失败。取决于业务环境的架构决策、产品选择、权衡：所有这些都没有经过测试来表明其是否正确，并且代理会产生一些看似合理的结果，但可能对您的情况完全错误。
他们在需要理解原因而不仅仅是如何做的任务上失败了。代理重构一个函数以使其看起来更干净，并在此过程中删除因未在任何地方写入的原因而存在的边缘句柄。
他们默默地失败，这是最危险的风险。代码恢复工作，测试通过，拉取请求看起来完美无缺，而逻辑则存在微妙的缺陷。人工智能会自信地犯错误，而自信会污染那些匆忙复习的人。
当你过于信任时，他们就会大规模失败。每天打开 10 个拉取请求的代理会生成 10 条质量可疑的评论，而人类仍然只有一条。如果没有治理，瓶颈就会转移到精疲力竭的审阅者身上。
值得谨慎的数据
支持这一立场的数字值得重复。在 2025 年 Stack Overflow 调查中，超过 49,000 名受访者对人工智能工具准确性的不信任超过了信任，只有极少数人（3%）强烈信任它们。
开发人员本身的这种怀疑并不是对变革的抵制。这是那些使用该工具并看到它的缺陷的人的经验。采用代理的领导者需要根据这一现实而不是反对它来设计流程。
少信任多检查并不是缺乏野心。这是充分利用代理商提供的服务的唯一负责任的方式。
如何采用治理
这里的治理不是官僚主义，而是一套让您安全使用代理的规则。首先定义什么可以委派，什么不能委派。
委托可验证和可逆。具有明确测试、独立更改的任务以及拉取请求可以包含和反转的工作。不要在没有专人负责的情况下委派不可逆转的关键事情：从数据库迁移到生产、安全配置更改、影响客户数据的更改。
使代理保持在技术限制范围内。环境隔离，权限受限，无法直接访问生产，无法单独部署。代理人建议，由人类决定播出什么内容。关于如何组织这个的细节，我写了关于[企业环境中的人工智能代理0和[在企业中采用这些工具时的治理1]的文章。
将每个代理拉取请求视为团队新成员的拉取请求：强制审查，无一例外，特别注意逻辑而不仅仅是语法。并衡量结果。如果缺陷率上升或者基础变得更加难以维护，那么代理就没有帮助，即使它看起来很有成效。
人类作为负责任的审阅者
责任不可委托。当代码投入生产时，做出响应的人是批准该代码的人，而不是生成该代码的工具。
这重新定位了工程师。价值不再在于写每一行，而在于很好地定义任务、很好地判断结果并做出决定。这是一个更高级的角色，而不是更少，它需要更多的判断力，而不是更少。
负责的审阅者是对代码的理解达到不同意的程度的人。谁会注意到被抹去的边缘、错误的假设、危险的捷径。委托给代理但保留强大审阅者的团队可以在不失去控制的情况下提高速度。一个委派和放松审查的团队只是将其错误外包。
如果您要引入代理，请从小规模和可验证的方面开始：选择一个具有明确测试的任务，让代理运行它，然后像新员工的工作一样对其进行审查。您可以在升级之前建立治理，而不是在第一次事件发生之后。
来源：[Stack Overflow 调查 20252.
另请阅读
- [软件开发流程中的人工智能：从生成片段到编排3
- [什么是带有 AI 的 SDLC：软件周期反思4
- [生成式 UI 需要更多的治理，而不是更少55
- [信任人工智能生成的代码：每个技术领导者需要面对的悖论6
- [训练人工智能的合成数据：实际收益和模型崩溃的风险7
- [SDLC各个阶段的人工智能：技术领导者的分阶段指南8