一个插件,治好了团队用 Agent 时的等待焦虑

本文讲了三件事。Agent 等待时到底卡在哪？DeepSeek Harness 能让我动手改什么？插件 dsh-runstat是如何把等待变得看得见。

团队里用 Codex、Claude 跑 Skill 和各种流程时，经常有人反馈跑得太慢，有时还会卡住。细问慢在哪里，是网络超时、模型迟迟没有输出，还是工具调用太多、执行太久，大家也说不清楚。

我自己也很烦这种等待。一个"正在思考"挂在那里，模型慢也是它，工具卡住也是它，到底还活着没有，只能靠我自己猜。尤其碰上网络不稳定，半天没有动静，继续等心里没底，打断又怕前面的工作白做了。

Codex · 等待界面

Claude Code · 等待界面

两次不同任务中的等待界面。处理时间还在增加，其他提示却很久没有变化，看起来就像卡住了似的。

Codex · 中途重新连接

另一次 Codex 任务已处理 7 分 40 秒。像这样提示"正在重新连接"，至少让我知道它正在尝试恢复连接。

等得久了，什么都开始怀疑。是不是 Skill 写得不好？是不是流程绕远了？还是这件事已经超出了 Agent 的能力？任务还没完成，先把自己折腾得够呛。

现在这些 Agent 已经有很详细的日志了，那为什么不把执行信息实时整理显示出来，看看 Agent 现在到底在干什么？

DeepSeek Harness，一切都是插件

最近在用 DeepSeek Harness（后面简称 DSH），它提倡"一切都是插件"。模型适配、工具、会话存储，甚至 Agent 不断请求模型、调用工具的运行循环，都由插件提供。

这样做的好处，是我们可以改动 Agent 本身。会话想接到公司的存储里，可以换；业务需要特殊的执行流程，也有替换运行循环的接口。这些改动可以通过插件交付，减少直接修改产品源码的需要。

Skill 已经能做很多，还要插件干什么？

平时用 Codex、Claude Code，也会从市场装插件，插件里往往打包了几个 Skill。单看 Skill，已经能覆盖不少事情了——把方法写清楚，Agent 自己加载照着做。那为什么还需要插件里那层代码？

市场里下载的"插件"其实只是一个打包壳，里面可能同时装着 Skill 和运行时代码，也可能只有其一。Skill 是一份写给模型看的"做事说明"，模型读懂、觉得适用才照着做，做不做、做成什么样它自己说了算；运行时代码则相反，由环境在固定节点强制执行，不靠模型自觉。

所以区别在于：Skill 是交给 Agent 加载调用的，插件里的运行时代码则在管住 Agent 每一步怎么走。 后者在指定节点自动跑起来，比如请求模型前选好模型、调用工具前检查权限，不用等模型自己想起来。

比如下面两件事，都要求运行环境替 Agent 把关：光在 Skill 里写明要求没用，必须改到 Agent 的运行机制。

一件是"某个阶段必须用指定模型"。这里说的不是会话开始时手动选一次供应商；Agent 一轮任务里要反复调几十次模型，得在每次请求发出前按环节自动决定这一轮用谁。另一件是"操作生产环境前必须审批"。

这里拿"审批"来看三家各自要开发什么、配置什么。核心差别是"拦截逻辑挂在哪个机制上"：

三家的叫法不同——DSH 统一用 Cordis 插件，Claude Code 用 Mod 或 hook，Codex 用 hook 或交给 App Server 这个外部服务——但套路一样：写一段逻辑，再把它登记到"工具执行前"这个节点。

DSH 的特点，是把模型、审批、存储乃至运行循环，都放进同一套可组合、可替换的插件机制里。需要定制时，可以沿着这套机制继续往里改。

连 UI 都是插件

DSH 更加激进，连自己的网页界面也是插件，不喜欢都可以自己替换掉。

输入框下方、右侧栏等位置都能接入组件，可以自己加状态条、统计面板和操作按钮。我想知道模型有没有返回数据、工具执行了多久，就可以监听运行事件，把状态直接放到输入框下方。前面那个让我烦躁的等待界面，也就有了自己动手改的办法。于是就有了下面这个插件。

我写了个插件，看 Agent 到底在干什么

我写了个插件 dsh-runstat，让它在执行时显示状态，任务结束后给优化建议。

执行时，实时看到状态

对话记录本来就能看到读文件、执行命令等动作。dsh-runstat 把模型阶段、计时、数据是否还在流入，以及批次进度，也集中显示在输入框下方的胶囊里面；想看细节，还能展开面板。

