DeepSeek Harness插件生态详解：从安装到生产级工作流优化

1. 这套 Harness 是什么场景下的产物

先交代一下背景，免得有人对不上号。我这边的工作流里，DeepSeek Harness 承担的是"AI 应用开发脚手架 + 运行时编排"的角色。它不只是一个 Python 库，而是一套把模型调用、提示词管理、工具调用、可观测性串起来的东西。实际用下来你会发现，它最大的价值不是模型本身，而是它周围那一圈插件生态——Harness 只负责"核心调度"，真正干活的是挂上去的各种插件模块。

这套插件机制的思路很像 VS Code：本体是编辑器，体验全靠扩展撑起来。Harness 的插件系统也走同一套路线，核心部分非常克制，但一旦你把合适的插件装上去，它就从一个"能跑通示例的框架"变成一个"能直接接到生产工作流里的工具集"。

这篇文章不是官方文档的翻译，是我自己从安装到日常使用，从插件选型到配置调优，踩过坑之后沉淀出来的一份清单。目标读者是这么几类人：

• 刚接触 DeepSeek Harness，想知道第一步该装什么插件的人
• 已经在用，但觉得默认行为不太顺手，想优化工作流的人
• 打算研究 Harness 源码或二次开发，想先搞清楚插件机制边界的人

先说一句重要的：插件不是装得越多越好。Harness 的插件系统有一个特点，就是很多扩展会修改运行时行为，装多了会互相影响，排查起来非常头疼。所以这份清单的核心逻辑是"按场景选装"，而不是"全装一遍"。我按使用频率和实用程度把插件分成了四类：核心增强、推理与调试、Agent 编排增强、界面与操作效率。下面逐个展开。

2. 为什么需要插件生态：Harness 本体的设计边界

在列清单之前，有必要先搞清楚一件事：为什么 Harness 非要有插件？理解了这个问题，你才知道哪些插件是"必须的"，哪些其实可以不用装。

2.1 调度内核与业务逻辑的分离

Harness 核心引擎只负责三件事：任务编排、资源调度、状态跟踪。它把一次 AI 任务的执行流程抽象成一个标准管线（pipeline），但这个管线里具体跑什么、用什么模型、怎么做提示词预处理、怎么解析输出结果，Harness 默认是不管的。它留了一堆 hook 点和扩展接口，让插件往里面填。

这个设计和 Git 有点像。Git 本身只管版本记录，合并策略、差异对比、提交信息格式化这些全是外部工具干的活。Harness 同样如此，它的默认配置只能让你"跑通"，但你要的是"跑好"，那就绕不开插件。

2.2 插件系统的加载机制（了解这个对排错至关重要）

Harness 的插件加载遵循严格的分层机制，简单说是配置声明 -> 解析依赖 -> 注册钩子 -> 懒加载实例这个链路。配置声明是从harness.yaml或config.toml里读取插件列表；解析依赖是确认插件之间的依赖顺序，注意，这里不会帮你处理循环依赖，装插件时如果两个插件互相依赖，Harness 会直接报错，不给你任何缓冲机会。

注册钩子阶段，插件会向特定生命周期事件注册回调函数，这些事件包括on_model_init、on_tool_call、on_output_parse等。懒加载是指插件只有在被实际调用时才实例化，不是启动就全部加载——这个设计有好有坏，好处是启动速度快、内存占用低；坏处是某些插件如果初始化逻辑有 bug，它会在运行中途才暴露，而不是启动时报错，这给排查增加了难度。

我实际排查过一个案例：某个工具调用类插件平时不用，只有跑到特定分支才会触发实例化。结果那一分支在初始化插件时依赖了一个不存在的工作目录，直接抛异常。因为懒加载机制，启动时一切正常，跑到中间才崩。所以后面我会特别强调：装新插件后，一定要跑一遍覆盖各个分支的测试用例，别只跑主路径。

2.3 插件市场的分级思路

Harness 官方插件市场里的插件，大致可以分成三个等级：

这份清单我会标注每个插件属于哪个等级。对大部分用户来说，Core 和 Verified 级别的插件就覆盖了绝大多数场景。Community 级别的，除非你确实需要一个特有功能且能找到源码读一遍，否则不建议直接装到生产环境。

3. 核心增强类：这四个插件我建议每个环境都装

