NomiFun 架构综合分析报告

主题：NomiFun Desktop AI Agent 平台（v0.2.30）的架构哲学定位 方法：CodeGraph 源码知识图谱分析 + 本地配置系统检查 + 知识库哲学框架对比 结论：Agent 联邦制（Agent Federalism）—— 一个新物种 日期：2026-07-22

摘要

本报告整合三项独立研究——(1) CodeGraph 源码分析（nomifun-tauri, 2,492 文件, 58K 节点）、(2) 系统配置检查（47 表数据库、MCP 服务、IDMM 配置）、(3) 知识库哲学框架（运行时共和制 vs 宪法控制面）—— 对 NomiFun 进行完整的架构哲学定位。

核心发现：NomiFun 并非两种现有哲学"共和制"或"宪政"的简单混合，而是在两个层面同时运作的新物种：

• 会话层面（Conversation/Terminal）：宪法控制面（~40%）与运行时共和制（~30%）共存于 IDMM 的双路监督架构中
• 组织层面（Agent 执行 DAG、跨会话通信、元监督）：完全独立于两种传统哲学的第三维度（~30%）

最终判定：Agent 联邦制——介于单体 Agent 治理与分布式 Agent 网络之间的中间形态。

目录

1. 方法论：三项研究的整合路径
2. 配置层快照：NomiFun 的生产部署状态
3. 源码层解剖：CodeGraph 揭示的架构基因
4. 哲学定位框架
5. 综合判定：Agent 联邦制
6. NomiFun 架构的三个运作层面
7. 关键创新机制详解
8. 风险、张力与演化方向
9. 三方研究交叉验证：本地源码 + 网络研究 + 哲学框架
10. 结论与建议

1. 方法论：四项研究的整合路径

1.1 四项研究的整合方式

┌─────────────────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│  ① CodeGraph 源码    │     │  ② 系统配置检查      │     │  ③ 深度网络研究     │
│  - 27 backend crates │     │  - 47 数据库表       │     │  - 46 crate 全景    │
│  - 6 agent crates    │     │  - 4 MCP 服务器      │     │  - 26+ 模型提供商   │
│  - 核心引擎模式      │     │  - IDMM tier/预算    │     │  - 8+ 竞品对比      │
└─────────┬───────────┘     └──────────┬───────────┘     └──────────┬───────────┘
          │                            │                            │
          └──────────────────┬─────────┼───────────┬───────────────┘
                             │         │           │
                    ┌────────▼─────────▼───────────▼──────┐
                    │  联合分析层                         │
                    │  - 源码模式 ⇔ 配置状态 ⇔ 市场定位    │
                    │  - 设计意图 ⇔ 实际部署 ⇔ 竞品差异    │
                    │  - 架构边界 ⇔ 运行时行为 ⇔ 生态位    │
                    └────────────────┬───────────────────┘
                                     │
                          ┌──────────▼──────────────────┐
                          │  ④ 哲学框架评估             │
                          │  - 运行时共和制 (Claude)    │
                          │  - 宪法控制面 (Codex)       │
                          │  - 新维度判定：联邦制       │
                          └─────────────────────────────┘

2. 配置层快照：NomiFun 的生产部署状态

2.1 数据库全景（47 表）

2.2 MCP 服务器状态

⚠️ 注意：所有 MCP 服务器绑定到 conv_019f831d，当前会话没有绑定，因此 deep-research 技能中的 jina/tavily/exa/sequential-thinking 调用在此会话中不可用。

2.3 IDMM 配置

3. 源码层解剖：CodeGraph 揭示的架构基因

3.1 代码规模总览

3.2 核心架构：三引擎驱动

┌─────────────────────────────────────────────────────────────────┐
│                    NomiFun 核心三引擎                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ① Agent Execution Engine (engine.rs, 3614行)                   │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  Planner ──→ Scheduler ──→ AttemptRunner                │    │
│  │  规划       调度         执行                           │    │
│  │  (goal→plan) (plan→steps) (steps→conversation)         │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ② IDMM 监督引擎 (supervisor.rs, 2132行)                       │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  fault_watch ──→ decision_watch                         │    │
│  │  提供者/Agent 错误   空闲/决策/开放问题                  │    │
│  │  └─ 独立预算、指数退避、升级阶梯                         │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ③ Gateway MCP 引擎 (server.rs, 584行)                          │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  CapabilityAuth ──→ RegistryDispatch ──→ ACP Bridge    │    │
│  │  能力凭证          工具分派            进程桥接          │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

3.3 Agent Execution Engine 深度发现

3.3.1 3 层控制流

3.3.2 内容寻址委派（Content-Addressed Delegation）

