claw-code 实战指南：claw-analog 最小智能体运行器的构建、配置、权限控制与 RAG 集成全解

claw-analog 是 claw-code 仓库中与主 CLI claw 共用同一套 API 栈（Anthropic / OpenAI 兼容 / xAI 提供商标识按模型自动选择，详见 USAGE.md）的精简版 agent 运行器：它提供一个“工具循环 + 显式权限 + workspace 沙箱”的最小可用实现，适合做权限审计、CI 集成、外部编排器（orchestrator）接入和 RAG 语义检索实验。本文基于 how_to_run.md 的完整操作手册，结合 rust/crates/claw-analog/ 的源码实现，系统讲解从构建、环境诊断、配置合并、NDJSON 输出契约到 claw-rag-service RAG 服务的完整落地链路。

1. claw-analog 是什么：定位与运行前提

从 Cargo.toml 的描述可以看到定位："Minimal agent harness: tool loop with explicit permissions and workspace jail."（最小 agent 骨架：带显式权限和 workspace 囚笼的工具循环）。它的依赖只有三个内部 crate——api（多提供商客户端）、runtime（权限执行器）、以及开发依赖 mock-anthropic-service（本地模拟服务，用于无网络测试）。

运行前提：

• 已安装 Rust 和 cargo（PATH 中可用，Windows 上通常是 %USERPROFILE%\.cargo\bin）；
• 已配置所选提供商的 API 密钥（例如 ANTHROPIC_API_KEY）。

工作目录约定： 后续所有命令的“工作目录”都是克隆出的仓库中的 rust/ 目录。如果终端提示符已经位于 …\claw-code-main\rust>，不要再执行一次 cd rust（否则会进入 rust\rust 导致路径错误）。

2. 构建与 doctor 环境诊断

基本构建与帮助：

cd D:\path\to\claw-code-main\rust
cargo build -p claw-analog
cargo run -p claw-analog -- --help

2.1 doctor 子命令：一次看清环境与配置

claw-analog doctor 拥有独立于主运行模式的 --help（其 CLI 定义在 doctor.rs）。它做四件事：

1. 配置预览（merge preview）：合并 .claw-analog.toml（位于 <workspace>/.claw-analog.toml，可用 --config 指定其他路径）与主运行模式的同名标志——--model、--permission、--preset、--output-format、--stream、--no-stream、--no-runtime-enforcer、--accept-danger-non-interactive，另有 --profile 用于显示 profile 文件路径。输出中会打印 NDJSON 契约标识（schema、format_version）、每个生效字段，以及 provenance 溯源行（每个值最终来自 CLI、TOML 还是默认值）；
2. 典型环境变量状态检查（doctor.rs#L16-L24 中的 ENV_CHECK 列表：ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL、OPENAI_API_KEY、OPENAI_BASE_URL、XAI_API_KEY、RAG_BASE_URL）——只报 set / unset 和字符串长度，不打印值；
3. 向上搜索 workspace 中的 Cargo.toml（可用 --manifest-dir 指定），然后默认执行 cargo check -p claw-analog（仅编译检查，不覆盖 target\debug\claw-analog.exe——否则在 Windows 上 cargo run … doctor 时嵌套的 cargo build 会因调试版 exe 正在运行而报“拒绝访问”）；
4. 可选连通性探测：--release-build 改跑 cargo build --release -p claw-analog（产物进 target\release\，与正在运行的 debug exe 不冲突）；--no-build 跳过 cargo；--tcp-ping（别名 --mock）对 ANTHROPIC_BASE_URL 中的 host:port（默认 https://api.anthropic.com）做 TCP connect，不检查 HTTP/TLS 层和响应体。

示例（均从 …\claw-code-main\rust 目录执行）：

cargo run -p claw-analog -- doctor
cargo run -p claw-analog -- doctor --no-build
cargo run -p claw-analog -- doctor --tcp-ping
cargo run -p claw-analog -- doctor -w D:\path\to\repo --preset implement
cargo run -p claw-analog -- doctor --release-build

