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

作者 | Tina

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 才介入。”Floatboat 技术联创 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 工具从业者认为，日常编程任务中的模型差距正在缩小，甚至有人认为“模型到顶了”。你认同吗？在你们开发 Agent 产品的过程中，有没有哪个具体场景让你觉得：如果模型再强一点，这个环节就不需要 Harness 如此费力地补偿？又有什么能力是 Harness 补不了的？

Remy：这个问题要分上限和下限看。上限部分，模型远没有到顶；下限部分，今天主流模型已经非常高了。日常补全、简单改错和常规脚手架越来越接近，但到了陌生代码库、开放任务、跨工具协作和长时状态保持，模型之间仍然有明显差异。

对我们的 Harness 来说，前几个月确实存在一些“补偿模型”的工作，主要是为 Agent 设计更合适的工作环境。但现在已经很少有需要特别费力补偿的部分，因为我们的目标从来不是替模型兜底，而是最大化模型能力。Floatboat 这个名字也表达了这个选择：不仅让用户悬浮于 AI 浪潮之上，我们的产品和技术也要悬浮于具体模型之上，随着模型水涨船高。

模型如果继续变强，对模糊错误的理解、长程约束的保持、工具副作用的预测和失败后的路径选择都会改善，Harness 中一部分机械纠错和提醒自然会变轻。但 Harness 补不了模型本身没有的抽象推理、领域知识和概念跃迁。它能做的是提供更好的感知、记忆、工具、反馈和边界，不能把不存在的认知能力包装出来。

模型决定每一步判断的上限，Harness 决定这些判断能否在一条长路径上积累成结果。我们的重点因此不是“补偿”，而是动态进化，并且要领先于模型所面对的真实需求：供给会越来越强，谁能更早理解并进入真实、复杂的需求，谁就能持续形成领先性。毕竟，模型训练最终也是为了参与和解决真实世界的问题。

InfoQ：现在大量 Coding Harness 的架构都可以概括为上下文、工具、Agent Loop、验证和运行环境。如果极端一点问，AI Coding 工具的实现路径是否正在全面收敛？真正还能形成差异的，究竟是某个技术模块，还是这些模块之间的整体配合？

Remy：真正形成差异的是整体，而且这个整体应该能够被 Agent 本身驱动进化。今天大家使用的名词正在收敛，但系统远没有收敛。所有操作系统都有进程、内存、文件和权限，不代表它们的体验、可靠性和边界相同；同样，拥有 Context、Tools、Loop、Verifier 和 Runtime，也不意味着会得到相同的 Agent。单看模块清单，很多 Harness 可能区别不大；但真正决定体验的是它们能否围绕一个交付标准稳定收敛。因此，差异不是某个孤立模块，而是整套闭环的控制策略和演进速度。

从这个角度看，AI 时代真正的生产力单位不是单个 Agent，而是一套能够持续执行、验证、记录状态，并在必要时升级给人的闭环。Harness 的价值，就是把一次智能调用变成可交付、可积累的生产系统。

差异往往发生在模块之间的协议里：工具失败时返回空字符串还是结构化错误；上下文压缩时保留的是字面信息还是任务不变量；验证发生在每一步、里程碑还是最后；权限拒绝后是停止、追问还是盲目重试。这些看似是实现细节，经过几十轮执行后会累积成完全不同的结果。

所以，单个模块可以形成阶段性领先，持久差异一定来自整体配合。所有模块必须服从同一个目标函数：以可接受的成本和风险，更快逼近交付标准，而不是上下文只追求压缩率、工具只追求数量、Loop 只追求步数、验证只追求通过率。局部都正确，整体仍然可能失败。

FloatSail 的作用，就是让 Runtime、Loop、Tools 和模型适配策略在真实任务反馈中持续进化。未来评估 Harness，不应该只数它有多少模块，而应该看三个结果：任务收敛得多快，错误能否被限制在局部，每交付一个成功结果需要多少成本。架构图会越来越像，运行时的因果纪律、反馈密度和产品判断不会自动趋同。

