← 主页 NO.144

第 144 期 · AGENT 工程 · 收录于 2026 年 8 月 16 日

模型路由的现状——NVIDIA、Cognition、OpenRouter

AI Engineer

Agent 工程

视频 48:14 原文约 5.0 万字预计阅读 24 分钟来源视频 ↗ 中英对照全文

原平台热度 YouTube ↗

2,893观看

60赞

2.1%点赞率

7评论

62.7万频道订阅

数据截至 8 月 27 日

TL;DR · 三句话

一便宜模型的总账更贵：拿 terminal bench（一类让模型在命令行环境里实际动手完成任务的评测）去跑，Opus 的分数大约好 3 倍，总成本却只有 Haiku 的十分之一——尽管 Haiku 每 token 便宜得多。原因是小模型一旦被推出自己的训练分布，就会疯狂调工具、陷进循环，轮次多到把单价差距吃干净还倒贴。→ 详细
二于是「哪个模型 benchmark 高就把哪类任务派给它」的朴素路由被整个推翻：Cognition 说按任务类型路由「极其脆弱，任务越 agentic 就越脆」，因为一次会话中途任务会变性质（先问代码库怎么运作 → 再让它实现功能 → 再让它跑实测调 bug）；正解是永远留一个前沿模型在场盯着、把执行派出去，他们靠这个把「Fable 级智能」的成本降了 40%。→ 详细
三省钱的真正开关不在「换便宜模型」，在「别丢缓存」：Cognition 用一个持续保有上下文的 sidekick、而不是一堆用完即弃的 sub-agent，因为缓存 token 便宜 10 倍；而每做一次上下文压缩就等于吃一次缓存未命中，那批输入 token 立刻按 10 倍计价。→ 详细

谁在台上（以及一个关于发言人归属的说明）

Walden Yan：Cognition 联创，产品是 Devin（AI 软件工程师）。客户天天问他「模型的 ROI 怎么算？哪些任务值得用最贵的模型？」 → 详细
Alex Atallah：OpenRouter 的人，直接从机场赶来（迟到了还得借麦克风）。OpenRouter 是语言模型的 marketplace——把各家模型聚合起来转卖的中转市场。 → 详细
Carter：NVIDIA 的 developer tech engineer，问题意识很朴素——前沿模型（frontier model，各家最强最贵的那一档）越来越贵，个人开发者和小公司想按心里想的频率用最好的工具，成本上吃不消。 → 详细
第四位（转写标为 Tuhin）：做模型评测出身，既看准确率也看效率和成本，再拿这些认知去搭 router。 → 详细
主持人本人也是 NVIDIA 的（开场即说「这也是我们在 NVIDIA 发布 Nemotron 的原因——数据集、权重、配方全部放出来」），所以台上其实是三个 NVIDIA 人 + Cognition + OpenRouter。 → 详细
⚠️ 说明：转写的发言人标注有几处明显不可靠——收尾时明显在主持全场的那几轮被标成了「NVIDIA 代表」，另有整段只标「NVIDIA」没说是谁。所以下文只对 Walden Yan 和 Alex Atallah 点名（他们的发言里有大量「我们 Cognition／我们 OpenRouter」的自指可交叉验证），NVIDIA 方的观点一律写成「panel 上有人提出」。宁可不写名字，也不安错人。

全场最反直觉的一个数字：便宜模型的总账更贵

Alex 的原话：「你拿 terminal bench 去跑 Opus 和 Haiku，Opus 的表现大概好 3 倍，成本却只有 Haiku 的十分之一——尽管 Haiku 单 token 便宜得多。」 → 详细
机制不是玄学：小模型一旦被推出自己的训练分布，就会「疯狂调工具、陷进各种离谱的循环里」。单 token 便宜，但完成一次任务要烧掉的轮次多到把差价吃干净还倒贴。 → 详细
所以计价的分母得换：不是「每 token 多少钱」，而是「每成功完成一个任务多少钱」。Alex 自己在谈 Fusion 在写代码上还没优化时用的也正是这个口径——「也可能反倒是小模型效率更高，也就是每成功完成一个任务花的钱更少」。 → 详细
一个可以当旁证的数据：Alex 说去看 OpenRouter 公开的排行榜，在分类任务上按消费金额排第一的模型是——Opus（全场笑）。分类是最典型「该给小模型干」的活，钱却流向了最贵的那个。 → 详细

