System-Design

上周六深夜，我通过钉钉听记完整记录了红杉资本 2026 AI Keynote。35 分钟的演讲中，有一个词反复刺痛了我：Diffusion Gap（扩散差距）。

演讲者说：“基础模型能力的增长速度，远超企业采用速度。”

这句话翻译成中国 SaaS 市场的语境就是：你的客户还在用 Excel 管客户、用微信群发通知、用邮件批流程，而 AI Agent 已经能自主完成端到端任务了。这个差距不是 bug，是未来三年最大的商业机会。

团队里的小王和小李都在用同一个 AI Agent 平台。

小王输入：「帮我总结一下今天群里的讨论。」

Agent 调用了 fast/small 模型做意图识别，然后用 medium 模型读取了 200 条消息，生成了摘要。耗时 3 秒，花费 0.02 元。

小李输入了完全相同的指令。

Agent 却调用了 large/reasoning 模型，不仅做了摘要，还自动关联了小李上周的项目文档，识别出了三个待办事项，并推送到了他的日历。耗时 12 秒，花费 0.15 元。

同样的输入，完全不同的执行路径。

这不是 bug，而是一个成熟的 Agent 系统应该具备的能力——根据用户画像、历史行为、任务上下文，动态决策每一步该用什么模型、什么工具、注入多少上下文、以什么并发度执行。

当你的 Agent 只有 100 个用户时，这些问题还不明显。你可以手动调几个规则，给 VIP 用户分配更好的模型，给普通用户限流。靠人肉运维，系统也能跑。

但当用户量从 100 涨到 10 万、100 万，当模型供应商从 1 家变成 10 家，当工具调用从几个 API 扩展到上百个——靠人写规则来调度，系统会直接崩溃。

不是因为规则写不出来，而是因为规则的组合空间是指数级的：

• 7 种任务类型 × 5 个复杂度等级 × 10 个模型 × 4 种用户画像 × 3 种上下文策略 = 4,200 种路由组合
• 这还只是单节点决策。如果任务被分解为 3-5 个子节点，每个节点独立路由，组合数直接爆炸到 百万级

没有人能手动维护百万级的路由规则表。

大多数 Agent 框架把执行路径写死在代码里：先调用 A 模型，再调用 B 工具，最后返回结果。这在 demo 阶段没问题，但一旦面向规模化用户，就会暴露三个致命问题：

1. 成本失控——所有用户都用最强模型，简单任务也在烧钱，规模化后月账单直接六位数
2. 体验一刀切——新手和专家拿到相同的结果，没有人觉得「懂我」，留存率上不去
3. 无法进化——系统上线后不会从用户反馈中学习，规则越写越多，越用越僵化

这篇文章，我们来拆解如何构建一个动态路由决策系统（Dynamic Routing Decision System, DRDS）——一套端到端的自进化引擎，让 Agent 的执行路径真正做到千人千面，并且在规模化下持续学习、自动优化。

核心观点：自进化不是 Agent 的「加分项」，而是规模化后的「必选项」。

上周三晚上 11 点，老王给我发消息：他们的桌面 Agent 上线刚满 30 天，DAU 爬到 8000，团队 4 个人。他翻了一周用户行为日志，发现一个反直觉的事实——用过 3 次以上的用户里，62% 只把它当"自然语言版的快捷启动器"用，真正让它做跨应用编排的不到 13%。但他们的技术栈正按"复杂编排"在搭：每个 query 直接扔给 GPT-4o 做 function calling，P50 延迟 1.6 秒，P99 干到 3.8 秒。

老王问：“我看了你之前那个四层意图漏斗，要不要现在就全套上？团队就 4 个人，老板说三个月内要把日活做到 5 万，怕 over-engineering。”

我的答案：要上，但不是一次上四层。1 个月的 Agent 团队最缺的不是模型层数，是能让你做对决策的数据。

上周，一个做 AI 编程助手平台的架构师朋友找我喝咖啡。他们的产品增长很快，企业客户越来越多，但工程团队正被四个问题折磨得焦头烂额：

“我们最初用 Docker 给每个用户起一个容器做代码执行沙箱，几十个人跑没问题。现在上千并发，问题全暴露了——

隔离：有客户的 Agent 在容器里 cat /proc/1/environ 读到了其他租户的 API Key； 持久化：客户抱怨上次会话写的代码，下次进来全没了； 弹性：一个大客户做代码审查把 GPU 配额全占满了，其他客户的 Agent 全部超时； 合规：法务要求支持 GDPR 数据删除，但我们连 Agent 的记忆散落在哪些存储里都说不清。”

他问：“你们做大规模 Agent 平台的时候，沙箱到底应该怎么设计？”

这不是他一个人的问题。2026 年，Agent 从 demo 走向生产，几乎所有做 Agent 平台的团队都会在这四个维度上踩坑。传统 SaaS 的多租户隔离只关心"数据别串"，但 Agent 沙箱要解决的是一个更复杂的问题：一个自主执行代码、持久化状态、调用外部工具的 AI 工作空间，如何在共享基础设施上安全、弹性、合规地运行？

