请求先进入 Clawo，
再被分配到客户的不同 Agent。
用一个动态图回答四件事：请求从哪里来，怎样进入 Clawo，如何被路由到不同模型能力层，以及最后如何回到客户 OpenClaw 的各个 Agent。
SDK、工作流、本地 OpenClaw 和外部任务统一进入同一入口。
所有流量先进入 api.clawo.net/v1，再加载绑定关系与策略。
平台按能力、预算、时延和 fallback 映射到不同模型能力层。
结果继续进入研究、编码、长文档和执行 Agent，并回流日志与账本。
路由不是按模型名硬编码，而是按任务语义分层。
真正的价值不在于页面上罗列多少模型，而在于能否把不同请求稳定映射到合适的能力 lane，并把治理边界收回产品层。
按推理、编码、长上下文和低时延特征选择 lane，而不是把所有请求固定写死到一个模型。
套餐、预算、倍率和配额一起参与路由决策，成本控制不再留给业务侧自己处理。
默认 provider 不可用时按既定链路切到备用通道，入口、密钥和主机绑定关系保持不变。
为当前主机、工作区和具体 Agent 绑定默认 alias 与可见模型集合。
主机页与工作区定义默认能力层级，具体 Agent 再覆盖 alias 或可见模型集合。这样接入保持统一，运行策略却可以按角色继续分化。
把复杂性留在平台内，把接入面留给业务。
对业务团队来说，问题通常不是会不会调模型，而是后面如何治理 key、成本、稳定性和异常切换。Clawo API 的意义，就是把这些复杂度从业务层拿走。
接得上，但长期管理很容易散。
一个统一网关，承接后续治理。
接入依旧很短，但控制层已经不是简单转发。
业务系统和 OpenClaw runtime 只需要维持一个兼容 OpenAI 的入口。控制层继续负责路由、策略、fallback 和账本回流。
所有请求统一进入 api.clawo.net/v1，不再让每个 Agent 维护一套上游地址和凭据。
运行时按租户、主机、工作区和 Agent alias 读取默认模型能力层级。
平台根据预算、时延、fallback 和可用度把请求分配到合适的模型 lane。
这也是 Clawo API 和普通转发层最大的差异: 请求完成之后，日志、用量、费用和路由轨迹会继续回到控制台，而不是消失在上游后台里。
比官方便宜，用同一个账户。
主流旗舰模型统一接入，实际价格约为官方的 7 折。
所有模型低于官方定价，一个账户覆盖全部。
切换模型不用单独充值，统一从套餐里扣。
重复内容自动命中缓存，实际成本通常更低。
选一个套餐，所有模型都在里面。
一次订阅，随时切换任意模型，不用分别购买。
倍率越低消耗越慢。控制台实时显示剩余用量。
客户只看到一个产品名，治理边界却完整留在平台侧。
客户需要的是一个统一 API 产品，而不是一堆上游通道说明。真正的专业化在于，把鉴权、路由、回流和预算治理放进同一个控制面。
客户只持有 Clawo API key，上游凭据保留在平台和渠道层，不散落到业务系统。
日志、用量、账本和费用继续回到同一个控制台，不再依赖多后台拼接。
命中了哪条 lane、走了哪级 fallback、消耗多少预算，都应当可以回查。