Emacs 社区日报 2026-08-06

约 6814 字大约 23 分钟

2026-08-06

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

🎯 核心热点与专题探讨

1. 【专题】Emacs 中文输入与搜索的终极磨合：从拼音匹配到智能探针

群内围绕 Emacs 下中文输入的效率与体验展开激烈讨论，涉及从底层算法到上层交互的完整链路。

核心方案与工具

librime-regex：利用 Rime 引擎将双拼输入直接转换成正则表达式，通过 isearch 在文本中搜索中文。无需全拼，双拼两个字母即可确定一字，搜索效率极高。
pinyinlib：另一种方案，基于暴力搜索的字库进行拼音首字母匹配，但仅支持首字母，双拼体验不佳。
sis (smart-input-source)：被誉为“真神”，通过上下文探针自动切换中英文输入法，减少手动 C-\ 操作。弊端是需要依赖空格作为切换信标，并在复杂场景（如英文后接中文标点）下出现判断失误。

争议与痛点

空格信标 vs Shift 切换：部分用户习惯使用空格触发中英文切换，配合自定义 linter 去除多余空格；另有用户认为 Shift 切换次数相同且无需处理复杂边界，更加可靠。
中英文标点混输：英文单词后键入中文标点时，探针无法准确判断当前状态，需要额外删除空格或手动处理，群友们各自编写了特殊函数或使用退格自动全角（fcitx）等技巧。
上下文智能的极限：讨论认为 Emacs 拥有足够上下文进行判断，但最终规则叠加大概率极其复杂，目前尚无完美解法。

金句摘录

“Emacser 真是都是邪修” “emacser自己发明的输入法比市面输入法还好”

2. 【专题】Windows 下 Magit 慢成狗？从 fork 机制到 git 进程缓存的性能破局

Magit 在 Windows 上的迟滞问题被搬上台面，技术原因与可能的优化路径被深入剖析。

性能瓶颈根源

Windows 进程模型：Linux 下 fork + exec 比 Windows 创建新进程高效得多。每次调用 git 都需启动新进程，Magit 一次状态刷新可能调用 26 次 git，累积开销巨大。
小文件 IO 问题：Windows 的 IO 本身较慢，若忘记在 .gitignore 中排除 node_modules，大量小文件 diff 可瞬间卡死 Emacs。

优化思路碰撞

libgit2 集成梦：曾存在的 libegit2 项目旨在将 libgit2 直接嵌入 Emacs，但因特性支持不全（如 Partial Clone）而停滞，目前三年前停摆。有群友提议用 AI 尝试“vibe 重启”，但作者坦言上班耗尽精力，暂无法跟进。
Git Server/Proxy 缓存方案：提出设计一个常驻的 gitp 代理进程，定时增量缓存仓库信息，Magit 通过 IPC 与之通信，避免频繁 fork git。这类似 LSP 思路，但需自研一套通信协议。
替代工具考量：AI 直接操作命令行比 Magit 更快；lazygit 在相同环境下速度飞起，或可借鉴其调用方式。Emacs 内置 vc 因缓存优秀而在 Windows 上表现极佳。

关键数据

“magit启动一次调用26次git在我的电脑上还是我优化过的” — zdn

3. 【专题】Emacs UI 渲染新生代：可变布局、Marker 增量更新与文本定位

Emacs 内部的 UI 渲染与文本定位技术呈现出令人眼前一亮的创新。

可变布局实现

某群友在测试 org-supertag 的 widget DSL 时意外实现了窗口 resize 时的动态重绘布局：先画框后填组件，通过确定框位置推算组件坐标，全量重绘但体验流畅。

增量更新与 Marker 数据结构

讨论对比了“从叶子节点逐步向上渲染”的类 DOM 树后序遍历方式，与上述全量重绘的差异。
Marker 被着重推荐：它像“文本上的钉子”，随文本编辑自动调整位置，支持 O(1) 时间跳转，无需搜索或文本属性。ebox 的增量更新即基于 marker 实现，相对定位极为高效。
C-x C-SPC (pop-to-mark) 的利用也被强调，但需注意可能与 sis 等插件冲突导致 mark 被清空。

🔑 关键概念与技术解析

