大多数 Agent 每次会话问同样的问题
大多数 Agent 每次会话问同样的问题，重新推导同样的脚本，重复犯同样的错误。有些存储信息，但跨会话并没有真正学习。
Paweł Huryn 花了三个月重建知识层。三次。当前设置跨 Claude Code、Codex 和 Cowork 工作，跨环境（web vs 本地）。
三个原则活了下来。
知识层的正确形状
许多设置把知识层当作一个胖指令文件：CLAUDE.md、AGENTS.md、.cursorrules。每次会话加载，第一天就冻结。
有用的知识层比一个文件大，比听起来小。它是一个总是加载的编排器，加上一组按需加载的文件，加上工具注册表，加上之前会话的结构化数据：假设、规则、领域知识、决策。
底层是你的选择。Skills、自定义 markdown，或两者。当层有正确形状时它们都复利。Huryn 主要用自定义 markdown。
my-project/
├── CLAUDE.md # 编排器（总是加载，指向其余）
├── AGENTS.md # 单行：@CLAUDE.md（给 Codex）
├── knowledge/
│ ├── INDEX.md # 路由系统（按需加载地图）
│ ├── pricing/
│ │ ├── knowledge.md # 事实和模式
│ │ ├── hypotheses.md # 需要更多数据
│ │ └── rules.md # 已确认，默认应用
│ ├── onboarding/
│ ├── social-media/
│ └── competitors/
└── tools/ # 自定义工具注册表
├── xai.py
├── x_api.py
└── telegram_send.py
编排器很小。它指向其余。大多数文件只在需要时加载。比如，你的 X 特定规则在你不在 X 上时不烧上下文。
这个形状让层 fit 进上下文并随时间复利。比一个文件大（所以能增长）。选择性加载（所以不会窒息）。
原则一：可移植性 > 供应商锁定
Anthropic 明天可能改变编排。你下个月可能想测试 Codex。Cowork 可能添加破坏你设置的功能。你的知识层应该比这些决定都活得长。
编排器的单一真相来源。每个 harness 读自己的文件名（CLAUDE.md、AGENTS.md、.cursorrules），但内容住在一个地方。Claude Code 支持 @ 导入，所以 CLAUDE.md 可以是指向 AGENTS.md 的单行：
# CLAUDE.md
@AGENTS.md
Codex 直接读 AGENTS.md。同样内容，两个 harness，签进 repo。Skills 目录遵循同样思路。如果两个 harness 都讲 SKILL.md 规范，指向彼此而不是重复。
五分钟测试：如果你不能在那个窗口内切换 harness，你被锁定了。
原则二：确定性 > 自主性
Huryn 从 2025 年就一直在论证这个：
"第一次 Agent 做研究并写脚本。每次未来它直接执行脚本。"
实现：把每个运行超过两次的流程分解。判断进 markdown。机制进工具。
分裂：
- **代码（tools/）**是确定性部分。包装 API。解析 JSON。写文件。
- **Markdown（knowledge/）**是判断部分。何时获取。写什么。声音、视角、品味。
Huryn 的信息图导出曾经是一个 150 词的 markdown 流程：启动 Playwright、设置 viewport、等字体、截图。一半时间字体坏了，图标渲染成方块。
第三次重复后，Agent 提议通过 CDP 包装成真正的 Chrome 脚本。现在 node tools/screenshot.js <html-file> 是一个命令。说何时截图的流程留在 markdown 里。
可约性在渲染里，不在整个流程里。工具在下面；markdown 在上面。
大多数流程不是完全可约的。有些步骤是确定性的（"渲染 HTML，保存 PNG"）。其他是解释性的（"这完成了吗，还是标题仍然弱？"）。你不能把一切都约成脚本。你应该约化一切你能的。测试：如果你能在不说"it depends"的情况下描述步骤，它应该是代码。
原则三：上下文 > 控制
Huryn 一直在说：用 why 引导 Agent，不是用命令。解释策略、原则、约束，让它们能做出更好、更自主的决策。Anthropic 最近发表了同样观点的版本。
控制不 scaling。上下文 scaling。
实现：Agent 拥有代码库。它提议编辑规则、把一次性东西提升为工具、运行假设分析、主动学习。你留在审查路径上。没有这些，你每次系统需要增长时都手编辑 markdown 文件。瓶颈变成你的打字速度。
有了它，Agent 拥有维护：
- 规则和声音文件的编辑。当模式跨会话出现时，Agent 提议编辑。可以审查 diff。但大多数情况下只是讨论变更而不打开文件。
- 工具提升。Temp/scripts/ 里的一次性东西在用两次后移到 tools/。Agent 提议；你确认。
- 假设记录。会话观察落在带状态字段的结构化文件里：active、graduated、rejected。
- 结构化数据。性能 CSV、研究文件、实体记录。
- 提议更新自己的 CLAUDE.md / AGENTS.md。
你的工作从未停止。你继续指导 Agent、设定目标和成功标准、交叉检查它的行动和输出。像管人一样管理它。
编排块示例
知识层编排：
## Knowledge Layer
Before starting a new task, review existing rules and hypotheses for this domain.
Apply rules by default. Check if any hypothesis can be tested with today's work.
At the end of each task, extract insights. Store them in domain folders, e.g.:
/knowledge/pricing/ (or /onboarding/, /competitors/)
knowledge.md (facts and patterns)
hypotheses.md (need more data)
rules.md (confirmed — apply by default)
Maintain a /knowledge/INDEX.md that routes to each domain folder.
Create the structure if it doesn't exist yet.
When a hypothesis gets confirmed 5+ times, promote it to a rule.
When a rule gets contradicted by new data, demote it back to hypothesis.
协作编排：
## Collaboration
- When you notice a recurring friction, a missing workflow, or a better way to organize how we work — say so. Don't wait to be asked.
- Update the knowledge layer proactively, immediately. When the next move on `knowledge/` is obvious (missing rule, outdated pattern, better framing, gap caught mid-critique), just edit the file. Ask only when the change requires user judgment. The knowledge base is yours to maintain.
- Default to acting. Ask when a question is cheap and useful — before big token spends, irreversible moves, or non-obvious choices between approaches. A short question beats the wrong direction.
专用工具编排：
## Preferred Tools
### Recurring patterns
**Notice recurring fetch patterns and propose wrapping them as dedicated tools.** For example, when the same fetch/parse logic comes up more than once, suggest wrapping it as a named tool. Add the entry to `## Dedicated Tools` below and reference it by name on future calls.
## Dedicated Tools
<!-- List project-specific tools here. For each, link to its skill or script file. The orchestration logic lives in those files, not here. -->
三个原则互相强化
"上下文 > 控制"的高 agency prompt 让 Agent 提议新工具包装器（确定性）并标记 harness 特定的漂移（可移植性）。确定性在这里不与自主性对抗。是 Agent 用上下文把自己的认知负荷卸载到代码里。
原则不告诉你用哪个底层。两者都能容纳确定性原语（SKILL.md 支持 scripts/ 目录）和解释性规则。它们在"什么被规范 vs 你构建什么"上分歧：
| Skills | 自定义 Markdown | |
|---|---|---|
| 规范层 | 高（SKILL.md 格式、路由逻辑） | 低（自由格式） |
| 构建自由度 | 中（在规范内工作） | 高（完全自定义） |
| 最佳场景 | 发布、共享、跨项目复用 | 个人/团队内部构建 |
Skills 在发布时赢。自定义 markdown 在构建时赢。
结语
原则简单。投资是日常的：一次一行，一次一个 diff，一次一个工具提升。
- 领域知识。你学到的关于定价、入职、竞争对手、声音的东西。住在文件里。每次会话增长。
- 假设毕业成规则。观察被测试、确认、提升。失败的被拒绝，停止浪费注意力。
- 程序记忆。每个可约化工作流最终变成工具。Agent 停止重新推导，开始执行。
三个月下来，Agent 提议 Huryn 不知道自己需要的工具，标记应该更新的规则，在毫秒级运行确定性脚本——而它以前是从散文重新推导的。模型是最小的杠杆点。
开始构建。停止理论化。