Ridge 上线:把 Coding Agent 接到本地/SSH/Docker/S3 资源,以及 Agent 资源访问层新样本 · 重庆智能体开发 · 行业资讯

2026 年 9 月 10 日,工程师 vasinov 在 Hacker News 发布《Show HN: Ridge - Connect coding agents to local, SSH, Docker, and S3 resources》,4 分首页关注。Ridge 是 Apache-2.0 开源的 AI Agent 资源访问中间层,定位是 "resource mesh for AI agents",用一致的接口让 Coding Agent 访问 local projects、Docker containers、SSH machines、S3 storage 四类基础资源,通过 MCP + CLI + Python 三种方式接入。这件事虽然评分不高,但解决的问题在企业 Agent 落地上极其关键——把"Agent 怎么访问基础设施资源"这件事从零散的胶水代码标准化成统一的契约层。结合 8 月 19 日 YC S26 的 OneCLI (88 分,把 secret 从 Agent 隔离到 vault + gateway)、8 月 18 日 machine0 (83 分,持久化 VM 运行时 + Profile 注入)和 9 月 1 日 SenteLabs extensible-mcp (3 分,policy 从 model 拿出去到 deterministic proxy)这四个独立产品的设计哲学,可以把企业 Agent 资源访问层这一层的工程新基线完整地勾出来。

一、Coding Agent 资源访问的现实痛点

vasinov 在 HN 帖里直接给了创建 Ridge 的原始动机。他想在 laptop 上用 Codex 跑 kernel optimization 实验,但执行要在他的 GPU box 上跑,模型存在 S3 里。Codex 在做实际实验之前,先要写文件传输和远程执行逻辑。这些脚本可以存下来留给下次 session,但这样一来每个实验都要维护一个小型的 infrastructure 项目。

这个故事把企业 Agent 落地最普遍的资源访问痛点讲得非常清楚——Coding Agent 在真实工作里要访问的资源几乎都不在本机。代码可能在远程 dev box,数据在 S3,大模型 checkpoint 在对象存储,GPU 在云端,生产数据库在内网。每次跑任务,Agent 都要先拼出一套"访问 X 资源、传输 Y 文件、执行 Z 命令"的胶水代码,这些胶水代码本身不是任务内容,但没有它们任务根本跑不起来。

更糟的是,这些胶水代码在每次新 session 都要重写或者读历史版本凑合用。Codex 能写 scp 命令、SSH 连接、boto3 S3 client、docker exec 调用,但每个 provider 的 API 不同、每个项目的资源组合不同、每次 token 预算紧张,真正花在任务上的 token 反而被这些 boilerplate 消耗掉。Ridge 把这件事标准化,提供一致的接口——Agent 只需要说"把 A 资源里的 X 文件复制到 B 资源",背后是 Docker / SSH / S3 / local 都走同一套 capability contract。

二、Ridge 的核心架构

Ridge 的设计哲学可以总结为四个核心能力加一条明确边界。

第一个核心能力是 Find usable resources——发现可用资源。Agent 通过 MCP / CLI / Python 三种入口,看到一个有名字的资源列表,每个资源声明自己支持哪些操作、允许哪些操作。Agent 不需要为每个 backend 学一套不同的 toolset,所有 backend 共享同一个访问模型。

第二个核心能力是 Keep artifacts out of model context——把工件从 model context 里拿走。Ridge 支持在兼容资源之间流式传输文件、源代码树、数据集、报告。Agent 只选择 endpoint 和读回自己需要的结果,不需要把整个传输 payload 塞进自己的 prompt context。这一条在企业 Agent 落地里至关重要——大文件传输如果不走流式,Agent 的 context window 会被快速消耗,即使是 GPT-6 Astra 这种 context 接近 1M token 的模型也吃不消。

第三个核心能力是 Delegate access, not just instructions——委托访问而不只是委托指令。Ridge 的核心创新是 access scope——一个 authority context,parent agent 给 worker 发放 selected resources + operations + narrower data views,可以设置 expiry 或主动 revoke。这条能力是现有 Coding Agent 平台普遍缺失的——Claude Code 和 Codex 的 subagent 能力更多是"分配任务",而不是"分配 scoped 访问权限"。Ridge 把 access control 做到 worker 这一层,parent 给 worker 的是有边界的访问 token,而不是无限制的访问能力。

