还有人注意到,开发 AI 智能体的人正在忘记软件工程的基本原则吗?
摘要
一位从业者认为,AI 智能体开发者正在重新发现一些基础软件工程早已解决的问题,例如输入验证、数据建模、进程隔离和访问控制,而氛围编程却忽略了这些贯穿各个环节的共性问题。文章呼吁将成熟的设计与架构原则应用于智能体工作流。
最近我读了很多帖子,都是人们在为智能体记忆、提示注入和目标劫持而苦恼。这些确实是问题,我并不是在否认它们。但我反复看到的是,基本的软件工程方法不见了。我们从来不会信任客户端在表单里提交的内容。我们会先设计数据模型,在客户端和服务端都进行验证,并在多个层面防范注入。我们会隔离进程和数据,避免某个服务被攻破后导致所有数据泄露。我们会采用基于角色的访问控制,并使用短期有效的令牌。同样的这些基本做法,大多也能解决人们在使用智能体时遇到的许多问题。就拿记忆来说。如果你不知道自己想存储什么,以及这些内容应该如何影响智能体,就无法为它设计数据结构。于是,只因为“它是个大语言模型”,所有东西就都以自由文本的形式存储,结果自然就出现了注入问题。我觉得,部分原因在于氛围编程。即使你通过氛围编程一次性生成一个全栈应用,AI 大概也能覆盖端到端的流程。但它不会处理深入的数据验证、数据库索引等问题。这些都需要你在上线之前补上。智能体工作流也是一样。通过氛围编程生成的智能体,不会替你处理那些贯穿整个系统的共性问题。你仍然需要懂软件工程、设计原则和架构,才能告诉它你真正想要什么。你们怎么看?
相似文章
AI代理是否让构建软件比理解软件更容易?
一位开发者反思了AI编码代理如何能够快速构建和修改软件,但开发者往往失去对代码库架构和决策的理解,从而带来新的工程挑战。
AI代理是否重新引入了软件工程已解决的问题?
本文探讨了AI代理工作流如何重新引入软件工程在可重复性、可审计性和状态管理方面的挑战,这些挑战此前已通过版本控制、CI/CD和静态代码实践得以解决,同时提到了GitHub的Agentic Workflows和git原生方法等新兴解决方案。
工程纪律
一位开发者讨论了在使用AI编码代理时,代码生成速度超过理解速度,如何保持工程纪律和架构完整性的挑战,并寻求避免创建低质量软件的最佳实践。
@arcane_bloom: 从软件工程到智能体工程的转变:五部分解析 1/6 大多数开发者在构建AI时失败…
一条推文解释了从传统软件工程过渡到智能体工程所需的5个核心思维转变,强调了为什么硬编码路由和二元测试等常规模式在AI智能体中会失效。
为什么大家都觉得AI智能体很容易?🚀
一篇反思性文章,质疑人们轻率地认为构建AI智能体很容易的想法,强调了API、RAG、工具调用、记忆和编排等复杂组件,并指出在需要真正的智能体之前,更简单的工作流往往就够了。