OpenClaw 目前是全球用户规模最大的自托管个人 AI 助手。从 AI Agent 开发者的视角来看，它不仅仅是一个 AI 工具，更是一个极具参考价值的真实世界 Agent 设计范例。它能够帮助我们在构建 Agent 时形成更加成熟、系统化的设计思路。

在本文中，我将探索 OpenClaw 的内部设计，并最终构建出一个概念模型。

概念模型

下图是我构建的 OpenClaw 概念模型：

OpenClaw 概念模型
（使用 Draw.io 打开）

该模型基于两个“事实来源”（source of truth）：

• OpenClaw 官方文档：https://docs.openclaw.ai/
  为了验证准确性，你可以在 draw.io 中打开该图，并点击图中指向文档的链接。
• 对运行中的 OpenClaw 进行 LLM Prompt 与 Tool Calling 的追踪分析

文档分析

官方文档 内容十分丰富，但其组织方式并不是“循序渐进式”的概念教学结构。因此，在阅读过程中，我经常会迷失在文档页面之间。

问题的核心在于：
文档缺乏一个整体性的概念地图，以及各个概念之间清晰、显式的关系描述。

在通读文档后，我尝试尽可能地提炼并还原这些概念之间的关联。

掌握 Prompt 追踪

绝大多数 AI 应用的“核心秘密”，都隐藏在其 LLM Prompt 之中。但对 LLM 流量进行追踪，往往就像掉进了一个由非结构化数据组成的兔子洞。

有效的可观测性（Observability）通常依赖两种主要方法：

• Tracing（追踪）
• Sampling（采样）

在我的实验环境中，我使用 OpenRouter 作为 LLM 网关。它支持一种名为 Broadcast 的追踪复制机制（文档）。
我将其配置为把追踪数据发送到我对外开放的、自托管的 Langfuse 服务。

环境准备

为了演示 Prompt 追踪，我们需要一个会触发 OpenClaw 执行特定 Skill 的场景。

我选择了自己自托管的 Home Assistant 实例（用于管理智能家居设备）作为目标环境。为了完成集成，我从以下地址安装了所需的 Skill：

https://clawhub.ai/dbhurley/homeassistant

并将其放置到目录：

~/.openclaw/workspace/skills/homeassistant

同时，别忘了设置环境变量（通常配置在 ~/.openclaw/.env 中）：

HA_URL=http://your-ha-host:8123
HA_TOKEN=your_ha_token

理解 Agent Skill 的“魔法”

打开 OpenClaw Dashboard，新建一个聊天会话，并输入以下 Prompt：

Any smart home device in my study room?

为什么要使用 OpenClaw Dashboard，而不是 IM 客户端？
虽然 OpenClaw 支持 Telegram、WhatsApp 等主流即时通讯工具，但在开发和调试阶段，原生 Dashboard 更具优势。
与普通聊天界面不同，Dashboard 提供了一个高可见度的“检查模式（inspection mode）”，能够实时展示：

• Agent 即将调用的 tool 及其参数
• 系统返回的原始执行结果
  这种透明性对于验证 Agent 行为至关重要。

接下来，打开 Langfuse Dashboard，进入 Tracing 页面。你将看到捕获到的一系列 Trace。
我们按时间顺序分析前两个 Trace，以理解 Skill 的发现、加载与调用机制。

1. Skill 发现

LLM 输入 —— Messages：

You are a personal assistant running inside OpenClaw.
...
## Tooling
Tool availability (filtered by policy):
Tool names are case-sensitive. Call tools exactly as listed.

- read: Read file contents
- write: Create or overwrite files
...
## Skills (mandatory)
Before replying: scan <available_skills> <description> entries.
- If exactly one skill clearly applies: read its SKILL.md at <location> with `read`, then follow it.
- If multiple could apply: choose the most specific one, then read/follow it.
- If none clearly apply: do not read any SKILL.md.
Constraints: never read more than one skill up front; only read after selecting.
The following skills provide specialized instructions for specific tasks.
Use the read tool to load a skill's file when the task matches its description.

<available_skills>
...
  <skill>
    <name>homeassistant</name>
    <description>Control Home Assistant - smart plugs, lights, scenes, automations.</description>
    <location>~/.openclaw/workspace/skills/homeassistant/SKILL.md</location>
  </skill>
</available_skills>

LLM 输入 —— Tool 声明：

tools: [
  {
    type: "function",
    function: {
      name: "read",
      description: "Read the contents of a file...",
      parameters: {
        type: "object",
        properties: {
          path: { "type": "string" },
...
          file_path: { "type": "string" }
        }
      }
    }
  }
]

LLM 输出：

completion: "read{\"path\": \"~/.openclaw/workspace/skills/homeassistant/SKILL.md\"}",
reasoning: "用户在询问书房里的智能家居设备，这与 Home Assistant Skill 完全匹配，因此需要加载该 Skill 的说明文档。"

此时，LLM 主动调用 read 工具，读取对应 Skill 的 SKILL.md 文件。

2. Skill 加载

Agent 接收到 LLM 的 Tool Call 后，执行 read，并将 SKILL.md 内容返回给 LLM。

LLM 输入（节选）：

