holon v0.14.1:Rust 重写与自举开发实践 ✍ jolestar🕐 2026-05-24📦 10.2 KB 🟢 已读 𝕏 文章列表 本文介绍了 holon v0.14.1 版本的更新,重点在于使用 Rust 进行了底层重写,并实现了项目的自举开发(即 Agent 自主完成从需求分析到代码合并的全流程)。文章详细阐述了采用 Rust 重写的原因、关键架构设计(如单 Session 模式、Workitem 机制和事件驱动),并展示了实际的 Dev 工作流及与竞品模型的对比测试数据。 AgentHolonRust自举开发DevOpsLLM工作流自动化开源 # holon v0.14.1:Rust 重写,自举开发 **作者**: jolestar **日期**: 2026-05-24T04:52:20.000Z **来源**: [https://x.com/jolestar/status/2058410746447564865](https://x.com/jolestar/status/2058410746447564865) ---  holon v0.14.1 发布了。当前 holon 的开发已经完全由 holon 自己进行——holon-pm 聊需求出 issue,holon-dev 写代码提 PR,holon-reviewer 审 PR 看 CI 决定合并,holon-ops 定期分析日志发现异常。我只需要在关键节点看一眼。 这个版本推迟了很久,因为我把 holon 用 Rust 重写了一遍,然后自己一直用,一直修 bug,直到把主要工作都迁移到 holon 上,没有太明显的 bug,才觉得可以放出来让大家试试。 ## 最初的想法:一条命令解决一个 issue holon 的起点很简单。去年我在 X 上发了一条推,描述了一个工作流:给 Agent 一个 GitHub issue,它自动理解需求、写代码、提交 PR。一条命令,一个 issue,一个 PR。 但真跑起来就发现不够。PR 提交之后,有 review comments,有 CI 失败,需要继续修。我不希望每次都要手动提醒 Agent——我期望它能自己监听 GitHub 事件,感知到 "review 给了 comments" 或者 "CI 挂了",然后自己推动 issue → PR → merge 的整个闭环。 再进一步:如果能完成一个 issue,那把一组 issue 放进一个里程碑,它应该也能逐个推进。 于是 holon 增加了外部触发机制,增加了 serve 模式,折腾了几个版本,最终确定了当前的架构。 ## 为什么用 Rust 重写 第一版 holon 基于 Claude Code SDK。很快就碰到了天花板:调度策略、上下文管理、缓存策略——这些对 Agent 长期运行质量至关重要的东西,SDK 层不暴露接口。同时我也希望 holon 能用任意模型——Codex、GLM、DeepSeek 等,而不是绑定在 Anthropic 上。 所以这次用 Rust 从零写了底层的 Agent 循环。调度、缓存、上下文窗口管理这些逻辑现在都握在自己手里,也就可以针对不同模型做更细致的优化。 ## 几个关键设计决策 重写的过程中做了几个比较根本的取舍,它们不是孤立的,互相之间有因果关系。 放弃内置外部集成,把 holon 变成可调用的基座 holon 不再内置各种外部事件接入——GitHub webhook、IM 消息、定时任务等等。holon 本身提供 API 和服务接口,外部集成通过其他工具配合完成。比如通过 AgentInbox 集成 GitHub 和各种 IM 服务,通过 uxc 统一接入外部工具链。 这样做的好处是:holon 基座保持稳定,TUI 以及未来的桌面 App 都通过接口来调用 holon,不需要反复改底层。 单 session + Workitem:同一个上下文中管理多个任务 这两件事是一体两面。 holon 放弃了多 session 机制。因为有多个 Agent 之后,再叠加多 session,用户管理起来会非常复杂。同一个 Agent 只有一个持续进行的 session——无论从 TUI 端还是外部应用和它交互,都在同一个上下文里。 那怎么并行推进多个任务?引入了 Workitem 的概念。一个 Workitem = Plan + TODO list。一个 Agent 可以管理多个 Workitem:你一次性交代给 Agent 一系列任务,它逐个制定计划、迭代完成,但所有上下文共享同一个 session,不会碎片化。 这其实是 holon 区别于其他 Agent 工具的一个核心差异。大多数工具的思路是:一个任务开一个会话,做完就扔。holon 的思路是:Agent 是一个持续存在的协作者,它记住上下文,管理多个任务,你随时可以插话。 AGENT_HOME:Agent 的持久化身份 每个 Agent 有一个 AGENT_HOME,这是它自己的持久化目录——身份、记忆、本地技能都存在这里。AGENTS.md 是 Agent 的角色契约,定义了它的职责、权限、工作方式。 但 Agent 不能只活在自己的 home 里。用户给它一个项目目录,它就进入那个项目工作。holon 把这个关系抽象成了 Workspace:Agent 的 AGENTS.md 定义"我是谁",项目里的 AGENTS.md 定义"在这个项目里怎么干活"。Agent 可以绑定多个项目目录,在它们之间切换,但工具调用始终以当前 Workspace 为基准,不会因为某个命令里 cd 了一下就跑偏。 这个设计让 Agent 既保持独立身份,又能参与多个项目。不是一次性工具,而是有自己家、能去不同项目干活的长期协作者。 事件驱动:休眠,而不是轮询 每个 Agent 有一个接口直接接收 Operator 消息,也有一个 webhook 事件接口用于唤醒通知(GitHub 事件、IM 消息等)。每个 Agent 还有一个 event stream 接口,输出 events,TUI 可以连接上去展示 Agent 当前的活动,也支持远程连接。 这意味着 Agent 不需要轮询——它正常处于休眠状态,有事件时被唤醒,处理完继续休眠。这既是资源效率的考量,也更贴近"协作者"的隐喻:不需要的时候不打扰你,有事的时候自己干活。 ## 一个真实的工作流 说了这么多设计,不如看一个具体的工作流。当前 holon 项目的日常开发是这样的: - holon-pm:我在 TUI 里跟它聊需求方案。它把方案整理成 issue,归类到对应的里程碑。 - holon-dev:追踪里程碑里的 issue,自动切换到 worktree,写代码,提交 PR。然后订阅 PR 的 review 和 CI 事件,CI 挂了或有人提了 comments,它自动修复。 - holon-reviewer:监听到新 PR,自动跟踪 CI 状态和 review comments,评估是否可以合并,能合并就合并,同时对 issue 做归类整理。 - holon-ops:定时分析 holon 中的 Agent 日志,发现异常问题自动建 issue,灌回 holon-pm 的 backlog。 整个过程我只需要在关键节点看一眼——PR 太复杂了审一下,合并前确认一下。其他时间 Agent 自己在跑。 ## 基准测试 自举开发跑了几周之后,我开始用真实 GitHub issue 做 benchmark,追踪 holon 在 token 效率、交付质量和稳定性上的变化。这里用最近的两轮说明当前状态:一轮 Holon 赢了,一轮没赢。两轮使用的对比模型都是 Codex 5.3 spark。 赢了的一轮:#1257 ExecCommand 重复启动策略 #1257 的任务是给 ExecCommand 加 duplicate_policy,让等价的活跃 command_task 默认复用而非重复启动。结果 Holon 被选为正式 PR: Holon(胜出) #1266 输入 11.33M token · 输出 48.3K token · 工具调用 159 次 · 变更 9 个文件 · CI ✅ Codex #1265 输入 12.73M token · 输出 73.1K token · 工具调用 218 次 · 变更 9 个文件 · CI ✅ 选 Holon 的理由:diff 更聚焦(没碰不相关的 RFC 文件)、保留了已有的回归测试(Codex 重写了它)、token 和工具调用成本更低。 没赢的一轮:#1261 MemorySearch 任务回执发现 #1261 的任务是为 MemorySearch 加入压缩后的任务记录索引,并让搜索结果中的 task:<id> 能通过 MemoryGet 取到。这一轮 Holon 在 token 效率上优势更夸张,但最终 Codex 胜出: Holon #1268 输入 4.61M token · 输出 23.0K token · 工具调用 71 次 · 变更 2 个文件 · CI ✅ Codex(胜出) #1267 输入 16.66M token · 输出 60.2K token · 工具调用 151 次 · 变更 3 个文件 · CI ✅ Holon 用了不到 Codex 三分之一的时间和 token,但漏了一个关键点:没改 MemoryGet 的 tool 层。底层的 get_memory() 能处理 task:<id>,但 Agent 实际调用的 MemoryGet 工具入口没放行,导致从搜索结果里拿到了 task:<id> 引用却取不出来。Codex 的 PR 虽然贵得多,但覆盖了完整的接受标准。 两条线说明的问题 这两轮基本概括了 Holon 当前的处境: - 好的方面:token 效率优势已经稳定。增量续接命中率极高(#1261 缓存命中 3.96M/4.61M),结构化上下文管理进入稳态。#1257 证明 Holon 在保持 diff 质量和测试覆盖上的判断力不比 Codex 差。 - 需要继续修的地方:多轮迭代中偶尔会丢失 issue 的某个约束——#1261 漏掉 MemoryGet 入口就是典型。这在 v0.14 后续版本中通过增强 WorkItem 的任务边界描述和接受标准跟踪来改进。 ## 边界和下一步 当前状态达到了我的工作流目标,但还有一些明确的短板: 1. 多 Agent 通信:holon-pm / holon-dev / holon-reviewer / holon-ops 目前是通过 GitHub issue 和 PR 间接协作的——本质上还是靠外部系统做消息传递。Agent 之间直接的通信机制还没有。 2. 外部系统集成:目前的集成方式是通过 AgentInbox 桥接,覆盖了 GitHub 和部分 IM。更多的外部系统需要逐步接入。 3. 多模态:Agent 现在还看不到界面。我调试前端的时候,仍然需要手动把错误输出贴给它。这块是下一步的重点方向之一。 ## 试试看 holon 是开源项目,代码在 github.com/holon-run/holon。 安装(二选一): # Homebrew(macOS) brew install holon # 或者 Cargo cargo install holon 启动:holon daemon start 拉起守护进程,然后 holon tui 进入终端界面。欢迎试用,反馈直接提 issue,holon-reviewer 会处理。 --- 原文:https://jolestar.com/holon-v0.14.1/ ## 相关链接 - [jolestar](https://x.com/jolestar) - [@jolestar](https://x.com/jolestar) - [1.1K](https://x.com/jolestar/status/2058410746447564865/analytics) - [#1257](https://github.com/holon-run/holon/issues/1257) - [#1266](https://github.com/holon-run/holon/pull/1266) - [#1265](https://github.com/holon-run/holon/pull/1265) - [#1261](https://github.com/holon-run/holon/issues/1261) - [#1268](https://github.com/holon-run/holon/pull/1268) - [#1267](https://github.com/holon-run/holon/pull/1267) - [github.com/holon-run/holon](https://github.com/holon-run/holon) - [https://jolestar.com/holon-v0.14.1/](https://jolestar.com/holon-v0.14.1/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [12:52 PM · May 24, 2026](https://x.com/jolestar/status/2058410746447564865) - [1,136 Views](https://x.com/jolestar/status/2058410746447564865/analytics) - [View quotes](https://x.com/jolestar/status/2058410746447564865/quotes) --- *导出时间: 2026/5/24 14:40:36*
I Introducing SMFS: The Supermemory Filesystem SMFS 是一个结合了 RAG 和传统文件系统优势的新型可挂载文件系统。它允许 Agent 使用标准的 Unix 命令(如 grep)执行语义搜索,支持多格式文件的自动解析与提取,并提供本地优先的同步引擎。内部基准测试显示,SMFS 能显著减少 Token 消耗和工具调用次数,同时大幅提升检索准确率。 技术 › 工具与效率 ✍ Dhravya Shah🕐 2026-04-29 RAGAgentLLM文件系统开源语义搜索RustDevOps工具SMFS
B BestBlogs 早报 · 07-17|Bun 借 AI 重写、Hook 堵越权、Nemotron 登顶检索 本期早报聚焦 AI 工程落地,精讲 Bun 用 64 个智能体 11 天重写 53.5 万行代码、腾讯 DECO 用 Hook 治理 LLM 偷懒越权、NVIDIA Nemotron 登顶检索榜。此外涵盖 Kimi K3、Inkling 模型、全双工语音等速览,强调竞争焦点从模型参数向工程实践迁移。 技术 › Harness Engineering ✍ ginobefun🕐 2026-07-17 AI工程BunRustAgentNVIDIALLM检索Hook开源模型评测
H How to Become a Hermes Agent Operator 本文介绍了由 Nous Research 开源的高杠杆 AI 框架 Hermes Agent。文章详细阐述了其架构(大脑、个性、技能集)、具备记忆与自学习能力的闭环机制,以及如何从单机部署扩展为 VPS 上的自动化营销团队。作者分享了将其作为营销基础设施的实际经验与配置指南。 技术 › Agent ✍ Shann³🕐 2026-05-16 HermesAgent营销自动化Nous ResearchDevOps工作流VPS开源LLM实战指南
C Claude Code 工程化最佳实践与架构指南 本文系统性地介绍了 Claude Code 的工程化实战知识库,涵盖了从基础配置到高级架构设计的方方面面。内容解读了创建者的定制技巧,深入解析了 Command、Agent、Skills 的核心架构与 Memory 作用域,并针对 Monorepo 场景提供了上下文管理策略。文章还总结了上下文管理、Agent 设计、调试方法及权限安全的实践经验,并分享了如何利用高级 API 特性(如程序化工具调用、动态过滤)来显著降低 Token 消耗并提升准确率。 技术 › Claude Code ✍ shanraisshan🕐 2026-02-23 AgentMCPMemory最佳实践上下文管理架构设计DevOpsLLM开源
R Run Your Harness Outside of the Sandbox (Why and How) 本文探讨了2026年以来关于Agent运行位置的争论,指出行业趋势是将Agent运行在沙箱之外。作者详细解释了沙箱内运行的三个主要问题:爆炸半径、信任边界和沙箱的间歇性运行,并提出了将沙箱作为工具暴露的正确架构,最后提供了基于Vercel AI SDK的实现示例和生产环境中的挑战。 技术 › Agent ✍ Nathan Flurry🕐 2026-07-28 Agent沙箱架构设计DevOps后端LLM安全性生产环境Vercel AI SDK状态管理
H Herdr + Hermes: 多智能体配置中的三个日常技巧 文章介绍了作者使用 Herdr 和 Hermes Agent 构建的多智能体工作流。Herdr 作为类似 tmux 的多路复用器统一管理多个 AI 编程代理,Hermes 则作为开源的总部代理负责驱动其他代理。作者分享了三个实用技巧:基础编排、技能创建以及状态检查汇报,从而将混乱的终端窗口转化为高效的系统。 技术 › Agent ✍ tonbi🕐 2026-07-27 多智能体HermesHerdrClaude Code工作流自动化开源DevOps效率工具Agent编排
浪 浪费20亿Token之后,我做了一个帮自己定义目标的Skill 作者分享了一个名为Leader.skill的开源工具,旨在解决Agent交互中目标定义模糊的问题。该工具基于“目标七问”方法论,将模糊需求转化为清晰的目标任务书,支持多模型组合(如Claude规划、GPT执行),显著提升长程任务的完成率与Token利用率。 技术 › Skill ✍ 数字生命卡兹克🕐 2026-07-27 AgentGoal Engineering目标定义自动化开源LLM效率工具方法论ClaudeGPT
管 管理 AI 员工团队:Ryan Carson 的高效工作系统 Ryan Carson 分享了如何作为唯一员工,通过管理云端 AI Agent 团队日处理 40 个 Pull Request 的经验。文章详细介绍了将工作迁移至云端、建立工作节奏、将重复检查自动化以及控制 Token 成本四个关键步骤,强调在 AI 时代,优秀的工程管理能力比以往任何时候都重要。 技术 › Agent ✍ The Startup Ideas Podcast (SIP)🕐 2026-07-25 AIAgentDevin工程管理自动化云端开发成本控制DevOpsLLM
G Graph Engineering: 在一个窗口构建 1000+ Agent 循环的完整指南 本文介绍了 Graph Engineering 的概念,即从线性的 Agent 循环转向图结构的工作流。文章详细讲解了如何利用 Claude Code 的动态工作流功能,通过五个步骤构建并行处理任务的 Agent 图,以解决上下文限制和执行效率问题,并探讨了在扩展到 1000+ Agent 时可能遇到的挑战及解决方案。 技术 › Agent ✍ codila🕐 2026-07-22 Graph EngineeringClaude CodeWorkflowAgent并行处理动态工作流LLMDevOps
C Claude Skills: 如何通过 Anthropic 的新功能节省 Token 并提升效率 文章介绍了 Anthropic 推出的 Claude Skills 功能,通过文件夹和 YAML 配置实现渐进式披露,显著减少 Token 消耗和重复解释。详细说明了技能的构建规则、命名规范、测试方法及分发策略,帮助用户将聊天机器人转化为高效的专业工程团队。 技术 › Skill ✍ Mr. Buzzoni🕐 2026-07-17 ClaudeSkillTokenAnthropicDevOps工具与效率LLMMCPAgent
O Own Your Agent Stack 文章强调企业应拥有自主的 Agent 技术栈,以避免依赖单一供应商。通过自主控制模型、数据、云和运行环境,企业能更好地保护数据和降低成本。作者提供了基于 GitHub 的快速搭建指南,并主张通过自主学习和改进来保持竞争优势。 技术 › Agent ✍ Ashpreet Bedi🕐 2026-07-15 Agent自主可控开源技术栈AIAgentOS数据主权云计算DevOps模型独立性
微 微软开源 SkillOpt:不动模型,只训练 Prompt 微软开源了 SkillOpt 项目,引入了“训练 Prompt”的新思路。与传统的 Agent Skill 开发不同,SkillOpt 在不改变模型权重的情况下,将神经网络训练方法(如 epoch、验证集)应用于优化 SKILL.md 文本。系统通过执行任务、打分、反思和筛选修改建议,实现技能文档的自动化迭代。论文表明,该方法在多模型环境下均有显著提升,且优化后的技能具备跨模型迁移能力。 技术 › Agent ✍ sitin🕐 2026-07-13 Prompt工程Agent微软开源LLMAutoML优化技能文档