事件概述

OpenAI News 在 2026 年 9 月 14 日发布了一篇创业公司案例，介绍总部位于欧洲与英国的初创公司 Fyxer 如何使用 OpenAI 的模型构建一款「让人愿意信任」的 AI 行政助理（AI executive assistant）。

Fyxer 的核心定位是跨工具的上下文跟踪：现代职场人的工作分散在收件箱、会议、消息和各种应用里，承诺和待办很容易掉在地上。Fyxer 试图让 AI 助理「跟着线索走」，把散落的承诺、关系和上下文串起来，其中邮件是最能体现其价值的场景——同一封邮件，两个人可能因为关系不同、历史不同、目标不同，需要完全不同的回复。

根据原文披露的量化结果：

  • 90% 的用户在 90 天后仍然留存（仍在使用并付费）；
  • 53% 的 AI 生成草稿被用户原样接受、未做修改即发送；
  • 2025 年，Fyxer 的年度经常性收入（ARR）从 100 万美元增长到 3200 万美元。

Fyxer 联合创始人 Archie Hollingsworth 用莫拉维克悖论（Moravec’s paradox）解释了这个产品的难点：「人类觉得容易的事情对计算机很难，计算机觉得容易的事情对人类很难。」写一封得体的邮件对人类是常识，对 AI 却是大量隐性判断的叠加。

关键技术点

1. 把「写邮件」拆成 30–50 个专用模型

Fyxer 没有把邮件当作单一的文本生成任务，而是把整个工作流拆成一组预测问题，由大约 30–50 个专用模型分工完成。原文给出的分工链路大致如下：

  • 回复决策模型（reply decision model）：新邮件到达时，先分类这封邮件是否需要回复、是否需要安排日程，还是只需要让用户知晓；
  • 意图与结果预测模型：如果确实需要回复，进一步分析邮件意图，并预测这次互动的可能走向——是在走向约会议、解决某个请求，还是在延续一段长期关系；
  • 记忆与检索模型（retrieval models）：决定哪些细节应该跨会话持久保存、哪些应该在单次交互后消失；新邮件到达时，把当前邮件与历史交互比对，召回与这个人和这条线索最相关的记忆；
  • 生成模型：完成最终草稿。

Hollingsworth 的原话是：「把问题拆成很多更小的模型，比让一个大模型去写一封好邮件，效果要好得多。」

需要注意的是，原文没有说明这些模型分别对应哪些具体的 OpenAI 模型版本。

2. 用 500,000+ 小时的真实助理工作流做训练数据

在推出 AI 产品之前，Fyxer 已经运营了多年「真人行政助理服务」。这段时间积累下来的标注数据超过 500,000 小时的行政工作流，记录了真实助理如何处理职业沟通——什么时候该快速回复、什么时候该等一等、哪一段更早的对话更重要、同一个请求对不同的人为什么需要不同的措辞。

这些数据本身就是「岗位现场」产出的训练样本，捕捉的是优质回复背后那些细碎的判断。训练侧的技术路径是：

  • 在整个系统中使用**监督微调（SFT）**和 LoRA（Low-Rank Adaptation），在控制训练成本的前提下产出任务专用的模型变体；
  • 产品开发早期，对需要高准确率的任务直接使用 OpenAI 的微调平台；
  • 更近一段时间，Fyxer 与 OpenAI 的托管微调团队合作，将一个新的 checkpoint 推入生产环境。

模型上线前，Fyxer 会用自己的邮件任务验证集做评估，覆盖撰写、分类、优先级判断等任务，并在准确率之外同时权衡响应时间和成本——因为「最优选择会随任务而变」。

3. 把用户反馈变成自训练闭环

Fyxer 系统上线后仍在持续改进，途径是真实用户反馈：

  • 当用户在发送前修改草稿，原始草稿与最终发出邮件之间的差异，就隐含了用户更偏好哪个输出；
  • Fyxer 用 **DPO（Direct Preference Optimization）**把这些对比转成训练数据，模型学习的是成对的输出（原始草稿 vs 用户编辑版），而不是依赖人工逐条标注；
  • 每一次撰写逻辑的改动都要经过 A/B 测试，只有在产生统计显著提升时才会发布新版本。原文提到，凭借其用户体量，团队有时能在一天之内达到这个显著性门槛。

最终结果就是前面提到的 53% 草稿原样接受率——意味着系统在相当大比例的真实对话里，正确预测了用户的意图和语气。

对数据科学或 AI Agent 落地的意义

