多智能体系统是运行时问题,而非提示工程问题

Reddit r/ArtificialInteligence 新闻

摘要

文章认为多智能体系统需要运行时基础设施层,而非更好的提示,引用了 MiniMax、OpenAI、Google 和 Anthropic 的发布。文章强调了工作者与验证者角色的分离以及多智能体设置的开销成本。

MiniMax 刚刚发布了带有 Agent Teams 的 Mavis。Claude Code 推出了 Agent View。OpenAI 有 Agents SDK,Google 有 ADK。所有主要 AI 公司都在朝着同一个方向汇聚:让智能体协作需要的是基础设施,而非更好的提示。Mavis 技术博客将我一直以来的感受具体化了:“多智能体系统是运行时问题,而非提示编排问题。”真正重要的问题不是“智能体下一步该做什么”,而是“谁分配任务,出现阻塞时怎么办,谁来验证完成。”Mavis 中的 Verifier(验证者)角色是最有趣的设计决策。在单智能体设置中,智能体同时扮演工作者和审查者。不出所料,它大多数时候都会批准自己的工作。Mavis 将 Worker(工作者)和 Verifier 分离,并赋予不同的目标函数。Worker 想要完成,Verifier 想要发现问题。两者之间的张力约束了质量。不得不说这相当优雅。他们还诚实地谈到了成本:多智能体有三类单智能体所没有的开销。交接成本(在智能体之间重新组织信息)、共享成本(全上下文共享会使窗口膨胀)以及聚合成本(将 10 个输出合并为一个交付物)。更多的智能体并不自动等于更好的结果。这与我的经验一致。我通过 Verdent 运行多智能体工作流已有几个月。子智能体架构在具有自然边界的任务上效果很好:研究 vs 实现 vs 测试。但对于紧密耦合的工作,一个具有良好上下文的强大智能体往往胜过那些花费一半 token 在协调上的团队。2026 年可能会成为行业承认提示工程收益递减并开始构建底层运行时层的一年。
查看原文

相似文章

多智能体系统与单智能体系统

Reddit r/AI_Agents

本文指出,大多数所谓的“智能体化”系统实际上只是配备工具的单智能体,并强调了多智能体架构带来的高昂成本和复杂性。文章梳理了三种有效的多智能体模式——编排者-工作者、流水线以及点对点模式,并提供了判断何时采用多智能体而非单智能体的标准。

@ghumare64: https://x.com/ghumare64/status/2052825541057626258

X AI KOLs Timeline

一个X帖子认为生产级AI代理需要运维支撑框架(运维手册、权限、日志、回滚、验证),而不仅仅是更好的提示词。作者引用了DevOps演进历程,指出提示词提供建议而运维手册提供控制,代理系统需要平台工程解决方案来实现权限、状态管理、验证、可观测性和回滚能力。

我们如何构建多智能体研究系统

Anthropic Engineering

Anthropic 详细介绍了其全新多智能体研究系统背后的架构与工程原则,重点阐述了采用 Claude Opus 4 和 Sonnet 4 的并行子智能体如何在复杂研究任务中显著优于单智能体方案。