我让智能体跑起来了,然后发现无聊的服务器杂事才是真正的问题
摘要
一位开发者反思将 AI 智能体工作流迁移到服务器的经历,发现 systemd、日志、幂等性和故障告警这些枯燥的基础设施问题比智能体本身更重要。
最近我把几个小型的智能体工作流从笔记本电脑上搬到了服务器上。没什么大不了的。一个负责写草稿,一个更新几个文件,还有一个按计划调用 API,本应在我不用像紧张兮兮的家长那样盯着的情况下自动运行。让第一版跑起来的感觉很棒。工具调用正常,输出看起来正确,日志里也有记录。在早期构建循环的某个阶段,我用了 MoClaw,它比我预想中更快地让我到达了“好吧,这东西确实能跑”的阶段。然后我把它放到一台便宜的 VPS 上,不再时刻盯着它。麻烦就从这里开始了。API 返回 200,但有用的数据却是空的。任务重试了,现在我得确保它没有重复执行同一操作。服务器在一次运行中途重启了。环境变量缺失——这几乎是必然的。日志显示成功,但我真正关心的事情根本没有发生。这些在智能体演示中很少见到。每个人都展示智能体如何使用工具。却没有人展示你凌晨 1 点 SSH 登上一台机器,试图弄明白你的“自主工作流”是死了、重复了,还是在礼貌地撒谎。我并不反对智能体。我仍然认为这东西很有用。但用它构建得越多,我越觉得智能体只是产品的一半。另一半是没人想截图的无聊东西。
我以为重要的 实际重要的
模型选择 cron/systemd
工具调用 幂等性
提示词 可读日志
记忆 故障告警
更大的上下文窗口 锁定的密钥
更多自主性 在风险操作前进行人工审批
有点好笑的是,智能体部分让我兴奋,但在服务器上的第一周让我对 systemd 肃然起敬。
相似文章
Agent工程中的枯燥部分
作者讨论了在生产中构建可靠AI Agent时那些不引人注目但至关重要的方面,包括监控运行中的进程、恢复失败的任务以及提供UI状态,并向社区询问常见的痛点和现成的解决方案。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述,构建AI智能体时的许多挑战实际上源于工作流和状态管理问题,而非模型智能,强调了稳健的状态处理和可观测性的必要性。
AI智能体中最无聊的部分:没人构建,人人都需要
一位实践者回顾了在生产环境中部署AI智能体的经历,指出80%的工程精力花费在工作流、所有权和审批流程上,而非模型本身。他强调,共享上下文和路由这些“无聊层”对于产生实际影响至关重要。
经过数月的智能体构建,我改变了关于什么最重要的看法。
作者反思了将AI智能体从原型推向生产环境的挑战,得出结论:可靠的编排和安全保护机制比模型的渐进改进更为关键。
真实用户出现后,AI代理的构建变得奇怪起来
一位经验丰富的开发者反思了AI代理演示与实际性能之间的差距,强调了诸如文档不完善、权限期望过于简单,以及认为概率性软件在生产中会变得确定性的误解等问题。