Coder Agent Relay：受监管企业如何在不放弃控制权的前提下使用云端编码代理

过去两年，编码代理从玩具变成了主力开发工具。但银行、国防、政府机构和大型跨国企业一直没能用上它们——不是因为开发者不想要，而是因为部署模式不合法：源代码需要受控访问、执行环境需要防止数据外泄、每一个动作都必须可审计，而供应商托管的工具满足不了这些要求。2026 年 9 月 2 日，Coder 发布了 Agent Relay，一个面向云端编码代理的自托管执行环境，SpaceXAI 是首发合作伙伴。Cursor Cloud Agents 现在可以运行在客户自有基础设施的 Coder 工作区里：Cursor 继续运行代理主循环（推理与规划），而工具调用全部在客户网络内的 Coder 环境中执行。

1. 市场缺口：被部署模型挡在门外的 AI 编码

Coder 在公告里说得直白：「企业从未拒绝 AI 代理，它们拒绝的是部署模型。」瓶颈从来不是模型本身，而是 pilot 之后发生的一切：代码在哪里运行、谁有权限、代理能触达什么、事后留下什么记录——这些都是基础设施问题。Gartner 预测到 2027 年 80% 的企业软件工程师需要为生成式 AI 提升技能，而在监管最严格的行业里，安全与合规审查仍然决定哪种工具能真正送到开发者手上。结果就是：最能从 AI 编码中获益的行业，恰恰被挡在最好的工具之外。

// The core trade: a cloud coding agent is really two loops.
// Loop A (planning + inference) can live in the vendor cloud.
// Loop B (tool calls: shell, git, editors, build) is where
// source code gets touched -- and where enterprises say no.
const agent = {
  planningLoop: "vendor cloud (Cursor): model inference, planning",
  executionLoop: "enterprise network (Coder workspace): shell, git, build",
  rule: "Loop B must run where the customer can audit it",
  result: "Cursor UX + governed execution + data stays inside",
};

2. Agent Relay 做了什么：拆分两个循环

关键洞察是：云端编码代理其实是两个循环。循环 A（规划与推理）可以在供应商云端运行；循环 B（工具调用：shell、git、构建）才是真正接触源代码的地方——也是企业说不的地方。Agent Relay 把循环 B 搬进客户自己运营的 Coder 工作区：每个工作区启动一个 Cursor worker，向 Cursor 建立一条出站连接。开发者保留熟悉的 Cursor 体验（应用、网页、移动端），平台团队则像管理现有开发环境一样供给和伸缩工作区。源代码、密钥和内部服务始终留在客户控制的机器上。

// Agent Relay, announced Sep 2, 2026, with SpaceXAI as launch
// partner: each Coder workspace starts a Cursor worker that
// opens an outbound connection to Cursor's cloud. Platform
// teams provision and scale it like any dev environment.
// Coder CEO Rob Whiteley: "Enterprises never rejected AI
// agents. They rejected the deployment model."
{
  "agent_relay": {
    "workspace": "coder-workspace-with-worker",
    "worker": "cursor-cloud-agent",
    "connection": "outbound-only, workspace -> cursor",
    "model": "cursor runs inference + planning",
    "execution": "tool calls run in the workspace"
  }
}

3. AI 操作层：五条铁律

Coder 把这个架构称作「AI 操作层」，并给出五条必须同时成立的性质：数据留在边界内；每个任务只能看到被授予的数据；只允许经过批准的模型运行；每个动作都留下记录；成本在被累积之前就设好上限。注意这不是一个产品功能清单，而是一个结束「速度还是安全」二选一的治理框架。团队可以放心采用让他们最快的工具，代理获得真正的自主权，而底下的这一层始终兜底。

// The AI Operating Layer: five properties that let an org
// adopt agents at speed without giving up safety.
const AI_OPERATING_LAYER = {
  "1_data_boundary": "data stays inside the boundary",
  "2_least_privilege": "every task sees only what it was granted",
  "3_model_allowlist": "only approved models run",
  "4_audit": "every action leaves a record",
  "5_cost_cap": "spend is capped before it accumulates",
};

4. 落地：工作区模板与出口策略

落地方式与现有开发者环境完全一致：用 Coder 模板定义包含 worker 的工作区，网络策略只允许工作区到 Cursor 中继的 443 出站流量，其余默认拒绝。企业可以把代理放在与私有代码、定制硬件同一网络分区里，却不必牺牲 Cursor 的产品体验，也不必放弃 Coder 工作区的安全与标准化。对安全团队来说，最舒服的一点是：出站白名单取代了「把整个仓库上传给第三方」的信任跳跃。

5. 治理：审计、审批与成本上限

五条铁律的后两条要靠工程实现。审计：把每次工具调用以 append-only 的 JSONL 写入并转发 SIEM，监管问「代理到底做了什么」时这就是答案。成本：在平台层面对每个代理会话设预算，超限自动暂停。模型允许名单：只允许通过合规评估的模型进入执行循环。所有这些都可以在客户自己的基础设施里实现，这正是供应商托管方案做不到的地方。

# Network policy: the workspace may reach the Cursor agent API
# (outbound), but internal services are only reachable from the
# sandboxed execution plane. No inbound from the internet.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-relay-egress
spec:
  podSelector:
    matchLabels: { app: cursor-worker }
  policyTypes: [Egress]
  egress:
    - to:
        - ipBlock:
            cidr: 203.0.113.0/24   # Cursor relay CIDR
      ports:
        - protocol: TCP
          port: 443

6. 对平台团队意味着什么

对平台团队，这是一个明确的信号：代理治理正在变成开发者平台的核心职责，与镜像仓库、CI 集群同级。接下来一年，预计会出现更多「本地执行 + 云端智能」的混合架构，而区分成熟度高低的标准，不是代理写代码有多好，而是执行环境有多可控、审计有多完整。尽早把 AI 操作层的五条性质写进你的平台规范，比事后补合规要便宜得多。

#!/bin/bash
# Audit hook: every tool call the agent makes is recorded to
# an append-only log shipped to the SIEM. Regulators ask
# "what did the agent do?" -- this is the answer.
cat >> /var/log/agent-audit.jsonl <<EOF
{"ts":"$(date -Iseconds)","workspace":"$CODER_WORKSPACE","user":"$CODER_USER","cmd":"$BASH_COMMAND","exit":"$?"}
EOF