delegation_operation_id() 对语义操作计算 SHA256 哈希，确保：

• 幂等重放：相同操作产生相同 ID，可安全重试
• 无冲突：避免重复创建相同的执行步骤
• 可审计：操作历史可完整追溯

这是 NomiFun 最精妙的设计之一 —— 将语义一致性与操作状态解耦。

┌────────────────────────────────────────────┐
│  operation_semantics                       │
│  (goal + delegator + strategy + adapt...)  │
│                    │                       │
│                    ▼                       │
│           SHA256(content_addr)             │
│                    │                       │
│                    ▼                       │
│  delegation_operation_id                  │
│  → idempotent replay                      │
│  → conflict-free DAG insertion            │
│  → audit trail                            │
└────────────────────────────────────────────┘

3.3.3 模型池系统

enum ModelPoolSpec {
    Automatic,  // 自动选择最佳模型
    Single { model: String },  // 固定模型
    Range { models: Vec<String> },  // 候选集
}

• Automatic 模式：根据任务类型自动选择模型
• Range 模式：可在 IDMM 监督下在候选模型中切换
• MAX_MODELS = 8：硬限制防止池膨胀

3.3.4 计划门控（Plan Gate）

enum PlanGate {
    Automatic,           // 立即执行
    RequireApproval,  // 等待审批
}

这是宪法控制面与运行时共和制的核心张力点——Automatic 赋予 Agent 运行时自由，RequireApproval 则是前置的宪法约束。

3.3.5 执行常量

3.4 IDMM 监督引擎深度发现

3.4.1 双路监视架构

                        ┌────────────┐
                        │  IDMM 核心  │
                        └────┬───────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────▼──────┐ ┌────▼────────┐
     │  fault_watch   │ │ decision_watch │
     │  ─ provider err│ │  ─ idle       │
     │  ─ agent err   │ │  ─ decisions  │
     │  ─ tool err    │ │  ─ open qs    │
     └────────┬───────┘ └──────┬────────┘
              │                │
              ▼                ▼
     ┌─────────────────────────────┐
     │      独立预算 & 升级路径      │
     │  ┌─────────────────────────┐│
     │  │ RuleOnly → RulePlusModel││
     │  │          → Halt         ││
     │  └─────────────────────────┘│
     └─────────────────────────────┘

3.4.2 升级阶梯（Escalation Ladder）

3.4.3 策略类型系统（policy.rs - 1399行）

3.4.4 破坏性否决检测

IDMM 内置了针对危险模式的模式匹配系统，检测如：

• rm -rf 类文件删除命令
• DROP TABLE 类数据库破坏语句
• git reset --hard 类版本控制破坏
• 其他高风险 shell 命令模式

这是宪法控制面在操作层的具象实现——一部分规则是运行时协商的，一部分是硬编码不可逾越的。

3.5 Gateway MCP 引擎深度发现

3.5.1 架构

┌────────────────────────────────────────────┐
│  Gateway Mcp Server (axum, 127.0.0.1:0)    │
│                                            │
│  ┌──────────────┐    ┌──────────────────┐  │
│  │ Capability    │    │ ToolRegistry     │  │
│  │ Issuer        │───→│ dispatch         │  │
│  │ (loopback)    │    │ visibility gates │  │
│  └──────┬───────┘    └────────┬─────────┘  │
│         │                     │            │
│         ▼                     ▼            │
│  ┌──────────────────────────────────────┐  │
│  │  POST /tool                          │  │
│  │  → verify capability                 │  │
│  │  → resolve tool                      │  │
│  │  → check visibility (profile×surface)│  │
│  │  → execute / forward to ACP          │  │
│  └──────────────────────────────────────┘  │
└────────────────────────────────────────────┘

3.5.2 三维可见性门控

工具分派受三层检查：

1. Profile（配置画像）：预设配置
2. Surface（交互面）：conversation / terminal / channel
3. Danger tier（危险等级）：低/中/高/不可逆

只有三层都允许的工具才可见。这是宪法控制面在工具层的完全实现——工具调用权不是运行时协商的，而是架构硬编码的。

3.5.3 ACP 协议桥接

• ACP stdio 进程通过 POST /tool 转发工具调用
• 能力凭证定期更新/撤销
• 跨进程工具调用的安全边界

3.6 Agent Runtime Registry 深度发现

3.6.1 工厂模式 + 单次飞行

trait AgentRuntimeRegistry {
    fn create(conversation_id) → AgentRuntime;
    fn get(conversation_id) → OnceCell<AgentRuntime>;
    fn destroy(conversation_id);
}

