「强个体 + 简单连接」优于「弱个体 + 复杂调度」

—— 这是蚁群、蜂群和人脑已经验证了亿万年的架构模式。

一段真实日志

# 节点 A (7700): capabilities=["browser","node"]  — 没有计算能力
# 节点 B (7701): capabilities=["calc"]             — 有计算技能

$ curl -X POST http://127.0.0.1:7700/task \
  -d '{"id":"test-001","description":"计算 1+1",
       "context":{"required_capabilities":["calc"]}}'

# 节点 A 日志:
Routing: FORWARD to peer  peer_addr=10.55.157.245:7701  required=["calc"]
Forwarding task to peer  attempt=1

# 节点 B 日志:
Routing: LOCAL (capabilities match)  local_caps=["calc"]
Task received, executing locally...
Sandbox execution start  level=Level3  mode=Sandbox isolation + static code scanning
Task completed  elapsed_ms=91819

# 客户端收到:
{"task_id":"test-001","response":"计算器结果：1 + 1 = 2.0 ✅","task_completed":true,"tool_calls":1}

没有中心调度器、没有队列、没有服务注册中心。两个独立节点通过 mDNS 自动发现彼此，通过能力标签自动路由任务，在 OS 级沙箱里安全执行，返回结果。整个过程零配置。

这就是本文要阐述的架构：自进化的极致单体 + 弹性 P2P 集群。

一、问题：当前多 Agent 架构的困境

2024–2026 年，多 Agent 协作（Multi-Agent）成为 AI 应用架构的热门方向。AutoGen、CrewAI、LangGraph 等框架纷纷提出各自的多 Agent 编排方案。但实践中暴露出三个系统性问题：

1.1 弱个体 + 复杂调度 = 脆弱系统

多数框架将复杂性放在调度层：Router Agent 解析意图、Planner Agent 拆分任务、Worker Agent 执行、Critic Agent 审查……每个 Agent 本身能力有限，系统可靠性取决于编排链路中最薄弱的环节。一旦 Router 误判意图，整条链路崩溃。

1.2 无法离线、无法断网运行

依赖中心化调度器或消息队列的架构，在断网、边缘设备、隐私场景下无法工作。而现实中，开发者笔记本断网、企业内网隔离、嵌入式设备离线，都是高频场景。

1.3 没有进化能力

几乎所有多 Agent 框架都是静态的：Agent 的能力在部署时确定，运行时不会变强。用户重复执行同类任务 100 次，第 101 次不会更快更准。系统不学习、不记忆、不成长。

---

二、核心论点：强个体优先

我们提出的架构可以用一句话概括：

先把一个节点做到极致（全能 + 安全 + 自进化），再用最简单的协议把它们连起来。

这不是凭空设计的。生物界的分布式智能系统——蚁群、蜂群、人脑神经元——无一例外遵循这个模式：

生物系统	个体能力	连接方式	涌现结果
蚁群	单蚁可独立觅食、筑巢、战斗	信息素（化学广播）	超个体智能
蜂群	单蜂可采蜜、建巢、导航	摇摆舞（简单信号）	精确集体决策
人脑	单神经元可独立放电	突触（电化学脉冲）	意识

关键观察：个体越强，连接协议越简单，涌现的集体智能越高。 反之，如果个体太弱（如简单的 if-else 节点），就需要极复杂的编排逻辑来弥补，系统变得脆弱且难以扩展。

---

三、架构总览

Skilllite 的安全自进化架构则是基于上述的思考而构建的，聚焦单个体的安全进化（除了Brain，Core，Sandbox）不可进化，其余皆可进化；

分为两层：极致单体（垂直深度）和 弹性集群（水平广度）。

---

四、极致单体：一个节点要多强？

4.1 Agent Loop：规划 → 执行 → 反思

不是简单的「LLM 调工具」循环，而是完整的认知架构：

规划阶段 (Planning)

• 加载 SOUL 身份文档（不可变的角色、信念、行为边界）

• 提取 Goal Boundaries（正则 + 可选 LLM 分析）

• LLM 生成任务列表，注入 Planning Rules（从历史经验学来的规则）

• 支持断点续跑（Run Checkpoint --resume）

执行阶段 (Execution)

• 批量工具调用，渐进式披露结果

• 每任务调用深度限制，防止无限循环

• 动态调整计划（update_task_plan），应对执行中的意外

• 连续失败达上限时主动停止，而非盲目重试

反思阶段 (Reflection)

• Anti-hallucination Nudge：检测 LLM「声称完成但未调用任何工具」的幻觉