2.2 config validate：不碰 API 的配置体检

claw-analog config validate（实现于 config_cmd.rs）：

• 解析 .claw-analog.toml（默认 <workspace>/.claw-analog.toml，可用 --config 覆盖），打印简版 merge preview（与 doctor 类似，但只含 TOML + 默认值，不含主运行标志）；
• 校验 profile.toml：与 run 相同的优先级（--profile 标志 → TOML 中的 profile 字段 → 若文件存在则取默认的 ~/.claw-analog/profile.toml）；
• 不发起任何 LLM 或网络 API 请求。

--strict：配置缺失或 profile 无法读取时以错误（退出码 1）收尾。

cargo run -p claw-analog -- config validate -w D:\path\to\repo
cargo run -p claw-analog -- config validate --strict -w .

2.3 complete：生成 shell 自动补全脚本

补全脚本输出到 stdout（自行重定向到 shell 的文档所指示的文件，如 $PROFILE）：

cargo run -p claw-analog -- complete powershell >> $PROFILE
# bash / zsh / fish — 见 `complete --help` 输出

可选值：bash、zsh、fish、powershell（别名 pwsh）。脚本由 main.rs#L411-L421 基于 clap_complete 从 clap 定义生成，因此永远与 CLI 定义同步。

3. 核心运行命令与参数

单任务模式：一个任务作为位置参数（或从 stdin 读入文本）：

# 从 ...\claw-code-main\rust 执行
cargo run -p claw-analog -- -w D:\path\to\repo "Кратко опиши структуру rust/crates"

实时流式输出（SSE，底层调用 stream_message）：

cargo run -p claw-analog -- --stream -w . "Объясни claw-analog в двух предложениях"

允许向 workspace 写文件：

cargo run -p claw-analog -- --permission workspace-write -w . "Добавь комментарий в начало crates/claw-analog/Cargo.toml"

关闭 runtime::PermissionEnforcer 校验（仅保留自己的路径囚笼，不推荐）：

cargo run -p claw-analog -- --no-runtime-enforcer -w . "…"

3.1 完整参数表（CLI 覆盖 TOML 同名项）

默认值常量定义在 main.rs#L179-L187，与下表一一对应：

标志	默认值	用途
--max-read-bytes	262144	read_file / grep_workspace / git_diff / git_log 的读取字节上限
--max-turns	24	“模型 → 工具 → 模型”的最大轮数
--max-list-entries	500	list_dir 行数上限
--grep-max-lines	200	grep_workspace 匹配行的总上限（跨多文件累计；单文件内可用 max_lines 设更小的局部上限）
--glob-max-paths	2000	glob_workspace 返回及 grep_workspace 内 glob 展开的最大路径数
--glob-max-depth	32	glob 目录遍历深度（基于 walkdir），防止无限递归
--output-format	rich	json 时 stdout 输出 NDJSON，便于脚本和外部 agent 消费
--print-tools	—	打印合并后 permission / enforcer 生效的工具清单，然后退出（不发 prompt、不调 API）
--lang	en	注入 system 的语言提示：en 或 ru（只改回复语言，不改 API 模型 id）
--preset	—	none | audit | explain | implement，另支持 auto（从 prompt 启发式推断），详见下文
--session	—	JSON 会话文件路径（相对路径相对 -w 解析）：历史持久化与 resume
--save-session	—	附加导出路径：每次快照时同样写入该文件（可与 --session 组合，也可单独使用，在跑完后导出一次 JSON）
--profile	—	含 line 字段的 TOML 片段（混入 system prompt）。省略时尝试 %USERPROFILE%\.claw-analog\profile.toml（Windows）/ ~/.claw-analog/profile.toml
--permission	read-only	read-only、workspace-write、prompt、danger-full-access、allow，详见 3.3 节
--accept-danger-non-interactive	—	允许在 stdin 不是 TTY（CI 场景）时使用 danger-full-access / allow；TOML 对应 accept_danger_non_interactive = true

