上周六深夜,我通过钉钉听记完整记录了红杉资本 2026 AI Keynote。35 分钟的演讲中,有一个词反复刺痛了我:Diffusion Gap(扩散差距)。
演讲者说:“基础模型能力的增长速度,远超企业采用速度。”
这句话翻译成中国 SaaS 市场的语境就是:你的客户还在用 Excel 管客户、用微信群发通知、用邮件批流程,而 AI Agent 已经能自主完成端到端任务了。这个差距不是 bug,是未来三年最大的商业机会。
[Read More]上周六深夜,我通过钉钉听记完整记录了红杉资本 2026 AI Keynote。35 分钟的演讲中,有一个词反复刺痛了我:Diffusion Gap(扩散差距)。
演讲者说:“基础模型能力的增长速度,远超企业采用速度。”
这句话翻译成中国 SaaS 市场的语境就是:你的客户还在用 Excel 管客户、用微信群发通知、用邮件批流程,而 AI Agent 已经能自主完成端到端任务了。这个差距不是 bug,是未来三年最大的商业机会。
[Read More]上个月和一个做电商运营的朋友聊天。她团队有 8 个人,每天忙的事情是:拉数据、做报表、调投放参数、写推送文案、设计活动页面。
我问她:「你觉得自己最重要的工作是什么?」
她想了想说:「理解用户想要什么。」
我说:「那你团队 80% 的时间都没花在这件事上。」
她沉默了。
这不是她一个人的问题。过去十年,运营这个岗位被大量低价值的重复工作绑架了。数据要手动拉,报表要手动做,渠道要手动调,文案要手动写。运营人员变成了流程的执行者,而不是策略的思考者。
但今年,情况正在发生根本性的变化。
大模型能力的跃迁和 Agent 生态的成熟,正在把运营从重复劳动中解放出来。低价值的流程性工作可以实现完全自动化,无需依赖技术人员支持。运营人员利用 AI 工具,可以 10 倍速度提升数据获取和分析的效率,做更精细化的人群和渠道分层,让洞察和策略更精准。
运营的本质,终于有机会回归它本来的样子:影响人群的价值观。
[Read More]上周,一个朋友的团队遇到了这样一件事:他们部署了一个 Coding Agent,让它独立完成一个微服务模块的重构。Agent 跑了整整 6 个小时,提交了 47 个 commit,改了 2000 多行代码。第二天早上,Tech Lead 打开 PR,看着满屏的 diff,沉默了五分钟,说了一句:“我怎么知道它中间做对了什么、做错了什么?”
这不是个例。随着 Agent 能处理的任务越来越长、越来越复杂,一个被忽略的问题浮出水面:谁来评估 Agent 的工作?
[Read More]上周和两个做 To B 的朋友吃饭,一个在 Salesforce 生态里做 ISV,一个在做面向中小商家的 SaaS。
做 ISV 的朋友说:“我们今年的策略很简单,盯住那些已经用 Salesforce 用得很好的大客户,帮他们把最后 10% 的定制化需求补齐。客户预算充足,决策链清晰,签一单够吃半年。”
做中小商家 SaaS 的朋友叹了口气:“我们正好相反。客户连 Excel 都不太会用,你得先教他为什么要数字化,再教他怎么用。但好处是,一旦用上了,粘性极高,因为他自己搞不定。”
两个人说完,桌上安静了几秒。
我忽然意识到,他们说的其实是同一件事的两个面——To B 的生意,归根结底只有两种:帮成功的人更成功,帮不成功的人成功。
这篇文章写完初稿后,一个做企业级 Agent 的创业者找我聊。他说:“我觉得 Agent 赛道不太一样。我们现在既在做 Copilot 帮员工提效,又在做 Auto Agent 帮企业自动化流程。两条路都在试。”
我问:“你们现在有多少客户?”
他说:“十几个吧,但每个客户用的方式都不一样。我们团队被扯得很散。”
我说:“你可能正在经历第三种死法——同一家公司同时做两条路径。”
他沉默了一会儿:“那你觉得该怎么选?”
这篇文章就是完整的回答。
[Read More]上周团队在规划 Agent 的多渠道接入方案。有人说"每个 IM 写一套 adapter",有人说"统一用 Webhook 接收然后标准化"。
我打开 Hermes Agent 的代码仓库,gateway/platforms/ 目录下躺着 18 个平台适配器——从 Telegram、Discord 到钉钉、飞书、企业微信、QQ 机器人,甚至还有 iMessage(BlueBubbles)、Signal 和 Home Assistant。
“所有平台共享同一个 Agent Loop,同一套 Session 管理,同一套工具调用。”
他们问:“那 18 个 adapter 之间代码复用率有多少?”
我给他们看了一张图。
[Read More]上周团队在讨论 Agent 产品的交互方案。前端同学主张用 Web UI + WebSocket,理由是现代、可扩展、支持多端。后端同学说那不如直接嵌到现有产品里,用 HTTP REST API。
我打开了我们自己的 Agent 代码仓库,给他们看了两套实现——一套是纯 Python 的同进程架构,另一套是 React + Python 子进程通过 JSON-RPC 通信。
“我们同一个产品里,两套通信协议并存。”
他们沉默了几秒。“为什么?”
因为这不是架构设计的失误,而是交互范式的必然分化。CLI 要的是零延迟的本地体验,TUI 要的是跨进程的事件驱动架构。用一套协议去套两种场景,只会两头都不讨好。
今天我们就来解剖一下 Hermes Agent 的两种交互架构——看看 CLI 和 TUI 分别是怎么和 Agent Loop 通信的,协议是什么,为什么这么设计。
[Read More]昨天我用 Agent 处理一个棘手的部署任务。它第一次跑的时候踩了个坑——少了一步 docker login,推送镜像时报错了。Agent 发现问题,自己补上登录步骤,重试后跑通了。
但最让我惊讶的不是它跑通了,而是它默默更新了自己的操作手册。
下一次我再让它做同样的任务时,它直接带上了 docker login,一步到位。
它自己"长记性"了。
这不是魔法,是 Hermes Agent 的 Skill 自进化机制。它把一次性的试错经验,固化成了可复用的程序化记忆。
[Read More]跑了一个长对话 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 行代码,每一步都有对应的失败案例和修复注释。
上周给 DingTalk 的一个内部项目做技术调研,需要从知乎、B站、小红书几个平台拉热榜数据做竞品分析。同事的第一反应是写爬虫——打开 Playwright,找 CSS 选择器,处理登录态,和 Cloudflare 斗智斗勇,折腾了两小时还没跑通。我看了看他的代码,说:“换个思路,试试 OpenCLI,opencli zhihu hot 一行命令就完了。”
一查这个项目——GitHub 上 16K stars。再看 AutoCLI(OpenCLI 的 Rust 重写版)的性能数据:bilibili hot 命令,OpenCLI 要 20 秒,AutoCLI 只要 1.66 秒,12 倍加速。
更令人震惊的不是性能数字,而是这两个项目背后的技术范式转变——它们不是在"做更好的爬虫",而是在重新定义怎么从网站获取数据。
[Read More]2023 年,你需要写一个爬虫:requests 发请求 → 正则解析 HTML → 异常处理 + 重试,300 行代码,每行都是你写的。
2025 年,你告诉 Agent:「把某网站上最近 100 篇文章的标题和链接存到 CSV 里」,它自己写代码、调试、跑通、交付结果。
问题来了:到底哪一段代码是你「写」的?
这不是编程工具的升级,而是软件开发范式的根本性转移。Karpathy 在 2017 年提出「Software 2.0」时说:神经网络是程序员用数据写出的程序。但八年后的今天,2.0 已经不够用了——因为系统不再只是「被训练」,它们开始「自己决定怎么做」。
我把这个演进分为四个阶段:
[Read More]