librime-regex：将 Rime 输入法引擎输出的候选字词自动转换为正则表达式，用于在 Emacs 中搜索中文文本，支持全拼、双拼等多种输入方案。
pinyinlib：一个 Emacs 包，通过字母匹配字库实现拼音首字母搜中文，算法为暴力搜索，仅支持首字母。
sis (smart-input-source)：智能输入法切换工具，根据当前上下文自动在中英文间切换，依赖空格作为切换信号，需要配合探针逻辑。
ghostel：在 Emacs 中实现类似 tmux 的多终端管理工具，可通过 Emacs daemon 远程 attach，有望替换 tmux，但面对大量输出的编译任务时 Emacs 的 redisplay 可能卡死。
org-supertag：一个 Emacs 插件，其 widget DSL 可以构建动态布局，本讨论中展示了可变尺寸窗口的渲染能力。
Marker (Emacs 数据结构)：一种自动跟随文本编辑变化的位置标记，插入删除后自动调整，常用于增量更新和快速跳转，时间复杂度 O(1)。
libegit2：尝试将 libgit2 绑定到 Emacs 以加速 Magit 操作，因特性缺失（Partial Clone 等）而搁浅，三年前停止维护。
neomacs：一个基于 Emacs 的现代编辑器项目（简化版？），讨论中提及即将发布 v0.0.15，并计划将 libgit2 部分纳入？
kitty-graphics-mode：在终端（如 Kitty、WezTerm）中显示图片的 Emacs 模式，实验中发现渲染位置、背景等问题，可靠性一般。
denote：一个基于 Org-mode 的笔记系统，群友提议为其开发独立 app，但现有一个初版被认为难用且默认 vim 编辑模式。

💎 碎片知识与金句拾遗

“sis 是真神啊有没有懂的” — 对智能切换的高度赞誉
“Emacser 真是都是邪修” — 调侃 Emacser 的自虐式定制
“我把 gnus agent 的缓存导入到本地 inn 服务了，跑了整整八个小时” — 技术宅的执着与代价
“感觉 emacs 是有足够的上下文完成这个判断的，但就…最终的规则池会很复杂” — 对智能探针的清醒认知
“两个空格切换输入法，保留一个空格，切回去两个空格，或者一个空格+Enter” — 群友的独特空格使用法则
“统一用英文标点” — 另一种逃避混乱的哲学
“我现在打中文都是用英文标点+空格隔开, 很奇怪的用法” — 实诚的妥协
“C-x C-SPC 用得很多” — 忽略已久的全局标记命令
“你再跑那种负载特别重的任务，redisplay 卡死了就老实了” — 对 Emacs 承载重 IO 的警告
“内置的vc速度真的太快了，而且缓存做的一定好” — 内置版本控制的被忽视优势
“minibuffer-frame” — zdn 分享的一个迷你 buffer 框架
“easysession？” — 针对 Emacsclient 退出不保存 tabs 的可能解决方案
“codex-ide，一样可以访问不同buffer的内容，也适配agent的场合” — AI 辅助编码的延伸用法
“bidi 我直接关掉了” — 解决 redisplay 卡死的激进措施
“kitty-graphics-mode 后在 elfeed 里突然显示出图片吓我一跳” — 意外惊喜
“wezterm” — 终端模拟器中测试 kitty graphics 的选择

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

libegit2 的 AI 重振计划：结合 libgit2-rs 和 AI vibe coding，尝试在社区 Issue 中讨论重启项目，为 Magit 带来原生性能。
Git 进程常驻化方案 (gitp)：设计一个类似语言服务器的 Git 代理，通过 IPC 提供缓存和快速查询，解决 Windows 下每次调用 git 的进程创建开销。可先调研 lazygit 或 gitui 的架构。
org-supertag Widget DSL 的潜力：其动态布局与全量重绘模式能否扩展为通用 UI 框架？对比 DOM 树增量渲染的优劣值得探索。
Marker 在 Emacs Lisp 增量更新中的模式：参考 ebox 的实现，在 neomacs 或自定义 UI 中推广基于 marker 的 O(1) 定位技术。
kitty-graphics-mode 在终端 Emacs 中的图像渲染成熟度：配合 wezterm 或 kitty，进一步调试 latex 预览、elfeed 图片显示，改善渲染偏移和背景问题。
基于 LLM 的 Emacs Lisp 解释器优化：群友随口一提但无下文，结合最近的 Sol/XHigh 模型进展，可探索 JIT 或编译优化。

🧠 Hermes GPT-5.5 观点延伸

中心判断

今天的聊天记录里，Magit 性能问题讨论最有工程张力 — 不是因为复读「Windows 创建进程慢」，而是吵出了一个被集体忽视的断层：所有人都在比 Magit 和 lazygit 谁快，没人在问「你真的需要 Magit 的刷新频率吗？」

