LangChain 和 Manus 的 AI 智能体上下文工程实践

内容概要

本次线上研讨会邀请了 LangChain 的 Lance 和 Manus 的 Pete，共同探讨了 AI 智能体的上下文工程 (Context Engineering)。Lance 首先概述了上下文工程的兴起和核心理念，例如上下文的卸载 (offloading)、缩减 (reduction) 和隔离 (isolation)。随后，Pete 深入分享了 Manus 在实践中总结的最新经验，重点介绍了上下文缩减、隔离以及一种用于工具卸载的全新分层式行为空间 (layered action space) 的高级技巧，并强调了保持简洁和结构化方法的重要性。

上下文工程简介
智能体驱动下上下文工程的兴起
上下文工程的常见主题
上下文卸载
上下文缩减
上下文检索
上下文隔离
上下文缓存
Open Deep Research 案例分析
上下文工程主题总结
Manus 关于上下文工程的最新经验
为什么上下文工程至关重要
上下文缩减：压缩与摘要
上下文隔离：通信模式与共享内存模式
上下文卸载：分层式行为空间
第一层：函数调用
第二层：沙盒工具
第三层：软件包与 API
连接五个维度
避免上下文过度工程
问答环节：Shell 工具与沙盒
问答环节：索引与文件系统检索
问答环节：Manus 中的长期记忆与知识
问答环节：适应模型与架构的演进
问答环节：数据存储格式
问答环节：为摘要生成提示
问答环节：搜索工具输出的压缩
问答环节：智能体间通信与“智能体即工具”
问答环节：模型选择与开源模型
问答环节：工具选择与行为空间扩展
问答环节：工具调用与沙盒的混合模式
问答环节：规划与待办事项列表
问答环节：多智能体系统设计（角色分工 vs 通用执行器）
问答环节：沙盒环境下的安全与防护
问答环节：评估策略（用户评分、自动化测试、真人实习生）
问答环节：可验证奖励的强化学习 vs 工具调用智能体
问答环节：通过相似工具名复现工具能力
总结与结束语

上下文工程简介

Lance: 好的，感谢各位的到来。我们现在开始本次的线上研讨会，相信还会有更多朋友陆续加入。我是 Lance，LangChain 的一位创始工程师。今天和我一起的是来自 Manus 的 Pete。

Pete: Pete，你想先简单介绍一下自己吗？好的，大家好，我是 Manus 的联合创始人兼首席科学家。我主要负责设计 Manus 的智能体框架和许多其他功能。今天能来到这里我感到非常兴奋，也感谢 Lance 的邀请。

Lance: 我们也很激动能共同举办这次活动。首先，Manus 是一款非常酷的产品，我自己也用了很久。此外，几个月前他们发表了一篇关于上下文工程 (Context Engineering) 的精彩博客，对我启发很大。所以，我想先快速介绍一下我眼中的上下文工程，并会引用他们的一些观点。然后，Pete 会介绍一些在那篇文章中没有涉及的新想法。如果你已经读过，那么这次将听到一些全新的、有趣的内容。我会先做个铺垫，然后交给 Pete，最后是问答环节。

智能体驱动下上下文工程的兴起

Lance: 你可能听说过“提示工程”(Prompt Engineering) 这个词，它大约在今年早些时候开始流行。从谷歌搜索趋势来看，提示工程是在 ChatGPT 发布后，也就是 2022 年 12 月左右兴起的。当我们有了聊天模型这种新事物后，如何为它们编写提示就成了一个热门话题，提示工程也随之发展成为一门与聊天模型交互的学科。

而上下文工程 (Context Engineering) 则是在今年 5 月左右开始崭露头角，并在谷歌趋势中迅速上升。这与“智能体之年”(year of agents) 的概念不谋而合。这是为什么呢？如果你开发过智能体，就会发现上下文会以一种非常特殊的方式增长。

具体来说，一个智能体包含一个大语言模型 (LLM)，并绑定了若干工具。LLM 可以在一个循环中自主调用这些工具。挑战在于，每次工具调用后都会返回一个观察结果 (observation)，这个结果会被追加到聊天记录中。随着时间推移，消息列表会不断增长，导致在智能体运行时消息数量出现无限制的爆炸式增长。

例如，Manus 在他们的文章中提到，典型任务大约需要 50 次工具调用。Anthropic 也指出，生产环境中的智能体对话可能会持续数百轮。因此，挑战在于智能体因为其长时间自主运行和频繁使用工具的特性，会通过工具调用累积大量上下文。

Anthropic 在一份出色的报告中谈到了“上下文腐烂”(context rot) 的问题，简单来说，就是随着上下文长度的增加，模型的性能会下降。这就形成了一个悖论：智能体需要大量上下文来进行工具调用，但我们又知道上下文越长，性能越差。这是我们许多人都面临的挑战，也催生了“上下文工程”这个术语。

当然，是 Andrej Karpathy 今年早些时候在 Twitter 上创造了这个词。你可以把上下文工程理解为一门精巧的艺术和科学，旨在用恰到好处的信息填充上下文窗口，以满足下一步任务的需求。它的目标是解决构建智能体时因其自由调用工具而引发的上下文爆炸问题。当所有工具消息都堆积在消息队列中时，我们如何筛选信息，确保在每个时间点都为智能体提供做出正确决策所需的信息？

上下文工程的常见主题

Lance: 为了解决这个问题，我们从包括 Manus 在内的许多工作中，总结出了一些常见的主题。

上下文卸载

Lance: 第一个思路是上下文卸载 (context offloading)。我们反复看到这个趋势。核心思想是，并非所有上下文都需要保留在智能体的消息历史中。你可以将信息卸载出去，存放到别处，使其位于上下文窗口之外，但在需要时仍然可以被检索。

其中最流行的方法之一就是使用文件系统 (file system)。例如，将工具消息的输出转储到文件系统中，然后只向智能体返回一个必要的最简信息。这样，智能体在需要时可以引用完整的上下文，但像网页搜索结果这种非常消耗 Token 的完整内容，就不会永远占据你的上下文窗口。

这个方法在许多项目中都有应用。Manus 在用，我们一个叫 Deep Agents 的项目也利用了文件系统。Open Deep Research 项目中，智能体状态 (agent state) 实际上也扮演了类似外部文件系统的角色。当然，Claude Code 和长时运行的智能体 (long-running agents) 也广泛使用了这种技术。所以，将上下文卸载到文件系统，是当今许多生产级智能体中非常普遍和流行的做法。

上下文缩减

