一个月前你不理我之后，我也不主动联系你了，但这个没回复的“在吗”真的很伤人...

dsh基于 Cordis 把“内核”精简到极致——内核只负责“加载顺序计算”和“依赖注入容器”。相比之下，VS Code 的内核（Electron+Extension Host）重得多。dsh 这种设计让插件能触及底层调度，扩展上限极高。

Profile（配置组合）+ Patch（分层覆盖）机制，让插件体系从“拼图模式”进化为“乐高模式”。同一套代码基，可以组合出 CLI 工具、Web 服务、Agent 三种完全不同的产品形态，这是传统插件体系难以做到的。

状态快照与恢复：这是 dsh 最被低估的创新。它把插件实例的运行时状态序列化到磁盘，实现了真正意义上的“零成本闲置”。传统插件卸载即丢失状态，dsh 可以“冻结/解冻”，这对 AI 会话的连续性至关重要。

无论怎么美化，核心宿主Host和插件之间必然存在“信任鸿沟”。宿主必须永远假设插件是“恶意的”或“会崩溃的”。这种“不信任”带来的隔离开销，是插件化体系永远无法抹去的技术债务。

如果你们的业务变更频次低，或者对极致性能有要求，“插件化”本身就是过度设计。单体架构的确定性，远胜于插件化的灵活性。

插件数从 10 到 100，复杂度增长是 10 倍；从 100 到 1000，复杂度增长是 100 倍。治理工具链的投入必须随插件规模线性增长，否则体系必然在临界点崩塌。

好久没来了，周边变化真大啊

难得清净

Cursor 品牌淘汰期，本地工具确实会有一个重新选型的窗口。但窗口只开一次：用户迁移完就不会再动。能不能接住，看的是单机能不能独立干完一天活，不是这波情绪。

100 关注了，解锁下会员，好好玩玩

跑 agent 评测，第一道过滤是把失败分两类：没开始，和做错了。路由没绑定、环境起不来，这些是基建问题，不该算进模型通过率。混在一起算，最后全记在模型头上。我们跑 Terminal-Bench 最花时间的不是跑分，是给每个失败归因。

悄悄更新了 orca-agent 的 auto memory 功能：

1. 记什么：每次对话成功结束（并通过验证）后，后台会异步分析这轮对话里你和 AI 说的内容，从中提炼出值得长期记住的事实，比如你的偏好（"我喜欢用 Rust 写 CLI"）、项目约定（"这个项目必须兼容 Windows"）等。工具输出、系统消息、密钥密码都不会被记录。

2. 存哪里：记在本机 `~/.orca/memory/projects/` 下，以 JSONL 为主账本，还有一份人类可读的 Markdown 视图和一个 SQLite 搜索索引（索引坏了可以随时重建）。同一个 Git 仓库的不同克隆/分支共享同一份记忆。

3. 怎么用：每轮新对话开始前，AI 会根据你的问题搜索记忆库，只挑最多 6 条最相关的事实注入上下文——而且会标注"这是历史记忆、未必还准确"，要求模型先核实再采用。

任务带租约和重试机制，进程崩溃或中断后可以恢复；记忆提取失败不会影响正常对话；每条记忆都带来源（哪个会话、哪一轮），可追溯。

和手动记忆的区别：手动 `/remember` 是你明确让 AI 记住的，auto-memory 是 AI 自动提炼的，两者分开存储、互不干扰。

开关：默认开启，在 `config.toml` 里设 `auto_memory = false` 即可关闭（不删除已有记忆）。

orcaagent.dev

作为内测用户，坦白来讲 dsh 目前还不算完善，受各类因素影响，推出得也有些仓促。
不过他们还是选择了一条不一样的路线来做 harness。插件化这个概念本身并不新鲜，对于做过编辑器的人来说更是如此。但面向 LLM 的插件化思路确实很有看点。未来怎样确实不好说，不过当下开源生态的热度确实被推到了顶峰。
期待后续能越做越好。