InfoQ：Floatboat 一开始面对的就是跨文件、浏览器和在线服务的通用任务，而一些 Harness 是在 Coding 场景中打磨出来的，比如 Claude Code、workbuddy 这些。这两种起点会不会把 Harness 带向哪些不同的技术路线？还是最后两种路线会趋同？目前，通用场景额外要求哪些 Coding Harness 不具备的能力？通用 Harness 与 Coding Harness 有没有一条关键的分界线？如果最终汇合，你们的护城河会落在哪里？

Remy：当前两条路线的差异非常大。如果最终要解决的任务越来越相似，从技术演化看，底层能力大概率会逐步趋同，但这个过程会很长。它有点像智能手机早期百花齐放，后来 OS 和应用的基本形态越来越接近；但趋同的是基础设施，不是所有产品都会因此变成同一个产品。

Coding 的优势是交付标准相对容易形式化：代码能否编译、测试是否通过、类型是否正确、diff 是否符合约束。通用任务则更多发生在开放世界和社会规则之中。一封邮件是否得体、一份研究是否抓住重点、一次跨 SaaS 操作是否符合组织政策，都包含情境、权限、审美和责任判断。

因此，通用 Harness 额外需要跨应用身份与权限治理、异构状态和长期记忆、不可逆操作的风险控制，以及与用户共同澄清验收标准的能力。它还必须处理隐私、数据最小化、审计和撤回机制。Coding Harness 主要管理技术复杂性；通用 Harness 同时管理技术复杂性和社会复杂性。

但风险治理不能退化成让用户审批一百个工具调用。那不是 Human-in-the-loop，而是把 Harness 的缺陷转嫁给用户。用户真正需要关心的，不是底层执行链的每个细节，而是与其目标、数据和责任有关的切面：系统准备做什么、会影响什么、哪些结果不可逆、什么时候必须由人判断。现有的一切 GUI 交互其实就是极好的用户切面，因为它用用户已经理解的对象、状态和动作来呈现系统行为。

这种起点最终会直接体现为产品形态。即使不用 Agent 功能，Floatboat 也应该是一台很好用的桌面工作站。我自己是很多效率软件的深度用户，过去会安装各种阅读器、播放器、文件搜索、字典和笔记软件。但最近换电脑时，我意外发现，原来将近三分之一的软件已经不需要再装了，因为这些能力都被 Floatboat 囊括了。这正是 FLoatboat 这个通用 Agent 产品与模型调用壳之间一个很根本的区别。

两者的关键分界线，是交付标准能否在任务开始时被充分形式化。能够预先写成测试的任务，核心是可靠执行；无法预先写成测试的任务，系统还要在执行中帮助用户发现自己真正要什么。后者要求系统在真正需要时具备 Agent 的主动性和自适应能力，但产品上始终是 Human-Centric。

如果最终汇合，护城河一定是综合的、动态的。团队、技术、产品、商业化任何一个单点，都很难在商业世界形成绝对壁垒。你必须持续成为当时技术条件下的最优解产品，积累真实任务形成的反馈和信任，同时获得足够的市场规模。底层能力可以标准化，但“解决什么问题、什么算做好、如何持续进化”不会被一次标准化带走。

InfoQ：DeepSeek Harness 把模型、工具、Skills、记忆、沙箱、任务调度和 UI 都做成可替换插件。有人认为，这套底座未来会直接进入通用 Agent 场景，压缩 WorkBuddy、Floatboat 这类通用 Agent 场景空间。你怎么看 DeepSeek Harness 对通用 Agent 市场的影响？当通用执行底座逐渐开源和标准化后，竞争差异会转移到哪些层面？

Remy：DeepSeek Harness 这条路径我们考虑过，但它首先是一套高自由度的执行底座，不是直接面向终端用户的完整产品。

我们要做的，是在这种高自由度与稳定交付之间找到平衡。面向技术演进很重要，但最终仍然要面向用户，回答谁在什么场景下，愿意把什么样的重要工作交给系统。

我们不把开放底座看作对通用 Agent 的简单替代。它会显著抬高行业下限：模型接入、工具协议、Skills、记忆、沙箱和调度不必由每个团队从零搭建。被压缩的首先是“把模块拼起来就算产品”的空间，而不是所有通用 Agent 的空间。