这篇案例对做 AI Agent 和垂直应用的团队，有几条可以直接借鉴的工程经验。

第一，Agent 的能力边界靠任务分解而不是靠更大的单体模型。 30–50 个窄职责模型分别负责分类、意图预测、记忆检索、生成，本质上是一种「预测系统」而非「生成系统」。这种架构的好处是每一步都可以单独评估、单独优化、单独替换，出问题时也更容易定位。对于邮件、客服、销售跟进这类长链路任务，单模型端到端生成很难把每个环节的可控性做出来。

第二，偏好数据是可以「白捡」的。 用户的每一次编辑都是一条免费的偏好标注，DPO 把这种隐式反馈转成训练信号的路径已经比较成熟。关键在于产品设计上要能捕获「编辑前 vs 编辑后」的成对信息，并把它送进训练管道。相比请标注团队打分，这是一个边际成本极低的数据飞轮。

第三，统计显著的 A/B 测试应该成为模型迭代的发布门槛。 原文里「改了就上」被替换成了「达到显著性才上」，这对模型行为频繁变动的 Agent 产品尤为重要——用户对语气和判断的容忍度很低，一次回退可能直接反映在留存上。

第四，评估必须同时看准确率、延迟和成本。 Fyxer 明确说不同任务的最优选择不同，这意味着不可能用一个统一的模型配置打天下，路由和分层是必然结果。这对任何要做大规模推理的数据团队都是直接的架构约束。

第五，领域专有数据仍是护城河。 500,000 小时的真人工作流不是任何人都能复制的资产。模型能力可以外购，但这批数据决定了模型在具体场景里「像不像一个懂行的助理」。

我的技术点评

Fyxer 这个案例最值得琢磨的地方，是它对「AI 助理」这个品类的理解方式：它没有去卷通用写作能力，而是去卷关系与上下文的判断。同一封邮件需要不同的回复，这个观察本身不新鲜，但把它拆成可训练的子任务（是否需要回复、意图是什么、走向如何、该记住什么），才算把一句产品直觉落成了工程结构。

几个我认为值得展开的点：

记忆系统是这个产品真正的技术分水岭。 原文提到记忆是系统最重要的部分之一，要决定「哪些细节跨会话保留、哪些单次交互后丢弃」。这其实是 Agent 领域至今没有标准答案的问题：上下文窗口再大，也解决不了「该记什么」的取舍问题。Fyxer 把它做成了一个检索+排序的模型问题，而不是一个纯工程问题，这个思路是对的，但它同时引入了难以验证的风险——记忆错位造成的伤害往往是延迟显现的，原文未说明 Fyxer 如何评估记忆的准确性。

53% 这个数字，取决于怎么解读。 作为「原样接受率」，它意味着接近一半的草稿仍被人类修改。这在一个高频、低风险、用户本就有编辑习惯的场景里是相当不错的成绩，但距离「可以完全托管」还有明显距离。有意思的是 Fyxer 真正的信心来源不是这个数字，而是 90 天留存——Hollingsworth 说得很直接：「大家都在谈 ARR，但我觉得留存才是真正的炫耀资本。」对于非技术背景的用户来说，每天主动打开使用才是产品有效性的最强证据。

对 OpenAI 的依赖是个需要正视的变量。 从数据处理、上下文重排到最终生成，Fyxer 的关键环节都跑在 OpenAI 模型上，同时高度依赖其微调平台与托管微调团队。这种紧密合作在早期是加速器，但也构成了结构性依赖。原文把这一点作为正面叙事呈现（「我可以在 Slack 里丢个问题就很快得到答复」），对读者来说则需要自行判断。

关于未来方向，原文给的信息比较克制。 Fyxer 表示正在构建对关系、偏好和进行中工作线索的更完整理解，要从「起草回复」走向更广义的、能承担更多沟通与协调工作的主动式助理。Hollingsworth 的愿景是让客户「永远不必打开电脑，并且信任 Fyxer 管理这一切」。至于具体的时间表、是否涉及新的模型能力、是否会扩展到邮件之外的场景，原文未说明。

一句话总结：Fyxer 的价值不在于它用了哪一代 OpenAI 模型，而在于它把 500,000 小时的人类职业判断、用户的每一次编辑、以及一套严格的 A/B 发布纪律，串成了一个持续转动的数据飞轮。对于做垂直 Agent 的团队来说，这套「拆任务 + 攒偏好 + 卡显著性」的组合拳，比任何单一模型技巧都更值得抄。

原文链接