AI代理是否重新引入了软件工程已解决的问题?
摘要
本文探讨了AI代理工作流如何重新引入软件工程在可重复性、可审计性和状态管理方面的挑战,这些挑战此前已通过版本控制、CI/CD和静态代码实践得以解决,同时提到了GitHub的Agentic Workflows和git原生方法等新兴解决方案。
最近在处理代理工作流时,我开始感觉我们只是在重新引入软件工程已经花了多年解决的一系列问题。一旦代理越过"Hello World"阶段,它的行为就取决于提示词、工具权限、记忆、检索设置以及当前可用的模型端点。这些状态大部分是运行时驱动的,或隐藏在框架抽象中。与我们大多数人习惯的静态代码工作流相比,要可靠地审查、重现或审计它变得困难得多。我们花了数十年围绕版本控制、CI/CD、PR审查、回滚能力和环境分离构建了成熟的工作流,这样你就能确切知道生产环境中运行的是哪个二进制文件,以及自上次事故以来发生了什么变化。对于代理来说,许多行为似乎仍然是在运行时动态组装,而不是作为适当版本化的工件处理。团队在实际生产环境中是如何处理这个问题的?人们是否正转向声明式、基于git的定义来管理代理工作流,还是生态系统仍然过于碎片化和框架特定,无法干净地实现?GitHub Next发布了Agentic Workflows,gitagent也存在,Claude Code已经重度依赖git原生工作流。这个方向显然已获得推动力,即使生态系统尚未收敛。
相似文章
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。
我们把AI当作魔术而不是软件对待,这让AI智能体变得难以维护。
文章认为,当前的AI智能体框架将智能体视为黑箱,导致其难以维护,并提出了一种基于Git的原生架构(Lyzr GitAgent、OpenGAP),在该架构中,智能体逻辑以平面文件的形式进行版本控制,并通过拉取请求实现回滚和可审计性。
AI代理重现了“rockstar developer”问题,只是速度更快
该文章将AI代理与“rockstar developers”进行对比,他们编写巧妙但难以维护的代码,指出AI代理缺乏对自己行为的记忆。它建议使用可见的约定,如AGENTS.md、ADRs和测试,以使AI代理生成的代码对团队来说易于理解。
AI 智能体开始暴露出大多数工作流程原本就已支离破碎的事实
文章认为,AI 智能体揭示了企业工作流程实际上是多么缺乏结构和混乱不堪,暗示成功的自动化更多取决于整洁的系统和完善文档,而非先进的模型。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述,构建AI智能体时的许多挑战实际上源于工作流和状态管理问题,而非模型智能,强调了稳健的状态处理和可观测性的必要性。