四个 AI 产品背后的系统设计

Codex、Cloudflare Ask AI、Google AI Overview 和 Firefox AI Chatbots 是最近比较有代表性的四款 AI 助手产品。它们都被称为“AI 助手”或“AI Copilot”，但它们的架构设计、用户交互、商业目标和市场入口却有很大差异。本文尝试从系统设计的角度分析这四款产品，看看它们背后是如何把 AI 能力嵌入不同的用户场景和商业防线的。

1. 先把它们放回各自的位置

如果只看交互形态，这四个产品都像“用户问一句，AI 回一句”。但从产品架构和商业目标看，它们其实在解决四类完全不同的问题。

为了让后面的架构图不变成“看起来很合理的想象”，先把公开事实和图中节点对齐：

接下来逐个看。重点不在“谁的模型更强”，而在模型被放进了什么系统。

2. Codex：把 AI 放进软件工程闭环

OpenAI 对 Codex 的公开定位很清楚：它不是普通聊天模型，而是 coding agent。Codex Cloud 文档说明，Codex 可以读取、修改并运行代码；Codex Cloud 可以在云环境中后台处理任务；连接 GitHub 后，可以在仓库上下文中工作并创建 pull request。更完整的产品形态，包括 CLI、IDE、Web、GitHub integrations、sandboxing、permissions 等，也集中在 Codex 文档里。

所以 Codex 的架构不能只画成“用户 -> 模型 -> 回答”。更贴近事实的理解是：用户给出工程任务，Codex 收集仓库和任务上下文，规划修改，编辑文件，运行测试或构建命令，再根据输出继续修复，最后生成可审查的 diff 或 PR。

用户提出工程任务
-> 收集仓库和任务上下文
-> 规划修改
-> 编辑文件
-> 运行测试、构建或检查命令
-> 根据输出继续修复
-> 生成可审查的 diff / PR

这条链路里最有价值的地方，不是“模型能写代码”，而是“代码可以被工程环境验证”。测试能不能通过、构建有没有失败、diff 是否合理，这些都是比自然语言回答更硬的反馈。早期 ChatGPT 可以告诉你“应该这样改”，但它不知道你的仓库里真实依赖是什么、隐藏测试会不会失败、团队是否接受这个 diff。Codex 的方向，是把这些工程反馈纳入循环。

从商业上看，Codex 卖的不是问答，而是研发吞吐量。它瞄准的是重复性代码改造、测试修复、依赖升级、bug 初步定位、PR 草稿生成、文档和代码同步等工作。企业是否愿意把它放进研发流程，关键不只是模型效果，还包括权限控制、代码所有权、审计、CI 集成、review 流程，以及 GitHub 工作流适配。

Codex 最值得关注的地方，不是它“会写代码”，而是它把写代码这件事放回了工程流程里。代码补全提升的是输入速度，Codex 试图提升的是任务完成速度。短期内，它更像一个能准备候选变更的虚拟工程成员，而不是替代工程师的人。真正的价值会出现在人机分工清楚的团队里：AI 负责探索、修改、跑测试和整理 PR，人类负责需求判断、架构边界、代码审查和最终责任。

3. Cloudflare Ask AI / Agent Lee：把 AI 放进云平台控制面

Cloudflare Agent Lee 是内置在 Cloudflare Dashboard 里的 AI co-pilot。Agent Lee 文档显示，它可以理解用户账户配置，基于真实账户状态回答问题，并执行 DNS、Workers、SSL/TLS、R2、Registrar、Cache、Cloudflare Tunnel、API Shield 等产品相关工具调用。

这类产品最容易被低估。它看起来是一个控制台里的聊天框，本质上却是在给云平台加自然语言操作层。Cloudflare 在 Introducing Agent Lee 里公开了比较具体的实现细节：Agent Lee 使用 Agents SDK、Workers AI、Durable Objects 和 Cloudflare MCP infrastructure；它没有简单把 MCP tool definitions 直接暴露给模型，而是使用 Codemode，把工具转换成 TypeScript API，让模型写调用这些 API 的代码；生成代码会发送到上游 Cloudflare MCP server 做沙箱执行；中间的 Durable Object 作为带凭证的代理，判断调用是 read 还是 write；read 可以直接代理，write 必须经过 elicitation gate，也就是用户明确批准；API key 不出现在模型生成代码里，而是在服务端注入。

Agent Lee 不是普通的“LLM 调 API”，而是一个有权限分类、有沙箱、有审批门的控制面代理。它的基本链路可以这样理解：

