你们公司现在有多少个 AI Agent？

五个？十个？还是更多？

如果你说"数不清了"，Ramp 的工程师可能会冲你苦笑。他们去年就是这样，各种 Agent 遍地开花，结果维护成本高到飞起，最后痛定思痛，决定走一条完全不同的路。

Ramp 是美国企业金融领域增长最快的公司，估值 320 亿美元，服务超过 5 万家企业，每年处理的交易金额超过 1000 亿美元。前不久的技术大会上，他们派出了四位工程师分享 AI 落地经验，干货满满，我帮你整理成了这篇文章。

咖啡杯里的秘密

工程师 Nik Koblov 讲了个有意思的故事。

他说，在传统流程里，你买一杯咖啡报销，大约需要 15 分钟的行政时间。写备注、把消费归类到公司的会计科目、找收据、规范化商户名称…… 这些事情单独看都很小，但全公司加起来，就是一笔巨大的隐形成本。

Ramp 做的事情简单说就是：把这些全部交给 Agent 自动处理。从刷卡那一刻开始，到写备注、分类、收据存档，一条龙服务。

这已经是三年前的技术了。那时候他们用 AI 做单步处理，比如自动规范化商户名。随着模型能力变强，效果越来越好。

但 Nik 说，这只是冰山一角。

Ramp 平台上，AP 专员处理发票、财务对账、采购比价、数据团队跑报表…… 每个角色都在做大量手动工作。Nik 提到一个细节：他们以前有个 Slack 频道，有人需要数据就在里面喊，然后有个可怜同事去写 SQL 查询。这个频道大概一年半前被 AI 彻底替代了。

从刷卡到关账，Ramp 试图把所有碎片化的工作都交给 Agent。Nik 说，这正在经历软件行业最激动人心的范式转变。

少即是多：收敛 Agent，扩张技能

这是 Ramp 最核心的架构判断：收敛 Agent，扩张技能。

去年他们让各团队放开手脚实验。结果呢？同步 Agent 有好几套，后台 Agent 也有好几套，对话界面膨胀到五个。维护成本高到离谱，团队苦不堪言。

现在他们把所有对话交互收敛到一个叫 Omnihat 的统一入口。“Omni” 是"无处不在"的意思，正在部署到产品的每个界面。

有意思的是，Omnihat 和传统 UX 并行工作。因为不是所有场景都适合"说话"，有时候表格和按钮反而更高效。

Nik 演示了一个例子：在 Omnihat 里输入"帮我入职一位新员工"，Agent 自动解析员工 ID，通过 HRIS 系统查询组织架构，找到之前创建的"新员工入职手册"工作流，然后问你是否确认执行。

这背后是一个轻量级 Agent 框架，工程师可以快速构建新工具。有个产品经理通过"凭感觉编程"（vibe coding）构建了大约 20 个工具，完全没要工程师帮忙。

统一对话入口、轻量框架、工具层，这就是 Ramp 说的"一个 Agent + 一千种技能"。

对于复杂流程，比如入职包含发卡、设置收据要求、Slack 欢迎、两周后跟进这四步，用户可以用自然语言描述想要的流程，系统把它编译成可执行的工作流，交给 Agent 运行。

从一杯咖啡开始

Policy Agent 是 Ramp 最受欢迎的 Agent 产品之一。

工程师 Viral Patel 展示了一个真实场景：财务团队每天要审核成百上千张收据。他拿出一张收据说，让他肉眼判断这笔钱该批还是拒，他大概率会出错。

但 Policy Agent 做了推理：识别出 8 位客人（Viral 说他自己勉强才看清），确认低于公司每人 80 美元的上限，判断是团队欢迎晚餐，建议批准。另一笔 OpenAI 交易，员工在测试 ChatGPT 功能，判定为合理业务支出，批准。一笔 3 美元的面包店消费被拒，因为既不是加班购买也不在周末。

这些案例背后有个有意思的故事：一家世界 500 强客户找到 Ramp，拿着一长串规则说：“帮我们按这些审批和拒绝。”

