Uber：如何把研发做成一座「软件工厂」

来源：微信公众号 HiFox · 原文链接

这张图片展示了绿色的“HiFox”品牌标识，左侧是带有代码符号的绿色狐狸头图案，右侧是深绿色的“hiFox”字样，背景是浅淡的渐变效果。这张图片是来源微信公众号HiFox的相关标识，对应文档中编译标注的对应内容，体现了该来源的品牌视觉特征。

编译：Hifox.com

这张图片展示的是Uber的成本驱动引擎相关内容，其核心分为两部分，上方是驱动逻辑流程，从用户、会话每用户的规模维度，经回合数每会话、请求数每回合、令牌数每请求的智能体效率维度，最终作用于每令牌价格的单位成本维度，导向成本结果。下方标注了Uber的AI规模化成果，自2月以来的每周活跃用户达7倍，每周智能体请求量达9.4倍，直观呈现了其AI规模化带来的业务规模与运行效率的增长成效。

如今，AI 工具已经嵌入 Uber 软件开发的每个阶段。超过 70% 的拉取请求（pull request，PR）由本地代理或云端代理完成。工程师围绕整个软件开发生命周期构建了超过 3,600 项代理技能，每天执行的代理技能超过 3 万次。

在 AI Engineer 2026 大会上，Uber 分享了对“软件工厂”的愿景，以及正在围绕整个生命周期构建的基础模块和托管代理。随着这一愿景逐步落地，越来越多的会话不再由人发起，而是由自动化托管代理处理：代码审查、自动修复 CI 失败、完成带视觉验证的端到端 PR、分流值班告警、调试新收到的缺陷，以及处理各种代码维护任务，并在必要时交由人工审查或升级处理。

如图 1 所示，从 2026 年 2 月到 8 月，所有员工（工程师和非工程师）在各类代理产品中的周活跃用户数增长了 7 倍，代理请求数增长了 9.4 倍。与此同时，由于 Uber 在各个环节进行了优化，AI 总支出自 4 月以来基本保持稳定。

这张图表是Uber每周采用率和成本的相关数据展示，对应2026年2月至8月的统计周期，且用户已完成跨工具去重。图表包含三部分内容：每周活跃用户从2月到8月持续增长，相较2月以来的水平达到7倍；代理请求量同期持续上升，较2月以来的水平达到9.4倍；成本曲线在2月至5月间波动上升，5月后有所回落，8月有小幅回升，呼应了文档中Uber通过优化使AI总支出基本稳定，每1000次模型请求成本和每会话成本大幅下降的相关内容。

图 1：2026 年 2 月至 8 月中旬的周活跃用户、代理请求和成本；用户已跨工具去重

由于采用率、工作负载构成和模型升级都在持续变化，要单独衡量 Uber 自身的优化收益，就需要固定一个模型，因为每次升级或更换模型系列都会导致行为变化。Uber 在 2 月至 7 月期间这样做了：每 1,000 次模型请求的成本较峰值下降了近 34%，每个会话的成本较 6 月峰值下降了 52%。

图片展示了2026年在模型固定不变情况下的单位成本变化情况。左侧图表为每1,000次请求的成本，3月成本最高，8月成本最低，较峰值下降34%；右侧图表为每次会话的成本，5月25日成本最高，8月成本最低，较峰值下降52%。该图与上下文紧密相关，直观呈现了Uber在固定模型后成本优化的具体影响，支撑了文档中关于Uber成本优化成效的论述。

图 2：固定模型后的成本优化影响。每会话成本数据从 5 月底开始统计

本文将介绍 Uber 如何理解软件工厂：代理会话运行的四个层级、用于拆解支出的成本公式、各项指标的衡量方式，以及如何在每一层优化这些指标。

本文对比中的所有定价和供应商指标均基于公开信息；成本效率提升来自 Uber 在标准分层定价范围内，更智能地路由 Uber 内部工作负载。Uber 测得的具体降本幅度属于 Uber 环境的特有结果，实际效果会因代码库、团队规模和代理工作流而异；但“以真实工作为基准进行评测，并同时优化准确性和成本”的方法具有普适性。

软件工厂及其成本公式

代理使用的四个层级

Uber 把 AI 使用划分为四个层级，从最专用到最通用。如图 3 所示，层级越高，对成本、质量和模型选择的控制力越强。

