原始标题: Brex’s AI Hail Mary — With CTO James Reggio

发布日期: 2026-01-17 | 来源频道: @latent-space

📝 深度摘要

1. 核心技术主旨 (The TL;DR)

Brex 这家曾经只服务初创公司的企业信用卡公司，正通过一场内部"AI 革命"试图完成自我颠覆。CTO James Reggio 主导的 AI 战略分为三大支柱：Corporate AI（全员工具赋能）、Operational AI（降本增效）、Product AI（产品智能化）。核心打法不是追逐单一模型或框架，而是构建多智能体网络（Multi-Agent Networks）——让一个面向员工的"Executive Assistant"Agent 与多个垂直领域 Agent（报销、差旅、政策、审计）协同工作。这种架构将软件工程的封装模式投射到 Agent 空间，每个 Agent 负责特定业务流程，通过 DM 式多轮对话而非简单的 Tool Call 协作。更有意思的是，Brex 选择不站队：让员工自己选 Cursor、Windsurf、Claude 等工具，用"Usage is Voting"的方式对抗厂商锁定。一句话总结：Brex 不是在用 AI 优化现有流程，而是用 Agent 网络重新定义企业财务工作的边界。

2. 嘉宾背景与当前技术栈 (Guest & Tech Stack)

嘉宾身份： James Reggio，Brex CTO。前身经历横跨 Stripe、Banter、Convoy，是少数从移动端（前端）工程leader 成长为大厂 CTO 的案例。

核心产品/架构： Brex 的业务边界早已从"初创公司信用卡"扩展到企业银行卡、费用管理、差旅、财会等全栈金融产品。其 AI 架构的核心是自研的 LLM Gateway（2023年1月ChatGPT发布后紧急搭建）+ Mastra（主 Agent 框架）+ 自研 Multi-Agent Orchestration 框架。技术栈选型：TypeScript（面向 AI Agent 层，原有后端为 Kotlin/Elixir）、PG Vector + Pinecone（向量检索）、Retool（内部运营工具的 UI 层）。Brex 的 AI 产品现已服务约 40,000 家企业客户，内部的 AI 自动化在過去 18 个月内帮助公司实现 收入增长 5 倍、支出削减 99%。

3. 底层架构与技术深潜 (Hardcore Architecture & Engineering)

a. 系统架构与硬件交互 (Infra & System Design)

Brex 的 AI 基础设施并非一步到位，而是经历了几次关键迭代。第一层是 LLM Gateway（2023年1月内部紧急搭建），实现了 Prompt 版本管理、Model Routing、Data Egress 控制、基础 Observability 和 Cost Monitoring。这套手写的 Gateway 至今仍在支撑大量轻量级 LLM 应用，比如全自动化的客户入驻 pipeline——过去需要人工审核的 Underwriting 和 KYC 流程，如今由一系列 Research Agent 自主完成。

第二层是 Agent 框架的选择。Brex 最初评估了 Langchain，但当时 Langchain 的 Logging/Tracing 能力不足以满足他们的需求，遂自建了一套内部框架。随着时间推移，他们发现 Mastra 的 Ergonomics 与其两年前自研的内部框架高度相似，且生态更成熟，因而采用 Mastra 作为主力的 Agent 开发框架。但还有约一半的应用跑在另一套自研的 Multi-Agent 框架上——这套框架专注于"Agent 与 Agent 之间的多轮对话式协作"（而非单轮 Tool Call），这正是 Brex 与市面上大多数方案的根本差异。

平台层是连接一切的隐形纽带。Brex 用 Retool 构建了面向业务团队的"低代码 AI 开发平台"——包含 Prompt Manager、Tool Manager、Eval Manager，让领域专家（而非纯工程师）可以直接在 UI 上迭代 Prompt、测试新模型。Sierra（Brex 投资的客服对话平台）也被纳入这套体系，作为前端客户支持的 Agent 接口。