这类插件的共同特征是：不改动 Harness 的调度逻辑，只补足基础体验。即使你只需要 Harness 跑最简单的单模型对话，装这几个也不吃亏。

3.1 harness-stdio-bridge

这个插件解决了"标准输入输出"的问题。默认的 Harness CLI 交互模式对管道支持很弱——你echo "hello" | harness run会发现输出格式很难控制，要么刷了整屏日志，要么什么都没有。装了 harness-stdio-bridge 之后，管道输入输出会被规范成统一的 JSON Line 格式，每行一个 JSON 对象，包含message、metadata、status等标准字段。

这个插件是 Core 级的，几乎是 Harness 交互体验的基石。我用它做了不少自动化集成，把 Harness 嵌入到自己的 Python 脚本里，作为本地子进程调用，体感非常爽。而且它是挂在 IO 层，不会干扰模型初始化，跟其他插件的兼容性几乎无冲突。

安装方式：

harness plugin install stdio-bridge --level core

装完以后，在harness.yaml里确认io_mode: "stdio-json"即可。注意，如果同时开了交互式 shell，需要把interactive: false关掉，否则会产生 IO 竞争。

3.2 harness-config-validator

这个插件是给"配置强迫症"准备的，但我更愿意叫它"灵异报错终结器"。Harness 的配置文件使用 YAML/TOML，层级如果写错，报错信息往往很不直观，尤其是指针引用错误和类型转换问题，光靠看日志根本定位不到。

config-validator 会在每次配置加载阶段做完整的静态校验：字段存在性检查、类型检查、跨配置引用解析、以及必填项缺失检测。校验不通过直接拒绝启动，并输出精确到行号和字段路径的错误提示。

它还支持 schema 热更新。你在开发插件的时候改了插件自带的 schema，validator 能自动检测到并重跑校验，省得每次手动重启服务。对一个插件生态繁荣的框架来说，这个工具价值非常大。

3.3 harness-log-sieve

老实用讲，Harness 的日志系统默认是偏啰嗦的。开启 debug 模式之后，一轮模型调用能打出几百行日志，大部分是内部事件流。你要真在里面捞有用的信息，视力不好真会崩溃。

log-sieve 做的事情也很直接：把日志重新分级过滤。你设一个"关键词优先"规则，它就会把所有日志按重要程度排序输出；对错误日志，它还会自动摘取上下文位置，打印出触发错误的调用链参数。

对我来说，这个插件最大的价值是"错误现场还原"。它能在日志中自动标记出某次工具调用的输入输出快照，这样模型行为异常时，我能直接看到传给工具的参数和返回结果，不需要再手动加 print。

3.4 harness-metrics-reporter

排名第四的 Core 插件是 metrics-reporter，它负责把 Harness 运行时打点信息导出到外部可观测性系统。支持 Prometheus、StatsD、以及本地文件轮转三种模式。

很多人觉得本地工具没必要接监控，但实际用上就会发现不行——Harness 跑久了，内存泄漏、延迟升高、工具调用卡死，这些问题没有指标裸眼看很难发现。metrics-reporter 可以记录这些关键指标，包括每次模型调用的耗时、Token 吞吐量、插件执行延迟、工具调用失败率。

我自己的习惯是开一个轻量 Prometheus + Grafana 的本地组合，但如果你不想上这么重的全家桶，metrics-reporter 的本地文件模式也够用。配置周期 10 秒导出一行 JSON，然后用脚本扫异常就够了。

4. 推理与调试：不是锦上添花，是涨效率的关键

这一类插件是给"调模型效果"和"查问题链路"用的。你要是只想用 Harness 跑通示例，不追求效果，那直接跳过。但凡你希望输出结果更可控，或者遇到"为什么模型答成这样"的困惑，这组插件能省你几十个小时。

4.1 harness-trace-inspector

trace-inspector 本质上是 Harness 的全链路追踪查看器插件，但它的实现方式不是侵入式的，而是拦截事件总线上的数据流。Harness 的每次任务执行，都会在事件总线上发布状态变更事件，trace-inspector 专门捕获这些事件，并在 Web UI 里渲染出一次任务的完整执行过程回放。这个回放能看到什么：

