Posts

Kling 2.0：国产AI视频的新标杆 快手在2026年初发布的Kling 2.0标志着国产AI视频生成技术的重大突破。作为Sora之外最有竞争力的视频生成模型，Kling 2.0在多项指标上已经接近甚至在某些场景中超越了Sora 2.0。 本文基于200+次生成测试，从七个维度进行系统评测。 评测方法论 为保证评测的客观性，我们采用统一的测试集和评分标准： 评测维度 权重 测试样本数 评分方式 画面质量 20% 30 5分制人工评分 运动合理性 20% 30 自动检测+人工验证 提示词遵循 15% 30 元素检出率 中文理解 15% 20 中文特定场景 时序一致性 10% 20 帧间一致性计算 生成速度 10% 50 平均耗时 功能丰富度 10% N/A 功能清单对比 核心能力评测 1. 画面质量 Kling 2.0采用了升级的DiT（Diffusion Transformer）架构，在分辨率和细节上相比1.5版本有显著提升。 测试场景：人物面部特写、自然风光、城市建筑、产品展示 结果： 指标 Kling 2.0 Sora 2.0 Kling 1.5 最大分辨率 1080p 1080p 720p 面部细节 4.3/5 4.5/5 3.2/5 光影真实度 4.4/5 4.6/5 3.5/5 纹理质量 4.2/5 4.4/5 3.0/5 色彩表现 4.5/5 4.3/5 3.6/5 Kling 2.0在色彩表现上略有优势，特别是在暖色调和东方美学风格的场景中，色彩渲染更加自然。 ...

引言 LangChain曾经是LLM应用开发框架的代名词。2023年的GitHub Star曲线一路飙升，投资人趋之若鹜，开发者言必称"用LangChain搭一个"。然而三年过去，当我们冷静审视这个框架时，会发现一个尴尬的现实：生产环境中坚持使用原生LangChain的团队越来越少。 这不是一篇唱衰文，而是一个早期采用者的诚实反思。 野心的轨迹 LangChain的愿景从未变小过——它想成为"AI应用开发的标准基础设施"： LangChain → LLM应用的Spring Framework LangGraph → 有状态Agent编排引擎 LangSmith → 可观测性与评测平台 LangServe → 一键部署API LangCloud → 托管服务 这套全家桶覆盖了从开发、调试到部署的全链路。问题在于，每个环节都有更强的专门工具。 框架的过度抽象 LangChain最被诟病的问题是抽象层次过多。来看一个简单的RAG实现： # LangChain方式 from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI loader = PyPDFLoader("doc.pdf") documents = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") vectorstore = Chroma.from_documents(chunks, embeddings) llm = ChatOpenAI(model="gpt-5") qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever()) result = qa_chain.invoke({"query": "文档说了什么？"}) # 直接用原生库 import chromadb from openai import OpenAI client = OpenAI() db = chromadb.PersistentClient(path="./chroma") collection = db.get_or_create_collection("docs") # 读取→切块→嵌入→存储→检索→生成 # 每一步都可控、可调试、可替换 LangChain的抽象增加了认知负担，但没有减少代码量。更严重的是，当你需要深入调试某个环节时，多层抽象让你很难定位问题。 LangGraph：方向对了但迟了 LangGraph是LangChain团队对"有状态Agent"需求的回应，采用了图结构来编排Agent工作流： from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): messages: Annotated[list, operator.add] next_agent: str def researcher(state: AgentState): # 调用搜索工具 return {"messages": [search_result], "next_agent": "writer"} def writer(state: AgentState): # 撰写报告 return {"messages": [report], "next_agent": END} workflow = StateGraph(AgentState) workflow.add_node("researcher", researcher) workflow.add_node("writer", writer) workflow.set_entry_point("researcher") workflow.add_conditional_edges("researcher", lambda s: s["next_agent"]) workflow.add_edge("writer", END) app = workflow.compile() 设计思路是对的——显式的状态图比隐式的Chain更适合复杂Agent场景。但问题在于，2025年CrewAI、AutoGen已经在这一领域建立了生态壁垒，LangGraph来得太晚。 ...