图片展示了Uber代理使用的四个层级层级。专用代理包括Minion、uReview、Agentic XP、Conan AI、Fawkes，分别对应意图、PR、XP完成、AI根因分析、定时任务等任务，成本、审查、输出、告警、清理等。通用代理为Cortana，零配置、无处不在，适用于任意技能。带技能的会话使用超过3,600个黄金技能的代理式任务，成本、会话等。原始会话通过合适的提示、上下文和引导完成代理式任务，成本、会话等。该图与上下文介绍的Uber把AI使用划分为四个层级，从最专用到最通用的内容相关。

成本公式

对于上述任一层级，Uber 都可以把一次代理会话的成本拆解为以下各项，并分别进行衡量和优化。

图片展示了Uber会话结构的成本公式。总支出等于用户数乘以每个用户的会话数，再乘以每个会话的轮次、每轮请求数、每次请求的Token数，最后乘以每个Token价格。右侧有三组箭头，分别代表增长（采用与参与）、缩减（代理轨迹）、缩减（单价），对应公式中不同部分。该图与上下文紧密相关，直观呈现了Uber成本拆解的各关键因素，帮助理解其成本构成及优化方向。

前两项代表采用率和参与度。无论用户是交互式使用，还是让代理代为处理任务，Uber 都希望这两项在整体用户群中持续增长。中间三项提供了优化空间：它们代表代理为完成工作而额外执行的部分，叠加在工程师实际提出的请求之上。Uber 的工作重点大多集中于此，包括帮助代理更快规划、减少不必要的轮次或错误、优化输入 token 等机制。

如何衡量

下面是 Uber 每周和每月跟踪的完整指标集合，它们帮助规划短期和长期工作，并进行预测。

图片展示了Uber衡量成本优化的指标体系。分为组合、单工具单元经济、模型经济性、驱动因素分解、托管智能体结果五个层级。组合层级关注总归因成本、去重归因用户数等；单工具单元经济关注每用户成本、每1,000次请求成本等；模型经济性关注成本及成本占比等；驱动因素分解按顺序分解成本变化；托管智能体结果关注每个托管智能体的单位价值交付成本等。该图与上下文紧密相关，直观呈现了Uber成本优化指标的构成与作用。

优化杠杆

下面几节将详细介绍 Uber 用于优化成本公式各部分的关键杠杆。其中一些杠杆会影响成本公式中的一行或多行。

图片展示了Uber衡量成本优化的几个关键杠杆。价格/每Token方面，有基准驱动的帕累托最优模型选择、模型默认设置；每次请求的Token数量涉及默认400K上下文上限和中等推理努力程度、提示缓存等；每轮请求次数包含基于图的上下文、持续技能优化；可见性与教育涵盖状态行中的实时成本计数器、会话分析仪表盘等。这些杠杆帮助Uber规划短期和长期工作，进行预测。

优化价格 / Token

Token 价格由供应商设定；Uber 决定哪个模型运行哪种工作负载。在托管代理的所有层级中，Uber 会为特定工作负载选择 Pareto 效率最高的模型。对 Uber 而言，Pareto 效率指的是成本/已完成任务、输出质量和模型可靠性之间的综合表现。

由基准测试驱动的模型选择

模型选择分为四步，Uber 运行的每个托管代理都遵循相同流程：

  • 根据代理的真实工作构建基准测试。
  • 在一个可为任意模型（前沿模型或开放权重模型）提供统一接口的测试框架上运行代理。
  • 切换到 Pareto 最优方案，并持续迭代。前沿大约每几周就会变化。

展望未来，Uber 会利用托管代理汇总出的洞察，测试并部署各种模型路由策略，持续改进工作负载表现。

例如，uReview 负责审查所有拉取请求中的 AI 代码审查。Uber 使用包含已知缺陷的真实 PR 构建基准，并将其分为简单、中等和困难三档。针对这些缺陷，Uber 评估精确率、召回率和 F1 分数，同时评估每次审查成本、延迟、超时和噪声。如图 5 所示，切换模型提高了 F1 分数，同时大幅降低了每个 PR 的成本。图中的虚线是 Pareto 前沿；位于其下方和左侧的所有配置，都被某个更便宜或更优的配置击败。

图片展示了Uber在Ureview基准上10种配置的成本与质量关系。横轴为每次审核成本（对数刻度），越便宜；纵轴为F1分数。图中用不同颜色和标记区分了前沿模型、开放权重模型及已投入生产的配置。其中，前沿模型A、B、C及开放权重模型A、B、C的配置点被标注，前沿模型C（$0.47，F1 0.50）被选中，开放权重模型A（$0.28，F1 0.48）和前沿模型B（$2.22，F1 0.483）的配置成本和质量也进行了对比。该图与上下文紧密相关，直观呈现了不同配置的成本与质量情况。

