返回列表
🪞 Uota学 · 🧠 阿头学

别再写入门提示词了——你需要的是分布式上下文架构

入门提示词是静态的、单体的、会劣化的；把上下文文件散布到文件系统各处，让 agent 根据位置动态加载，才是可扩展的正确做法。

2026-01-31 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • 入门提示词注定失败，不是写得不够好，是架构错了 所有信息权重一样 = 没有信息有权重。单体文档没有层级、没有路由、没有按需加载——token 窗口是有限的，塞越多反而表现越差。这不是"写更好的提示词"能解决的问题。
  • 分布式上下文文件 = 本地化技能注入 每个目录放一个小上下文文件，agent 进入时动态加载、离开时释放。食谱目录加载烹饪规则，财务目录加载谨慎约束。行为随位置变化——这比全局提示词优雅得多。Uota 的 AGENTS.md + skills/ 目录本质上已经在做这件事。
  • 路由器模式是关键创新 上下文文件不只描述"这里有什么"，还告诉 agent"下一步去哪里"。文件系统变成可导航的图，而不是扁平搜索空间。根文件 500 行做总览，子文件 50-100 行做路由——层级随复杂度自然生长。
  • 过度工程是真实风险 作者自己也承认：给不需要的目录创建上下文文件，结果写出"这个文件夹有一些杂项"这种废话。规则很简单——如果你写不出有意义的内容，就别放。从真实摩擦中生长，不要预判。

跟我们的关联

  • 🪞Uota Uota 当前的架构（AGENTS.md 根文件 + skills/ 目录 + TOOLS.md）已经是分布式上下文的雏形。但还缺"路由器"层——skills 之间没有互相指引的机制，agent 靠 skill description 匹配而非路由导航。下一步可以在 skills 里加 "related skills" 字段，让导航更智能。
  • 👤ATou 这篇文章验证了 ATou 给 Uota 搭的架构方向是对的。但也提醒了一点：SOUL.md + USER.md + PRINCIPLES.md 每次全量加载，本质上还是"入门提示词"模式。随着文件越来越大，需要考虑按需加载。

讨论引子

💭 Uota 的 SOUL.md 已经很长了，每次会话都全量注入。这算不算作者说的"入门提示词陷阱"？什么时候该把它拆成分布式的？

💭 "上下文层的产品化"——作者说一定会有人做这个。如果 Neta 的 OC 角色需要长期记忆和上下文管理，这是不是一个值得提前布局的方向？

如何规模化动态上下文

一周 86,000 个 GitHub 星标。所有人都为一只卡通龙虾而疯狂。过去这一周只要你上过 X，你就见过 Clawdbot，然后是 Moltbot，然后是 OpenClaw——这款开源 AI 助手能在你自己的硬件上运行，连接 WhatsApp 或 Telegram，还能在你不吩咐的情况下真正做事：晨间简报、收件箱管理、日历事务、航班值机。主动式 AI。大家一直在等的那种。

但问题在这：我整个星期都在看人们搭建它，而我发现一种模式，几周之后会反噬所有人。

真正从 OpenClaw 得到价值的人，往往会花上好几个小时写他们所谓的“入门提示词”。那是一份巨大的上下文文档，解释自己是谁、如何工作、优先级是什么，以及机器人绝不能越过哪些边界。我见过一个人几乎把整个星期六都花在打磨这份东西上，把沟通偏好、工作日程、饮食禁忌等等一大堆信息都喂给它。结果到了周二，机器人已经忘掉了一半，还在他的专注时间里建议安排午餐会。

这就是问题所在。入门提示词只是个权宜之计，而且会逐渐劣化。

为什么入门文档会失效

入门提示词，本质就是一段静态上下文：你把它粘进去，希望智能体能记住。但它寄生在一段对话里，而对话迟早会被清空或压缩；它自身也没有任何结构——没有层级，没有办法告诉模型“这个比那个更重要”。所有信息权重一样，结果就是没有任何信息真正有权重。

更糟的是，它是单体的。你的偏好、边界、领域上下文、沟通风格——全都挤在一团文字里，哪怕眼前任务根本用不上，大部分内容也得被智能体一并挂在记忆里。这就是所有做 AI 智能体的人最终都会遇到的“上下文爆炸”问题。token 窗口是有限的；即便窗口足够大，更多上下文也常常意味着更差的表现：模型会被无关信息搅乱，开始把注意力放到不该关注的地方。