用户在 Dashboard 提问或提出操作
-> Agent Lee 理解意图
-> 通过 MCP / API 读取账户状态或执行诊断
-> 只读问题直接返回基于账户事实的答案
-> 涉及写操作时生成变更计划
-> 用户明确批准
-> 通过 Cloudflare API 执行变更
-> 返回结果

这里的关键设计是 read path 和 write path 分离。读路径解决 grounding，让回答来自真实账户状态；写路径解决安全，避免 AI 绕过用户审批直接修改线上配置。对云平台来说，这不是锦上添花。DNS、WAF、TLS、Tunnel、Workers 路由这些配置一旦改错，影响的是线上可用性、安全边界和业务流量。

Cloudflare 的商业诉求也很自然。它的产品线很宽，Dashboard 的复杂度会随着产品能力增长而增长。用户排查一个问题，可能要在 DNS、TLS、WAF、Workers、缓存、日志和文档之间切换。Agent Lee 的价值，是把“查文档、找页面、理解配置、运行诊断、执行修改”压缩到一个自然语言入口里。它提升的是平台使用深度和留存，而不是单独卖一个聊天机器人。

Agent Lee 是“控制平面智能化”的典型样本。它不是在替代 Cloudflare 文档，也不只是给 Dashboard 加一个聊天框，而是在把平台操作本身重新包装成对话式工作流。未来 AWS、Google Cloud、Azure、Datadog、Snowflake、Vercel、GitHub 这类平台都会继续往这个方向走。谁掌握账户状态、操作 API、权限体系和审计链路，谁就更适合把 AI 做成平台入口。

4. Google AI Overview：把生成式答案放进搜索系统

Google AI Overview 最容易被误解成“Google 搜索里的 chatbot”。但 Google Search 关于 AI Overviews and AI Mode 的官方 PDF说得更具体：AI Overviews 使用为 Search 定制的 Gemini 模型，并与 Google Search 现有系统协作，包括 ranking systems、quality systems、Knowledge Graph、高质量网页结果、supporting links 和安全机制。

也就是说，AI Overview 不是一个独立问答应用，而是搜索系统中的生成层。它的工作路径大致是：

用户输入 query
-> 判断 query 是否适合触发 AI Overview
-> 搜索系统检索并排序高质量网页结果
-> 结合 Knowledge Graph 等结构化信号
-> 定制 Gemini 模型生成摘要
-> 经过质量和安全过滤
-> 在 SERP 中展示 AI Overview 和 supporting links

这里有两点特别重要。

第一，触发机制本身就是产品能力。不是所有 query 都适合生成 AI Overview。健康、金融、法律、安全、时效性新闻、数据不足的问题，如果质量信心不够，生成式答案会把不确定性包装成确定性。

第二，AI Overview 不是普通 RAG。普通 RAG 通常是“检索若干文档，塞进 prompt，然后生成回答”。Google AI Overview 背后是搜索级基础设施：网页索引、排序、质量评估、Knowledge Graph、安全策略、网页生态和广告系统。生成模型只是其中一层。

商业上，AI Overview 是 Google 对搜索入口的再防守。用户已经开始把复杂问题交给 ChatGPT、Perplexity 等 answer engine，Google 必须让 Search 继续成为默认问题入口。但这件事有代价：AI Overview 会把一部分“点击网页后阅读和综合”的工作提前到搜索结果页完成，用户效率提高了，网站点击和内容生态的分配方式也会变化。

所以 supporting links、触发阈值、质量系统不是纯技术细节，也是商业平衡机制。Google 一方面要直接回答用户，另一方面不能让 Web 内容生态失去继续生产高质量内容的动力。

AI Overview 的核心竞争焦点不是“模型回答是否流畅”，而是“搜索生态能否承受生成式答案层”。Codex 的风险是改坏代码，Cloudflare Agent Lee 的风险是改坏配置；AI Overview 的风险更隐蔽，它改的是用户看信息的顺序。答案越靠前，网页越靠后，搜索平台、内容生产者和用户之间的关系就会被重新分配。

5. Firefox AI Chatbots：把浏览器变成第三方 AI 的上下文入口

Mozilla 官方支持文档说明，Firefox 可以在侧边栏中接入第三方 AI chatbot。用户选择文本并使用建议 prompt 时，Firefox 会把 prompt、selected text 和 page title 发送给用户选择的 chatbot。Firefox 产品页也列出了 ChatGPT、Gemini、Copilot、Claude、Mistral 等可选 provider。

