A Home for Personal Context个人上下文的归宿

Every agent I use is building a model of me. Claude has learned how I like my prose. ChatGPT remembers what I’m working on. I don’t mind this—every person I have a relationship with carries a model of me in their head, and every company I do business with keeps a profile. Other people’s understandings of me have never been mine to control, after all.我使用的每一个智能体（agent）都在构建一个关于我的模型。Claude 已经学会了我喜欢的文风；ChatGPT 记得我正在处理的工作。我不介意这一点——我交往的每个人脑海中都有一个关于我的模型，我打交道的每家公司也都保留着一份关于我的资料。毕竟，别人对我的理解从来都不是我所能控制的。

But an agent occupies a different role. It learns my writing style, my preferences, and the shape of my work and life, all to help me with what I do. Yet if I switch products, I have to start over. If I use three agents, each rebuilds from scratch what the others already know. Everything an agent learns lives with its vendor.但智能体扮演着不同的角色。它学习我的写作风格、偏好以及我的工作和生活形态，一切都是为了辅助我的工作。然而，如果我更换产品，就必须从头开始。如果我同时使用三个智能体，每个智能体都会将其他智能体已经掌握的信息从零开始重建一遍。智能体学到的一切都留在了它的服务商那里。

It doesn’t need to be this way. What if every person had a canonical, user-controlled repository of context that any agent could request permission to use? What if my context lived not only with the company providing the agent but also in a home under my control? And what if an observation captured by one agent could be proposed to that repository and, once accepted, made available to every other agent I choose?情况本不必如此。如果每个人都有一个标准的、用户可控的上下文存储库，任何智能体都可以请求权限使用它，会怎样？如果我的上下文不仅存在于提供智能体的公司，还存在于我控制的“家”中，会怎样？如果一个智能体捕获的观察结果可以被提交到该存储库，并且一旦被接受，就能提供给我选择的其他所有智能体使用，又会怎样？

By user-controlled, I don’t necessarily mean self-hosted. I mean that I can inspect what the repository contains, decide who can read or change it, understand where each piece came from, and export the whole thing in a form I can take elsewhere. Its storage, identity, and synchronization may all be provided by someone else. Control does not require me to operate the infrastructure; it requires that no agent or platform be the only way in—or the only way out.所谓“用户可控”，并不一定意味着要自托管。我的意思是，我可以检查存储库包含的内容，决定谁可以读取或更改它，了解每一条信息的来源，并以一种我可以带走的形式导出整个内容。它的存储、身份验证和同步可以由他人提供。控制权并不要求我亲自运营基础设施；它要求的是，没有任何一个智能体或平台是唯一的入口——或唯一的出口。

The repository wouldn’t be a portable copy of any agent’s internal model of me. It would be a legible record of things I have written, facts and preferences I have chosen to keep, as well as observations that agents have proposed and I have accepted, each with its provenance, scope, and history. Agents could consult or add to that record according to their permissions; their private inferences would remain their own.这个存储库不会是任何智能体内部关于我的模型的便携副本，而是一份我所写内容的易读记录，包含我选择保留的事实和偏好，以及智能体提出并经我接受的观察结果，每一条都带有其来源、范围和历史。智能体可以根据权限查阅或添加记录；但它们私有的推理结果仍属于它们自己。

The dream is not a new one. Tim Berners-Lee’s Solid project has argued for years that personal data should live in pods that people control, and Doc Searls’s VRM project has been making the case for user-driven relationships with vendors for decades. What those efforts never had was mainstream demand. Agents are supplying it: An assistant needs rich personal context to be useful, and each vendor is building that context inside its own walls. Ordinary people now have a reason to want a personal data store, even if nobody will actually call it that.这个梦想并不新鲜。Tim Berners-Lee 的 Solid 项目多年来一直主张个人数据应存储在用户控制的“数据舱”（pods）中；Doc Searls 的 VRM 项目几十年来也一直在为用户驱动的供应商关系奔走。这些努力所缺乏的是主流需求。而智能体正在填补这一需求：助手需要丰富的个人上下文才能发挥作用，而每个供应商都在各自的围墙内构建这种上下文。普通人现在有了想要一个个人数据存储库的理由，即使没人会真的这样称呼它。

