快速浏览软件工程中的代理/生成式AI

代理方法现在很热门，因为单个 LLM 模型似乎仅限于点工具应用。每个这样的应用程序都令人印象深刻，但仍然是我们想要自动化的更复杂的推理任务链中的一个步骤，代理方法应该在其中大放异彩。我一直听说软件工程 （SWE） 团队在 AI 采用方面比硬件团队进步得更快，因此认为对状态进行快速现实检查会很有用。本着这个想法的精神，我使用 Gemini Deep Research 来寻找本文的来源，有选择地抽样它提供的一些调查，同时添加一些我自己的发现。我的快速总结是，首先，什么算作进步取决于应用：基于便利性的使用模型在今天更容易实现，精确的使用模型也是可能的，但更有限。其次，在自动化子任务方面，进步更为明显，这些子任务受制于交叉检查和人工监控的自然框架，而不是免提的全面 SWE 目标。

自动化带来便利

一篇有趣的论文建议，我们应该从出于方便需求的应用程序转向基于提示的查询，以服务于相同的目标。原则上，这种方法比应用程序做得更好，因为基于提示的系统消除了应用程序开发的需要，可以通过我们都使用的语言进行控制，而不需要神秘的人机界面，并且可以更容易地适应需求的变化。

有效的提示工程可能仍然比我们希望的更像一门艺术，但作者建议我们可以学习如何变得更有效，并且（我的解释）也许我们只需要学习一次这项技能，而不是为每个独特的应用程序学习。

即使是技术工程师也需要这种支持，不是在深度开发或分析中，而是在常规但重要的问题上：“还有谁在使用这个功能，最近使用它是什么时候，其他人看到了什么问题？传统上，这些问题可能可以通过帮助库或内部数据管理应用程序来回答，但是如果您想将问题与该应用程序范围之外的其他来源或约束交叉怎么办？在硬件开发中，想象一下，如果您可以对所有设计数据（规范、用例、源代码、日志、波形、修订等）进行基于提示的搜索，那么发现能力会有多大。

自动化精密开发

本文描述了一个代理系统，用于开发相当复杂的功能，包括人脸识别系统、聊天机器人系统、口罩检测工具、蛇游戏、计算器和井字游戏，使用基于LLM的代理系统进行管理、代码生成、优化、QA、迭代细化和最终验证。它声称与标准基准相比代码准确率为 85% 或更高，可在几分钟内构建和测试这些系统。在 85% 的准确率下，我们仍然必须遵循初始代码，开发人员努力验证和纠正生产质量。但假设这种准确性水平是可重复的，那么不难相信，即使经过几周或几个月的开发人员测试和改进，在不损失质量的情况下生产力的净收益也可以是相当可观的。

另一篇论文指出，在 SWE 中，自动开发的代码仍然存在信任问题。然而，他们补充说，大多数大规模软件开发更多的是从多个来源组装代码，而不是从头开始开发代码。这将信任问题变成了您可以信任多少组件和组件。我猜他们认为 DevOps 中的组装相对微不足道，但在硬件设计中，SoC 级组装（甚至多芯片系统组装）更复杂，尽管仍然主要是机械的而不是创造性的。出错的范围肯定比从头开始创建一个全新的函数要有限。我知道十多年前有一个基于人工智能的系统，它可以为 SoC 创建大部分集成基础设施——时钟、复位、中断、总线结构等。这早在我们听说法学硕士和代理之前。

同时，代理/生成式人工智能不仅对代码开发有用。工具似乎可以自动化测试设计、生成和执行、调试以及更普遍的 DevOps。其中许多系统实际上相互交叉检查，并辅以人工监督。错误可能会发生，但可能不会比在无人工智能系统中更严重。

方便、精确还是两者兼而有之？

工程师痴迷于精度，尤其是在人工智能方面。但我们一天中所做的大部分事情都不需要精确。如果我们能快速得到“足够好”的答案，它们就可以了。搜索、总结电子邮件或论文中的要点、生成文档初稿，这些都是我们依赖（或希望）快速且“足够好”的首次通过的便利性的领域。另一方面，在某些情况下，精度至关重要。对于金融交易、喷气发动机建模、逻辑仿真，我们希望得到最准确的答案，而“足够好”是不够好的。

即便如此，精密应用仍然具有优势。如果人工智能能够非常快（几分钟）提供一个足够好的起点，并且如果我们能够通过接受超越该起点的改进和验证的需求来管理我们的期望，那么缩短时间表和减少工作量的净收益可能是值得投资的。只要您能对人工智能系统可以提供的质量建立信任。

顺便说一句，我自己的经验（我在 Gemini、Perplexity 和 Chat GPT 中尝试了深度研究 （DR） 选项）支持了我的结论。每个 DR 分析在 ~10 分钟内出现，对我来说主要是他们提供的参考资料而不是 DR 摘要。其中一些参考资料对我来说是新的，有些我已经知道了。如果我的研究纯粹是为了我自己的兴趣，这可能就足够了。但我想更准确，因为我的目标是提供可靠的见解，所以我也通过更传统的在线图书馆寻找其他参考资料。事实证明，结合这两种方法是富有成效的！