ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← Home NO.137
第 137 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日

CCA反模式手册

FC
Frank Coyle · AI Engineer
视频 19:53 原文约 1.6 万字 预计阅读 12 分钟 来源视频 ↗ 中英对照全文
TL;DR · 三句话
  1. Anthropic 三月刚发布的 Claude Certified Architect(CCA,Claude 认证架构师)考试,与其当成一张证书,不如当成一本 agent 工程的「反模式手册」——它给六个生产场景、考试随机抽四个出题,而答对的钥匙常常是"知道什么不能做"。→ 详细
  2. 讲者逐个走场景,每个都先甩反模式再给正解:拿到模型响应就用(应按 stop reason 分支)、一个 agent 塞满工具(应专一)、子任务把完整输出倒进主线程(应 fork 出去只回灌汇总)、持续集成流水线里留着交互模式(应配成一路跑到底)。→ 详细
  3. 底层逻辑是 1990 年代设计模式运动的重演:那时有面向对象的模式,也有反模式;现在有了 agent 的模式,反模式同样是"通向该怎么做的钥匙"。→ 详细
01

元命题:agent 时代缺的不是模式,是那半本「反模式」

  • 讲者 Frank Coyle 教了三十多年计算机,现在在 UC Berkeley。他做这件事的起点很实在——"计算机科学已经不再是通往一份工作的那条魔法通道了",学生撞上 AI 这堵墙,他得给他们找个抓手。→ 详细
  • 他的类比是 1990 年代初伴随面向对象编程兴起的 design patterns(设计模式)运动:那时候人们不光总结"该怎么写对象",也总结 anti-pattern(反模式,被反复验证过的错误做法)。他的原话是——"反模式是理解「什么不该做」的关键,而搞清楚什么不该做,恰恰是通向「该怎么做」的钥匙"。agent 这一波,模式已经有人在写了,反模式那半本还空着。→ 详细
  • 所以整场演讲是固定套路:每个生产场景先甩反模式,再给正解。他直说这也是答题技巧——"解决问题的方式有很多种,但很关键的一点是「什么不能做」,这往往就是答对这些题的钥匙"。→ 详细
  • 贯穿全场的个人理念来自 Corita Kent 修女的一句话:"没有什么是错误,没有赢也没有输,只有去做。" 配上 Edison 那句"我没有失败,我只是找到了一万种行不通的办法"。落点是:别只读,要做。→ 详细
02

CCA 考试本身:三月刚发布、99 美元、半年一次

  • 形式:基于场景、有时间限制、有监考;Anthropic 生态里的公司可以考,个人 99 美元、每六个月能考一次。题型是选择题,但"题目都建立在真实的约束条件和真实的场景之上"。(讲者只说"三月份发布、非常新",未提年份。)→ 详细
03

五个考纲领域与分值

五个考试领域及其分值权重 ▲ 图注:五个考纲领域按权重从高到低:Agentic 架构与编排、Claude Code 配置与工作流、Prompt 工程与结构化输出、工具设计与 MCP 集成、上下文管理与可靠性。权重排序本身就是一张优先级表——架构与编排的分量最重,上下文管理垫底。(图为 360p 截帧,具体百分比数字请以原片为准。)

  • 他只报了两个明确配比:agentic 架构 27%Claude Code(怎么配置这套系统和工作流)20%→ 详细
  • 其余只念了名字、没报分值:prompt engineering 与输出结构化("到处用 JSON")、tool 设计MCP(Model Context Protocol,让模型接外部工具和数据源的标准协议)集成context 管理与可靠性。(口播里这几项并没有严整对齐成"五个桶",此处照他念的顺序保留。)→ 详细
  • 他的建议:不考也该弄懂这几块——"它能帮你为 agentic 世界扔给你的各种状况做好准备"。→ 详细
04

六个生产场景,考试随机抽四个

