企业官网建设流程全解析

开篇

之前写了一篇思考文章《从 Perplexity 看「以用户为中心」的新型商业模式》，当时是读了一篇讲 User-Centric Agent 的论文，加上 Aravind 的一场访谈，总结了几个判断：

1. AI 服务要从「用户 → 平台」变成「用户 → Agent → 平台」

2. 平台中心化的根本问题是被困在碎片化日志里，比如淘宝不知道你刚在小红书干了什么

3. 第三方 Agent 靠爬虫和模拟点击走不远，平台不会心甘情愿交出入口

半年过去，这件事好像有了名字：Personal Agent。🤔

Personal Agent 的上下文要围绕「人」

Personal Agent 和办公 Agent 最本质的区别，就是在上下文怎么组织。

办公 Agent 的上下文是围绕任务：修一个 Bug，就读相关代码、报错和测试文件，任务结束，这组上下文的作用也就结束了。但是 Personal Agent 的上下文要围绕人：它不仅要知道你这次要订酒店，还要知道你过去住什么样的酒店、预算大概多少；一件事隔了几周，不能因为对话结束就从零开始。

这里问题就来了：这个围绕「人」的上下文，要从哪来呢？

现在常见的 agent 有两条路。一条是和它聊天，它慢慢积累记忆；另一条就是连接器，授权它读邮件、日历、订单，它从这些数据里自己去判断。

但它们都是碎片化且是被动的。你在 ChatGPT 里花两年积累的记忆，换一个 Agent 就要重新再教一遍。记忆是 Agent 的副产品，锁在某家产品里，而不属于你。

并且一个人的数字生活散在十几个地方：公众号、小红书、微信、知乎、GitHub、笔记软件...每个平台都只有一部分，而且平台之间互不开放。

所以现在 Personal Agent 更像是「有手有脚、但不知道自己在替谁做事」。它能行动，但它对你的认识是从零开始、一点点攒出来的，而且攒出来的东西还很难带走。☹️

Agent 替你做事之前，先得有一份「关于你的知识库」

所以，Personal Agent 需要一个对应物：一份属于本人的、机器可读的、由本人维护的、跨平台的知识库，Agent 不需要再从零认识你，它来读这份知识库就行了。

这个想法听起来好像很古老：把自己的一切整理到一个地方。从 1945 年 Vannevar Bush 的 Memex，到微软研究院 2001 年起让 Gordon Bell 把一辈子的信件、照片、通话全部数字化的 MyLifeBits，试了八十年，没有一次真正普及。原因很一致：不是采集难，是维护难。交叉引用要更新，旧说法被新说法推翻要标记，分类要保持一致...

今年 4 月 Andrej Karpathy 发了一个叫 llm-wiki 的 gist，回答的就是这个问题。RAG 要每次提问都从原始文档重新检索、重新拼凑，没有积累；而他的这个替代方案是让 LLM 持续维护一个 wiki。👇

三层结构非常简单：

• raw 层：原始素材，你负责放进去，不可修改，是事实来源。

• wiki 层：由 LLM 生成和维护的 Markdown 页面——摘要、实体、概念、对比、综述，互相链接。你读，LLM 写。

• schema 层：一份约定文件，告诉 LLM 目录怎么组织、页面什么格式、新素材进来要做哪几步。

对应着有三个动作：

1. 新素材进来叫 Ingest，LLM 读完更新所有被波及的页面；

2. 提问叫 Query，LLM 先读目录再钻页面，好的回答回填成新页面；

3. 定期体检叫 Lint，找页面之间的矛盾、被新来源推翻的旧说法、没人引用的孤页。

👉 Bush 的 Memex 没解决的是「谁来维护」，现在 LLM 来维护。

Karpathy 的 wiki 第一条写的就是「Personal：归档日记、文章、笔记，随时间建立一幅关于你自己的结构化图景」。这样来看，一份关于自己的 wiki 里可以至少包含这些：

• 身份和经历：你是谁、做过什么、什么时候做的。