配置文件默认从 <workspace>/.claw-analog.toml 读取（若文件存在），可用 --config PATH 指定其他路径。TOML 采用严格 schema：未知键即为解析错误——这是刻意设计，防止拼写错误被静默忽略（解析逻辑见 lib.rs 中的 load_analog_toml）。

.claw-analog.toml 完整示例：

model = "sonnet"
stream = true
output_format = "rich"
permission = "read-only"
language = "en"
preset = "audit"
session = ".claw-analog.session.json"
profile = "~/.claw-analog/profile.toml"
no_runtime_enforcer = false
accept_danger_non_interactive = false
max_read_bytes = 262144
max_turns = 24
max_list_entries = 500
grep_max_lines = 200
glob_max_paths = 2000
glob_max_depth = 32
# 可选：RAG（claw-rag-service）— 见下文 RAG 一节
# rag_base_url = "http://127.0.0.1:8787"
# rag_timeout_secs = 30
# rag_top_k_max = 32

合并优先级（源码依据 main.rs 的 build_config）：stream 上 --no-stream 最高优先级，其次 --stream，最后是 TOML 的 stream；其余数值型上限均为 CLI > TOML > 硬编码默认。模型解析顺序为 --model > TOML model > 内置默认 sonnet（常量 ANALOG_DEFAULT_MODEL，见 lib.rs#L244）。

3.2 RAG 工具 retrieve_context 的启用条件

若设置了环境变量 RAG_BASE_URL 或 TOML 中非空的 rag_base_url，工具集会额外注入 retrieve_context（对已索引 workspace 的语义搜索）。取值是 HTTP 服务根地址，不带 /v1 后缀（实际请求发往 {base}/v1/query）。超时与 top_k 上限分别由 rag_timeout_secs、rag_top_k_max 控制（默认 30 秒和 32，绝对硬顶 256——见 main.rs#L185-L187 的 RAG_TOP_K_ABS_CAP，并在 build_config 中 clamp(1, 256)）。索引构建仍是独立的 claw-rag-service 命令，详见 docs/rag-web-ui.md。

3.3 permission 权限模式

取值与完整 claw 相同（TOML 里也是同样字符串；解析逻辑见 lib.rs#L248-L257，workspace-write 可简写 write、danger-full-access 可简写 danger）：

取值	工具 write_file	非交互（stdin 非 TTY）
read-only	不可写	正常
workspace-write	可写（限制在 -w 内）	正常
prompt	不可写（此 harness 中 Enforcer 不允许无确认写入）	stderr 打印警告；无头自动写入请改用 workspace-write
danger-full-access、allow	可写	拒绝，除非显式提供 --accept-danger-non-interactive 或 TOML accept_danger_non_interactive = true

该非交互拒绝逻辑实现在 lib.rs#L25-L60 的 enforce_non_interactive_permission_rules_with_tty：DangerFullAccess/Allow 且 stdin 非 TTY 且未显式接受时直接返回错误；prompt 模式非交互则降级为警告（写仍被拒绝）。

--stream 命令行标志打开流式；--no-stream 显式关闭（用于覆盖 TOML 中的 stream = true）。

language TOML 字段：en 或 ru（与 --lang 同值域），CLI 优先。注意 ru 只是往 system prompt 注入一行回复语言提示（见 lib.rs#L89-L96），不切换 API 模型。

4. 会话持久化（--session / --save-session）

会话文件是 JSON（version: 1）：元数据 workspace、model，可选 preset，以及 API 格式的 messages 数组（role + content）。

• 启动时若文件已存在，历史被追加加载，本次请求文本（位置参数或 stdin）作为新的用户消息追加（bootstrap 逻辑见 lib.rs#L538-L553 的 session_bootstrap_messages，版本不匹配会报可读错误）；
• 状态在每个完整工具轮结束后以及无 tool_use 的正常结束时落盘（persist_conversation_sessions，lib.rs#L471-L486）；
• --save-session 与 --session 文件格式相同：每次会话文件会被更新的时机，同样在此路径写一份（路径与 --session 相同时跳过二次写入）；也可以不带 --session 单独使用——把单次运行的完整历史导出为 JSON，供脚本消费或作为后续 --session 的起点，免去手工拼 messages。