六个生产场景总览 ▲ 图注:六个生产场景一览:客服问题解决 agent、用 Claude Code 做代码生成、多 agent 研究系统、开发者生产力、Claude Code 进 CI/CD、结构化数据抽取。最后一个「结构化数据抽取」讲者预告了但时间到了没讲——本报告因此只覆盖前五个。

  • 考试给 六个生产场景,系统 随机抽四个,所有题目围绕抽中的这四个出。→ 详细
  • 预告的清单:① 客服问题解决 agent;② 代码生成;③ 多 agent 研究系统;④ 用代码提升开发者生产力;⑤ Claude Code 用于持续集成;⑥ 结构化数据抽取的模式。→ 详细
  • 实际只走完前五个——第六个(结构化数据抽取)开头预告过,但 19 分钟讲完时间到了,没讲。→ 详细
05

为什么"loop 是新东西"这句话不成立

  • 现在人人谈 loop(循环):Boris Cherny 说他不写代码,他的工作是写 loopPeter Steinberger(转写作 OpenClaw 的作者)说"我已经不写代码了,我只设计那些驱动 agent 的 loop"。→ 详细
  • 讲者的回应是"其实并不是什么新东西":1966 年 Böhm 和 Jacopini 证明,一门语言要图灵完备(能算出计算机原理上能算的一切)只需要三样东西——顺序执行、if-then 条件分支、loop→ 详细
  • 他不是泼冷水,是在定位:过去的 LLM 用法基本停在"顺序 + 偶尔分支",补上 loop 这一样,agent 才拿到完整的计算能力——"这才是力量的来源"。→ 详细
06

场景一 · 客服问题解决 agent:反模式是"拿到响应就用",正解是"围绕 stop reason 循环"

按 stop_reason 分支的 agent 循环代码 ▲ 图注:场景一的正解代码:while True 里按 stop_reason 分支。要点是模型自己不执行工具——它只把工具请求递出来,真正执行的是你的代码,执行完再把结果回灌继续循环。

  • 反模式:直接让 agent 跑一趟,把返回的响应拿来就用。→ 详细
  • 正解:写一个 while true 循环,每轮按 stop reason(停止原因,即模型这一轮为什么把控制权交回给你) 分支。循环第一块调用模型,把 messages(context window 里那一串 prompt 的序列)连同 prompt、context、tool 一起传进去。→ 详细
  • 最容易被误解的一条LLM 自己不执行 tool。讲者说得很直白——"它只是一个概率性的下一个词预测器……它除了跟你说话什么都做不了"。它能做的是把参数配好;真正执行工具的是你的代码→ 详细
  • 分支怎么走:stop reason 若是 tool use(模型想用工具),就去执行那个工具、把结果回灌,继续循环;模型看到"跑成功了"、不再要工具,循环结束。→ 详细
  • 出口必须挂两个东西:① human in the loop(人在环里)——拿到答案先检查置信度,靠谱就留,不靠谱就升级给人处理;② token 耗尽也是一种 stop reason——这种情况模型照样返回一个响应,但那是被迫中断时基于不完整内容给出的,不看 stop reason 就会把半截答案当完整答案用。→ 详细
07

场景二 · 代码生成:CLAUDE.md 分三层

CLAUDE.md 三层规则的正例与反例 ▲ 图注:场景二的一句话原则:「CLAUDE.md:正确的规则要待在正确的层级」——项目顶层、项目文件夹、子目录各放各的规则,别把所有约定堆在一个文件里。

  • Claude Code 用 CLAUDE.md(一个 markdown 文件,把希望它知道的规矩写进去)来喂规则。→ 详细
  • Anthropic 建议设三层:项目最上层一份、项目文件夹里一份、各个子目录里还可以再指定——形成一套分层的规则来控制系统怎么响应。→ 详细
08

场景三(上)· 多 agent 研究系统:反模式是"一个 agent 塞满工具"