• 模型在做什么：等首包、接收思考内容、输出回复、生成工具调用，分别显示。已经开始接收后，超过 5 秒没有新数据，就提示"流停顿"；失败重试也会显示原因。
• 工具在做什么：显示"运行测试 npm test"或读取哪个文件、哪几行，附上计时和本批完成数量。并行工具分别列出，需要审批或回答时也会提示。
• 进度和耗时：展开面板，查看待办进度、本批工具大致还需多久，也就是 ETA，以及每轮、每步的模型、工具和审批等待耗时。

Harness · 状态在输入框下方

状态放在输入框下方。这时正在接收思考内容，显示已接收字数和用时。

38 秒 · 输出回复

1 分 12 秒 · 思考

2 分 31 秒 · 规划 write 调用

同一任务的三个时刻。上方原生提示只有一个总用时，下方状态条显示当前环节和这一步的计时。第 11 轮这一步从思考进入规划 write 调用，截图时已用 1 分 49 秒。规划调用还不等于工具正在执行。

另一个任务 · 并行规划

另一个任务中，模型同时规划 todo_write 和三个 subagent 调用，状态条合在一行显示。

展开过程记录，每一步旁边都有模型耗时、首包等待、工具耗时和 Token，方便对照哪次请求等得久、哪次工具执行慢。

执行记录 · 每一步的耗时与 Token

执行记录节选：每一步的动作和模型、工具耗时放在一起，方便定位耗时较长的步骤。

执行后，给出优化建议

报告先列出这次的耗时、调用次数和 Token 用量，再指出哪些步骤值得改。这些建议不是空口说的：插件先在本地把执行日志扫一遍，标出哪里值得动，再让模型照着记录判断该怎么改。整套规则来自业界积累的 Agent 工程经验，背后的原理就一句话——

Agent 的时间和 Token，大致等于"来回多少趟 × 每趟带多少东西"。 所以省的方向只有两个：少跑几趟，或者每趟少带点；再进一步，就是别什么都让大模型亲自做，把确定性的活交给脚本、模板或更便宜的模型。

把一次 Skill 或流程的执行摊开看，常会发现不少步骤其实次次都在重复——模型每次现分析、现写脚本、现提问题。这些早该固化下来：

• 靠模型"分析"、但结果其实能用脚本或模板算出来的，固化成脚本或模板，只把真正模糊的那部分留给模型判断。
• 每次都新写的临时脚本，存下来改成带参数的固定脚本，下次直接调用，不再重写重调试。
• 每次都重新问、每次都撞了才想起补的前提，提前写成流程里的约束，在源头堵住坑。

具体到一次执行，还有几条常踩的坑：

• 互相独立的读取、搜索，一次列全并行做，别一步一个来回。
• 反复读的文件，先做索引或摘要按需取，别整段塞回上下文。
• 大份原始数据，让脚本在外面筛完只带回结论，别原样进上下文。

任务结束 · 统计与优化建议

确认任务完成后，面板拆分模型、工具等耗时，并列出具体优化建议及其适用条件。

我平时最常用的一个 skill 是周报汇总，流程一步步是这样：

登录 --> 爬取团队成员信息 --> 提取信息 --> 大模型提炼汇总 --> 按模板排版

这个 skill 当初是让 AI 写出来的，很多环节都靠模型现场写代码去跑，临时脚本写了一大堆，信息也一次只取一点、来回特别多。插件看完这次执行，给了三条优化：

• 把反复重写的爬取、提取脚本固化下来，下次直接调用，别再现场写。
• 原来一次只取一点的信息，改成一次并行抓完。
• 剩下真正需要判断的提炼汇总交给模型，前面的取数和后面的排版都走脚本和模板。

写在最后

各种 Agent 能做的事看上去大差不差，细用起来又各有特点。Codex 的界面和交互已经很顺，Computer Use 插件更是能替你处理电脑上绝大多数事，用着爽，可定制的地方却不多；DSH 把一切都做成插件，定制化强得多，唯独图片、多模态这类能力一直没跟上。

最早我是用 Claude Code 写代码，一用就很上瘾，后来各种日常工作都交给它。接着用上 Codex，界面交互、会话保存、权限自动审批都更丝滑。到现在又觉得 DSH 也不赖，第三方插件市场里的东西是真的多——更关键的是，它让我从"只能干等"变成了"看不顺眼就自己改"。

插件地址：https://github.com/yujiashancheshen/dsh-runstat