当我最初开始构建软件时，我是一个氛围程序员。我有一个想法，打开编辑器，就开始写。没有图表，没有过度思考——只是像与计算机对话一样让代码流淌。它很快、有趣，而且往往杂乱无章。
这种氛围编程的思维模式多年来对我很有帮助。我可以在一个下午就搭建一个原型，与朋友测试，并快速迭代。它有一种魔力：感觉代码几乎自己写出来，由直觉和动量引导。
但随着我转向构建 AI 智能体——那些需要可靠、可调试、可维护的系统——氛围编程开始适得其反。智能体有一种暴露每一个隐藏假设的方式。在设计提示或状态管理中的一个小错误可能导致一系列奇怪的行为，当你的代码库是一团快速决策的乱麻时，这些行为几乎无法追踪。
氛围编程对智能体的危害
氛围编程在模糊性中繁荣。你依赖你的心智模型，让事物保持松散定义，并相信你稍后会理解它。对于传统软件，这有时有效，因为执行是确定性的。但智能体具有非确定性核心（LLM）和涌现行为。对于脚本来说”足够好”的东西，当智能体需要将工作移交给另一个智能体，或者当你需要重现失败时，就变成了脆弱的契约。
我艰难地学到了这一点。我的第一个多智能体项目是一个意大利面条怪物。我有智能体互相调用，握手协议只存在于我的脑海中。当某些东西坏了时，我会花数小时解开流程。曾经感觉像速度的氛围现在感觉像技术债务滚雪球。
智能体工程实际意味着什么
智能体工程不是关于放弃创造力。它是关于有意的设计应用于自主系统。它意味着：
- 明确的契约：定义每个智能体的期望和返回，就像你会定义一个 API 一样
- 可观测状态：让智能体的想法、决策和行动可见。记录日志就像为未来的自己留下面包屑
- 幂等步骤：设计工作流，使重试一个步骤不会破坏东西。智能体会失败；你的系统不应该崩溃
- 组合优于巧妙：构建小的、专注的智能体，可以以不同方式组合，而不是做一切的单一大脑
这种思维转变就是我所说的从氛围到工程的转变。你仍然可以发挥创造力——但在保持系统在更改一个部分时不崩溃的围栏内。
我如何弥合两种思维模式
我没有完全放弃氛围编程。我仍然将它用于探索：尝试一个新的提示模式，测试一个库，或构建一次性脚本。现在的区别在于我将原型视为实验，而不是最终产品。一旦某些东西有效，我将其重构为具有清晰接口和测试的适当智能体组件。
我使用的一个实用技巧：我以规范文档（即使很短）开始每个新智能体。它回答：
- 这个智能体的工作是什么（一句话）？
- 它需要什么输入？什么格式？
- 成功是什么样子？失败是什么样子？
- 我们如何知道它是否有效？
这种简单的纪律在我写一行代码之前就能捕捉到很多问题。
有帮助的工具
我一直在使用 Antfarm 模式来编排专门的智能体。关键是每个智能体都有单一职责并通过结构化消息通信。就像从单体脚本转向微服务，但是为了 AI。氛围仍然存在——我可以设计智能体如何思考和交互——但工程确保当一个智能体脱轨时，其他的保持稳定。
拥抱两者，但知道何时切换
氛围编程用于学习和探索。智能体工程用于构建持久的系统。我认识的最优秀的从业者可以在模式之间切换：他们会快速构建原型，然后迅速将其固化 production-ready 的东西。
如果你在构建智能体，不要让涌现性诱使你跳过基础知识。你未来的自己——和你的用户——会因为这种清晰而感谢你。
你呢？你在构建智能体时发现自己是在氛围编程还是工程思维？让我们在 Twitter 或评论中讨论。