第四个核心能力是 Pick up long-running work——承接长任务。Background jobs 在 client 重连后保留 ID、状态、日志和结果,授权的 parent 可以 inspect descendant jobs。这是 always-on Agent 时代的基础设施要求,跟 machine0 的 suspend/resume + snapshot 模式是同一类需求。

第五个核心能力是 Coordinate shared updates——协同共享更新。Ridge 在支持的 filesystem 场景下支持并发 publish 不同文件,或在多步更新中 reserve 文件、目录树、精确的 S3 对象。冲突的 participating operations 在它们各自的 access scope 之外独立协调。这条能力在多 Agent 并行跑同一份数据时至关重要,没有这套机制,worker A 写到 results:metrics.json 时 worker B 也在写,S3 没有原子写保护。

Ridge 的明确边界是它不是 sandbox,不是 infrastructure provisioner,不是 agent orchestrator。Native OS 和 service permissions 仍然适用——delegated data root 只 narrow Ridge data operations,不能 narrow 一个 command 能 reach 到哪里。这条边界把 Ridge 与 machine0、OneCLI、extensible-mcp 区分开:Ridge 管"Agent 怎么访问资源",machine0 管"Agent 跑在哪里",OneCLI 管"Agent 怎么用 secret",extensible-mcp 管"policy 在哪一层执行"。四个产品解决不同的层次,但互相补充。

三、Ridge 的具体工作流

Ridge README 给出一个完整工作流示例。假设 workspace 接入本地项目 + remote workers + 一个共享 destination,evaluation code 和 worker runtimes 已经可用。parent agent 收到任务——"对比方法 A 和 B 在数据集上的表现,让 worker 各自评估,保存报告,告诉我哪个更好,保持 inputs 不变"。

第一步,parent 通过 Ridge inspect 可用资源和自己的 authority。第二步,parent 发放 scopes——给 worker A 一个 read-only inputs + 独立 output views(scope 1),给 worker B 同样的 scope(scope 2),harness 给每个 child 单独绑一个 Ridge connection。第三步,children 各自 copy inputs、跑 evaluation、publish 报告,Ridge 流式传输文件、追踪 background jobs、协调 participating operations。第四步,parent inspect jobs 和 reports、对比输出、收集结果后 revoke delegated access。

整个工作流里 Ridge 承担的是 "resource access" 这一层——文件传输、命令执行、scope 管理、job tracking、conflict resolution 都由 Ridge 处理,Agent harness 只负责 planning 和 worker launching。这种"分层清晰"的设计让 Ridge 成为一个可被多种 Agent harness 复用的标准层——Codex、Claude Code、LangChain 都能通过 MCP 直接接入。

四、把 Ridge 放进 Agent 资源访问层的产品矩阵

把 Ridge 跟 machine0、OneCLI、extensible-mcp 这三个产品放在一起,可以非常清晰地看出企业 Agent 资源访问层正在分裂成四个清晰的层次。

第一层是 infrastructure layer——Agent 跑在哪里。machine0 给出样板——专用持久 VM、CLI + MCP 接口、suspend/resume/snapshot、Profile 注入。这层关注的是 compute 和生命周期。

第二层是 resource access layer——Agent 怎么访问资源。Ridge 给出样板——统一 capability contract、MCP + CLI + Python 三接口、scoped access、stream-based transfer、background job tracking。这层关注的是 resources 和 access pattern。

第三层是 secret/credential layer——Agent 怎么用 secret。OneCLI 给出样板——secret 隔离到 vault,Agent 通过 deterministic gateway 调用,HITL approval 在 chat 内完成。这层关注的是 credentials 和 audit。

第四层是 policy layer——policy 在哪一层执行。extensible-mcp 给出样板——policy 在 model 之外的 deterministic proxy 层执行,human approval 密码学可验证,policy 用 Lean proof assistant 写成数学证明。这层关注的是 authorization 和 trust。

