夜雨聆风多 Agent 协作，别再靠一堆 markdown 硬塞上下文了
同一个 workspace 里，编码 Agent 在改接口，产品 Agent 在补 PRD，运维 Agent 在排查发布问题，结果三个人共用一套 SOUL.md、AGENTS.md、TOOLS.md、MEMORY.md。最后经常出现一种很蠢的情况：写代码的 Agent 读到了产品讨论废话，做方案的 Agent 又把工程约束漏掉，排障时还把别的项目配置带进来。
这不是模型变笨了，是上下文管理方式太原始。文件堆叠在小规模时还能忍，一旦进入多 Agent、多项目、长周期协作，噪音、串扰、误写回都会一起爆出来。
我看 OpenClaw 用户侧这套 workspace 重构方案，重点不在“整理文档”，而是在把上下文当工程资产来治理。它明确对着 4 个问题下手：上下文分层不清、上下文注入偏静态、项目上下文缺失、沉淀机制不明确。这个判断，我基本认同。
事件摘要：这不是改文件名，是把上下文体系重做一遍
先说结论：这套方案不是要你多建几个目录看起来更专业，而是把原来“所有信息都往几个 markdown 里塞”的做法，升级成分层、动态装配、可回写的工作空间体系。
它的 5 条设计原则很硬，我直接翻成大白话：
分层，而不是堆叠 结构化优先，不要散文式堆信息 动态装配优于全量注入 回写本来就是上下文工程的一部分 规则、知识、状态必须拆开
这 5 条里，我最认同的是最后一条。很多团队现在最大的问题不是上下文少，而是把“规范”“经验”“临时状态”写在一个地方。结果模型每次都把临时讨论当长期规则，把局部经验当全局制度。
还有一个点做得比较务实：它强调这是逐步演进的目标结构，不要求一次改完。这个很重要。因为大多数团队不是死在方案差，而是死在第一次重构就想一步到位，最后没人维护。
核心观点一：先把上下文分层，才能减少噪音和串扰
过去很多 workspace 的问题，不是文件少，而是职责乱。SOUL.md 里可能混了人格、语气、行为边界；AGENTS.md 里既有安全约束，也有 heartbeat 规则，甚至还有记忆策略；TOOLS.md 里又混了开发规范和业务 API 约束；MEMORY.md 更夸张，长期偏好、公司背景、产品架构、技术栈、项目目录位置全塞进去。
这类结构短期省事，长期一定烂。因为不同信息的生命周期根本不一样。人格是稳定层，项目状态是易变层，工程规范是规则层，业务背景是知识层。你把它们揉在一起，后面就只能靠人脑区分，Agent 当然也会读乱。
这次方案先把基础文件职责重新定位，我觉得很合理：
SOUL.md：稳定人格层 IDENTITY.md：身份标签 USER.md：服务对象基础画像 AGENTS.md：workspace 级运行约定 TOOLS.md：本地工具说明 MEMORY.md：长期记忆
注意，这还只是第一层拆分。真正关键的是继续往下切，把重文件减负。
比如 AGENTS.md 现在内容过重，就不该继续当垃圾桶。安全与行为约束拆到 policies/safety.md，记忆规则拆到 memory/README.md，heartbeat 规则拆到 operations/heartbeat-policy.md。这样做的好处不是“目录更漂亮”，而是每类 Agent 在装配上下文时知道自己该读什么。
TOOLS.md 也一样。工具说明就是工具说明，不要顺手把开发规范和业务 API 规则塞进去。开发规范迁移到 policies/engineering.md，外部系统集成规则迁移到 integrations/ 目录，这才像工程化结构。
MEMORY.md 最该动刀。长期记忆不应该兼任业务背景、工程规范、产品架构、技术栈和项目目录索引。方案里建议拆成 MEMORY.md、BUSINESS.md、ENGINEERING.md、INTEGRATIONS.md，我觉得这是必要操作，不是可选优化。不拆，后面所有动态加载都是空话。
如果你想先在自己团队里试，不用等全量重构，先做一次盘点就行。我通常会这么分：
# 先把现有内容按四类归档rules/# 规则：安全、工程规范、运行约束knowledge/# 知识：业务背景、系统说明、产品逻辑state/# 状态：近期决策、阶段进展、待办projects/# 项目：项目专属上下文、目录说明、接口约束第一步别追求完美，先把“混着写”的问题打散。只要规则、知识、状态分开了，后面很多误注入会立刻下降。
核心观点二：动态装配，比全量加载更适合多 Agent 协作
多 Agent 场景里，最蠢的一种做法就是：不管什么任务，先把所有上下文全喂进去。这种方式看起来稳，实际非常浪费，而且错误传播范围特别大。
写代码时，你真正需要的是人格约束、用户画像、工程规范、当前项目上下文。你大概率不需要完整产品背景、公司战略、全部外部系统接入说明。反过来，做 product_design 的时候，业务背景和产品文档就比工程规范重要。
所以这套方案里，我最愿意跟的是“任务类型与上下文加载建立映射”。例如：
casual_chat：加载人格、用户、长期记忆 coding：加载人格、用户、工程规范、项目上下文 product_design：加载人格、用户、业务背景、产品文档
这个思路对，关键是别只停留在口头。要把加载规则落成文件，最好能维护。
方案建议在 docs/context/ 下新增这些文件：
BUSINESS.mdENGINEERING.mdINTEGRATIONS.mdCONTEXT_LOADING_RULES.md
这几个文件的价值，不是给人看，而是把“Prompt 手感”固化成团队规则。尤其 CONTEXT_LOADING_RULES.md，它本质上是在把经验变成配置。
我建议直接按可执行思路写，哪怕先用 markdown，结构也要像配置，而不是散文：
task_context_map:casual_chat:load:-SOUL.md-USER.md-MEMORY.mdcoding:load:-SOUL.md-USER.md-docs/context/ENGINEERING.md-docs/projects/current-project/README.mdproduct_design:load:-SOUL.md-USER.md-docs/context/BUSINESS.md-docs/projects/current-project/product.md如果 OpenClaw 还不能原生按任务动态装配，也没关系，先人工执行这个规则。因为规则一旦稳定，后面很容易接自动化，不管是脚本拼接，还是 Agent middleware 组装，技术都不难。
我自己会建议团队至少先定义 3 类高频任务：coding、product_design、ops_support。不要一上来分 15 类，分类越细，维护成本越高，漏载概率也越高。先抓大头任务，效果最好。
动态装配最大的收益有两个。第一，减少无关信息注入，响应更聚焦。第二，降低跨项目串扰。很多误操作不是模型不会做，而是读到了不该读的上下文。这个锅不该让模型背，应该让上下文装配层背。
核心观点三：回写机制不补上，团队只是在重复聊天
很多团队天天和 Agent 聊得很热闹，但一周后你问：上次讨论结论在哪？通常没人答得上来。问题不在于没产出，而在于没有回写链路。
这次方案把“回写”直接纳入上下文工程，我觉得这个判断很成熟。因为如果上下文只有读，没有写，那它永远只是消费品，不会变成资产。
这里至少要分两层。
第一层是原始记录层，方案里定义得很清楚：memory/YYYY-MM-DD.md 是日记式原始记录层，用来保存当天讨论结论、做过的事情、关键决策、临时问题和解决结果。它不是正式规范层，这一点一定要守住。
第二层是正式知识沉淀区，也就是 docs/。这个目录未来应该成为技术方案、产品方案、开发规范、系统设计说明、项目上下文文档、操作手册的核心区。能进 docs/ 的内容，默认已经过提炼，不是聊天摘抄。
我建议实际落地时用这个节奏：
会话记录 -> memory/YYYY-MM-DD.md -> 每周整理摘要 -> 提炼长期有效结论 -> 写入 docs/ 或长期记忆文件如果想再规范一点，可以给 memory 记录固定模板，避免后续无法整理：
# 2026-04-08## 今日结论-支付服务重试策略从 3 次改为 2 次-coding 类任务默认加载 ENGINEERING.md 和项目 README## 已完成-修复 webhook 签名校验-补充 staging 发布回滚步骤## 临时问题-CRM API 限流阈值不明确## 处理结果-已在 integrations/crm.md 标注“需要 200ms 间隔调用”但这里有个坑，我必须提前说：不是所有写回都该直接进长期记忆，更不是所有讨论都该进入 docs/。如果没有审核标准，错误结论会被正式化，后患比“不沉淀”更大。
所以回写一定要带治理。最少要回答 3 个问题：
谁能把 memory内容升格到docs/项目文档和全局文档冲突时谁优先 过期知识谁清理
不回答这 3 个问题，回写机制最后会把 workspace 写成第二个垃圾场。
为什么重要：企业真正缺的，往往不是模型，而是上下文治理
总结观点：这套东西值得跟，但别只学目录，要学治理思路
我对 OpenClaw 这次 workspace 重构的判断很明确：值得跟。
值得跟的原因，不是它多了几个 md 文件，也不是目录更规范，而是它重新定义了工作空间里每类信息的职责边界。人格归人格，规则归规则，知识归知识，状态归状态，项目归项目。这个边界一旦立住，多 Agent 协作才有可能稳定。
我的结论也很硬：只要你们开始把 Agent 用进真实业务，继续靠文件堆叠和全量注入，迟早会碰到噪音、串扰、误操作和沉淀失效。这个不是会不会发生的问题，是早晚发生的问题。
所以这条路我会选：分层、动态装配、可回写。这三个点，就是上下文工程走向团队化、企业化的基本盘。
但我也保留一句提醒：如果自动化装配、治理机制、权限控制跟不上，这套结构最后也可能退化成更复杂的文档系统。方向没问题，成败看执行。
互动引导
你们团队现在的 Agent workspace，最乱的是规则、知识，还是项目上下文？
如果已经在用 OpenClaw 或类似框架，我更建议你们回头看一眼：哪些文件其实已经承担了不该承担的职责，哪些任务其实根本不需要全量上下文。