• OnceCell：每个会话只有一次创建机会
• AsyncMutex：序列化构建/销毁，避免竞争条件
• 单一事实来源：运行时实例与会话 1:1 绑定

3.6.2 崩溃循环治理（RestartGovernor）

• 滑动窗口内限制重启次数
• 超过阈值后延长等待期或放弃
• 只有 ACP Agent 参与空闲清理

3.7 Agent 执行类型系统

状态机定义（agent_execution.rs）：

// 步骤生命周期：7 态
ExecutionStepStatus {
    Pending, Ready, Running, Completed,
    Failed, AwaitingApproval, Skipped
}

// 尝试生命周期：8 态
ExecutionAttemptStatus {
    Pending, Planning, Running, Completing,
    Completed, Failed, Cancelled, AwaitingApproval
}

权限过渡规则（明确的 CAS 匹配）：

• Pending → Ready：依赖条件满足
• Ready → Running：调度器分配
• Running → Completed/Failed：执行完成/出错
• 需要审批时 → AwaitingApproval

这是典型的宪法控制面状态机——状态转换路径由代码枚举定义，而非运行时协商。

4. 哲学定位框架

4.1 基准坐标系：两种经典哲学

4.2 NomiFun 的基因检测矩阵

📜 宪法控制面基因（~40%）

🏛️ 运行时共和制基因（~30%）

🧬 新物种基因（~30%）— 两种哲学都没有的

4.3 哲学归属的三层分布

                          ┌──────────────────┐
                          │   组织层 (NEW!)   │
                          │   ~30% 新物种     │
                          │                  │
                          │  DAG 参与者       │
                          │  跨会话通信       │
                          │  元监督           │
                          │  自治工作循环     │
                          │  联邦边界         │
                          └──────────────────┘
                                    │
                          ┌─────────▼─────────┐
         ┌────────────────┐                   ┌────────────────┐
         │  审慎层         │                   │  反应层         │
         │  ~30% 共和制    │                   │  ~40% 宪政      │
         │                 │                   │                 │
         │  Planner 规划   │                   │  状态机硬编码    │
         │  ModelPool 自选 │                   │  Gateway 门控   │
         │  IDMM 模型绕过  │                   │  IDMM 策略规则   │
         │  Fail-open      │                   │  Crash 治理      │
         └─────────────────┘                   └─────────────────┘

这一发现至关重要：NomiFun 并非三种元素的随机混合，而是按架构层级有规律地分布：

• 反应层（毫秒级安全约束）→ 宪法控制面主导 — 确定性、不可绕过
• 审慎层（任务规划与执行）→ 运行时共和制主导 — 动态性、可适应
• 组织层（多 Agent 协调）→ 全新维度 — 两种经典哲学都不覆盖

5. 综合判定：Agent 联邦制

5.1 为什么不是"混合"而是"新物种"

5.2 类比：美国联邦制

5.3 核心命题

NomiFun 的架构创新不在于"混合了两种哲学"，而在于引入了第三种维度：Agent 的组织层。Agent 联邦制将单个 Agent 的治理从两方（规则 vs 自由）扩展为三方（宪法约束 + 运行时适应 + 组织级协作），形成了一个可递归、可扩展的 Agent 治理层次结构。

6. NomiFun 架构的三个运作层面

6.1 反应层（Reactive Layer）：宪法控制面主导

职责：毫秒级安全保护，阻止不可逆操作

组成：

• Gateway 三维可见性门控（profile × surface × tier）
• IDMM PermissionRule（safe/risky 硬权限）
• 破坏性命令模式匹配（rm -rf / DROP TABLE 等）
• RuntimeRegistry 崩溃循环治理
• 容量硬限制（MAX_PARALLEL、MAX_DEPTH 等）

哲学特征：

• 代码枚举而非运行时协商
• 拒绝规则不可绕过（硬编码、类型系统强制执行）
• 与宪法控制面（Codex）完全一致

6.2 审慎层（Deliberative Layer）：运行时共和制主导

职责：任务规划、模型选择、执行决策

组成：

• Planner 从 goal + participants 动态生成 plan
• ModelPool Automatic 运行时选择最优模型
• IDMM OptionRule / OpenQuestionRule 模型级灵活处理
• Adaptation Policy 执行时调整
• Step kind（verify / judge / loop）运行时决定

哲学特征：

• 自然语言提示词驱动 Agent 行为
• 模型推理参与决策（IDMM RulePlusModel）
• 允许运行时绕过纯规则
• 与运行时共和制（Claude Code）一致

6.3 组织层（Organizational Layer）：全新维度

职责：多 Agent 协调、任务编排、元监督

组成：

