技术分享 on CAO ZUOHUA

系统崩溃归因：从内核到内存的五层收敛法

Tue, 03 Nov 2026 22:00:00 +0800

系统崩溃归因：从内核到内存的五层收敛法

导语：崩溃分析真正的工作量不在「找到崩溃的那个函数」，而在证明它不是根因。

崩溃报告给出的，几乎总是发现故障的位置，而不是造成故障的位置。

内核是个诚实的证人，但它的证词有偏差：它只在踩到非法内存的那一刻报警。而那块内存可能几毫秒前、也可能十几分钟前就被别人写坏了；那个对象可能早已被回收，指针只是还挂在某个链表上。所以崩溃点天生在下游，根因在上游，两者之间隔着一段时序。

这决定了排查的基本形状：不是去找「谁崩了」，而是沿时间往回退，直到找到一个能被证据钉住、又能被实验证伪的环节。

下面这套分层方法，是我在一次真实的蓝屏排查中逐步磨出来的。它不是检查清单的堆叠，而是一条证据粒度越来越细的收敛链。

五层漏斗：每层只回答一个问题

层与层之间不是并列关系，而是上下游关系。上层的产物是下层的输入，判据是「是否产出一个能被下一层消费的锚点」。没有锚点的层，等于没做。

图 1 · 每层只承担一个问题，且必须交付一个可被下层消费的锚点
越往下越接近机理，也越贵 —— 上层没收敛就别急着往下跳

在进入 L1 之前，还有一件成本最低、收益最高的事。

mem0 最小部署：193MB 跑起来的 Agent 记忆层，瓶颈却不在内存

Wed, 21 Oct 2026 11:00:00 +0800

mem0 最小部署：193MB 跑起来的 Agent 记忆层，瓶颈却不在内存

mem0 是这两年的 Agent 记忆层网红。但当你真的想把它塞进一个个人项目时，第一个问题不是"怎么用"，而是"它到底要吃多少资源"。

Meta Muse 拆解：消费级 Agent 的玩法全解，与上线六周暴露的七个问题

Thu, 01 Oct 2026 08:10:00 +0800

Meta Muse 拆解：消费级 Agent 的玩法全解，与上线六周暴露的七个问题

2026 年 9 月 8 日，Meta 发布 Muse，自称「世界首个为所有人打造的个人 AI Agent」。六周之后，它交出的成绩单是双面的：美国日活约 60 万、专用硬件 Muse Charm 定档 12 月发货；同时它也比任何一个同类产品更快地踩中了地址外泄、零日漏洞、被电商平台封禁、被指抄袭开源框架这一整串问题。

这篇文章不站队，只做一件事：把 Muse 的产品设计、技术架构和商业模式拆开，让你看清一个消费级 Agent 到底是怎么运转的，以及这套设计在哪里漏了风。

一、30 秒结论

它是什么：一个「执行型」而非「对话型」的个人 Agent。用户告诉它要完成什么，它自己去开浏览器、填表单、发邮件、谈价格、下单付款；关掉 App 也继续跑，只在敏感动作前回来找你要授权。
最有价值的设计：Muse Secure VM + Sentinel 双 Agent 架构。每个用户独占一台云端虚拟机，另有一个系统级隔离的守门 Agent，Muse 的任何出网动作都要经它批准。这是目前消费级产品里对「Agent 越权」最认真的一次工程回应。
最有商业含义的动作：支付走 Stripe Link，且是第一个被 Link 购买保护覆盖的 AI Agent——虚拟一次性卡号、丢件/降价/退货有保。Meta 明确说长期变现靠交易抽佣，不是订阅费。
最能说明问题的部分：六周内的七个事故。它们不是孤立的运维失误，而是指向同一个结构性矛盾——给 Agent 的权限越大，可被诱导的路径就越多。
一个关键背景：Muse 的文件体系（SOUL.md、memory、tools）与开源 Agent 框架 OpenClaw 高度同源。理解这一点，才能理解它的安全边界是从哪来的。

二、它到底能替用户做什么

先交代一个容易被忽略的前提：Muse 由 Meta 自研模型 Muse Spark 1.3 驱动（该版本 9 月 2 日发布，官方称其主打真实世界的 agentic 工作）。产品和模型共用「Muse」这一系列名，意味着 Meta 走的是自研模型 + 自研 Agent 的垂直整合路线——这一点与后文要对照的 Manus 恰好相反。

Manus 2.0 拆解：Cascade、云电脑与 Cue——把 Agent 做成「卖电脑的生意」

Thu, 01 Oct 2026 08:00:00 +0800

Manus 2.0 拆解：Cascade、云电脑与 Cue——把 Agent 做成「卖电脑的生意」

2026 年 9 月 28 日，Manus 发布 2.0。此时距它 9 月 1 日正式恢复独立运营，只过了 27 天。

官方开篇第一句就把调子定死了：「Manus 2.0 不是一次版本更新。它是围绕一个根本问题构建的新架构、新产品和新能力：下一代 Manus 应该是什么样的？」

这篇文章要回答的是：这个「全家桶」里，哪些是真变化，哪些只是把已有能力重排了一遍；以及为什么它和同月上线的 Meta Muse，走的几乎是相反的两条路。