in / out of distribution：这条线才决定便宜方案省不省钱

术语：in distribution（分布内）＝这类任务长得像它训练数据里见过的东西；out of distribution（分布外）＝没见过。Alex 的判断是长期你想要模型自己知道「这在我的训练数据里」——分布内小模型很好用、能省不少钱；分布外，小模型反而把成本推高。 → 详细
反过来的例子很具体：「这是人名还是机构名？」这类文本分类是极度 in domain 的活，「这种任务你不该丢给大模型，就该交给小模型，谁家都有这类落在自己 domain 里的活」。 → 详细
所以判断 in domain / out of domain 是 OpenRouter Fusion 投入最大的一块工作，另一块是搞清楚不同类型的任务该怎么编排外层模型和内层模型。 → 详细
Alex 的长期判断：用小模型处理分布内的简单任务机会非常大，而且这类任务在总量里的占比会越来越高——相对于那些最有价值、要靠非常聪明的模型花掉大部分时间去啃的任务。 → 详细

Cognition Fusion：不是换便宜模型，是让贵模型只做规划、把执行派出去

先澄清口径：主持人问「你们博客说比前沿模型表现还好」，Walden 特意纠正——不是说在 Fable 的水平之上又拉开一个身位，真正成立的说法是把「Fable 级智能」的成本降低了 40%。 → 详细
做法：让 Fable 继续负责规划和难的决策，把大量具体的活交给一个「实现模型」（implementation model）——可以是某个开源模型，也可以是更便宜的 mini 模型。 → 详细
反直觉的第二层：正因为执行模型便宜，你反而可以让它「以比原来更深、更狠的力度去啃这个任务」——比如一口气派出三个 sub agent（子 agent，主 agent 临时派出去干一件事的分身）去把代码库摸一遍，「这可能比让 Fable 自己去看代码库还更全面」。于是「更省钱」和「更周全」同时成立。 → 详细
底层哲学一句话：「越聪明的模型，越擅长把活派出去。」他们做 router 的理念是绝不把用户路由到一个更笨的模型上然后卡住——「接下来你还是得自己切回聪明的模型，那笔贵的成本照样得付」。 → 详细
主持人补的预算视角：前沿模型每 token 是这个价、小模型便宜得多，那你就能在原来那份预算之内让小模型跑多得多的 token。 → 详细

为什么「按任务类型路由」很脆：一次会话中途，任务会变性质

很多人看到「小模型在某些 benchmark 上比前沿模型还好」，第一反应是把那类任务直接路由给小模型。Walden：这种朴素做法「极其脆弱，而且你处理的任务越 agentic 就越脆」。 → 详细
他给的画面是一条真实的开发者会话轨迹：先问「这个代码库是怎么运作的？」→ 再问「你能不能帮我实现几个功能？」→ 再问「你现在能不能把这个功能拿去跑个实测，把那些很深的 case 调通？」——任务的复杂度和类型一路在变，「而你并不希望自己被留在一个配不上当前任务的次等模型上」。 → 详细
这也解释了大家为什么偏爱前沿模型：它们「就是通用地聪明，能在各种不同领域之间来回切换」，哪怕你在某些非常具体的任务上确实能榨出更好的表现。 → 详细
Cognition 的解法不是把路由做得更聪明，而是永远留一个主 frontier agent 在旁边看着——哪怕干活的不是它，它至少要一直盯着盘，能判断出「我派出去的那个 agent 现在已经超出它的能力范围了，我得把它换到别的地方去」。 → 详细
Walden 的总结句值得抄下来：「光是『系统里永远有 frontier 级智能在场』这个保证，就把这类系统的脆弱性降低了很多。」 → 详细
panel 上有人给了同一条纪律的另一种说法：routing 会随任务本身的演进而演进，所以更有用的看法是「把事情看成一个个子任务和 session，而不是一个个孤立的待解问题」，设计 router 的人必须理解这些不同复杂度的阶段，再决定是把活分给 sidekick 还是去借别的模型的专长。 → 详细

sidekick 而不是 sub-agent：真正的省钱开关是别把缓存丢了