• 自动 Nudge：有未完成任务时推送继续执行

• Context Overflow 恢复：检测并截断超长上下文，避免 token 爆炸

这个三阶段循环保证了单节点的自主性：不需要外部编排器告诉它下一步做什么。

4.2 三维自进化引擎

这是整个架构最核心的差异化能力。进化引擎在三个维度上让节点「越用越强」：

进化维度               │  产物                 │  安全约束
───────────────────────┼───────────────────────┼──────────────────
Prompts（提示进化）    │  rules.json           │  L2: 单次 ≤5 规则
                       │  examples.json        │  L3: 禁止敏感模式
───────────────────────┼───────────────────────┼──────────────────
Memory（记忆进化）     │  MEMORY.md            │  L1: 路径白名单
                       │  SQLite FTS5          │  本地存储、不外泄
───────────────────────┼───────────────────────┼──────────────────
Skills（技能进化）     │  SKILL.md + 脚本      │  L4: 静态扫描
                       │  _evolved/_pending/   │  A10: 人工确认
                       │                       │  L3: 沙箱执行

Skill Synth（技能合成） 是进化引擎的核心：

• Generate（生成）：从成功/失败经验中识别重复模式，生成新技能

  • 成功驱动：高成功率的重复操作 → 固化为可复用 Skill

  • 失败驱动：持续失败的能力缺口 → 合成补全 Skill

• Refine（精炼）：失败的 Skill → 分析错误 → LLM 修复 → 重试（最多 2 轮）

• Retire（退役）：低成功率或长期未用的 Skill → 归档

Prompt Learner（提示学习） 从执行历史中提取规划规则：

• 哪些任务拆分策略效果好？→ 写入 rules.json，下次规划时注入

• 哪些示例能帮助 LLM 理解？→ 写入 examples.json

进化触发机制：不是随时进化，而是基于条件触发——

• 未处理决策数超过阈值

• 失败率超过阈值

• 检测到重复模式

• should_evolve() 函数综合判断

关键设计：新合成的 Skill 不会立即启用，而是进入 _evolved/_pending/ 待确认区。用户通过 skilllite evolution confirm 明确批准后才加入正式技能库。这是人机共治的进化，不是失控的自我复制。

4.3 五层 Gatekeeper：进化的安全护栏

自进化系统最大的风险是「进化失控」—— Agent 修改自己的代码、注入恶意逻辑、泄露敏感数据。五层 Gatekeeper 解决这个问题：

层级	守护内容	机制
L1 路径白名单	进化只能写入 prompts/、memory/、skills/_evolved/	硬编码路径检查
L1b 模板完整性	占位符不被破坏	正则校验
L2 变更规模	单次进化最多 5 条规则、3 个示例、1 个技能	数量限制
L3 内容安全	禁止 api_key、secret、eval 等敏感模式	正则 + 模式匹配
L4 静态扫描	进化生成的脚本执行前扫描	规则引擎 + 熵检测 + Base64 检测

加上 OS 级沙箱（macOS Seatbelt / Linux bwrap+seccomp），形成「进化在笼子里发生」的安全模型。

4.4 SOUL：不可变的身份锚点

SOUL 文档定义了节点的身份（Identity）、信念（Core Beliefs）、行为边界（Will Do / Will Not Do）。关键约束：

• SOUL 只读：Agent 无法修改自己的 SOUL

• 边界注入：规划阶段将「Will Not Do」注入系统提示，LLM 生成的计划不得违反

• SOUL 不进化：三维进化（Prompts/Memory/Skills）不触碰 SOUL

这保证了一个哲学层面的安全性：节点可以变强，但不能变坏。

---

五、弹性集群：最简单的连接协议

5.1 设计哲学：三件事就够

组网层只做三件事，不多也不少：

功能	实现	复杂度
发现：谁在网络上？	mDNS（_skilllite-swarm._udp.local.）	零配置
路由：谁能做这个任务？	能力标签匹配 + 广播竞价	极简
同步：新学到的技能共享给谁？	Gossip 协议广播 NewSkill	待实现

没有 Leader 选举、没有共识算法、没有分布式事务。因为不需要。

5.2 零配置发现

每个节点启动时通过 mDNS 广播自己的能力标签：

Service: _skilllite-swarm._udp.local.
TXT: capabilities=["calc","math"]
Address: 10.55.157.245:7701

同网段的其他节点自动发现，无需手动配置任何注册中心。

5.3 标签匹配路由