本文从四个工程维度系统性地拆解云端大规模 Agent 沙箱的架构方案：多租户隔离、状态持久化、弹性调度、合规治理。

上周团队里的某同事给他的 AI Agent 加了一个"帮我总结这个网页"的功能。用户发一个 URL，Agent 自动打开、提取内容、生成摘要。听起来很简单对吧？

结果上线第一天就翻车了。

一个用户发了一个 GitHub 仓库链接，Agent 用浏览器沙箱打开了仓库首页，截取了 README 的前几屏，然后用一个 7B 的轻量模型生成了摘要——完全忽略了仓库里真正的核心代码和 issue 讨论。用户等了 40 秒，得到了一段废话。

同一个功能，另一个用户发了一个新闻网站链接，这次 Agent 反而用了最强的推理模型去处理——一个纯文本提取任务，花了不必要的 token 费用，还因为推理模型的"过度思考"把简单的新闻摘要写成了一篇分析报告。

某同事跑来找我：“模型能力明明够了，为什么用户体验这么差？”

我说：“你的问题不是模型不行，是你没有给任务找到合适的模型和执行环境。你缺的是一个推荐系统。”

上周一个计算机大四学生加我钉钉问：“朱老师，我们宿舍最近吵翻了。一个室友说现在 Cursor 能秒写算法题，刷 LeetCode 是浪费时间，应该去学系统设计；另一个说大厂面试还在考八股，老老实实刷题才靠谱。我已经拿了 offer，再过 4 个月入职——我现在应该学什么？”

这个问题很典型。它背后其实藏着一个更深的认知误区——把"写代码"和"做架构"看作两个独立的阶段，仿佛 AI 替代了前者，后者就可以直接上手。

但真相恰恰相反。AI 不是让你跳过写代码，而是让你在写代码的过程中，同时训练架构思维。 传统的架构师成长路径是"先写 5 年代码，再学系统设计"，而 AI 时代的路径是"从你写第一行代码起，就让 AI 帮你同时跑两条线"。

这篇博客就是写给正在毕业、或者刚入职 1-2 年的计算机专业同学的。我会给你一个可以从 今天 就开始执行的成长路径。

上周团队在规划 Agent 的多渠道接入方案。有人说"每个 IM 写一套 adapter"，有人说"统一用 Webhook 接收然后标准化"。

我打开 Hermes Agent 的代码仓库，gateway/platforms/ 目录下躺着 18 个平台适配器——从 Telegram、Discord 到钉钉、飞书、企业微信、QQ 机器人，甚至还有 iMessage（BlueBubbles）、Signal 和 Home Assistant。

“所有平台共享同一个 Agent Loop，同一套 Session 管理，同一套工具调用。”

他们问：“那 18 个 adapter 之间代码复用率有多少？”

我给他们看了一张图。

上周团队在讨论 Agent 产品的交互方案。前端同学主张用 Web UI + WebSocket，理由是现代、可扩展、支持多端。后端同学说那不如直接嵌到现有产品里，用 HTTP REST API。

我打开了我们自己的 Agent 代码仓库，给他们看了两套实现——一套是纯 Python 的同进程架构，另一套是 React + Python 子进程通过 JSON-RPC 通信。

“我们同一个产品里，两套通信协议并存。”

他们沉默了几秒。“为什么？”

因为这不是架构设计的失误，而是交互范式的必然分化。CLI 要的是零延迟的本地体验，TUI 要的是跨进程的事件驱动架构。用一套协议去套两种场景，只会两头都不讨好。

今天我们就来解剖一下 Hermes Agent 的两种交互架构——看看 CLI 和 TUI 分别是怎么和 Agent Loop 通信的，协议是什么，为什么这么设计。

昨天我用 Agent 处理一个棘手的部署任务。它第一次跑的时候踩了个坑——少了一步 docker login，推送镜像时报错了。Agent 发现问题，自己补上登录步骤，重试后跑通了。

但最让我惊讶的不是它跑通了，而是它默默更新了自己的操作手册。

下一次我再让它做同样的任务时，它直接带上了 docker login，一步到位。

它自己"长记性"了。

这不是魔法，是 Hermes Agent 的 Skill 自进化机制。它把一次性的试错经验，固化成了可复用的程序化记忆。

跑了一个长对话 session，agent 帮我重构了一个模块，修了三个 bug，又加了一组测试——最后触发了 context compression，屏幕上显示：“Compressed: 347 -> 18 messages (~89,000 tokens saved, 74%)"。

我好奇它是怎么做到的：压缩了 89K tokens 后，agent 继续干活，居然还记得之前改过的文件路径、失败的测试用例、我说过"不要用 == 要用 is 比较 None"这种细节。

这不是魔术，是一个经过大量 bug 修复迭代出来的上下文压缩算法。我花了两个小时读了 Hermes Agent 的 context_compressor.py，1163 行代码，每一步都有对应的失败案例和修复注释。