Lance: 第二个思路是缩减上下文 (reducing context)。卸载是指将像工具消息这样消耗大量 Token 的信息，不全部返回到消息列表中，而是转储到文件系统，仅在需要时检索。缩减上下文与此类似，但它做的是对信息进行摘要或压缩。

一个直观的方法是摘要工具调用的输出。我们在 Open Deep Research 项目中就是这么做的。另一个方法是修剪 (pruning) 工具调用或工具消息。有趣的是，Claude 3.5 Sonnet 实际上已经内置了这个功能。如果你去看他们最近的发布，会发现它现在原生支持这个特性。所以，修剪旧的工具调用和输出，已经成为 Claude 在其 SDK 中内置的功能。

对完整的消息历史进行摘要或压缩，在 Claude Code 的压缩功能中可以看到。当上下文窗口使用率达到一定百分比时，它就会触发压缩。Cognition 公司也提到了在智能体交接时进行摘要或修剪的想法。因此，缩减上下文是一个非常流行的主题，我们可以在从 Claude Code 到 Open Deep Research 再到 Cognition 等许多案例中看到它的身影，Claude 3.5 Sonnet 也集成了这一功能。

上下文检索

Lance: 接下来是检索上下文 (retrieving context)。如今，在 X 或 Twitter 上，关于检索上下文的正确方法，存在着经典的争论。Cursor 的 Lee Robinson 最近在 OpenAI 的演示日上做了一次非常精彩的演讲，我会确保分享这些幻灯片，以便大家查看链接。他谈到，Cursor 使用了索引和语义搜索，以及像 glob 和 grep 这样更简单的基于文件的搜索工具。而 Claude Code 则只使用文件系统和简单的搜索工具，主要是 glob 和 grep。

所以，为智能体按需检索上下文有不同的方式：一种是索引加语义搜索，另一种是文件系统加简单的文件搜索工具。两者都可以非常有效，各有优劣，我们可以在问答环节讨论。但无论如何，上下文检索对于构建高效的智能体至关重要。

上下文隔离

Lance: 上下文隔离 (context isolation) 是我们看到的另一个主要主题，特别是通过多智能体 (multi-agents) 来划分上下文。这里的要点在于，每个子智能体 (sub-agent) 都有自己独立的上下文窗口，从而实现关注点分离 (separation of concerns)。

Manus 的 Wide Agents 谈到了这一点，我们的 Deep Agents 项目也使用了这种方法，Open Deep Research 同样如此。Claude 在其研究中也利用了子智能体，例如在 Claude 的多智能体研究员 (multi-agent researcher) 和 Claude Ghost 中都支持子智能体。因此，子智能体是实现上下文隔离的一种非常常见的方式，我们已在许多不同的项目中见证了它的应用。

上下文缓存

Lance: 另外，我觉得非常有趣的一点是缓存上下文 (caching context)，Manus 对此有很多讨论。稍后我会让 Pete 详细阐述，但我认为这也是一个非常有意思的技巧。

Open Deep Research 案例分析

Lance: 我来举一个我们在 Open Deep Research 项目中看到的简单例子。这是我们一个非常受欢迎的开源项目，它基本上是一个开源的深度研究实现，性能与市面上一些最好的实现相当。你可以查看我们的代码库，我们在 Deep Research Bench 的测试结果显示它排名前十。

这个项目分为三个阶段：研究范围界定、使用多智能体架构的研究阶段，以及最后的一次性写作阶段 (one-shot writing phase)。我们使用了卸载技术，即首先创建一个摘要来界定研究计划的范围。我们将其卸载，而不是直接保存在上下文窗口中，因为这个窗口之后会被其他信息填满。我们将其独立保存，在我们的案例中，可以从 LangGraph 的状态中访问，但也可以从文件系统中访问，原理是相同的。

你创建一个研究计划，然后卸载它，这样它就始终可被访问。接着你进行大量工作，之后可以按需将其调回，比如放在消息列表的末尾，这样智能体在执行写作阶段等任务时，就能方便地获取。如你所见，我们利用卸载来引导研究和写作阶段。我们还使用缩减技术，来摘要那些消耗大量 Token 的搜索工具调用的观察结果，这在研究阶段内部完成。最后，我们在研究阶段内部，通过子智能体实现了上下文隔离。

上下文工程主题总结

Lance: 这大致总结了在不同项目中我们看到的各种思路。接下来，Pete 将专门介绍 Manus 的情况以及他们学到的一些经验。我这里只是做个铺垫。这张幻灯片总结了我刚才提到的不同主题：卸载、缩减、检索、隔离、缓存，以及一些热门项目和它们的应用场景。

我会把这些带有链接的幻灯片分享到笔记中。现在我想把时间交给 Pete，确保他有足够的时间进行展示和回答问题。我的铺垫就到这里，Pete，交给你了。我停止共享屏幕。

Manus 关于上下文工程的最新经验

Pete: 好的，你能看到我的幻灯片吗？

Lance: 可以。

Pete: 很好。谢谢 Lance。今天非常高兴能在这里分享我们从构建 Manus 中学到的关于上下文工程的最新经验。我之所以说“最新”，是因为我意识到你提到的那篇关于上下文工程的博客是我在七月份写的。而今年是智能体之年，七月基本上已是“上古时代”了。当然，在这次分享前，我回去又读了一遍，幸运的是，我认为当时写的大部分内容今天依然成立。但我不想浪费大家的时间，只是重复博客里已经有的东西。

所以今天，我想深入探讨一些我之前没有深入或完全没有触及的领域。实际上，我们会聚焦于 Lance 之前幻灯片中“不推荐”的那一列，因为我个人认为，探索那些非共识的想法往往能带来最大的启发。

今天分享的主题包括：首先，我们会探讨一个更宏大的问题，即为什么我们需要上下文工程。然后，我们会更多地讨论上下文缩减、上下文隔离，以及最后，一些我们 Manus 内部正在测试的关于上下文卸载的新东西。今天我分享的所有内容都已经在 Manus 的生产环境中经过了实战检验，但我不知道它们能持续多久，因为技术变化实在太快了。

为什么上下文工程至关重要

Pete: 好的，让我们从第一个大问题开始：为什么我们甚至需要上下文工程？尤其是在今天，模型的微调 (fine-tuning) 或后训练 (post-training) 已经变得越来越容易。例如，Thinking Machine 团队刚刚发布了 Tinker API，我非常喜欢它的设计。但对我来说，“为什么需要上下文工程”这个问题，是经历了几个痛苦的认知阶段才得出的答案。

