最近，两篇博客文章引发了关于多智能体系统的讨论：Cognition团队发布的《不要构建多智能体》和Anthropic团队发布的《我们如何构建多智能体研究系统》。尽管标题看似对立，但它们实际上分享了许多共同的见解，尤其是在何时以及如何有效地使用多智能体架构方面。
首先，上下文工程（Context Engineering）是成功的关键。Cognition的文章强调了这一概念，指出即使是最智能的模型，如果没有适当的上下文，也无法有效工作。传统的“提示工程”已经演变为“上下文工程”，它要求工程师在动态系统中自动为每个子智能体提供正确的背景信息。Anthropic的文章虽然没有直接使用这个术语，但同样关注了长期对话管理、子任务描述和上下文压缩等问题。例如，他们描述了如何在长时间运行的研究中，通过智能摘要和外部存储来保持上下文的连贯性。
其次，多智能体系统在“读”任务上比“写”任务更易管理。Cognition的编码系统涉及大量的写操作，这导致子智能体之间容易产生冲突，因为“动作带有隐式决策，冲突的决策会带来糟糕的结果”。而Anthropic的研究系统则更多地依赖于读操作（如搜索和收集信息），最终报告由单个智能体统一编写。这表明，当写操作需要并行化时，协调和合并的复杂性会急剧增加。
生产环境中，多智能体系统还面临一系列工程挑战。Anthropic的文章列举了持久执行、错误处理、调试和可观测性等问题。例如，智能体长时间运行后，任何小错误都可能累积成严重问题，且无法简单地从起点重启。因此，需要框架支持耐用执行，确保在出错时能从中断处恢复。此外，智能体的非确定性行为使得调试变得困难，需要全面的跟踪和可观测性工具来诊断问题。
评估也是另一个重要方面。Anthropic建议从小规模评估开始（甚至20个数据点），使用LLM作为评判来自动评分，同时保留人工测试。这与LangSmith的评估方法论不谋而合，后者提供了数据集管理、LLM评判和人工注释队列等功能。
结论是，多智能体系统并非万能药。它们最适合那些价值高、需要大量并行化、信息超出单一上下文窗口、或涉及多个复杂工具的任务。对于像编码这样依赖性强的任务，当前的多智能体技术可能并不理想。因此，框架应允许开发者在单智能体和多智能体之间灵活切换，而LangGraph正是为此设计。同时，像LangGraph和LangSmith这样的工具可以提供耐用执行、调试、可观测性和评估等通用能力，让开发者专注于业务逻辑。