AI Agent开发正在遗忘软件工程基本功？

Reddit上有个帖子引发了不小的共鸣：越来越多做AI Agent的人，正在忘记基本的软件工程原则。作者列举了Agent记忆管理、提示注入、目标劫持这些高频问题，然后一针见血地指出——这些问题的根源，是开发者跳过了几十年软件工程积累下来的那些基本功。

那些被遗忘的软件工程常识

原帖作者回顾了一套经典做法：从不可信的表单输入、先设计数据模型、客户端与服务端双重验证、多层注入防护、进程与数据隔离、基于角色的访问控制加短期令牌。这些做法在传统Web开发中属于肌肉记忆，但到了Agent开发场景，似乎被集体遗忘了。

这个观察值得重视。Agent本质上是一个接受自然语言输入、调用外部工具、维护状态、输出结果的系统。它的攻击面不比一个Web应用小，甚至更大——因为LLM的输出天然不可预测，工具调用的副作用可能直接作用于真实世界。但很多人对待Agent的安全态度，却像是回到了Web 1.0时代。

提示注入是指攻击者在Agent可以读取的输入中（用户消息、网页内容、工具返回值、记忆条目等）嵌入伪装的指令，诱使LLM偏离原本任务、执行攻击者意图的操作。它与传统SQL注入的区别在于：SQL注入攻击的是解析器，有明确的语法边界可以防御；而提示注入攻击的是模型对自然语言的理解本身，指令与数据共存于同一token序列中，目前没有可靠的通用解法。目标劫持是提示注入的一种具体表现，攻击者通过注入内容覆盖Agent的原始目标，使其转而执行其他任务，例如把「帮我总结这封邮件」变成「把这封邮件转发给某地址」。防御思路通常包括：对不可信来源的内容做显式标记与隔离、限制工具调用的权限范围、在关键动作前引入人工确认或独立校验层。

记忆系统的设计缺失

作者对Agent记忆问题的分析尤为精彩。他指出：如果你不清楚要存什么、这些信息应该如何影响Agent行为，你就无法为它设计数据结构。结果就是所有东西都被当作自由文本塞进去，理由是"反正它是LLM"。

这个逻辑链条指向一个关键问题：Agent的记忆系统本质上是一个数据建模问题，而不是一个Prompt工程问题。传统应用中，我们会根据查询模式设计表结构、建立索引、定义关系。但Agent的"记忆"经常被简化为一个向量数据库加一段拼接的上下文窗口。缺乏结构意味着无法有效验证、无法精确检索、也无法控制信息如何回流到推理过程中。注入攻击之所以在Agent场景中特别猖獗，很大程度上是因为记忆层没有做输入净化和来源标记。

向量数据库通过嵌入模型把文本映射为高维向量，再基于余弦相似度等度量做近似最近邻检索，适合处理语义相近但字面不同的查询。但它的局限也很明显：无法表达结构化关系（如「这条记忆由哪个用户、在哪个会话、什么时间产生」），无法做精确过滤和事务性更新，相似度阈值也缺乏可解释性。相比之下，传统关系型数据库支持外键、唯一约束、索引和事务，可以精确控制写入与读取。Agent记忆系统更合理的做法往往是混合架构：结构化元数据（来源、时间、权限、类型）存在关系库中，语义内容用向量索引辅助检索召回，再通过规则过滤决定什么信息可以回流到推理上下文。这样既保留语义检索的灵活性，又能对来源和权限做可验证的控制。

Vibe Coding的另一面

原帖作者把部分原因归咎于vibe coding的流行。他的判断是：即使你用AI一次性生成一个全栈应用，AI大概率能覆盖端到端的流程，但不会处理深层验证、数据库索引这些"不显眼但关键"的部分。这些需要你在上线前自己补上。Agent工作流同理——vibe coding出来的Agent不会替你处理横切关注点。

这个观点并非否定vibe coding的价值。快速原型验证想法确实需要这种效率。问题在于，很多人把原型直接当成了产品。原型和生产系统之间的差距，恰恰就是软件工程要解决的问题：错误处理、边界条件、安全性、可观测性、性能退化。

横切关注点（cross-cutting concerns）指那些无法干净地归属到单一模块、却会渗透到系统各处的需求，典型例子包括日志、认证、错误处理、事务管理、限流和可观测性。它们的难点在于：不是某一处写对就行，而是要在所有相关路径上保持一致。这类问题恰恰是AI代码生成最容易忽略的部分——生成模型倾向于把注意力放在主流程上，让demo跑通，而横切逻辑往往散落在边界条件、异常分支和并发场景里，不容易在单次生成中被覆盖。这也是为什么原型能跑起来不等于系统可用：原型只验证主路径，生产系统必须处理所有副路径。

你需要知道你要什么

原帖最后一句值得单独拎出来：你仍然需要懂软件工程、设计原则和架构，才能告诉AI你真正想要什么。

这句话触及了AI辅助开发的核心悖论。AI可以帮你写代码，但它无法替你定义问题。如果你不知道需要什么样的验证逻辑、什么样的隔离级别、什么样的数据模型，你甚至无法写出有效的Prompt来让AI生成正确的实现。软件工程知识在这里不是被替代了，而是变成了与AI协作的前提条件。

换个角度看，AI编程工具降低的是实现门槛，不是设计门槛。能把想法翻译成代码的人变多了，但能想清楚系统应该如何组织的人并没有同比增加。这中间的缺口，就是当前Agent开发中各种问题的温床。