在创办 Manus 之前，我已经在自然语言处理 (NLP) 领域工作了超过十年，那时的我们称之为构建语言模型，但这都是在 ChatGPT 之前。Manus 是我的第二还是第三家公司了。在我之前的创业公司，我们从零开始训练自己的语言模型，用于开放域信息抽取 (open domain information extraction)、构建知识图谱和语义搜索引擎。

那段经历非常痛苦。我们产品的创新速度完全受限于模型的迭代速度。即使当时模型比现在小得多，一个完整的训练加评估周期也可能需要一到两周。最糟糕的是，当时我们还没有找到产品市场契合点 (PMF)，却花费所有时间去提升那些可能对产品根本不重要的基准测试分数。

因此，我认为初创公司不应急于构建专门化的模型，而应尽可能长时间地依赖通用模型和上下文工程。当然，现在这可能已经是一种共识了。但随着你的产品成熟和开源基础模型的日益强大，你很可能会想：“我是不是应该选一个强大的基础模型，用我的数据进行微调，让它在我的应用场景下表现得特别好？”我们也尝试过，结果发现那是另一个陷阱。

要让强化学习 (RL) 效果好，你通常需要固定一个行为空间 (action space)，围绕当前产品行为设计奖励函数，并生成大量的同策略部署 (on-policy rollouts) 和反馈。但这同样危险，因为我们仍处于 AI 和智能体的早期阶段，一切都可能在一夜之间发生颠覆。对我们来说，一个典型的例子就是 MCP (Manus Code Playground) 的推出，它彻底改变了 Manus 的设计，从一个紧凑的静态行为空间，变成了一个几乎可以无限扩展的东西。如果你训练过自己的模型，就会知道这种开放域问题是极难优化的。

当然，你可以投入巨大努力进行后训练以确保泛化能力，但那样一来，你岂不是在试图成为一家大语言模型公司吗？因为你基本上是在重复构建他们已经建好的那一层，这是在重复劳动。

所以，经过这么多铺垫，我的观点是：坚定地划清界限。目前，上下文工程是应用和模型之间最清晰、最实用的边界。请相信你的选择。

上下文缩减：压缩与摘要

Pete: 好了，哲学讲得够多了，让我们来谈谈真正的技术。第一个主题是上下文缩减 (context reduction)。在这里，我想澄清两种不同的压缩操作，因为我们认为上下文缩减这个概念虽然引人入胜，但也比较新，实现方式有很多种。在 Manus，我们将其分为压缩 (compaction) 和摘要 (summarization)。

对于压缩，在 Manus 中，每一次工具调用和工具结果实际上都有两种格式：完整格式和紧凑格式。紧凑版本会剥离任何可以从文件系统或外部状态中重建的信息。例如，假设你有一个向文件写入的工具，它可能有两个字段：路径 (path) 和内容 (content)。一旦工具执行完毕，你可以确保该文件已经存在于环境中。因此，在紧凑格式中，我们可以安全地去掉超长的内容字段，只保留路径。如果你的智能体足够聪明，当它需要再次读取该文件时，只需通过路径即可检索。

这样一来，没有任何信息真正丢失，只是被外部化了。我们认为这种可逆性 (reversibility) 至关重要，因为智能体需要基于之前的行为和观察进行链式预测，你永远不知道哪个过去的行为会在十步之后突然变得极其重要。这是无法预测的。所以，这是一种通过压缩实现的可逆缩减。

当然，压缩也有其极限。最终，你的上下文仍然会增长并触及上限。这时，我们会将压缩与更传统的摘要结合起来，但我们做得非常谨慎。例如，在进行摘要之前，我们可能会将上下文的关键部分卸载到文件中。有时，我们甚至会更激进，将整个摘要前的上下文转储为一个文本文件或日志文件，以便日后随时恢复。就像 Lance 刚才提到的，有些人只用 glob 和 grep，而 glob 对日志文件同样有效。如果模型足够聪明，它甚至知道如何检索那些被摘要前的上下文。

所以，这里的区别在于，压缩是可逆的，而摘要不是。两者都减少了上下文长度，但行为方式截然不同。为了让这两种方法共存，我们必须跟踪一些上下文长度的阈值。最高层是你模型的硬性上下文限制，比如现在常见的 100 万 Token。但实际上，大多数模型在远低于这个数值时就开始性能下降，通常在 200k Token 左右，你会开始看到我们所说的“上下文腐烂”(context rot)，比如重复、推理变慢、质量下降。

通过大量的评估，确定那个“腐烂前”的阈值非常重要，通常在 128k 到 200k 之间。我们将它作为触发上下文缩减的信号。每当上下文大小接近这个阈值，你就必须触发缩减，但要从压缩开始，而不是摘要。并且，压缩不意味着压缩整个历史记录。我们可能会压缩最旧的 50% 的工具调用，同时保留较新的调用记录的完整细节。这样，模型仍然有新鲜的少样本示例 (few-shot examples) 来学习如何正确使用工具。否则，在最坏的情况下，模型会模仿这种行为，输出带有缺失字段的紧凑格式，那就完全错了。

压缩之后，我们必须检查我们实际获得了多少空闲上下文。有时，就像这张图里显示的，经过多轮压缩后，增益会变得微乎其微，因为即使是紧凑格式，它仍然占用上下文。这时候，我们才会转向摘要。但同样要记住，在进行摘要时，我们总是使用完整版本的数据，而不是紧凑版本。并且，我们仍然会保留最后几次工具调用和结果的完整细节，而不是摘要它们。因为这能让模型知道它上次停在了哪里，从而更平滑地继续工作。否则，你会发现摘要之后，模型有时会改变其风格和语气。我们发现保留几个完整的工具调用和结果示例非常有帮助。

上下文隔离：通信模式与共享内存模式

Pete: 好的，我们已经讨论了缩减，现在来谈谈隔离 (isolation)。我非常同意 Cognition 在他们博客中提出的观点，他们警告不要轻易使用多智能体设置，因为当你拥有多个智能体时，它们之间的信息同步会变成一场噩梦。但这并不是一个新问题。多进程或多线程协调在计算机编程早期就是一个经典挑战，我认为我们可以借鉴一些那里的智慧。

我不知道今天在座有多少 Go 语言的开发者，但在 Go 编程语言社区，有一句来自其吉祥物 Gopher 的名言：“不要通过共享内存来通信，而要通过通信来共享内存。” 当然，这句话不完全是针对智能体的，有时甚至对智能体来说是错的。但我认为重要的是，它突出了两种截然不同的模式：“通过通信”或“通过共享内存”。