The hard problem in all this isn’t syncing or storing data. It’s negotiation. Who can read a given part of my context? Who can add to it, change it, or remove it? Which parts of my life can a particular instance of an agent see? How do I make those decisions in a policy-driven way? And how do I manage them from wherever I happen to be?这一切中的难题不在于同步或存储数据，而在于协商。谁可以读取我上下文的特定部分？谁可以添加、更改或删除它？智能体的特定实例可以看到我生活的哪些部分？我该如何以策略驱动的方式做出这些决定？又该如何从我所在的任何地方管理它们？

But before I could work on negotiation, I had to figure out where my context should live. That’s the question I’ve spent the past year on, and I’ve tried three answers.但在着手解决协商问题之前，我必须先弄清楚我的上下文应该存放在哪里。这是我过去一年一直在思考的问题，我尝试了三种答案。

First answer: The laptop第一个答案：笔记本电脑

Immediately after getting access to Claude Code at the start of 2025, I pointed it at an Obsidian vault—a folder full of Markdown files that can be used as a personal wiki. This wasn’t a particularly novel idea. Many of the geeks I know did the same, and the pattern has since spread in many forms. The best-known recent example is probably Karpathy’s LLM Wiki, elegant not just as a design but as a document: You give the description to your agent, and the agent builds a version tailored to you.2025年初获得 Claude Code 的访问权限后，我立即将其指向了一个 Obsidian 库——一个装满 Markdown 文件的文件夹，可以用作个人维基。这并不是什么特别新颖的想法。我认识的许多极客都做了同样的事，这种模式此后以多种形式传播开来。最近最著名的例子可能是 Karpathy 的 LLM Wiki，它不仅设计优雅，而且作为文档本身也很出色：你将描述提供给智能体，智能体就会为你构建一个量身定制的版本。

A year of using a pile of Markdown text files with agents has taught me five things about what a personal context system has to get right.使用一堆 Markdown 文本文件配合智能体工作了一年后，我总结出了个人上下文系统必须做好的五件事。

Local-first foundations matter. Text files are remarkably legible, portable, and easy to store somewhere I control. Git moves them between computers and remembers every change. But the result is centered on a laptop or desktop and assumes a user comfortable with plain text and version control. Most annoyingly, my context in this form isn’t readily available on my phone, which is the computer that goes with me everywhere. Nor can agents running anywhere other than my laptop reach it.本地优先的基础至关重要。文本文件非常易读、便携，且易于存储在我控制的地方。Git 可以在电脑间移动它们并记录每一次更改。但这种方式以笔记本电脑或台式机为中心，且假设用户习惯于纯文本和版本控制。最令人恼火的是，这种形式的上下文无法在我的手机上随时获取，而手机才是我随身携带的电脑。此外，运行在笔记本电脑之外的智能体也无法访问它。

Provenance matters, and so do proposals. Karpathy’s Wiki is almost entirely written (and rewritten) by the LLM. In my own system, I write most things myself and lean on agents to help me edit as well as contribute their observations. I want to know which thoughts are mine, which were captured by an agent, and which we arrived at together. That means an agent’s observation should not automatically enter the repository on the same footing as something I wrote. The default should be a proposal that I—or a policy I control—can accept, revise, or reject. Direct write access is something a trusted agent should earn.来源至关重要，提案机制也一样。Karpathy 的 Wiki 几乎完全由大语言模型（LLM）编写（和重写）。在我自己的系统中，我大部分内容是自己写的，并依靠智能体来帮助我编辑以及贡献它们的观察结果。我想知道哪些想法是我自己的，哪些是由智能体捕获的，哪些是我们共同得出的。这意味着智能体的观察结果不应自动以与我所写内容相同的地位进入存储库。默认情况应该是一个提案，由我——或我控制的策略——来接受、修改或拒绝。直接写入权限是受信任的智能体应该赢得的权利。