术语先摆平：KV cache（键值缓存）是模型把已经读过的那段上下文算好的中间结果存起来，下次同样的前缀不用重算——所以这部分 token 收费便宜得多。Walden 给的倍数是便宜 10 倍。 → 详细
因此 Cognition 明确说，做成「主 agent + 一堆 sub-agent」那种结构「其实会白白浪费很多」。他们不用 sub-agent，用的是 sidekick——一个持续保有运行中 context 的固定副手，主 agent 不用把之前的上下文再喂一遍，「那些内容都还在 KV cache 里」。而且主副位置可以来回换：想把聪明模型从旁边换到主位、或者反过来，「完全没问题」。 → 详细
这条是对 Alex 观点的当场修正：Alex 说缓存红利来自主线那个负责编排的模型，Walden 说旁边那个 agent 同样能吃到缓存红利。 → 详细
Alex 那边的原始争论值得记下来：OpenRouter 内部最大的争论之一，就是负责编排（orchestration）的外层模型该用大模型还是小模型——「选择不同，结果差别非常大」，连价格影响都说不清，因为大模型当外层时可以靠自己的缓存做更多决策，而它缓存带来的省钱幅度常常比小模型夸张得多。 → 详细
Alex 的诚实边界：他们几周前发布的那批结果里，让聪明模型当外层 wrapper 效果最好——但那是 deep research 场景，「Fusion 在写代码这块还没怎么优化过」，换成别的任务「现在下结论还太早」。 → 详细

多模型系统很容易变得更贵：同一个文件被读三遍

Walden 的警告很直白：一旦你把多个模型放在一起跑，其实非常容易搞出一个反而更贵的系统——「就这一次文件读取，现在每个模型都要把这同一个文件读一遍，于是你被收了三倍的钱」。 → 详细
他们花大量时间琢磨出的诀窍：默认情况下绝大部分 context 只流向一个模型（比如都给小模型）；然后非常仔细地调「回传什么」——也许展示它读了哪些文件、把它在做什么的高层思路回传给主模型，甚至专门调教小模型「把 context 汇报回主模型」的能力。 → 详细
而这套东西不必从零发明：context compaction（上下文压缩：工作记录太长了，就压成一份摘要再继续）在做真正长时间运行的 agent 时本来就得先解决，直接把压缩后的 context 交回主 agent 即可。 → 详细
主持人替读者说出了那个隐忧：做 routing 等于在放大「浪费的、冗余的 token」，因为同一份东西你得在多个模型上各处理一遍。 → 详细

compaction 还是 routing：压缩一次就吃一次缓存未命中

panel 上有人提了个很实在的取舍：自托管时 context 越长成本越高（context 一深吞吐就掉），那与其换一个更便宜的模型，不如用 compaction 把吞吐拉回来——「一个是让要处理的 token 变少，一个是让 token 变便宜」。 → 详细
Walden 的反驳分两层。第一层是账：「你一做 compaction 就等于吃了一次 cache miss（缓存未命中）——那些 input token 你现在要付的钱，是不 compact 时的 10 倍。」所以光靠压缩解决不了成本和吞吐问题。 → 详细
第二层是他们真正压缩的原因——不是省钱，是智能：「各家都在宣传自己有多离谱的 context window，动不动一百万 token。我基本不会建议这些模型用到 200K token 以上，能压在 100K 以内最好。到了某个点，智能就是断崖式往下掉。」然后补了句「抱歉了 Anthropic，如果你们在看的话」。 → 详细
所以结论是条件式的：如果你反正都要吃一次缓存未命中（比如正要路由到另一个模型、想把窗口压到最小），那 compaction 就是个非常有用的工具。 → 详细

上下文的根本哲学：人的 context 比模型还短，靠文件系统兜底

Walden 的小实验：「作为人，我现在开始一个个报数字，你能记住几个才开始跟丢？其实非常少。某种意义上你可以说，你的 context window 比这些语言模型还短。」可你照样做得非常好——因为人的记忆本来就是高度有损的。 → 详细
关键在于有无损的系统兜底：文件系统。你只需要记得「我之前读过某个文件」和它的关键部分，完整版本还好好躺在系统里。所以好 harness（外壳/脚手架，即包在模型外面那层工程：工具、提示、记忆、循环控制）的标准是——「harness 得具备找到它所需内容的一切条件，哪怕这些内容并不都摆在眼前」。 → 详细
落到实操：sidekick 干完活告诉主模型「我找到的东西都在这儿」时，只给文件引用而不是把内容整个倒出来；而更大更聪明的模型在用工具和读东西上 token 效率反而更高——只看关键部分，或者判断「我跑一条命令就能确认是不是都弄对了」。 → 详细
panel 上有人提了另一条路：用 AST（抽象语法树，代码的结构化表示）这类表示来做上下文压缩——「compaction 本质上就是有损的」，而代码库天然带着可以一路带下去的结构，这更接近「近乎无损」的压缩，还能保留模型或 agent 的状态。 → 详细
Walden 顺手说了句不该被当作理所当然的观察：「更贵的模型反而造出一个整体更便宜的系统，这一点都不显然。」另一位补上 scaling laws 的一面：模型越大用 token 越高效，小模型越不高效。 → 详细

