
GitHub正在准备一项新功能,用于自动化DevOps中最昂贵的工作:那些没人愿意承担的隐形维护工作。开发者更愿意构建功能特性,而不是调试不稳定的持续集成(CI)管道、分类低质量问题、更新过时文档或填补测试覆盖率的持续缺口。
为了帮助开发者和企业管理维护代码库的运营阻力,GitHub正在预览智能体工作流,这是一项使用AI自动化与代码库维护相关的大多数日常任务的新功能。
不过,这项功能不会完全解决维护问题。
开发者仍然需要用自然语言描述智能体可以遵循的自动化工作流,将指令存储为代码库中的Markdown文件,这些文件可以通过终端使用GitHub CLI创建,或在Visual Studio Code等编辑器中创建。
然后,他们需要连接想要智能体使用的大语言模型和编程工具——可选项包括GitHub Copilot、Claude或OpenAI Codex——并设置防护栏,定义智能体被允许读取的内容、可以提出的建议,以及哪些事件(问题、拉取请求、计划运行)应该触发它。
一旦提交,工作流就像其他任何自动化一样在GitHub Actions上执行,智能体的决策和建议的更改会以问题评论、拉取请求和CI日志的形式出现,供开发者审查。
GitHub高管在关于GitHub智能体工作流的博客文章中写道,这些自动化工作流应该减少开发者围绕维护工作的认知负担。
分析师也看到了开发者和工程主管的立即生产力收益,特别是在减少构建停滞、加快根因分析和保持更干净代码库方面,这些都能在相同人员配置下悄然提高交付速度。
The Futurum Group首席信息官实践副总裁Dion Hinchcliffe说:"中等规模的工程团队获得了立即的生产力好处,因为他们在重复性维护工作如分类和文档偏差方面最为困难。"
获得生产力的另一个原因是智能体工作流使用基于意图的Markdown而不是YAML,这使开发者的编写更快,Hinchcliffe补充说。
然而,Broadcom高级站点可靠性工程师Advait Patel警告说,虽然基于意图的Markdown使工作流编写更快,但也可能降低精确度:"YAML很烦人,但它是明确的。自然语言可能被不同的模型或版本不同地解释。"
同样,Hinchcliffe指出,如果这些工作流无人看管或未得到管理,也存在产生过多低价值拉取请求或问题噪音的风险。
Patel还警告说,除了精确度和信噪比担忧外,还有一个团队可能在开始时低估的更现实的风险:随着智能体工作流在代码库中扩展并更频繁地运行,底层计算和模型推理成本可能悄然累积,如果不加以控制,看起来像生产力提升的东西可能变成不断增长的运营开支项目。
Patel补充说,这可能成为工程主管和首席信息官的董事会问题,因为他们必须证明投资回报,特别是在他们正在努力理解让软件智能体在生产工作流中运行真正意味着什么的时候。
此外,Kramer & Company首席分析师Shelly DeMotte Kramer警告说,GitHub的方法也可能加深开发者和首席信息官的平台依赖,有效地推动团队更紧密地锁定在智能体工作流上。
"通过将智能体原生嵌入GitHub Actions而不是从外部添加它们,他们创造了超越工具熟悉度的切换成本。这是并且将是具有挑战性的,并创造了一种锁定情况,因为你无法轻易将基于Markdown的智能体工作流移植到GitLab,因为执行引擎、权限模型和安全输出架构都是GitHub原生的,"Kramer说。
Kramer补充说,这一战略举措反映了GitHub推动对开发者工作流施加更大控制的努力,押注拥有软件开发生命周期自动化层的所有权将塑造软件团队的运作方式,使其相对于竞争对手具有优势。
然而,分析师预期很快会看到GitLab和Atlassian等竞争对手推出类似产品:"有趣的问题是他们是构建原生智能体运行时还是简单地成为第三方智能体可以驱动的MCP兼容界面。"
鉴于MCP刚刚转移到Linux基金会,Kramer补充说,第二条道路可能"实际上比GitHub的专有方法加速更快"。
分析师还看到了安全问题,特别是在受监管行业的背景下,尽管智能体工作流提供了最小权限和沙盒执行等安全功能。
"首先,GitHub描述了网络隔离,但没有指定工作流执行环境是否获得FedRAMP授权,这对美国政府相关工作至关重要,或者审计日志是否满足HIPAA要求的保留和访问控制标准,这对美国医疗保健至关重要,"Kramer说。
Kramer补充说,GitHub也没有指定智能体对代码库内容的访问(包括代码库中嵌入的潜在敏感代码、秘密或客户数据)是否受数据驻留要求的管辖。
"对于金融服务,需要完整的血统层,不仅仅是'这个工作流创建了这个PR',而是智能体进行的每个API调用、读取的每个文件和做出的每个决策的完整记录。这些都是需要解决的问题,"分析师进一步指出。
虽然GitHub让开发者和个人团队决定在智能体工作流中编写什么自动化以及走多远(包括规划自主CI/CD),但分析师建议企业将技术预览视为受控测试窗口,评估新功能是否可以在不破坏治理、安全或成本纪律的情况下被吸收到生产环境中。
"对于首席信息官来说,这是学习阶段:在非关键代码库中建立受控试点,早期开发治理模式,并为可审计性和运营可预测性稳定后的更广泛采用做准备,"Hinchcliffe说。
为了控制成本和量化投资回报,首席信息官可以设定预算上限、分层大语言模型选择,并密切跟踪"运行"频率和AI请求量,然后将这些成本与回收的开发者时间和减少的运营延迟进行基准比较,Hinchcliffe补充说。
分析师表示,对于开发者来说,这可能标志着文化和绩效指标的转变。
"开发者文化将向监督自动化而不是执行日常任务发展。这可能会让开发者转向架构、设计决策和更高价值的问题解决,"Hinchcliffe说。
"团队结构将更加重视平台工程和自动化管理,而绩效指标从活动衡量转向结果,如周期时间、可靠性和每个开发者的工程效率,"分析师补充说。
Q&A
Q1:GitHub智能体工作流是什么?它能解决什么问题?
A:GitHub智能体工作流是一项新功能,使用AI自动化代码库维护的日常任务,如调试CI管道、分类问题、更新文档、填补测试覆盖率缺口等。它能减少开发者在维护工作上的认知负担,让他们专注于构建功能特性。
Q2:使用GitHub智能体工作流需要什么条件?
A:开发者需要用自然语言描述工作流并存储为Markdown文件,连接大语言模型(如GitHub Copilot、Claude或OpenAI Codex),设置权限防护栏,定义智能体可读取的内容、提出的建议和触发事件。
Q3:GitHub智能体工作流有什么风险和挑战?
A:主要风险包括:自然语言可能被不同模型解释不同导致精确度降低;可能产生过多低价值拉取请求;计算和模型推理成本可能累积;存在平台锁定风险;在受监管行业中的安全合规问题需要解决杠杆交易。
京海策略提示:文章来自网络,不代表本站观点。