昨天我用 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]如果把 Agent 拆解成一个公式，最简单的表达就是：
Agent = Model + Harness
Model 负责思考、推理、决策；Harness 负责循环控制、工具路由、状态管理。过去一年，社区的目光几乎全部聚焦在 Model 上——谁的能力强、谁更便宜、谁上下文更大。但 Anthropic 工程团队最近发布的 Managed Agents 架构文章揭示了一个被忽视的事实：
“Harnesses encode assumptions about what Claude can’t do on its own. Those assumptions go stale as models improve.”
Harness 编码了关于"模型做不到什么"的假设，而这些假设会随着模型能力提升而迅速过时。一个更有趣的推论是：模型越强，Harness 的设计就越重要——因为越强的模型需要越精密的控制结构，才能把能力转化为可靠的产出。
这篇文章从 Anthropic 的工程实践出发，拆解 Agent 架构的核心设计模式，以及"面向未来的 Harness"到底长什么样。
[Read More]昨天我写了一篇《用 LLM 构建程序化知识系统》，提出「记忆 · 知识 · 技能」三层架构。文章发出后不到 24 小时，两个重量级项目几乎同时进入我的视野——YC 总裁 Garry Tan 开源了 GBrain，EverMind 团队发布了 EverOS。
更巧的是，这两个项目恰好代表了 AI Agent 长期记忆的两条截然不同的技术路线：一条是"用自然语言指令驱动 LLM 自行理解"，另一条是"用工程架构确定性落地"。它们互为镜像，又互相矛盾。
[Read More]上周我让 AI Agent 帮我写博客。它干得不错——风格、结构、代码规范都对。因为我之前花了一个下午，让它读完我的 174 篇旧文，把写作风格提炼成了一份可执行的 Skill 文件。
第二天我让它再写一篇，它又对了。第三天，还是对的。到第四天，我发现了一件有意思的事：它自己改了 Skill 文件。它在"反模式"列表里新增了一条——“不要用’随着 AI 的发展’开头”——这是前几次我手动纠正过的，但我从来没有明确要求它把这个规则写进去。
那一刻我意识到，这个 Agent 已经不是在"执行指令"了。它在积累经验。
但紧接着我遇到了下一个问题：它记住了"怎么写文章"，却不记得"上次写了什么"。我让它写一篇关于 Agent 进化的文章，它洋洋洒洒写了 800 行——和三天前那篇重复了 60%。技能在进化，记忆在归零，知识没有沉淀。三条腿，只长了一条。
这个经历让我重新审视了一个问题：我们到底需要怎样的知识架构，才能让 Agent 真正"越用越强"？不是靠更大的上下文窗口，不是靠更贵的模型，而是一套程序化的记忆、知识与技能管理系统。
Karpathy 和社区最近的两个项目——让 Agent 一晚自主迭代 100 次实验的 autoresearch，和把任意文件夹变成可查询知识图谱的 graphify（25k+ stars）——也在指向同一个方向。
[Read More]上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。
我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。
这不是某个工具的 bug。这是当前所有 AI Agent 的共同困境：Agent 的记忆被钉死在了设备上。
[Read More]去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。
他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”
这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。
[Read More]