Ramp 如何给 AI 智能体开放权限，同时保持控制

Ramp 首席技术官 Rahul Sengottuvelu 说，他让 Claude Fable 处理公司大型 Python 应用中的循环导入和延迟加载问题。模型取得了进展，其中许多代码已经合并。他希望了解模型会在哪些地方失败，以便团队在后续版本发布时重新尝试这些问题。

Sengottuvelu 早期对 Fable 的一项测试特意设计成可衡量的：他选择了产品本身之外、测试套件中的一大段代码，并用大量数据检查其行为。他说，生成的实现以影子模式运行了数周，速度始终快于现有版本。

Anthropic 的 Boris Cherny 说，他会给每个新模型一组测试，Fable 是第一个全部完成的模型。遇到困难时，他使用了由 Claude 编排子智能体的动态工作流。在他自己的 CI 例子中，智能体反复分析和优化系统，他估计中位耗时从 18 分钟降到了 6 分钟。

Cherny 说，工作流先合并代码，等待一天获取生产数据，然后回来重复这一过程，逐步积累改进。Ramp 工程师 Austin Ray 问，当许多后台智能体在视线之外工作时，他如何信任如此大的工作量。Cherny 将这种工作流比作在测试时给模型更多计算资源。

被问及循环与动态工作流的区别时，Cherny 说，循环适合重复工作，例如跟踪拉取请求、修复 CI 和重新变基。动态工作流适合系统优化等开放式任务，因为下一步事先并不确定。Ray 说，使用这些工具意味着要把更多工程工作交给智能体。

Cherny 将循环描述为从许多工程师的工作中横向切出反复出现的一项任务，例如代码审查或每日清理死代码。作为更端到端的例子，他说 Claude Tag 可以启动实验、稍后检查、扩大实验覆盖范围，并最终准备拉取请求以发布某个版本；他批准了最初的拉取请求。

Ray 介绍了自己相对简单的 Claude Code 配置：多个终端窗格、很少的插件或工具，以及简单的 CLAUDE.md。他使用子智能体和对抗式审查，认为简洁配置有助于了解模型的能力。Sengottuvelu 则把更多工作移到后台，常用来收集服务运行情况或项目瓶颈的信息。

Sengottuvelu 说，当公司拥有许多服务、数据库和队列时，同时运行多个本地开发实例很快会成为限制。根据他的经验，较新的模型需要较少的手把手指导，因此他越来越多地把会话移到后台；需要仔细调试或访问本机上下文时，本地会话仍然有用。

Sengottuvelu 说，Ramp 已在工程生命周期的许多环节使用智能体：提出想法和发现问题、注意日志中的异常、编写和审查代码，以及监控部署后的修改。公司也考虑了查找漏洞和其他问题等安全用途。

Sengottuvelu 说，随着模型进步，Ramp 经常移除为早期能力搭建的配套结构。团队试图通过提供工具、上下文和自主权限，为未来的模型做设计，让它能更像同事一样处理请求。他也承认，当前产品今天就必须正常运行。

Ray 将此称为一场关于速度的赌注：为弥补当前模型限制而设计的基础设施可能很快变成技术债务。把目标放得更远，或许能让团队用现有资源取得更多进展，尽管团队必须决定在哪里下注。

Cherny 问，随着系统规模扩大，Ramp 如何控制数据访问、成本和代码质量。Sengottuvelu 说，团队研究具体执行轨迹，而不只是看汇总基准：本应运行什么命令，智能体是否缺少上下文或合适工具？分层防护让公司可以限制访问，同时赋予智能体更多自主权。

目标是只给模型所需的权限，例如在适当情况下使用只读凭据。Sengottuvelu 希望同事说明需要的结果——修复漏洞或实现功能——而不是规定每一步。团队围绕成功完成任务应走的路径，用提示词、工具和技能来塑造智能体的行为。

Ray 补充说，硬性控制和最小权限可以从根本上阻止某些操作。Sengottuvelu 说，Ramp 的安全团队构建了基础设施，帮助配置网络访问策略和凭据，也亲自使用这些智能体。这项工作与负责安全的人员密切相关。

Sengottuvelu 说，Ramp 寻找这类场景：即使修改有缺陷，最坏后果也受到严格限制，同时潜在收益清晰可见。公司正在为更大的产出准备测试和部署验证流程。Ray 补充说，随着模型不再犯某些类型的错误，审查者的关注重点也应随之改变。

Ramp 还在后台智能体 API Inspect 上构建了代码审查机器人。Sengottuvelu 说，一些团队会编写技能文件，记录希望机器人检查的特定问题和积累的知识，让审查实践可以重复使用。

被问到如何让工程师有能力消除瓶颈时，Sengottuvelu 指出，公司文化允许实验失败。他说，Ramp 为工程师提供工具访问权限，不设置个人 token 或工具预算，这也让同事之间更容易形成共同理解。

Ray 说，Glass 是非技术员工与编码智能体交互的入口，他们无需查看代码或技术细节。Sengottuvelu 将 Inspect 描述为后台同事：它可以访问 GitHub、Linear、Slack、Datadog 和 Sentry 等工具，调查工单、错误和其他工程任务。

Ray 说，人们可以从网页启动 Inspect，也可以在 Slack 对话中提及它。同事看到有人在讨论中请它帮忙，便发现自己也可以这样做。Sengottuvelu 说，每个拉取请求都会在一段时间内配有虚拟机，方便人们通过链接接手会话或协作。

Ramp 仍在努力为 Inspect 提供所需的仓库、依赖和工具，让人们可以更长时间在后台工作，而不必回到本地开发。团队持续询问智能体本应做什么，并围绕这一正确路径调整工具和上下文。

Ray 介绍了一个始终运行在 Claude Code 上的值班助手。Ramp 先在本地开发技能、工具和提示词，再把助手连同防护措施打包进容器。他说，助手会处理分配给工程师的事件，包括客户支持工单和系统事件，并把根因分析发回事件对应的 Slack 频道，供响应人员使用。

Cherny 将 Inspect 与 Anthropic 的 Claude Tag 比较：后者也在 Slack 中工作，并接手了此前由专用机器人处理的任务。Sengottuvelu 说，如今由自动化触发的 Inspect 会话比人工启动的更多；定时任务和外部系统会触发会话，并可通知频道或个人。

Sengottuvelu 说，这些自动化的组织方式比较分散。一个团队维护 Inspect 等共享基础，其他团队则可以在其上构建自己需要的功能。Ray 说，平台团队会关注反复出现的需求或平行开发的工作，把它们做成更可靠的共享工具，同时预测未来模型的能力。

Sengottuvelu 说，Ramp 不设置个人 token 或美元用量上限，但会采用考虑成本的默认设置、批处理和灵活 API，并为无人控制的自动化使用较便宜的模型。团队预计会持续采用更新的模型，也尽量不让功能依赖某个模型的特定行为。

Ray 说，团队也会与用量突然上升的人交谈。如果某个实验能让其他人受益，他们会帮助将其转化为共享能力；如果支出是意外产生的，他们会帮助纠正。等团队确认实验值得扩大后，再优化成本。

Sengottuvelu 认为，如果每花 1 美元购买 token 能创造超过 1 美元的价值，那么降低成本不一定是目标。他预计，达到同等智能水平的价格会随时间下降，并希望 Ramp 员工熟练运用这些能力解决困难问题。

他对其他技术领导者的建议是关注模型进步的速度，而不只是当前能力。他说，Ramp 尝试为三至六个月后可能实现的能力做准备，因为只围绕今天限制设计的系统，等到发布时可能已经落后。