• 模型的输入提示词和原始输出，而且是最终发给模型的完整版本
• 每次工具调用的触发原因、参数、返回结果
• 各阶段的耗时分布，精确定位到到底是推理慢还是工具执行慢
• 上下文窗口的使用情况，当前任务消耗了多少 Token、剩余配额多少

特别是最后一项，实际价值极高。我遇到过很多次"模型突然变傻"的问题，其实就是上下文窗口塞满了，模型在失效的历史信息里找答案。有 trace-inspector 之后，这类问题一眼见底。

使用上它是 Web UI 模式，启动后本机起一个 debug 服务，浏览器访问localhost:18632就能看。如果跑在远程服务器上，注意加一层访问控制，因为调试端口不带鉴权。

4.2 harness-prompt-playground

这个插件在"调提示词"这个场景上，单挑效率最高。Harness 的配置里直接改提示词然后跑任务，一次循环至少两三分钟起步，因为要等模型推理。prompt-playground 做的事情是批量测试。

它允许在一个面板里同时配置多组提示词变量组合，然后并发发往模型服务，返回结果并列对照。你可以快速对比"一样的任务模板，不同的语气描述、不同的示例数量、不同的输出格式约束"到底哪个效果好。

更实用的是它的 version 管理功能。每次进入 playground 修改提示词，都会自动生成一个版本号，随时可以回退到任意历史版本。这对实验性迭代特别重要——有时候你连续调试了七八版，发现还是第三版效果最稳定，没有版本管理就得靠手动备份。

4.3 harness-token-budgeter

它是个"管钱"的插件。模型调用都是要计费的，Harness 场景下很容易出现浪费，一个简单的循环任务能烧掉大量 Token，原因往往是任务失败后的自动重试没有上限，或者 Agent 工具调用陷入循环，反复调用同一个没有副作用的工具。

token-budgeter 可以在任务级别设定硬性额度限制：

budget: max_total_tokens: 100000 max_retries: 2 on_exceed: "suspend" # suspend | abort | notify

超过预算后，任务会被自动挂起或中断，同时通知配置的接收方。它还能按插件维度统计 Token 消耗，这样你能看到"到底哪一步在烧钱"。对于团队共用一套 Harness 服务的场景，这个插件配置不当会直接导致月度账单刷爆。实测下来，我自己的日常开发任务，加上 token-budgeter 之后月成本降了约百分之四十几，因为它能拦截相当多的无效重试。

4.4 harness-context-compactor

这个插件解决的问题是"长对话上下文失控"。Harness 默认不会自动压缩历史消息，只要任务一直跑，上下文窗口就会一直涨。

context-compactor 提供了三种压缩策略：摘要压缩、关键信息抽取、滑窗截断。摘要压缩是用一个轻量模型把早先的历史对话归纳成一段摘要，塞回上下文；关键信息抽取是试图从历史里取出与当前任务最相关的数据，其他全部丢弃；滑窗截断最简单也最快，直接只保留最近 N 轮对话。

实用建议：摘要压缩的效果最好，但会消耗额外的推理时间；关键信息抽取适合信息密度高的场景，比如有大量的 API 返回结果；滑窗截断适合性能优先的场景。各有取舍，不需要一次全开。

5. Agent 编排增强：让 Harness 从"单次问答"升级成"能干活的 Agent"

如果你只用 Harness 跑单轮问答，那这一节的内容可以略过。但凡是让 Harness 自动化执行多步骤任务，或者在工具调用上做了编排，那这一组的插件就非常关键了。

5.1 harness-tool-registry

Harness 默认的工具管理方式比较粗放，把工具函数注册进框架就算完事。但项目一复杂，工具越来越多，管理成本就上来了。harness-tool-registry 提供了一个集中的工具注册中心：

• 支持动态注册和注销，不需要改主配置
• 支持工具版本标记，方便回退
• 支持按命名空间分组，不同任务加载不同的工具集
• 内置了工具健康检查，调用失败次数过多的工具会被自动熔断，避免 Agent 反复调用一个已知失败的工具

这里面最有价值的是工具熔断。Agent 场景里一个很头疼的问题是模型会执着于调用某个"理论上可行"的工具，即使该工具已经连续报错五六次。没有熔断机制，整个任务就会卡死在那里。tool-registry 的熔断器可以在连续 N 次失败后自动将工具降级，同时反馈给 Agent 一个"该工具不可用"的信号，让模型切换策略。

5.2 harness-function-schema-builder

