claw-code Rust 移植行为对等性Parity深度解读Mock Harness、9-Lane 检查点与 40 工具规格审计【免费下载链接】claw-codeAn agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention.项目地址: https://gitcode.com/gh_mirrors/claudeco/claw-code本文以仓库根目录的 PARITY.md 为唯一主体文档展开。该文档是 claw-code Rust 移植工程的对等性状态机——它被 rust/scripts/run_mock_parity_diff.py 直接消费逐条记录 Rust 端相对于上游 Python 实现的行为对齐进度从 Mock LLM 对等性 Harness 的里程碑推进、9 条功能 Lane 的合并检查点到 40 个暴露工具规格Tool Spec的真实度分级审计。读完本文你将掌握如何读懂 PARITY 清单、如何复现 12 个脚本化对等性场景、如何核对 9-Lane 提交哈希与工具面分级以及这些结论背后的源码证据落在哪些文件。一、PARITY.md 是什么一份被脚本消费的对等性状态机顶层 PARITY.md 的定位在文档开头就写得很明确Canonical document: this top-levelPARITY.mdis the file consumed byrust/scripts/run_mock_parity_diff.py.也就是说这份文档不是给人类读着玩的状态汇报而是机器可校验的契约。校验脚本 rust/scripts/run_mock_parity_diff.py 会读取场景清单 rust/mock_parity_scenarios.json 中每个场景的parity_refs字段逐条检查其引用的标题是否真实存在于PARITY.md正文中ensure_refs_exist()随后运行 Rust 侧的 mock parity harness 集成测试产出报告并与清单做 diff。任何清单声明了、文档没写、测试没跑的断裂都会以非零退出码暴露出来。文档记录了一个关键的 9-lane 检查点状态All 9 lanes merged onmain当时main的 HEAD 为ee31e00stub 实现被真实的 AskUserQuestion RemoteTrigger 替换之前的节点。仓库统计为292 commits onmain/ 293 across all branches、9 crates、48,599 tracked Rust LOC、2,568 test LOC、3 authors时间跨度 2026-03-31 → 2026-04-03。Mock 对等性 Harness 侧统计为12 个脚本化场景、21 条捕获的/v1/messages请求记录于 rust/crates/rusty-claude-cli/tests/mock_parity_harness.rs。这些数字的意义在于PARITY.md 把行为对等从一句口号变成了可计数、可追溯、可回归的工程度量。二、Mock 对等性 Harness在无外部 LLM 的前提下证明行为等价行为对等最难的地方在于可复现性——真实模型响应不确定无法作为断言基准。PARITY.md 记录的解决方案是三层组合确定性的 Anthropic 兼容 Mock 服务rust/crates/mock-anthropic-service 提供/v1/messages接口根据SCENARIO_PREFIX见 mock_parity_harness.rs返回脚本化响应干净环境 CLI Harnessrust/crates/rusty-claude-cli/tests/mock_parity_harness.rs 中的集成测试clean_env_cli_reaches_mock_anthropic_service_across_scripted_parity_scenarios会为每个场景创建临时工作区、注入隔离的环境变量端到端启动 CLI行为 diff/清单校验器rust/scripts/run_mock_parity_diff.py 汇总清单引用与测试结果。两个里程碑覆盖 12 个脚本化场景Milestone 1基础能力覆盖 5 个场景场景验证内容streaming_text无工具调用的流式文本输出read_file_roundtripread_file 工具执行与最终合成grep_chunk_assemblygrep_search 分块 JSON 输出的组装write_file_allowedworkspace-write 模式下写入成功与文件系统副作用write_file_deniedread-only 模式下写入被拒绝并返回错误Milestone 2行为扩展追加 7 个场景场景验证内容multi_tool_turn_roundtrip同一轮 assistant turn 内连续执行 read_file grep_searchbash_stdout_roundtripdanger-full-access 模式下 bash 执行与 stdout 回传bash_permission_prompt_approvedworkspace-write 向 bash 升级权限时批准响应bash_permission_prompt_denied升级权限时拒绝响应plugin_tool_roundtrip外部插件工具加载并经运行时工具注册表执行auto_compact_triggered累计输入 token 超过阈值时触发自动压缩token_cost_reportingJSON 输出中包含 usage token 计数与estimated_cost12 个场景的权威描述集中在 rust/mock_parity_scenarios.json每个条目带categorybaseline / file-tools / permissions / multi-tool-turns / bash / plugin-paths / session-compaction / token-usage与parity_refs反向锚定 PARITY 文档章节。Harness 测试代码中每个场景用ScenarioCase结构声明permission_mode、allowed_tools、prepare与assert例如write_file_denied使用read-only模式 allowed_tools: Some(write_file)从而在单一测试函数内完成同一工具、不同权限、不同结果的对照见 mock_parity_harness.rs。复现命令cd rust/ # 运行全部 12 个脚本化场景需要 cargo 与 Rust 工具链 ./scripts/run_mock_parity_harness.sh # 行为清单 / parity diff--no-run 时只校验场景清单引用与 PARITY.md 的一致性不跑测试 python3 scripts/run_mock_parity_diff.py python3 scripts/run_mock_parity_diff.py --no-run手动启动 Mock 服务进行本地联调cd rust/ cargo run -p mock-anthropic-service -- --bind 127.0.0.1:0服务启动后会打印MOCK_ANTHROPIC_BASE_URL...将该地址设置为ANTHROPIC_BASE_URL并使用任意非空ANTHROPIC_API_KEY即可把真实 CLI 指向 Mock 服务细节见 rust/MOCK_PARITY_HARNESS.md。Harness v2 行为清单PARITY.md 将 Harness v2 的行为清单归纳为六类并在 rust/mock_parity_scenarios.json 中建立了场景 → 行为的映射多工具 assistant 轮次multi_tool_turn_roundtripBash 流程往返bash_stdout_roundtrip 两个权限提示场景跨工具路径的权限执行write_file_denied、bash_permission_prompt_*插件工具执行路径plugin_tool_roundtrip文件工具——Harness 验证过的流程read_file_roundtrip、grep_chunk_assembly、write_file_*流式响应支持三、9-Lane 检查点从固定载荷 stub 到真实注册表实现的合并里程碑PARITY.md 的核心章节是 9-Lane 检查点表每条 Lane 都锚定了 feature commit、merge commit 与源码证据LaneStatusFeature commitMerge commitEvidence1. Bash validationmerged36dac6c1cfd78abash_validation.rs10042. CI fixmerged89104ebf1969cesandbox.rs22/-13. File-toolmerged284163ba98f2b6file_ops.rs195/-14. TaskRegistrymerged5ea138e21a1e1dtask_registry.rs3365. Task wiringmergede8692e4d994be6tools/src/lib.rs79/-356. TeamCronmergedc486ca649653feteam_cron_registry.rs、tools/src/lib.rs441/-377. MCP lifecyclemerged730667fcc0f92emcp_tool_bridge.rs、tools/src/lib.rs491/-248. LSP clientmerged2d66503d7f0dc6lsp_client.rs、tools/src/lib.rs461/-99. Permission enforcementmerged66283f4336f820permission_enforcer.rs、tools/src/lib.rs357Lane 1 — Bash validation诚实记录分支先行、main 滞后这条 Lane 是文档中最体现honest parity精神的例子。Feature commit36dac6c一次性加入 6 个验证子模块——readOnlyValidation、destructiveCommandWarning、modeValidation、sedValidation、pathValidation、commandSemantics1005across 2 files。但在 PARITY 记录的时间点main上的实际活跃实现仍是 rust/crates/runtime/src/bash.rs283 LOC含 timeout/background/sandbox 执行权限由PermissionEnforcer::check_bash()做只读门控而专用验证模块尚未落 main。文档明确写道Onmain, this statement is still materially true——上游 Bash 工具有 18 个子模块Rust 当时只有 1 个。从当前仓库树看rust/crates/runtime/src/bash_validation.rs 已存在于 runtime crate 中验证能力已随后续合并落地Still open 清单也将 Bash validation lane merged ontomain 标记为已完成。Lane 2 — CI fix用能力探测替代二进制存在性假设Feature commit89104ebfix(sandbox): probe unshare capability instead of binary existence的动机直指 CI 稳定性此前 sandbox 支持与否取决于系统上是否存在某个二进制而 rust/crates/runtime/src/sandbox.rs385 LOC改为从实际的unshare能力与容器信号ContainerEnvironment.in_container markers推断 sandbox 支持度见 sandbox.rs。这之所以重要是因为 CI 工作流.github/workflows/rust-ci.yml运行cargo fmt --all --check与cargo test -p rusty-claude-cli在容器环境中执行二进制存在 ≠ 能力可用。Lane 3 — File-tool边界防御三件套Feature commit284163b为文件工具补齐了边缘情况护栏MAX_READ_SIZE/MAX_WRITE_SIZE均为 10 MB见 file_ops.rs、基于首块 NUL 字节的二进制检测is_binary_file()读前 8192 字节以及基于规范化路径的工作区边界校验validate_workspace_boundary()拒绝../逃逸与符号链接逃逸。file_ops.rs 当前为 744 LOCgrep 默认忽略.git、node_modules、target、dist等目录GLOB_SEARCH_IGNORED_DIRS。Lane 4/5 — TaskRegistry 与 Task wiring从 stub 状态到真实内存注册表Lane 4 引入 task_registry.rs335 LOC一个线程安全ArcMutexHashMap...的内存任务注册表提供create、get、list、stop、update、output、append_output、set_status、assign_team等完整生命周期操作TaskStatus枚举覆盖created / running / blocked / completed / failed / stopped六态。Lane 5 则在 tools/src/lib.rs 中通过execute_tool()与具体的run_task_*handler 把TaskCreate、TaskGet、TaskList、TaskStop、TaskUpdate、TaskOutput六个工具接入注册表global_task_registry()以OnceLock提供进程级单例。文档特别划清边界它不自行增加外部子进程执行——这是注册表级对等不是进程调度级对等。Lane 6 — TeamCron团队与定时任务的生命周期化team_cron_registry.rs363 LOC同时提供线程安全的TeamRegistry与CronRegistrytoolscrate 将TeamCreate、TeamDelete、CronCreate、CronDelete、CronList接入其中。文档同样注明局限已具备内存生命周期行为但尚未达到真正的后台调度器或 worker 舰队。Lane 7 — MCP lifecycle连接状态的注册表桥mcp_tool_bridge.rs406 LOC把 MCP 工具面ListMcpResources、ReadMcpResource、McpAuth、MCP与既有McpServerManager运行时桥接起来跟踪服务器连接状态McpConnectionStatusdisconnected / connecting / connected / auth_required / error、资源列表、资源读取、工具列表、工具分派确认、认证状态与断开事件。McpToolRegistry内部持有ArcOnceLockArcMutexMcpServerManager即注册表连接到底层 stdio MCP 管理器。文档明确 scope这取代了纯 stub 响应但端到端 MCP 连接填充与更深的传输/运行时能力仍依赖 mcp_stdio.rs、mcp_client.rs、mcp.rs。Lane 8 — LSP client诊断/悬停/定义/引用/符号的注册表分派lsp_client.rs438 LOC以有状态注册表建模 diagnostics、hover、definition、references、completion、symbols、formatting。工具面中暴露的LSP工具 schema 当前枚举symbols、references、diagnostics、definition、hover请求经registry.dispatch(action, path, line, character, query)路由。文档诚实指出completion/format 在注册表模型里存在但未在工具 schema 边界清晰暴露真正的外部 language-server 进程编排仍在注册表之外。Lane 9 — Permission enforcement全工具权限门控permission_enforcer.rs340 LOC在 permissions.rs 之上叠加工具门控、文件写入边界检查与 bash 只读启发式。tools/src/lib.rs 暴露enforce_permission_check()并在每个工具规格中携带required_permission。具体行为将在第五节详述。四、Tool Surface40 个暴露工具规格的真实度分级PARITY.md 明确mvp_tool_specs()位于 rust/crates/tools/src/lib.rs暴露40 个工具规格。核心执行能力已就位的是bash、read_file、write_file、edit_file、glob_search、grep_search既有产品工具包括WebFetch、WebSearch、TodoWrite、Skill、Agent、ToolSearch、NotebookEdit、Sleep、SendUserMessage、Config、EnterPlanMode、ExitPlanMode、StructuredOutput、REPL、PowerShell。9-Lane 推送把Task*、Team*、Cron*、LSP与 MCP 工具从固定载荷 stub 换成了注册表后端 handler。Brief是execute_tool()中的执行别名不是独立暴露的规格。真实实现行为对等深度不一工具Rust 实现行为备注bashruntime::bash283 LOC子进程执行、timeout、后台、sandbox——强对等验证子模块经36dac6c补齐read_file / write_file / edit_file / glob_search / grep_searchruntime::file_opsoffset/limit 读取、创建/覆盖写入、old/new 字符串替换、glob 匹配、ripgrep 风格搜索——良好对等TaskCreate / TaskGet / TaskList / TaskStop / TaskUpdate / TaskOutputruntime::task_registrytools注册表后端的完整任务生命周期——良好对等TeamCreate / TeamDelete / CronCreate / CronDelete / CronListruntime::team_cron_registrytools团队生命周期 任务分配、cron 条目管理——良好对等LSPruntime::lsp_clienttools诊断/悬停/定义/引用/完成/符号/格式化——良好对等ListMcpResources / ReadMcpResource / MCPruntime::mcp_tool_bridgetools有状态 MCP 调用桥——良好对等WebFetch / WebSearch / TodoWrite / Skill / Agent / NotebookEdit / REPL / PowerShell / Configtools中等对等部分细节如内容截断、重定向处理待核实Sleep / SendUserMessage / Brief / ToolSearch / EnterPlanMode / ExitPlanMode / StructuredOutputtools良好对等仅存 stub只有表面规格无行为工具状态备注AskUserQuestionstub返回 pending 载荷缺真实交互 UI 接线McpAuthstub需要超越 MCP lifecycle 桥的完整认证 UXRemoteTriggerstub需要 HTTP 客户端TestingPermissionstub仅测试用途五、PermissionEnforcer 纵深结构化 allow/deny 与分级模式9-Lane 中最值得展开的是权限执行因为它是跨工具路径的横切关注点。从 permission_enforcer.rs 源码看结构化结果EnforcementResult是带outcometag 的枚举——Allowed或Denied { tool, active_mode, required_mode, reason }便于上层把拒绝原因直接回传模型核心入口PermissionEnforcer::check(tool_name, input)委托给PermissionPolicy::authorize()。特别设计是当 active mode 为Prompt时直接放行return EnforcementResult::Allowed把交互式确认交给调用方的提示流程而不是硬拒绝——因为 enforcer 本身没有 prompter动态必选模式check_with_required_mode()支持按 bash 命令分类动态判定所需权限比较active_mode required_mode模式具备偏序ReadOnly WorkspaceWrite DangerFullAccess文件写入check_file_write()在ReadOnly模式直接拒绝WorkspaceWrite模式调用is_within_workspace()校验规范化边界bash 门控check_bash()在只读模式下拒绝变更性命令并阻止未确认的 prompt 模式 bash。工具面一侧tools/src/lib.rs 的ToolSpec结构携带required_permission: PermissionModeenforce_permission_check()在execute_tool()分派前执行门控。Harness 侧由write_file_denied、bash_permission_prompt_approved、bash_permission_prompt_denied三个场景覆盖见 mock_parity_harness.rs 中对应的ScenarioCase权限模式设置。六、从旧 PARITY 清单收敛而来的已完成项PARITY.md 保留了一组从旧清单调和的勾选项均带源码锚点可直接复核路径穿越防护符号链接跟随、../逃逸——见 file_ops.rs 的validate_workspace_boundary()读写大小限制——MAX_READ_SIZE/MAX_WRITE_SIZE 10 MB二进制文件检测——NUL 字节探测权限模式执行read-only vs workspace-write——permission_enforcer.rs配置合并优先级user project local——ConfigLoader::discover()按用户 → 项目 → 本地顺序加载由对应测试loads_and_merges_claude_code_config_files_by_precedence()验证合并顺序插件 install/enable/disable/uninstall 流程——/plugin斜杠命令处理位于 rust/crates/commands/src/lib.rs委托给 rust/crates/plugins/src/lib.rs 的PluginManager::{install, enable, disable, uninstall}无#[ignore]测试掩盖失败——对rust/**/*.rs的 grep 结果为 0 个忽略测试七、仍待解决项与迁移就绪度一份诚实的开放清单PARITY.md 的价值正在于它不粉饰未完成项端到端 MCP 运行时生命周期超出当前 main 上的注册表桥部分连接填充、传输深度输出截断大 stdout/文件内容——已完成会话压缩行为匹配auto_compaction阈值来自环境变量——已完成token 计数 / 成本追踪精度——已完成Bash validation lane 合并上 main——已完成当前仓库树中的 bash_validation.rs 即为落地证据每个 commit 的 CI 全绿这是唯一在迁移就绪度清单中连续出现两次的未决项迁移就绪度清单的最终形态是PARITY.md 保持维护与诚实9 条请求的 Lane 均以 commit 哈希 当前状态记录9 条 Lane 全部落地main无#[ignore]测试掩盖失败CI 每个 commit 全绿代码库形态足以用于交接文档结语PARITY 作为移植工程的行为对等账本从这份文档可以提炼出可复用的工程方法论行为对等不是一次性的验收而是一条可脚本化、可回归、可追溯的持续契约。claw-code 的做法是——用确定性的 Mock 服务消除外部依赖的随机性12 个脚本化场景、21 条捕获请求用 commit 哈希与 merge commit 让每条能力 Lane 可审计9-Lane 检查点用 40 个工具规格的分级表让真实实现 / 中等对等 / 仅 stub一目了然最后用run_mock_parity_diff.py把场景清单、测试与 PARITY 文档三方绑定任何一端漂移都会在 CI 中显形。这份 PARITY.md 既是 Rust 移植的进度账本也是Agent 维护的仓库如何自我证明行为正确的参考范式。【免费下载链接】claw-codeAn agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention.项目地址: https://gitcode.com/gh_mirrors/claudeco/claw-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考