小模型怎么知道自己搞不定了：三种信号，都还没定论

先说坏消息：Walden 说他们花了大量时间在「怎么让小模型擅长自己检测」上，但「不幸的是，很多情况下你确实需要大模型来做这个判断」。 → 详细
信号一（他们博客里没写的便宜做法）：你本来就得按某个节奏刷新缓存（默认存活约 5 分钟），既然反正要刷，「只要问法得当，你基本上就能白拿一次 frontier model 的调用」——就在那时问一句：「你看一眼小模型现在在干嘛，它是不是钻进某个死胡同了、需不需要帮忙？」 → 详细
信号二（Alex 提的）：小模型开始狂吐 token 是不是该切大模型的最好时机？他怀疑这本身就是后面一连串智能问题的根因——「你希望大模型去生成大块的 token，小模型只生成小块的」。Walden 老实说还没试过，而且这事微妙：有些小模型 token 效率确实差，但它们又是拿自己的 trace 训出来的，可能又抵消掉了，「都得非常讲经验数据地去测」。（顺带确认：小模型确实会用掉更多 token。） → 详细
信号三（panel 上有人提的）：幻觉探针（hallucination probe，直接作用在模型内部状态上的小分类器），给出「它现在有多倾向于产生幻觉」的评分，相当于一个「模型在自己的思考里迷失到什么程度」的代理指标。原理是缓存说到底就是 prefill 阶段算出来的一堆向量，可以在这些向量上训分类器去推测模型状态。 → 详细

模型能力是参差的：benchmark 高不等于哪儿都强

panel 上有人（转写标为 Tuhin，做模型评测那位）提出 jagged capabilities（参差的能力）：「写代码」不是一个单一领域——光数据可视化里就有 scikit-learn、matplotlib 等等，强弱取决于每个模型的训练语料里进了什么。所以「模型 A 在某个 coding benchmark 上分数更高，不代表它在所有任务上都更强」。 → 详细
机制：模型 post-training（后训练，即预训练之后针对具体用法的调教）时会被不同 teacher 调教、在不同子任务上微调，所以分析各模型在不同子任务上的失败情况时，那些互相错开的强项会明显显现——把系统编排成去吃这个套利空间，「这部分收益基本上是白捡的」。数字：在 LLM router bench 上用这些方法「准确率甚至能提高最多 10%」，取决于模型池和具体任务。 → 详细
一句可以直接拿走的话：「模型各有各的强项，而不是『有一个模型能通吃一切』。」 → 详细

OpenRouter 的路由生意：auto router 两年没人用，被一个心跳机制引爆

auto router 差不多两年前就上线，刚推出时基本没有真实用量——大家还是想指定具体模型；他们当时把它当一个「发现」入口，让你知道哪个模型可能适合你的 prompt。 → 详细
转折点是今年 1 月 OpenClaw 起来：它大概每 10 分钟往你选定的模型发一次心跳，纯粹为了确认客户端还活着——你要是把 Opus 设成默认模型，「光这个心跳流程就会烧掉大量 token」。Alex 的定性：这是头一回出现「一个非常流行的应用，内部却有两种完全不同的智能需求」，加上开源模型也进步到了把市场切成这两块说得通的程度。 → 详细
现在的产品线：Pareto Code（在你设定的阈值下给编程任务上帕累托最优的模型，阈值可调）、Fusion（编排多个模型给出融合结果）。目标是两头都要：给开发者好的原语去玩高级编排（sub-agent、advisor 工具那类），同时给普通用户一个「设一个 slug 就行、所有 harness 都能用」的简单选项。 → 详细

marketplace 的位置限制：看不见别人的缓存，但能替你算「要不要丢掉它」