利用大型单体代码库中的数千个真实 PR，Uber 内部还建立了 Uber SWE Benchmark，可让前沿模型和开放权重模型处理不同类型的任务。Uber 用它指导整个软件开发生命周期托管代理的模型选择。

默认模型选择

在交互式界面中，Token 单价保持不变；不过，Uber 可以策略性地管理 Token 在不同模型之间的分配。两个默认设置主要决定这种分配：会话初始模型和子代理模型。

事实证明，子代理的默认设置是影响最大的杠杆，而且其重要性还在持续上升。随着最新模型能力提升、多代理编排变得更有效，启动子代理的会话比例稳步增加。子代理执行的是输入明确、定义清晰的任务，通常不需要前沿级推理，因此 Uber 默认使用能力较弱但更具成本效益的模型，同时允许手动覆盖。主模型负责任务拆解和评估，子代理负责执行工作。

优化 Token / 请求

每一轮都会重新发送完整的对话历史、项目上下文和工具结果。任何能减少单次请求载荷的措施，都会在整个会话中产生复合收益。

默认设置

所有交互式测试框架都使用统一封装层，负责安装管理、配置、身份验证和成本可见性。两项标准化默认配置可以直接减少每次请求的 Token 消耗：

  • 即使模型拥有 100 万 Token 的上下文窗口，也会在 40 万 Token 处自动压缩上下文。这个阈值在模型性能、缓存突发和重复输入 Token 成本之间取得平衡。Uber 的测量显示，这能显著降低全体系统每次请求的输入 Token 数量。
  • 默认将推理强度设为 Medium（中等）。在主模型上，包括内部推理 Token 在内的输出 Token，其计费倍率是输入 Token 费率的数倍；这一策略调整直接减少了最高成本类别中的支出。对于大量任务而言，中等推理在成本和质量之间取得了良好平衡。

提示词缓存策略

Uber 的提示词缓存策略由供应商缓存读写的经济性驱动。由于每轮都会重新传输完整对话历史，缓存前置上下文可以避免反复支付全部成本，使后续读取降至标准输入 Token 费率的 0.1 倍。不过，写入溢价各不相同：5 分钟缓存条目的成本是 1.25 倍，1 小时缓存条目的成本是 2 倍。因此，最优 TTL（生存时间）取决于两轮之间间隔的长短。Anthropic® 提供 5 分钟和 1 小时两种 TTL，OpenAI® 提供 30 分钟 TTL。

图片展示了Uber在提示词缓存策略中关于TTL（生存时间）的优化情况。图中以时间轴形式呈现，分为主线程和子智能体两部分。主线程中，工程师阅读差异、加入会议等操作导致缓存过期，5分钟TTL和1小时TTL成本分别为3.95倍和2.40倍，后者便宜39%。子智能体生成、工作等操作，5分钟TTL和1小时TTL成本分别为1.65倍和2.40倍，后者便宜31%。该图与上下文紧密相关，直观说明了不同TTL策略对成本的影响。

由于工程师经常让交互式会话空闲超过 5 分钟，Uber 已将默认 TTL 从 5 分钟切换为 1 小时。过去，这些频繁的空闲间隔会使前缀缓存失效，迫使系统以全价重建上下文。相比之下，子代理专注于单一且生命周期较短的任务，因此仍保留 5 分钟缓存 TTL。

通过 Shell 执行 MCP 工具

在 Uber，所有 MCP（模型上下文协议）交互都通过统一网关路由。这个单一入口覆盖 1,000 多个 MCP 服务器，包括内部 MCP 和第三方 SaaS MCP，并集中处理身份验证和策略执行。

然而，标准 MCP 会把所有工具的 schema 直接加载到每个会话中，无论工程师是否会在该会话里调用这些工具。例如，安装超过 100 个工具时，这种预加载会在初始提示中增加约 5 万至 7 万个 Token 的 schema 开销，随后每一轮上下文都会再次发送。

图片展示了Uber为解决上下文膨胀问题引入的两种互补优化机制。左侧为安装每个服务器时，每个工具schema无论是否使用都会占用约50 - 70,000个token，工程师添加的服务器上安装了100+个工具。右侧为工具搜索 + CLI，aifx mcp调用在调用时解析，上下文中没有Uber MCP schema，网关持有它们每一个，占用token接近零。该图与上下文紧密相关，直观呈现了两种优化机制的上下文占用情况。