路由逻辑极其简单，用一棵决策树就能表达：

收到 NodeTask(required_capabilities=["calc"])
  │
  ├─ 本地有 "calc" 标签？
  │   └─ Yes → 本地执行 (RouteTarget::Local)
  │
  ├─ 已知 peer 有 "calc" 标签？（mDNS 缓存）
  │   └─ Yes → 转发给该 peer (RouteTarget::Forward)
  │
  ├─ 广播「谁能做 calc」给所有 peer？（GET /can-do?required=calc）
  │   └─ 有人回复 can_do:true → 转发 (RouteTarget::Forward)
  │
  └─ 无人响应 → NoMatch（503）

为什么不用更复杂的路由？

• 不做负载均衡：Phase 3 阶段，能接就接。复杂的负载感知在节点数 < 100 时收益极低。

• 不做竞价拍卖：简单的标签匹配已覆盖 90% 场景。竞价是未来可选升级。

• 不做一致性哈希：任务无状态，不需要固定路由到同一节点。

5.4 蜂群技能共享

一个特别的路由策略：当 required_capabilities 为空时（用户只描述了任务，没有指定需要什么能力），系统会：

1. 如果本地有能力标签 → 本地执行

2. 如果本地无能力标签，但 peer 有 → 转发给有能力的 peer

这实现了「蜂群共享技能」—— 一个空节点加入网络后，不需要自己拥有任何技能，就可以通过转发利用整个集群的能力。类似蜂群中新加入的工蜂，通过摇摆舞获知蜜源位置。

5.5 优雅降级

断网、无 peer、peer 全部挂掉时：

• 不挂死：超时 5 秒后回退本地执行

• 不报错：本地执行可能能力不足，但至少尝试

• 不依赖：swarm 功能通过 Cargo feature flag 可选，--features swarm 才编译

单节点永远可以独立工作。 组网只是增强，不是依赖。

---

六、为什么这么架构？—— 设计决策推演

6.1 为什么不用中心化调度？

方案	优点	致命缺点
中心化调度器（如 K8s + 消息队列）	全局最优调度、易监控	单点故障、无法离线、运维复杂
去中心化 P2P	无单点、可离线、零运维	无全局视图、路由可能次优

对于 AI Agent 场景，可离线 和 零运维 的优先级远高于「全局最优调度」。开发者不会为了让 AI 助手多 Agent 协作而去部署一套 Kafka + K8s。

6.2 为什么先进化后组网，而不是反过来？

如果先实现组网再考虑进化：

• 每个节点是静态的 → 组网只是「同样弱的节点多了几个」→ 1 + 1 < 2

• 进化需要跨节点协调 → 分布式进化的复杂度爆炸

如果先实现进化再组网：

• 每个节点已经很强 → 组网产生「强强联合」→ 1 + 1 > 2

• 进化在本地完成 → 组网只需传递 NewSkill → 简单

先进化后组网，让复杂度集中在单节点内部，组网层保持极简。

6.3 为什么进化产物需要人工确认？

完全自主进化（无人审核）的风险：

Agent 执行任务失败
  → 进化引擎合成新 Skill
    → 新 Skill 包含 curl 外泄数据的逻辑
      → Gatekeeper L3/L4 可能漏判
        → 恶意 Skill 被永久安装

A10（待确认 Skill）的设计：_evolved/_pending/ 是一个缓冲区。新 Skill 在这里等待，用户通过 skilllite evolution confirm 审批后才进入正式库。这是「人机共治」—— 机器负责创造，人类负责把关。

6.4 为什么不可变内核 + 可变数据层？

借鉴操作系统设计：内核（Brain/Core/Sandbox）是不可变的，可变的只有数据层（Prompts/Memory/Skills）。

• 不可变内核：agent_loop、evolution engine、sandbox 的代码逻辑不被进化修改

• 可变数据层：进化只修改 prompts/、memory/、skills/_evolved/

这确保了：

• 进化不会破坏核心执行逻辑

• 回滚简单：删除进化产物即可恢复

• 审计清晰：所有进化变更都有 txn_id 可追溯

---

七、优劣势分析

7.1 优势

优势	说明
反脆弱	单节点全能 → 断网时仍可独立工作；节点故障不影响集群。系统在压力下变强（通过进化）
线性扩展	加一个节点 = 加一份能力。没有协调开销随节点数指数增长的问题
越用越强	三维自进化 → 用得越多，规则越精准、记忆越丰富、技能越完善
零运维	mDNS 零配置发现，无注册中心、无消息队列、无数据库依赖
隐私安全	记忆和进化产物本地存储，不外泄。沙箱 + Gatekeeper 约束进化行为
渐进式采用	先用单节点（已经很强），有需要再启用 swarm（--features swarm），不强制