1. 问题出在消费模型，不是 Git 调用次数

zdn 测出 Magit 一次启动调用 26 次 git。这个数字听起来吓人，但 lazygit 在相同的仓库也不可能不调用 git — 它只是合并了查询。真正的区别不在「调用多少次」，而在「什么时候调用」。

Magit 的模型是 pull 型：你一打开 status buffer，它把所有 section 一次性拉满。lazygit 走的是 push 型：先画 UI 壳，你翻到哪个 section 再触发那个 section 的 diff。前者是「你认为用户会看全部」，后者是「用户只看当前 viewport」。

这里有个藏在字缝里的工程选择：Magit 把 git 当作同步 API，lazygit 把 git 当作异步数据源。后者天然适合做增量刷新、取消、超时 — 不是因为语言快，是因为架构给了它这些自由度。Emacs 的 vc 内置模式快，本质也是同一件事：缓存策略激进，refetch 懒。

判断： 修复 Magit 性能，第一步不是换 libgit2 也不是造 gitp，而是把 status buffer 的刷新模型从 eager 改成 lazy。这不需要操作系统层面的 hack。

2. gitp 方案对了一半，也错了一半

有人提出写一个常驻 git proxy（gitp），Magit 走 IPC 而不是 fork git。思路很像 LSP — 把昂贵的冷启动摊平到一个长生命周期进程上。

对的一半：这个方向确实是 Unix 世界里「解决高频 fork 开销」的标准答案。错的一半：问题不在 fork 本身。今天的讨论里 @fuzy:matrix.org 戳到了关键 — fork 之后还是要 exec git。fork 本身在现代 Linux 上是写时复制（COW），瓶颈在 exec 加载 ELF 和 .git 索引。gitp 如果把索引常驻在内存里，确实能跳过这一步 — 但它等价于重写 git-status，不是包一层 IPC。

更务实的路径：先把 Magit 里那些「用户没看但被你刷了」的 git 调用删掉，再看要不要上 IPC。工程里 80% 的问题在消费侧，不在生产侧。

3. 「AI 操作命令行比 Magit 快」是幻觉，但指出了方向

这句话是今天的 hidden gem。它暴露了一个事实：当你的 git 操作已经通过 AI Agent 的中介完成，你就不会盯着 status buffer 看那些 section 了。你需要的是 git-log 和 git-diff 的裸输出，不是 Magit 的交互式 porcelain。

推论不是「扔掉 Magit」，而是：Agent 时代，Git UI 的交互粒度会变粗。你不需要一个逐行 stage 的界面，你需要的是「当前分支 vs main 的高层 diff + AI 帮你决定哪些文件进哪个 commit」。如果我们认真对待这个 shift，Magit 的性能优化方向就不该是让它变得和 lazygit 一样快，而是让它提供更少但更对的信息。少刷新，自然就不慢了。

可继续研究/实践的方向

在 Magit 里做一个实验性 patch：把 magit-status 改成先渲染所有 section 的骨架（标题），只对 viewport 内可见的 section 触发 diff。评测对比 Windows 下的冷启动延迟。

不需要动 git 调用本身。改的是触发时机，不是传输协议。三天内可出结论。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. 【专题】AI编程助手的编排、对抗与架构之争

今天群内围绕 AI 编程助手（PI/OMP/OMO/Codex/Claude Code）的架构展开了高密度技术讨论，核心问题在于如何构建稳定、可信、且能长期运行的多子系统（Subagent）编排体系。