同一个 DeepSeek V4 Flash 的对照实验也说明，拥有类似模块不等于得到相同系统。

DeepSeek 官方 Harness 与 Floatboat Harness 使用相同底座和输入参数，五项基准仍然出现从 1.9% 到 23.6% 的增益差异。标准化解决的是接口可用性，不会自动解决上下文取舍、错误语义、权限边界、验证时机和长程收敛。

就像 OS 逐渐标准化以后，竞争仍然存在，执行底座标准化之后，差异会转移到最终解决什么问题、生产什么价值，以及产品在生态中的位置。更具体地说，是任务与评测、真实反馈资产、信任与安全、人与 Agent 的产品界面，以及单位成功任务的经济性。开放会扩大市场，也会让真正的差异更难伪装。

InfoQ：2026 年被称为“Agent 编排之年”，但现有产品仍大致没有跳出几种基本编排模式。从你们的视角看，过去一年多 Agent 的实质进展是什么？你们目前在多 Agent 编排上是否已有实践？如果已经实现多个 Agent 共同完成任务，它们怎样共享状态、分配任务、处理冲突并完成最终验收？如果还没有，你们认为现阶段缺的是实际需求，还是基础设施？

Remy：过去一年，一个重要背景是开源模型的能力下限提升得非常快，而且是在市场相对悲观的氛围里成长起来的。这说明做技术和产品，关键还是专注于解决问题，不要被市场噪音支配。氛围是别人的，突破必须由自己完成。

多 Agent 真正的进展也不是屏幕上同时出现了更多头像，而是复杂任务开始具备可分工、可隔离、可验收的组织结构。Floatboat 在架构上很早就采用了多 Agent 编排，我们也发布了 FloatIM，探索人和 Agent、Agent 和 Agent 之间的协同，目前已经有用户和客户在使用。

但正因为做得早，我们反而更确认：多 Agent 首先是产品问题，不是技术指标。不是所有任务都需要多个 Agent，大部分时候甚至不需要。只有当任务能够被清楚拆分、子任务具有局部验收标准，而且并行收益高于协调成本时，多 Agent 才真正成立；否则只是把单体 Agent 的内耗变成分布式内耗。

所以现阶段既不缺需求，也不只是缺一个调度框架，真正缺的是可证明的协作经济学：什么任务值得拆、每个角色贡献了什么、冲突如何计价、最终质量是否超过单 Agent 基线。这个方向我们已经有实践，但整体仍然处于探索阶段。

InfoQ：你们的评测呈现出一个规律：任务越长程，Harness 带来的增益越大。你们认为这会成为一条普遍规律吗？“长程”应该按照执行步数、工具调用次数、状态跨度，还是任务的开放程度来衡量？很多 Agent 前十几步表现很好，到了四五十步就开始漂移。你们观察到的长程失控，主要来自目标被稀释、上下文压缩失真、工具错误累积，还是验证反馈不足？这些问题中，哪一个至今仍没有好的技术解法？

Remy：这个判断一开始来自逻辑推演，评测结果进一步验证了它。同一个 DeepSeek V4 Flash，在短程 Terminal Bench 2.1 上，Floatboat Harness 相对官方 Harness 的提升是 1.9%；到了长程 DeepSWE，提升达到 23.6%。HLR 也从 0.78 倍上升到 3.57 倍。任务链条越长、状态越复杂、验证越稀疏，Harness 的杠杆通常越大。

不过，“长程”只是任务复杂度的一个表征。复杂度本身很难直接度量，所以工程上常用 Loop 次数作为代理，但不能只看步数。调用 50 次同一个稳定 API，未必比修改 7 个相互依赖的文件更长程。更重要的维度包括依赖链深度、状态跨越的时间和工具数量、目标开放程度、操作可逆性、验证信号的稀疏度，以及错误被发现前需要经过多少轮反馈。

