上周团队里的某同事给他的 AI Agent 加了一个"帮我总结这个网页"的功能。用户发一个 URL，Agent 自动打开、提取内容、生成摘要。听起来很简单对吧？
结果上线第一天就翻车了。
一个用户发了一个 GitHub 仓库链接，Agent 用浏览器沙箱打开了仓库首页，截取了 README 的前几屏，然后用一个 7B 的轻量模型生成了摘要——完全忽略了仓库里真正的核心代码和 issue 讨论。用户等了 40 秒，得到了一段废话。
同一个功能，另一个用户发了一个新闻网站链接，这次 Agent 反而用了最强的推理模型去处理——一个纯文本提取任务，花了不必要的 token 费用，还因为推理模型的"过度思考"把简单的新闻摘要写成了一篇分析报告。
某同事跑来找我：“模型能力明明够了，为什么用户体验这么差？”
我说：“你的问题不是模型不行，是你没有给任务找到合适的模型和执行环境。你缺的是一个推荐系统。”
[Read More]上周一个计算机大四学生加我钉钉问：“朱老师，我们宿舍最近吵翻了。一个室友说现在 Cursor 能秒写算法题，刷 LeetCode 是浪费时间，应该去学系统设计；另一个说大厂面试还在考八股，老老实实刷题才靠谱。我已经拿了 offer，再过 4 个月入职——我现在应该学什么？”
这个问题很典型。它背后其实藏着一个更深的认知误区——把"写代码"和"做架构"看作两个独立的阶段，仿佛 AI 替代了前者，后者就可以直接上手。
但真相恰恰相反。AI 不是让你跳过写代码，而是让你在写代码的过程中，同时训练架构思维。 传统的架构师成长路径是"先写 5 年代码，再学系统设计"，而 AI 时代的路径是"从你写第一行代码起，就让 AI 帮你同时跑两条线"。
这篇博客就是写给正在毕业、或者刚入职 1-2 年的计算机专业同学的。我会给你一个可以从 今天 就开始执行的成长路径。
[Read More]最近钉钉内部做了一次 AI 能力摸底。结果出乎很多人意料——那些平时代码写得最溜、技术栈最广的工程师，在解决客户问题的 AI 协同效率上反而不如几个产品同学和前线服务客户的同学。
我观察了一个细节：区分高下最明显的指标，不是 prompt 写得有多长多花哨，而是他们向 AI 提出的问题本身的质量。
技术强的同学倾向于问：“帮我写一个 Python 脚本，读取 CSV 文件，按日期分组，输出统计报表。"——这是执行指令，不是提问。
而得分最高的一个产品同学问的是：“我现在有一个用户行为日志，想找出哪些功能改版后使用率下降了。你觉得我应该从哪些维度分析？有什么常见的分析陷阱？"——这是真正的提问，它打开了一个探索空间。
这个观察让我意识到一个反直觉的判断：评估一个人是否是 AI 人才，最可靠的指标不是他会用多少 AI 工具，而是他提问的能力。
[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]上周我让 Claude Code 帮我跑一遍我的 Tauri 笔记应用的回归测试。给它的任务很简单：「新建一条笔记，输入’hello’，保存，重启应用，验证笔记还在」。
它失败了。不是因为应用有 bug，而是因为它根本看不见这个应用——它能启动进程、能截屏，但屏幕里的「新建按钮」对它来说是一团像素；它知道「保存」这个动词，但不知道怎么把这个动词翻译成 IPC 调用；它甚至不知道「重启之后笔记是否还在」这件事该去哪里查证。
那一刻我意识到：让 AI 测试一个应用，瓶颈从来不在 AI 的能力，而在于这个应用本身是否「可被 AI 测试」。这是一种新的工程属性，我把它叫做 AI Test Ready。
[Read More]2023 年，你需要写一个爬虫：requests 发请求 → 正则解析 HTML → 异常处理 + 重试，300 行代码，每行都是你写的。
2025 年，你告诉 Agent：「把某网站上最近 100 篇文章的标题和链接存到 CSV 里」，它自己写代码、调试、跑通、交付结果。
问题来了：到底哪一段代码是你「写」的？
这不是编程工具的升级，而是软件开发范式的根本性转移。Karpathy 在 2017 年提出「Software 2.0」时说：神经网络是程序员用数据写出的程序。但八年后的今天，2.0 已经不够用了——因为系统不再只是「被训练」，它们开始「自己决定怎么做」。
我把这个演进分为四个阶段：
[Read More]