Hugo Zhu's Blog

上周和一个做 AI 创业的朋友吃饭，他说了这样一段话：

“当一个 3.75 的同学收到超预期的即时奖励时，他爆发出来的效率是 10 倍的提高。再加上 AI 这个放大器，一个人绝对有可能达到 100 倍的效率提升。”

我当时第一反应是：这个数字太夸张了。但回来路上仔细想，我发现真正值得讨论的不是 100 倍这个数字是否准确，而是这句话背后隐含了一个组织范式的根本性转变——

传统组织靠控制来管理风险，AI 原生组织靠激发来释放上限。

而这两者的底层假设，完全不同。

上周和两个做 To B 的朋友吃饭，一个在 Salesforce 生态里做 ISV，一个在做面向中小商家的 SaaS。

做 ISV 的朋友说：“我们今年的策略很简单，盯住那些已经用 Salesforce 用得很好的大客户，帮他们把最后 10% 的定制化需求补齐。客户预算充足，决策链清晰，签一单够吃半年。”

做中小商家 SaaS 的朋友叹了口气：“我们正好相反。客户连 Excel 都不太会用，你得先教他为什么要数字化，再教他怎么用。但好处是，一旦用上了，粘性极高，因为他自己搞不定。”

两个人说完，桌上安静了几秒。

我忽然意识到，他们说的其实是同一件事的两个面——To B 的生意，归根结底只有两种：帮成功的人更成功，帮不成功的人成功。

这篇文章写完初稿后，一个做企业级 Agent 的创业者找我聊。他说：“我觉得 Agent 赛道不太一样。我们现在既在做 Copilot 帮员工提效，又在做 Auto Agent 帮企业自动化流程。两条路都在试。”

我问：“你们现在有多少客户？”

他说：“十几个吧，但每个客户用的方式都不一样。我们团队被扯得很散。”

我说：“你可能正在经历第三种死法——同一家公司同时做两条路径。”

他沉默了一会儿：“那你觉得该怎么选？”

这篇文章就是完整的回答。

上周三，一家头部互联网公司的CTO在季度复盘会上盯着一组数据沉默了整整两分钟。

Q1 的 AI 投入报表显示：工程团队 token 消耗同比增长 400%，人均 AI 工具支出逼近 20 万美元/年——已经和一个高级工程师的人力成本持平。但业务端呢？营收增长 35%，客户满意度提升了 8 个百分点。

“我们买了蒸汽机，但跑出来的速度还不如马车。“他最终说了这么一句。

会议室里没人接话。因为所有人都知道，问题不在 AI 技术本身——他们的工程师确实写出了更多代码，做了更多功能。问题在于：组织的工作方式没有变。AI 被塞进了旧的流程、旧的考核、旧的管理思维里，变成了"更贵的自动化”。

这不是个例。2026 年硅谷一线的最新观察揭示了一个残酷现实：AI 技术迭代已经进入"周级范式转换”，但绝大多数企业的组织形态还停留在"年度规划+季度复盘"的工业时代节奏里。技术跑得太快，组织跟不上，中间的鸿沟正在吞噬 AI 本该带来的价值。

上周三晚上 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 年的计算机专业同学的。我会给你一个可以从 今天 就开始执行的成长路径。

最近钉钉内部做了一次 AI 能力摸底。结果出乎很多人意料——那些平时代码写得最溜、技术栈最广的工程师，在解决客户问题的 AI 协同效率上反而不如几个产品同学和前线服务客户的同学。

我观察了一个细节：区分高下最明显的指标，不是 prompt 写得有多长多花哨，而是他们向 AI 提出的问题本身的质量。

技术强的同学倾向于问：“帮我写一个 Python 脚本，读取 CSV 文件，按日期分组，输出统计报表。"——这是执行指令，不是提问。

而得分最高的一个产品同学问的是：“我现在有一个用户行为日志，想找出哪些功能改版后使用率下降了。你觉得我应该从哪些维度分析？有什么常见的分析陷阱？"——这是真正的提问，它打开了一个探索空间。

这个观察让我意识到一个反直觉的判断：评估一个人是否是 AI 人才，最可靠的指标不是他会用多少 AI 工具，而是他提问的能力。

上周团队在规划 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 通信的，协议是什么，为什么这么设计。