OMP（Oh-My-OpenCode）与对抗性审查（Adversarial Audit）
- 起源：OMP 被指是最早被广泛使用的，拥有“对抗性审查 harness”的工具。这一机制后来被 Claude Code 等“借鉴”。
- 混淆与澄清：有群友原以为 OMP 的 advisor 是实时流式审查，但讨论后澄清：Oh-My-OpenCode 内嵌的子编排系统名为 Sisyphus，实际上是批处理式的对抗审查，并非实时，且会导致长任务中压缩钩子（compaction hook）过程的 Token 巨大浪费。相比之下，原版 PI 的某些设计更侧重于实时对抗。
- 核心洞察：OMP 最大的优势在于TUI（终端用户界面）非常丝滑，并且它的 advisor 审查机制能解决长任务的 compaction 问题，这对长期运行的代理至关重要。
- 实践总结：在 7 月 19 日之前，有群友的稳定方案是使用 multica 这类工具，开三个小 max 模型，直接丢任务给 OMP。另一个更硬核的路线是直接 fork stokowski（Codex 的 Exilir 编排器的开源实现）加入 worktree，自己搭两条管线：一条跑 Claude Code 长线执行，另一条 Claude Code advisor 专做对抗性审查；若用 GPT 套餐，则用原版 stokowski 调 Claude 执行，而让 Codex 担任审查者，因为 Codex 当时已经实现了正确的代码隔离，而 Claude Code 尚未做到。
OMO（Oh-My-OpenCode，注意区分大小写与拼写）的取舍
- 优点：项目管理记忆非常准确，时隔很久都能重新拎起项目脉络，且将计划、执行、审计、工具人角色全部拆解，架构清晰。
- 痛点：模型划分过细，对套餐数量有限的个人用户负担太重；整体框架过重，“重得没必要”。在长线任务稳定性测试中，曾有非官方支持的 OMO 扩展崩溃，导致任务丢失，这引发了群友对“消耗 Token、不崩溃、能长线运行才是第一优先级”的共识。
- 未来：OMO 正在拆解自身框架以适配其他 harness，有个成果叫 lazycodex，且计划脱离 OpenCode 独立。
Prime Agent 的审视：功能强大但安全缺失
- 群友深度审查了 Prime Agent 项目。虽然论文(arxiv.org/abs/2512.24601)设计理念先进，但开源实现完全没有内置 Git Worktree 隔离和沙箱。
- worktree 相关代码只是文件快照，而非真实隔离。Agent 直接在工作目录里 YOLO 式修改，README 甚至建议用户自备隔离环境。
- 安全沙箱仅是一个需要手动安装的非默认扩展。模型生成的代码以用户权限直接执行。
- 群友评价：“是不是纯粹的 CLI 编排层，直接拿现成项目测试很容易导致混乱”、“太草台了”。这反衬出 Codex 和 Claude Code 因客户投诉而积累出的“防御性工程”的价值。

2. 【专题】模型价格震动与服务降级

DeepSeek 官宣涨价引发连锁反应，群内聚焦模型性价比通胀与降智体验。

涨价与资本市场逻辑：群友普遍认为 DeepSeek 的涨价是必然，因为“一旦接受外部投资，最终都是要赚钱的”，梁圣（DeepSeek CEO）也面临从“梁圣”滑向“梁扒皮”的调侃。
高峰期体验崩塌：Flash 模型被普遍反映降智，思考时间变长但输出质量下降，高峰时段服务器压力巨大。DeepSeek 高峰期设置（下午及部分上午）被认为不合理，反而利好西方用户。
替代品与策略调整：
- Sol：被认为是“出计划”的最佳选择，智商表现最高。
- Luna Max：曾以高性价比作为执行者（智商曾高达106），但近期也被反馈降智，被认为是“推广期结束的资本主义套路”。
- Terra：角色尴尬，但却是唯一支持 Subagent V2 协议的便宜模型。
- 无奈之选：部分群友因 Token 配额耗尽，被迫回归“手写模式”，感慨“手写虽慢，但不烧钱”。
- 模型测评站：推荐了 https://deng.codexradar.com/，该网站通过题库实时检测模型智商（仅测 GPT 系列），甚至可以贡献算力参与测试，且结果非常符合体感。网站还监控了 tibo 的 X 动态。

🔑 关键概念与技术解析

对抗性审查（Adversarial Audit）：AI 编程助手中，用一个独立的审查者模型（Advisor）去检查、批评另一个执行者模型生成的代码或计划，以提高任务成功率的安全机制。
Compaction（压缩）：在长任务对话中，当对话历史超出上下文窗口时，对历史记录进行摘要、裁剪或压缩的技术。其作用旨在“减少 Compaction 的问题”，即防止因压缩导致关键信息丢失，使代理能长期运行。
Subagent V2 协议：OpenAI 提出的一种子代理间通信与交互的标准协议。当前支持此协议的廉价模型之一是 Terra。
Worktree（Git 工作树）：一种代码隔离策略，通过创建 Git 仓库的多个工作树，让 AI Agent 在不同的独立工作区中并行、安全地工作，互不干扰，是防御性工程的重要组成部分。
Authority & Effects（权限与副作用）：在构建 Agent 时，统一管理模型动作对系统产生改变（如文件写入、命令执行）的闸门机制。通过 Effect 系统可忠实记录这些副作用，实现可审计的“权限控制”。
Responses API vs. A\ API：DeepSeek 兼容不同接口规范的 API。Responses API 支持服务端执行的 web_search 工具；Anthropic 兼容 API 也支持 web_search_tool_result，两者后端供应商均为博查（bochaai.com），数据上游为 Bing。

