Transcript
00:00:00最近出现了一个叫“图工程”的新词，X 上的所有人都在讨论它。
00:00:04在图出现之前，大家用的都是“循环工程”，也就是给 Agent 一个目标，让它自己
00:00:09去逐步完成。但有了图之后，工作不仅完成得更快，覆盖面也远比
00:00:14循环工程广得多。不过图工程也有个致命的弱点：只要图中
00:00:18一小部分出错，整个返回的最终输出都会受到干扰，而且很难定位排查，因为你最后
00:00:23看到的只是一个结果。所以 Anthropic 刚刚发布了一个新方案，正好解决了这个
00:00:27问题，让你的图结构能稳健运行而不出错。如果你是新朋友，我们是一家软件
00:00:32公司，这里是我们的频道 AI Labs，我们会展示如何用 AI 来优化业务，
00:00:37如果你还没有自己的业务，也可以用这些技能帮别人做优化来赚钱。
00:00:42在这期视频中，我们将为还不了解图工程的朋友深入科普，
00:00:46并提供 Anthropic 建议的具体解决方案。在解释图工程之前，你需要
00:00:52先理解什么是循环工程。如果你已经了解，可以跳过这部分。
00:00:56循环本质上就是你交给 Agent 的一个工作周期。你不需要亲自提示它
00:01:02去完成每一个步骤，而是告诉它最终需要达到的目标，它就会边做边调整，
00:01:07自己搞定。我们在自己的工作流里大量使用这种模式，之前也专门做过一期
00:01:12关于循环工程的视频，深入讲解了不同的构建方式。但现在，循环正在向“图”演进。
00:01:17循环的问题根源在于它们的构建方式。
00:01:22循环做完一部分工作后，会触发验证步骤，检查结果是否符合预期。
00:01:27通过验证后，才会开始下一步。所有步骤都是单线串行的，所以每一步都在
00:01:32傻傻等待前一步，哪怕这两步之间毫无干系。而图工程
00:01:37解决的就是这个问题。图不再是单线运行，而是将主任务拆分成更小的
00:01:42子任务，每个部分分配给单独的 Agent。这样做最直接的好处就是速度快，因为
00:01:47多个 Agent 同时并列干活，而不是靠单个 Agent 硬啃完所有工作。而且把
00:01:52工作拆开后，还能在一定程度上降低成本，因为你可以为每个子任务挑选
00:01:56最合适的模型。这样你就不用在根本不需要高智商的环节上
00:02:01浪费最昂贵的模型了。不过这指的是单个 Agent 的成本，而不是总体成本。图结构消耗的
00:02:07Token 远比单个 Agent 多得多，因为你有一整套 Agent 在同时运行。
00:02:12如果你使用图结构，额度会比平时更快见底，所以你很难
00:02:17靠 Claude Code 或 Codex 的 20 美元基础套餐搞定。如果你一直在用 Claude Code，
00:02:22这对你来说可能并不完全新鲜，因为你其实已经见过一种图结构了——那就是“动态工作流”。
00:02:27动态工作流会把你给的任务进行并行拆分，分发给一组子 Agent，
00:02:33这本质上就是图在做的事。在深入了解图有哪些具体形态之前，你需要
00:02:38先明白它的基本构成。每个图都由两样东西组成：节点（Nodes）和边（Edges）。节点
00:02:44本质上是从大任务里拆分出的单个独立子任务。它作为一个 Agent，
00:02:49在自己隔离的上下文窗口中执行任务并返回汇报。而把所有这些独立任务
00:02:55串联在一起的，就是“边”。边控制着数据如何从一个节点流向下一个节点，确保某个 Agent 的输出
00:03:01能在正确的时间节点传递给正确的 Agent。因此，每个节点都必须以某种方式
00:03:06融入整个图。比如在一组 Agent 同时审查同一份代码或工作时，它们之间
00:03:10互不等待，但都基于同一份初始输入，且各自的报告最后都会汇集到
00:03:15同一个地方，这就是图的构成。接下来是这些组件是如何编排组合的。
00:03:20第一种形态我们在频道里展示过，不过当时我们把名字叫错了。
00:03:25当时我们叫它“循环”，因为那时候甚至还没有“图工程”这个概念。但
00:03:30我们当时实际构建的是一个处于循环中的图，形状像个菱形。顶层的一个任务
00:03:35拆分给多个并行运行的子 Agent，最后再收拢汇总到一个
00:03:41Agent 中，将它们找到的所有内容整合成一个最终答案。然后是屏障扇入图（Fan-in at a Barrier Graph），
00:03:46当你需要从多个角度同时评估一件事时，这种结构最合适。扇出（Fan-out）
00:03:51部分会将同一个问题分发给一组 Agent，每个 Agent 从不同的视角去审查。
00:03:56在所有 Agent 都完成汇报之前，没有任何步骤会推进，只有在全部完成后，
00:04:00才会去统一执行修复。当然还有很多其他形态。但所有这些形态都依赖于
00:04:05同一个核心，那就是“验证”（Verification）。如果验证环节没搭好，后面每个 Agent
00:04:10都只是在错误的基础上制造更多的错误。不过在聊验证之前，如果你能
00:04:15订阅本频道并点个赞就太棒了！这对我们支持巨大。
00:04:20一旦你运行一整队 Agent，出问题的方式将是单个 Agent 绝不会遇到的。
00:04:25最大的问题就是工作量太大了。它们同时推进，一瞬间吐回
00:04:30海量的内容，最后极难去人工审查。另一个问题是
00:04:34黑盒化。一旦出了错，你根本无法断定到底是哪里引起的。
00:04:39现在，不管你有没有明确要求，所有 Agent 都会对写出的代码进行某种验证。如果是写代码，
00:04:44通常就是 Agent 运行你的测试套件，捕获返回的报错。但这只能捕捉到重大
00:04:49错误。它依然不会去检查代码的编写质量，这非常关键，因为如果 Claude
00:04:53一直用有隐患的方式写代码，日后必将埋雷。在 Claude Code 中，
00:04:58有几个内置工具可以解决这个问题。第一个是 Verify 技能，它会从头到尾运行代码，
00:05:03确认其行为确实符合预期。第二个是工具链（Tool Chaining），
00:05:08即 Agent 运行不同工具来进行验证。Claude 自身就知道去运行那些
00:05:13检查工作的工具，读取反馈的报错并自动修复。它甚至能自己摸索出
00:05:18项目的具体运行命令。不过把这些命令直接写进你的 `Claude.md` 文件里，可以省去它
00:05:24每次都要重新猜测推断的麻烦。第三个是 Code Review 技能，它会根据
00:05:29一套标准去审查代码。并非每个 Agent 都自带这个技能，但如果你的没有，可以直接让 Agent 帮你自己造一个。
00:05:33不过，最有效的验证往往是你亲自定制的，
00:05:38而不是完全依赖开箱即用的内置功能。要快速构建一个验证工作的技能，
00:05:44最快的方式是使用 Claude Code 中的 Skill Creator 插件。这个技能也可以
00:05:49在 Codex 中使用。运行插件命令，搜索 Skill Creator 并安装。接着，
00:05:54有两种安装作用域可选。你可以安装在用户全局作用域（User scope），这样无论你在哪个
00:05:58项目文件夹下都能用；也可以只针对当前正在开发的项目进行局部安装。
00:06:03鉴于这是个会高频使用的技能，我们选择了全局安装。之后，
00:06:07用斜杠命令重新加载插件，Skill Creator 就可以使用了。现在告诉它
00:06:12你想构建什么，你可以在这里具体描述你想要的验证逻辑。
00:06:17我们主要使用 Review 技能来根据最初的需求来比对检查完成的工作。
00:06:22这在图结构中尤为关键，因为每个 Agent 往往只能看到自己负责的那一小块。
00:06:28这样就能给它一种手段，去对照原始需求核查该模块。但是，技能的效果
00:06:32完全取决于运行它的模型。之前我们在给社区网站的 UI 构建验证系统时，
00:06:37让 Haiku 来跑 Reviewer，因为模型便宜而且任务看起来很简单。
00:06:43结果它列出了一长串问题。单看找到的盲点数量，感觉它表现得非常出色。
00:06:47接着我们在完全相同的任务上换用 Opus 跑了一遍，它标注出的问题少得多。
00:06:53乍一看 Opus 好像表现更差，直到我们去细读它的分析逻辑。原来 Haiku 报出的很多问题，
00:06:58其实都是我们故意保留的设计。也就是说它找出的绝大多数问题都是毫无必要的误报。
00:07:03Opus 通过结合上下文逻辑推断出了这一点，而 Haiku 完全漏掉了这一点。所以用便宜模型
00:07:08做审查并没有省钱，因为审查报告本身还需要人工再去审查一遍。现在把这种情况放到
00:07:13图结构里，一整排节点都在用这个技能检查各自的工作，
00:07:18你的 Agent 就会白白浪费时间和 Token 去修复根本没坏的东西。而且因为这是
00:07:23多个独立 Agent 同时发生的，你甚至无从得知是哪个节点先引发的。
00:07:27因此，你选择的模型不仅决定了审查的质量，更决定了整个图的质量。
00:07:31负责把关评估的节点，绝对是“想省 Token 就会招致全面溃败”的地方。
00:07:37另一件你需要决定的事，是这个技能该如何以及何时被调用。
00:07:41这可以将它们分为三种类型。不过在深入讲解类型之前，先插入一段赞助商广告。
00:07:46如果你曾经从网上抓取过实时数据，就会知道网页爬虫简直是一场噩梦：
00:07:51你要跟验证码和速率限制斗智斗勇，跟代理节点折腾，还要维护那些一上线就失效的
00:07:56页面布局。所以我们选择了 SERP API，它能解决所有这些痛点，让你专注于核心业务。
00:08:01只需一次 API 调用，发送请求后就能收货干净的 JSON 对象，包含你精准需要的数据，
00:08:07拥有超过 99.9% 的可用性，响应时间仅约 1.2 秒。在构建 AI Agent 时，
00:08:14你可以让 Google 搜索 API 为需要时效信息的 Agent 提供支持，也可以用 Google 学术 API
00:08:20获取带有完整元数据的同行评审论文，这就是为什么如此多生产级 Agent 都依赖它。点击
00:08:25简介里的链接或扫描屏幕上的二维码，即可免费获得 250 个 Credit。感谢 SERP API 对
00:08:32本期视频的赞助。第一种类型是独立技能（Standalone），它只有在你自己手动触发时
00:08:37才会运行。独立技能专为对现有成果进行深度把关而设计，能够
00:08:42全面复盘已完成的输出。这就是为什么你不希望它在每次运行后都自动触发的原因，因为这会把
00:08:48Token 浪费在对尚未完成的工作进行无意义的高强度审查上。我们之前用过的一个例子是
00:08:53Cursor 的 Thermonuclear Code Review。它会分发一组 Agent，让每一个 Agent
00:08:59从不同的安全视角排查代码。所有的发现都会汇总到一个地方，以便统一进行
00:09:04修复，而这恰恰是你只会在应用开发完成后才运行的审查类型。要构建这种技能，用
00:09:10Skill Creator 远比直接写 Prompt 效果更好，因为生成的成果经过了测试，结果更
00:09:15令人信服。你在 Prompt 中告诉它希望审查哪个领域，并务必强调
00:09:20审查需要全面（Comprehensive），这样它就知道你要的是深度排查而非走过场。但是独立
00:09:26技能对正在工作中途的节点毫无帮助，因为你需要手动运行。这就轮到嵌入式
00:09:31技能（Embedded skills）登场了。嵌入式技能会作为现有工作流的一部分自动触发，无需你额外手动操作。
00:09:36你可以构建一个在有人请求新功能时自动介入的技能。它会检查
00:09:41新建的每个组件是否符合你在技能中制定的规则，并且在通过
00:09:45规则检查之前，绝不允许代码实现擅自结束。你可以自己构建
00:09:50嵌入式技能，但无法直接将预装好的技能设置为自动调用，比如我们之前
00:09:54提到的 Verify 技能。这些预装技能的运行指令是内嵌在产品底层的，
00:10:00无法直接修改。要自己构建，可以在 Skill Creator 中输入提示词，要求在每个功能实现后
00:10:05自动运行验证步骤，让它从头到尾对新功能进行测试，从而判断
00:10:10新代码是否弄坏了原有功能。随后 Claude 会为你生成这个技能，
00:10:16由于是 Skill Creator 自动生成的，它会附带经过流程化结构设计和测试的
00:10:21参考资料和脚本。在验证功能时，Claude 默认会使用浏览器测试（Browser testing），
00:10:26通过打开一个完整的 Chrome 浏览器，加载页面并截图来检查界面。
00:10:31如果你配置了 Puppeteer 或 Playwright（这也是大多数人
00:10:36用来自动驱动浏览器的主流工具），它们也是一样的逻辑。但众所周知 Chrome 非常吃内存
00:10:41且运行沉重，如果要在工作流内部反复检查页面，它的低效会
00:10:46开始带来不可忽视的时间成本。因此，有一种更轻量的方式，叫做 Chrome Headless Shell。
00:10:52它本质上是一个剥离了所有非必要组件的简化版浏览器。Agent 依然可以
00:10:57像平常一样访问页面并执行截图，只是处理速度要比完整版
00:11:02Chrome 快得多。你可以将它直接内置到创建的验证技能中。这样 Agent 开发的
00:11:07每个功能都能自动进行视觉检查，无需你每次手动配置。除此之外，
00:11:12我们在自己的工作流中最常使用的技能是一个叫做“Second Opinion”（参考第二意见）的技能，原因很简单：
00:11:17编写代码的那个 Agent，恰恰是最不适合去审查该代码的。它会基于
00:11:23构建代码时的同一套上下文来自圆其说并进行审查。而全新的 Claude 会话完全没看过
00:11:28那些历史上下文，能够给出客观公正的审查和直截了当的答案。Claude 确实内置了
00:11:33一个类似的 Advisor 功能，但它会读取你当前的聊天记录，因此继承了
00:11:38相同的上下文干扰。当你想排除干扰进行纯粹的审查时，Second Opinion 就派上用场了。
00:11:43它的工作原理是从当前会话内部使用 `-p` 标志启动另一个独立的 Claude 会话。`-p`
00:11:48这个标志可以在后台启动一个完全独立的 Claude Code 会话，并给它传入提示词
00:11:53让其独立工作。不过在使用时有几点需要特别注意：因为它
00:11:57启动了一个全新的独立会话，需要相当长的时间才能返回答案，
00:12:02而且模型的选择在这里比任何地方都重要，因为核心诉求就是获取更聪明的二次评估。
00:12:07因此非常值得在提示词中显式指定 Claude 使用 Opus 模型来启动该会话。这能让你图中的
00:12:12每一个节点都有途径让完全未参与该工作的第三方来交叉验证其成果。不过单个技能
00:12:18并不能覆盖所有维度。要真正做好审查，你需要从多个
00:12:22不同的角度切入，而每个角度都有自己的评估标准。你不能把所有的审查类型强行塞进
00:12:27一个技能里，因为那样 Agent 会因为审查指令过多而顾此失彼，效果适得其反。
00:12:33所以你应该为每个维度构建单独的技能，并将它们链式组合起来。Anthropic 自己的
00:12:38团队也是这样工作的。他们将 Code Review 技能、Simplify 技能和 Verify 技能
00:12:43串联在一起，这三个技能现在都随 Claude Code 原生附带。此外，他们还会运行自定义的 Design 技能，
00:12:49用以比对界面与 `design.md` 文件，该文件记录了
00:12:54产品的每一个设计决策。这就是一个同时来自四个维度的综合审查。最终你
00:12:59也能达到相同的效果，拥有一组分别覆盖不同维度的技能组合。但你不能
00:13:04直接命令 Agent 一口气运行所有技能。你需要一个凌驾于其他技能之上的主控技能，
00:13:09也就是一个编排技能（Orchestrator skill），它的唯一职责就是去调度运行其他技能。它会为你拥有的
00:13:15每个审查技能各自启动一个 Agent 并分发具体技能任务。它们会在各自隔离的
00:13:20上下文窗口中同时展开审查。随后主控技能将所有发现汇总成一份统一报告，供负责修复的 Agent
00:13:25参考并执行修复。这样，当你构建图结构时，只需在 Prompt 里交代
00:13:30让它调用那一个主控技能即可。它生成的每个节点都会自动加载该技能，整套审查流程
00:13:35就会在底层自动展开并执行。我们已经整理了一份详细文档，涵盖了为图结构配置
00:13:40验证机制的所有方法。这份文档以及视频中展示的所有技能，都可以在
00:13:45我们的 AI Labs Pro 社区中获取。如果你觉得我们的内容有价值并希望支持本
00:13:50频道，这是最好的方式。链接就在下方简介中。本期视频
00:13:55到这里就结束了。如果你想支持本频道并帮助我们继续制作这样的视频，可以
00:14:00点击下方的超级感谢（Super Thanks）按钮。一如既往，感谢收看，我们下期再见！