先说判断:这期强相关,而且是少见的"结构本身就是可交付物"。你手上两条多-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 条你自己已经踩过的,每条"反模式 → 正解"两行)。跑完这一小时,你就知道这份清单该不该长成一份独立文档。