如果我们将这里的“内存”一词转换成“上下文”，这种对应关系就非常清晰了。“通过通信”更容易理解，因为它就是经典的子智能体 (sub-agent) 设置。例如，主智能体编写一个提示，然后将其发送给子智能体，而子智能体的全部上下文只包含那条指令。我们认为，如果一个任务有简短、清晰的指令，并且只关心最终输出，比如在代码库中搜索特定代码片段，那么就应该使用通信模式，保持简单。因为主智能体不关心子智能体是如何找到代码的，它只需要结果。这就像 Claude Code 通常做的那样，使用它的“任务工具”将一个独立的、明确的任务委托给某个子智能体。

但对于更复杂的场景，相比之下，“通过共享内存”意味着子智能体可以看到整个先前的上下文，包括所有的工具使用历史。但子智能体有自己的系统提示和行为空间 (action space)。例如，想象一个深度研究的场景，最终报告依赖于大量中间的搜索和笔记。在这种情况下，你应该考虑使用共享内存模式，或者用我们的术语来说，叫“通过共享上下文”。因为即使你可以将所有笔记和搜索结果存入文件，再让子智能体重新读取，你也只是在浪费延迟和上下文。如果你计算 Token 数量，这样做可能甚至会消耗更多的 Token。

所以我们认为，对于那些需要完整历史记录的场景，就应该使用共享内存模式。但要注意，共享上下文的成本较高，因为每个子智能体都需要预填充 (prefill) 一个更大的输入，这意味着你会在输入 Token 上花费更多。而且由于系统提示和行为空间不同，你无法重用 KV 缓存 (KV cache)，所以必须支付全部的代价。

上下文卸载：分层式行为空间

Pete: 最后，我们来谈谈上下文卸载 (context offloading)。当人们说卸载时，通常指的是将工作上下文的一部分移到外部文件中。但随着你的系统变得越来越复杂，特别是如果你决定有一天要集成 MCP (Manus Code Playground)，你会发现工具本身也会占用大量上下文。上下文中工具过多会导致混乱，我们称之为“上下文混淆”(context confusion)，模型可能会调用错误的工具，甚至是不存在的工具。所以我们必须找到一种方法，也能卸载工具。

目前一个常见的方法是，对工具描述进行动态的 RAG (Retrieval-Augmented Generation)，例如，根据当前任务或状态按需加载工具。但这也会带来两个问题。首先，由于工具定义位于上下文的前端，每次变动都会导致你的 KV 缓存重置。更重要的是，模型过去对那些已被移除的工具的调用记录仍然存在于上下文中，这可能会误导模型去调用无效的工具或使用无效的参数。

为了解决这个问题，我们正在 Manus 中试验一种新的分层式行为空间 (layered action space)。基本上，我们让 Manus 可以从三个不同层次的抽象中进行选择：第一层是函数调用 (function calling)，第二层是沙盒工具 (sandbox utilities)，第三层是软件包与 API (packages and API)。让我们深入了解这三个层次。

第一层：函数调用

Pete: 我们从第一层，函数调用 (function calling) 开始。这是经典的方法，大家都知道。由于有约束解码 (constraint decoding)，它的模式是安全的 (schema safe)。但我们也都知道它的缺点，例如我们提到过的会破坏缓存，以及过多的工具可能导致混淆。

所以在 Manus 中，我们目前只使用固定数量的原子函数 (atomic functions)，例如读写文件、执行 Shell 命令、在互联网和文件中搜索，以及一些浏览器操作。我们认为这些原子函数有非常清晰的边界，并且可以组合起来完成更复杂的工作流。然后，我们将其他所有东西都卸载到下一层，也就是沙盒工具。

第二层：沙盒工具

Pete: 如你所知，每个 Manus 会话都在一个完整的虚拟机沙盒 (sandbox) 中运行。它运行在我们自己定制的 Linux 系统上，这意味着 Manus 可以使用 Shell 命令来运行我们为其预装的工具。例如，我们有一些格式转换器、语音识别工具，甚至一个非常特别的 MCP 命令行工具 (MCP CLI)，这就是我们调用 MCP 的方式。我们没有将 MCP 工具注入到函数调用空间，而是在沙盒内通过命令行界面来完成所有操作。

这些工具的好处在于，你可以在不触及模型的函数调用空间的情况下增加新功能。这就像你电脑上预装的一些命令，如果你熟悉 Linux，总能知道如何找到这些新命令，甚至可以运行 --help 来了解如何使用一个新工具。

另一个好处是，对于较大的输出，它们可以直接写入文件或分页返回结果。你可以使用所有那些 Linux 工具，如 grep、cat、less、more 来即时处理这些结果。这里的权衡在于，它对处理大输出非常友好，但对于与前端进行低延迟的来回交互则不那么理想，因为你总是需要将智能体的交互过程可视化并展示给用户。所以这一点比较棘手，但我们认为它已经卸载了大量的功能。

第三层：软件包与 API

Pete: 接着我们还有最后一层，我们称之为软件包与 API (packages and APIs)。在这里，Manus 可以编写 Python 脚本来调用预授权的 API 或自定义软件包。例如，Manus 可以使用一个 3D 设计库进行建模，或者调用一个金融 API 来获取市场数据。实际上，我们已经代表用户购买了所有这些 API 并支付了费用，这包含在订阅服务中。所以，我们在 Manus 中预装了大量的 API 密钥，Manus 可以使用这些密钥来访问 API。

我认为这对于那些需要大量内存计算，但又不需要将所有数据推送到模型上下文的任务来说，是完美的解决方案。例如，想象一下你在分析一支股票全年的价格数据，你不会把所有数字都喂给模型。相反，你应该让脚本来计算，只把摘要结果放回上下文中。

而且，由于代码和 API 具有极高的可组合性 (composable)，你实际上可以在一步之内链接很多操作。例如，在一个典型的 API 调用中，你可以在一个 Python 脚本里完成获取城市名称、城市 ID、天气等所有操作。我一个朋友有一篇名为 CodeAct 的论文，很多人都在讨论，我认为那也是同样的想法，因为代码是可组合的，可以在一步内完成很多事情。

但它的缺点在于，它不是模式安全的 (schema safe)，很难对代码进行约束解码。所以我们认为，你应该为这些功能找到合适的场景。对我们来说，所有可以在编译器或解释器运行时内部处理的事情，我们都用代码来做；否则，就使用沙盒工具或函数调用。