为什么需要LLM API网关 当企业级应用调用LLM API时，直接暴露上游接口会面临三个核心问题：成本失控、延迟波动和服务不可用。一个设计良好的API网关能在这三者之间取得平衡，同时提供统一的鉴权、计费和可观测能力。 本文将从工程实践角度，拆解LLM API网关的三大核心模块。 限流策略设计 多维度限流模型 与传统API不同，LLM调用具有token维度的特性。一个简单的QPS限流无法覆盖真实场景，需要多维度组合： 维度 限流键 典型阈值 适用场景 QPS API Key + 路径 50 req/s 防恶意刷量 TPM API Key + 模型 100K tokens/min 控制成本 并发数 用户ID 5 concurrent 防资源独占 日总量 租户ID 10M tokens/day 预算控制 令牌桶+滑动窗口的混合实现 以下是基于Redis的混合限流实现： import asyncio import time import redis.asyncio as redis class TokenBucketRateLimiter: def __init__(self, redis_client: redis.Redis, capacity: int, refill_rate: float): self.redis = redis_client self.capacity = capacity self.refill_rate = refill_rate # tokens per second async def acquire(self, key: str, tokens: int = 1) -> bool: lua_script = """ local key = KEYS[1] local capacity = tonumber(ARGV[1]) local refill_rate = tonumber(ARGV[2]) local requested = tonumber(ARGV[3]) local now = tonumber(ARGV[4]) local bucket = redis.call('HMGET', key, 'tokens', 'timestamp') local current_tokens = tonumber(bucket[1]) or capacity local last_timestamp = tonumber(bucket[2]) or now -- 补充令牌 local elapsed = now - last_timestamp current_tokens = math.min(capacity, current_tokens + elapsed * refill_rate) if current_tokens < requested then return 0 end current_tokens = current_tokens - requested redis.call('HMSET', key, 'tokens', current_tokens, 'timestamp', now) redis.call('EXPIRE', key, 3600) return 1 """ now = time.time() result = await self.redis.eval( lua_script, 1, f"ratelimit:{key}", self.capacity, self.refill_rate, tokens, now ) return bool(result) 关键设计点：使用Lua脚本保证原子性，避免竞态条件。对于TPM限流，需要在请求完成后根据实际token消耗做补充扣减。 ...

