DEV Community: llimage

FROST-SOP 源码解读：3个核心模块的工程精髓

llimage — Thu, 02 Jul 2026 03:25:44 +0000

FROST-SOP 源码解读：3个核心模块的工程精髓

作者：FROST Team

日期：2026-07-02

主题：代码教程 | 周四轮换

前言

FROST-SOP 是 FROST 思想的开花结果——一个面向工程实践的 AI Agent 生产平台。

本文从源码出发，解读三个核心模块的设计精髓：

Agent 生命周期管理：如何让 Agent "生有所依，死有所终"
向量记忆系统：ChromaDB 集成的优雅降级设计
事件驱动架构：松耦合的异步通信机制

这三个模块代表了 FROST-SOP 的工程哲学：可观测、可治理、可追溯。

一、Agent 生命周期管理：从生到死的完整闭环

1.1 为什么生命周期重要？

传统的 Agent 实现往往忽略生命周期管理：

Agent 创建后状态未知
运行中无法追踪
失败后资源不释放

FROST-SOP 的 Agent 类（core/agent.py）实现了完整的生命周期：

class Agent:
    def __init__(self, name: str = None, store: Store = None, skills: dict = None,
                 sop_steps: list = None, generation: int = 0,
                 max_spawn_generation: int = None,
                 retry_config: Dict = None,
                 on_max_retries: Optional[Callable] = None,
                 event_driven: bool = False):

        # 生命周期状态追踪
        self._status: str = "idle"          # idle / running / destroyed
        self._created_at: datetime = datetime.now()
        self._destroyed_at: Optional[datetime] = None

        # V2.0: 发布 AGENT_CREATED 事件
        if self._event_driven:
            self._publish_event("agent_created", {
                "agent_name": self.name,
                "generation": self.generation,
            })

关键设计：

_status 三态机：idle → running → destroyed
时间戳记录：created_at + _destroyed_at
事件驱动：可选的事件通知机制

1.2 run() 方法：任务的执行与守护

def run(self, sop_steps: list, initial_context: dict = None) -> dict:
    """核心执行循环"""
    context = dict(initial_context) if initial_context else {}

    # 任务开始：写入状态
    self._status = "running"
    self._write_agent_status("running", context.get("_task_id", ""))

    try:
        for step in sop_steps:
            step_result = self._execute_step_with_retry(step, context)
            if not step_result["success"]:
                break
            context = step_result["context"]

            if self._event_driven:
                self._publish_event("step_completed", {...})
    finally:
        # 确保销毁，防止资源泄漏
        self.destroy()

    return context

亮点设计：

try-finally 确保 destroy() 必执行
步骤级重试机制（P0-2 自修复）
事件驱动可插拔

1.3 destroy() 方法：优雅的资源释放

def destroy(self):
    """销毁 Agent"""
    if self._status == "destroyed":
        return  # 防止重复销毁

    self._status = "destroyed"
    self._destroyed_at = datetime.now()

    # 写入生命周期记录
    self._write_agent_status("destroyed", "")

    # 发布销毁事件
    if self._event_driven:
        self._publish_event("agent_destroyed", {...})

    # 释放资源
    self._cleanup()

设计原则：

幂等性：destroy() 可安全重复调用
审计友好：每次状态变更都有时间戳
资源隔离：清理临时数据，保留审计数据

1.4 自修复重试机制

def _execute_step_with_retry(self, step, context, step_records) -> dict:
    """带重试的步骤执行"""
    for attempt in range(1, self._max_retries + 1):
        try:
            if isinstance(step, str):
                new_context = self.skills[step].execute(dict(context))
            elif isinstance(step, Agent):
                new_context = step.run(step._sop_steps, dict(context))

            step_records.append({"step": step_name, "success": True, "retries": attempt - 1})
            return {"success": True, "context": new_context}

        except Exception as e:
            if attempt == 2 and isinstance(step, str):
                alt_step = self._find_alternate_skill(step)
                if alt_step:
                    step = alt_step

            if attempt < self._max_retries:
                time.sleep(self._retry_delay_seconds)
            else:
                if self._on_max_retries:
                    self._on_max_retries(max_retries, step_name, e)

二、向量记忆系统：优雅降级的工程美学

2.1 为什么需要优雅降级？

向量数据库（如 ChromaDB）是强大的记忆工具，但在生产环境中可能：

依赖缺失
服务不可用
网络超时

FROST-SOP 的 MemoryStore（core/memory.py）实现了优雅降级：

class MemoryStore:
    def __init__(self, agent_id: str, persist_directory: str = CHROMADB_DIR):
        self.agent_id = agent_id
        self.fallback_mode = False  # 降级模式标志
        self._init_chromadb()
        self._memory_keywords = []

    def _init_chromadb(self):
        """初始化 ChromaDB"""
        try:
            import chromadb
            self.chroma_client = chromadb.PersistentClient(
                path=self.persist_directory,
                settings=Settings(allow_reset=True, anonymized_telemetry=False)
            )
            self.collection = self.chroma_client.get_or_create_collection(
                name=self.collection_name,
                metadata={"agent_id": self.agent_id}
            )
        except Exception as e:
            logger.warning(f"ChromaDB 初始化失败，使用降级模式: {e}")
            self.fallback_mode = True

2.2 统一接口的降级实现

def search_memory(self, query: str, top_k: int = 5) -> List[Dict]:
    if self.fallback_mode:
        # 降级模式：关键词匹配
        query_words = set(query.lower().split())
        results = []
        for mem in self._memory_keywords:
            text_words = set(mem["text"].lower().split())
            overlap = len(query_words & text_words)
            if overlap > 0:
                results.append({
                    "id": mem["id"],
                    "text": mem["text"],
                    "score": overlap / len(query_words)
                })
        results.sort(key=lambda x: x["score"], reverse=True)
        return results[:top_k]

    # ChromaDB 模式
    return self.collection.query(query_texts=[query], n_results=top_k)

设计精髓：

统一接口：调用方无需关心底层实现
降级透明：功能可用，只是精度降低
自动恢复：ChromaDB 恢复后自动切换

2.3 单例模式的记忆存储

_memory_stores = {}  # 全局缓存

