Kilo 云平台架构解析：从 Web 控制平面到 Cloud Agent 的托管服务拓扑与运行边界-港品优选

Kilo 云平台架构解析：从 Web 控制平面到 Cloud Agent 的托管服务拓扑与运行边界

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

Kilo Cloud 是 Kilo（all-in-one agentic engineering platform）的托管平台层，承担身份认证、模型路由、计费、产品配置、自动化任务与受限执行（scoped execution）服务。本文以 packages/kilo-docs/pages/contributing/architecture/cloud-platform.md 为骨架，结合仓库内 packages/kilo-gateway 客户端实现与架构总览、自动化服务、云端安全等相邻文档，系统梳理托管服务分层、Cloudflare 运行时原语、Cloud Agent 执行会话、自动化边界、应用生成、KiloClaw 与多智能体编排等核心拓扑，帮助读者建立"触发 → 编排 → 执行 → 输出"的完整托管链路认知。

静态源码范围说明：本页描述的 Worker 表面、绑定、路由与代码路径均来自开源的Kilo-Org/cloud仓库（下文services/*、apps/web/*路径均相对于该仓库根目录）。静态源码证明的是"可部署架构"，而非"生产环境实际启用情况"——包括上线比例、保留策略与供应商配置。在做出生产或合规声明前，请以真实运行环境为准。信任边界与数据流请参阅 Kilo Cloud 安全架构。

本页的使用方式

阅读本文可掌握三件事：托管服务存在哪些产品边界、长时运行任务在哪里执行、托管运行时之间如何关联。若需进一步研究"触发到执行"的工作流细节，继续阅读自动化服务架构；若关注信任边界与控制项，请转向 Cloud Security。

下文多次出现的owner一词，均指授权特定产品状态与凭据的个人用户或组织。

托管分层（Hosted layers）

Kilo Cloud 整体分为四层，职责边界清晰：

层	职责	示例
Web 控制平面	身份、组织授权、计费、产品配置与 API 编排	`apps/web/`中的 Next.js 应用
共享云服务	模型路由、异步编排、实时投递、持久化适配器与运维服务	Kilo Gateway、Workers、队列、Durable Objects、R2、KV、Hyperdrive
受限执行	运行代码或 owner 范围内的运行时工作负载	Cloud Agent、App Builder 预览沙箱、部署构建沙箱、KiloClaw 运行时、Gas Town 容器
外部提供方	Kilo Cloud 信任边界之外的服务	模型提供方、源码控制提供方、消息提供方、遥测提供方

这一分层与仓库架构总览中"三层架构"（本地运行时与客户端 / Kilo Cloud 共享服务 / 托管产品运行时与自动化）一脉相承：本地编码会话与托管工作是两个独立边界，编辑器客户端通过本地kilo serve服务器工作，而托管自动化在需要云端编码时才会启动 Cloud Agent 执行会话。

Cloudflare 术语

Kilo Cloud 的共享服务大量构建在 Cloudflare 原语之上，文档中的术语含义约定如下：

术语	本文档中的含义
Worker	处理 HTTP 请求、队列消息、调度或服务绑定调用的已部署服务边界
Durable Object	具有稳定身份、存储与 alarm 支持的有状态 Cloudflare actor
Queue	用于将入口与长时工作分离的异步投递边界
死信队列（Dead-letter queue）	存放耗尽正常投递尝试次数的消息的队列
Service binding	在 Wrangler 中配置的 Worker 间直接调用边界
R2	用于作用域化 blob、资产、附件或导出数据的对象存储
KV	用于缓存、映射、上线与去重状态的分布式键值存储；不是强一致权威
Hyperdrive	用于将 Workers 连接到 PostgreSQL 的 Cloudflare binding
Sandbox	被选定的托管工作负载使用的隔离容器执行绑定

理解这些原语是读懂下文所有拓扑图的基础：Worker 是"边界"，Durable Object 是"状态与协调"，Queue 是"异步解耦"，R2/KV/Hyperdrive 是"持久化分级"。

产品拓扑总览

下图给出了全量托管产品拓扑（源自 cloud-platform.md）：

需要特别强调的是：并非每个托管流程都会启动 Cloud Agent。共享服务同时承担模型请求路由、聊天事件投递、通知分发、生成应用托管以及 owner 作用域运行时的协调工作——Cloud Agent 只是受限执行层中的一环。

服务族（Service families）

托管服务按产品域划分为七个服务族：

服务族	主要服务	角色
会话执行（Session execution）	`cloud-agent-next`、`session-ingest`、`git-token-service`、`notifications`	托管编码会话、会话摄取、仓库凭据与完成推送
自动化（Automation）	`code-review-infra`、`auto-triage-infra`、`auto-fix-infra`、`security-auto-analysis`、`security-sync`、`webhook-agent-ingest`	队列支撑的评审、分诊、修复、安全与配置化触发流程
应用生成（App generation）	`app-builder`、`db-proxy`、`images-mcp`、`deploy-infra/builder`、`deploy-infra/dispatcher`	生成应用预览、数据访问、图像工具、构建编排与已部署应用入口
KiloClaw	`kiloclaw`、`kiloclaw-billing`、`gmail-push`、`kiloclaw-inbound-email`	owner 作用域助手运行时协调、计费与外部入口
实时聊天（Real-time chat）	`kilo-chat`、`event-service`、`notifications`	会话状态、WebSocket 投递与移动推送
多智能体编排（Multi-agent orchestration）	`gastown`、`wasteland`	Town 执行与协作公地
评估与运维（Evaluation and operations）	`o11y`、`kilo-ops`、`model-eval-ingest`	指标、告警、运维与模型评估摄取
归因（Attribution）	`ai-attribution`	AI 编辑归因事件

从架构总览（index.md）可知，这些服务族并非孤岛：它们附着在"Web 控制平面 → Automation Workers → Cloud Agent"这条核心执行脊柱上，为具体产品流程提供扩展能力。

Kilo Gateway：第一方模型路由边界

Kilo Gateway 由云侧 API 路由与当前仓库中的packages/kilo-gateway/客户端集成共同构成（云侧实现位于Kilo-Org/cloud的apps/web/src/app/api/gateway/与apps/web/src/lib/ai-gateway/）。它在支持账号上下文的同时，也提供匿名免费模型访问。

职责	说明
认证	在需要时解析已登录账号与组织上下文
匿名免费访问	在基于 IP 的上下文与限额下，允许符合条件的免费模型请求无需账号认证
提供方路由	路由 managed-key、BYOK、自定义端点与已配置网关请求
目录（Catalogs）	提供模型、提供方、嵌入模型与转写模型表面
用量与计费	记录适用的 token 用量、积分、权益与计费元数据

Auto Model 的客户端/服务端解耦是网关设计的关键点：Auto Model 客户端发送稳定的kilo-auto/*层级 ID，网关在提供方路由之前先在服务端解析层级映射，因此映射调整无需客户端发版。当前各层级的解析规则见 Models & Providers 的 Auto models 章节，例如kilo-auto/frontier按x-kilocode-mode请求头在anthropic/claude-opus-4.7与anthropic/claude-sonnet-4.6之间切换，kilo-auto/efficient按 API 接口（Completions / Responses / Messages）选择基线模型。

符合条件的网关请求还可携带规范化项目标签，用于用量归因与分组——该标签只标识项目而不发送完整仓库 URL，兼顾了可观测性与隐私。

从当前仓库的客户端实现可以印证网关的多提供方适配策略：packages/kilo-gateway/src/provider.ts 中createKilo()在解析 API key 与基础 URL 后，同时构造 OpenRouter、Anthropic、OpenAI 与 OpenAI-compatible 四个 SDK provider，并通过自定义fetch包装动态注入Authorization头与 Kilo 特有头（组织 ID 等）；模型目录抓取由 packages/kilo-gateway/src/api/models.ts 的fetchKiloModels/fetchKiloImageModels/fetchKiloTranscriptionModels完成，与网关侧的 catalog 职责一一对应。

Cloud Agent：托管编码会话运行时

services/cloud-agent-next/是当前的 Cloud Agent 会话运行时。每次启动的单元就是一个 Cloud Agent 执行会话（execution session），运行时采用queue-first 编排与会话消息模型。

每个执行会话都获得独立的 workspace 与 home 路径；需要特别注意的是，策略选择的沙箱分配并非"一容器一会话"：

层	隔离规则
工作目录（Working directory）	每次执行会话独立
主目录（Home directory）	每次执行会话独立
Git 工作区	每次执行会话独立
沙箱身份（Sandbox identity）	策略选择
默认分配	可跨会话共享 owner 作用域沙箱
选定的组织流程	可使用按会话沙箱
Devcontainer 流程	使用按会话 DIND 沙箱

Cloud Agent 会话的绑定拓扑如下：

这些绑定由services/cloud-agent-next/wrangler.jsonc定义。Wrangler 配置中出现的绑定证明的是"可部署拓扑"，而非生产环境的实际分配数量或上线策略——这是阅读本页时始终要牢记的静态源码边界。

从会话生命周期看，session-ingest（会话摄取）、git-token-service（仓库凭据解析）与notifications（完成推送）共同支撑了 Cloud Agent 会话从启动、身份解析到结果回传的完整闭环。

自动化边界：谁在什么时机启动 Cloud Agent

自动化服务架构负责触发器、owner 作用域、队列、回调、输出与恢复的完整细节。下表只展示自动化与托管平台的关联关系：

服务	托管执行关系
Kilo Bot	为请求的仓库工作启动 Cloud Agent
Code Review	通过 Cloud Agent 运行排队中的评审会话
Auto Triage	在查重阶段可以不依赖 Cloud Agent 完成分类；仅在需要分类会话时启动 Cloud Agent
Auto Fix	启动 Cloud Agent 创建问题修复拉取请求
Security Agent	在`security-auto-analysis`中运行模型分诊；仅对选定的深度分析启动 Cloud Agent
Webhook Agent Ingest	将配置好的提示投递给 Cloud Agent 或 Kilo Chat 目标

自动化服务普遍遵循同一生命周期形状：触发 → 授权 owner → 编排（持久化工作状态、协调队列/Durable Object/回调/alarm）→ 执行目标（仅在需要仓库或结构化编码工作时启动 Cloud Agent，部分流程提前终止或选择其他目标）→ 输出（评审、标签、PR、finding 状态、回调或目标消息）→ 恢复（重试队列投递、超时 alarm、陈旧状态对账或派发下一等待项）。

自动化状态与凭据默认按 owner（个人用户或组织）作用域隔离，个人与组织路径分开处理，避免凭据、并发、finding 与回调坍缩为全局自动化状态。

应用生成边界：预览、构建与入口分离

App Builder 属于产品级编排，而非普通自动化入口。其关键设计是"编码迭代、预览、部署构建、公共入口"四个边界各司其职：

边界	归属
编码与迭代	Cloud Agent 编辑生成的应用程序代码
预览	`services/app-builder/`拥有预览路由与预览沙箱容器
部署构建	`services/deploy-infra/builder/`在独立沙箱边界中拥有构建编排
公共已部署应用入口	`services/deploy-infra/dispatcher/`拥有通配入口与命名空间路由

每个边界都对应独立的沙箱或 Worker 表面，这正是 Cloud Security 中"生成应用预览与部署"信任边界章节讨论的对象：Cloud Agent 编码会话、预览沙箱、构建沙箱互不混用。

Webhook Agent Ingest：配置化触发边界

services/webhook-agent-ingest/负责配置化触发：接收 HTTP webhook 与定时 alarm，随后派发到选定的 Cloud Agent 或 Kilo Chat 目标。其激活方式有两种变体：

HTTP webhook：可在排队投递前应用配置好的 webhook 认证；
定时调度：使用 cron 表达式 + Durable Object alarm（webhook 认证不适用）。

目标有两种：cloud_agent（携带 webhook 或调度平台标记启动 Cloud Agent 会话）与kiloclaw_chat（通过 Kilo Chat service binding 投递到用户作用域的 Kilo Chat 目标）。触发配置与 alarm 状态存放在TriggerDO中，队列消费者负责派发。激活、认证、队列与 alarm 的完整细节归自动化服务架构所有。

Security Agent：发现同步与分析分离

Security Agent 将"发现同步（finding sync）"、"分析派发（analysis dispatch）"与"沙箱执行（sandbox execution）"三个环节彻底分开：

PostgreSQL 保存 owner 作用域的 findings、分析队列行、owner 暂停/封禁状态、Security Agent 配置与审计记录。要点在于：security-sync每六小时 cron 一次，为启用的 GitHub 安全扫描 owner 各派发一条 owner 级队列消息；security-auto-analysis认领排队的分析行，先跑模型网关分诊，仅在需要深度分析时启动 Cloud Agent；Web 清理 cron 只在没有匹配的pending/running队列行时对账陈旧runningfindings。队列生命周期与静态源码局限详见自动化服务架构，信任边界见 Cloud Security。

聊天事件与通知：票据化 WebSocket 与存在感知推送

Kilo Chat 将会话状态存放在 Durable Objects 中，通过 Event Service 扇出事件；通知在推送前检查 Event Service 的存在上下文，并异步处理 Expo 回执：

短时连接票据（short-lived connection ticket）由 Web 控制平面签发，客户端凭票据打开 WebSocket——该机制让 WebSocket 入口具备时效性认证。票据与推送投递的信任边界细节见 Cloud Security。

KiloClaw：owner 作用域的托管助手运行时协调

KiloClaw 是 owner 作用域的托管 OpenClaw 运行时协调层。Durable Objects 跟踪实例生命周期、路由、配置与对账；运行时提供方支持 Fly、docker-local 开发与 Northflank 路径——但源码支持并不能证明生产环境的实际提供方启用情况。

KiloClaw 的全部入口路径及其认证/校验策略如下：

入口路径	认证或校验	入口边界	异步交接	目标
浏览器请求	JWT 认证	KiloClaw proxy	无	Owner 作用域运行时
一次性访问码	兑换的访问码 + 认证 cookie	Access gateway	无	Owner 作用域 OpenClaw UI
控制器机器回检（check-in）	机器 API key + 派生网关 token	KiloClaw controller route	无	Owner 作用域运行时控制器
Kilo Chat RPC	Service binding	KiloClaw binding	无	Owner 作用域运行时
Cloudflare Email Routing	别名查找 + 受限解析	`kiloclaw-inbound-email`	队列	KiloClaw 平台服务
Gmail Pub/Sub 推送	Google OIDC 校验	`gmail-push`	队列	Owner 作用域运行时控制器

KiloClaw 在运行时投递前会先解析 owner 或实例作用域；上表对比的是各入口边界，而非全局共享目标。

Fly 提供方拓扑示例

以 Fly 提供方为例，可以看清"Cloudflare Worker 控制面 + 每用户 Fly 应用 + owner 作用域容器"的完整形态：

值得注意的隔离细节：Fly 层采用每用户 Fly 应用 + 每用户加密，持久卷挂载/root/.openclaw配置与/root/clawd工作区，实例身份由 Worker 内的 per-instance Durable Object 维护，JWT 认证与 Kilo 用户绑定。

Gas Town 与 Wasteland：多智能体仓库编排

Gas Town 面向仓库上的编码工作做多智能体编排。TownDO持有 town 状态，TownContainerDO持有 town 容器执行。活跃 town 工作使用 5 秒 alarm 节奏，空闲 town 使用 5 分钟节奏。

Gas Town 领域概念：

Gas Town 概念	角色
Town	拥有一个或多个 rig 的工作区或项目
Rig	附加到 town 的仓库
Bead	工作单元，如 issue、任务、合并请求或消息
Convoy	带依赖追踪的相关 beads
Mayor	分解并委派工作的持久协调者
Polecat	编辑代码并创建拉取请求的 Worker 智能体
Refinery	运行质量门禁并处理合并流程的评审智能体
Triage	用于处理自动化检查结果不明确场景的临时智能体

Gas Town 通过WASTELAND_SERVICE绑定连接独立的wastelandWorker。Wasteland 使用WastelandDO与WastelandRegistryDODurable Objects，并绑定 DoltHub 支撑的协作公地路径：

可观测性：o11y 指标与告警

services/o11y/是当前的指标与告警基础设施。更高层级的"智能体结果分析"若没有独立实现支撑，仍属路线图工作。其静态源码行为如下：

表面	静态源码行为
告警评估	Worker cron 每分钟运行
API 指标	Analytics Engine 数据集 + Pipeline 流
会话指标	Analytics Engine 数据集 + Pipeline 流
导出	Pipelines 双写 R2 Parquet 数据供 Snowflake 导出基础设施使用
告警去重	KV 命名空间保存基于 TTL 的冷却状态
告警配置	`AlertConfigDO`保存强一致配置
会话连接	`session-ingest`绑定`o11y`并发出会话指标

去重与配置的分工同样体现了 Cloudflare 原语的设计取舍：KV 承担"允许最终一致"的去重冷却状态，而告警配置这类需要强一致读的元数据放在 Durable Object 中。

源码地图：快速定位实现

以下路径均相对于Kilo-Org/cloud仓库根目录：

关注点	源码路径
Cloud Agent 会话服务与绑定	`services/cloud-agent-next/`、`services/cloud-agent-next/wrangler.jsonc`
会话摄取与 Git token	`services/session-ingest/`、`services/git-token-service/`
自动化 Workers	`services/code-review-infra/`、`services/auto-triage-infra/`、`services/auto-fix-infra/`、`services/webhook-agent-ingest/`
Security Agent	`apps/web/src/lib/security-agent/`、`services/security-auto-analysis/`、`services/security-sync/`
应用生成与部署	`services/app-builder/`、`services/db-proxy/`、`services/images-mcp/`、`services/deploy-infra/`
KiloClaw	`services/kiloclaw/`、`services/kiloclaw-billing/`、`services/gmail-push/`、`services/kiloclaw-inbound-email/`
聊天、事件与通知	`services/kilo-chat/`、`services/event-service/`、`services/notifications/`
多智能体编排	`services/gastown/`、`services/wasteland/`
可观测性与运维	`services/o11y/`、`services/kilo-ops/`、`services/model-eval-ingest/`
归因	`services/ai-attribution/`

需要再次提醒：这些services/*路径位于独立的Kilo-Org/cloud仓库；当前仓库（Kilo-Org/kilocode）内的对应部分主要是本地侧集成，例如 Kilo Gateway 客户端 packages/kilo-gateway/src/provider.ts、自动补全模型定义 packages/kilo-gateway/src/autocomplete.ts 以及网关基础 URL 与常量解析 packages/kilo-gateway/src/api/constants.ts。

企业官网建设流程全解析