• DAG 参与者系统：多实体加入执行
• 内容寻址委派：幂等性保证的跨 Agent 呼叫
• IDMM 双路 + 元监督：监督者也被监督
• AutoWork 自治工作循环：Agent 自动接任务
• Cron 定时自治：无人值守的周期性行为
• 跨会话消息注入（MCP 工具）
• 网关作为联邦边界

哲学特征：

• 两种经典哲学都没有的维度
• Agent 间关系由联邦协议而非单体规则管理
• 分权制衡——规划、执行、监督分离
• 可递归——联邦可以包含子联邦

7. 关键创新机制详解

7.1 内容寻址委派（Content-Addressed Delegation）

NomiFun 的委派系统不是简单的"调用子 Agent"，而是通过 SHA256 哈希语义操作来生成幂等 ID：

goal = "分析系统配置"
delegator = "conv_xxx"
strategy = "automatic"
adapt = "default"

→ SHA256("analysis system config|conv_xxx|automatic|default")
→ id = "0x4a8f..."

重要性：这解决了分布式系统中的根本难题——一次且仅一次执行语义。如果网络分区导致确认丢失，重试时相同操作会解析到已有步骤而非创建重复。

7.2 IDMM 的 Constitutional 元层

IDMM 不仅仅是"监督模块"，它是一个自指的宪法系统：

                          ┌──────────────────────┐
                          │  Constitution          │
                          │  (IDMM Policy Types)   │
                          └──────┬───────────────┘
                                 │ interprets
                          ┌──────▼───────────────┐
                          │  Judiciary            │
                          │  (IDMM Supervisor)    │
                          │  dual-watch + escal.  │
                          └──────┬───────────────┘
                                 │ supervises
                          ┌──────▼───────────────┐
                          │  Executive            │
                          │  (Agent Execution)    │
                          │  Planner/Scheduler    │
                          └──────┬───────────────┘
                                 │ but also...
                          ┌──────▼───────────────┐
                          │  IDMM can be          │
                          │  SUPERVISED by        │
                          │  higher-tier IDMM     │
                          │  (元监督, 递归)       │
                          └──────────────────────┘

IDMM 本身也可以被监督（通过更高层级的 IDMM 配置），实现可递归的宪法执行。

7.3 Fail-Open 与优雅降级

NomiFun 在多个层面实现了优雅降级：

这与宪法控制面的"失败时禁用"哲学形成鲜明对比——NomiFun 选择部分降级而非完全停止。

7.4 三层分离的三权分立

┌─────────────────────────────────────────────────────┐
│               Agent 联邦制权力结构                     │
├─────────────────────────────────────────────────────┤
│                                                      │
│  ┌────────────────────┐  ┌────────────────────┐     │
│  │  立法权             │  │  司法权             │     │
│  │  IDMM Policies     │  │  IDMM Supervisor   │     │
│  │  IDMM Config       │  │  decision_watch    │     │
│  │  Gateway Security  │  │  escalation ladder │     │
│  └────────────────────┘  └────────────────────┘     │
│                                                      │
│  ┌──────────────────────────────────────────────┐   │
│  │  行政权                                      │   │
│  │  Agent Execution Engine                     │   │
│  │  Planner → Scheduler → AttemptRunner        │   │
│  └──────────────────────────────────────────────┘   │
│                                                      │
└─────────────────────────────────────────────────────┘

关键设计决策：规划者、执行者和监督者不是同一个进程。Planner 不与 IDMM 共享代码路径，Gateway 不与引擎共享安全策略——故障无法跨越权力边界传播。

8. 风险、张力与演化方向

8.1 内部张力

8.2 架构风险

1. 宪法漏洞：IDMM PermissionRule 和 OptionRule 的交互可能导致未被预期的行为——规则定义中的矛盾
2. 联邦边界模糊：Gateway 作为联邦边界，但当 MCP 服务器绑定到错误会话时（如本次分析中的 conv_019f831d），边界可能被绕过
3. 可递归复杂性的非线性增长：Agent 执行 DAG 的最大深度为 4，但如果每个 Agent 又可以委派，实际的监督嵌套可能难以预测
4. Fail-Open 的安全代价：DB 写入失败不阻塞，这意味着在某些故障模式下安全事件可能丢失
5. 状态机完整性问题：状态转换虽然有 CAS 保证，但从 7 态和 8 态状态机的转移矩阵来看，是否存在"不可能达到"或"永冻"状态？

8.3 可能演化方向

现在 ────────────────────────────────────────────→ 未来