def get_memory_store(agent_id: str) -> MemoryStore:
    """获取记忆存储（单例模式）"""
    if agent_id not in _memory_stores:
        _memory_stores[agent_id] = MemoryStore(agent_id)
    return _memory_stores[agent_id]

三、事件驱动架构：松耦合的异步通信

3.1 事件总线的设计

class Event:
    def __init__(self, event_type: str, source: str, data: dict):
        self.event_type = event_type
        self.source = source
        self.data = data
        self.timestamp = datetime.now()


class EventBus:
    def __init__(self):
        self._subscribers: Dict[str, List[Callable]] = defaultdict(list)

    def subscribe(self, event_type: str, handler: Callable):
        self._subscribers[event_type].append(handler)

    def publish(self, event: Event):
        for handler in self._subscribers.get(event.event_type, []):
            try:
                handler(event)
            except Exception as e:
                logger.error(f"事件处理失败: {e}")

3.2 Agent 中的事件集成

def _publish_event(self, event_type: str, data: dict) -> None:
    """向 EventBus 发布事件"""
    try:
        from core.event_bus import get_event_bus, Event
        bus = get_event_bus()
        bus.publish(Event(
            event_type=event_type,
            source=self.name or "unknown_agent",
            data=data,
        ))
    except Exception as e:
        # 事件发布失败不影响主流程
        logger.warning("事件发布失败: %s", e)

设计原则：

失败隔离：try-except 确保主流程不受影响
异步可选：通过 event_driven 标志控制
类型安全：预定义事件类型常量

四、工程设计原则总结

设计模式	应用场景	价值
生命周期管理	Agent 状态追踪	可观测、可调试
幂等性设计	destroy() 重复调用	防错、安全
优雅降级	ChromaDB 不可用	韧性、可用性
单例模式	记忆存储缓存	性能、资源复用
事件驱动	组件解耦	灵活性、可扩展
失败隔离	事件发布	健壮性

五、实战：5分钟跑起 FROST-SOP

# 1. 克隆仓库
git clone https://gitee.com/liao_liang_7514/frost-sop.git
cd frost-sop

# 2. 安装依赖
pip install -r requirements.txt

# 3. 运行测试
pytest extracted/tests/ -v

# 4. 启动 API 服务
python -m extracted.api.main

快速验证记忆系统

from core.memory import MemoryStore, get_memory_store

# 创建记忆存储
memory = get_memory_store("my_agent")

# 添加记忆
id1 = memory.add_memory(
    "完成 Python 项目开发",
    {"project": "FROST-SOP", "type": "task"}
)

# 搜索记忆
results = memory.search_memory("Python 开发", top_k=3)
print(results)

结语

FROST-SOP 的代码不是炫技，而是工程严谨性的体现：

生命周期管理：让 Agent 有始有终
优雅降级：让系统在逆境中依然可用
事件驱动：让组件之间松耦合、易演进

这三个设计贯穿整个框架，是 FROST"可治理、可继承、可审计"理念的技术支撑。

从思想到工程：FROST 与 FROST-SOP 的双生之旅

llimage — Wed, 01 Jul 2026 03:24:52 +0000

从思想到工程：FROST 与 FROST-SOP 的双生之旅

你知道吗？每一个伟大的工程背后，都有一个简单而深刻的起点。

引言：从 500 行到 5000 行的演进

在开源世界里，我们见过太多"大而全"的框架——它们功能丰富，却让人望而生畏。今天我想分享一个反其道而行之的项目：FROST。

FROST（Fractal Runtime of Orchestrated Skills & Tasks）最初只是一个 500 行的教学框架，用最朴素的代码讲述 Agent 的本质。它的核心哲学只有一句话：

细胞会死，但谱系会存续。Agent 会消亡，但宪法会传承。资产会永存。

而今天我要介绍的，是 FROST 思想"开花结果"后的工程实践——FROST-SOP，一个拥有 5000+ 行代码的完整 Agent 工程平台。

FROST：理解 Agent 的钥匙

FROST 不是什么复杂的框架。它的设计哲学是最小原子集 + 分形宪法：

四个原子，理解一切

原子	职责	生物学类比
Store	记忆容器，只做 save/load/delete	细胞核
Skill	纯能力单元，无状态无副作用	蛋白质
Agent	膜包裹的细胞，拥有 Store + Skills	神经细胞
SOP	有序步骤列表，可教学、校验、优化	宪法文本

from core import Store, Agent, skill_set, skill_get

store = Store()
agent = Agent("cell", store, skills={
    "set_context": skill_set,
    "get_context": skill_get
})

result = agent.run(
    sop_steps=["set_context", "get_context"],
    initial_context={"key": "message", "value": "FROST is alive"}
)
# result["_result"] == "FROST is alive"

5 行代码，你就能理解整个 Agent 系统的运作原理。这就是 FROST 的魔力——用最少的代码，讲述最深的道理。

五维元模型（V4.0/V5.0）

FROST V4.0 引入的五维元模型，将框架从扁平升级为多维度 Agent 编排系统：

武器注册表：能力的元数据管理与发现
任务注册表：DAG 任务编排与图谱 SOP
事件编目：态势感知与双模式事件分析
平台注册表：外部能力的发现、调用与健康检查
规则注册表：可版本化的治理约束与合规检查

197 个测试用例保障质量，最新 Release：FROST v5.0.0

FROST-SOP：思想的工程化

FROST 教会我们理解，FROST-SOP 教会我们构建。

事件驱动的 Agent 家族

FROST-SOP 实现了完整的祖辈 → 父辈 → 子辈三层递归架构：

import asyncio
from core.event_bus import get_async_event_bus, Event, EventType
from agents.ancestor import create_ancestor
from agents.parent import create_parent

async def main():
    bus = get_async_event_bus()

    # 创建事件驱动的 Agent 家族
    ancestor = create_ancestor(constitution, asset, event_driven=True)
    parent = create_parent("parent-1", store, event_driven=True, 
                          asset_store=asset, sop_id="DEV-001")

    # 发布任务，Agent 家族自动响应
    await bus.publish(Event(
        event_type=EventType.TASK_CREATED,
        source="user",
        data={"task_id": "task-001", "task_description": "开发一个用户登录功能"}
    ))

    await asyncio.sleep(10)

asyncio.run(main())

完整的工程特性