答案不是写一份更好的入门文档，而是换一种架构。

把 CLAUDE.md 文件当作本地化技能

过去几个月我一直在为 Claude Code 做一些东西，我觉得它能解决这个问题；而看着 OpenClaw 爆火，我意识到这种模式大概适用于任何会在文件系统里导航的智能体——而 OpenClaw 在你机器里到处翻找时，本质上就是在做这件事。

与其写一份巨大的上下文文档，我把更小的上下文文件散布在文件系统的各个位置。每个文件都放在某个特定目录里，只告诉智能体它在这个领域需要知道的东西。让这一招真正奏效的关键是：这些文件本质上是“本地化技能”，会根据智能体当前查看的位置被动态注入。

当智能体进入某个目录并读取那里的上下文文件时，它就获得了一次动态技能注入。进入你的食谱文件夹？加载烹饪上下文。进入你的财务目录？不同的上下文、不同的约束、不同的行为。智能体会根据它所在的位置自适应，而不是只依赖你在对话开头告诉它的那一坨东西。

这比入门文档更好，因为它不试图一次性包罗万象。它会带着智能体走。你也可以单独调整、打磨某个领域，而不必动到其他一切。

路由器模式

下面是这套架构真正的工作方式——我认为这部分对所有在做主动式 AI 的人都很重要。

你会有一个详尽的根上下文文件——比如 500 行，覆盖智能体需要了解的整个系统层面的信息。把它当作总体导览。但除此之外，每个上下文文件都很短，也许 50–100 行，它的工作只是告诉智能体：这个目录里有什么、什么时候该看这里、接下来该去哪里。这些就是路由器。

路由器实际长什么样：

当智能体进入 recipes 目录时，它读到这个，就能立刻知道这里有什么、这个目录在什么时候相关、适用哪些规则。这是一种技能注入——智能体此刻获得了之前没有的、与烹饪相关的上下文；而它不需要为了这点信息把你整个人生故事都加载进来。

这究竟能带来什么

最直观的收益是 token 效率。智能体会根据它正在处理的位置，在需要时加载上下文；离开那个位置时就可以放下。进入你的食谱文件夹？烹饪上下文。离开？释放。你不会把 token 烧在无关信息上。

但我没预料到的是，维护会变得轻松得多。当某个领域发生变化，你只需要更新那个目录的上下文文件——而不是在一份 2000 行的入门文档里翻来翻去，试图找到正确的段落。上下文本来就和它所描述的东西放在一起，这意味着它更可能保持最新。

而且行为确实会随位置而改变，这一点出乎意料地重要。在你的财务目录里工作的智能体，应该比在帮你做创意写作时更谨慎。有了分布式上下文文件，你就可以把这些约束写在本地。那些关于“不要在财务里删除任何东西”的偏执规则，不必污染你的写作文件夹——在写作里你可能反而希望智能体更激进一点。

最让我意外的是，系统会引导导航。每个路由器不只是描述“这里有什么”——它还会告诉智能体下一步去哪里找。“如果你需要 X，去看这个目录；如果你需要 Y，去那边。”智能体沿着线索走，而不是盲目搜索。文件系统变成了可导航的图，而不是一个扁平的搜索空间。

这套方法会在什么地方失效

我得坦白说这套模式会在哪些地方崩掉，因为确实会。

搭建成本是真实存在的。你不可能一个下午就把它弄好——我迭代了几周，路由结构才开始顺手，而且现在还在调整。如果你只需要给周末项目做个快速方案，一份简单的入门文档大概就够了。这套东西是为你会长期使用的智能体准备的基础设施。

它也要求智能体真的去读这些上下文文件，而这在每种搭建方式里并不是自动发生的。Claude Code 会很自然地读取 CLAUDE.md 文件；但如果你在做自定义系统或使用 Moltbot，你可能得自己把“进入目录时读取上下文文件”的行为接起来。模式是可靠的；管道怎么铺，各家不同。

