先说结论：本期强相关。 不是因为它讲 AI，而是因为整场圆桌在算的那笔账，跟你「一人公司」那根「AI 员工管理成本账」的支柱是同一笔账；而它关于「怎么给多 agent 链路派活」的结论，直接顶到了 app_incubator 和 Holdwell 那条多角色流水线的设计上。
一、onehuman_company（一人公司 build-in-public）· 对准「AI 员工管理成本账」
① 「便宜模型总账更贵」是一条现成的验证体选题
- 怎么做的：OpenRouter 的 Alex 在台上抛的数字是——拿 terminal bench 跑 Opus 和 Haiku，Opus 分数大约好 3 倍，总成本却只有 Haiku 的十分之一，尽管 Haiku 每 token 便宜得多。机制不玄：小模型一旦被推出自己见过的训练分布，就会反复调工具、陷进离谱的循环，轮次多到把单价差距吃干净还倒贴。他还甩了个旁证：OpenRouter 公开排行榜上，分类任务按消费金额排第一的模型是 Opus——最该给小模型干的活，钱却流向了最贵的那个。
- 你可以怎么做：这条几乎是为你那根支柱写的——标题都现成：「我给我的 AI 员工降薪，结果账单涨了」。但别只转述数字，那过不了你自己的弹药库闸门（删掉你的判断和实测还成立的内容不发）。要实测：在 drizzle tech 一条真实链路上（比如造 App 链路里某个固定环节）锁死同一个任务，跑 A/B——A 全程用贵模型，B 把执行步换成便宜模型，两边只记两个数：完成一次任务的总花费和总耗时/总轮次。哪怕只翻一次车，你就有了一篇带自己数据的验证体，而不是又一条转述。
② 真正的省钱开关不是「换便宜的」，是「别丢缓存」
- 怎么做的：Cognition 把「Fable 级智能」的成本降了 40%，办法不是把用户降级到便宜模型，而是让贵模型继续做规划和难决策、把执行派给便宜的实现模型。而在实现上他们刻意不用「主 agent + 一堆用完即弃的 sub-agent」，改用一个不解散、持续保有上下文的 sidekick——因为缓存 token 便宜 10 倍，每开一个新 sub-agent 重新灌上下文，等于把这 10 倍折扣扔掉。Walden 还点了多模型最常见的翻车方式：「就这一次文件读取，现在每个模型都要把这同一个文件读一遍，于是你被收了三倍的钱。」
- 你可以怎么做：给你的成本账加一个此前多半没记的科目——重复灌上下文的钱。下次盘 AI 员工账单时，数一下「同一份需求文档 / 同一段代码，在一次任务里被几个 agent 分别读了几遍」。这个数字本身就是内容：一人公司的读者最认「我以为我在省钱，其实我在为同一份文件付三遍钱」这种账，而且它可抄——每个用多 agent 的人回去都能数一遍自己的。
③ 一次上下文压缩 ＝ 那批输入 token 按 10 倍计价
- 怎么做的：Walden 的账是：compaction（工作记录太长时压成摘要再继续）一做，就等于吃一次缓存未命中，那批输入 token 现在要付的钱是不压缩时的 10 倍。所以他们做压缩的主要原因根本不是省钱，是智能——各家宣传百万 token 上下文，他「基本不会建议这些模型用到 200K token 以上，能压在 100K 以内最好」，因为到某个点智能会断崖式下跌。
- 你可以怎么做：你那几条长链路（PRD 工厂、造 App 链路、第二大脑处理长文）里每一次「太长了，压一下」都是一次真金白银的重新计费。把压缩时机从「长了就压」改成「反正要换模型/换阶段时顺手压」，成本立刻不一样。这也是一条能写的短篇：「AI 的记性不是越大越好」——配上你自己链路里超过某个长度后质量明显掉下去的观察，正好是「大佬说 X 我试了」的形状。
④ 看不见的常驻消耗才是账单杀手
- 怎么做的：Alex 讲了 OpenRouter auto router 被引爆的原因——某个非常流行的应用每 10 分钟往你选定的模型发一次心跳，纯粹为了确认客户端还活着；如果你把 Opus 设成默认模型，光这个心跳就烧掉大量 token。一个应用内部同时存在两种完全不同的智能需求，这才是路由真正的起点。
- 你可以怎么做：翻一遍你那套 9+1 Agent 里所有「常驻 / 轮询 / 守护」类动作（定时巡检、内容雷达、每日简报），看有没有哪个在拿贵模型干纯打卡级的活。这类「体检」选题对一人公司读者可抄性极高：列出你的 AI 员工里谁在拿高薪打卡，附一张改前改后的账单对比。
二、app_incubator + Codex Holdwell ERP work（多角色 agent 流水线）· 工程纪律
① 派活要按「会话走到哪儿了」，不按「这是什么类型的任务」
- 怎么做的：这是 Cognition 最硬的一条结论——按任务类型做初步路由「极其脆弱，而且你处理的任务越 agentic 就越脆」。他给的画面是一条真实会话轨迹：先问代码库怎么运作 → 再让它实现功能 → 再让它跑实测调深层 bug。复杂度和类型一路在变，「你并不希望自己被留在一个配不上当前任务的次等模型上」。panel 上另一位换了个更好记的说法：要「把事情看成一个个子任务和 session，而不是一个个孤立的待解问题」。
- 你可以怎么做：如果你的多角色链路是「按角色 / 按环节各配一个模型」定死的，这条正好说清它脆在哪。改法不必大动：在阶段推进的那几个交接点上加一次「当前任务性质变了吗」的判断，让模型档位跟着阶段走而不是跟着角色走。最省事的落点就是那几个跨阶段的交接处——那也正是你现在最容易掉链子的地方。
② 「永远留一个聪明的在场」比再加一道流程闸门便宜
- 怎么做的：Cognition 的解法不是把路由算法做得更聪明，而是永远留一个前沿 agent 在旁边盯着——哪怕干活的不是它，它也要能判断「我派出去的那个已经超出能力范围了」。Walden 的原话：光是这个保证，「就把这类系统的脆弱性降低了很多」。更妙的是成本技巧：反正每隔几分钟要刷新一次缓存，那次刷新就能顺带白拿一次前沿模型的调用——问它一句「小模型是不是钻死胡同了、需不需要帮忙」。
- 你可以怎么做：你 PRD 工厂那边一直悬着「碰撞协议的纪律到底守没守住」的问题。这条给的思路是：与其再加一道流程闸门（那道闸门的真实成本是你的注意力），不如加一个常驻观察者——一个贵模型的旁观角色，只做一件事：定期看一眼当前 agent 的产出，判断它有没有走偏、该不该升档。用「反正要换阶段 / 反正要刷缓存」的时机去触发它，边际成本极低，而且它管的是所有角色，不用每个环节各加一遍。
③ sidekick 而不是一堆 sub-agent
- 怎么做的：Cognition 明确说「主 agent + 一堆 sub-agent」的结构「会白白浪费很多」，因为每个 sub-agent 都要重新接收上下文；他们改用一个持续保有上下文的固定副手，而且主副位置可以来回换。同时 OpenRouter 内部对「外层编排模型该大还是该小」至今没有定论——他们只在 deep research 场景验证过「聪明模型当外层」最好，写代码场景明确说还没优化，「也可能反倒是小模型每完成一个任务更省钱」。
- 你可以怎么做：把你链路里那些「开一个、用完扔」的临时 agent 挑出来，看哪几个其实是同一条上下文的延续——那几个合并成一个不解散的副手。同时记住 Alex 的诚实：外层该大该小在你的场景里必须自己测，别照抄别人 deep research 的结论直接套到写代码上。
④ 交接只给引用和高层思路，别把全量 trace 倒过去
- 怎么做的：Walden 说他们花大量时间调的就是「回传什么」：默认绝大部分上下文只流向一个模型，回传给主模型的是「它读了哪些文件」和「它在做什么的高层思路」，甚至专门调教小模型汇报的能力。落到实操就是 sidekick 说「我找到的东西都在这儿」时只给文件引用，不把内容整个倒出来；而更聪明的模型读东西反而更省 token——只看关键部分，或者「跑一条命令就能确认是不是都弄对了」。
- 你可以怎么做：这条直接对到你那个「跨线对齐」的痛点。对齐不必先建成完整数据模型——先规定交接协议：agent 之间交接时只允许传「文件路径 + 三行高层结论 + 需要对方决定的那一件事」，原文一律留在文件系统里让对方自己去取。这同时掐住了漂移：所有人指向同一批文件，而不是各自带一份被压缩过、已经开始漂移的副本。
⑤ 用真实使用信号迭代路由，而不是拿数据集调
- 怎么做的：Walden 剧透了他们想做但还没做的事：不拿数据集调优，而是收集真实信号——用户自己主动升级 / 降级模型、系统发现最初路由错了要换。把「当时路由到了哪个、本该路由到哪个」持续记下来，在内部搭系统全捕获，不断迭代直到贴合真实生产数据。
- 你可以怎么做：这正好补你「agent 产出可观测/可验证」的缺口，而且成本极低：在链路里加一行日志，只记三件事——这一步派给了谁、我有没有中途手动接管或升档、最后有没有返工。攒一个月，你既有了路由调优的依据，也第一次有了「这条流水线到底有没有用」的可量化证据，不用再靠印象汇报。
⑥ prompt 怎么迭代：让聪明模型解释走偏，再当回归测试跑一遍
- 怎么做的：对自动化 prompt 调优框架 Walden 不看好，他更信一套「重得多但更聪明」的办法：把当时的决策和上下文交给一个聪明模型，问「为什么走偏了」，甚至笨到直接问「你为什么选了这个而不是那个」、让它引出是哪句 prompt 导致的，然后让 Devin 去改 prompt，再把这个 case 当回归测试跑一遍确认结果真的变了。Alex 补的半句同样重要：prompt 就是创业公司做产品这个过程的一部分，好在它特别容易观测——任何人或 agent 都能翻 trace、改 prompt、实时看准确率变化。
- 你可以怎么做：你有一批 skill 和 agent 定义在跑，如果迭代方式还是「人肉觉得不好就改两句」，换成这套三步：留住失败那次的完整 trace → 让一个贵模型出具「为什么走偏 + 是哪句 prompt 导致的」→ 改完把这个 case 存成回归用例。三次之后你就有了一个属于自己的失败案例库——这本身也是「一人公司」最好的内容原料，因为别人手上没有。
三、Personal Thinking（第二大脑）
有损压缩 + 无损兜底：你的报告结构已经踩对了，可以更自觉地用
- 怎么做的：Walden 那段关于上下文的哲学是全场最耐嚼的：人一次能记住的数字少得可怜，「某种意义上你可以说，你的 context window 比这些语言模型还短」，可你照样做得很好——因为你有文件系统这种无损系统兜底。所以好系统的标准不是「什么都带在身上」，而是「具备找到它所需内容的一切条件，哪怕这些内容并不都摆在眼前」。panel 上还有人提出用代码的结构化表示做「近乎无损」的压缩，因为纯摘要式压缩本质是有损的。
- 你可以怎么做：你的总结报告 + 每条
[→ 详细] 锚点，正好就是「有损摘要 + 无损原文」这个结构——但你现在多半只把它当阅读便利。把它当检索契约来用：以后写摘要时的自检不再是「我有没有把重要的都写进来」（这是不可能达成的目标），而是「任何一条结论，读者或未来的 agent 能不能在 30 秒内回到原文那一句」。这条也是你摄入 SOP 信噪比问题的正解：宁可摘得更短，但每条都可回溯。
四、StockHelp / 你的价值投资视角（一条，只是分析框架）
- 怎么做的：全场收尾的问题是「router 最终是一个独立产品，还是变成底层管道的一部分？」panel 上有人用 Web 的历史给了判断：当年 Web 起来时也有基于流量的路由，「所有这类路由控制权，随着时间推移都逐渐集中化了」，理由是应用跑在非确定性系统之上、信任度很低，仲裁只能落在编排这一层。Alex 给了反面情形：也许会出现一个大模型说「任何任务我都做得更好还更便宜，我凭什么把活派给别人」。
- 你可以怎么做：这是一个可以直接加进你选股清单的问题模板——「一个新出现的中间层，最终会长成有护城河的产品，还是被上下游吸收成管道？」判据这场圆桌也给了：如果它的价值来自「知道每个模型的真实行为、握有真实使用信号、掌握缓存位置」，那它像产品；如果只是转发，那它像管道。同一把尺子可以量你 watchlist 里任何一家做「中间层」生意的公司。（这是分析框架，不是任何买卖建议。）
更深三角度
该反着用：台上三家都是资源充足的团队，他们搭复杂编排是为了把每 token 的钱压下来。你的稀缺资源不是钱，是精力和注意力——照抄「三层编排 + 自训协作模型」对你是反向浪费。正确读法是：只取那条最贵的教训（别让便宜模型硬扛分布外的活 + 留一个聪明的在场），跳过所有需要长期维护的编排基建。Walden 自己都说，他希望一年后回头看 Devin Fusion 的这些技术「已经很老古董了」——追一条正在剧烈变化的曲线，不是一个人公司该下的注；等它沉淀成别人的默认能力再接手，成本低得多。
和你现在做法冲突：你的多 agent 体系是按角色分工的（PRD 工厂的三驾马车、造 App 的 9+1 个 Agent，各司其职）。这场圆桌的核心结论——路由要按会话阶段而不是任务标签——跟「角色即分工」是有张力的：真实工作流里，同一个角色在不同阶段需要的智能档位能差好几档，而不同角色在同一阶段的需求可能完全一样。另一处张力更直接：如果你现在的交接方式是把上一个 agent 的完整产物塞给下一个，那「同一个文件被收三遍钱」和「压缩一次按 10 倍计价」就是你账单上一直没被解释的那部分。这两条我不替你下结论，但它们值得你在下次改链路前先测一次。
对你的镜子：全场没有一个人在争论「哪个模型更强」，他们争的是每完成一件事花多少钱。把分母从「每 token」换成「每件事」，结论就整个翻过来了。你自己的时间也是同一道题：手动干、用弱工具反复试，单价最低（不花钱），但「完成一件事」的总成本最高。你那条「判断力 > 努力」的操作系统，其实就是这场圆桌用美元重讲了一遍。
所以呢
- 可迁移思维模型【耐用】：① 换分母——任何成本比较都要问「每完成一个任务多少钱」，而不是「每单位多少钱」；② 分布内 / 分布外才是决定「能不能上便宜方案」的那条线，而不是任务难不难；③ 永远留一个聪明的在场——用一个低成本的常驻观察者，换系统脆弱性的大幅下降；④ 有损压缩必须配无损兜底，好系统的标准是「能找到」而不是「全带着」。
- 【会过期】：40%、缓存便宜 10 倍、5 分钟缓存窗口、200K/100K 的上下文建议、terminal bench 上的 3 倍 / 十分之一——这些数字和 sidekick 这种具体形态，按讲者自己的预期一年内就会被换掉。记结论的结构，别记数字。
- 判断更新：你此前多半默认「便宜的活派便宜模型」是省钱的默认动作。本期之后该改成：先问这活在不在它的分布内——分布内就大胆用小的（分类、抽取这类活会越来越多），分布外就别省，省下的单价会以轮次的形式加倍还回来。
- 这周一个赌注：挑 drizzle tech 里你最常跑的一条链路，做一次同任务双跑（全程贵模型 vs 关键步降级），只记两个数：完成一次的总花费和总耗时。一周内出结果——赢了是一个工程决定，输了是「一人公司」的一篇带自己数据的验证体存稿。两头都不亏。