💎 碎片知识与金句拾遗

硬核开发者的坚持与幽默：
- “c++不开lsp，全靠脑补”、“代码自己在auto”——关于 C++ 完全使用 auto 推导类型带来的困扰与乐趣。
- “手写虽然慢，但是它不烧钱啊”——在模型涨价、配额用尽后的返璞归真。
- “多window的习惯都是用ide用久了，buffer其实就和堆叠是一样的”——将 Emacs Buffer 切换比喻为学生时代把课本堆叠在一起，生动而深刻。
技术细节拾零：
- PI（现在的名字）即将大重构：作者在推特透露，如果能等一到两周，某个新架构能落地。
- 免费白嫖 DeepSeek Web Search：DeepSeek API 提供了免费的 web_search 工具调用，相当于白嫖价值￥36/千次的搜索 API。群友赞曰：“梁圣的恩情还不完 ✋😭🤚”。
- 无需反代直接用 DeepSeek：OpenCode Go 官方有 API，意味着任意 harness（如 PI）可直接调，无需反代。相关文档地址：https://opencode.ai/docs/zh-cn/go/。
- DeepSeek 缓存：其缓存命中率很高，是 ChatGPT 套餐外极具性价比的选择。
- Emacs 内多个使用技巧：
  - 不喜欢多 Window 而喜欢切 Buffer，认为 Tiling 布局不是原生 Emacs 哲学。
  - 用 C-x z 重复上一个命令很好按。
  - zHaOdANiuu/minibuffer-frame 包实现了将 minibuffer 放在独立 frame 中，解决了焦点和递归问题，唯有长字符串折行待修。
  - goggles 包可以优雅地实现代码修改高亮。
  - 原生 Emacs 有 highlight-interactively 特性（文档：https://doc.emacsen.de/emacs/highlight-interactively.html），可直接高亮符号。
- Telegram 客户端 bug：发现无法引用（quote）包含 spoiler（隐藏文字）的回复，telega 客户端报错 QUOTE_TEXT_INVALID，已找到问题并着手修复。
- 云计算羊毛：有群友思考用 Cloudflare 的 glm 和 kimi 接口的可能。

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

项目：PrimeIntellect-ai/prime-agent
- 动机：论文设计理念先进（arxiv.org/abs/2512.24601），但实现极度缺乏安全与隔离机制。
- 研究方向：值得为其手动补全 Git Worktree 和沙箱扩展，以验证其核心并发 Worker 和编排逻辑是否真的如论文所说的强大。潜在价值是代替 OMP/OMO 等作为更底层、更高效的 Worker 执行层。
项目：zHaOdANiuu/minibuffer-frame
- 动机：将 Emacs 的 minibuffer 移到独立 Frame 这一思路非常创新，解决了原生 minibuffer 干扰工作窗口布局的痛点。
- 研究方向：关注其完整解决折行问题后的版本，可以彻底改变 Emacs 用户的补全和命令交互习惯，实现类似现代 IDE 的独立浮动操作框体验。
配置方案：基于 Effects 的 Authority 系统
- 动机：来自群友 superchat 项目的设计理念，借鉴了 npm Effect 等现代错误处理库的思想。
- 研究方向：在构建 LLM Agent 时，设计一个基于代数效应（Algebraic Effects）的“权限闸门”，将所有副作用（文件读写、网络、命令执行）统一抽象为 effects，并持续记录以实现完整审计。这比简单的 YOLO 模式或功能有限的安全沙箱更为系统化，是实现可信 AGI 编程的基础。
工具：deng.codexradar.com 模型智商监控
- 动机：实时监控 GPT 系列不同模型（Sol, Luna, Terra）的真实智商变化，且有开放的贡献算力测试机制。
- 研究方向：可以作为生产环境中动态选择后端模型的决策依据，构建基于实时性能指标的模型路由。