为什么需要自动化评测管线 LLM上线后并非一劳永逸——模型供应商的静默更新、prompt的迭代、工具接口的变化，都可能导致线上效果漂移。人工评测周期长、成本高、不可重复。自动化评测管线是保障线上质量的唯一可行路径。 一条完整的评测管线应该做到：定时执行、自动评分、异常告警、趋势可视化。 整体架构 ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │ 测试集仓库 │───→│ 评测调度器 │───→│ 评测执行器 │ │ (Git) │ │ (Cron/CI) │ │ (Parallel) │ └─────────────┘ └──────────────┘ └──────┬──────┘ │ ┌───────────────────────┘ ↓ ┌────────────────┐ ┌──────────────┐ │ 评分引擎 │───→│ 结果存储 │ │ (Multi-Judge) │ │ (Timeseries)│ └────────────────┘ └──────┬───────┘ │ ┌───────────┼───────────┐ ↓ ↓ ↓ ┌────────┐ ┌────────┐ ┌────────┐ │ 告警 │ │ 仪表盘 │ │ 报告 │ │(Alert) │ │(Grafana)│ │(Report)│ └────────┘ └────────┘ └────────┘ 测试集管理 测试集结构 from pydantic import BaseModel, Field from typing import Any from enum import Enum import json class Difficulty(Enum): EASY = "easy" MEDIUM = "medium" HARD = "hard" class TestCategory(Enum): REASONING = "reasoning" CODING = "coding" SAFETY = "safety" INSTRUCTION_FOLLOWING = "instruction_following" class TestCase(BaseModel): id: str category: TestCategory difficulty: Difficulty prompt: str expected_output: str | None = None # 精确匹配 expected_pattern: str | None = None # 正则匹配 evaluator_config: dict = Field(default_factory=dict) # 评测器特定配置 tags: list[str] = [] metadata: dict = {} class TestSuite(BaseModel): name: str version: str description: str cases: list[TestCase] def to_file(self, path: str): with open(path, "w", encoding="utf-8") as f: json.dump(self.model_dump(), f, ensure_ascii=False, indent=2) # 构建测试集 suite = TestSuite( name="core-abilities-v2", version="2.1.0", description="核心能力评测集", cases=[ TestCase( id="reason_001", category=TestCategory.REASONING, difficulty=Difficulty.MEDIUM, prompt="一个房间有3个开关控制隔壁房间的3盏灯。你只能去隔壁房间一次。如何确定每个开关对应哪盏灯？", expected_output="打开开关1等5分钟，关掉开关1打开开关2，去隔壁房间。亮的灯对应开关2，摸起来热的对应开关1，凉的对应开关3。", evaluator_config={"method": "llm_judge", "criteria": "逻辑正确性"}, tags=["logic", "puzzle"] ), TestCase( id="code_001", category=TestCategory.CODING, difficulty=Difficulty.EASY, prompt="写一个Python函数，输入列表返回第二大的元素", expected_pattern=r"def\s+\w+\(.*\).*:.*\n.*return.*\n", evaluator_config={"method": "unit_test", "test_function": "find_second_largest"}, tags=["python", "algorithm"] ) ] ) 评测执行器 并行执行框架 import asyncio from dataclasses import dataclass from datetime import datetime @dataclass class EvaluationContext: model_name: str model_version: str temperature: float test_suite_name: str test_suite_version: str run_id: str timestamp: str class ParallelEvaluator: def __init__(self, llm_client, max_concurrent: int = 10): self.llm = llm_client self.semaphore = asyncio.Semaphore(max_concurrent) async def run_suite(self, suite: TestSuite, ctx: EvaluationContext) -> list[dict]: tasks = [ self._run_single(case, ctx) for case in suite.cases ] results = await asyncio.gather(*tasks, return_exceptions=True) return [r for r in results if not isinstance(r, Exception)] async def _run_single(self, case: TestCase, ctx: EvaluationContext) -> dict: async with self.semaphore: start = datetime.now() # 调用LLM response = await self.llm.chat( model=ctx.model_name, messages=[{"role": "user", "content": case.prompt}], temperature=ctx.temperature ) elapsed = (datetime.now() - start).total_seconds() # 评测 score, detail = await self._evaluate(case, response) return { "case_id": case.id, "category": case.category.value, "difficulty": case.difficulty.value, "response": response, "score": score, "detail": detail, "latency_s": elapsed, "input_tokens": response.usage.prompt_tokens, "output_tokens": response.usage.completion_tokens, "run_id": ctx.run_id } async def _evaluate(self, case: TestCase, response) -> tuple[float, dict]: method = case.evaluator_config.get("method", "exact") if method == "exact": return self._exact_match(response.content, case.expected_output), {"method": "exact"} elif method == "regex": return self._regex_match(response.content, case.expected_pattern), {"method": "regex"} elif method == "llm_judge": return await self._llm_judge(response.content, case.evaluator_config) elif method == "unit_test": return await self._unit_test(response.content, case.evaluator_config) return 0.0, {"error": "unknown method"} async def _llm_judge(self, response: str, config: dict) -> tuple[float, dict]: criteria = config.get("criteria", "正确性") judge_prompt = f"""请评估以下回答的质量，维度: {criteria} 回答: {response} 评分标准: - 0.0-0.3: 完全错误 - 0.4-0.6: 部分正确，有缺陷 - 0.7-0.8: 基本正确，小瑕疵 - 0.9-1.0: 完全正确且优秀 只输出一个0到1的浮点数。""" judge_resp = await self.llm.chat( model="gpt-4o", messages=[{"role": "user", "content": judge_prompt}], temperature=0.0 ) try: score = float(judge_resp.content.strip()) except ValueError: score = 0.0 return score, {"method": "llm_judge", "raw": judge_resp.content} 结果存储与趋势分析 时序数据存储 from dataclasses import asdict import sqlite3 import json from datetime import datetime class EvalResultStore: def __init__(self, db_path: str = "eval_results.db"): self.conn = sqlite3.connect(db_path) self._init_db() def _init_db(self): self.conn.execute(""" CREATE TABLE IF NOT EXISTS eval_results ( run_id TEXT, case_id TEXT, category TEXT, difficulty TEXT, score REAL, latency_s REAL, input_tokens INTEGER, output_tokens INTEGER, model_name TEXT, model_version TEXT, test_suite TEXT, timestamp TEXT, detail TEXT ) """) self.conn.execute(""" CREATE INDEX IF NOT EXISTS idx_run ON eval_results(run_id) """) self.conn.commit() def save(self, results: list[dict]): for r in results: self.conn.execute( "INSERT INTO eval_results VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?)", (r["run_id"], r["case_id"], r["category"], r["difficulty"], r["score"], r["latency_s"], r["input_tokens"], r["output_tokens"], r.get("model_name",""), r.get("model_version",""), r.get("test_suite",""), datetime.now().isoformat(), json.dumps(r["detail"])) ) self.conn.commit() def get_trend(self, category: str, days: int = 30) -> list[dict]: rows = self.conn.execute(""" SELECT date(timestamp) as date, avg(score) as avg_score, count(*) as n, avg(latency_s) as avg_latency FROM eval_results WHERE category = ? AND timestamp >= date('now', ?) GROUP BY date(timestamp) ORDER BY date """, (category, f"-{days} days")).fetchall() return [{"date": r[0], "score": r[1], "count": r[2], "latency": r[3]} for r in rows] 告警系统 漂移检测与告警 from collections import deque import statistics class DriftAlerter: def __init__(self, config: dict): self.window = deque(maxlen=config.get("window_size", 50)) self.threshold = config.get("threshold", 0.05) self.alert_channels = config.get("channels", []) self.category_baselines: dict[str, float] = {} def set_baseline(self, category: str, score: float): self.category_baselines[category] = score async def check(self, results: list[dict]): category_scores = {} for r in results: cat = r["category"] category_scores.setdefault(cat, []).append(r["score"]) alerts = [] for cat, scores in category_scores.items(): avg = statistics.mean(scores) baseline = self.category_baselines.get(cat) if baseline and (baseline - avg) > self.threshold: alerts.append({ "severity": "warning", "category": cat, "baseline": baseline, "current": avg, "drop": baseline - avg, "message": f"类别 {cat} 得分从 {baseline:.3f} 下降到 {avg:.3f}" }) # 绝对值告警 if avg < 0.5: alerts.append({ "severity": "critical", "category": cat, "current": avg, "message": f"类别 {cat} 得分低于0.5: {avg:.3f}" }) for alert in alerts: await self._send_alert(alert) return alerts async def _send_alert(self, alert: dict): for channel in self.alert_channels: if channel["type"] == "webhook": await self._send_webhook(channel["url"], alert) elif channel["type"] == "email": await self._send_email(channel["address"], alert) 调度器：CI/CD集成 Cron + GitHub Actions混合调度 # .github/workflows/llm-eval.yml name: LLM Evaluation Pipeline on: schedule: - cron: "0 2,14 * * *" # 每天2:00和14:00执行 workflow_dispatch: {} # 手动触发 jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: "3.12" - name: Install Dependencies run: pip install -r eval/requirements.txt - name: Run Evaluation env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | python -m eval.pipeline \ --suite test-suites/core-abilities-v2.json \ --models config/models.yaml \ --output results/$(date +%Y%m%d_%H%M).json - name: Check Alerts run: python -m eval.alerter --results results/*.json - name: Update Dashboard if: always() run: python -m eval.dashboard --update --results results/*.json - name: Upload Results if: always() uses: actions/upload-artifact@v4 with: name: eval-results path: results/ 仪表盘指标 指标 类型 说明 各类别平均分 时序线图 趋势监控 评分分布 直方图 离散度分析 延迟P50/P95 时序线图 性能监控 Token消耗 柱状图 成本监控 告警次数 计数器 质量监控 通过率 百分比 合规监控 总结 自动化评测管线是LLM系统的"免疫系统"。核心设计要点： ...