b. AI 范式与工作流重构 (AI Paradigms & Workflows)

核心范式转移：从单一大一统 Agent 到多智能体网络（Multi-Agent Network）。 Brex 意识到，让一个 Agent 同时负责费用管理、差旅预订、政策咨询、合同采购等全部功能是不现实的——Context Window 再大也无法良好处理如此宽泛的任务域。他们的方案是：

  • 树状（Tree）而非网状（Graph）的层级结构：顶层的 Brex Assistant（面向每个员工）是对话入口，它背后连接着多个子 Agent（报销 Agent、差旅 Agent、政策 Agent、审计 Agent 等）。每个子 Agent 拥有自己的工具集和职责边界。
  • Agent 间的协作方式是"DM 而非 Tool Call"：传统方案中，子 Agent 被当作 Tool 调用，输入输出都是结构化参数。Brex 改为让主 Agent 与子 Agent 进行多轮自然语言对话，子 Agent 可以回复"我需要更多信息"让主 Agent 向用户追问，也可以与其他子 Agent 交叉协作。
  • 案例：Audit Agent + Review Agent 的双人舞：Audit Agent 极其"激进"，会标记大量潜在的违规行为（比如某员工连续多次在 Receipt 要求阈值 75 美元附近提交 74 美元报销）。随后 Review Agent 会判断这些"案件"是否值得跟进（金额够不够大、用户历史合规性如何），决定是否升级为正式 Case。整个过程是多 Agent 协作的典型场景。

MCP（Model Context Protocol）的定位：在 Brex 的架构中，MCP 和 Tool 更多是"面向传统 imperative 系统的接口"，而不是 AI 空间的 Agent 间通信方式。James 明确指出：Agent-to-Agent 应该是对话式的（chat-back），而非 RPC 式的单次调用。

c. 评估体系与工程阻力 (Evals & Engineering Bottlenecks)

Evals 的构建逻辑：Brex 将 Evals 分为两类。Operational AI 侧（KYC、Underwriting、Fraud Detection 等），Evals 由业务领域专家（Subject Matter Expert）与工程师联合构建，每个错误都会转化为回归测试用例。Product AI 侧（多 Agent 网络）更具挑战性——他们在探索 State-of-the-art 的 Multi-turn Eval 技术：用 Agent 模拟用户执行多轮对话，最后用 LLM Judge 评估结果。有时还会"预埋"对话前置条件（手写前两轮对话）来隔离特定行为进行测试。

最大工程阻力：

  1. 幻觉控制（Hallucination Control）：Assistant Agent 经常"假装"能联系不存在的团队（如"我帮您联系财务团队"），实际什么都没做。这类问题通过 System Prompt 硬约束解决，而非依赖外部 Guardrail 框架。
  2. 代码质量的 Second-order Effects：AI 写代码变得极其容易，但代码审查的压力没有减少。Brex 使用 Ruff 做传统 Linting，CodeRabbit / Graphite 做智能代码审查。James 的观点尖锐：“你不能用更多的 AI 来解决 AI 引入的问题——最终还是得靠人类注意力去覆盖。” 他推动每个工程师"拥有更多代码"（Own More Code），用更少的人做更多的事，但前提是增加人在代码理解上的投入。
  3. Context Rot 与知识管理：大模型对"Brex 是什么"的认知往往是过时的（“Brex 是服务初创公司的信用卡"或"只服务大企业”）。Brex 必须构建自己的Product Knowledge Base来对齐模型认知，这涉及大量产品文档、流程文档、ICP（理想客户画像）的整理和持续更新。

4. 产品哲学与商业化博弈 (Product Philosophy & GTM Strategy)

