Beginner
不要建一千个 Agent：Ramp 如何用一个 Agent 搞定金融自动化
不要建一千个 Agent：Ramp 如何用一个 Agent 搞定金融自动化
Ramp 是美国增长最快的企业金融平台之一，估值 320 亿美元，超过 50,000 家客户，年交易处理量超过 1000 亿美元。在 The Pragmatic Summit 上，Ramp 派出了四人阵容分享他们过去一年在 AI 领域的实战经验：工程执行副总裁（EVP）Nik Koblov、应用 AI 总监 Viral Patel、以及两位资深工程师（Staff Engineer）Will Koh 和 Ian Tracey。
他们聊了五件事：为什么从“建一堆 Agent”转向“一个 Agent + 一千种技能”，Policy Agent 从零到上线的全过程，怎么定义“正确”，怎么建内部 AI 基础设施，以及一个让 50% 以上 PR 都由 AI 生成的内部编码 Agent。
要点速览#
- Ramp 去年让各团队自由实验 Agent，结果产生了四种实现方式和五个对话界面，最终认为应该收敛为“一个 Agent + 一千种技能”的架构
- Policy Agent 最大的错误来源不是模型本身，而是给模型的上下文不够。员工职级、收据细节、商户信息这些上下文比换模型更管用
- 用户的审批行为不能作为“正确”的标准，Ramp 建了跨职能团队每周标注数据来定义自己的基准答案（ground truth）
- Ramp 内部编码 Agent“Inspect”当月产出了超过 50% 的合并 PR，使用者包括产品、设计、法务、营销等非工程团队
- AI 时代工程师的价值不在于写代码的速度，而在于判断力：知道该建什么，以及知道 AI 建的东西哪里不对
一杯咖啡背后的 15 分钟#
Nik Koblov 用一个所有人都能理解的场景开场：一笔咖啡消费。
买一杯咖啡，在传统流程里要花大约 15 分钟的行政时间。写备注，按公司的会计科目分类，找收据、附收据，把商户名称规范化到公司的商户库里。这些事情在公司层面不断累积。
Nik Koblov 用“一杯咖啡”解释企业金融里那些最容易被忽视的手工流程成本。
Ramp 做的事情，最简单的理解方式，就是把这 15 分钟压缩到接近零。从刷卡到写备注到分类到收据，全部由 Agent 自动完成。这是 Ramp 大约三年前就开始做的事，最早是用 AI 做单步处理，比如规范化商户名、自动写备注。随着模型能力提升，效果越来越好。
但这只是起点。Ramp 平台上几乎每个角色都在做大量手动工作：AP 专员（应付账款）处理发票，财务团队对账，采购团队比价，数据团队跑报表。Nik 提到一个细节：Ramp 以前有一个 Slack 频道叫 help-data，有人需要数据就在里面发请求，然后有个可怜人去写 SQL 查询。这个频道大约一年半前被 AI 替代了。
从卡费、采购到关账和分析，Ramp 试图把这些分散在各团队里的碎片工作都交给 Agent。
不要建一千个 Agent#
Nik 说，Ramp 在 AI 方面正在经历软件行业最激动人心的范式转变。这个转变要求彻底重新思考，同时也意味着简化技术栈。
他们学到的教训是：
你不需要建一千个 Agent。你应该把框架收敛为一个 Agent 配一千种技能。 （“You don't need to build a thousand agents. Instead you want to drive your framework towards a single agent with a thousand skills.”）
Ramp 给出的架构判断很直接：收敛 Agent，扩张技能。
去年 Ramp 有意让各个团队自由实验。结果他们发现，公司内部出现了大约四种不同的方式来做同一件事，同步 Agent 和后台 Agent 各有好几套实现。同时，对话界面也膨胀到了五个。
现在 Ramp 把所有对话交互收敛到一个叫 Omnihat 的统一界面。Omni 取“无所不在”之意，正在部署到产品的每个界面上。它和传统 UX 配合使用，因为你不总是想跟软件“说话”，有时候表格和按钮就够了。
Nik 展示了一个例子：在 Omnihat 里输入“请帮我入职一位新员工”，Agent 会自动解析员工 ID，通过 HRIS（人力资源信息系统）工具查询组织架构，然后找到一个之前创建的工作流“新员工入职手册”，问你是否要用这个流程来入职。
这背后是 Ramp 自建的一个轻量级 Agent 框架，提供编排能力和工具。工程师可以很快构建新工具。最近有一位产品经理通过凭感觉编程（vibe coding）构建了大约 20 个工具，完全不需要工程师参与。
统一对话入口、轻量框架和工具层，构成了 Ramp 所说的“一个 Agent + 一千种技能”。
对于复杂流程，比如员工入职包含四个步骤（发卡、设置收据要求、在 Slack 上欢迎、两周后跟进），用户可以在 Ramp 上用自然语言描述想要的流程，系统会把它编译成一个可运行的确定性工作流，然后交给 Agent 执行。
费用政策就是“代码”#
Ramp 的 Policy Agent 是他们最受欢迎的 Agent 产品之一。
Viral Patel 接过话题，先展示了一个实际场景：财务团队每天要审核成百上千张收据。他拿出一张收据说，如果让他肉眼判断这笔交易该批准还是拒绝，他大概率会出错。
但 Policy Agent 对这张收据做了推理：识别出有 8 位客人（Viral 说他自己勉强才看清这个数字），确认低于公司内部每人 80 美元的上限，判断这是一次团队欢迎晚餐，建议批准。另一笔 OpenAI 的交易，某位员工在测试 ChatGPT 功能，Policy Agent 判定为合理业务支出，批准。还有一笔 3 美元的面包店消费被拒绝，因为它不属于加班购买，也不是在周末。
这些案例背后的产品理念来自一个机会：一家世界 500 强客户找到 Ramp，拿着一长串规则说：“帮我们按这些审批和拒绝。”
Policy Agent 不只是读规则，它还要和会计、记账等其他 Agent 配合，把决策真正落到系统里。
Ramp 可以继续走老路，把这些规则硬编码为确定性逻辑，一条条加进产品里。但他们选择了另一个方向。Viral 引用了 Andrej Karpathy 的说法：英语是新的编程语言。他们决定把费用政策文档本身变成规则，让 Agent 直接读懂自然语言的政策文档并据此执行。
【注：Andrej Karpathy 是 OpenAI 联合创始人之一、特斯拉前 AI 负责人。“英语是最热门的新编程语言”是他 2023 年发的推文，后来成为 AI 时代的标志性金句。】
【注：Ramp 官方数据显示，截至 2025 年 10 月，Policy Agent 在超过 100 亿美元的支出中做出了 2600 多万次决策，阻止了 51 万笔违规交易，节省了约 2.9 亿美元。】
AI 产品不能一步到位#
Viral 和 Will Koh 都强调了一个核心教训：
AI 产品不能一步到位。你必须从简单的东西开始。 （“AI products cannot be oneshotted. You need to start with something simple.”）
Viral 认为这是一个文化层面的共识：产品经理、设计师、工程师都必须接受第一天不会完美这个前提。
他们一开始也想大干一场，“让我们自动化整个财务审核”。但真正动手时，他们选择了最小的切入点：一杯咖啡的报销。这些单笔小额交易风险低，财务团队不太在意。
Ramp 把第一步压到最小：先解决一类高频、低风险、但很烦的审批场景。
Ramp 先在内部做了大量 dogfooding（自己试用自己的产品），用公司内部的交易数据来训练和测试 Policy Agent。
一个关键发现改变了他们的思路：
Policy Agent 出错的原因，大多不是模型本身，而是我们给 LLM 的上下文不够。 （“A lot of the reason that policy agent would be wrong would be less on the models themselves and more about the context that we were giving to LLMs.”）
他们可以一开始就坐下来想清楚所有需要的上下文，但他们发现最好的方式是从内部实际数据中学习。比如他们发现，员工的职级和头衔对费用审批影响巨大。C 级高管（CEO、CFO 等）可能有更高的消费限额，出差可以坐头等舱。这种信息如果不放进上下文，Agent 就会做出错误判断。
于是他们开始从收据中提取更多信息，从 HRIS 系统中拉入员工资料。每次发现一个新的上下文维度，就加进去，再观察效果。
从简单流水线到 Agent 自主循环#
Will 详细讲述了 Policy Agent 架构的三个演进阶段。
第一阶段很简单：费用进来，检索相关上下文，通过一系列定义清晰的 LLM 调用判断“是否合规”“为什么合规”“怎么向用户展示合规理由”，然后输出结果。
第二阶段开始有了条件分支。他们发现每种费用类型差别很大：差旅、餐饮、娱乐各有不同的判断逻辑。于是加入了费用分类，根据类型做条件化的提示词和上下文检索，同时给 LLM 一些工具，让它能自主决定“我需要查航班信息”或“我需要查这位员工的职级”。
几轮迭代后，到了第三阶段：完全的 Agent 化工作流。Agent 可以读取 Ramp 平台上的所有数据，有一套公司内部共享的工具箱（不只是 Policy Agent 用，所有 Agent 都能用）。它现在不只是读，还能写：写审批决策，写推理过程，直接替用户批准费用。而且它在一个循环中工作，可以多次调用工具、收集信息、做出判断。
这张 slide 几乎就是 Ramp 的方法论：先做简单流水线，再逐步增加条件分支、工具和自主循环。
Will 坦言，这带来了一个经典的权衡：能力上去了，自主性上去了，但可追溯性和可解释性下降了。一个小黑盒变成了大黑盒。你可以看推理 token，但本质上你无法控制它会做什么。
用户不一定对#
既然黑盒在变大，可审计性就变得格外重要。Will 提出一个原则：即使你知道系统内部怎么运作，也要假设你只能看到输入和输出，然后验证输出是否正确。
但这引出了一个更根本的问题：什么是“正确”？
用户其实经常是错的。 （“Turns out the users are actually incorrect. They're wrong.”）
最初他们以为用户的行为就是标准答案：用户批准了，Agent 就应该批准；用户拒绝了，Agent 就应该拒绝。但实际上，很多用户不了解公司的费用政策，有些太信任下属懒得细看，有些是周末审批随手点了通过。财务团队事后会回来说“这笔不应该放行的”。
所以 Ramp 必须建立自己的正确性定义。他们的做法是每周召集跨职能团队进行数据标注会议，包括工程师、PM、设计师等共同参与。
Ramp 把“用户操作”从答案里拿掉，转而用跨职能标注去定义自己的 ground truth。
这带来了两个好处。第一，他们有了一个可以持续测试的基准答案数据集，确定这些标注是对的。第二，所有人对齐了认知。如果 Agent 错了，大家都知道错在哪；如果 Agent 缺少上下文，大家也清楚缺什么。减少了沟通成本，团队能快速聚焦到真正的优先事项上。
用 Claude Code 一把搞定标注工具#
但每周把一群人叫到一起，让他们标注 100 个数据点，成本很高。Will 说大家都有自己的事，有时候根本没做完“作业”就来开会了。
所以他们想让标注过程尽可能简单。先看了第三方工具，发现有的太专用，有的太通用，光是试不同工具就得花好几周。于是他们决定自己建。
用 Claude Code 和 Streamlit，他们基本上一次性搞定了整个标注工具。 最大的好处是维护成本低，风险也低。它在代码库中一个独立的角落，坏了能马上修。部署几乎是秒级的。非工程师也能去改它，直接 vibe code 就行。
Ramp 没有在标注平台上纠结太久，而是用 Claude Code 和 Streamlit 先把能跑的内部工具做出来。
【注：Streamlit 是一个 Python 开源框架，可以快速构建数据应用的 Web 界面。】
Eval 从 5 个样本开始#
有了基准答案数据集，迭代速度大幅提升。发现需要员工职级信息？加进去，跑一遍数据集，看能不能正确捕获新场景。
Will 说，他觉得 eval 的概念现在大家都知道了，但他想强调的是**“早做”**。不要追求完美，不需要一上来就有 1000 个数据点。他们从 5 个开始，确保这 5 个绝对不会出错，然后不断积累。
几个实操要点：确保任何人都能轻松运行 eval 命令，确保结果一目了然（好的、坏的一眼能分清），把它集成到 CI（持续集成）中让每次代码合并都自动跑。
Ramp 的 eval 体系不是“做大再说”，而是先让团队能反复跑、敢切模型、敢持续加上下文。
给 LLM 更多上下文、更多工具，往往会带来意想不到的副作用。上下文腐化（context rot，上下文过多反而导致模型性能下降）、工具说明写得模糊或矛盾，这些问题不跑 eval 根本发现不了。
在线评估（online eval）也有价值。他们有一个“不确定”的决策类型，意味着 Agent 认为信息不足以做出判断。监控这个比率的变化，就是一个简单但有效的系统健康度指标。
另外，有了完善的 eval 体系，切换模型变得有底气。每当新模型发布，跑一遍 eval 就知道该不该切。新模型可能让某些问题变好，但也可能让另一些变差。没有 eval，你根本不敢动。
让用户修改自己的“Claude.md”#
Policy Agent 上线后，Will 分享了一个发现：工程师用 Claude Code 时可以修改 Claude.md 文件来控制 Agent 行为，财务人员其实也有同样的需求，只是他们的“Claude.md”是公司的费用政策文档。
【注：Claude.md 是 Claude Code 的项目配置文件，开发者可以在其中写下项目约定和偏好来引导 AI 的行为。】
如果 Policy Agent 的决策不对，Ramp 的建议是：“去更新你的费用政策文档。”这对财务人员来说一开始有点吓人。费用政策是正式文件，不是随便能改的，改动要走审批流程。
但一旦他们发现修改后能立即看到效果，态度完全反转。这种即时反馈循环让他们兴奋起来。
Ramp 的产品反馈循环很像工程师调 Agent：策略写进文档，修改后立刻看到系统行为变化。
信任的建立是分阶段的。Ramp 先从世界 500 强大客户开始推，因为这些企业费用量最大，审批痛苦最深，能最直观地感受到产品价值。一开始只提供“建议”，不做任何自动操作。
然后客户自己找上来说：“20 美元以下的交易，你们判断基本都对，我不想再看了，让我直接自动批准吧。”
于是 Ramp 给了他们一个**“自主性滑块”**，让客户自己决定自动化到什么程度。信任不是产品经理设计出来的，是用户在使用中自己建立的。
Will 做了一个类比：就像 LLM 能通过测试代码来获得反馈循环并迭代改进一样，用户在产品内也需要同样的反馈循环。给他们修改政策文档、调整 Agent 行为的工具，他们会比你预期的更主动、更投入。
让模型切换只需改一行配置#
Ian Tracey 接手基础设施部分。他说 Ramp 在思考的一个核心问题是：怎么给 Ramp 自身获得杠杆？不只是给客户，也给内部的工程师和跨职能团队。
Ramp 内部 AI 的核心是一个叫 Applied AI Service 的服务。从高层看，它像一个 LLM 代理，类似 LiteLLM 这样的统一接口工具，但有三个重要扩展。
【注：LiteLLM 是一个开源工具，让开发者用统一的 API 调用不同的 LLM 提供商（OpenAI、Anthropic、Google 等）。】
第一，统一的结构化输出和跨模型提供商的一致性 API/SDK。 不同模型提供商的 API 变化很快，Ramp 不想让下游产品团队操心这些。如果你想从 GPT-5.3 切到 Opus，或者试试 Gemini 3 Pro，改一行配置就行，马上就能跑语义相似性测试或者沙箱实验。
Applied AI Service 把模型切换、结构化输出、批处理和成本治理这些底层麻烦事全都收口了。
第二，批处理和工作流。 对于批量文档分析或 eval 这类场景，怎么处理速率限制，选在线还是离线任务，这些都不需要下游团队考虑。
第三，跨团队和跨产品的成本追踪。 这让他们能识别性能和成本的帕累托曲线（找到性能和成本的最佳平衡点）：什么模型在什么性价比上是最优的？哪些团队的用法长期来看不可持续？
Ian 提到一个细节：他们内部经常开玩笑说，客户可能用着比他们自己都还没意识到的最新前沿模型。因为当新模型发布时，Ramp 内部只需要一行配置变更就能影响所有下游 SDK。团队不需要学新 SDK，不需要改十几个调用点，改一个地方就能享受最新模型的能力。
在工具层面，Ramp 建了一个内部工具目录。里面有像“获取政策片段”“查 PDM 费率”“查最近交易”这样的工具，由产品团队参与建设，深入理解数据和场景的细微之处。这个目录当前已有数百个工具，预期会增长到数千个。
Ramp 认为 Agent 的上限很大程度取决于工具箱和上下文，而不是单纯取决于换哪个模型。
这个目录的一个巧妙之处在于：它既能在内部仓库中使用，也能在核心产品中使用。如果你有一个“报销 Agent”的新想法，直接从目录里选工具、组装，就能在 vibe coding 环境下快速原型化，不需要从头造轮子。
50% 的 PR 来自 AI#
Ian 接着谈到 Ramp 内部面临的一个和客户类似的问题：工程师的日常工作也高度碎片化。即使你在用 Claude Code 或 Codex，很多工作散落在 Datadog 日志、生产数据库、告警系统、Incident.io、Slack 消息、Notion 文档里，再加上各产品团队独有的知识和流程。
2025 年底，他们决定解决这个问题，建了一个叫 Ramp Inspect 的内部后台编码 Agent。
当月，Ramp Inspect 产出了超过 50% 的合并到生产环境的 PR。 （“Currently this month, Ramp Inspect is responsible for over 50% of PRs that we merge to production.”）
【注：Ramp 在 2026 年 1 月已在 builders.ramp.com 公开了 Inspect 的完整架构蓝图，同时有第三方基于此开发了名为 Open Inspect 的开源实现。此前公开报道的数据是约 30% 的 PR 由 Inspect 生成，本次分享更新为 50%+。】
Ian 展示了一个使用数据看板。工程团队的使用量遥遥领先，但产品、设计、风控、法务、企业财务，甚至营销和客户支持团队也在用。他们做的事包括简单的文案修改、逻辑修复、响应事故或 Bug。
Inspect 不只是“会写代码”，它本质上是一套可并行调度、可接上下文、可在沙箱中运行的后台编码系统。
技术上，每个 Inspect 会话在 Modal 沙箱中启动，速度很快。沙箱包含完整的开发环境，和工程师本地开发一样。它有一系列任务来保持方向，会创建 GitHub 分支，并与所有内部上下文集成：Datadog、只读副本数据库、各种上下文文档。还内嵌了 VS Code 编辑器和远程桌面环境，可以跑 Chrome DevTools，能做全栈开发工作。它能访问 Ramp 的 150,000 多个测试用例，如果 CI 失败，它会自己修补后再通知你 PR 准备好了。
【注：Modal 是一个云端计算平台，让开发者可以按需启动容器化的沙箱环境来运行代码。】
启动方式有三种：看板界面、API、或 Slack 线程。从 Slack 启动时，它会读取完整的 Slack 对话上下文，不需要你重新描述问题。
Ian 特别强调了一个设计选择：
我们把它设计成多人协作优先的。 （“We designed it to be multiplayer first.”）
这意味着当你和设计师或 PM 协作时，他们可以在同一个 Inspect 会话里观察和引导 Agent 的行为。他们能点开链接看到“这里的结果和我预期不一样”，给出反馈。这成为跨职能协作的一个入口，也帮非工程人员提升了 prompt 技能。
用 AI 更快地做错事#
Ian 最后把话题转向了工程文化。他提出了一个思想实验：假设有两种团队。
Team A 关心影响力，能处理模糊问题，理解产品、业务和数据，愿意采纳新工具，能找到创造性方案，痴迷于用户体验。
Team B 争论该用哪个库，出现混乱时加流程，不停抱怨人手不够，在细节上无限纠结而不是关注用户体验（比如“我们该用函数式编程范式吗？”），在理解问题之前就开始建东西（“我们直接 vibe code 这个，兄弟，别担心”），或者执着于主观的代码风格品味。
Ian 引用了一项哈佛研究。这项研究分析了 285,000 家美国公司中 6,200 万工人的数据（2015-2025 年），发现 AI 工具普及后，初级岗位的招聘在六个季度内下降了约 7.7%，而高级岗位基本不受影响。这种下降主要由招聘放缓驱动，而非裁员。
【注：该研究由哈佛大学的 Seyed M. Hosseini 和 Guy Lichtinger 发表，论文题为“Generative AI as Seniority-Biased Technological Change”。】
但 Ian 认为，这项研究被过度简化地解读成了“初级 vs 高级”的年资问题。他觉得真正的分界线不是工作年限，而是 Team A 和 Team B 之间的差距。
编码从来就不是很多工作中最难的部分。资深工程师拿高薪，更多是因为他们的判断力：上下文理解能力、预见风险的能力、过去踩坑积累的“伤疤组织”（scar tissue）。当你让 Opus 4.6 去做一件事，有经验的人能看出来它的方案行不通，或者本身就是个坏主意。
Ian 的核心观点不是“AI 取代谁”，而是高价值工作的门槛正在从写代码速度转向判断力。
用 AI 编码 Agent，你完全可能只是更快地做错事，以及更快地制造更大的烂摊子。 （“You could still build the wrong thing just a lot faster and you can build bigger messes.”）
很多媒体叙事忽略了这一点。他们关注“AI 能写代码了”，但没有看到：搞清楚该建什么、说服持怀疑态度的利益相关者、在信息不完整时做设计决策、在漫长的项目中间地带保持动力，这些能力只会变得更重要。
关于 SaaS 行业和 vibe coding 的讨论也类似。确实，快速搭个原型很容易。但真正穿越从原型到产品市场契合的那段“中间地带”，需要真正优秀的工程师，这一点被讨论得太少了。
软件永远做不完#
Ian 以一个乐观的判断收尾。他承认围绕 AI 有很多悲观叙事，但他认为这是一个令人兴奋的建设时代。
他引用了 Ramp 内部的一句话：“Jobs not finished”（活儿没干完）。软件永远处于“没完成”的状态。当多出来的产能不再被低层级的琐事占据，四件事会发生：公司会追逐之前负担不起的机会，会进入相邻市场为客户拼接更多价值，会重建那些过去成本太高不敢碰的旧系统，会提高“够好”的标准。
Ramp 用这张结尾 slide 把态度说透了：AI 不只是省时间，它还会把“值得去做”的边界往外推。
这不是一个“人人效率翻倍所以裁掉一半人”的故事。一家做金融运营软件的公司去建内部编码 Agent，以前可能觉得疯了，现在完全说得通。
Ramp 的四位工程师在 36 分钟里给出了一个清晰的图景：AI 在企业级金融产品中的落地，不是一个模型能力问题，而是一个上下文工程问题、一个正确性定义问题、一个信任建设问题，以及一个工程文化问题。 模型越来越强，但知道该用模型做什么，以及知道模型做得对不对，才是真正稀缺的能力。
几个值得关注的信号：Ramp Inspect 的 PR 占比从 30% 跃升到 50%+，这个趋势还会继续吗？当越来越多非工程师用编码 Agent 提交代码，质量把控怎么做？当 Policy Agent 越来越自主，“自主性滑块”最终会滑到什么位置？