长程漂移首先与 LLM 的概率特性有关，其次是用户需求通常不会在任务开始时就完全明确。再往后，才是 Harness 中的目标稀释、上下文压缩失真、工具错误累积、回溯困难、分支裁剪，以及缺少高置信度反馈。这些因素不是彼此独立的，而是一条因果链：早期偏差被写入环境，验证又来得太晚，最后才以“突然漂移”的形式暴露。漂移不是突然发生的错误，而是迟到的错误报告。

当前最困难的问题，是如何把模型分布之外或分布边缘的问题，编排成模型分布内可解、可验证的操作。我们当前的技术方向，就是把模型分布之外或边缘化的问题，逐步转成可编程、可验证、可恢复的子问题，并形成系统化闭环。我们已经形成了一套系统化的解法路径，但这并不意味着问题已经终结；真实世界不断产生新的边缘情形，系统也必须持续进化。

InfoQ：你们提到 FloatSail 会让 Runtime、Loop、Tools 和模型适配策略根据真实任务反馈持续演进。这里的“演进”具体是系统自动修改 Harness，还是工程团队基于运行数据持续优化？目前哪些环节已经能够自动完成？如果这里的“持续演进”包含系统自动修改 Harness，你们如何看待“软件自进化可能是个伪命题”这一观点？模型可以不断生成新的 Skill、工具和策略，但需要长期保留的软件仍然要经过设计、验证和维护，否则自进化可能只是自动积累技术债。你们认为真正的 Harness 自进化应该满足哪些条件？

Remy：我们不会把“演进”理解成模型随时随地任意改写生产系统。对产品级 Harness 来说，真正可用的演进必须是受控闭环：从真实任务中发现问题，生成候选改动，在隔离环境中评测，通过质量、成本、时延和安全门槛后灰度发布，再持续监控并保留回滚能力。Floatboat 的演进分阶段推进：最初是人在环中，现在更多是人在环上——大量局部优化可以自动完成，人主要负责目标、边界、例外和系统级治理，而不是逐环节微操。

所以，“软件自进化是伪命题”这个质疑有一半是对的：如果所谓自进化只是不断生成新的 Skill、工具和策略，却没有版本管理、评测、淘汰与维护，它确实只是在自动积累技术债。但研究已经证明，在边界清晰的条件下，自我改进可以成立。Darwin Gödel Machine 通过让 Coding Agent 修改自身代码，并用基准评测验证每次变化，显著提升了 SWE-bench 和 Polyglot 表现；同时它也依赖沙箱与人类监督。这恰好说明关键不在“能不能改自己”，而在“如何证明改得更好、代价可控，而且随时能退回去”，实现帕累托改进。

我们认为，真正的 Harness 自进化至少要满足五个条件：第一，适应度来自真实任务和明确验收，而不是模型自我感觉；第二，所有变化可观测、可版本化、可回滚；第三，在沙箱、权限与风险边界内运行；第四，用质量、成本、时延、安全等多目标共同约束，避免只刷单一 Benchmark；第五，能合并、淘汰和维护已有能力，而不是只增不减。长远看，它还需要与模型高度协同，但进化方向最终来自对真实生产力的广泛、深入参与。更重要的是，进化必须有方向。这个方向不是 Benchmark 分数本身，而是能否广泛、深入地进入真实世界的生产力，参与真实经济体的价值创造。

模型训练会越来越成熟，模型能力也会分化，以及商业世界的客观规律，共同决定了开放、中立生态位必然存在。Floatboat 中长期的价值，就是在这个生态位上，把不断增强的模型能力转化成真实、稳定、可持续的生产力。

METR：《Measuring AI Ability to Complete Long Software Tasks》，NeurIPS 2025；arXiv:2503.14499 v4（2026-07-10）。https://arxiv.org/abs/2503.14499

Anthropic：《How we built our multi-agent research system》（2025-06-13）。https://www.anthropic.com/engineering/multi-agent-research-system

Jenny Zhang 等：《Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents》，arXiv:2505.22954 v3（2026-03-12）。https://arxiv.org/abs/2505.22954

Anthropic：《Building Effective Agents》（2024-12-19）。https://www.anthropic.com/research/building-effective-agents