AI Agent on All about Raspberry Pi

AI 时代的个人知识管理最佳实践：从笔记仓库到认知操作系统

Tue, 19 May 2026 00:00:00 +0000

AI 时代，个人知识管理（PKM）正在经历一场根本性的范式转移。

最大的变化不是「记笔记的方式变了」，而是：

你需要开始经营一套「可被 AI 理解、调用、推理、持续学习」的个人上下文系统。

过去的知识管理是为「人脑回忆」设计的——核心动作是分类、收藏、归档。 AI 时代，知识管理是为「人 + AI 协同工作」设计的——核心变成了上下文（Context）、可计算（Computable）、可演化（Evolving）、可调用（Actionable）。

很多人还停留在 Obsidian 堆 Markdown、Notion 堆页面、收藏 5000 篇文章然后让 AI 帮忙总结的阶段。但真正有价值的，是一整套 AI 原生的知识管理体系。

这篇文章从工程视角出发，拆解 AI 时代个人知识管理的核心目标、架构设计和五项可落地的最佳实践。

悟空技巧十五：从「记录系统」到「经营系统」，企业 AI Agent 的终极形态

Tue, 19 May 2026 00:00:00 +0000

过去二十年，企业软件的核心使命是**「记录」**。

ERP 记录财务流水，CRM 记录客户关系，OA 记录审批流程，HR 系统记录考勤和绩效。这些系统回答了同一个问题：「发生了什么？」

但它们从来不回答另一个更重要的问题：「接下来该做什么？」

决策依然靠人。老板看报表、开会、拍脑袋。系统只是「记录员」，不是「经营者」。

AI Agent 的出现正在改变这个范式。当 AI 能够 7×24 小时持续推理、自动执行业务动作、并对经营结果负责时，企业购买的不再是「软件许可证」，而是**「持续在线的经营能力」**。

这就是「悟空云端」的核心定位：企业经营型 AI Agent 平台（Business Operating Agent）。

在前面的十四篇文章中，我们从需求澄清、多 Agent 编排、可观测性到成熟度模型，构建了 AI 协作的完整技术体系。

今天，我们推出系列的第十五篇：从技术视角解读「经营型 Agent」的架构设计、行业落地路径和核心壁垒，探讨企业 AI Agent 的终极形态。

通用桌面 Agent 新用户激活：首次任务推荐引擎设计

Mon, 18 May 2026 00:00:00 +0000

通用桌面 Agent（Desktop AI Agent）的推广面临一个经典的增长难题：用户安装后，面对一个"什么都能做"的空白界面，往往不知道该让它做什么，最终流失。

本文从工程实践角度，探讨如何基于用户画像（行业、部门、层级、企业规模、城市、常用应用、工作任务、技能水平）构建首次任务推荐引擎，最大化新用户的点击转化率和激活率。

AI Agent使用的复利效应：为什么第二步的「无用功」最值得投入

Sat, 16 May 2026 00:00:00 +0000

HashiCorp 的 Mitchell 把自己的 AI 使用历程分成六个阶段。他不是那种用了就觉得好的人，每个阶段都带着怀疑和验证。六步走完后，他得出了一个反直觉的结论：最痛苦、看起来最「无用」的第二步，恰恰是后续一切复利的起点。

大多数人从第一步直接跳到第四步 —— 觉得 AI 好用就开始委托任务。Mitchell 却在第二步花了大量时间做冗余工作：已经手动完成的事，再让 Agent 做一遍。原文说「I literally did the work twice」。目的不是省时间，是建立对 Agent 能力边界的真实认知。

正是这个阶段的「无用功」，让后续每一步都产生了指数级的复利效应。

基础设施比模型更重要：Stripe Minions 给 AI Agent 落地的启示

Sat, 16 May 2026 00:00:00 +0000

昨晚在电子书上读到一段关于 Stripe Minions 的文字，让我停下来想了很久。

