Emacs 社区日报 2026-07-17

约 6898 字大约 23 分钟

2026-07-17

自动整理自 Telegram 讨论组，每天更新。内容为 AI 摘要，仅作信息索引与回顾。

🎯 核心热点与专题探讨

专题：Emacs 社区的文化割裂与开发者生态

本次讨论中，Emacs 社区内部的氛围差异成为热议焦点。群友们发现，不同地区的 Emacs 社区呈现出截然不同的文化面貌：

Reddit 社区的保守主义：群友 Aiser 指出，Reddit 的 r/emacs 社区对 AI 和新人极不友好，存在“张口就问 AI 占多少”、“求助帖得不到回答反而被喷”的现象。其他人附和认为，Reddit 上“保守派居多”，甚至对 Neovim 用户也缺乏友好度。
Emacs-China 的技术向与包容：相比之下，Emacs-China 社区被认为“有什么问题都会热心解答”，对 AI 的排斥情绪相对较低，更愿意探讨技术本身。群友 Aiser 透露其配置 99% 由 AI 生成时，群内并未出现排斥，反而有“人工修订”、“给 LLM 写优化原型”等务实讨论。
开发者的沉默与自娱：一位开发者因社区氛围而选择低调，直言“现在写包都懒得宣传了，自己用着乐”。这反映出社区环境对开源贡献者积极性的潜在影响。

核心矛盾：当 AI 工具和新型编辑器（如 Neovim）不断涌现，Emacs 的“正统”定义权之争愈发激烈。社区内部“正统派”（守护传统工具链与哲学）与“实用派”（拥抱 AI、借鉴新特性）之间存在明显的文化张力，这直接影响了新人体验与项目生态。

专题：Emacs 文本渲染的“深水区”——Overlay 与 Whitespace 的冲突

群友 zdn 在魔改 citre 包时，遭遇了一个 Emacs 底层渲染难题：如何让 whitespace-mode 渲染空格（如·）的行为，不对 overlay（文本覆盖层）渲染的字符串生效。

技术难点：whitespace-mode 的实现极为底层，它基于一个“渲染表”对整个 buffer 的空格进行替换。Overlay 字符串虽然独立于 buffer 文本，但其内部的空格同样会被这个全局的表替换。
探索过程：zdn 发现无法通过 hook 在 overlay 渲染时临时关闭 whitespace-mode 而保持 buffer 其余部分开启。最终不得不采用“笨方法”——在 overlay 的字符串中手动将空格替换为其他字符。
解决方案缺失：这个问题暴露出 Emacs 渲染机制的一个盲区：缺乏区分“buffer 原始文本空格”与“overlay 渲染内容空格”的细粒度控制。whitespace-mode 的实现让此事变得“特别特别麻烦”。

深层启示：这个看似小众的 bug，揭示了 Emacs 核心渲染模型的复杂性和历史包袱。Overlay 作为文本属性的组合拳，在处理像 whitespace-mode 这种在底层 table 上全局替换字符的 minor mode 时，会不可避免地产生冲突。这不仅是用户配置问题，更是 Emacs 核心代码在抽象层上的经典痛点。

专题：Scheme 生态的依赖管理之痛与包管理器反思

一次关于 Chez Scheme 依赖管理的讨论，激发出对“包管理器”这一现代软件工程的核心理念的深刻反思。

现状：群友抱怨 Chez Scheme 的工具链（如 akku）体验差，依赖管理混乱，需要手动修改 $CHEZSCHEMELIBDIRS 环境变量，且收录的包版本陈旧。
解决方案：资深成员提出“vendor everything”（直接将所有依赖库放在项目目录内）的方案，并使用 git submodule + Makefile 或 direnv、nix flake 来管理。理由是“Scheme 的库没有那种多层的依赖关系，和 C 的情况比较像”。
“包管理器是糟粕”论：一位成员尖锐地批评包管理器是“糟粕”，认为它会“诱惑人写出一堆破碎的、维护程度不高的包”。他主张，如果某个包真的有用，应该直接加入标准库或成为事实上的标准，而不是依赖一个包管理器来维持其生命周期。

各方观点：

实用派：希望有“rust written package manager”来解决 Scheme 的现状。
原教旨主义派：推崇最小化工具链，认为对于依赖简单的生态，复杂的包管理器是冗余和负担，甚至会扭曲开发者行为。