Alex 很坦白：OpenRouter 是模型的 marketplace，「除非模型是我们自己在跑（这种情况很少），否则我们看不到模型内部的 KV cache」，所以 KV cache 层面的优化他们做不了。 → 详细
他们能做的是：为这条 prompt 找最合适的模型或模型组合；一旦看到缓存命中，就把这段缓存的有效期用满，并把命中省下的钱原封不动让给下游客户。 → 详细
一个还没开放的能力很有意思：判断「现在换模型的收益明显很大，但你的 cache 还没用完，还剩 2 分钟」——为此丢掉剩下的缓存值不值，然后让用户自己调节对这种行为的容忍度。「这块我们已经做了一点，但还没开放给客户。」 → 详细
提问方关心的是 KV cache aware 的路由（按缓存在哪儿来决定往哪儿发请求）在生产环境里到底有没有真实需求。 → 详细

NVIDIA 这边的解法：可伸缩的权重、拿训练配方判断分布、Dynamo 的前缀缓存

Flex Run：先有一个主模型，蒸馏（distill，把大模型能力压进小模型）成若干更小尺寸的版本，再根据手头任务切换由哪个模型来做 decoding；单个模型产物内部也能只激活某一类能力、某一部分权重。 → 详细
一个只有开放模型才有的优势：只要拿得到训练配方，就能判断一个问题对这个模型有多「新」——即直接判断在不在分布内；有训练记录还能看出蒸馏时各 teacher 模型和产物之间的差距，因为「你虽然喂了各个领域的数据，但并不保证模型对这些数据的吸收在各处是均匀的」。 → 详细
主持人接的一句正好落在 NVIDIA 的位置上：基础模型本来就是针对将来要跑的 harness 做 post-training 的，「如果 harness 里会包含大量 routing，那这部分自然也该进到 post-training 里去」。→ 详细
另外顺带推荐了 Dynamo，说里面做了很多 prefix cache（前缀缓存，命中「开头那一大段没变」的部分）优化。 → 详细

自托管 vs API：5 分钟的缓存不是物理定律，是运营决定

为什么缓存会过期：让 KV cache 保持热是要付成本的，「GPU 里能常驻的 cache 数量是有限的」，一段缓存没被反复用到就会被换出去、基本等于丢了——「所以 inference 服务商才会跟你收这笔钱」。 → 详细
但那个 5 分钟窗口「更像是一个运营层面的决定，而不是什么科学结论或者底层的物理定律」。自己部署就能「想留多久留多久，完全按你自己的业务逻辑来」。 → 详细
更本质的一笔账：用服务商时，他们是「把所有人的用法摊平之后再给你一个价格」，优化的是所谓「通用场景」。比方说你的负载平均是 32K 缓存、1K 输入、1K 输出，而别人是 64K 加 1K、1K——你自托管就能只针对自己的场景做优化，「花的钱大概率会少很多」。 → 详细
这条在 Cognition 的历史里有实证：2024 年他们刚做第一批 agent 时还没有 cached token 这回事，「你哪怕发的是同样的 10 万个 token，也得按全价付」——别人不做 agent 的一个原因就是太贵。他们能把 Devin 做出来的关键之一，是直接从服务商那里买算力、不按 token 计费而是为底层算力付钱。Walden 现在想要的下一个东西：能落到 S3 之类存储、保留时间长得多的缓存。 → 详细

本地 vs 云：路由的第三类用例是隐私和「已经买下的算力」

panel 上有人把路由的用例摊开成三类：拿到更好的答案；答案差不多时省钱；以及今天还没聊到、但对现场观众最相关的第三类——什么时候该在本地跑，什么时候才真的需要前沿模型。 → 详细
隐私那条给了具体流程：本地模型先检测 prompt 里有没有敏感信息，有就在设备上处理，甚至先把这部分信息脱敏，再把更复杂的负载拿到云上去跑。 → 详细
成本那条的算法很朴素：「我买了台 DGX Spark，我知道自己肯定没跑到 100% 利用率」——本地只付进来的那点电费，而云上的 token 是按全价付的，所以要想办法把这块算力用足。 → 详细
收尾时还补了一条边缘硬件特有的理由：本地推理时如果显存占用已经很高，你要提的就是算力利用率——做法之一是同时起多个 agent 协同工作。也就是说「协同」不只是云端负载的最优解，恰恰是压榨边缘硬件性能的方式。 → 详细

下一步是把编排训进模型：RL 训协作者、协同设计、prompt 怎么迭代