一、30 秒结论

最硬的一项：自研 Agent 框架 Cascade。官方数据是 token 消耗降 23.2%、任务耗时降 28.2%、运行成本降 32%——注意官方同时声明这是单项测试配置的结果，不是全场景平均，这个自我限定比数字本身更值得注意。
最实用的两项：Cloud Computer（可购买的云电脑，让项目在用户合上笔记本后继续跑）与 Automations（把「定时任务」升级为「事件触发」——一封邮件、一条 Slack 消息、一次 Notion 更新都能启动工作流）。
最有想象力的一项：个人 Agent 产品 Cue。每个 Agent 拥有独立的邮箱、电话号码、钱包和自己的电脑，可以在预算内付款、代接电话并留摘要，还能把多个 Agent 拉进同一个群聊协作。
最好记的一句定位：创始人肖弘说「我一直觉得 Manus 挺像是一个卖电脑的生意」——工作之外也得能看视频、打游戏。这句话解释了 2.0 为什么要把视频、游戏、远程控制全塞进来。
和 Meta Muse 的分野：Muse 追求「尽可能多的人」，用 WhatsApp 触达二十亿用户；Manus 追求「尽可能深的活」，把 Agent 做成一个可购买、可常驻、可协作的工作空间。

二、Cascade：这一版的重点，是「省」

Agent 框架这个层面，用户的感知最弱，但它决定了产品的成本结构和上限。

DeepSeek 开源昇腾版 TileLang：一份写给非底层读者的阅读指南

Wed, 30 Sep 2026 22:00:00 +0800

DeepSeek 开源昇腾版 TileLang：一份写给非底层读者的阅读指南

2026 年 9 月 30 日，DeepSeek 官宣开源一批面向华为昇腾算力平台的基础设施组件：TileLang 高级语言编译器、计算库、分布式通信库，共六个组件，与它此前面向英伟达平台开源的那一套「一一对应」。

这条新闻在国内被反复转述为「对标 CUDA」。这个说法方向对、程度夸。本文想做的事只有一件：让没写过 CUDA、也没碰过昇腾的读者，读完之后能自己判断这类新闻里哪句是事实、哪句是厂商自评、哪句是媒体加的戏。

一、30 秒结论

先把答案给出来，后面全是展开。

发生了什么：DeepSeek 把自己训练和推理真正在用的那套底层软件，从英伟达平台搬到了华为昇腾平台上，并且开源了。核心是编程语言层（TileLang），外围是六个可直接调用的库。
为什么重要：英伟达真正难被替代的不是芯片，是芯片外面那层软件。别人能做出一块算力接近的卡，但做不出「让四百万开发者不用重新学习就能把模型跑起来」的那层东西。这次是模型厂商第一次把自己吃饭的家伙下沉到国产芯片上，性质比「适配一下模型」重得多。
哪句要打折：所有性能数字都是厂商自评，没有第三方基准；跑出那些数字用的还是非公开的 PoC 固件；官方没有说 V4 已经在昇腾上完成了全量训练。
一句话定位：这不是「国产 CUDA 建成了」，而是「国产芯片的软件生态，第一次有了一个由顶级模型团队亲手填上的、可用的关键零件」。

二、补三个概念：写给不写底层代码的人

要读懂这条新闻，只需要三个概念。它们都有日常类比。

2.1 算子（kernel）：AI 芯片的「招式」

大模型跑起来，本质上是无数次的矩阵乘法、加法、数据搬运。每完成一个不能再拆的基本运算单元，就叫一个算子（英文 kernel，直译「内核」，但在中文语境里叫算子更准确）。

类比：如果 AI 芯片是一台厨房设备，算子就是一套固定的刀工——切片、切丝、剁馅。市面上有现成的刀工（框架自带的算子），但顶级厨师遇到特殊食材时，必须自己设计一套新刀法。这套新刀法就是「自定义算子」。

关键点：算子的效率决定了芯片效率。 同一块芯片，算子写得好能跑到理论性能的 99%，写得差可能只有 30%。芯片参数的差距，经常被算子水平的差距盖过去。

2.2 编译器 / DSL：从「人话」到「机器指令」的翻译官

直接对着芯片写指令，等于让人用汇编语言写 App——不是不行，是太慢太痛苦。于是有了编译器：你用一门更接近人话的语言描述「我要做什么」，它负责翻译成芯片能执行的指令，并顺手做优化。

这门「更接近人话的语言」如果只为某个领域服务，就叫 DSL（领域专用语言）。TileLang 就是这类东西，而且是 Python 风格的——这一点很重要，因为后面所有性能优势都来自「写起来像 Python，跑起来像手写汇编」。

2.3 CUDA：英伟达真正的护城河

CUDA 是英伟达的编程语言 + 整套工具链。它之所以是护城河，不是因为语言本身多优美，而是因为：

十几年积累的库、调试器、性能分析器、文档；
几乎所有 AI 框架都优先支持它；
据《纽约时报》估计，全球约 400 万开发者 已经会用它。

换一块卡容易，换掉这 400 万人脑子里的东西很难。这就是为什么「国产芯片」的瓶颈常常不在算力，而在软件。

