一个多智能体工作流跑起来，最容易被忽略的成本不是模型调用，而是那些闲着也在占资源的组件。CanyonOS 给出的思路很直接：把每个智能体做成独立的容器服务，各自带队列和副本上下限，谁忙谁扩，谁闲谁缩。

这套平台是开源的。它的核心概念可以拆成三层来看。

第一层：智能体即容器

在 CanyonOS 里，每个智能体不是一段跑在同一个进程里的函数，而是一个独立的容器服务。容器自带队列，也自带副本数量的上下限。这意味着扩容的粒度从"整个工作流"下沉到了"单个智能体"。

传统做法是统一扩容：工作流里有一个环节压力大，整套服务一起加机器，结果那些本来就空闲的组件也跟着多占一份资源。CanyonOS 对每个智能体分别计量、动态伸缩，资源利用率因此提高。

第二层：策略写在配置文件里

扩缩策略放在 scaling.yaml 中，对每个智能体分别计量，判断依据是每副本每分钟完成的请求数。除了每分钟请求数，自动扩缩还会参考队列长度。两个指标一起看，扩缩的触发条件就不只是"忙不忙"，还包括"排队积压到什么程度"。

第三层：追踪放在平台层

调用链路追踪和成本估算由平台层记录，请求路径、耗时、费用都在这一层留下痕迹。业务代码里不需要额外添加追踪装饰器，代码侵入因此降低。

演示环节用了一个具体场景：分析苹果 40%、微软 35%、英伟达 25% 的市值构成。整个执行过程包含 10 个可追踪步骤，只发生了两次 LLM 调用。步骤数和模型调用次数之间的这个落差，正好说明多智能体编排的价值所在——大量环节靠流程和工具完成，模型只在关键节点出手。

对做 Agent 编排的团队来说，这套组合回答的是一个工程问题：当工作流里的智能体数量变多、负载分布不均时，扩容的计量单位该定在哪一层。CanyonOS 的答案是定在单个智能体上，并且把观测能力收归平台，不让业务代码替平台干活。