Chronology matters. Wiki links aren’t the only structure in a life. Most of what I record—and much of what agents observe—is anchored in time. Thoughts build on thoughts. Observations about people accumulate meeting by meeting. Some facts fade as they age. Time should be a primary axis of the system, not something reconstructed afterward from file histories and metadata.时间顺序至关重要。维基链接并不是生活中唯一的结构。我记录的大部分内容——以及智能体观察到的大部分内容——都锚定在时间上。想法建立在想法之上。关于人的观察随着一次次会面而积累。有些事实会随着时间推移而淡化。时间应该是系统的核心轴，而不是事后从文件历史和元数据中重建出来的东西。

Scopes matter. My context spans work, personal, family, and public life. I want one unified view; no agent should have one. An agent connected through my work account should see work and public context—and nothing about my family. Fully separate silos would protect those boundaries, but they would also shred the single history I want to keep building for decades.范围至关重要。我的上下文涵盖工作、个人、家庭和公共生活。我想要一个统一的视图；没有任何智能体应该拥有全部权限。通过工作账号连接的智能体应该只能看到工作和公共上下文——而不能看到关于我家庭的任何信息。完全隔离的孤岛虽然能保护这些边界，但也会粉碎我想要持续构建几十年的单一历史。

Identity and type matter. LLMs can extract all sorts of meaning from plain text, but some things, such as people, companies, and places, deserve to be typed records rather than mentions in prose. A persistent identity gives observations, relationships, and history an anchor to accumulate around; it can help resolve nicknames and follow changes in roles and titles. An agent can then act on who someone is without reconstructing them from prose every time.身份和类型至关重要。大语言模型可以从纯文本中提取各种含义，但某些事物，如人、公司和地点，应该作为结构化记录存在，而不是散落在文章中的只言片语。持久的身份为观察、关系和历史提供了一个积累的锚点；它可以帮助解析昵称并跟踪角色和职位的变化。这样，智能体就可以在不每次都从文章中重新构建的情况下，针对某人是谁采取行动。

As I learned these lessons, I added tooling and conventions to my personal context repository. It’s surprising how far you can push a directory of Markdown files. Each new affordance, however, turned my simple folder into a more specialized system, and the result only works for geeks like me. It doesn’t work for my family, however. They use agents every day but they are never going to deal with a pile of Markdown files in a Git repo. They want their personal context to be with them, easy to use, and transparent to the rest of their life.在学习这些经验的过程中，我为我的个人上下文存储库增加了工具和约定。令人惊讶的是，你可以将一个 Markdown 文件目录推向多远。然而，每一个新的功能都将我简单的文件夹变成了一个更专业的系统，其结果只适用于像我这样的极客。它不适用于我的家人。他们每天都在使用智能体，但绝不会去处理 Git 仓库中那一堆 Markdown 文件。他们希望自己的个人上下文能随身携带、易于使用，并且对他们生活的其余部分透明。

More to the point, the five lessons above describe what a context system must do. They don’t answer where it should live if /home/$USER isn’t the center of your computing life.更重要的是，上述五点经验描述了一个上下文系统必须做什么。但如果 /home/$USER 不是你计算生活的中心，它们并没有回答它应该存放在哪里。

Second answer: The web第二个答案：网络