• 作品：你写过的、做过的、能拿出来的东西，以及它们最早出现在哪里。

• 长期观点：你对一些事情怎么看。但这里有一个要紧的细节：要标清楚哪些是事实、哪些是你的判断、哪些只是猜想，以及每条是什么时候形成的、后来变没变。（一个人的观点是会变的，一份好的知识库不应该把你描述成一个永远正确的人，而应该保留变化本身。）

• 偏好和约束：你的预算、你的禁忌、你不希望 Agent 替你做的事。

它和 Agent 记忆的关系是：知识库是记忆的上游。记忆是 Agent 在使用过程中产生的、属于 Agent 的；而知识库是你主动整理的、属于你的，Agent 来读它、在此基础上再积累记忆。换 Agent 的时候，记忆可能丢，但知识库不会。

有技术能力的人可以自己做，没有的人怎么办？

对于有技术能力的人，这件事完全能自己动手：把散落各处的内容收到一个地方，按 Karpathy 那种方式整理，再让 Agent 去读。

但绝大多数人可能不会去为此写代码。那他们的那一份从哪里来呢？可能会有三种形式：

第一种，平台托管。比如小红书给每个创作者生成一份机器可读的档案，微信给每个人一个 Agent 可读的名片。这个的门槛几乎为零。但它的问题也是 3 月那篇的结尾说的，刚逃出一个围墙花园，又掉进另一个： 格式由平台定义，哪些字段开放由平台决定，在小红书的那一份和在微信的那一份还是两片。平台会以帮用户的名义做这件事，但做出来的东西首先服务于平台。

第二种，工具层。Notion、飞书、印象笔记这类本来就在用的工具，加一个「发布为个人档案」的按钮；或者更底层，操作系统来做。Apple Intelligence 那种系统级上下文，天然能看到所有 App 的活动。这一种比平台托管中立一些，但系统级的方案又回到了 OS 巨头降维打击的老问题：操作系统能看到所有 App 的活动，这既是它做个人上下文的优势，也意味着谁能读这份上下文、读多少，都由它说了算。😶‍🌫️

第三种，Agent 自己成为那一份。Agent 不只替你做事，它开始持有你的身份，别人的 Agent 直接来问你的 Agent。但这同样会带来一个问题，就是当一个 Agent 声称代表你回答「你怎么看某件事」时，它说的到底是你写过的事实，还是它凭自己的理解补全的？

这个问题，在 Karpathy 的 gist 评论区里有一条很有意思的经验：有人照着做了一个实现，第一版把 Ingest 做成黑盒，用户的反应是「AI 在背后改我的笔记」；第二版改成每次先列出它准备改什么，你批准了才写，作者说这是他做过的最大的信任改进。

还是协议层的问题，但多了一层

3 月那篇文章最后，结论是主权在协议层：谁定义意图级 API 的格式、谁控制归因和结算规则，谁才是主权者。现在再看，这个结论要再加一层：除了「意图」的格式，还有「人」的格式。

Personal Agent 要向平台证明“我代表这个用户”，但用户允许你代表我，不等于平台承认你可以进来。关于「我是谁」的知识库面对的是同一个问题：谁来承认这一份代表这个人？如果格式由每家平台各自定义，那一个人就会有十几个互不兼容的“我”，Agent 读哪一个？如果有一个开放格式，那它才真正属于人而不是平台。

但开放格式在商业上总是弱的。所以一个统一的标准不一定会出现，更可能的是：平台各做各的，工具层做一些桥接，少数人自己维护一份完整的，而大多数人的“我”继续散落着。

但不管容器是什么，一个人的信息要被 Agent 准确理解，就需要被结构化地表达。哪条是事实、哪条是判断、什么时候形成的、后来变没变、哪些能公开。这些格式问题不会因为换了容器就消失。

最后

也许现在就需要开始有意识地把散落的东西往一个地方收，不用等平台给你一份，可以先有一份粗糙的。记忆是 Agent 的，但知识库是你的。先有知识库，再谈个人 Agent。