这说明 Firefox 的重点不是自研模型，而是浏览器侧的 provider routing 和 context handoff。它的工作路径很直接：

用户在网页中阅读或选中文本
-> 打开 Firefox AI sidebar
-> 选择第三方 provider
-> Firefox 构造 prompt + selected text + page title
-> 发送给所选 chatbot
-> 第三方 chatbot 返回结果
-> Firefox 在 sidebar 中呈现

这条链路里最重要的是边界。Firefox 控制浏览器入口和上下文交接，但真正的模型推理、账号体系、数据保存和训练策略都在第三方 provider 侧。换句话说，Firefox 做的是 AI 使用入口，不是模型平台。

商业上，这个选择很现实。训练和运营顶级大模型成本极高，Firefox 没有必要在模型层直接和 OpenAI、Google、Anthropic、Microsoft 竞争。它选择保留浏览器入口，让用户自己选择 provider。好处是轻资产、开放、符合用户选择权；代价是端到端能力不由 Firefox 完全控制，隐私和数据处理规则也会进入第三方 provider 的政策体系。

Firefox AI Chatbots 是“AI 分发入口产品”。它不靠模型质量取胜，而靠浏览器场景、用户信任和 provider 选择权。这个方向看起来轻，但并不弱。浏览器是用户阅读、搜索、复制、整理信息的核心界面之一，只要 AI 能自然进入这个上下文，就能影响大量日常信息工作。Firefox 的选择是把模型竞争留给 provider，自己守住入口和用户选择。

6. GitHub：AI 编程生态绕不开的基础设施

GitHub 不是本文四个产品之一，但讨论 Codex 和 AI 编程时绕不开它。

它是公开代码生态的核心节点。早期 OpenAI Codex 介绍明确提到模型基于自然语言和公开可用源码训练。GitHub Copilot Trust Center 也长期围绕公开代码、训练数据、相似代码检测和企业数据保护展开。这里需要谨慎：不能简单写成“所有模型都实时查询 GitHub 代码学习”。不同厂商、不同模型、不同时间点的数据政策不同。更准确的说法是：公开代码生态塑造了代码模型能力，而 GitHub 是这个生态的中心平台之一。

也是是开发者工作流入口。Issue、PR、review、Actions、commit history 都是 coding agent 最需要的上下文。如果 AI 只停留在聊天框里，它很难成为团队工具；能进入 repo、PR、CI 和 review 流程，才有机会成为工程系统的一部分。测试是否通过、PR 是否被 review、代码是否 merge 或 revert，这些反馈比普通网页文本更接近“这段代码是否真的工作”。

所以 OpenAI、Microsoft/GitHub、Google、Anthropic 等厂商在代码生成和 coding agent 方向竞争，最终都会碰到同一个入口：谁能更自然地进入 repo、PR 和 CI。

这也引出一个很现实的问题：既然 GitHub 已经有 Copilot，为什么不少人还是觉得 Codex 更好用？我的看法是，差异不主要来自“模型会不会写代码”，而来自默认交互模型。

先说清楚边界：Copilot 现在已经不只是“自动补全”。GitHub Copilot features 里列出了 autocomplete、Chat、IDE、GitHub.com、Mobile、Terminal 等多种入口；Copilot coding agent 文档也说明，可以让 Copilot 创建 pull request；在 IDE 侧，GitHub Copilot agent mode可以根据任务编辑代码，并在需要时建议运行终端命令。GitHub 也提供 model picker，让用户在不同模型之间选择。也就是说，今天的 Copilot 覆盖了从补全、问答、模型选择到 agent 的多个层次。

问题恰恰在这里：Copilot 的能力很多，但入口也多。它像一个铺在 IDE 和 GitHub 各处的助手；Codex 更像一个围绕“完成这件工程任务”组织起来的 agent。还有一个容易被忽略的差异：Codex 是 OpenAI 自家 coding agent，模型、工具调用、执行环境、权限策略和产品交互可以围绕同一套 agent runtime 一起优化；Copilot 虽然能综合多家模型，但模型可用性、不同 surface 的支持程度、能力边界和交互体验会被 GitHub 的产品层再抽象一遍。多模型选择是优势，也会带来一致性成本。下面这张图更适合解释体感差异：

Codex 的交互中心是“任务”。用户通常从一个明确的工程目标开始：修 bug、改功能、迁移代码、补测试。系统围绕这个目标组织仓库上下文，执行命令，观察结果，继续修复，最后输出 diff、测试证据或 PR。它的链路更像：