这插件是给"懒人"准备的。写 OpenAI 风格的 function call schema 很烦，要严格定义参数名、类型、描述、required 字段，任何一个环节不严谨都有可能导致模型调用参数错位。

function-schema-builder 支持用 Python 类型注解直接定义函数，然后由插件自动推导生成标准 schema。比如你写一个函数：

@harness_tool() def query_weather(city: str, date: str | None = None) -> dict: """ Query weather information for a given city. Args: city: The city name, e.g. "Beijing". date: Optional date in YYYY-MM-DD format. Default to today. """ ...

这个插件会根据函数签名和 docstring 自动生成包含参数类型、描述、required 判断的 schema，准确率相当高，省去了一大堆手写 JSON 的折磨。

它支持 TypeScript/Python 等多语言的类型系统，不同语言定义的工具都能统一转成标准 schema 注册进 tool-registry。

5.3 harness-planner

这个我要重点说一下。Harness 的 Agent 模式默认的规划策略很简单——让模型直接生成执行计划然后逐步执行。这在小任务上没问题，但任务一复杂就大概率出幺蛾子：计划不合理、步骤遗漏、执行顺序混乱。

harness-planner 把规划拆成了两阶段。第一阶段先生成一个"粗规划"，只定到任务步骤层面，不涉及具体调用；第二阶段再把每个步骤映射到实际工具和参数。这种拆解显著降低了模型在复杂任务上的规划错误率。

它还带一个"plan verify"功能，在正式执行前先把计划发给一个"审查者"模型，检查计划的完备性和依赖关系。审查不通过就打回重新规划，最多重试三次。实测下来，复杂任务的第一轮成功率能从百分之三十几提升到百分之七十多。但却有一个代价，额外多了一轮模型调用，延迟略增。在非实时场景下完全能接受。

5.4 harness-memory-scope

这个插件解决的是 Agent 的持久记忆问题。Harness 默认是无状态执行，任务结束，上下文清零。但很多真实场景需要 Agent 记住之前发生过的事：比如执行的是多轮数据抓取，每一轮的结果会影响下一轮的策略。

memory-scope 提供分层的记忆存储：会话级、任务级、全局级。会话级是单次运行内的短期记忆；任务级能跨多次运行记住同一个任务的关键信息；全局级则适用跨任务的长期信息。

接的存储后端可以是 SQLite（默认）、Redis、PostgreSQL。如果团队已经在用 Redis，那直接配上就行。注意全局记忆要设置过期策略和容量上限，不然存太多垃圾信息之后，Agent 每次读取记忆还要做一次信息检索，反而拖慢响应。

6. 界面与操作效率：日常使用是否顺手，就看这一层

先声明，这一节不代表"装了界面插件就有掌控感"。我的标准很简单：能不能省时间。省时间的界面插件是好插件，只是好看的可以先放放。

6.1 harness-studio

Harness 有一个官方桌面/网页仪表盘，就是热词里经常一起出现的 harness studio。很多社区的讨论经常把 harness-studio 当做一个独立工具，但它本质上就是挂在 Harness 运行时的官方 UI 插件。

它提供任务列表、实时日志查看、执行结果对比、插件管理面板、配置热编辑。特别是配置热编辑功能，可以直接在界面里改harness.yaml的某个字段，保存后不需要重启服务就能生效。前提是不涉及插件列表变更——增删插件还是需要重启的。

如果你的环境比较封闭，跑在无显示器服务器上，也可以只装 Web 模式的 studio，浏览器远程访问。建议在反向代理层加上认证，别裸奔在公网。

6.2 harness-workflow-viz

这个插件能把 Agent 的执行过程绘制成可视化流程图。注意，它和 trace-inspector 的定位有区别：trace-inspector 更像"事后查看回放日志"，workflow-viz 是"实时展示执行状态"。

对调试多步骤 Agent 来说，实时流程图的价值在于能一眼看到当前卡在哪一步。任务如果执行了超过 10 个步骤，纯看日志根本没法判断当前进度。有 workflow-viz，你能在浏览器里看到步骤间的依赖边和当前激活节点，卡住了直接知道是哪一步在阻塞。

6.3 harness-quickrun

这个小工具说实话不炫，但没有它我会有点不太习惯。它在终端里加了一个harness run --quick命令，跳过所有全局初始化检查，减少启动时间。平时跑完整模式大概 3 到 5 秒的启动开销，quickrun 能压到 1 秒内。