风险须知（原文档明确强调，stderr 中也会打印提醒）：

• 文件内可能包含秘密（read_file 读出的内容、日志中的密钥），文件不加密；
• 长历史会增加 API token 成本；
• 会话中 workspace / model / preset 与当前运行不匹配时仅警告，运行继续。

5. 预设（--preset）、自动推断与 profile

预设向 system prompt 追加一段简短的偏置文本（审计/教学/改代码三类，文案见 lib.rs#L137-L150 的 Preset::extra_system）。工具集合仍由 permission 决定；其中 implement 在 CLI 和 TOML 都未指定 permission 时，默认补上 workspace-write（保证有 write_file）——见 main.rs#L256-L277 的 merge_permission。文件中显式 permission = "read-only" 或 CLI --permission read-only 均优先生效。

auto 推断（文档未强调但源码存在，main.rs#L240-L254 与 lib.rs#L161-L236 的 infer_preset_from_prompt）：当 CLI 传 --preset auto、TOML 写 preset = "auto"、或两者都缺省时，会对初始 prompt 做保守的启发式推断——安全/审查类关键词（audit、security、vulnerability、уязв、аудит…）优先归为 audit；改动类（implement、add、fix、refactor、добав、почин…）归为 implement；解释类（explain、why、how、объясни…）归为 explain；都不命中则 none。该推断是纯字符串包含匹配，属启发式，重要场景建议显式指定预设。

Profile（profile.toml） 是一个极小的 TOML：

line = "Короткая подсказка стиля (одна строка в system)."

限制：文件不超过 2048 字节；line trim 后不超过 512 个 Unicode 字符（超出则截断并警告）。内容以一行 Learner hint: … 形式追加进 system prompt（单测 system_prompt_includes_preset_and_hint 即验证了该行为，见 lib.rs#L2472-L2487）。

6. 工具集：无任意 shell 的封闭工具面

claw-analog 的全部工具由 lib.rs#L883 的 tool_definitions 按权限模式动态生成，不含 bash / MCP / 插件：

名称	可用模式	说明
read_file	read-only 及以上	读取 -w 之下的 UTF-8 文件
list_dir	read-only 及以上	列目录（非递归）
glob_workspace	read-only 及以上	返回 -w 下的文件路径：参数 pattern（相对 root 的 glob，用 / 斜杠）、可选 root（默认 .）、max_paths（受 CLI 上限裁剪）；模板中禁止 ..
grep_workspace	read-only 及以上	按行做字面量子串搜索；恰好一个选择器：path、paths 数组或 glob（可加 glob_root）。总行预算为 max_lines 与 --grep-max-lines。多文件时行格式为 相対/パス:行番号:内容
grep_search	read-only 及以上	与 grep_workspace 共用同一处理器（为兼容完整 claw 的 prompt 保留）
git_diff	read-only 及以上	在 -w 所属仓库内执行无颜色 git diff。可选 cached（staged）、rev_range、context_lines、paths。输出受 --max-read-bytes 限制
git_log	read-only 及以上	无颜色 git log。可选 max_count（默认 20）、rev_range、paths。输出受 --max-read-bytes 限制
retrieve_context	read-only 及以上	仅当设置了 RAG_BASE_URL 或 TOML rag_base_url：向 claw-rag-service 发 HTTP POST {base}/v1/query，返回 chunk 的路径与片段（限制见 3.2 节）
write_file	workspace-write、danger-full-access 或 allow	写文件；必要时创建父目录（prompt 模式下 Enforcer 拒绝写入）

工具的分发实现集中在 lib.rs#L1953 的 dispatch_tool：每个工具先过 enforce_tool（enforcer 开启时），再执行具体逻辑，错误以 error: 前缀字符串回传给模型，模型据此自行纠错——这使整个工具面保持“无 shell、错误可自修”的收敛特性。