特性	说明
19 个内置 Skill	任务分解、SOP 搜索、Agent 组装、知识归档
AsyncEventBus	事件总线，Agent 间解耦通信
双前端界面	Next.js + Streamlit，可视化监控
零核心依赖	FROST 内核独立运行
84 个测试	全量覆盖核心功能

双生关系的核心价值

为什么需要两个项目？

FROST 解决的是"认知问题"：

帮助开发者理解 Agent 的本质
用最少的代码讲述最深的道理
适合学习、教学、概念验证

FROST-SOP 解决的是"工程问题"：

帮助开发者构建真实的 Agent 系统
提供完整的生产级功能
适合产品开发、企业应用

它们不是竞争关系，而是互补关系：

理解 FROST  ──→  概念清晰
     ���
     ▼
构建 FROST-SOP  ──→  工程可靠

学习路径建议

如果你想学习 FROST 生态，我建议：

第一阶段：阅读 FROST 源码（500 行）
- 理解四个原子
- 理解家族治理模型
- 理解五维元模型
第二阶段：运行 FROST-SOP 示例（5000+ 行）
- 体验事件驱动架构
- 理解层级 Agent 协作
- 掌握工程实践
第三阶段：构建自己的应用
- 使用 FROST-SOP 作为底座
- 定制自己的 Agent 家族
- 实现自己的 SOP 工作流

结语：从思想到工程的桥梁

开源世界的美妙之处在于：每一个伟大的工程，都始于一个简单的问题。

FROST 问的是："Agent 的本质是什么？"
FROST-SOP 答的是："让我们用工程的方式实现它。"

如果你对 Agent 系统感兴趣，不妨从 FROST 开始，从 500 行代码开始，理解本质，然后让 FROST-SOP 帮你把思想变成现实。

相关链接：

FROST（教学框架）：https://gitee.com/liao_liang_7514/frost
FROST-SOP（工程平台）：https://gitee.com/liao_liang_7514/frost-sop

Tags: python agent ai opensource frost

FROST-SOP：当家族治理遇上工程化SOP | V3.0 AsyncEventBus架构首发

llimage — Tue, 30 Jun 2026 02:56:56 +0000

FROST-SOP：当家族治理遇上工程化SOP

作者：神通说

日期：2026-06-30

主题：SOP工程 | FROST-SOP V3.0

从"经验"到"资产"：SOP工程化的必然

每一位技术管理者都面临同一个困境：团队中那些"只有他知道"的隐性知识，随着人员流动而消散。

这个问题在AI Agent领域尤为突出。当我们用LangChain、AutoGPT这样的框架构建AI应用时，每一条成功的执行路径都变成了"一次性脚本"——无法复用、无法审计、无法传承。

FROST-SOP正是为解决这个问题而生。

FROST-SOP是FROST（教学框架）的工程化分支，核心理念是：将SOP（标准操作流程）从个人经验升级为企业级可治理资产。

FROST-SOP V3.0：AsyncEventBus架构

V3.0版本采用异步事件总线架构（AsyncEventBus），实现了SOP的模块化、动态编排与可视化配置。

核心架构

┌─────────────────────────────────────────────────────────────┐
│                     FROST-SOP V3.0                          │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │   前端界面   │◄──►│  Async      │◄──►│   API服务   │     │
│  │  (可视化配置)│    │  EventBus   │    │  (Flask)    │     │
│  └─────────────┘    └──────┬──────┘    └──────┬──────┘     │
│                            │                    │           │
│              ┌─────────────┴────────────────────┘           │
│              ▼                                               │
│  ┌───────────────────────────────────────────────────────┐ │
│  │                  SOP Store (持久化)                    │ │
│  └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

关键特性

特性	描述	价值
AsyncEventBus	异步事件驱动总线	高并发、低耦合
SOP Store	SOP持久化存储	版本控制、审计追溯
Skill Registry	原子能力注册表	能力复用、快速编排
Agent Orchestrator	智能体编排器	复杂流程自动化

260个测试全绿：工程质量的承诺

V3.0版本经过260个测试用例全部通过，覆盖单元测试、集成测试、端到端测试。

# 运行测试
cd /path/to/frost-sop
pytest tests/ -v

# ======================== 260 passed in 12.34s ========================

260测试全绿，不仅是一个数字，更是工程化承诺的量化证明。

SOP四层次价值模型

FROST-SOP定义了SOP的四层次价值递增：

层次	名称	描述	典型场景
L1	文档化	将隐性经验显性化	SOP文档编写
L2	可执行	SOP转化为机器可执行流程	工作流引擎
L3	可编排	SOP支持动态组合与分支	Agent编排
L4	可进化	SOP自我优化与传承	家族治理

FROST与FROST-SOP：思想与工程的分工

维度	FROST	FROST-SOP
定位	教学框架	工程平台
代码规模	~500行（极简）	完整应用
目标用户	学习者、研究者	生产环境用户

FROST是思想源头，帮助理解Agent治理的本质；FROST-SOP是工程落地，将思想转化为可运行的生产系统。

快速开始

# 克隆仓库
git clone https://gitee.com/liao_liang_7514/frost-sop.git
cd frost-sop

# 安装依赖
pip install -r requirements.txt

# 运行测试验证
pytest tests/ -v

定义第一个SOP

from frost_sop import SOPStore, Skill, Agent

# 1. 定义Skill
hello_skill = Skill(
    name="hello_world",
    description="输出问候语",
    execute=lambda ctx: {"greeting": f"Hello, {ctx.get(\name, \World)}!"}
)

# 2. 创建SOP Store
store = SOPStore()

# 3. 注册SOP
store.register_sop(
    name="hello_flow",
    steps=[hello_skill],
    description="最简单的SOP示例"
)

# 4. 创建Agent并执行
agent = Agent(name="DemoAgent", store=store)
result = agent.execute("hello_flow", {"name": "FROST"})
print(result)  # {"greeting": "Hello, FROST!"}

为什么你需要FROST-SOP

解决"经验流失"问题：传统SOP纸质文档版本混乱，FROST-SOP将其数字化、版本化、可追溯。
实现SOP的自动化执行：FROST-SOP支持SOP的自动编排与执行。
构建家族治理能力：FROST-SOP的家族治理模型，确保AI行为在可控边界内。
享受260测试的质量保障：260个测试全绿，是我们对质量的承诺。