任务 -> 仓库上下文 -> 执行反馈 -> 可审查变更

Copilot 的交互中心更分散。它既是 IDE 里的自动补全，也是 Chat，也是 agent mode，也是 GitHub 上的 coding agent。这个覆盖面很大，优点是无处不在；代价是用户经常要自己判断该切到哪个模式：什么时候用补全，什么时候用 Chat，什么时候开 agent mode，什么时候把 issue assign 给 Copilot。对小改动和局部辅助来说，这很方便；但对跨文件、多步骤、需要反复跑命令验证的仓库任务来说，这种分散感会变成摩擦。

简洁对比如下：

所以，如果你说“Copilot 确实没有 Codex 好用”，我会把这句话限定在一个更准确的场景里：当任务是端到端仓库变更，而不是局部编码辅助时，Codex 通常更顺手。原因有三点。

第一，Codex 的任务边界更清楚。它默认围绕“把这个问题处理完”组织交互，而 Copilot 常常从“我现在在编辑器里需要一点帮助”开始。
第二，Codex 的反馈闭环更集中。读代码、改代码、跑命令、观察失败、继续修复，整体更像一个连续工作流；Copilot 虽然也有 agent mode 和 coding agent，但用户常常需要在补全、Chat、agent mode、issue agent 之间切换。
第三，Codex 的模型和产品适配更一体。OpenAI 可以把最新的 coding model、工具协议、沙箱执行和 Codex 交互一起调优；Copilot 需要在 GitHub、IDE、企业策略和多模型选择之间做统一封装。它的兼容面更广，但同一条端到端任务链路里的“贴合感”就容易弱一些。
第四，Codex 的交付物更接近工程团队要看的东西：diff、测试证据、说明、PR。Copilot 在开发过程中很好用，但它的默认体验更像“随叫随到的助手”，不是“把一个任务收束成候选变更的代理”。

这并不是说 Copilot 没价值。Copilot 的优势很硬：GitHub 原生、IDE 覆盖广、补全体验成熟、多模型选择、日常陪伴感强。但如果评价标准是“我给一个跨文件任务，希望 AI 自己读、改、跑、修，最后给我一个可以 review 的结果”，Codex 的产品形态更贴近这个目标。它的好用，来自模型新、工具链贴合、agent runtime 集中，以及 OpenAI 自家产品里的整体适配。

7. 四种产品选择背后的市场方向

这四种产品的差异，最后会落到商业入口上。

Codex 争夺的是开发者工作流。它如果成功，价值不只是帮个人程序员少写几行代码，而是进入企业研发流程：Issue、repo、CI、review、PR、merge。这个入口一旦成立，AI 就不再是开发者旁边的问答工具，而是研发流水线里的生产单元。实际中，产品体验虽然强些，但是和 Claude Code 用来干活相比，还是存在一点点劣势。

Cloudflare Ask AI 争夺的是云平台控制台。云平台越强，控制台越复杂；产品线越多，用户越需要跨产品理解状态。Agent Lee 的价值，是把 Cloudflare 的复杂能力包进一个更低摩擦的操作入口里。它能提升产品发现率，也能让用户更深地使用平台。

Google AI Overview 争夺的是问题入口。搜索的核心商业价值来自“用户有问题时先来这里”。当 answer engine 开始分流复杂查询，Google 必须把生成式答案放进 SERP，防止用户问题入口外流。但它又不能完全切断网页生态，因为搜索质量仍然依赖高质量网页持续生产。

Firefox AI Chatbots 争夺的是浏览器里的 AI 入口。它不做模型军备竞赛，而是让用户在网页上下文里选择 provider。这个策略更轻，也更符合 Firefox 的产品气质：不把用户锁进单一模型，而是保留选择权和浏览器侧的交互位置。

所以，我对这四类产品的总体判断是：AI 产品正在从“通用聊天框”分化成“场景入口”。真正有商业价值的 AI，不一定是模型能力最强的，而是能嵌入高频、高价值、高上下文密度的工作流。Codex 嵌入软件工程，Cloudflare Ask AI 嵌入云控制面，Google AI Overview 嵌入搜索结果页，Firefox AI Chatbots 嵌入网页阅读。这四条路线背后，是四种完全不同的商业防线。可以注意到国内的不少产品页，也集成了 ask.ai 和 ai search support 的功能，但很少看到有产品在云控制面、软件工程流程里做深度集成的。未来 AI 产品的竞争格局，可能会围绕这些不同的场景入口展开。