PPAYMENTS HOT
精选/全部动态/Brex
A1 · 官方一手证据完整中文译文不进入实时 Feed97/100

Brex

长期运行的智能体不需要工具或托管沙箱;他们唯一需要的是 bash。

Brex 围绕 bash 工作台重建了费用审计智能体,减少了令牌使用,同时提高了开放式审查的召回率。

长期运行的智能体不需要工具或托管沙箱;他们唯一需要的是 bash。
来自官方页面的原始图片
日期核验已核验: 2026年7月6日
采集方式直接抓取 · 7月16日 16:29
标题证据verified · captured_page
正文指纹8fb805f19c997c9ce7
1768原文词数14张原图8个标题16个链接
阅读模式

中文页按照英文原文结构提供完整中文译文,并保留原始图片、链接与追溯信息。切换到英文可查看采集到的官方原文;中文译文可能需要人工复核,版权仍归官方来源所有。

长期运行的智能体不需要工具或托管沙箱;他们唯一需要的是 bash。

证据等级:A1 证据类型:官方一手信息 来源:Brex Engineering Blog 官方发布日期:2026-07-06 采集时间:2026-07-16T20:29:56.141Z

Official source image

在 Brex,我们正在为企业支出构建智能体。一个智能体帮助员工完成报销,另一个我们称之为审计智能体,负责审核支出、检测滥用或欺诈模式,并将最高价值的操作升级给财务团队。

审计智能体必须检查收据、用户历史记录、先前案例、日历上下文、网络研究和保单文本,然后生成财务操作:批准、拒绝、标记审查、请求更多信息或发送保单提醒。目标是逐一审查:审核更多支出并仅显示需要人工的决策。

有些评论很简单,只需一笔费用、一张收据和一张保单支票。更难的评论是开放式的。在智能体读取旅行背景之前,晚餐可能会不符合政策。报销看起来可能没什么害处,除非它与公司卡费用结合在一起。旅行模式可能需要收据文本、网络研究、先前案例和政策数学。

我们无法预先规定每条调查路径。智能体必须决定检查、加入、丢弃和继承什么。

我们的第一个实施为该模型提供了针对费用、收据、用户、案例、日历、网络搜索和最终审核提交等明显来源的专用工具。我们还使用结构化输出,并在生成的操作不符合质量标准时重新运行作业。

简单的评论就很好了。更深入的调查暴露了运行时问题:每个本机工具调用都会返回到对话中。收据页面、费用列表、部分联接和假设填满了上下文窗口,没有便宜的地方可以丢弃不相关的行、保留草稿记录或将 1000 行结果减少为重要的 12 行。

Context window

本机工具循环将费用数据、收据文本、先前案例、Web 结果和部分连接推送到模型上下文中。工作台将原始工件保留在转录本之外,并返回较小的决策数据包。

智能体需要一个用于调查中间的工作台:一个保存原始工件、减少它们并仅将有用的上下文带回到决策中的地方。工具是智能体接触世界的方式,而工作台是将原始访问转化为有用上下文的地方。这改变了工具设计问题。费用、旅行、政策、商家、网络研究和案例位于一个轴上,而获取、过滤、分组、排序和搜索位于另一轴上。针对每个细胞的专用工具变成了逐个工作。工作台让智能体自行组成行和列。

编码-智能体形

智能体编码已经找到了这种模式。当工作需要很多步骤时,模型可以很好地使用终端和文件。他们搜索、编写脚本、检查输出、将中间状态保留在对话之外,并返回重要的结果。

我们希望产品智能体具有相同的形状。我们考虑过自定义 Python 和 JavaScript 沙箱,以及专用的暂存工具,但这两种工具都不像我们每天在智能体编码中使用的工具那样自然。

当 Vercel 团队发布 just-bash 时,它在产品运行时中提供了该形状:带有虚拟文件系统的类似 TypeScript bash 的解释器,在与服务器相同的 Node 环境中运行,而无需每次运行都启动 Docker 容器。我们想立即尝试一下。

slack message

看到j​​ust-bash后的第一反应:用bash运行时重建审计智能体。

在安全部门批准库之后,我们将一个 Brex 审计智能体迁移到该运行时。P90 令牌使用量从每次执行接近 300 万令牌的高峰降至大约 60 万到 70 万,而 P95 执行时间减少了约一半。

Token trace

在将一个 Brex 审计智能体移向 just-bash 之前和之后的生产令牌追踪。运行时更改后尾部变平。

制作信号很强,但归因不明确。提示、工作流程设计和运行时形状一起发生了变化。因此,我们构建了一个简化的审计基准来隔离运行时问题。

基准

每个基准运行都是一周的综合支出,其中包含我们在生产中关心的相同成分:公司支付的费用、报销、收据文本、用户上下文、先前案例、附近支出、日历证据、网络搜索和约 1,500 字的支出政策。

我们在三个尺度上运行它:

batch size

该基准测试以 10、100 和 1000 项费用运行相同的支出审核任务,以将简单的工具使用与长时间运行的侦探工作分开。

每个尺寸都在 Haiku、Sonnet 和 Opus 上运行,每个尺寸/模型/运行时单元有 20 次运行。每个运行时都有相同的产品操作:get_expenses、analyze_receipt、get_users、get_cases、analyze_calendar_events、web_search、submit_review。完整的设置位于存储库中。

四种运行时形状是:

  • 原生工具
  • 具有对话压缩功能的本机工具
  • 只是重击
  • 完整的 Docker 容器