好消息是，即使有这三个层次，从模型的角度来看，所有三个层次最终仍然通过标准的函数调用来执行。因此，接口保持了简单、对缓存友好，并且各个函数之间是正交的 (orthogonal)。因为我们提到的沙盒工具，你仍然是通过 shell 工具函数来访问的。同样，如果你使用第三方应用的 API，你也只是用文件函数来读写文件，然后用 shell 函数来执行它。所以，这并没有给模型增加额外的负担，一切仍然是模型经过训练并且已经熟悉的操作。

连接五个维度

Pete: 让我们把视野拉远，将这五个维度连接起来：卸载 (offload)、缩减 (reduce)、检索 (retrieve)、隔离 (isolate) 和缓存 (cache)。你会发现它们并非相互独立。我们可以看到，卸载和检索使得缩减更为高效，而稳定的检索则使隔离变得安全。但隔离又会减慢上下文的传递速度，降低缩减的频率。然而，更多的隔离和缩减又会影响缓存效率和输出质量。

所以，归根结底，我认为上下文工程是一门艺术与科学，它要求在多个可能相互冲突的目标之间找到完美的平衡。这真的很难。

避免上下文过度工程

Pete: 好的，在结束之前，我想留给大家最后一个想法，它可能与我刚才所说的一切都相反，那就是：请避免上下文过度工程 (context over-engineering)。回顾 Manus 上线以来的六七个月，我们所见证的最大飞跃，并非来自增加了更多花哨的上下文管理层或巧妙的检索技巧，而是来自简化，来自移除不必要的技巧，以及每一次都对模型多一点信任。每当我们简化架构，系统就会变得更快、更稳定、更智能。

因为我们认为，上下文工程的目标是让模型的工作变得更简单，而不是更难。所以，如果今天你只能从我的分享中带走一件事，我希望是：少做加法，多做理解 (build less and understand more)。

非常感谢大家，再次感谢 Lance 和 LangChain 团队的邀请。期待看到各位接下来会创造出什么。现在，把时间交还给 Lance。

问答环节：Shell 工具与沙盒

Lance: 非常精彩，谢谢你的分享。我们这里有一些很好的问题，也许我们可以开始逐一回答，如果需要的话可以回顾一下幻灯片。Pete，你的幻灯片大家可以获取吗？

Pete: 嗯，可以，我之后可以分享 PDF 版本。

Lance: 好的。那我先看看问题，也许我们从最新的开始。第一个问题：大语言模型是如何调用各种 Shell 工具的？它怎么知道哪些工具存在以及如何调用它们？也许你可以解释一下你在 Manus 中使用的多层沙盒设置。

Pete: 好的。想象一下你正在使用一台新电脑。如果你了解 Linux，可以想象所有的工具都位于 /usr/bin 目录下。我们实际上做了两件事。首先，我们在系统提示中给 Manus 一个提示，告诉它在某个特定文件夹下有很多预装的命令行工具。其次，对于最常用的那些工具，我们已经将它们注入到系统提示中，但格式非常紧凑。我们不会告诉智能体如何使用这些工具，只列出它们的名字，并告知智能体可以安全地使用 --help 标志，因为所有这些工具都是我们团队开发的，格式统一。

问答环节：索引与文件系统检索

Lance: 明白了。另外，你谈了很多关于使用文件系统的内容。你对使用索引 (indexing) 有何看法？当处理的上下文变得足够大时，你们会动态启动向量存储 (vector stores) 吗？你们如何处理这个问题？

Pete: 我认为在这个领域没有绝对的对错。但在 Manus，我们不使用索引数据库。因为目前，每个 Manus 会话的沙盒都是一个全新的环境，而用户希望交互能快一些。所以我们实际上没有时间去动态构建索引。我们更像 Claude Code，依赖于 grep 和 glob。但我认为，如果你考虑构建某种更长期的记忆，或者想集成企业知识库，那么你仍然需要依赖外部的向量索引，因为这关乎你能访问的信息量。但对于像 Manus 这样在沙盒中操作，或者像编码智能体在代码库中操作的场景，这取决于规模。

问答环节：Manus 中的长期记忆与知识

Lance: 这是一个很好的后续问题。假设我是一个用户，我有一个 Manus 账户，并且在多个会话中与它互动。你们有记忆 (memory) 的概念吗？比如 Claude 有 claude.md 文件，可以在不同会话间持久化。你们是如何处理长期记忆的？

Pete: 好的，实际上在 Manus 中，我们有一个叫做“知识”(knowledge) 的概念，它类似于一种显式记忆 (explicit memory)。例如，你每次都可以告诉 Manus：“记住，我每次要东西时，都用 Excel 格式交付。” 这条信息不会自动插入到某个记忆库中，而是会弹出一个对话框说：“这是我从我们之前的对话中学到的，你希望接受还是拒绝？”这是一种需要用户确认的显式方式。

同时，我们也在探索更自动化的方式。例如，智能体有一个很有趣的现象，与聊天机器人相比，用户更频繁地纠正智能体。一个常见的例子是，Manus 在做数据可视化时，如果使用中文、日文或韩文，经常会出现字体问题，导致渲染出的图像有错误。用户通常会说：“你应该使用支持 CJK 的字体。”对于这类问题，不同的用户会提出相同的修正。我们需要找到一种方法来利用这种集体反馈，这有点像我们所说的，通过在线学习实现自我改进的智能体，但这是一种无参数 (parameter-free) 的方式。

问答环节：适应模型与架构的演进

Lance: 还有一个问题，你在演讲结尾提到，通过删减功能获得了很大收益，这很大程度上可能是因为模型本身也在进步。随着模型能力的提升，你可以逐步移除一些脚手架 (scaffolding)。你是如何看待这个问题的？因为这是我面临的最大挑战之一：随着时间推移，模型变得更强，我可以移除一些辅助性结构。你是在一个不断上涨的基础上构建，那么你是否会每隔几个月随着新模型的发布就重新审视你的架构，并删除一些东西？你是如何应对这个问题的？

Pete: 这是个非常好的问题。实际上，从三月份上线至今，我们已经重构了 Manus 五次。我们认为不能停下来，因为模型不仅在进步，还在变化。模型的行为会随着时间而改变。一种方法是与模型提供商紧密合作。但我们内部还有另一套理论，用于评估和设计我们的智能体架构。我之前在 Twitter 上稍微提过，基本上我们不关心某个静态基准测试的性能，而是固定智能体架构，然后在不同模型之间切换。