它其实是在做"增量初始化"，只加载本次任务必需的插件，跳过闲置的模块。如果你频繁跑小任务，能省下相当多时间。

7. 安装与配置的完整操作：从零到能用

这一节写给第一次接触 Harness 插件的读者。如果你已经装过插件了，前两部分可以快速过一眼，重点看后部分的"配置编排"。

7.1 环境准备与基础安装

Harness 支持主流平台。Windows、macOS、Linux 都提供了安装包，建议先确认你的 Python 版本——Harness 的运行时对版本要求比较严格，官方推荐 Python 3.10 到 3.12 之间，太高或太低都可能在插件编译环节出问题。

基础安装我建议走官方包管理器。Windows 用户注意，安装路径不要带中文和空格，否则部分插件在解析路径时会踩坑。安装完成之后先确认版本：

harness --version

看到版本号输出再进入下一步。

7.2 插件安装命令详解

插件安装的核心命令长这样：

harness plugin install <plugin-name> [--level core|verified|community] [--version x.y.z]

举例说明：

# 安装核心增强插件 harness plugin install stdio-bridge --level core harness plugin install config-validator --level core # 安装一个社区插件并锁定版本 harness plugin install harvest-browser --level community --version 0.3.1

有几个点需要强调：

• 锁定版本很重要。插件市场更新快，有些新版本会变更接口，导致你的配置字段失效。我吃过亏，所以现在凡是社区插件一律锁定版本号。
• 安装命令支持批量处理，配置目录下用harness plugin install --from-file plugins.txt，让批量安装更省事。
• 如果安装失败，第一反应不要盲目重试，先看日志里有没有schema mismatch或handler not found关键字。这两大类错误占了安装失败原因的绝大多数。

7.3 配置文件中的插件编排

所有已安装的插件，统一在harness.yaml里配置启用状态、加载顺序和参数。一个最小可用配置长这样：

plugins: enabled: - stdio-bridge - config-validator - trace-inspector - token-budgeter order: - stdio-bridge - config-validator configs: stdio-bridge: io_mode: "stdio-json" token-budgeter: max_total_tokens: 100000 max_retries: 2 on_exceed: "suspend"

order字段控制加载顺序。顺序很重要，特别是存在 hook 拦截关系的插件，因为这意味着后加载的插件可以在链路上先拦截事件。如果你多个插件都对on_model_init事件做了反应，加载顺序决定了它们的处理顺序。

关于懒加载的那一节我记得已经讲过了，这里就不过多啰嗦。配置完成后，重启 Harness 服务，输入下面命令验证插件加载状态：

harness plugin list

每条插件应该显示enabled状态和版本号。如果某个插件是error状态，优先看日志定位，别急着反复重启。

7.4 插件升级与回滚

插件升级命令是：

harness plugin update <plugin-name>

但升级前强烈建议做一件事：先把当前版本记录到配置文件的locked_versions字段里。这是我在生产环境踩过一次坑之后的标配动作。

有一次我把一个 Agent 编排插件从 0.9.x 升到了 0.10.0，结果它重新命名了好几个 internal API，导致我本来正常的工作流全部崩掉。升级容易回滚难，回滚操作要找到旧版本包再手动替换，非常费时间。所以现在我的习惯是：任意生产环境插件，启动前先harness plugin freeze > plugin-lock.json锁定当前版本，再考虑升级。

8. 实测性能对比：有插件和无插件的差距

说再多理论都不如直接亮数据。下面是我在一台标准开发机（8 核 16G 内存、本地模型服务）上的实测结果，任务是一个典型的多步骤 Agent 工作流，包含 3 次工具调用和 1 次长文本推理。

看到这个数据，有几个结论可以作为参考：

• 插件的启动开销是叠加的，但总量可控。从无插件到全套推荐，启动耗时从 4.2 秒涨到 8.7 秒，还在合理范围内。但如果装了太多低质量社区插件，启动时间能飙到 20 秒以上，不建议追求全量安装。
• 推理调试类插件对成功率的提升最明显。主要是由于 trace-inspector 和 prompt-playground 帮助识别了很多问题，迭代速度上来了，成功率自然就涨了。
• 全套推荐的情况下，虽然任务总耗时略微增长，但成功率从 62% 提升到 83%，这个性价比我觉得很值。

