人工智能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点击查看免费下载本文以 crates/atomcode-kernel/SPIKE.md 为主体讲清 atomcode 项目中「中立内核neutral kernel」平台策略的 Phase A0 设计验证内核如何用一条双向、可序列化的AgentCommand/AgentEvent句柄驱动一个完整的 agent 运行循环并通过 14 项可执行论断claim逐一证明「审批不进内核、工具选择性挂载、一种原语适配全部前端」等关键设计假设。读完本文你能理解该内核的 Driver 模型与 Hook 机制perceive vs inject并能直接用cargo test -p atomcode-kernel复现全部验证结论。一、Spike 的定位只验证 API 形状不追求实现SPIKE.md 开篇明确了这个 crate 的性质Design-validation spike for the neutral-kernel platform strategy … Internals are minimal/throwaway — the public APIshapeis what Phase A1 carries the proven production hot-paths into.即atomcode-kernel是一个设计验证 spikePhase A0对应原文引用的中立内核平台策略规格2026-06-05-atomcode-kernel-platform-strategy.md。它的内部实现是「最小化、可抛弃」的真正要证明的是公共 API 的形状shape是否成立——Phase A1 将把生产环境已验证的热点路径「原样搬进」这些槽位而不是重写。这一点在 Cargo.toml 中也得到印证[package] name atomcode-kernel description Spike: neutral agent kernel (Phase A0 — design validation, throwaway internals) publish false同时该 crate 通过一个test-supportfeature 提供test_support::isolate_home()供各 crate 的测试隔离~/.atomcode避免污染开发者的真实数据目录。二、要证明什么14 项核心论断一览SPIKE.md 的核心是一张「论断 → 验证位置」的表。每一项 claim 都对应一个具体的测试函数跑cargo test -p atomcode-kernel即可全部复现#论断Claim验证位置1中立内核——一个 turn 可以在没有 persona、没有任何 middleware 的情况下运行tests/spike_claims.rsneutral_turn_runs_without_persona_or_middleware2审批是一种基于 id 关联往返round-trip的外部 middleware同上approval_middleware_gates_risky_tool_via_id_roundtrip3工具选择性挂载——未挂载的工具不可见、不生效src/tool.rs 测试only_mounted_tools_are_exposed_or_resolvable4同一个原语同时服务 one-shot 与交互式 driver同上one_shot_adapter_auto_answers_and_aggregates examples/minimal_specialization.rs5wire 兼容serde 往返可序列化→ web/daemon 可复用同一 seam同上events_and_commands_are_wire_serializable6LifecycleHooks——turn 级注入turn_end继续循环TurnStarted观察同上lifecycle_hook_injects_and_continues_loop7完整 LifecycleHooks 面——8 个 turn 级点全部接线且触发同上lifecycle_hooks_complete_surface_all_fire8执行状态被记录Message.meta 投影给 LLM尾部 reminder 缓存安全同上execution_state_recorded_projected_to_llm_and_cache_safe9轮次预算投影给 LLMround X/Y 硬上限记录在meta.round缓存安全同上round_budget_projected_to_llm_and_hard_capped10on_model_response拿到mut Message——可以变换响应变换会落盘经 Snapshot 验证同上on_model_response_can_transform_response_into_storage11on_model_response对 tool_calls 的删改被内核尊重被删的调用不执行同上dropping_tool_calls_in_on_model_response_prevents_execution12ToolMiddleware 的before可改写/拦截不产生幽灵 ToolStartedafter变换结果同上tool_middleware_rewrites_blocks_and_transforms13命令级审批——参数感知的Tool::risk(args)审批中间件拦截危险命令、放行安全命令、按会话缓存授权同上dangerous_command_requires_approval_safe_does_not_and_grant_is_cached14user_prompt_submit可以拦截 prompt返回Err→ prompt 被拒、不产生 turn、不入库同上user_prompt_submit_can_block_a_prompt这张表是整份 spike 文档的骨架它把一个「内核应该长什么样」的抽象主张拆成了 14 条可被编译器与测试裁决的具体命题。下文选取几条关键 claim结合源码看它们到底验证了什么。三、代表性论断的源码剖析3.1 Claim 1没有 persona、没有 middlewareturn 依然能跑neutral_turn_runs_without_persona_or_middleware 只注册了一个EchoTool构造 Agent 时不给 hooks、不给 middlewarelet handle Agent::builder() .provider(provider) .tools(reg.mount([echo])) .build() .spawn();测试断言三件事安全工具被执行了echoed、turn 正常完成completed、内核没有发出任何Request事件!requested。最后一条是关键——它证明「中立」不是口号没有任何特殊化配置时内核自身不会凭空产生审批、提问等外部交互需求。3.2 Claim 3选择性挂载——未挂载的工具零影响这一 claim 的实现在 tool.rs 的ToolRegistry::mount/// Select the subset exposed to the LLM. Unmounted tools never produce a /// ToolDef and are not resolvable during a turn → zero effect on the agent. pub fn mount(self, names: [str]) - MountedTools从源码结构看mount会先select出名字子集然后固化成一个MountedToolsSnapshot含ToolCatalogRevision、选中的工具集合、以及预先渲染好的ToolDef列表。这意味着模型在某一轮看到的工具定义与该轮实际可解析的工具来自同一个快照未挂载的工具既不会产生ToolDef供 LLM 看见也不会在执行阶段被解析到——正是「invisible/inert」两个词的落点。tool.rs模块头部还写明了内核的信任模型契约这是理解挂载语义的必要前提内核不做沙箱挂载一个工具就是把宿主进程的完整环境权限文件系统、网络、环境变量授予其executeRiskLevel只是建议性元数据而非执行边界内核在这一高度上唯一内建的安全机制是工具结果字节上限AgentBuilder::max_tool_result_bytes默认 64 KiB。OS 级隔离seccomp、容器、独立子进程是嵌入方的责任。3.3 Claim 2 / 13审批完全活在 specialization 一侧approval_middleware_gates_risky_tool_via_id_roundtrip 展示了审批的完整回路模型发起risky_write工具调用ApprovalMiddleware位于 testkit.rs即 specialization 侧经RequestCtx挂起内核发出AgentEvent::Request { id, kind: approval, payload }driver 收到后回发AgentCommand::Respond { id, value: {decision: allow} }工具执行结果以wrote: ...出现。Claim 13 的 dangerous_command_requires_approval_safe_does_not_and_grant_is_cached 进一步验证了三个层次的行为参数感知arg-aware同一个bash工具ls被risk(args)评为 Safe直接执行、零次审批询问rm -rf /tmp/x被评 Risky触发一次审批。Tooltrait 中对应方法签名为fn risk(self, _args: str) - RiskLeveltool.rs L215-L217默认Safe——工具自己最清楚哪条命令危险会话级授权缓存第一次rm -rf的Respond带上remember: true后同一会话中完全相同的危险命令第二次执行时asked仍为 1只问过一次ran为 2两次都执行了。这正呼应了 SPIKE.md 的边界事实第 1 条内核核心文件agent.rs、event.rs、tool.rs从不出现 approval 一词审批整个住在testkit::ApprovalMiddleware之上构建在RequestCtx::request这个通用往返之上。3.4 Claim 8 / 9执行状态的「记录 → 投影 → 缓存安全」三段式这两条 claim 验证的是同一套规则的两侧记录侧on_model_response时内核把执行统计写入 kernel 原生的Message.metasidecar。当前 message.rs 中的 MessageMeta 携带tokens、elapsed_ms、ctx_window、used_tokens、utilization、round以及turn_id/request_id等关联 ID。Spike 文档写的是「MessageMeta只持有内核实测事实tokens、elapsed_ms、ctx_window、used_tokens、utilization、roundcost 等特化关切留在内核之外」——当前字段集是其自然演进新增的均为#[serde(default)]的增量字段旧快照仍可反序列化。投影侧pre_requesthook 把当前利用率投影为一条尾部 reminder发给 LLM。测试 execution_state_recorded_projected_to_llm_and_cache_safe 用MockProvider捕获了两次真实外发请求逐条断言第 1 次调用只有用户消息尚无 reminder历史里还没有 meta第 2 次调用中历史用户消息逐字节相同b[0] calls[0][0]前缀缓存安全的直接证据assistant 消息文本保持干净meta 是 sidecar不烘焙进text最后一条消息正是投影出的([User], [ctx 10%])尾部提醒。硬上限侧round_budget_projected_to_llm_and_hard_capped 让 MockProvider 脚本化 4 轮工具调用模型永不收手而 builder 设了.max_rounds(3)。断言结果实际 LLM 调用只有 3 次第 4 轮脚本从未被请求投影逐轮升级[round 1/3]→[round 2/3]→[round 3/3 - final round, wrap up now]触顶时发出含 max rounds 的Error事件每轮 assistant 消息的meta.round依次为1, 2, 3。max_rounds在引擎中就是一个普通的Optionu32engine.rsAgentBuilder::max_rounds但 SPIKE.md 强调其角色是「safety fuse」——即使模型无视投影的提醒循环也必然终止。3.5 Claim 10 / 11on_model_response拿到mut Messageon_model_response_can_transform_response_into_storage 用RedactHook把模型输出的my password is SECRET改写成my password is [redacted]随后发送AgentCommand::Snapshot命令从快照消息里验证变换后的文本确实落盘、SECRET已消失且 hook 看到的就是内核填好metatokens.prompt 50的响应对象。Claim 11 则验证了tool_calls的可编辑性DropToolsHook在on_model_response里清空tool_calls后内核不再执行任何工具无ToolStarted/ToolResultturn 因 pending 为空而正常完成。这与 hook.rs 中 trait 方法的注释一致on_model_response可以「observe 或 transform——包括删除/改写tool_calls内核会尊重HONORS」。3.6 Claim 14user_prompt_submit可以拒绝整条 promptuser_prompt_submit_can_block_a_prompt 中RejectPromptHook对 prompt 文本返回Err随后断言驱动收到含 rejected 的Error、没有TurnStartedturn 从未开始、且 Snapshot 中不存在被拒的 prompt 文本它从未进入对话。这与 hook.rs 中user_prompt_submit的 trait 注释完全对应「rewrite / augment the text, or returnErr(reason)to BLOCK the prompt — it never enters the conversation and no turn runs」。四、Driver 模型一个原语四种前端形态SPIKE.md 的 Driver 模型一节是整个 API 设计的主张核心One primitive: a long-lived session consumingAgentCommandand emittingAgentEvent(AgentHandle). The round-trip seam is the id-correlatedAgentEvent::Request{id,kind,payload}↔AgentCommand::Respond{id,value}.关键细节是解析 middleware 挂起的那个oneshot只存在于RequestCtx内核内部绝不出现在任何事件里。正因为事件与命令中不含进程内的 channel 句柄它们才可以整体 serde 序列化——同一套协议既能在进程内工作也能跨 wire 工作。四种 driver 形态都坐在这一原语之上Driver命令来源事件去向Request 由谁回答one-shot / CI / CodeReview一条SendMessage聚合为OutcomeAutoRespond策略TUI按键渲染循环模态框 →RespondWebWS/HTTP →AgentCommandAgentEvent→ SSE/WS用户 →Respond帧server / daemon每会话 RPC每会话 SSE策略或远端用户其中 one-shot 路径在 engine.rs 中实现为run_to_completion(input, policy)它内部其实就是spawn()出一个 handle然后自动循环消费事件——遇到Request就用AutoRespondAllowAll / DenyAll回Respond最终把TextDelta聚合成text、把所有ToolResult收集进tool_results、把终止原因放进stop得到结构化的 Outcome还带error、http_status、error_code等字段失败不会被吞掉伪装成成功。Claim 5 的 events_and_commands_are_wire_serializable 用最小的 serde 往返AgentEvent::Request与AgentCommand::Respond各序列化/反序列化一次封住了这一主张。examples/minimal_specialization.rs 则把两种形态放在一起演示同一个AgentBuilder挂EchoTool、RiskyWriteTool、persona、ApprovalMiddleware先跑run_to_completion(do the demo, AutoRespond::AllowAll)再spawn()成交互式 handle在事件循环里手动把Request答成allow——claim 4 的完整证据。五、Hook 面perceive 与 inject 是两套机制SPIKE.md 对 hook 面的划分值得单独强调因为它划定了观察与干预的能力边界perceive感知 只读的AgentEvent流。观察者无法改变循环inject注入LifecycleHookstrait。它在循环内部运行可以修改状态、甚至让循环继续。trait 在 hook.rs 声明各钩子按「是否落盘PERMANENT/EPHEMERAL」标注了存储契约例如session_start会话开始、turn 之前可注入种子上下文/persona持久化user_prompt_submit用户消息进循环前改写或Err拦截持久化turn_start每个用户消息触发一次非每 round持久化pre_request每次 LLM 请求前改写外发消息EPHEMERAL——作用于每请求的克隆绝不污染前缀缓存on_model_response拿到尚未入库的mut Message含内核填好的 meta可变换持久化offer_continuation模型想停无 tool calls时被调用返回Some(text)注入后续 user 消息并继续循环turn_complete/on_error/session_end回合结束、错误、会话结束的观察点。SPIKE.md 列出的是 8 个 turn 级点session_start、user_prompt_submit、turn_start、pre_request、on_model_response、turn_end、on_error、session_endClaim 7 断言「每一个都被接线且会触发」。当前 lifecycle_hooks_complete_surface_all_fire 实际校验的已经是扩展后的 12 个点——新增了on_request只读的最终外发请求观察telemetry/前缀缓存 RCA 的落点、on_text_delta/on_reasoning_delta流式分片的就地变换以及offer_continuation/turn_completespike 时期写作 turn 续跑/结束的机制现与 README 中描述的 verify loop seam 对应。这个演进方向说明 spike 的 API 形状经受住了压力新能力是加钩子而不是改形状。工具级关切则被明确划到另一套组合机制ToolMiddlewarebeforeafter不进LifecycleHooks。Claim 12 的 tool_middleware_rewrites_blocks_and_transforms 用三个场景钉死了语义(a)before改写参数 → 改写后的参数到达执行层结果含 rewritten(b)before拦截 →不产生幽灵ToolStarted事件但仍给出一条内容含 blocked 的ToolResult模型不会被蒙在鼓里(c)after变换结果 → 结果以[truncated]开头。跨进程注入则复用 id 关联的Request/Respond往返hook 向远端 driver 提问并 await 答案机制与审批完全同构。六、关键边界事实Key boundary factsSPIKE.md 明确列出了三条边界事实是理解「内核不做什么」的浓缩内核核心从不点名 approval。工具携带参数感知的risk(str) - RiskLevel方法工具自己知道哪些命令危险审批整体住在testkit::ApprovalMiddlewarespecialization 侧之上。ApprovalMiddleware还持有会话级授权缓存——相同的危险命令一个会话只问一次。ToolContext不携带任何语义/图/LSP 服务。当前 ToolContext 定义 只有working_dir、cancel协作式取消 token、progress进度旁路与requester提问 seam——「proving the kernel needs none」。Crate 被排除在 workspacedefault-members之外。工作区根 Cargo.toml 中default-members只有atomcode-cli、atomcode-daemon、atomcode-telemetry、atomcode-tuix所以产品构建完全不受该 spike 影响。另外两条从源码中可以确认的、与 spike 契约一脉相承的约束值得开发者留意见 tool.rs 模块文档must-not-panic 契约execute不允许 panic。工作区 release profile 是panic abort根 Cargo.toml 中profile.release明确设置一个 panic 的工具会直接带走宿主进程结果字节上限AgentBuilder::max_tool_result_bytes默认 64 KiB是内核对工具的唯一内建约束——过大的ToolResult.content会被截断防止失控工具打爆上下文窗口。七、运行与验证SPIKE.md 给出的运行方式只有两条命令均可以在当前仓库直接执行cargo test -p atomcode-kernel cargo run -p atomcode-kernel --example minimal_specialization前者跑通 tests/ 下全部测试包括承载 14 项 claim 的 spike_claims.rs后者运行最小程序演示先以 one-shot 形态打印聚合结果再以交互式形态走一遍Request → Respond的审批往返。dev-dependencies 里启用 tokio 的test-utilfeature让涉及审批挂起的测试能用#[tokio::test(start_paused true)]在虚拟时间上瞬时推进测试因此不需要真实等待。testkit模块testkit.rs提供了验证所需的全部零件MockProvider脚本化多轮流事件、EchoTool/RiskyWriteTool/DangerousBashTool不同风险特征的工具桩、ApprovalMiddleware及各类 hook/middleware 示例RedactHook、DropToolsHook、RejectPromptHook、RoundBudgetHook、ArgRewriteMiddleware等。它们既是 spike 测试的道具也是理解每个 seam 用法的最小可读样例。八、Phase A1形状已证热路径入场SPIKE.md 的收尾给出了明确的下一阶段路线图——把生产热点路径搬进已验证的槽位而不是重写生产组件落点TurnRunner循环agent.rsctx/renderpersona 注入点背后的一个CtxBuilder实现conversationmessage.rs中立 provider 实现provider.rs约束只有一条保留前缀缓存prefix-cache不变量与已有的边缘情况修复。从前文 Claim 8/9 对「历史消息逐字节不变」的断言可以看出这些不变量在 spike 阶段就已是被测试守护的契约而非口头约定。小结crates/atomcode-kernel/SPIKE.md 用一份 14 项论断的清单把「中立内核」从一个架构愿景变成了可编译、可测试、可复现的事实审批、预算、提示拦截、流式变换等能力全部以 middleware/hooks 的形式外挂在AgentCommand/AgentEvent这条可序列化协议之上四种前端形态共享同一个原语记录走Message.metasidecar、投影走pre_request尾部 reminder从而在把执行状态反馈给 LLM 的同时保住前缀缓存。若你在设计自己的 agent 框架这个 spike 提供的最大参考价值在于方法论——先以最小实现把 API 形状变成测试断言再谈往里搬生产代码。赞分享人工智能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点击查看免费下载相关推荐IronClaw 静态内核进程日志设计证明以中立进程日志统一 Agent Turn 与扩展生命周期IronClaw 静态内核进程日志设计证明以中立进程日志统一 Agent Turn 与扩展生命周期 本篇技术指南以 IronClaw 仓库中的内部设计文档《S人工智能AI 应用交互助手AI AgentFreeRTOS 内核 TaskIncrementTick 内存安全证明CBMC 形式化验证实战解析FreeRTOS 内核 TaskIncrementTick 内存安全证明CBMC 形式化验证实战解析 导读 本文围绕 FreeRTOS 官方 CBMC 形式操作系统嵌入式OS嵌入式物联网GitHub_Trending/om/OM1 Unitree G1人形机器人AI控制框架GitHub_Trending/om/OM1 Unitree G1人形机器人AI控制框架 你是否还在为Unitree G1人形机器人的AI控制开发感到困扰复区块链Web3上一篇FASPell论文复现指南手把手教你复现EMNLP 2019最佳中文拼写检查模型下一篇Ladybug天气数据分析5个简单步骤掌握建筑环境模拟核心技能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考