如果你的架构从一个较弱的模型切换到一个较强的模型后能获得巨大提升，那么在某种程度上，你的架构就更具未来适应性 (future-proof)，因为明天的弱模型可能就和今天的强模型一样好。所以我们认为，在强弱模型之间切换，可以为你提供一些关于明年会发生什么的早期信号，让你有时间准备架构。在 Manus，我们通常每一两个月就会进行一次这样的审视，并经常在内部使用开源模型或提前试用专有模型，为下一个版本的发布做准备，甚至在下一个模型正式发布之前就开始了。

Lance: 这是一个很好的观察，通过切换现有的不同模型，就可以测试你的架构。这很有道理。

问答环节：数据存储格式

Lance: 关于存储数据的格式，你有什么最佳实践或考虑吗？比如 Markdown 文件、纯文本、日志文件，你有什么特别偏好吗？

Pete: 我认为关键不在于是纯文本还是 Markdown，我们总是优先考虑基于行 (line-based) 的格式。因为这样可以让模型使用 grep 或按行范围读取。此外，Markdown 有时会带来麻烦。模型被训练得非常擅长使用 Markdown，但有时，对于某些模型（我不想点名），如果你过于频繁地使用 Markdown，它可能会输出过多的项目符号。所以，我们倾向于更多地使用纯文本。

问答环节：为摘要生成提示

Lance: 明白了。关于压缩与摘要，我们来谈谈摘要。这是一个我被问过很多次的问题。你如何编写提示来生成好的摘要？正如你所说，摘要是不可逆的，如果提示不当，可能会丢失信息。我能想到的最好答案是调整提示以获得高召回率 (high recall)，但你是怎么做的呢？

Pete: 实际上，我们尝试了很多方法来优化摘要的提示，但结果发现一个简单的方法效果很好：不要使用自由形式 (free-form) 的提示让 AI 生成所有内容，而是定义一个模式 (schema)，就像一个有很多字段的表单，让 AI 去填写。例如，“这是我修改过的文件”、“这是用户的目标”、“我上次停在这里”。如果你使用这种更结构化的模式，至少输出会比较稳定，并且你可以在此基础上进行迭代。所以，不要使用自由形式的摘要。

问答环节：搜索工具输出的压缩

Lance: 明白了，这个观察很棒。使用结构化输出而不是自由形式的摘要，来强制某些信息总是被概括。这很有道理。那么对于压缩呢？我想确认一下我的理解是否正确。对于压缩，比如一个搜索工具，你得到原始的搜索输出，这会是你的原始消息。那么压缩后的结果就只是一个文件名之类的东西，对吗？

Pete: 是的。这不仅适用于工具调用，也适用于工具的结果。有趣的是，我们发现 Manus 中几乎所有的操作，只要能卸载到文件系统或外部状态，就都是可逆的。对于大多数这类任务，你已经有了一个唯一的标识符。例如，文件操作有文件路径，浏览器操作有 URL，即使是搜索操作，你也有查询本身。所以这个标识符是天然存在的。

Lance: 这是一个很好的观点，我想再强调一下，因为我经常遇到这个问题。比如，我是一个使用搜索的智能体，执行搜索后返回了一个消耗大量 Token 的结果。我不想把整个工具消息都返回给智能体。我尝试过做一些摘要或压缩，然后把摘要发回去。但你是怎么处理的呢？因为你可能希望智能体能访问所有信息以做出下一步决策，但又不希望那个巨大的上下文块一直存在于消息历史中。你是怎么做的？你可以把整个消息发回去，然后稍后移除，就像 Claude 现在做的那样。你也可以先做摘要，然后发送摘要。或者你可以发送所有内容，然后做压缩，这样之后你的消息历史里就只有一个指向文件的链接了。

Pete: 这要看具体场景。例如，对于复杂的搜索，我指的是不止一次查询，比如你有多个查询，并且想整合一些重要信息，丢弃其他部分。在这种情况下，我认为应该使用子智能体，或者我们内部称之为“智能体即工具”(agent as tool)。从主模型的角度看，它仍然是一个函数，可能叫“高级搜索”。它触发的实际上是另一个子智能体，但这个子智能体更像一个工作流，有固定的输出模式，这个结果会返回给主智能体。但对于其他更简单的搜索，比如只是搜索谷歌，我们就直接使用完整的详细格式，将其附加到上下文中，并依赖于压缩机制。但我们总是会指示模型将中间的见解或关键发现写入文件，以防压缩发生得比模型预期的早。如果你这样做得很到位，实际上通过压缩并不会丢失太多信息，因为有时那些旧的工具调用随着时间的推移已经变得无关紧要了。

问答环节：智能体间通信与“智能体即工具”

Lance: 这很有道理。我很喜欢“智能体即工具”这个想法，我们自己也经常这样做，确实非常有效。但这又引出了另一个有趣的话题，你之前也稍微提到过：智能体之间的通信。你如何解决这个问题？Cognition 的 Walden Yan 在一篇精彩的博客中提到，这是他们在 Devin 项目中遇到的一个主要问题。你是如何思考这个问题的，如何确保传输了足够的信息，但又不会像你说的，用过多的上下文预填充子智能体？

Pete: 一个月前，我们在 Manus 推出了一个名为“广泛研究”(wide research) 的功能，内部我们称之为“智能体版 MapReduce”，因为我们受到了 MapReduce 设计的启发。这对 Manus 来说很特别，因为会话背后有一个完整的虚拟机。我们从主智能体向子智能体传递信息或上下文的一种方式是共享同一个沙盒，所以文件系统是共享的，你只需要传递不同的路径即可。

我认为向子智能体发送信息并不难，更复杂的是如何从不同的智能体那里获得正确的输出。我们的做法是，每次主智能体想要生成一个新的或十个子智能体时，它必须先定义输出的模式 (schema)。在子智能体的视角中，有一个特殊的工具叫“提交结果”(submit result)，我们使用约束解码来确保子智能体提交回主智能体的内容符合主智能体定义的模式。所以你可以想象，这种 MapReduce 操作会生成一个类似电子表格的东西，而这个电子表格是受模式约束的。

问答环节：模型选择与开源模型

Lance: 这似乎是你设计 Manus 时一个反复出现的主题：你使用模式和结构化输出来进行摘要和智能体间通信，就像使用模式作为契约一样，来确保信息以结构化和完整的方式传递。非常好，这非常有帮助。我还在看其他一些有趣的问题。关于模型，你们似乎在使用 Anthropic，那你们会用开源模型吗？你们会做微调吗？你谈了很多关于 KV 缓存的内容，这可能需要用到开源模型。你是如何看待模型选择的？