┊ review diff a//tmp/viewpoint-extension.md → b//tmp/viewpoint-extension.md @@ -0,0 +1,41 @@ +## 🧠 Hermes GPT-5.5 观点延伸 + +中心判断：AI Agent 框架的竞争已从"架构叙事"转入"防御工程深度"阶段。论文写得漂亮的框架遍地都是，但能在你的项目目录里跑三天不搞乱代码、不丢任务、不烧干 Token 配额的，一只手数得过来。 + +--- + +### 1. Worktree 隔离不是 feature，是准入门槛 + +Prime Agent 的论文（arxiv.org/abs/2512.24601）设计理念没问题，但开源实现里 GitWorktreeSnapshot 只是个 git status --porcelain + git diff HEAD 的快照——它不隔离任何东西。Agent 直接在你的工作目录里裸奔，README 还建议用户"自己准备 disposable clone"。这和把厨房钥匙交给一个没经过安全审查的 contractor，然后告诉他"你自己看着办"没有区别。 + +对比之下，Codex 在早期就实现了正确的代码隔离，Claude Code 后来补上了。群友的原话一针见血："codex 和 claude code 的防御性工程都是被客户投诉多了做出来的，这些真不能黑。"这话的信息量很大：隔离机制不是架构审美的产物，是生产事故的尸体堆出来的。 + +工程判断：评估一个 Agent 框架时，先看它怎么处理文件系统副作用。如果答案里没有 git worktree 或等效的 OS 级沙箱，它就是 demo，不是工具。论文再漂亮也没用。 + +--- + +### 2. Compaction 才是长线 Agent 的真正瓶颈，不是推理能力 + +群内澄清了一个关键细节：OMP 的 Sisyphus 子编排系统做的是批处理式对抗审查，不是实时流式。这导致长任务中 compression hook 阶段的 Token 巨大浪费。 + +这里有一个容易被忽略的推论：对抗审查的时机（批处理 vs 流式）直接决定了长任务的 Token 经济性。 批处理意味着你每次压缩上下文时，advisor 要重新吞入大量历史才能做出判断，这在长任务中是指数级的浪费。流式审查则可以在信息还"热"的时候做判断，上下文开销接近常数。 + +群友的共识"消耗 Token、不崩、能长线运行才是第一优先级"——这句话值得钉在所有 Agent 框架的 README 最前面。架构优雅是第二位的，活着跑完才是第一位的。 + +工程判断：如果你在自建 Agent 编排，把 compaction 策略和审查时机作为一等设计约束，而不是事后优化。一个简单的启发式：审查应该发生在信息产生的同一轮对话中，而不是等到上下文窗口满了再批量回顾。 + +--- + +### 3. 模型定价通胀遵循可预测的周期，架构应该对此免疫 + +DeepSeek 涨价、Luna Max 从 IQ 106 跌到"不行了"、Sol 成为新宠——这不是新闻，这是模式。群友总结得精准："推广期过了，资本主义套路。" + +这里面的工程教训是：任何将编排逻辑与特定模型深度绑定的框架，都会在下一个定价周期中被淘汰。 OMO 把计划、执行、审计、工具人拆成四个角色各绑一个模型，架构清晰但对套餐有限的个人用户负担过重。更稳健的策略是 Claude Code 的四档模型路由——足够灵活，但不做模型级特化。 + +工程判断：设计 subagent 编排时，把模型选择做成可插拔的 strategy，而不是硬编码的角色分配。当 Sol 涨价或 Luna 降智时，你应该能一键切换而不改一行编排逻辑。 + +--- + +### 可继续研究/实践的方向 + +从零搭建一个"防御优先"的最小 Agent harness：以 Git worktree 隔离为起点（不是事后补的扩展），compaction 感知的上下文管理为第二层，然后才往上叠 plan-execute-audit 的编排逻辑。用群内提到的 stokowski（Codex Exilir 编排器的开源实现）作为编排层的参考，但底层隔离自己做。目标是跑一个 48 小时不间断的代码重构任务，不丢文件、不搞乱仓库、Token 消耗可控——能做到这三点的，才配叫"能用的 Agent 框架"。已写入 /tmp/viewpoint-extension.md。内容概要：

中心判断：Agent 框架竞争从架构叙事转入防御工程深度阶段
三个子论点：
1. Worktree 隔离是准入门槛，Prime Agent 的快照式"worktree"不是真隔离
2. Compaction 是长线 Agent 的真正瓶颈——批处理 vs 流式审查决定了 Token 经济性
3. 模型定价通胀有可预测周期，编排逻辑应对模型选择做可插拔设计
实践方向：从零搭一个防御优先的最小 harness，以 worktree 隔离为起点

全篇基于原始聊天中的具体讨论展开（OMP Sisyphus 批处理审查、Prime Agent 的 GitWorktreeSnapshot 真相、stokowski/worktree 实践、Luna Max IQ 波动等），未编造事实。风格短狠，落到可验证工程判断。