人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载本文以 AtomCode 开源仓库中的实施计划 2026-07-25-retire-core-tool-ball-D.md 及其配套设计文档 2026-07-25-retire-core-tool-ball-D-design.md 为主体结合当前仓库源码系统讲解如何在大型 Rust workspace 中安全退役一组互相纠缠的 core 模块。读者读完将掌握一套可复用的依赖审计 → 符号搬迁 → 类型归位 → 纯删除四阶段重构方法论以及每阶段的行为一致性parity契约、编译驱动验证和回滚策略。一、背景什么是纠缠球为什么要退役它AtomCode 是一个用 Rust 构建的开源终端 AI 编程 AgentREADME.md。在早期架构中一个名为atomcode-core的 crate 内聚集了tool、conversation、provider、ctx四个模块。这四个模块彼此引用、互为依赖形成一团纠缠球entangled ball存活的 core 模块通过tool::real_home_dir()与tool::ToolCall两个符号碰球daemon守护进程通过tool::PermissionDecision与tool::parse_permission_decision作为core::tool的唯一外部代码消费者没有任何存活模块引用conversation/provider/ctx但它们内部与tool纠缠导致整个球想删删不掉。根据设计文档的背景调查在此之前子项目 Acompact provider、Bvision、Cdaemon 传输脱core::conversation已经落地conversation/provider/ctx的外部代码消费者已归零但物理删除仍被阻塞——正是被tool↔ctx的纠缠与core::tool的外部消费者卡住。子项目 D 的目标就是解开并删除整个球最终实现最初目标——core::conversation的物理删除。从当前仓库状态可以确认这一重构已经落地crates/下已不存在atomcode-coredaemon 的依赖清单 atomcode-daemon/Cargo.toml 中也不再声明atomcode-core。本文既是该实施计划的深度解读也是对其落地结果的源码级验证。二、重构前的依赖审计把谁在碰球查得一清二楚任何大型删除重构的第一步都是精确的依赖审计绝不能凭感觉动手。设计文档给出了三条审计结论每条都有可验证的代码依据core::tool的唯一外部代码消费者 daemonPermissionDecisionparse_permission_decision出现在 daemon 的permission_bridge.rs、lib.rs、live_api.rs三处ToolCall/ToolResult的外部引用此前已在 C3 后归零config/util.rs 与 capabilities/pathnorm.rs 中的命中只是注释。存活 core 模块碰球只通过 2 个符号tool::real_home_dir()调用点位于 skill.rs:501、graph/indexer.rs:489、plugin/installer.rs:267/271与tool::ToolCall仅core::stream/mod.rs内部使用外部对core::stream只消费TokenUsage。没有任何存活模块引用conversation/provider/ctx。capabilities 已有PermissionDecision位于 approval.rs变体为AllowOnce/AllowAlways/Deny语义等价于 core 版的Allow/AllowAlways/Denydaemon 实测只用Allow(10)/AllowAlways(3)/Deny(7)从不用Ask——这意味着迁移后没有缺口变体需要填补。审计还要回答一个架构约束问题core不依赖 kernel仅 dev-dep所以ToolCall只能迁到 core 内部模块不能用kernel::tool::ToolCall顶替。这一约束直接决定了 D1 的搬迁目标。三、目标状态三刀拆解D1 → D2 → D3整个计划的核心思想是把删除拆成三步可独立编译、可独立回滚的刀每刀都留下一个绿色状态刀动作完成后的状态D1把real_home_dir搬进core::process_utils把ToolCall搬进core::stream存活 core 模块不再引用crate::toolD2PermissionDecision归 capabilities新增parse_permission_decisionrepoint daemon 三文件core::tool外部代码消费者归零D3删除tool/conversation/provider/ctx四个模块目录 lib.rs 声明 orphan 测试core::conversation物理删除最初目标达成顺序不可颠倒D1/D2 负责解开所有对球的引用各自独立编译绿D3 才是纯删除。下面逐刀展开。第一刀 D1real_home_dir→core::process_utilsToolCall→core::streamStep 1 — 搬real_home_dir。从tool/mod.rs约 360 行处剪切整个pub fn real_home_dir() - OptionPathBuf连同其私有 helper 与单测到crates/atomcode-core/src/process_utils.rs补齐use std::path::PathBuf;等导入。随后更新 3 个 core 内部调用点把crate::tool::real_home_dir()改为crate::process_utils::real_home_dir()。这一搬迁不是随意的real_home_dir是一个纯函数无状态、无对外副作用而process_utils是存活 util 模块选择它作为新家可以让函数就近存在于其用户一侧。设计文档特别强调它不能迁到 capabilities——因为调用者是存活的 core 模块而 core 不能依赖 capabilitiesL1 分层必须留在 core 内部。Step 2 — 搬ToolCall。从tool/mod.rs约 824 行处剪切三字段结构体pub struct ToolCall { pub id: String, pub name: String, pub arguments: String }连同其 derive 属性到crates/atomcode-core/src/stream/mod.rs并删除stream/mod.rs中原来的use crate::tool::ToolCall;现在同模块内定义。计划中有两个明确警告⚠️不要搬ToolCallBuffer——那是 tool 内部类型随球删除⚠️ 球内部其它使用ToolCall的代码provider/conversation/ctx随球删不用管只需保证存活模块stream 及其消费者能编译。Step 3 — 编译确认。运行cargo build -p atomcode-core 21 | grep -E error|warning: unused。此时球还在只是符号搬走了球内对旧路径crate::tool::real_home_dir/crate::tool::ToolCall的引用可能报错——计划的稳妥做法是球内引用也一并改到新路径D3 再删球。Step 4 — 全绿 独立提交。运行cargo build --workspace cargo test --workspace --no-run cargo test -p atomcode-core后提交提交信息为refactor(core): real_home_dir→process_utils, ToolCall→stream解开 tool 对存活模块的钩子·D1。第二刀 D2PermissionDecision归 capabilitiesdaemon 脱core::toolD2 要解决审批类型归谁的架构决策。设计文档的关键决策是PermissionDecision 归 capabilities审批域权威不新建 kernel 类型、不在 daemon 内建副本——DRY 与 L1 审批栈统一。当前源码证实了这一决策的落地审批基础设施ApprovalMiddleware、ApprovalRequest、PermissionStore全部位于 approval.rscc_hooks.rs/write_approval.rs等审批域代码均已使用它。Step 1 — 先写失败测试TDD在approval.rs的#[cfg(test)]中加入#[test] fn parse_permission_decision_maps_daemon_wire() { assert_eq!(parse_permission_decision(allow), PermissionDecision::AllowOnce); assert_eq!(parse_permission_decision(always_allow), PermissionDecision::AllowAlways); assert_eq!(parse_permission_decision(deny), PermissionDecision::Deny); assert_eq!(parse_permission_decision(garbage), PermissionDecision::Deny); }PermissionDecision需PartialEq——若没有就给 enum 加#[derive(PartialEq, Eq)]或用matches!。该测试在当前仓库中已经存在见 approval.rs#L356-L371。Step 2 — 跑测试确认失败cargo test -p atomcode-capabilities parse_permission_decision此时函数未定义。Step 3 — 实现 wire 解析器逐字对齐被退役的core::tool::parse_permission_decision的 wire 映射/// Parse the wire string used by the daemons permission endpoints /// (/chat/permission, /live/permission) into a decision. Mirrors the /// retired core::tool::parse_permission_decision wire mapping. pub fn parse_permission_decision(s: str) - PermissionDecision { match s { allow PermissionDecision::AllowOnce, always_allow PermissionDecision::AllowAlways, _ PermissionDecision::Deny, } }注意这里只处理 daemon 的字符串键控 wireallow/always_allow/ 其它→Deny与已有的PermissionDecision::from_value(Value)解析{decision: ..., remember: ...}JSON职责不同、互补共存。当前仓库中的实现还额外增加了allow_all_bash PermissionDecision::AllowAlwaysAll分支用于 daemon 字符串端点承载会话级允许全部 Bash语义见 approval.rs#L143-L156。随后在 tools/mod.rs 的 re-export 中加入parse_permission_decision与PermissionDecision同处当前仓库 L95-L96 已确认。Step 4 — repoint daemon 三文件。把permission_bridge.rs、live_api.rs、lib.rs中的atomcode_core::tool::{PermissionDecision, parse_permission_decision}全部改为atomcode_capabilities::tools::{PermissionDecision, parse_permission_decision}并把全 daemon 的PermissionDecision::Allow改为PermissionDecision::AllowOnce约 10 处用grep -rn PermissionDecision::Allow\b crates/atomcode-daemon/src/定位注意AllowAlways不要误改。当前源码证实 daemon 已经完成迁移permission_bridge.rs:7与live_api.rs:14均导入atomcode_capabilities::tools::PermissionDecision。Step 5 — 编译 全绿 提交。运行cargo build --workspace cargo test --workspace --no-run cargo test -p atomcode-daemon cargo test -p atomcode-capabilities并确认grep -rn atomcode_core::tool crates/atomcode-daemon/为空。提交信息为refactor(daemon): PermissionDecision 归 capabilitieswire parser脱最后一个 core::tool 消费者·D2。第三刀 D3删掉整个球Step 1 — 确认球零外部/存活引用。两条 grep 都应返回空否则回到 D1/D2 补grep -rnE crate::(tool|conversation|provider|ctx)::|use crate::(tool|conversation|provider|ctx)\b crates/atomcode-core/src/ | grep -viE /(tool|conversation|provider|ctx)/ grep -rnE atomcode_core::(tool|conversation|provider|ctx)\b crates/ --include*.rs | grep -v crates/atomcode-core/ | grep -vE ^\s*//|///Step 2 — 删模块。用git rm -r删除四个模块目录并在lib.rs中删除pub mod tool;35 行、pub mod conversation;18 行、pub mod ctx;19 行、pub mod provider;29 行以及相关的pub usere-exportgit rm -r crates/atomcode-core/src/tool crates/atomcode-core/src/conversation crates/atomcode-core/src/provider crates/atomcode-core/src/ctxStep 3 — 清 orphan 测试 编译。cargo build -p atomcode-core 21 | grep -E error与cargo test -p atomcode-core --no-run 21 | grep -E error会精确指出哪些crates/atomcode-core/tests/*.rs还在引用被删模块如set_messages_resume_test.rs用了core::ctx——这些 orphan 测试必须一并删除或改写。这是设计文档风险清单中的重点项删除 conversation/tool 会留下引用被删模块的测试文件必须靠--no-run编译所有测试目标来兜住。Step 4 — 全绿。cargo build --workspace cargo test --workspace --no-run cargo test -p atomcode-core cargo test -p atomcode-daemon。Step 5 — 确认 conversation 已物理删除。ls crates/atomcode-core/src/conversation应报 No such filegrep -rn core::conversation crates/ --include*.rs应只剩历史注释。当前仓库中相关残留仅是注释性质的说明文字如 daemon 的legacy_convert.rs中解释历史数据格式的注释代码引用已清零。Step 6 — 提交。git commit -m chore(core): 删除 tool/conversation/provider/ctx 纠缠球core::conversation 物理删除·D3。四、行为 parity 契约删的是代码不是行为大规模删除重构最怕删代码的同时删掉了行为。设计文档用三条 parity 契约锁死行为一致性real_home_dir/ToolCall定义逐字搬迁语义不变。函数签名real_home_dir() - OptionPathBuf与ToolCall { id, name, arguments }三字段结构体在 D1 前后完全一致。daemon permission 流 wire 映射不变parse_permission_decision对allow/always_allow/其它→Deny的映射逐字对齐 core 版变体Allow→AllowOnce是纯改名语义放行一次相同。capabilities 的AllowOnce/AllowAlways/Deny覆盖 daemon 全部用法daemon 从不使用Ask无缺口。被删的球本体无外部行为conversation/provider/ctx/tool 的执行机器早已不被任何存活代码调用删除不改变任何运行时路径。当前源码可验证第 2 条daemon 的live_api.rs中fallback_approval_decision将ApprovalMode::AcceptEdits | Plan映射为PermissionDecision::Deny、Build | Auto映射为PermissionDecision::AllowOnce与 parity 契约一致。五、测试与验证策略每刀都留一个绿色状态计划的验证节奏非常明确适用于任何分阶段重构每任务后cargo build --workspacecargo test --workspace --no-run编译所有测试目标——这是本项目用教训换来的经验只编译 lib 会漏掉 orphan 测试touched crate 测试绿。每任务一提交docs/superpowers目录用git add -f强制纳入版本控制。D1 专项real_home_dir/ToolCall搬迁后 core 单测绿搬迁时带原测试一并搬。D2 专项新parse_permission_decision单测三 wire→三变体 daemon permission 相关测试绿。真机验证D2 唯一行为面webui 审批流在 Build 模式弹审批→Allow/Always/Deny 各一次确认/chat/permission、/live/permission端点仍工作。已知例外daemon 的 2 个 webui embedded-asset 测试是既有环境性失败与本次重构无关不算回归。六、风险与回滚让每一步失败都可控设计文档把风险定级为中低理由在于刀法本身的性质D1/D2 是符号搬迁 改名编译器驱动——漏改任何一处引用cargo build立刻报错不存在悄悄跑飞的引用D3 是纯删除cargo test --workspace --no-run兜住 orphan 测试每刀独立 commit坏在哪一刀就单独回滚哪一刀不影响其它刀D3 之前 D1/D2 已绿若删除炸掉漏了某处引用编译器立刻指出不存在越删越黑盒的状态。最大的坑是orphan 测试删 conversation/tool 可能留下crates/atomcode-core/tests/*.rs引用被删模块如set_messages_resume_test.rs用core::ctx。D3 必须一并处理靠--no-run抓出全部。七、非目标YAGNI知道不做什么同样重要计划明确列出本子项目不做的事情防止范围蔓延不动存活 core 模块的功能stream/proxy/plugin/skill/graph/…只搬 2 个符号进来不删 daemon 的atomcode-core依赖——daemon 仍使用core::stream等存活类型当前仓库中 daemon 实际消费的是atomcode_kernel::stream::TokenUsage见 daemon/lib.rs不继续退役其它 core 模块stream/proxy/plugin/skill→L1——那是后续 E/F/G 子项目的事core 删 D 后仍存活为中等大小 crate不改 capabilities 已有的PermissionDecision变体 /from_value——只新增 wire 解析器。八、总结从这份计划中可复用的方法论子项目 D 的价值不止于删掉了四个模块而在于它示范了一套可复制到任何大型 Rust workspace 的模块退役流程审计先行先精确列出谁在碰球——外部代码消费者、存活模块引用、纯函数 vs 结构体、架构分层约束core 不能依赖 capabilities、core 不依赖 kernel每个结论都要有代码位置佐证先搬后删把可分离的符号纯函数、仅被存活模块使用的结构体先搬进存活模块把类型归到正确的域审批类型归审批域让删除变成最后一步的纯机械操作parity 契约显式化搬迁逐字、wire 映射不变、改名注明纯改名——把行为不变从口头承诺变成可 grep、可测试的清单编译驱动 独立提交每刀一个绿色状态、一个独立 commit失败只回滚一刀YAGNI 边界明确列出不做什么防止重构过程中顺手改坏存活功能。这套方法论在 AtomCode 仓库中已有完整落地证据审批类型与 wire 解析器位于 approval.rsdaemon 的权限桥接 permission_bridge.rs 与 live API live_api.rs 均已切换到 capabilities 侧类型crates/目录下已无atomcode-core。计划与实现相互印证构成了一份完整、可引用的 Rust 模块退役参考案例。赞分享人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载相关推荐Atomcode 架构退役实战以删除 core::tool 纠缠球为例的系统性模块拆除方法论Atomcode 架构退役实战以删除 core::tool 纠缠球为例的系统性模块拆除方法论 本文基于仓库中 子项目 D 设计文档 https://lin人工智能AI Agent代码智能体自主智能体MCP ClientsCLI退役 core::conversation将 AtomCode TUI 会话模型端口至 kernel Message 的设计与实践退役 core::conversation将 AtomCode TUI 会话模型端口至 kernel Message 的设计与实践 这是一份面向架构师与 TU人工智能AI Agent代码智能体自主智能体MCP ClientsCLIatomcode 内核迁移实录/compact 摘要 provider 迁入 kernel-native factory退役 core::provider 子项目 Aatomcode 内核迁移实录/compact 摘要 provider 迁入 kernel native factory退役 core::provider人工智能AI Agent代码智能体自主智能体MCP ClientsCLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考