Pete: 实际上，我们目前没有使用任何开源模型。这并非因为质量问题，有趣的是，是成本问题。我们通常认为开源模型可以降低成本，但如果你达到 Manus 的规模，并且构建的是一个输入远长于输出的真实智能体，那么 KV 缓存就至关重要。而分布式 KV 缓存用开源方案实现起来非常困难。如果你使用那些前沿的大语言模型提供商，他们有更坚实的基础设施来实现全球分布式的缓存。所以有时，你算一下账会发现，至少对 Manus 来说，使用这些旗舰模型有时甚至比使用开源模型更便宜。

我们现在也不仅在使用 Anthropic。对我们来说，Anthropic 的模型是处理智能体任务的最佳选择，但我们也看到了 Gemini 和 OpenAI 新模型的进步。我认为目前这些前沿实验室的发展方向并不趋同。例如，如果你做编码，当然应该用 Claude；如果你想做更多多模态的东西，应该用 Gemini；而 OpenAI 的模型在复杂数学和推理方面非常出色。所以我认为，对于像我们这样的应用公司，我们的一个优势就是不必只依赖一个模型。你可以做任务级别的路由，甚至子任务或步骤级别的路由，只要你能实现那种 KV 哈希验证。所以这对我们来说是一个优势，我们内部做了大量评估，来决定哪个子任务使用哪个模型。

Lance: 很有道理。我想澄清一个小问题，关于 KV 缓存，你们具体使用了提供商的哪些缓存管理功能？是像 Anthropic 的输入缓存 (input caching) 那样的吗？

Pete: 是的，就是那个意思。

Lance: 好的，明白了。

问答环节：工具选择与行为空间扩展

Lance: 工具选择也是个好问题。你提到你们不使用那种基于语义相似度索引工具描述并动态获取工具的方法。你们是如何处理的？多少个工具算太多？工具选择是个经典问题，你怎么看？

Pete: 首先，这取决于模型，不同模型对工具的承载能力不同。但我认为一个经验法则是，尽量不要包含超过 30 个工具。这只是我脑海中的一个随意数字。但实际上，如果你在构建像 Manus 这样的通用 AI 智能体，你会希望那些原生功能是高度原子化的。所以实际上，我们需要放入行为空间的原子功能并没有那么多。比如 Manus 现在只有 10 到 20 个原子功能，其他所有东西都在沙盒里。所以我们不需要动态地拉取东西。

Lance: 没错，我们来详细解释一下。所以你有大约 10 个工具可以被智能体直接调用。但正如你所说，智能体也可以选择比如编写并执行一个脚本，这极大地扩展了它的行为空间，而无需为每个可能的脚本都提供一个独立的工具，那太疯狂了。所以一个像“编写并运行脚本”这样的通用工具，就解决了很多问题，是这个意思吗？

Pete: 完全正确。我们之所以非常有信心地称 Manus 为通用智能体，是因为它运行在一台计算机上，而计算机是图灵完备的。计算机是人类最伟大的发明。理论上，一个智能体可以做任何一个初级实习生用电脑能做的事情。有了 Shell 工具和文本编辑器，我们认为它已经完备了，所以你可以将大量的事情卸载到沙盒中。

问答环节：工具调用与沙盒的混合模式

Lance: 好的，这很有道理。那么 Manus 是如何工作的？是所有的工具调用都是……我换个方式问。你提到了代码和代码智能体。我的理解是，模型总是会生成一个脚本，然后在代码沙盒中运行。所以每次工具调用实际上都是生成并运行一个脚本。听起来你们用的是一种混合模式，有时 Manus 可以直接调用工具，有时它会选择在沙盒中做些什么，是这样吗？

Pete: 是的，我认为这非常重要。我们曾尝试完全用代码驱动 Manus，但问题是，如果用代码，你就无法利用约束解码，事情很容易出错。但代码在某些特定场景下很有用，就像我之前在幻灯片里提到的，比如处理大量数据。你不需要把所有东西都放到工具结果里，而是可以把它放在比如 Python 的运行时内存中，只把最终结果返回给模型。所以我们认为应该采用混合的方式。

Lance: 明白了。允许直接调用一部分工具，比如十个左右，也允许一部分工具在沙盒本身运行。非常清晰，很有趣。

问答环节：规划与待办事项列表

Lance: 那么你们如何引用所有之前生成的文件呢？哦，抱歉，我们换个话题。关于规划 (planning)，我知道 Manus 有一个待办事项 (to-do) 工具，会在任务开始时生成一个待办列表。能谈谈这个吗？

Pete: 这是一个很有趣的话题。一开始，Manus 确实使用了 todo.md 这种模式。我不想说它愚蠢，但它确实浪费了大量的交互轮次。在三四月份的时候，如果你去看一些 Manus 任务的日志，会发现大概三分之一的操作都是在更新那个待办列表，这浪费了非常多的 Token。所以现在我们使用了一种更结构化的规划方式。比如，如果你用 Manus，会看到系统底部有一个规划器。在内部，它也是一种工具调用，我们用“智能体即工具”的范式实现，所以有一个独立的智能体在管理计划。因此，最新版的 Manus 已经不再使用 todo.md 了。当然，todo.md 仍然有效，也能生成不错的结果，但如果你想节省 Token，可以找到其他方法。

Lance: 明白了。所以你们有一个规划器智能体，对于子任务，更像是“智能体即工具”的调用方式。

Pete: 是的。而且有一个独立的智能体，从不同视角来审视计划，这很重要，它可以做一些外部审查。你还可以用不同的模型来做规划，比如 Claude Haiku 有时能产生一些非常有趣的见解。

问答环节：多智能体系统设计（角色分工 vs 通用执行器）

Lance: 这确实是个好点子。那我们来谈谈多智能体。你可能会有一个规划智能体，有自己的上下文窗口，它制定计划，生成一个计划对象，可能是一个文件，也可能直接调用子智能体。你是怎么考虑的？通常你推荐使用多少个不同的子智能体？

Pete: 这也取决于你的设计。但在 Manus，它并非典型的多智能体系统。我们看到很多系统按角色划分智能体，比如设计师智能体、程序员智能体、经理智能体。我们不这么做，因为我们认为这种划分源于人类公司的运作方式，而这是由人类上下文能力的局限性导致的。Manus 是一个多智能体系统，但我们不按角色划分。我们只有很少几个智能体，比如一个庞大的通用执行器智能体、一个规划器智能体、一个知识管理智能体，可能还有一些数据 API 注册智能体。