My next move was to sort out how to make my context available when I wasn’t at my laptop—to me and, just as importantly, to my agents. The obvious solution to me as someone who has been building on the web since the mid-1990s: put it on a server behind a URL. I deployed a Cloudflare Worker, uploaded my context, and stood up both a REST API and an MCP server. The improvement was immediate. My context was reachable from my phone and grantable to any agent I chose.我的下一步是解决如何在我不在笔记本电脑旁时，让我自己——以及同样重要的，让我的智能体——能够获取我的上下文。对于一个从 90 年代中期就开始在网络上开发的人来说，显而易见的解决方案是：把它放在 URL 后面的服务器上。我部署了一个 Cloudflare Worker，上传了我的上下文，并建立了一个 REST API 和一个 MCP 服务器。改进立竿见影，我的上下文可以从手机上访问，并可以授权给任何我选择的智能体。

New problems arrived just as fast. I had created a new trust boundary with its own access control mechanism and appointed myself its security team. I was now the operator of a small SaaS with exactly one customer, responsible for its uptime and its backups. And I had traded away local-first, offline editing to get there.新问题随之而来。我建立了一个带有自己访问控制机制的新信任边界，并任命自己为安全团队。我现在成了拥有唯一客户的小型 SaaS 的运营者，负责它的正常运行时间和备份。而且为了实现这一点，我牺牲了本地优先的离线编辑功能。

These are solvable problems. Our industry has spent two decades learning to host services, and CRDTs could probably win back offline editing. But as agents gain access to more sensitive data and more power to act on our behalf, the price of getting a boundary wrong keeps rising.这些都是可以解决的问题。我们的行业花了二十年时间学习托管服务，CRDT（无冲突复制数据类型）可能可以重新实现离线编辑。但随着智能体获得更多敏感数据的访问权限以及更多代表我们行事的权力，边界设置错误的代价也在不断攀升。

And even with those solved, a deeper problem remains: A stand-alone service sits outside my computing home, apart from the contacts, calendars, messages, files, and system-level agents already inside it. Apple’s Siri AI announcements made that separation vivid, and Gemini’s integration into Google’s ecosystem points the same way. An agent embedded in an ecosystem works with everything inside its trust boundary; my worker would have to rebuild every one of those connections from outside.即使解决了这些问题，一个更深层的问题依然存在：一个独立的服务器位于我的计算“家园”之外，脱离了已经存在于其中的联系人、日历、消息、文件和系统级智能体。苹果的 Siri AI 发布让这种分离变得显而易见，Gemini 对谷歌生态系统的整合也指向了同一个方向。嵌入在生态系统中的智能体可以与信任边界内的所有内容协同工作；而我的 Worker 必须从外部重建每一个连接。

Third answer: My pocket第三个答案：我的口袋

As I tinkered, I kept returning to a simple mental image: my context living on the device in my pocket that goes with me everywhere. Not literally every byte, of course, but within the personal computing ecosystem that phone is the center of—the one that already establishes my identity, synchronizes my devices, stores much of my personal data, and mediates what applications can access. In this sense, a home is not a physical location. It is a trust boundary.在折腾的过程中，我一直回到一个简单的心理意象：我的上下文生活在我口袋里那个随身携带的设备上。当然，不是字面上的每一个字节，而是在那个以手机为中心的个人计算生态系统内——那个已经确立了我的身份、同步了我的设备、存储了大部分个人数据并调解了应用程序权限的系统。从这个意义上说，“家”不是一个物理位置，而是一个信任边界。

Living inside the boundary doesn’t mean that every application inside gets my context, or that agents outside are shut out. The boundary supplies identity, secure storage, synchronization, and native integration; the context layer still decides what each connection may read, propose, change, or delete. Native agents participate through the platform’s own capabilities, while agents from other companies connect through explicit, revocable permissions.生活在边界之内并不意味着里面的每个应用程序都能获取我的上下文，也不意味着外面的智能体被拒之门外。边界提供身份验证、安全存储、同步和原生集成；上下文层仍然决定每个连接可以读取、提出、更改或删除什么。原生智能体通过平台自身的能力参与其中，而来自其他公司的智能体则通过明确的、可撤销的权限进行连接。