多 agent 系统的模式与反模式对照 ▲ 图注:本场最典型的一张对照表:左绿是 PATTERN、右黄是 ANTI-PATTERN。「专业化,别超载」对「一个 agent 什么工具都给」「隔离子 agent 的上下文」对「把完整上下文泄漏出去」——这正是他整场「先讲反模式」讲法的样板。

  • 先摆出几个必须想清楚的问题:agent 怎么分工?是不是中心辐射式(hub and spoke,一个中心调度、多个分支执行)?谁当 orchestrator(编排者)?它们各自该知道多少信息?→ 详细
  • 反模式:只用一个 agent,往它身上塞满各种 tool。他的比喻很好记:你请木匠来家里干活,结果这人带着水管工的工具、木匠的工具、电工的工具,说"我什么都能干"——你想要的其实是一个专业的木匠。→ 详细
  • 正解:借函数式编程那条老规矩——一个函数只做一件事。"如果你能让你的 agent 只做一件事,最多配一两个 tool,那就是一次胜利。"一句话:要专一,别塞太满→ 详细
  • 同一场景下还有一条老经验:多线程共享内存会引出同步问题、要加锁,所以让线程独立,也让 agent 独立——"让每个任务待在自己的小宇宙里"。→ 详细
09

场景三(下)· 子 agent 的 context 不许溢出,因为 agent 会「群体思维」

  • 第二条反模式:让子 agent 的 context 溢出到主 context 里。理由有两层——context 就意味着 token,token 就意味着钱;而且context 越多,LLM 给答案时越容易犯迷糊。别因为"一百万 token 的窗口"就什么都往里塞,限制进去的东西,系统才更准→ 详细
  • 具体做法(critic 子 agent 的例子):你跑完一轮,想让一个 critic(评审 agent) 来审。只传给它 claim(结论/方案)和 evidence(支撑证据),不给它形成这个 claim 的整个思考过程。→ 详细
  • 为什么要藏起思考过程:一堆 agent 凑在一起协作、互相交流会出现 group think(群体思维)——"所有 agent 好像都会收敛到同一个想法上去"。他的比喻:派对上所有人都想吃披萨,就你不想,但别人一劝你也就跟着去了,因为你不想扫大家的兴。"agent 好像也是这么运作的。"→ 详细
  • 顺着披萨接出的总结句:每个 agent 只拿自己那一片→ 详细
10

场景四 · 开发者生产力:context fork + 只回灌汇总 + 到点压缩

fork 噪声工作、窗口满时压缩 ▲ 图注:场景四的一句话:「把吵闹的活 fork 出去;窗口满了就压缩」——高消耗低结论的环节单开一条上下文,只把汇总回灌主线程。

  • 反模式(两条):① 让每个子任务把完整输出一股脑倒进主线程,把 context 挤爆;② 让 context 无限制地涨→ 详细
  • 正解一 · context fork(上下文分叉):以"扫描所有日志里的 error 并汇总问题出在哪"为例——把 agent fork 到一个类似独立线程的地方,它在里面做的、想的、堆出来的那些 token 都不回流污染主 context;干完之后只把那份汇总、不带其他杂七杂八的东西加回上层 context→ 详细
  • 正解二 · compaction(压缩,把长会话的 context 折叠成更短的摘要):先检查当前 token 数,设一个上限——"一旦超过 15 万 token,你就可以跑一次 compact"。讲者坦承 Anthropic/Claude 的 compaction 具体怎么实现的他也不确定,但这个机制确实存在。→ 详细
11

题外话:会场小册子里的「自定义 context 压缩」

  • 他插了一段现场见闻:会场外有人在发小册子,他昨晚翻到其中一段,说某人的公司提供自定义的 context 压缩逻辑——继承他的基类、写自己的压缩规则,留什么、压什么由你判断哪些重要来定→ 详细
  • ⚠️ 转写存疑:作者名(转写作 "Sam Bagwell",讲者本人也卡了一下,并说"我根本不认识他")和"在线版第 32 页"这个出处,ASR 可信度低,不建议直接引用。→ 详细
12

场景五 · Claude Code 进持续集成:流水线里不能留交互模式

CI/CD 场景的模式与反模式 ▲ 图注:场景五的对照:PATTERN 是*无头运行、解析 JSON + 让延迟匹配任务;ANTI-PATTERN 是在流水线里留交互模式 + 为可以等的活阻塞。*

  • 反模式:在 CI(持续集成,代码提交后自动跑构建和测试的流水线) 里还留着交互模式——那样 Claude 会停下来问"你要做这个吗?这个能给我权限吗?",整条线就卡住。→ 详细
  • 正解:有办法把它配置成一路跑到底(讲者没展开具体参数)。→ 详细
