大家好，感谢参与。由于我仍遵循西海岸时间，感觉像是在早上七点开始这场对话。很高兴能和大家探讨 Claude Agent SDK。今天的议程大致如下：我们将介绍什么是 Claude Agent SDK 以及为何使用它；在众多智能体框架中，智能体与智能体框架的定义是什么；如何利用 Agent SDK 或通用方法设计智能体；最后，我将进行实时编码演示，展示如何原型化一个智能体。虽然我有 starter code，但我们的目标是充分利用两小时进行协作和问答。这并非预先录制的固定演示，而是现场思考的过程，我也不会立刻给出所有答案。我认为构建智能体循环更像是一门艺术或直觉，这种探索方式将非常有益。
在开始之前，我想做个小调查：有多少人听说过 Claude Agent SDK？好的，非常棒。那有多少人实际使用或尝试过它？看来参与度很高。接下来，我将简要概述智能体的概念。虽然大家可能见过相关介绍，但 AI 功能的演变仍在被深入理解中。回想 GPT-3 发布时，重点在于单一大语言模型（LM）功能，例如分类任务。随后，我们进入了类似工作流的阶段，比如给邮件打标签，或基于代码库索引提供 RAG 支持，甚至预测下一个要编辑的文件。这些结构化任务被称为工作流，即输入代码，输出代码。
如今，我们正迈向智能体时代。以 Claude Code 为例，它是一个典型的智能体工具。与限制其能力的传统方式不同，Claude Code 允许用户通过文本自由交流，它能执行极其广泛的操作。智能体会自主构建上下文，决定自身的行动轨迹，并以高度自主的方式工作。展望未来，智能体的自主性将越来越强。虽然它们尚不完美，但现在正是开始构建智能体的绝佳时机。我相信许多人已经尝试或使用了 Claude Code，我认为它是第一个真正的智能体，我第一次看到 AI 连续工作十到三十分钟，这正是 Claude Code 作为编码智能体的表现。
Claude Agent SDK 实际上是构建在 Claude Code 之上的。我们之所以这样做，是因为在 Anthropic 构建智能体时，我们发现反复重建相同的组件。为了让大家了解这包括什么，首先当然是模型，然后是工具集。这是最直观的第一步，即为智能体添加工具。稍后我们会展示如何从零开始构建自己的工具集，以及其中的挑战。工具不仅包括自定义工具，还可能涉及文件系统追踪，如 Claude Code 中的功能。这里有个小插曲，请问音量是否调大了？还是麦克风没拿近？谢谢，请保留一些回声。
总之，我们有工具，并在循环中运行它们，接着是提示词，包括核心智能体提示词和过渡提示词。最后，我们有文件系统。文件系统是一种上下文工程手段，我们稍后会详细讨论。通过 Claude Code，我们有一个关键洞察：上下文不仅仅指提示词，还包括工具、文件和脚本。此外，我们还推出了技能（Skills），如果大家对这部分感兴趣，我们可以进一步探讨。其他组件还包括子智能体、网络搜索、研究、压缩、钩子（Hooks）和记忆等。围绕工具集的这些组件相当繁杂，而 Claude Agent SDK 正是将这些内容打包供你使用。
现在，让我们看看应用层。为了说明为何使用 Claude Agent SDK，我想指出人们已经在 SDK 上构建智能体。许多软件智能体应用于软件可靠性、安全性、事件分诊、错误查找、网站和仪表板构建等领域，这些都非常流行。如果你正在开发此类应用，务必使用 SDK。此外，还有 MS Office 智能体，适用于各种办公任务，有很多示例。此外，还有法律、金融、医疗等领域的智能体。总之，有无数人在此基础上构建。
那么，为何选择 Claude Agent SDK？为何我们将其构建在 Claude Code 之上？我们意识到，一旦发布 Claude Code，工程师们开始使用它，随后财务人员、数据科学家和市场营销人员也加入其中。我们意识到人们将 Claude Code 用于非编码任务。在构建非编码智能体的过程中，我们不断回归到它。稍后我们将解释为何它能胜任非编码任务，剧透一下：关键在于 Bash 工具。我们看到这是一种涌现的模式，因此决定在其之上构建我们的智能体。
这些是我们从部署 Claude Code 中学到的经验教训，我们将其融入其中。比如工具使用错误、压缩或其他类似的问题。这些东西通常需要很大的规模才能发现，你知道的，比如什么是最佳实践，我们将其融入了 Claude Agent SDK。因此，我们对构建代理的最佳方式有很多强烈的观点。我认为 Claude Agent SDK 是非常有主见的。我会讨论其中一些观点，以及为什么我们选择它们。是的，其中一个主要观点是 Bash 工具是最强大的代理工具。
那么，什么是我想描述的 Anthropic 构建代理的方式呢？我不是说你只能通过这种方式构建代理，但如果你使用我们 Agent SDK 中的有主见的堆栈，那会是什么样呢？大致上是 Unix 原语，比如 Bash 和文件系统，我们将演示如何使用 Claude Code 进行代理原型设计。我的目标真的是实时展示那是什么样的，为什么 Bash 有用？为什么文件系统有用？为什么不直接使用工具？
是的，代理……我的意思是，你也可以创建工作流。我稍后会谈到这一点。代理构建自己的上下文。思考非编码的代码生成。比如我们使用代码生成来生成文档、查询网络、进行数据分析、采取非结构化行动。所以，这点对某些人来说可能相当违反直觉。同样，在原型设计环节，我们将介绍如何使用代码生成来构建编码代理。
是的，每个代理都有一个容器或在本地托管，因为这是 Claude Code，它需要文件系统，需要 Bash，需要能够对其进行操作。因此，这是一种非常不同的架构。我今天不打算过多谈论架构，但如果人们感兴趣，我们可以在最后讨论。或者抱歉，我所说的架构是指托管架构，即如何托管代理？以及那里的最佳实践是什么？我很乐意在最后讨论这个问题。
[清嗓子] >> 是的。那么，让我暂停一下，因为我觉得我已经讲了很多。关于 Agent SDK、代理，或者你从中获得的东西，目前有什么问题吗？你能解释一下“非编码的代码生成”到底是什么意思吗？是的。嗯，这基本上是指当你要求 Claude Code 执行任务时，比如你说，要求它找到旧金山的天气，并告诉你该穿什么，对吧？
它可能会做的，是开始编写一个脚本来获取天气 API，对吧？然后开始……也许它希望它是可重用的，比如你可能经常需要做这件事，对吧？所以，它可能会获取天气 API，然后甚至动态获取你的位置，基于你的 IP 地址，然后它会……你知道，检查天气，然后可能调用一个子代理来给你建议。也许有一个 API 用于你的衣柜或衣橱，对吧？所以，这就是一个例子。
我认为对于任何单个例子，我们可以讨论你如何使用代码生成。其中很多是关于组合 API 的，这是思考它的高级方式。是的。嗯，是的，>> [清嗓子] >> 是的。工作流与代理，对于重复性任务，或者你知道的，总是相同的过程或业务流程，你仍然更喜欢构建代理而不是完全确定性的工作流吗？
是的，我们有。哦，当然，是的，是的。嗯，所以问题是关于工作流与代理的，你仍然会使用 Claude Agent SDK 用于工作流吗？是这样吗？是的。所以，嗯，我的意思是，我们基本上只是告诉你们我们在内部做什么。我们在内部做的是，我们做了很多基于 Claude Agent SDK 的 GitHub 自动化和 Slack 自动化，所以你知道，我们有一个机器人，当问题进来时对其进行分类。这相当像工作流，但我们仍然发现，为了分类问题，我们希望它能够克隆代码库，有时启动 Docker 容器并测试它等等。
所以，它最终仍然像是一个……中间有很多步骤需要相当流畅，然后在最后得到结构化输出。所以，是的。好吧，我再问一个问题，然后继续。所以，是的，在蓝色区域。是的，嗯，你能谈谈安全和护栏吗？比如，你知道，你使用 Claude Agent SDK，并且倾向于使用 Bash 作为那个……你知道的，无所通用的工具，那么防止常见攻击矢量的责任在于构建代理的人，还是模型在做这件事？
是的，所以我认为这有点像瑞士奶酪防御。哦，是的，抱歉。是的，所以问题是关于 Bash 工具的权限，对吧？或者你是如何思考权限和护栏的？当你给代理这么多权力来控制……你知道的，它在计算机上的环境时，你如何确保它是对齐的，对吧？所以我们思考这个问题的方式是，我们称之为瑞士奶酪防御，对吧？所以，每一层都有一些防御措施，我们希望它们一起阻止一切，对吧？
显然在模型层，我们在那里做了很多对齐工作。我们刚刚发表了一篇关于奖励黑客攻击的优秀论文。超级推荐你查看一下。所以，我认为 Claude 模型……我们试图使它们非常对齐，对吧？然后，还有护栏本身，对吧？所以，我们有很多权限和提示，嗯，比如我们对 Bash 工具进行 AST 传递解析，所以我们知道 Bash 工具实际上在做什么，这肯定不是你想自己构建的东西。
最后，最后一层是沙盒化，对吧？所以，比如，如果有人恶意接管了你的代理，它实际上能做什么？我们包括了一个沙盒化，你可以沙盒化网络请求，以及在文件系统之外沙盒化文件系统操作。所以，嗯，是的，最终这被称为致命三重奏，对吧？即能够在环境中执行代码，更改文件系统，以及窃取代码，对吧？我想我得到了致命的
这里有个小偏差，但核心思想是：如果它们能把你的信息泄露出去，对吧？这意味着它们仍然需要能够提取信息。因此，如果将网络沙盒化，这是一种很好的做法。如果你使用沙盒容器进行托管，比如 Cloudflare、Modal，或者 AWS、DigitalOcean 等，这些沙盒提供商都在安全方面做了一定程度的工作，对吧？所以，你不是在自己的个人电脑上托管，也不是在有广泛敏感信息的电脑上托管。因此，这里有多种不同的安全层级。我们可以深入讨论托管问题。
接下来，我想简单谈谈 Bash，以及“Bash 即一切”的理念。这是我的执念，我会一直说下去，直到大家同意为止。这是我在 Anthropic 发现的一点，也是我来这里后逐渐领悟到的。Bash 让 Claude Code 变得如此出色。我想你们可能见过代码模式或程序化工具调用，比如不同的 API 组合方式。Cloudflare 和一些博客文章对此有过介绍。我认为代码模式或 Bash 就像是第一种代码模式。
Bash 工具允许你将工具调用的结果存储到文件中，存储内存，动态生成脚本并调用它们，组合功能如 tail、grep。它还让你使用现有的软件，比如 FFmpeg 或 LibreOffice。Bash 工具能做很多有趣且强大的事情。回想一下 Claude Code 为什么好。如果你在设计一个智能体框架，你可能会设置搜索工具、代码检查工具和执行工具，即 N 个工具。每次想到新的用例，你就觉得需要一个新的工具。
相反，现在 Claude 直接使用 grep，或者它知道你的包管理器，所以它会运行类似 npm run test.ts 或 index.ts 的命令。它可以进行代码检查，找出你的代码检查方式，然后运行 npm run lint。如果你没有代码检查工具，它甚至会说：“要我为你安装 ESLint 吗？”正如我之前所说，这是第一种程序化工具调用，第一种代码模式。你可以非常通用地执行许多不同的操作。
让我们在非编码智能体的背景下谈谈这一点。假设我们有一个邮件智能体，用户问：“我这周在打车上的花费是多少？”它通常有能力搜索你的收件箱。它可以运行查询，比如“搜索 Uber 或 Lyft”。如果没有 Bash，它搜索 Uber 或 Lyft，得到 100 封邮件，然后它必须思考如何处理。这就像有人拿着一叠纸问你：“我这周打车花了多少钱？能帮我读读邮件吗？”这很难做到，需要极高的精确度和召回率。
但如果有 Bash，比如有一个 Gmail 搜索脚本，它接受查询函数，你可以将该查询函数保存到文件或管道处理。你可以用 grep 筛选价格，将它们相加，还可以检查工作。你可以说：“让我用 grep 找出所有价格，将它们带行号存储在文件中，然后事后检查这些是否真的是价格，每个价格对应什么？”使用 Bash 工具，你可以做更多动态信息处理来检查工作。
这是一个简单的例子，但希望展示了 Bash 的可组合性力量。我就说这么多。关于“Bash 即一切”或 Bash 工具有什么问题吗？我可以解释得更清楚吗？有人知道 YOLO 模式的使用统计数据吗？我想我们有。内部可能没有，但这只是因为我们采取更高的安全姿态。我不确定，我可以查一下。关于 Bash 还有其他问题吗？好的。
为了给你更多例子，假设你有一个邮件 API，想通过它获取“告诉我这周谁给我发了邮件”。你有两个 API：收件箱 API 和联系人 API。你可以通过 Bash 实现，也可以通过代码生成实现。这本质上就是代码生成，Bash 是一个代码生成工具。再比如，假设你有一个视频会议智能体，想找出“在财报电话会议中，演讲者提到季度业绩的所有时刻”。你可以使用 FFmpeg 切片视频，然后用 JQ 分析信息。
Bash 有很多强大的使用方式。接下来我要谈谈工作流和智能体。Agent SDK 都可以构建。智能体就像 Claude Code。如果你想用自然语言交互并灵活采取行动，那就是在构建智能体。比如，有一个智能体与你的业务数据交互，提供见解、仪表板、回答问题或编写代码。这就是智能体。而工作流则像 GitHub Actions，你紧密定义输入和输出，比如“接收一个 PR 并给我代码审查”。
你可以使用 Agent SDK 构建两者。你可以使用结构化输出，我们刚刚发布了这个功能。你可以两者都做。我主要谈论智能体，但许多学到的东西也适用于工作流。现在，举手示意一下。
之前有人设计过智能体循环吗？好的，酷。太好了。所以，我的意思是，我认为设计智能体循环时最重要的元学习经验，就是反复阅读转录文本。每次看到智能体运行时，都要阅读并思考：“它在做什么？为什么这么做？我能否以某种方式帮助它？”对吧？我们稍后会做这方面的练习，对吧？所以，我们将构建一个智能体循环。智能体循环包含三个部分：首先是收集上下文，其次是采取行动，最后是验证工作。这并非构建智能体的唯一方式，但我认为这是一种很好的思考框架。
收集上下文就像在 Claude Code 中通过 grep 查找所需文件，或者在邮件智能体中查找相关邮件。思考智能体如何找到这些上下文非常重要，很多人往往跳过或低估这一步，但这至关重要。接着是采取行动，即智能体如何完成工作。它是否拥有正确的工具？代码生成、Bash 等都是更灵活的行动方式。验证是另一个非常关键的步骤。如果你正在考虑构建智能体，请思考：你能否验证其工作？如果能，它就是智能体的绝佳候选者。
如果你能验证其工作，那就很好。例如，代码可以通过 linting 验证，至少确保它能编译。但如果是深度研究，验证工作就难得多。一种方法是通过引用来源，这是验证的一步。显然，研究在某种程度上比代码更难验证，因为代码有编译步骤，你可以执行它并查看结果。我认为，随着我们构建智能体，那些最接近通用智能体的，是拥有强大验证步骤的智能体。
有人问，你何时生成需要执行的工作计划？抱歉，刚才的问题是你何时在运行前生成计划？在 Claude Code 中，你并不总是生成计划，但如果想要，可以将其插入在“收集上下文”和“采取行动”之间。计划有助于智能体逐步思考，但会增加延迟，因此存在权衡。Agent SDK 也支持规划功能。
有人问，能否让智能体创建待办事项列表，并 100% 确定它会创建并执行？是的，如果你使用 Agent SDK，我们提供了一些待办事项工具，它会维护并勾选待办事项，你可以随时查看。还有其他问题吗？好的，接下来我简要介绍如何实现这些功能，即你使用什么工具。主要有三种：工具、Bash 和代码生成。
传统上，许多人只关注工具。我的行动号召是更广泛地思考。工具结构极其严谨且可靠，若追求最快输出、最少错误和重试，工具是最佳选择。缺点是上下文占用高。如果你构建了拥有 50 或 100 个工具的智能体，它们会占用大量上下文，导致模型困惑。工具缺乏可发现性，且不可组合。这里说的工具是指使用消息或完成 API 的方式。当然，也有代码模式和程序化工具调用，可以混合使用。
其次是 Bash。Bash 高度可组合，静态脚本，上下文占用低。但发现时间稍长。例如，如果你有 Playwright CLI 这样的 Bash 工具，你可以运行 playwright help 来了解所有功能，但智能体每次都需要这样做。它需要发现自己能做什么，这有助于降低高上下文占用，但增加了延迟。调用率可能略低，因为它需要时间查找工具，但这会随时间改善。
最后是代码生成。高度可组合，动态脚本。执行时间最长，需要 linting 甚至编译。API 设计在此变得非常关键，我稍后会详细讨论如何在智能体中进行 API 设计。这三种是你拥有的工具。使用工具时，仍需要工具，但应将其视为智能体通常需按顺序执行的原子操作，你需要对其有严格控制。
例如，在 Claude Code 中，我们不使用 Bash 写入文件，而是使用“写入文件”工具，因为我们要让用户查看输出并批准，且不将其与其他操作组合，这是一个原子操作。发送邮件也是例子。任何非破坏性或不可逆的更改都适合使用工具。然后是 Bash，例如搜索文件夹、使用 GitHub、代码 linting 和检查错误或内存等可组合操作。你可以将文件写入内存，Bash 即可作为你的内存系统。
最后是代码生成。如果你试图执行高度动态、非常灵活的逻辑，代码生成是最佳选择。
组合 API，就像你正在做数据分析或深度研究，或者复用模式。所以，是的，我们稍后会更多地讨论代码生成。到目前为止，关于 SDK 循环、工具与 Bash 以及代码生成，大家有什么问题吗？是的。是的，我本来想问……[清嗓子]……你们是否会提供现成的工具，用于上传工具调用结果？[轻笑]
上传工具调用结果，比如上传到文件系统？……就像，假设它进入了 Bash，然后上下文爆炸了。嗯。是不是像……[清嗓子]……输入一个命令，现在就能完成所有操作？好吧。或者，否则，只是长输出会保留在你的历史记录中。当然，是的。是的。是的。我不认为总是上传文件。是的。是的。我认为这是一个很好的常见做法。我记得最近在一些关于 Claude Code 的 PR 中看到过关于处理非常长输出的讨论。我不太确定。我想我们正在走向一个越来越多的东西被存储在文件系统中的地方。这是一个很好的例子。是的，比如它随时间存储长输出。我认为通常提示代理执行此操作是一种很好的思考方式。
或者，即使你有，我想我现在总是做的一件事是，每当我进行工具调用时，我都会将工具调用的结果保存到文件系统中，这样你就可以搜索它，然后让工具调用返回结果的路径。因为这有助于它重新检查自己的工作。所以，嗯，是的。嗯，你觉得需要使用……[清嗓子]……技能构建来帮助 Claude 更好地使用 Bash，还是开箱即用就不需要了？是的，所以问题是关于技能，以及我们是否需要技能来更好地使用 Bash。嗯，是的，为了上下文，技能。好的，是的。技能基本上是一种允许我们的代理处理更复杂的任务，并通过上下文加载内容的方式，对吧？
比如，我们有一堆 docx 技能。这些 docx 技能告诉它如何进行代码生成以生成这些文件，对吧？所以，是的，我认为总体而言，技能基本上就是一组文件。它们也类似于非常依赖文件系统或 Bash 工具构建的例子，对吧？因为它们只是你的代理可以 CD 进去并阅读的文件夹，对吧？所以，是的，我们发现技能非常有用的是那些需要大量专业知识的可重复指令。比如，我们最近发布了前端设计技能，我很喜欢。它实际上就是一个非常详细且良好的关于如何进行前端设计的提示。
但它来自我们最好的……你知道……AI 前端工程师，你明白我的意思吗？他确实投入了大量的深思熟虑和迭代。所以这是一种使用技能的方式。嗯，是的。快速提问。是的。
所以问题是关于 skill.md 和 claude.md 的区别，以及如何思考这一点，对吧？我想说，所有这些概念都非常新。你明白我的意思吗？即使 Claude Code 也是大约八九个月前发布的，对吧？而技能是两周前才发布的。我不会假装知道所有方面的最佳实践，对吧？我认为一般来说，技能是一种渐进式上下文披露的形式。这是我们讨论过很多的一种模式，对吧？就像 Bash 一样，你知道，更喜欢它而不是纯粹的正常工具调用。这是一种让代理心想：“好的，我需要做这个。让我找出怎么做。”然后让我读取 skill.md 的方式，对吧？
你让它制作一个 docx 文件，然后它 CD 进入目录，读取如何做，编写一些脚本并继续执行。所以，是的，我认为关于到底如何定义技能以及如何拆分它，仍然需要建立一些直觉。但是的，我认为那里仍然有很多最佳实践需要学习。是的。所以昨天讨论了……[清嗓子]……技能的未来。你认为这些最终会成为模型的一部分，还是有些技能只是填补空白的过渡方案？是的，所以问题是技能最终是否是模型的一部分？它们是填补空白的方案吗？我错过了巴里的演讲，巴里昨天提到了演讲，但是的，我认为大致思路是，模型将越来越擅长处理各种任务，而技能是赋予它分布外任务的最佳方式，对吧？但……[清嗓子]……我会广泛地说，特别是如果你不在实验室，很难确切地知道模型将走向何方。
我的一般经验法则是，我尝试每六个月重新思考或重写我的代理代码，因为事情可能已经发生了足够大的变化，我已经在这里固化了一些假设。所以，我认为我们的代理 SDK 旨在尽可能随着能力的进步而发展，对吧？Bash 工具会越来越好。我们是在 Claude Code 之上构建的。所以随着 Claude Code 的演变，你将立即获得这些优势。但同时，你知道，现在与一年前相比，AI 工程方面已经截然不同了，对吧？我认为对我而言，一般最佳实践是：“嘿，我们可以快 10 倍地编写代码。你也应该快 10 倍地抛弃代码。”我认为不要过度押注于未来在哪里，而是思考今天什么真正有效，对吧？让我们今天获得市场份额，不要害怕以后抛弃代码。
如果你是初创公司，这可以说是你相对于竞争对手的最大优势。他们……你知道……大型公司……[轻笑]……有六个月的孵化周期。所以他们总是被困在代理能力的过去中，对吧？所以你的优势在于你可以说：“嘿，代理能力就在那里。让我现在就构建使用它的一些东西。”对吧？所以，嗯，是的。关于技能和 Bash，还有其他问题吗？好的，看来有很多关于技能的问题。所以，嗯，是的，后排有人可能需要喊一下。是的，那么为什么使用技能而不是 API？它们看起来与那里的 Python 程序非常相似，可以是一个包，对吧？是的，所以问题是为什么使用技能而不是 API？好问题。我认为这些基本上都是向代理揭示其需要做什么的渐进式披露形式。我会举例说明……你只有一个 API，对吧？在我们的原型制作环节中。这完全取决于用例，
对吧？就像我刚才说的，我认为没有通用的规则。我觉得应该阅读转录文本，看看你的代理想要什么。如果你的代理总是倾向于将 API 视为一个 API.ts 文件或类似的文件，那就那样做。你知道，这很好。我认为技能（Skills）就像是引导人们思考如何将文件系统作为存储上下文的一种方式，对吧？它们是一种很棒的抽象。但使用文件系统的方法有很多。嗯，我还得说一下，关于技能的一点是，你需要 bash 工具、虚拟文件系统等。所以，目前代理 SDK 基本上是唯一能真正充分利用技能的方式。是的。
刚才那位朋友的问题是可以期待有一个技能市场吗？是的，Claude Code 有一个插件市场，你也可以通过代理 SDK 使用它。我们正在随时间推移不断演进它。你知道，这最初更像是一个 V0 版本。说到市场，我不确定人们是否会为此收费。我认为它更多只是一个发现系统。但目前这个市场是存在的。你可以在 Claude Code 中输入 /plugins 来查找一些插件。
那么，你目前的想法是什么？在解决什么问题时会选择使用代理 SDK？嗯，问题是“我什么时候使用 SDK 来解决一个问题？”如果我基本上是在构建一个代理，我认为我的整体观点是，对于任何代理，bash 工具都提供了巨大的力量和灵活性，而使用文件系统也提供了巨大的力量和灵活性，因此你总是可以从其中榨取性能提升，对吧？所以，是的，在这场演讲的演示部分，我们将看一个仅使用工具的示例，以及一个使用 bash 和文件系统的示例，并比较这两者。这就是我所指的“基于 bash 工具构建”。
我通常从代理 SDK 开始。我想 Anthropic 的许多人也开始这样做了。当然，我也想说的是，很多时候代理 SDK 有点烦人，因为你有一个网络沙箱容器，你会想：“我讨厌这样，我不想这样做。”你明白我的意思吗？我想在本地浏览器上运行，对吧？我完全理解。我认为这确实存在性能上的权衡。我这样想它，有点像 React 与 jQuery 的对比。你知道，当我刚开始时，我非常热衷于 Web 开发，使用 jQuery 和 Backbone，然后 React 出来了，由 Facebook 推出，他们说：“你必须用这个。这是 JSX，我们刚发明的，现在有了打包器，对吧？”我当时觉得太烦人了。
但一般来说，它让模型或让 Web 应用变得更强大，对吧？我认为代理 SDK 对我来说就像代理框架中的 React，因为我们在其之上构建自己的东西，所以你知道它是真实的，而且它所有烦人的部分只是让我们感到烦恼的地方，但我们觉得它“就是能工作”。你必须这样做，你知道的。嗯，好的，更多关于技能的问题，我想是吧。是的，就在这里。我想谈谈风格。>> Bash 问题，太棒了。我爱 bash。是的，自定义内部 bash 工具。>> 是的。你如何发现它们？还是说你必须精通工具？
这个问题是，如果你有自定义的代理 bash 工具，你如何让代理发现它们？自定义 bash 工具是指 bash 脚本吗？>> 是的，bash 脚本，没错。是的。嗯，所以我认为，嗯，在哪里呢？你只需要把它放在文件系统中，然后告诉它，嘿，这里有一个脚本。你可以调用它。我的意思是，通常在云代理 SDK 的语境下思考，其中文件系统和 bash 工具是绑定在一起的。我有时看到一种反模式，人们说：“哦，我们要在虚拟化的地方托管 bash 工具，它不会与代理循环的其他部分交互。”你知道，这有点让人困惑，因为如果工具结果正在保存一个文件，那么你的 bash 工具就无法读取它，除非所有内容都在一个容器中。但这回答你的问题了吗？嗯，某种程度上。我的意思是，你只是说把它放在系统提示中之类的吗？
是的，只需放入系统提示中，并说：“嘿，你可以访问这个。”我希望将所有 CLI 脚本设计为带有 -help 之类的选项，这样模型就可以调用它，然后它可以渐进地披露脚本中的每个子命令。是的，就像那样。是的。所以，我的问题是关于何时使用代理 SDK。那么，你是否设计过，或者你建议某人使用代理 SDK 来构建一个通用的聊天代理吗？让他去说，哦，你知道，我正在构建一个代理，你有一些输入，代理去做一些事情，最后我在意的是输出。让他回去说，比如某人，你是使用还是预计使用代理来构建代理 SDK 来构建 Claude 应用，而不是 Claude Code？
是的，所以问题是“我们什么时候使用代理 SDK？”嗯，我们会使用代理 SDK 来构建 Claude.ai 吗？那是更传统的聊天机器人，而不是 Claude Code？嗯，我认为 Claude Code 的界面不是传统的聊天机器人界面，但输入和输出是分开的，对吧？你输入代码，你得到文本输出，或者你输入文本，你得到文本输出，并在过程中采取行动。你可能已经看到，当我们为 Claude.ai 推出文档创建功能时，它现在能够启动文件系统，并通过生成代码来创建电子表格、PowerPoint 文件等。所以，我们正在努力合并我们的代理循环等，但 broadly 来说，是的，Claude.ai 正变得越来越多地像你所看到的技能、记忆工具等，越来越多地基于文件系统构建。
所以，我们认为这是一个你可以广泛使用的通用功能，并且已经讨论过。嗯，还有一个问题，然后我们就继续下一个。嗯，仍在试图理解构建工具或使用工具的规则，何时用脚本包装东西，还是只让代理……
在 Bash 中随意发挥吧。因为我会举个例子。假设我需要不时访问数据库。我可以使用 SCP，将其封装在脚本中，然后让代理直接从 Bash 调用该端点，对吧？是的，很好的问题，很好的问题。所以，还在努力理解何时使用工具、何时使用 Bash、何时使用代码生成。他举了个例子，比如，好的，我有一个数据库。嗯，我希望代理能够以某种方式访问它，我该怎么做？我应该创建一个以某种方式查询数据库的工具吗？嗯，我应该使用 Bash 吗？我应该使用代码生成吗，对吧？这些都是三种实现方式。嗯，我认为你可以使用其中任何一种，而且我认为这部分……嗯，我认为不幸的是，没有单一的“最佳实践”，对吧？这更像是一个系统设计问题。
但假设你想通过工具访问你的数据库，如果数据库非常结构化，且你必须非常谨慎，比如你在访问用户敏感信息之类的东西，并且你想说，“嘿，我只能接受这个输入，我需要输出这个结果，并且我必须向代理屏蔽数据库的其他所有内容”，对吧？显然，这限制了代理能做的事情，对吧？比如它不能编写非常动态的查询。嗯，如果你编写完整的 SQL 查询，我肯定会使用 Bash 或代码生成，只是因为当模型编写 SQL 查询时，它可能会出错，而它修正错误的方式是通过 linting 或运行文件，查看输出，看看是否有错误，然后迭代修正，对吧？
因此，一般来说，如果我在今天构建代理，我会给它尽可能多的数据库访问权限，然后设置护栏。比如，我可能会以不同方式限制其写入权限，但我可能会做的是，给它写入权限并制定具体规则，然后如果它尝试做它不能做的事情，就给它反馈，你明白我的意思吗？所以我知道这有点难，但我认为这是我们面临的这类问题。比如，我们构建了一个 Bash 工具解析器，嗯，这是一个非常令人头疼的问题，但我们需要解决这个问题，以便让代理能够通用地工作，对吧？
同样的道理也适用于数据库。是的，很难理解查询在做什么，但如果你能解决这个问题，随着时间的推移，你可以让代理更通用地工作。所以，嗯，是的，我认为尽可能灵活地思考，并将工具保持为非常原子的操作，即那些需要大量保证的操作。嗯，是的，还有一个问题。同样的问题，你如何确保基于角色的访问控制得到处理？你如何……所以问题是，你如何确保基于角色的访问控制得到处理？通常，这取决于你如何配置 API 密钥或后端服务等。比如，我认为我通常会创建临时的 API 密钥。有时人们会在中间创建代理来插入 API 密钥，以防担心数据外泄。
但嗯，是的，我会为代理创建以特定方式限制范围的 API 密钥，这样在后端，你可以检查它试图做什么，以及如果是代理，你可以给它不同的反馈，所以是的。好吧，是的，还有一个问题。嗯，你能告诉我们更多关于记忆工具、内部记忆工具的信息吗？嗯，我不是想保守秘密。我不确定，比如我没读过代码，但我认为它通常在文件系统上工作。它是暴露给代理 SDK 的吗，还是已经内置了？嗯，我会说，我们经常收到这个问题。我只会在云代理 SDK 中使用文件系统。我会创建一个类似“记忆”的文件夹，并告诉它在那里写入记忆。嗯，我不知道记忆工具的具体实现，但它确实以这种方式使用了文件系统，所以是的。
嗯，好吧，是的，是的，最后一个关于这个问题的问题。你如何管理 Bash 和代码的可重用性？假设同一个代理被部署给数百个用户，每次生成相同的代码，每次执行相同的代码，那么我们如何利用可重用性？是的，这是一个非常好的问题。所以，嗯，是的，假设你有两个代理与两个不同的人交互。问题在于，你如何看待代理之间的可重用性，或者代理如何通信，对吧？嗯，我认为这是一个需要探索的领域。我认为还有很多最佳实践和系统设计要做，因为传统上，Web 应用是将一个应用服务于百万用户，对吧？而在代理方面，比如使用 Claude Code，我们提供一对一的容器。
当你在 Web 上使用 Claude Code 时，那是你的容器，对吧？因此，容器之间没有太多的通信。这是一个非常不同的范式。我不会说我知道确切的最佳系统设计，对吧？而且我认为还有很多最佳实践，比如，这些代理在重用工作，我们如何给它们通用的脚本来结合它们完成的工作，我们如何让它们共享这些工作？嗯，我通常认为这是一个关于代理通信框架的旁支话题。我会说，我们可能不需要……嗯，我认为这更多是个人意见。我认为我们可能不需要发明新的通信系统。代理擅长使用我们现有的东西，比如 HTTP 请求、哈希工具、API 密钥、命名管道等等。
因此，代理可能只是彼此之间通过 HTTP 服务器进行 HTTP 请求。那里有很多有趣的工作。我看到有人为他们的代理创建虚拟论坛，他们发布主题，然后回复之类的。嗯，挺酷的。我认为那里有很多东西可以探索和发现。是的。好的。嗯，继续。我们时间过得怎么样？好的，我想还有一个小时。好的。嗯，酷。所以，设计代理的一个例子。嗯，这不是原型设计阶段，但我认为这……
这就像我们会深入探讨的那样。假设我们正在开发一个电子表格智能体。搜索电子表格的最佳方式是什么？执行代码的最佳方式是什么？在电子表格中采取行动的 best way 是什么？链接电子表格的最佳方式又是什么？这些都是非常有趣的课题。接下来我会演示 Figma 的部分，我们可以一起过一遍。如果有人能帮我拿瓶水，那就太好了，我现在真的需要喝水。好的，谢谢。
那么，我们来讨论一下。或者，我想让你们花几分钟时间自己思考这个问题。你有一个电子表格智能体，你希望它能够搜索、收集上下文、采取行动并验证其工作成果。你会如何思考这个问题？所以，花点时间思考一下，做些笔记什么的。
大家好都花了一点时间思考这个问题吗？有人想要更多时间，还是直接深入讨论？好的。那么，智能体搜索电子表格的最佳方式是什么？我得一只手打字，有点不方便。我得解决这个问题，因为后面我还要打字。好的，搜索电子表格。有什么想法吗？怎么搜索电子表格？你会怎么做？CSV。好的，你有一个 CSV 文件。现在，你的智能体想要搜索这个 CSV 文件。它会怎么做？它抓取文件。好的。grep 的样子是什么样的？你只是查看所有标题。查看标题。好的，所有工作表的标题。很好。
假设我在查找 2024 年的收入之类的东西。现在我有了标题，我就直接调出一个电子表格。假设里面有一列是收入，还有一列是年份，比如 2026 年。这有点像表格问题，对吧？这里有收入，那里有 2026 年。这是多维数据。如果我们只看标题，然后提取数据，你会得到 100、200、300 这样的数字。我们需要更多一点的信息。还有其他想法吗？
有一个 bash 工具，awk。Awk？好的。是的。那 awk 会查找什么？这取决于你在找什么。是的，这就是问题所在，用户在找什么？他们可能在找类似 2026 年收入这样的数据。也许使用 API，利用 Google 工具将所有数字相加，或者使用 VLOOKUP 之类的函数。是的，想法是使用 API，比如使用 Google API 来查找。这很棒。
但是，假设我们是在本地工作。我们需要设计这些 API，对吧？SQLite 可以直接解释 CSV。这也行。哦，很有趣。好的，是的，我之前不知道。这很棒。所以，你可以使用 SQLite 来查询 CSV。这是一种非常有创意的思考 API 接口的方式。如果你能把某样东西转换成智能体非常熟悉的接口，那就太好了。如果你有数据源，能将其转换为 SQL 查询，那么你的智能体就很擅长搜索 SQL。思考这种转换过程非常有趣，这是设计智能体搜索接口的好方法。
刚才提到工具，因为你可以用 CSV 来做这些事。在这个工具中是否有排名？Claude 足够聪明，能为合适的任务选择正确的工具吗？这正是我们要讨论的，正确的工具用于正确的任务。Claude 足够聪明，能为正确的任务选择正确的工具吗？是的，如果你提示它的话。或者，我认为这是那种我们需要验证的事情。让我们看看转录内容。如果它不够聪明，我们该如何帮助它？我觉得所有这些都需要一种直觉，就像骑马一样。虽然我从未骑过马，但我想象那就像是在给马发出信号，安抚它，试图找到如何让它跑得更快。这是一种非常有机的东西。
我们常说模型是“生长”出来的，而不是“设计”出来的。所以我们在理解它们的能力。是的，它们在哪里，以及处于什么状态。快速提问：有没有办法给电子表格添加元数据？你能在不同的文档中给出描述吗？是的，比如 KPI。我想了解如何为电子表格构建智能响应问题。所以，这是另一个很好的模式：能否给电子表格添加元数据？在思考搜索之前，你需要考虑一些预处理步骤，以使搜索效果更好。
例如，你可以将其转换为 SQL 格式或其他可查询的格式，这是一个转换步骤。另一步骤是，也许你有一个工具或预处理步骤，由另一个智能体注释电子表格并添加信息，以便智能体能更好地基于这些信息进行搜索。是的。还有一个问题。我只是好奇，所有这些工具听起来都很好，但为什么智能体不能简单地按照建议的那样，读取标题然后获取数据呢？我觉得这应该相当简单。或者读取任务。是的，我可能应该用代码准备好这个，对吧？但我以前构建过很多电子表格智能体。基本上，这并不简单，有点难做。
所以我通常会这样思考。Sean，你有什么建议，让我能一边编程一边说话吗？在你的电脑上安装语音转文字。哦，我明白了。是的，把你的麦克风夹在衬衫上。背面有一个麦克风按钮。我觉得我不信任那些东西，伙计。好吧。让我们看看。那是搜索。一种方法是在电子表格中设计公式，比如 B3 到……
好的。所以，这是代理非常熟悉的语法示例，对吧？从 B3 到 B5，对吧？因此，你可以设计一个类似这样的代理搜索界面，比如 B3 到 B5 之类的。所以，你的代理搜索界面可以接受一个范围，对吧？你可以接受一个范围字符串，对吧？这些都是像……它非常熟悉的东西，对吧？
比如，你可以进行 SQL 查询，对吧？代理对 SQL 查询非常熟悉，对吧。嗯，而且……你也可以做 XML，对吧？抱歉，字体太小了。嗯，好的。嗯，是的，你也可以做 XML。我不确定你们是否知道，但实际上 X 文件在后台是 XML，对吧？而 XML 是非常结构化的。你可以进行 XML 搜索查询，并且有不同的库可以执行此操作。所以，这是一个例子，对吧？它是关于如何搜索和收集上下文的。我希望这能说明，收集上下文是非常有创造性的，对吧？
就像有很多迭代，如果你只尝试了一种迭代，那可能还不够，对吧？就像尽可能多地思考不同的方法。就像尝试这些，对吧？尝试 SQL，或者尝试搜索，尝试 grep 和 awk，以及所有这些工具，并且进行一些测试，看看代理喜欢什么，不喜欢什么。这取决于每种情况。抱歉。是的。你的意思是，当你说“代理”时，你指的是机器人、模型，还是因为我们在这里加载了一个代理？
是的。而且你依赖于已经存在的关于如何处理 XML 的知识。是谁在做这件事？是模型吗？是的，因为问题在于，知识来自哪里？是模型吗？还是说，我所说的“代理”是什么意思？是的，通常我认为你在寻找的是，你有一个问题，你希望它尽可能处于代理的“分布内”（in-distribution），对吧？因此，代理对很多东西都很了解。例如，它对金融非常了解，对吧？所以，如果你让它做一个 DCF（现金流折现）模型，它知道 DCF 是什么，对吧？如果你想给它更多信息，你可以创建一个技能（skill），对吧？但它知道 DCF 是什么，也知道 SQL 是什么。它能将这些东西结合起来吗？
所以，理想情况下，你的问题在某种程度上是“分布外”（out-of-distribution）的，对吧？就像有一些信息不在互联网上，或者是一些对你来说独特的东西，而你希望尝试将其调整为尽可能处于“分布内”。嗯，而且，是的，我认为这非常有创造性。你知道，对我来说，这不像是一门科学，而更像是一门艺术。哈哈。嗯，好的。所以，我们尝试了收集上下文，然后是采取行动。我们可能在这里可以做很多之前做过的事情，对吧？比如，我们可以向数组插入数据，对吧？如果你有 SQL 接口，对吧？我们可以进行 SQL 查询。我们可以编辑 XML。这些通常非常相似，对吧？
采取行动和收集上下文，你可能需要类似的 API 来回交互。最后一件事是验证工作，对吧？你是怎么思考这个问题的？检查空指针，这是其中一种方法。还有其他关于验证的想法吗？是的？抱歉，我有点困惑你在说什么。是的，是的。当你使用其他 SDK 构建代理时，我不需要告诉它如何收集上下文。我只给它上下文，并解释这基本上是什么意思，我用通俗的语言解释它应该做什么。
而我倾向于做的是，如果我错了请告诉我，我实际上会为 QA（质量保证）创建一个单独的代理来进行验证，因为我不信任代理自己验证自己。嗯哼。但我只是有点困惑，在那个例子中我需要向代理提供多少细节。好的，好的。所以，这个问题是关于向代理提供上下文与让它自己收集上下文。你提到你有时使用 QA 代理。我可以问一下你构建代理的领域是什么吗？在网络安全方面。好的，当然。是的，是的。
我认为我需要研究更多细节，但 Claude Agent SDK 非常适合网络安全，而我通常会建议人们让代理尽可能多地收集上下文。你知道，让它尽可能多地自己寻找工作。你试图给它寻找自己工作的工具。我是这样思考这个问题的，假设有人把你锁在一个房间里，他们给你一个任务，你知道，这就是你的工作。就像 MrBeast 那种场景，对吧？你得到 50 万美元，在这个房间里待 6 个月。然后有人给你一条信息，你需要什么工具才能完成它，对吧？你只是想要一份论文列表，还是想要一个计算器，或者一台电脑，对吧？我可能想要一台电脑，对吧？我想要谷歌，我想要所有这些工具，对吧？
所以，我不希望那个人发给我一堆论文说：“嘿，这大概是你需要的所有信息。”我宁愿他说：“嘿，给我一台电脑，给我这个问题，让我去搜索并弄清楚，对吧？”所以，我也是这样看待代理的。就像它们被困在一个房间里。所以，你必须给它们工具。所以，如果你能回到幻灯片，回到这些图表，你是指像这样的图表吗？是的，这个上面的。所以，基本上，收集上下文基本上就是我提供给它的这些工具。是的，完全正确。是的，你……我给你提供了一些东西，比如代码生成的 API，也许我给它一个 SQL 工具，也许我给它一个 bash。这些都是例子，对吧？所以，是的。你有一个问题吗？
问题。所以，对于你……[清嗓子]……在某种状态下的所有代理，它们共享相同的上下文窗口吗？它的大小是多少？很有趣。是的，所以代理共享上下文窗口吗？我认为这是一个关于如何管理上下文的有趣问题。我认为，虽然我没有过多谈论这一点，但子代理（sub-agents）是管理上下文的一种非常重要的方式。我认为我们在 Claude Code 内部越来越多地使用子代理，我认为你应该非常普遍地考虑使用子代理。所以，比如我们可能会为这个……
电子表格代理，也许我们有一个搜索子代理，对吧？子代理非常适合那些需要大量工作并向主代理返回答案的场景。例如，如果问题是“我如何找到2026年的收入？”，你可能需要进行一系列解析。也许你需要搜索互联网，或者搜索电子表格，诸如此类。
有很多事情不需要进入主代理的上下文。主代理只需要看到最终结果，对吧？因此，这是一个很好的子代理任务。我这里没有专门的子代理界面，但它们非常有用，我认为这是一种很好的思考方式。
为了进一步回答这个问题，以验证为例，你可以想象使用技能或子代理来完成。你甚至可能想要一个对抗性的网络安全示例。这是一个很好的例子，我还没有深入探讨，也没有与已有的工作建立任何同情关系。这是一个光谱，但你是说你会在这里使用子代理吗？你会使用技能吗？你会如何思考这个问题？
是的，绝对如此。关于子代理的问题，我不确定它是如何工作的以确保这一点。哦，当然。好的，是的，谢谢。 appreciated。嗯，好的。嗯，你可以使用子代理进行验证吗？是的。我认为这是一种模式。我认为，理想情况下，最好的验证形式是基于规则的，对吧？比如，是否存在空指针之类的东西？这种验证很容易，它不会增加长度或编译。尽可能多地插入规则。
再次强调，要发挥创意。例如，在Cloud Code中，如果代理试图写入一个我们已知它尚未读取的文件，比如我们还没有看到它进入读取缓存，我们会抛出一个错误。我们会告诉它：“嘿，你还没有读取这个文件。先试着读取它，对吧？”这是一个确定性的工具示例，我们将其插入到验证步骤中。
因此，尽可能多地思考，每当你在考虑验证时，第一步是确定你能做什么确定性的事情。当你选择代理类型时，拥有更多确定性规则的代理更好。当然，随着模型推理能力的提高，你可以使用这些子代理来检查主代理的工作。关键在于避免上下文污染。
你可能不想分叉上下文。你可能希望启动一个新的上下文会话，并告诉它：“嘿，对抗性地检查这个输出，它是由麦肯锡的初级分析师制作的，或者类似的情况。他们毕业于不太好的学校，GPA很低，等等。”给它喂一些信息，然后让它进行批评。这是子代理的工具之一。
随着模型变得越来越好，这种验证也会变得更好。但确定性地执行是一个很好的开始。是的，问题。>> [清嗓子] >> 只是关于验证工作的问题。所以 >> 是的。嗯，假设我们发现了空指针，可能很容易就说“好的，修复它”。但是，比如，我们部署到生产环境，客户正在使用它，结果他们以某种方式陷入了整个电子表格被删除的境地。
那么，我们在什么层面上需要内置撤销工具的能力呢？因为，假设QA代理返回他们的电子表格是空的。不一定能够撤销，或者类似的情况。你的建议是什么？是的，问题是，你如何思考状态以及撤销和重做，基本上就是修复错误，对吧？
我认为这是一个非常好的问题，老实说，当你思考代理擅长什么时，或者代理擅长的问题领域是什么时，工作的可逆性是一个非常好的直觉。代码是非常可逆的。你可以回去，你可以撤销git历史。我们一开始就带来了原子操作。我经常在Cloud Code中使用git。我不再输入git命令了。
这是一个很好的例子。一个很差的例子是计算机使用，[清嗓子] 你知道，因为计算机使用在状态上不可逆。比如，你去doordash.com，用户想让你点可乐，你又点了百事可乐。现在你不能回去点击可乐，你必须去购物车并移除百事可乐。你的错误被放大了，状态和状态机变得更加复杂。
因此，每当我们处理非常复杂的状态机，而你无法撤销或重做时，这就变得困难了。我认为作为工程师，你的一个问题是将此转变为可逆状态机，就像你说的，你是否可以在检查点之间存储状态，以便用户可以说：“哦，我的电子表格现在乱了，回到上一个检查点，对吧？”
甚至模型能否回到之前的检查点？我认为有人有一个时间旅行工具，他们将其提供给一个编码代理，这很酷，你可以时间旅行回到发生之前的那个点，你明白我的意思吗？这很有趣。我认为所有这些工具，其中一些目前效果不佳，但我们会到达那里的。
嗯，是的，思考状态和验证是非常有用的。嗯，是的，后面的好问题。是的，我有点好奇关于规模的问题。如果电子表格有数百万行，成千上万列，或者它只是任何类型的数据库，那该怎么办？在这种情况下，你会如何搜索？显然有上下文窗口。你有上下文窗口。是的，这很好。
我可能应该把电子表格示例作为我的编码示例。预览一下，我的编码代理是一个宝可梦代理。嗯，电子表格可能会更好。好的。问题是，如果电子表格非常大怎么办？如果你有百万行。
行，呃，你怎么看待一百列，比如一百？对，一百列或者十万列，或者随便多少列。你是怎么思考这个问题的？比如你的数据库也非常大。你是怎么做到的？嗯，我认为对于所有这些情况，当然，如果数据变得越来越大，这只是一个更难的问题。你知道，这绝对是事实。你的准确率会下降，对吧？比如，Cloud Code 在较大的代码库中表现比在较小的代码库中差，对吧？随着模型的进步，它们在所有这些方面都会变得更好。嗯，对于这些，我会思考：如果我有百万列和百万行的电子表格，我会怎么做？我是说，我需要开始搜索它，对吧？如果我搜索“收入”，我会像按 Ctrl+F 搜索“收入”，然后我会检查每一个结果，我会想：“这是对的吗？”然后我会看到，比如，这里有数字吗？然后我可能会保留一个草稿，比如一个新工作表，我会写：“嘿，比如收入等于这个，你知道的？”并存储这个引用，然后继续。
所以我认为思考这个问题的一个好方法是：模型不应该，你不应该把整个电子表格读入上下文，因为那会占用太多资源，对吧？嗯，你想给它初始量的上下文。这也是你工作的方式，对吧？比如，假设你打开了电子表格，你看到的是行，对吧？你看到的是前 10 行和前 20 或 30 列之类的，对吧？这就是你看到的。你不会立刻把所有内容加载到上下文中。你可能有一种直觉，比如：“嘿，我应该加载更多上下文到里面，对吧？”然后想：“哦，我应该导航到另一个工作表，对吧？”而这个其他工作表有更多数据，对吧？嗯，但你需要像……你自己在收集上下文，对吧？所以代理可以以同样的方式运作。它可以导航到这些工作表，读取它们，尝试保留一个草稿，保留一些笔记，然后继续。所以这就是我会思考的方式。
嗯，是的，在后面。是的，所以我的问题是关于管理上下文窗口。实际上，我想这与上一个问题有关。嗯，你有没有什么经验法则，你知道，在开始遇到收益递减或这变得不那么有效之前，你使用多少比例的上下文窗口？是的，问题是，是的，上下文管理。你有没有什么经验法则，比如在使用多少上下文窗口之前它会变得不那么有效？这实际上我认为是一个目前相当有趣的问题。嗯，我认为很多时候当我与使用 Cloud Code 的人交谈时，他们说：“我已经进行了第五次压缩。”我说：“什么？”就像，我几乎从未做过压缩，你知道我的意思吗？我必须通过强迫自己进行压缩来测试用户体验。嗯，只是因为我倾向于经常清除上下文窗口，对吧？当我自己使用 Cloud Code 时，只是因为在代码中，状态位于代码库的文件中，对吧？
所以假设我做了一些更改，Cloud Code 可以只看我的 git diff 并说：“哦，嘿，这些是你做的更改。”它不需要知道我与它的整个聊天历史，以便继续新任务，对吧？所以在 Cloud Code 中，我经常清除上下文，我会说：“嘿，看看我未完成的 git 更改。我正在做这个。你能帮我以这种方式扩展它吗，对吧？”这是一种思考方式。而当你构建自己的代理时，比如假设我们构建一个电子表格代理，这就变得稍微复杂一些，因为你的用户不太懂技术，对吧？他们不知道什么是上下文窗口，对吧？嗯，我认为这是一个难题。我认为这里有一些用户体验设计，比如你能重置对话状态吗，对吧？比如，也许每次用户问一个新问题时，你能自己进行压缩或类似操作，并总结上下文吗？嗯，在电子表格中，很多状态都在电子表格本身中，所以它可能不需要知道整个上下文。嗯，你能存储用户偏好，随着进行而记住一些这些东西，你知道的？就像有很多方面，这是一门艺术。有很多不同的角度和方式你可以做到这一点，对吧？嗯，但你是试图最小化上下文使用。嗯，你可能不需要像百万个上下文之类的东西，你知道我的意思吗？你只需要良好的上下文管理，比如用户体验设计。是的。
嗯，是的。嗯，我只是想问，子代理是为了保护核心代理的上下文而创建的，对吧？没错。是的，子代理是为了保护上下文而创建的。>> 你们能否使用多个子代理，并尝试创建一个过程，将电子表格分块，以防它非常大，这样代理就可以并行地遍历每个部分？是的，是的。我是说，嗯，是的，所以 Cloud Code 让我喜欢的事情之一是我们是使用子代理的最佳体验。特别是带有 bash 的子代理。它非常好。我并没有完全意识到所有的痛苦。嗯，我认为如果有人去 QCon，我相信 Adam Wolfe 将在 QCon 上发表关于我们如何实现 bash 工具的演讲。Adam 是传奇人物，bash 工具做得非常好。嗯，当你同时运行并行子代理时，bash 变得非常复杂，并且有很多竞争条件之类的东西。而我们在那里解决了很多工作，对吧？所以这是我喜欢 Cloud Code 的事情之一，你可以只是说：“嘿，启动三个子代理来做这个任务。”它会那样做。在 Agent SDK 中也是如此，你可以只是要求它这样做。所以第一，子代理是 Agent SDK 中很棒的原始组件，我还没有看到任何人做得像这样好。所以这是使用它的一个大原因。嗯，是的，通常你希望这些子代理保留上下文。假设你有，如果你有电子表格，你同时可能有多个读取子代理在进行，对吧？所以也许主代理会说：“嘿，这个代理能读取并总结第一张表吗？这个代理能读取第二张表的总结吗？这个代理能总结第三张表吗？”然后它们返回它们的结果，然后代理可能会再次启动更多子代理，对吧？所以，这是你拥有的另一个旋钮。嗯，我想说的是，
我们之前讨论过很多关于如何创造性地解决问题的方法。我认为，你应该在这个层面上去思考你的问题，而不是去纠结于如何启动一个进程来创建一个子代理，或者思考像“压缩器”这样的底层系统工程设计。在 Agent SDK 的框架中，我们已经为你处理了所有这些底层细节。这样，你只需要关注那些真正核心且困难的问题：比如，我需要启动哪些子代理？如何设计遗传搜索接口？以及如何验证它们的工作成果？
如果你花费时间去解决那些低层级的技术问题，而不是上述核心问题，那么你可能并没有为用户交付真正的价值。我非常推崇 Agent SDK 中的子代理机制。这是一个很好的问题。我们有一个动作和验证的路径。那么，验证究竟应该放在哪里呢？在这个例子中，假设在生成 SQL 查询之后，我可以验证生成的查询是否正确，这是一条路径。
另一条路径是生成查询后直接执行，然后在获取输出结果后再进行验证。那么，代理如何动态选择哪条路径是正确的呢？关于验证的时机，你是在最后才验证，还是在中间过程就进行验证？我认为，只要有可能，就应该无处不在地进行验证。正如我之前提到的，我们在 Claude Code 的读取步骤中就进行了一些验证，这是一个很好的例子。
你当然可以在最后进行验证，这绝对是必要的。但在其他任何时间点，如果你有规则或启发式方法，也可以进行验证。例如，如果你的规则是“搜索的列总数不应超过 10,000 或 1,000”，这就是一个很好的验证方式。同样，也许你不应该插入巨大的值行。这时，你可以向模型提供反馈，告诉它：“嘿，把它分块处理。”
你可以抛出错误并给予反馈。模型最棒的地方在于它会听取反馈。它会阅读错误输出，然后继续执行。因此，虽然我在演示中将其展示为一个循环，但验证实际上可以发生在任何地方，并且应该尽可能多地发生。你可以把它放在你能想到的任何地方。
好的，我需要开始进行一些原型设计，但我再回答一个问题。我们如何定义步骤？如何告诉代理先进行搜索，然后执行这一步，再执行那一步？它是如何从起点一步步循环执行的呢？你只需要告诉它。是的，在系统提示词中。对于 Claude Code，我们只是给它提供 Bash 工具，并告诉它：“嘿，收集上下文，读取文件，做一些事情，比如运行代码检查。”
对于代理，你不需要强制规定这些步骤。你不需要告诉它“你必须做这个”，因为有时候这样做可能并不必要。比如，如果有人问的是一个只读的电子表格问题，你不需要验证是否有编译器错误，因为你没有执行任何写入操作。让代理保持智能，就像你在工作中希望拥有的自由一样。
好的，酷。我想现在尝试进行一些原型设计，既然我们有了这个框架。好的，让我们说在进行了大量问答之后才执行。好的，原型设计。假设你有一个代理，你想构建一个代理。听完这次演讲后，你会有很多想法，但你知道如何去做吗？我认为总体而言，构建代理应该是简单的。你的代理最终应该是简单的，但简单并不等同于容易。
开始使用应该非常简单，事实确实如此。只需前往 Claude Code，给它一些脚本、库、自定义 Claude 身份，并让它去做。这就是我们要做的。它应该非常容易，比如你可以说：“嘿，这是我的 API，这是 API 密钥。你能帮我搜索我的客户支持工单，并按优先级整理它们吗？”然后观察 Claude Code 做了什么，并在此基础上迭代。
这是一种跳过那些困难的、特定领域的问题的好方法。你有很多领域特定的问题，比如如何组织数据、如何进行遗传搜索、如何为数据库设置护栏。这些都是你可以立即开始使用 Claude Code 解决的问题。尝试构建一个感觉良好的东西，我发现通常你可以直接使用 Claude Code 在本地获得非常好的结果。
你应该对此充满信心。好吧，我忘了这个更多信息，看我的人工智能工程师讲话。这是一个我们内部使用的演示文稿。好的，我要插入这个。所以，你看到的是我们向客户展示的内容。好的，使用 Claude Code。再次强调，简单但不容易。你的代理中的代码量不应该超级大。不需要巨大，也不需要极其复杂，但它需要优雅。它需要符合模型的期望。
你想拥有这种有趣的见解：让我们把模型转换成 SQL 查询。让我们把电子表格转换成 SQL 查询，然后从那里开始。以这种方式思考，Claude Code 是一种很好的方法。好的，让我们创建一个宝可梦代理。这就是我们要做的。宝可梦是一个拥有大量信息的游戏。
数千只宝可梦，每只都有大量招式。嗯，我们希望保持通用性，因此实际上有一个 Poké API。我选择宝可梦的原因很简单，因为我知道你们也有自己的 API，对吧？而且它们都非常独特。所以，我想选择一个我未曾尝试过的、具有复杂 API 特性的对象。Poké API 允许你搜索像“百变怪”这样的宝可梦，或者搜索道具等物品。它包含了游戏中的一切内容。因此，你的代理可能想要帮助用户完成的任务之一是组建一支宝可梦队伍。我热爱宝可梦，但我对如何组建一支在竞技比赛中有趣的队伍知之甚少。我的代理能帮我吗？那会很酷，对吧？
我的目标是创建一个可以聊宝可梦的代理，然后我们看看能做什么，能走多远。我已经做了一些工作，现在展示给你们看。第一步，这里的提示是：我主要进行代码生成。这会在 GitHub 上吗？实际上是的。在我的个人 GitHub 上。我本来也想提交所有这些代码。我的个人 GitHub 是……让我们看看。是安全的 GitHub 还是里面有恶意软件？[笑声] 你们是 AI 工程师，你们知道的。如果被黑了，那是你们的错。你们可以克隆这个仓库。我需要推送最后的更改。大家能看到吗？我应该切换到深色模式吗？还是这样就行？深色模式？好的。[笑声]
这样更好吗？不？你想要另一种深色模式？深色硬核？好吧，我觉得这对你们来说还不够好。大家还能听到我说话吗？好的。这是一个例子：我给出的提示是“嘿，去搜索 Poké API 的 API 并创建一个 TypeScript 库。”这是完全由代码生成的。你可以看到它创建了一个宝可梦的接口，也就是这个宝可梦 API。我可以按名称获取宝可梦，列出宝可梦，获取所有宝可梦，获取物种、能力等信息。这只是我给出的一个提示，它生成了这个 TypeScript API。它也为招式做了同样的事情。然后它创建了我可以使用的 API。导入 PokéAPI，来自 PokéAPI SDK，你可以看到它是如何设置的。
相比之下，这是我制作的 Claude，也就是 PokéAPI 的 TypeScript SDK。这是 PokéAPI 中的模块。这里有一些关键功能。我要求它在 examples 目录中编写脚本，然后执行这些脚本来帮助我查询。我给它一些示例脚本。它并不总是需要所有这些信息的。获取宝可梦、列出资源、获取数据等。这就是我的代理。我给出的提示是生成一个 TypeScript 库，然后我制作的这个 Claude，我可以在 Claude Code 中与它聊天。我还会展示一个仅使用工具的版本。这里我使用的是消息补全 API，并给它提供了一些来自 API 的工具。比如获取宝可梦、获取宝可梦物种、获取宝可梦能力、获取宝可梦类型、获取招式。你定义了所有这些工具，我给了它一个提示让它制作这些工具。
它不想制作 100 个工具，因为 PokéAPI 的数据量很大。但参数数量有限。所以它有了这个工具调用。我制作了一个简单的聊天界面。让我现在去这里说：这是我的工具调用。你推送最新版本了吗？我漏掉了吗？太好了。这里我们有 chat.ts。我在原型开发时使用 Bun，因为我不想从 TypeScript 编译到 JavaScript。Bun 内置了 linting。这简化了代理的工作，代理不需要记得编译。但 TypeScript 更适合生成，因为它有类型。我将启动 Bun chat，然后尝试问：“二代的水属性宝可梦有哪些？”你会看到它开始搜索，我在这里记录所有工具调用。这非常重要，因为它需要执行工具调用。你可以看到它搜索了许多宝可梦。然后它告诉我，这是二代的水属性宝可梦：小锯鳄、蓝鳄、大力鳄。你可以看到它在每一步之间都在思考之前的步骤。
假设我想用 Claude Code 做点什么，我想我需要删除这个示例。哦，是的。小问题：你如何记录工具调用？这只是可以传递的参数吗？哦，是的，这在普通 API 中。在模型中，每次它记录时，我就调用这个。这是在普通的 Anthropic API 中。在 SDK 中，我会回到 SDK。只需记录每个助手消息，也就是做 console.log。明白了吗？好的。你展示的聊天界面是使用普通 API 还是代理 SDK？是的，使用普通 API。不是代理 SDK。对。我要删除这个脚本，因为我不想让它作弊。我打开了 Claude Code。我在这里创建了许多文件。我说：“能告诉我所有二代的水属性宝可梦吗？”然后我们看看它能做什么。我忘了是否需要提示它编写脚本。我想没问题。我们看看会发生什么。你介意去核心 SDK 文件，展示一下关于不同上下文、然后是行动、然后是验证的讨论吗？
你能在代码中展示这一点，以及我们如何配置工具描述吗？是的，所以呃，我们还没有做 SDK 的部分。所以，到目前为止，我只是在 Claude Code 中放入了一些 API。是的，是的，是的。没错。我以为我漏掉了那个。这就是为什么不，不，不，是的，是的，是的，当然。好吧。嗯，但是是的，所以好吧，你可以看到这里呃，它给了我更多，对吧？而且呃
是的，它给了我更多。所以，它说这里有 20 个水系宝可梦，对吧？我认为这大致是正确的。我像呃，它做了什么？哦，我想它只是知道了。好吧。是的，这很有趣。现场演示这个。嗯，无论如何，呃，是的，宝可梦有点分布广泛，这是呃，我想这是好事。>> [笑声] >> 嗯，但是是的，所以像它会做的是，它会尝试像
写一个脚本，呃，因为你不想让它想太多，对吧？所以，这里它就像，好吧，我要做的是呃，让我们看看。第二代水系宝可梦。是的。它在哪里？好吧，所以是的，你可以看到它知道，好吧，世代的开始。它通过 API 获取这些呃。我想它决定不使用我的 Google API。呃，然后呃，是的，然后运行它，
对吧？所以，呃，我想我需要像改进我为此制作的 Claude。但无论如何，你可以看到它能够像检查 200 多个宝可梦，然后检查它们的类型，你知道，获取他们的获取他们的信息，对吧？所以，这就像呃，只是一个关于如何做代码生成以及如何利用 Claude Code 来做它的快速示例，对吧？所以，我们将运行这个脚本，然后像呃呃
像继续下去，对吧？所以，呃，它会给我输出。而且呃，基本上我想展示的是，让我们看看，我们还有大约 15 分钟。呃，只是让它玩宝可梦。只是让它玩宝可梦。是的，是的。实际上，这是我打算做的演示之一。呃，Claude Code 玩宝可梦。所以，就像你说你想做一个代理版本的 Claude 玩宝可梦，你会怎么做
你会怎么做？呃，我认为你会做的是，你会给它访问内部内存的呃 ROM 的权限，对吧？所以，假设它想找到它的队伍，它可以在内存中搜索。而宝可梦红版是一个呃逆向工程呃的游戏，分布非常广泛，对吧？所以，它可以在内存中搜索，就像，嘿，这些是宝可梦。呃，这些就像这是
我如何确定地图的位置，我如何导航它。对吧？所以，这就像呃，也许实际上我得告诉读者如果你想尝试的话。就像呃，有一个 Node.js GBA 模拟器。呃，我想我得合法地说你必须去买宝可梦红版并尝试它。呃，但是是的，我想呃，是的，好例子。无论如何，这里。所以，它已经获取了所有的，并且列出了所有
它们的类型，而且呃，是的，你可以看到它是如何使用代码生成来做这个的，对吧？所以，呃，一个使用 Claude Code 快速原型设计的例子。呃，现在，这里可以有像更有趣的数据。所以，呃，我想留出时间做例子。所以，我想我会只是像处理问题一样。所以，我会只是像过一遍例子。假设你在制作竞技
宝可梦。竞技宝可梦有很多不同的变量和数据。所以，这就像来自这个在线的呃库的一个文本文件，基本上，它存储了像所有的宝可梦和它们的像招式以及它们和谁配合得好和配合得不好，你知道，像谁被它们克制以及所有这些，对吧？所以，这里有很多数据，对吧？而且都在文本文件中。
呃，这对于 Claude Code 来说其实相当不错，对吧？因为我可以说，好吧，呃，嘿，我要给它多一点数据。通常，我把这个放在呃检查数据文件夹中。告诉我我想要围绕妙蛙种子组建一支队伍。你能根据 Smogon 数据给我一些建议吗？呃，而 Smogon 是这个在线 API。所以我我不完全确定它会在这里做什么。我
以前没做过这个职业。呃，但我们会看到的。我想它会很有趣。呃，在那里。那是哦，我看到了。
呃，是的，但我想要做的是像梳理这些数据，对吧？并且像从自身从第一性原理出发，在没有见过这些数据之前，我怎么能像回答我的查询，对吧？所以，呃，当它这样做的时候，我会我会接受任何问题。是的？呃，所以，很棒的研讨会。呃，所以，这就像是在 Cloud Code 之上的。所以，我的问题是，如果我们部署这个
面向客户的应用程序，我们是否应该让 Cloud Code 像呃像集群中运行，或者我们是否 somehow 能够把 Cloud Code 部分去掉，只使用 Cloud 和 Agent SDK？嗯，是的。所以，让我像非常快速地展示一下像使用 Agent SDK 在这里看起来像什么。呃，所以，我已经做了这个文件系统，对吧？而且再次，我想让你把文件系统想象成一种
做上下文工程的方式，对吧？就像这是像进入代理的很多输入。所以，我的实际代理文件就像 50 行，对吧？呃，而且它大部分就像随机的像样板代码，对吧？就像我想是的，它决定阻止它呃在自定义脚本目录之外写脚本。再次，所以我们反向编码它。所以，呃，是的，你可以看到它只是运行这个查询，接收
工作目录，呃，和呃像在一个循环中运行它，对吧？所以，可能我想像把它转换成一些允许的工具在这里和 stuff，但它很简单。而且和呃，如果我要像生产化这个，我做的第一步是像，好吧，我在 Cloud 上在 Cloud Code 上测试了它。它似乎做得很好。我写这个文件，然后把它放这里有两种方法。所以，一个是
我认为像本地应用可能会随着 AI 回归，因为我想像运行它的开销如此之大。就像例如，Cloud Code 是一个前端应用，对吧？就像它在你的电脑上工作。所以，也许我运送这个宝可梦应用的方式是像，嘿，我有一个像你会安装的应用，它在你电脑上本地工作，并且它在运行脚本。我想那是一个方法
这样做，对吧？呃，另一种方式是，是的，你有你 [清嗓子] 在沙盒中托管它。呃，而且再次，有很多不同的沙盒提供商让它变得非常容易。就像 Cloudflare 有一个好的例子呃使用 Agent SDK，它就像沙盒.start，你知道？然后像 bun agent.ts，这就是它所需的全部，对吧？就像它像抽象掉了
很多。呃，所以你运行像沙盒，呃，然后你和它通信。而且呃，是的，我想有一些非常有趣的东西，我不确定我有时间去涉及，但是呃，像我想一些有趣的问题是像呃，是的，像你怎么做这种像服务？现在，我们只是启动一个子像每个用户一个沙盒。呃，有很多像我会说最佳
这里有一些实践问题需要解决。我想让大家思考的一件事是，如果你正在构建一个带有用户界面的智能体，比如我的宝可梦智能体，我希望拥有一个能适应用户需求的界面。有些用户可能在组建队伍，有些用户在寻求游戏帮助，还有些用户只想看宝可梦的图片。那么，如何让智能体实时适应用户呢？
我会这样做：在沙盒中设置一个开发服务器，该服务器会暴露一个端口，运行在 Bun 或 Node 等环境中。智能体可以编辑代码并实现实时刷新，用户则与该网站互动。许多网站构建工具（如 Lovable）就是这样工作的，它们使用沙盒并托管开发服务器。如果你想为自定义界面，这是一种很好的方法。
让我们看看它做了什么。它生成了一个脚本，展示了一些基础属性，建议了一套招式和队友。我们可以看到它开始搜索妙蛙花，并找到了相关属性的宝可梦。当它这样做时，它还会获取提到妙蛙花的其他宝可梦，从而找到它的队友和克制它的对手。
经过一段时间，它找到了一些有趣的宝可梦，这些宝可梦可能与其配合良好。它进行了多次搜索，建立了档案，找到了常见的队友，并编写了脚本来分析这些数据。这一切都是基于一个文本文件。当然，我可以预先对文本文件进行更多预处理。
它为我做了这种有趣的分析。稍后我会将更多代码推送到 GitHub 仓库，并在推特上分享。我的推特账号是 TRQ212，我经常发推，主要关于 Agent SDK 的内容。我们还有大约 8 分钟，我想利用剩余时间回答关于任何方面的问题。
很抱歉我们没有进行更多的原型制作。有人问，能否将其与 Cloud Play 的宝可梦功能结合，看看智能体是否能更谨慎地选择队友并尝试捕获？我会把它放进 Cloud Play 的宝可梦中。我也想做 Cloud Play 的宝可梦，这听起来很有趣。
不过，我们尽量保持 Cloud Play 为纯粹的推理任务。还有其他问题吗？有人好奇人们是如何通过 Cloud Code SDK 实现货币化的。是的，我认为目前智能体成本较高。因为模型刚开始具备智能体特性，我们专注于最智能的模型。
这就像一般的 SaaS 软件业务，你更愿意向解决棘手问题的少数用户收取更高费用。所以，我认为这仍然可行。你应该寻找这些困难的使用场景，但第一步是确保你解决的问题是人们愿意付费的。
第二步，你可以选择订阅制或基于 Token 的计费。这取决于你预期用户使用产品的频率。Cloud Code 用户使用频繁，所以我们采用混合模式：提供速率限制，超出后按使用量计费。这取决于你的用户群体。
但我会说，货币化是你应该 upfront 考虑的事情，并围绕它设计智能体，因为这些流程很难回退。后面那位朋友，你一直没提到 Hooks，我想听听你的看法。是的，Hooks 有很多可说的。Hooks 很棒，我们确实提供了 Hooks。
Hooks 是一种进行确定性验证或插入上下文的方式。我们将 Hooks 作为事件触发，你可以在 Agent SDK 中注册它们，文档中有指南。例如，你可以用它来每次验证电子表格。或者，当智能体操作电子表格而用户也修改了它时，这是一个使用 Hooks 的有趣场景。
你可以在每次工具调用后插入用户所做的更改，以有趣的方式提供实时上下文变化。文档中有更多关于 Hooks 的内容，会后我也很乐意讨论。还有更多问题吗？当我调用 Agent SDK 时，我在做什么？
比如，我在 Cloud Code 中处理数据，发现它有效，我想将已经完成的对话转化为智能体。我遵循了一些步骤，现在它实际上在工作了，我不想重写所有代码来适配 Agent SDK。你说得对，既然它有效，当然可以。
如果你已经完成了原型制作并找到了有效的方法，我会总结 cloud.md 文件。比如我之前尝试时，它没有直接使用我的 API 而是写了 JavaScript。我应该在 cloud.md 中更具体地说明。所以，第一步是总结到 cloud.md 中。
第二步，保留你需要的辅助脚本，然后编写类似 agent.js 的文件来运行测试。有人问，我试图让它为钱工作，我觉得没问题。它还利用脚本输出来回答问题，尝试几次，因为我的测试用例写得很好。
它尝试两次，然后给出比较表。对于这类问题有什么建议吗？这是一个好问题。
我觉得这里确实有些混乱，对吧？比如，如果一个智能体知道答案，而你想要像对抗它一样去纠正它，说“不，现在是第九代生成，情况已经变了，出现了一种新的范式”，这很难。实际上，我认为做到这一点的一种方法是使用钩子（hooks）。例如，你可以说：“嘿，如果你在没有编写脚本的情况下返回了响应，你可以检查一下。你可以提供反馈，比如请确保你编写了脚本，请确保你阅读了这些数据。”
你可以使用钩子以与 Cloud Code 中类似的方式提供这种反馈，就像我们有这样的规则：“在写入之前确保先读取文件”，以此来增加确定性。正如我所说的，这确实是一门艺术。有时候，也许写代码吧，我想大概是这样的。
[笑声] >> 是的，在灰色地带。你们是如何处理大型代码库的？有些代码库有超过 5000 万行代码。所以，是的，grep 工具不太管用，我不得不构建自己的语义索引类型工具来帮助解决这个问题。
有没有什么产品层面的思考，比如如何让这更原生地融入产品？比如几个月后，我写的东西会消失吗？或者你们是怎么看待这个问题的？好的，这是你们的最后一个问题：几个月后它会消失吗？通常来说，是的。
[笑声]
只要提到 AI，就是这样。我认为，语义搜索……这更像是一个 Cloud Code 的问题，而不是 Agent SDK 的问题，但我很乐意回答。你知道，语义搜索存在权衡，我认为它更脆弱。你必须进行索引和搜索，而且模型并没有针对语义搜索进行训练，所以我认为这是一个问题。
比如，grep 之所以容易做到，是因为它是为此训练的，但语义搜索你是在实现定制的查询。对于非常大的代码库，我们知道有很多客户在使用大型代码库。我认为我看到的情况是，他们只是做好良好的 cloud.md 文档。你从你想开始的目录开始，确保有良好的验证步骤、钩子和链接等。这就是我们要做的。我们没有定制化的东西，我们内部使用 Cloud Code。
好的，是的，最后一个问题。我们不得不结束了，很遗憾。谢谢大家。
[掌声] [音乐]
[音乐]