Agent 技能解剖（四）：Proactive Agent——主动性的代价与上下文存活

Mon, 28 Sep 2026 21:30:00 +0800

Agent 技能解剖（四）：Proactive Agent——主动性的代价与上下文存活

前三篇都在处理「记忆」：怎么存、怎么约束、怎么改进。这一篇换一个层面——记忆的载体本身会消失。 上下文压缩一发生，没落盘的一切就没了。而在这个前提下，讨论「主动」才有意义。

这篇的位置

Proactive Agent 是本系列里定位最特殊的一个：它不提供存储，而是提供一整套协作行为规范。它的自我描述是「把 AI Agent 从任务执行者变成主动伙伴」，实际内容可以归到两个问题：

怎么让主动行为不打扰人？（主动性必须有上限，否则就是骚扰）
怎么让 Agent 活过上下文压缩？（这是主动性的前提——一个连昨天做过什么都想不起来的 Agent，无法主动）

第二个问题是硬约束，第一个问题是软约束。技能的绝大部分篇幅给了第二个。

技能档案

项	值
技能名	Proactive Agent
slug	`proactive-agent`
作者	halthelobster
版本	3.1.0
下载量	273,764
安装量	28,937
星标	913
来源	ClawHub
组成	SKILL.md（v3，含 v2.3 备份与 v3 草案）+ 7 个工作区模板 + 2 份参考 + 1 个安全审计脚本

数据抓取于 2026-09-28。作者署名是一个 AI Agent 本身（Hal 9001），技能里没有理论引用，全部是「这样试过、那样会坏」的经验条目——这决定了它的读法：当成事故报告合集来读，比当成架构文档读收获大。

上下文存活的三个协议

这是全篇最硬的部分，按触发时机串起来看：

flowchart TD M["每收到一条消息"] --> S{"扫描 6 类信号 纠错 / 专有名词 / 偏好 决策 / 草稿变更 / 具体数值"} S -- "命中任一" --> WAL["WAL：先写 SESSION-STATE.md 再回复"] S -- "未命中" --> N["正常回复"] N --> C{"上下文用量"} M --> C C -- "＜60%" --> NB["正常处理"] C -- "≥60%" --> BUF["Working Buffer 激活 之后每条消息双向落盘 （人说的话 + 自己回复的摘要）"] BUF --> CK{"发生压缩？"} CK -- "是" --> REC["Compaction Recovery 1 读 buffer → 2 读 SESSION-STATE → 3 读今昨日记 → 4 不行再全量搜"] REC --> OUT["『从缓冲区恢复完成，上一件事是 X，继续？』 禁止问『我们刚才在聊什么』"]

协议一：WAL（Write-Ahead Log）

触发条件是用户的输入，不是模型的自省。 这是整个设计里最关键的一处选择。技能列出了需要扫描的六类信号：

Agent 技能解剖（三）：Self-Improving Agent——从纠错日志到规则晋升

Mon, 28 Sep 2026 21:20:00 +0800

Agent 技能解剖（三）：Self-Improving Agent——从纠错日志到规则晋升

前两篇解决的是一致性问题：怎么把记忆存成数据、怎么用 schema 约束它。但记忆本身不改变行为。你知道一件事，不等于你会因此改变做法。 这一篇讲的是把「知道」变成「改掉」的机制。

一个被普遍误读的词

「自我改进的 Agent」这个说法容易让人想到权重更新、在线微调、参数层面的学习。而本系列讨论的这类技能，做的完全是另一件事：

它把「学习」实现为一个文档编辑流程。

模型的行为由 prompt 决定，那么「改变行为」的最短路径就不是训练，而是改 prompt。于是「自我改进」被拆解成一条可执行的流水线：把纠正与错误写成结构化日志 → 反复出现的模式被识别出来 → 蒸馏成一句规则 → 写进项目的常驻 prompt 文件。

这个技能就是这个流水线的一份完整、且经过版本迭代的实现。它是当前装机量最高的技能（86,140），不是偶然——它解决的是所有 Agent 用户都有的痛感。

技能档案

项	值
技能名	self-improvement（包名 `self-improving-agent`）
slug	`self-improving-agent`
作者	pskoett
版本	3.0.24
下载量	1,268,197
安装量	86,140（SkillHub 全站第 1）
星标	4,517
来源	ClawHub
组成	三份日志模板 + 两个 hook 脚本 + 一个 OpenClaw hook + 技能提取脚本

数据抓取于 2026-09-28。版本号走到 3.0.24 说明它经历了长期实际使用与修正。

四层记忆阶梯

先看它把知识放在了哪几层。这是理解全技能的钥匙：

flowchart TD L0["L0 会话上下文 易失，压缩即丢"] -->|"发现问题立刻写"| L1 L1["L1 .learnings/*.md 原始观测，append-only LEARNINGS / ERRORS / FEATURE_REQUESTS"] L1 -->|"复现≥3 次 · 跨≥2 任务 · 30 天内"| L2 L2["L2 项目常驻 prompt CLAUDE.md / AGENTS.md .github/copilot-instructions.md"] L2 -->|"满足可复用性门槛"| L3 L3["L3 SKILL.md 跨项目可复用技能"] L2 -.行为类.-> L4["L4 SOUL.md / TOOLS.md 身份、边界、工具坑"]

