LiveAgent 的扩展体系：这篇讲什么
LiveAgent 是本地优先的开源 AI Agent 桌面客户端（MIT 协议，GitHub star 约 2000，2026-09 查询为 2018），基础能力是本机文件读写、命令执行与进程监管，项目定位见是什么篇。本文聚焦它的扩展与自动化体系：Tauri 侧原生桥接任意 stdio/http MCP 服务器，Skills 包按渐进式披露按需加载并接入 ClawHub 生态，子代理以 worktree 隔离并行执行再自动合并，持久记忆走 Markdown 加 SQLite FTS，定时任务支持 bash/http/prompt 三种 cron 类型。机制均出自官方 README。
MCP 桥接：stdio 与 http 双协议
官方 README 的表述是「Tauri 侧原生桥接任意 stdio/http MCP 服务器」，关键词有两个：任意、原生。先补一句科普：MCP（Model Context Protocol）是 Anthropic 发起的开放协议，把 AI 可调用的工具标准化成客户端-服务器接口——一个 server 暴露一组工具，客户端接入后模型就能调用（公开事实）。
stdio 与 http 是 MCP 的两类传输：stdio 型 server 在本机以子进程方式拉起，经标准输入输出通信，适合文件系统、Git 这类本地工具；http 型直连远程端点，适合搜索、数据库这类托管服务（传输差异为 MCP 通用常识）。LiveAgent 把桥接做在 Tauri 侧，接入逻辑发生在桌面应用自己的后端进程里，与本地优先的定位一致（README）。
选型判断很简单：工具在哪、数据在哪，就选哪种传输。本地代码库检索用 stdio 型文件系统 server，团队知识库检索用 http 型托管 server。给 Claude Code 配 MCP 的思路在这里同样适用，可对照站内的 MCP 配置实践。
Skills 包体系：渐进式披露与按需加载
Skills 解决的问题是把「某类任务怎么做」封装成可安装、可创建、可打包的包，需要时才加载——README 原话是 progressive disclosure 与 on-demand loading，并接入 ClawHub 生态。
渐进式披露的工程含义：上下文窗口是稀缺资源，把所有技能说明一次性塞进系统提示词，既费 token 又互相干扰。渐进式披露先让模型看到技能目录与摘要，任务命中某类技能时才展开完整说明——装 50 个技能和装 5 个技能，日常对话的上下文开销几乎一样（机制解读基于 README 描述的 progressive disclosure 特性）。
ClawHub 是 Skills 包的生态入口；README 对 LiveAgent 侧能力的描述是三项：安装、创建、打包。安装面向社区生态，创建让你把验证过的流程沉淀成包，打包便于分发与备份。这套思路与本站写过的 AgentDock Skills 体系同源——把能力资产化、可复用、可运营；差异在 AgentDock 带三级发布通道，LiveAgent 接的是 ClawHub 生态。
子代理并行：worktree 隔离加自动合并
README 对子代理的描述是「独立子代理并行执行，worktree 隔离 + 自动合并」。这十几个字背后是多代理系统的头号工程难题：并发写冲突。
为什么必须隔离？让多个 Agent 同时改同一份工作区，轻则文件互相覆盖——A 刚写完的配置被 B 的整文件重写抹掉；重则执行环境互相踩——A 正在跑构建，B 把 node_modules 删了重装。Git 的 worktree 机制（git worktree，Git 原生能力）给每个子代理一份独立检出，各自提交互不可见，从根上消掉写冲突。隔离机制为 README 描述加 Git 公开常识，冲突边界则属工程经验。
自动合并是把各 worktree 的产出合回主工作区。两条实践经验值得记住（工程建议）：并行任务按模块切分，多个子代理改同一个文件等于自造冲突；合并后跑一遍构建与测试——自动合并不等于自动正确。
持久记忆：Markdown 加 SQLite FTS
跨会话记忆的载体是 Markdown 文件加 SQLite FTS 全文索引（README），一个管人读，一个管机查。
这个组合的工程合理性：Markdown 是纯文本，可以直接打开读改、进 git 版本管理、随工作区备份，记忆不锁在黑盒里；SQLite FTS 走关键词路线的全文检索，命中靠词项匹配，无需额外的 embedding 模型与向量库——本地 Agent 不用为记忆多养一个模型服务（FTS 与向量检索的差异属通用工程常识）。代价是语义泛化弱于向量检索，换个说法可能搜不到；写记忆时保留关键词丰富的原始表述，是实用的缓解技巧（工程经验）。
定时任务：bash、http、prompt 三种 cron 类型
定时任务让 Agent 在你没开对话时也能干活，README 定义了三种类型，覆盖脚本、接口、模型三档场景。
| 类型 | 执行的内容 | 适用场景（示例） |
|---|---|---|
| bash | 执行 shell 命令 | 清理构建产物、备份目录、跑巡检脚本 |
| http | 发起 HTTP 请求 | 调用健康检查接口、触发 Webhook |
| prompt | 向模型发送提示词 | 每日生成工作摘要、定时整理记忆 |
三种类型可以叠出值守体系：bash 负责「做」，http 负责「通知与触发」，prompt 负责「想」。每天早上让模型读昨日构建日志生成摘要，就是 prompt 型 cron 的典型用法（场景为示例）。
典型组合场景
把前面几块能力拼起来，才是 LiveAgent 区别于聊天客户端的地方。以下均为示例场景，说明能力组合方式，非实测数据。
并行重构：主对话把「三个模块各自升级依赖」拆成三个子任务，三个子代理在各自 worktree 里并行执行，完成后自动合并回主工作区——人只在合并后跑测试确认。
每日巡检：bash 型 cron 每天清晨跑一遍构建与测试脚本，prompt 型 cron 接着把失败项整理成日报写进记忆。第二天打开 LiveAgent，先读记忆里的巡检结论再开工。
远程下单：Gateway 部署好后（见安装与 Gateway 篇），用手机浏览器连回家里的机器，下一条「把昨天的实验数据整理成表格」，到家时结果已经在本地目录里。
MCP 与 Skills 的分工：外部工具对能力封装
两者解决的是不同问题：MCP 管「AI 能连上什么」，Skills 管「AI 会不会做某类事」。判断该补哪块，看缺口在哪一端。
| 维度 | MCP | Skills |
|---|---|---|
| 本质 | 工具接入协议 | 能力封装包 |
| 解决的缺口 | AI 连不上外部系统 | AI 不会做某类事 |
| 加载方式 | server 常驻，工具列表常在 | 渐进式披露，按需加载（README） |
| 接入来源 | 任意 stdio / http 服务器（README） | 安装 / 创建 / 打包 + ClawHub（README） |
| 典型例子 | 数据库查询、搜索引擎、浏览器控制 | 部署流程、代码规范、巡检套路 |
两者是配合关系：先接上 MCP 打通数据通路，再把重复流程固化成 Skill。只有外部工具没有 Skills，每次都要重新口述流程；只有 Skills 没有 MCP，流程里缺数据支撑——扩展体系两头一起补才完整。
常见问题
LiveAgent 支持哪些 MCP 服务器？
官方 README 的表述是任意 stdio/http MCP 服务器：stdio 型在本机拉起子进程，http 型直连远程端点，桥接由 Tauri 侧原生完成。主流 MCP server 基本都落在这两类传输里，接入前确认传输方式即可。
Skills 和把经验写进系统提示词有什么区别？
Skills 是按需加载的能力包：渐进式披露让细节只在任务命中时进入上下文，多个技能互不挤占日常对话的 token。全写进系统提示词则常驻上下文，技能一多既费 token 又互相干扰，还没有安装、创建、打包这套管理能力。
子代理并行会弄乱我的代码吗？
不会互相覆盖：子代理在独立 worktree 里执行并自动合并（README）。但自动合并遇到真实编辑冲突仍需人介入，工程上建议并行任务按模块切分，合并后跑一遍构建与测试再收工。