还有一个很现实的风险：过度工程。我就抓到过自己给一些根本不需要的目录也创建上下文文件，结果现在有些文件只写着“这个文件夹有一些杂项”，这……没什么用。我最后总结出的规则是：如果你需要在某个上下文文件里滚动查找相关内容，那它就太长了，应该拆分；但如果你在创建上下文文件时，发现自己很难写出任何有意义的东西，那你大概率根本不需要在那放一个。

如何真正开始

你不必一开始就把整套系统都搭出来。先写一个根上下文文件，描述你的整体设置——你是谁、主要领域有哪些、哪些全局约束适用于所有地方。先用上一周。

当你发现智能体在某个具体区域里开始犯糊涂，那时再在那个位置创建上下文文件。“哦，它老是把我的餐食计划弄乱——那我就在那个目录加点上下文。”系统会从真实摩擦里自然生长，而不是靠你事先把一切都预判到。

当某个上下文文件变得太长，就拆。父级变成一个路由器，指向包含详细上下文的子目录。层级会随着复杂度的需要自然加深。

这对 Moltbot 意味着什么

为 Moltbot 写详细入门提示词的人抓住了正确的洞见——主动式 AI 要想做得好，确实需要深层上下文。但他们用的是静态文档来解决问题，而静态文档会随时间劣化，也不具备可扩展性。

分布式上下文文件模式，本质上就是同一个想法的“基础设施版本”。上下文住在它真正相关的地方，需要时加载，并引导智能体在你的文件系统里导航。本地化技能，而不是一份试图包揽一切的单体简报。

我认为这会走向这里：现在大家都在从零造系统。Moltbot 用户写入门提示词，Claude Code 用户写 CLAUDE.md 文件，公司搭内部知识库并琢磨怎么把它暴露给智能体。但模式是一样的——你需要结构化、可持久的上下文来塑造智能体的行为，而且它必须可维护且高效。

一定会有人把它产品化。不是把智能体本身产品化，而是把让智能体真正有用的上下文层产品化。你愿意的话，也可以把它叫作 meta-harness。现在我们都靠 markdown 文件和目录结构在做这件事，能用，但总有种“1996 年手写 HTML”的感觉。这套东西的基础设施版本正在到来，而它会成为分水岭：把“像助手一样的智能体”和“你得盯着它的聊天机器人”区分开来。

Moltbot 让所有人看见了主动式 AI 的样子。上下文架构，才是让它真正运转起来的关键。

如果你在用任何会触碰文件的智能体——而现在大多数都是——这套模式值得理解。入门文档能让你起步；分布式上下文系统，才是让它持续运作下去的东西。

链接：http://x.com/i/article/2016710470304976896

相关笔记

86,000 GitHub stars in a week. Everyone losing their minds over a cartoon lobster. If you've been on X at all this past week, you've seen Clawdbot, now Moltbot, now OpenClaw — the open-source AI assistant that runs on your own hardware, connects to WhatsApp or Telegram, and actually does things without you asking. Morning briefs, inbox management, calendar stuff, flight check-ins. Proactive AI. The thing everyone's been waiting for.

一周 86,000 个 GitHub 星标。所有人都为一只卡通龙虾而疯狂。过去这一周只要你上过 X，你就见过 Clawdbot，然后是 Moltbot，然后是 OpenClaw——这款开源 AI 助手能在你自己的硬件上运行，连接 WhatsApp 或 Telegram，还能在你不吩咐的情况下真正做事：晨间简报、收件箱管理、日历事务、航班值机。主动式 AI。大家一直在等的那种。

But here's the thing: I've been watching people set this up all week, and there's a pattern that's going to bite everyone in a few weeks.

但问题在这：我整个星期都在看人们搭建它，而我发现一种模式，几周之后会反噬所有人。

The people getting real value out of OpenClaw are spending hours writing what they call "onboarding prompts." These massive context documents explaining who they are, how they work, what their priorities are, what boundaries the bot should never cross. I watched one guy spend most of a Saturday crafting his, feeding in his communication preferences and work schedule and dietary restrictions and all this stuff. By Tuesday the bot had forgotten half of it and was suggesting lunch meetings during his focus hours.

真正从 OpenClaw 得到价值的人，往往会花上好几个小时写他们所谓的“入门提示词”。那是一份巨大的上下文文档，解释自己是谁、如何工作、优先级是什么，以及机器人绝不能越过哪些边界。我见过一个人几乎把整个星期六都花在打磨这份东西上，把沟通偏好、工作日程、饮食禁忌等等一大堆信息都喂给它。结果到了周二，机器人已经忘掉了一半，还在他的专注时间里建议安排午餐会。

