LLM代理框架在实践中令人失望，文章认为多智能体架构是导致其脆弱和不可靠的主要原因。作者提出了构建有效且长期运行AI代理的两个核心原则：全面共享上下文和认识到行动携带隐含决策，并倡导采用单线程或精心管理上下文的架构来提高可靠性。

多智能体架构的缺陷

• 现有的LLM代理框架，如OpenAI的swarm和Microsoft的autogen，推崇多智能体架构，但作者认为这是一种错误的构建方式。
• 将任务分解为子任务并分配给多个子代理的架构（如“Flappy Bird 克隆”示例）看似诱人，但在实践中非常脆弱，容易出现复合错误和不一致。
• 子代理可能因上下文不足或误解任务而产生不协调或错误的结果，即使尝试共享原始任务上下文也可能因多轮对话和工具调用而失效。
• 在2025年，多智能体协作只会导致系统脆弱，因为决策过于分散，且代理间无法彻底共享上下文。

核心原则：上下文工程

• 提出两个关键原则：1. 共享上下文（Share context）；2. 行动携带隐含决策（Actions carry implicit decisions）。
• “上下文工程”是“提示工程”的下一阶段，旨在动态系统中自动管理和提供模型所需上下文，这是构建AI代理工程师的首要任务。
• 原则1强调应共享完整的代理追踪信息，而不仅仅是单个消息，以确保每个代理都能获得之前所有相关决策的上下文。
• 原则2指出代理的行动基于隐含假设，冲突的假设会导致不一致的结果（例如“Flappy Bird”子代理生成不同视觉风格的组件）。

构建可靠的长期运行代理

• 可靠性是代理长期运行的关键，必须采取措施遏制潜在的复合错误，而上下文工程是核心。
• 最简单的实现方式是采用单线程线性代理，确保上下文的连续性，这种架构在大多数情况下足以满足需求。
• 对于包含大量子任务且可能导致上下文窗口溢出的超长任务，可以通过引入一个专门的LLM模型来压缩历史行动和对话，提取关键信息。
• Cognition公司已实践通过微调小型模型来解决长上下文管理问题，以提高代理在更长上下文中的有效性。

原则的应用与实际案例

• Claude Code子代理： 该代理会生成子任务，但子任务代理不与主代理并行工作，且通常只负责回答问题，不编写代码，以避免因上下文不足导致的冲突。
• 编辑应用模型： 过去，大型模型输出修改说明，小型模型实际执行编辑，但常因指令歧义导致错误；现在倾向于由单个模型一次性完成编辑决策和应用，以提高可靠性。
• 人类在协作中（如解决代码合并冲突）能高效沟通并达成共识，但AI代理目前尚不具备这种高效、主动的沟通能力。

未来展望与挑战

• 当前关于上下文工程的观察只是代理构建标准原则的开始，未来还有更多挑战和技术有待探索。
• 虽然作者对代理间协作的长期可能性持乐观态度，但目前多智能体协作系统仍然脆弱，因为跨代理的上下文传递问题尚未得到有效解决。
• 作者认为，随着单线程代理在与人类沟通方面做得更好，跨代理的并行性和效率将自然而然地大幅提升。
• Cognition公司将这些原则融入其内部工具和框架的构建中，并认识到理论并非完美，需要保持灵活性和谦逊以适应领域发展。