项目路线图

版本	目标	状态
V1.0	基础SOP执行引擎	✅ 完成
V2.0	Skill注册与发现	✅ 完成
V3.0	AsyncEventBus架构	✅ 当前版本
V4.0	前端可视化编排	🚧 规划中

结语

FROST-SOP V3.0 不仅是FROST思想的工程化实现，更是SOP工程化的一次有益探索。

从L1文档化到L4可进化，FROST-SOP定义了SOP进化的阶梯。

260测试全绿的工程质量承诺，让SOP从"经验沉淀"升级为"企业级可治理资产"。

了解更多：

FROST-SOP Gitee：https://gitee.com/liao_liang_7514/frost-sop
FROST Gitee：https://gitee.com/liao_liang_7514/frost

FROST-SOP V3.0 — AsyncEventBus架构首发版

事件（Event）：让 Agent 学会"喊话" | FROST 五维元模型系列

llimage — Mon, 29 Jun 2026 02:57:02 +0000

事件（Event）：让 Agent 学会"喊话"

FROST 五维元模型系列 · 第 2 篇

从"哑巴 Agent"到"喊话 Agent"

上一篇文章我们讲了武器（Weapon）——Agent 的技能军械库。

但光有技能还不够。想象一个团队，每个人都会干活，但谁也不说话：

A 干完了，不知道通知 B
B 不知道 A 干完了，自顾自地继续
C 发现问题了，没法喊人来看
D 任务完成了，没人知道结果

这不是团队，是一群孤立的个体。

当前大多数 Agent 框架就是这样：每个 Agent 只会闷头干活，干完就完了。没有通知，没有广播，没有协作。

FROST 的答案是：事件（Event）。

事件总线：Agent 的神经网络

在 FROST-SOP V2.0 中，我们引入了 EventBus（事件总线）。

事件总线是 Agent 家族的神经网络。 Agent 通过发布/订阅事件通信，而不是直接调用彼此。

from core.event_bus import get_event_bus, Event, EventType

# 获取全局事件总线
bus = get_event_bus()

# 发布一个事件
bus.publish(Event(
    event_type=EventType.STEP_COMPLETED,
    source="agent_scout",
    data={"step": "fetch_data", "result": {"count": 42}}
))

这就是 Agent"喊话"的方式——不需要知道谁在听，喊一声就行。

事件类型：Agent 能喊什么？

FROST 定义了清晰的事件类型体系：

层级	事件类型	含义
任务	`TASK_CREATED`	新任务被创建
	`TASK_DECOMPOSED`	祖辈完成任务分解
	`TASK_COMPLETED`	任务全部阶段完成
	`TASK_FAILED`	任务失败（不可恢复）
阶段	`STAGE_STARTED`	SOP 阶段开始执行
	`STAGE_COMPLETED`	SOP 阶段执行完成
	`STAGE_FAILED`	SOP 阶段执行失败
步骤	`STEP_COMPLETED`	Agent 单步 Skill 执行完成
Agent	`AGENT_CREATED`	Agent 被创建
	`AGENT_DESTROYED`	Agent 被销毁

命名规范是 <层级>_<动词>，一看就懂。

发布/订阅模式：谁想听谁举手

事件总线的核心是发布/订阅模式：

发布者（Publisher）：Agent 完成某件事，喊一声
订阅者（Subscriber）：其他 Agent 注册监听，有消息就收到通知
事件总线（EventBus）：中间人，负责传递

bus = get_event_bus()

# 定义一个监听器
def on_task_completed(event: Event):
    print(f"任务完成: {event.data}")

# 订阅事件
bus.subscribe("task_completed", on_task_completed)

# 另一个 Agent 发布事件
bus.publish(Event(
    event_type="task_completed",
    source="agent_parent",
    data={"task_id": "task_001", "output": "report.pdf"}
))

解耦是关键：发布者不需要知道谁在听，订阅者不需要知道谁发的。

Agent 生命��期事件：出生与死亡

每个 Agent 都有生命周期：

创建 (AGENT_CREATED) → 运行 (running) → 销毁 (AGENT_DESTROYED)

FROST-SOP V2.0 让 Agent 自动发布这两个事件：

class Agent:
    def __init__(self, name, event_driven=True):
        self.name = name
        if event_driven:
            self._publish_event("agent_created", {
                "agent_name": self.name,
                "generation": self.generation,
            })

    def destroy(self):
        self._write_agent_status("destroyed", "")
        if self._event_driven:
            self._publish_event("agent_destroyed", {
                "agent_name": self.name,
                "destroyed_at": datetime.now().isoformat(),
            })

这让实时监控 Agent 生命周期成为可能。

步骤完成事件：SOP 执行的里程碑

Agent 执行 SOP 时，每一步完成都会发布 STEP_COMPLETED 事件。

这让实时监控 SOP 执行进度成为可能：

# 监控系统订阅步骤完成事件
def on_step_completed(event: Event):
    data = event.data
    print(f"[{data["agent_name"]}] 步骤 {data["step_name"]} 完成")

bus.subscribe("step_completed", on_step_completed)

异步事件总线：V3.0 的进化

FROST-SOP V3.0 引入了 AsyncEventBus（异步事件总线）：

from core.event_bus import get_async_event_bus, Event

async_bus = get_async_event_bus()

# 支持异步订阅者
async def on_task_completed_async(event: Event):
    await send_notification(event.data)

async_bus.subscribe_async("task_completed", on_task_completed_async)

# 异步发布
await async_bus.publish(Event(
    event_type="task_completed",
    source="agent_parent",
    data={"task_id": "task_001"}
))

为什么需要异步版本？

V2.0 EventBus（同步）：适用于 Streamlit UI 和简单场景
V3.0 AsyncEventBus：适用于异步任务编排

事件持久化：让过去有据可查

事件不仅实时分发，还持久化到数据库：

db.insert("event_log", {
    "event_id": event.event_id,
    "event_type": event.event_type,
    "source": event.source,
    "data": json.dumps(event.data),
    "timestamp": event.timestamp.isoformat(),
})

这意味着：审计追溯、问题排查、性能分析都成为可能。

为什么叫"事件"而不是"消息"？

在传统消息队列中，消息是数据——只是传递信息。

