CanyonOS 开源：多智能体工作流可按单个智能体独立扩缩

规划器、研究智能体、综合智能体的负载曲线不同，整应用一起扩会让空闲部分白占机器，CanyonOS 只给堆积请求的那个智能体加副本。扩缩策略写在 scaling.

yaml，按每副本每分钟完成请求数或全部副本排队长度计量，默认约每 5 秒采样、连续 4 次越线才加减副本，缩容先排空再停。智能体之间仍写成普通方法调用，本地控制器转发并返回 Future，支持同时发出多路调用而不必改写成异步代码。

追踪在平台层完成：智能体间调用和经内置 LLM 网关的请求会记录路径、耗时、token 和估算费用，可导出到 OpenTelemetry，业务代码无需加装饰器；需要按「一个智能体一个文件」接入，或用转换助手改写 LangChain、LangGraph 项目，可部署到本机 Docker、自有 AWS 或 Kubernetes，模型需 OpenAI 兼容接口。

作者用 portfolio 示例跑了一次 40% 苹果、35% 微软、25% 英伟达的回看分析，自报 10 个可追踪步骤、两次 LLM 调用、估算费用 0.000184 美元，但这些是单次自报数据而非独立评测；

目前接口无内置鉴权，看板默认关闭登录，生产使用需自己补这层。

CanyonOS：多智能体工作流可以只给忙的智能体加副本 https://t.co/xAgd2YWY0N 按智能体扩缩，也按智能体追踪 各智能体很少同时需要同一份容量：规划器很快结束，请求却可能堆...

CanyonOS：多智能体工作流可以只给忙的智能体加副本 github.com/CanyonCodeCore… 按智能体扩缩，也按智能体追踪 各智能体很少同时需要同一份容量：规划器很快结束，请求却可能堆在某个研究智能体后面。整应用一起扩，空闲部分也会被加机器。CanyonOS 把每个智能体做成独立的容器服务，自带队列和副本上下限。智能体之间仍写成普通方法调用，由本地控制器转发并立即返回 Future，可以同时发出多路调用，而不必改写成异步代码。扩缩策略写在 scaling.yaml，对每个智能体分别计量：看每副本每分钟完成的请求数，或该智能体全部副本上的排队长度。默认约每 5 秒采样，连续 4 次越线才加减一个副本，大约 20 秒反应一次；缩容会先排空再停。数据库和入口不参与扩缩，副本下限至少为 1。 智能体之间的调用，以及经内置 LLM 网关的模型请求，由平台记下路径、耗时、token 和估算费用，并可导出到 OpenTelemetry。不必在业务代码里加追踪装饰器，但仍要按「一个智能体一个文件」接入，或用转换助手改写 LangChain、LangGraph 项目。可部署到本机 Docker、自有 AWS 或 Kubernetes，模型需提供 OpenAI 兼容接口。 一次演示，以及现在的边界 用官方 portfolio 示例分析了 40% 苹果、35% 微软、25% 英伟达，回看过去一年。跟帖截图是本地 canyonos test：Test passed，约 22.4 秒，价格来源为 yfinance。他写道有 10 个可追踪步骤、两次 LLM 调用，估算费用 0.000184 美元，但截图里看不到这张明细。这些是作者单次自报，不是独立评测。费用按平台价目估算，会用到 LiteLLM 的报价，不是账单原件。已部署接口没有内置鉴权，看板默认关闭登录。 Sumanth @Sumanth_077 Multi-agent workflows have a scaling problem! The agents inside the same workflow rarely need the same amount of capacity at the same time. Say you have a planner, multiple research agents, and a final synthesis agent. The planner might finish quickly while requests start piling up behind one of the research agents. Scaling the entire application would add capacity everywhere, even though only one part of the workflow actually needs it. CanyonOS is an open-source, workflow-aware platform for multi-agent Python applications and the harness between your agents. Each agent runs as a separate service with its own queue and replica limits, so the busy research agent can get additional capacity while the planner and synthesis agents stay where they are. It also handles communication between the agents and gives you visibility into what happens across the workflow after a request comes in. CanyonOS records the path a request took, including the agents it called, parallel branches, model usage, execution time, and estimated model costs. And you don't need to add tracing decorators or a separate instrumentation SDK throughout your agent code. You still integrate the workflow with CanyonOS, but tracing is handled at the platform layer. I also ran a multi-agent portfolio analysis workflow through it with separate agents working across three stocks. A single request produced 10 traceable steps across the workflow, and I could see which agents ran, where the LLM calls happened, how long each stage took, and the estimated model cost. For multi-agent applications, being able to operate each agent independently while still seeing the complete execution path becomes much more useful as the workflow grows. CanyonOS is open source. Link to the GitHub repo in the comments! 🔗 View Quoted Tweet📊 5 ⚡

本条情报归属 AITOP「产品」核心栏目，重点聚焦北美前沿实验室与硅谷科技巨头。在跨区域产业观察坐标中，该动态直接关联「AI 开发者工具链、Coding Agent 与工程化实践」「中美大模型技术代差与商业化对照」研究主线，反映出当前技术演进与商业落地的最新风向。涉及核心实体与技术议题包括：CanyonOS、多智能体、LangGraph、OpenTelemetry，读者可通过下方标签进入对应专题页查阅历史脉络与关联对比。

信源核验说明：本文原始线索采编自「shao__meng」（@shao__meng），经 AITOP 多维评分管线结构化提炼。截至目前，全网已有 11 家独立信源对该事件进行交叉印证与跟进报道（含 pandaily、Simon Willison’s Weblog、AWS Machine Learning Blog 等），属于近期高关注度行业信号。