Policy Agent 不仅读规则，还和会计、记账等其他 Agent 配合，把决策真正落地。

Ramp 可以走老路，把规则硬编码进产品。但他们选择了另一条路。Viral 引用了 Andrej Karpathy 的话：英语是最热门的编程语言。他们决定让 Agent 直接读懂自然语言的政策文档。

Viral 和同事 Will Koh 强调了一个核心教训：

AI 产品不能一步到位，必须从简单的东西开始。

他们一开始也想大干一场，“自动化整个财务审核”。但真正动手时，选择了最小的切入点：一杯咖啡的报销。这种小额交易风险低，财务团队不在乎。先解决高频、低风险但很烦的场景。

上下文比模型更重要

Ramp 先在内部大量试用自己的产品，用真实交易数据训练和测试 Policy Agent。

他们发现一个关键点：Policy Agent 出错的原因，主要在于给模型的上下文不够，而不是模型本身不行。

一开始他们以为想清楚所有上下文就能搞定，但现实不允许。比如员工的职级和头衔对费用审批影响巨大。C 级高管的消费限额更高，出差可以坐头等舱。这种信息不塞进上下文，Agent 就会判断错误。

于是他们开始从收据提取更多信息，从 HRIS 系统拉取员工资料。每次发现新的上下文维度，加上，再观察效果。

Will 详细介绍了 Policy Agent 架构的三个演进阶段：

第一阶段：简单流水线。 费用进来，检索上下文，通过一系列定义清晰的 LLM 调用判断是否合规、为什么合规、怎么向用户展示，然后输出。

第二阶段：条件分支。 发现每种费用类型差别很大：差旅、餐饮、娱乐各有不同逻辑。于是加入费用分类，根据类型做条件化的提示词和上下文检索，同时给 LLM 工具，让它能自主决定"我需要查航班信息"或"我需要查这位员工的职级"。

第三阶段：完全 Agent 化。 Agent 可以读取平台上所有数据，有一套内部共用的工具箱。它不只是读，还能写：写审批决策、写推理过程、直接替用户批准费用。而且它在循环中工作，可以多次调用工具、收集信息、做判断。

这张 slide 就是 Ramp 的方法论：先做简单流水线，再逐步加条件分支、工具、自主循环。

能力上去了，自主性上去了，但可追溯性和可解释性下降了。小黑盒变大黑盒。你可以看推理 token，但本质上无法控制它会做什么。

黑盒变大，可审计性就变得格外重要。Will 提出了一个原则：就算你知道系统内部怎么运作，也要假设你只能看到输入和输出，然后验证输出是否正确。

用户的操作不是标准答案

刚开始他们以为用户行为就是正确答案：用户批准了，Agent 就应该批准。但实际上，很多用户不了解公司费用政策，有些太信任下属，有些周末审批随手点通过。财务团队事后会说"这笔不应该放行"。

所以 Ramp 必须建立自己的正确性定义。他们的做法是建立跨职能标注流程，用人工标注的数据定义 ground truth。

这带来了两个好处。第一，有了一个可以持续测试的基准答案数据集。第二，所有人对齐了认知。Agent 错了知道错在哪，缺少上下文知道缺什么。减少沟通成本，团队能快速聚焦真正的优先事项。

但每周把人聚在一起标注 100 个数据点，成本很高。大家都有自己的事，有时候没完成"作业"就来开会了。

于是他们想尽办法让标注过程简单。看第三方工具，有的太专用，有的太通用，试不同工具就要好几周。最后决定自己建。

用 Claude Code 和 Streamlit，他们一次性搞定了整个标注工具。最大好处是维护成本低、风险低。放在代码库独立角落，坏了能马上修。部署几乎是秒级的。非工程师也能改，直接 vibe coding 就行。

有了基准数据集，迭代速度大幅提升。发现需要员工职级信息？加进去，跑一遍数据集，看能不能正确捕获新场景。

Will 强调"早做"。不要追求完美，不需要一上来就有 1000 个数据点。从 5 个开始，确保这 5 个绝对不出错，然后不断积累。