为解决上下文膨胀问题，Uber 引入了两种互补的优化机制：

  • CLI 工具解析：允许模型执行 Shell 命令，以此替代直接的 MCP 集成。CLI 在调用时动态解析所需工具，并通过网关执行，从会话上下文中移除 Uber MCP schema。内部 MCP 网关中的 1,000 多个 MCP 工具都被映射为 CLI 命令。
  • 工具搜索：允许模型搜索工具目录，并按需只加载需要的工具，从而扩展到数千个工具。这种方式通常能减少工具定义所占的 Token，同时在工具库不断扩大时保持较高的选择准确率，避免大规模工具集带来的性能下降。

代码模式（Code-mode）

当工具通过 Shell 命令直接调用函数时，模型可以在一个脚本中批量执行多个操作。这种批处理对交互频繁的工具协议尤其有利。在标准 MCP 工作流中，每个操作都需要单独一轮模型调用来发出请求、将原始响应加载进上下文，并按顺序处理结果。例如，执行一次 SQL 查询需要提交请求、轮询状态 2 至 5 次，再获取输出。代码模式把整个流程简化为自动运行的 Python 循环，将中间轮询留在模型活跃上下文之外。如图 8 左侧所示，模型参与轮询循环，每次响应都会进入上下文；右侧则是在子进程中运行循环，只有摘要返回给模型。

图片展示了MCP工具使用和代码模式下模型执行流程的对比。左侧为工具模式，模型每一步都是模型轮次，需提交查询、运行ID、轮询状态等，完整原始载荷每次查询903 - 1,431,594个token。右侧为代码模式，循环在模型外部运行，编写脚本后提交，轮询xN次，简洁摘要约400个token，其中约300个来自打包技能。该图与上下文紧密相关，直观呈现了两种模式下模型执行的不同流程及效率差异。

Uber 在同一会话中通过两条路径执行 5 次完全相同的 SQL 查询，对此进行了测量：

这张图片是Uber关于SQL查询的测试数据表格，展示了同一会话中5次相同SQL查询分别使用LLM工具和代码模式的Token使用量及节省比例数据。表格里的查询包括SELECT 1(1行)、COUNT(*)(1行)等，其中代码模式的Token使用量远低于LLM工具使用量，且对应不同的节省比例，最高的是SELECT *宽表(50行)的查询，节省比例接近100%，这些数据对应了上下文里代码模式能显著降低Token使用量的核心结论，所有查询的令牌数均是在同一次Claude Code会话中测量得出。

前三行数据突出了主要结论：即使结果集很小、远低于响应大小限制，代码模式也能将 Token 使用量降低 50% 以上。这些效率提升并不是因为绕过了大型数据载荷，而是因为消除了不必要的开销，包括 schema 初始化、多轮轮询和重复的逐步推理。

批量工作流会进一步放大这一效果，因为原本需要 N 轮模型调用的循环现在变成一个脚本，节省幅度可叠加到 90% 以上。Uber 已经为访问量最高的 MCP 服务器部署了 25 多项预构建代码模式技能，确保标准工作流默认采用最具成本效益的路径。

SaaS MCP

管理第三方软件的难度明显高于管理内部服务器。供应商设计 MCP 服务器时，通常会暴露产品的全部能力，因为他们无法预知每位客户的具体使用方式。例如，一个工作区套件在单个服务器中捆绑 49 个工具，需要约 2.2 万 Token 的 schema；消息和项目跟踪供应商分别提供 34 个和 46 个工具。加载两三个供应商服务器后，代理携带的 schema 开销甚至会超过用户准备编辑的文件大小，而用户还没来得及输入提示词。

为解决这个问题，Uber 使用与内部 MCP 相同的机制，把 SaaS MCP 服务器通过 MCP 网关路由。Uber 还将所有这些 MCP 暴露为任何代理界面都能调用的 CLI。此外，Uber 在代码模式插件中为每个服务器编写专用技能，封装常见工作流。这样便在众多 SaaS 供应商之间实现了高效的代理工作流。

图片展示了Uber的MCP网关架构。左侧是aifx mcp调用命令，包含服务器和工具信息，被一个shell命令调用。右侧是MCP网关，负责认证、策略、计量，连接每个SaaS服务器。网关右侧还列出工作区套件、项目跟踪器、消息、问题跟踪器、设计等工具，以及网关上的其他所有服务器。该图与上下文紧密相关，直观呈现了MCP网关在SaaS MCP优化中的作用及连接关系。