Walden 提的下一个台阶：「不是把现成的模型拿来编排一下，而是能不能让你的模型和编排系统协同设计。」用 RL（强化学习）把一个模型训到端到端完成任务的文献已经很多，但怎么训一个擅长协作的模型？他们两种设置都试了——把在训的模型当编排者（决定什么活派给谁），以及当执行者（那个 sidekick，看它执行别人指令执行得怎么样）。 → 详细
prompt 不可迁移是现实问题：不同模型行为差别很大，切架构 prompt 就得改。Alex 把它变成了一件产品资产——一家 agent 公司的价值「就在于你们摸索出来的那些跨行业的『死循环』场景，以及从里面脱身的最佳办法」，这些全体现在 prompt 上：advisor 模型（他管它叫「聪明朋友」）怎么被调用、subtask agent 怎么被调起来。好在任何人或 agent 都能翻 trace、改 prompt、实时看到准确率变化。 → 详细
Walden 想做但还没做的一件事（他自己说算剧透）：不拿数据集调优，而是拿真实使用信号调优——用户主动升级/降级模型、系统发现最初路由错了要换，都是有用的信号流。他们想进入一种「自动研究」状态：持续收集「当时实际路由到了哪个、本该路由到哪个」，不断迭代直到贴合真实生产数据。 → 详细
对自动 prompt 调优框架（转写里提到 GEPA 这类）他不看好：与其做偏底层偏机械的调优，不如直接告诉一个聪明模型「这是当时做出的决策，这是当时的 context，你来分析为什么走偏了」，甚至笨到直接问「你为什么选了这个而不是那个」、让它引出相关 prompt 片段，再让 Devin 改 prompt、把测试当回归跑一遍确认结果真的变了。「这套系统当然重得多，但我对这种系统的智能程度信任得多。」 → 详细

收尾争论：router 会是一个产品，还是变成底层管道？

收尾问题：router 最终是独立产品还是底层管道的一部分？是模型自己变得擅长把任务路由给别的模型，还是 harness 知道自己在跨多个模型工作？ → 详细
Walden：已经在发生了。Cognition 在训练自己的模型成为好的协作者，而新一代前沿模型（Fable 系列、GPT-5.5 和 5.6）「本身就天然更会协作、更擅长把任务委派出去」。 → 详细
中间派：不会出现「一个特别出色的 harness，背后却没有一个特别出色的模型」，反过来也一样；系统会变成既看整体也看组件的东西，而且不会只由模型构成。 → 详细
「必然有控制层」派：应用跑在模型这种非确定性系统之上，处在信任度非常低的环境里；哪怕站在模型自己的角度，它也不知道其他每一个模型的行为特性，所以仲裁只能落在编排这一层。历史先例是 Web 刚起来时的流量路由——「所有这类路由控制权，随着时间推移都逐渐集中化了」。 → 详细
Alex 的两面：未来也许真会出现一个大模型说「任何任务我都能做得比 Haiku 好、价格还更低，那我凭什么要把活派给 Haiku？」但缓存这类因素永远在（比如另一个模型的缓存里已经存着正确的 context），而且编排模型天然掌握更多 context、模型之间必须对齐。所以他「基本想象不出一个『我们没法让模型之间很好协作』的世界」。 → 详细
主持人对这波浪潮的定性：model routing 现在「天时地利全占了」——一方面把问题拆开本来就该写出更好、bug 更少的代码；另一方面 agent 改掉了工作负载的形态，从「我问一句它答一句」到「先推理再回来」再到心跳式常驻，「如果我的 agent 跑在最优状态，那基本每秒都在生成 token」。 → 详细
全场对自身阶段的判断一致：非常早期。Walden 甚至希望一年后回头看 Devin Fusion 的这些技术「已经很老古董了」；Alex 说之前关于 model fusion 的研究「大多不够细，有时候结论也没那么乐观」，最近才开始变乐观。 → 详细

闪电问答 / 收尾

（本期无闪电问答环节。收尾只有一个开放问题「router 会是产品还是管道」及四位的回答，已完整写在主题第十八节。）

联系方式

（本期无。台上提到的产品：Cognition Devin / Devin Fusion、OpenRouter（auto router、Pareto Code、Fusion）、NVIDIA Nemotron / Flex Run / Dynamo。）

接着读

NO.143 · Agent 工程多人协作的 agentic 工程——Arjun Singh(Superconductor) Arjun Singh · 21 分钟 NO.142 · AI 产品普通人的 Claude Code:技能、语音模式,以及怎么和 AI 协作 Grace Clarke · 23 分钟