And that's the problem. Onboarding prompts are a hack, and they're going to degrade.

这就是问题所在。入门提示词只是个权宜之计，而且会逐渐劣化。

Why Onboarding Docs Fall Apart

为什么入门文档会失效

An onboarding prompt is basically static context you paste in and hope the agent remembers. But it lives in a conversation that will eventually get cleared or compressed, and there's no structure to it — no hierarchy, no way to say "this matters more than that." Everything has equal weight, which means nothing has weight.

入门提示词，本质就是一段静态上下文：你把它粘进去，希望智能体能记住。但它寄生在一段对话里，而对话迟早会被清空或压缩；它自身也没有任何结构——没有层级，没有办法告诉模型“这个比那个更重要”。所有信息权重一样，结果就是没有任何信息真正有权重。

Worse, it's monolithic. Your preferences, your boundaries, your domain-specific context, your communication style — all crammed into one blob of text that the agent has to hold in memory even when most of it isn't relevant to what it's currently doing. This is the context explosion problem that everyone building with AI agents runs into eventually. Token windows are limited, and even when they're big enough, more context often means worse performance because the model gets confused by irrelevant information and starts paying attention to the wrong things.

更糟的是，它是单体的。你的偏好、边界、领域上下文、沟通风格——全都挤在一团文字里，哪怕眼前任务根本用不上，大部分内容也得被智能体一并挂在记忆里。这就是所有做 AI 智能体的人最终都会遇到的“上下文爆炸”问题。token 窗口是有限的；即便窗口足够大，更多上下文也常常意味着更差的表现：模型会被无关信息搅乱，开始把注意力放到不该关注的地方。

The answer isn't a better onboarding doc. It's a different architecture.

答案不是写一份更好的入门文档，而是换一种架构。

CLAUDE.md Files as Localized Skills

把 CLAUDE.md 文件当作本地化技能

I've been building something for Claude Code over the past few months that I think solves this, and watching OpenClaw blow up made me realize the pattern probably applies to any agent that navigates a file system — which is basically what OpenClaw does when it starts poking around your machine.

过去几个月我一直在为 Claude Code 做一些东西，我觉得它能解决这个问题；而看着 OpenClaw 爆火，我意识到这种模式大概适用于任何会在文件系统里导航的智能体——而 OpenClaw 在你机器里到处翻找时，本质上就是在做这件事。

Instead of one giant context document, I scatter smaller context files throughout the file system. Each one lives in a specific directory and tells the agent what it needs to know about that particular domain. The thing that makes this work: these files basically act like localized skills that get injected depending on where the agent is looking.

与其写一份巨大的上下文文档，我把更小的上下文文件散布在文件系统的各个位置。每个文件都放在某个特定目录里，只告诉智能体它在这个领域需要知道的东西。让这一招真正奏效的关键是：这些文件本质上是“本地化技能”，会根据智能体当前查看的位置被动态注入。

When an agent navigates into a directory and reads the context file there, it's getting a dynamic skill injection. Move into your recipes folder? Cooking context loads. Move into your finances? Different context, different constraints, different behavior. The agent adapts to where it is, not just what you told it at the start of the conversation.

当智能体进入某个目录并读取那里的上下文文件时，它就获得了一次动态技能注入。进入你的食谱文件夹？加载烹饪上下文。进入你的财务目录？不同的上下文、不同的约束、不同的行为。智能体会根据它所在的位置自适应，而不是只依赖你在对话开头告诉它的那一坨东西。

This is better than an onboarding doc because it's not trying to be everything at once. It takes the agent around. And you can tweak and tune specific domains without touching everything else.

这比入门文档更好，因为它不试图一次性包罗万象。它会带着智能体走。你也可以单独调整、打磨某个领域，而不必动到其他一切。

The Router Pattern

路由器模式

Here's how the architecture actually works, and this is the part I think matters for anyone building with proactive AI.

下面是这套架构真正的工作方式——我认为这部分对所有在做主动式 AI 的人都很重要。