a. 颠覆性反共识洞察 (Contrarian Hot Takes)

  1. “不选边站队"是对抗厂商锁定的最优解：业界都在纠结"选 GPT-4 还是 Claude？选 Cursor 还是 Windsurf？“Brex 的答案是**“全都要”**。他们为企业购买多套工具的授权，让员工自己投票。续约时，谁的 Usage 高谁就能继续留下。这种"Usage is Voting"的机制不仅降低了被单一供应商绑架的风险，还能在工具快速迭代的当下保持灵活性。

  2. RL（强化学习）在金融决策中是 Over-engineering：Brex 最初曾投入大量资源用 RL 做信用评估和授信额度决策，最终性能远不如一个简单的 Web Research Agent。James 的结论是：金融机构的合规要求决定了决策过程必须可审计、可追溯，而 RL 的"不可解释性"与这一需求天然冲突。“把问题拆解到 SOP 级别，让 LLM 执行 SOP"比试图让模型自己学会决策更可靠。

  3. “不要试图用 DAG / Workflow 把 LLM 框死”：James 明确表示，将 LLM 强制嵌入 deterministic workflows 或 DAG 是在"低估模型的规划与执行能力”。他认为行业应该更激进地拥抱 Agent-to-Agent 的交互模式，让模型有更大的自由度去规划路径，而非预先设计好每一步。

b. 商业模式与成本经济学 (Business Model & Unit Economics)

Brex 的 AI 战略本质上是一场Unit Economics 重构。过去服务中小企业（SMB）的 ROI 为负——人工审核 Underwriting、KYC、Disputes 的成本太高。AI 自动化后：

  • 80% 的初创公司和商业企业申请可以在 60 秒内完成"零接触”（Touchless）审批——这直接改变了 Brex 的获客边界，从"只服务高成长科技公司"扩展到"年收入 100 万美元以上"的商业客户（律所、牙科诊所等）。
  • Operational AI 的边际成本趋近于零：一个处理 Fraud Detection、Dispute Automation、Underwriting 的 Agent，一经部署即可服务数万客户，Token 成本 vs. 人工成本的优势是数量级的。
  • “不追求 Headcount 增长"作为 CTO 成绩单：James 明确表示，担任 CTO 以来 Engineering 团队规模零增长，但业务量翻了数倍。“300 个工程师，未来一年后还是 300 人，但效率提升 30-50%。” 这是 AI 带来的真正价值——不是裁员，而是让同样的人做更多高价值的事。

5. 极客文化、组织构建与野史 (Hacker Culture, Team & Lore)

a. 人才密度与招聘哲学 (Talent & Hiring)

“反直觉"的团队构成：Brex AI 团队（约 10 人）采用 “20岁 AI Native + Staff Engineer” 的配对模式。年轻工程师不懂"历史包袱”，敢于用 AI-First 的方式解决问题；而 Staff Engineer 熟悉代码库和产品Know-How，两者互补。James 甚至直言：“有时候，太多经验反而是障碍——你会用老方法去套新问题，而不是从零思考 AI 该怎么解决。”

“Quitters Welcome"文化：Brex 公开倡导**“前创始人优先”**的招聘策略。他们认为，经历过从零到一的人会带来"创始人心态”（Ownership、Agency），即使这些人可能在 1-2 年后离开去创业，Brex 也愿意"培养"他们。James 本人就是例子——他在接到 CTO Offer 时甚至在考虑"要不要自己出去做一家公司”。

面试流程 AI 化：Brex 将面试题从"算法题 + 系统设计"改为**“Agentic Coding Project”——候选人需要用 AI 工具在限定时间内完成一个小型项目，所有工程师（包括 Manager）都必须经历这轮面试。James 说：“看到 Infra 团队的 Engineering Manager 是 Cursor 最大用户时，我知道文化已经到位了。”**