四层的分工非常明确，且晋升是单向的：

Agent 技能解剖（二）：Ontology——用 schema 管住模型的不确定性

Mon, 28 Sep 2026 21:10:00 +0800

Agent 技能解剖（二）：Ontology——用 schema 管住模型的不确定性

上一篇讲 Agent Memory，结论是「把记忆做成数据层」。但数据层有一个自带的问题：数据一旦自由生长，就查不动、也信不过。 这一篇讲那个问题的解法：给记忆加一层类型系统与约束校验。

问题的真正形态

用自然语言存储记忆，会遇到三类麻烦，而且它们都不会立刻暴露：

形态漂移。「项目」「Project」「project」是同一个东西；「进行中」「in progress」「active」也是同一个状态。写入时没人觉得有问题，三个月后查询时全都查不全。
关系丢失。「张三负责官网改版」这句话，在纯文本记忆里就是一句话。你没法问「张三还负责什么」，只能全文搜「张三」，然后自己读。
无校验。模型写下「会议结束时间早于开始时间」，存储层照单全收，没有任何环节会拒绝它。

Ontology 这个技能给出的答案是教科书式的：因为语言是不确定的，那就不要再让语言承担一致性保证——把它压缩成「实体 + 类型 + 属性 + 关系」，然后用 schema 去校验。

技能档案

项	值
技能名	ontology
slug	`ontology`
作者	oswalpalash
版本	1.0.4
下载量	286,820
安装量	29,080
星标	787
来源	ClawHub
存储介质	`memory/ontology/graph.jsonl`（追加式）+ `memory/ontology/schema.yaml`
入口	`scripts/ontology.py`（create / get / query / list / update / delete / relate / related / validate / schema-append）

数据抓取于 2026-09-28，口径为 SkillHub 聚合榜。

Agent 技能解剖（一）：Agent Memory——把「记住」做成数据层

Mon, 28 Sep 2026 21:00:00 +0800

Agent 技能解剖（一）：Agent Memory——把「记住」做成数据层

本系列共四篇，逐篇拆解四个当前装机量最高的 Agent 技能，全部基于下载技能包后的源码级阅读，不是对 README 的转述。解读视角固定为 prompt 工程：它把哪一部分不确定性交给了模型，又把哪一部分交给了代码。

为什么先拆这一个

关于「让 Agent 记住」，业内长期存在两种做法：

塞进上下文——把历史对话、文件、笔记尽可能多地带进 prompt；
外置成存储——把记忆写成结构化数据，需要时检索回来。

第一种做法的问题不是「不够长」，而是成本与轮次线性相关：每一轮都要为全部历史重新付费，且上下文越长，模型对中段的注意力越差。第二种做法把问题从「prompt 长度」转换成了「数据工程」，代价是要自己定义 schema、自己做检索、自己处理过期与冲突。

Agent Memory 是第二种路线上装机量最高的技能之一。它值得拆的地方在于：代码只有 680 行，却把一个记忆系统该有的骨架全都摆出来了——三种记忆类型、覆盖率、冲突覆盖、遗忘机制。骨架清晰，正好适合当教学样本；同时它的几处实现与宣称不一致，也正好适合当反面教材。

技能档案

项	值
技能名	Agent Memory
slug	`agent-memory`
作者	dennis-da-menace
版本	1.0.0
下载量	145,610
安装量	25,555
星标	172
来源	ClawHub
代码规模	`src/memory.py` 688 行 + 3 个 CLI + 1 个测试文件
外部依赖	无（`requirements.txt` 仅一行「No external dependencies - just Python stdlib」）

数据抓取于 2026-09-28，口径为 SkillHub 聚合榜。

Dify 深度玩法（五）：Agent、MCP 与一个完整实战

Sat, 26 Sep 2026 20:40:00 +0800

Dify 深度玩法（五）：Agent、MCP 与一个完整实战

上一篇：RAG 深度玩法。本篇是收官：先讲清 Agent 与 Workflow 的分工原则，再讲 MCP 的实际价值，最后把整个系列串成一个跑得通的真实项目——博客勘误官。

Agent 与 Workflow：谁管什么

新版 Dify 的 Agent 带来了 Linux 沙箱与技能（Skills）体系：Agent 可以在隔离环境里执行命令、管理文件、按需安装依赖。能力变强之后，最重要的设计原则反而是克制：

Agent 管判断：任务路径开放的环节——自己决定查什么、跑哪个脚本、怎么补证据；
Workflow 管编排：触发、顺序、分支、审批门、重试、归档——所有需要确定性的环节。

flowchart TD T["定时 / 表单触发"] --> W["Workflow 编排层 触发·顺序·审批门·重试·归档"] W --> A{"需要开放判断？"} A -- "否：路径确定" --> N["普通节点链 LLM·Code·HTTP·知识检索"] A -- "是：现场决定做什么" --> AG["Agent 节点 沙箱内自主执行"] N --> O["出口：API / Web App / MCP / 推送"] AG --> O