不是因为它用了什么惊艳的模型，而是因为它揭示了一个被大多数人忽略的事实：

Minions 能 work 的首要原因跟 AI 模型本身几乎无关，而是 Stripe 在 LLM 出现之前就为人类工程师建设了多年的基础设施。

完整的代码树、成熟的构建系统、全面的测试覆盖、标准化的开发环境——这些不是为 AI 准备的，是十多年来为人类工程师准备的。AI Agent 到来时，直接继承了这套基础设施。

好的人类工程基础设施，就是好的 AI 工程基础设施。

企业级 Agent 落地：要抓好左右手

Wed, 13 May 2026 00:00:00 +0000

上周和一个做企业数字化的朋友吃饭。他公司去年花了两百多万，引入了一套"AI Agent 平台"。

销售演示的时候很惊艳：对着对话框说一句话，系统就能生成报表、审批流程、甚至写 SQL 查数据。

上线三个月后，他告诉我：

“员工用了两周就放弃了。现在那个系统成了公司最贵的摆设。”

我问他：系统出 Bug 了？

他说：不是。是系统不会变聪明。

第一个月，Agent 回答问题的准确率大概 70%。第二个月还是 70%。第三个月，员工发现问同样的问题，得到的答案一模一样——系统完全没有从实际使用中学到任何东西。

“它就是个会说话的自动化脚本。”

这句话戳中了一个很多人不愿承认的事实：

今天市面上 90% 的"企业 Agent"，本质上只是给 LLM 套了个聊天框。

中国 SaaS 厂商的护城河应该怎么建

Tue, 12 May 2026 00:00:00 +0000

上周和一位做 HR SaaS 的创始人吃饭。他抛出一个困扰了很久的问题：

“我们的 AI 简历解析准确率比竞品高 8%，但客户续约率还是在掉。竞品三个月就追平了准确率，价格还低 20%。技术优势在中国到底能维持多久？”

我给的回答很直接：6 到 12 个月。 然后就没有了。

这不是悲观，而是现实。中国企服市场的迭代速度让任何纯技术壁垒都迅速商品化。如果你的护城河是"我们的模型更准"“我们的算法更快”，那这条河很快就会干涸。

这篇文章，我想系统回答一个问题：在中国做 SaaS，到底什么才是真正的护城河？

红杉 2026 AI Keynote 启示录：中国 SaaS 的扩散差距与 Agent 重构

Mon, 11 May 2026 00:00:00 +0000

上周六深夜，我通过钉钉听记完整记录了红杉资本 2026 AI Keynote。35 分钟的演讲中，有一个词反复刺痛了我：Diffusion Gap（扩散差距）。

演讲者说：“基础模型能力的增长速度，远超企业采用速度。”

这句话翻译成中国 SaaS 市场的语境就是：你的客户还在用 Excel 管客户、用微信群发通知、用邮件批流程，而 AI Agent 已经能自主完成端到端任务了。这个差距不是 bug，是未来三年最大的商业机会。

AI 时代运营的本质：影响人群价值观

Fri, 08 May 2026 00:00:00 +0000

上个月和一个做电商运营的朋友聊天。她团队有 8 个人，每天忙的事情是：拉数据、做报表、调投放参数、写推送文案、设计活动页面。

我问她：「你觉得自己最重要的工作是什么？」

她想了想说：「理解用户想要什么。」

我说：「那你团队 80% 的时间都没花在这件事上。」

她沉默了。

这不是她一个人的问题。过去十年，运营这个岗位被大量低价值的重复工作绑架了。数据要手动拉，报表要手动做，渠道要手动调，文案要手动写。运营人员变成了流程的执行者，而不是策略的思考者。

但今年，情况正在发生根本性的变化。

大模型能力的跃迁和 Agent 生态的成熟，正在把运营从重复劳动中解放出来。低价值的流程性工作可以实现完全自动化，无需依赖技术人员支持。运营人员利用 AI 工具，可以 10 倍速度提升数据获取和分析的效率，做更精细化的人群和渠道分层，让洞察和策略更精准。