产品动作保持不变。智能体通过不同的界面接触到他们。

大规模发生了什么

支出审查运行可能会结束,但仍然是错误的。它可能会标记错误的员工,错过重复的报销,或者在证据不足的情况下立案。我们根据生成的参考集测量质量:

  • 精确:当智能体创建案例时,它是否指向正确的费用?
  • 回想一下:智能体是否找到了它应该找到的费用?
  • F1:精确度和召回率的综合得分。

P70 意味着 70% 的得分得分等于或低于该数字。 P95 表示 95% 等于或低于该值。在费用为 1,000 时,该表将已完成的运行与有效评论分开,因为这些运行在某些运行时开始出现分歧。

费用为 10 时,质量如下:

quality 10

在小规模下,每个运行时都有效。运行时问题很容易被忽视。

费用为 100 时,质量如下:

quality at 100

在中等规模下,结果好坏参半。所有运行时仍然完整,并且每个单元运行 20 次,这太小了,不足以声称存在显着的接口差异。有用的读物​​是,运行时问题已经开始出现,但模型和运行间差异仍然占主导地位。

费用为 1,000 时,质量如下:

quality at 1000

在费用为 1,000 的情况下,召回率是值得关注的结果。 just-bash 和完整的 Docker 容器始终发现更多的预期支出。本机工具的运行通常更具选择性,但它们错过了更多批次。

在财务审查中,低精度会带来清理工作。召回率低就会败诉。

可以通过合并重复项和抑制弱候选者的后续步骤来提高精度。回忆更难恢复。如果第一遍从未发现重复报销或直接违反政策的情况,则后面的精确步骤永远不会发现它。

工作台形状的运行时有助于第一遍检查批次的更多部分并保留所需的证据。一旦出现合适的候选人,系统就可以对其进行优化。

费用图片

10 项费用的运行时间成本:

cost 10 expenses

对于小任务,本机工具保持精简。在有足够的调查工作来摊销之前,工作台就会产生开销。

100 项费用的运行时间成本:

cost 100

对于中等规模,成本情况好坏参半。本机工具在许多单元中仍然使用较少的令牌,而工作台变体开始在某些模型上购买较低的挂钟时间。

费用为 1,000 时,成本变成了可靠性和尾部问题:

cost 1000

成本结果并不是“bash 总是使用更少的令牌”。在 10 和 100 的费用下,原生工具通常更便宜,因为没有太多中间工作需要摊销。

在 1,000 时,本机工具形状变得不太稳定。 Haiku 和 Sonnet 原始工具仍然存在上下文溢出故障。压缩减少了一些令牌尾部,但仍然没有缩小质量差距。在生产线束中,这种差距通常会在重试时出现。

单个完整的工具运行看起来比工作台运行更便宜。如果第一次未达到质量标准并且必须再次运行,则端到端系统的成本仍然会更高。

工作台变体支付了本地状态和内存的费用,但它们完成了大批量工作并发现了更多的预期支出。 Docker 也完成了,但有用的部分是相同的壳形工作区。对于此工作负载,just-bash 通过毫秒启动而不是容器生命周期在 Node 内获得了该形状。

Bash 是粘合剂

Bash 之所以有效,是因为它为智能体提供了一种小型语言,用于编写工具、文件、过滤器、脚本和提交验证。

bash 版本仍然使用相同的产品功能**:get_expenses、analyze_receipt、get_users、get_cases、analyze_calendar_events、web_search、** 和 submit_review。它们作为工作台内的命令公开。

产品团队获得了更好的设计循环。您不必为每种可能的场景构建专门的工具,而是公开一小组域命令并让智能体组合它们。这与 Unix 工具仍然有效的原因相同:小程序、文本流、管道和文件。

智能体通常需要从较小的角度来看待广泛的结果:

snippet 1

该管道可防止将全部费用有效负载转储到模型上下文中。文件也出现同样的情况:

snippet 3 lines

智能体可以获取一次、保存结果并运行多个独立查询,而无需付费重新读取对话中的完整有效负载。

它也适用于政策:

snippet 2 lines

没有政策工具调用。系统提示中没有粘贴巨大的策略。智能体可以像人一样检查文件系统。

代码成为上下文过滤器。文件成为记忆。命令成为工具界面。

产品仍然拥有边界:命令清单、帮助文本、JSON 合同、策略、验证器和工作流程。

读取痕迹

当第一个命令存在时,工作不会停止。下一个循环是跟踪驱动的。

当智能体重复编写相同的脚本时,该脚本可能想成为一个命令。当它不断加载相同的指导时,该指导可能属于提示或种子文件系统。当它尝试不存在的标志时,失败的命令是产品接口信号。

当工作流程需要任意本机二进制文件、软件包安装、浏览器自动化或真实机器边界时,请使用 Docker。大多数产品智能体工作都是在已知系统上进行编排。为此,有用的原语更小:一个有界的工作台,智能实体可以在要求模型做出决定之前塑造证据。

涵盖一大类长期运行产品智能体的堆栈是:

  • 用于生产智能体循环的 AI SDK
  • just-bash 用于工作台
  • 用于安全访问公司数据的产品 CLI
  • 验证最终工件的提交工具

如何尝试

基准存储库包含方法、已发布的结果和重新运行说明:

https://github.com/herculesggimenes/bash-sandbox-benchmarks

当工作变得长时间运行时,给智能体一个工作的地方。给它猛击。