反例是"一个 Agent 干全部"：触发它自己定、写操作它自己批、失败它自己咽——这类流程出问题时你连现场都还原不了。自主性是成本，不是默认值。

Dify 深度玩法（四）：RAG 做到什么程度才算到位

Sat, 26 Sep 2026 20:30:00 +0800

Dify 深度玩法（四）：RAG 做到什么程度才算到位

上一篇：节点自定义的五个层级。自托管 Dify 的 RAG 不是"上传文档然后问答"，而是一条每一段都能调参的流水线，且没有云版的容量阉割。

全链路：入库与查询

flowchart LR subgraph IN ["入库侧（一次性）"] A["多源接入 文档·网页·Notion·API"] --> B["分块 通用·父子·问答对"] B --> C["双路索引 向量 + 关键词"] end subgraph Q ["查询侧（每次请求）"] D["查询预处理 改写·分类路由"] --> E["混合检索 向量+全文+元数据过滤"] E --> F["重排 rerank 精排"] F --> G["带引用生成 可拒答·可溯源"] end C -.->|"查询时检索"| E

平台能力是现成的。效果差异来自三个你自己做的决定：分块策略、检索模式、元数据设计。

效果的四层阶梯

层次	做出来的效果	依赖能力
1. 基础问答	回答带引用来源，知识库里没有就明确说不知道	混合检索 + 重排 + 阈值
2. 精准知识库	长文档问答不丢上下文；检索自动限定在某类文档	父子分段 + 元数据过滤
3. 可编程检索流水线	查询改写、分类路由、多库检索、生成前校验全部画进画布	RAG 流水线 / Chatflow
4. 外挂检索引擎	Dify 只当编排层，检索打到你自己写的 API（ES、数据库、自建向量服务）	外部知识库 API

第 2、4 层是自托管的意义所在：云版免费额度装不下，而外部知识库接口意味着可以整体绕开内置向量库。

Dify 深度玩法（三）：节点自定义的五个层级

Sat, 26 Sep 2026 20:20:00 +0800

Dify 深度玩法（三）：节点自定义的五个层级

上一篇：部署选型与模型 Key。进了画布，第一个问题是"这东西到底能改多深"。答案是分层看：参数、逻辑、数据流三层几乎不设限；节点类型可靠插件扩展；硬边界只有两处。

五个层级总览

flowchart TD L1["L1 参数级 每个节点的配置项"] --> L2["L2 逻辑级 Code 与 HTTP 逃生门"] L2 --> L3["L3 数据流级 变量系统 + 容错策略"] L3 --> L4["L4 节点类型级 插件定义新节点"] L4 --> L5["L5 协议级 DSL 手改 + 外部知识库 API"] L1 -.- N1["自由度：低，但覆盖日常"] L2 -.- N2["自由度：高，万能逃生门"] L4 -.- N4["自由度：最高，成本也最高"]

L1 参数级：每个节点都有一层配置

LLM 节点：每个节点独立选模型、独立调参数（温度、最大输出等），提示词模板可引用任意上游变量，支持结构化输出、视觉输入、会话记忆。
知识检索节点：可挂多个知识库，检索模式、返回条数、相似度阈值、重排模型逐项可配。
问题分类器 / 参数提取器：分类类别和抽取字段完全由你定义，抽取方式可选函数调用或提示词驱动。

这一层覆盖了八成日常需求，特点是"改配置不改逻辑"。

L2 逻辑级：两个万能逃生门

Code 节点（Python 3.10+ 或 Node.js 18+）负责任意数据变换。一个真实可用的例子——对抓取结果做归一化去重：

Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单

Sat, 26 Sep 2026 20:10:00 +0800

Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单

上一篇：Dify 适合做什么。本篇回答第二个实际决策：在哪跑、接什么模型。

先澄清一个常见误解

很多人以为云版免费额度限制的是"调用量"。真实情况是：自带 API Key 的调用不消耗 Dify 的 message credits（credits 只在使用 Dify 内置供应商时消耗）。云版免费版（Sandbox）真正的瓶颈是：

维度	云版 Sandbox（免费）	自托管 Community
应用数	5 个	不限
知识库	50 篇文档 / 50 MB	取决于你的磁盘
本地模型（llama.cpp / Ollama）	访问不到你的 localhost	容器内直连
费用	0（够用要升级到约 59 美元/月）	0（电费与磁盘）
维护	无	升级需读 release note、改环境配置后重启

结论很直接：多项目 + RAG 的组合，云版免费版装不下。应用数和知识库容量这两个上限，恰好卡在个人开发者的典型需求上。

三阶段部署路径

不建议二选一，建议分三步走：

flowchart TD A["第 1 步：云版免费账号 用 0 到 2 天"] --> B["第 2 步：本机 Docker 自托管 正式开发"] B --> C["第 3 步：迁移到 VPS 需要对外服务时"] A -.- A1["目的：熟悉节点与画布 不绑自己的 Key，不建知识库"] B -.- B1["目的：无配额限制 直连本机 llama.cpp 或 Ollama"] C -.- C1["目的：Web App 与 API 常在线 本地模型改走云端 API"]

