xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
不需要注册，不需要安装，打开浏览器就能用。
| 工具 | 说明 |
|---|---|
| 图片压缩 | 拖入即压，支持批量，体积大幅缩小 |
| 格式转换 | JPG / PNG / WEBP / GIF 互转 |
| 图片裁剪 | 自由裁剪，支持比例锁定 |
| 图片拼接 | 多张图拼长图，一键导出 |
| 拼图/九宫格 | 多种布局模板，支持自定义分格，可加文字/箭头/标注 |
| 图片分割 | 把一张图切成 N 等份 |
| 添加水印 | 文字水印，支持位置、透明度、旋转自定义 |
| 去除水印 | AI 智能修复，涂抹区域自动填充 |
欢迎收藏备用，处理图片的时候应该用得上。有问题或者建议欢迎留言。
在搭建 OpenClaw 的过程中，花费我最多时间的其实是配置大模型的 API Key 。
一开始尝试通过 ChatGPT 的 OAuth 授权方式接入，但始终无法成功；改用 API Key 方式也不行，日志里一直报 fetch failed 。当时甚至怀疑是不是根本没有免费的 token 可以使用。
后来改用阿里 Qwen 的 OAuth ，反而一次就成功了，整体接入流程明显顺畅很多。
相比之下，其他一些国产大模型的配置体验就没有那么友好。比如月之暗面家的模型，获取 API Key 的流程似乎比较繁琐，不太清楚是需要经过一定身份认证，还是本身就以付费为主。
感觉后面还是要找到长期的量大的方便使用的 token
本文由体验技术团队kagol原创。 AI Agent 时代，人们已经不满足只是与 AI 进行问答交互，而是希望 AI 能直接帮人干活。 OpenTiny NEXT‑SDK 是一套面向前端智能应用的开发工具包，核心是基于 MCP（Model Context Protocol） 协议，让前端应用快速接入 AI Agent，实现前端界面可被智能体直接操控的能力。 OpenTiny NEXT‑SDK 可以帮助开发者： NEXT‑SDK 是基于 MCP 协议实现，将 MCP 的能力扩展到了 Web 端，让 Web 应用也能被 AI 操控，以下是项目优势： 我们一起来看一个演示动画，直观感受下 NEXT-SDK 的能力吧！ 接入 NEXT-SDK 的前端应用，右下角会出现一个机器人图标，点击这个图标会从侧边弹出 AI 对话框，我们可以使用自然语言与 AI 对话，让 AI 帮我们操作前端应用。 比如我们可以输入以下内容： 这时 AI 会调用页面中定义的名为 add-user 的 MCP 工具，帮我们创建 zhangsan 这个用户。 我们提供了一个 Playground 代码演练场，你可以在线体验 NEXT-SDK 的能力。 NEXT-SDK Playground：https://playground.opentiny.design/next-sdk 使用 OpenTiny NEXT-SDK，只需要以下四步，就可以把你的前端应用变成智能应用。 在 Web 应用的主入口（比如：Vue 项目的 App.vue 文件）定义 WebMcpClient。 在 Web 应用的子页面（比如：views/page1.vue）中定义 WebMcpServer，每个页面可以定义自己的 WebMcpServer，页面切换时，MCP Client 会与当前页面的 MCP Server 建立连接，并丢弃与之前页面的连接。 完成！现在你的前端应用已经变成智能应用，可以被 AI 操控了，你可以通过各类 MCP Host 来操控智能应用。 我们提供了一个开箱即用的 AI 对话框组件，支持 PC 端和移动端，就像一个遥控器，可以通过对话方式操控你的前端应用。 安装遥控器组件： 在 Vue 项目中使用： 遥控器会在你的应用右下角显示一个图标，悬浮后可以选择： 不管是 PC 端还是移动端，都可以通过自然语言对话的方式让 AI 帮你操作应用，极大提升工作效率！ 如果你想了解更多 NEXT-SDK 的用法，请参考 NEXT-SDK 官网文档：https://docs.opentiny.design/next-sdk 在 AI 技术快速迭代的今天，前端智能化不再是“高端需求”，而是提升产品竞争力、提升操作效率的核心能力和必选项。 OpenTiny NEXT-SDK 让前端 AI 集成，从“复杂踩坑”到“5分钟上手”，让你的应用瞬间拥有 AI 能力，领跑行业智能化创新！ 立即行动，解锁前端智能化新可能： 如果你有任何问题，欢迎在评论区留言交流！前言
目前 AI 帮人干活的场景越来越丰富，最常见的就是 AI 帮人写代码、做视频、做 PPT、做设计稿。
你有没有想过 AI 能帮人操作网页？
这就是 OpenTiny NEXT-SDK 做的事情。1 简介
2 项目优势
3 演示动画
帮我创建以下用户，用户信息如下：
邮箱：zhangsan@sina.com
密码：Abc123456
用户名：zhangsan
4 快速接入
第一步：安装依赖
npm install @opentiny/next-sdk第二步：创建 MCP Client
import { onMounted, provide } from 'vue'
import { WebMcpClient, createMessageChannelPairTransport } from '@opentiny/next-sdk'
onMounted(async () => {
// 创建通信通道
const [serverTransport, clientTransport] = createMessageChannelPairTransport()
provide('serverTransport', serverTransport)
// 创建 MCP Client
const client = new WebMcpClient()
await client.connect(clientTransport)
// 这个 sessionId 是 Web 应用与 WebAgent 服务建立连接后，由 WebAgent 服务生成的，用来唯一标识被操控的 Web 应用（被控端）
const { sessionId } = await client.connect({
agent: true,
url: 'https://agent.opentiny.design/api/v1/webmcp-trial/mcp'
})
})第三步：创建 MCP Server
import { onMounted, inject } from 'vue'
import { WebMcpServer, z } from '@opentiny/next-sdk'
onMounted(async () => {
const serverTransport = inject('serverTransport')
// 创建 MCP Server
const server = new WebMcpServer({
name: 'mcp-server-page1',
version: '1.0.0'
})
// 定义 MCP 工具
server.registerTool(
'demo-tool',
{
title: '演示工具',
description: '一个简单工具',
inputSchema: { foo: z.string() }
},
async (params) => {
console.log('params:', params)
return { content: [{ type: 'text', text: \`收到: \${params.foo}\` }] }
}
)
await server.connect(serverTransport)
})第四步：添加 AI 遥控器
npm install @opentiny/next-remoter<script setup lang="ts">
import { TinyRemoter } from '@opentiny/next-remoter'
import '@opentiny/next-remoter/dist/style.css'
// 使用第二步获取的 sessionId
const sessionId = 'your-session-id'
</script><template>
<tiny-remoter
:session-id="sessionId"
title="我的智能助手"
/>
</template>
5 立即行动
npm install @opentiny/next-sdk 安装 OpenTiny NEXT-SDK，5分钟上手实操，快速体验 AI 操控效果opentiny-official，加入 OpenTiny 技术交流群，获取一对一集成指导，解决实操难题，与同行交流 AI 前端集成经验
在构建企业级 AI Agent 的过程中，开发者往往会陷入环境配置的泥潭。想象一下，你好不容易写好了 Agent 的核心逻辑，却在 Docker 容器编排、依赖冲突或者网络配置上浪费了整整两天。这就是为什么OpenClaw是什么成为了近期技术圈的热门话题。简单来说，OpenClaw 是一个开源的、旨在简化 AI Agent 开发与部署流程的框架，它不仅支持多模型接入，更重要的是提供了一套标准化的工具调用协议。而对于追求效率的团队，七牛云OpenClaw一键部署方案则直接将这个过程从“天”缩短到了“分钟”级。 很多开发者初次接触 OpenClaw 时，容易把它简单等同于 LangChain 或 AutoGPT。其实，OpenClaw 的核心竞争力在于其对“工具链”的极致封装。它不仅是一个 Agent 运行时，更是一个能够让大模型真正“长出双手”的操作系统。 传统的 Agent 开发中，你需要手动编写大量的胶水代码来连接数据库、API 接口和搜索引擎。而 OpenClaw 通过预置的工具集和标准化的接口定义，让这一过程变得像搭积木一样简单。特别是当你需要OpenClaw对接DeepSeek模型配置时，你会发现其内置的适配层能够完美处理 DeepSeek 的上下文窗口和 Function Calling 格式，避免了繁琐的 Prompt 调试。 这种设计理念直接解决了企业级Agent方案中最头疼的稳定性问题。在私有化部署场景下，OpenClaw 的架构允许数据完全留在本地，同时又能灵活调用外部的强大算力，实现了安全与智能的平衡。 对于大多数开发者来说，如何快速搭建OpenClaw环境是迈向实战的第一步。手动拉取 GitHub 代码、配置 Python 环境、安装 Docker 依赖虽然可行，但极易踩坑。这里推荐使用七牛云的镜像方案，实测可以在 5 分钟内完成环境搭建。 在 OpenClaw 的配置文件中，只需填入七牛云提供的 API Key 和 Base URL，即可让你的 Agent 拥有 DeepSeek-V3 或 Claude 3.5 的推理能力。 如果你需要更定制化的功能，可以参考MCP服务使用说明文档。七牛云 MCP 接入服务是一个标准化的模型能力编排与托管平台，通过兼容 OpenAI Agent、SSE 等多种协议，实现多工具服务的云端安全聚合与统一管理，让开发者无需本地部署即可快速构建具备复杂工具调用能力的 Agent 智能体应用。通过这套文档，你可以将公司内部的 API 封装成 MCP 服务，让 OpenClaw 直接调用，真正实现业务流程的AI Agent自动化部署。 在进行OpenClaw私有化部署教程的实践中，有几个细节需要特别留意： 数据持久化：使用 Docker 部署时，务必挂载本地卷（Volume）来保存向量数据库的数据，否则重启容器后知识库会丢失。 相关文档：
为什么选择 OpenClaw？不仅仅是开源
实战：七牛云 OpenClaw 一键部署全流程
登录七牛云控制台，在创建云主机实例时，不需要选择空白的操作系统。直接在应用镜像市场搜索，选择OpenClaw一键部署镜像。这个镜像已经预装了 OpenClaw 运行所需的所有系统级依赖、Python 虚拟环境以及常用的向量数据库组件。选它可以直接使用预装工具，省去手动部署的步骤，让你开机即用。
环境跑起来后，核心就是接入“大脑”。OpenClaw 的强大之处在于不绑定特定模型。你可以通过配置界面轻松接入AI大模型推理服务。这是一个集成 Claude、Gemini、MiniMax、DeepSeek 等顶级模型的全开放平台，通过完美兼容 OpenAI 和 Anthropic 双 API，支持联网搜索、深度思考及 MCP Agent 开发，为开发者提供“体验即送 300 万 Token”的高性能、低门槛一站式大模型接入方案。
部署完成后，如何让 Agent 做更多复杂任务？比如查询实时天气并写入飞书文档？这就需要用到 MCP（Model Context Protocol）。OpenClaw 原生支持 MCP 协议，这意味着你可以直接复用社区现有的 MCP Server。私有化部署的避坑指南
网络连通性：虽然是在国内云服务器上部署，但如果你的 Agent 需要访问海外 API（如某些特定的搜索工具），可能需要配置网络代理。不过使用七牛云的 AI 推理服务通常能规避这个问题，因为其 API 端点在国内有加速。
资源监控：运行复杂的 Agent 任务（特别是涉及大量向量检索时）会消耗较多内存，建议云主机的配置至少在 4核 8G 以上。
通过七牛云的OpenClaw镜像，我们不仅省去了繁琐的环境搭建时间，更重要的是获得了一个稳定、可扩展的 Agent 运行基座。无论是为了快速验证 AI 创意，还是构建企业内部的智能助手，这套组合拳都是目前性价比极高的选择。现在就动手试试，让你的第一个智能体跑起来吧。
MCP使用文档https://developer.qiniu.com/aitokenapi/12984/mcp-user-manual
openclaw系统部署：https://app-6978b382b249d02502166b4c.app.qiniucc.com
从 0 到 1 ，用 AI 辅助开发一个 OpenClaw 类似的 Agentic AI 工具。10 天，73 个 commit ，13000+ 行 Rust 。
这篇文章记录了整个过程中的思考、踩坑与感悟。
代码在 GitHub。如果你也想造一只属于自己的螃蟹钳子，欢迎 star/fork 。我的 GitHub：jackwener，欢迎 follow 。
2026 年 2 月，OpenClaw 火了。朋友圈里人人都在聊这只龙虾——一个能在 Telegram 里跟你对话、帮你干活的 AI 智能体。在我看到 Bub 之后，我也起了一个想自己写一个的心
我先简单看了 Nanobot（ OpenClaw 的最小复现）了解核心架构，
深入研究了 **Bub**——PsiACE 的 Agent 项目。Bub 的架构非常优雅：AgentLoop 抽象、Tape 记忆系统、Skills 引擎，每个模块都恰到好处。后来在做 schedule 等功能时，也参考了 Zeroclaw 的实现思路。
CrabClaw 的架构大量借鉴了 Bub ，核心理念是 "路由 → 模型 → 工具 → 记忆" 的确定性单向数据流：
下面详细介绍图中每个组件。
CrabClaw 支持三种接入方式，它们的职责只有一个——收消息、发结果，不包含任何 agent 逻辑：
| Channel | 场景 | 特点 |
|---|---|---|
| CLI | cargo run -- run --prompt "..." |
一次性执行，适合脚本集成 |
| REPL | cargo run -- interactive |
交互式终端，支持流式输出 |
| Telegram Bot | cargo run -- serve |
长轮询，带白名单 ACL 、typing indicator |
所有 Channel 最终都通过 AgentLoop::handle_input(text) 进入同一条管线。
这是 CrabClaw 的心脏。最初我给 CLI 、REPL 、Telegram 各写了一套 agent 循环逻辑——消息解析、LLM 调用、工具执行、结果录制，每处都有微妙差异、重复代码。后来参考 Bub 的做法，抽出了统一的 AgentLoop：
pub struct AgentLoop<'a> {
config: &'a AppConfig, // 运行配置（模型、API key 等）
workspace: &'a Path, // 工作区目录
tape: TapeStore, // 会话记忆
tool_view: ProgressiveToolView, // 渐进式工具视图
tool_ctx: ToolContext, // 工具执行上下文（ notifier + agent_runner ）
}
每次用户发消息，handle_input 跑一个完整的 6 步管线：
1. Route → 用户输入经过 Router 分流（命令 vs 自然语言）
2. Record → 用户消息写入 Tape （只追加）
3. Tools → 从 ProgressiveToolView 获取当前可用工具定义
4. Context → 从 Tape 构建上下文窗口（滑动窗口截断，默认 50 条）
5. Model → ModelRunner 发起 LLM 推理 + Tool Calling Loop
6. Process → 处理结果：录入 Tape 、检测助手输出中的逗号命令
所有 , 开头的输入直接走命令路由，绕过 LLM——零延迟、确定性结果：
,help → 内部命令，直接返回帮助文本,git status → Shell 执行（/bin/sh -c），30 秒超时,tools → 列出所有注册工具,tape.search <query> → 搜索对话历史,handoff → 创建上下文切换锚点（下面详解）非 , 开头的输入才走 LLM 推理。这个设计确保了"确定性操作"的可靠性，同时把"需要智能"的部分交给模型。
这是 Agent 区别于普通 Chatbot 的核心机制。当 LLM 的回复中包含 tool_calls（比如它想调用 file.read 读文件），ModelRunner 会：
第 1 轮：LLM → "我想调用 file.read(path='src/main.rs')"
→ 执行 file.read → 返回文件内容
→ 把结果追加到上下文 → 再次调用 LLM
第 2 轮：LLM → "我看到了代码，现在调用 file.edit 修改第 42 行"
→ 执行 file.edit → 返回成功
→ 再次调用 LLM
第 3 轮：LLM → "修改完毕，这是我的总结：..."
→ 没有 tool_calls → 循环结束，返回最终文本
最多 15 轮，防止模型陷入无限循环。这个数字最初是 5——直到有人给 bot 发了"帮我从 HackerNews 采集 20 条新闻并总结"，5 轮根本不够完成 web.fetch → 解析 → 总结的完整链路。Zeroclaw 用的是 10 ，我们给了更多余量：
const DEFAULT_MAX_TOOL_ITERATIONS: usize = 15;
此外，参考 Zeroclaw 的设计，CrabClaw 还有一个 loop 检测 机制：用 HashSet<(tool_name, canonical_args)> 追踪每轮 tool call 的签名，如果 LLM 重复调用相同工具 + 相同参数，直接跳过并返回提示。这样就不会傻等 15 轮才超时——重复调用第 2 次就会被拦截。
CrabClaw 内置的工具集：
| 工具 | 功能 |
|---|---|
file.read/write/edit/list/search |
工作区沙箱化的文件操作 |
shell.exec |
Shell 命令执行（失败结果包装为 XML 供 LLM 自我纠正） |
web.fetch / web.search |
抓取网页 / DuckDuckGo 搜索 |
schedule.add/list/remove |
定时任务（支持 reminder 和 agent 两种模式） |
skill.* |
从 .agent/skills/ 自动发现的 Markdown 技能插件 |
如果每次 LLM 请求都带上所有工具的完整 JSON Schema （参数定义、类型约束、描述），那光工具定义就要吃掉约 720 token。对于简单的对话来说，这是巨大的浪费。
ProgressiveToolView 的思路是 **"先给菜单，再给菜谱"**：
初始状态（~50 token ）：系统提示词只包含工具名和一行描述：
<tool_view>
- shell.exec: Execute shell commands in the user's workspace
- file.read: Read file contents (workspace-sandboxed)
- web.fetch: Fetch a URL and return content as Markdown
...
</tool_view>
按需展开：当 LLM 在回复中提到 $file.read`（`$ 前缀是 hint 语法），或者实际调用了某个工具，该工具的完整 Schema 才会在下一轮请求中发送给 API：
// 检测 $hint 模式并展开
view.activate_hints("I'll use $file.read to check the config");
// → file.read 被展开，下次 API 调用会带上完整参数定义
// 工具被实际调用时也会展开
view.note_selected("shell.exec");
效果：从第一轮的 ~50 token 到按需展开的少量工具完整 Schema ，节省了 90%+ 的 token 消耗。对于简单对话（不需要工具的），节省是 100%。
对话历史存储在 JSONL 格式的 TapeStore 中——只追加，不修改。每行是一个 TapeEntry：
{"id": 1, "type": "message", "payload": {"role": "user", "content": "读一下 Cargo.toml"}}
{"id": 2, "type": "message", "payload": {"role": "assistant", "content": "..."}}
{"id": 3, "type": "event", "payload": {"event": "tool_call", "tool": "file.read"}}
{"id": 4, "type": "anchor", "payload": {"name": "handoff", "state": {...}}}
Anchor 是 Tape 中的"书签"——标记一个有意义的时间点，比如"任务阶段完成"、"上下文切换"。
tape.anchor("phase-1-done", json!({ "summary": "搭建完成" }));
Anchor 不影响对话流，但可以用于：
当对话变得很长，或者你要切换到完全不同的任务时，用 ,handoff 命令创建一个特殊的 Anchor 并重置上下文窗口：
> ,handoff phase-2
Handoff anchor 'phase-2' created. Context window reset (127 entries before).
Handoff 做了两件事：
type: "handoff" 的 Anchor ，记录切换前的条目数build_messages）从最后一个 handoff Anchor 之后开始构建上下文，相当于"忘记"之前的对话为什么需要 Handoff ？ LLM 的上下文窗口有限。如果你跟 bot 聊了 200 轮关于前端的问题，突然要切到后端，之前的 200 轮上下文不仅浪费 token ，还可能干扰模型对新任务的理解。Handoff 让你在同一个 session 内优雅地"翻篇"。
,tape.search <query> 可以在整个对话历史中做全文搜索（大小写不敏感），找到之前讨论过的内容。搜索范围包括消息内容、事件 payload 、Anchor 名称。
ToolContext 是工具执行时的"环境对象"，携带了当前 session 的能力：
pub struct ToolContext {
pub notifier: Option<Notifier>, // 发送通知消息
pub agent_runner: Option<AgentRunner>, // 运行完整 agent pipeline
}
bot_token + chat_id。当 schedule reminder 触发时，通过这个闭包把消息发回给用户config + workspace + session_id。当 schedule agent job 触发时，调用 process_message 跑完整 agent pipeline ，结果通过 Telegram API 发回CLI 和 REPL 的 ToolContext 是空的（None, None）——它们没有通知能力。
整个开发过程几乎全部由 AI 辅助完成。我用 Gemini 做方案设计，用 Claude 写实现，用 Codex 做代码 review 。
里面有意思的一段。用户在 Telegram 里给 bot 发了这么一条消息：
"帮我做个任务，每天十一点的时候从 HackerNews 上收集热点新闻，并且把摘要发给我。"
然后 bot 卡住了。
原因很简单：当时的 schedule 只能发静态文本。当 job 触发时，它只调用 notifier("⏰ 提醒: xxx")——发一条固定消息。它做不到调用 web.fetch 抓 HackerNews ，更做不到调用 LLM 生成摘要。
于是我去研究了 Bub 和 Zeroclaw 怎么做的：
| 项目 | Schedule 触发行为 | 实现方式 |
|---|---|---|
| Bub | 启动子进程跑 agent | subprocess.run(["bub", "run", prompt]) |
| Zeroclaw | 进程内调 agent::run() |
异步直接调用 |
| CrabClaw (重构前) | 发静态文本 ❌ | notifier(text) |
最终我选了 Zeroclaw 的路线，但做了更优雅的实现——用闭包捕获所有上下文：
pub type AgentRunner =
Arc<dyn Fn(String) -> Pin<Box<dyn Future<Output = ()> + Send>> + Send + Sync>;
Telegram 在收到消息时，构建一个 AgentRunner 闭包，捕获 config、workspace、session_id、chat_id。当 schedule 触发时，直接 .await 这个闭包，完整地跑一轮 agent pipeline——LLM 可以调 web.fetch、生成摘要，最后通过 Telegram API 把结果发回给用户。
整个重构分了三步：
execute_tool 感知 session 上下文schedule.add 支持 mode: "agent"，触发时运行完整 agent这个设计比 Zeroclaw 更轻——不需要 SQLite 存储 job 、不需要 cron 表达式解析、不需要复杂的 delivery config 。一个闭包搞定一切。
重构完，兴冲冲地部署，给 bot 发了"一分钟后帮我采集 HackerNews"。bot 说"好的，已创建任务"。然后……什么也没发生。
排查了半天，发现问题：agent_runner 是一个 async 闭包，在 tokio::spawn 里执行。如果里面 panic 了——tokio task 静默死掉，没有任何日志，没有任何通知。用户看到的就是"bot 说做了，但什么也没发生"。
修复方式是在 fire_job 里用 tokio::task::spawn(fut).await 加 match：
match tokio::task::spawn(fut).await {
Ok(()) => info!("agent-mode job completed"),
Err(e) => {
error!("agent-mode job panicked: {e}");
// 回退到 notifier 通知用户
if let Some(notify_fn) = notifier {
notify_fn(format!("⚠ Agent job failed: {e}"));
}
}
}
教训：在 Agent 系统里，任何 async 回调都必须有明确的错误传播路径。"fire and forget" 是 Agent 开发的大忌——用户永远不应该面对"机器人说做了但什么也没发生"的情况。
10 天 73 个 commit ，13000+ 行 Rust 。这不是吹嘘速度——如果只看代码量，这大概是纯手写一两个月的工作量。但这个过程中真正有意思的不是"快"，而是整个开发方式的变化。
CrabClaw 最初没有架构。我跟 AI 说"帮我写一个 Telegram bot ，能调 LLM ，能跑工具"，它就给我生成了一整坨——消息处理、LLM 调用、工具执行全在一个函数里。能跑，但每加一个功能，面条就长一截。
这是我第一个感悟：代码模式会以极快的速度扩散，无论好坏。AI 生成代码的速度太快了，一个面条式的起点，滚三天雪球就是万行单文件。错误会自我强化——AI 看到已有代码是面条式的，它生成的新代码也会是面条式的。
转折点是我去读了 Bub 的源码。看到 Bub 把 AgentLoop 、ModelRunner 、Router 拆得清清楚楚，我才意识到：AI 时代也需要软件工程，甚至更需要。架构不是给人看的文档，而是一种约束——控制复杂度、阻止不确定性扩散的约束。我回去花了一天把 CrabClaw 重构成现在的 AgentLoop → ModelRunner → ToolContext 三层结构，之后所有功能开发都顺畅了。
做 schedule 重构的时候，我试过先写一份详细的 spec ，列清楚每个文件要改什么、接口长什么样、数据怎么流，然后把 spec 丢给 AI 执行。
效果不好。第二天我改了 ToolContext 的结构，spec 立刻过时了。但 AI 不知道，它还在按旧 spec 生成代码——忠实地执行一个已经不符合现实的计划，还不告诉你哪里不对。
Augment Code 说得好：设计文档、架构图、onboarding wiki ，几乎一写出来就过时了。过时的文档误导人类顶多浪费点时间，因为人会自己判断；但过时的 spec 误导 Agent 是灾难性的，Agent 会一路错到底。
后来我换了方式：描述需求 → 让 AI 起草方案 → 我 review → 边做边调整。比如做 AgentRunner 的时候，我只说"schedule 触发时要能跑完整 agent pipeline"，AI 起草了实现方案，做的过程中发现需要闭包捕获上下文，方案就跟着改。人和 AI 共同维护计划，而不是人写完 spec 扔过墙。
这 10 天里，AI 最让我惊喜的是 bug 检查和代码 review。有一次 CI 挂了，我让 AI 分析 clippy 报错截图，它不仅修了报错，还顺手指出了两个我没注意到的逻辑问题。它在"已知 pattern 的代码生成"上也极其高效——给它 Bub 的架构，它能快速翻译成 Rust 实现。
但 AI 在 high-level 架构决策上几乎没给过有效建议。每次我让它"设计一个 schedule 系统"，出来的都是过度工程化的方案——SQLite 存储、cron 表达式解析、retry 策略、delivery config 。实际上一个 Arc<dyn Fn> 闭包就够了。好的架构是做减法，而 AI 倾向于做加法。
开发后期我发现，工程师的核心工作不再是写代码，而是搭建一个让 AI 能自己跑通的环境。CrabClaw 里有几个具体的例子：
cargo fmt + cargo clippy 强制格式和质量，AI 提交代码，hook 报错，AI 自己修——不需要我盯着。做 schedule 重构时改了 17 个文件，全靠 hook 和 CI 保证没引入回归AI 已经完全的改变了我们的 coding 方式，乃至于我们的生活方式。
我希望我自己变成一个 AI native 的人，适应这个新的 AI 世界。
就像这篇文章也是 AI 写的
我发现在 Planet 的 markdown 编辑器里面是支持这种 html 嵌入的, 但是 V2EX 里面好像不支持嵌入.
我目前能想到的折中方案可能是定时截个图然后用 markdown 加载图片来实现.
有什么更好的方式或者建议吗?
<html>
<head>
<meta charset="utf-8">
<script type="module" src="https://widgets.tradingview-widget.com/w/en/tv-mini-chart.js"></script>
</head>
<body>
<tv-mini-chart symbol="WEEX:V2EXUSDT"></tv-mini-chart>
</body>
</html>
大家的 claude.ai 现在能用吗？我的返回这个 Claude will return soon
Claude is currently experiencing a temporary service disruption. We're working on it, please check back soon.
大佬们好，最近想学习下剪辑和做特效，op 纯小白。只知道如果用 pc 的话需要学 pr+pe，但是这个好像很复杂？想问问大佬们有没有啥教程推荐的？ 有没有可以用 ipad 剪辑的教程？剪辑软件有哪些推荐？
相信大家和我们一样，遇到的第一桩难事，就是选场景，定目标。目标场景定的不对，不但常常让产研的心血付诸东流，还会无法形成合力，形成由点线再到面的连招攻击。为了介绍我们如何选场景，定目标，先介绍一下京东保险在干嘛？我们做传统保险，在京东场内还有许多特色服务，比如零售商品延长保障，运费险，不爱吃包退，复购补贴，宠物险，账户安全险，上门医疗险，外卖准时宝等。不看不知道，一看\~还真不知道。为了让大家用的安心，每一个场景都可以有保险参与深度的定制化建设，每一款产品又都有一条完整的产品供应链来保障运行。 为了回答在哪里开始，我们还需要先了解智能体。 什么是AI 智能体？人就是一个智能体。智能体就是像人一样，能够感知环境、思考决策并执行行动的智能系统。 Agent有哪些好处？解决哪些痛点？ 缺人？—— 高效的AGENT前来救驾，AI Agent产能无限，准实时响应，解锁无限人力能开创的安全度和利润空间。 信息管理难？—— 透明的AGENT前来救驾，数字阳光，腐败绝迹；标准清晰，歧路清零；全局增改，无需培训；自驱自查，终止熵增。 需要自我解释的能力？—— 社交的AGENT前来救驾，建立Agent -人网络，人可监控，修改，接手Agent工作，和Agent合作。建立Agent- Agent网络，解锁群体智能。 业务变化大？—— 自主的AGENT前来救驾，Agent自适应，可以进行目标导向的灵活规划和持续进化。 Agent落地收益预估 当下Agent最擅长代理的类型是——在线的信息处理。在一家商业公司，最适合落地的场景，就是在线的把信息转化为金钱的场景。 智能体落地经济收益公式 R：智能体落地的经济收益 Ch：单位人力成本 Ca：单位Agent运行成本 D：转化链路的直接性（0\~1） A：Agent智识覆盖度（0\~1） S：规模 其中： M: 信息输入量 T 获得反馈的周期（时间单位） I:基准智识难度（值越大越难） 从我们自己总结的智能体落地经济收益公式可以看到： 知识到金钱的转化路径越直接，原有转化链路成本越高，Agent智识能覆盖的链路和比例越全面，业务规模越大，则收益越大，越适合作为优先落地场景。 其中，Agent智识覆盖度取决于agent本身的准确率，想要Agent的效果好，需要选择场景任务本身难度不超过当下Agent智识可处理的阈值，可输入给Agent的有效指令信息越全面清晰越好，Agent获取外部反馈的周期越短越好。 保险的本质是通过集体协作，将个体不确定的巨大风险损失，转化为确定的小额保费支出。 保险公司就是通过经营风险实现“把个体无法承受的大损失转化为群体可分摊的小成本”，这种经营风险的底层逻辑是基于概率建立起来的，风险的系数的预估是通过信息估算得来的，与AI的决策逻辑一脉相承。 保险供应链就是风险这种虚拟的概率型产品从生产到交付到售后的全流程，主要包含产品生产、定价、营销、交易、履约理赔、风控。 •虚拟的概率型产品本质使得AI Agent负责一款保险产品“从生到死”具备了底层逻辑上的可能性； •保险业务的生产流程高度流程化与规则化，使得这个过程能相对容易地被AI Agent理解与学习； •保险业务生产流程中，AI Agent提升的是最昂贵、最重复、最容易出错的人工环节，涉及大量知识到金钱的链路转换，收益和价值能直接快速地体现在业务结果中。 Agent中文翻译是智能体，直译是代理。Agent的目标就是所代理角色的目标。成本和规模是最常见的例子，当他们串联成线和面，一个直面经营结果的agent化的保险供应链就产生了。 Agent由上述组成部分演化而来，技术底座做的好，核心是每个技术模块的精益求精加整体架构的灵活性和成长性。我们将技术亮点总结如下： 通用大模型虽然具备强大的语言理解和生成能力，但在特定行业和业务场景中往往存在不足，主要体现在： •领域知识匮乏，尤其是保险，金融领域相关的知识，导致这些领域的专业知识无法精准回答； •语言风格与行业规范不符，专业性不足； •价值观与行业导向(如合规、风险控制)不一致； 外挂知识库(RAG)的方式虽然可以部分解决掉专业性的问题，来适配生产流程，但部分ToB场景，及大多数ToC的场景中，尤其是实时意图理解相关的情景，要求大模型自身习得领域专业知识，才能做到精准识别用户意图，因此有必要训练保险领域大模型。 小尺寸模型通过业务数据微调，已经被证明在保险垂类场景可以满足业务需求。大部分ToC场景有实时性需求，需要做到与用户交互过程的实时响应，这也限制了模型参数不能盲目增加。另外现阶段保险AI业务变动还计较多，控制合理的尺寸可以在可控的成本内及时响应不断变化的业务需求 。因此现阶段的最佳选择是训练一个保险领域的小尺寸大模型。随着未来AI业务更加稳定，方法论更加成熟，我们会逐渐增模型尺寸，来达到更好的业务效果。 亮点： 一、数据驱动的精准洞察力 通过融合海量、高质量的保险领域专有数据，包括：精算级保险条款库：覆盖全品类产品的标准化与个性化条款；真实的电商行为数据：动态反映用户消费偏好与潜在保障需求。通过持续预训练 → 监督微调 → 对齐优化”的三阶段，让模型擅长于条款解读，商机洞察和产品推荐。 二、上下文长度 在小参数模型中，利用上下文差值等技术，让上下文长度和长文本理解能力具有显著优势。为用户提供流畅、即时的交互体验，有效支撑高并发、低延迟的线上业务场景。 三、“LLM as Agent”理念实践 我们将大模型定位为具备任务执行能力的智能体（Agent），而非仅局限于问答系统。模型可主动调用外部工具、实时获取数据并执行复杂逻辑计算，独立完成产品对比、方案定制、核保咨询等全链路保险任务，从而真正转型为一个懂保险、能办事的智能保险专家。 四、少数据量情景下的训练链路设计 一般情况下，持续预训练（cpt）会选择从base model 训练，sft和对齐则从instruct model开始训练，这存在两个问题，一是cpt好的模型还需要大量的昂贵的instruct指令数据才能变成一个成熟的instruct模型，这里的数据成本和流程依赖会大大延迟模型的训练产出效率。二是SFT阶段的造成的对知识的灾难性遗忘很明显，所以需要在流程上或者数据上再去做混合训练来再SFT阶段输入知识，如：hybrid-turning， structTuning, 我们参考SHADOW-FT 的工作，利用BASE模型和INSTUCT模型在参数和后续SFT，DPO训练上表现的一致性，采用在base模型上SFT，和对齐训练，最后再将变化了的参数用一定的方式和Instuct模型叠加 ，获取相似效果来解决之前提到的两个问题。经验证，这种方式结合 structTuning做SFT阶段名词解释和知识注入，在知识保留上有更好的效果。 五、少数据量情景下的样本构造 使用种子数据，利用WizardLM ,MAGPIE,GraphGen,Condor,Self-Instruct,Self-QA,Self-KG等丰富的方法构造多样的训练数据。 六、科学测评 通用能力，保险通用能力，业务能力三方面展开测评，在保险通用能力上，由于没有开源权威榜单，构造相应榜单。 A. 业务把保险领域能力分为了八个维度，每个维度下有多个子类 •IDK 保险领域知识：保险知识解读、保险科学 •IMI 保险-医疗交叉：医疗实体抽取与标准化、诊断/Q\&A、风险/处方预测 •IME 保险-电商交叉：商品风险点挖掘，用户POI标签 •IUC 保险理解与认知：意图理解、槽位填充（产品/标的/疾病）、属性抽取、条款解释、责任/产品选择分析 •ILR 保险逻辑推理：精算、金融数学、数值计算、免责条款推理 •IPE 保险职业考试：保险、医/药/兽医执业、精算资格、销售人员认证 •ISC 安全与合规：信息安全、基线控制、文档合规、价值对齐、问题识别、事实核查、合规验证 •IMG 营销增长：客户分群、服务总结、营销文案、推荐脚本、投资者教育、人群分类、策略制定 •ISD 服务对话：覆盖产品/监管解读、核保与保全、理赔评估与结算、保后操作、规划配置、条件化方案选择与对比、保费/保障计算等多轮服务对话 B. 任务格式 •多选（MC） •判断（TF） •开放问答（QA） •多轮对话（MD）：模拟真实咨询场景的延伸式对话，要求跨轮次上下文理解与知识应用。 C. 难度 简单（Easy） ， 中等（Medium), 困难（Hard） 1.表格处理优化： 保险有非常多表格，传统OCR识别表格方法，仅输出文本，表格结构被破坏，无法识别单元格的层级和对应关系，我们经过实验，采用最简单的表格序列化方法，利用大模型对于markdown ,HTML 等序列化语言学习能力，对于非常不规则的表格也实现了很好的理解能力 2.利用层级分片（Structural Chunking），保持多长下文之前的全局一致性 适用材料：保险条款 材料特征： 保险条款具有明确的层级结构（章→节→条→款），逻辑严谨，用户问题往往指向具体条文，如“自燃是否属于除外责任”“等待期内能否报销”等。 技术选型： •按原有层级切分，以“条”或“款”为最小单元。 •每个 chunk 需附带元信息，如章节路径（第×章–第×节–第×条）、险种名称、生效日期等。 •延迟切分（Late chunking）：保留全局语义、减少割裂 ◦整篇文档索引：首先以较大粒度（整章或整节）生成语义向量，保留上下文全貌 ◦检索阶段粗召回：查询命中的相关章节 ◦命中区域再细切：在检索到章节内部再按照300--600 tokens动态切分 3.微调训练embedding和基于大模型的rerank模块 对于人，条款，场景等关键内容向量化模块进行训练，增强检索效果。数据构造时可以采用假设回答弥补query 和答案之间的gap,训练的目标，即包含准确性，也包含多样性。 4.用意图识别和deepdoc补全复杂query多库搜索的路由模块 和deepsearch一样，query可能混合多库检索需求，或者混合精确查找和语义查找，用deepdoc进行query改写和查询规划，实现复杂查询。 和人做计划一样，agent做计划，也需要以上四个模块，规划阶段的目标是生成一个高质量、可执行的计划。挑战在于： •理解复杂/模糊的意图： 用户输入往往不精确。 •工具选择的准确性： 如何从众多可用工具中选出最合适的？ •参数生成的正确性： 如何为选定的工具生成正确的输入参数？ •处理依赖关系： 如何正确识别和排序任务之间的依赖？ •应对不确定性： 如何制定能够应对执行过程中可能出现的意外情况的计划？ 我们混合使用三种方式实现意图识别和流程规划 策略一：基于提示词的流程编排和自主规划 （ 以上图片来自网络，侵权请联系作者删除） 将意图识别和流程反思规划的所有部件和流程写在代码或者提示词里。像上面的表格所示的流程编排，可以互相嵌套，实现很大的复杂性和可控性。适合容错率低，回复时长要求高的场景。 也可以采用纯自主agent模式，如下图所示：利用React，preAct 模式，形成 “plan → act → revise plan” 循环，进行更自主的规划。适合容错率高，回复时长要求低的场景。 部分固定用途的模块，如意图分类，工具选择和参数提取等，可以训练小的语言模型来实现更好的性能和准确性。 策略二：基于搜索增强的层级规划 这个链路适合海量工具和复杂环境的情况，可以大大减少模型的上下文压力。 基于搜索增强的知识组织及灵活层级规划流程： •Data(线上化索引)： 业务落地的关键，不仅要沉淀原始数据、明细数据和结果数据，并明确各类数据的含义，还需系统性地记录从原始数据加工至结果数据的全过程逻辑。 •比如利用 embedding 做一个“候选工具/Agent 粗筛”，再让 LLM 做最后决策 •Search： 多智能体扩展的关键，将面向场景的扩展与模型定制化解耦。Agent应用如果伴随模型的定制化优化，将会变成一种很重的模式，从而限制应用的广泛性。用户发布具体任务时，首先将其转化为搜索任务，系统将检索与该任务相关的业务知识、业务逻辑及可用工具等业务导向内容，并提供给大模型进行处理。 •Think\&Plan： 根据搜索结果，大模型利用模型的推理能力、思维链、运筹规划等技术，进行深度思考和任务规划，明确后续需执行的操作并进行优化，如形成一个DAG运行图。 •Do\&Environment： 大模型利用AI NATIVE的业务系统提供的接口，完成系统调用等流程，实现对业务系统的实际操作。在执行过程中，可以利用编写程序，继续搜索等工具，完成现有工具无法涵盖的新任务。 •Reflection： 通过业务系统产生的业务反馈，Agent系统能够自主的思考、优化、沉淀最佳实践，从而持续提升整个链路的运行表现。 策略三：基于RL的自主编排 这个链路适合环境随着agent行为改变比较剧烈的长程规划。我们以赋予智能体“从实践经验中自主学习、持续进化”的能力为核心目标。基于强化学习的模式以最终结果的奖励信号为核心驱动，通过 “行为 - 反馈 - 奖励” 的闭环持续优化策略，这种从结果倒推优化方向的逻辑，与人类 “从实践结果中总结经验、调整决策” 的认知本质高度契合。 智能体的执行过程RL抽象过程： 在关键决策点记录下系统的状态 (State)，并明确是什么调用 (Call)触发了从一个状态到另一个状态的转变，捕获这一系列 状态（State） ：在任务 x 的第 k 次执行中，时间步 t 的状态由一组变量构成： 调用（Call） ：一次完整的执行由 N 次调用组成： 其中第 i 次调用的结构为： •meta：调用的元数据（如组件名、API端点、LLM温度等） •input：调用该组件时提供的输入 •output：组件执行后返回的输出 状态与调用的关系： 带奖励的执行轨迹（Execution with Reward） ：将奖励信号加到每次调用上，得到可用于学习的完整轨迹： 最终将智能体的复杂执行过程抽象为标准的 应用展示： 包涵四个主要部分： •Agent专家角色实现——利用大模型实现保险行业的各专家能力； •Agent专家能力扩展——利用各种外挂工具让Agent更加强大，这些外挂包括： 大脑外挂——记忆模块，让 Agent拥有从经验中学习的能力； 知识外挂——知识库，让 Agent拥有调用外部知识的能力，让Agent的决策更加可控，准确； 手外挂——工具模块，让Agent可以方便的使用各种工具来完成自己的任务。 脚外挂——行为模块，让Agent系统完成与浏览器提供的各种操作。 •Agent专家调度策略——在所有专家Agent之上，更高级认知模块。主要包括反思和计划模块，作用是协调和规划各专家Agent的行为，如任务拆解，优先级排序等，并依据外界反馈，优化Agent的行为。 •Agent专家持续进化——通过反思，训练优化模型表现。 外界任务进入后，Agent通过计划模块将任务拆解为各子任务流程，分派给各专业Agent进行推理。专业Agent调用历史记忆，知识，工具等模块作出决策响应。最后调用行为模块，产生最终行动，作用于EVA浏览器。反思模块再根据浏览器和业务系统的反馈，结合Agent运行产生的记忆，调整优化Agent行为。 经验及时积累，基于self-play 的RL模型进化。 一个自主交互式agent系统，一定要实现自身的进化和成长，不然不足以应对复杂多变的业务场景，而设计一个能从自身和人类经验中学习的系统，是最关键的一步。我们的自主交互式系统如下： •角色是指用LLM的方式进行角色数字员工的角色扮演，模版角色是指利用可以复用于其他场景的基础角色。 •意图识别识别用户意图，我们将意图分为快速问答，知识检索，任务处理 和探索发现类，决定是快速问答，调用知识库，调用任务处理机制，还是上网搜索整合信息以及自由组合多agent完成任务。通过领域与策略的提前区分，平衡速度，准确度，和答案覆盖度。 •知识搜索和工具是可靠的“资料库和听诊器”，结合深度文档搜索功能，提供高质量的答案。主要采用DeepDoc技术完成，将非结构化的文档（如PDF条款）转化为结构化、可查询、可推理的知识对象并进行自主路由和调用。 •记忆系统提供了对话历史和用户背景，分为短期记忆：存储用户最近对话等，长期记忆：存储经常参照的里历史，知识，准则，工作记忆：由LLM抽取器总结的对话和任务状态，情景记忆，对历史不同情景处理的好方案存档。 •策略库是由人，或者大模型反思总结起来的策略，包括观察到某种情况时，如何思考和行动，利用策略库达到badcase可控修复，经验沉淀复用的目的。 •动作空间是Agent可以灵活决策的空间，自主的Agent系统将自由的选择空间中的工具和知识完成用户请求。 •减少幻觉机制是严格的“质检员”，确保每句话都有据可依，在交互前，知识采集时，交互后都可以进行校验确认。 •经验池不断根据反馈挖掘用户对话中的好的策略，形成置信度低于策略库的策略，帮助Agent系统把握最新的事件和风险，学习第一手的人类示范，也可用以丰富策略库内容。 •反思进化模块建立基于强化学习的自训练反思链路，交互（通过经验重放，和环境交互，自我博弈产生数据） →训练（消化数据，优化策略模型和奖励模型） →进化（通过智能体环境循环，让进化步骤自迭代起来） 这个闭环系统确保了智能体在不断试错、学习和自我挑战中，实现真正意义上的“成长”和“进化”。 通过这一整套流程，AI Agent才能在高精度、高风险的任务中，做到既准确又安全，最终成为一个值得信赖的数字员工。 经营结果及时反思，基于智能体角色的离线反思系统设计，实现面向收益和规模的Agent自主优化。 基于结果反馈的离线反思，对于效果也非常重要。 迭代过程： 1.初始化：这个基础版本的智能体们被赋予了预设的角色、目标和工作流程。 2.执行与评估：执行智能体按照基础配置运行，各司其职，完成任务，产生输出。这些输出接着被评估智能体拿去评估，对照着定性和定量的评估标准，打出一个分数。这个分数就反映了系统当前的性能水平。 ****3.优化 ： 优化主智能体分析评估结果，找出改进点。修改智能体 采纳改进方案，调整审核流程 & 规则，AI 评分阈值 & 决策标准。 4.新变体执行与评估：新的系统变体由执行智能体运行，产生新的输出。这些新输出再次被评估智能体评估，打出新的分数。 5.选择与迭代：选择智能体比较新旧变体的分数，如果新变体得分更高，那就说明它更优秀，就把新变体选为最佳变体，替换掉旧的。然后，系统就以这个新的最佳变体为基础，继续进入下一轮的迭代。如果新变体得分没有旧的好，或者提升的幅度很小，低于预设的一个阈值，那系统就会停止迭代，因为这时候再改来改去意义也不大了。当达到最大迭代次数时，系统也会停止。最终，系统会返回最佳变体及其输出，这个最佳变体就是经过多轮迭代优化后的最优系统版本。 落地项目，不仅仅是技术问题，这些技术亮点，大多数时候并不是成功的关键。回头反思，我们能顺利落地这些项目的关键，是有一个支持我们的系统。 纸上得来终觉浅，绝知此事要躬行。尽管我们做了非常多抽象，高定场景业务细节需要算法躬身入局，仔细拆解。 在AI时代，算法了解AI，还需要了解业务。下文我们会仔细分解：定品-定价-履约-风控的目标和打法，与传统时代有啥不一样？看看为啥说理解业务，才是AI落地最关键的一步。 点击查看Eva浏览器视频获得直观感受 通过Eva浏览器打开业务系统，实现无侵入、低耦合采集业务系统页面数据，识别当前用户意图；记录学习用户操作行为，自动生成推荐工作空间。进入空间通过流程编排和多Agent调用，完成AI辅助工作。支持AI对话，多模态输入完成意图识别，调用多Agent精准输出结果，或推荐用户进入相关工作空间快捷开始工作。 Eva智能体引擎：融合原算法引擎高效的数据->特征->规则->模型->编排的全链路能力，支持灵活的智能体搭建功能，支撑业务落地过程的高效、稳定 •数据链接层：支持灵活的数据接入，通过配置不同数据源(Drois、JDBC、Hive、Oss等)将数据接入系统; •算力层：提供算法、模型、数据加工方法的发布、销毁、执行能力，支撑系统对数据的运算能力扩展； •算力调度层：进行计算流量分发，均摊至算力层，同时支持触达业务或其他系统的能力； •算法编排层：主要负责计算状态的流转，包括既定流程型流转和大语言模型自动判断的流转； •算法分流层：主要负责ABTest和数据收集功能，提供支撑算法对结果分析、预测的数据； •算法调用层：业务流量入口； •管理层：对各层能力及结果进行可视化展示。 我们正从简单反应性 prompt 工程时期，走向更强自主性的多智能体上下文工程时期，在这个事情，我们探索出来的最佳分工是： 1.LLM的优化算法的事情。 2.提示词工程是大家的事情，归根结底是业务的事情。 上下文工程现阶段是算法和研发的事情，归根结底是业务和研发的事情。 3.知识库是研发的事情，知识库需要产品化设计，知识库的组织需要数据团队的设计，知识库维护业务的事情。知识的召回，检索是算法的事情。 4.工具建设（mcp,serverless) 是研发的事情，工具灵活调度是算法的事情。 5.多agent的编排调用是业务的事情，agent的自主调度是算法的事情。 6.agent的测评是算法和测试的事情。 7.agent的反思，进化是算法的事情。 以上分工适合当下情况，agent是个快速变化中的技术，可以预见需要以后机动调整。 看场景： 以延保为例，延保服务产品，1款产品0-1产生约10天+，涉及业务、产品精算、合规等，约至少4～6人协作，还要考虑后续监控，经营，履约成本。目前受限于生产方式，当前平均GMV渗透为0.0x%，只覆盖保费规模非常大的传统品类。 1.大量此前未覆盖的蓝海品类需进行快速延保产品设计上品覆盖； 2.成千上万保费规模非常小的场景，可以由agent去提升覆盖率； 3.定品不是一锤子买卖，当一款品卖的不好，或者超赔时候，及时下架，改价格或者调整条款。 得结论： AI时代的定品——追求极致的规模 toC——实时直面用户需求的个性化产品定制。 toB——风险点地毯式搜索，覆盖的产品定制—— “品海战术”； 定品不在是在某个时间点发生，而是通过“自主运营”持续不断的改品（ 改条款，改价格，改上架状态），直至好品产生 。 这将改写之前的定品逻辑，产生规模收入。 技术亮点：deepsearch获取网络信息 + 多维特征深挖场内信息+ 滚动更新保障信息实时 （我们的方案很好的利用统计信息来撬动大模型的创新性） 风险预估准： 预估偏差不高于2%，基于海量数据和机器学习算法，建设千X千面动态定价能力； 经营调整快： 全方位监控实时调整，基于经营预测和运筹优化，从被动调整转为事前主动预防； 报价效率高： 从询价到报价不超过1分钟，用Agent重构询报价流程，建设高效自主的定价专家； 基于AI打造保险行业内预估最准、调整最快、效率最高的定价能力，支撑业务放开手脚、尽情展业 借数据+算法推动业务规模增长，降低边际成本、优化用户体验、提升展业效率，最终驱动订单渗透率、利润等业务核心结果同步增长。 从整个保险供应链来看定价位于产品生产之后位于营销交易之前，其合理性直接影响规模和利润。定价需要通盘考虑保障责任、履约方式、运营成本等多个环节。精准性是基石，快速调整护航经营结果，效率是生产力。 保险定价与实物商品差异点就是，保险定价以风险概率为核心。前者聚焦可见的 “实物成本”，后者紧盯抽象的 “不确定风险”。而风险的动态变化和不确定性也为展业和定价带来巨大挑战。 采用自底向上的建设模式，先夯实底层能力/工具，再建设顶层Agent 之所以采用自底向上的 Agent 建设模式，核心原因在于：当前Agent无法完全代理核保、精算、经营等领域专家做出自主决策，也难以独立完成两类关键任务 —— 一是海量数据下基于机器学习的精准预估，二是百万商家/千万商品下的运筹求解。因此，我们的方案聚焦于 “先夯实底层工具能力，再搭建顶层Agent 交互体系”，分步实现能力落地。 AI定价专家：通过多智能体协同，模拟人类决策逻辑，解决定价不准、经营难、效率低等问题 ** 很多算法面临的困局——Agent如何与机器学习、运筹和数据协同？ ML、OR、Data都可以被Agent调度，都可以是Agent的工具，各司其职 定价Agent：顶层智能体，负责与人交互、整体调度、协调。 机器学习：被Agent调度，用于数据分析和模型预测。 运筹：被Agent调度，用于优化决策和资源分配。 数据：被Agent、机器学习和运筹优化共同调度，作为共享资源。 大模型自主运筹探索和调研 在大模型自主运筹能力的探索与调研中，我们通过对比多款 “基模”在运筹学领域的表现，并针对 7 个挡位的调价场景模拟不同决策粒度后发现：当前基模仅能在小规模问题中呈现较好效果，难以在细粒度决策问题中实现最优化求解。此外，保险定价本身需基于大数定律开展各类杠杆测算，综合考量业务目标达成、ROI等核心因素后，我们最终确定采用 “自底向上” 的能力建设思路。 3.1Master Agent：系统 “大脑” ，承担业务交互、意图识别及任务调度核心职责，是全流程协同的中枢 ** ** 3.2核保Agent：“风险审核与方案优化专家”，以风险可控为前提，探索更具竞争力的报价方案，平衡定价风险与市场竞争力 3.4精算Agent：“定价计算核心引擎”，依托海量数据与机器学习模型，输出科学且可解释的费率表，为报价精准性提供坚实保障 ** 风险预估准：预估偏差不高于2%，基于海量数据和机器学习算法，建设千X千面动态定价能力 在当前保险场景下，随着海量数据持续积累，传统精算方法已难以满足精准、高效的定价。为此，需基于商家经营、产品画像、用户行为、承保履约等多维度数据，结合机器学习技术，构建 “千X千面” 的动态定价体系，最终支撑业务规模与利润的双增长。 打法3(多模型融合预估)：分别建立近7天、10天、15天出险率预估模型，将多模型结果统一校准至满期90天口径，有效提升稳定性和通用性通用性：可快速实现不同保险期间的千店千面定价，定价效率从数月→周级别 打法1(大模型挖掘非结构化特征)：基于商品详情页、保障责任、履约方式等数据，借助大模型多模态能力，将非结构化数据转化为结构化特征 打法2(多产品线联合建模)：针对出险率与赔款预估的样本选取及模型构建，不再依赖经验进行产品线间的物理隔离，而是对质量、意外、全保等多个延保产品线实施联合建模，进一步提升整体预估精准度 打法3(实时报价捕捉风险)：以 “特征-模型-系统” 为核心，深挖风险特征，快迭代特征体系与定价模型，辅以实时询报价系统，敏锐捕捉风险，强化定价准确性与稳定性 3.5经营Agent：“价格运营与策略中心”，以全局视角监控定价全流程效果，为经营决策提供支撑，保障定价与业务目标对齐 ** ** 全方位监控实时调整，基于经营预测和运筹优化，从被动调整转为主动预防 在当前经营中，不仅会因风险预警滞后，让正常的业务经营错失干预时机，还可能因对未来经营趋势判断不足，错失规模扩张窗口与利润优化空间，最终陷入 “调整永远赶不上变化” 的被动局面。 为此，我们建立了一套贯穿 “实时风险感知 - 未来趋势预判 - 科学策略输出” 的全链路闭环管理机制，最终实现从被动应对到主动预防的跃迁。 1)经营实时监测：搭建实时、多维的定价数据罗盘及主动触达机制，防患未然 2)未来经营预测：以历史经营数据结合实时监测指标为基，用机器学习预估经营关键指标，提前识别风险和机遇，实现从被动调整到主动预防的转变 **\ 核心算法: Prophet: 非常适合具有强季节性、节假日效应的时间序列数据，且对缺失值和异常值稳健。 LSTM: 深度学习模型，能捕捉更复杂的长期依赖和非线性模式。 Transformer: 可融合外部变量，实现多变量时间序列预测，精度极高。 输入特征: 历史序列: 指标过去90天的历史值。 外部变量: 是否节假日、是否大促、实时异常信号、天气预报数据。 3)经营策略制定：结合经营预测结果与既定经营目标，通过运筹优化与沙盘模拟，输出科学决策方案 ，切实提升经营决策的效率与精准度 3.6从询价到报价不超过1分钟，用Agent重构询报价流程，建设高效自主的定价专家 在保险询报价场景中，展业人员提交需求后，需反复对接核保沟通风险、等待精算测算费率、同步经营端校验，不仅报价周期长，还因人工经验导致定价偏差 —— 既错失商机，又难平衡风险与市场竞争力。 以询报价Agent为核心彻底重构询报价流程，大幅提升效率。 询报价Agent：Workflow与ReAct相结合的模式，保障稳定性同时具备自主性 7x24小时延保询报价Agent，为用户提供了分钟级报价、方案调整建议、信息查询、知识问答服务。以京Me/Max/PC为载体，通过自然语言交互支持灵活展业，极大提升展业效率。 建设AI原生的定价范式，驱动规模、利润和体验大幅提升 经营预测： 逐步由机器学习升级为 AI 原生大模型预估，攻克数据稀疏、模型拟合不足和泛化能力弱等痛点。 智能决策： 围绕自动建模、加速求解和可解释性构建运筹大模型，解决运筹建模难、求解慢及难解释等痛点。 端到端决策： 建立端到端决策模型，解决先预测后优化误差传递放大和大规模交易场景无法实时决策等痛点。 （ 以上图片来自网络，侵权请联系作者删除） 数据：多源数据底座 聚合保险、集团内部、外部三类数据，为后续模型提供产品线、供应链、市场环境等全维度、多场景的信息基础，支撑复杂业务下的预测与决策需求。 模型：“经营预测 + 智能决策” 双大模型协同 经营预测大模型：基于多源数据，通过 “特征融合” 整合产品线、供应链等海量业务数据，以 “多任务 + 多目标” 基座模型为核心，再经SFT适配业务场景、RLHF迭代优化，最终得到性能更优的模型。该流程实现了从传统统计学模型到机器学习大模型的技术升级，解决了 “拟合能力不足、泛化性差” 的痛点。 智能决策大模型：遵循 “问题描述→数学模型→垂直场景标签→代码编写→模型求解” 的流程，针对运筹优化场景，结合线性规划、整数规划、启发式算法等方法，实现 “自动建模（降低人工经验依赖）、加速求解（多算法适配不同复杂度问题）、结果可解释（垂直场景标签增强业务可读性）”，破解 “运筹建模难、求解慢、难解释” 的痛点。 端到端：OneModel一体化决策闭环 通过动态规划（DP）、统计方法、策略规则等生成监督标签，基于 “多特征输入（m-fea）→共享特征（share fea）→多子模块（sub1/sub2/...）→多输出（op1/op2/...）” 的 E2E 网络架构，搭配多目标损失函数（如 MinSum 融合 MSE 等指标），直接完成 “数据输入→决策输出” 的一体化过程。这种设计既避免了 “先预测后优化” 流程中误差传递放大的问题，也满足了大规模交易场景下的实时决策需求，实现了端到端决策的闭环。 履约成本一定程度决定定价能定多低，从而影响规模，AI时代的履约就是要直面业务指标和约束，追求极致的成本降低。 核心打法——打造多智能体协同的履约AI Agent，理解保险条款，履约方案、申请材料，面向结果(通过or拒绝)决策，决策效果更好(精准性90%+)、决策成本更低(分级)、决策效率更高(产能无上限) 从生产系统调度AI Agent走向AI Agent调度生产系统，通过数据流转互联互通 ** ** 双盲验收测评，分阶段推全上线。 经过抽检与测评，履约理赔AI已全量应用过期赔理赔场景，审核准确率94%+；AI审核覆盖业务单量占比95%+，运行稳定，单均审核成本0.02元；得益于审核范围的全量覆盖，对黑灰产与羊毛党起到震慑作用，理赔申请单量与理赔金额持续下降。 建设覆盖保险全链路的AI风控体系，实现从风险发现到风险处置的全流程自主高效，让保险业务的发展没有黑灰产和羊毛党的后顾之忧。 •核保风控： 在极致耗时要求下，以异步方式应用模型识别结果，预防风险发生。 •理赔风控： 建设实时大模型理解与预测能力，对已知风险评级，及时阻断风险。 •追偿风控： 依托跨时空数据，通过大模型归纳能力发现未知风险，主动追偿。 •全流程自主风控： 实现全流程自主高效的风控，通过各环节协同达成风控闭环治理。 保险业务流程： 当前业务背景及痛点： 保险业务复杂，链路多、周期长：保险业务复杂，各险种业务模式差别较大，整体链路和周期长：包括产品定价、签约、核保、承保、理赔等主要环节。 业务发展迅速，欺诈风险持续存在：保险业务整体发展迅速，像延保、30180等业务规模不断扩展下，也给黑灰产、羊毛党可乘之机，其业务中存在相关欺诈风险，风控侧亟需治理。 黑产变形持续对抗：随着风控侧和黑灰产的对抗，像运费险、晚到赔等业务下，黑灰产攻击手段持续升级，呈现出技术专业化、行为隐蔽化、攻击规模化的特点，风控侧须持续迭代模型，以抵御黑产攻击，保障业务健康。 2.1 核保风控：在极致耗时要求下， 以异步方式应用模型识别结果 ，预防风险发生。 特点： 核保风控环节流量大（核心险种QPS超1000）、耗时要求严苛（响应需≤20ms），无法直接应用模型实时预测风险。 思路： 采用 “预计算+实时调用” 模式，先通过模型提前完成风险识别与判断，将结果转化为标准化标签；核保流程中直接调用预生成标签进行决策，既充分发挥模型的风险识别能力，又满足时效要求，实现风险提前预判。 打法一：通过数据分析挖掘，构建核保环节特征体系，以规则布控预防风险。 针对已知、明确、高确定性的风险模式，依托完善的核保特征体系，使用实时规则进行拦截，做到高效精准。 打法二：结合策略命中及无监督模型挖掘的风险，通过关联分析形成风险名单库。 通过关联分析发现个体背后隐匿的群体性风险和****关联风险，将分散的风险点串联成网，形成动态共享的风险名单库。即使黑产更换了身份证、账号，只要使用了相同的IP、设备或联系方式，依然能被迅速识别出来。 2.2 理赔风控：建设实时大模型理解与预测能力，对已知风险评级，及时阻断风险。 特点： 该环节是保险风控的重中之重，直接决定业务利润空间的大小，对于欺诈理赔请求，直接进行风险拦截可转化为成本节约。相较于核保风控环节，该阶段对耗时的要求稍有放缓，允许我们通过实时模型进行风险决策，并且能够使用比较复杂的模型进行实时识别和风险阻断。 思路： •兼顾和黑产对抗的灵活高效，同时考虑和黑产对抗的鲁棒性和泛化性，采用规则+小模型+大模型的三路并跑的方式进行实时风控治理。 治理阶段： 打法一：规则风控，结合多维度的风险表现，构建完善的特征体系，通过灵活高效的规则布控快速拦截风险。 规则风控主要基于明确的风险表现，将 “风险判定逻辑” 转化为可执行的条件，直接使用规则结果进行拦截，并根据黑产的变化可以灵活快速调整，规则风控承担着 “第一道防线” 的关键角色，主要特点是 “看得见、可解释、易调整”。通过构建完善的风控特征体系，可以覆盖保险业务的风险表现，基于规则引擎进行规则策略的快速布控。不同规则的布控，需结合业务特点和黑灰产的风险表现。详情如下 打法二：小模型风控，利用小模型的成本优势，可以保障风控效果，提高泛化。 当各业务的风控规则积累到一定厚度后，有一定量级的标签和特征数据，可以针对特定场景和风险进行轻量级模型的构建，提高风险对抗的鲁棒性，并进一步增强风险识别的泛化能力。根据模型的作用不同，小模型风控主要包括功能型和决策型两类： •功能型模型：着重对某一个功能的事实性判断，可以在不同业务场景进行快速复用； •决策型模型：可以替代原有的规则引擎，直接进行决策，着重对具体业务和问题进行风险判断。 打法三：大模型风控，基于大模型的通用世界知识及强大的学习理解能力，通过多维度数据融合进行风险决策。 基于小模型进行实时决策，依赖特征工程，在保险业务风控中，通过大模型决策，可整合多维度数据（请求数据、统计特征、行为序列、用户画像等），具备更强的泛化与决策能力，并且仅需少量级的标注数据就可以取得不错的效果。 通过大模型进行实时风险决策，主要思路从欺诈行为的本质出发，捕捉违反业务逻辑（物流时间异常、物流无轨迹）、用户行为异常 （高频理赔、切换设备）、团伙关联 （BC联合、共用设备/IP）、虚假交易 （虚假地址、虚假发货、伪造物流单）以及后续新型欺诈等多类风险信号，可以通过如下阶段： 大模型风控实时决策流程： 2.3 追偿风控：基于跨时空的数据，通过大模型的归纳能力，及时发现未知风险，主动追偿。 特点： 该阶段由于欺诈已经发生且未知，证据链隐藏在跨时空的海量数据中，重点在发现团伙欺诈和未知欺诈模型。对耗时没有硬性要求，可利用的数据最为全面，广度上可使用多域数据(保险、零售、科技、物流、健康、外部数据都可以)，深度上可使用跨时空数据(欺诈发生时刻、发生之前和发生之后的数据都可使用) 思路： 以擅长总结及归纳的无监督算法及大模型为主，同时也要兼顾该环节挖掘风险结果的使用，可通过不同颗粒度的时效进行应用，以反哺其他风控环节。 打法一：通过数据统计及关联分析方法，挖掘明显的作案风险。 主要通过对“电商交易 - 保险行为 - 跨域关联”全链路数据的深度分析，识别隐藏的欺诈模式、不合理赔付风险等，包括单维度异常识别和多维度关联方法等。 打法二：通过无监督算法，发现具有一定规模及隐蔽性的风险模式。 主要是从无标注的海量数据中，自主发现隐藏的风险模式（如欺诈团伙、异常群体等），无需依赖历史欺诈标签。主要包括社区发现算法等。 团伙挖掘： 核保风控： 目前以标签的形式周期性应用模型结果，小时级别进行团伙挖掘，自动应用于签约、核保等环节，已在运费险、外卖险、质保金等业务应用。 理赔风控： 实时反欺诈模型、异常图像识别模型、社区发现模型等在保险核心业务场景应用，并实现实时大模型风控在保险及集团的首次应用。 •场景覆盖：包括运费险、延保等核心险种； •线上效果：风控模型累计减损数千万； •大模型风控：具有良好的泛化性和鲁棒性，并且只使用了小模型5%的数据就能覆盖其99%的拦截效果且还有额外新增，成本也几乎没有增加。对于黑灰产攻击，有很好的拦截效果，过往可以达到99.95% 的拦截率。 追偿风控：目前社区发现算法、关联方法等应用在运费险、外卖险、延保等主要险种，可以实现分钟级别的更新及应用，可支持打击侧同事近一步分析及追偿，同时将风险结果以标签形式应用于线上。 4.1 夯实核心环节的风控能力，并扩大应用覆盖范围 核保风控： 结合多模态数据，通过大模型预测风险概率，生成标准化标签。离线形式下，不再孤立处理数据，将核保、理赔、追偿环节中的结构化数据与非结构化文本、图像数据融合，通过大模型进行深度关联分析与推理，生成远超单一数据维度的、具有高预测价值的风险概率标签。 理赔风控：完善覆盖欺诈本质的语料知识库，通过多模态数据融合提高大模型风控的风险识别能力。同时，构建保险通用风控大模型，只需针对特定业务风险微调模型即可快速应用。 追偿风控： 基于知识图谱和大模型，挖掘具有关联性的隐性及潜在风险。知识图谱具有结构化的特点，有可推理能力，大模型具有语义理解及生成的能力，将二者结合起来可以提升风险挖掘的深度和广度。 业务覆盖： 扩展当前风控能力的覆盖范围，实现核心业务险种的全覆盖。 4.2 实现全流程自主高效风控，通过各环节协同达成风控闭环治理 基于多智能体协同实现保险全流程自主风控体系，其核心是建立一个中央指挥智能体—风控Master Agent，像“风控大脑”一样统筹调度核保、理赔、追偿各子环节Agent。整个运作机制形成了一个“感知-决策-执行-评估-优化”的强闭环，使系统能够不断自我迭代。 通过风控Master Agent统筹调度核保、理赔、追偿各子环节Agent，实现从全局感知、智能决策、协同执行到效果评估的闭环自治。 全流程自主风控： ** 结果第一： 1.夯实保险B端供应链Agent建设， Agent带来的直接利润占业务总利润 30%以上。 2.toC 场景发力，保顾，客服数字人服务客户，拓展规模。 3.在持续沉淀toB能力基础上，打造200+AI数字员工，大幅降低边际成本、提升运营效率。 技术为本： 💡1.持续优化自主Agent系统，让Agent更加AI Native，更加智能。一、 AI Agent落地方法论与技术点
1.怎么选场景，定目标？
R = (Ch - Ca) × D × A × SA= M /（TI）为什么说保险供应链的生产流程非常适合AI Agent落地？
直面经营结果(规模/利润)增长而非过程指标的目标设计
2.AI应用于生产是什么样的，需要怎样的技术积累？
亮点一：领域大模型——场景业务模型微调+小尺寸大模型学习保险数据及行业偏好。
亮点二：知识库，适配业务的深度检索
转换后的表格<table>| 保障类型 | 场景 | 区域 | 报销比例 | 免赔额 |保障类型：住院医疗 | 场景：一般住院 | 区域：国内 | 报销比例：80% | 免赔额：1000元 保障类型：住院医疗 | 场景：一般住院 | 区域：境外 | 报销比例：60% | 免赔额：2000元 保障类型：住院医疗 | 场景：意外住院（含手术） | 区域：全部 | 报销比例：90% | 免赔额：500元 保障类型：门急诊 | 场景：一般门诊 | 区域：国内 | 报销比例：70% | 免赔额：200元 保障类型：门急诊 | 场景：特殊门诊（含肿瘤放疗） | 区域：全部 | 报销比例：85% | 免赔额：300元</table>
亮点三: Agent做计划，三种策略满足不同场景。
(状态 -> 调用 -> 新状态)的序列。
(component， input， output， reward)序列，在智能体的具体实现逻辑与通用的RL训练算法之间架起了一座桥梁，实现了二者的解耦。
亮点四：如名称Eva（进化）所暗示，架构设计重点保障成长性。
Eva Agent模块：
3.经验回顾，什么是成功落地关键点？
1.算法向前一步，深入拆解业务，进行AI时代打法设计，搞定高定场景。
2.前、中、后台设计，助力全链路Agent覆盖
Eva智能浏览器：服务于保险业务各环节，实现与现有保险生产系统的⽆侵⼊集成，打开Eva浏览器自动具备AI助手功能，加速业务系统实现AI化升级
Eva智能工作台：打造人与AI教学相长的协作模式，支持快速、高效的业务知识输入和智能体创建，支持AI决策过程的可观测、可运营、可接管，建设透明、可信的智能体过程
3.探索出AI时代的分工，大家搞，才能真的好
二、AI定品
1. AI时代直面业务增长的AI定品能力是怎样的？
2. 保险定品的技术设计
3. 当前进展和取得的效果
三、AI定价
1.从目前业务模式出发，直面业务结果的保险定价能力是什么样？
2.为什么风险预估准、经营调整快、报价效率高是驱动规模增长的关键？
3.直面结果的保险定价Agent怎么做？
**通用性：可快速实现不同保险期间的千店千面定价，定价效率从数月→周级别
预测目标:** 未来N天每天的整体出险率、保费收入、赔付支出等。
4.未来我们怎么做？
四、AI履约
1. 直面业务增长的AI履约能力是怎样的？
2.保险履约的技术设计
3. 当前进展和预期
五、AI风控
1. 结合保险业务特点，AI驱动的全链路风控体系应该是什么样？
2. AI驱动的全链路风控应该怎么做？
3. 当前进展和取得的效果
4.未来我们怎么做？
六、回顾
以AI驱动的保险供应链X产品线25年为业务带来15%+利润
**
七、展望
今天不想讲那些技术架构图，也不想堆砌一堆iOS专业术语。我就想聊聊，作为一个离用户最近的客户端开发，我是怎么看待AI的——它到底是让咱们的产品变更好了，还是变更拧巴了。梁宁老师在《增长三十讲》里说过一句话特别打动我："产品经理要有同理心，要能感受到用户的爽点、痛点和痒点。"今天我想说，做技术的人也得有同理心。不只是对用户，更是对我们自己。 这种场景你们熟不熟悉： AI同学："我们的新模型精度提升了10个点，识别更准了！" 3D同学："等等，你这模型多大啊？" AI同学："也就60MB，还行吧。" 3D同学："那推理时间呢？ AI同学："大概增加了30-40ms……" 客户端同学心里咯噔一下："完了，这玩意儿肯定得出事。" 产品经理："太好了！竞品最近上了很多AI功能，我们也得跟上！" 具体数字每次不太一样，但这个对话的"味儿"，基本就是这样。 功能上线or demo演示第二天，用户反馈炸了： 领导问："怎么回事？不是说AI很智能吗？"我们说："AI是很智能，但用户的手机不够智能。" 所以今天我想和大家聊聊，怎么避免这种"好心办坏事"。 每个人都是对的： 但系统错了。 梁宁说，"很多时候，你觉得是做加法，但对用户来说是做减法。"AI功能加上去了，但用户体验减下来了。 爽点：即时满足痛点：恐惧、焦虑痒点：满足虚拟自我放到移动端AR里：用户的爽点： 用户的痛点： 用户的痒点： 很多人以为AI是爽点。但实际上，AI做不好，就是最大的痛点。为什么？因为用户不关心你用了多牛逼的模型，他只关心： AI如果让这5个变差，用户不会夸你智能，只会骂你智障。 最大的感受就是：不要用你自己的iPhone15Pro来代表用户 真实情况是： 同一个AI模型： 性能差距：接近10倍！ 移动端的独特挑战：1. 多任务干扰 从我的观察和行业数据来看： 使用特点： 用户容忍度： 根据应用商店评论和用户反馈， 负面评价主要集中在：卡顿、发热、耗电。 梁宁强调，好产品要给用户确定性。什么叫确定性？就是用户知道会发生什么，并且确实发生了。 反例：只为高端设备优化 正例：分层体验 误区1："模型越大越好"这是技术人的执念。AI同学会说："我们的模型精度提升了5个点！"但用户不会说："哇，精度从89%提升到94%，我好感动！"用户只会说："为什么我的手机这么烫？"梁宁视角：你在追求技术指标，用户在追求情绪稳定。 误区2："端侧AI就是先进"很多团队为了宣传，强调"本地AI、保护隐私"。但真相是： 没有绝对的优劣，只有场景适配。实时交互（如手势识别）：必须端侧非实时分析（如场景理解）：可以云端，梁宁视角：不要为了"先进"而先进，要为了"用户体验"而先进。 误区3："AI失败了就提示用户"最常见的做法： AI识别失败 → 弹窗："识别失败，请重试" → 用户：？？？ 这是最烂的体验。更好的做法： AI识别失败 → 自动降级到传统方案 → 用户无感知 → 核心功能继续可用 梁宁视角：别让用户承担你的技术缺陷。技术的不确定性，不应该转嫁给用户。 梁宁说，"产品要克制"。我对AI的理解也是：克制。 案例：手势识别模型优化 原始模型：60MB，精度94% → 量化后：15MB，精度92%（损失2%） → 剪枝后：8MB，精度89%（损失5%） → 蒸馏后：3MB，精度85%（损失9%） 决策： 牺牲9%精度，换来100%覆盖率。梁宁视角：让80%的人满意，比让20%的人惊艳更重要。 永远不要让用户看到"功能不可用"。 分层设计： L1（保底）：所有设备都能跑 L2（标准）：中高端设备体验更好 L3（高级）：旗舰设备极致体验 动态监控： 运行中监控： 用户感受： 梁宁视角：确定性= 用户知道最坏会怎样，并且最坏也还能接受。 不是所有AI都要端侧跑。 实时场景（端侧）： 非实时场景（云端）： 网络不好时： 梁宁视角：系统要有冗余，有备份，不能把所有鸡蛋放一个篮子。 梁宁说，"用户要的不是你的产品，是他问题的解决方案。"用户的问题是： 所以： AI是工具，不是目的。 第一反应：用ARKit手部追踪，系统级能力。 设备兼容性： 性能开销： 功能适配： 系统能力很好，但有边界。 我们需要： 梁宁说，"要理解不同用户的不同需求。"我们设计了三层： L1：传统交互（100%用户） L2：ARKit手势（60-70%用户） L3：自定义AI（10-20%用户） 用户使用过程中，设备状态会变化： 每秒检测： 用户感受： 这种分层设计的结果： ✅ 100%用户可用（这是底线） ✅ 大部分用户能体验到手势交互（60-70%） ✅ 卡顿投诉显著下降 ✅ 帧率更稳定，体验更流畅 梁宁视角：这叫"分层满足"。 高端用户有高端体验， 普通用户有稳定体验， 所有人都没有被抛弃。A 正例（基于行业观察）： 一些做得好的AR应用会这样设计： 这种分层设计的效果： 梁宁视角：AI应该降低门槛，而不是提高门槛。 ARKit虽然"免费"（不用下载模型），但： 系统能力也有成本，不要以为调个API就完事了。 梁宁说，"不要让完美成为好的敌人。"移动端开发最大的教训： 精度从94%降到85%，换来设备覆盖率从20%提升到100%，值不值？值。因为用户要的不是你的精度数字，是"能不能用"。 梁宁说，"产品要有底线思维。"AI会失败，这是确定的。所以： 60%用户好体验+ 40%用户能用，远比80%用户都不够好更明智。 理解：客户端不是服务器。提供： 最重要的是轻量版！因为它决定了产品的下限。 理解：GPU是共享资源。提供： 我们一起守护用户的帧率。 理解：不是所有功能都要加。思考： 梁宁说："产品要克制。" 刚入行时，我追求技术极致。现在我明白，技术的价值在于让更多人受益。80%的人能用，比20%的人惊艳更重要。 十年前，产品说加功能，我就加。现在我会问： 梁宁说，"产品经理要有同理心。"我想说，客户端开发也要有同理心。我们最懂用户的真实设备和使用场景。所以我们有责任说： 我们不只是写代码，是为用户体验把关。 回到标题这个问题。答案是： 用得好： 用得不好： AI让设备卡顿发热 提高使用门槛 用户体验变差 这不是AI的错，是我们用AI的方式。 关键在于： 同理心 理解用户的设备、场景、情绪 克制 不是所有地方都要用AI 分层 让所有人都能用，只是精细度不同 保底 永远有Plan B，永远不让用户卡死平均使用时长： 梁宁说："好的产品，是克制的产品。"我说："好的AI集成，是克制的AI集成。" 这次分享的核心信念：> 技术的价值不在于"我们能做到多先进"，而在于"我们能让多少人受益"。移动端开发的本质：> 在约束中找到最大公约数，让大部分人满意。这需要： ═══════════════════════════════════════ ═══════════════════════════════════════ 数据参考： XR性能测试。。写在前面的话
一、开场：一个真实的冲突场景
先讲个事儿
然后真出事了
这就是梁宁说的"系统思维"缺失
二、用户真正要的是什么？——梁宁的"爽点、痛点、痒点"
梁宁的理论我是这么理解的
AI在这里的定位是什么？
三、移动端的残酷真相：80%用户用的不是旗舰机
设备碎片化有多恐怖？
场景碎片化
梁宁说的"确定性"在哪里？
四、AI部分深入：不是技术问题，是人性问题
1. AI的三个常见误区
2. AI在移动端的正确打开方式
原则1：轻量化优先
模型大小 设备覆盖率 精度 60MB（原始版） ▌▌ 20% 94% ⚠️ 15MB（量化版） ▌▌▌▌▌ 70% 92% 👍 8MB（ 剪枝版） ▌▌▌▌▌▌ 85% 89% 👍 3MB（Lite版 ） ▌▌▌▌▌▌▌100 85% ✅ 原则2：优雅降级
↓
↓
原则3：端云协同
3. AI不是炫技，是解决问题
五、思考：如果要做AR手势交互，怎么选方案？
假设场景：我们要做一个AR应用的手势交互。
但需要考虑这些问题
重新设计：分层适配
动态降级：核心逻辑
结果
六、AI在移动端的4个核心洞察
洞察1：AI是提效工具，不是门槛
洞察2：免费≠无成本
洞察3：80%能用 > 20%完美
洞察4：保底方案决定产品下限
七、站在不同视角
站在AI视角
站在3D引擎视角
站在产品视角
八、三点感悟
感悟1：技术是为人服务的
感悟2：不要只做功能，要做体验
感悟3：客户端是用户的守门员
九、总结：AI给移动端续命，还是催命？
最后的话
谢谢大家
─────────
欢迎交流讨论
随着京东业务增长、平台商家数的大幅增加，京东的订单量急剧上涨，尤其是2025年京东发力本地生活业务，给B端订单存储带来较大压力； 另一方面京喜自营做为京东低价策略心智的店铺，业务增长也是非常迅猛，一个店铺订单相当于几十近百个店铺单量总和。基于以上订单ES存储面临极大挑战，系统架构升级迫在眉睫。 本文主要介绍B端pop订单异构系统当前系统架构现状，阐述下我们面临的主要问题、以及解决思路和技术升级方案（后续持续更会有更多的技术方案细节文章）；一方面为了介绍下我们当时解决问题的一些心路历程，另一方面也未了能让大家更好的了解目前这套运行了多年的系统为什么以这种形式存在、以及目前我们遇到的核心问题有哪些，对于订单ES架构存储的升级方案是什么样的。 POP订单ES最早定位是对商家提供待履约订单查询服务（非C端检索）。系统核心是写和读两个服务，写服务消费订单管道消息、pop订单JED的binlog、OFW的ODC变更消息、台账系统对账消息等更新订单ES数据；读服务提供订单列表（商家维度）、订单详情的检索服务。 系统之初仅支持已付款且达到可履约状态的订单（不包含未付款订单）检索，用户商家订单履约，主要服务于开放订单API检索及京麦端订单检索。随着业务的发展，后续消费了提单、订单拆分、预售订单等消息，对未付款订单、预售订单存储、兼容处理。 随着百万商家项目推进，服务商、自研KA商家及中小开发者对开放API提出了更多的诉求，期望能够通过更少的接口获取更多的数据，提升开发者对接及日常维护效率，开放平台侧启动开放RESTful API项目，其中订单做为商家的核心业务数据，历史开放接口不够内聚，开发者需要多个接口才能获取完整的订单信息，基于以上pop订单还异构了发票、promise、售后、评价等系统的状态信息，这些都给POP订单ES存储带来较大的挑战。 •应用层做业务处理 ， 写服务负责消费上游各方MQ处理业务务处理，之后调用代理层服务更新订单信息；读服务核心对外提供订单列表、详情两个服务。大促高峰时可达到每分钟70万次更新写入，每分钟50万的检索查询； •代理层负责数据路由、读取与写入。划分为热集群读写代理、归档集群读写代理。热集群通过设置不同topic分组隔离消费实现双流架构，汇天廊坊互为主备保证系统高可用。读服务支持动态路由配置，可根据ES负载情况动态分配流量，如汇天、廊坊各百分之50流量，或汇天20%，廊坊80%；同时可以将某个商家查询流量路由到固定机房。目前归档集群考虑成本暂时并未升级至双流架构，通过ES副本机制来保障高可用。 •存储层采用ES做为存储介质，分为热集群、归档集群；热集群存储近8个月的订单数据，单个集群有98个节点（3个主节点，10个网关节点，85个数据节点）。集群中共计12个索引，其中11个KA索引（存储大商家订单数据），每个索引只有1个主分片（1副本）；普通商家索引有96各数据分片（1副本）；冷集群存储了16年至2024年所有的订单数据，每年创建一个索引，每个索引96分片（1副本）。 pop订单改造前的架构图如下： （为方便让大家更好理解，本图会忽略一些细节便于大家理解）： 1、目前POP订单ES存在较严重的数据倾斜问题，由于是B端订单检索为了不跨索引和分片检索数据，是以venderId维度进行路由分片，确保同一个商家的订单数据存储在同一个分片。但商家的经营情况差异较大，如上边所说京喜自营做为一个京东自己运营的店铺，订单体量可以占到总订单量的1/4，类似于这样的大商家落到一个数据分片会导致某个数据分片存储超级大，最大的数据分片已经到了1TB以上。大商家的一个复杂检索查询会对所有在该分片上的商家产生较大性能波动，同时若硬件故障大分片数据在恢复迁移时都是在灾难性的。下边是升级前汇天集群部分分片数据的统计信息，数据差异达5倍之多。 2、随着业务增长，自身的订单ES数据量持续增加，部分分片数据高达1TBG以上，ES官方推荐分片数据在50-100G，已经是官方推荐值的50倍。京喜自营订单属于二段单逻辑，C端京喜大店下单，订单会由供货商去履约，供货商同时还会是京东的一个pop商家，这个订单在京喜店铺存储一份，同时会在供应商店铺下会在存储一份，京喜大店业务给整个存储带来了0.5倍增长。 3、ES的核心数据源是上游订单数据库的binlog消息，随着业务不断迭代，接入了更多的消息如：order\_submit（提单）、delete\_parent\_order（拆单）、orderpipe\_edit\_v2（管道修改）、ODC（锁定、解锁、取消）、order\_state\_zanting（暂停）、afs\_status（售后状态）、comment\_change(备注变更)等将近10+的消息。订单ES更新频次持续增加，每分钟高达30万，每新增一个MQ消费，每个订单至少会增加1次更新操作。ES的更新冲突明显增加，对于订单检索的时效性也带来了很大压力。 4、数据维护成本高， 目前我们有冷热两个集群，每年两次大促前需要将热集群中超过5个月以上的订单迁移至归档集群，这个过程相对比较繁琐耗时长，DUCC变更、迁移数据、比对数据、灰度切流等等。周期较长主要是以下两个原因： 1.数据迁移范围强依赖上游订单JED线上库，速度过快对线上有影响，同时还会反查ES数据比对给线上ES也带来较大查询压力，导致无法再白天运行。 2.整个写入过程均为单个订单写入、删除ES，过程中会产生大量的Segment merge，将小段合并成大段，会影响写入性能，导致正常订单更新延迟。 数据倾斜问题核心是我们采用了venderId进行路由，商家的体量不可控，在最初相关同学已经考虑到了这种情况，在热集群中创建了对应的单独索引进行隔离，但当时这个索引创建的时候只有一个shards，数据集中在一个分片上，并不能解决数据倾斜问题（数据仍集中在一个分片上，可能考虑跨分片聚合数据的性能问题）。 1.物理层隔离，降低影响： 为大商家申请独立集群进行存储，在独立集群中为每个商家创建独立索引并根据体量配置不同的分片数量。代理层增加大商家虚拟路由逻辑， 将大商家的请求routing到独立集群中指定索引，降低了大商家对其他商家带来的不确定性影响。 2.灵活的路由分片策略： 原有路由策略仅支持商家维度，在代理层对集群分片路由规则做扩展支持，针对大商家存储集群的分片路由商家维度升级为订单维度，根据订单号进行路由保证各分片数据的均等。 ES官方建议单分片数据控制在50-100G，同时ES集群节点（网关、主节点、数据节点）数量控制在100个以内（故障恢复时长考虑，可参考附录5）。基于这两个原则，单集群已无法满足存储诉求，当时也考虑了更换存储介质，考虑到端上丰富的查询诉求，团队内部研讨后决定继续采用ES。 我们决定将热集群中普通商家的ES集群由1个扩展至3个（基于当前业务发展及成本综合考量决定）。在数据代理层扩展集群路由逻辑，基于商家id哈希将商家数据分散到3个ES集群。 当前系统采用了ES的乐观锁更新机制，在收到上游消息后，第一步获取ES版本号，第二部设置更新字段，第三部保存更新，保存更新版本冲突会发送一个重试MQ进行重试。 经过分析订单变为待出库前的消息比较集中，上游各系统基本都是同步消费订单管道消息完成业务操作后对外广播消息，这些消息同时到达我们系统，一方面存在并发冲突问题，第二方面是给ES带来了较大的更新压力。为了降低ES的更新压力，考虑增加一个挡板对消息进行汇总整型降低ES的更新次数，同时减少ES的更新冲突问题。 3.4 日常数据维护成本高的问题 受限于ES集群节点数量是有上限，大促前都需要对热集群订单数据进行归档操作，由热集群迁移至冷集群。系统初始是通过一个归档任务来进行迁移操作。首先圈定迁移数据的范围逐条读取--->逐条写入归档集群--->比对数据无误--->删除热集群数据。业务高峰期无法操作，新增、修改、删除对频繁删除会产生很多的段文件，ES定期对段文件进行merge操作（详情可参照附录部分内容），单次数据迁移大概耗时1个月左右时间，操作过程也较繁琐。我们的目标是全流程自动化的数据迁移无需人工介入，仅需要关注相关业务监控即可。考虑到资源及ROI问题，数据迁移改造共经历了两个阶段： 第一阶段通过通过reindex方式迁移数据，然后通过回放归档消息的方式追齐过程中的数据变更。该方案一定程度缩减了整体的时间及工作量，相较之前效率上大幅提升，时间大概由原来的20多天缩减至10天左右。 第二阶实现数据归档的全流程自动化操作。新建归档ES缓存，每天一个索引，把每天订单变更记录保存至索引中。通过一个定时任务批量读取、比对、写入同时删除原集群中数据。 本次升级通过 “租户分级隔离 + 双层 Hash 路由 + 差异化分片策略 + 双活物理底座” 的组合拳，成功构建了一个 高性能、高扩展、高可用 的企业级订单检索与分析平台，完美支撑了业务量的爆发式增长。 ES 是一个 P2P（对等）架构的分布式系统，虽然有 Master 节点，但所有节点都需要保存集群的状态。核心瓶颈：Cluster State（集群状态）的广播 ES 的 Master 节点负责维护 每一次变更（如创建索引、Mapping 变更、节点上下线），Master 都要把更新后的 Cluster State 广播给集群内的所有节点；所有节点收到后，都需要向 Master 确认（Ack）。 当节点数超过 100 时会面临以下问题： 1）网络风暴： Master 发布一次状态更新，需要处理大量的网络包。如果更新频繁（例如大量创建索引），Master 的带宽和 CPU 会瞬间饱和。 2）收敛慢： 必须等待绝大多数节点确认，集群状态才能生效。节点越多，遇到“慢节点”拖累整体变更速度的概率就越大。 3）Full GC 风险： 大集群通常意味着分片数巨多。Cluster State 对象在内存中会变得非常大（几十 MB 甚至上百 MB）。Master 节点在处理这个巨型对象时，极易发生 Full GC 导致假死。 要理解压力的来源，必须理解 ES（基于 Lucene）的 “不可变性” (Immutability) 原则。核心机制：伪更新 (Delete + Insert) 在 ES 内部，根本不存在物理意义上的“修改”操作。当你执行一个 Update 请求时，ES 实际上在做以下三步： 1.读取 (Read): 取出旧文档（如果是 Partial Update，它需要先通过 \_source 字段获取完整文档）。 2.标记删除 (Soft Delete): 在旧的 Segment（段）文件中，将旧文档的 ID 标记为 .del（逻辑删除，类似墓碑）。 3.写入新文档 (Insert): 将修改后的新文档作为一个全新的 Document 写入到新的 Segment 中，并分配新的 \_version 号。 这意味着，更新不仅仅是 IO 操作，它还涉及大量的 CPU 计算（重新分词、重新索引）。 1、磁盘 I/O 爆炸与 Segment Merge（段合并）风暴 •现象： 磁盘 I/O 持续 100%，写入拒绝（Rejection）。 •原因： 每次 Update 都会产生一个新的小 Segment。ES 后台为了优化查询，会不断触发 Segment Merge，将小段合并成大段，并物理剔除被标记为 .del 的数据。 •压力点： 高频更新会导致 Merge 线程极其繁忙，消耗大量的磁盘 IOPS 和 CPU。如果 Merge 速度跟不上产生碎片的速度，ES 会启动 Throttling（写入限流），导致你的写入请求被阻塞。 2、查询性能随着“墓碑”增加而衰退 •现象： 即使数据量看起来没变，查询延迟却越来越高。 •原因： 虽然旧文档被标记删除了，但在物理合并发生前，它们依然存在于索引中。 •搜索开销： 查询时，ES 必须扫描所有文档（包括旧的），然后在最后阶段通过 .del 文件过滤掉已删除的文档。如果你的索引中有 50% 是“墓碑”数据，查询效率就会大打折扣。 •BitSet 内存占用： 维护大量的删除标记需要消耗堆内存。 3、缓存失效 (Cache Invalidation) •现象： Filter Cache（Node Query Cache）命中率极低。 •原因： ES 的 Filter Cache 是基于 Segment 的。一旦 Segment 因为 Merge 发生了变化，或者产生了新的 Segment，旧的缓存就会失效。高频更新导致 Segment 频繁变动，缓存根本热不起来，查询请求会直接击穿到底层磁盘。 4、GC (垃圾回收) 压力 •原因： Update 过程涉及将旧文档读入内存、反序列化、修改、再序列化。这会产生大量的临时对象，增加 JVM 的 Young GC 频率。如果 Merge 压力过大导致内存堆积，甚至可能触发 Old GC 或 Full GC，导致节点 "Stop-the-World"。导读
一、系统现状
1.1 业务背景介绍：
1.2 系统架构简介：
二、系统当前的核心痛点
三、解决方案
3.1 数据倾斜问题
3.2 集群中单数据分片过大问题
3.3 ES频繁更新的问题
3.4 终局方案
四、附录：
4.1 超大集群维护的挑战
Cluster State（包含所有索引的 Mapping、Setting、分片路由表等元数据）。4.2 ES更新细节
4.3 频繁更新带来的四大压力：
本教程主要用于构建一个物理服务器自动化交付的系统，当一个物理服务器上电、配置好IPMI、RAID后。通过PXE可自动安装好一个操作系统在系统盘，并配置好网卡、SSH连接信息。 cloudpods 云平台支持 Baremetal(物理机) 管理，提供的功能如下: 使用 Docker Compose 快速部署 Cloudpods Baremetal 物理机管理服务。(单节点) docker 版本: ce-26.1.3+ 国内参考文档：https://help.mirror.nju.edu.cn/docker-ce/?mirror=NJU 官方文档安装：Install Docker Engine PS：也可以用国内的Gitee下载：https://gitee.com/songxwn/ocboot/raw/master/compose/baremetal/docker-compose.yml 运行服务，注意需要设置 LISTEN\_INTERFACE 和 PUBLIC\_IP 两个环境变量。 下面命令假设 eth0 网卡上的 ip 地址为 10.168.222.205，具体设置请根据自己的环境设置。 等服务启动完成后，就可以登陆 https\://$PUBLIC\_IP 访问前端服务，默认登陆用户密码为：admin 和 admin\@123。 物理机管理服务部署完成后，接下来纳管物理机测试。 注意 待纳管的物理机信息： IPMI 带外信息: 纳管物理机，需要创建PXE、IPMI、物理机 3个类型的 IP 子网。 这三个网段最好是运行服务所在节点网络可达的，请根据自己的网络环境设置。 点击前端“网络/IP子网/新建"，创建以下的三个子网。 假设需要给物理机 PXE 启动的网段为 192.168.77.100 到 192.168.77.200，网关为 192.168.77.1，并设置 dhcp\_relay 为 PUBLIC\_IP，名称为 bmnet-0，服务器类型选择PXE。 注意： 这里一定要设置 dhcp\_relay 为 PUBLIC\_IP，在这个环境中是 192.168.77.12，请根据自己环境修改。 该网段需要包含物理机的 ipmi ip，假设为 192.168.222.200 到 192.168.222.210，网关为 192.168.222.1，名称为 ipmi-0，类型为IPMI。 该网段需要包含物理机的业务网卡的网段，其他要求一样。 在Web管理控制台添加物理机，点击”主机/基础资源/物理机/添加”，选择 “PXE 注册引导”，输入对应的物理机纳管信息。 IPMI 信息（这些以具体机器所在环境为准） 管理口 MAC 地址: 00:0C:29:01:3E:C1 创建完成后，在物理机列表可以看到机器处于“准备中”的状态，并且探测到了品牌为 Lenovo 。(得确保IPMI 可连接到) 可以通过访问物理机的带外控制台，会看到物理机开始 PXE 引导，如果网络配置没有问题，物理机会获得物理机管理服务下发的 grub 引导配置。 获取 grub 配置后，物理机会从管理服务的 PUBLIC\_IP 下载内核和 initramfs。 下载完成后，就会进入 yunionos 内存系统。 之后平台的服务会通过 ssh 远程探测收集物理机的硬件信息，等物理机变成“运行中”的状态，就算纳管成功了。 勾选对应的物理机，点击启用，就可以进行后续的安装操作系统等操作。 点击“主机/系统镜像/上传”按钮，导入需要装机的镜像。 等待镜像状态变成“可用”，就可以将此镜像用于安装操作系统了。 https://cloud.debian.org/images/cloud/bookworm/latest/debian-... KVM安装一个Debian 12虚拟机(安装好软件包和配置)，将镜像下载下来。qemu-img convert -f qcow2 -O raw debian-disk.qcow2 debian-disk.raw 等待镜像状态变成“可用”，就可以将此镜像用于安装操作系统了。 点击“主机/基础资源/物理机” 选择一个物理机 点击更多选择启用，然后选择安装操作系统。 可以使用 '-d/--detach' 参数把所有服务放到后台运行，命令如下： 如果要使用命令行工具对平台做操作，可以使用下面的方法进入容器： 当物理机通过 pxe 启动成功后，会引导进入一个内存 linux 系统，可以通过下面的方式 ssh 进入这个系统，遇到错误的时候方便排查。 另外也可以通过 如果物理机 pxe 内存系统上报登录信息失败，则会设置成默认的密码：mosbaremetal，对应逻辑可参考通知代码。 所有服务的持久化数据都是存储在 cloudpods-baremetal/data 目录下面的，所有配置都是自动生成的，一般不需要手动修改，下面对各个目录做说明： 所有服务的持久化数据都是存储在 cloudpods-baremetal/compose/data 目录下面的，删除容器不会丢失数据，下次直接用 docker compose up 重启即可，操作如下： 当上游的 ocboot/compose/baremetal/docker-compose.yml 更新了，就可以通过 curl 命令下载最新的配置文件，然后重新启动就可以了，步骤如下： 拉取最新的 docker-compose.yml 配置文件后，使用下面命令重启服务就行了。 发送邮件到 ➡️ me@songxwn.com 或者关注WX公众号：网工格物简介
功能概览
支持安装的操作系统
Docker Compose 快速安装和使用
环境准备
服务器配置要求
服务器网卡要求
安装配置Docker CE
部署运行 Cloudpods Baremetal 服务
在部署机器上创建 cloudpods-baremetal 目录，并且进入该目录。
cd /opt
mkdir cloudpods-baremetal
cd cloudpods-baremetal使用下面的命令，把运行物理机管理的 docker compose 配置文件下载下来。
curl https://raw.githubusercontent.com/yunionio/ocboot/master/compose/baremetal/docker-compose.yml -o docker-compose.yaml在 cloudpods-baremetal 目录运行下面的 docker compose 命令正式开始安装
ip addr show 查看对应网卡上的地址。LISTEN_INTERFACE=eth0 PUBLIC_IP=10.168.222.205 docker compose up -d
纳管物理机教程
1. 创建网段
创建一个PXE类型的子网
创建一个 IPMI 类型的子网
创建一个物理机类型的业务子网
查看创建好的3个网段
2.1 PXE引导注册纳管物理机(有IPMI\&BMC)
2.2 预注册纳管物理机(无IPMI\&BMC)
3. 导入装机镜像
Debian 12 AMD64 通用物理机QCOW2镜像
Debian 12 自定义包
或是点击社区镜像在线导入
4. 为物理机安装操作系统)
前提条件：物理机PXE已启动 YunionOS For PXE 系统
安装系统到物理机硬盘
配置安装信息
操作说明
1. 将服务放到后台运行
# 所有服务放到后台运行
# 下面命令假设 eth0 网卡上的 ip 地址为 10.168.222.205，具体设置请根据自己的环境设置。
$ LISTEN_INTERFACE=eth0 PUBLIC_IP=10.168.222.205 docker compose up -d
# 服务放到后台后，可以通过 logs 自命令查看输出日志
$ docker compose logs -f2. 登陆 climc 命令行容器
$ docker exec -ti cloudpods-baremetal-climc-1 bash
Welcome to Cloud Shell :-) You may execute climc and other command tools in this shell.
Please exec 'climc' to get started
# source 管理员认证信息
bash-5.1# source /etc/yunion/rcadmin
bash-5.1# climc user-list3. 登录物理机 pxe 内存系统
# 1. 进入 climc 容器
docker exec -ti cloudpods-baremetal-climc-1 bash
# 2. 查看物理机 id
climc host-list
# 3. ssh 到 host 的内存系统
climc host-ssh $对应物理机idclimc host-logininfo $对应物理机id 获取 root 用户的登录密码。4. 查看服务配置和持久化数据
$ tree data
data
├── etc
│ ├── nginx
│ │ └── conf.d
│ │ └── default.conf # 前端 nginx 配置
│ └── yunion
│ ├── *.conf # cloudpods 各个服务配置
│ ├── pki # 证书目录
│ ├── rcadmin # 命令行认证信息
├── opt
│ └── cloud
│ └── workspace
│ └── data
│ └── glance # 镜像服务存储的镜像目录
└── var
└── lib
├── influxdb # influxdb 持久化数据目录
└── mysql # mysql 数据库持久化数据目录5. 删除所有容器
# 删除服务
$ docker compose down升级
更新 compose 配置文件
# 注意切换到对应的 cloudpods-baremetal 目录
cd /opt/cloudpods-baremetal
# 下载配置文件
curl https://raw.githubusercontent.com/yunionio/ocboot/master/compose/baremetal/docker-compose.yml -o docker-compose.yaml
# 重启服务
docker compose up -d重启 compose 服务
cd /opt/cloudpods-baremetal
docker compose down
# 下面命令假设 eth0 网卡上的 ip 地址为 10.168.222.205，具体设置请根据自己的环境设置。
LISTEN_INTERFACE=eth0 PUBLIC_IP=10.168.222.205 docker compose up已成功测试安装系统
关于PXE 网络的交换机配置
运维技术交流群
现在用的移动 500M 单宽带，马上到期了，之前还有公网 ip ，去年底统一取消掉了，想着正好到期换一家，现在看的是联通默认都有公网 ip 可以改桥接，xhs 上看了个套餐 960 包两年千兆宽带，月 200g 流量，想问问老哥们有没有更合适的推荐，这个价格已经是能接受的上限了，流量可以少一点
公路工程资料管理在整个公路建设项目中意义重大，从项目规划、施工到验收，每一个环节都离不开精准、规范的资料记录。筑业公路工程资料软件凭借其卓越特性，成为公路工程领域资料管理的得力工具。
深度贴合规范，模板完备精准
筑业公路工程资料软件紧密贴合公路工程行业的规范与标准。软件内置海量且精准的资料模板，全面覆盖公路工程全流程。从前期的项目可行性研究报告，到施工过程中的路基路面施工记录、桥梁隧道检测报告，再到最后的竣工验收资料，各类模板应有尽有。这些模板依据最新的行业规范动态更新，如《公路工程质量检验评定标准》等。例如，在路面基层施工资料方面，模板严格按照规范要求设定数据格式、填写内容及签字流程，资料员只需根据实际施工情况填写，就能保证资料的规范性与准确性，大大节省资料编制时间，降低因规范理解误差造成的错误率。
智能化功能突出，显著提升效率
该软件搭载多项智能化功能，极大提升公路工程资料管理效率。智能数据采集与填充功能可自动从施工设备监测系统、测量仪器等数据源获取关键数据，并精准填充到对应资料表格，减少人工手动录入工作量，同时降低错误风险。智能审核功能依据公路工程资料逻辑和行业标准，对资料进行全面细致审查。一旦发现数据异常、逻辑矛盾或不符合规范之处，迅速给出提示及修改建议，帮助资料员及时修正，有效提升资料质量。此外，智能检索与分类功能可让用户根据关键词快速定位所需资料，实现资料的高效查询与调用。
协同管理便捷，促进高效协作
公路工程项目涉及多方主体，包括建设单位、施工企业、监理单位、设计单位等。筑业公路工程资料软件提供便捷的协同管理平台，各方人员可在同一平台实时共享、编辑资料。不同单位人员针对特定资料内容进行在线沟通、讨论与批注，确保信息及时准确传递，避免因沟通不畅导致的资料错误或延误。通过精细的权限设置，软件为不同用户分配相应操作权限，保障资料安全性与保密性，使各方在协作过程中既高效又安全。
数据安全可靠，确保资料无忧
公路工程资料包含大量关键信息，数据安全至关重要。筑业公路工程资料软件采用先进加密技术，对云端与本地存储的数据进行加密处理，防止数据被窃取或篡改。同时，具备完善的备份恢复机制，可按设定时间间隔自动备份资料。即使遭遇系统故障、自然灾害等突发状况，也能确保资料完整，并快速恢复到最新状态，为公路工程资料长期稳定存储与随时调用提供可靠保障。
操作界面友好，降低使用门槛
筑业公路工程资料软件操作界面简洁直观，充分考虑公路工程人员操作习惯，易于上手。软件内配备详细操作指南与帮助文档，用户在使用过程中遇到问题可随时查阅获取帮助。此外，设有专业技术支持团队与在线客服，及时响应解答用户咨询，为用户提供全方位技术指导，确保用户使用软件过程顺畅无阻，降低使用难度。
筑业公路工程资料软件凭借贴合规范、智能化程度高、协同管理便捷、数据安全可靠以及操作界面友好等优势，为公路工程资料管理提供全面、高效的解决方案，有力推动公路工程项目规范、有序开展。
别被这个词唬住。Skill 翻译过来是"技能"，但在今天的语境下，它远不止"会修电脑"或者"会做PPT"这么简单。 Skill = 你能稳定输出价值的能力 它包括： 软技能（Soft Skills）：没法直接考证，但能决定你能走多远的底层能力。比如沟通、领导力、抗压、学习能力。 举个栗子 🌰： 说实话，不用 Skill 也行，但你会活得很难。 现在的招聘市场啥情况？一个岗位发出去，几百份简历砸过来。HR 看简历的时间不超过 10 秒。 没有硬核 Skill，你连简历关都过不了。 但 Skill 不只是敲门砖，更是你的护城河： 铁饭碗？不存在的。昨天还火热的岗位，今天可能被 AI 取代。 但 Skill 是可迁移的： Skill 让你不怕变化，因为你有"随时重新上岗"的底气。 别听那些"靠认知赚钱"的鸡汤。认知不落地，就是空谈。 真正能换成钱的，是你能解决具体问题的 Skill： 你的收入天花板，取决于你的 Skill 稀缺性和可替代性。 直接给结论：成年人不做选择，两个都要。但优先级看阶段。 🟢 0-3 年职场新人： 🟡 3-7 年资深员工： 🔴 7 年以上管理层/专家： 重点练战略思维、商业洞察、团队激励 别盲目跟风学，先问自己这 3 个问题： 时间有限 → 选"碎片化学习"友好的 Skill，别选需要大块时间练的（如设计） @产品经理老王："35 岁危机不是年龄危机，是 Skill 危机。你 30 岁用的那套方法论，35 岁还在用，不淘汰你淘汰谁？" @前端小李："去年死磕 React，今年发现公司全转 Vue 了...Skill 更新速度真的恐怖，得保持学习。" @运营阿花："硬技能让我入行，软技能让我带团队。现在招人不只看你会不会，更看你能不能推动事情落地。" @自由职业者 Ken："Skill 是我脱离坐班的底气。会写作+会运营+会点设计，一个人就是一家公司。" 把你自己当成一家公司，Skill 就是你的核心资产。 记住： 别只闷头学，要展示出来（作品集、博客、开源项目） 最后抛个问题给大家：🔥 一文搞懂 Skill：这玩意儿到底是啥？为啥大家都在用？
Skill 不是简单的"会什么"，而是你在这个快速变化的世界里安身立命、升职加薪、甚至弯道超车的核心武器。看完这篇，你会明白为什么大佬们都在聊 Skill，以及怎么用它让自己更值钱。
🤔 先搞清楚：Skill 到底是什么？
💡 为什么现在人人都在谈 Skill？不用不行吗？
1. 职场卷疯了，Skill 是你的护城河
2. 行业变化快，Skill 是你唯一的确定性
3. 赚钱的本质，是 Skill 的变现
⚖️ Skill 的优劣势：别盲目学，先看清利弊
✅ 优势：为什么 Skill 这么香？
优势 说人话 直接变现 学了就能用，用了就能赚钱，路径清晰 可积累 像滚雪球，越老越吃香（前提是选对方向） 确定性高 不像运气、人脉那么虚，Skill 是实打实的 跨行业通用 数据分析、项目管理这类 Skill，换行照样用 抗风险 经济不好时，有 Skill 的人最后才被裁 ❌ 劣势：学 Skill 也有坑，别踩！
劣势 说人话 过时风险 有些 Skill 火两年就凉（比如某些过时的技术栈） 学习痛苦 真的累，尤其是工作后再学新东西，时间精力都是成本 过度专精陷阱 只会一样，容易被锁死在某个岗位，转型困难 忽视软技能 技术强但情商低，升不上去，只能当大头兵 焦虑感 永远感觉"学不完"，容易陷入自我怀疑 
🥊 硬技能 vs 软技能：到底该卷哪个？
📊 对比一览
维度 硬技能 软技能 学习难度 有明确路径，跟着学就行 没标准答案，靠悟性和实践 见效速度 快（3-6 个月能入门） 慢（需要长期沉淀） 天花板 中（专家级后难突破） 高（决定你能不能当老板） 替代性 高（容易被 AI/新人替代） 低（AI 搞不定人情世故） 适合人群 新人、转行者、技术岗 管理者、创业者、资深专家 🎯 不同阶段的策略
🚀 怎么选 Skill？3 个避坑指南
1. 这个 Skill 能帮我解决什么问题？
2. 3 年后这个 Skill 还值钱吗？
3. 我的性格和资源适合学这个吗？
💬 社区热议：关于 Skill 的真实声音
🎁 总结：Skill 是你的个人 IPO
你最近在学习什么 Skill？过程中踩过哪些坑？欢迎在评论区交流，互相避坑 👇
大家好，我们是一个 3 人的小团队，经历数月，终于完整了 Sendflare 的开发
Sendflare 是一个对标 resend 的替代品，定价比 resend 更加合理，同时支持营销邮件和交易电子邮件
后续我们还会支持邮件自动化功能
目前刚刚上线，可能多多少少有一点小问题，希望大家在给我们一点时间
免费用户支持添加 2 个域和每月 3000 封邮件
访问地址: https://sendflare.com