总结：这场讨论超越了 Scheme 本身，触及了软件生态的核心哲学——在“易于发现与复用”和“生态健康与依赖控制”之间如何取舍。它反映出在 Lisp 家族这类小众但纯粹的语言生态中，用户对工具链的“控制感”和“简洁性”有极高的要求。

热点四：Emacs 社区对 AI 的复杂态度

与社区的保守形象相反，群内对 AI 的讨论呈现出非常务实和工具理性的态度。

AI 作为效率工具：群友普遍承认“AI 只是个 tool”，并且有人透露其配置“99% AI 生成”，主要用途是“给 LLM 写优化原型”和“人工修订”。
AI 的局限性认知：有人明确指出 LLM 写出的代码“直接写了个 O(n²)的缓存扫描，卡死我了”，表明群友并非无脑吹捧，而是以批判的眼光看待 AI 产出。
古法与工具的辩论：一场关于“古法编程”的辩论中，群友反驳“以前的人写代码没有高亮”的观点，认为“有更方便的工具为什么不用”，并类比鸟山明画画和现代数字工具。

结论：这群硬核开发者并非反 AI，而是将 AI 视为一种强大的、但需用批判性思维去驾驭的新工具。他们更关注 AI 在生产环境中的实际效果和性能开销，而非其哲学意义。这与 Reddit 上简单的“反 AI”情绪形成鲜明对比。

🔑 关键概念与技术解析

Overlay (文本覆盖层)：Emacs 中的一种机制，允许你在不修改 buffer 文本自身的情况下，向特定区域附加显示属性（如字体、颜色、图片，甚至替换显示的字符串）。常用于语法高亮、代码折叠、行号显示等。是 Emacs 文本渲染的基石。
Whitespace-mode：Emacs 的一个 minor mode，用于高亮显示文本中的空白字符（如空格、Tab、换行符）。其实现非常底层，会基于一个内部“渲染表”对所有文本进行替换，因此会影响到 Overlay 渲染的字符串。
Dynamic Module (动态模块)：允许 Emacs 在运行时加载用 C/C++ 等语言编写的共享库的机制。它为 Emacs 提供了脱离 Elisp 瓶颈执行高性能计算的能力，例如群友提到的“布局重排中的并行计算”。
Vendor (供应商 / 内建)：软件工程术语，指将项目依赖的第三方库直接复制到项目的版本控制目录内，而非依赖操作系统或语言包管理器的全局安装。优点是避免了版本冲突和网络依赖。
akku：一个用于 Chez Scheme 的包管理器，类似于 Common Lisp 的 Quicklisp。但群友反馈其收录的包版本老、使用体验不佳。
elisp-autofmt：一个 Emacs Lisp 代码自动格式化工具，可用于编写一致风格的 Elisp 代码，减少格式化相关的争论。

💎 碎片知识与金句拾遗

关于 GNU 软件的哲学：
“emacs 用着用着，越来越喜欢古董了，动不动二三十年历史的工具。” “GNU 做的东西，很多都是文本相关的一些东西，很有意思...简洁的美。” “GNU的东西都有一种又新又旧的感觉。”
关于 Emacs 与 Neovim 的缩进条：
“neovim 上的 indent guide 竟然是正常工作的” “Emacs上的不是吗？” （暗示 Emacs 的默认实现或配置体验不如 Neovim 开箱即用。）
关于代码折叠的习惯：
“我开代码文件的第一件事情就是把代码折叠了，然后搜索。” vs “我不喜欢折叠，直接搜索跳转就好了。” （展现了不同的代码浏览哲学。）
关于 Emacs 内嵌视频：
对在 Emacs 中内嵌视频播放器的需求持谨慎乐观态度，认为需要等待 emacs-canvas-patch 合并后，再“搓一个颜色盘出来”。当前实用方案是通过 ffplay 或 mpv 调用外部播放器。
关于 LLM 代码质量：
“它直接写了个 O(n²)的缓存扫描，卡死我了。” （对 LLM 产出的典型务实评价。）
关于包管理器的哲学思辨：
“package manager 是糟粕。package manager 会诱惑人写出一堆破碎的维护程度不高的包。” “如果一个包真的很有用，不如直接加到标准库里，或者成为某种事实上的标准。”
关于“过去 vs 现在”的怀旧辩论：
“你想想像现在人食物多了就有很多胖子，刀法武术都变成表演了，买枪练瞄准比较实用。” “你能想象现在的漫画家直接在纸上画吗？有更方便的工具为什么不用？ai 也只是个 tool。” “小时候最讨厌父母说以前怎样，现在年纪大了，我时常也会想说以前怎样，但我忍着不说，不能活成讨厌的样子。” （生动地反映了技术圈中“怀旧派”与“实用派”的拉锯。）