第 1 步不要投入任何东西——云版只用来确认"画布的工作方式你是否接受"。第 2 步才是正式开发环境。第 3 步等真的要给别人用时再做，因为自托管应用可以导出 DSL 迁移，前期投入不会浪费。

Dify 深度玩法（一）：它适合做什么，不适合做什么

Sat, 26 Sep 2026 20:00:00 +0800

Dify 深度玩法（一）：它适合做什么，不适合做什么

本系列共五篇，基于 2026 年的 Dify（含新版 Agent 与 MCP 能力）整理自实际调研与项目设计。这一篇先回答最容易被跳过的问题：什么项目该用 Dify，什么项目用了反而更慢。

一句话定位

Dify 是一个 LLMOps 平台：把「可视化编排 + 知识库 RAG + Agent + 一键发布（Web App / API / 嵌入组件）」装进同一个画布。它与 LangChain 这类代码框架的本质区别是——Dify 是产品，LangChain 是框架。框架给你最大自由，产品给你最快速度，代价是边界由平台划定。

三条判断标准

一个项目"适合 Dify"，通常同时满足三条：

逻辑主体是 IO + 数据整形 + LLM 判断。抓数据、清洗、让模型打分或判定、输出文本——这条链路是 Dify 节点的母语。
需要快速拿到可调用的出口。你需要在几小时内拥有一个能点开的 Web App、一个 REST API、一个可嵌入的聊天组件，而不是先写两周前后端。
改提示词的频率远高于改代码的频率。Dify 上改一个 LLM 节点的 prompt 是秒级的，不需要重新发版。如果你的项目半年才改一次提示词，这个优势归零。

反过来，满足不了这三条的，用 Dify 通常更慢。下面这张决策图可以直接对着用：

flowchart TD A["接到一个 LLM 项目需求"] --> B{"逻辑主体是 IO + 数据整形 + LLM 判断？"} B -- "不是：重计算/事务/低延迟" --> C["直接写代码 不要用 Dify"] B -- "是" --> D{"需要 3 天内拿到 可给别人用的界面或 API？"} D -- "不需要，纯后台数据管道" --> E["脚本也可以胜任 Dify 是可选项"] D -- "需要" --> F{"会频繁调提示词 和检索策略吗？"} F -- "不会" --> G["写代码 + 配置文件 更可控"] F -- "会" --> H["用 Dify 原型到生产都在画布上迭代"]

场景对照表

场景	用 Dify	原因
多源抓取 → 清洗 → LLM 打分 → 输出日报	✅	典型的 IO + LLM 链路，改数据源不动代码
文档知识库问答（RAG）	✅	分块、检索、重排、引用都是现成节点
一次性深度调研报告生成	✅	多 Agent 分工 + 引用校验节点
需要快速给客户演示的垂直领域助手	✅	Web App 与 API 一键发布
高频低延迟 API（P95 要求数百毫秒内）	❌	每个节点都有额外开销与队列
视频渲染、大规模数值计算	❌	沙箱 30 秒超时 + 内存上限，干不了重活
复杂有状态业务流程（事务、回滚、幂等）	❌	声明式分支表达不了状态机
逻辑需要严格 code review 与版本控制	⚠️	工作流导出为 YAML，diff 可读性差

关于"拖拉拽"的真实配比

一个常见误解是"用 Dify = 纯拖拽"。实际项目里有效的配比是约八成拖拽、两成 Code 节点：

Agent 开发实践：基于 simple-agent 的循环构建与工具调用

Thu, 17 Sep 2026 00:00:00 +0000

在 AI Agent 的开发中，一个健壮的 Loop 循环（Agent Loop）是其处理复杂任务的核心。simple-agent 作为一款轻量级框架，通过其简洁的接口将 LLM、工具（Tools）和状态（Context）有机结合。

本文将调研 simple-agent 的核心接口，构建一套完备的 Agent Loop 示例，并解析其背后的设计逻辑。

核心接口分析

simple-agent 的设计哲学是“去重型化”，其核心接口围绕着 Agent 类展开：

Agent() 初始化：支持自定义 LLM 配置（通过 LiteLLM 支持 100+ 模型）、System Prompt 以及工具目录。
run(task)：单轮任务执行，适合一次性的问答或任务。
chat(message)：多轮会话管理，自动维护 Context 状态，这是实现“Agent 记忆”的关键。
Skills System：支持 Tier 1（元数据）到 Tier 2（指令）的渐进式加载，有效减少 token 消耗。

完备的 Agent Loop 示例

以下代码展示了一个具备工具调用与上下文感知的 Agent 运行逻辑：

from simple_agent import SimpleAgent

# 1. 初始化：设置模型与行为约束
agent = SimpleAgent(
 model="openrouter/anthropic/claude-3.5-sonnet",
 system_prompt="你是一个能够执行网络诊断的专业 AI 助理。",
 enable_skills=True
)

# 2. 模拟真实 Agent Loop
def run_agent_loop(task: str):
 print(f"--- 任务开始: {task} ---")
 
 # 获取初始结果
 response = agent.run(task)
 
 # 3. 循环判断与迭代（模拟生产逻辑）
 iterations = 0
 while not response['success'] and iterations < 5:
 print(f"迭代 {iterations}: 尝试自我修正...")
 response = agent.chat("请根据之前的错误重新规划你的工具调用。")
 iterations += 1
 
 return response['result']