FROST 的事件是事实——代表系统中真实发生的事情：

AGENT_CREATED = 真的有一个 Agent 出生了
STEP_COMPLETED = 真的有一个步骤完成了
TASK_FAILED = 真的有一个任务失败了

事件不只是数据，更是系统的记忆。

下一步：任务（Task）

武器解决了"Agent 能做什么"，事件解决了"Agent 之间怎么通信"。

但谁来组织这一切？

下一篇预告： 《任务（Task）：让 Agent 学会协作》

FROST v5.0.0 Released: Five-Dimensional Meta-Model Complete

llimage — Sun, 28 Jun 2026 16:21:40 +0000

FROST v5.0.0 Released: Five-Dimensional Meta-Model Complete

Repository: https://gitee.com/liao_liang_7514/frost

Version: v5.0.0

Release Date: June 29, 2026

TL;DR

FROST has officially evolved from a "teaching framework" to an "engineering platform" — the five-dimensional meta-model is fully implemented with 197 tests passing.

What is the Five-Dimensional Meta-Model?

FROST's core philosophy: AI Agents aren't tools, they're members of a "digital family." The five-dimensional meta-model defines how this family operates:

Dimension	Name	One-Line Explanation
Weapon	Armory	Skill registry + dependency graph — what Agents can do and what they depend on
Task	Task Registry	Task definition + graph-based SOPs — how work is broken down and connected
Event	Event Catalog	Event bus + advisor analysis layer — what happened and how to interpret it
Platform	Platform Registry	Multi-platform adaptation + cockpit integration — where to work and how to coordinate
Rule	Rule Registry	Governance rules + autonomy constraints — who can do what and where the boundaries are

These five dimensions form FROST's "meta-capabilities" — any AI Agent that connects to FROST automatically gains this complete operating system.

v5.0.0 Deliverables

New Core Modules (core/)

core/
├── __init__.py              # Unified exports (backward compatible)
├── armory.py                # Weapon registry
├── skill_graph.py           # Skill dependency graph
├── task_registry.py         # Task registry
├── event_catalog.py         # Event catalog
├── platform_registry.py     # Platform registry
└── rule_registry.py         # Rule registry

Test Coverage

Total tests: 197 (from baseline 27 to 197, +630%)
New test files: 6
Execution time: 0.38 seconds
Backward compatibility: All original 27 tests pass, zero regression

Why "Five Dimensions"?

Traditional AI Agent frameworks focus only on "capabilities" (what Agents can do), but real Agent operations need more:

