企业官网建设流程全解析

• 网络安全
• 渗透测试
• AI Agent
• 多智能体
• 人工智能
• 应用安全
• 代码智能体
• 红蓝对抗

本文围绕 T3MP3ST 仓库中 option-matrix.md 这一 AIWG（AI Working Group）准入决策文档展开，系统讲解它如何以“项目现实 → 约束与上下文 → 优先级与权衡 → 决策选项 → 框架应用 → 所有者验证 → 决策记录”为主线，把开源代码库中沉淀的证据转化为可被维护者最终拍板的治理基线。读完本文，你将理解该决策矩阵中每一张表、每一组权衡的推导逻辑，掌握它在 iteration-001-plan.md 等后续治理工作中的应用方式，并能够把同样的“证据加权 + 明确取舍 + 非协商底线”方法论复用到其他安全类开源项目的路线规划中。

一、这份文档是什么：AIWG 准入流程中的“项目意图捕获器”

option-matrix.md是 .aiwg/intake/ 目录下 AIWG 准入（intake）流程的产物之一。它的Purpose明确写道：捕获项目“是什么”，并把“必须由所有者（owner）输入来完成”的决策暴露出来。也就是说，这份矩阵不是一份纯代码分析报告，而是一份半成品决策输入——仓库证据负责回答“现状如何”，而战略取舍（稳定性优先还是扩张优先、是否转向托管化等）必须由维护者回答。

在 .aiwg/intake/ 目录中，它与其他文档形成一条完整的证据链：

• project-intake.md —— 基于代码库的详细现状盘点（Brownfield intake），提供“证据输入”；
• option-matrix.md —— 本矩阵，提供“意图与取舍”的草案；
• solution-profile.md —— 给出推荐的治理严谨度与路线图；
• risk-screening.md —— 给出非协商的安全风险约束；
• intake-form.md —— 浓缩版准入表单与所有者已确认的上下文。

文档生成时间是 2026-07-20，对应的基线修订记录在 intake-form.md 中（基线修订号186afe6b50e365371774aa2ed7986d73eb0656db），触发原因则是“过渡到 AIWG 记忆系统”。

从项目事实看，T3MP3ST 是一个成熟的、自托管的 TypeScript 攻击性安全平台，具备本地浏览器 UI（War Room）、CLI、HTTP API、MCP 集成、外部安全工具适配器、可复现基准测试与大量文档（这些能力可分别在 README.md、FEATURES.md 与 package.json 的脚本表中得到印证）。矩阵开篇即给出判断：稳定的核心在受授权目标上运行真实工具，而部分多智能体、领域专属与进化式能力仍处于实验或规划阶段——这正是全文所有权衡的出发点。

二、项目现实快照：矩阵如何用“证据 + 置信度”描述现状

2.1 受众与规模

矩阵第一张表回答“这个项目给谁用、规模多大”，并刻意把“可验证证据”与“所有者口头输入”分开：

这里体现了一个贯穿全文的方法论：“所有者报告”不等于“已测量数据”。受众构成、开源分发方式是仓库可直接确认的高置信度事实（例如 README.md 中列出的 Claude Code、Codex、Hermes、OpenCode、Oh My Pi 等接入方式，以及 Ollama、LM Studio、vLLM 等离线推理后端），但“成千上万用户”被明确标记为 unmeasured，只作为规划输入而非对外声明。这一点在后面的“决策记录”中再次强调：scale 数据“treated as owner-supplied planning context until telemetry supports a measured claim”。

2.2 部署与基础设施

这些条目都有仓库证据支撑：

• 部署形态：src/cli.ts、src/server.ts（Express API + War Room 静态托管）、src/mcp-server.ts（MCP stdio 集成）构成了多交付面，package.json 中npm run server、npm run mcp等脚本与之对应；
• 默认回环绑定：HTTP 默认绑定 loopback，配合 localhost CORS/origin 与 Host-header 防护（见 project-intake.md 的安全控制清单）；
• 无应用数据库：持久化依赖本地配置（conf依赖）、浏览器 localStorage、报告与证据文件系统工件；Docker 场景下挂载reports/与evidence/（docker-compose.yml）；
• CI/CD：GitHub Actions 质量流水线（install、lint、typecheck、test、coverage、doctor、claim verification、anti-fitting、provenance、prompt audit、smoke 等，见 package.json 的test:release串联），但没有托管化生产部署流水线。

2.3 技术复杂度基线

矩阵给出了一组可复算的复杂度数字（来自代码库分析）：

• src/下约46,129 行 TypeScript，分布在 111 个文件；
• 仓库共1,665 个被跟踪文件，其中大量是提交的 JSON 基准工件（见 bench/ 下的 xbow、cybench、cve-zero 等目录）；
• 主语言 TypeScript，辅助 JS/MJS、Shell、YAML、Python、C、Java、Go、Rust、Perl、HTML 与容器定义；
• src/与scripts/下75 个 test/spec 命名文件；
• docs/与docsite/下52 个 Markdown 文档；
• 高风险因素清单：真实攻击性操作、凭据、外部工具、网络访问、敏感证据、模型非确定性、多提供商兼容性、公开基准声明。