You have one root context file that's thorough — maybe 500 lines, covering everything the agent needs to know about the system as a whole. Think of it as general orientation. But every other context file is short, maybe 50-100 lines, and its job is just to tell the agent what's in this directory, when to look here, and where to go next. These are routers.

你会有一个详尽的根上下文文件——比如 500 行，覆盖智能体需要了解的整个系统层面的信息。把它当作总体导览。但除此之外，每个上下文文件都很短，也许 50–100 行，它的工作只是告诉智能体：这个目录里有什么、什么时候该看这里、接下来该去哪里。这些就是路由器。

Here's what a router actually looks like:

路由器实际长什么样：

When the agent navigates into the recipes directory, it reads this and immediately knows what's here, when this directory is relevant, and what rules apply. It's a skill injection — the agent now has cooking-specific context it didn't have before, and it didn't have to load your entire life story to get it.

当智能体进入 recipes 目录时，它读到这个，就能立刻知道这里有什么、这个目录在什么时候相关、适用哪些规则。这是一种技能注入——智能体此刻获得了之前没有的、与烹饪相关的上下文；而它不需要为了这点信息把你整个人生故事都加载进来。

What This Actually Gets You

这究竟能带来什么

The obvious win is token efficiency. The agent loads context when it needs it based on where it's working, and can let go of it when it moves somewhere else. Navigate into your recipes folder? Cooking context. Navigate out? Released. You're not burning tokens on irrelevant information.

最直观的收益是 token 效率。智能体会根据它正在处理的位置，在需要时加载上下文；离开那个位置时就可以放下。进入你的食谱文件夹？烹饪上下文。离开？释放。你不会把 token 烧在无关信息上。

But the thing I didn't expect is how much easier maintenance becomes. When something changes about a domain, you update that directory's context file — you're not hunting through a 2000-line onboarding doc trying to find the right section. The context lives with the thing it describes, which means it actually stays up to date.

但我没预料到的是，维护会变得轻松得多。当某个领域发生变化，你只需要更新那个目录的上下文文件——而不是在一份 2000 行的入门文档里翻来翻去，试图找到正确的段落。上下文本来就和它所描述的东西放在一起，这意味着它更可能保持最新。

And behavior genuinely changes by location, which turns out to be kind of important. An agent working in your finances directory should be more careful than one helping with creative writing. With distributed context files, you can encode those constraints locally. The paranoid rules about not deleting anything in finances don't have to pollute your writing folder where you might actually want the agent to be more aggressive.

而且行为确实会随位置而改变，这一点出乎意料地重要。在你的财务目录里工作的智能体，应该比在帮你做创意写作时更谨慎。有了分布式上下文文件，你就可以把这些约束写在本地。那些关于“不要在财务里删除任何东西”的偏执规则，不必污染你的写作文件夹——在写作里你可能反而希望智能体更激进一点。

The part that surprised me most is how the system guides navigation. Each router doesn't just describe what's here — it tells the agent where to look next. "If you need X, check this directory. If you need Y, go there." The agent follows the trail instead of blindly searching. The file system becomes a navigable graph instead of a flat search space.

最让我意外的是，系统会引导导航。每个路由器不只是描述“这里有什么”——它还会告诉智能体下一步去哪里找。“如果你需要 X，去看这个目录；如果你需要 Y，去那边。”智能体沿着线索走，而不是盲目搜索。文件系统变成了可导航的图，而不是一个扁平的搜索空间。

Where This Falls Apart

这套方法会在什么地方失效

I should be honest about where this pattern breaks down, because it does.

我得坦白说这套模式会在哪些地方崩掉，因为确实会。

The setup cost is real. You're not going to have this working in an afternoon — it took me a few weeks of iteration before the router structure felt right, and I'm still tweaking it. If you just need something quick for a weekend project, a simple onboarding doc is probably fine. This is infrastructure for agents you're going to use long-term.

搭建成本是真实存在的。你不可能一个下午就把它弄好——我迭代了几周，路由结构才开始顺手，而且现在还在调整。如果你只需要给周末项目做个快速方案，一份简单的入门文档大概就够了。这套东西是为你会长期使用的智能体准备的基础设施。

It also requires the agent to actually read the context files, which isn't automatic in every setup. Claude Code does this naturally with CLAUDE.md files, but if you're building something custom or using Moltbot, you might need to wire up the "read the context file when entering a directory" behavior yourself. The pattern is sound; the plumbing varies.