# 执行
result = run_agent_loop("检查 google.com 的连接性，并根据结果提供建议")
print(f"最终结果: {result}")

关键技术解读

1. 状态维持与“内存”

LLM 本身是无状态的，Agent 的“记忆”完全依赖于 SimpleAgent 类内部的对话历史管理。在 chat() 接口调用时，框架会自动把最新的交互追加到历史列表中，并重新作为整个上下文发送给 LLM。这种实现方式确保了 Agent 的一致性。

一份基座，N 套人格：LoRA 热插拔的原理、接口与真实成本

Mon, 14 Sep 2026 10:40:00 +0800

一份基座，N 套人格：LoRA 热插拔的原理、接口与真实成本

如果你曾经为"想要三个不同风格/不同领域的模型"而准备下载三份模型文件，那这篇文章能帮你省下大量磁盘、显存和等待时间。

核心结论先给出：一份基座模型 + 若干个几十 MB 的 LoRA 适配器，可以在运行时自由切换甚至叠加，不重启、不重新导出、不复制大文件。 在生产环境里，这套做法已经有人把每月的 GPU 成本从约 2.4 万美元降到约 1200 美元。

一、LoRA 是什么：给大模型贴一张"专用贴纸"

微调（Fine-tuning）传统上指：拿一份预训练模型，用你自己的数据继续训练，得到一份完整的新模型文件。问题很明显——一个 8B 模型就是 16 GB，你想要三个风格，就要存三份 48 GB，跑起来还要三份显存。

LoRA（Low-Rank Adaptation，低秩适配）的做法完全不同。它发现了一个经验规律：模型从"通用"变成"某个专用领域"，权重需要改变的部分其实很少。于是它不动原来的权重，而是额外学两个很小的矩阵。

用数学写出来非常简单：

原始输出： y = x · W
加上 LoRA： y = x · W + scale · x · A · B

其中 W 是原来那个巨大的权重矩阵（冻结、不动），而 A 和 B 是两个"瘦长"的小矩阵。它们的尺寸是刻意设计成很窄的——中间那个很窄的维度就是 rank（秩），通常取 16 到 64。

它为什么能这么小？举个例子：一个 8B 模型在 rank 16 下的可训练参数约 1500 万，而模型本身有 80 亿冻结参数——你只训练了不到 0.2% 的参数，最终产物就是几千万个数字，落到磁盘上大约 40 MB（rank 16）。

让 2B 当侦察兵：投机解码的原理、实测数据与失效边界

Mon, 14 Sep 2026 10:30:00 +0800

让 2B 当侦察兵：投机解码的原理、实测数据与失效边界

上一篇我们提到，2B 小模型最"值钱"的用法之一是给大模型当草稿机。这个技术的正式名字叫投机解码（Speculative Decoding）。它的效果相当戏剧化：有人实测把 27B 模型的生成速度从 25 tok/s 提到 45 tok/s，也有人实测把 60 tok/s 掉到 45 tok/s——用的是同一个技术。

本文面向没有推理优化背景的读者，先讲清"为什么能加速"，再讲清"为什么有时反而变慢"，中间穿插多组真实实测数据。

一、先搞懂一个反直觉的事实：大模型生成慢，不是因为算不过来

这是理解投机解码的唯一前提。

大模型生成文字是一个字一个字往外蹦的（术语叫自回归）。每蹦一个字，都要把整个模型的全部权重从显存里完整读一遍。以 27B 模型 Q4 量化为例，权重约 16 GB——也就是说，每生成一个字，就要搬运 16 GB 数据。

这带来一个关键结论：瓶颈在内存带宽，不在计算能力。显卡的计算单元绝大部分时间在空转等数据。用一张带宽 936 GB/s 的 RTX 3090 举例，理论上限就是 936 ÷ 16 ≈ 58 tok/s，无论这张卡的算力有多强。

所以加速的方向有两条：

减少要搬运的数据量（量化、用小模型）——代价是质量。
让空转的算力干点活——这正是投机解码的思路，且不损失任何质量。

二、核心思路：让便宜的小模型去"猜"，让贵的大模型去"批改"

打个比方。大模型是个写文章很慢但水平很高的资深编辑，小模型是个打字飞快但水平一般的实习生。

传统方式：编辑一个字一个字亲自写，写一个字想一下，慢。
投机解码：实习生先一口气猜出接下来 5 个字，编辑拿过来一次性扫一眼——“前 3 个对，第 4 个不对”。于是前 3 个字直接采纳（几乎白赚），第 4 个字由编辑自己改，第 5 个字扔掉重来。

关键在于：编辑一次性检查 5 个字的成本，和检查 1 个字的成本几乎一样。因为权重的搬运量在一次前向传播里是固定的，检查 5 个 token 只是把这条数据多算几遍而已——而算力本来就是空闲的。

curl 不止是下载工具：AI 与 Agent 开发中的十二类实战场景

Mon, 14 Sep 2026 10:00:00 +0800