这组数字的意义在于：复杂度决定治理成本。一个能在单一进程内执行真实网络攻击、调用外部二进制工具、并把结果沉淀为证据的平台，其安全审查负担远高于普通开发者工具——这正是后续“质量与安全 0.35”权重最高的原因。

三、约束与上下文：已知、未知与“非协商项”

3.1 已知约束（Known）

• AGPL-3.0-or-later 开源许可（package.json 的license字段可确认）；
• Node.js 18+ 运行时、Node.js 22 CI（注意当前 package.json 的engines已声明node: >=22.19.0，即运行时要求比矩阵撰写时的基线更进一步）；
• 本地优先 / 无密钥（keyless）操作是核心产品承诺：无需新增 API Key，可直接复用本机已登录的编码 Agent，或对接本地 OpenAI 兼容推理服务（Ollama / LM Studio / vLLM），见 README.md；
• 授权使用与目标范围是不可协商的安全约束（对应 SECURITY.md 与 risk-screening.md 的 R-001）；
• 声明必须能从已提交证据中复现：对应npm run verify-claims（scripts/verify-claims.mjs）；
• 稳定 vs 实验状态必须保持显式：这是 adr-005.md（“把当前状态与研究愿景分离”）的核心决策；
• 支持异构贡献者群体与多提供商/运行时环境。

3.2 未知或未验证项（Unknown or Unverified）

矩阵诚实列出无法从仓库推断的事项：

• 维护者的可用时间与预算；
• 已测量的用户/安装遥测与观察到的增长率；
• 收入或资金模式；
• 合同义务与通用支持 SLA；
• 正式合规或认证目标；
• 发布节奏与下一个里程碑；
• 当前最高优先级的痛点。

这些未知项随后被映射到“Owner Validation Needed”小节，要求所有者逐条作答，而不是由分析者臆测。这也解释了为什么这份矩阵的定位是“决策输入”而非“决策本身”。

四、优先级与权衡：证据加权的四条标准

矩阵给出一个待所有者验证的临时权重表（provisional weighting）：

配套给出了三个层面的指导原则：

• Optimizing for（优化目标）：可信、可复现的攻击性安全能力，同时保持“默认安全”（safe-by-default），并借助用户已拥有的基础设施（本机 Agent、本地模型服务）触达用户；
• Likely acceptable trade-off（可接受的取舍）：实验性能力可以在完全可靠之前迭代，前提是成熟度状态足够醒目、共享安全边界始终被强制执行；
• Non-negotiable（非协商底线）：授权、目标遏制、秘密保护、证据完整性、诚实的性能声明，以及对披露或实质性危险行为的人工控制。

这四条底线不是口号，仓库里有对应机制：范围门（src/tests/arsenal-scope-gate.test.ts）、精确 origin 的凭据/头注入（src/tests/target-headers-static.test.ts）、声明的可复现校验（scripts/verify-claims.mjs）以及 stub/计数诚实性测试（src/tests/stub-honesty.test.ts、src/tests/arsenal-count-honesty.test.ts）。在 risk-screening.md 中，这条底线被形式化为“阻断规则”（Blocking rule）：任何削弱授权、默认范围遏制、精确 origin 凭据或必要证据/声明门的变更，在没有获批替代控制之前阻断发布。

五、四个决策选项：稳定、扩张、蜂群、托管

矩阵的核心产出是四个可供所有者选择的战略方向：

结合仓库证据逐一展开：

• 选项 A（稳定核心）：聚焦既有稳定路径（CLI、War Room、HTTP API、MCP、arsenal、基准测试）、安全边界、文档与发布质量。这是信任与回归面风险最优的选择，但代价是领域扩张变慢。
• 选项 B（渐进扩张，代码证据下的默认推荐）：每次只推动一个实验域，用显式的基准与安全门作为晋升门槛。这与 adr-005.md 的成熟度晋升要求完全吻合——晋升到 stable 需要“确定性共享安全测试、可操作路径、当前文档、与声明匹配的可复现证据、以及 UC/US/NFR/SAD 可追溯性更新”；也与 vision-alignment.md 的评估方法一致（Implemented / Partial-experimental / Research / Future 四级分类，且“对齐不等于实现”）。
• 选项 C（蜂群优先研究）：优先多智能体协同与进化能力。仓库中确有对应的实验资产（scripts/obsidivm-agent.mjs、scripts/obsidivm-evolve.mjs、scripts/cli-swarm.mjs 等），但矩阵同时指出成本、非确定性与安全复杂度更高——这正是它只在“研究经费与容忍度明确”时才成立的原因。
• 选项 D（托管/企业化演进）：引入集中式服务运维、租户、治理与合规。矩阵判定这是“重大架构与运营模式变更”，且仓库层面无多租户架构、无应用数据库、无集中观测（见 project-intake.md 的“未检测到”清单），因此仅在真实客户需求与资源具备时才值得启动。

最终选定的姿态（见“决策记录”）是平衡型组合：稳定性、领域扩张、蜂群研究与采用四者并举，而不是单选其一。