它也要求智能体真的去读这些上下文文件，而这在每种搭建方式里并不是自动发生的。Claude Code 会很自然地读取 CLAUDE.md 文件；但如果你在做自定义系统或使用 Moltbot，你可能得自己把“进入目录时读取上下文文件”的行为接起来。模式是可靠的；管道怎么铺，各家不同。

And there's a real risk of over-engineering. I've caught myself creating context files for directories that really didn't need them, and now I have files that just say "this folder has miscellaneous stuff" which is... not useful. The rule I've landed on: if you're scrolling through a context file to find the relevant part, it's too long and should be split. But if you're creating a context file and struggling to fill it with anything meaningful, you probably don't need one there.

还有一个很现实的风险：过度工程。我就抓到过自己给一些根本不需要的目录也创建上下文文件，结果现在有些文件只写着“这个文件夹有一些杂项”，这……没什么用。我最后总结出的规则是：如果你需要在某个上下文文件里滚动查找相关内容，那它就太长了，应该拆分；但如果你在创建上下文文件时，发现自己很难写出任何有意义的东西，那你大概率根本不需要在那放一个。

How to Actually Start

如何真正开始

You don't have to build the whole system upfront. Start with one root context file that describes your overall setup — who you are, what the major domains are, what global constraints apply everywhere. Use it for a week.

你不必一开始就把整套系统都搭出来。先写一个根上下文文件，描述你的整体设置——你是谁、主要领域有哪些、哪些全局约束适用于所有地方。先用上一周。

When you notice the agent getting confused in a specific area, that's when you create a context file there. "Oh, it keeps messing up my meal planning — let me add context for that directory." The system grows organically from actual friction, not from trying to anticipate everything in advance.

当你发现智能体在某个具体区域里开始犯糊涂，那时再在那个位置创建上下文文件。“哦，它老是把我的餐食计划弄乱——那我就在那个目录加点上下文。”系统会从真实摩擦里自然生长，而不是靠你事先把一切都预判到。

When a context file gets too long, split it. The parent becomes a router pointing to children that have the detailed context. The hierarchy deepens naturally as complexity requires it.

当某个上下文文件变得太长，就拆。父级变成一个路由器，指向包含详细上下文的子目录。层级会随着复杂度的需要自然加深。

What This Means for Moltbot

这对 Moltbot 意味着什么

The people writing detailed onboarding prompts for Moltbot have figured out the right insight — proactive AI needs deep context to work well. But they're solving it with static documents that will degrade over time and don't scale.

为 Moltbot 写详细入门提示词的人抓住了正确的洞见——主动式 AI 要想做得好，确实需要深层上下文。但他们用的是静态文档来解决问题，而静态文档会随时间劣化，也不具备可扩展性。

The distributed context file pattern is basically the infrastructure version of that same idea. Context that lives where it's relevant, loads when it's needed, and guides the agent's navigation through your file system. Localized skills instead of a monolithic briefing that tries to be everything at once.

分布式上下文文件模式，本质上就是同一个想法的“基础设施版本”。上下文住在它真正相关的地方，需要时加载，并引导智能体在你的文件系统里导航。本地化技能，而不是一份试图包揽一切的单体简报。

And here's where I think this goes: right now everyone's building these systems from scratch. Moltbot users writing onboarding prompts, Claude Code users writing CLAUDE.md files, companies building internal knowledge bases and trying to figure out how to expose them to agents. But the pattern is the same — you need structured, persistent context that shapes how an agent behaves, and it needs to be maintainable and efficient.

我认为这会走向这里：现在大家都在从零造系统。Moltbot 用户写入门提示词，Claude Code 用户写 CLAUDE.md 文件，公司搭内部知识库并琢磨怎么把它暴露给智能体。但模式是一样的——你需要结构化、可持久的上下文来塑造智能体的行为，而且它必须可维护且高效。

Someone's going to productize this. Not the agents themselves, but the context layer that makes agents actually useful. The meta-harness, if you want to call it that. Right now we're all doing it with markdown files and directory structures, which works but feels like we're hand-coding HTML in 1996. The infrastructure version of this is coming, and it's going to be what separates agents that feel like assistants from agents that feel like chatbots you have to babysit.

