Google 免费两小时课，从零搭一个会自己改进的系统

Google 放出一门两小时的免费课，讲 harness 工程。时间轴切得很细：

• 0:29 harness 工程从零开始
• 11:08 正经搭出第一个 agent
• 28:08 用 chief of staff agent 做 eval 工程
• 1:00:13 循环工程
• 1:23:19 一个不会停的自改进图系统

Anatoli Kopadze 转推时写了句话：我见过 500 美元的课，前 15 分钟都没覆盖这门课讲的东西。课程是 @anniewangtech 做的，他在回复里补了一句，让人去关注她。

课值得看。但课程背后那套思路，比课程本身更值得先搞清楚。Anatoli 自己写过一篇很长的 Graph Engineering，把来龙去脉、坑在哪、什么时候别用，都画出来了。

图就两个东西

方框叫节点。一个 agent 干一件事，一个输入，一个输出。箭头叫边。一个活等另一个活的结果，因为后者要用前者产出的东西。边只有在真有数据传过去时才算数。

节点干活，边传结果。词汇表就这些。

节点要能用，得有契约：一件有边界的活，定义好的输入，定义好的输出。输出是一堵自由文本的墙，那这个节点只有人能读。输出有固定形状，下一个节点才能不靠猜地接过去。

假边测试

看你现在的工作流，逐步问一句：这一步真的需要上一步的结果吗？

需要，边是真的，顺序保留。不需要，边是假的，两边可以同时跑。

一个简单例子：审查文件 A 的 bug，再审查文件 B 的 bug。读起来是两步，但 B 的检查根本不看 A 返回了什么。它们串行，只是因为你按这个顺序敲的。并行跑，总时间等于较慢的那一个文件，不是两个加起来。

几乎任何工作流里都能找到两三条假边。每一条都是白扔的时间。

40 步的线性流程有 40 个顺序失败点，延迟是 40 步相加。同样 40 件事画成图，真实依赖通常三到五条，跑完的时间等于最慢那层。五分钟变十五秒，模型没动，线动了。

菱形

不需要一百种形状。严肃的 agent 系统反复出现同一张图：活分出去，几个 worker 并行挖，有东西检查挖到的东西，最后合成一个答案。

fan out 收广度，用 plain code 做 reduce 压数据，一个强模型做 synthesize 写答案。Claude 的 research 功能跑的就是这个，一个主 agent 规划角度，worker 并行收集，发现被检查，一份报告送到你面前。

一旦看清菱形，问题就从“怎么让 agent 多走几步”变成“在哪里分，在哪里合”。第二个问题才能放大。

检查器不能共用上下文

模型检查自己的活，太宽容。几乎所有关于 AI 自我评估的测试都指向同一件事：模型会漏掉自己大部分的错误。

所以干活的 agent 不能检查自己的活。边上挂一个独立节点，唯一任务是试着杀掉这条发现。活下来，往下走。死了，就在这里结束。

但检查器得有干净的上下文。给它看 worker 的聊天记录，它不是检查，是在另一个字体里对自己点头。一个共享上下文的 agent 图，就是穿了件衣服的单个循环，崩得慢一点，贵一点。

三个视角分开：对不对，新不新，来源真不真。三个不同的透镜能抓到十个一样的透镜抓不到的东西。

三种崩法

上下文崩塌。一千个节点扇出去，把一千个输出全倒进最后一步，窗口在合成开始前就炸了。修法是分层扇入，每批先摘要，合的是摘要，不是原始堆。

假独立。两个节点的 prompt 里没提对方，但写同一个文件，或者打同一个限流的 API。这是隐藏的边。Bun 团队最早把大活扇给多个 agent 时，共享一个工作区，互相覆盖。修法是每个 worker 自己的隔离空间，审的是共享资源，不只是共享数据。

静默失败。链里一个失败全停，烦但明显。图里两百个节点死一个，能滑进一份看起来很完整的报告。修法是每个合并步骤数一下输入数量，对不上就报，别只拿一半数据合成还叫完整。

锚点

更深的坑在图本身。

每个节点看另一个节点的报告，审计对着财务数字，财务来自同一个系统。全都一致，什么都没验证。

这张图会以单个循环同样的方式失败，只是更晚、更贵、一路绿灯。

拓扑不买真相。图需要锚，不能争论的东西。真跑过的测试，真到账的收入，真留下来的客户。有些规则得冻住，尤其是优化器最想改的那几条。

账单

Bun 的案例写在 Anatoli 文章里：一个工程师用这套设置重写运行时，535,000 行翻译成超过一百万行，用了大概 11 天。差不多 50 个 workflow，最多 64 个 agent 同时跑。账单大约 165,000 美元，有人工设计、盯着全程，也有批评说这么多 AI 写的代码没法安全审查。

评论区有个人对着这个数字发愁，问在小仓库里怎么做得起。Anatoli 回了句，你在哪看到的价格。数字传出去，连作者自己都不一定认得。

这是重版用法。有预算、有上限、有监控的团队才玩得动。小规模先跑，看一次花多少，再决定扩不扩。

什么时候别用

任务小、要每步审批、还没想清楚要找什么、步骤真的串行，这些情况别上图。图买的是宽度，不买判断力。判断标准还是假边测试：找不出两条互不依赖的活，就没有图要建，一个循环就够了。

课是入口，两小时，免费。用 Anatoli 的话说，模型从来不是瓶颈，你画的线才是。今晚找张纸，把工作流画出来，看哪条箭头后面没数据跟着跑。删掉它们。

课程由 @anniewangtech 制作。Anatoli 的原文和课程链接在 X 上。