2025 上下文工程最新进展深度解析（3）: 最佳实践分享

2025 上下文工程最新进展深度解析（3）: 最佳实践分享 2025 上下文工程最新进展深度解析（3）: 最佳实践分享 Modified October 18, 2025 子任务 2“构建一个可以上下移动的鸟”。 结果，子 Agent 1 实际上误解了你的子任务，并开始构建一个看起来像 Super Mario Bros 的背景。 子 Agent 2 为你构建了一只鸟，但它看起来不像游戏资源，而且它的移动方式与 Flappy Bird 中的鸟完全不同。 现在，最终 Agent 不得不承担一个不理想的任务，即组合这两个误解。 这可能看起来有些刻意，但现实世界中的大多数任务都有许多层次的细微差别，所有这些都有可能被误解。 你可能会认为一个简单的解决方案就是将原始任务作为上下文复制到子 Agent 中。 这样，他们就不会误解自己的子任务。 但请记住，在一个真实的生产系统中，对话很可能是多轮的， Agent 可能不得不进行一些工具调用来决定如何分解任务，而且任何数量的细节都可能对任务的解释产生后果。 原则 1 共享上下文，并共享完整的代理跟踪，而不仅仅是单个消息 让我们再次修改我们的Agent，这次确保每个Agent都有先前Agent的上下文。 不幸的是，我们还没有完全摆脱困境。 当你给你的智能体分配相同的 Flappy Bird 克隆任务时，这次你可能会得到一只鸟和背景具有完全不同的视觉风格。 子智能体 1 和子智能体 2 无法看到对方在做什么，因此他们的工作最终变得彼此不一致。 子 Agent 1 采取的行动和子 Agent2 采取的行动基于事先未规定的相互冲突的假设。 原则 2 行为隐含着决策，而冲突的决策会导致不良后果 我认为原则 1 和原则 2 至关重要，而且很少值得违反，因此你应该默认排除任何不遵守这些原则的智能体架构。 你可能会认为这很限制，但实际上你仍然可以探索许多不同的智能体架构。 遵循原则最简单的方法就是使用单线程线性智能体： 在这里，上下文是连续的。 但是，对于包含许多子部分的大型任务，可能会导致上下文窗口开始溢出。 说实话，简单的架构已经能让你走得很远了，但对于那些真正有长期任务需求，并且愿意投入精力的人来说，你可以做得更好。 有几种方法可以解决这个问题，但今天我将只介绍一种： 在这个世界，我们介绍一种新的 LLM 模型，其关键目的是将一段行动和对话的历史压缩成关键细节、事件和决策。 这很难做到正确。需要投入资源来确定最终成为关键信息的内容，并创建一个擅长于此的系统。 根据领域，你甚至可以考虑微调一个较小的模型（事实上，这正是我们在 Cognition 所做的事情）。 Claude Code SubAgent 截至 2025 年 6 月， Claude Code 是一个会生成子任务的 Agent 示例。 然而，它从不与子任务 Agent 并行工作，而且子任务 Agent 通常只负责回答问题，不编写任何代码。 为什么？ 子任务 Agent 缺乏来自主 Agent 的上下文，否则它将无法做任何超出回答明确问题的额外工作。 而且，如果它们运行多个并行子 Agent ，可能会给出冲突的响应，导致我们之前看到的 Agent 示例中的可靠性问题。 在这种情况下，拥有一个子 Agent 的好处是，子 Agent 的所有调查工作不需要保留在主代理的历史记录中，从而允许在上下文耗尽之前进行更长的跟踪。 Claude Code 的设计者采取了故意简单的方法。 编辑 应用模型 2024 年，许多模型在代码编辑方面表现很差。 在编码代理、 IDE 、应用构建器等（包括 Devin ）中，一种常见的做法是使用“编辑应用模型”。 其核心思想是，给定一个描述所需更改的 Markdown 说明，让一个小模型重写整个文件，实际上比让一个大模型输出格式正确的 diff 更可靠。 因此，构建者让大模型输出代码编辑的 Markdown 说明，然后将这些 Markdown 说明输入给小模型以实际重写文件。 然而，这些系统仍然存在很多错误。 例如，小模型经常误解大模型的指令，由于指令中最轻微的不明确性而做出错误的编辑。 如今，编辑决策和应用的执行通常由单个模型在一个动作中完成。 子任务 2“构建一个可以上下移动的鸟”。 结果，子 Agent 1 实际上误解了你的子任务，并开始构建一个看起来像 Super Mario Bros 的背景。 子 Agent 2 为你构建了一只鸟，但它看起来不像游戏资源，而且它的移动方式与 Flappy Bird 中的鸟完全不同。 现在，最终 Agent 不得不承担一个不理想的任务，即组合这两个误解。 这可能看起来有些刻意，但现实世界中的大多数任务都有许多层次的细微差别，所有这些都有可能被误解。 你可能会认为一个简单的解决方案就是将原始任务作为上下文复制到子 Agent 中。 这样，他们就不会误解自己的子任务。 但请记住，在一个真实的生产系统中，对话很可能是多轮的， Agent 可能不得不进行一些工具调用来决定如何分解任务，而且任何数量的细节都可能对任务的解释产生后果。 原则 1 共享上下文，并共享完整的代理跟踪，而不仅仅是单个消息 让我们再次修改我们的Agent，这次确保每个Agent都有先前Agent的上下文。 不幸的是，我们还没有完全摆脱困境。 当你给你的智能体分配相同的 Flappy Bird 克隆任务时，这次你可能会得到一只鸟和背景具有完全不同的视觉风格。 子智能体 1 和子智能体 2 无法看到对方在做什么，因此他们的工作最终变得彼此不一致。 子 Agent 1 采取的行动和子 Agent2 采取的行动基于事先未规定的相互冲突的假设。 原则 2 行为隐含着决策，而冲突的决策会导致不良后果 我认为原则 1 和原则 2 至关重要，而且很少值得违反，因此你应该默认排除任何不遵守这些原则的智能体架构。 你可能会认为这很限制，但实际上你仍然可以探索许多不同的智能体架构。 遵循原则最简单的方法就是使用单线程线性智能体： 在这里，上下文是连续的。 但是，对于包含许多子部分的大型任务，可能会导致上下文窗口开始溢出。 说实话，简单的架构已经能让你走得很远了，但对于那些真正有长期任务需求，并且愿意投入精力的人来说，你可以做得更好。 有几种方法可以解决这个问题，但今天我将只介绍一种： 在这个世界，我们介绍一种新的 LLM 模型，其关键目的是将一段行动和对话的历史压缩成关键细节、事件和决策。 这很难做到正确。需要投入资源来确定最终成为关键信息的内容，并创建一个擅长于此的系统。 根据领域，你甚至可以考虑微调一个较小的模型（事实上，这正是我们在 Cognition 所做的事情）。 Claude Code SubAgent 截至 2025 年 6 月， Claude Code 是一个会生成子任务的 Agent 示例。 然而，它从不与子任务 Agent 并行工作，而且子任务 Agent 通常只负责回答问题，不编写任何代码。 为什么？ 子任务 Agent 缺乏来自主 Agent 的上下文，否则它将无法做任何超出回答明确问题的额外工作。 而且，如果它们运行多个并行子 Agent ，可能会给出冲突的响应，导致我们之前看到的 Agent 示例中的可靠性问题。 在这种情况下，拥有一个子 Agent 的好处是，子 Agent 的所有调查工作不需要保留在主代理的历史记录中，从而允许在上下文耗尽之前进行更长的跟踪。 Claude Code 的设计者采取了故意简单的方法。 编辑 应用模型 2024 年，许多模型在代码编辑方面表现很差。 在编码代理、 IDE 、应用构建器等（包括 Devin ）中，一种常见的做法是使用“编辑应用模型”。 其核心思想是，给定一个描述所需更改的 Markdown 说明，让一个小模型重写整个文件，实际上比让一个大模型输出格式正确的 diff 更可靠。 因此，构建者让大模型输出代码编辑的 Markdown 说明，然后将这些 Markdown 说明输入给小模型以实际重写文件。 然而，这些系统仍然存在很多错误。 例如，小模型经常误解大模型的指令，由于指令中最轻微的不明确性而做出错误的编辑。 如今，编辑决策和应用的执行通常由单个模型在一个动作中完成。 🔗 原文链接： https://mp.weixin.qq.com/s/503cS3dF... https://mp.weixin.qq.com/s/503cS3dF... 原创 Brad强 一支烟花AI2025年10月17日 07:30 上海 Manus 模型如何调用Shell工具？ Peak解释说，Manus通过两种方式让模型了解并调用Shell工具： 首先，系统提示中会包含预装命令行实用程序的路径提示； 其次，最常用的工具会以紧凑格式注入到系统提示中，只列出工具名称，并告知智能体可安全使用 help标志来获取详细用法。 Manus的工具都由其团队开发，格式统一，因此智能体能有效学习和使用。 索引与文件系统的使用？ Lance询问了Manus对索引数据库的看法。 Peak表示，Manus目前不使用索引数据库，因为每个沙箱会话都是新的，且用户追求快速交互，没有时间动态构建索引。Manus更倾向于使用 grep 和 glob 等文件系统搜索工具。 然而，Peak也指出，对于构建长期记忆或集成企业知识库，外部向量索引仍然是必要的，这取决于所需访问的信息规模和应用场景。 智能体的长期记忆管理？ 关于智能体的长期记忆，Peak介绍了Manus的“知识”概念，这是一种显式记忆。用户可以明确指示Manus记住某些偏好（例如“每次都用Excel交付结果”），系统会弹窗确认是否接受这些学习到的信息。 Manus还在探索更自动化的记忆方式，例如通过收集用户对智能体行为的纠正（如数据可视化中的字体问题），利用集体反馈实现“在线学习的自改进智能体”，以无参数的方式提升智能体性能。 架构演进与模型能力提升？ Lance提出了一个核心挑战：随着模型能力的提升，如何持续优化智能体架构，移除不必要的“脚手架”? Peak透露，Manus自3月发布以来已重构五次，因为模型不仅在改进，其行为也在不断变化。 Manus的内部理论是固定智能体架构，然后在不同模型之间切换。 如果架构能从弱模型切换到强模型中获得显著收益，则说明其更具未来性。 Manus每隔一两个月会进行架构审查，并利用开源模型和早期专有模型进行内部研究，为未来的模型发布做准备。 数据存储格式偏好？ 在数据存储格式方面，Peak表示Manus优先考虑基于行的格式（如纯文本），因为它便于模型使用grep或按行范围读取。 尽管Markdown模型处理得很好，但有时会导致模型输出过多项目符号，因此Manus更倾向于使用纯文本。 摘要的提示策略？ 关于如何生成高质量摘要，Peak分享了Manus的经验：避免使用自由形式的提示让AI生成所有内容。 相反，他们定义了一种结构化的 “模式” （ Schema ），包含多个字段，让AI来填充。 例如，明确指出“这是我修改过的文件”、“这是用户的目标”、“这是我上次中断的地方”。这种结构化输出确保了摘要的稳定性和可迭代性，避免了信息丢失。 上下文压缩的深度探讨？ Lance进一步询问了上下文压缩的细节，特别是当搜索工具返回大量信息时如何处理。 Peak指出，Manus中的几乎每个动作都是可逆的，可以将结果卸载到文件系统或外部状态，并使用唯一的标识符（如文件路径、URL、查询）来引用。 对于复杂的搜索，Manus会使用“作为工具的智能体”（子智能体）来处理，子智能体负责收集关键信息并以固定模式返回给主智能体。 对于简单搜索，则使用完整的详细格式，并依赖压缩机制。 Peak还强调，模型应将中间见解或关键发现写入文件，以防压缩过早发生导致信息丢失。 智能体之间的通信也通过 “智能体MapReduce” 模式实现，主智能体定义输出模式，子智能体使用“提交结果”工具并结合约束解码来确保输出符合模式，从而实现高效且结构化的信息传递。 Cognition 上下文工程原理 我们将逐步深入以下原则： 1. 共享上下文 2. 行为隐含决策 为什么要思考原则？ HTML 于 1993 年问世。2013 年， Facebook 向世界发布了 React 。如今已是 2025 年， React （及其衍生品）主导着开发者构建网站和应用程序的方式。为什么？因为 React 不仅仅是一个编写代码的脚手架。 它是一种理念。通过使用 React ，你拥抱了以反应性和模块化模式构建应用程序，而人们现在将其接受为标准要求，但这对于早期的网页开发者来说并非显而易见。 在 LLMs 和构建 AI 代理的时代，感觉我们仍然在玩原始的 HTML & CSS ，并试图弄清楚如何将它们组合在一起以创造良好的体验。目前还没有单一的构建代理的方法成为标准，除了一些绝对的基础之外。 构建长期运行代理的理论 让我们从可靠性开始。 当代理需要在长时间运行时保持可靠并维持连贯的对话时，你必须做某些事情来控制潜在的错误累积。 否则，如果你不小心，事情很快就会崩溃。 可靠性的核心是上下文工程。 它是在动态系统中自动完成这项工作。它需要更多的细微差别，并且实际上是构建 AI 代理工程师的首要工作。 以一个常见的代理类型为例。 这个代理: 1.将其工作分解为多个部分 2.启动子代理来处理这些部分 3.最后将这些结果组合起来 这是一个诱人的架构，特别是如果你在一个包含多个并行组件的任务领域中工作。然而，它非常脆弱。 关键故障点是：假设你的任务是“构建一个 Flappy Bird 克隆版”。 这被分为 子任务 1“构建一个带有绿色管道和碰撞框的移动游戏背景”和