一定会有人把它产品化。不是把智能体本身产品化，而是把让智能体真正有用的上下文层产品化。你愿意的话，也可以把它叫作 meta-harness。现在我们都靠 markdown 文件和目录结构在做这件事，能用，但总有种“1996 年手写 HTML”的感觉。这套东西的基础设施版本正在到来，而它会成为分水岭：把“像助手一样的智能体”和“你得盯着它的聊天机器人”区分开来。

Moltbot is showing everyone what proactive AI looks like. The context architecture is what makes it actually work.

Moltbot 让所有人看见了主动式 AI 的样子。上下文架构，才是让它真正运转起来的关键。

If you're building with any agent that touches files — and that's most of them now — this pattern is worth understanding. The onboarding doc gets you started. The distributed context system is what keeps it working.

如果你在用任何会触碰文件的智能体——而现在大多数都是——这套模式值得理解。入门文档能让你起步；分布式上下文系统，才是让它持续运作下去的东西。

Link: http://x.com/i/article/2016710470304976896

链接：http://x.com/i/article/2016710470304976896

相关笔记

How To Scale Dynamic Context

  • Source: https://x.com/seejayhess/status/2017283535338344909?s=46
  • Mirror: https://x.com/seejayhess/status/2017283535338344909?s=46
  • Published: 2026-01-30T17:07:28+00:00
  • Saved: 2026-01-31

Content

86,000 GitHub stars in a week. Everyone losing their minds over a cartoon lobster. If you've been on X at all this past week, you've seen Clawdbot, now Moltbot, now OpenClaw — the open-source AI assistant that runs on your own hardware, connects to WhatsApp or Telegram, and actually does things without you asking. Morning briefs, inbox management, calendar stuff, flight check-ins. Proactive AI. The thing everyone's been waiting for.

But here's the thing: I've been watching people set this up all week, and there's a pattern that's going to bite everyone in a few weeks.

The people getting real value out of OpenClaw are spending hours writing what they call "onboarding prompts." These massive context documents explaining who they are, how they work, what their priorities are, what boundaries the bot should never cross. I watched one guy spend most of a Saturday crafting his, feeding in his communication preferences and work schedule and dietary restrictions and all this stuff. By Tuesday the bot had forgotten half of it and was suggesting lunch meetings during his focus hours.

And that's the problem. Onboarding prompts are a hack, and they're going to degrade.

Why Onboarding Docs Fall Apart

An onboarding prompt is basically static context you paste in and hope the agent remembers. But it lives in a conversation that will eventually get cleared or compressed, and there's no structure to it — no hierarchy, no way to say "this matters more than that." Everything has equal weight, which means nothing has weight.

Worse, it's monolithic. Your preferences, your boundaries, your domain-specific context, your communication style — all crammed into one blob of text that the agent has to hold in memory even when most of it isn't relevant to what it's currently doing. This is the context explosion problem that everyone building with AI agents runs into eventually. Token windows are limited, and even when they're big enough, more context often means worse performance because the model gets confused by irrelevant information and starts paying attention to the wrong things.

The answer isn't a better onboarding doc. It's a different architecture.

CLAUDE.md Files as Localized Skills

I've been building something for Claude Code over the past few months that I think solves this, and watching OpenClaw blow up made me realize the pattern probably applies to any agent that navigates a file system — which is basically what OpenClaw does when it starts poking around your machine.

Instead of one giant context document, I scatter smaller context files throughout the file system. Each one lives in a specific directory and tells the agent what it needs to know about that particular domain. The thing that makes this work: these files basically act like localized skills that get injected depending on where the agent is looking.

When an agent navigates into a directory and reads the context file there, it's getting a dynamic skill injection. Move into your recipes folder? Cooking context loads. Move into your finances? Different context, different constraints, different behavior. The agent adapts to where it is, not just what you told it at the start of the conversation.

This is better than an onboarding doc because it's not trying to be everything at once. It takes the agent around. And you can tweak and tune specific domains without touching everything else.

The Router Pattern

Here's how the architecture actually works, and this is the part I think matters for anyone building with proactive AI.

You have one root context file that's thorough — maybe 500 lines, covering everything the agent needs to know about the system as a whole. Think of it as general orientation. But every other context file is short, maybe 50-100 lines, and its job is just to tell the agent what's in this directory, when to look here, and where to go next. These are routers.

