不要建一千个 Agent：Ramp 如何用一个 Agent 搞定金融自动化

不要建一千个 Agent：Ramp 如何用一个 Agent 搞定金融自动化 不要建一千个 Agent：Ramp 如何用一个 Agent 搞定金融自动化 Modified March 16 No access ff4d2232819f4d49af1d1a0ee71c753e 00:00 在线评估（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 的建议是：“去更新你的费用政策文档。”这对财务人员来说一开始有点吓人。费用政策是正式文件，不是随便能改的，改动要走审批流程。 但一旦他们发现修改后能立即看到效果，态度完全反转。这种 即时反馈循环 让他们兴奋起来。 1 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，改一行配置就行，马上就能跑语义相似性测试或者沙箱实验。 2 Applied AI Service 把模型切换、结构化输出、批处理和成本治理这些底层麻烦事全都收口了。 第二，批处理和工作流。 对于批量文档分析或 eval 这类场景，怎么处理速率限制，选在线还是离线任务，这些都不需要下游团队考虑。 第三，跨团队和跨产品的成本追踪。 这让他们能识别性能和成本的帕累托曲线（找到性能和成本的最佳平衡点）：什么模型在什么性价比上是最优的？哪些团队的用法长期来看不可持续？ Ian 提到一个细节：他们内部经常开玩笑说，客户可能用着比他们自己都还没意识到的最新前沿模型。因为当新模型发布时，Ramp 内部只需要一行配置变更就能影响所有下游 SDK。团队不需要学新 SDK，不需要改十几个调用点，改一个地方就能享受最新模型的能力。 在工具层面，Ramp 建了一个 内部工具目录 。里面有像“获取政策片段”“查 PDM 费率”“查最近交易”这样的工具，由产品团队参与建设，深入理解数据和场景的细微之处。这个目录当前已有数百个工具，预期会增长到数千个。 3 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。 4 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 去做一件事，有经验的人能看出来它的方案行不通，或者本身就是个坏主意。 5 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”（活儿没干完）。软件永远处于“没完成”的状态。当多出来的产能不再被低层级的琐事占据，四件事会发生：公司会追逐之前负担不起的机会，会进入相邻市场为客户拼接更多价值，会重建那些过去成本太高不敢碰的旧系统，会提高“够好”的标准。 builders.ramp.com No access ff4d2232819f4d49af1d1a0ee71c753e 00:00 No access ff4d2232819f4d49af1d1a0ee71c753e 00:00 在线评估（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 的建议是：“去更新你的费用政策文档。”这对财务人员来说一开始有点吓人。费用政策是正式文件，不是随便能改的，改动要走审批流程。 但一旦他们发现修改后能立即看到效果，态度完全反转。这种 即时反馈循环 让他们兴奋起来。 1 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，改一行配置就行，马上就能跑语义相似性测试或者沙箱实验。 2 Applied AI Service 把模型切换、结构化输出、批处理和成本治理这些底层麻烦事全都收口了。 第二，批处理和工作流。 对于批量文档分析或 eval 这类场景，怎么处理速率限制，选在线还是离线任务，这些都不需要下游团队考虑。 第三，跨团队和跨产品的成本追踪。 这让他们能识别性能和成本的帕累托曲线（找到性能和成本的最佳平衡点）：什么模型在什么性价比上是最优的？哪些团队的用法长期来看不可持续？ Ian 提到一个细节：他们内部经常开玩笑说，客户可能用着比他们自己都还没意识到的最新前沿模型。因为当新模型发布时，Ramp 内部只需要一行配置变更就能影响所有下游 SDK。团队不需要学新 SDK，不需要改十几个调用点，改一个地方就能享受最新模型的能力。 在工具层面，Ramp 建了一个 内部工具目录 。里面有像“获取政策片段”“查 PDM 费率”“查最近交易”这样的工具，由产品团队参与建设，深入理解数据和场景的细微之处。这个目录当前已有数百个工具，预期会增长到数千个。 3 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%+。】 builders.ramp.com Ian 展示了一个使用数据看板。工程团队的使用量遥遥领先，但产品、设计、风控、法务、企业财务，甚至营销和客户支持团队也在用。他们做的事包括简单的文案修改、逻辑修复、响应事故或 Bug。 4 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 去做一件事，有经验的人能看出来它的方案行不通，或者本身就是个坏主意。 5 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”（活儿没干完）。软件永远处于“没完成”的状态。当多出来的产能不再被低层级的琐事占据，四件事会发生：公司会追逐之前负担不起的机会，会进入相邻市场为客户拼接更多价值，会重建那些过去成本太高不敢碰的旧系统，会提高“够好”的标准。 6 Ramp 用这张结尾 slide 把态度说透了：AI 不只是省时间，它还会把“值得去做”的边界往外推。 这不是一个“人人效率翻倍所以裁掉一半人”的故事。一家做金融运营软件的公司去建内部编码 Agent，以前可能觉得疯了，现在完全说得通。 Ramp 的四位工程师在 36 分钟里给出了一个清晰的图景： AI 在企业级金融产品中的落地，不是一个模型能力问题，而是一个上下文工程问题、一个正确性定义问题、一个信任建设问题，以及一个工程文化问题。 模型越来越强，但知道该用模型做什么，以及知道模型做得对不对，才是真正稀缺的能力。 几个值得关注的信号：Ramp Inspect 的 PR 占比从 30% 跃升到 50%+，这个趋势还会继续吗？当越来越多非工程师用编码 Agent 提交代码，质量把控怎么做？当 Policy Agent 越来越自主，“自主性滑块”最终会滑到什么位置？ 完整访谈视频：https://www.youtube.com/watch?v=NMs8C2 3M0w 🔗 原文链接： https://mp.weixin.qq.com/s/zABBY8WO... https://mp.weixin.qq.com/s/zABBY8WO... 原创 宝玉 宝玉 宝玉AI2026年3月16日 14:45 美国 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。 原始视频链接：https://www.youtube.com/watch?v=NMs8C2 3M0w 1. Ramp 去年让各团队自由实验 Agent，结果产生了 四种实现方式和五个对话界面 ，最终认为应该收敛为“一个 Agent + 一千种技能”的架构 2. Policy Agent 最大的错误来源不是模型本身，而是给模型的上下文不够 。员工职级、收据细节、商户信息这些上下文比换模型更管用 3. 用户的审批行为不能作为“正确”的标准，Ramp 建了 跨职能团队每周标注数据 来定义自己的基准答案（ground truth） 4. Ramp 内部编码 Agent“Inspect”当月产出了 超过 50% 的合并 PR ，使用者包括产品、设计、法务、营销等非工程团队 5. 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 强