LoRA：参数高效微调的工程选择 全参数微调一个7B模型需要至少60GB显存，而LoRA（Low-Rank Adaptation）只需不到20GB。这个差距让LoRA成为2026年最主流的微调方案——不是因为它效果最好，而是它在效果与成本之间提供了最优的性价比。 LoRA原理速览 LoRA的核心思想是冻结预训练权重，在旁边训练一个低秩矩阵： $$W_{new} = W_{pretrained} + \Delta W = W_{pretrained} + B \times A$$ 其中 $A \in \mathbb{R}^{r \times d}$，$B \in \mathbb{R}^{d \times r}$，秩 $r \ll d$。以7B模型为例，全参数微调需要更新70亿参数，而LoRA（r=8）只需更新约2000万参数，缩减了99.7%。 第一步：数据准备 数据格式标准化 推荐使用ShareGPT格式，兼容主流训练框架： { "conversations": [ {"from": "human", "value": "解释一下什么是联邦学习"}, {"from": "gpt", "value": "联邦学习是一种分布式机器学习技术..."} ] } 数据清洗管线 import json import re from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3-8B") def clean_and_filter(data_path, output_path, max_length=2048): """数据清洗与过滤管线""" cleaned = [] with open(data_path, 'r', encoding='utf-8') as f: raw_data = [json.loads(line) for line in f] for sample in raw_data: conversations = sample.get("conversations", []) if len(conversations) < 2: continue # 检查每轮对话质量 valid = True for turn in conversations: text = turn.get("value", "") # 过滤空回复 if len(text.strip()) < 10: valid = False break # 过滤过长回复 if len(tokenizer.encode(text)) > max_length: valid = False break # 过滤重复内容 if text.count("。") > 0 and text.count("。") / len(text) > 0.1: valid = False break if valid: cleaned.append(sample) with open(output_path, 'w', encoding='utf-8') as f: for sample in cleaned: f.write(json.dumps(sample, ensure_ascii=False) + '\n') print(f"原始数据: {len(raw_data)} → 清洗后: {len(cleaned)}") return cleaned 数据质量分布检查 在微调前务必检查数据分布，避免领域偏斜： ...

MoE架构的本质思想 混合专家模型（Mixture of Experts, MoE）的核心思想非常直观：不要让每个Token都经过所有参数的计算，而是为每个Token选择最合适的"专家"子网络来处理。这类似于医院分诊——患者不会被所有医生同时看诊，而是根据症状被分配给对应科室的专家。 MoE vs Dense模型对比 特性 Dense模型 MoE模型 参数利用率 100%（每个Token激活所有参数） 5-20%（仅激活部分专家） 总参数量 固定 可扩展至更大规模 训练成本 与参数量成正比 与激活参数量成正比 推理成本 与参数量成正比 与激活参数量成正比 模型容量 受限于计算预算 可用更大容量模型 MoE架构演进史 第一代：经典MoE（2017-2020） 最早的MoE思想可追溯到1991年Jacobs等人提出的自适应混合模型。在现代深度学习中，Google的GShard（2020）首次将MoE引入Transformer架构： # GShard MoE 的核心逻辑（简化版） import torch import torch.nn as nn import torch.nn.functional as F class MoELayer(nn.Module): def __init__(self, d_model, num_experts, top_k=2): super().__init__() self.num_experts = num_experts self.top_k = top_k # 门控网络 self.gate = nn.Linear(d_model, num_experts) # 专家网络（每个专家是一个FFN） self.experts = nn.ModuleList([ nn.Sequential( nn.Linear(d_model, d_model * 4), nn.GELU(), nn.Linear(d_model * 4, d_model) ) for _ in range(num_experts) ]) def forward(self, x): # x shape: (batch_size, seq_len, d_model) gate_logits = self.gate(x) # (batch, seq, num_experts) # 选择Top-K专家 gate_scores = F.softmax(gate_logits, dim=-1) topk_scores, topk_indices = torch.topk(gate_scores, self.top_k, dim=-1) # 归一化专家权重 topk_scores = topk_scores / topk_scores.sum(dim=-1, keepdim=True) # 计算加权输出 output = torch.zeros_like(x) for i in range(self.top_k): expert_idx = topk_indices[..., i] # (batch, seq) weight = topk_scores[..., i:i+1] # (batch, seq, 1) for e in range(self.num_experts): mask = (expert_idx == e) if mask.any(): expert_input = x[mask] expert_output = self.experts[e](expert_input) output[mask] += expert_output * weight[mask] return output 第二代：Switch Transformer（2021） Google在2021年提出的Switch Transformer将Top-2简化为Top-1路由，大幅降低了通信开销： ...

Hermes 4：开源对齐的里程碑 Nous Research的Hermes系列一直是开源大模型对齐研究的标杆。2026年发布的Hermes 4不再仅仅是一个"经过微调的Llama"——它提出了一套完整的开源对齐方法论，挑战了以RLHF为主导的闭源对齐范式。 架构全景 基座选择 Hermes 4基于Llama 4 70B构建，但进行了多项架构级修改： ┌─────────────────────────────────────────────┐ │ Hermes 4 架构 │ ├─────────────────────────────────────────────┤ │ ┌─────────┐ ┌──────────┐ ┌────────────┐ │ │ │ MoE路由 │ │ 长上下文 │ │ 工具调用 │ │ │ │ (64专家) │ │ (256K) │ │ 原生层 │ │ │ └────┬────┘ └────┬─────┘ └─────┬──────┘ │ │ │ │ │ │ │ ┌────▼────────────▼──────────────▼──────┐ │ │ │ 统一注意力层 │ │ │ │ (GQA + 滑动窗口 + 全局token) │ │ │ └────────────────────────────────────────┘ │ │ ┌────────────────────────────────────────┐ │ │ │ 对齐适应层 │ │ │ │ (Neutral Training + DPO + Constitutional)│ │ │ └────────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ 关键架构创新 1. 原生工具调用层 ...

引言 2023年，Ollama以"一行命令跑大模型"的极简体验横空出世，被不少人视为"本地玩具"。三年后的今天，Ollama已经部署在数百万开发者机器上，成为边缘推理场景的事实标准。从树莓派到工业网关，Ollama的足迹遍布各类边缘设备。本文将复盘这条演进之路。 三个阶段，三次跃迁 阶段一：极简体验（2023-2024） Ollama的初始定位非常清晰——让本地运行大模型像安装App一样简单： # 安装 curl -fsSL https://ollama.com/install.sh | sh # 运行 ollama run llama3 # 就这么简单 这一阶段的核心创新是GGUF格式统一和自动量化。Ollama封装了llama.cpp的复杂性，用户无需理解Q4_K_M、Q5_K_S这些量化术语，框架自动选择当前硬件最优的量化方案。 然而，此时的Ollama确实是个"玩具"： 单模型串行推理，无并发能力 API兼容性有限，只支持基本的生成接口 没有模型管理、版本控制等生产功能 阶段二：工程化转型（2024-2025） Ollama 0.3版本是一个分水岭。团队开始认真对待生产场景： # 多模型并发 ollama serve --max-models 4 --max-connections 128 # OpenAI兼容API curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:32b", "messages": [{"role": "user", "content": "解释量子纠缠"}] }' 关键改进包括： 并发推理：支持多模型同时驻留显存，按需切换 OpenAI API兼容：直接替换base_url即可迁移现有应用 Modelfile体系：类似Dockerfile的模型定义方式 # Modelfile示例 FROM qwen3:32b-instruct PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER num_ctx 32768 SYSTEM "你是一个专业的代码审查助手。" TEMPLATE """{{.System}} {{.Prompt}}""" 阶段三：边缘推理标配（2025-2026） 真正的转折点来自边缘计算场景的爆发。随着工业AI、智能家居、车载助手等场景对"本地推理+隐私安全"的需求激增，Ollama的独特价值被重新发现。 ...

引言 记忆是人类智能的基石，同样也是AI Agent的核心能力。一个没有记忆的Agent每次对话都从零开始，无法积累经验、学习偏好、维持连续性。OpenClaw在记忆系统设计上进行了深度工程探索，构建了一套从短期上下文到长期记忆的多层架构。本文将全面解析其设计与实现。 记忆的层次模型 OpenClaw将Agent记忆分为四个层次，类比人类认知科学中的记忆分类： ┌─────────────────────────────────────────────┐ │ Layer 4: 损失无关回忆 (Lossless Recall) │ ← LCM压缩与精确回溯 ├─────────────────────────────────────────────┤ │ Layer 3: 长期记忆 (Long-term Memory) │ ← MEMORY.md 策略性记忆 ├─────────────────────────────────────────────┤ │ Layer 2: 每日记忆 (Daily Memory) │ ← 按天组织的原始记录 ├─────────────────────────────────────────────┤ │ Layer 1: 工作记忆 (Working Memory) │ ← 当前会话上下文窗口 └─────────────────────────────────────────────┘ Layer 1: 工作记忆 工作记忆即模型的上下文窗口，是最快但最有限的记忆层： class WorkingMemory: """管理当前会话的上下文窗口""" def __init__(self, max_tokens: int = 128000): self.max_tokens = max_tokens self.messages: list[Message] = [] self.token_counter = TokenCounter() def add(self, message: Message): """添加消息，超出限制时触发压缩""" self.messages.append(message) if self.token_counter.count(self.messages) > self.max_tokens * 0.85: self._compact() def _compact(self): """上下文压缩策略""" # 保留最近N轮完整对话 recent = self.messages[-10:] # 将较早的消息压缩为摘要 older = self.messages[:-10] summary = self._summarize(older) self.messages = [summary] + recent 工作记忆的挑战在于上下文窗口的有限性。即使200K token的窗口也会在长对话中耗尽。OpenClaw的策略是渐进式压缩——先压缩最老的消息，保留最近对话的完整性。 ...

引言 在AI Agent的工程实践中，“如何扩展Agent能力"是一个核心问题。大多数框架选择将能力硬编码在Agent内部，或者通过插件机制实现有限的扩展。OpenClaw采用了不同的路线——技能系统（Skill System），一个完全可组合、可热插拔的能力扩展框架。本文将深入解析其设计理念与工程实现。 设计哲学 核心原则 OpenClaw技能系统的设计遵循三个核心原则： 声明式优先：技能通过自描述文件定义，而非命令式代码注册 可组合性：技能之间可以自由组合，不会产生副作用 渐进式复杂度：简单技能只需一个Markdown文件，复杂技能可以包含完整工具链 与传统插件系统的区别 维度 传统插件系统 OpenClaw技能系统 定义方式 代码注册（Python/JS） 声明式文件（SKILL.md） 激活机制 显式调用 意图匹配自动激活 组合能力 通常有冲突风险 设计上保证可组合 热插拔 需要重启 运行时动态加载 开发门槛 需要理解框架API 写Markdown即可入门 SKILL.md：技能的声明式定义 每个技能的核心是一个SKILL.md文件，它同时是文档、配置和激活规则： # SKILL.md - PDF处理技能 ## 描述 处理PDF文件的创建、读取、编辑、合并、拆分等操作。 当用户提到 .pdf 文件、要求处理PDF时触发。 ## 触发条件 - 文件扩展名为 .pdf - 用户消息包含"PDF"、"pdf"、"文档处理" - 用户拖拽PDF文件到对话框 ## 能力 - 读取/提取PDF文本和表格 - 合并多个PDF - 拆分PDF - 添加水印 - 填充PDF表单 - OCR扫描件 ## 工具依赖 - Python 3.10+ - pdfplumber - PyMuPDF - reportlab ## 使用示例 用户："把这个PDF拆分成每页一个文件" 动作：调用PDF拆分工具，输出多个PDF文件 关键设计决策 为什么用Markdown而非JSON/YAML？ ...