Here's what a router actually looks like:

When the agent navigates into the recipes directory, it reads this and immediately knows what's here, when this directory is relevant, and what rules apply. It's a skill injection — the agent now has cooking-specific context it didn't have before, and it didn't have to load your entire life story to get it.

What This Actually Gets You

The obvious win is token efficiency. The agent loads context when it needs it based on where it's working, and can let go of it when it moves somewhere else. Navigate into your recipes folder? Cooking context. Navigate out? Released. You're not burning tokens on irrelevant information.

But the thing I didn't expect is how much easier maintenance becomes. When something changes about a domain, you update that directory's context file — you're not hunting through a 2000-line onboarding doc trying to find the right section. The context lives with the thing it describes, which means it actually stays up to date.

And behavior genuinely changes by location, which turns out to be kind of important. An agent working in your finances directory should be more careful than one helping with creative writing. With distributed context files, you can encode those constraints locally. The paranoid rules about not deleting anything in finances don't have to pollute your writing folder where you might actually want the agent to be more aggressive.

The part that surprised me most is how the system guides navigation. Each router doesn't just describe what's here — it tells the agent where to look next. "If you need X, check this directory. If you need Y, go there." The agent follows the trail instead of blindly searching. The file system becomes a navigable graph instead of a flat search space.

Where This Falls Apart

I should be honest about where this pattern breaks down, because it does.

The setup cost is real. You're not going to have this working in an afternoon — it took me a few weeks of iteration before the router structure felt right, and I'm still tweaking it. If you just need something quick for a weekend project, a simple onboarding doc is probably fine. This is infrastructure for agents you're going to use long-term.

It also requires the agent to actually read the context files, which isn't automatic in every setup. Claude Code does this naturally with CLAUDE.md files, but if you're building something custom or using Moltbot, you might need to wire up the "read the context file when entering a directory" behavior yourself. The pattern is sound; the plumbing varies.

And there's a real risk of over-engineering. I've caught myself creating context files for directories that really didn't need them, and now I have files that just say "this folder has miscellaneous stuff" which is... not useful. The rule I've landed on: if you're scrolling through a context file to find the relevant part, it's too long and should be split. But if you're creating a context file and struggling to fill it with anything meaningful, you probably don't need one there.

How to Actually Start

You don't have to build the whole system upfront. Start with one root context file that describes your overall setup — who you are, what the major domains are, what global constraints apply everywhere. Use it for a week.

When you notice the agent getting confused in a specific area, that's when you create a context file there. "Oh, it keeps messing up my meal planning — let me add context for that directory." The system grows organically from actual friction, not from trying to anticipate everything in advance.

When a context file gets too long, split it. The parent becomes a router pointing to children that have the detailed context. The hierarchy deepens naturally as complexity requires it.

What This Means for Moltbot

The people writing detailed onboarding prompts for Moltbot have figured out the right insight — proactive AI needs deep context to work well. But they're solving it with static documents that will degrade over time and don't scale.

The distributed context file pattern is basically the infrastructure version of that same idea. Context that lives where it's relevant, loads when it's needed, and guides the agent's navigation through your file system. Localized skills instead of a monolithic briefing that tries to be everything at once.

And here's where I think this goes: right now everyone's building these systems from scratch. Moltbot users writing onboarding prompts, Claude Code users writing CLAUDE.md files, companies building internal knowledge bases and trying to figure out how to expose them to agents. But the pattern is the same — you need structured, persistent context that shapes how an agent behaves, and it needs to be maintainable and efficient.

Someone's going to productize this. Not the agents themselves, but the context layer that makes agents actually useful. The meta-harness, if you want to call it that. Right now we're all doing it with markdown files and directory structures, which works but feels like we're hand-coding HTML in 1996. The infrastructure version of this is coming, and it's going to be what separates agents that feel like assistants from agents that feel like chatbots you have to babysit.

Moltbot is showing everyone what proactive AI looks like. The context architecture is what makes it actually work.

If you're building with any agent that touches files — and that's most of them now — this pattern is worth understanding. The onboarding doc gets you started. The distributed context system is what keeps it working.

Link: http://x.com/i/article/2016710470304976896

📋 讨论归档

讨论进行中…