不横评 Gemini，聊聊 toA 赛道我闷了半年的那个判断

上个月底对账的时候，我盯着那张 token 消费报表愣了大概三十秒。十一个人，每人每天几百次调用，清一色 Opus 和 GPT-5.6 的单价。一个人用顶配模型无感，十一个人跑一个月，数字就开始往你脸上糊。这件事本身不稀奇，但把我真正卡住的不是账单，是账单背后那个结构性问题：我们为什么没有一条更便宜的路？

顺带说一句，Gemini 3.8 Flash 这周正式可用了。Google 在 Flash 这条线上的迭代从来没停过，这一代的推理延迟、单次调用价格、API 兼容性都比上一代有实质进步。我当天就在 Token Hub 上把对接跑通了。但今天这篇不写模型横评，我想聊一个完全不同的东西。

我在硅谷做 AI 创业快两年了，Zaokit 从立项到现在接近二十个月。toA——to Agent，面向 AI Agent 的产品和基础设施——大概是过去半年融资密度最高的赛道，新案子几乎周周都有，打法卷得厉害。我天天泡在这个生态里，对各家在做什么、做到哪一步、卡在哪一步，算是比较清楚。

今天想抛出的判断，不是从哪份行业报告里读来的。它是我自己团队运营数据里慢慢浮出来的，我酝酿了大概半年才敢下笔。我给它起的名字是：**团队共同记忆演化**。

先讲能力断层这件事。我团队里有几个工程师，AI 工具链玩得极熟。Claude Code、Codex、各种 Agent 框架全部拉满，Context → Dev → Skill → Eval → Loop 整条链路跑下来，一个人能顶过去三四个人的产出。硅谷每个团队都有这种人，他们是把组织往前拽的核心引擎，不稀缺。

真正让我停下来想的是另外那群人。我翻了一遍其余成员的使用日志，落差大到我不舒服。同一项任务，头部的人十分钟交付，其他人磨了一整天还在手动试错。不是聪明不聪明的问题，是认知层面有一道墙。prompt 怎么组织、skill 怎么编排、eval loop 怎么搭——这些 know-how 只长在明星员工的脑子里，没有任何标准化的传递通道。大多数 p50 水平的同事，要么学不会，要么根本没有能让他们学会的上下文。

我踩过一次。有一次让一位 p50 的同事复现一个 skill 编排，他对着文档做了两个小时，出来的东西和明星员工十分钟的产出差距是数量级的。他跟我说"我已经很努力在学了"，明星员工那边觉得"这明明很简单啊"。两边都没错，但团队人效就被这道鸿沟死死拖住了。我管这个叫：**不可迁移**。

第二个问题更隐蔽。Agent 在 Loop 里跑任务，不断踩坑。有些坑是 PM 验收时发现的，有些是 QA 回归里捞出来的，有些是工程师自己跑着跑着撞上的。每次都是 ad hoc 修一下——调个 prompt、加个 edge case 判断、手动纠一次输出，打个补丁继续。

但你要意识到，这些坑是你自己的。你的业务数据长什么样、你的 API 有什么怪癖、你的客户在什么场景下触发边界条件——这些东西不在任何通用模型的训练集里。Fable 5.1 不知道你的 API 在周末会返回一个不同格式的 response。GPT-5.6 不知道你的客户习惯在金额字段里塞带逗号的数字。

每次修完就翻篇了。知识留在修的那个人脑子里，或者某条 Slack 消息的角落里。下一次同样的坑冒出来，换一个人重新踩一遍。

我判断这类私有化领域问题会持续很久。大模型通用能力在涨没错，但你的 domain-specific 知识不在它的训练集里，这个 gap 不会因为下一次模型更新自动消失。我管这个叫：**不可演化**。

第三个跟钱有关，但根源不是"贪便宜"。团队成员用 AI 的本能选择是用最好的，可大量任务根本不需要顶级智能。格式化一份报告、提取结构化数据、跑一个已知模式的代码变更——理论上小模型完全够。

问题在于，现在的小模型在你的具体业务场景下就是做不好。GLM、Kimi、一些开源 7B 模型，一次性做对的概率太低，试两三次才能拿到合格输出，时间成本反而被拉高。所以团队的理性选择就是：用贵的。Claude Opus，GPT-5.6，一次做对，省下的时间比多花的 token 钱值。

但这笔账放到团队规模上，成本曲线非常陡。一个人用 Opus 没感觉，十个人每天几百次调用，月底的数字会让你重新审视这件事。我管这个叫：**大材小用**。

三件事缠在一起，指向同一个缝隙。明星员工踩过的坑、沉淀出的 prompt 和工作流，能不能自动变成团队资产？每一个 domain-specific 问题，解决之后能不能回灌进系统，让下次同类问题自动处理？必须用顶级模型才能做对的任务，解决路径能不能被蒸馏到一个极小、极便宜的本地模型里？

我管这整件事叫：**团队共同记忆演化**。

落地的路径我看到两条。

一条是 **Record as a Skill**。把一次成功的问题解决过程录下来，抽象成 skill，挂到团队里任何人的 Agent 上。明星员工解了一个 bug，这个解法就变成一条可复用的 skill，下次别人遇到同类问题，Agent 自动调用。知识从个人脑子里流进系统，不再依赖口口相传。

另一条是 **Post-training**。拿团队自己的业务数据做微调，让一个参数量可能只有 1B 甚至更小的本地模型，在某个特定场景下做到和顶级模型接近的表现。那种重复性高、调用频率高的任务，不需要每次都请 Opus 出手。蒸馏完的小模型跑在本地，成本能降两个数量级。

这两条路不矛盾。Skill 解决的是知识迁移，Post-training 解决的是成本。两个一起做，团队的 AI 能力才能从"几个人会用"变成"所有人站在同一条水平线上"。

这个方向不是我空想的。已经有好几个开源项目在碰类似的事，我全拉下来跑了一遍。

差强人意。

每一个在 demo 数据集上都跑得不错，但换成我自己的业务数据，准确率掉得很快。fine-tuning pipeline 的底层假设和我的数据分布对不上，prompt 模板太通用，覆盖不了业务里的边界情况。

这不是某一个开源项目的问题。这是 toA 赛道目前的通病——给 Agent 用的工具铺天盖地，但让 Agent 在你的地盘上做 domain adaptation 的基础设施太少。大家都在做更聪明的 Agent，没人做让 Agent 在你的业务里变聪明这件事。

这是我 side project 正在探索的方向。Gemini 3.8 Flash 发了，模型越来越便宜，对 toA 赛道是利好。但成本降了不等于问题消失。你的团队知识没有进到模型里，你的 domain-specific 的坑还在那，你的 p50 员工和明星员工之间的 gap 也还在那。

团队共同记忆演化，就是去解这个缝隙里的问题。

如果你知道有产品在认真做这件事，分享给我。如果你有 idea，也告诉我。做了快两年 Zaokit，我越来越确定一件事：值钱的创业方向不是坐在会议室里想出来的，是从自己团队的痛点里长出来的。