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

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

为什么先拆这一个

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

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

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

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

技能档案

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

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

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

Agent 与 Workflow：谁管什么

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

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

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

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

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

全链路：入库与查询

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

效果的四层阶梯

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

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

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

五个层级总览

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

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

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

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

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

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

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

先澄清一个常见误解

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

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

三阶段部署路径

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

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

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

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

一句话定位

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

三条判断标准

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

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

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

场景对照表

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

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

Agent 评测领域最容易造成误解的，不是某个指标怎么算，而是同一个词在不同框架里常常指向不同层级。

有人把一次模型调用叫 Run，有人把整个工作流叫 Run；有人说 Replay，实际只是重新发送 prompt；有人把 Trace 当日志，也有人把它当成一棵有父子关系、可以定位耗时与错误的执行树。术语没有先对齐，评测报告里的“成功率 95%”“支持恢复”“全链路可追踪”就很难验证。

这篇文章不按字母顺序背词典，而是沿着一条完整链路解释这些概念：Agent 怎样运行，怎样留下证据，怎样用数据集和评估器打分，又怎样把失败样本变成回归测试。

先看全局：一次运行如何变成一次评测

Dataset 中的一条 Case
        │ 输入 + 可选 Ground Truth
        ▼
Workflow 启动一个 Run
        │
        ├── Span：模型调用
        ├── Span：Tool Call
        ├── Span：Guardrail 检查
        ├── Checkpoint：保存 State
        └── HITL：暂停并等待人工决定
        │
        ▼
Trace：串起本次执行的完整证据
        │
        ├── Evaluator 打分
        ├── Offline Eval 批量比较
        ├── Online Eval 生产监控
        └── Replay / Regression Eval 复现与防回退

这里可以先记住三句话：

这是 Agent 框架评测实验室系列第五篇，也是阶段开发记录。

起点：先让不同框架完成同一任务

Lab 最早解决的是兼容性：统一 stdin/stdout 的请求与结果契约，让不同 Python/Node 框架可以在各自隔离环境运行。这个阶段最直观的产物是 matrix 和报告，但也很快暴露问题：

• 每个 adapter 对 usage 的理解不同；
• 有的框架隐藏模型重试；
• MCP SDK 与 CLI 协议不同；
• 同名模型可能被 gateway 路由到不同后端；
• prompt、工具包装稍有不同，分数就不可比。

因此第一条经验是：先统一证据格式，再谈统一排行榜。

V2.0—V2.1：运行时从附属代码变成核心边界

普通 runner 只关心子进程退出码。企业 Agent 还需要 job、attempt、lease、事件 revision、预算 reservation、checkpoint 和 immutable artifact。

runtime-v1 采用 SQLite WAL 和 append-only event/reducer：

command -> validate current snapshot -> append events
        -> reduce new snapshot -> transactionally persist both

这个阶段没有急着做远程服务，而是坚持单机、一次命令、可验证状态。事实证明这是正确取舍：并发和网络还没加入时，就已经发现事件序列、预算结算和终态工件之间有大量边界条件。

V2.2：恢复不是“再跑一次”

接下来加入 host crash、SQLite reopen、orphan attempt 回收和 checkpoint resume。LangGraph composed 与 OpenAI Agents native 都通过了“researcher 已完成后恢复，只继续 analyst/reviewer”的测试。

“LangGraph、OpenAI Agents、PydanticAI、Google ADK，到底哪个更强？”

这句话听起来像一个排行榜问题，实际上至少藏着六个不同问题：谁更容易写出第一个 demo，谁在同一模型下更省 token，谁能安全暂停审批，谁能在进程崩溃后恢复，谁的原生抽象更适合复杂工作流，谁的运行证据足以通过企业审计。

如果不先限定业务场景和风险边界，“最强框架”没有可验证的含义。

我在开发 Agent Framework Lab 的过程中，逐步把框架测验从“同一个 prompt 跑一遍”改造成一条证据链：冻结任务、提示词、工具、模型和价格；交错重复执行；注入审批、取消、工具故障、worker 崩溃和进程重启；保存不可变原始结果；最后才按自定义权重生成比较结果。

这个系列整理 Lab 的核心理念、方法、代码、失败经验和阶段记录。它既是项目复盘，也是未来开发其他 Agent 测验项目时可以复用的设计手册。

系列文章

1. 别急着问哪个 Agent 框架最好：先把比较问题定义对
2. 把企业需求写成可执行的 Agent 评测契约
3. 不注入故障，就测不出 Agent 框架的生产能力
4. 从原始运行到排行榜：硬门、权重与统计陷阱
5. Agent Framework Lab 开发实录：从比较 demo 到企业就绪 Alpha

此前发布的《Agent 框架开发与评测踩坑实录》是本系列的代码型伴读，集中记录事件账本、审批绑定、幂等键、价格表和 ground truth 等十二类工程坑。

一张图理解 Lab

场景 / Prompt / 工具 / 模型 / 价格 / 限额
                  │ 冻结并版本化
                  ▼
        Framework Adapter Matrix
       ┌──────────┴──────────┐
       │ 公平公共赛道        │ 原生上限赛道
       │ 同输入、同工具      │ 原生图、handoff、checkpoint
       └──────────┬──────────┘
                  ▼
       正常运行 + 固定故障注入
                  ▼
      Raw Result / Events / Artifacts
                  ▼
       硬性 No-Go → 加权能力画像
                  ▼
        Go / Conditional-Go / No-Go

这套方法最重要的变化，是不再把框架看成一个只负责“调用模型”的 SDK。企业应用真正关心的是一整组能力：任务质量、安全治理、故障恢复、审计、成本、延迟、可运维性、开发体验和迁移成本。

这是 Agent 框架评测实验室系列第三篇。

一个 Agent 在 demo 中完成任务，最能说明的是：这次模型、网络和工具刚好都没有出大问题。企业系统真正区分框架能力的地方，往往发生在错误之后。

七类最低故障矩阵

生产变更 Alpha 固定测试七类场景：

这些测试不能只检查“最后还是成功了”。还要检查事件顺序、预算余额、checkpoint 哈希、工具调用次数和幂等收据。

审批不是一个布尔值

如果审批只保存 approved=true，就无法确认批准的是哪次操作。安全审批至少绑定：

class ApprovalDecision(BaseModel):
    approval_id: UUID
    job_id: UUID
    attempt_id: UUID
    operation_id: UUID
    action: str
    arguments_sha256: str
    decision: Literal["approved", "rejected"]
    approver_id: str
    revision: int

恢复时重新计算参数摘要。job、operation、action、参数或 revision 任一不一致，都不能复用原批准。测试不仅要覆盖正确批准，还要专门提交“看起来很像”的错误批准。