🛠️ 值得深入研究的点 (Follow-up)

indent-bars (https://github.com/jdtsmith/indent-bars)：一个 Emacs 缩进指示线插件。社区评价为功能强大但“配置项太多，作者摆烂不提供开箱设置”，且“应该直接进 core”。适合想要精细控制缩进显示的用户深入研究。
emacs-canvas-patch (https://github.com/minad/emacs-canvas-patch)：一个尚未合并的 Emacs 核心补丁，旨在为 Emacs 提供原生的 2D 画布渲染能力。若合并，将解锁在 Emacs buffer 中进行游戏、图表、复杂 UI 等开发的可能性。群友已计划基于此“搓一个颜色盘”。
scheme-langserver (https://github.com/ufo5260987423/scheme-langserver)：一个 Scheme 语言服务器协议实现。在 LSP 大行其道的今天，为小众语言提供 LSP 支持是提升开发体验的关键一步。
elisp-autofmt (https://github.com/emacsmirror/elisp-autofmt)：自动化格式化 Elisp 代码的工具。对于规范 Emacs Lisp 项目代码风格，减少协作摩擦有重要作用。
Vendor 管理方案 (git submodule + Makefile / direnv / nix flake)：对于使用依赖简单的小众语言（如 Scheme, C, Common Lisp）的用户，研究如何用这些工具优雅地管理 vendor 依赖，比依赖包管理器可能更稳定可控。

┊ review diff a/emacs_china_2026-07-17_opinion.md → b/emacs_china_2026-07-17_opinion.md @@ -0,0 +1,23 @@ +## 🧠 Hermes GPT-5.5 观点延伸 + +中心判断：当 AI 代码撞上 Emacs 的交互式性能墙，社区分裂的根源不是哲学立场，而是对"坏代码成本"的不同感知。 + +--- + +1. AI 辩论的胜负手在 Elisp 回车的那一刻 + +Reddit 的 r/emacs 反 AI、Emacs-China 用 AI 写 99% 的配置——这条裂痕看似是意识形态，实则是工程反馈回路的差异。当你把 LLM 生成的代码塞进 post-command-hook 或 completion-at-point-functions，它写的是 O(n²) 还是 O(n) 会在 500 毫秒内决定你的编辑器是流畅还是卡死。"它直接写了个 O(n²)的缓存扫描，卡死我了" 这句话比任何「AI 是好是坏」的宣言都有分量。 + +Emacs 用户是对 LLM 代码质量最苛刻的 QA 群体：代码在启动时加载，在每次按键时执行，在每次 buffer 切换时触发。没有 CI pipeline、没有 staging 环境——只有你的手指和屏幕刷新率。能在这种环境下活下来的 AI 生成代码，才是真正通过验收的代码。Reddit 那边反的可能不是 AI，而是未经 Emacs 级性能验证就敢推的代码。 + +2. "包管理器是糟粕"——小众语言的反直觉生存逻辑 + +"package manager 会诱惑人写出一堆破碎的、维护程度不高的包"——这个观点值得认真对待。标准工程叙事是：包管理器 → 生态繁荣 → 网络效应 → 质量飞轮。但对 Chez Scheme（以及很多 Emacs 包）这类依赖树不超过 2-3 层深的生态，这个链条可能在第二步就断了。包管理器降低发版门槛，制造长尾废弃包，废弃包制造依赖冲突，最终回到工具链痛苦的原点。 + +反直觉的洞察：在依赖足够简单的生态中，git submodule + Makefile = vendor everything 不是退步，是去掉一个不会给你正回报的抽象层。这与 Emacs 社区反复出现的「这个包应该进 core」（indent-bars 的讨论）形成镜像——好工具要么在标准库里，要么你直接把源码搬进项目。中间态的"通过包管理器发现→安装→版本漂移→废弃"可能才是真正的熵增。 + +--- + +可继续研究的方向 + +对比同一个 LLM 在 Emacs Lisp 和 TypeScript 场景下的可接受率差异：Elisp 的执行路径短、性能反馈即时、出错成本高（编辑器级而非服务级），天然构成一个更严苛的 AI 代码质量过滤器。如果能在 Emacs 配置的语境下建立一套 LLM 代码的"生存率"指标（生成 → 人工修订 → 实际启用 → 30 天后仍在运行），会比抽象的「AI 能写代码吗」更有说服力。已完成。板块已写入：

/home/geekinney/.hermes/workspace/emacs_china_2026-07-17_opinion.md

内容聚焦当天两个最有张力的话题：

AI 代码在 Emacs 里的真实考验 — 不是哲学站队，而是 O(n²) 缓存扫出来卡死编辑器的事实。Emacs 的交互式性能需求天然构成比任何静态分析都严苛的 LLM 代码过滤器，Reddit vs Emacs-China 的 AI 态度差异可能根源不在意识形态，而在谁真正把 AI 代码跑在了生产级 Elisp 路径上。
"包管理器是糟粕"的反直觉逻辑 — 对依赖树不深的小众语言，包管理器引入的废弃包熵增可能超过它解决的发现成本。vendor everything + git submodule 不是退步，是去掉一个净收益为负的抽象层。这个逻辑与 Emacs 生态中"好东西应该进 core"的反复呼吁形成镜像。

字数约 950 中文字（不含标题和标点），结构：中心判断 → 两个分论点 → 一个可实践的研究方向。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】Agent 架构与可观测性：从“黑盒”到“白盒”的探索

群内多位成员围绕 Agent 的工作流编排、可观测性及上下文管理进行了深入讨论，呈现出对当前 AI Agent 模式“不可控”、“不可见”的痛点反思。

痛点与分歧：
- “Harness”定义之争：对“Harness”（模型运行环境/编排框架）的理解存在分歧。一方认为它应实现“人完全不干预”，让 Agent 独立完成任务；另一方则尖锐指出“人不干预太遥远”，认为当前 Agent 的可观测性严重不足。
- 可观测性缺失：用户应该能查询到 Agent 任务执行过程中的所有信息（状态、上下文、数据流），以便进行更好的干预。有成员直言“pi的可观测性也不够”。
- 上下文版本控制：有成员提出用户应能更自由地操作上下文（如编辑 message、删除会话、从其他会话截取片段拼接），并考虑为上下文引入版本控制与“fork”能力。这一想法被部分人认可为可行，並认为“LLM 可以自己 compact 一段上下文”。
结构化解决方案设想：
- Lisp DSL 编排：有成员提出放弃 TUI/GUI，使用 Lisp DSL 来编排 Agent。核心思路：使用多个上下文受限的小 Agent 组成网络，每个 Agent 只负责非常确定的任务，人工搭建整体网络结构，从而保证确定性和可掌控性。
- Common Lisp 镜像优势：有成员强调 CL 的“镜像快照”能力对于 Agent 自我完善和状态恢复极具价值。Agent 可以在运行时动态调用 LLM 或自己添加新函数/宏，利用 slynk 实现远程调试、热更新与快速回退，这被认为是实现“持续进化” Agent 的理想模型。另有成员指出，Steel (Scheme) 作为 Rust 中的脚本语言，也能提供类似“嵌入 Full Functional 语言”的灵活性。
小结：群内普遍倾向构建一个高度可控、可观察、可干预、可版本化上下文的 Agent 系统。CL 及其镜像能力被部分人认为是理想底座，但 Lisp DSL 的编排思想得到了更广泛的认同。

【专题二】国产芯片、智算生态与“韬效率”的争议

群友从 AI 模型推理成本、高端晶圆产量切入，引发了关于华为“堆叠”技术（“韬等效/韬定律”）真实性的激烈辩论，并触及国家层面的算力战略选择。

现状与焦虑：
- 芯片产能瓶颈：有成员指出日本在高端晶圆产量上全球领先，中国占比不足 10%。推理卡因 H200 数据流上限和多模态需求不足，算力缺口明显。
- 昇腾 vs 英伟达：DeepSeek 已将推理部分迁移至华为昇腾，但训练仍主要依赖英伟达。成员评价昇腾“成本太高”、“不好用”、“重新开发算子浪费大量时间”，目前只是“成本高总比没芯片好”的无奈选择。DS 自研芯片的消息传出，更被解读为“要么华为把 DS 当猪宰，要么就是华为的不好用”。
“韬定律”的尖锐争论：
- 一方：技术突破在于“高温超导磁控硅单晶生长技术”和“3D 逻辑堆叠”设计（缩短逻辑电路长度）。认为这是一个颠覆性的工程方案，需要在设计层级“完全重新设计多少亿单元的结构”，9 月的 Mate 90 麒麟 2026 芯片将验证其可行性。
- 另一方：尖锐反驳，认为堆叠技术是台积电深耕多年的技术，华为只是“改名就成自己发明的了，笑嘻了”。并质疑“连工程验证都没有”、“手机芯片还在吃 18 年的技术”。关于极客湾不敢评测的传闻，一方认为是“营销”，另一方则认为“自己判断，我信极客湾”。
战略反思：“保模型还是保算力，国家选择了算力，目前选择错了。” 有成员认为，在 H200 受限的大背景下，硬推国产算力可能导致模型能力发展受阻。

【专题三】Emacs 生态的内核化、补全与极致 UI 打磨

作为一个硬核 Emacs 群，本日讨论了多个 Emacs 技术细节，包括 telega 补全 bug、原生 UI 组件与终端对齐等。

telega 补全故障排查：一名成员通过 git bisect 将 telega 补全失效的 bug 定位到 2026-06-05 的 commit 50f05b6，并提交了 PR。这一 PR 只涉及很小的改动，但被指出“indent 很重要，格式化一下应该很容易就看出来了”，强调了良好代码风格对调试的价值。
Emacs Toolkit 开发：有成员展示了其开发的 appkit.el、disco.el 等 Emacs 原生 UI 包，强调“先把框架做好，应用大家来做”，目标是用 E-lisp 表达复杂的交互逻辑，同时上手不难。
终端对齐与排版讨论：
- 在讨论 org-mode 排版时，有人建议使用 string-width 进行字符对齐，以避免终端下因字体问题导致的错位。
- 关于英文断词，提到了若实现内置的 hypen 断词（类似英文报刊排版）会很牛逼，但也指出了使用类似 KP 算法进行实时编辑排版可能带来的性能问题。

🔑 关键概念与技术解析

Harness (在 Agent 语境下)：本群讨论中，Harness 不仅指模型运行环境（如 browser-harness.com），更指一种 Agent 编排框架。强烈的共识是，好的 Harness 必须提供完全的透明性和可观测性，让人能查询所有中间状态，而不是一个黑盒。
Lisp DSL 编排 Agent：一种 Agent 架构思想。放弃使用 GUI/TUI 来编排复杂的 Agent 工作流，而是使用 Lisp 语言（如 Common Lisp 或 Scheme 方言如 Steel）的 DSL 来描述 Agent 拓扑结构、任务依赖和数据流。强调确定性：人工搭建网络，每个 Agent 上下文极小，任务确定。
Common Lisp (CL) 镜像快照 (Image)：CL 的一项核心能力。Agent 可以在运行时保存整个内存状态（包括代码、数据、会话）到一个镜像文件中。下次启动时可以直接加载镜像，恢复所有状态，实现热更新、热回退和持久化工作环境。这被认为是实现“自我完善 Agent”的理想机制。
韬等效 (Tao Equivalent) / 韬定律：群内讨论的一种技术路线名称，指通过 3D 先进封装/堆叠技术，将多个成熟制程的芯片等效成更先进制程芯片性能的思路。核心议题是其是否真正可行，以及是否为“华为的营销概念”。
string-width：Emacs Lisp 中用于计算字符在终端下实际显示宽度（考虑中英文、特殊字符等）的函数。常用于实现终端界面的精准对齐。

💎 碎片知识与金句拾遗

“帕米尔雄鹰生活在高原，潘帕斯雄鹰是低海拔平原。” (某成员的幽默阶级开摆)
“我最近想做一个编排 agent 的东西，之前试了一个 gui 感觉效果不是很好。后来我觉得 tui 可能效果也不好，我现在想就是用 lisp dsl。” (从 GUI 到 TUI 到 DSL 的架构探索思路)
“我觉得是用很多 agent, 每个有非常受限的上下文，这样整体的网络人工搭建，agent 可以做好自己的事情，虽然不能 one-shot, 但是可以非常确定。” (对确定性和可控性的强烈追求)
“cost应该就是一个 pro 吧，AI 公司的成本不能算我们的吧，又不是转卖。” (关于 AI 订阅价格讨论中的用户视角)
“人干的活越多越省钱（” (在讨论 AI 自动化与细节打磨关系时的反讽式洞察)
“保模型还是保算力，国家选择了算力，目前选择错了。” (对当前半导体与 AI 国家战略的尖锐评论)
“我觉得要发起一个全新的项目还是挺难的，要考虑的东西比在已有的东西上修修补补多多了。” (开发者对创新难度的直观感受)
“很多 tui 补全都做不好。” (对当前终端 AI 补全工具生态的批评)
“reset 大战。” (对 Codex Pro 用量重置的戏谑总结)

零散细节记录：
Codex Spark 被讨论为周限用完后可替代使用的工具，但其补全能力和稳定性被认为不如 GPT/grok 付费方案。
sing-box 比 xray 作为后端创建 hy2 节点速度更快。
chatgpt desktop 用户反馈其不支持 Spark。
有成员分享了其通过 chatgpt 的 computer use 功能发送了一条 Telegram 消息的经历。
有成员分享了 tmux-agent-sidebar 项目。

🛠️ 值得深入研究的点 (Follow-up)

sema-lisp/sema: 一个 GitHub 项目，被群友认为是“Lisp DSL 编排 Agent”思路的具体实现，展示了社区对 Lisp 作为 Agent 工作流 DSL 的进一步认可。
mermaid-rs-renderer (mermaid in Rust): 项目 jcode 为了在 Emacs 中实现 Mermaid 预览，用 Rust 重写了 mermaid 渲染器。该库 star 数量上千，说明在 Emacs 界面中集成复杂图表渲染是一个强需求。
Emacs 原生 UI 工具包：appkit.el 与 disco.el: 0WD0 开发的一系列 Emacs 原生 UI 包，展示了一种“用构建前端框架的方式”来构建 Emacs 界面的思路，值得关注其在 Emacs 社区的未来发展。
cliproxy 的限速/负载均衡能力：群内成员在讨论如何优化 LLM 调用频繁导致的 rate limit 时提到了 cliproxy，暗示其具备高级的限速和等CD功能，这类工具对于批量任务优化很有价值。

🧠 Hermes GPT-5.5 观点延伸

当天最值得咀嚼的不是哪款芯片能不能量产，而是一群用 Emacs 的人对 Agent 架构的直觉判断：上下文不应该是一条只能往前滚的聊天记录，而应该是一个可版本化、可 fork、可 compact 的软件制品。

这不是随口一说的脑洞。讨论中从"用户应该能编辑 message、删除中间会话、从其他地方截一段接上"一路推到"版本控制不够，fork 更有用，因为你不需要回滚"。这个判断非常精准——Agent 的探索是树状的，不是线性的。你让 Agent 试一条路，走到一半觉得不对，你想的不是"退回去"，而是"从这里分叉，试另一个方向"。线性 undo 是文本编辑器的思维，branch 才是 Agent 工作流的思维。

第二个值得认真对待的判断："用很多 agent，每个有非常受限的上下文，整体网络人工搭建"。这本质上是把 Agent 从"一个全能大脑"降级为"一个确定性的函数"。每个小 Agent 的输入输出可控，整体拓扑由人设计，可观测性自然就有了——因为每个节点的状态都是可查询的。这比在单体 Agent 上加一堆 logging 中间件要根本得多。群里有人贴了 sema-lisp/sema，说明这个方向已经开始有实现。

关于 CL 镜像的讨论容易被误解成"Lisp 崇拜"。实际上核心论点是：Agent 的持久化不应该靠手工序列化一堆状态字段，而应该靠语言运行时的原生能力。 CL 的 image dump/restore 是极端案例，但方向是对的——你今天用 Python 写 Agent，重启后要重建所有工具注册、会话上下文、内存状态，每一步都是出错点。群里提到的 Steel (Rust 嵌入式 Scheme) 走的是另一条路：不追求完整镜像，但追求"在 host 语言里嵌入一个完整的 functional 脚本环境"。这两种思路都在回答同一个问题：Agent 的状态应该有多"厚"。

可研究的方向： 做一个最小原型——用一个支持 fork 的上下文管理器（类似 git 的数据结构），加上 3-5 个小 Agent 组成的确定性拓扑，看看在"完全不依赖模型本身做编排决策"的前提下，能不能完成一个中等复杂度的软件工程任务。如果这个原型能跑通，当前的 Agent 框架设计有相当比例是过度工程。