四个层次解决的问题正交,但每一个都是企业 Agent 真正落地不可缺的部分。任何一层缺失,Agent 平台都会暴露严重问题——没有 infrastructure layer,Agent 跑 1 小时就被销毁,无法承担跨天任务;没有 resource access layer,Agent 每次要拼胶水代码,token 浪费严重;没有 secret layer,Agent 拥有 secret,prompt injection 直接外泄;没有 policy layer,policy 在 prompt 里被改写,合规失效。

五、企业 Agent 资源访问层的具体设计 checklist

把这四个层次合并,企业 Agent 资源访问层的设计应该满足如下 checklist。

第一条,基础设施必须持久化。任何 Agent 跑在持久 VM 上(参考 machine0 设计),而不是 ephemeral sandbox(参考 E2B 设计)。Always-on + suspend/resume + snapshot 是最低要求,99.9% uptime 是底线。

第二条,资源访问必须统一接口。Agent 通过标准 capability contract 访问 local / Docker / SSH / S3,而不是为每个 backend 写一套 toolset(参考 Ridge 设计)。MCP + CLI + Python 三种接入方式覆盖 Agent harness、脚本、嵌入代码三种使用场景。

第三条,资源访问必须 streaming。文件传输走流式而不是 context 注入(参考 Ridge 的 Keep artifacts out of model context)。任何大于 100KB 的文件不应该经过 Agent 的 prompt context。

第四条,资源访问必须 scoped。parent 发 scope 给 worker 时携带 selected resources + operations + narrower data views + expiry(参考 Ridge Delegate access)。revocation 是 atomic 操作,不需要重写 workspace configuration。

第五条,secret 必须从 Agent 隔离。Agent 通过 vault + gateway 用 secret,不直接持有 credential(参考 OneCLI 设计)。HITL approval 在 chat 内完成,deterministic,audit-able。

第六条,policy 必须在 model 之外执行。policy 不能住在 prompt 或 model 能访问的任何位置(参考 extensible-mcp 设计)。deterministic proxy 层 + 形式化验证是长期方向。

第七条,任何 subprocess 调用必须进审计流。GitSpawn 揭示的教训——Agent 自己跑 git status 的 subprocess 时,fsmonitor 配置可能触发任意代码执行。subprocess spawn 必须进独立审计流(参考 machine0 + OneCLI 实践)。

第八条,resource mesh 必须支持 background job tracking。长任务的 background job 在 client 重连后保留 ID、状态、日志、结果(参考 Ridge Pick up long-running work + machine0 suspend/resume 组合)。

六、下一步:Agent 资源访问层的标准化

把这件事放到更大的图景里看,Agent 资源访问层当前正在从"零散胶水"过渡到"标准化 mesh"。早期 Coding Agent 直接拼 bash 命令、scp、boto3,接下来两年的重心会是把"Agent 怎么访问基础设施"这件事像 MCP 一样做成协议+中间件+生态。

Ridge 是这个方向的早期样板——把 capability contract 作为资源访问的标准化协议,把 scoped access 作为细粒度授权模型,把 stream-based transfer 作为默认传输模式。machine0 配合给出 compute layer,OneCLI 配合给出 secret layer,extensible-mcp 配合给出 policy layer。四个产品在同一时期出现不是巧合,是企业 Agent 真正落地时必须同时解决四层问题,缺哪一层都不行。

对企业 IT 来说,这件事意味着评估 Agent 平台时必须同时看四层能力——infrastructure / resource access / secret / policy。只解决其中一两层的 Agent 平台在生产环境都会暴露严重问题,四层都解决完整的 Agent 平台才能真正承担关键业务。这是 Agent 平台从 demo 时代过渡到生产时代必须过的四道关,也是未来一年内 Agent 厂商必须补齐的四块板。

回到一开始的问题——Ridge 作为 resource mesh 样板,加上 machine0 / OneCLI / extensible-mcp 三个不同层次的补充,把企业 Agent 资源访问层的工程新基线第一次用四个独立产品的形态清楚地呈现出来。剩下的是企业 IT 在落地时把四层都做对,把 Agent 平台从"演示工具"升级为"生产基础设施"。一年内,具备完整四层能力的 Agent 平台会成为企业市场的入场券,只有一两层能力的会被快速淘汰。