上周团队在规划 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]