Weapon: Capability definition (foundation)
Task: Work organization (how to break down work)
Event: Perception feedback (what happened)
Platform: Execution environment (where to work)
Rule: Governance boundaries (what can/can't be done)

The five-dimensional meta-model transforms FROST from a "skill framework" into a complete "digital family operating system."

Next: FROST-SOP Engineering Platform

The five-dimensional meta-model is FROST's core upgrade. FROST-SOP is the engineering platform that brings this model to life.

FROST-SOP Repository: https://gitee.com/liao_liang_7514/frost-sop

FROST-SOP provides:

Visual cockpit (Next.js)
Standardized workflow engine
Multi-Agent collaboration framework
Complete SOP template system

If FROST is the "genetic blueprint for digital families," FROST-SOP is "the factory that turns blueprints into reality."

Acknowledgments

Thank you to everyone following the FROST project. The completion of the five-dimensional meta-model is a milestone, but the FROST story is just beginning.

We firmly believe: The future of AI is not monolithic superintelligence, but collaborative digital families.

FROST — enabling every family to have their own digital family.

Get Started:

Source: https://gitee.com/liao_liang_7514/frost
Whitepaper: https://gitee.com/liao_liang_7514/frost/blob/main/WHITEPAPER.md
Issues: https://gitee.com/liao_liang_7514/frost/issues

This is the 5th article in the FROST open-source series. Follow for more updates on AI Agent family architecture.

Weapon: Give Your Agent a Real Skill Arsenal

llimage — Sun, 28 Jun 2026 10:50:01 +0000

Weapon: Give Your Agent a Real Skill Arsenal

FROST Five-Dimensional Meta-Model Series · Part 1

An Embarrassing Scenario

Imagine you have an Agent. It's smart—it can write code, analyze data, search for information.

But when you ask it: "Help me build a crawler to scrape e-commerce prices and analyze trends," it freezes.

Not because it can't, but because it can't find what it knows.

It has a bunch of skills scattered across the codebase, but no unified place telling it: "You know these things, use them as needed."

This is the common problem with current Agent frameworks: skills exist, but they're unorganized.

Weapon Registry: Agent's Skill Armory

In FROST V4.1, we introduced the Weapon Registry.

A Weapon is not a traditional "tool" or "function"—it's:

A discoverable, composable, versionable skill unit.

Think of it this way:

Traditional Agent skills are like LEGO bricks scattered on the floor
FROST Weapons are like equipment neatly arranged in an armory, each with an ID, description, and use case

Three Core Capabilities

1. Registration: Give Skills an Identity

from core.armory import Armory

# Create a weapon registry
armory = Armory()

# Register a weapon
armory.register(
    name="web_scraper",
    version="1.0.0",
    skill=WebScraperSkill(),
    metadata={
        "category": "data_collection",
        "description": "Scrape web data",
        "input_schema": {"url": "str", "selector": "str"},
        "output_schema": {"data": "list[dict]"},
    }
)

# Register another one
armory.register(
    name="trend_analyzer",
    version="1.0.0",
    skill=TrendAnalyzerSkill(),
    metadata={
        "category": "analysis",
        "description": "Analyze data trends",
        "input_schema": {"data": "list[dict]"},
        "output_schema": {"trend": "str", "confidence": "float"},
    }
)

Every weapon has:

Unique name: web_scraper, no conflicts with other skills
Version number: 1.0.0, supports upgrades and rollbacks
Metadata: Input/output schemas, categories, descriptions

2. Discovery: Find Skills on Demand

# Find by category
data_skills = armory.find_by_category("data_collection")
# => [web_scraper, api_fetcher, file_parser, ...]

# Find by capability (fuzzy match)
relevant = armory.find_by_capability("scrape web")
# => [web_scraper]

# List all available weapons
all_weapons = armory.list_all()
# => [web_scraper, trend_analyzer, code_writer, ...]

Agents no longer need to hardcode "what I can do"—they dynamically discover which weapons they can use.

3. Composition: Stack Skills to Create New Capabilities

# Define a composite weapon
armory.register_composite(
    name="ecommerce_price_tracker",
    components=["web_scraper", "trend_analyzer"],
    description="E-commerce price tracking and trend analysis",
    workflow="""
    1. Use web_scraper to scrape price data
    2. Pass data to trend_analyzer for analysis
    3. Return analysis report
    """
)

# Use the composite weapon
result = agent.execute("ecommerce_price_tracker", {
    "url": "https://example.com/product",
    "selector": ".price"
})

Composite weapons let Agent capabilities grow exponentially:

2 base weapons → 1 composite weapon
10 base weapons → 100+ possible combinations

How Is This Different from Traditional "Tool Calling"?

Dimension	Traditional Tool Calling	FROST Weapon Registry
Discovery	Hardcoded in source	Dynamic query, matched by need
Versioning	None	Semantic versioning (1.0.0 → 1.1.0)
Metadata	Simple function signatures	Full input/output schemas + categories + descriptions
Composition	Manual glue code	Declarative composition, auto-generated workflows
Testability	Need to mock entire tool chains	Each weapon tested independently, compositions also testable

Key difference: The Weapon Registry makes skills first-class citizens, not just appendages to code.

A Real-World Scenario

Suppose you want to build an automated competitor analysis Agent:

The Traditional Way

# Hardcode all steps
class CompetitorAnalyzer:
    def __init__(self):
        self.scraper = WebScraper()  # Hard dependency
        self.analyzer = TrendAnalyzer()  # Hard dependency
        self.reporter = ReportGenerator()  # Hard dependency

    def analyze(self, competitor_url):
        data = self.scraper.scrape(competitor_url)
        trend = self.analyzer.analyze(data)
        report = self.reporter.generate(trend)
        return report

Problems:

❌ Can't swap the scraper (unless you change the code)
❌ Can't reuse the analyzer (tied to this class)
❌ Can't dynamically choose tools (e.g., auto-select scraper type based on URL)

The FROST Way

# Declarative composition
agent = Agent(armory=armory)

# Agent decides which weapons to use
result = agent.execute("competitive_analysis", {
    "competitor": "https://competitor.com",
    "metrics": ["price", "features", "reviews"]
})

# Agent's internal logic (automatic):
# 1. Query armory.find_by_capability("scrape web") → select web_scraper
# 2. Query armory.find_by_capability("analyze trends") → select trend_analyzer
# 3. Query armory.find_by_capability("generate report") → select report_generator
# 4. Compose and execute, return result

Advantages:

✅ Swap any weapon anytime (found a better scraper? Just register it)
✅ Weapons are reusable (trend_analyzer works in other scenarios too)
✅ Agent autonomously chooses the best weapon (based on metadata matching)

Why "Weapon" Instead of "Tool"?

This is FROST's design philosophy:

Tools are passive; weapons are active.

Tools wait for humans to use them
Weapons are Agent's equipment—Agent actively chooses and actively uses them

In FROST's family governance model:

Ancestor defines the constitution, specifying which weapons are available
Parent coordinates tasks, deciding which weapon combinations to use
Child executes specific operations, using weapons to complete tasks

The Weapon Registry makes this process auditable, controllable, and evolvable.

Next Up: Event

Weapons solve "what Agent can do."

But how do Agents collaborate? How do they know "task completed," "error occurred," "need help"?

The answer is Event—Agent's nervous system.

Next article preview: Event: Teaching Agents to "Shout Out"

用FROST写一个你的第一个Agent，只用10��钟

llimage — Sun, 28 Jun 2026 02:54:44 +0000

用FROST写一个你的第一个Agent，只用10分钟

你好，FROST

周末好！今天不聊深奥的理论，就来点实际的：手把手教你用FROST写一个会聊天的Agent。

整个过程只需要10分钟，代码不超过30行。

什么是FROST？

先简单介绍一下。FROST是一个教学用的轻量Agent框架，只有500行代码，核心概念只有三个：

Agent：执行者
Skill：技能（类似函数）
Store：记忆（存储上下文）

听起来简单？没错，它就是为你设计的——让你从第一行代码开始，就清楚地知道自己在做什么。

GitHub: https://gitee.com/liao_liang_7514/frost

开始之前

你需要：

Python 3.10+
一颗想学习的心

安装FROST：

pip install frost-ai

或者直接clone源码：

git clone https://gitee.com/liao_liang_7514/frost.git

实战：写一个"翻译助手"

让我们写一个简单的翻译Agent。它能接收中文，翻译成英文。

第一步：定义技能

from frost import Skill, Store, Agent

class TranslateSkill(Skill):
    """翻译技能"""
    def __call__(self, store, text, target_lang="en"):
        # 这里你可以接入任何翻译API
        # 为了演示，我们用一个简单的mock
        translations = {
            ("你好", "en"): "Hello",
            ("今天天气怎么样", "en"): "How is the weather today?",
            ("再见", "en"): "Goodbye"
        }
        result = translations.get((text, target_lang), f"[翻译中] {text}")
        store.set("last_translation", result)
        return result

看到了吗？Skill就是一个普通的Python类，继承Skill，实现__call__方法。

第二步：创建Agent

# 创建记忆存储
store = Store()

# 把技能交给Agent
agent = Agent(skills=[TranslateSkill()], store=store)

# 运行！
response = agent.run("你好")
print(response)  # 输出: Hello

完整的代码就这些：

from frost import Skill, Store, Agent

class TranslateSkill(Skill):
    def __call__(self, store, text, target_lang="en"):
        translations = {
            ("你好", "en"): "Hello",
            ("今天天气怎么样", "en"): "How is the weather today?",
        }
        return translations.get((text, target_lang), f"[翻译中] {text}")

store = Store()
agent = Agent(skills=[TranslateSkill()], store=store)
print(agent.run("你好"))

30行代码，一个翻译Agent就这么跑起来了。

为什么选FROST？

可能有同学会问：我直接用LangChain不就好了吗？

好问题。对比一下：

对比项	LangChain	FROST
代码量	几十万行	500行
上手难度	😰 较高	✅ 轻松
理解底层	😰 很难	✅ 一目了然
适用场景	生产开发	学习原理

FROST不是用来替代LangChain的。

它的定位是：让你理解Agent是怎么工作的。

当你用FROST弄懂了Agent的核心逻辑，再去用LangChain，会发现"原来那些API背后是这么回事"——学习效率翻倍。

还能做什么？

目前FROST已经有几个现成的示例：

1. 搜索助手

class SearchSkill(Skill):
    def __call__(self, store, query):
        result = web_search(query)
        store.set("last_search", result)
        return result

2. 记忆助手

# Store可以存储Agent的"记忆"
store.set("user_name", "小明")
store.set("user_preference", "喜欢简洁的设计")

3. 多技能组合

agent = Agent(
    skills=[SearchSkill(), TranslateSkill()],
    store=store
)
# Agent会自动选择合适的技能完成任务

写给想深入的你

FROST的源码非常适合作为学习材料。

整个框架的核心代码在这里：

frost/
├── agent.py      # Agent主体 (~100行)
├── skill.py      # Skill基类 (~50行)
├── store.py      # Store存储 (~50行)
└── __init__.py   # 导出接口 (~20行)

你可以一边读源码，一边改代码，看看会发生什么。学习 Agent 最好的方式就是自己动手实现一个。

工程版预告

如果你觉得FROST的教学理念有意思，想看看"同样思想在生产环境长什么样"——

FROST-SOP 即将开源！

FROST-SOP是基于FROST思想打造的工程级Agent开发平台，包含完整的企业级功能（FROST-SOP Gitee仓库正在筹备中）。

FROST：教学框架，揭示本质
FROST-SOP：工程平台，用于生产

两者共享同样的设计哲学：分形架构 + 家族治理。

写在最后

周末抽10分钟，给自己一个小挑战：

试着修改上面的翻译Agent，让它支持更多语言，或者添加一个新技能（比如"计算字数"）。

学习编程最好的方式就是动手写代码。

如果你完成了，欢迎在评论区分享你的作品！

如果你喜欢这种轻松的学习风格，欢迎关注并转发。

Tags: #AI #Agent #Python #开源 #教程 #FROST

从"玩具"到"教材"：一个500行AI框架的自我修养

llimage — Sat, 27 Jun 2026 03:15:07 +0000

为什么我要造一个500行的Agent轮子？

你好，我是 FROST 的作者。

2026年了，Agent 框架多得能让人挑花眼：LangGraph 有 34.5M 月下载量，Dify 在 GitHub 斩获 129.8K Stars，各大厂商都在疯狂推自己的 SDK。这种环境下，再写一个"轮子"，是不是有点多余？

说实话，我也纠结了很久。

一个困惑：新学者的两难困境

事情要从一次失败的辅导说起。

我帮一个朋友入门 Agent 开发，推荐了 LangChain。结果他学了两个月，还在和 chain.invoke() 搏斗，脑子里依然没有"Agent 到底是怎么工作的"这个概念。

问题出在哪？

现在的框架太强了，强到把所有的复杂性都藏了起来。 你可以三行代码跑起来一个 Agent，但你也永远不知道它内部发生了什么。就像学开车，你学会了踩油门转弯，但发动机是怎么工作的、变速箱怎么换挡，一概不知。

而对于想真正理解 Agent 本质的人来说，这是一个巨大的 Gap：

需求	现有选项
快速开发产品	LangChain/CrewAI
理解底层原理	论文 + 源码
入门级教学框架	❌ 空白

这个空白，就是 FROST 存在的原因。

FROST 的设计哲学：Less is More

FROST 不是一个生产级框架，它是一个教学框架。

这意味着它刻意放弃了：

❌ 复杂的依赖生态（不需要 LangChain）
❌ 丰富的工具集成（没有 100+ 内置工具）
❌ 分布式部署能力（就是单机 Python）

它只保留了三个核心概念：

\`python

Store - 记忆容器（类似神经细胞的存储功能）

class Store:
"""存储上下文、记忆、状态"""
def init(self): self.data = {}

Skill - 纯函数变换（类似神经细胞的处理功能）

class Skill:
"""输入→处理→输出，无状态"""
def call(self, store, *args, **kwargs): pass

Agent - 执行单元（类似神经细胞本身）

class Agent:
"""调用 Skill，操作 Store，完成目标"""
def init(self, skills: list[Skill], store: Store): pass
`\

是的，就这么简单。三个类，不超过 500 行代码。

但正是这种简单，让"理解"变得可能。

一行代码跑起来的 Agent

\`python
from frost import Agent, Store, Skill

定义一个"搜索助手"技能

class SearchSkill(Skill):
def call(self, store, query):
result = web_search(query) # 这里是你的搜索实现
store.set("last_search", result)
return result

创建 Agent 并运行

store = Store()
agent = Agent(skills=[SearchSkill()], store=store)
response = agent.run("北京今天天气怎么样")
print(response)
`\

对比一下用 LangChain 实现同样的功能：

\`python
from langchain.agents import AgentExecutor, create_react_agent
from langchain_openai import ChatOpenAI

... 还有十几行初始化代码

`\

FROST 让你从第一行代码开始，就知道自己在做什么：

Agent 是执行者
Skill 是它的能力
Store 是它的记忆

没有魔法，没有黑箱，只有清晰的数据流。

为什么叫 FROST？

FROST 的全称是 Fractal Remote Organ of Scalable Thoughts——可扩展思维的分形远程器官。

这个名字源于它的设计灵感：神经细胞（Neural Cell）。

在生物学中，每个神经细胞都很简单：

接收信号
处理信号
发出信号

但当亿万个神经细胞连接在一起，就涌现出了智能。

FROST 试图在软件层面复现这个过程：

Neural Cell          →  Agent
Synapse              →  Skill
Long-term Memory     →  Store
Brain (Emergence)    →  Multi-Agent System

这不是在模仿大脑，而是在学习生物界的智慧：简单单元 + 清晰连接 = 复杂行为。

我的踩坑日记

作为一个从零开始写框架的人，踩的坑比代码行数还多：

坑1：追求"完整"差点毁掉项目

最初我设计了一个包含配置管理、日志系统、错误重试的"完整框架"。写了 2000 行后，我发现：

代码复杂度指数级上升
核心概念被淹没在细节里
教学价值归零

教训：教学框架的第一原则是最小化。功能可以以后加，但第一印象无法重来。

坑2：被"这有什么用"质疑

最常见的质疑是："你这么简单的框架，生产环境谁会用？"

我的回答是：这不是给生产环境用的。

FROST 的用户��像是：

刚学完 Python，想了解 Agent 的学生
想从应用层深入到底层原理的开发者
想给学生演示 Agent 工作原理的讲师

为特定用户解决特定问题，比"什么都能做"更有价值。

FROST-SOP：思想的开花结果

在 FROST 的基础上，我又开发了 FROST-SOP——一个面向工程实践的 Agent 开发平台。

如果说 FROST 是"理解 Agent"的教材，那 FROST-SOP 就是"使用 Agent"的工具箱。

FROST：教学框架，500行代码，揭示本质
FROST-SOP：工程框架，完整功能，用于生产

两者共享同样的设计思想：分形架构 + 家族治理，只是侧重点不同。

了解更多：https://gitee.com/liao_liang_7514/frost

加入我们

FROST 还有很多不完善的地方：

文档还在补全
示例还不够丰富
测试覆盖还有提升空间

但这恰恰是一个开源项目的真实状态。

如果你对 Agent 框架感兴趣，无论是想学习原理、贡献代码，还是只是想看看"一个 500 行的框架长什么样"，欢迎：

GitHub：https://gitee.com/liao_liang_7514/frost
文档：项目 README
提 Issue：功能建议、Bug 反馈、代码贡献

最后

造轮子不是目的，理解轮子才是。

当你读完 FROST 的 500 行代码，希望你收获的不只是一个框架，而是：

"原来 Agent 的本质，就是这么简单。"

如果你觉得这篇文章有帮助，欢迎转发给需要的朋友。

Tags: python, agent, ai, opensource

FROST - Understanding Agent Architecture in 500 Lines of Python

llimage — Fri, 26 Jun 2026 06:32:03 +0000

What is FROST?

FROST (Fractal Runtime of Orchestrated Skills & Tasks) is a minimalist Python framework that uses biological metaphors to help you understand how AI agents work.

Instead of abstracting everything away, FROST shows you exactly how an agent system is built — in just 500 lines of code.

Why It Matters

Most agent frameworks are thousands of lines of code. FROST strips away the complexity and reveals the core patterns:

Neural Cells — the basic unit of intelligence
Cell Nucleus — where knowledge and reasoning live
Family Structure — how agents organize and delegate
Fractal Growth — how simple rules create complex behavior

Getting Started

git clone https://gitee.com/liao_liang_7514/frost.git
cd frost
pip install -r requirements.txt

The Big Picture

FROST is not another framework to add to your toolbox. Its purpose is to help you understand the essence of agents — so you can build your own, with any framework.

👉 Star the repo: https://gitee.com/liao_liang_7514/frost

Python #Agent #OpenSource #AI #Teaching

DEV Community: llimage

FROST-SOP 源码解读：3个核心模块的工程精髓

FROST-SOP 源码解读：3个核心模块的工程精髓

前言

一、Agent 生命周期管理：从生到死的完整闭环

1.1 为什么生命周期重要？

1.2 run() 方法：任务的执行与守护

1.3 destroy() 方法：优雅的资源释放

1.4 自修复重试机制

二、向量记忆系统：优雅降级的工程美学

2.1 为什么需要优雅降级？

2.2 统一接口的降级实现

2.3 单例模式的记忆存储

三、事件驱动架构：松耦合的异步通信

3.1 事件总线的设计

3.2 Agent 中的事件集成

四、工程设计原则总结

五、实战：5分钟跑起 FROST-SOP

快速验证记忆系统

结语

相关链接

从思想到工程：FROST 与 FROST-SOP 的双生之旅

从思想到工程：FROST 与 FROST-SOP 的双生之旅

引言：从 500 行到 5000 行的演进

FROST：理解 Agent 的钥匙

四个原子，理解一切

五维元模型（V4.0/V5.0）

FROST-SOP：思想的工程化

事件驱动的 Agent 家族

完整的工程特性

双生关系的核心价值

学习路径建议

结语：从思想到工程的桥梁

FROST-SOP：当家族治理遇上工程化SOP | V3.0 AsyncEventBus架构首发

FROST-SOP：当家族治理遇上工程化SOP

从"经验"到"资产"：SOP工程化的必然

FROST-SOP V3.0：AsyncEventBus架构

核心架构

关键特性

260个测试全绿：工程质量的承诺

SOP四层次价值模型

FROST与FROST-SOP：思想与工程的分工

快速开始

定义第一个SOP

为什么你需要FROST-SOP

项目路线图

结语

事件（Event）：让 Agent 学会"喊话" | FROST 五维元模型系列

事件（Event）：让 Agent 学会"喊话"

从"哑巴 Agent"到"喊话 Agent"

事件总线：Agent 的神经网络

事件类型：Agent 能喊什么？

发布/订阅模式：谁想听谁举手

Agent 生命���期事件：出生与死亡

步骤完成事件：SOP 执行的里程碑

异步事件总线：V3.0 的进化

事件持久化：让过去有据可查

为什么叫"事件"而不是"消息"？

下一步：任务（Task）

相关链接

FROST v5.0.0 Released: Five-Dimensional Meta-Model Complete

FROST v5.0.0 Released: Five-Dimensional Meta-Model Complete

TL;DR

What is the Five-Dimensional Meta-Model?

v5.0.0 Deliverables

New Core Modules (core/)

Test Coverage

Why "Five Dimensions"?

Next: FROST-SOP Engineering Platform

Acknowledgments

Weapon: Give Your Agent a Real Skill Arsenal

Weapon: Give Your Agent a Real Skill Arsenal

An Embarrassing Scenario

Weapon Registry: Agent's Skill Armory

Three Core Capabilities

1. Registration: Give Skills an Identity

2. Discovery: Find Skills on Demand

3. Composition: Stack Skills to Create New Capabilities

How Is This Different from Traditional "Tool Calling"?

A Real-World Scenario

Agent 生命��期事件：出生与死亡

用FROST写一个你的第一个Agent，只用10��钟