运营的本质，终于有机会回归它本来的样子：影响人群的价值观。

Agent-as-a-Judge：自进化Agent的眼睛

Thu, 07 May 2026 00:00:00 +0000

上周，一个朋友的团队遇到了这样一件事：他们部署了一个 Coding Agent，让它独立完成一个微服务模块的重构。Agent 跑了整整 6 个小时，提交了 47 个 commit，改了 2000 多行代码。第二天早上，Tech Lead 打开 PR，看着满屏的 diff，沉默了五分钟，说了一句：“我怎么知道它中间做对了什么、做错了什么？”

这不是个例。随着 Agent 能处理的任务越来越长、越来越复杂，一个被忽略的问题浮出水面：谁来评估 Agent 的工作？

To B 的生意只有两种

Mon, 27 Apr 2026 00:00:00 +0000

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

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

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

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

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

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

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

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

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

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

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

Agent 如何同时活在钉钉、Telegram、Discord 和微信里？

Sun, 19 Apr 2026 00:00:00 +0000

上周团队在规划 Agent 的多渠道接入方案。有人说"每个 IM 写一套 adapter"，有人说"统一用 Webhook 接收然后标准化"。

我打开 Hermes Agent 的代码仓库，gateway/platforms/ 目录下躺着 18 个平台适配器——从 Telegram、Discord 到钉钉、飞书、企业微信、QQ 机器人，甚至还有 iMessage（BlueBubbles）、Signal 和 Home Assistant。

“所有平台共享同一个 Agent Loop，同一套 Session 管理，同一套工具调用。”

他们问：“那 18 个 adapter 之间代码复用率有多少？”

我给他们看了一张图。

解构 Agent CLI：从 React 子进程到 Python 回调的通信协议

Sun, 19 Apr 2026 00:00:00 +0000

上周团队在讨论 Agent 产品的交互方案。前端同学主张用 Web UI + WebSocket，理由是现代、可扩展、支持多端。后端同学说那不如直接嵌到现有产品里，用 HTTP REST API。

我打开了我们自己的 Agent 代码仓库，给他们看了两套实现——一套是纯 Python 的同进程架构，另一套是 React + Python 子进程通过 JSON-RPC 通信。

“我们同一个产品里，两套通信协议并存。”

他们沉默了几秒。“为什么？”

因为这不是架构设计的失误，而是交互范式的必然分化。CLI 要的是零延迟的本地体验，TUI 要的是跨进程的事件驱动架构。用一套协议去套两种场景，只会两头都不讨好。

今天我们就来解剖一下 Hermes Agent 的两种交互架构——看看 CLI 和 TUI 分别是怎么和 Agent Loop 通信的，协议是什么，为什么这么设计。

Agent 的 Skill 自进化机制：它是如何自己长记性的

Sat, 18 Apr 2026 00:00:00 +0000

昨天我用 Agent 处理一个棘手的部署任务。它第一次跑的时候踩了个坑——少了一步 docker login，推送镜像时报错了。Agent 发现问题，自己补上登录步骤，重试后跑通了。

但最让我惊讶的不是它跑通了，而是它默默更新了自己的操作手册。

下一次我再让它做同样的任务时，它直接带上了 docker login，一步到位。

它自己"长记性"了。

这不是魔法，是 Hermes Agent 的 Skill 自进化机制。它把一次性的试错经验，固化成了可复用的程序化记忆。

LLM Agent 上下文压缩算法

Sat, 18 Apr 2026 00:00:00 +0000

跑了一个长对话 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 行代码，每一步都有对应的失败案例和修复注释。

OpenCLI vs AutoCLI：把网站变成 CLI 的技术革命

Sat, 18 Apr 2026 00:00:00 +0000

