2 · 它如何运作 —— 一家 “AI 餐厅”

第 2 篇 · 共 6 篇 · 阅读约 7 分钟

如果把技术黑话拿掉,这个平台运作起来就像一家餐厅。

我发现这个比喻贴合得出奇地好,所以我会用它把每一个重要概念都讲一遍。读完之后,你再去看这套系统的任何技术描述, 都能明白底下到底在发生什么事。

这家餐厅

想象你走进一家餐厅。你坐下。你看菜单。你告诉服务员你想吃什么。服务员把订单送到厨房。一个厨师做这道菜。服务员把菜端回来。你吃。

现在把同样的流程里的员工换成软件:

你坐下             (打开网页)
   │
   ▼
看菜单     ─────────────►   你在浏览器里看到的仪表盘
   │
   ▼
告诉服务员 ─────────────►   你发出的 API 请求
   │
   ▼
服务员     ─────────────►   agent-route —— 协调器
   │
   ▼
挑厨师     ─────────────►   负载均衡器 —— 选一个 AI 工人
   │
   ▼
厨师做菜   ─────────────►   AI 模型执行你的请求
   │
   ▼
端回来     ─────────────►   响应回到你的浏览器

整体形状就是这样。“agent route” 的每一个功能, 不过是这个流程的更复杂版本而已 —— 不同房间有不同的服务员,多道菜的套餐,外卖订单, 甚至厨房分散在不同城市。

角色登场

我用餐厅术语和技术术语,把每个部分都点一下名, 让你以后看到这两套词都能对得上。

菜单 —— 你的仪表盘

仪表盘

这是你真正点击的东西。一个网页,带按钮和表单。有时候是个聊天框。有时候是个 “提交研究问题” 的表单。有时候是个贴满便签想法的看板。不管它是什么,它是你下单的界面。

我们系统里目前有两份菜单:

Agent Route —— 管理员仪表盘,用于配置和监控所有事情
Infinite Research(无限研究) —— 一份专注的菜单,用于下单递归式研究

第三份正在路上:AI Institute(智研所) —— 多智能体投研团队的菜单。

服务员 —— agent-route

任务管理器

服务员不做菜。服务员负责:

知道厨房的布局(今天哪些厨师在班,谁擅长什么)
接你的订单并写下来
把订单送到合适的厨师手里
在做菜过程中跟踪进度
把菜端回给你

用软件术语说,这是一个跑在 Cloudflare 网络上的小程序。它是无状态的(它自己不记任何东西),没人吃饭的时候自动缩到零, 而且在全球 200 多个城市都有副本运行,所以离你最近的那一份会服务你。

厨房 —— AI 工人(我们叫它们 “hands”)

真正干活的地方。这里有不同种类的厨师:

云端厨师 —— 谷歌的 Gemini、Anthropic 的 Claude、OpenAI 的 GPT。这些是大型专业厨房,你打电话点单(也就是 API)。按盘收费(按 token 收费)。24 小时营业,但每顿都要付钱。
本地厨师 —— Mac Studio、Linux 主机、你自己的笔记本。本地跑 AI 模型。一道菜不收钱(只算开厨房用的电费), 但一次只能做这么多事,而且只有开机时才在岗。

每个厨师都有自己的拿手菜。有的擅长写代码(比如 opencode CLI)。有的擅长长篇写作(Claude)。有的搜索特别快(Vane)。服务员清楚谁擅长什么,据此分配。

储藏室 —— 存储

厨师做完一道菜后,服务员不会把剩下的东西扔掉。它们都会进一个所有厨师都能访问的共享储藏室:

菜谱和笔记 —— 放在一个小型数据库里, 方便我们查询什么时候、由谁、为哪个订单、做了什么
备好的食材 —— 以文件形式存储。比如 “Claude 昨天早上写的报告” 或者 “为这个项目下载好的数据集”
谁干了什么的台账 —— 每个订单、每一步、每个结果的日志。用于追溯发生了什么事。

厨房的大脑 —— 菜谱和工作流

工作流

有些订单是一次性的(“给我一杯水”)。另一些是多步骤的菜谱 (“做一份三道菜的品鉴套餐,配酒,主厨上菜时还要解说每一道”)。

在我们的系统里,这种多步菜谱叫 工作流(workflow)。你把工作流描述一次 —— “第 1 步:用 Gemini 调研主题; 第 2 步:让 Claude 分析发现; 第 3 步:让 Codex 基于分析生成代码” —— 之后每次触发,系统就会自动执行。

如果你设成定时执行(每天早上 8 点),它会自己跑。

预约簿 —— 会话

客户端管理

如果你常去同一家餐厅,店员可能会记下你的口味、过往订单、对什么过敏。这就是顾客档案。在我们的系统里,这叫 会话(session)。