六、框架应用：什么现在做、什么推迟、什么触发调整

6.1 现在推荐（Recommended now）

• 核心安全、发布、来源（provenance）与承载声明（claim-bearing）的路径采用完全严谨（full rigor）；
• 实验模块采用适度严谨（moderate rigor）——对应 solution-profile.md 的“实验模块用更轻迭代，但保留显式成熟度标签、威胁分析、共享安全边界测试与晋升前的基准标准”；
• 对信任边界与成熟度晋升做架构决策；
• 持续的安全、架构、风险与测试策略循环；
• 为本地服务器、Agent/提供商故障、外部工具与敏感工件编写运维手册（runbook）。

6.2 推迟直到触发（Defer unless triggered）

• 企业治理与正式变更委员会（change board）；
• 托管多租户架构；
• 多区域基础设施与集中式可观测性；
• 正式合规认证工作。

6.3 调整触发条件（Adaptation triggers）

以下任一情形出现时，应重新评估上述框架：

• 出现托管服务或集中保留的用户/目标数据；
• 出现合同 SLA 或受监管客户需求；
• 维护者数量或发布频率出现实质增长；
• 危险工具面扩张；
• 实验性能力被晋升为稳定；
• 公开声明无法被确定性验证完全覆盖；
• 用户/安装量显著增长，或出现反复的生产事故。

这组触发器与 adr-005.md 中的“新基线触发器”以及 iteration-001-plan.md 中“托管/分布式/自治架构请求将退出本期迭代并启动新的 inception/架构工作”的变更控制规则相互呼应。

七、所有者验证与决策记录：矩阵如何闭环

7.1 待所有者回答的问题（Owner Validation Needed）

矩阵明确：最终意图不能从代码推断，必须由所有者回答五个问题。文档中记录的回答如下：

1. 触发本次准入的决策或里程碑是什么？—— 过渡到 AIWG 记忆系统；
2. 下一版本最重要的是什么：稳定性、领域扩张、蜂群研究还是采用？—— all of the above（全部）；
3. 当前用户/安装规模与未来 12 个月预期变化？—— 数千到数万；
4. 除已记录的授权约束外，哪些失败是不可接受的？—— none, failsafe patterns always（没有，始终采用故障安全模式）；
5. 仓库之外是否存在未体现的合同、资金、合规或支持承诺？—— no（无）。

注意第 4 问的回答被细化为：fail-safe 不代表所有失败都可接受，也不意味着安全/证据缺陷可以被豁免——这与 risk-screening.md 的阻断规则一致。

7.2 决策记录（Decision Record）

• 选定姿态：在稳定性、渐进领域扩张、蜂群研究与采用之间采取平衡组合；
• 主导约束：故障安全行为；授权、范围、秘密、证据完整性与诚实声明保持非协商；
• 规模输入：数千到数万用户/安装，在遥测支持可测量声明之前仅作为所有者提供的规划上下文；
• 承诺：未提供额外的合同、资金、合规或支持承诺；
• 架构影响：继续本地优先的模块化基线；托管/分布式工作必须由新决策驱动，而不能从采用目标中推断。

7.3 落地：从矩阵到迭代计划

矩阵并非停留在纸面。其结论直接输入 iteration-001-plan.md（“Architecture Alignment”迭代）——目标是把当前状态架构、安全可追溯性、成熟度声明与工作负载证据变成可自动维护的治理资产，包括：评审 SAD 与 ADR-001~005、实现成熟度一致性审计（CI 或发布检查可发现矛盾的 stable/experimental/research/roadmap 标签）、补全网状适配器安全清单、建立源码注入与并发任务的基准 receipts、以及清理 TODO/FIXME/HACK 标记。其中“成熟度一致性审计”正是 adr-005.md Definition of Done 中尚未勾选的“机器可检查的跨文档成熟度一致性门”。

八、方法论总结：如何复用这份矩阵

option-matrix.md之所以值得作为模板，是因为它遵循了三条可复用的纪律：

1. 证据与输入分层：凡能从仓库确认的（代码、测试、配置、CI、文档）标注为事实；凡来自所有者的（规模、承诺、预算）明确标注为待验证输入，两者永不混同；
2. 权重公开、临时、可复议：优先级权重带有明确的证据理由、合计为 1.00，且标注 provisional，等待所有者复议；
3. 底线独立于策略：无论选择稳定、扩张、蜂群还是托管，授权、范围、秘密、证据与诚实声明这五条非协商底线不变——策略可以平衡，底线不能交易。

对任何希望为安全类开源项目建立治理基线的团队，这套“现状快照 → 约束盘点 → 证据加权 → 选项与取舍 → 触发器 → 所有者闭环”的骨架都可以直接套用；而 T3MP3ST 的 .aiwg/ 目录则为每个环节提供了可直接对照的实例（intake-form.md、solution-profile.md、risk-screening.md、adr-005.md、iteration-001-plan.md）。

• 网络安全
• 渗透测试
• AI Agent
• 多智能体
• 人工智能
• 应用安全
• 代码智能体
• 红蓝对抗