7. 工作原理：workspace 囚笼与 agent 主循环

原文档列出的五条原则与源码逐条对应（主循环入口为 lib.rs#L1220 的 run）：

1. workspace 根（-w）先 canonicalize 成规范路径；所有工具内路径均为相对路径，禁止 .. 与绝对路径段；
2. 访问文件前校验真实路径仍在根内（symlink / canonicalize 双重防逃逸）；
3. 权限策略（未用 --no-runtime-enforcer 时）：复用主 CLI 的同一套实体——PermissionPolicy + PermissionEnforcer::check（工具级）与 check_file_write（写入级）；
4. agent 循环：请求提供商 → 若 stop_reason == "tool_use" 则执行各调用，结果以 tool_result 追加进历史 → 进入下一轮；直到无 tool_use 或达到 --max-turns；
5. 流式：--stream 时助手文本随 SSE 增量即时打印；下一轮的完整历史由 SSE 事件按“块索引 + JSON tool input”重建，与完整 claw 管线一致（实现见 stream_to_message_response，lib.rs#L1428-L1479）。

诊断日志（[claw-analog] … 前缀）一律走 stderr：rich 模式下模型回答是 stdout 上的纯文本；json 模式下 stdout 只有 NDJSON。

8. NDJSON 输出契约（CI 与外部 agent）

--output-format json 将 stdout 切换为 JSON 行流（一行一个对象）。字段语义稳定，集合可扩展。契约常量 schema = "claw-analog-ndjson"、format_version = 1 定义在 lib.rs#L239-L241，run_start 事件（lib.rs#L1266-L1283）会原样携带这两个字段供编排器校验。

主要事件 type：

type	触发时机
run_start	运行开始：schema（claw-analog-ndjson）、format_version，其后是 workspace、model、stream、permission，可选 preset、session、session_save，以及布尔 rag_enabled（retrieve_context 是否可用）
turn_start	一轮模型调用开始（turn 序号）
assistant_text_delta	仅 --stream 时：助手文本片段
assistant_turn	一轮结束：stop_reason、usage、完整 text、tool_calls 数组、request_id
tool_result	工具执行后：name、tool_use_id、is_error、output（可能截断）、truncated、output_len_chars
run_end	成功结束（ok: true）
error	出错（运行崩溃或空 prompt 时单独成行打印）

PowerShell 示例（逐行解析可用 jq 或任意 JSON 解析器）：

# 从 ...\claw-code-main\rust 执行
$env:ANTHROPIC_API_KEY = "sk-ant-..."
cargo run -p claw-analog -- --output-format json -w . "Summarize rust/README.md" 2>$null | ForEach-Object { $_ | ConvertFrom-Json | Select-Object -ExpandProperty type }

加 --stream 时，stdout 先输出 assistant_text_delta 事件，随后同一轮再输出一条含完整 text 的 assistant_turn（利于可复现的日志记录）。

对编排器的限制与风险：

• tool_result.output 中较大内容会被截断（上限约 32 KiB，常量 MAX_JSON_TOOL_OUTPUT_BYTES = 32 * 1024，见 lib.rs#L733 及 truncate_for_json），同时置 truncated: true；
• 秘密泄露：不要把 stderr 未过滤地直接引入公共日志；output 理论上可能含被读取文件的内容；
• 编排器契约：NDJSON 走 stdout，诊断走 stderr，出错时退出码非 0。首行 run_start 应校验 schema 与 format_version；注意 run_start 也暴露了 workspace 路径与模型名，分享日志时需自行脱敏。

9. 无真实网络的自动化测试

单元测试与基于本地 mock-anthropic-service 的集成测试：

# 从 ...\claw-code-main\rust 执行
cargo test -p claw-analog