b. 硬核极客日常与轶事 (Geek Lore & Quirks)

  • Friday Demos @ 1:20 AM：AI 团队有个传统，周五凌晨 1:20 集体 Demo 最近一周的进展。照片发在 Pedro（CEO）的 Twitter 上，成为 Brex"内部创业"文化的象征。
  • “不写文档的 Gen Z”：James 在与大一届的大学新生交流时惊讶地发现，最流行的用法不是让 AI 写代码，而是让 AI 协助写 Design Doc / Architecture 文档——“Rubber Duck Co-architect"模式反而比直接生成代码更受欢迎。
  • Cursor 的头号粉丝是 Engineering Manager：这不是一线工程师，而是管理者。这印证了 Brex"Operate at All Levels"的核心价值观——领导也要亲自写代码。

6. 未来推演与终局思考 (Future Outlook & Endgame)

a 短期技术前瞻 (Next 12-18 Months)

  • Multi-turn Eval 将成为行业标配：随着 Agent 系统复杂度提升，单轮测试已不够。Brex 认为"让 Agent 模拟用户进行多轮对话 + LLM Judge 评分"会是标准做法。
  • “模型饱和度追踪"会火：James 提到一家叫 Various AI 的公司做User Simulation，核心思路是：用户今天还不需要某个功能，但企业想知道"未来何时需要”。通过持续运行"失败中"的 Evals（始终标记为 FAIL 但持续监控），可以量化模型的能力饱和曲线。
  • “AI Fluency"能力分级会进入每家公司的 L&D 体系：Brex 的"User → Advocate → Builder → Native"四级框架已经在内部运营团队推行，接下来会扩散到全公司。

b. 长期演进形态 (The Endgame)

  • “Brex 完全消失”：James 的终极愿景是 “The Best UI for Brex is No UI”——员工只需要刷信用卡，所有软件交互（报销、预订、合规审查）都由 AI Agent 在后台完成。对用户而言，Brex 从一个"SaaS 产品"退行为"隐形的基础设施”。
  • Agent Network 的终局是"去中心化的组织模拟”：每个员工有一个 Personal EA，每个财务职能（AP/AR/Audit/Policy）有一个垂直 Agent。“未来的企业不是人与人之间的协作，而是 Agent 与 Agent 的协作网络。”
  • AI 不会让 Engineering 消失，但会让"不会用 AI 的工程师"消失：James 的判断是，“会用 AI 放大自己能力的工程师会变得极其高效，不会用的会被自然淘汰——这不是’裁员’，而是自然选择。”

7. 原汁原味金句 (Based Quotes)

“We actually paused and asked ourselves: what would a company that was founded today to disrupt Brex look like? And then we tried to use that answer to form this team internally.” “我们停下来问自己：如果今天有人要创办一家公司来颠覆 Brex，它会是什么样子？然后我们用这个答案来组建内部团队。”

“We wanted to build like that EA connected to the same data sources and see if we couldn’t simulate that behavior so that, you know, you basically, your interface to Brex is SMS in the card.” “我们想构建一个连接到相同数据源的执行助理，模拟这种行为——换句话说，你和 Brex 的交互界面就是卡背后的那条短信。”

“You can’t fight AI with more AI. You can’t just throw an AI reviewer on their AI code and you solved it. So you do need to scale human attention.” “你不能用更多的 AI 来解决 AI 引入的问题。你不能扔一个 AI 审阅者去审查 AI 写的代码就完事了。所以归根结底，你还是得放大人类注意力的投入。”

“Trying to craft LLMs into deterministic workflows and DAGs is kind of underselling the power that they have to actually plan and execute more in a more sophisticated fluid way.” “试图把 LLM 塞进确定性的 Workflow 和 DAG 里，本质上是在低估它们真正规划与执行的能力——低估了它们可以多灵活、多复杂地解决问题。”

“The best UI, UX for Brex is just the card. Every single thing that you have to do in the software beyond just swiping the card is an opportunity for AI to eliminate some work for you.” “对 Brex 来说，最好的 UI/UX 就是那张卡。所有你在软件上除了刷卡之外还要做的每一件事，都是 AI 帮你消灭工作的机会。”

📺 播客地址

播客时长: 74分钟