从单点功能到自主智能体的演进
本次工作坊由Anthropic的Thariq Shihipar主持，旨在深入探讨Claude Agent SDK的核心价值与应用场景。演讲者首先梳理了人工智能应用的发展脉络，指出早期如GPT-3时代主要聚焦于单一语言模型功能，例如简单的文本分类或结构化响应生成。随后，行业进入了工作流（Workflow）阶段，用户通过预设的固定步骤指导AI处理特定任务，如邮件标签化或基于RAG的代码补全。这些工作流具有高度的结构性和确定性，输入与输出之间的逻辑链条是预先定义好的。然而，当前的趋势正转向智能体（Agents），其核心特征在于自主构建上下文和自主决定行动轨迹。与受限的工作流不同，智能体能够在更广阔的空间内自主探索，这种转变标志着AI从被动执行指令向主动解决问题的跨越。正如演讲者所言：
"We're getting to agents... agents build their own context, like decide their own trajectories, are working very autonomously."
尽管智能体目前尚不完美，但演讲者认为现在是开始构建智能体的最佳时机，因为技术成熟度已达到一个关键的临界点，允许开发者以更高的自由度进行创新。
Claude Code：智能体架构的基石与意外发现
Claude Agent SDK并非从零构建，而是建立在Claude Code的基础之上。Claude Code被定义为第一个真正的通用智能体，它能够持续运行数十分钟，自主完成复杂的编码任务。Anthropic在内部开发智能体时发现，团队反复重建相同的底层组件，包括模型接口、工具集成、提示词工程、文件系统交互以及记忆管理等。这些组件构成了智能体的“骨架”，而Claude Code恰好提供了这一完整的技术栈。更有趣的是，Anthropic观察到一种涌现模式：在Claude Code发布后，不仅工程师，金融、数据科学和市场营销人员也开始广泛使用它处理非编码任务。这一现象促使Anthropic意识到，基于Claude Code构建通用智能体具有巨大的潜力。演讲者指出：
"We realized basically that as soon as we put Claude Code out... the finance people started using it... we just realized that people were using Claude Code for non-coding tasks."
这一发现验证了Bash工具等通用接口在非编程领域的强大适应性，使得基于同一底层架构构建多领域智能体成为可能，从而避免了重复造轮子，提高了开发效率。
SDK的核心组件与生态系统
为了降低开发门槛，Anthropic将上述所有复杂组件打包为Claude Agent SDK。该SDK涵盖了智能体运行的所有关键要素：模型接口、工具链（包括文件系统追踪、自定义工具等）、核心提示词、状态转换逻辑以及文件系统上下文工程。此外，SDK还集成了近期推出的技能（Skills）、子智能体、网络搜索、上下文压缩、钩子（Hooks）和记忆机制等功能。这些组件共同构成了一个强大的智能体开发框架，使得开发者无需关注底层基础设施的搭建，即可专注于智能体的行为逻辑设计。目前，基于该SDK开发的智能体已广泛应用于软件可靠性、安全审计、故障排查、网站构建以及MS Office自动化等领域。演讲者强调，SDK的设计初衷是解决构建智能体时的工程复杂性，通过提供标准化的工具包，让开发者能够更专注于智能体的艺术性与直觉性设计，而非重复的基础设施开发。这种架构不仅加速了智能体的落地，也为非技术背景的用户提供了构建专业领域智能体的可能性。
核心设计理念：基于 Unix 原语与强观点架构
Anthropic 在构建 Claude Agent SDK 时，将部署 Claude Code 过程中积累的最佳实践深度整合进 SDK 中，形成了一套具有强烈“意见”（Opinionated）的代理构建方法论。演讲者指出，Bash 工具是代理最强大的工具，这一核心观点构成了 Anthropic 构建代理的基础。这种架构并非唯一路径，但在使用该 SDK 时，它代表了推荐的工程范式。其核心在于利用 Unix 原语（如 Bash 和文件系统）来构建代理，而非仅仅依赖抽象的 API 调用。这种设计允许代理直接操作环境，从而在原型开发阶段展现出极高的灵活性和效率。通过这种方式，代理能够像人类开发者一样，通过命令行和文件操作来解决问题，而不是被限制在预定义的函数接口中。
代码生成在非编码场景中的应用
“代码生成”（Code Generation）的概念不仅限于编写软件代码，它同样适用于非编码任务，如生成文档、查询网络、数据分析或执行非结构化操作。演讲者通过一个具体案例解释了这一机制：当用户询问旧金山的天气及穿衣建议时，Claude Code 并不会直接返回一个静态答案，而是编写一个脚本来调用天气 API。为了增强实用性，该脚本可能还会动态获取用户 IP 以定位，甚至调用子代理（Sub-agent）结合衣柜 API 提供个性化建议。这种方法的本质是通过代码组合 API，将复杂的任务分解为可执行、可复用的脚本步骤。对于需要频繁执行或逻辑复杂的任务，这种动态生成代码的方式比硬编码的工作流更具适应性和扩展性。
工作流与代理的边界：以 GitHub 自动化为例
在处理重复性任务或确定性业务流程时，是否应优先使用工作流（Workflow）而非代理（Agent）？Anthropic 的内部实践表明，即使是高度结构化的工作流，也常需借助 Agent SDK 构建。例如，他们使用 Claude Agent SDK 构建 GitHub 和 Slack 自动化机器人。以“问题分类”（Triage）这一看似确定性的任务为例，代理不仅需要判断问题类型，还需要克隆代码库、启动 Docker 容器进行测试等动态操作。这些中间步骤具有高度的流动性（Fluidity），传统的确定性工作流难以灵活应对。因此，Anthropic 倾向于使用代理来处理这类任务，最终输出结构化结果。这种混合方法既保留了代理的环境操作能力，又通过结构化输出确保了结果的可靠性，证明了在复杂工程场景中，代理架构优于纯确定性工作流。
安全防御体系：瑞士奶酪模型与致命三重奏
鉴于 Bash 工具赋予代理极高的环境权限，Anthropic 采用“瑞士奶酪防御模型”（Swiss Cheese Defense）来确保安全。该模型强调多层防御叠加，以消除单一层的漏洞。第一层是模型对齐，通过强化学习等技术确保模型行为符合人类价值观，Anthropic 近期发布的关于“奖励黑客”（Reward Hacking）的论文即为此领域的重点。第二层是护栏机制（Harness），包括权限控制和提示工程，例如对 Bash 工具进行 AST 解析，以可靠地识别命令意图，防止恶意执行。第三层是沙箱隔离（Sandboxing），限制代理的网络请求和文件系统操作范围。演讲者将这三层防御称为“致命三重奏”（Lethal Trifecta）的对抗手段，即防止代理在环境中执行代码、修改文件系统或泄露数据。这种多层级、纵深防御的策略，旨在确保即使代理被恶意接管，其破坏力也被限制在最小范围内。
安全沙箱与 Bash 的“万能工具”哲学
在构建 AI Agent 时，安全性是首要考量，特别是防止敏感信息泄露。演讲者指出，如果 Agent 能够向外部回传信息，就存在数据外泄风险。因此，网络沙箱化是关键的防护手段。通过托管在 Cloudflare、Modal、AWS 或 DigitalOcean 等提供沙箱环境的平台上，开发者可以避免在本地计算机或存储广泛密钥的机器上运行 Agent，从而构建多层安全防御体系。
“如果它们能将你的信息提取出来，那就意味着它们仍然需要能够提取信息。因此，如果你沙箱化网络，这是一种很好的做法。”
在安全基础设施之上，Anthropic 发现 Bash 是 Claude Code 如此强大的核心原因。演讲者将 Bash 视为“第一种代码模式”（first code mode）。与为每个新用例专门开发新工具（如搜索工具、Lint 工具、执行工具）的传统 Agent 框架不同，Bash 工具允许 Agent 动态生成脚本、存储调用结果到文件、管理内存，并组合现有软件功能（如 tail、grep）。这种通用性使得 Agent 无需预先定义所有工具，而是可以直接利用操作系统中已有的强大工具链，如 FFmpeg 或 LibreOffice，从而实现极高的灵活性和通用性。
Bash 在非编码 Agent 中的动态组合能力
Bash 的强大不仅限于代码生成，它在处理非编码任务（如邮件分析）时展现了卓越的动态信息处理能力。以“统计本周网约车支出”的邮件 Agent 为例，如果没有 Bash，Agent 仅能调用搜索工具获取包含“Uber”或“Lyft”的邮件列表，然后依靠模型自身进行推理。这就像让人面对一叠纸质文件，要求高精度和高召回率地阅读并计算，难度极大且容易出错。
引入 Bash 后，Agent 可以执行更复杂的管道操作：
1. 运行 Gmail 搜索脚本获取原始数据。
2. 使用 grep 提取价格信息。
3. 将结果保存到带行号的文件中以便后续验证。
4. 动态检查每一行是否确实代表价格，并关联具体交易。
“你可以 grep 所有价格，将它们存储在带有行号的文件中，然后稍后检查，这真的是价格吗？每一个对应什么？”
这种可组合性（composability）允许 Agent 在运行时动态构建工作流，不仅执行操作，还能自我验证结果。例如，Agent 可以安装 ESLint 来检查代码，或者运行 npm run test.ts 来执行测试，甚至自动发现用户项目的 Lint 配置。这种“Bash 即代码生成”的理念，使得 Agent 能够以极低的预配置成本处理高度定制化的任务。
Agent 与 Workflow 的架构区分
在 Anthropic 的 Agent SDK 中，开发者可以构建两种主要类型的自动化系统：Agent 和 Workflow。虽然两者都支持结构化输出（Structured Outputs），但其设计哲学和应用场景有显著区别。
Agent 类似于 Claude Code，适用于需要自然语言交互和灵活行动的场景。当用户希望 Agent 与业务数据对话、获取洞察、生成仪表板、回答问题或编写代码时，Agent 是最佳选择。它强调灵活性和对模糊指令的理解能力。
相比之下，Workflow 更类似于 GitHub Actions。它要求输入和输出被严格定义。例如，一个 Workflow 可能专门用于“接收 Pull Request 并生成代码审查报告”。在这种模式下，流程是确定性的，每个步骤的输入输出关系紧密耦合，适合标准化、重复性高的任务。
“Agent 是像 Claude Code 这样的东西……如果你想要用自然语言与它交谈并灵活采取行动，那就是你在构建 Agent。而 Workflow 则更像是我们做的很多 GitHub Actions，你非常紧密地定义输入和输出。”
尽管演讲者主要聚焦于 Agent 的构建，但 SDK 的设计使得从 Workflow 到 Agent 的许多概念是通用的。开发者可以根据任务对灵活性和确定性的需求，选择合适的架构模式。
工具调用结果的文件化存储策略
在构建 Agent 时，处理 Bash 命令产生的大量输出是一个常见挑战。演讲者指出，随着上下文窗口的爆炸式增长，将工具调用的结果直接存储在文件系统中成为一种更优的实践方案。与其让冗长的输出充斥对话历史，不如让 Agent 将结果写入文件，并在工具调用中返回该文件的路径。这种机制不仅有助于 Agent 在后续步骤中重新检查其工作成果，还使得跨步骤的数据检索和搜索成为可能。
"I think like generally prompting agent to do this is a good way to think about it. Or even if you have... whenever I have a tool call, I save it like the results of the tool call to the file system so that you can like search across it and then have the tool call return the path of the result."
这种模式被视为一种渐进式上下文披露（Progressive Context Disclosure）的体现。通过让 Agent 主动将数据持久化到文件系统，开发者可以避免上下文窗口被无关的中间过程填满，从而保持对话的清晰度和效率。目前，Anthropic 也在通过 PR（Pull Requests）等方式优化 Claude Code 对长输出的处理，进一步推动了这一趋势。
Skills 的本质与渐进式上下文披露
关于 "Skills"（技能）的概念，演讲者将其定义为允许 Agent 加载复杂任务所需上下文的机制。Skills 本质上是一组文件，通常表现为 Agent 可以 cd 进入并读取的文件夹。它们特别适用于那些需要高度专业知识且可重复执行的指令，例如生成 .docx 文件或进行前端设计。
以 recently released 的 前端设计技能（Front-end Design Skill） 为例，它包含了来自 Anthropic 顶级 AI 前端工程师的深度思考与迭代成果。当 Agent 被要求执行特定任务时，它会先 cd 进入相应的技能目录，读取 skill.md 中的详细指导，然后生成脚本并继续执行。这种方式让 Agent 能够像人类专家一样，先查找方法，再执行操作，从而显著降低错误率。
"Skills are basically a way of like you know allowing our agent to take longer complex task and like sort of load in things via context... they're really good for is pretty like repeatable instructions that need a lot of expertise in them."
Skills 与模型能力的演进关系
针对 "Skills 是否会最终成为模型的一部分" 的疑问，演讲者认为，模型能力的提升与 Skills 的补充作用是并行的。虽然模型会越来越擅长处理广泛的任务，但 Skills 仍然是提供 "分布外（Out-of-Distribution）" 任务能力的最佳方式。由于 AI 工程领域变化极快，每六个月重写一次 Agent 代码被视为一种合理的最佳实践，以应对底层能力的快速迭代。
Anthropic 的 Agent SDK 设计旨在尽可能随模型能力同步进化。例如，基于 Claude Code 构建的 Bash 工具会随着 Claude Code 的更新而自动获益。演讲者强调，不要过度押注于未来的技术路线，而应专注于当下能产生市场优势的方案。
"My general rule of thumb is like I try and like rethink or rewrite my like agent code like every six months just cuz I'm like things have probably changed enough that I've like baked in some assumptions here."
对于初创公司而言，这种灵活性是相对于大公司的最大优势。大公司往往受限于漫长的孵化周期，而初创公司可以立即利用现有的 Agent 能力构建产品，并在必要时快速抛弃旧代码。这种 "快速迭代、快速抛弃" 的心态是应对 AI 技术不确定性的关键策略。
Skills 与 API 的选择考量
在区分 Skills 与 API 的使用场景时，演讲者指出两者都服务于 渐进式上下文披露 的目的，但选择取决于具体用例。API 通常用于直接调用外部服务或执行特定编程任务，而 Skills 更侧重于提供复杂的、基于文件的指导框架。
在原型设计阶段，开发者可以根据需求灵活组合这两种方式。如果任务涉及大量的文件操作、多步骤的逻辑判断以及需要专家级指导的重复性流程，Skills 提供了更结构化的上下文管理方式。相反，如果任务仅仅是简单的数据获取或状态更新，直接调用 API 可能更为高效。最终，没有绝对的优劣之分，只有对特定工作流更合适的抽象层次。开发者应根据任务的复杂度、上下文需求以及维护成本来权衡使用 Skills 还是直接集成 API。
技能（Skills）与文件系统的深度集成
在构建智能体时，技能（Skills）不仅仅是一个简单的功能模块，它本质上是一种将文件系统作为上下文存储介质的抽象方式。演讲者指出，虽然存在多种利用文件系统的方法，但目前要充分发挥技能的潜力，Agent SDK 是唯一可行的途径。这是因为技能的运行依赖于 Bash 工具和虚拟文件系统的紧密配合，脱离了 SDK 的环境，技能无法完整运作。对于开发者而言，理解这一点至关重要：将 API 视为代码文件（如 API.ts 或 API.py）进行管理，是构建高效智能体的关键思维转变。这种设计允许智能体通过读写文件来维持状态和上下文，从而比传统的内存存储更具灵活性和持久性。
“Skills are like a sort of an introduction into like thinking about the file system as a way of storing context... the agent SDK is like basically the only way to really use skills to their full extent right now.”
此外，关于技能的市场化前景，Anthropic 目前通过 Claude Code 的插件市场提供发现机制，但这更多是一个发现系统（Discovery System）而非严格的收费平台。随着 SDK 的演进，这一生态系统将持续完善，允许开发者在更广泛的场景下复用和共享技能组件，而无需担心复杂的商业授权问题。这种开放且以发现为导向的策略，旨在降低开发者构建复杂智能体的门槛，同时保持系统的灵活性和可扩展性。
何时选择 Agent SDK：性能与灵活性的权衡
对于“何时使用 Agent SDK”这一核心问题，演讲者给出了明确的建议：只要你在构建智能体，就应从 Agent SDK 开始。其核心理由在于，Bash 工具和文件系统提供了无与伦比的性能和灵活性。通过直接操作文件和执行系统命令，开发者可以挖掘出比纯工具调用更高的性能上限。为了验证这一观点，演讲中计划通过对比实验来展示：仅使用工具（Tools-only）与结合 Bash 和文件系统（Bash & File System）两种模式下的性能差异。这种对比旨在证明，利用底层系统能力是突破智能体性能瓶颈的关键。
当然，演讲者也坦诚地指出了 Agent SDK 的缺点：网络沙箱和容器化环境带来了额外的复杂性和性能开销。对于希望本地浏览器运行的开发者来说，这种架构可能显得繁琐。为了形象地说明这一点，演讲者将 Agent SDK 比作前端开发中的 React 与 jQuery 的关系。正如 React 引入了 JSX 和打包器等新概念，初期学习曲线陡峭且显得“令人讨厌”，但它最终赋予了 Web 应用更强的能力。同理，Agent SDK 虽然引入了沙箱等“麻烦”的机制，但它构建了一个真实、强大且经过验证的基础设施，使得开发者能够构建出真正复杂的智能体应用。
“I think the agent SDKs are like the React of agent frameworks to me... it just works, like you have got to do this, you know?”
这种类比强调了长期收益大于短期痛苦的工程哲学。尽管初期需要适应新的工作流，但 SDK 提供的标准化接口和底层优化，使得开发者能够专注于业务逻辑而非基础设施的搭建。Anthropic 内部团队也普遍采用这一策略，进一步验证了其在生产环境中的可靠性和有效性。
自定义 Bash 工具与通用智能体的设计原则
在讨论自定义 Bash 工具时，演讲者强调了一种反模式（Anti-pattern）：将 Bash 工具托管在隔离的虚拟化环境中，使其无法与智能体循环（Agent Loop）中的其他部分（如文件系统）交互。这种隔离会导致工具结果无法被其他组件读取，从而破坏智能体的连贯性。正确的做法是将自定义脚本直接放置在文件系统中，并通过系统提示词（System Prompt）告知智能体其可用性。为了增强智能体对工具的发现和理解能力，建议为所有 CLI 脚本添加 --help 参数，使模型能够通过调用帮助命令来渐进式地（Progressively Disclose）了解子命令和功能，从而降低提示工程的复杂度。
“I would like sort of design all my CLI scripts to have like a dash help or something, so that the model can call that and then it can like progressively disclose like every like sub command inside of the script, yeah.”
关于 Agent SDK 是否适用于构建通用聊天应用（如 Claude.ai 而非 Claude Code），演讲者指出，虽然 Claude Code 的输入输出间隔较长且涉及代码操作，但 Claude.ai 正在逐渐融合这些能力。例如，Claude.ai 的新功能允许生成电子表格和 PPT 文件，这背后正是文件系统能力的引入。随着 Skills 和 Memory 工具的整合，Claude.ai 正变得越来越“文件系统构建”（File System Built）。这表明，Agent SDK 的设计哲学具有广泛的适用性，不仅限于代码助手，也能支撑起更通用的、具备复杂操作能力的聊天应用。这种趋势预示着，未来的智能体将更多地依赖文件系统和工具调用来完成端到端的任务，而不仅仅是生成文本回复。
工具、Bash 与代码生成的选型策略
在构建 Agent 时，面对数据库访问需求，开发者常面临使用专用工具（Tools）、Bash 脚本还是代码生成（Code Gen）的抉择。Thariq 指出，这并非单一的最佳实践问题，而是一个系统设计问题，需要根据数据结构和安全性灵活选择。如果数据库包含高度敏感的用户信息，且需要严格限制输入输出格式，使用专用工具是更优解。这种方式通过原子化的 API 接口，强制屏蔽数据库内部结构，防止 Agent 直接操作底层数据，从而保障安全性。
"If your database was very, very structured and you have to be very careful about like I don't know, you're accessing like user sensitive information... I can only take in this input and I need to like give this output and I have to mask everything else about the database from the agent."
然而，当涉及复杂的 SQL 查询时，Thariq 强烈建议使用 Bash 或代码生成。原因在于，大语言模型在编写 SQL 时容易出错，而通过 Bash 或代码文件，Agent 可以利用 linting（代码检查）、运行文件并查看错误输出，从而进行迭代修正。这种机制允许 Agent 在犯错后自我修复，比受限于固定输入输出的专用工具更具灵活性。因此，现代 Agent 构建趋势是赋予 Agent 尽可能多的数据库访问权限，并通过后置的 guardrails（护栏）和规则限制其写操作，而非在入口处过度限制。
权限控制与内存管理的实现路径
关于角色基于访问控制（RBAC）的实现，Thariq 建议将权限管理下沉至API Key 或后端服务的配置层。具体做法是为 Agent 创建作用域受限（Scoped）的临时 API Key，并在后端服务中验证这些 Key 的权限范围。如果担心密钥泄露，可以在中间层设置代理（Proxy）来注入密钥。这种设计使得后端能够根据 Agent 的身份和权限，对其尝试执行的操作进行精细化的反馈和控制，从而在赋予 Agent 能力的同时确保系统安全。
"Usually, that's in like how you provision your API key or your back end service or something like that... I would create like API keys for your agents that are scoped in certain ways and so then on the back end, you can sort of check it's like, you know, what it's trying to do."
对于内部记忆工具（Memory Tool）的实现，Thariq 透露其底层机制主要依赖于文件系统。尽管 Anthropic 内部可能有更复杂的实现，但对于开发者而言，最实用的建议是直接使用 Cloud Agent SDK 中的文件系统功能。开发者可以创建一个专门的 memories 文件夹，并指示 Agent 将记忆内容写入其中。这种基于文件系统的记忆管理方式简单直接，避免了依赖黑盒内部实现的复杂性，同时也便于开发者调试和控制记忆的读写流程。
Agent 复用性与通信架构的未来探索
当同一 Agent 被部署给数百名用户时，如何确保代码和逻辑的复用性是一个新兴的系统设计挑战。Thariq 指出，传统 Web 应用是“一个应用服务百万用户”，而 Claude Code 等 Agent 模式往往是“一对一的容器隔离”。在这种范式下，不同 Agent 实例之间缺乏天然的通信机制，因此复用性最佳实践仍在探索阶段。目前，社区正在尝试让 Agent 通过共享通用脚本来结合彼此的工作成果，或者通过 HTTP 请求、命名管道（Named Pipes）等现有基础设施进行交互。
"I think like if we probably don't need to reinvent uh like a new communication system. They're like the agents are good at using the things that we have like HTTP requests and hash tools and API keys and uh named pipes and all of these things."
Thariq 认为，我们无需重新发明通信系统，Agent 擅长利用现有的 HTTP 服务器、API 密钥和工具链进行通信。例如，已有开发者构建了虚拟论坛，让 Agent 发布主题并相互回复。这种去中心化的通信方式展示了 Agent 间协作的潜力。未来的重点在于如何设计通用的脚本组合机制和共享工作成果的标准，以解决大规模部署下的复用和协作问题，这将是 Agent 系统设计中需要持续探索和发现的关键领域。
电子表格智能体：搜索策略的复杂性探讨
在构建电子表格智能体（Spreadsheet Agent）时，核心挑战在于如何设计最佳的搜索、代码执行及操作接口。演讲者提出，这不仅仅是简单的数据读取，而是一个涉及上下文获取、行动执行与工作验证的系统工程。为了深入探讨这一问题，现场观众被要求先独立思考：如果拥有一个能搜索电子表格的智能体，应如何设计其搜索机制？
"How would you think about it, right? So like just spend some time thinking through that, take some notes or something."
讨论初期，观众提出了几种直观方案。一种思路是将电子表格导出为 CSV 格式，智能体通过读取文件头（Headers）来理解数据结构。例如，若用户查询“2026年的收入”，智能体需识别出包含“Revenue”和“2026”的列。然而，这种多维度的表格数据查询并非易事，简单的头部扫描往往不足以支撑复杂的多维数据检索需求。观众进一步提出使用命令行工具如 awk 或 grep 进行文本过滤，但这依赖于用户明确知道搜索的具体模式，缺乏语义理解能力。
数据接口转换：从 CSV 到 SQL 的范式转移
针对直接处理 CSV 的局限性，演讲者引入了一种更具创造性的接口设计思路：将数据源转换为智能体更擅长的查询语言。观众提出使用 SQLite 直接解释 CSV 文件，这一观点得到了高度认可。通过这种转换，智能体无需学习复杂的电子表格特定 API，而是利用其已有的强大 SQL 查询能力来搜索数据。
"If you have a data source, if you can convert it into a SQL query, then your agent really knows how to search SQL, right?"
这种转换思维是设计智能体搜索接口的关键。通过将非结构化或半结构化的电子表格数据转化为结构化的 SQL 表，智能体可以执行更精准的多条件筛选和聚合操作。此外，观众还提到了使用 Google Sheets API 或 VLOOKUP 等原生函数，但在本地离线环境下，SQL 化提供了一种通用且强大的替代方案。这种策略强调了预处理在提升智能体搜索效率中的核心作用。
工具选择与元数据增强：构建智能响应
除了数据格式的转换，如何为智能体选择合适的工具以及增强数据本身的语义信息也是关键议题。观众质疑 Claude 模型是否具备自动工具排名（Tool Ranking）的能力，即根据任务自动选择最合适的工具。演讲者认为，这更多依赖于提示工程（Prompting）和对模型能力的理解，而非模型固有的设计，就像驾驭马匹一样，需要给予适当的信号和引导。
"Is Claude smart enough to write rank the right tool for the right job? ... I think all of these things are like an intuition..."
为了进一步优化搜索效果，元数据（Metadata）的添加成为另一个重要策略。观众建议为电子表格添加描述性文档或 KPI 说明，帮助智能体理解数据背后的业务含义。这种预处理步骤可以包括让另一个智能体对表格进行标注，从而丰富搜索的上下文。尽管有观点认为读取表头并获取数据是“琐碎”的任务，但演讲者指出，实际构建中这非常困难，需要结合公式设计（如 Excel 公式）和复杂的逻辑判断，而非简单的文本匹配。
上下文收集的创造性与工具多样性
在构建 Agent 搜索界面时，设计者需要充分利用模型已知的结构化数据格式，如 B3-B5 范围、SQL 查询或 XML 格式。演讲者指出，上下文收集是一个极具创造性的过程，而非简单的技术实现。由于 XML 文件在底层本质上是结构化的，Agent 能够很好地处理此类查询。然而，仅依赖单一迭代往往不够，开发者应尝试多种组合，包括 SQL、grep、awk 等工具，并通过测试观察 Agent 对不同工具的偏好。
"Gathering context is really creative... there's so many iterations... try SQL or try the search try the grep and awk and like all of these things."
这种多样性测试至关重要，因为每个案例中 Agent 的表现可能截然不同。开发者不应假设某种工具在所有场景下都最优，而应通过实际测试来确定最佳实践。这种灵活性允许 Agent 在面对复杂任务时，能够动态选择最有效的信息获取方式，从而提升整体任务执行的准确性和效率。
分布内与分布外问题的处理策略
理解 Agent 的知识边界是设计的关键。Agent 通常对广泛分布内（in-distribution）的问题非常熟悉，例如金融领域的 DCF 模型或通用的 SQL 操作。然而，当问题涉及互联网上不存在或独特的信息（即分布外，out-of-distribution）时，开发者需要采取措施将问题“重塑”为更接近分布内的形式。
"Ideally, you want to like your problem is going to be out of distribution in some way... you want to try and like massage it to be as in-distribution as possible."
演讲者强调，这更像是一门艺术而非科学。开发者可以通过创建特定的“技能”（skills）来增强 Agent 的能力，但其核心在于让 Agent 尽可能利用其预训练知识。如果问题过于独特，可能需要通过提供额外的上下文或工具，帮助 Agent 更好地理解和处理这些非标准任务，从而缩小分布内外的差距。
上下文收集与行动执行的 API 一致性
上下文收集（Gathering Context）与采取行动（Taking Action）在技术实现上往往具有高度的相似性。例如，两者都可能涉及 SQL 查询、XML 编辑或数组插入操作。因此，为 Agent 提供一致的后端 API 接口至关重要。这种一致性不仅简化了开发流程，还降低了 Agent 在切换不同任务类型时的认知负荷。
演讲者指出，如果 Agent 能够通过 SQL 接口执行查询以收集上下文，那么它很可能也能通过相同的接口执行更新或删除操作。这种API 的复用性使得开发者可以构建更简洁、更高效的 Agent 系统。同时，这也意味着开发者在设计工具集时，应优先考虑工具的通用性和兼容性，以便 Agent 能够无缝地在信息获取和执行操作之间切换。
验证机制与子代理（Sub-agents）的上下文管理
关于工作验证（Verifying Work），常见的做法包括检查空指针等错误。然而，演讲者分享了一种更高级的策略：创建独立的 QA Agent 进行验证。由于开发者可能不信任主 Agent 自我验证的准确性，引入一个专门用于质量控制的子代理可以提高结果的可靠性。这种方法在网络安全等高风险领域尤为重要。
"I actually end up creating a separate agent for QA... to verify because I don't trust the agent to verify itself."
此外，子代理（Sub-agents）是管理上下文窗口的重要方式。通过将大任务分解为多个子任务，每个子代理可以专注于特定的上下文，从而避免主上下文窗口过载。演讲者建议，开发者应像给被困在房间的人提供工具一样，赋予 Agent 搜索和解决问题的能力，而不是直接提供所有信息。这种“给予工具而非答案”的思路，鼓励 Agent 自主探索和执行，从而更有效地利用有限的上下文资源。
子代理在复杂搜索任务中的应用策略
在构建Agent系统时，子代理（Sub-agents） 是处理高复杂度任务并返回结果给主代理的理想架构。以“查找2026年收入”为例，主代理无需将所有中间过程放入上下文，而是委派子代理执行互联网搜索、电子表格检索等大量解析工作。这种模式的核心优势在于避免上下文污染，主代理仅关注最终结果，从而保持对话历史的简洁与高效。
“子代理非常适合那些需要做大量工作并将答案返回给主代理的场景。”
这种分工不仅限于搜索，还适用于验证（Verification）环节。例如，在网络安全对抗场景中，可以设立一个专门的子代理来 adversarially（对抗性地）检查主代理的输出。通过启动新的上下文会话，子代理可以模拟“麦肯锡初级分析师”等角色，对主代理的工作进行批判性审查。随着模型推理能力的提升，这种基于子代理的验证机制将变得更加可靠，成为提升Agent整体质量的关键手段。
验证机制：从确定性规则到模型推理
在实施验证时，确定性规则（Deterministic Rules） 应作为首选方案。相比于依赖模型推理，基于规则的验证更为可靠且成本更低。例如，在Cloud Code中，如果Agent试图写入未读取的文件，系统会直接抛出错误，提示其先读取文件。这种确定性工具在验证步骤中起到了关键作用，它通过预设的逻辑约束，防止Agent犯下低级错误。
“理想情况下，最好的验证形式是基于规则的……尽可能多地插入规则。”
选择Agent类型时，具有更多确定性规则的Agent表现更好。这是因为确定性规则提供了明确的边界，减少了模型幻觉的风险。虽然随着模型推理能力的增强，子代理可以进行更复杂的逻辑检查，但第一步始终是确定性的验证。这种分层验证策略——先规则后模型——能够最大限度地平衡效率与准确性，确保Agent在复杂任务中的稳定性。
状态可逆性：Agent设计的核心直觉
在处理生产环境中的错误时，状态的可逆性（Reversibility） 是评估Agent适用性的关键指标。代码操作通常具有高度的可逆性，例如通过版本控制（git）可以轻松回滚。相比之下，计算机使用（Computer Use） 场景中的状态往往不可逆。例如，在DoorDash上订餐时，如果错误地添加了Pepsi，用户必须手动进入购物车移除，而不能简单地“撤销”点击动作。这种状态机的复杂性会随着错误操作而累积，导致修复难度增加。
“代码是非常可逆的……而计算机使用在状态上并不可逆。”
因此，工程师在设计Agent时，应思考如何将复杂的状态机转化为可逆的状态机。这包括在检查点之间存储状态，使用户能够回滚到之前的状态，甚至让Agent具备“时间旅行”工具，回退到错误发生前的节点。这种设计思路不仅适用于电子表格操作，也适用于任何涉及状态变更的场景，确保Agent在犯错时具备自我修复或用户干预的能力。
海量数据场景下的上下文管理思维
在处理包含十万列或百万行级别的超大规模数据集（如电子表格）时，核心挑战在于如何避免将全部数据强行加载至模型上下文窗口中，因为这不仅成本高昂且会显著降低准确率。模型在大型代码库或数据集中的表现通常弱于小型数据集，因此必须采用类似人类处理 Excel 的逻辑：先加载初始可见部分，通过搜索定位关键信息，并在“草稿纸”上记录引用关系，逐步构建上下文。这种策略强调按需获取上下文而非一次性全量摄入，模型应像用户操作软件一样，主动导航至特定工作表或区域，读取必要数据后记录笔记，再继续下一步操作，从而在保持精度的同时控制资源消耗。
“我永远不会建议把整个电子表格读入上下文，因为那会占用太多资源。你应该给它初始的上下文量，就像你打开电子表格时只能看到前几行和几十列一样。”
上下文窗口使用的经验法则与 UX 设计
关于何时开始压缩上下文或何时出现收益递减，目前并无绝对固定的比例规则，但在代码生成场景中，状态主要存储在文件本身而非对话历史中。因此，开发者可以频繁清空上下文窗口，让模型直接读取 Git Diff 或当前文件状态来继续任务，而无需保留漫长的聊天历史。然而，对于面向非技术用户的 Agent（如电子表格助手），由于用户不理解上下文窗口的概念，上下文管理更多是一个用户体验（UX）设计问题。建议通过自动总结、重置对话状态或存储用户偏好来优化体验，避免让模型维护数百万 token 的冗余上下文，而是通过智能的状态重置和摘要机制来最小化上下文使用量，确保 Agent 能高效处理新任务。
子代理并行处理与 Anthropic 的工程优势
为了进一步保护主代理（Core Agent）的上下文并提升效率，子代理（Sub-agents）是 Agent SDK 中的关键原语，特别适用于将大型任务（如处理超大电子表格）分块并行处理。例如，主代理可以同时启动多个子代理分别读取和总结不同的工作表，最后汇总结果。Anthropic 在实现这一机制时，特别是在结合 Bash 工具进行并行子代理运行时，解决了复杂的竞态条件（Race Conditions）问题。Thariq 指出，Claude Code 在使用子代理方面提供了最佳体验，其底层的 Bash 工具经过专门优化，能够安全地并行执行多个子代理任务，这是其他框架难以比拟的工程优势。通过这种分层和并行架构，Agent 既能保持主上下文的整洁，又能利用并行计算加速大规模数据处理。
“子代理是为了保护核心代理的上下文而设计的。你可以让多个读取子代理同时运行，比如分别总结工作表一、二、三，然后返回结果。”
抽象底层工程，聚焦核心业务逻辑
在构建 Agent 系统时，开发者往往容易陷入对底层系统工程的过度关注，例如纠结于如何启动子代理进程或处理复杂的后台机制。演讲者强调，开发者不应将精力耗费在如何拆分进程或理解 Compactor 等底层实现上，因为 Anthropic 的 Agent SDK 已经将这些繁琐的工程细节封装在 Harness 中。这种设计哲学的核心在于让开发者专注于解决真正核心且困难的问题，例如确定需要启动哪些子代理、如何设计遗传搜索接口以及如何验证其工作成果。任何在低层问题上花费的时间，本质上都是在偏离为用户创造价值的轨道。
"Any time you spend not solving these problems [core business logic] and solving like lower-level problems, uh you're probably not delivering value to your users."
这种抽象使得开发者能够以更高的视角审视问题，将系统工程的负担交给 SDK 处理，从而确保团队资源集中在提升产品核心竞争力的关键路径上。通过屏蔽底层复杂性，Agent SDK 旨在让开发者从繁琐的基础设施维护中解放出来，直接应对业务逻辑中的挑战。
验证机制的全局化与动态反馈
关于验证（Verification）的放置位置，演讲者指出验证不应仅局限于流程的终点，而应尽可能多地嵌入到各个环节中。以生成 SQL 查询为例，开发者可以选择在生成后直接验证查询的正确性，或者在执行后验证输出结果。更高级的做法是利用规则或启发式方法在中间环节进行动态干预。例如，如果规则规定搜索的列数不应超过 10,000 列，模型在检测到潜在违规时，可以通过错误反馈立即收到提示，并被要求将操作分块处理。
"Verification can happen anywhere and should happen in anywhere. Like like put it in as many places you can."
这种机制的关键优势在于模型能够理解并响应错误反馈。当模型收到类似“请分块处理”的指令时，它会读取错误输出并继续执行后续步骤。因此，验证是一个持续的过程，通过在多个节点设置检查点，可以显著降低最终错误发生的概率，并确保模型在每一步都符合预期的约束条件。
赋予 Agent 智能决策的自由度
在定义 Agent 的执行步骤时，开发者无需强制规定严格的线性流程（如“先搜索，再执行，最后验证”）。相反，应在系统提示词（System Prompt）中提供工具和上下文，让 Agent 自行判断最佳路径。例如，在使用 Claude Code 时，只需赋予其 Bash 工具权限，并指示其收集上下文、读取文件或运行 linting，Agent 就能根据任务性质灵活选择动作。
如果用户只是询问电子表格的只读数据，Agent 无需执行编译检查或写入操作；只有当涉及写入操作时，才需要相应的验证步骤。这种设计类似于给予人类员工工作自由，信任 Agent 的智能来判断何时需要验证，何时可以跳过。强制性的步骤约束不仅冗余，还可能阻碍 Agent 处理简单任务的效率。因此，通过提供工具而非限制流程，可以让 Agent 展现出更自然、更高效的决策能力。
快速原型开发与“简单但不容易”的理念
构建 Agent 的过程应当简单，但简单并不等同于容易。演讲者建议开发者利用 Claude Code 进行快速原型开发：提供 API 密钥、脚本库和自定义身份，让 Agent 直接处理如“按优先级整理客户支持工单”等具体任务。通过观察 Claude Code 的行为并迭代，开发者可以快速跳过基础工程问题，直接切入领域特定的难点，如数据组织、遗传搜索或数据库护栏设置。
"Simple is not the same as easy, right? So, like it should be very simple to get started, and it is."
最终的目标是构建代码量精简但逻辑优雅的 Agent。例如，将电子表格转换为 SQL 查询，再基于 SQL 进行操作，这种思路既简洁又高效。演讲者以“Pokémon Agent”为例，说明通过本地快速原型验证，开发者可以在短时间内获得高质量结果，从而建立对系统的信心。关键在于让模型处理其擅长的转换任务，而非编写复杂的控制逻辑。
项目背景与 PokéAPI 的复杂性选择
本次工作坊的核心目标是构建一个能够协助用户组建宝可梦对战队伍的智能代理（Agent）。演讲者 Thariq Shihipar 特意选择了 PokéAPI 作为数据源，原因在于该 API 具有极高的复杂性，涵盖了成千上万的宝可梦、丰富的技能树以及物品系统等游戏内所有元素。这种非标准化的复杂 API 能够很好地模拟真实世界中开发者面临的独特接口挑战，从而验证 Agent 在应对未知或复杂数据结构时的泛化能力。
"I want to choose something with the kind of complex API that I haven't tried before."
演讲者指出，虽然用户可能希望 Agent 帮助组建具有竞争力的对战队伍，但首先需要解决的是数据获取与结构化的问题。通过让 Agent 理解 PokéAPI 的架构，包括搜索特定宝可梦（如 Ditto）、查询物品等，可以建立一个通用的基础。这一阶段的目标不仅仅是简单的问答，而是让 Agent 能够深入理解 API 的逻辑，进而执行更复杂的任务，如生成 TypeScript 库来封装这些 API 调用，为后续的智能交互奠定代码基础。
代码生成与 TypeScript SDK 的构建
为了简化后续的开发流程，演讲者首先演示了如何利用 Claude 进行代码生成。通过输入提示词 "Hey, I go search Poké API for its API and create a TypeScript library"，Agent 成功生成了一个完整的 TypeScript SDK。这个 SDK 包含了定义清晰的接口，例如 getByName、list、getAll 等，涵盖了宝可梦本体、物种、能力、类型以及技能等关键模块。
生成的代码结构如下表所示，展示了 SDK 的核心功能模块：
| 模块/功能 | 描述 | 关键方法示例 |
|---|---|---|
| Pokémon 本体 | 获取单个或列表宝可梦信息 | getByName, list, getAll |
| 物种信息 | 获取宝可梦的物种详情 | getSpecies |
| 能力数据 | 查询宝可梦的技能/能力 | getAbilities |
| 技能数据 | 查询招式/技能信息 | getMoves |
"It's created this like interface for Pokémon... It also did it for moves."
演讲者强调，这种自动生成库的方式极大地降低了与复杂 API 交互的门槛。生成的代码允许开发者通过 import { PokéAPI } from 'PokéAPI SDK' 的方式直接调用，无需手动处理 HTTP 请求和 JSON 解析。此外，他还提供了示例脚本（位于 examples 目录），这些脚本不仅展示了如何使用 SDK，还可以由 Agent 执行以辅助查询。这种代码即文档、代码即工具的模式，使得 Agent 能够基于生成的类型定义进行更准确的推理和操作。
工具调用与 Chat 接口的实现
在 SDK 构建完成后，演讲者展示了另一种实现方式：直接使用 Messages Completion API 并定义一系列工具（Tools）。这种方式不依赖预生成的 SDK，而是让 Agent 在运行时动态调用工具。定义的工具包括 getPokemon、getPokemonSpecies、getPokemonAbility、getPokemonType 和 getMove 等。由于 PokéAPI 数据量巨大，Agent 不会生成所有可能的工具，而是根据上下文选择最相关的几个。
为了演示这一过程，演讲者使用 Bun 运行时环境创建了一个简单的聊天界面（chat.ts）。选择 Bun 的原因在于其内置 linting 和无需编译 TypeScript 的特性，这简化了 Agent 的操作流程，避免 Agent 需要记住编译步骤。在运行 Bun chat 后，用户输入 "What are the generation two water Pokémon?"，Agent 开始执行工具调用。
工具调用的日志输出如下表所示，展示了 Agent 的思考与执行路径：
| 步骤 | 动作 | 详细信息 |
|---|---|---|
| 1 | 工具调用 | 搜索 Generation 2 的水系宝可梦 |
| 2 | 结果处理 | 识别出 Totodile, Croconaw, Feraligatr |
| 3 | 最终回复 | 列出符合条件的宝可梦名称 |
"It's got Totodile, Croconaw, Feraligatr. You can see sort of like how it's like in between each step it's thinking through the previous steps."
演讲者特别指出，记录工具调用日志至关重要。通过 console.log 输出助手消息，开发者可以清晰地看到 Agent 是如何一步步思考并执行操作的。这种透明度不仅有助于调试，也展示了 Agent 在处理多步推理任务时的逻辑链条。虽然这个 Chat 接口使用的是普通 API，但它为后续引入更高级的 Agent SDK 功能奠定了基础。
Claude Code 集成与后续展望
最后，演讲者切换到 Claude Code 环境，展示如何在实际开发中集成这些功能。他删除了之前的示例脚本，以确保 Agent 不会“作弊”，而是真正理解并生成新的代码。在 Claude Code 中，他再次询问 "Can you tell me all the generation two water Pokémon?"，观察 Agent 的反应。
演讲者提到，他需要删除某些文件以避免干扰 Agent 的判断，这体现了在自动化代码生成过程中，环境纯净度的重要性。此外，他还简要提及了 SDK 中的不同上下文、动作和验证机制，暗示了后续将深入探讨 Agent SDK 的核心架构。通过对比普通 API 的工具调用和 Claude Code 的代码生成能力，演讲者展示了 Anthropic 工具链在提升开发者效率方面的巨大潜力。
"I think it'll be fine. We'll see what happens."
这一部分不仅展示了技术实现，还强调了迭代开发的重要性。通过不断调整提示词、清理环境并观察 Agent 的行为，开发者可以逐步优化 Agent 的性能和准确性。演讲者最后提到将回到 SDK 部分，进一步解释如何将这些能力封装成更通用的 Agent SDK，供更广泛的开发者社区使用。
代码生成与自动化脚本演示
在演示环节中，演讲者展示了如何利用 Claude Code 进行高效的代码生成与自动化任务处理。通过简单的自然语言指令，AI 能够理解复杂的查询意图并自动生成相应的执行脚本。例如，当被要求查找特定属性的宝可梦时，AI 并没有直接调用预设的 Google API，而是选择自主编写脚本来从外部数据源获取信息。这种能力体现了 AI 在上下文工程和工具使用上的灵活性，它可以根据任务需求动态决定最佳的数据获取路径。
"It's given me a lot more... it knows like, okay, the start of the generations. It fetches these for API."
在实际操作中，AI 成功识别了“第二世代水系宝可梦”这一概念，并自动生成了遍历超过 200 个宝可梦数据的脚本。它不仅检查了每个宝可梦的类型，还提取了相关信息，最终列出了所有符合条件的结果。这一过程展示了代码生成在实际应用中的潜力：用户无需手动编写繁琐的数据抓取逻辑，只需描述目标，AI 即可完成从逻辑构思到代码执行的全过程。这种自主性大大降低了开发原型和进行数据探索的门槛。
高级用例：基于 Smogon 数据的团队构建
为了展示更复杂的数据处理能力，演讲者引入了一个基于 Smogon 数据的进阶案例。Smogon 是一个拥有庞大文本数据库的在线平台，存储了关于宝可梦属性克制、技能搭配以及团队协同等详尽的竞技数据。演讲者将这部分数据放入工作目录，并向 AI 提出一个开放性问题：“基于 Smogon 数据，请为妙蛙花（Venusaur）推荐一些队伍搭配建议。”
这一案例的核心在于让 AI 从第一性原理出发，在没有预先见过这些数据的情况下，自行分析文本文件中的逻辑关系。AI 需要理解哪些宝可梦与妙蛙花相性良好，哪些存在克制关系，从而构建出一个逻辑自洽的队伍。这不仅是对 AI 代码生成能力的测试，更是对其推理能力和数据洞察能力的挑战。通过这种方式，用户可以快速获得基于大量隐藏数据的策略建议，而无需手动查阅复杂的数据库或编写复杂的分析算法。
生产环境部署：Agent SDK 与沙箱架构
在问答环节，演讲者探讨了如何将此类 AI 应用从本地演示转化为生产级服务。他明确指出，虽然 Claude Code 是一个优秀的本地前端应用，但在面向客户部署时，需要考虑不同的架构方案。主要有两种路径：一是开发本地安装应用，利用 AI 降低本地应用的开发开销；二是将应用托管在云端沙箱中。
"I think that like local apps might be coming back with AI... the other way is, yeah, you have host it in a sandbox."
演讲者重点介绍了使用 Agent SDK 进行云端部署的简便性。以 Cloudflare 为例，开发者只需启动一个沙箱实例，并指定执行脚本（如 bun agent.ts），即可实现与 AI 代理的通信。这种架构通过沙箱隔离确保了安全性和稳定性，同时利用 SDK 抽象化了底层基础设施的复杂性。每个用户请求可以对应一个独立的沙箱实例，这种每用户一沙箱的模式虽然资源消耗较大，但提供了极高的安全性和隔离性，是当前 AI 代理应用的主流部署范式之一。
文件系统作为上下文工程的核心
在整个演示和架构讨论中，演讲者反复强调了一个关键概念：文件系统即上下文工程（Context Engineering）。在 Agent SDK 的实现中，实际的代理代码可能只有短短 50 行，大部分是样板代码。真正的智能来源于输入给代理的文件结构和数据内容。
通过精心设计的文件目录结构，开发者可以引导 AI 的行为边界。例如，通过限制 AI 只能在特定目录下编写脚本，可以有效防止其执行不受控的操作。这种基于文件的上下文管理方式，使得代理的行为更加可预测和安全。演讲者指出，这种模式不仅适用于简单的数据查询，也适用于复杂的逻辑推理任务。通过将数据、规则和执行环境分离，开发者可以构建出既强大又可控的 AI 代理系统，为未来的AI 原生应用开发提供了重要的架构参考。
构建实时自适应的Agent用户界面
在开发带有用户界面（UI）的Agent时，实时适应不同用户需求是一个核心挑战。以“Pokémon Agent”为例，不同用户可能关注团队建设、游戏辅助或单纯获取图片。为了实现这种动态适配，推荐采用沙箱环境（Sandbox）+ 开发服务器（Dev Server）的架构。具体而言，在沙箱中运行一个基于Bun或Node.js的开发服务器，并暴露特定端口。Agent可以直接编辑代码，并通过热重载（Live Refresh）机制实时更新前端界面。用户通过浏览器与该网站交互，从而获得个性化的体验。这种模式被Lovable等网站构建工具广泛采用，其本质是向用户托管开发服务器，使Agent能够根据实时反馈调整UI逻辑。
“The agent could edit code, and it would live refresh. And your user would be interacting with that website.”
在实际演示中，Agent展示了强大的自主分析与代码生成能力。它首先搜索“Venusaur”（妙蛙种子）及其相关类型，进而挖掘出常见的队友和克制对手。随后，Agent基于文本文件数据，编写脚本进行统计分析，生成基础属性、技能组合及队友建议。这一过程完全由Agent自主完成，从数据搜索到脚本编写再到结果呈现，体现了端到端的自动化工作流。虽然预处理文本文件可进一步优化流程，但当前方案已能展示Agent在复杂任务中的上下文理解与代码执行能力。
Agent SDK的商业化与定价策略
关于Cloud Code SDK的商业化路径，演讲者指出，目前Agent技术仍处于早期阶段，模型成本较高，因此定价策略需慎重设计。首要原则是解决用户愿意付费的痛点，即聚焦于那些具有“硬需求”（Hard Problem）的场景。在商业模式上，可采用订阅制或基于Token的使用量计费。具体选择取决于用户的使用频率：对于高频使用的产品（如Cloud Code），可结合速率限制（Rate Limits）与超额使用费；对于低频使用场景，则可能更适合固定订阅。演讲者强调，商业化设计应在产品初期就融入架构，因为一旦流程定型，后续调整将非常困难。
“Monetization is something you should think about up front and design your agent around because it's hard to walk back these processes.”
此外，针对将现有原型转化为Agent SDK产品的疑问，建议采取渐进式迁移策略。首先，总结原型阶段的有效交互，将其提炼为清晰的cloud.md指令文件，明确API调用规范（如避免生成不必要的JavaScript）。其次，保留必要的辅助脚本，并编写专门的测试入口（如agent.js）。这种从原型到生产环境的平滑过渡，既能保留已验证的逻辑，又能利用Agent SDK的结构化优势，避免重复造轮子。
Hooks机制：确定性验证与上下文注入
Hooks（钩子）是Agent SDK中用于实现确定性验证和上下文动态注入的关键机制。通过注册Hooks，开发者可以在Agent执行特定事件（如工具调用前后）时插入自定义逻辑。例如，在每次操作电子表格后，Hook可以触发验证脚本，确保数据完整性。更高级的用法是处理并发上下文冲突：当Agent正在修改电子表格，而用户也同时进行了更改时，Hook可以在每次工具调用后，将用户的最新更改注入到Agent的上下文中。这种机制使得Agent能够感知实时环境变化，从而做出更准确的决策。
“Hooks are a way of doing deterministic verification in particular, or inserting context.”
对于测试用例的优化，演讲者建议通过增加重试次数和细化比较逻辑来提升准确性。例如，当Agent生成的脚本未能直接通过测试时，可让其尝试多次执行，并输出详细的对比表格。这种迭代式调试方法，结合清晰的错误反馈，能显著提高Agent在复杂任务中的成功率。尽管Hooks功能强大，但文档中已有详细指南，开发者可参考官方示例快速上手，实现更精细的Agent行为控制。
利用Hooks增强Agent行为的确定性
在构建AI Agent时，开发者常面临一个核心挑战：如何确保Agent在已知答案的情况下仍遵循特定的执行流程。这种“对抗性”引导旨在防止Agent跳过必要步骤，例如在生成最终响应前未编写脚本或读取数据。为了解决这一问题，Hooks（钩子）机制被提出作为一种有效的干预手段。通过Hooks，开发者可以在Agent执行过程中插入检查点，强制其完成特定动作。
"You can use hooks to like give that feedback in the same way that in cloud code um we have these like rules like make sure you read a file before you write to it."
这种机制类似于Claude Code中的规则设定，即在写入文件前必须先读取文件。通过这种方式，开发者可以为Agent增加确定性（Determinism），减少因模型随机性导致的流程遗漏。尽管这被视为一种“艺术”，但在处理复杂任务时，这种强制性的反馈循环是保证输出质量的关键。开发者需要仔细设计Hook逻辑，以平衡Agent的自主性与流程的规范性，确保每一步操作都符合预期。
大型代码库的索引与搜索困境
当Agent面对超过5000万行代码的大型代码库时，传统的搜索工具往往失效。演讲者指出，在如此庞大的代码基数下，grep工具不再有效，因为无法通过简单的字符串匹配来定位相关逻辑。为应对这一挑战，开发者不得不构建自定义的语义索引（Semantic Indexing）系统，以帮助Agent理解代码结构和上下文。
然而，这种定制化方案带来了显著的复杂性。与小型项目不同，大型项目需要更精细的索引策略，否则Agent容易迷失在海量代码中。这引发了一个产品层面的思考：这些为特定场景构建的工具在几个月后是否会被淘汰？ 尽管AI技术迭代迅速，但在处理超大规模代码库时，语义搜索仍是当前不可或缺的补充手段。开发者需要在通用模型能力与专用索引工具之间找到平衡，以应对不断变化的代码库规模。
语义搜索的局限性与最佳实践
针对大型代码库的搜索问题，演讲者进一步分析了语义搜索（Semantic Search）的局限性。虽然语义搜索看似智能，但它实际上比传统搜索更脆弱（Brittle）。主要原因在于，模型并未针对语义搜索进行专门训练，导致其在处理特定查询时可能出现偏差。相比之下，grep等工具因其简单的匹配逻辑而更加可靠。
"Semantic search this is a cloud code question more than an agent SDK question... it's more brittle... the model's not trained on semantic search."
对于拥有大型代码库的客户，Anthropic观察到的最佳实践并非依赖复杂的语义索引，而是优化.claude配置文件和目录结构。具体建议包括：从目标目录开始工作，并设置严格的验证步骤（Verification Steps）。通过良好的项目结构和Hooks配置，开发者可以在不使用定制语义搜索的情况下，有效引导Agent处理大规模代码。这种方法降低了技术复杂度，提高了系统的稳定性，是应对大型代码库更务实的选择。