mock-anthropic-service 在 Cargo.toml 中注册为 dev-dependency，意味着测试不需要任何真实 API 密钥或外网——它在本机模拟 Anthropic Messages API（含 SSE 流式），从而覆盖流式重建、工具循环、权限拒绝等路径。GitHub Actions 中有独立的 job claw-analog (test + clippy -p)，额外跑 cargo test -p claw-analog 与 cargo clippy -p claw-analog --no-deps（在 workspace 级 cargo test / clippy 之外）。并行测试时，Anthropic 环境变量在 mock 场景下用 mutex 隔离；遇到偶发失败可用 cargo test -p claw-analog -- --test-threads=1 串行复现。

10. 配套的 claw-rag-service：索引、Qdrant 与 Docker

索引与 HTTP API 都位于 cargo run -p claw-rag-service（ingest + serve 两个子命令，crate 见 rust/crates/claw-rag-service/）。serve 之后打开 http://127.0.0.1:8787/ 可看到一个轻量 UI（stats + 搜索）。对 claw-analog 的接入方式即上文的 RAG_BASE_URL / retrieve_context。更完整的 env 说明见 docs/rag-web-ui.md。

10.1 Ingest：单仓库与跨仓库

ingest 的 --workspace 可重复——这是官方支持的 cross-repo RAG 方式（多个仓库进同一个数据库/集合）：

# 从 ...\claw-code-main\rust 执行

# 单个 workspace
cargo run -p claw-rag-service -- ingest --workspace "D:\v\kria\s6"

# 多个 workspace（跨仓库）
cargo run -p claw-rag-service -- ingest --workspace "D:\repo1" --workspace "D:\repo2"

多仓库时，检索结果中的 path 形如 repoId:relative/path，避免不同仓库间相同相对路径的冲突。

10.2 Mock 嵌入（无密钥 / 无网络）

本地跑通或测试时可以开启 mock 嵌入：

$env:CLAW_RAG_MOCK_PROVIDERS = "1"
cargo run -p claw-rag-service -- ingest --workspace "D:\v\kria\s6"

10.3 Qdrant（推荐的本地向量后端）

大仓库场景建议起本地 Qdrant：相比 SQLite 的线性扫描，gRPC 向量检索更省 CPU、响应更快。Qdrant 是可选 feature（qdrant-index，见 rust/crates/claw-rag-service/Cargo.toml 的 [features] qdrant-index = ["dep:qdrant-client"]），不启用时默认走内置 SQLite 索引。

启动 Qdrant（gRPC 端口 6334）：

docker run --rm -p 6333:6333 -p 6334:6334 -e QDRANT__SERVICE__GRPC_PORT=6334 qdrant/qdrant

持久化卷（命名 volume）：

docker volume create claw-qdrant-data
docker run --rm -p 6333:6333 -p 6334:6334 `
  -e QDRANT__SERVICE__GRPC_PORT=6334 `
  -v claw-qdrant-data:/qdrant/storage `
  qdrant/qdrant

bind-mount（宿主机路径）：

mkdir .claw-qdrant | Out-Null
docker run --rm -p 6333:6333 -p 6334:6334 `
  -e QDRANT__SERVICE__GRPC_PORT=6334 `
  -v "${PWD}/.claw-qdrant:/qdrant/storage" `
  qdrant/qdrant

然后设置环境变量并以 qdrant-index feature 运行 ingest：

$env:CLAW_RAG_QDRANT_URL = "http://127.0.0.1:6334"
$env:CLAW_RAG_QDRANT_COLLECTION = "claw_rag_chunks"

# （可选）嵌入不走真实 API
$env:CLAW_RAG_MOCK_PROVIDERS = "1"

cargo run -p claw-rag-service --features qdrant-index -- ingest --workspace "D:\v\kria\s6"

ingest 会按嵌入维度自动创建尚不存在的 collection。

10.4 Docker Compose 一键拉起（Qdrant + claw-rag-service）

仓库根目录提供 docker-compose.yml，镜像基于 rust/crates/claw-rag-service/Dockerfile：

1. 启动服务：

cd D:\path\to\claw-code-main
docker compose up --build

