我认为我们在AI代理上重蹈了早期微服务的覆辙
摘要
作者将早期的微服务热潮与当前的多智能体系统热潮进行了类比,认为工程实践——而非更好的模型——可能是实现可靠多智能体系统的关键。
许多代理演示让我想起了微服务刚开始流行时的情形。大家都热衷于将系统拆分成更小的组件。在架构图上看起来优雅,看起来可扩展,看起来像是未来。后来人们意识到,困难的部分不在于构建服务,而在于通信、编排、可观测性、调试、版本控制以及复杂性管理。如今,当我看到多代理系统时,也有类似的感觉。构建一个代理已经不再特别困难。但构建5个、10个或20个能够可靠协作、保持上下文、从故障中恢复并随时间保持可管理性的代理,似乎是一个更大的挑战。有时我在想,代理系统的下一个突破根本不会来自更好的模型,而是来自围绕代理的更优工程实践。我很好奇构建生产系统的人是否同意这一点,还是我完全搞错了。
相似文章
多智能体系统可能被过度使用了
文章认为多智能体系统在AI应用中经常被过度使用,并建议单个智能体,配备良好的工具、严格的状态和清晰的停止条件,对于许多工作流程来说更高效、更易调试且更经济。
停止构建多智能体系统
一篇观点文章认为,向系统中添加更多智能体通常是解决可靠性问题的错误方法,而一个精心设计的、具有更好上下文、工具、护栏和评估的单一智能体通常更优。
还有人注意到,开发 AI 智能体的人正在忘记软件工程的基本原则吗?
一位从业者认为,AI 智能体开发者正在重新发现一些基础软件工程早已解决的问题,例如输入验证、数据建模、进程隔离和访问控制,而氛围编程却忽略了这些贯穿各个环节的共性问题。文章呼吁将成熟的设计与架构原则应用于智能体工作流。
关于 AI 智能体的真实内情
一位资深从业者分享了将 25 个以上 AI 智能体部署到生产环境的经验教训,指出记忆、编排和可审计性远比模型选择重要。文章详细介绍了上下文丢失、静默成本循环等常见故障模式,并推荐了包含 Claude Sonnet 4、Pydantic AI 以及 Octopodas 等专用记忆层的技术栈。
我认为我们思考AI代理的规模太小了
这篇文章批评了当前对个别AI代理的关注,并提议转向将其视为一个更大的、持久的操作系统的一部分,用于管理工作目标和工作流程。