整理自 2026-09-20 至 09-21 的讨论。主题：这些概念之间是什么关系、能力与边界在哪、什么时候该搭什么、以及开发 Agent 的三条技术路径。
0. 一句话结论
这些概念不在同一个层级上，它们构成一条自下而上的依赖链：
模型层（LLM）→ 平台与能力层（Dify、Skill）→ 编排层（Agent）→ 交付层（WorkBuddy、Dify 的 Agent、WorkBuddy 专家）
判断"要不要动手做点什么"时，只需问一句：我缺的是"内容"，还是"容器"？ 十次里有九次，缺的是内容。
1. 四个层级：谁依赖谁
| 层级 | 代表 | 本质 | 类比 |
|---|---|---|---|
| 交付层 | WorkBuddy / Dify 的 Agent / WorkBuddy 专家 | 你直接打交道的东西 | 车 / 司机 |
| 编排层 | Agent / 智能体 | 循环 + 工具 + 记忆 + 目标 | 员工本人 |
| 平台与能力层 | Dify 平台 / Skill | 被上层调用 | 装配工厂 / 一门手艺 |
| 模型层 | LLM 大模型 | 原始生成能力，无状态 | 发动机 |
1.1 LLM 大模型
- 是：智力原料。文字进、文字出，懂语义、会推理、会写代码。
- 不是：一个函数，不是一个员工。没有记忆、没有手脚、不知道上一轮发生了什么。
- 边界：无状态无记忆、不会动手；有幻觉；知识有截止时间。
1.2 Agent（智能体）
- 是：给 LLM 装上"循环 + 工具 + 记忆 + 目标"后的产物。
- 关键认知：Agent 是一种架构模式，不是某个产品。"智能体"就是 Agent 的中文译名——日常语境里两者基本可互换，只是"智能体"往往强调更完整的产品形态（有人设、有记忆、有工具）。
- 边界：能力 = 模型 × 工具；长任务容易跑偏、消耗大，必须留人复核。
1.3 Skill
- 是："一门手艺的打包"——把某类任务的标准流程、脚本、参考知识写成说明书，Agent 需要时加载进上下文。
- 本质：上下文注入。不是插件，也不是工具。
- 边界：自己不主动做事，不被加载就等于不存在；需要持续维护。
1.4 Dify 平台
- 是："装配工厂"。提供不写代码就能把上面这些东西拼起来的画布，以及上线后的运行与运维环境。
- 不提供：智力（那是模型的事）、行业知识（那是你的事）。
- 边界：部署、权限、成本全由你负责。
1.5 交付层的三者
- WorkBuddy：造好并上好牌的车——通用桌面智能体，开箱即用。
- Dify 的 Agent：你在工厂里自己攒出来的车。
- WorkBuddy 专家：这辆车上的一位专业司机（自带某个行业的经验和工具箱）。
专家 vs Skill 的关系：专家 ≈ 一个角色（人设 + 领域知识 + 一组 Skill + 工具权限）；Skill 是这个角色会的一门具体手艺。
2. 能力与边界全景表
| 东西 | 它是什么 | 能力上限 | 边界（做不到 / 风险） |
|---|---|---|---|
| LLM 大模型 | 生成引擎 | 理解、推理、归纳、写代码 | 无状态无记忆、不会动手；有幻觉；知识有截止 |
| Agent / 智能体 | 架构模式 | 自主拆目标、循环调工具直到完成 | 能力 = 模型 × 工具；长任务易跑偏、烧 token，需人复核 |
| Skill | 能力封装 | 把专业流程与知识随身携带、按需加载 | 自己不主动做事；不加载即无效；需持续维护 |
| Dify 平台 | 组装与运行平台 | 不写代码搭出 RAG / 工作流 / Agent 并发布 | 不含行业知识；部署、权限、成本全由你负责 |
| Dify 的 Agent | 平台内产出的智能体 | 按你的编排稳定执行，可集成成 API | 受节点与已接工具限制；上限 = 你组装的水平 |
| WorkBuddy | 成品通用智能体 | 读写本地文件、上网、跑代码、定时任务、长期记忆 | 通用取向，垂直深度靠专家 / Skill 补 |
| WorkBuddy 专家 | 领域角色包 | 开箱即用的行业打法和知识 | 领域之外会回退通用能力，覆盖面窄 |
一句话选型准则
- 要它"会说" → LLM
- 要它"会做" → Agent
- 要它"做得专业" → Skill / 专家
- 要"自己搭、自己控" → Dify
3. 能力由什么决定：五格对照
把"能力"拆成五格，看各形态点亮了哪几格。空着的那一列，就是它遇到问题时的墙。
| 形态 | 模型基础能力 | 自主编排循环 | 工具动手执行 | 领域知识流程 | 开箱即用 |
|---|---|---|---|---|---|
| 裸调 LLM API | 有 | 无 | 无 | 无 | 无 |
| LLM ＋ 自己写代码 | 有 | 有 | 部分 | 无 | 无 |
| Dify 的 Agent | 有 | 有 | 有 | 部分 | 部分 |
| WorkBuddy 通用 | 有 | 有 | 有 | 部分 | 有 |
| WorkBuddy 专家 | 有 | 有 | 有 | 有 | 有 |
三条推论
- 从左到右点亮的格子越多，能力越强。
- Dify 给你水管，不给你水——第四格（领域知识）默认是空的，得自己灌 prompt、灌知识库。
- 真正决定产出质量的通常不是最下面那层的模型，而是第四格。 → 所以"换个更强的模型"往往不如"配一套对的 Skill / 专家"有效。
4. 一次任务里的协作链路
你 → WorkBuddy（拆解与编排）→ Skill / 专家（注入领域流程）→ LLM（推理与生成）→ 工具与服务（文件 / 网络 / 代码）
↑
└──── 循环：观察结果，再决策，直到目标达成 ────┘
关键提示：Dify 里做好的 Agent 发布成 API 后，对上层来说就只是一个普通外部工具，和你自己的本地脚本没有本质区别。两者可以串联，不是二选一。
5. 决策：什么时候搭 Skill / 专家 / Agent
5.1 三个判断轴
- 谁触发——只有人在对话框里驱动，还是机器 / 时间 / 事件也能驱动？这是 Skill、专家 与 Agent 最本质的分界线。
- 复用频次——只干一两次的事，固化它的成本高于收益。
- 判断复杂度——做法唯一、照着做就对，那是 Skill；每次都得看情况取舍、还要求口径一致，那需要专家。
5.2 四步筛子（从上往下过）
| 你的情况 | 该动哪一层 |
|---|---|
| 只做一两次，或这事本来就没有稳定章法 | 什么都不用搭，直接对话 |
| 会反复做，而且步骤明确、每次做法基本一样 | 搭 Skill |
| 会反复做，但每次都得专业判断：看情况选路子 | 搭 专家 |
| 没人盯着也要跑：定时、事件驱动、嵌进自有系统 | 才需要自建 Agent |
注意：高频只是"值得固化"的门槛。Skill 真正的前提是做法固定。高频但每次判断都不同 → 该上专家。
5.3 真正需要自建 Agent 的四个硬条件（满足其一才考虑）
- 要脱离对话界面，被定时任务、事件或程序触发，无人值守地跑；
- 要嵌进你自己的产品或系统，对外提供接口；
- 必须跑在你自己的环境里（内网、自有数据库、合规要求），现成宿主进不去；
- 需要对循环策略、成本、并发、SLA 做极细粒度控制。
不满足这些，自建 Agent 就是纯浪费——你会亲手把循环、重试、工具调用、上下文管理、错误恢复重新实现一遍，而且大概率做得比现成的差。你付出的成本买到的不是能力，只是"掌控感"。
5.4 平台决定了你必须造什么
- 用 WorkBuddy：宿主是现成的 → 你只做 Skill 和专家，几乎永远不用"搭 Agent"。
- 用 Dify：Dify 不提供现成宿主，它的交付单位本身就是 Agent → 你必须连容器一起造。
很多人"觉得必须要搭 Agent"，其实是被 Dify 这类平台的默认形态带偏了。"我要不要搭 Agent" 等价于 "我选的那个平台，把宿主给我了吗"。
5.5 推荐的升级路径（别一步到位）
能对话解决 → 就先对话
→ 发现要反复做 → 固化成 Skill
→ 发现每次都得专业判断、口径要统一 → 升级成 专家
→ 发现必须无人值守或嵌进系统 → 才去自建 / 部署 Agent
6. 开发路径：怎么造 Agent
6.1 名称对齐
| 常见误记 | 实际是 |
|---|---|
| Long Chain / Long Drive | LangChain / LangGraph |
| Hugging Face Agent | smolagents（Hugging Face 的极简 Agent 库） |
| Pi Agent / PaI Agent | Pi（pi.dev，MIT，Mario Zechner 开发，OpenClaw 的底层） |
| Harness | Harness 这一层的概念；具体产品是 DeepSeek Harness（"一切皆插件"，Cordis 微内核，目前 Developer Preview） |
| DeepSeek Aranis | 应为 DeepSeek Harness |
6.2 关键纠正
Pi 和 DeepSeek Harness 是同一层的东西——都是 harness。 所以"在极简 Agent 上扩展"和"在 Harness 上做插件扩展"不是两条路，而是同一条路上的两个位置：内核越小，你要写的越多。
Pi 的官方立场就是 Agent = Model + Harness；DeepSeek Harness 做的是把 harness 本身也拆成插件。
6.3 三条路径对比
| 路径 | 代表 | 你要写 | 代价 |
|---|---|---|---|
| 原生自研循环 | LangChain · LangGraph | 整个 loop、上下文、重试、工具接入、沙箱与观测 | 控制力最强，但工程量与长期维护成本最高 |
| 极简 harness 扩展 | Pi · smolagents | 用扩展、Skill、提示词模板补齐内核之外的能力 | 内核干净、改造成本低，但沙箱与运维要自己补 |
| 成熟 harness 插件 | WorkBuddy · Claude Code · DeepSeek Harness · Dify | 只写 Skill、专家、插件这类内容 | 成本最低、见效最快，但上限受宿主限制 |
6.4 差异化判据
先问：你的差异化到底在哪一层？
| 差异化位置 | 选型 |
|---|---|
| 在循环与工程机制 | 选极简 harness 自己扩展（Pi · smolagents） |
| 在领域知识与流程 | 在成熟 harness 上写内容（Skill · 专家） |
| 在企业集成与合规 | 选工程化的 harness，别自己从零造 |
| 都不在这三层 | 直接用现成的通用智能体对话，不写代码 |
6.5 极简 harness 值不值得用？分目的
| 你的目标 | 建议 |
|---|---|
| 学 Agent / 做原型 / 自用工具 / 把循环本身当产品 | ✅ 极简 harness 最合适，你会真正搞懂每一层在干什么 |
| 尽快把某个领域的活干得更好 | ❌ 反了。去成熟 harness 上写 Skill / 专家，性价比高一个数量级 |
| 对外提供稳定服务 | ❌ 起点偏低。沙箱、权限、多租户、审计、断点恢复都要自己补 |
极简 harness 的优点（以 Pi 为例）：系统提示词压在 1000 token 以内（对比 Claude Code 约 5.5 万），只手握四五个基础工具，上下文窗口几乎全留给真实内容——省钱、干净、好调。
但代价明确：Pi 没有内置沙箱，以完整用户权限运行，隔离要自己做；子代理、MCP、计划模式、权限弹窗全要自己补或装扩展。
一句话：极简 harness 适合"想把循环握在自己手里的人"，不适合"想尽快把活干好的人"。
7. 四个必须拧过来的认知
① 智能体 ≠ 更聪明的模型
它的智能来自"循环 + 工具 + 记忆"这套外壳，模型只是发动机。换更强的模型是提速，装配线才是决定能不能把活干完的东西。
② Skill 不是插件、不是工具
它是写给智能体看的一份"说明书"，本质是上下文注入——所以必须被加载才生效，也因此非常轻量、可以随手写随手改。
③ "跑循环"和"微调"是正交的两件事，别捆在一起
微调改的是模型权重（模型层），跑循环是 harness 层，它们根本不在同一层。对个人开发者来说，99% 的情况不需要微调：prompt + Skill + 工具调用就够了。把这两件事混在一起，会让你误以为"想做个 Agent 得先训模型"，这是最大的弯路。
④ "开发 Agent 的技术路径" ≠ "该不该开发 Agent 的决策"
这两件事必须彻底分开：
- 前者是三条同层路径任你挑（自研循环 / 极简 harness / 成熟 harness 插件）；
- 后者才是那个"十次有九次答案是'不需要'"的问题。
8. 术语表
| 术语 | 含义 |
|---|---|
| LLM 大模型 | 生成引擎，只提供"思考能力"，无状态、不能动手 |
| Agent / 智能体 | 架构模式：LLM + 循环 + 工具 + 记忆 + 目标。同一译名的两种用法 |
| Agent Loop | 系统的"心跳"：请求模型 → 调用工具 → 回传结果 → 继续推理（ReAct 是典型形式） |
| Harness | 模型与现实工作环境之间的执行宿主。负责上下文、工作区、权限、沙箱、状态、日志与恢复 |
| Skill | 可复用的流程与知识封装，本质是上下文注入；不加载即无效 |
| 专家（Expert） | 领域角色包：人设 + 领域知识 + 一组 Skill + 工具权限 |
| Plugin（插件） | 可安装的能力包，通常打包 skills + MCP servers + harness 特有的 hooks / rules / commands |
| Agent Plugins 规范 | 2026 年 8 月发布的厂商中立打包规范，Amazon / Cursor / Microsoft / OpenAI / Vercel 等参与；让同一份插件能跨 harness 安装 |
harness 与 agent loop 的区别：loop 是心跳，harness 是完整的身体系统。判断一套 harness 是否可靠，可以直接问五个问题——任务跑到一半能不能停？程序重启后能不能接着跑？模型看过什么能不能查回来？敏感操作能不能拦住？不同用户之间会不会串数据？
9. 一个值得利用的事实：Skill 正在成为跨 harness 标准
- Pi 的 Skills 明确兼容 Claude Code 和 OpenAI 的 Skill 标准；
- DeepSeek Harness 干脆把"技能"也定义成插件；
- 2026 年 8 月出现了厂商中立的 Agent Plugins 规范（Amazon、Cursor、Microsoft、OpenAI、Vercel 等参与维护）。
含义：你今天写的 Skill，大概率不用重写就能搬到别的 harness 上。这给"先做内容、后选容器"加了一条硬理由。
10. 最终判据
先问自己"我缺的是内容，还是容器"。 十次里有九次，缺的都是内容。
而内容的最小起点，就是写一个 Skill。
注：Pi、DeepSeek Harness、Agent Plugins 规范等均属 2026 年新生态，接口与形态仍可能变化，DeepSeek Harness 目前官方标记为 Developer Preview，落地前建议复核版本状态。
