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

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

一段真实日志

# 节点 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_keysecreteval 等敏感模式

正则 + 模式匹配

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和交流

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