开发者Matt推出Airlock,用策略即代码管理AI编程代理集群
来源标题:Show HN: Airlock – Policy-as-code for fleets of AI coding agents
开发者Matt正在构建Airlock,一个用于管理自主工程代理集群的开放标准,目前项目仅有3至4周。其配置标准旨在开源,schema和可复用的GitHub Actions已公开,每个代理运行通过GitHub OIDC令牌验证身份并换取仅一小时有效的GitHub令牌。Matt正就项目方向和企业管理AI的痛点征求反馈。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
我叫 Matt,正在开发 Airlock。Airlock 的目标是成为一套管理自主工程 agent 集群的开放标准。我希望大家能就这个项目的方向提出建设性反馈,也想了解在大型企业里管理 AI 使用的主要痛点是什么。目前我自己就在用这套框架运营公司,四个大型项目里一共跑着 23 条工作流。Airlock 还非常早期,只有 3-4 周大。Airlock 的配置标准会开源,等我对目前做出来的东西更有信心、也更经得起公开审视之后,我也会把 backplane 开源。现在 schema 本身和可复用的 GitHub actions 已经公开了。我私心当然会想办法找到变现方式,但我理想中的客户是大型企业。Airlock 做的事挺多,如果要用几条要点概括,大概是:1) 让 agent 的行为和生命周期可以在版本控制下配置。每次 agent 运行都用 GitHub 的 OIDC token 证明自己的身份,Airlock 用它换一个有效期一小时、且只能访问该 agent 角色文件中所列仓库和权限的 GitHub token。2) 可以配置自主级别,从仓库的基础自主级别开始,到代码库中单个文件,都可以有更严格的覆盖设置。(比如整个仓库你都信任 agent,但可能想对 billing 或 auth 模块额外加一道关卡。)3) 支持一套标准的自主级别量表。4 级时 agent 主导项目方向,1 级时 agent 依赖人类来主导项目方向。4) 开箱即用提供一个 OTEL collector,存储审计时你会关心的那部分 agent 操作。我正在探索如何存储 agent prompt 和用户 prompt,使得只有客户能解密,但还没决定具体怎么做。5) 自带 shadow 模式,让你可以运行 Airlock 观察它在你的组织中会如何表现,而不真正启用它。想试用的话,只需安装 GitHub App,创建一个 policy 仓库,然后在 GitHub 托管的 runner 上运行即可。我个人用的是 EC2 spot 实例上的自托管 runner。访问 https://airlock.lunareng.com/docs/quickstart 开始使用。我最近非常热衷于探索[近]未来的企业将如何用 agent 大规模有效地管理自主开发。我想帮助回答这个问题:企业如何更好地管理 AI 支出、token 使用的优先级、agent 操作的可审计性,以及符合各类治理、风险和合规框架。我的视角来自 15 年以上的工程师经历,但我也设法对大型企业如何运作建立了不错的理解。我设想的未来是:工程师不再直接在自己电脑上使用 agent harness[来写代码]。取而代之的是,工程团队管理一个更大的工作积压,由这些 agent 自动领取。工程将不再是写代码,而更多是有效地部署技术来解决业务问题。感谢阅读,期待在评论区与大家交流。参考资料: https://github.com/lunareng/airlock-actions https://airlock.lunareng.com/schema/role.schema.json https://airlock.lunareng.com/schema/autonomy.schema.json https://airlock.lunareng.com/schema/config.schema.json https://www.anthropic.com/institute/measuring-pace-of-ai-dev... https://felixrieseberg.com/how-to-be-more-ambitious-a-tutori... 评论 URL:https://news.ycombinator.com/item?id=50419615 点数:1
评论数:0
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。