零加工哲学：一句设计原则如何毁掉整个运行时¶
证据等级：F（源码直接证明）
分析基线：4f843556
一句话¶
CLA.md 中有一条核心设计原则："ONE set of file tools covers EVERYTHING. No per-concept tools needed." 这条原则解释了前述四篇文章中所有运行时缺陷的共同根因。
1. 原则原文¶
这条原则意味着：不管是记忆、技能、日志、产出物、会话历史——全部通过同一套 read_file / write_file 操作。
2. 后果链¶
零加工哲学
├── 018 · 工具输出直通 messages[]
│ "不需要区分执行结果和对话上下文——都是字符串"
│
├── 019 · 上下文一锅炖
│ "不需要分层——全部拼成一个 system message"
│
├── 020 · 伪缓存 + 心跳税
│ "不需要缓存策略——每次都重传"
│ "idle 和 running 不需要区分——心跳都是 LLM 会话"
│
└── 021 · Memory 全局文件
"不需要 per-user 隔离——一个文件搞定"
"不需要结构化存储——markdown 就够"
3. 系统性后果¶
- 无分层：system / task / memory / tool result 混在一起
- 无缓存：静态内容每次都重算重传
- 无审计：工具执行结果不持久化，只在
messages[] - 无隔离：memory 跨用户共享，无访问控制
- 无截断策略：输出能被截断（Docker 10K），也能不截断（subprocess 1MB）
4. 与 AI Coding 的关系¶
- "一套文件工具覆盖所有"是 AI 最自然的实现方式：不需要为每个概念设计独立的存储、检索、权限
- 产品原则的包袱：一旦写入 CLA.md 成为"设计原则"，AI 在后续所有任务中都会忠实执行——不会主动质疑
- 局部合理、全局灾难：每个
read_file+write_file调用本身是正确的——但因为没有分层，系统整体行为不可预测
5. 这五篇文章的阅读顺序¶
- 018 · 一根管道 — 工具输出怎么进入对话
- 019 · 垃圾桶 — 上下文怎么被拼装
- 020 · 伪缓存与心跳税 — 为什么每轮都重传 + 为什么 idle 也在烧钱
- 021 · 当"一切皆文件"变成"一切皆灾难" — memory 为什么是全局污染源
- 022 · 零加工哲学（本文） — 以上四篇的共同根因