人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载IronClaw 是一个以隐私、安全与可扩展性为核心诉求的 Agent OS当前开发重心全部落在crates/下的 Reborn 模块化架构中。本文以仓库内 openwiki/development/workflows.md 为主线完整梳理 IronClaw 的日常研发工作流——包括修 Bug、加功能、代码评审、本地调试、安全层变更、新增工具、生产部署、重构、性能优化、Git 规范与 CI 流水线并结合仓库源码、测试与 CI 脚本给出可验证的实现细节。读完本文你将掌握一套可直接照做的工程化流程如何先写失败回归测试再修复、如何判断新功能落在哪个 crate、如何在评审中守住安全边界、以及如何把改动安全地发布到生产环境。背景Reborn 架构与工作流的前提理解 IronClaw 的开发工作流首先要知道代码的组织方式。根目录 AGENTS.md 明确所有产品工作都归属crates/下的 Reborn 工作区发货二进制是crates/app/ironclaw_cli包中的ironclaw命令。crates/共十个功能家族contracts、substrates、events、domains、kernel、lanes、loop、extensions、product、appcrates/AGENTS.md是进入这些家族的路由地图它规定了一个七层依赖矩阵contracts → substrates → runtimes → kernel → loops → products → appcrate 只能依赖本层及以下层级且由crates/app/ironclaw_architecture_tests/tests/reborn_dependency_boundaries.rs中的架构测试机械地强制执行。这意味着依赖方向只能向上流动不允许循环依赖安全决策授权、审批、密钥、沙箱与 Agent 循环隔离测试底层不需要产品基础设施重构产品不会动摇 substrate。因此几乎所有工作流的第一步都是先定位代码归属新行为去loop/或product/安全机制去kernel/与substrates/可执行能力去lanes/安装包去extensions/packages/。定位工具方面根 AGENTS.md 推荐先运行bash scripts/codebase-graph.sh status探测代码知识图谱图不可用时再退回crates/AGENTS.md与针对性rg搜索。此外openwiki/是生成式文档属于只读内容任何手工修改都不被允许文档类变更应进入docs/或各 crate 自己的 README/CONTRACT。命令行提示本文沿用工作流文档中的cargo run -p ironclaw_cli --bin ironclaw-reborn -- ...历史写法但当前仓库该包名为ironclaw见 crates/app/ironclaw_cli/Cargo.toml根 AGENTS.md 亦确认发货二进制为ironclaw。命令不生效时以cargo run -p ironclaw -- --help为准先查看实际子命令列表。Workflow: 修复 BugFixing a BugIronClaw 的 Bug 修复遵循严格的测试优先纪律根 AGENTS.md 测试纪律第 1 条Every fix ships with a regression test。任何修复都必须附带一个本可以拦住该 Bug 的回归测试。第 1 步理解 Bug# 查找相关 issue gh issue list --search label:bug # 获取 issue 详情 gh issue view issue-number # 阅读相关代码 # 使用代码知识图谱定位见 AGENTS.md: Code Discovery # 图谱不可用时用 rg 做针对性搜索 rg -n 相关符号或关键词 crates仓库为代码发现提供了额外辅助bash scripts/codebase-graph.sh status可检查图谱是否就绪对配置、文档与测试夹具直接用rg更合适。理解阶段的关键是确认复现路径与归属 crate修复属于crates/family/crate/中的哪一个决定后续测试写在哪一层。第 2 步先写失败的回归测试为什么必须先写测试没有回归测试的修复无法证明Bug 确实被修好了也无法在未来防住同类回归。// 放在 tests/ 或所属模块内 #[test] fn test_bug_scenario() { let input /* 触发 Bug 的具体输入 */; let result function_with_bug(input); assert_eq!(result, /* 期望结果 */); // 当前会失败 }运行它并确认失败cargo test test_bug_scenario # 应显示FAILED根 AGENTS.md 还强调**通过调用方测试而不是只测辅助函数**当辅助函数掌控副作用HTTP、DB 写入、OAuth 流程、工具执行时必须在调用点测试而不能只对辅助函数做单元测试并且 mock 要捕获生产调用方传入的每一个参数。第 3 步定位并修复 Bug# 不确定 Bug 在哪时按序排查 cargo clippy # clippy 能发现吗 cargo test # 哪个测试在失败 grep -r bug_keyword . # 有没有遗留的 TODO修复源码fn function_with_bug(input: str) - String { // 修复前错误逻辑 // 修复后正确逻辑 }这里有一个仓库级的硬性约束生产代码禁止.unwrap()/.expect()测试中允许必须用.map_err(|e| SomeError::Variant { reason: e.to_string() })?带上下文传播错误并使用thiserror定义error.rs中的错误类型。修复时若发现类似模式还应当按根 AGENTS.md 的要求在整个crates/中搜索同类实例一并处理。第 4 步验证修复# 运行回归测试 cargo test test_bug_scenario # 应显示ok # 运行全部测试 cargo test # 检查格式化与 lintCI 以零警告为准 cargo fmt cargo clippy -- -D warnings第 5 步提交git add . git commit -m fix(scope): description of the bug Details about what was wrong and how its fixed. Include a reference to the issue: Fixes #123.提交信息格式由 commit-msg 钩子强制校验见 openwiki/development/setup.mdTypefix、feat、docs、style、refactor、test、choreScope受影响的模块或区域Message改了什么Body为什么改可选但推荐并引用 issue如Fixes #123Workflow: 新增功能Adding a Feature第 1 步规划功能# 检查 FEATURE_PARITY.md 中是否已有该功能的追踪记录 grep -i feature-name FEATURE_PARITY.md # 决定在哪里构建 # - 新的运行时行为→ crates/ 下 loop/ 或 product/ 相关 crate # - 新工具→ crates/extensions/packages/ 或 ironclaw_extension_registry / ironclaw_capabilities # - 新网关能力→ crates/product/ 或 ironclaw_cli / ironclaw_webui # - 新渠道Slack、Telegram 等→ crates/extensions/packages/name/ # 阅读相关架构文档 # 示例新增能力读 openwiki/architecture/overview.mdFEATURE_PARITY.md 是 IronClaw 与 OpenClaw 参考实现之间的功能对等矩阵用 ✅//❌///➖ 标记每一项的状态架构、网关、渠道、CLI、Agent 系统、模型、安全等 16 大类。加功能前先查它避免重复建设或遗漏对等项加完功能也要回来更新它。架构层面openwiki/architecture/overview.md 给出了新功能放哪里的决策树核心原则是新功能一律进 Reborncrates/绝不进 v1src/且要遵循功能 → 归属家族 → 具体 crate的定位路径。例如新增 GitHub issue 工具应落在ironclaw_first_party_extensions与ironclaw_capabilities文件写入需要审批落在ironclaw_approvals与ironclaw_safety。第 2 步先写测试// 在实现之前先测功能 #[test] fn test_new_feature_basic_case() { let result new_feature(input); assert_eq!(result, expected); } #[test] fn test_new_feature_edge_case() { let result new_feature(edge_case_input); assert!(result.is_ok()); }运行测试确认它们失败因为功能尚未实现cargo test test_new_feature # 应显示FAILED (not yet implemented)仓库测试分层详见 openwiki/development/testing.mdTier 1 单元测试cargo test --lib毫秒级、无外部依赖、Tier 2 集成测试cargo test --test *160 秒可用 PostgreSQL/libSQL、Tier 3 E2E 测试cargo test -- --ignored分钟到小时级。此外根 AGENTS.md 的测试纪律还要求合并而非扩散优先扩展现有覆盖同一路径的测试、集成优先生产级行为必须在tests/integration/通过 harness 驱动并断言在 seam 上而不是只wait_for_status(Completed)。第 3 步实现功能pub fn new_feature(input: str) - ResultOutput { // 实现 }实现时遵守仓库编码规范强类型与枚举表达已知领域形状、原始字符串只留在外部边界多行 prompt 必须放prompts/*.md文件用include_str!()加载不硬编码进 Rust所有 I/O 使用 tokio 异步共享状态用ArcT。第 4 步验证测试通过cargo test test_new_feature # 应显示ok cargo test # 全部测试应通过第 5 步更新文档功能对等更新 FEATURE_PARITY.md 中的状态标记文档面向用户的内容加入docs/公开 Mintlify 站点内部工程文档必须放docs/internal/由scripts/ci/docs_publication_boundary.py强制检查OpenWiki架构级变更才更新openwiki/注意它是生成式文档且为只读代码注释公开 API 必须写///doc comments第 6 步提交git add . git commit -m feat(scope): description of the feature Why this feature was added. Include issue reference if applicable. Includes tests: test_new_feature_basic_case, test_new_feature_edge_caseWorkflow: 代码评审Code Review第 1 步认领 PR# 在 PR 上留言认领 gh pr comment pr-number -b Taking this for review # 标记为评审中 gh pr edit pr-number --state ready第 2 步评审清单范围PR 是否只聚焦一项变更测试是否包含测试且覆盖充分架构变更是否落在正确的位置家族 / 层级矩阵安全是否触及 auth、secrets 或沙箱文档FEATURE_PARITY.md、README、OpenWiki 是否更新代码质量clippy 是否零警告格式是否正确性能是否存在明显低效第 3 步本地测试# 检出 PR 分支 gh pr checkout pr-number # 构建 cargo build # 运行测试 cargo test # 手动验证功能 cargo run -p ironclaw_cli --bin ironclaw-reborn -- run --message test第 4 步给出评审结论在 GitHub 上Approve所有检查通过Request changes存在问题给出具体反馈Comment仍在评审中细节问题、疑问第 5 步安全敏感评审如果 PR 涉及以下内容必须逐项核对依据根 AGENTS.md 的 Security and Runtime Invariants 一节Auth验证 bearer token、CORS、origin 校验是否被削弱Secrets确认没有内联密钥只出现环境变量名credential_name与extension_name两个身份不得混用Sandboxing验证隔离性与资源限制WASM 沙箱、进程沙箱、网络边界Approvals验证审批 lease 精确绑定到具体调用不允许一次批准永久放行Network验证 allowlist、DNS 检查外部 HTTP 必须走ironclaw_network评审者还要注意根 AGENTS.md 的硬性安全不变式任何 listener、路由、产品适配器、运行时 lane、容器与外部服务在类型化边界建立信任之前一律视为不可信LLM 数据永不删除只能加时间戳并过滤不得绕过ProductSurface与 capability contracts 直接改存储。第 6 步合并# 批准且 CI 通过后 gh pr merge pr-number # --squash 表示压成单个提交Workflow: 本地调试Debugging Locally第 1 步复现问题# 搭建最小环境 export IRONCLAW_REBORN_HOME$PWD/.reborn-debug export OPENAI_API_KEYsk-... # 运行失败的命令 cargo run -p ironclaw_cli --bin ironclaw-reborn -- run --message ...LLM 提供商的完整环境变量对照可参考 openwiki/development/setup.mdOpenAI 用OPENAI_API_KEY可选OPENAI_MODEL/OPENAI_BASE_URLAnthropic 用ANTHROPIC_API_KEYOpenRouter 用OPENROUTER_API_KEY本地 Ollama 用--llm-backend ollama可选OLLAMA_BASE_URL/OLLAMA_MODEL通用 OpenAI 兼容端点用LLM_BASE_URL。第 2 步添加调试输出// 使用 debug!() 宏不要用 info!()避免刷屏用户输出 debug!(Variable: {:?}, variable); // 以 debug 日志级别运行 RUST_LOGdebug cargo run -p ironclaw_cli --bin ironclaw-reborn -- run --message ...REPL/TUI 用debug!()而非info!()是根 AGENTS.md 中明确列出的关键架构决策Key Architectural Decisions 第 11 条也是 openwiki/development/workflows.md 常见坑表中的一条Secret leaked in logs → 用debug!()而不是info!()。仓库级日志前缀示例见根 AGENTS.mdRUST_LOGironclawdebug cargo run -p ironclaw -- serve可加tower_httpdebug看 HTTP 日志。第 3 步使用调试器VS Code CodeLLDB在编辑器行号处点击设置断点按 F5 启动调试用 watch 面板检查变量命令行调试# 安装 LLDB如未安装 # macOS: 随 Xcode 自带 # Linux: sudo apt install lldb # Windows: 使用 WinDbg 或 VS Code # 用调试器运行 rust-lldb ./target/debug/ironclaw-reborn # 常用命令 # (lldb) breakpoint set -n function_name # (lldb) run ... args # (lldb) p variable_name # (lldb) n (next) # (lldb) c (continue)第 4 步检查状态# 检查事件存储本地文件事件溯源架构的审计日志 cat ~/.ironclaw/reborn/events.jsonl | jq . # 检查 PostgreSQL如使用 psql -U ironclaw -d ironclaw -c SELECT * FROM events LIMIT 10; # 检查文件系统 ls -la ~/.ironclaw/reborn/IronClaw 采用事件溯源event sourcing所有状态变更都是不可变事件状态由投影projections计算而来——相关实现分布在crates/events/ironclaw_event_log、ironclaw_event_projections等 crate。因此调试时先看事件流往往比断点更快定位状态异常。开发模式默认使用 libSQL内置可选 PostgreSQL 双后端docker-compose.yml提供了postgres服务测试时用IRONCLAW_HOOKS_POSTGRES_URL指向它。第 5 步验证修复一旦认为已修复写一个测试固化#[test] fn test_issue_is_fixed() { // 复现原始问题 // 验证现已修复 }Workflow: 变更安全层Changing the Safety Layer安全层是高风险区域必须遵循专门流程。IronClaw 的安全扫描归属crates/substrates/ironclaw_safety根 AGENTS.mdsafety scanning 属于ironclaw_safety不要从其他 crate 引入。理解当前行为阅读 crates/substrates/ironclaw_safety/CLAUDE.md 与该 crate 的 README、CONTRACT。先写测试#[test] fn test_new_safety_check() { let dangerous_input /* 攻击向量 */; let result check_safety(dangerous_input); assert!(!result.is_safe); }实现检查逻辑在crates/substrates/ironclaw_safety/中添加检测逻辑用真实攻击向量测试验证对合法输入无误报以安全视角评审能否被绕过是否有边界情况覆盖是否充分更新测试确保安全层测试全面运行完整测试套件提交git commit -m feat(safety): add detection for new threat Detects XXX pattern. Tests added: test_*. Reviewed by security-expert.仓库侧佐证ironclaw_safetycrate 自带benches/基准与fuzz/模糊测试目录配合测试分层安全层覆盖率要求 90%见 openwiki/development/testing.md 的 Coverage Targets根 AGENTS.md 还配套scripts/check_no_panics.py等脚本从无 panic维度加固安全关键路径。安全层的核心职责包括 prompt injection 检测、凭据检测、脱敏与 sanitization。Workflow: 新增一个工具Adding a New Tool设计工具提供什么能力接受哪些参数输出什么需要什么权限创建 manifest当前仓库的工具扩展布局已统一为一个包一个目录crates/extensions/packages/name/manifest.toml数据包或 workspace cratecrates/extensions/AGENTS.md是扩展家族的路由与边界规则。参考实现的范式可看test-tools/下的示例工具如test-tools/ascii-renderer/、test-tools/hacker-news/、test-tools/market-data/每个都包含manifest.toml、schemas/JSON schema、prompts/工具提示词与wasm-src/WASM 实现源码。注意工作流文档中提到的旧路径crates/ironclaw_first_party_extensions/assets/...已是历史布局请以crates/extensions/packages/为准。实现工具添加 WASM 实现wasm32-unknown-unknown目标rustup target add wasm32-unknown-unknown或原生代码在 capability registrycrates/kernel/ironclaw_capabilities中注册工具运行时归属crates/lanes/ironclaw_wasm添加测试#[tokio::test] async fn test_my_tool_basic() { let result execute_my_tool(params).await; assert_ok!(result); }添加文档工具 prompt指导 LLM 如何使用输入/输出 schemaJSONL / JSON Schema仓库层面的扩展契约可参考crates/extensions/packages/pkg/README.md每个包目录都有含数据包以及registry/tools/*.json中的工具注册示例github、gmail、google_calendar、web_search 等。工具执行遵循架构模式 2Host Portsloop 通过CapabilityRequest请求能力kernel 门禁授权 → 审批 → 资源 → 安全扫描放行后才执行。Workflow: 生产部署Deploying to Production第 1 步准备发布# 更新 CHANGELOG.md # 更新 Cargo.toml 中的版本号 # 提交并打 tag git tag v0.x.y git push origin v0.x.y根 AGENTS.md 特别提醒Rust 工具链版本存在rust-toolchain.tomlchannel字段与 CI 的 setup-rust actiontoolchain输入两处二者由scripts/ci/lib/rust_toolchain_contracts.py强制同步升级必须同 PR 双改否则门禁失败。第 2 步构建 Docker 镜像# 构建发布镜像 docker build -f Dockerfile -t ironclaw:0.x.y . # 测试镜像 docker run ironclaw:0.x.y ironclaw-reborn --version # 推送到镜像仓库 docker push your-registry/ironclaw:0.x.y仓库根目录提供Dockerfile主镜像、Dockerfile.process-sandbox与Dockerfile.sandbox-workerdocker-compose.yml则用于本地 PostgreSQL 等开发场景docker/reborn/下还有生产形态的配置样例config.production.toml、config.hosted-single-tenant.toml等。第 3 步部署# Docker 方式 docker run -d \ -e IRONCLAW_REBORN_HOME/data \ -e IRONCLAW_REBORN_PROFILEproduction \ -e IRONCLAW_REBORN_POSTGRES_URL$DB_URL \ -e IRONCLAW_REBORN_SECRET_MASTER_KEY$SECRET_KEY \ -p 3000:3000 \ ironclaw:0.x.y serve # systemd 方式Linux sudo systemctl restart ironclaw仓库提供现成的部署资产deploy/ironclaw.servicesystemd unit、deploy/env.example环境变量清单、deploy/setup.sh、deploy/cloud-sql-proxy.service云 SQL 代理profiles/下还有local.toml、local-sandbox.toml、server.toml、server-multitenant.toml多种运行 profile对应IRONCLAW_REBORN_PROFILE的取值。云端部署的完整指南见 docs/infrastructure/amazon.mdx、docs/infrastructure/droplet.mdx 与 docs/infrastructure/google.mdx服务化使用方式见 docs/using/service.mdx。密钥管理上开发环境密钥明文存于 state root生产环境必须用IRONCLAW_REBORN_SECRET_MASTER_KEY走加密存储openssl rand -hex 32生成且绝不把密钥提交进 git。第 4 步验证部署# 健康检查 curl http://localhost:3000/health # 查看日志 journalctl -u ironclaw -f # 测试一个简单命令OpenAI 兼容 API curl -X POST http://localhost:3000/v1/chat/completions \ -H Authorization: Bearer $TOKEN \ -d {message: hello}功能对等矩阵显示网关层还提供/api/health、/api/gateway/status、/healthz、/readyz等就绪探针端点可作为部署验证的补充检查项。Workflow: 重构Refactoring重构大面积代码时规划重构改什么、为什么改影响哪些 API现有代码如何适配先弃用#[deprecated(since 0.x.y, note Use new_function instead)] pub fn old_function() { ... }渐进迁移不要一次全改一次更新一个调用方每次改动后运行测试更新文档面向用户/开发者的迁移指南API 文档OpenWiki 章节沟通PR 描述说明重构内容代码评审聚焦正确性附上迁移指南链接仓库对此有专门的门禁一旦依赖边、layer key、crate 位置或测试固定的引导文件发生变化必须运行cargo test -p ironclaw_architecture_tests依赖/层级/边界门禁与python3 scripts/ci/check-target-tree.py包集合 vs 文档化目录树移动/改名后还要在 agent guidance、contracts、docs、tests、scripts、manifests 与前端 import 中搜索旧路径根 AGENTS.md 的 Change discipline。trait 变更时要枚举所有实现、装饰器、适配器与测试替身。Workflow: 性能优化Performance Optimization先测量cargo build --release time cargo run --release -- run --message complex task剖析# CPU 剖析 cargo install flamegraph cargo flamegraph --bin ironclaw-reborn # 内存剖析 HEAPPROFILE/tmp/ironclaw cargo run --release优化聚焦剖析发现的热路径优化前后都加基准测试验证确实更快验证# 运行基准 cargo bench # 运行全部测试 cargo test仓库提供了完整的性能工程配套tools/ironclaw_stress/是压力测试框架示例cargo run -p ironclaw_stress -- --requests 1000 --concurrency 10其results/下已有大量压测产物harness/latency/提供延迟探针与评分脚本probe.sh、score.sh、status.sh、lint.sh。安全等关键 crate 自带 bench如cargo bench -p ironclaw_safety。性能优化不能以牺牲测试纪律为代价——优化前后都要跑cargo test。Git 工作流分支策略# 创建功能分支 git checkout -b fix/issue-123-description # 或 git checkout -b feat/new-feature # 推送到远端 git push -u origin fix/issue-123-description提交卫生# 频繁提交按逻辑块 git add specific_file.rs git commit -m fix(scope): small logical change git add another_file.rs git commit -m fix(scope): another logical change # 推送全部提交 git push冲突解决# 如果 main 已前进 git fetch origin git rebase origin/main # 解决冲突 # ... 编辑文件 ... git add . git rebase --continue # rebase 后安全强推 git push --force-with-lease仓库还通过scripts/dev-setup.sh安装三层 git 钩子详见 openwiki/development/setup.mdpre-commitfmt 检查、cargo clippy -- -D warnings、cargo deny、检测硬编码/tmp路径、校验 UTF-8、commit-msg强制 conventional commits 格式type(scope): message、pre-pushpre-commit 全部检查 回归测试 架构边界测试。钩子失败时先修复cargo clippy --fix/cargo fmt--no-verify仅作最后手段。持续集成Continuous IntegrationGitHub Actions 自动完成每次 push/PR运行测试、clippy、fmt、deny依赖审计合并到 main构建 Docker 镜像、更新覆盖率打 tag构建发布、发布产物查看状态# 查看工作流状态 gh run list # 查看详情 gh run view run-id --log仓库侧的 CI 资产十分完备scripts/ci/下集中了质量门禁脚本quality_gate.sh、quality_gate_strict.sh、reborn-e2e-rust.sh、check-target-tree.py、docs_publication_boundary.py、ws12_workflow_contracts.py等数十个其中scripts/ci/ws12_workflow_contracts.py会校验 35 个 CI job 是否都经由 composite action 获得工具链 pincrates/app/ironclaw_architecture_tests是工作区级架构边界测试依赖/层级矩阵门禁依赖或层级变化时必须运行。测试分层文档 openwiki/development/testing.md 还列出了 CI 工作流清单test.yml单元/集成约 10 分钟、reborn-tests.ymlReborn crate 测试约 5 分钟、e2e.yml浏览器 E2E手动触发约 30 分钟、code_style.yml格式/clippy/依赖约 5 分钟、coverage.yml覆盖率push 到 main 触发约 20 分钟。常见坑Common Gotchas问题解决方案CI 中测试失败但本地通过检查环境变量、文件路径、操作系统差异CI 中 clippy 警告本地运行cargo clippy -- -D warnings测试慢用 flamegraph 剖析优化热路径功能没出现在 CLI help 里重新构建了吗cargo build日志里泄露了密钥REPL/TUI 用debug!()而不是info!()测试超时用tokio::time::sleep不要用std::thread::sleep结合仓库证据再补充几点高频坑根 AGENTS.md / openwiki/development/testing.md测试本地过 CI 挂CI 工作目录、env 与本地不同CI 更慢超时型测试易 flakyCI 可能与本地 OS 不同。flaky 测试时间类问题用tokio::time::sleep随机性用种子化 RNG如StdRng::seed_from_u64(42)每个测试保持独立不共享状态外部服务一律 mock不调真实 API。测试挂起用timeout 30 cargo test test_hanging兜底排查死锁锁/互斥/通道循环等待、死循环、外部服务不可达。依赖层级违规新增跨家族 import 前先读目标家族AGENTS.md的排除清单再跑架构测试cargo test -p ironclaw_architecture_tests会拦住层级矩阵违规。小结与延伸阅读至此从理解 Bug → 写失败测试 → 修复 → 验证 → 提交的最小闭环到规划 → 测试先行 → 实现 → 文档 → 提交的功能开发流程再到评审、调试、安全层变更、新工具、部署、重构、性能优化、Git 规范与 CIIronClaw 的整套研发工作流已经串成了一条可执行的流水线。它的底层逻辑始终一致测试优先纪律、调用点测试、零警告门禁、层级矩阵与安全不变式——所有环节都由仓库里的架构测试、CI 脚本与 git 钩子机械地兜底。继续深入可参考openwiki/development/setup.md — 环境搭建、LLM 配置、IDE 与 Docker 开发容器openwiki/development/testing.md — 三层测试策略、覆盖率目标与测试模式openwiki/architecture/overview.md — 四层模型、crate 组织与依赖方向AGENTS.md — 仓库级编码规则、安全不变式与测试纪律CONTRIBUTING.md — 贡献指南FEATURE_PARITY.md — 功能对等矩阵与追踪状态crates/AGENTS.md — 十大 crate 家族路由图与层级矩阵crates/substrates/ironclaw_safety/CLAUDE.md — 安全层深入指引赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐终极Konva.js部署指南从开发到生产的完整工作流终极Konva.js部署指南从开发到生产的完整工作流 Konva.js是一个强大的HTML5 Canvas JavaScript框架它通过为桌面和移动应用程图形学前端坎巴拉太空计划模组管理革命CKAN如何让模组安装变得简单高效坎巴拉太空计划模组管理革命CKAN如何让模组安装变得简单高效 你是否曾经因为《坎巴拉太空计划》模组安装的复杂性而感到困惑面对数百个模组、复杂的依赖关系和版本开发工具包管理器游戏开发终极Jcrop部署实战指南从开发到生产的完整流程终极Jcrop部署实战指南从开发到生产的完整流程 Jcrop是一款强大的JavaScript图片裁剪引擎能够帮助开发者轻松实现网页端的图片裁剪功能。本指南将上一篇喜马拉雅音频下载器完整配置与使用指南下一篇Traymond核心功能揭秘隐藏窗口、恢复窗口与快捷键操作详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考