For me, that home in my pocket is Apple’s ecosystem, with iCloud at its center. For you, it may be Google or Microsoft. The point is not that any one ecosystem is the right home for everyone. It is that most people already have a primary digital home, and that home is the most practical default for their personal context. We shouldn’t need to create a separate service with its own identity. Instead, agents should have a common, permissioned interface to the context where it already lives.对我来说，口袋里的那个“家”是苹果的生态系统，以 iCloud 为核心。对你来说，可能是谷歌或微软。重点不在于某个特定的生态系统是每个人的正确归宿，而在于大多数人已经拥有一个主要的数字家园，而那个家园是他们个人上下文最实际的默认位置。我们不应该需要创建一个带有独立身份的单独服务。相反，智能体应该拥有一个通用的、基于权限的接口，连接到上下文已经存在的地方。

There’s an obvious risk here. A home rooted in a vendor’s ecosystem invites lock-in. The mitigation is straightforward: The whole repository—entities, provenance, and history included—must be exportable at any time as a directory of plain text files that can be taken anywhere. A pile of files in a folder may not be the right solution for live context, but it makes a perfect escape hatch.这里有一个明显的风险。植根于供应商生态系统的家园会招致锁定。缓解措施很简单：整个存储库——包括实体、来源和历史——必须能够随时导出为纯文本文件目录，以便带到任何地方。文件夹里的一堆文件可能不是实时上下文的最佳解决方案，但它提供了一个完美的逃生舱。

I’ve started testing this thesis in a SwiftUI app, and my early prototypes suggest that the architecture is workable: iCloud handles synchronization, and I can expose selected context to authenticated agents through MCP. It’s also shown that working in the Apple developer ecosystem is more annoying than deploying a web app.我已经开始在一个 SwiftUI 应用程序中测试这个论点，早期的原型表明该架构是可行的：iCloud 处理同步，我可以通过 MCP 将选定的上下文暴露给经过身份验证的智能体。这也表明在苹果开发者生态系统中工作比部署 Web 应用程序更令人头疼。

The remaining work is clear, however. Choosing a home for context is one problem; negotiation—permissions that remain understandable as a repository grows, proposals from multiple agents reviewed and reconciled—is another. That is the hard problem I mentioned before, and it deserves its own deep dive.然而，剩下的工作很明确。为上下文选择一个家是一个问题；协商——随着存储库增长而依然易于理解的权限，以及对来自多个智能体的提案进行审查和协调——是另一个问题。这就是我之前提到的难题，它值得进行深入探讨。

One pattern, many homes一种模式，多个家园

Others are converging on this pattern from different directions. The note-taking app Bear, which stores its notes locally on Apple devices and synchronizes them through iCloud, now exposes them to local agents through MCP; its latest release lets users include or exclude notes by tag when granting access, offering a practical approach to scopes. Craft’s MCP connections likewise let users choose which documents or spaces an agent can access and whether it can read or write them. Reflect has embarked on an open source client using Markdown files that will have an iOS companion app.其他人正从不同方向向这种模式靠拢。笔记应用 Bear 将笔记本地存储在苹果设备上并通过 iCloud 同步，现在它通过 MCP 将笔记暴露给本地智能体；其最新版本允许用户在授予访问权限时按标签包含或排除笔记，这提供了一种实用的范围界定方法。Craft 的 MCP 连接同样允许用户选择智能体可以访问哪些文档或空间，以及它是否可以读取或写入。Reflect 则启动了一个使用 Markdown 文件的开源客户端，并将推出 iOS 配套应用。

These are just a few examples, and there are a lot more out there. What I haven’t yet seen emerge however is the attribution and provenance of items that an agent contributes or edits that I think a durable personal context requires.这些只是几个例子，还有很多。然而，我尚未看到智能体贡献或编辑的项目所需要的归属和来源（provenance）机制出现，而我认为这是持久的个人上下文所必需的。

Zooming out, here are the principles I think are needed in any system like this, wherever it makes its home:放眼全局，我认为任何此类系统都需要遵循以下原则，无论它以何处为家：

