概览
去问一个团队他们的流程要花多久，他们会把工作时间加起来：复核一小时、审批二十分钟、准备半天。而端到端一测，是十一天。差额是排队时间——工作躺在收件箱里、等一次批量运行、等一场每周二才开的会、等那个唯一会做这一步的人。
几乎每一次改进努力瞄准的都是「动手时间」，因为那是人们能看见自己在做的部分。它通常不到总时长的十分之一，所以把它砍一半，对端到端时间几乎没有影响，于是所有人得出结论：这个流程就是复杂。
排队时间在每一个工作流系统本来就记录着的时间戳里都看得见，而且它很少是均匀分布的。它集中在某一步上，通常是出于一个结构性的原因：一个唯一审批人、一个只在批量窗口才跑的步骤、一次跨时区团队之间的交接，或者一个退回循环——工作往回走，然后重新排到队尾。
最后这一项是人们最容易漏掉的那条发现，因为返工在吞吐量数字里是隐形的——那个事项最终还是完成了。
这个智能体报告时间实际去哪了，点名每一段排队的结构性成因，并说明去掉它会带来什么变化。它不改动任何工作流，也绝不评估任何个人。
价值
力气对准真正的约束
而不是对准那个人人都能看见自己在做的部分。
省下的是天，不是分钟
因为那些天都在排队里。
返工终于被算进去了
它通常是第二大的成本，而任何报表里都没有它。
功能说明
把排队时间和动手时间分开
动手时间通常不到总量的十分之一。把它砍一半什么也改变不了，而这正是改进努力令人失望的原因。
点名那个结构性成因
一个唯一审批人、一个批量窗口、一次跨时区交接。而不是「这一步很慢」。
度量返工循环
往回走、又重新排队的工作。在吞吐量里是隐形的，因为那个事项最终还是完成了。
找出单点依赖
只有一个人会做的那一步，以及他休假那周流程会怎样。
说明去掉每一段排队能换来什么
折算成端到端时间上减掉的天数，好让这些修补可以互相比较。
不评估任何个人
堵在某个人那一步上的队，是一条产能和设计层面的发现。度量人的速度，改变的是什么被记录下来，而不是实际发生了什么。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 度量一个流程的端到端时间实际去哪了。
- 目前由谁完成
- 靠把工作时间加起来去估，而那完全漏掉了等待。
- 多久一次
- 每当有人抱怨它慢的时候。
- 通常的人工投入
- 排队时间只存在于没人端到端去读的时间戳里。
为什么偏偏是运营。动手时间通常不到总量的十分之一，所以每一次改进努力都瞄准了显眼的那部分，却几乎什么也没改变。而返工在吞吐量里是隐形的，因为那个事项最终还是完成了。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
流程瓶颈分析代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-opus-5，并自动回退
- 3工具extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"items": [],
"period": "H1 2026",
"process": "Customer onboarding"
}输出
{
"rework": {
"commonestLoop": "Credit approval returns items to document check for a missing signature, and they rejoin the queue at the end rather than where they left. None of this appears in throughput, because every one of them eventually completes.",
"addedElapsedHours": 96,
"itemsAffectedPercent": 22
},
"endToEnd": {
"p90Hours": 812,
"medianHours": 264,
"queueTimeHours": 245,
"touchTimeHours": 19,
"queueSharePercent": 92.8
},
"escalate": true,
"disclaimer": "An analysis of your own workflow timestamps. No workflow or assignment has been changed, no individual's speed has been measured or compared, no approval or control is recommended for removal without stating what it prevents, and distributions are reported rather than averages.",
"workingWell": [
"Account setup completes in a median of 40 minutes with no queue. Nothing here should touch it."
],
"queuesByStep": [
{
"step": "Credit approval",
"structuralCause": "One approver holds this step and it waits for the Tuesday credit meeting. An item arriving Wednesday morning waits six days before anyone looks at it.",
"medianQueueHours": 118,
"shareOfTotalQueue": 48.2,
"removingItWouldSave": "Roughly 4.5 days off the median, more than every other fix combined."
},
{
"step": "Document check",
"structuralCause": "A handover between two teams whose working hours overlap by three hours a day.",
"medianQueueHours": 46,
"shareOfTotalQueue": 18.8,
"removingItWouldSave": "About 1.5 days."
}
],
"couldNotMeasure": [
"Started timestamps are missing on one step, so its touch time is excluded and queue time is overstated for it."
],
"distributionNote": "Median 11 days, 90th percentile 34 days. The average of 14 describes almost nothing and is the number currently reported.",
"escalationReason": "One step holds 48.2% of all queue time, depends on a single approver with no cover, and rework affects 22% of items.",
"singleDependencies": [
"Credit approval has one approver and no cover. In the two weeks they were away, median elapsed time went from 11 days to 19."
]
}使用条件
集成
无需集成。
开始之前
- 各事项在各步骤的时间戳：进入、开始、完成
- 每个事项流转到了哪一步，包括往回退的流转
- 工作时间或日历，如果各步骤不同的话
- 需要 全量访问 套餐或更高
使用场景
一个所有人都说太慢的流程
时间实际去哪了。
在把某一步自动化之前
那一步到底是约束，还是只是显眼的那一步。
服务水平出问题
是哪一段排队在造成违约。
一次流程变更之后
那段排队是消失了，还是只是挪了个地方。
价格
常见问题
它会度量个人干活有多快吗？
不会，而且它绝不能。堵在某个人那一步上的队，是一条产能和设计层面的发现。度量人的速度，改变的是什么被记录下来、而不是实际发生了什么，而且它会毁掉这个分析所依赖的数据。
它会改我们的工作流吗？
不会。它没有任何工作流系统的访问权，也不改动任何东西。它报告时间去哪了。
它需要什么数据？
时间戳：每个事项在什么时候进入和离开每一步，以及谁或什么处理了它。每一个工作流、工单和案件系统都已经在记录这些，而几乎没有人端到端地去读它。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体