来源： YouTube | Jared Zoneraich（PromptLayer 创始人）| NYC AI Engineering Workshop 压轴场 原文发表： Dec 26, 2025 纪要生成： 2026-02-22
Jared Zoneraich 是 PromptLayer 的创始人，这是一个面向 AI 工程师团队的提示词管理、日志记录与测试平台，总部位于纽约，已运行三年，每天处理数百万次 LLM 请求。本次演讲是一个约 800 人参加的 NYC AI Engineering Workshop 的最后一场，也是全场压轴。内容完全基于 Jared 深度使用各类编程 Agent 的第一手经验，以及与 PromptLayer 客户大量对话所积累的洞察，非 Anthropic 官方内容，Jared 本人也多次强调这一点（甚至笑称因为演讲标题被 Anthropic"批评"过）。
本节重点 - Jared 的团队已将整个工程组织围绕 Claude Code 重构，制定了"一小时内能用 Claude Code 搞定的直接做，不排优先级"的规则 - 演讲目标：理解编程 Agent 为何突然变好、内部机制是什么、如何应用于自己的 AI 工程实践 - 演讲定性：个人观点，非官方背书，但基于大量第一手使用经验
详细精要
Jared 在自我介绍中描述了 PromptLayer 的核心理念：严格的提示词工程（Rigorous Prompt Engineering）和严格的 Agent 开发。他们相信 AI 产品开发必须让多方参与——产品团队、工程团队，乃至领域专家。如果你在做 AI 律师工具，就应该让律师参与进来，而不只是工程师。这个理念决定了他们对 AI 工程工具的理解方式：不是单纯的技术问题，而是协作与专业知识的融合。
关于 PromptLayer 当前状态：小团队（有意保持小规模），产品已运行三年（在 AI 领域算很长，但对其他行业还很早期），每天处理数百万次 LLM 请求，Jared 本人花大量时间"Dog-fooding"（用自己的产品来构建 Agent）。
对于 Claude Code 的实际使用体验，他分享了一个具体的工程管理案例：PromptLayer 作为一个平台产品，需要处理极大量的边界情况——数据集上传失败、各种 edge case——过去工程师会把这些问题放进优先级队列，反复讨论是否值得修。引入 Claude Code 后，团队制定了一条规则：凡是用 Claude Code 能在一小时内完成的任务，直接做，完全不排优先级。这条规则从根本上改变了工程团队的工作节奏，让小团队能处理以前需要更大团队才能覆盖的问题范围。
💬 这件事让我们真的上了一个新台阶。我们是有意保持小团队的，但 Claude Code 帮了大忙。
"We made a rule for our engineering organization: if you can complete something in less than an hour using Claude Code, just do it. Don't prioritize it. And we're a small team on purpose but it's helped us a lot and I think it's really taken us to the next level."
本节重点 - 编程 Agent 经历了四个清晰的演化阶段，每一步都有质变 - Claude Code 代表了当前最新形态：彻底的"无界面"工作流，Agent 自主完成所有操作 - 突破的核心原因：模型变好（最重要）+ 架构变简单（协同效应）
详细精要
Jared 梳理了编程 Agent 的历史演变路径，帮助理解"为什么是现在"：
第一阶段：ChatGPT 复制粘贴时代 最原始的工作流：把代码复制进 ChatGPT，把回复复制出来，再贴回编辑器。虽然原始，但在当时已经是革命性体验，很多开发者因此第一次感受到 AI 辅助编程的可能性。
第二阶段：Cursor 1.0（Command K 时代） Cursor 1.0 本质上是 VS Code 的分支版本加上 Command K 快捷键。Jared 坦言当时软件本身"并不好用"，但大家愿意试因为"没什么可失去的"——只是个 VS Code 分支而已。这种低门槛试用策略后来被证明是极其成功的产品决策。
第三阶段：Cursor Assistant（来回对话的 Agent 模式） 引入了 Agent 风格的来回对话，开始有了一些自主执行的能力，但仍然高度依赖 IDE 界面。
第四阶段：Claude Code（无界面工作流） Claude Code 代表的是完全不同的范式：不触碰代码，也不需要 IDE。Agent 在终端里自主运行，自己读文件、改文件、运行命令、验证结果。这要求 Agent 非常可靠，任何失误都没有图形界面作为缓冲。Jared 指出这是"工作流的质变，不只是工具的升级"。
关于"为什么是现在才变好"，Jared 给出了他认为诚实但"有点无聊"的答案：一是模型变好了，这是最核心的原因——Anthropic 持续发布了在 Tool Calling 上优化得更好的模型；二是架构变简单了，但这两者是相辅相成的。更好的模型让简单架构成为可能，简单架构又让模型的能力得到充分发挥。
💬 大部分突破坦白说有点无聊——就是 Anthropic 发布了一个更好的模型，在工具调用这类任务上表现更好。
"I think a lot of the breakthrough is kind of boring in that it's just Anthropic releasing a better model that works better for these type of tooling calls and these type of things."
本节重点 - 核心哲学一句话：给它工具，然后让它自己干（Give it tools and get out of the way） - Tool Call 取代了过去所有复杂的 JSON 格式化、分类、路由机制 - 工程师的本能是过度优化——这是要主动抵制的冲动 - Python 之禅是理解 Claude Code 架构的最好注脚
详细精要
Jared 解释了工具调用（Tool Call）作为新抽象层的意义：它取代了过去开发者需要手写的各种 JSON 格式化库（比如早期流行的 JSONformer），把"让模型输出结构化数据"这件事标准化了。模型现在专门为 Tool Calling 做了训练，并且还在持续变好。
警惕工程师的过度优化本能：Jared 特别强调了这一点，因为这是他自己也犯过的错误。当你刚开始思考如何构建一个 Agent 时，工程师的本能会驱动你说："我要用这个 Prompt 防止幻觉，再用这个 Prompt 处理边界情况，然后在这里加一个分类器，那里加一个路由……"。他的建议是：不要这样做。就用一个简单的循环，让模型自己干，删掉所有脚手架。 Less scaffolding, more model（更少脚手架，更多模型），这是他的核心口号。
关于"不要为今天的模型缺陷过度工程化"，Jared 引用了 Anthropic 内部的一种思考方式（他称之为"AGI 药丸"）：你今天为了绕过模型局限性而搭建的复杂系统，在未来几个月内会随着模型变强而过时。花在这上面的工程时间是浪费的。
Claude Code 的哲学体现在它扔掉了什么： - Embeddings（词向量嵌入）：用 Grep/Glob 代替向量搜索 - Classifiers（分类器）：让模型自己判断，不用专门的分类模型 - Pattern Matching（模式匹配）：不需要预先定义各种匹配规则 - RAG（检索增强生成）：用简单的搜索工具代替复杂的向量检索管道 - 复杂分支的工作流：用单一的 while 循环代替多分支 DAG
Python 之禅的类比：Jared 展示了 import this 的输出，并指出这几条原则直接对应 Claude Code 的设计决策：Simple is better than complex（简单胜于复杂）、Complex is better than complicated（复杂胜于繁复）、Flat is better than nested（扁平胜于嵌套）。他说："这就是整个演讲的核心。你只需要知道这些，就理解了 Claude Code 为什么有效。"这不是营销说辞，而是回归了软件工程的第一原则。
💬 给它工具，然后让它自己干——这就是今天架构的一句话总结。
"Give it tools and then get out of the way is what a one-liner of the architecture is today."
本节重点 - 所有工具的设计原则：模拟人类在终端操作的方式，不是发明新范式 - Edit 使用 Diff（差异）而非重写整个文件，是节省 Token 和减少错误的关键 - Web Search/Fetch 被路由到更便宜更快的子模型，不占用主循环资源 - 工具列表每天都在变化，今天的清单不是终态
详细精要
Jared 逐一拆解了 Claude Code 的核心工具，并强调了一个贯穿始终的设计原则：所有工具都是在模拟人类开发者在终端会做的事。没有发明新的工作范式，只是把人类的自然操作封装成模型可以调用的接口。
Read 工具
表面上只是 cat 命令，但专门处理 Token 上限问题。当你使用 Claude Code 时会看到"这个文件太大了"之类的提示，这就是 Read 工具在工作——它不是直接把整个文件扔给模型，而是有智能的截断和提示机制。
Grep/Glob 工具
用搜索代替 RAG（检索增强生成），这在当时是反直觉的选择。RAG 的做法是：建立向量数据库，把代码 Embedding 化，用语义搜索找相关内容。Claude Code 的做法是：直接用 Grep 搜索关键词，就像开发者在终端里会做的那样。Jared 指出这不是说 RAG 没有价值，而是在通用编程 Agent 的场景里，Grep/Glob 足够好，而且更简单、更可靠。
Edit 工具（Diff 实现）
Jared 认为这是最值得关注的设计之一。Edit 工具绝大多数时候不重写整个文件，而是使用统一 Diff（Unified Diff）格式做增量修改。他用了一个生动的类比：给你一篇文章，让你修改后默写全文 vs. 让你在原文上划线标注改动——后者显然更快、错误更少、消耗的 Token 也更少。Diff 是防止错误的天然机制，因为改动范围被明确限定了。他后来还特别提到这值得用一整张幻灯片来讲，并推荐所有构建 Agent 的人都采用 Unified Diff 作为标准。
Bash 工具
最重要的工具，后面专门有一节讲。
Web Search / Web Fetch
这两个工具有一个特别的设计：它们会把任务转发给更便宜、更快的子模型来处理，而不是让主模型（Claude）去做。Jared 举例说，如果你在构建一个 Agent，需要它访问一批 API Endpoint，这类任务可以下沉到"子层级"处理，不占用主循环的高成本模型资源。这是成本控制和性能优化的实际体现。
Todo 工具
保持模型在正确轨道上的核心机制，后面专门讲。
Task 工具（子 Agent）
上下文管理的核心答案。每个 Task 有自己完全独立的 Context Window，只把结果返回主循环，不污染主上下文。后面专门讲。
Jared 最后提醒：这个工具列表每天都在变化，Anthropic 几乎每隔几天就有新版本发布。今天可能是这几个工具，明天可能多 15 个，后天可能缩减到 5 个，这是一个快速迭代的领域。
本节重点 - Bash 是所有工具中最重要的：简单、万能、训练数据最丰富 - Claude Code 创建 Python 临时脚本、运行、删除——这是整个系统能力的象征 - Todo 完全靠 Prompt 实现，没有代码层面的强制，但现在的模型足以遵守 - Todo 感觉像是周末项目，却带来了巨大的用户体验提升
详细精要
Bash 为什么是最重要的工具
Jared 指出 Bash 有两个让人印象深刻的特质，缺一不可：
第一，简单且万能。Bash 能做的事几乎没有上限——你可以调用系统上任意已安装的工具，可以创建文件、运行程序、管理进程、访问网络……几乎任何计算机上能做的事情都可以通过 Bash 来完成。这意味着你不需要为 Agent 设计专门的工具来处理每种情况，Bash 就是通用接口。
第二，训练数据极其丰富。模型在 Rust 等冷门语言上表现较差，根本原因就是训练数据少。Bash 是所有程序员共用的语言，几十年来积累了海量的代码示例、Stack Overflow 问答、教程……模型在 Bash 上见过的模式远多于任何专用工具，所以特别可靠。这是一个"站在巨人肩膀上"的设计选择。
第三，Bash 具体能做什么的象征性案例：当你看到 Claude Code 创建一个 Python 文件、运行它、然后删掉它时，那就是这个系统能力的精髓体现。它不需要一个"运行 Python 脚本"的专用工具——就用 Bash 创建文件、用 Bash 运行、用 Bash 删除，三步完成。Jared 说每次看到这个操作都觉得"很酷"。他同时也提到，他经常需要明确告诉 Claude Code "不要这样做"，因为它太喜欢创建临时脚本了。
Jared 还分享了一个自己经常用的场景：搭建本地开发环境。以前他会把几个常用命令写在某个文件里，但这些命令会慢慢过时失效。现在他直接让 Claude Code 通过 Bash 搞定环境搭建——它会自己探索需要哪些步骤，比任何手写脚本都更能应对变化。
Todo 列表的深层含义
Todo 的核心规则：一次只处理一个任务、完成后标记已完成、遇到阻塞继续留在当前任务、把大任务拆解成更小的步骤。这些都符合直觉，但 Jared 认为最有趣的地方在于：这些规则完全是通过 Prompt 实现的，没有代码层面的强制执行。
Todo 只是系统提示（System Prompt）里的几条文字规则，完全依赖模型的指令遵循能力。模型在运行时会读到这些规则，然后自觉遵守——一次只做一件事，做完标记，遇到问题继续处理当前任务。一年前这不可能实现，两年前更不可能。这个功能之所以现在能用，是因为模型的指令遵循能力有了质的飞跃。
Jared 猜测这个功能的实现"感觉像是某人用了一个周末做出来的"，然后发现它有效就上线了。他把 Todo 比作"整理工作台"——就像你开始工作前会整理桌面，这是在帮助模型组织自己的认知状态。
💬 Bash 就是你所需要的全部。你可以把其他工具全删掉，只留 Bash，它能做一切。
"Bash is all you need. I think you could probably get rid of all these tools and only have Bash."
本节重点 - Todo 数据结构包含：版本号、哈希 ID、人类可读标题、可注入的任意证据数据 - Todo 带来四个核心好处：强制规划、崩溃恢复、UX 可见性、用户可引导 - DAG（有向无环图）曾是构建 Agent 的主流方式，PromptLayer 客户中大量存在，现在可以扔掉了 - 放弃 DAG 的代价：带回了 Prompt Injection 攻击面；收益：开发效率 10 倍提升
详细精要
Todo 的内部数据结构
Jared 展示了 Todo 数据结构的细节（基于对 Claude Code 系统提示的研究）。每个 Todo 项包含：
- version：版本号，用于管理格式演进
- id：哈希值，用于在对话中引用特定 Todo 项
- title：人类可读的任务描述
- evidence：可以注入任意数据 blob 的字段
这些数据以结构化格式被注入到系统提示中，模型将其作为组织工作的参照系——就像你工作前整理桌面。ID 是哈希值而非序号，是因为模型需要能够在长对话中稳定引用特定 Todo，哈希比序号更可靠。
Todo 的四个核心价值
强制规划（Forced Planning）：在开始执行前让模型先把任务拆解，就像人类开始大型项目前会先列提纲。这大幅减少了模型在执行中途"走偏"的情况。
崩溃恢复（Resume After Crash）：Claude Code 有时会失败（网络中断、Context 超限等），有了 Todo 记录，用户可以看到进行到哪一步，甚至告诉模型"从第三步继续"。
UX 可见性（User Experience Visibility）：这是 Jared 认为被低估的一点。一个 Agent 跑 40 分钟完全没有进度信号，用户的焦虑感会极大影响使用体验。Todo 的实时进度显示让 Agent 感觉"可控"，即使它不能让 Agent 本身更聪明，也让用户更愿意使用。
可介入引导（Steerability）：用户可以随时看到 Agent 的当前计划，并在合适的时机插入新指令，调整方向。这是人机协作的关键接口。
告别 DAG（有向无环图）
Jared 分享了 PromptLayer 客户的亲身经历，这些客户过去两年半都在为各种 Agent 构建 DAG：比如客服 Agent，逻辑是"如果用户说要退款，路由到退款 Prompt；如果说投诉，路由到投诉 Prompt；如果是一般问题……"，越来越复杂，最终变成了几百个节点的噩梦。
DAG 方式的优点： - 可以对每个节点做精确的测试和版本控制 - 流程确定性高，减少幻觉 - 对 Prompt Injection 有天然防御（在纯分类 Prompt 里，注入指令基本无效，因为上下文被丢弃了）
DAG 方式的缺点： - 开发和维护成本极高，Jared 描述为"一张工程疯狂的蜘蛛网" - 不够灵活，边界情况处理困难 - 新增一条业务逻辑就要改图结构
放弃 DAG 转向简单循环的代价是：带回了 Prompt Injection 的攻击面（模型现在会真正处理用户输入的全部内容，注入攻击有效）。但收益巨大：开发效率提升 10 倍、可维护性提升 10 倍，而且实际效果更好，因为现在的模型足够强大。
💬 放弃 DAG 让开发效率提升 10 倍、可维护性提升 10 倍，而且效果更好——因为我们的模型现在已经足够好了。
"It's 10x easier to develop these things, 10x more maintainable, and it actually works way better because our models are just good now."
本节重点 - 核心原则：遇到不确定时，依靠模型探索，不要手动预设每个步骤 - 过多的手工引导反而会让 Agent 变差（加了按钮标题导致导航变差的实验） - 折中方案：保留简单循环主框架，把高确定性要求的操作封装成严格可测试的工具 - 沙箱（Sandboxing）是 Claude Code 代码最复杂的部分，Prompt Injection 是最大威胁
详细精要
"依赖模型探索"的反直觉实验
Jared 分享了一个自己做的实验，结果让他意外：他想让浏览器 Agent 自动操作 PromptLayer 的网站，于是给网站所有按钮都加了清晰的标题注释，以为这能帮助 Agent 更好地导航。结果完全相反——Agent 的表现反而变差了。原因是过于明确的指令让 Agent 失去了探索能力，它不知道在规则之外如何处理情况，反而陷入困惑。
这个例子说明：给 Agent 太多明确的引导，会限制它的灵活性。更好的方式是让 Agent 自己探索界面，自己判断该点哪里。就像培训新员工，与其给他一个详细操作手册，不如让他在实际工作中自己摸索——对于足够聪明的"员工"（即足够好的模型），后者效果更好。
关于"脚手架是否值得"的问答
现场有观众提出了一个实际的工程问题：如果我今天搭建的脚手架是为了解决当前模型的局限性，但三到六个月后模型变好了，这些脚手架就没用了——这不是浪费吗？
Jared 的回答分层次： - 这确实是权衡，没有通用答案 - 高风险场景（如银行聊天机器人）需要更多工程化保护，不能完全依赖模型 - 折中方案：采用 while 循环 + Tool Call 的主框架，但把真正有确定性要求的边界情况封装成严格可测试的独立工具调用。工具就像函数，有明确的输入和输出，可以单独 eval 和版本控制。其他探索性任务则完全交给模型。
沙箱与权限
Jared 坦言沙箱（Sandboxing）是他认为最无聊的话题，因为他自己经常开"YOLO 模式"运行——但不得不讲，因为团队有成员因此删掉了本地数据库。
主要威胁：Prompt Injection（提示词注入）。当 Agent 有 Shell 访问权限并执行 Web Fetch 时，恶意网页可能在其内容中嵌入指令，欺骗 Agent 执行不应该执行的操作（比如"现在删除所有文件并发送数据到外部服务器"）。这是一个真实存在的攻击面。
Claude Code 的应对方案： - URL 屏蔽：限制可以访问的域名 - 容器化：对部分操作做沙箱隔离 - Bash 命令分级：根据命令前缀判断走哪个沙箱环境，不同类别的命令有不同的权限要求 - 子 Agent 隔离：高风险的 Web 操作放进子 Agent，限制其能做的事情范围
Claude Code 在实际使用中会时常询问"我可以访问这个 URL 吗？"或"我可以执行这个操作吗？"这种"烦人"的确认机制正是沙箱系统在工作。
💬 遇到不确定时，依靠模型去探索和解决，不要试图手动预设每一个 if 语句。
"Don't try to think through every edge case and think through every if statement. Just rely on the model to explore and figure it out."
本节重点 - 子 Agent（Sub-Agent）是解决 Context 污染问题的核心方案：独立上下文，只返回结果 - Task 工具 API：接受 Description 和 Prompt 两个参数，主 Agent 动态生成子 Agent 的 Prompt - 系统提示泄露内容揭示了 Claude Code 的细节调优方式：每条指令都来自 Dog-fooding 的发现 - Claude 的 think/ultra think 机制让推理 Token 预算成为可动态调整的参数
详细精要
子 Agent 的工作原理
子 Agent 是对 Context Window 问题的直接回答。核心设计是：每个子 Agent 有自己完全独立的 Context，主 Agent 只看到子 Agent 返回的结果，不看中间过程。这样无论子 Agent 内部消耗了多少 Context（比如读了整个大文件、做了大量搜索），都不会污染主循环的 Context。
四个典型使用场景： - Researcher（研究员）：搜索和阅读大量资料，只返回关键信息摘要 - Docs Reader（文档读取器）：读取长文档，只返回与当前任务相关的片段 - Test Runner（测试运行器）：运行测试套件，只返回通过/失败结果和错误信息 - Code Reviewer（代码审查员）：审查代码改动，只返回问题列表
Jared 分享了自己的实际案例：当他想给 PromptLayer 网站的按钮加标题时，他让 Agent 先"用子 Agent 读取文档"，然后基于文档内容执行操作。子 Agent 读取文档、提取关键信息、返回给主 Agent，主 Agent 再利用这些信息做后续操作，Context 始终保持干净。
Task 工具的 API 设计
Jared 展示了 Task 工具的调用结构：
- description：用户界面显示的内容（用户看到的进度信息）
- prompt：给子 Agent 的完整指令字符串
关键洞察：prompt 是一个字符串，在主 Agent 运行时动态生成。这意味着主 Agent 会根据当前状态，实时为自己的子 Agent 写提示词。这是 AI 在给 AI 写指令——一种递归的、自组织的模式。Task 调用可以并行执行，多个子 Agent 同时运行，各自独立地完成任务并返回结果。
现场有人问：子 Agent 是否获得主 Agent 的全部 Context？Jared 的回答是：不是系统提示，但是整个对话上下文（包括工具调用记录）会传递给子 Agent。Tool Call 的 Schema（结构定义）在主 Agent 的 Context 中，子 Agent 收到的是 Task 工具调用时生成的具体 Prompt，不是主 Agent 的完整历史。
系统提示泄露的内容
Jared 基于网上流出的 Claude Code 系统提示（他自己也承认可能版本不是最新的），列出了几个他认为有价值的设定： - 简洁输出：不要说"好的，我来帮你……"，直接做任务 - 多用工具，少用文字解释："不要说'我想运行这段 SQL'，直接用工具运行" - 匹配已有代码风格：不随意添加注释（他吐槽这条对他自己不管用） - 广泛并行运行独立命令：能同时做的就同时做 - 遵守 Todo 规则
这些设定的来源很明显：Anthropic 团队在大量 Dog-fooding 过程中发现了各种小问题，然后一条条加进系统提示。这说明系统提示的迭代是高度经验驱动的，而非一开始就设计好的。
Claude 的推理 Token 预算机制
Jared 提到了 Claude 的 think / think hard / think harder / ultra think 系列触发词（他最喜欢 ultra think）。这套机制让推理 Token 预算成为一个可以动态调整的参数——用户可以通过 Prompt 词语来提示模型增加思考深度，模型也可以在不同任务中自适应调整。这比"做一个专门的规划 Tool Call"更灵活，是 Prompt Engineering 和工具设计的巧妙结合。
💬 最有意思的地方是：主 Agent 在实时为自己的子 Agent 生成 Prompt，这是 AI 在给自己的 AI 写指令。
"The prompt you're going to give as a long string—which is really interesting because now we have the coding agent prompting its own agents."
本节重点 - CLAUDE.md 是项目的"宪法"，比 Cursor 的向量数据库方案简单得多但够用 - Skills 是"按需加载的扩展系统提示"，解决 CLAUDE.md 超过 40K 字符的问题 - Jared 用三个 Skills 组合完成了本次演讲的 PPT 制作 - Unified Diff 是所有 Agent 编辑文件时都应该采用的标准，能大幅减少错误和 Token 消耗
详细精要
CLAUDE.md 的设计哲学
CLAUDE.md 文件（Codex 用 agents.md，其他 Agent 有不同叫法）是"项目宪法"——放置给 Agent 的项目级指令，包括代码风格要求、项目结构说明、常用命令、注意事项等。
Jared 指出这个设计本身就是 Claude Code 哲学的体现：Cursor 1.0 的做法是在本地建一个向量数据库来"理解"代码库，做了很多工程工作。Claude Code 的做法是"就放一个 Markdown 文件，用户需要改就改，Agent 需要改就改"。简单、透明、用户可控。
这不是偷懒，是哲学上的选择：最简单的方案如果够用，就是最好的方案。Jared 承认他对这个方案有点偏见，因为 PromptLayer 本身就是一个 Prompt Engineering 平台，但他真心认为"所有东西最终都是 Prompt Engineering，或者说 Context Engineering"——如何让通用模型适应你的特定使用场景，这就是核心问题，而 CLAUDE.md 给出了一个极其直接的答案。
Skills（斜杠命令）
当 CLAUDE.md 文件内容超过 40K 字符时，Claude Code 会发出黄色警告提示"文件太长了"。Skills 是这种情况的解决方案：把不同类型任务的专属上下文拆分成独立的 Skills，只在需要的时候加载，避免系统提示常驻过长。
Jared 展示的他自己的 Skills 体系： - 文档更新 Skill：包含他的写作风格指南和 PromptLayer 产品说明。每次做文档更新时召唤这个 Skill，Claude Code 就知道用什么风格写、产品的关键特性是什么 - Microsoft Office Skill：让 Claude Code 处理 Word/Excel 文件，需要对二进制格式做"反编译"，比较复杂但有人在用 - 设计风格指南 Skill：告诉 Agent 他的设计偏好，比如"盒子要有强调色"这类细节 - 深度研究 Skill：他把一个 GitHub 仓库里的深度研究方法论完整地重建成了一个 Skill，使用时只需说"用深度研究 Skill 调研这个主题"
这次演讲的 PPT 本身就是用 Claude Code + Skills 完成的：Slide Dev Skill（研究 reveal.js 库的用法）+ Deep Research Skill（研究各个 Agent 的内部实现原理）+ Design Skill（控制 PPT 视觉风格）。
Unified Diff 的重要性
Jared 认为 Unified Diff 值得单独用一节讲。结论简单：所有构建 Agent 的人，只要 Agent 需要编辑文件，都应该用 Unified Diff 作为标准格式。原因和 Edit 工具一致：改动范围被明确限定，速度更快，Token 消耗更少，错误更少。他还注意到一些 Agent 会根据具体情况做 Unified Diff 的变体（比如省略行号），但核心思想是一致的。
💬 一切最终都是 Prompt Engineering，或者说 Context Engineering——如何让通用模型适应你的特定场景。
"Everything's prompt engineering at the end of the day, or context engineering. Everything is: how do you adapt these general purpose models for your usage?"
本节重点 - Skills 的现实问题：Agent 经常不会主动调用，实际上需要用户手动触发 - 这可能是模型训练问题，也可能是 Prompt 问题，Skills 作为功能还不够成熟 - 未来两种路线：减少工具数量（一个超级工具）vs. 增加工具数量（几百个专用工具） - 自适应推理预算：把推理模型本身作为一个可调用的工具
详细精要
Skills 的实际困境
现场一个观众提出了真实痛点：他把 CLAUDE.md 内容拆成了多个 Skills，但 Claude Code 常常"无视"这些 Skills，不知道在什么情况下该调用哪个。Jared 承认这个问题确实存在：理论上，每个 Skill 在系统提示里有一行描述，模型应该能根据任务需要选择合适的 Skill 调用。但实践中，他自己也经常需要手动触发 Skill，而不是让 Agent 自动选择。
这本质上是一个"工具调用的元认知"问题：模型需要知道什么时候该调用哪个 Skill，这和知道什么时候调用 Read 工具、什么时候调用 Bash 一样需要判断力。当前模型在这方面还不够成熟。可能的解决方案： 1. 更多的 Post-training（后训练），专门训练模型在合适时机调用 Skill 2. 更好的 Skill 描述文字，让模型更容易判断 3. 接受现状，把 Skills 作为"用户主动调用"的功能而非"Agent 自动选择"的功能
两种对立的未来方向
关于工具调用的未来，Jared 描述了业界的两种主流观点：
主流派：工具会越来越多，工具调用能力会持续提升，最终会有几百个高度专用的工具，模型知道什么情况用什么工具。
Jared 的少数派观点：应该走向相反的方向——减少工具数量，理想情况下一个"超级工具"加上 Bash 就够了，或者把任务逻辑写成脚本文件放在本地目录，用 Bash 调用。他认为工具数量越多，Context 消耗越大，维护成本越高，复杂度越难控制。
把推理模型作为工具调用
Jared 认为"推理模型作为工具"是一个很有潜力的范式：主模型跑得快但稍微笨一些（可以是 20 倍更快的小模型），当遇到特别复杂的问题时，调用一个慢但强的推理模型作为工具。这样可以平衡速度和质量：日常任务用快模型，规划和复杂推理用强模型。他举例说，可能在做规划时先用 GPT-5.1 或 Opus，然后执行阶段用更快的模型。
新的"一等公民"范式
Jared 认为 To-Do 和 Skills 都是"一等公民"范式的例子——把某个重要但通常隐式存在的概念，显式地建模到系统中，赋予它结构和接口。还有哪些概念值得这样处理？他认为答案尚未出现，但这是一个值得探索的方向。
本节重点 - "AI 治疗师问题"：某类 AI 产品问题没有全局最优解，只有针对不同情境的最优解 - 五个有代表性的编程 Agent 各有独特哲学，没有绝对赢家 - 设计品味（Taste）和架构判断力比技术细节更重要，这是护城河
详细精要
"AI 治疗师问题"框架
Jared 提出了一个他反复思考的框架，用于理解编程 Agent 的竞争格局。他以纽约的治疗师市场为例：在纽约，每个街区都有六个治疗师，有做冥想的、有做 CBT（认知行为疗法）的、有用更激进方法的——没有人能说哪个是全球最优，因为不同的人在不同的情境和问题下需要不同的方法。这不是主观偏见，而是领域的客观性质。
编程 Agent 也是同样的情况：你可以有五个都很厉害的编程 Agent，但没有人知道哪个最好——Anthropic 不知道，OpenAI 不知道，Sourcegraph 不知道，市场也不知道。不同的 Agent 在不同场景下更好。Jared 本人的使用习惯就是： - Claude Code：需要和系统工具深度配合（git、本地环境搭建、PR 创建） - Codex：复杂的硬核编程问题 - Cursor Composer：需要速度时
这个框架的重要推论是：设计品味（Taste）和架构判断力在这个领域比技术细节更重要。没有全局最优解意味着，如何为特定场景做出正确的架构选择，是真正的竞争优势。这也是为什么 PromptLayer 关注的是"把领域专家引入 AI 开发"——律师、医生、金融分析师的领域知识与 AI 能力的结合，才能构建真正有护城河的产品。
💬 我真的不认为会有一个赢家。不同的使用场景会有不同的赢家。
"I don't think there's going to be one winner to this. I think there's going to be different winners for different use cases."
本节重点 - OpenAI Codex：开源、Rust 编写、更偏事件驱动、内核级沙箱（kernel-based） - Sourcegraph AMP：免费、无模型选择器、核心目标是构建"Agent 友好的开发环境" - AMP 的 Handoff 机制：直接开新线程代替等待 Compact，类似"换弹匣比等重新装弹快"
详细精要
OpenAI Codex 的架构特点
与 Claude Code 最大的共同点：同样采用 while 循环 + Tool Call 的主架构，因为这确实是目前最优解。差异点：
Sourcegraph AMP 的独特视角
AMP 有几个非常有特色的设计决策：
免费层：通过广告变现，利用各 AI 提供商的闲置 Token 容量。Jared 本人在 AMP 上有广告，他是"亲广告派"，认为这是值得探索的商业模式。
无模型选择器：AMP 刻意不让用户自己选择使用哪个模型，这和大多数工具相反。背后的逻辑是：当用户没有固定的模型预期时，AMP 可以随时切换底层模型（比如换到更好或更便宜的新模型），开发团队的灵活度大幅提升。这改变了他们的产品开发方式。
核心愿景——Agent 友好的开发环境：AMP 的目标不只是"最好的 Agent"，而是"与 Agent 配合最好的开发环境"。具体来说：如何构建一个密封的（Hermetically Sealed）代码库，让 Agent 可以跑测试？如何建立完整的反馈循环（Feedback Loop），让 Agent 能基于测试结果自我修正？如何让 Agent 看自己的设计输出并迭代改进？这是"自主 Agent 的圣杯"。Jared 说他很期待看到前端版本的这类系统。
Handoff 机制：当 Context 快满时，AMP 不是等待 Compact（压缩摘要，通常需要等待较长时间），而是直接开一个新的对话线程，把当前任务的必要信息打包传递过去，继续执行。Jared 用 Call of Duty 的类比：换弹匣（Handoff）比等待重新装弹（Compact）快得多。他认为这可能是更好的策略，虽然两种策略可能都有价值。
本节重点 - AMP 的三档模型：Fast / Smart / Oracle，Oracle 刻意不透露具体是哪个模型 - Cursor Composer 靠蒸馏（Distillation）构建快速专用模型，重新点燃了业界对微调的兴趣 - Cursor 的成功是迭代的成功：1.0 很烂但进入门槛低，然后一直变好
详细精要
AMP 的模型策略
AMP 提供 Fast、Smart、Oracle 三个档次。Fast 是日常任务，Smart 是一般复杂任务，Oracle 是最强的——但他们不告诉你 Oracle 具体是哪个模型。逻辑和无模型选择器一致：他们会随着新模型出现更换 Oracle 的定义，但外部接口保持稳定。用户知道"用 Oracle 处理最难的问题"就够了，不需要知道底层细节。
Cursor Composer 的蒸馏策略
Cursor Composer 让 Jared 几乎完全切换过来，因为快得惊人——快到他不小心把代码推到了自己个人项目的 master 分支（他提醒大家这不总是好事）。
Cursor 的核心差异化是蒸馏（Distillation）：他们有大量用户数据，基于这些数据训练了一个更快的专用模型。这让 Jared 觉得"微调复活了"——在过去，他几乎不向 PromptLayer 客户推荐微调，因为数据量要求高、维护成本大。但 Cursor Composer 证明了：当你有足够量的领域相关数据，基于这些数据做微调确实能带来显著优势，并形成竞争壁垒。OpenAI 的 Codex 模型同样是经过蒸馏优化的，Jared 认为 OpenAI 也可能推出类似 Composer 的快速版本。
Cursor 的迭代故事
Jared 特别提到 Cursor 的成功是一个关于产品迭代的故事：Cursor 1.0 真的很烂，但因为只是 VS Code 的分支，进入门槛极低——"没什么可失去的，试试看"。这个低摩擦的入口让 Cursor 积累了大量用户，获得了大量数据，然后用这些数据不断改进。现在 Cursor 是市场上最受欢迎的编程工具之一。低门槛试用 + 持续迭代 + 数据飞轮，这个组合被证明非常有效。
本节重点 - Benchmark 已经沦为营销工具，"所有模型都在打败 Benchmark"不可信 - 三种评测框架：端到端测试、时间点快照测试、回测（Backtest，最推荐） - "Agent Smell"概念：工具调用次数、重试次数、耗时是快速健康检查的表面指标 - 严格可测试的工具：对于有明确输出格式要求的任务，应封装成可独立测试的工具
详细精要
Benchmark 失效
Jared 直言：传统 Benchmark 已经不可信了。"每个模型都在声称打败 Benchmark，我真的不知道这怎么可能同时发生。"Benchmark 现在更多是营销工具，而非客观评测指标。
在简单 while 循环架构下，评测反而变得更难了。以前用 DAG 时，每个节点可以单独测试，输入输出明确。现在依赖模型灵活探索，如何客观评测"这个 Agent 表现好不好"？这是一个开放问题。
三种评测方式
端到端测试（End-to-End Test）：最直接，就问"问题最终解决了吗？"Jared 展示了他在 PromptLayer 里跑的一个案例：用 Headless Claude Code 批量测试各 AI 提供商的最新模型信息。指令是"搜索这个提供商，找到他们最新最大的模型，返回名字"——他不关心 Agent 内部怎么操作，只看最终返回的名字是否正确。这是最容易入手的评测方式。
时间点快照测试（Point-in-Time Test）：给 Agent 一个半完成的对话上下文（知道此刻应该执行什么操作），测试它是否在这个特定时刻执行了正确的工具调用。这比端到端测试更精细，但需要更多准备工作。
回测（Backtest）：Jared 最推荐的起点。方法：先开始记录 Agent 的历史运行数据，然后当你修改了 Prompt 或工具时，用新版本重新跑历史案例，看结果是否改善。关键是"先收集数据，再分析"，不要一开始就想设计完美的评测框架。
"Agent Smell"概念
Jared 提出了一个他称为"Agent Smell"的健康检查方法：通过观察这些表面指标来快速判断系统是否健康—— - 工具调用次数：一个任务调用了多少次工具？正常范围是什么？ - 重试次数：模型失败重试了几次？频繁重试说明有问题 - 耗时：完成任务花了多长时间？
这些指标不能替代深度评测，但作为"闻一闻"的快速检查非常有用，能帮你快速发现明显异常。
何时构建严格可测试的工具
并非所有任务都应该依赖模型自由探索。Jared 给出了判断标准：当你对输出有非常具体的格式要求时，把这个需求封装成严格可测试的工具。
例子：他的邮件写作 Agent 必须包含问候语、正文、签名三个部分。这个格式要求很明确，可以用 LLM Judge 检查，可以写测试用例，可以版本控制。这类任务不应该依赖模型"自由发挥"，而应该有严格的质量门控。其他探索性任务（如"找出这个 Bug 的根因"）则没有固定正确答案，应该依赖模型探索。
💬 Benchmark 已经成了很多模型提供商的营销工具。所有人都说自己打败了 Benchmark，我不知道这怎么可能同时发生。
"Benchmarks have become marketing for a lot of these model providers. Every model beats the benchmarks. I don't know how that happens."
本节重点 - 具体的 LLM Judge 测试流程：运行 → 检查 → 若不符合则自动修正 → 循环 - Headless Claude Code SDK 让 Agent 成为 CI/CD 流水线的一部分 - Jared 的实际案例：GitHub Action 每天自动更新文档并创建 PR
详细精要
LLM Judge 评测的实际流程
Jared 展示了一个具体的邮件写作评测案例（在 PromptLayer 界面中操作）：
他用这个方法把通过率从初始值提升到了 100%（对测试集）。他还提到了一个更复杂的 SEO 博客写作工作流，有约 20 个节点：深度研究 → 生成大纲 → 修正结论 → 添加内外部链接。对于这类有明确交付格式的任务，工作流 + LLM Judge 的方式比完全依赖模型探索更容易评测和改进。
Headless Claude Code SDK
当时刚宣布的 Headless Claude Code SDK（官方提供的编程接口），让开发者可以把 Claude Code 嵌入任何自动化流水线，只需提供一个 Prompt，Claude Code 就自主完成任务并返回结果。
Jared 的实际使用案例：他配置了一个 GitHub Action，每天自动运行： 1. 读取所有代码仓库的最新提交记录 2. 读取 CLAUDE.md 判断是否需要更新文档 3. 如果需要，自动更新文档内容 4. 创建 Pull Request（不自动合并，需要人工审查）
有观众调侃"你真的有在审查那些 PR 吗？"Jared 笑着确认：是的，他审查 PR，不会让 Agent 直接合并。
他认为这种模式预示着一个更高抽象层的开发范式：开发者不再自己搭建 Agent 脚手架，而是直接调用 Claude Code SDK 或其他 Agent 来做编排和执行。这可能从根本上改变 AI 应用的开发方式。
💬 你只需要给一个 Prompt，它就成了你流水线里的一个普通步骤。我有一个 GitHub Action 每天自动更新文档并创建 PR。
"You just give a simple prompt and it's just another part of your pipeline."
本节重点 - 五条核心 Takeaway：信任模型、简单设计、Bash 就够、管理 Context、尊重不同视角 - 这整个 PPT 本身就是用 Claude Code + Skills 构建的，是方法论的现场证明 - 未来的设想：多 Agent 并行运行并互相讨论，就像一个专家团队
详细精要
Jared 总结了整场演讲的五条核心原则：
1. 信任模型（Trust the Model）：遇到不确定时，依靠模型探索，不要预设所有边界情况。这是其他所有原则的基础。
2. 简单设计赢（Simple Design Wins）：原则一和原则二高度相关。简单架构不是妥协，而是在模型足够强大的前提下，复杂性是负担。
3. Bash 就够（Bash is All You Need）：工具不用多，5 到 10 个比 40 个好。Bash 是核心，是万能适配器，也是训练数据最丰富的工具。
4. Context 管理很重要（Context Management Matters）：这是当前 Agent 的最大瓶颈，也是所有优秀设计都在努力解决的问题。也许未来的模型会更好，但总会有上限——Jared 用了一个自嘲的类比："就像我一天见太多人就记不住名字，这是我的 Context 管理问题，或者说是我的愚蠢。"
5. 不同视角很重要（Different Perspectives Matter）：工程师思维容易忽视这一点，但在没有全局最优的领域，识别和接受不同方法的价值是核心能力。Jared 的终极设想：让 Claude Code 和 Codex 同时解决同一个问题，比较它们的输出，甚至让它们在一个 Slack 频道里互相讨论，然后汇总给用户——他在等人来做这个产品。
关于 PPT 的制作
Jared 最后展示了本次演讲的 PPT 是如何用 Claude Code 构建的，作为对整个方法论的实际验证： - Slide Dev Skill：让 Claude Code 研究 reveal.js（演讲框架库）的用法，然后生成 PPT 内容 - Deep Research Skill：让 Claude Code 研究各个编程 Agent 的内部实现原理，为演讲收集素材 - Design Skill：告诉 Claude Code 他的设计偏好，让它给视觉元素（比如盒子）添加合适的颜色和样式
整个 PPT 的制作过程就是对"给它工具、信任模型、用 Skills 按需加载上下文"这套方法论的现场演示。
本节重点 - DAG 有价值的场景：固定步骤、固定输出格式的任务 - 没有 DAG 也能保证顺序的方法：系统提示里指定顺序要求 + Tool Call 封装关键步骤 - 判断标准：问题有没有固定的正确执行步骤？有就用 DAG 或类似机制，没有就信任模型
详细精要
一位观众提出了对"告别 DAG"的反驳：DAG 的核心价值是保证顺序执行，比如客服 Agent 必须先问姓名、再问邮箱、再解释问题。如果没有 DAG，怎么保证这个顺序？
Jared 的回答提出了一个区分问题类型的框架：
问题类型一：没有固定步骤的通用问题。例子：通用编程 Agent（修复这个 Bug、实现这个功能）。这类问题没有预定义的执行路径，每个任务的解法可能完全不同。对这类问题，依赖模型探索是最好的策略，强加 DAG 反而会限制效果。
问题类型二：有固定步骤和固定输出的专用问题。例子：生成旅行行程（必须包含日程、住宿、交通等固定部分）。这类问题有确定的交付格式，DAG 或类似机制是合适的。但即便是旅行行程，其中的"研究"步骤（搜索每个城市的信息）也不应该用 DAG，因为每个城市情况不同。
混合策略的具体实现：对于旅行行程 Agent，Jared 会： - 让模型自由探索研究阶段 - 把"生成最终行程文档"封装成一个 DAG 风格的 Tool Call（有明确的输入格式和输出格式） - 在系统提示里加一条"始终以生成输出文件作为结束"的指令
这样既保留了探索阶段的灵活性，又保证了输出格式的一致性。
本节重点 - 未来可能直接调用 Headless Claude Code 而非 LLM API：推理模型本质上就是个 while 循环 - 规格驱动开发（Spec-Driven Development）和测试驱动开发（TDD）对 Agent 编程依然有价值 - Claude Code 的系统提示存储在本地机器上，有人已经挖出来过（版本可能不是最新的）
详细精要
"是否还需要直接调用 LLM API？"的问答
一位观众提出了一个前瞻性问题：我们是否在走向一个"不再直接调用 LLM API，而是只调用 Headless Claude Code"的世界？
Jared 的分析：
支持这个方向的论据：推理模型本质上就是服务器上的一个 while 循环——OpenAI 的 o1 不是什么神秘技术，核心就是让模型跑一个思考循环，直到得出答案。Claude Code SDK 也是更复杂的 while 循环。从技术本质上说，直接调用高层 Agent 接口和调用底层 API 没有本质区别，只是抽象层级不同。对很多开发者来说，Headless Agent 接口更容易使用、更能利用前沿能力。
反对的论据：很多场景需要更精细的控制——精确控制 Token 预算、精确指定输出格式、做低延迟优化……这些在高层抽象接口里不好实现，还是需要接近底层。
历史类比：他提醒大家，以前很多人坚持认为 Completion 模型（非对话形式的 LLM 调用）会长期存在，结果现在几乎没人用了。谁知道未来会不会所有东西都变成 Agent 接口？
规格驱动开发的价值
另一个观众问：鉴于"越简单越好"，如何看待测试驱动开发（TDD）和规格驱动开发（Spec-Driven Development）在 AI 编程中的价值？
Jared 的回答是：回归你信奉的工程原则。关于 TDD 是否适合所有场景，工程界本来就有争论，引入 Agent 并没有改变这个基本问题。对于 Agent 编程，TDD 确实有明显价值——AMP（Sourcegraph）的整个哲学就是"好的测试让 Agent 表现更好"。Jared 个人在处理复杂任务时重度依赖规划阶段和规格文档，但对于简单修改就直接跳过。"没有银弹，回归你信奉的原则"。
系统提示存储位置的揭秘
演讲快结束时，有观众问：Claude Code 的系统提示是存在 Anthropic 的服务器上还是本地机器？现场有人（Nico）知道答案：存在本地机器上。Jared 说这意味着他之前研究的那份泄露版本可能确实是从某人的本地文件里找到的，并不需要破解服务器。
| 术语 | 解释 |
|---|---|
| Tool Call / 工具调用 | 让 LLM 不只输出文字，而是调用预定义的函数（工具）并获取结果的机制。比如调用"读取文件"工具，LLM 会输出结构化的调用参数，系统执行后将结果返回给 LLM |
| While Loop / while 循环 | 编程中一种持续执行的循环结构，只要条件为真就一直运行。Claude Code 的主循环就是"只要还有 Tool Call 就继续执行" |
| Context Window / 上下文窗口 | LLM 一次能处理的最大文本量（以 Token 计）。超出这个范围，早期内容会被遗忘或截断，是当前 Agent 的核心限制 |
| RAG（Retrieval-Augmented Generation） | 检索增强生成：先从知识库检索相关内容，再把检索结果连同问题一起输入 LLM。常用于让 LLM 访问外部知识，但需要构建向量数据库等复杂基础设施 |
| DAG（Directed Acyclic Graph） | 有向无环图：一种工作流表示方式，每个节点是一个操作步骤，边表示依赖关系。过去常用于构建复杂 Agent 流程，每个分支处理不同的情况 |
| Embedding / 词向量嵌入 | 把文字转换为数字向量的技术，使得语义相似的内容在向量空间中距离更近。用于 RAG 中的语义搜索 |
| Unified Diff / 统一差异格式 | 一种标准的文件差异表示格式，只显示变动的部分及其上下文，而非整个文件。Git 的 patch 文件就是这种格式 |
| Sandboxing / 沙箱 | 把 Agent 的操作限制在隔离环境中，防止恶意或错误操作影响宿主系统。Claude Code 通过沙箱限制 Bash 命令的权限范围 |
| Prompt Injection / 提示词注入 | 一种攻击方式：通过在 Agent 会处理的外部内容（如网页）中嵌入指令，欺骗 Agent 执行攻击者期望的操作 |
| Sub-Agent / 子 Agent | 在主 Agent 的工作流程中，为特定子任务单独启动的独立 Agent，有自己的 Context，只把结果返回主 Agent |
| System Prompt / 系统提示 | 在对话开始前注入给 LLM 的固定指令，用于设定 LLM 的行为规则、角色和约束条件 |
| Dog-fooding / 狗粮测试 | 公司内部使用自己产品的实践，用于在发布前发现问题。来自"吃自己的狗粮"这个英文表达 |
| Distillation / 蒸馏 | 用大模型生成的数据来训练小模型，使小模型在特定任务上接近大模型的表现，同时速度更快、成本更低 |
| Fine-tuning / 微调 | 在预训练大模型的基础上，用特定领域数据继续训练，使模型在该领域表现更好 |
| LLM Judge | 用一个 LLM 来评判另一个 LLM 输出质量的方法。比起人工评审更快速，比固定规则更灵活 |
| Spec-Driven Development | 规格驱动开发：先写详细的功能规格文档，再让 Agent 或开发者实现。有助于明确需求并评测结果 |
| Compact / 上下文压缩 | Claude Code 在 Context 接近上限时自动进行的摘要压缩操作，丢弃中间内容，保留头尾，保存整体摘要 |
| Handoff | AMP（Sourcegraph）提出的替代 Compact 的方案：直接开一个新的对话线程并传递必要信息，而非等待压缩 |
| Headless | 无界面模式：Agent 在后台自主运行，不需要用户实时交互。Headless Claude Code 可以嵌入 CI/CD 流水线 |
| Scaffolding / 脚手架 | 围绕 LLM 搭建的额外代码层，用于处理格式转换、路由、错误处理等。Jared 认为过多脚手架是反模式 |
| Post-training / 后训练 | 在基础模型训练完成后进行的额外训练，用于调整模型行为（如 RLHF、指令微调等），是让模型遵守特定规则的关键手段 |