上周给 DingTalk 的一个内部项目做技术调研，需要从知乎、B站、小红书几个平台拉热榜数据做竞品分析。同事的第一反应是写爬虫——打开 Playwright，找 CSS 选择器，处理登录态，和 Cloudflare 斗智斗勇，折腾了两小时还没跑通。我看了看他的代码，说：“换个思路，试试 OpenCLI，opencli zhihu hot 一行命令就完了。”

一查这个项目——GitHub 上 16K stars。再看 AutoCLI（OpenCLI 的 Rust 重写版）的性能数据：bilibili hot 命令，OpenCLI 要 20 秒，AutoCLI 只要 1.66 秒，12 倍加速。

更令人震惊的不是性能数字，而是这两个项目背后的技术范式转变——它们不是在"做更好的爬虫"，而是在重新定义怎么从网站获取数据。

从写代码到定义目标：软件 1.0 到 3.0 的进化论

Fri, 17 Apr 2026 00:00:00 +0000

2023 年，你需要写一个爬虫：requests 发请求 → 正则解析 HTML → 异常处理 + 重试，300 行代码，每行都是你写的。

2025 年，你告诉 Agent：「把某网站上最近 100 篇文章的标题和链接存到 CSV 里」，它自己写代码、调试、跑通、交付结果。

问题来了：到底哪一段代码是你「写」的？

这不是编程工具的升级，而是软件开发范式的根本性转移。Karpathy 在 2017 年提出「Software 2.0」时说：神经网络是程序员用数据写出的程序。但八年后的今天，2.0 已经不够用了——因为系统不再只是「被训练」，它们开始「自己决定怎么做」。

我把这个演进分为四个阶段：

Agent 的记忆战争：GBrain vs EverOS，两条路线的终局

Tue, 14 Apr 2026 00:00:00 +0000

昨天我写了一篇《用 LLM 构建程序化知识系统》，提出「记忆 · 知识 · 技能」三层架构。文章发出后不到 24 小时，两个重量级项目几乎同时进入我的视野——YC 总裁 Garry Tan 开源了 GBrain，EverMind 团队发布了 EverOS。

更巧的是，这两个项目恰好代表了 AI Agent 长期记忆的两条截然不同的技术路线：一条是"用自然语言指令驱动 LLM 自行理解"，另一条是"用工程架构确定性落地"。它们互为镜像，又互相矛盾。

用 LLM 构建程序化知识系统：记忆、技能与进化

Tue, 14 Apr 2026 00:00:00 +0000

上周我让 AI Agent 帮我写博客。它干得不错——风格、结构、代码规范都对。因为我之前花了一个下午，让它读完我的 174 篇旧文，把写作风格提炼成了一份可执行的 Skill 文件。

第二天我让它再写一篇，它又对了。第三天，还是对的。到第四天，我发现了一件有意思的事：它自己改了 Skill 文件。它在"反模式"列表里新增了一条——“不要用’随着 AI 的发展’开头”——这是前几次我手动纠正过的，但我从来没有明确要求它把这个规则写进去。

那一刻我意识到，这个 Agent 已经不是在"执行指令"了。它在积累经验。

但紧接着我遇到了下一个问题：它记住了"怎么写文章"，却不记得"上次写了什么"。我让它写一篇关于 Agent 进化的文章，它洋洋洒洒写了 800 行——和三天前那篇重复了 60%。技能在进化，记忆在归零，知识没有沉淀。三条腿，只长了一条。

这个经历让我重新审视了一个问题：我们到底需要怎样的知识架构，才能让 Agent 真正"越用越强"？不是靠更大的上下文窗口，不是靠更贵的模型，而是一套程序化的记忆、知识与技能管理系统。

Karpathy 和社区最近的两个项目——让 Agent 一晚自主迭代 100 次实验的 autoresearch，和把任意文件夹变成可查询知识图谱的 graphify（25k+ stars）——也在指向同一个方向。

Agent Context Roaming：桌面Agent与云端Agent协同的理想方式

Mon, 13 Apr 2026 00:00:00 +0000

上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。

我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。