如果你需要的是低延迟场景，可以只保留核心增强和 tool-registry，放弃一部分可观测性，换取更低的启动开销。

9. 常见问题排查链路：装完插件翻车怎么办

插件装多了总会有翻车的时候，这里整理几条我反复踩过的高频问题排查思路。

9.1 插件互相冲突，环境卡住

症状是装了新插件之后，原有功能直接失效，或者报出和之前完全无关的奇怪错误。

排查链路：先停掉所有非核心插件，逐步恢复。具体步骤：

# 先临时禁用所有插件 harness plugin disable --all # 逐个启用并测试 harness plugin enable stdio-bridge harness run --test harness plugin enable trace-inspector harness run --test

通过二分法缩小冲突范围。等定位到两个冲突插件后，去插件市场的 issue 区看看有没有人报过同样问题，基本都会有答案。冲突通常在事件处理器上，如果你懂一点源码，可以看下两个插件 hook 了哪些事件。

9.2 插件启动报 schema 冲突

症状是最直观的：启动 Harness 时直接报schema mismatch或者field not allowed。

原因是插件版本和应用配置版本不同步。插件升级后新增强制字段，但你的配置里没有；或者旧配置里的字段，在新版插件里已经被废弃。

处理方式按三条线排查：

1. harness plugin list查看每个插件的实际版本
2. 去官方文档里确认该版插件对应的配置 schema 是什么
3. 对照修改harness.yaml，把废弃字段删掉、必填字段补上

报schema类错误时千万别跳过直接重启，因为 Harness 的配置解析是启动阶段硬校验的，不修复它永远启动不了。

9.3 插件能加载，但功能不生效

这种情况最恶心，表面上看是个能跑的运行时，插件状态也是 enabled，实际却不干活。

排查优先级：

• 确认事件是不是被其他插件拦截了。多个插件注册了相同优先级的事件处理器时，后加载的插件可能先处理，如果它没有调用next()放行，后面插件就收不到事件。
• 检查懒加载逻辑。如果插件只有走到某个特定分支才实例化，主路径上它是"存在但没初始化"的状态。这种要跑到目标分支才知道插件到底有没有问题。
• 看插件日志级别。Harness 默认日志级别是 WARNING，如果你的插件在 INFO 级别才有有效日志，会误以为它没有干活。把全局日志切到harness --log-level debug，再触发一次任务，就能看到完整调用链。

9.4 插件卸载后配置残留

卸载插件用harness plugin uninstall <plugin-name>，这步没有问题，但它的配置不会自动清理。如果你后来装了同名但不同版本的插件，旧配置可能会被读取，产生不可预期的行为。

稳妥的卸载流程是：先停用，再卸载，最后手动编辑harness.yaml把该插件相关的configs节点全部删除。这套流程养成习惯后能避免很多小毛病。

10. 基于个人经验的最终建议与后续扩展方向

像这种框架类项目的插件生态，发展是很快的。我这份清单基于当前稳定版，但插件市场每个月都有新东西冒出来。我的建议是：不要每出一个新插件就去装，给自己定一个规则——要解决一个明确的痛点才装，或者新的插件比你现在方案强至少一个档次才装。

我自己在用的"黄金配置"大概包含以下八个插件：stdio-bridge、config-validator、log-sieve、metrics-reporter、trace-inspector、tool-registry、function-schema-builder、harness-studio。这个组合能覆盖我百分之九十的日常需求，并且不显得臃肿。

最后分享一个我后期准备尝试的扩展方向：用 harness-tool-registry 加 harness-memory-scope 组合搭建一个长期运行的数据采集 Agent，让它周期性抓取特定信息、写入存储、并且能基于历史结果做策略调整。这个场景对插件的编排能力和记忆能力要求都比较高，正适合拿来做插件体系的压力测试。

另外，如果你在考虑自己写一个 Harness 插件，我的建议是先从harness-plugin-sdk的示例代码入手，跑通一个最简单的带钩子的插件，添加一个自定义工具并注册，可以基于function-schema-builder体验自动 schema 生成，再考虑更复杂的生命周期操作。框架的插件系统是有良好扩展接口的，我自己试过一轮，梳理清楚生命周期之后，开发体验还挺顺畅的。