注意：rag-serve / rag-ingest 镜像用较新的 Rust 基础镜像构建（qdrant-client 可能要求比旧 pinned 标签更新的 Rust）。若构建阶段出现 transferring context: 21.02GB 之类的异常传输，检查两点：compose 是否从仓库根目录（docker-compose.yml 所在处）执行；是否存在 .dockerignore（存在 target/ 或本地索引时尤其重要，可显著缩小 build context）。若 load local bake definitions 步骤直接 EOF，可尝试禁用 bake/BuildKit：

$env:COMPOSE_BAKE = "0"
$env:DOCKER_BUILDKIT = "0"
docker compose up --build

2. Ingest 是批量任务，需单独执行（以单 workspace 为例）：

docker compose run --rm rag-ingest ingest --workspace "/workspaces/main"

rag-ingest 默认把索引写入共享 volume，因此 rag-serve 能立刻检索到 chunk。

10.5 把 RAG 接入 claw-analog

$env:RAG_BASE_URL = "http://127.0.0.1:8787"
cargo run -p claw-analog -- -w "D:\v\kria\s6" "Найди где реализован ingest в RAG сервисе"

此时 run_start 中 rag_enabled: true，system prompt 会额外声明 retrieve_context 可用（对应单测 system_prompt_rag_lists_retrieve_context），模型即可在推理中自主调用语义检索。

11. Auto-TDD：写文件后自动跑校验

完整 claw（以及其他 runtime 消费者）可通过 .claw/settings.json 在成功的 write 工具调用后自动执行 linter/测试。原文档给出的示例配置为：

{
  "autoTdd": {
    "enabled": true,
    "tools": ["write_file", "edit_file"],
    "commands": [
      "cd rust && cargo fmt",
      "cd rust && cargo clippy --workspace --all-targets -- -D warnings",
      "cd rust && cargo test --workspace"
    ]
  }
}

需要说明的是：在当前仓库中检索 autoTdd 仅命中 how_to_run.md 本身，Rust 侧 runtime crate 源码中尚无对应实现标识——从源码结构看，这属于面向完整 claw 产品层的配置约定（可能对应规划中的功能），而 claw-analog 本身的工具面是刻意收窄的，不包含该机制。

12. claw-analog 与完整 claw 的差异

原文档给出的三点差异，结合源码可以补充印证：

• 工具面窄：无 bash / MCP / 插件，只有 8 个受控文件/检索/git 工具（+可选 RAG），因此行为边界清晰；
• 更易审计与限额：所有 I/O 上限（字节、轮数、行数、路径数、深度）都可以显式收紧，配合 --print-tools 可在不发 prompt 的情况下预先确认生效的工具清单；
• 主产品仍是 claw：cargo run -p rusty-claude-cli 构建的 claw 二进制（crate 位于 rust/crates/rusty-claude-cli/）才是面向日常使用的完整 CLI，claw-analog 与它共享 api 提供商栈与 runtime 权限实体，是同一体系的“最小可审计子集”。

13. 延伸阅读路径

• 主 CLI 使用与提供商配置：USAGE.md、rust/USAGE.md；
• RAG Web UI 与服务细节：docs/rag-web-ui.md；
• 核心源码：rust/crates/claw-analog/src/lib.rs（agent 循环与 NDJSON 契约）、rust/crates/claw-analog/src/main.rs（CLI 与配置合并）、rust/crates/claw-analog/src/doctor.rs（诊断子命令）；
• 测试基础设施：rust/crates/mock-anthropic-service/（无网络集成测试的本地模拟服务）。

要点回顾：claw-analog 的价值在于把“多提供商 agent 循环”压缩到可完整审读的规模——canonicalize 路径囚笼 + PermissionEnforcer 双保险、可预测的 CLI/TOML/默认三级合并、claw-analog-ndjson 稳定输出契约、以及可选的 RAG 语义检索扩展，使其同时适合人交互、CI 批处理和外部编排器三种用法；配合 doctor、config validate 与本地 mock 测试栈，可以在不消耗任何真实 API 配额的前提下完成从构建、诊断到回归验证的完整闭环。