优化请求 / 轮次

缺乏依据的代理并不会更便宜地失败，而是会缓慢失败：它不断发送扩大的上下文窗口，只为再搜索一个位置。提前提供更丰富的信息，仍然是减少这类搜索开销最强大的单一杠杆。

上下文工程

Uber 的代码库和数据生态极其庞大，包含数亿行代码和数千张表。代理大部分轮次都花在定位信息上，而不是生成代码。为此，Uber 构建了 AI Context Graph（AI 上下文图）：一个统一网络，包含 2,400 万个节点和 8,000 万条边，覆盖 86 种节点类型和 117 种边类型。它整合了 30 多个内部系统的数据，包括服务、工程团队、事故日志、拉取请求、架构设计文档、部署记录、数据集以及历史表使用查询，并允许任何代理用自然语言查询。

这张图对比了使用与不使用AI Context Graph图结构处理特定查询的结果。针对“有没有办法在Forge中对Vehicle Lists进行Hive查询？”的问题，使用图结构的处理耗时38秒，无错误，结果被判定为正确，涉及名为dwh.lookup_product_vehicle_list的表，该表有53位用户使用过；不使用图结构的处理耗时20分09秒，出现3个错误，结果判定为错误，耗时是使用图结构的30倍以上。两者的正确性评分分别为30/30、19/30，体现了AI Context Graph在提升查询效率和准确性上的作用。

有上下文 grounding 的代理查询了历史使用记录，找到了 50 多名分析师使用的具体表，并在 38 秒内给出答案。相反，没有 grounding 的代理看不到这张表，花了 20 分钟检查服务代码，启动 2 个子代理并遇到 3 次错误，最终错误地得出“该数据集无法查询”的结论。

可见性与教育

这一部分的杠杆是可见性和反馈闭环，帮助工程师与代理更快收敛。

状态栏

Uber 在测试框架的状态栏中加入实时成本计数器，跟踪每位用户在单个测试框架以及所有测试框架中的实时支出。

图片展示了Uber工程师在终端中始终可见的实时成本计数器状态栏。内容包括终端命令“engineer@devbox:go-code (feature/statusline - pool +1)”、Tokens数量及占比、Sonnet和Claude的使用情况、pool和session成本、effort等级以及链接。该图片与文档中“状态栏”部分内容相关，直观呈现了文档所描述的终端中始终可见当前会话成本这一状态栏功能。

可见性与支出等级

为了避免设置严格上限，Uber 实现了实时支出跟踪和自动提醒：

  • 状态栏实时计数器：终端中始终可见当前会话成本。
  • 测试框架池：所有交互式测试框架共享一个等级，而不是每个工具单独设预算；托管代理则使用独立等级。
  • Slack 提醒：在达到预期支出的 50%、80% 和 100% 时发出提醒，让工程师有时间规划。
  • 便捷的审批流程：升级支出等级只需经理批准，并能快速生效。
  • 成本检查技能和提示：提供按需拆解成本的仪表板技能，以及状态栏实时效率指导。

这些机制让工程师能够独立评估任务的投资回报率，同时降低支出失控的风险。

会话分析仪表板

状态栏能突出显示会话总支出，却看不到成本驱动因素或可执行的效率改进步骤。通用指导只能提供高层原则，无法评估每位开发者的具体工作流。会话分析仪表板通过直接检查会话产物，填补了这一空白。

它直接构建在运行时中，无需设置或主动启用。执行成本仪表板技能后，系统会分析该用户在所有测试框架中、本地和远程云沙盒里的全部会话轨迹。它不会只生成一个汇总指标，而是识别会话中的 16 种不同反模式，并为每种反模式标注财务影响和有针对性的改进措施。其中包括：

  • 次优模型路由：在 Opus 上执行简单的多轮会话，而 Sonnet 完全能够胜任。
  • 上下文窗口膨胀：大型 MCP 载荷（例如 40KB 的响应）持续留在上下文中，并在后续轮次重复计费。
  • 缓存过期低效：长时间中断后恢复会话时，已过期的提示缓存迫使系统按全价重建前缀。
  • 提示初始化开销：在用户输入任何内容之前，预加载 100,000 个 Token 的系统指令和工具定义。

该会话分析仪表板属于Uber优化AI会话相关数据的工具，是其提升研发效率举措的一部分。它展示了多项核心业务数据，包括总支出4162.07美元、会话总数433个、缓存命中率95%，以及缓存错失成本1097.82美元和潜在节省金额1213.87美元，这些是针对次优模型路由等会话相关问题的分析依据。页面顶部带有Overview、Charts等功能标签，还设有日期范围、项目、代理的筛选选项，下方设有“按时间支出”“按模型成本”的分析板块，可帮助相关人员直观查看会话相关的成本与运营数据。