几个实操要点：确保任何人都能轻松运行 eval，确保结果一目了然，集成到 CI 让每次合并自动跑。

给 LLM 更多上下文、更多工具，往往带来意想不到的副作用。context rot（上下文过多导致性能下降）、工具说明模糊或矛盾，这类问题只有 eval 才能暴露。

在线评估也有价值。他们有"不确定"的决策类型，意味着 Agent 认为信息不足以做判断。监控这个比率变化，是简单但有效的系统健康度指标。

有了完善的 eval 体系，切换模型变得有底气。新模型发布，跑一遍 eval 就知道该不该切。新模型可能让某些问题变好，也可能让另一些变差。没有 eval，换模型就是在赌。

财务人员的 Claude.md

Policy Agent 上线后，Will 发现了一个有趣的现象：工程师用 Claude Code 时可以修改 Claude.md 控制 Agent 行为。财务人员其实也有同样需求，他们的"Claude.md"就是公司的费用政策文档。

如果 Policy Agent 判断不对，Ramp 的建议是：“去更新你的费用政策文档。“这对财务人员一开始有点吓人。费用政策是正式文件，不是随便能改的。但一旦发现修改后能立即看到效果，态度完全反转。

这种反馈循环很像工程师调 Agent：策略写进文档，修改后立刻看到系统行为变化。

信任的建立是分阶段的。Ramp 先从世界 500 强客户开始推，因为这些企业费用量最大、审批痛苦最深，能最直观感受到价值。一开始只提供"建议”，不做自动操作。

然后客户自己找上来：“20 美元以下的交易你们判断基本都对，我不想再看了，让我自动批准吧。”

于是 Ramp 给客户一个"自主性滑块”，让他们自己决定自动化到什么程度。信任不是产品经理设计出来的，是用户在使用中建立的。

一行配置切换模型

工程师 Ian Tracey 分享了基础设施部分。他说的核心问题是：怎么给 Ramp 自身获得杠杆？不只是给客户，也给内部工程师和跨职能团队。

他们建了一套叫 Applied AI Service 的服务。类似 LiteLLM 这样的统一接口工具，但有三个重要扩展：

第一，统一的结构化输出和跨模型一致性 API/SDK。 不同模型提供商的 API 变化很快，Ramp 不想让下游团队操心这些。想从 GPT-5.3 切到 Opus，或者试试 Gemini 3 Pro，改一行配置就行，马上能跑语义相似性测试或沙箱实验。

第二，成本治理。 模型切换、结构化输出、批量处理、成本治理这些底层麻烦事全收口了。批量文档分析或 eval 怎么选在线还是离线任务，不需要下游团队考虑。这让他们能识别性能和成本的帕累托曲线。

Ian 开了个玩笑：客户可能比他们自己更先用上最新前沿模型。因为新模型发布时，Ramp 内部只需一行配置变更就能影响所有下游 SDK。团队不需要学新 SDK，不需要改十几个调用点。

第三，工具目录。 里面有"获取政策片段"、“查 PDM 费率”、“查最近交易"等工具，由产品团队参与建设。这个目录已有数百个工具，预期增长到数千个。

Ramp 认为 Agent 的上限取决于工具箱和上下文，而不是单纯取决于换哪个模型。

这个目录既能在内部仓库用，也能在核心产品用。如果你想做个"报销 Agent”，从目录选工具组装，就能在 vibe coding 环境下快速原型化。

当月 50% PR 来自 AI

Ian 谈到一个和客户类似的问题：工程师日常工作高度碎片化。即使在用 Claude Code 或 Codex，很多工作散落在 Datadog 日志、生产数据库、告警系统、Jira、Figma、Slack、Notion 里，再加上各团队独有的知识和流程。

2025 年底，他们决定解决这个问题，建了叫 Inspect 的内部编码 Agent。

当月，Inspect 产出了超过 50% 合并到生产环境的 PR。

Ian 展示了一个使用看板。工程团队用量遥遥领先，但产品、设计、风控、法务、企业财务，甚至营销和客户支持团队也在用。他们做文案修改、逻辑修复、响应事故或 Bug。