curl 不止是下载工具：AI 与 Agent 开发中的十二类实战场景

多数人学 curl 的第一课是"下载文件"，此后便把它归类为 wget 的同类。但在 AI 与 Agent 工程中，curl 的角色完全不同：它是唯一一个在协议层完全透明、零依赖、可在任何环境逐字复现的 HTTP 客户端。当需要回答"这个模型接口到底返回了什么"“延迟究竟卡在哪一段"“Agent 的工具调用为什么静默失败"时，curl 往往比任何 SDK 都更快给出答案——因为它不隐藏任何东西。

本文以 curl 8.22.0（2026-09-02 发布，第 276 个版本，命令行选项累计 278 个）为基线，梳理十二类高频场景。所有命令均可直接粘贴执行，只需替换端点与凭据。

一、LLM 接口调试的四个基本动作

1.1 最小可复现调用

--json（7.82.0 引入）是单次调用最省事的写法，它等价于同时做三件事：把数据作为 --data-binary 发送、设置 Content-Type: application/json、设置 Accept: application/json。

curl -sS https://api.deepseek.com/chat/completions \
 -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
 --json '{
 "model": "deepseek-chat",
 "messages": [{"role": "user", "content": "只回复 OK"}],
 "temperature": 0
 }' \
 -w '\n[%{http_code} | %{time_total}s | %{size_download}B]\n'

三点值得强调：

别把 2B 当小号 GPT-4：llama.cpp + Qwen 2B 的六种实战玩法

Sun, 13 Sep 2026 12:00:00 +0800

别把 2B 当小号 GPT-4：llama.cpp + Qwen 2B 的六种实战玩法

在本地跑一个 2B 级别的模型（Qwen2.5-1.5B、Qwen3-1.7B 这一类），最常见的失望是「它连个像样的回答都给不出来」。于是很容易得出一个结论：小模型没用，还得上 32B 甚至 72B。

这个结论错在前提。2B 的定位从来不是"小号 GPT-4"，而是流水线里一个廉价、快速、输出确定的专用零件。

在一台普通笔记本上，Qwen 2B（Q4_K_M 量化）的生成速度可以轻松跑到 30 tokens/s 以上，显存占用不到 2GB。这意味着它一秒能吞下几十条请求。真正的技术含量不在于它有多聪明，而在于你如何把任务切到它擅长的那一格。

一句话概括本文的判断：不要让小模型去"思考"，要让它去"填空"。

先确认你的跑法

下文所有玩法都建立在 llama-server 上——它提供 OpenAI 兼容接口，任何现成的 SDK 都能直接接。一个够用的启动命令：

./llama-server \
 -m models/Qwen2.5-1.5B-Instruct-Q4_K_M.gguf \
 -c 4096 \
 -np 8 --cont-batching \
 --jinja \
 --host 127.0.0.1 --port 8080

几个参数值得单独说明：

参数	作用
`-c`	上下文长度，小模型不要盲目开大
`-np` `--cont-batching`	并行槽位 + 连续批处理，是批量吞吐的关键
`--jinja`	启用模型自带对话模板，工具调用能力依赖它
`-ctk q8_0 -ctv q8_0`	KV Cache 量化，长上下文时能省一半显存
`--mmproj xxx.gguf`	加载视觉投影层，进入多模态模式

玩法一：语法约束输出器 —— 最高杠杆的一招

llama.cpp 原生支持 GBNF 语法与 JSON Schema 约束解码。这是它相对于 vLLM、Ollama 最显著的差异点，也是让 2B 从"勉强能用"跳到"近乎可靠"的关键。

从自动化到智能化：Playwright 全栈进阶指南

Sun, 13 Sep 2026 00:00:00 +0000

从自动化到智能化：Playwright 全栈进阶指南

Playwright 已经超越了传统的自动化测试框架，成为了 Web 浏览器协议栈的最强控制端。无论是常规的端到端测试，还是赋予 AI Agent 真实世界的“双手”，Playwright 都是必不可少的工具。

以下是 Playwright 从零到 AI 代理的进阶路线图。

1. 环境搭建与架构初探

Playwright 基于 WebKit、Chromium 和 Firefox 的原生 CDP（Chrome DevTools Protocol），相比 Selenium 具有更高的稳定性和并发性能。

初始化：npm init playwright@latest 或 Python 下 pip install playwright
关键配置：理解配置文件中的 projects（多浏览器并行）与 use（全局断言/超时设置）。

2. 定位器与交互艺术

拒绝 XPath，全面拥抱 Web-First Locators。

推荐使用：getByRole, getByLabel, getByPlaceholder, getByTestId。
交互逻辑：click, fill, press 均具备自动等待功能，有效减少了手动 sleep 的“代码异味”。

3. 异步测试与高级等待机制

事件驱动：利用 page.waitForEvent 和 page.waitForResponse 精准监控 Web 交互流。
状态断言：使用 expect 工具链进行原子化断言（如 toBeVisible）。
网络拦截：使用 page.route 进行 API Mock 或异常注入，模拟复杂的后端行为。

4. AI 代理与浏览器控制 (MCP)

这是 Playwright 进阶的巅峰：将浏览器控制权交给 LLM。