Agent 联邦制          提升宪法一致性         分布式自治联邦
┌──────────┐         ┌──────────┐         ┌──────────┐
│ 单体联邦  │ ──────→ │ 结构化宪法 │ ──────→ │ 正式宪法  │
│ 隐式规则  │         │ IDMM 2.0  │         │ 可证明安  │
│ 经验式    │         │ 形式化策略 │         │ 全性      │
└──────────┘         └──────────┘         └──────────┘

方向 A — 提升宪法一致性：将 IDMM 策略从 Rust 枚举升级为形式化策略语言（类似于 Open Policy Agent 的 Rego），使规则可组合、可证明、可审计。

方向 B — 强化共和制弹性：增加更多运行时协商机制，如 Agent 间冲突解决协议、动态模型切换策略（非预设 Range）。

方向 C — 联邦自治化：引入 Agent 联邦之间的自治协议，使联邦可以包含子联邦（目前 MAX_DEPTH=4 限制了递归深度）。

9. 三方研究交叉验证：本地代码分析 + 深度网络研究 + 架构哲学对比

本章整合 方法 3（深度网络研究） 的外部发现与本报告已有分析，揭示每项发现如何在三种方法间交叉验证。

9.1 方法 3 概述：网络视角的 NomiFun

9.2 三方交叉验证矩阵

9.3 方法 3 的独有发现（CodeGraph 无法覆盖的视角）

以下发现仅通过网络研究获得，源码树或本地配置无法独立验证：

9.4 方法 3 独有的结构性发现

9.4.1 三种门面（Facades）设计

方法 3 揭示了 Gateway 的三种公开暴露面，深化了我们对 server.rs 的理解：

→ 联邦制的核心基础设计：同一个能力总线通过三种门面暴露给不同粒度、不同安全需求的联邦成员。

9.4.2 "Config Once, Use Anywhere"范式

"知识库、技能、agent、MCP 服务器、模型在中央枢纽定义一次，然后按对话/终端/渠道/伴侣选择复用。"

这解释了为何 MCP 服务器绑定到特定会话（我们在本地配置中发现的 conv_019f831d 现象）——该绑定是会话级选用，而非故障。它甚至是联邦制"可复用资产"的故意设计。

9.4.3 ACP 作为联邦入盟协议

方法 3 揭示了 ACP（Agent Client Protocol） 作为外部 Agent 加入联邦的门户。约 19 个外部 Agent（Claude Code、Codex、Gemini、Cursor、Copilot 等）通过此协议获取 NomiFun 的能力。

→ 这回答了我们在源码分析中的一个关键问题：Gateway 的 ACP 桥接服务于谁？——服务于独立的、异构的联邦成员。

9.5 修正与补充

9.6 联合分析的重要结论

三方研究的最大验证：NomiFun 的"Agent 联邦制"不仅在内部一致（源码→配置→模式），在外部也成立——竞品中没有同类架构。

结论在竞品对比中得到强化：8 个同类项目中，没有一个是"能力总线 + 本地优先 + 开放 Agent 联邦"的组合。NomiFun 作为第三个 Agent 治理维度的唯一代表，其联邦制定位是差异化核心。

10. 结论与建议

10.1 最终判定

NomiFun 是 Agent 联邦制（Agent Federalism）——一个在 Agent 架构分类中的新物种。

10.2 NomiFun 与两种经典哲学的关键差异

10.3 建议

1. 对架构师：关注宪法漏洞风险——IDMM 规则与模型推理的交互边界需要更严格的测试覆盖
2. 对安全团队：检查 Gateway 会话绑定策略，确保 MCP 工具不能被未授权会话访问
3. 对 AI 研究者：Agent 联邦制揭示了从"单体智能"到"组织化智能"的架构过渡——DAG 参与者系统和内容寻址委派是这一过渡的核心技术
4. 对平台开发者：考虑将 IDMM 策略从枚举硬编码升级为可插拔策略引擎，支持运行时策略热加载

10.4 有待探索的领域

• 🚧 未详细分析的 crate：workshop、creation、companion、channel、realtime
• 🚧 未深入探索的协议：ACP 协议细节、Gateway 与 MCP 的端口分配策略
• 🚧 未验证的假设：MAX_DEPTH=4 在实际中是否足够？
• 🚧 未运行的实际观察：IDMM 在真实使用中的干预频率和模式

本报告基于 CodeGraph 源码知识图谱、系统配置检查、深度网络研究、知识库哲学框架四项独立研究的联合分析。 分析目标：nomifun-tauri（v0.2.30），CodeGraph 索引 2,492 文件 / 58,278 节点 / 224,391 边。 方法 3 数据来源：nomifun_research.md（其他研究会话的深度网络分析）。 生成日期：2026-07-22