Flounder

一个自主的白帽安全审计器。
用于目标准备、审计、漏洞利用构建和执行证明的安全自动化工具。

使用说明 · 架构 · 安全 · 贡献

Flounder 将现代编码代理转化为端到端的安全审计系统。给它一个公开源代码或已授权的目标边界——一个仓库、源码树、软件包、已部署的线索或之前的运行记录——代理就可以准备工作区，阅读代码和支撑材料，映射攻击面，深入挖掘有希望的区域，构建漏洞利用路径，运行本地验证测试，然后针对现实世界的真实情况复现已确认的发现。 重要的区别在于，Flounder 不是针对单一技术栈的扫描器、清单运行器或一组手写的 bug 规则。它是围绕模型构建的轻量级白帽审计工作流：模型决定如何对目标进行推理，而 Flounder 提供沙箱、命令策略、持久化状态、执行门控、daemon 控制平面和所需的报告，使该推理具备可用性。

## 结合代理使用 即使您在本地没有检出源代码，也可以直接从 GitHub 安装此技能： ``` npx skills add adshao/flounder --skill flounder -g -a codex -a claude-code ``` 如果您已经在本地检出，请安装检出的副本： ``` npx skills add . --skill flounder -g -a codex -a claude-code ``` 然后自然地向 Codex、Claude Code 或其他支持技能的代理发出请求： ``` Audit this repository with Flounder. ``` 已安装的技能应在涉及以下请求时触发：Flounder 审计、公开源代码或已授权的源代码审查、智能合约或 ZK 审计工作、daemon/provider 设置、验证可疑发现、确认真实发现或收集有执行依据的 bug 报告。事实来源是 [skills/flounder/SKILL.md](skills/flounder/SKILL.md)。 ## 为什么选择 Flounder - **自主审计循环。** `flounder run ` 可以将 prepare -> map -> dig -> synthesize -> verify -> confirm -> report 作为受跟踪的工作流执行。Prepare 可以将交易、地址、项目、仓库或链接转换为暂存的源代码和材料；map 对审计面进行清点；dig 编写并运行验证测试；synthesize 组合跨范围的候选漏洞；verify 通过本地执行确认或反驳候选漏洞；confirm 在真实目标上复现发现；report 将复现的 bug 打包成 Markdown 报告。操作员无需为每个目标构建自定义的场景流水线。 - **框架无关的推理。** Flounder 不内置针对 Solidity/EVM、ZK/证明系统、Rust、Go、JavaScript、协议或特定加密方式的审计策略。源代码、语料库和可选的配置文件都是输入；审计策略来自模型本身。随着编码模型的改进，审计能力也随之提升，而无需针对每个新出现的技术栈重写框架。 - **以执行为依据的发现。** 发现并非仅因为模型说它看似合理就被认为是真实的。它必须引用一个能够触发该漏洞路径且通过执行的本地命令。更强的发现还能通过差异确认、独立反驳和忠实的 PoC 申诉检查。 - **盲测发现结合开放世界复现。** 发现阶段在网络安全隔离下运行，因此发现是基于目标材料推导出来的，而不是从公开披露中复制的。随后 `flounder confirm` 仅为了白帽复现、新颖性检查以及提交/不提交决策表而开放网络。 - **沙箱化执行边界。** 模型生成的代码、PoC、依赖项安装和本地测试都在复制的 workspace 中运行，而不是直接在宿主机的检出目录中运行。默认的 OCI 后端拒绝静默的宿主机执行，仅 bind-mount 复制的 workspace 和 package cache，丢弃 Linux capabilities，使用 `no-new-privileges`、只读根文件系统和 tmpfs 临时目录，在配置后应用进程/内存/CPU 限制，并为密封的审计命令禁用网络。这降低了恶意依赖项、不安全的 PoC 和模型错误在污染宿主机之前的波及范围。 - **多种审计场景。** 同一个产品可用于盲测能力审计、从可疑链上证据进行的事件调查、开放世界的 bug 赏金审计、对可疑发现的定向跟进以及披露准备。无论是由 Flounder 自己准备目标还是您提供源代码路径，这只是输入路径的不同，而不是场景的不同。 - **完美契合 Solidity 和 ZK。** Solidity/EVM 目标效果很好，因为本地分叉和 Foundry/Hardhat 测试可以证明真实的链上影响。ZK/证明系统目标效果也很好，因为本地证明器和约束测试组件可以将细微的缺失约束转化为可执行的反例。这些是高信号的示例，而非硬编码的限制。 - **专为代理工具设计。** Flounder 通过 CLI、React dashboard、自描述的 REST API、pi 扩展、provider 配置文件和 daemon 执行平面公开审计工作流。Codex 风格和 Claude Code 风格的 provider 可以通过相同的沙箱和审计契约进行路由。 - **本地控制代码和凭证。** UI 服务器是一个控制平面。审计在 daemon 上运行（可选择在另一台机器上），因此目标代码和 provider 凭证始终保留在执行主机上。 ## 核心场景 | 场景 | 起始条件 | Flounder 的预期行为 | | --- | --- | --- | | 盲测能力审计 | 公开源代码或已授权的项目、repo、软件包、源码树或项目链接，无 bug 提示 | 尽可能让 Flounder 准备目标，或者在您已经拥有时提供源代码/构建路径。不要包含事件报告、已知的 bug 名称、漏洞利用理论或包含答案的语料库。根据覆盖率和有执行依据的发现来评判结果，而不是凭一句“目标安全”的声明。 | | 事件调查 | 可疑交易、地址、漏洞利用链接或事实性事件线索 | 使用 Prepare 收集链上事实、已部署的源代码、官方项目材料和复现要求。线索是证据，不是证明；输出应解释根本原因，以及它是否在攻击者真实的本地真实环境中得到了复现。 | | 开放世界公开源代码审计 | 公开源代码目标、repo、软件包、部署、项目或赏金范围 | 让 Prepare 在可用时主动收集官方文档、部署、出处、软件包元数据和赏金范围。审计仍然由模型主导，但允许的上下文比盲测能力测试更广。 | | 定向跟进 | 可疑发现、scope id、文件/区域或之前的运行记录 | 使用 `audit --verify`、`audit --scope`、`confirm` 或选定的项目操作，通过执行来解决更具体的问题。 | | 披露准备 | 已确认或已复现的发现 | 整合重复项，在需要时运行真实目标确认，重新生成选定的报告，并仅打包未被忽略且有证据支撑的 bug。 | ## 准备路径 准备关乎 Flounder 如何接收目标，而不是审计的类型。 - **框架准备的目标，默认推荐**：从线索开始，例如项目链接、repo、软件包、赏金页面、交易或地址。`flounder run ` 运行 prepare -> map/dig -> synthesize -> verify -> confirm -> report，当项目包含 task/clue 时，dashboard 会使用相同的路径。 - **源代码提供的目标**：当代码已在本地暂存或用户明确表示不需要外部准备时，使用 `--source`、`--build-root` 和可选的 `--corpus`。这将直接进入密封的 map/dig/synthesize/verify 审计。 - **混合项目**：提供本地源代码/构建路径以及 task/clue。这适用于开放世界的赏金任务，即 Flounder 应该审计本地检出目录，但仍需收集官方公开的上下文、范围、部署和出处。 ## Flounder 自动化的内容 Flounder 专为安全工作中通常需要人工频繁切换工具和上下文的环节而构建： | 步骤 | Flounder 的操作 | | --- | --- | | 目标准备 | 将 repo、源码树、软件包、项目链接、地址、交易或之前的运行记录转化为暂存的审计材料。 | | 源代码和语料库审查 | 让模型阅读源代码以及项目自有的规范、文档、过往审计和设计材料。 | | 范围映射 | 在花费深度审计时间之前，枚举审计面并对 scope 进行评分。 | | 深度审计 | 逐项义务地深入审计选定的 scope，而不是进行浅层的单次提示。 | | 漏洞利用构建 | 在隔离的 workspace 内编写本地 PoC、测试、fixtures 或 harnesses。 | | 沙箱化执行 | 在远离宿主机的源码树、凭证和用户环境的地方运行模型生成的测试和 PoC。 | | 执行证明 | 在本地运行证明，仅在存在命令证据时才提升发现级别。 | | 发现健康度 | 编写运行健康度和积压产物，以便将零发现的运行与浅层运行、资源缺失造成的阻塞或仍需后续深挖的覆盖范围区分开来。 | | 真实目标确认 | 针对现实世界的真实情况（例如已部署目标的本地分叉）复现已确认的发现。 | | 报告 | 跨项目跟踪状态、产物、确认决策、正式报告和提交状态。 | ## 快速入门 使用 Node 24 LTS。此仓库包含固定为 24.13.0 的 `.nvmrc` 和 `.node-version` 文件，这是测试套件所使用的版本。 ``` nvm use npm install npm run build npm run sandbox:build ``` 下面的命令示例使用已安装的 `flounder` 二进制文件。在全新检出源代码且尚未安装或链接该包之前，请使用 `node dist/cli.js` 代替： ``` # 启动本地 control plane 和 dashboard。 node dist/cli.js ui ``` 全局安装该包后，相同的命令为： ``` flounder ui # 在每台 executor 机器上，对其将要运行的 providers 进行身份验证。 flounder daemon provider login openai-codex flounder daemon provider check openai-codex # 对于另一台机器上的 daemon，首先生成一个 control-plane token。 flounder server daemon-token mint remote-1 flounder daemon start --server http://:4500 --token ``` `openai-codex` 使用 pi 订阅/OAuth 认证。代理可以通过运行 `flounder daemon provider login openai-codex` 来触发用户登录；该命令会打印出一个浏览器 URL 或设备码说明供用户完成操作。如果同一个 provider 已经通过 pi 登录（位于 `~/.pi/agent/auth.json`），Flounder 会在执行 `login`/`check` 时将该 provider 条目导入到其 daemon 本地的认证文件中。 然后在 dashboard 中创建一个项目，在 task/clue 框中描述审计任务，选择其执行 daemon 和默认的 provider profile，并开始运行。项目目录默认为 daemon workspace 下的项目 UUID，因此即使显示名称更改，它也能保持稳定。全新安装会为 `openai-codex · gpt-5.5 · xhigh` 和 `claude-code · opus 4.8 max` 播种初始 profile；每个选定的 daemon 仍然需要为其将要运行的 provider 提供本地认证。CLI 可以驱动同一个控制平面： ``` # 推荐默认设置：让 Flounder 准备 target，然后进行 audit、confirm 和 report。 flounder run # 现有本地 source：直接输入 sealed map/dig。 flounder run --target my-target --source ./src --build-root . --corpus ./docs # 根据真实的 ground truth 确认已完成的 run。 flounder confirm ~/.flounder/my-target- --source ./src --build-root . ``` 对于盲测能力审计，clue 应仅指明公开源代码或已授权的目标，而不是可疑的 bug。对于事件调查，clue 应为事实证据，例如交易或地址。对于开放世界的赏金任务，将本地源代码路径与指明公开计划或项目的 task/clue 结合使用，以便 Prepare 可以收集官方上下文。 `--mock-llm` 用于开发环境的离线运行。有关命令、材料、daemon 设置、provider profile、预算和 API，请参阅 [docs/USAGE.md](docs/USAGE.md)。 ## 场景命令 这些是起点。请将占位符替换为公开源代码或已授权的目标，并确保不要将私密材料留在可能被共享的命令行中。 ### 盲测能力审计 使用此命令来衡量 Flounder 的无辅助审计能力。请勿包含事件报告、已知的 bug 名称、漏洞利用理论或带有答案的语料库。 ``` # 让 Flounder 准备一个 public-source target。 flounder run https://github.com/org/protocol # 或者 audit 已经在本地 staged 的 source。 flounder run \ --target protocol-blind \ --source ./contracts \ --build-root . \ --corpus ./docs/specs \ --max-scopes 30 \ --dig-samples 2 ``` ### 事件调查 当输入是可疑交易、地址或事实性的漏洞利用线索时使用此命令。线索是证据，而不是根本原因的答案。 ``` flounder run 0x flounder run ``` ### 开放世界公开源代码审计 当 Flounder 需要在可用时收集官方公开上下文、部署、软件包元数据、出处和赏金范围时使用此命令。 ``` flounder run "Open-world public-source audit for https://github.com/org/protocol; use official docs, deployments, and public scope where available." # 当 source 已经被 checked out 但 Prepare 仍应收集 public context 时的混合项目。 # "dir" 位于 daemon workspace 下；source/corpus 路径是相对于它的。 curl -X POST http://127.0.0.1:4500/api/projects \ -H 'content-type: application/json' \ -d '{"name":"protocol-audit","providerId":1,"daemonId":1,"dir":"protocol","sourcePaths":["contracts"],"buildRoot":".","corpusPaths":["docs"],"config":{"prepareClue":"Open-world public-source audit for ; use official docs, deployments, and public scope where available."}}' curl -X POST http://127.0.0.1:4500/api/projects//runs \ -H 'content-type: application/json' \ -d '{"verb":"run"}' ``` ### 范围映射与定向深挖 当操作员希望先获得一个 scope 清单，然后对选定的 scope 或区域进行特定跟进时使用此命令。 ``` flounder map --target protocol-map --source ./contracts --build-root . --corpus ./docs/specs flounder audit --scope --source ./contracts --build-root . --dig-samples 3 flounder audit src/Vault.sol:120-220 --source ./contracts --build-root . ``` ### 验证已有可疑漏洞 对于来自先前运行、人工审查或导入的 JSON 文件的声明使用此命令。 ``` flounder verify claims.json --source ./contracts --build-root . ``` `flounder audit --verify claims.json --source ./contracts --build-root .` 是等效的。 ### 真实目标确认 在密封运行中本地确认了需要部署级别复现的发现之后，使用此命令。 ``` flounder confirm ~/.flounder/protocol- --source ./contracts --build-root . ``` ### 报告重生成与发现分类 项目报告生成是限定在项目范围内的，因为它使用了被跟踪的发现。未加选择时，它仅生成缺失的正式报告。选定的发现即使已存在报告也会被重新生成；`--all` 会重新生成当前所有可报告的发现。 ``` PROJECT_UUID= flounder report --project "$PROJECT_UUID" flounder report --project "$PROJECT_UUID" --finding 123 --finding 456 flounder report --project "$PROJECT_UUID" --all curl -X POST http://127.0.0.1:4500/api/projects/$PROJECT_UUID/runs \ -H 'content-type: application/json' \ -d '{"verb":"report","findingIds":[123,456]}' curl -X POST http://127.0.0.1:4500/api/projects/$PROJECT_UUID/runs \ -H 'content-type: application/json' \ -d '{"verb":"report","regenerateReports":true}' curl 'http://127.0.0.1:4500/api/projects/'"$PROJECT_UUID"'/findings?tracking=ignored' curl -X PATCH http://127.0.0.1:4500/api/findings/123/tracking \ -H 'content-type: application/json' \ -d '{"status":"open"}' ``` ## 沙箱时 真实的审计会通过沙箱执行模型生成的命令。安全的默认设置是 `--sandbox-backend auto`：在 Apple 硅芯片的 macOS 上，当选定的镜像和密封网络就绪时，它首先使用 Apple 的 `container` 运行时；如果镜像可用，则使用基于 Docker 的 OCI。如果没有沙箱引擎就绪，它会安全失败，而不是在宿主机上静默运行测试。 对于基于 Docker 的路径，请安装并启动 Docker 或兼容 Docker 的运行时，然后使用 `npm run sandbox:build` 构建默认镜像。对于 Apple 的路径，请安装并启动 Apple 的 `container` 运行时，将选定的沙箱镜像构建或拉取到该运行时中，并让 `auto` 在 Apple 硅芯片的 macOS 上选择它。`--sandbox-backend apple-container` 明确要求使用该路径。密封的 Apple 命令使用内部的仅限宿主机、无 DNS 的 `flounder-sealed` 网络。 默认镜像是一个基线，并不保证涵盖每个目标技术栈。它包含了常见的构建和审计工具链，使得首次运行具有安全的执行边界，但特定目标应使用由 daemon 或操作员提供的镜像，其中包含它们所需的确切编译器、证明器、链上工具或包管理器： ``` flounder run --source ./src --build-root . --sandbox-image your-audit-image:latest ``` 镜像构建是受信任执行基础的一部分。审计模型可以报告缺失的工具链或提出镜像方案，但在审计循环内部不应获得不受限制的 `docker build` / `docker pull` 能力。安全的自动化路径是生成一个可审查的特定目标镜像计划，在受控的 daemon/操作员步骤中构建它，然后通过名称或摘要固定并重用该镜像。 仅用于受信任的本地冒烟测试，请使用 `--sandbox-backend host --allow-host-execution` 或设置 `FLOUNDER_ALLOW_HOST_EXECUTION=1`。Host 模式仍然使用复制的 workspace 以及隔离的 `HOME` 和 package cache 路径，但它不提供内核级别的文件系统或网络隔离，不应用于不受信任的目标、恶意依赖项或真实的模型生成的漏洞利用代码。 ## 自行使用 代理可以通过 [skills/flounder/SKILL.md](skills/flounder/SKILL.md) 驱动一切，但每个步骤也直接公开可用： - **Dashboard**：`flounder ui` 用于管理项目、daemon、provider profile、运行、scope、发现、实时活动和报告。 - **CLI**：工作流动作（`prepare`、`run`、`map`、`audit`、`verify`、`confirm`、`report`）、运行历史导入、`flounder server ...` 下的控制平面资源、`flounder daemon ...` 下的 daemon 本地操作以及 `config`。 - **REST API**：`GET /api` 返回自描述目录；代理无需 UI 即可创建项目、将运行加入队列、查看日志并读取发现。 - **pi 扩展**：`flounder_prepare`、`flounder_run`、`flounder_map`、`flounder_audit` 和 `flounder_confirm` 在通过 pi 加载时公开代理会话工作流工具。 ## 工作原理 被跟踪的工作流为： 1. **Prepare**：当运行从线索开始时，获取或暂存源代码、语料库、依赖闭包和部署匹配证据。 2. **Map**：枚举审计面并对其评分，不产生发现。 3. **Dig**：深度审计选定的 scope，构建 PoC，并在本地通过执行确认发现。 4. **Synthesize**：将每个 scope 的发现组合成不同的跨范围 bug 候选漏洞。 5. **Verify**：通过本地执行确认或反驳可疑和合成的候选漏洞。 6. **Confirm**：在现实世界的真实情况中复现已确认的发现，并决定它们是否为提交候选。 7. **Report**：为复现的或通过源代码本地确认的 bug 生成正式的 Markdown 报告。 您可以端到端运行，也可以直接驱动每个阶段： | 命令 | 用途 | | --- | --- | | `flounder prepare ` | 从交易、地址、项目、软件包、仓库或链接进行开放世界的获取，转化为暂存的源代码、语料库、依赖闭包和部署匹配证据 | | `flounder run ` | 一条命令实现 prepare -> 密封的 map/dig/synthesize/verify -> confirm -> report，从交易、地址、repo、软件包、项目、赏金或链接开始 | | `flounder run --source --target ` | 源代码提供的密封审计：对已在本地暂存的源代码进行 map -> dig -> synthesize -> verify | | `flounder map --target --source ` | 仅枚举并持久化 scope 清单；不产生发现 | | `flounder audit --source ` | 深度审计一个指定的文件/函数/区域，无需新的 map | | `flounder audit --scope --source ` | 在 `flounder map` 之后深度审计选定的库存 scope | | `flounder audit --verify --source ` | 通过执行确认或反驳来自 JSON 的可疑发现 | | `flounder verify --source ` | `audit --verify` 的别名；通过执行确认或反驳来自 JSON 的可疑发现 | | `flounder confirm --source ` | 在现实世界的真实情况中复现已本地确认的发现 | | `flounder report --project [--finding ...] [--all]` | 生成缺失的正式报告，重新生成选定的报告，或重新生成当前所有可报告的发现 | | `flounder history import-run --target --run ` | 将现有的运行目录导入到被跟踪的历史记录中 | | `flounder server project list` | 列出被跟踪的项目 | | `flounder server run list [--project ]` | 列出全局或项目的运行历史 | | `flounder server finding list [--project ] [--status ] [--tracking ]` | 全局或针对单个项目列出发现 | | `flounder server daemon list` | 列出已注册的执行 daemon | | `flounder server daemon-token mint [name] [--server ]` | 为远程 daemon 创建 token | | `flounder daemon start --server --token ` | 运行一个领取排队任务的执行器 | | `flounder daemon provider list/check/login [provider]` | 在执行器机器上管理 provider 认证 | | `flounder config list/get/set/unset/path` | 读取或写入持久化的 CLI 默认值 | | `flounder ui [--port ] [--host ] [--no-daemon]` | 启动本地控制平面 dashboard、REST API、存储和可选的同机 daemon | 正式报告生成可从 dashboard 的 More actions 菜单或使用 `{"verb":"report"}` 的项目运行 API 中获取。它被特意绑定到被跟踪的项目，因为它需要发现 ID、跟踪状态和确认决策。 发现的状态是框架根据执行得出的判定： | 状态 | 含义 | | --- | --- | | `confirmed-differential` | 漏洞利用运行了，并且模型的最小修复阻止了它，同时测试仍然继续运行。 | | `confirmed-executable` | 引用的本地确认测试触发了该 bug。 | | `suspected` | 可信但未经执行证明，或被反驳降级。 | | `refuted` | 怀疑者或真实目标的复现打破了该声明。 | ## 输出物 运行会在输出目录下生成私有产物。默认情况下，Flounder 将本地状态保存在 `~/.flounder` 下： - `~/.flounder/flounder.db`：用于项目、运行、scope、发现、发现积压、daemon token 和作业的本地跟踪数据库。 - `~/.flounder/-/`：运行产物、复制的 workspace、日志、记录、发现和报告。 - `~/.flounder/history//`：持久内存、scope 清单、构建缓存和项目历史记录。 - `~/.flounder/workspace/`：用于项目目录的默认 daemon workspace。 - `~/.flounder/agent/auth.json`：daemon 本地的 provider 认证，由 `flounder daemon provider login` 创建或从现有的 pi 认证条目导入。 系统临时目录仅用于短暂的草稿操作，例如非交互式 CLI 子进程工作目录或内联验证 payload；它们不是默认的跟踪存储。 运行产物目录包含： - scope 清单和覆盖率（`audit_scopes.json`、`summary.json`） - 发现和假设（`audit_findings.json`、`audit_hypotheses.json`） - 命令证据（`audit_command_runs.json`） - 发现健康度和积压（`run_health.json`、`coverage_gaps.json`、`resource_requests.json`、`followup_scopes.json`） - 实时/回放跟踪（`events.jsonl`、`audit_transcript.json`、`calls/*.json`） - 私有报告草稿（`audit_report.md`、`report_.md`） - 确认决策表（`confirm_decision.json`、`confirm_report.md`、`confirm_equivalence.json`，以及当尝试收集实时暴露证据时生成类似赏金的 `impact_inventory.json`） dashboard 将元数据、运行健康度、发现积压记录和产物路径存储在 SQLite 中，因此代理无需抓取运行目录即可检查进度。 ## Dashboard `flounder ui` 是一个本地控制平面和 dashboard，用于管理项目、daemon、provider profile、运行、scope、发现、报告和实时活动。项目被绑定到一个执行 daemon 和一个默认的 provider profile，并可选地为 prepare、map、dig 和 confirm 阶段提供特定的 provider 覆盖。选定的 daemon 必须对项目可以使用的每个 provider profile 进行认证。新项目从一个显眼的 task/clue 输入框开始，创建后可立即运行，并将其 daemon workspace 目录默认为项目 UUID。 项目视图显示 prepare -> map -> dig -> synthesize -> verify -> confirm -> report 工作流、当前阶段、scope 覆盖率、运行健康度、发现积压、实时模型活动、即时落地的发现、针对单个发现的确认操作、真实目标复现状态以及报告。主要操作是在首次流水线运行之前的**运行**，以及在存在运行后的**继续**；更细粒度的 Prepare、Map、Dig、Verify、Confirm 和 Report 操作位于 More actions 下。项目列表可以固定项目，将其归档到 Settings，稍后取消归档，并拖动活动项目以进行手动排序。 跨项目的“发现”视图跟踪每个发现的提交状态。它支持项目、审计状态和跟踪过滤器；默认的 Active 视图隐藏标记为 `ignored` 的发现，而 Ignored 视图允许操作员通过将其状态改回 `open` 来稍后恢复机器报告的误报。 每个 UI 操作也是一个 REST 调用。`GET /api` 返回 API 目录，`GET /api/projects/:uuid/backlog` 列出发现积压记录，`PATCH /api/backlog/:id` 更新其操作员状态，`GET /api/runs/:id/log` 流式传输执行中 daemon 的实时模型输出、工具调用和里程碑。 ## 白帽边界 Flounder 支持对公开可用的源代码、您自己的代码、客户授权的目标或公开的 bug 赏金范围进行白帽审计。密封的发现仅在本地进行。模型生成的文件和命令在复制的沙箱 workspace 内运行，而不是直接修改宿主机的检出目录。开放世界的确认可以获取、搜索、fork 和读取，但绝不能广播交易、转移资金、提交写入、持久化访问或针对声明目标边界之外的系统。仅在本地测试、本地分叉或隔离的 harnesses 上重放漏洞利用，并且除非赏金计划规定了其他途径，否则应私下披露公开源代码的发现。请参阅 [SECURITY.md](SECURITY.md)。 ## 文档 - [使用说明](docs/USAGE.md)：命令、沙箱设置、dashboard、API、材料、provider、daemon 设置和输出物。 - [架构](docs/ARCHITECTURE.md)：轻量级代理设计、沙箱边界、确认边界、控制/执行分离和跟踪模型。 - [代理技能](skills/flounder/SKILL.md)：Codex / Claude Code 操作手册。 - [领域配置文件](configs/README.md)：可选的无答案上下文包。它们不是产品模式，默认关闭。 - [可选的 Solidity/EVM 说明](docs/SOLIDITY.md)、[Cairo/Starknet 说明](docs/STARKNET.md)、[TON/FunC 说明](docs/TON.md) 和 [ZK 约束配置文件](configs/zk-constraint-audit.default.json)：高信号的上下文示例和验证环境设置，并非 Flounder 的核心限制。 ## 贡献 请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)。采用 AGPL v3 许可证。