素材来源官方媒体/网络新闻
,
,
,
上下文工程的原则 \x0a· 原则1：共享完整上下文 智能体需要共享完整的上下文和历史记录，而不仅仅是单一消息。例如，在构建一个“Flappy Bird 克隆”游戏时，如果子智能体只接收部分任务描述（如“构建背景”或“构建小鸟”），可能会误解需求，导致结果不一致。共享完整上下文（包括之前的决策和动作）可以减少误解 \x0a· 原则2：动作隐含决策，冲突决策导致失败 每个智能体的动作都包含隐性决策。如果多个子智能体在没有充分沟通的情况下独立工作，可能会基于冲突的假设，导致最终结果不协调。例如，背景和小鸟的视觉风格不一致 \x0a建议：默认避免违反这两个原则的多智能体架构。单线程线性智能体架构更简单可靠，因为上下文是连续的 \x0a\x0a长期运行智能体的理论 \x0a· 可靠性挑战：长期运行的智能体容易因错误累积而失败。上下文工程是确保可靠性的核心，超越了传统的“提示工程”，需要动态、自动化的上下文管理 \x0a· 多智能体的脆弱性：将任务拆分为子任务并分配给多个子智能体看似高效，但容易因上下文丢失或误解而失败。例如，子智能体可能误解任务，导致结果无法整合 \x0a· 解决方案： \x0a · 单线程架构：最简单的方式是使用单一智能体，保持上下文连续性，适合大多数任务 \x0a · 上下文压缩：对于超长任务，可以引入一个专门的 LLM 模型来压缩动作和对话历史，保留关键信息。这需要针对特定领域进行优化，甚至可能需要微调模型 \x0a · 挑战：上下文窗口有限，处理超长上下文仍是一个未完全解决的问题 \x0a\x0a应用这些原则 \x0a· Claude Code 的例子：Claude Code 避免并行子智能体，仅用子智能体回答明确问题，而非执行复杂任务，以保持上下文一致性 \x0a· 编辑应用模型：早期代码编辑依赖大模型生成 markdown 说明，再由小模型重写代码，但小模型常误解说明。如今，单一模型同时决策和执行更可靠 \x0a· 多智能体的局限：多智能体协作（类似人类讨论解决冲突）理论上可行，但当前智能体缺乏足够智能，无法高效共享上下文，导致系统脆弱\x0a\x0a原文地址：\x0ahttps://cognition.ai/blog/dont-build-multi-agents