13

省钱贴士:batch 模式便宜一半

  • 把 prompt、把要干的活打包成一个 batch(批处理) 提交,token 成本便宜 50%,24 小时内给结果。→ 详细
  • 适用场景他说得很生活化:要去睡个午觉、要去度假、要休一天假——那就用 batch 模式跑,账单会轻不少。→ 详细

收尾引用与讲者联系方式 ▲ 图注:收尾页引用 Corita Kent:「Nothing is a mistake. There is no win, no fail. Only MAKE.」——呼应全场「反模式不是失败清单,是造东西的路标」。页面下方是讲者的几个联系方式(截帧分辨率有限,具体账号请以原片为准)。

  • 闪电问答:(本期无)——19 分钟的单人演讲,没有问答环节。

  • 收尾金句(把开场那句改了一个词):"记住,没有什么是错误,没有赢,没有输,也没有什么考试,只有去做。你动手做,做出来,你就会成功。"→ 详细

  • 邮箱:口播是 "coyle at Berkeley"(只念了这两截,完整域名没给全)。→ 详细

  • 个人网站:口播作 "co-supreme AI"(⚠️ 转写存疑,确切拼写不确定)——他说这名字是照 John Coltrane 的《A Love Supreme》 取的,因为他是爵士乐迷。→ 详细

🎯 于你何益 为你定制 · 非通用结论

先说判断:这期强相关,而且是少见的"结构本身就是可交付物"。你手上两条多-Agent 流水线——Holdwell 的 PRD 工厂、app_incubator 的造 App 链路——缺的正是一份"哪几条是坑"的目录。这场演讲把它列出来了,而且每条都是"反模式 → 正解"成对给的。

一、Holdwell ERP 的多-Agent PRD 工厂

1. 反模式目录,就是你那条流水线一直缺的那张表

  • 怎么做的:Frank 走每个生产场景都是同一个套路——先说不该做什么,再给正解。他明说这不只是教学法,也是答题法:"解决问题的方式有很多种,但很关键的一点是「什么不能做」。"背后的历史依据是 1990 年代的设计模式运动:模式和反模式成对出现,而反模式往往更好用,因为它把无穷多种错法收敛成有限几条。
  • 你可以怎么做:你给 PRD 工厂写了大量"该怎么做"——三驾马车的职责、碰撞协议六步、agent 定义,但没有一份"这么干必废"的清单。花一小时,把你已经踩过的坑写成 5–8 条反模式(每条两行:反模式是什么 → 正解是什么),贴在流水线入口说明的最前面。你多半会发现,碰撞纪律之所以让你不放心,常常是因为没人写下来"跳过它会发生什么"