1. Context shouldn’t be captive to any particular agent. A person should be able to change or combine agents without ever starting over.上下文不应被任何特定的智能体所俘获。一个人应该能够在不从头开始的情况下更换或组合智能体。
2. Context should be reachable by local and remote agents alike, with appropriate authentication and authorization.上下文应该能够被本地和远程智能体访问，并具有适当的身份验证和授权。
3. Permissions should be scoped and revocable. Access should be granted to a specific connection with an agent, limited to a defined subset of the context, and should distinguish between reading, proposing, changing, and deleting.权限应该是可限定范围且可撤销的。访问权限应授予智能体的特定连接，仅限于上下文的特定子集，并应区分读取、提出、更改和删除操作。
4. Provenance should persist. Every item records where it came from, who or what created it, and how it has changed. The distinction between human-written, agent-captured, and collaborative work should outlive the conversation that produced it. 来源应持久化。每一项内容都应记录其来源、创建者或创建工具，以及它是如何变化的。人类编写、智能体捕获和协作工作之间的区别应该在产生这些内容的对话结束后依然存在。
5. Time should be part of the context. The system should preserve when something was observed, when it was true, and how it changed, rather than continually overwriting the past with the present. Database folks will recognize this as bitemporality: the distinction between transaction time and valid time.时间应该成为上下文的一部分。系统应该保留某事被观察到的时间、它为真的时间以及它如何变化，而不是用现在不断覆盖过去。数据库领域的人会将其识别为双时态（bitemporality）：事务时间和有效时间之间的区别。
6. Entities should be first-class. People, companies, places, and other recurring concepts should remain recognizable as names, roles, and relationships change. 实体应该是“一等公民”。人、公司、地点和其他反复出现的概念在名称、角色和关系发生变化时，应保持可识别性。
7. Interoperability should not require uniformity. Different people and companies should be able to build different context systems for different ecosystems and trust boundaries. What they need is agreement on identity, permissions, provenance, and exchange, not one universal application. For the exchange, plain text files with structured metadata are a strong candidate.互操作性不需要统一性。不同的人和公司应该能够为不同的生态系统和信任边界构建不同的上下文系统。他们需要的是在身份、权限、来源和交换方面达成共识，而不是一个通用的应用程序。对于交换而言，带有结构化元数据的纯文本文件是一个强有力的候选方案。

Using these principles, personal context can be something a person owns: You can inspect it, grant and revoke access to it, trace where each piece came from, and take the whole of it elsewhere. Every agent may still develop its own understanding of you, but you’ll be able to bring a durable context of your own to the relationship, one that participates in the agentic ecosystem without being subordinate to any vendor in it.遵循这些原则，个人上下文可以成为你真正拥有的东西：你可以检查它、授予和撤销访问权限、追踪每一条信息的来源，并将它完整地带走。每个智能体可能仍会发展出对你的理解，但你将能够为这种关系带来属于你自己的持久上下文，它参与智能体生态系统，而不从属于其中的任何供应商。

Karpathy’s LLM Wiki is a description, not a tool; it’s meant to be implemented by anyone, in whatever form fits. This essay is offered in the same spirit. The important part isn’t whether the app I’m tinkering with ever ships beyond my own devices. I’m more interested in the dialogue it will take for everyone to have personal context that works for them, in their ecosystem and with the agents they want to use. If we get the pattern right, changing agents won’t mean changing homes. The context they help us build will remain ours.Karpathy 的 LLM Wiki 是一种描述，而不是工具；它旨在由任何人以适合的任何形式实现。这篇文章也是本着同样的精神提供的。重要的不是我正在折腾的应用程序是否会走出我自己的设备。我更感兴趣的是，为了让每个人都能拥有适合自己、适合其生态系统以及适合其所用智能体的个人上下文，我们需要进行什么样的对话。如果我们掌握了正确的模式，更换智能体就不意味着更换家园。它们帮助我们构建的上下文将永远属于我们。