Inspect 本质是一套可并行调度、可接上下文、可在沙箱运行的后台编码系统。

技术上，每个 Inspect 会话在 Modal 沙箱启动，速度很快。沙箱包含完整开发环境，和工程师本地开发一样。它有一系列任务保持方向，创建 GitHub 分支，集成所有内部上下文：Datadog、只读数据库、各种文档。还内嵌 VS Code 编辑器和远程桌面环境，能跑 Chrome DevTools，做全栈开发。它能访问工具目录，如果 CI 失败，会自己修补后再通知你 PR 准备好了。

启动方式有三种：看板界面、API、或 Slack 线程。从 Slack 启动时，读取完整 Slack 对话上下文，不需要重新描述问题。

这意味着和设计师或 PM 协作时，他们可以在同一个 Inspect 会话里观察和引导 Agent 行为。这成为跨职能协作入口，也帮非工程人员提升了 prompt 技能。

从写代码到判断力

Ian 最后聊到工程文化。他提出了一个思想实验：假设有两种团队。

Team A 关心影响力，能处理模糊问题，理解产品、业务和数据，愿意采纳新工具，找到创造性方案，痴迷用户体验。

Team B 争论该用哪个库，出现混乱加流程，抱怨人手不够，在细节上纠结而不是关注用户体验，在理解问题前就开干，或者执着于主观代码风格。

Ian 引用了哈佛一项研究。分析了 28.5 万家美国公司、6200 万工人的数据（2015-2025 年），发现 AI 工具普及后，初级岗位招聘在六个季度内下降约 7.7%，高级岗位基本不受影响。下降主要由招聘放缓驱动，不是裁员。

但 Ian 认为，这个研究被过度简化成"初级 vs 高级"的年资问题。真正的分界线不是工作年限，而是 Team A 和 Team B 之间的差距。

编码从来不是很多工作中最难的部分。资深工程师拿高薪，更多是因为判断力：上下文理解能力、预见风险能力、过去踩坑积累的"伤疤组织"。让 Opus 4.6 去做一件事，有经验的人能看出来它的方案行不通，或者本身就是个坏主意。

Ian 的核心观点不是"AI 取代谁"，而是高价值工作的门槛正从写代码速度转向判断力。用 AI 编码 Agent，你可能只是更快地做错事，更快地制造更大的烂摊子。

Ian 以乐观判断收尾。他引用了 Ramp 内部一句话：“Jobs not finished”（活儿没干完）。软件永远处于"没完成"状态。当多出来的产能不再被低层级琐事占据，四件事会发生：公司追逐之前负担不起的机会，进入相邻市场为客户拼接更多价值，重建过去成本太高不敢碰的旧系统，提高"够好"的标准。

AI 不只是省时间，它还会把"值得去做"的边界往外推。

FAQ

Q: 为什么 Ramp 选择"一个 Agent + 一千种技能"而不是建多个专业 Agent？

A: 去年让各团队自由实验，结果多套 Agent 实现和多个对话界面造成严重维护负担。收敛到一个 Agent、扩张技能数量，可以降低复杂度，同时保持扩展能力。

Q: Policy Agent 最大的挑战是什么？

A: 不是模型能力，而是给模型的上下文。员工职级、收据细节、商户信息这些上下文维度，需要通过 eval 一点点发现和添加，比单纯换模型更管用。

Q: Ramp Inspect 对非工程师友好吗？

A: 非常友好。产品、设计、法务、营销等团队都在用。它支持从 Slack 启动，读取完整对话上下文，非工程师可以直接参与和引导 Agent 的行为。

顺便分享一个我常用的 AI自媒体运营工具 ，覆盖内容排版、素材处理和效率提效，写公众号会更省力。

最近在玩 Claude Code 的新功能，发现官方出了个 Codex 增强版门户 ，把各种智能编程能力整合在一起了，感兴趣可以去看看。

如果你想看到更多这类工具测评和 AI 编程实战，欢迎关注我的公众号「梦兽编程交个朋友」，每周更新。