每个会话有自己专属的储藏室角落、自己的历史、自己之前订单的连贯线索。你可以明天再回来,引用昨天发生的事,厨房知道你在说什么。

一个完整的例子

日常报告

让我把一个具体订单走一遍,让事情更具象。

你在 Infinite Research 的菜单前坐下,输入这个问题:

“未来 12 个月,中美贸易紧张会如何影响半导体行业?”

接下来发生的事:

仪表盘把订单送给服务员(一个发往 agent-route 的 HTTPS 请求)。
服务员为这次研究创建一个 “会话” (这样所有相关的工作,都有一本共享的笔记可写)。
第一个厨师被叫去做初步分析(假设是 Gemini)。 Gemini 读了问题,生成一段 5 段的、带来源的回答, 并提出 3 个深入挖掘的后续问题。
服务员注意到这些后续问题,把每一个都变成新订单: 一个厨师调研子问题 A,另一个调研 B,另一个调研 C。它们在不同厨师上并行运行。
每一个又产出 3 个后续问题, 被派生为更多订单。树就这么长出来。
你在仪表盘上看着这一切发生 —— 一张可视化地图,标出每个子问题、谁在做、做完了什么、还在跑什么。你随时可以中断。
整棵发现树都保存在你这次会话的储藏室里, 所以你明天回来,可以问 “给我一份 1 页的总结” —— 一个厨师就会读完之前所有收集到的内容,把总结写出来。

这只是平台的一个功能。把 “研究” 替换成 “投资简报” 或 “代码重构” 或 “市场活动策划”, 同一套机器照样干这些活。厨师不在乎你问的是什么;服务员据此路由就好。

为什么这件事其实不容易(为什么我们需要一套操作系统)

有三件事看起来简单,实际上需要一套操作系统才能搞定:

1. 知道该叫哪个厨师

如果你只有一个厨师,容易。但当你有 7 个不同专长、不同空闲程度、不同每盘成本的厨师时, 你需要一个真正的负载均衡器。我们的负载均衡器会考虑:哪些厨师现在在线、哪些在忙、最近哪些错误率低、哪些最快。它为每个订单挑出最合适的那个。

2. 厨师做到一半走人时,如何恢复

AI 模型偶尔会卡住。CLI 偶尔会崩。网络偶尔会抽风。天真的系统会把订单丢掉。我们的系统有个看门狗,会发现一个订单在厨房待得太久还没进展, 就把它标为失败,然后要么换一个厨师重试,要么浮出来让人审。没有这个,几个小时之内,队列里就会塞满 “幽灵订单”。

3. 在不同厨房之间共享储藏室

一个厨师写完一个文件,其他每个厨师下次上班都得能看到 —— 哪怕他们在另一个城市。在底层,每个文件一被写出来,就立刻上传到一个共享的云端储藏室, 谁需要谁就下载下来。厨师不需要知道这件事在发生;他们只看到文件在那里。

你不需要去想的事

搭这套操作系统的全部意义,就是让用户不需要懂内部机制。

你不需要去想:

你这个任务现在跑在哪个模型上
这个模型在 Mac Studio 上还是云端 API 上
文件在不同会话之间怎么持久化
出问题了会怎样

你只需要想:

你想要什么
谁来产出(哪个智能体,或者 “整个团队”)
你什么时候想要(现在、定时、由触发条件触发)

如果操作系统在好好干活,厨房就是隐形的。你只是在下单。

用起来是什么感觉

一次典型的交互:

我打开仪表盘。看到 4 个 AI 工人在线 —— claude、gemini、codex、opencode。我从我的项目里挑 “AI Institute”。我看了一眼自己积累想法的看板。把其中一个 —— “新加坡稳定币监管” —— 拖到 “正在研究” 那一栏。系统并行派出 3 个 AI 分析师:一个合规官、一个 ESG 分析师、一个衍生品策略师。我看着仪表盘。20 分钟后,我有了 3 份报告, 加上首席经济学家的一份汇总。我读、评论、调整。明天早上 8 点,同一个工作流会自动跑一遍,基于新数据,把结果发我邮箱。

这不是未来设想。这是今天就在跑的东西, 跑在三份顶级 AI 订阅(Claude、ChatGPT、Gemini)、几乎可以忽略的 Cloudflare 开销、加角落里几台我本来就有的 Mac 上。

后面两篇文章会更详细地讲实际的应用。第 3 篇讲 Infinite Research —— 递归式问题探索器。第 4 篇讲 AI Institute —— 多智能体投研团队。

上一篇: 核心想法 · 下一篇: 应用聚焦 —— 无限研究

它如何运作 — 架构深度解析