messages: [
    ...
    {
role: "tool"
content: "---
name: homeassistant
description: Control Home Assistant - smart plugs, lights, scenes, automations.
homepage: https://www.home-assistant.io/
metadata: {"clawdis":{"emoji":"🏠","requires":{"bins":["curl"],"env":["HA_TOKEN"]},"primaryEnv":"HA_TOKEN"}}
---

# Home Assistant

Control smart home devices via Home Assistant API.

## Setup

Set environment variables:
- `HA_URL`: Your Home Assistant URL (e.g., `http://192.168.1.100:8123`)
- `HA_TOKEN`: Long-lived access token (create in HA → Profile → Long-Lived Access Tokens)

## Quick Commands

### List entities by domain
```bash
curl -s "$HA_URL/api/states" -H "Authorization: Bearer $HA_TOKEN" | \
  jq -r '.[] | select(.entity_id | startswith("switch.")) | .entity_id'
```
...

随后，LLM 输出：

completion: "exec{\"command\": \"curl -s \\\"$HA_URL/api/states\\\" -H \\\"Authorization: Bearer $HA_TOKEN\\\" | jq -r '.[] | select(.attributes.area_name // .attributes.room // .entity_id | contains(\\\"study\\\")) | {entity_id: .entity_id, name: .attributes.friendly_name, state: .state, area: (.attributes.area_name // \\\"N/A\\\")}' | head -20\"}"

在理解了 homeassistant Skill 的文档后，LLM 发起了一个 exec Tool Call，通过命令行访问 Home Assistant 的 HTTP API。

这里最巧妙的设计点在于安全性：

Agent 不会将真实的 Token 或凭据直接传递给 LLM。
Skill 使用环境变量来注入敏感信息，从而确保这些秘密：

• 不会暴露在 LLM 的上下文中
• 不会被记录在 Trace 历史里

这是一个值得借鉴的 Agent 安全设计模式。不过，OpenClaw 中充满了各种被业界认为不安全的设计，所以，参考时还需要多加甄别。

机器人领域的专家轨迹、互联网上的文本图像视频，这些数据让生成模型在机器人操控、语言生成与规划、视觉理解等任务上取得了惊人效果。但问题来了：换到具体任务上这些模型往往不太行。这是因为LLM 需要微调才能遵守安全约束或符合人类偏好，机器人策略也得继续训练才能弥补演示数据的不足。

扩散模型和流模型已经成为生成任务的主流方法，强化学习则是任务层面追求最优性能的老路子。两者结合就有了 DDPO、DPPO、FPO、Flow-GRPO 这些工作。这类方法普遍在数十亿参数、图像文本这种高维环境下运行，所以我们换个思路：在一个二维简单环境里研究训练细节，只优化单条去噪轨迹。

这个环境训练不到一分钟，计算资源几乎可以忽略。状态空间和动作空间都简单到指标没什么意义，不过真正有意思的是不同微调策略下涌现出来的视觉行为。虽然这里聚焦于 DPPO 和扩散策略（把数据当作"动作"），但微调动态完全可以推广到其他基于 RL 的扩散应用场景。

环境

定义一个"环形"高奖励区域，模型要学会把样本去噪到这个环的任意位置。观察点在于：模型会收敛到环上的某个模式，还是把样本均匀分布开？对环宽度的敏感程度如何？下面是一条去噪轨迹的例子：

期望行为：从随机初始化（噪声状态）走向高奖励区域，最后一步就是去噪完成的样本。

不过在开始之前我们先解释 DPPO 和相关术语，再尝试用这个算法优化扩散模型来生成高奖励样本。

DPPO 算法概述

DPPO 是 PPO 的变体，属于 on-policy 方法。核心思路是更新扩散模型参数让生成样本获得更高奖励。它把扩散过程建模成 MDP：每个扩散时间步是一个状态，动作就是"去噪"，奖励来自最终的去噪状态。奖励通过蒙特卡洛估计传播回有噪声的时间步——也就是对完整回合的折扣回报求平均来估计期望累积奖励。DPPO 论文里这张图讲得很清楚：

外循环先做回合采样，存下每个扩散时间步的动作对数似然，加上状态、动作、奖励这些标配。内循环跑 K 个 epoch，用 PPO 风格的目标更新扩散模型参数。PPO 的细节网上讲得很多，下面只展开相关部分。内循环结束后，用新策略再采样一批回合。损失包含信任域策略更新、价值函数损失和探索用的熵项。为简化起见，这里只看上图中的"t=0"这一步，对应单条扩散轨迹。

算法 1. DDPO + DDIM 实现的伪代码。第 5 行的"动作"就是去噪一个样本。

步骤 1：回合采样

 state = env.reset()  

# (aside: action variance is learned)  
action_var = nn.Parameter(torch.full((2,), action_std_init * action_std_init))  

current_pos = state[:2]  

# in the rollout...  
with torch.no_grad():  
    # conditional noise prediction  
    pred_noise = policy.actor(current_pos, t)  
    # the "T-1" prediction is the next position in the denoising trajectory  
    action_mean = policy.ddim_step(pred_noise, t, current_pos)  
    dist = Normal(action_mean, action_var.sqrt())  
      
    # sample from distribution with learned noise  
    action = dist.sample()  
    action_log_prob = dist.log_prob(action).sum(dim=-1)  

next_state, reward, done = env.step(action)  

# store in Buffer  
 buffer.states.append(state, action, action_log_prob, reward, done)  

这段代码对应 DPPO 论文公式 4.3。目前微调整个 DDIM 轨迹，后面会比较只微调最后几步的效果：

代码里去噪过程的每一步都被当作动作，这是 DPPO 内部 MDP 的关键。动作方差设为可学习参数，因为 DDIM 本身是确定性的，需要加探索噪声（公式里的 sigma）。

DDIM 步骤方法如下，求解概率流 ODE 得到去噪过程的前一步（参考伪代码里的公式）。这个操作必须可微，梯度才能流过去噪过程：loss → logprobs → dist → action → ddim_step → pred_noise → actor weights。噪声调度参数是预设好的。

 # DPPO differentiates through diffusion steps, so this needs to be differentiable  
def ddim_step(self, model_output, timestep, sample):  
    # Handle t-1 (if t=0, prev=0, but alpha_prev=1.0)  
    prev_timestep = torch.clamp(timestep - 1, min=0)  
    alpha_prod_t_prev = alphas_cumprod[prev_timestep].view(-1, 1)  
    alpha_prod_t = alphas_cumprod[timestep].view(-1, 1)  
    beta_prod_t = 1 - alpha_prod_t  
      
    # DDIM Formula  
    pred_original_sample = (sample - torch.sqrt(beta_prod_t) * model_output) / torch.sqrt(alpha_prod_t)  
    pred_sample_direction = torch.sqrt(1 - alpha_prod_t_prev) * model_output  
    prev_sample = torch.sqrt(alpha_prod_t_prev) * pred_original_sample + pred_sample_direction  
      
     return prev_sample

步骤 2：奖励缩放和 GAE

这部分基本是标准 PPO。跟踪运行统计量来归一化奖励，因为奖励方差太大会让价值函数训练不稳定。然后对缓冲区里所有状态跑一遍价值函数前向（不算梯度），用 GAE 从回报计算优势值，平衡偏差和方差。GAE 做的事情是给去噪过程中的"动作"分配功劳，价值函数则是为带噪声的状态建模这个功劳（注意输入里也带了扩散时间步）。

 # get values from buffer  
old_states = torch.cat(buffer.states, dim=0)  

# scale rewards using running statistics  
rewards_np = np.array(buffer.rewards)  
rewards_norm = (rewards_np - reward_scaler.mean) / (np.sqrt(reward_scaler.var) + 1e-8)  

# compute Values for GAE  
with torch.no_grad():  
    x_t = old_states[:, :2]  
    t_long = old_states[:, 2].long()  
    # Get values from critic  
    values = policy.critic(x_t, t_long)  

advantages = []  
last_gae_lam = 0  

# iterate backwards through the buffer  
# buffer.is_terminals tells us if the episode ended at that step  
for step in reversed(range(len(buffer.rewards))):  
    if step == len(buffer.rewards) - 1:  
        next_non_terminal = 1.0 - float(buffer.is_terminals[step])  
        next_val = next_value  
    else:  
        next_non_terminal = 1.0 - float(buffer.is_terminals[step])  
        next_val = values[step + 1].item()  
          
    # Delta = r + gamma * V(s') * mask - V(s)  
    delta = rewards_norm[step] + gamma * next_val * next_non_terminal - values[step]  
      
    # Advantage = Delta + gamma * lambda * Advantage_next * mask  
    last_gae_lam = delta + gamma * gae_lambda * next_non_terminal * last_gae_lam  
    advantages.insert(0, last_gae_lam)  
   
# Compute Returns: Return = Advantage + Value  
# This is the target for the Value Function  
returns = advantages + values  

# Normalize Advantages (Standard PPO trick)  
 advantages = (advantages - advantages.mean()) / (advantages.std() + 1e-8)

步骤 3：PPO 更新

优化策略，降低低优势动作的概率，提高高优势动作的概率。这个过程跑多个 epoch 以充分利用缓冲区数据，不是更新一次就扔掉。每次迭代策略都在变，所以要在新策略下重新计算旧动作的对数概率，用新旧比率控制策略改进幅度。后面会实验不同的裁剪参数（eps clip）。

 # next state (from previous cell)  
state = next_state  

old_actions = torch.cat(buffer.actions, dim=0)  
old_logprobs = torch.cat(buffer.logprobs, dim=0)  

# K epochs define how   
for _ in range(K_epochs):  
    x_t = old_states[:, :2]  
    t_long = old_states[:, 2].long()  

    pred_noise = policy.actor(x_t, t_long)  
    mean_action = policy.ddim_step(pred_noise, t_long, x_t)  
      
    # learnable action variance (defined during rollout)  
    dist = Normal(mean_action, action_var.sqrt())  
    # recalculate log probs under new policy for policy ratio  
    logprobs = dist.log_prob(old_actions).sum(dim=-1)  
    ratios = torch.exp(logprobs - old_logprobs)  

    surr1 = ratios * advantages  
    surr2 = torch.clamp(ratios, 1-eps_clip, 1+eps_clip) * advantages  
    policy_loss = -torch.min(surr1, surr2)  
       
    # compute V(s) with gradients this time, to train value function  
    state_values = policy.critic(x_t, t_long)  
    value_loss = 0.5 * nn.MSELoss()(state_values, returns)  
      
    # there can also be an entropy term and KL term here, but omit for now  
     loss = policy_loss + value_loss

DPPO 和 DDPO 的区别

网上几乎没有对比这两个名字容易混淆的方法：Denoising Diffusion Policy Optimization（DDPO）和 Diffusion Policy Policy Optimization（DPPO）。DDPO 针对文本生成图像，DPPO 针对扩散策略优化。动机差异之外，DDPO 用按 prompt 的奖励归一化，"类似于价值函数基线"；DPPO 用更成熟的 GAE 加上显式学习的价值函数。概念上真的很难分清楚，不过这里的实现因为用了 GAE，技术上算 DPPO。

从头训练 DPPO（失败）

理论上跟 PPO 一样，给够回合数就能最大化奖励。但 RL 和实际训练里，样本效率才是命门。模拟环境确实降低了采样成本，可灵巧操控这种 sim2real 效果差的任务，还是得靠真实演示用尽量少的回合搞定。所以先试试只用 300 个回合从头训练，看看性能曲线。下图和后续图里，蓝点是去噪后的样本，训练过程中定期评估。

300 个回合后 DPPO 完全没收敛，样本压根没往高奖励区域靠。扩散模型本身就需要大量样本，再叠上 RL 臭名昭著的样本低效，失败并不意外。就算加到 5000 个回合，超参不仔细调也收敛不了。

从专家演示微调

现实场景里不可能有无限回合，所以专家演示通常够引导奖励最大化。要模拟"专家演示"，需要一个分布：接近高奖励区域的多个模式，大体形状像那么回事，但又留有 RL 优化空间。于是选了一个半径 1.0 的圆形分布，用监督学习训练扩散模型去噪到这个区域——可以类比从演示学习或在互联网数据上预训练。30k epoch 后几百个样本的可视化效果如下：

微调前的预训练动作分布（去噪轨迹未画出）。

加载预训练 checkpoint 再跑 DPPO，性能提升明显行为也符合预期：大约 150 个回合后粒子开始收敛到高奖励区域。不过通常是找到第一个被探索到的高奖励模式，而不是均匀分布在 radius=1.5 的环上。

DPPO 微调把动作从 radius=1 的预训练分布引导到 radius=1.5 的高奖励区域，比从头训效果好太多

添加 KL 约束

Flow-GRPO 等工作在 PPO 目标之外加了 KL 约束。对 LLM 和图像生成模型（Flow-GRPO 的主要场景），偏向有效文本和语义正确的图像是有道理的。机器人领域不太在意行为克隆的真实分布，只是借它引导通常稀疏且初次难以成功的高奖励区域（比如到底拿没拿起咖啡杯）。但如果用的是可能被"利用"的密集奖励，KL 约束就有用了——比如"杯子举多高"这种奖励，很容易被往上抛的动作钻空子。

DPPO 和 Flow-GRPO 目标对比如下：

DPPO 目标

Flow-GRPO 目标

Flow-GRPO 的组大小 G 可以替代 GAE 做优势估计。KL 约束确保新策略不会偏离原策略太多，能防止收敛时的发散行为。策略比率则保证更新幅度不要太大。加上 KL 后损失变成：

带 KL 约束的新 DPPO 目标

观察到的现象是：动作没有像之前那样收敛到一两个模式，而是保留了更多圆形分布的形状，分散在多个奖励模式周围。总奖励偏低，但这在预期之内。Flow-GRPO 论文也有类似发现：

…我们发现省略 KL 会导致视觉多样性崩溃，这是一种奖励利用的形式…（第 5.2 节）

分布在多个高奖励模式上，对应现实中完成任务有多种方式的情况（可以抓杯身也可以抓杯把）。KL 约束还能增加泛化性，防止只收敛到单一高奖励模式。比如普通 DPPO 可能只学会抓杯身，碰到杯子烫得不行的分布外场景就傻了；加了 KL 约束的 DPPO 还知道可以抓杯把。

即便抓杯把本来不在演示分布里，这个好处也可能成立。值得后续研究的问题是：PPO 更新中的 KL 约束到底保持的是预训练分布的形状，还是分布本身？在这个玩具环境里，如果带 KL 的 DPPO 最优策略确实收敛到均匀分布在 radius=1.5 圆上，就可以定性地说形状被保留了，只是低奖励特性被替换。如果 KL 只是把动作值锁在 radius=1.0，那就不成立了。

消融实验

微调跑通之后，就可以看看 PPO 各组件对性能的影响。

只微调最后几个扩散步骤

DPPO 论文建议提高效率的做法是：预训练后复制两份模型，一份冻结用于去噪前面的时间步，另一份微调用于去噪最后几步（附录 C.2 建议 10% 来平衡效率）。但在这个环境里，30% 到 50% 似乎更合适（总共 50 个去噪步骤）。

只微调最后 10%、30%、50% 的步骤（从左到右）。30% 到 50% 之间效果明显更好

这个环境还可以对比不同设置下的扩散轨迹，训练结束后可视化 20 个样本：

只微调最后 10%、30%、50% 步骤的采样轨迹（从左到右）

放大 10% 微调步骤产生的轨迹（最左边），可以看到样本越过预训练流形后有个向高奖励区域的急剧"转向"。转向后面的去噪步骤就是被微调的模型。有意思的是，微调步骤越多，这个转向越平滑，但预期还是会在某个地方出现——最左边轨迹在第 90 百分位步骤能看到，中间轨迹偶尔在第 70 百分位出现，最右边第 50 百分位已经是平滑过渡了。如果转向的急剧程度和微调效果差相关（急剧可能意味着最后几步过度补偿），那可以考虑用轨迹急剧程度作为拟合质量的指标，尤其是高维场景下不容易定位问题的时候。

跟微调整个轨迹的结果对比：

线条颜色更深，说明显著地把样本推向了高奖励区域，初始扩散步骤的重要性可见一斑。

策略比率 eps clip 和学习率的交互

直觉上这两个东西作用类似。策略比率控制策略变化速度，actor 学习率也决定这一点。

低/高 clip 与学习率的对比（clip = 0.1/0.4，lr = 1e-4, 5e-3）。高 clip 意味着允许更大的策略偏移

学习率的影响压过了策略裁剪，这说得通——参数空间偏移太大的话，策略比率会变得巨大。跑了几个实验后结论很清楚：学习率最需要调，策略裁剪挡不住过激更新（哪怕 clip 设到 0.01 配上高学习率也没用）。有意思的是，低学习率似乎有助于保留奖励区域的多个模式。

移除策略比率

完全去掉策略比率，min() 两边都设成优势值乘对数概率（注意如果只用 A 不带 log prob，梯度就断了）。动作收敛到比不加 KL 项更紧密的分布（跟上一节高 clip 结果很像），不过奖励依然挺高。这也暴露了环境复杂度的局限——没有性能掉下去就回不来的区域，而策略比率本来就是为防这个设计的。不过有趣的是，这又是一个能防止奖励模式崩溃的因素。另一个有趣现象是训练久了会在多个奖励模式之间跳——像是高学习率行为的稍微稳定版。

其他超参的一些观察

优化 epoch 数确实和 eps clip 成反比，两个超参都在权衡每次更新的策略改进幅度。

DPPO 更新间隔的时间步数和学习率成反比，两者都在权衡策略改进的速度。

总结

这篇文章解释了如何为单步环境中的扩散模型实现 DPPO，希望能提供一个比典型机器人环境更容易理解训练动态的平台。跑了只微调最后几个去噪步骤、调各种 PPO 超参的实验。大家可以自己从这些结果里得出结论，也可以动手改改环境，看能不能提升样本效率——这仍然是 PPO 的关键瓶颈。

代码在这里：https://avoid.overfit.cn/post/f27f00300f6c4bf79312ed79a23ae9df

作者： Neel

2024 年 10 月 8 日，John Hopfield 和 Geoffrey Hinton 凭借在人工智能领域的奠基性工作获得了诺贝尔物理学奖。这一决定最初让许多人感到困惑：为什么计算机科学的成就被归入了物理学？

诺贝尔委员会的答案揭示了一个深刻的真理：现代 AI 的核心算法并非凭空创造的数学游戏，而是深深植根于描述自然界物质行为的物理定律中。从磁铁的微观结构到统计热力学，再到量子场的宏大理论，AI 正是物理学在数字世界的一种镜像。

以下是这一跨学科奇迹背后的四个核心物理支柱。

1. 从磁铁到记忆：伊辛模型与能量景观

要理解 AI 如何“记忆”，首先需要审视磁铁的物理本质。

在物理学中，伊辛模型 (Ising Model) 被用来解释铁磁性。想象一个微观网格，格子里充满了原子，每个原子都有一个“自旋”方向（向上或向下）。原子倾向于与邻居保持一致（如果邻居向上，我也向上），因为这样系统的总能量最低、状态最稳定。

1982年，John Hopfield 受到这个物理模型的启发，构建了 霍普菲尔德网络 (Hopfield Network)：

• 原子变成了神经元：原本的原子自旋变成了人造神经元的“激活” (1) 或“未激活” (-1) 状态。
• 磁力变成了权重：原子间的相互作用变成了神经元连接处的“权重” (Synaptic Weight)。

Hopfield 网络最精妙的地方在于它引入了 能量景观 (Energy Landscape) 的概念。可以将网络的所有可能状态想象成一片连绵起伏的山地：

• 学习即“挖坑”：当教 AI 记住一个图案时，实际上是在调整连接权重，在能量地形上“挖掘”出一个低能量的山谷（势阱）。
• 回忆即“滚动”：当给 AI 一个残缺的图案（相当于把弹珠放在山坡上），根据物理学趋向最低能量的原理，弹珠会自动滚入最近的山谷。这意味着网络能自动从噪点中“恢复”出最初记忆的完整图像。

2. 从固执到灵活：Hinton 与热力学的魔法

Hopfield 网络虽然天才，但有一个致命缺陷：如果弹珠滚进了一个很浅的坑（局部最优解），它就会卡在里面出不来，无法找到真正的深谷（全局最优）。这就好比 AI 陷入了思维定势。

Geoffrey Hinton 引入了统计物理中的 “温度” (Temperature) 概念，将 Hopfield 网络升级为 玻尔兹曼机 (Boltzmann Machine)。

他借用了冶金学中的 “模拟退火” (Simulated Annealing) 原理：

• 加热：在训练初期，给系统极高的“温度”。这意味着弹珠会剧烈抖动（引入高随机噪声），即使遇到小坑也能轻易跳出来。
• 降温：随着时间推移，逐渐降低温度，让弹珠慢慢稳定下来，最终有极大概率落入整个地形中最深的山谷。

正是这种受热力学启发的“随机性”，让 AI 摆脱了死记硬背，拥有了举一反三的生成能力。

3. 数学的幽灵双胞胎：神经网络与量子场

如果说磁学解释了 AI 的记忆，热力学解释了 AI 的学习，那么 量子场论 则揭示了 AI 更深层的数学结构。这一联系之紧密，可以通过著名的 模型 (The Phi-Fourth Model) 和一个直观的类比来理解。

场景 A：无限宽网络 = 宇宙真空的涨落

为了理解这一点，我们可以想象一台拥无限多个像素点（神经元）的巨大电视屏幕。

• 现象：如果你随机初始化这些像素的亮度。虽然每个点是随机的，但如果你统计整个无限屏幕的亮度分布，它会呈现出一个完美的钟形曲线（高斯分布）。
• 物理对应：这就像量子力学中的“真空”。真空不是空的，而是充满了随机的能量波动。如果没有粒子相互作用（自由场），这些波动的统计规律也正好是完美的钟形曲线。
• 结论：一个什么都没学的、无限大的 AI 大脑，它的“脑电波”底噪，和宇宙真空的量子涨落是一模一样的。

场景 B：有限宽网络 = 粒子碰撞与 模型

但现实中的 AI 网络是有限的，就像把那台巨大的电视变小了。

• 现象：因为像素（神经元）变少了，随机性的统计规律开始出现偏差，钟形曲线不再完美。
• 物理对应：这就像在真空中放入了真实的粒子。粒子不再是孤独的，而是开始相互作用（碰撞、吸引）。物理学家使用 模型 来描述这种粒子成对相互作用的情况。

惊人的同构

最令人震惊的发现在于：为了描述有限宽神经网络的偏差，科学家所使用的数学修正公式，竟然和物理学家用来计算 模型中粒子碰撞的公式是 同构（结构相同） 的。

这也让物理学家找到了解开 AI 黑盒的钥匙——费曼图 (Feynman Diagrams)。这一物理学家算了几十年的、用来描述粒子碰撞的图解工具，现在竟可以用来精确分析神经网络的内部运作。

4. 创造的物理学：扩散模型与墨水实验

这一跨界融合的终极案例，是目前驱动 Midjourney、Sora 等生成式 AI 的核心——扩散模型 (Diffusion Model)。

它的灵感直接来源于 非平衡热力学。为了理解它，我们可以把生成一张图片的过程想象成“让时间倒流”。

正向过程：熵增与毁灭（Destruction）

想象你有一张清晰的照片，或者一滴滴入清水的浓墨。

• 物理现象：随着时间推移，墨水分子做布朗运动（无规则运动），图像逐渐模糊，最终变成一盆均匀的、毫无信息的灰水。
• 数学本质：这是一个不断叠加高斯噪声的过程。在物理学中，这对应着熵增（Entropy Increase），即系统从有序走向无序。这是宇宙最自然的法则，不需要学习。

逆向过程：逆熵与重塑（Creation）

AI 的任务是挑战热力学第二定律：它要学会如何把这盆灰水还原回那滴墨水。

• 学习机制：科学家训练 AI 观察无数张图片被“加噪”的过程。AI 并不需要一次性复原图片，它只需要学会预测“每一步加了什么噪声”。
• 生成的艺术：当你要 AI 画画时，你其实是给它一团完全随机的噪点（一块杂乱的大理石）。AI 开始运行“逆向扩散方程”，根据你的提示词，一步步减去噪声。

雕刻家的比喻

这就像米开朗基罗雕刻大卫像。以前的 AI（如 GAN）试图一次性堆叠出完美的形状，容易倒塌；而扩散模型则是雕刻。
它面对的是一块包含所有可能性的“噪声大理石”，利用物理方程作为凿子，通过成百上千次微小的操作，剔除多余的杂质（噪声），最终让藏在石头里的图像“显形”。

没有流体力学和热力学的方程，就没有今天生成式 AI 的爆发。

结语

2024 年的诺贝尔物理学奖并非一次跨界的勉强，而是一次某种意义上的“归宗”。

物理学研究的是“上帝”构建的神经网络（宇宙），而 AI 研究的是人类构建的宇宙（神经网络）。这两个领域的殊途同归或许暗示着，智能并非碳基生物的特权，而是物质复杂到一定程度后，为了降低系统熵值而产生的一种必然物理现象。

AI 的物理学，才刚刚开始。

本文由mdnice多平台发布

写 Symfony 项目时，琐碎且重复的底层工作其实挺让人头疼的，比如处理文件上传、写 CRUD 界面、同步数据库时间戳。如果每个项目都从零开始，不仅容易加班，代码还容易出 Bug。

我总结了 9 个 Symfony 扩展包。这些工具解决的都是开发中躲不开的痛点。

FOSElasticaBundle：让全文搜索快起来

当数据库数据量达到几十万条时，用 LIKE %...% 搜索会变得非常慢。FOSElastica 把 Elasticsearch 集成到了 Symfony 中。

我们可以直接通过 Finder 服务来搜索索引中的内容：

$results = $container->get('fos_elastica.finder.app.article')->find('搜索关键词');

它最省心的地方在于，当你用 Doctrine 保存实体时，它会自动把数据同步到 Elasticsearch。

StofDoctrineExtensionsBundle：别再手动更新时间戳

以前每建一个表，我都要在 Entity 里写 setCreatedAt。一旦忘了写，数据追踪就断了。这个扩展包最常用的功能就是自动处理时间和生成 URL 别名（Slug）。

只要在字段上加个注解，剩下的事就不用管了：

use Gedmo\Mapping\Annotation as Gedmo;

class Post
{
    // 创建时自动填充
    #[Gedmo\Timestampable(on: 'create')]
    #[ORM\Column]
    private \DateTime $createdAt;

    // 只要有改动就自动更新
    #[Gedmo\Timestampable(on: 'update')]
    #[ORM\Column]
    private \DateTime $updatedAt;

    // 根据标题自动生成唯一的 URL 别名，不用自己写正则过滤
    #[Gedmo\Slug(fields: ['title'])]
    #[ORM\Column(length: 150)]
    private $slug;
}

LiipImagineBundle：搞定各种尺寸的缩略图

如果让用户直接上传 5MB 的图片并在列表页展示，页面加载会非常慢。LiipImagine 的思路是：原图存一份，缩略图按需生成并缓存。

在模板里直接调用定义好的滤镜：

{# 自动生成并调用 120x120 的裁剪缩略图 #}
<img src="{{ asset(product.image) | imagine_filter('thumbnail_120') }}" />

EasyAdminBundle：半天搭建出一套后台

如果项目需要一个后台管理界面，没必要从 HTML 模板写起。EasyAdmin 几乎是 Symfony 开发者的首选，它能通过简单的 PHP 类配置出完整的 CRUD。

class ProductCrudController extends AbstractCrudController
{
    public static function getEntityFqcn(): string
    {
        return Product::class;
    }

    public function configureFields(string $pageName): iterable
    {
        yield TextField::new('name');
        yield MoneyField::new('price')->setCurrency('CNY');
    }
}

VichUploaderBundle：文件上传不再乱糟糟

手动写文件上传要判断后缀、重命名防止冲突、还要在数据库记录路径。而 VichUploader 把这些流程标准化了。

只需要在配置文件里定义好映射，在 Entity 里绑定一个 File 对象即可：

#[Vich\Uploadable]
class UserProfile
{
    #[Vich\UploadableField(mapping: 'avatars', fileNameProperty: 'imageName')]
    private ?File $imageFile = null;

    #[ORM\Column]
    private ?string $imageName = null;

    public function setImageFile(?File $imageFile = null): void
    {
        $this->imageFile = $imageFile;
        if ($imageFile) {
            $this->updatedAt = new \DateTimeImmutable();
        }
    }
}

KnpPaginatorBundle：分页逻辑一劳永逸

写分页最烦的就是算偏移量和总页数。我习惯直接把 Query 对象丢给 KnpPaginator，它能自动处理分页逻辑。

// 在 Controller 里
$pagination = $paginator->paginate(
    $queryBuilder, 
    $request->query->getInt('page', 1), 
    12 // 每页数量
);

return $this->render('list.html.twig', ['pagination' => $pagination]);

在 Twig 里一行代码就能渲染出分页条：{{ knp_pagination_render(pagination) }}。

SchebTwoFactorBundle：安全加固其实很快

现在很多项目要求增加双重验证（2FA）。自己写验证码逻辑和 Google Authenticator 绑定很费劲，这个扩展包把安全流程都写好了。

只需要在 security.yaml 里开启：

security:
    firewalls:
        main:
            two_factor:
                auth_form_path: 2fa_login
                check_path: 2fa_login_check

它会自动处理验证码的校验逻辑，我们只需要关注 UI 界面。

JMSTranslationBundle：多语言翻译不抓瞎

做多语言项目时，最怕漏掉某个页面的翻译键值。这个包能扫描整个项目，把所有需要翻译的内容提取出来。

# 执行这个命令，它会自动更新你的 translation.yaml 文件
php bin/console translation:extract zh --config=app

它会找出所有 trans 标签和方法调用的内容，我们只需要对着文件填空，不用担心遗漏。

MakerBundle：高效生成的命令助手

这是大家最熟悉的，但很多人只用它生成 Entity。其实它能做的事情非常多，比如生成权限控制（Voter）或者自定义命令。

# 快速生成一个权限检查器
php bin/console make:voter PostVoter

# 快速生成一个 CRUD 完整流程（含 Controller、Form、Template）
php bin/console make:crud Product

养成使用命令行生成的习惯，能规避很多手写代码带来的低级错误。

在本地开发 Symfony 时，就不得不提配置 PHP 环境。有时候老项目要用 PHP 5.6，新项目要用 PHP 8.3，不同项目需要的扩展还不一样，在电脑里装一堆版本切来切去非常痛苦。

我最近在用 ServBay，它不仅能一键安装 PHP版本，支持 PHP 5.3到 PHP 8.6-dev，并且支持多版本 PHP 同时并存。

以前换个环境可能要折腾半天 Docker 或虚拟机，ServBay 是一键安装的，它把 PHP、MariaDB、PostgreSQL、Redis、Elasticsearch 这些开发常用的组件都集成在一起了。最方便的是，可以在一个界面里同时运行多个 PHP 版本，不用为了跑一个老项目去重装环境。

如果也受够了在本地折腾 brew install 或者改各种配置文件，尝试用 ServBay 配合上面这些 Bundle，能把更多精力放在业务逻辑上，开发节奏会顺畅很多。

最后

不要再把时间浪费在手动写上传和分页这种琐事上了。要么学会利用现成的轮子，要么就在无意义的搬砖中耗尽职业热情。你会发现，原来高质量的开发真的可以很快。

真实场景：当紧急故障来袭

监控器突然告警："支付服务不可用"。你猛地坐起来，打开手机——群里已经炸了，但没人知道谁负责处理。你一边翻聊天记录，一边开电脑查监控，还要同步问DBA、开发 等终于定位问题时，已经过去了40分钟。这是运维同学的日常。

几个核心概念

故障（Incident）

• 在观测云里，故障（Incident）由监控器触发，例如"支付服务不可用"。
• 关键特点：故障是对业务可用的威胁，必须有专人立即响应处理。

什么是值班（On-Call）？

系统 7×24 小时运行，但人不能 24 小时盯着屏幕。On-Call 就是一种轮班值守机制，确保任何时间点都有明确的人负责响应问题。

什么是升级？

现实场景：值班（On-Call）的手机静音了，没听见告警，后续也没人解决问题，故障越来越严重。

升级就是解决这个问题的兜底机制：规定时间内无人响应，自动并且持续扩大通知范围直到问题被解决。

关键原则：升级是确保关键故障必有响应和解决。

核心问题：为什么需要故障中心？

故障中心解决的是流程问题：谁来处理？处理到哪一步了？有没有升级机制？

场景一：告警无人响应

监控器触发 P0 告警"支付服务不可用"，短信发给了一个"技术值班"群时无人响应。然后就是客服热线被打爆，老板才知道出了故障。

传统方式：告警发出后，没有明确的负责人和跟进机制。

观测云故障中心：通过值班（On-Call）明确责任人，通过升级策略确保无人响应时自动扩大通知范围。如果故障在规定时间内未被认领，系统按预设规则升级通知。例如：

• T+0 分钟：不断通知值班人员，直至问题被解决
• T+20 分钟：如果状态仍为待分配（Open），不断通知团队负责人解决问题（也支持同时通知值班人员）
• T+60 分钟：不断通知部门经理解决问题

确保关键故障不遗漏、不悬置、有结果。

场景二：处理过程混乱

在紧急故障处理过程中时常出现没人知道当前谁在主导处理，处理到哪一步，历史操作记录在哪里，需要不断在群里跟进。

传统方式：故障响应依赖群聊同步，信息碎片化；

观测云故障中心：

• 状态管理：待分配（Open） → 处理中（Working） → 已解决（Resolved） → 已关闭（Closed），每一步清晰可追溯
• 唯一负责人：只有当前负责人能变更状态，避免多人重复处理或互相推诿
• 操作记录：每个动作、每次通知、每次交接都有据可查

支持多团队轮换（工作日 A/B 团队，周末 C/D 团队）、标签匹配（DB 故障找 DBA）、时区设置（跨国团队协作），让值班体系真正落地。

场景三：数据孤岛

确认故障后，需要同时打开监控面板看指标趋势，日志查询看错误日志，链路追踪看调用链，基础设施看主机状态。在 4 个 Tab 来回切换以拼凑故障全貌。

故障中心自动关联所有故障（Incident）有关上下文，状态一页看完，大幅减少 MTTR。

实际使用场景

假设监控器检测到"支付服务不可用"，自动创建 P0 故障：

• 值班通知：立即电话 + 短信通知当前值班人 A
• 认领响应：A在故障中心点击"认领此故障（Incident）"，状态变为 Working，A 成为唯一负责人
• 查看上下文：故障（Incident）详情页自动展示最近 2 小时的关联数据
• 协调处理：A 发现是数据库问题，@DBA 团队在协作记录中沟通
• 状态流转：服务恢复后，A 标记 Resolved，观察稳定后关闭（Closed）

如果 A 在 15 分钟以内未认领故障（Incident），系统自动升级到团队负责人 B；30 分钟仍未处理，升级到技术总监 C。每个状态变更，通知发送，负责人交接都有记录。

人性化设计

值班人员可在个人状态标记"休假中"，系统将自动跳过，通知下一位值班人。避免"人在沙滩躺着还被告警吵醒"的情况。

同时对于排班管理员来说，也可以避免因为有人临时休假而需要频繁修改排班。

总结：故障中心给SRE和运维带来什么？

观测云故障中心是一套让故障"必有响应、必有流程、必有结果"的SRE工作流。

减少 MTTR，降低业务损失，让运维同学睡个好觉。

观测云故障中心，现已上线！

近日，AI 原生应用开源开发者沙龙·上海站圆满落幕。本场活动吸引了 120+ 名技术从业者深度参与，聚焦 AI 原生应用架构领域的开源技术与落地实践， 围绕 AgentScope Java 1.0 发布、HiMarket、Higress、LoongSuite、RocketMQ 等议题展开深度分享，并设置了动手实操环节。

关注「阿里云云原生」公众号，后台回复：0127

免费获得上海站讲师 PPT 合辑

精彩回顾

议题一：AgentScope Java 1.0 发布丨何家欢(屿山) AgentScope Maintainer Alibaba Sentinel PMC

AgentScope 是阿里巴巴推出的一款以开发者为核心，专注于智能体开发的开源框架，是继 ModelScope 在 AI 智能体领域的战略级产品。AgentScope Java 提供生产级能力支持，覆盖从开发到持续进化的全流程。核心优势包括：领先的开发范式，默认提供 ReAct 范式、实时介入、高效工具调用和强大的内置工具；开箱即用的且生产就绪的企业级能力；强大的生态帮助开发者开发一个越用越好用的智能体。

议题二：HiMarket：企业私有化 AI 开放平台丨徐靖峰(岛风) Higress Maintainer & HiMarket Maintainer

HiMarket 是企业级 AI 开放平台，提供 AI 应用落地的最短路径，集 AI 场景创新、市场构建与治理于一体。支持自然语言对话、文生图、联网搜索等快速验证，构建 Agent、模型、MCP 等多类型 AI 资源共享市场，并具备统一权限、安全审核、计量计费等治理能力。平台采用云原生与 AI 原生架构，基于 Higress 和 Nacos 实现，通过开源推动生态共建，助力企业实现 AI 应用的规模化、合规化与货币化，应对 AI 普及中的管理、安全与成本挑战。

议题三：Higress for Gateway API： 兼容新一代标准的推理服务智能路由丨赵源筱(如漫) Higress Maintainer

Higress 已从云原生 API 网关升级为 AI 原生智能网关，在模型集成、工具调用、安全合规与稳定性保障等方面提供丰富而先进的能力；将在 v2.2.0 版本中全面兼容最新版 Gateway API 与 Gateway API Inference Extension (GIE)，支持基于 GIE 的推理服务智能负载均衡能力；同时持续联动 AgentScope、Dify 等生态，共建 AI Infra 与 AI 应用双轨体系，推动开源协同与开发者共建。

议题四：LoongSuite 在多模态 Agent 时代的观测新解法丨余韬(迅飞) LoongCollector Maintainer LoongSuite Contributor

LoongSuite 是面向多模态 Agent 时代的高性能可观测性开源方案，将传统文本日志升维为可检索、可分析的“认知资产”；创新兼容 OpenTelemetry 语义标准（含 Modality 规范），通过异步采集、解耦数据结构、剔除 Base64 冗余等技术，突破现有方案在查询效率、性能损耗等“四大硬伤”；已支持 Python/Java/Go 及 LangChain、DashScope 等 AI 框架，致力于打造最懂生成式 AI 的端到端可观测套件。

议题五：Apache RocketMQ for AI：面向 AI 应用的异步解决方案丨张硕(墨岭) RocketMQ Maintainer

RocketMQ 面向 AI 应用场景推出异步架构升级，首创轻量级事件载体 LiteTopic，支持百万级动态队列、自动生命周期管理及差异化/独占订阅模型；基于此实现用户级精细化流控与全异步 AI 会话网关等场景，具备断连恢复、无状态重连能力，解决了 AI 场景下的多智能体（Multi-Agent）通信、大规模任务调度及长会话状态管理等问题，为构建企业级 AI 应用与微服务应用提供可靠异步通信基础设施。

此外，现场设置了动手实操环节，讲师详细介绍了如何基于 AgentScope 搭建狼人杀小游戏，以及如何通过 RocketMQ 实现多智能体异步通信，并带领用户现场动手实操，互动交流热烈。

现场精彩瞬间

近期，阿里云人工智能平台 PAI 的视频编辑算法论文在 AAAI2026 上正式亮相发表（Zero-to-Hero: Empowering Video Appearance Transfer with Zero-Shot Initialization and Holistic Restoration）。AAAI 是人工智能领域最具影响力的国际顶级会议之一，旨在为研究人员、工程师与产业界专家提供交流平台，展示在机器学习、计算机视觉与生成式 AI 等方向的最新研究成果与应用进展。此次入选标志着阿里云人工智能平台 PAI 在视频编辑算法方面的研究获得了学术界的充分认可。

视频编辑的目标是根据用户需求对目标视频进行修改，其中“外观编辑”是一类关键任务：在尽可能保留视频结构与运动模式的前提下，改变目标主体的颜色、纹理或整体风格。过往主流方法多采用文本提示（prompt）引导编辑，但文本表达往往存在歧义，且难以精确描述细粒度外观（例如复杂配色、局部纹理布局等），从而限制了用户对编辑结果的精细控制。因此，更符合真实创作流程的方案是“参考图驱动的视频编辑”：用户先对某一帧进行精修，得到理想外观的参考图（可通过 Photoshop、ComfyUI 或任意图像编辑工具完成），再将该外观一致地传播到后续帧中（如图1所示）。这类任务天然地将问题拆解为两步：先获得高质量参考帧，再实现跨帧外观一致传播。

 图1. 我们提出的视频编辑算法与主流方法的对比

尽管参考图驱动的视频外观传播已有不少探索，但现有方法仍面临明显局限。一类方法依赖光流估计来对齐并传播外观特征，其效果容易受到光流精度影响，在大幅运动、遮挡或复杂镜头变化下会明显退化；另一类方法基于图生视频（I2V）模型进行反演与去噪传播，但往往受显存限制约束视频长度，且轻量时序建模对大运动范围适应不足。此外，近年来一些零样本（zero-shot）外观迁移方法通过干预扩散模型的注意力机制实现跨帧传播，虽然能提升鲁棒性，但往往会引入复合画质退化，例如模糊、颜色缺失或过饱和等问题，并且这种退化会随着多帧传播而累积。

针对上述问题，PAI 团队提出了全新的两阶段方法 Zero-to-Hero，用于提升视频外观迁移的准确性、时序一致性与最终画质。Zero-to-Hero 将“外观传播”解耦为两个阶段：首先生成一个可靠的零样本传播初始化（Zero-Stage），再通过整体性视频修复模型提升画质（Hero-Stage）。图2展示了我们算法的整体框架。在 Zero-Stage 中，我们利用原始视频帧之间的对应关系来引导扩散模型的注意力传播，相比以往依赖光流或额外时序模块的方案，在处理大运动目标时更稳健，从而提供准确且时序一致的初始化结果。然而，对注意力机制的干预会带来难以避免的模糊与颜色缺失等退化。为突破这一零样本上限，我们进一步提出 Hero-Stage：训练一个面向退化模式的条件生成模型，对视频进行画质修复。

图 2：视频编辑过程示意图

如图3所示，Zero-to-Hero 在 Colorization 与 Blender-Color-Edit 两项可逐帧评测的任务上均取得最优结果（PSNR 分别达 28.21/26.76 dB，且 LPIPS 最低、SSIM 最高），同时在 General-Edit 上也在锚点帧指标与时序一致性（MS/SC）上整体领先，体现了更稳定的外观传播与更高的画质保真。

图 3：实验效果概览

如图4所示，在 General-Edit 数据集的定性对比中，Zero-to-Hero 能更准确地贴合参考帧外观，同时最大程度保持原视频的结构与运动一致性；相比基线方法，结果中外观漂移与细节模糊现象更少，整体观感更稳定。

图 4：Zero-to-Hero与其他方法编辑结果示例

论文信息
论文名字：Zero-to-Hero: Empowering Video Appearance Transfer with Zero-Shot Initialization and Holistic Restoration
论文作者：苏彤彤、汪诚愚、廖海鹏、黄俊、鲁东明
论文 pdf 链接：https://arxiv.org/abs/2505.23134

国务院印发的《关于深入实施“人工智能+”行动意见》（后统称为意见），标志着AI与全社会各领域的融合迈入深度绑定和扩展阶段。不仅为未来社会的智能化发展构建了框架，规划出了蓝图，同时也着重强调了“人工智能+”的推进离不开安全可信的信任基础，因此务必推动电子认证与数字技术在全社会全领域的广泛应用。此次意见的出台，是人工智能向上的一次探索，但底层的核心逻辑依然是围绕海量的、可值得信任的数据流动和交互。若通信管道存在风险漏洞，智能处理中心将很可能无法获得值得信任的数据，遭遇信息污染，使得诈骗或虚假信息泛滥，肆意传播，严重影响社会经济发展。JoySSL技术总监认为，国家出台“人工智能+”这一战略导向，实质上等于将电子认证体系中的SSL证书的重要性提升到了全新的高度。数字证书不再只是单一的网站加密，更是能够保障AI数据完整和安全，构建值得信赖的人机关系，是当下时代确保人工智能化应用合规落地不可或缺的认证官。

“人工智能+”核心驱动引发安全新挑战

“人工智能+”的本质，是AI模型和算法深入到经济社会的生产、流通和服务等多个环节，只有汇集更多的源数据，AI的训练才能得到加强。且智能应用本就需要与用户、设备以及各种系统进行实时交互，数据会在云、端、机构等各种主体间穿梭，流动规模庞大，路径复杂，引发数据压力爆炸式增长。

人工智能的推动与落实，要求交互不止局限于人和人之间，更是扩展到服务器、设备、模型甚至服务上。一旦交互主体信息不明，将会引发AI数据风险。数据在传输过程中若得不到高强度加密，可被恶意窃取或篡改，导致模型出现偏差，给用户以错误的指引。此外，攻击者一旦突破系统防御，可伪造身份，仿冒平台或客服提供假数据，亦将造成严重后果。

SSL证书为“AI+”构建可信数据交互规则

数字证书以高强度加密技术与身份验证机制，成为响应和推动“人工智能+”有效落地的关键。通过建立HTTPS/TLS加密通道，保障AI数据供应链的安全传输，有效防止数据被窥窃和修改，确保数据的准确性。
组织与扩展验证型证书通过建立服务端的可信身份，为企业提供合法合规的AI服务，杜绝仿冒与欺诈。同时基于SSL证书的双向认证，确保数据自动化交互在可信实体间进行，为AI生态可信化奠定基础。

数字认证技术赋能“人工智能+”信任基础

伴随着“人工智能+”浪潮的翻涌，企业与机构应当构建坚实易用的数字信用体系，将数字认证技术赋能至人工智能发展中。JoySSL技术总监表示，专业的电子认证技术，可牢筑智能安全防线，保障信息安全，有效助力全社会数字化转型。而数字身份技术可为AI业务提供可信身份凭证，防范欺诈，保障大规模分布式AI数据通信安全。

智能化发展时代 携创新与信任共同前行

此次意见的出台，标志着全社会智能化步入全面升级阶段，人工智能发展的深度与广度，取决于底层数据的基础建设。SSL证书作为电子认证与数字技术的实践，是底层数据安全可信的重要前提。以数字证书作为智能化发展的基石，可有效保障创新与信任能够同步前行。

日前，由国内数智技术前沿社区 DataFUN 主办的“AGENTIC AI 超级智能体系统架构峰会”在京召开，会议正式揭晓了 2025 年第三届星空奖·数智技术系列榜单。

Aloudata 大应科技凭借在众多行业数智化头部企业的高质量 NoETL 数智实践荣获“年度科技领航企业”；Aloudata 自主研发的分析决策智能体 Aloudata Agent，以独创的 NL2MQL2SQL 技术路径和实用性荣获“年度科技创新突破奖（Data + AI）” ；与客户中交一公局携手构建智能数据分析决策平台，荣获“年度技术最佳实践奖”。

伴随 AI 时代的到来，在“算力普惠”和“算法普惠”之后，数据已经成为企业数智竞赛最大的差异要素。作为中国数据语义编织（Semantic Fabric）领导者，Aloudata 在 2025 年不仅持续强化 NoETL 产品创新实践能力，赢得了越来越多的金融、消费零售、制造、能源、工程建设及 ICT 等行业头部企业合作，帮助客户实现从数据集成、治理到分析的全链路提质增效，更以领先的“NoETL 数据语义编织（Semantici Fabric）”能力，为企业规模化落地 Data Agent 逐步构建可信智能的数据底座，驱动可信 AI 决策。

去年 4 月面世的 Aloudata Agent，作为一款以“NoETL 明细语义层 + 多 Agent 协同”架构为支撑的分析决策智能体，能够帮助企业实现以指标为中心的对话式数据分析，精准对齐业务语义和数据语言，避免“数据幻觉”，开展准确、灵活、快速、安全地智能问数。迭代至今，Aloudata Agent 已跑通“智能问数-归因分析-智能报告-行动建议”的分析决策闭环，并支持按照业务职能或数据领域，创建场景化分析助手。

在中交一公局向“精细化、智能化”经营管理转型升级的关键期，Aloudata 为其提供了 Aloudata CAN 指标平台和 Aloudata Agent 分析决策智能体，携手构建起智能数据分析决策平台，通过指标语义层沉淀 AI 业务知识，以 NL2MQL2SQL 技术路径部署智能数据助手，让业务无需依赖 IT，自助完成 80% 数据查询需求，关键决策响应速度提升 90%，跨部门沟通成本降低 30%。

面向未来，Aloudata 将深度融合企业数据语义、业务知识、应用场景等，以 NoETL 数据语义编织技术体系，助力平滑落地以 Data Agent 为代表的 AI 应用，实现数据普惠、深度洞察、可信决策、业务创新。

在数据基础设施领域，向量检索正在经历从“单一功能组件”向“核心生产系统”的跨越。

随着LLM应用、搜广推系统进入深水区，企业对向量数据库的需求早已超越了简单的“TopK 召回”。在生产环境中，如何在大规模数据下保持极低的延迟？如何在复杂的标量过滤条件下依然维持高吞吐？如何在数据频繁更新时保证索引的鲜度与性能？这些是决定业务成败的关键。

近日，阿里云多模数据库 Lindorm 发布了新版向量检索服务，并基于业界通用的 VectorDBBench 基准测试工具，发布了最新版本的性能报告。测试结果显示，通过引入 CBO/RBO 混合优化器 与 自适应混合索引 架构，Lindorm 在大规模数据与复杂过滤场景下展现出了显著的性能优。这不仅是一次跑分上的突破，更验证了国产云原生数据库在处理大规模、高并发、复杂混合检索场景下的硬核实力。

01 Benchmark实测分析

我们选取了业界公认的 Cohere 标准数据集，在真实云环境下与主流向量数据库进行了严苛的对比测试。

场景一：高并发 KNN 检索性能

我们分别在千万级 (Cohere-10M) 和百万级 (Cohere-1M) 规模下进行了测试。值得一提的是，这种极速体验并非以牺牲精度为代价——在两个数据集的测试中，Lindorm 始终保持了 99% 以上的超高召回率。

1. Cohere-10M：

在 1,000 万量级的数据规模下，我们将 Lindorm (32C 单节点) 与 VectorDBBench 榜单上的顶级云服务进行了横向对比：
QPS 遥遥领先：Lindorm 跑出了 2.4万+ 的极高 QPS，大幅超越了榜单前列的 Zilliz Cloud (3,957) 以及此前的 SOTA 记录（18,000）。
延迟极致丝滑：在同等高吞吐下，Lindorm 的 P99 延迟表现稳定在 2.5ms。相比之下，竞品的延迟普遍在 10ms 甚至 100ms 以上。

2. Cohere-1M：在 100 万量级下，Lindorm 展现了碾压级的性能优势：Lindorm QPS 突破 5.6万，同时将延迟控制在 2ms；相比之下，主流开源产品如 Milvus、OpenSearch 的 QPS 普遍在 3,000 左右。
   

   场景二：融合检索 (Hybrid Search)

   融合检索是生产环境的真实考验——业务中 80% 的查询带有复杂的标量过滤条件。而传统的“先过滤再检索”或“先检索再过滤”模式，往往在特定过滤比例下出现严重的性能坍塌。

得益于 CBO/RBO 混合优化器 与 自适应混合索引 架构，Lindorm 在全过滤区间内实现了智能的执行计划路由，不仅保持了极高的性能水位，更确保了全链路分支的召回率均在 90% 以上：

• 低过滤比例 (Vector-Driven)：当过滤出的结果集较大时，优化器选择向量导航优先策略。利用交叉流水线技术，在图遍历的同时并行执行标量过滤，保持了与纯向量检索相当的 5万+ QPS。

• 高过滤比例 (Scalar-Driven)：当过滤条件极严苛时，CBO 自动切换为标量驱动模式。利用 Bitmap / 倒排索引 快速圈定目标集，彻底规避了无效的向量计算，QPS 更是飙升至 26万+，完美解决了传统方案在稀疏结果集下的“深坑”问题。
  

  注：

  • 数据来源：Lindorm 数据基于 32C128G 规格单节点实测；Hologres 数据引用自 阿里云开发者社区；其他竞品数据直接引用自 VectorDBBench Leaderboard 及公开评测报告。
  • 真实业务模拟：Lindorm 上述成绩均为 无 Query Cache 模式下的实测值。我们测的不是缓存，是实打实的性能。

02 测试方式

为了确保测试结果的公正性与可复现性，本次测试采用了业界通用的标准硬件规格与开源测试框架。

• 测试环境规格：Lindorm 实例规格为 32核 128GB (32C128G)，这是云上生产环境的典型配置。
• 软件版本：Lindorm 向量引擎版本为 3.10.16 及以上。

• 测试工具：使用业界权威的 VectorDBBench 进行压测。为了支持 Lindorm 的特定协议，我们已将适配代码提交至 VectorDBBench 官方仓库。

  开源共建：相关适配代码详见 PR #718: zilliztech/VectorDBBench。开发者可直接基于此 PR 复现上述测试结果。

03 技术解密：如何做到极致性能？

Lindorm 向量检索性能的突破，并非依赖单一算法的优化，而是源于对数据库系统架构的深度重构。我们将向量检索从“外挂索引”进化为了“原生数据库系统”。

1. 突破内存墙的多技术融合架构

向量检索的本质是大量的随机内存访问。Lindorm 引入了聚类、图与两层量化深度融合的设计，将内存带宽的使用效率推向极致：

• 聚类索引：提供稳定的空间划分，快速定位目标区域，大幅减少无效搜索。
• 图索引：在聚类的基础上构建导航图，提供极速的近邻收敛能力。
• 两层量化：
  Layer 1 粗排层：通过高压缩比的量化技术，使索引数据能最大程度驻留在 CPU L3 Cache 中，极大缓解了内存总线压力。
  Layer 2 精排层：仅对筛选出的少量关键候选集，加载原始精度向量进行重排。

这种先快后精的策略，让 Lindorm 在召回率不打折的前提下，检索吞吐实现了质的飞跃。

2. 融合检索：从“外挂”转向“原生数据库系统”

这是 Lindorm 向量引擎最核心的革命。在此之前，业界的融合检索方案往往陷入两难：

• 产品化方案的“缝合怪”困境：大多数向量数据库仅是将向量索引与标量索引简单拼接。两者在底层存储与执行逻辑上完全割裂，导致查询时需要在不同引擎间大量搬运数据，性能损耗巨大。
• 学术界方案的“僵化”难题：学术界的融合索引虽然在特定数据集上表现优异，但往往要求预先定义固定的过滤字段与数据结构，无法适应真实业务中频繁变更 Schema 的动态需求。

Lindorm 选择了一条全新的道路：将向量与标量视为统一的抽象实体。

• 以向量为锚的统一抽象：Lindorm 彻底摒弃了“外挂”思维，而是以向量数据为锚点，重新设计了整个系统的存储结构、优化器与执行器。在这种架构下，标量属性不再是向量的附属品，而是与向量特征紧密交织的原生一等公民。
• 自适应混合索引：为了应对多样化的标量数据分布，系统内置了自适应混合索引引擎。对于高基数数据，自动采用 Hash 或 B-Tree 结构；对于低基数数据，自适应启用 Bitmap 或 Roaring Bitmap，利用 SIMD 位运算优势实现极速集合操作。
• 智能执行计划路由：系统实时维护高维直方图统计信息。当查询到来时，优化器会根据过滤条件的选择率（Selectivity），智能判断是应该“先查向量再过滤”，还是“先查标量再计算距离”，亦或是采用“交叉流水线”并行执行。这种智能决策机制，确保了无论数据分布如何倾斜，系统始终能选择最优的执行路径。

3. 全架构自适应加速

不同于依赖固定写死的优化路径，Lindorm 向量引擎支持跨平台自适应，根据运行环境自动选择更合适的执行策略，让性能在不同硬件上都能“开到最优档”：

• x86 环境：自动探测并激活 AVX512 / AVX2 指令集，利用硬件级指令实现距离计算的极致加速。
• ARM 环境：深度适配 NEON 指令集，确保在国产化算力底座上依然表现强劲。

4. 图结构的自我进化

索引在增量写入后，往往会因为数据分布的漂移导致图结构的“局部最优”陷阱，造成检索路径变长。Lindorm 向量引擎引入后台重整机制：在不影响在线服务的情况下，持续观察结构质量并做温和修复与优化，让导航结构逐步回到更理想的状态，让引擎始终处于稳定的运行状态。

5. 面向生产的动态能力

在快速迭代的业务中，数据结构绝不能是死板的。Lindorm 赋予了索引强大的动态修改能力：

• 实时更新：无论是向量还是标量数据，都支持实时的增删改操作。标量修改仅涉及倒排索引的微小变动，向量修改则支持原地实时更新，确保每一次写入都能即刻被检索到。
• Schema 演进：支持在线 Schema 演进，业务可以随时添加或删除标量列，无需漫长的索引重建周期。

结语

Lindorm 向量服务不仅仅是一个更快的检索索引，它是对向量数据库底层逻辑的一次重构。通过将高性能检索加速、全架构适配以及数据库级的查询优化深度融合，Lindorm 为大规模 AI 应用提供了最坚实的性能护城河。

无论是万亿级参数的大模型检索增强，还是面对超高 QPS 压力、实时变动的商品推荐，Lindorm 已准备好为你的业务披挂上阵。

关于 Lindorm

云原生多模数据库 Lindorm 是阿里巴巴自主研发的面向 AI 时代的云原生数据库，支持向量、宽表、搜索、列存、时序等多种数据模型，为企业提供一站式的数据存储与处理能力。了解更多请访问产品官网：https://www.aliyun.com/product/apsaradb/lindorm

在ClkLog的设计中，我们做了一件看起来“很简单”，但在实际项目里非常关键的事情：内置了开箱即用的成熟用户行为分析模型（如基础访问、访问来源等）。
这意味着，在完成SDK接入后，团队不需要先定义大量自定义事件，也不需要反复设计分析口径，就可以直接看到基础分析结果，用于产品和运营决策。

这个能力的目标只有一个：让埋点分析系统在“接完SDK”之后，真的能马上用起来。

为什么「接完SDK能马上用」这么重要？
在实际项目中，大家应该遇到过这样的情况：

• SDK很快就接好了
• 数据也确实开始上报了
• 但分析系统迟迟没有被真正使用起来
  这不是技术问题，其实是数据分析的门槛。

很多分析系统使用的前提是：你已经知道要看什么数据了、知道指标怎么计算了……
但真实的业务场景里却是相反的，对于很多刚接触分析的团队来说是想先看到数据，在逐步明确怎么继续深入分析。

为什么很多埋点系统「有数据，却不好分析」？
1.一上来就要求做自定义事件
为了做一次基础分析，往往需要先做这些事情：

• 梳理完整的埋点规范
• 定义事件和属性
• 统一命名和口径
  这对早期或节奏快的团队来说，成本非常高。

2.分析模型本身是隐性成本
新老访客、忠诚度、留存、漏斗、路径、转化……这些分析并不是“画个图”那么简单，而是：

• 涉及用户去重规则
• 涉及时间窗口
• 涉及事件顺序和条件
  很多团队在真正实现时才发现：
  写统计不难，写对、写稳、写得长期可用才难。

ClkLog内置分析模型解决的是什么问题？
正是基于这些实际使用问题，ClkLog 在产品中内置了一套开箱即用的分析模型。
核心目标只有一个：
降低“从接入到产生分析价值”的门槛。
让团队可以快速验证产品的可行性，也能让运营团队慢慢熟悉产品为下一步深入分析做准备。
当团队逐步明确需求后，再进行深入分析、二次开发，方向会更明确、成本也更可控。

ClkLog内置了哪些分析能力？
在完成 SDK 集成后，以下分析能力可以直接使用的：
1.基础访问分析

• PV/UV/IP数
• 平均访问时长
• 跳出率
  
  无需额外事件定义，即可了解整体访问情况。

2.访客分析

• 新老访客
• 地域分析
• 来源网站/渠道/设备分析
  
  
  
  访客的基础信息可以一目了然。

3.用户分析

• 构建用户基本画像
• 用户忠诚度分析
  
  
  详细了解每个用户的使用情况。

ClkLog通过内置分析模型，希望解决的是：
让团队在完成SDK集成后，就能尽快进入“分析和决策”阶段，而不是被埋点和模型设计拖慢节奏。

如果你有兴趣可以来gitee和github直接获取ClkLog社区版进行部署集成，快速开启用户分析。