7.2 劣势

劣势	说明	缓解措施
无全局最优调度	P2P 路由基于标签匹配，可能不是最优分配	未来可选竞价机制；当前节点数少时影响可忽略
mDNS 局限	仅限同网段；跨网段需 Libp2p Kademlia	长期路线：Phase 5 引入 Kademlia
进化质量依赖 LLM	Skill Synth 和 Prompt Learner 的质量受 LLM 能力限制	5 层 Gatekeeper + 人工确认兜底
冷启动	新节点无记忆无技能，初始能力有限	蜂群共享技能 + NewSkill Gossip（技能同步）
行业共识缺失	「自进化 + P2P」尚未形成主流范式	技术逻辑自洽；若多 Agent 协作成为主流，先发优势明显
单体复杂度	极致单体意味着单节点代码量大（~41,500 行 Rust）	分层清晰（core→sandbox→executor→agent），模块边界 8/10

7.3 与主流方案对比

维度	中心化编排（AutoGen/CrewAI）	MCP 工具扩展	自进化 + 弹性集群
单节点能力	弱（角色固定）	中（工具可扩展）	强（全能 + 自进化）
多节点协作	强（中心调度）	无	中（P2P 标签路由）
离线能力	无	有	有
进化能力	无	无	三维自进化
安全模型	弱（信任所有 Agent）	中（工具权限）	强（5 层 Gatekeeper + OS 沙箱）
运维成本	高	低	零
复杂度位置	调度层	工具层	单节点内部

---

八、从日志看架构的运行效果

回到开头的日志，逐行解读架构如何工作：

# 1. 零配置发现
Peer discovered via mDNS  peer=...  addr=10.55.157.245:7701  capabilities=["calc"]

→ 节点 A 通过 mDNS 自动发现节点 B，获知其能力标签 ["calc"]。无需配置。

# 2. 标签匹配路由
Routing: FORWARD to peer  peer_addr=10.55.157.245:7701  required=["calc"]

→ 客户端向 A 发送需要 calc 能力的任务。A 本地无此能力，查到 B 有，决定转发。

# 3. 安全沙箱执行
Sandbox execution start  level=Level3  mode=Sandbox isolation + static code scanning

→ B 在 OS 级沙箱（macOS Seatbelt）中执行任务，同时做静态代码扫描。计算逻辑被隔离在沙箱内。

# 4. 结果返回
Task completed  elapsed_ms=91819
{"task_id":"test-001","response":"计算器结果：1 + 1 = 2.0 ✅","task_completed":true}

→ 结果通过标准 NodeResult 格式返回给 A，A 透传给客户端。整个过程对客户端透明。

整个链路：客户端 → A(路由) → B(沙箱执行) → A(透传) → 客户端。零配置、安全隔离、能力匹配。

---

九、未来演进

阶段	时间	目标
当前	已完成	极致单体（Agent Loop + 三维进化 + 五层 Gatekeeper + OS 沙箱）+ P2P 基础路由
Phase 4	近期	NewSkill Gossip —— 一个节点进化出新技能，自动同步给集群
Phase 5	中期	Libp2p Kademlia 替代 mDNS，支持跨网段发现
Phase 6	远期	可选竞价机制 —— 多节点都能做时，选「最擅长的」而非「第一个响应的」

最值得期待的是 Phase 4（NewSkill Gossip）：节点 A 在执行任务过程中进化出一个新技能，通过 Gossip 协议广播给集群中所有节点。接收方在沙箱中验证后入库。这意味着一个节点的进化，是整个集群的进化。 蜂群中一只蜜蜂发现了新蜜源，通过摇摆舞告诉所有同伴。

---

十、结语

这个架构赌的是一个判断：AI Agent 的未来不是更复杂的编排，而是更强的个体。

编排的复杂度有上限（人类的理解力和调试能力），但个体的进化没有上限。当每个节点都能自主规划、执行、反思、进化，并且在安全约束下持续变强时，它们之间只需要最简单的连接——「谁能做？」「我来。」——就能涌现出超越任何中心化调度器能安排的集体智能。

蚁群已经这样做了一亿年。

---

基于 SkillLite 项目（~41,500 行 Rust）的架构分析与实践。2026-03-06。

持续输出实战经验和思考，欢迎star和交流