自研Runtime、Agent Loop、Infra：一家通用Agent公司的全栈赌注

2026 年 8 月， Floatboat 公布了一份评测数据 "：使用 DeepSeek-V4-Flash（混合价 $0.175/M）跑完五项基准，成绩全面超越贵 57.1 倍的 Claude Opus 4.8。同一个模型，在 DeepSeek 官方 Harness 上一项未赢；接入 Floatboat Harness 后五项全胜。增益随任务程长递增，短程任务仅 1.9%，长程 DeepSWE 达 23.6%。 这组数据第一次为“模型之外那半个系统”给出了定量答案。但比分数更值得追问的是：一个 Harness 凭什么能做到又便宜又好？ Floatboat 团队的回答是：因为从一开始，他们的目标函数就不同。 这支团队的底色 "，来自十年安卓 OS 生态的产品交互与商业化经验，服务过数亿用户。当大多数 AI 产品把 Agent 装进网页对话框时，而做了一个桌面客户端——把文件管理器、编辑器和浏览器直接做成 Agent 的运行环境。 背后的逻辑是：Web 端的 Agent 只能感知上传的文件和输入的 prompt，感知不到文件结构、操作历史、跨应用流转——那些沉淀在行为里的隐性知识。而真实的工作流，是跨文件、跨应用、跨权限、持续数小时甚至数天的长程任务。要承接这种复杂性，Agent 需要的不是一个对话框，而是一个完整的操作系统级入口。 这个起点直接决定了 Floatboat Harness 的设计哲学。他们自研了完整的 Runtime、Agent Loop、Tools 和 Infra，以及一套名为 FloatSail 的自适应进化系统。与主流 Harness 最大的不同在于：它不要求所有任务都经过 Agent。“如果一件事用 Workflow 或普通桌面操作就能完成，根本不需要 Agent。只有真正出现不确定性时，Agent 才介入。”团队产品技术负责人 Remy 说。这既是产品判断，也是经济判断——不让模型做它不需要做的事，是成本可控的前提。 “省”不是优化出来的，是被设计出来的。 这种设计哲学的另一个体现，是他们对“长程任务”的理解。行业里许多 Harness 是为短程问答优化的，而真实工作恰好是长程的那一类。用户日常要处理的不是一条命令，是跨文件、跨应用、跨很多步、中途还要改主意的活儿。 长程任务真正的难点在于：交付标准在开始时往往模糊，而模型在长链条中会持续漂移。Floatboat 的 Harness 不是为了“让模型多跑几步”，而是为了在每一步都把结果拉回交付标准——该回退时回退，该追问时追问，该自我校验时自我校验。 评测数据印证了这条逻辑：任务越长程，Harness 的增益越大。短程任务只差 1.9%，长程任务提升达到 23.6%。HLR（Harness Leverage Ratio）从 0.78 倍一路涨到 3.57 倍——任务越复杂，换 Harness 比换模型更划算。 “未来评估 Harness，不应该只数它有多少模块，而应该看三个结果：任务收敛得多快，错误能否被限制在局部，每交付一个成功结果需要多少成本。”Remy 说，“架构图会越来越像，但运行时的因果纪律、反馈密度和产品判断，不会自动趋同。” InfoQ 近日采访了 Floatboat 团队，试图拆解他们自研全栈 Harness 背后的技术选择与产品逻辑。 InfoQ：你们提到自研 Runtime、Agent Loop、Tools 和 Infra。最初遇到的哪个具体问题，让你们确认必须掌握整个技术栈？哪些部分因此做出了不同于主流 Harness 的技术选择？ Remy：最初让我们确认必须掌握整个技术栈的，是办公和通用任务所呈现出的现实复杂性。我们的目标是把最前沿的技术产品化给尽可能多的人，但真实工作不像 Coding：它会跨文件、跨应用、跨权限，用户一开始也未必能完整说清验收标准。为相对明确、可测试的 Coding 任务构建的系统，不能直接搬过来解决这类问题。 这也和团队背景有关。我们既做过模型，也做过亿级用户产品，所以一方面不会盲目跪拜模型，另一方面也知道，把 Coding 之外的复杂性全部压给 LLM，既不现实，也不经济。模型提供的是高度不确定的智能，产品必须用一套可控、可观测、可回退的系统，把这种智能转化为稳定交付。简单说，这两点决定了我们必须掌握完整的 Agent，也就是 Models + Harness 的技术栈。 这背后还有一个更根本的立场差异：模型厂和应用厂的目标函数并不完全相同。模型厂天然倾向于让模型解决尽可能多的事情，因为这意味着更多 Token 消耗。所以很多现有 Harness 是强 Agent-First 的：哪怕一个任务很简单，完全可以通过代码或固定流程直接完成，也仍然要让 Agent 参与。目前大多数 Code/Work Harness 并不真正允许一条“不经过 Agent”的最优路径存在。 具体选择上，第一是跨平台架构；第二是产品与技术同构。除了 Runtime、Agent Loop、Tools、Infra 和完整的自适应进化系统 FloatSail，我们还构建了原生文件协议、GUI-Agent 双向协议等能力。技术架构上，我们为 Agent 准备了完整能力，但这不意味着所有任务都必须经过 Agent；产品取向上，我们始终是 Human-Centric。UI 不是 Harness 外面的包装，而是人和 Agent 共享的 Runtime。 GUI-Agent 双向协议的含义非常直接：在 Floatboat 里，用户能看到、能操作的 GUI，Agent 同样能够理解和修改。用户可以先在 UI 里完成一部分，再自然地用口述把后续交给 Agent；也可以随时接手 Agent 的结果继续操作。从 UI 操作到口述委托，不是切换到另一套工作模式，而是同一工作流中控制权的自然交接。 第三，我们不是只用 Agent 解决一切。Floatboat 首先考虑用户熟悉的交互环境，以及完成任务最快、最可靠、最经济的路径。如果一件事用代码、Workflow 或普通桌面操作就能直接完成，根本不需要 Agent，我们的 Harness 会允许这条路径发生；只有真正出现不确定性或问题时，Agent 才介入。Agent 是一种能力，而不是所有任务都必须缴纳的“智能税”。 面向真实工作，Workflow、Code、Agent、LLM 都可以被组织和协同。Harness 的任务不是让模型多跑几步，而是根据任务自适应地利用所有可用能力，在“多、快、好、省”之间找到最优解。五项 Benchmark 中，同一个 DeepSeek V4 Flash 在 Floatboat Harness 上全部超过 Claude Code + Claude Opus 4.8，证明的是这套系统工程的增量；而用户实际使用的完整客户端，工具面更宽，表现还会更高。 所以，全栈自研不是为了把所有轮子都握在手里，而是为了掌握完整的因果链：系统为什么采取这个动作、结果有没有更接近交付标准、出了问题能否解释和修正。Agent 的核心问题不只是生成，而是收敛。 InfoQ：一些开发者和 Coding 工具从业者认为，日常编程任务中的模型差距正在缩小，甚至有人认为“模