下一步是什么？

当前正在推进的工作包括：

  • 扩大托管代理规模：每新增一个代理，Uber 都遵循一致的路线图：确定目标结果指标、建立评测基准，并找出 Pareto 最优模型。这个系统化方法旨在让软件开发生命周期的每个阶段都在工厂成熟度模型中进一步提升。
  • 动态模型路由：扩展对不同编程语言、代码仓库和代理形态的基准覆盖。有效的模型路由高度依赖全面评测，因为不同模型的能力差异很大。
  • 深化上下文图谱集成：让更多自主代理能够使用图谱查询能力。
  • 将会话分析演进为实时开发者指导：从定期批处理检测反模式转向持续监控轨迹，直接为工程师提供个性化的实时效率建议。
  • 持续改进技能：Uber 正在研究一种自动化方式，记录代理技能执行过程中的“硌脚点”（papercut），并根据收集到的轨迹自动生成技能更新。

结论

管理和遏制不断上升的 AI 编码支出，同样是一个可以通过工程手段解决的问题。Uber 通过消除浪费、没有价值的 Token 消耗，而不是只依赖降低单价或降级工具，实现了使用量增长 7 倍，同时所有指标的单位成本都下降，并且输出质量得到提升或保持。

这套方法的关键，不是某个单独的模型或工具，而是一条可持续的闭环：用真实任务建立评测基准，用数据同时观察成本、质量和延迟，再把高频工作流沉淀为可复用、可托管的代理能力。将软件开发生命周期中的工作负载迁移到托管环境后，团队才有可能统一管理模型路由、上下文、执行框架和运营支出，并以更低的边际成本持续扩展。

对正在探索 AI 工程化的团队来说，可以从小处开始：先让每次调用的成本和结果变得可见，再逐步优化模型选择、上下文组织和工作流编排。最终目标不是让每个人都成为提示词或模型调参专家，而是让 AI 真正成为研发系统的一部分，并且越用越高效。

Al 时代全新的软件开发协作平台

Uber 的实践说明，AI 代理要在大规模研发中发挥价值，不能只停留在某个工程师的终端里。除了执行能力，团队还需要一层协作能力：任务从哪里来、应该交给谁、多个 Agent 如何并行、过程怎么被看到，以及结果如何进入验收。

这正是 HiFox 所在的层。HiFox 将任务、项目、People、Agent 和 Computer 统一组织起来；Agent 在选定的 Computer 上负责理解代码、调用工具和执行任务，过程与结果则回到 HiFox 中持续跟踪。

Jira、TAPD 等传统项目管理工具，诞生于“人是唯一执行者”的软件开发时代。进入 AI 时代，团队需要一套全新的软件开发协作平台。HiFox 把 Agent 变成真正的队友：像给同事指派任务一样，直接把任务指派给 Agent，并持续跟踪它的执行过程与结果。

HiFox 还将不同的 Agent 工具接入统一的协作平台，可直接接入** Claude Code、Codex、OpenCode、CodeBuddy、Qoder、TRAE、Pi 等支持通过 CLI 使用的 Agent 工具。团队无需放弃现有工具链，就能在统一的任务、项目和协作体系中调度不同 Agent。**

换句话说，Agent 负责把事情做完，HiFox 负责把事情组织起来：让任务可分配、过程可追踪、权限可处理、结果可验收。当 AI 从个人工具变成团队基础设施，这一层协作能力也会变得越来越重要。

如果你的团队也在尝试把 AI 编程从个人实验推进为稳定的研发流程，可以从 HiFox 开始，让分散的 Agent 能力进入同一条可协作、可并行、可验收的工作流。

**👉 立即体验 Hifox： **https://hifox.com

图片展示的是HiFox内测群的二维码。背景为黑色，二维码外框为绿色，内框为白色。二维码下方有绿色的HiFox图标，图标旁文字为“HiFox内测群”，再下方是“扫一扫群二维码加入该群”的提示。该图片位于文档结尾处，与文档中“如果你的团队也在尝试把AI编程从个人实验推进为稳定的研发流程，可以从HiFox开始，让分散的Agent能力进入同一条可协作、可并行、可验收的工作流”等内容相呼应，引导用户扫码加入HiFox内测群，体验相关功能。