2. "要专一,别塞太满"——对着三驾马车的职责盘一遍

  • 怎么做的:反模式是一个 agent 身上塞满各种工具。他的比喻是请木匠:人来了,背着水管工、木匠、电工三套工具,说"我什么都能干"——你其实想要一个专业木匠。正解借的是函数式编程那条老规矩:一个函数只做一件事;"如果你能让你的 agent 只做一件事,最多配一两个 tool,那就是一次胜利。"
  • 你可以怎么做:拉一张"角色 × 它实际背的职责"的矩阵(.Codex/agents/*.toml 里就能数)。凡是一个角色的定义里塞了三件以上不同性质的活的,要么拆职责,要么收权。判断标准别用"它能不能干",用"它是不是这件事的专业木匠"——一个既写需求、又做评审、又管实体建模的角色,就是那个背三套工具上门的人。

3. 碰撞的那几个角色,别让它们看见前面的讨论过程

  • 怎么做的:他举了 critic(评审 agent)的例子:只传结论和证据,不给形成这个结论的思考过程。理由不是省 token,是防群体思维——"一堆 agent 凑在一起协作、互相交流,所有 agent 好像都会收敛到同一个想法上去"。他的比喻是派对上所有人都想吃披萨、就你不想,但别人一劝你也就跟着去了,因为不想扫大家的兴。
  • 你可以怎么做:这条直接打在你的碰撞协议上——你规定独立初稿互不可见,赌的就是防群体思维;但如果碰撞环节几个角色拿到的是同一份"包含前面所有讨论"的上下文,你得到的不是几个独立意见,而是同一个意见被点了几次头——这也正是"碰撞纪律走空"的一种形态:碰撞看起来都做了,但没有一个角色是真正独立看过的。改法很轻:让每个角色只拿到对方初稿文本 + 支撑材料,写作过程、前序讨论、别的角色的结论一律不给。

4. 把检查点从"文档里的规定"改成"按上一步的返回状态分支"

  • 怎么做的:他反复强调 stop reason(模型这一轮为什么把控制权交回来)。正确的循环不是"跑一趟拿结果",而是每轮按 stop reason 走不同分支:模型说要用工具 → 由你的代码去执行(模型自己什么都执行不了,它只是"概率性的下一个词预测器"),结果回灌继续;模型不要工具了 → 出循环。特别提醒:token 用尽也是一种停止原因,这时模型照样返回一个"看起来完整"的答案,其实是半截的。出口再挂一道人工:检查置信度,够就留,不够就升级给人
  • 你可以怎么做:你的流程停点现在靠"文档里写着必须做"生效,所以会被跳过。改成流程按上一步交回来的状态分支:每个环节结束时带一个明确状态(做完了 / 缺材料 / 证据不足 / 超长被截断),下一步读状态决定走哪条路,人只在"证据不足"时被叫醒。"半截答案看起来像完整答案"这一条,值得单独写进你反模式清单的第一行。

二、app_incubator 的 7-Agent 造 App 链路

5. 高消耗、低结论的环节,fork 出去、只回灌汇总

  • 怎么做的:反模式是每个子任务把完整输出倒进主线程,把上下文挤爆。正解叫 context fork(上下文分叉):以"扫描所有日志找 error"为例,把这活 fork 到一个独立分支里跑,它在里面读的、想的、堆出来的 token 都不回流主上下文,最后只把汇总加回来。再配一道阈值:检查 token 数,超过 15 万就跑一次压缩
  • 你可以怎么做:7 个 agent 串起来最典型的死法,就是走到第四五个时主线程已经被前面几个的完整输出撑爆。把"读代码库、抓设计稿、扫笔记库"这类读得多、结论少的环节挑出来,规定它们只能往主线程回灌一段结构化摘要(比如"改了哪几个文件 / 设计稿里有哪几条硬约束"),原始内容留在分支里。这也顺带回答你那个"把该做什么前移到 agent"的痛点——前移的前提,是后面的 agent 还有上下文可用

6. 想无人值守的那几段,先把权限清单定死

  • 怎么做的:Claude Code 进持续集成的反模式是流水线里还留着交互模式——它会停下来问"你要做这个吗?这个能给我权限吗?",整条线就卡住。正解是配置成一路跑到底(他没展开怎么配)。
  • 你可以怎么做:造 App 链路里凡是你希望"点一下就自己跑完"的段落,提前把它需要的权限列全并授掉;跑之前先自问一句"这一段会不会在中间停下来问我"。能不能无人值守,是这条链路从玩具变成产线的分水岭。

7. 不赶时间的批量活走 batch,直接省一半

  • 怎么做的:把 prompt 和要干的活打包成一个 batch(批处理) 提交,token 成本便宜 50%,24 小时内出结果。他的用法很朴素:"要去睡个午觉、要去度假、要休一天假,那就用 batch 模式跑。"
  • 你可以怎么做:链路里那些不需要你盯着的批量环节——批量生成文案变体、批量重跑一遍历史需求的评审、批量试一批提示词——挪到批处理里,一晚上跑完,账单减半。

三、这本第二大脑(Personal Thinking)

8. 分层规则文件:你最近刚做完的那件事,正是官方推荐做法

  • 怎么做的:Anthropic 建议规则文件设三层——项目最上层一份、项目文件夹里一份、各个子目录里还能再指定,形成一套分层的规则去控制系统怎么响应。
  • 你可以怎么做:你刚把这本库的入口文件从一百多行砍到几十行、把协议全文推到二级目录,方向和他说的完全一致。还能再往下切一层:转写归档目录里放一份只管"这一类产物的规矩"的说明(命名、存放、每期只留一个文件夹),主入口就不必替它记这些。判断标准很简单:主入口只留路由,具体规矩住在它管辖的那层目录里。

四、一人公司账号(onehuman_company)

9. 这一期是"大佬说 X,我试了"的现成弹药库

  • 怎么做的:Frank 给的每条反模式都是可证伪的具体主张,不是正确的废话——一个 agent 最多配一两个工具;评审 agent 只给结论和证据、不给过程;超过 15 万 token 就压缩;持续集成里必须关掉交互;批处理便宜 50%。而且它们成对出现(反模式 → 正解),天生适合做对照实验。
  • 你可以怎么做:挑一条拿你自己的多-Agent 链路实测,出一篇验证体。首选"评审只给结论和证据"这条——它反直觉(大多数人觉得给的上下文越全越好)、成本低(改一次输入就能跑对照)、结果可视(同一份稿子,给全过程 vs 只给结论,几个角色的意见分散度差多少,截图就能说明)。这篇能过弹药库闸门:删掉你的实测对比,这个观点就只剩一句听过就忘的建议。

该反着用

Frank 的听众是要找工作的学生,他的落点是"去看看这个考试、甚至考一个"。你不需要这张证书——99 美元和半年一次的考试机会对你没有意义,那六个生产场景对你才有意义。反过来用:把六个场景(客服解决、代码生成、多 agent 研究、开发者生产力、持续集成、结构化数据抽取)当成你自己两条流水线的验收清单,逐条问"我这条线在这个场景下的反模式是什么、我防住了吗"。另外,他讲的是官方给的通用场景,你做的是垂直 ERP 和造 App——坑的类型可以借,坑的位置得自己踩

和你现在做法冲突

你在 PRD 工厂上加的是"更结构化":六步流程、三份独立初稿、碰撞互看、全量快照重出。而他整场的主旋律是"更少"——少给工具、少给上下文、少让 agent 之间互相说话。这两条不可能同时都对。真正的张力落在他没解答的地方:你的碰撞环节本质上就是"让 agent 之间互相说话",那"该互看的碰撞"和"该隔离的初稿"之间,线画在哪? 他只说了"别让子 agent 的上下文溢出到主上下文",没说共享层该怎么建、什么算合法共享。这个问题得你自己答,而且答案很可能决定碰撞是真交锋,还是互相传染。

对你的镜子

你这一年补的都是"该怎么做"——更全的规格、更细的角色定义、更硬的流程。这期提醒的是:卡住一条流水线的,通常不是没人写清楚该怎么做,而是没人写下来不该怎么做。 一份反模式清单的边际收益,很可能高于往 agent 定义里再加一段职责。

所以呢

  • 【耐用】反模式先于模式:把错法写下来,正解会自己收敛。这条从 1990 年代设计模式运动活到今天,模型再换几代也不会过期。
  • 【耐用】少即准:给 agent 的信息越少,它越准。这不是模型能力问题,是结构问题——上下文既是钱,也是噪音。
  • 【耐用】独立才有独立意见:让评审看不见形成过程,才可能拿到真正的第二个意见。这条对 agent 成立,对人组成的评审会同样成立。
  • 【会过期】所有具体数字:15 万 token 触发压缩、一个 agent 配一两个工具、批处理便宜 50%——都会随模型换代和定价变动漂移。讲者自己都说不清压缩到底怎么实现的,别把这些数字当常量焊进流水线。
  • 判断更新:你之前默认"多 agent 系统的质量取决于角色设计得多细"。这期给的反例是——质量更取决于每个 agent 被剥夺了多少信息。剥夺是一个设计动作,不是省钱动作。
  • 这周一个赌注:花一小时,给 PRD 工厂写出第一版反模式清单(先写 5 条你自己已经踩过的,每条"反模式 → 正解"两行)。跑完这一小时,你就知道这份清单该不该长成一份独立文档。
接着读