我们对增加更多子智能体非常谨慎，原因我们之前提过，通信非常困难。我们更多地将子智能体实现为“智能体即工具”的形式。

Lance: 这是个很好的观点。我经常看到这种错误，或者说不一定是错误，但人们常常将智能体拟人化，比如“我的设计师智能体”。我认为把子智能体想象成人类组织架构图是一种牵强的类比。所以对你们来说，就是一个规划器、一个知识管理器。知识管理器会做什么呢？

Pete: 它做的事情甚至更简单。就像我们提到的，Manus 有一个知识系统。知识智能体的作用就是回顾用户和智能体之间的对话，然后判断哪些内容应该被存入长期记忆。就这么简单。

Lance: 明白了。就像一个记忆管理器、一个规划器，然后你有一些子智能体，比如一个通用的执行器子智能体，可以调用所有工具或在沙盒中执行操作。保持简单，我非常喜欢这个思路。

问答环节：安全与防护

Lance: 还有个问题是关于防护 (guardrailing)。有人问到安全和防护的问题，你是怎么考虑的？我猜沙盒的好处之一就在于此，能谈谈吗？

Pete: 这是一个非常敏感的问题。如果你有一个连接到互联网的沙盒，任何事情都是危险的。所以我们在防护上投入了大量精力。至少，我们不允许信息泄露到沙盒之外。例如，如果你被提示注入 (prompt injected)，我们对出站流量有一些检查，确保像 Token 这样的东西不会离开沙盒。如果用户想从沙盒中打印一些东西，我们也有相应的移除机制，确保信息不会外泄。

但还有另一种情况，我们在 Manus 内部有一个浏览器，这非常复杂。比如，你登录某些网站时，可以选择让 Manus 持久化你的登录状态。这非常棘手，因为有时网页内容本身也可能是恶意的，可能在进行提示注入。我认为这在某种程度上超出了应用公司的能力范围，所以我们与模型提供商，如 Anthropic 和 Google，紧密合作。他们正在增加很多防护措施。目前在 Manus 中，每当你进行一些敏感操作，无论是在浏览器内还是沙盒中，Manus 都会要求手动确认。你必须接受，否则就得自己接管来完成。所以我们很难设计一个完美无缺的解决方案，这是一个循序渐进的过程。现在我们让用户更频繁地接管，但如果模型本身的防护能力增强，我们就可以做得更少。

问答环节：评估策略（用户评分、自动化测试、真人实习生）

Lance: 关于评估 (evals) 的话题，网上讨论很多。Claude Code 谈到他们做的正式评估较少，至少对代码是这样，因为代码评估基本饱和了，他们更多地进行内部试用 (dogfooding)。你对评估怎么看？它们有用吗？哪些评估真正有用？

Pete: 在 Manus 刚发布时，我们使用像 GAIA 这样的公开学术基准。但上线后发现，这与实际情况非常不符。在 GAIA 上得分高的模型，用户并不喜欢。所以现在我们有三种不同的评估方式。

首先，最重要的是，对于 Manus 中每一个完成的会话，我们都会请求用户给出一到五星的反馈。这是黄金标准，我们始终关心平均用户评分。这是第一点。第二点，我们仍然使用一些内部的、有可验证结果的自动化测试。例如，我们创建了自己带有明确答案的数据集。我们也仍然使用很多公开的学术基准，但我们还创建了一些更侧重于执行 (execution) 的数据集，因为大多数基准都更关注只读任务。我们设计了一些执行性或交易性任务，因为我们有沙盒，可以频繁地重置测试环境。这是自动化部分。

最重要的是第三点，我们有很多实习生。你必须用真人实习生来评估像网站生成或数据可视化这样的东西，因为很难设计一个好的奖励模型来判断输出在视觉上是否吸引人。这关乎品味。所以我们仍然大量依赖真人评估。

问答环节：可验证奖励的强化学习 vs 工具调用智能体

Lance: 我知道时间快到了，但我想问一个关于新兴趋势的问题：使用可验证奖励的强化学习 (reinforcement learning with verifiable rewards) 与构建工具调用智能体的对比。比如 Claude Code 非常出色，他们的优势在于他们构建了那个测试环境 (harness)，可以在其中进行强化学习，从而让模型在使用他们提供的工具时表现得非常出色。你们会做强化学习吗？或者你怎么看这个问题？因为那样的话你就得用开源模型了。

Pete: 我提到过，在创办 Manus 之前，我就是做模型训练的，做过很多年的预训练、后训练和强化学习。但我必须说，现在，如果你有足够的资源，可以尝试。但正如我之前提到的，MCP (Manus Code Playground) 是一个巨大的变数。因为如果你想支持 MCP，你就不能用固定的行为空间。如果行为空间不固定，就很难设计好的奖励函数，生成的部署和反馈也会不平衡。所以，如果你想构建一个支持 MCP 的模型，你实际上就是在自己构建一个基础模型。

我认为社区里的每个人，包括模型公司，都在为你做同样的事情。所以现在我不认为我们应该在强化学习上花费太多时间。但正如我之前提到的，我们正在探索新的方式，比如可以称之为个性化或某种在线学习，但使用无参数 (parameter-free) 的方式，例如集体反馈。

问答环节：通过相似工具名复现工具能力

Lance: 沿着这个思路，Anthropic 使用 Claude Code 对一系列工具进行了带有验证奖励的强化学习。你是否发现，通过模仿他们的测试环境，使用相似的工具名，也能解锁类似的能力？比如，他们使用了 glob、grep 等一系列操作文件系统的工具。你能在你的环境中，通过使用完全相同的工具名和描述，来有效地复现同样的功能吗？

Pete: 我知道这个问题的明确答案，但对我们来说，我们实际上尽量不使用相同的名字。因为如果你设计自己的函数，你可能对它有不同的要求，参数和输入参数也可能不同。你不想让模型感到困惑。如果模型在大量的后训练数据中学习了某些内部工具，你不想让它搞混。

Lance: 好的，明白了。我们时间到了，我想尊重你的时间，我知道你在新加坡现在时间很早。这次分享非常好，谢谢你。我们一定会提供这次的录音和幻灯片。你还有什么想补充的吗？

Pete: 我只想说，大家都去试试 Manus，我们有免费版本。

Lance: 当然。非常感谢 Pete，希望以后有机会再聊。

Pete: 谢谢邀请。

Lance: 好的，再见。

{{userData.name}}已认证